| Message ID | 20170127010548.27970-1-krisman@collabora.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jan 26, 2017 at 11:05:45PM -0200, Gabriel Krisman Bertazi wrote: > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > output"). qxl_num_crtc defaults to 4 and is configurable as a module > parameter. > > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> > --- > drivers/gpu/drm/qxl/qxl_fb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c > index e6ade6aab54c..4ba2d2f81bd3 100644 > --- a/drivers/gpu/drm/qxl/qxl_fb.c > +++ b/drivers/gpu/drm/qxl/qxl_fb.c > @@ -399,7 +399,7 @@ int qxl_fbdev_init(struct qxl_device *qdev) > &qxl_fb_helper_funcs); > > ret = drm_fb_helper_init(qdev->ddev, &qfbdev->helper, > - qxl_num_crtc /* num_crtc - QXL supports just 1 */, > + qxl_num_crtc, btw if you're super-bored could do an audit to make sure all drivers init crtc before calling this function. And then removing this argument and replacing it with dev->mode_config.num_crtcs. -Daniel > QXLFB_CONN_LIMIT); > if (ret) > goto free; > -- > 2.11.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jan 26, 2017 at 11:05:45PM -0200, Gabriel Krisman Bertazi wrote: > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > output"). qxl_num_crtc defaults to 4 and is configurable as a module > parameter. > > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Since I ended up reading it all anyway, on the entire series: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> > --- > drivers/gpu/drm/qxl/qxl_fb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c > index e6ade6aab54c..4ba2d2f81bd3 100644 > --- a/drivers/gpu/drm/qxl/qxl_fb.c > +++ b/drivers/gpu/drm/qxl/qxl_fb.c > @@ -399,7 +399,7 @@ int qxl_fbdev_init(struct qxl_device *qdev) > &qxl_fb_helper_funcs); > > ret = drm_fb_helper_init(qdev->ddev, &qfbdev->helper, > - qxl_num_crtc /* num_crtc - QXL supports just 1 */, > + qxl_num_crtc, > QXLFB_CONN_LIMIT); > if (ret) > goto free; > -- > 2.11.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote: > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > output"). qxl_num_crtc defaults to 4 and is configurable as a module > parameter. Picked up patches 1-3 for drm-qemu branch. Patch 4 doesn't apply and seems to have a dependency on out-of-tree changes, git am fails to do a 3way merge due to missing commits (trying to apply to 4.10-rc5). cheers, Gerd
On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote: > On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote: > > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > > output"). qxl_num_crtc defaults to 4 and is configurable as a module > > parameter. > > Picked up patches 1-3 for drm-qemu branch. > > Patch 4 doesn't apply and seems to have a dependency on out-of-tree > changes, git am fails to do a 3way merge due to missing commits (trying > to apply to 4.10-rc5). It needs the demidlayer that's already in drm-next ... -Daniel
Daniel Vetter <daniel@ffwll.ch> writes: > On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote: >> On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote: >> > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 >> > output"). qxl_num_crtc defaults to 4 and is configurable as a module >> > parameter. >> >> Picked up patches 1-3 for drm-qemu branch. >> >> Patch 4 doesn't apply and seems to have a dependency on out-of-tree >> changes, git am fails to do a 3way merge due to missing commits (trying >> to apply to 4.10-rc5). > > It needs the demidlayer that's already in drm-next ... Thank you guys for the review. Yes, my patches were based on drm-misc next branch, I should have mentioned that in the original patch. It actually depends on stuff already in drm-misc, so I won't be able to rebase just this to drm-qemu tree. Do you want to merge from drm-misc or should we push this one directly via drm-misc?
Hi, > Do you want to merge from drm-misc or should we push this one > directly via drm-misc? Merging through drm-misc is fine with me. cheers, Gerd
On Fri, Jan 27, 2017 at 02:41:29PM -0200, Gabriel Krisman Bertazi wrote: > Daniel Vetter <daniel@ffwll.ch> writes: > > On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote: > >> On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote: > >> > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > >> > output"). qxl_num_crtc defaults to 4 and is configurable as a module > >> > parameter. > >> > >> Picked up patches 1-3 for drm-qemu branch. > >> > >> Patch 4 doesn't apply and seems to have a dependency on out-of-tree > >> changes, git am fails to do a 3way merge due to missing commits (trying > >> to apply to 4.10-rc5). > > > > It needs the demidlayer that's already in drm-next ... > > Thank you guys for the review. > > Yes, my patches were based on drm-misc next branch, I should have > mentioned that in the original patch. It actually depends on stuff > already in drm-misc, so I won't be able to rebase just this to drm-qemu > tree. > > Do you want to merge from drm-misc or should we push this one > directly via drm-misc? I guess I could ask Gerd whether we wants to be part of the experiment to maintain small drivers in drm-misc, to avoid these kinds of coordination issues? Since some of the patches are in drm-misc and some in the qemu tree we need to wait for them to resync now (I'll send out another drm-misc pull later today). -Daniel
Hi, > I guess I could ask Gerd whether we wants to be part of the experiment to > maintain small drivers in drm-misc, to avoid these kinds of coordination > issues? Sounds reasonable. There isn't much activity, that's why I've grouped all four qemu drivers into a single branch already. The docs throw 403 access denied though atm. So, how would that process look like then? Would you merge my drm-qemu pulls into drm-misc? Or would I commit to drm-misc directly? cheers, Gerd
On Mon, Jan 30, 2017 at 10:41:18AM +0100, Gerd Hoffmann wrote: > Hi, > > > I guess I could ask Gerd whether we wants to be part of the experiment to > > maintain small drivers in drm-misc, to avoid these kinds of coordination > > issues? > > Sounds reasonable. There isn't much activity, that's why I've grouped > all four qemu drivers into a single branch already. > > The docs throw 403 access denied though atm. So, how would that process > look like then? Would you merge my drm-qemu pulls into drm-misc? Or > would I commit to drm-misc directly? drm-misc runs with the committer model, i.e. a few maintainers to do pull requests and backmerges, a big pile of people directly pushing patches. Someone wreaked the entire 01.org domain, but you can get at all the tooling and documentation with git://anongit.freedesktop.org/drm-intel maintainer-tools And then run make in there. We're not yet clear how exactly drivers within drm-misc would look like (wrt which drivers and how much review and stuff like that), hence the RFC. -Daniel
Hi, > drm-misc runs with the committer model, i.e. a few maintainers to do pull > requests and backmerges, a big pile of people directly pushing patches. [ looked at docs too meanwhile ] Sounds good. I guess switching over simplifies things for all of us. We'll avoid issues like the one at hand. Patch flow would be faster too. Right now I'm only doing 1-2 drm-qemu pull requests per kernel release due to low patch volume even for all four qemu drivers combined. > Someone wreaked the entire 01.org domain, but you can get at all the > tooling and documentation with > > git://anongit.freedesktop.org/drm-intel maintainer-tools Hmm. On a quick glance most of dim (except apply-patch) seems to be more useful for maintainers which do merges etc, not so much for committers. I'm used to use https://github.com/stefanha/patches for qemu, and started using it for drm-qemu too. It makes applying patches easier. It manages a patch database, using notmuch mail storage, and can apply patches and patch series from the patch database. That way I don't have to save the patches as mbox somewhere. The tool also picks up [Reviewed,Tested,Acked}-by lines from replies, and it stores the message id (but unlike dim it doesn't build a patchwork link out of it). See bfac9f4fb4d87881375ccdc5c85d5ad59f2f115d for example. Would that format be acceptable for drm-misc? > And then run make in there. We're not yet clear how exactly drivers within > drm-misc would look like (wrt which drivers and how much review and stuff > like that), hence the RFC. Ok. How quickly could I start using drm-misc? I have some pending patches for the 4.11 merge window. Any chance I can push them through drm-misc-next? Or should I better send a pull req to Dave? cheers, Gerd PS: I'm kraxel@freedesktop.org
On Mon, Jan 30, 2017 at 06:14:49PM +0100, Gerd Hoffmann wrote: > Hi, > > > drm-misc runs with the committer model, i.e. a few maintainers to do pull > > requests and backmerges, a big pile of people directly pushing patches. > > [ looked at docs too meanwhile ] > > Sounds good. I guess switching over simplifies things for all of us. > We'll avoid issues like the one at hand. Patch flow would be faster > too. Right now I'm only doing 1-2 drm-qemu pull requests per kernel > release due to low patch volume even for all four qemu drivers combined. Yeah, with dim I do send out pull requests every 1-2 weeks, depending upon how much pending stuff there is. > > Someone wreaked the entire 01.org domain, but you can get at all the > > tooling and documentation with > > > > git://anongit.freedesktop.org/drm-intel maintainer-tools > > Hmm. On a quick glance most of dim (except apply-patch) seems to be > more useful for maintainers which do merges etc, not so much for > committers. > > I'm used to use https://github.com/stefanha/patches for qemu, and > started using it for drm-qemu too. It makes applying patches easier. > It manages a patch database, using notmuch mail storage, and can apply > patches and patch series from the patch database. That way I don't have > to save the patches as mbox somewhere. The tool also picks up > [Reviewed,Tested,Acked}-by lines from replies, and it stores the message > id (but unlike dim it doesn't build a patchwork link out of it). > > See bfac9f4fb4d87881375ccdc5c85d5ad59f2f115d for example. That sha1 isn't in linux-next, so no idea. But in principle, yes dim isn't all that much about handling patches, and much more about handling branches. One part that imo really should stick around is the drm-tip integration tree rebuilding. That allows us to distribute conflict handling (e.g. between drm-misc-fixes and drm-misc-next), and with more people and more drivers in drm-misc I expect more conflicts. > Would that format be acceptable for drm-misc? The other bit is that dim is a nice place for catching obvious screw-ups. E.g. for drm-intel it checks that the patch only touches i915, and if not if there's an ack from Dave on it. So I think standardizing on that tool has benefits (as long as we can't just enforce such simple checks with CI on the server side). But dim apply-branch is a supposed to be a drop-in replacement for git apply-mbox, so should be simple to integrate into another set of scripts to manage the mails. And if there's changes to dim needed to make that happen, we can do that (we push patches to it at a regular pace). > > And then run make in there. We're not yet clear how exactly drivers within > > drm-misc would look like (wrt which drivers and how much review and stuff > > like that), hence the RFC. > > Ok. How quickly could I start using drm-misc? I have some pending > patches for the 4.11 merge window. Any chance I can push them through > drm-misc-next? Or should I better send a pull req to Dave? If you want you can get started right away. I plan to type some small docs for this experiment, but the only thing you need is an fdo account with drm-misc commit rights. Simplest to ping me (and fdo admins) on #dri-devel. -Daniel
Hi, > branches. One part that imo really should stick around is the drm-tip > integration tree rebuilding. That allows us to distribute conflict > handling (e.g. between drm-misc-fixes and drm-misc-next), and with more > people and more drivers in drm-misc I expect more conflicts. Ok, good point. I see there is a separate "dim rebuild-top" command, so that should be doable no matter how I actually apply the patches. Trying to run dim throws errors at me though: kraxel@nilsson ~/tmp/maintainer-tools (maintainer-tools)# ./dim help ./dim: line 1602: declare: -n: invalid option declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...] kraxel@nilsson ~/tmp/maintainer-tools (maintainer-tools)# bash --version GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu) > But dim apply-branch is a supposed to be a drop-in replacement for git > apply-mbox, so should be simple to integrate into another set of scripts > to manage the mails. And if there's changes to dim needed to make that > happen, we can do that (we push patches to it at a regular pace). The patches tool prepares a mbox file, then runs "git am". Shouldn't be that hard to make it configurable ... > > Ok. How quickly could I start using drm-misc? I have some pending > > patches for the 4.11 merge window. Any chance I can push them through > > drm-misc-next? Or should I better send a pull req to Dave? > > If you want you can get started right away. I plan to type some small docs > for this experiment, but the only thing you need is an fdo account with > drm-misc commit rights. Simplest to ping me (and fdo admins) on > #dri-devel. Ok. cheers, Gerd
On Tue, Jan 31, 2017 at 09:55:46AM +0100, Gerd Hoffmann wrote: > Hi, > > > branches. One part that imo really should stick around is the drm-tip > > integration tree rebuilding. That allows us to distribute conflict > > handling (e.g. between drm-misc-fixes and drm-misc-next), and with more > > people and more drivers in drm-misc I expect more conflicts. > > Ok, good point. I see there is a separate "dim rebuild-top" command, so > that should be doable no matter how I actually apply the patches. > > Trying to run dim throws errors at me though: > > kraxel@nilsson ~/tmp/maintainer-tools (maintainer-tools)# ./dim help > ./dim: line 1602: declare: -n: invalid option > declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...] > kraxel@nilsson ~/tmp/maintainer-tools (maintainer-tools)# bash --version > GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu) Hm, this is strange. I have GNU bash, version 4.4.5(1)-release (x86_64-pc-linux-gnu) here, but Jani is on debian stable so I guess even older bash than yours. Adding Jani, maybe he has an idea. -Daniel
On Tue, 31 Jan 2017, Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > >> branches. One part that imo really should stick around is the drm-tip >> integration tree rebuilding. That allows us to distribute conflict >> handling (e.g. between drm-misc-fixes and drm-misc-next), and with more >> people and more drivers in drm-misc I expect more conflicts. > > Ok, good point. I see there is a separate "dim rebuild-top" command, so > that should be doable no matter how I actually apply the patches. > > Trying to run dim throws errors at me though: > > kraxel@nilsson ~/tmp/maintainer-tools (maintainer-tools)# ./dim help > ./dim: line 1602: declare: -n: invalid option > declare: usage: declare [-aAfFgilrtux] [-p] [name[=value] ...] > kraxel@nilsson ~/tmp/maintainer-tools (maintainer-tools)# bash --version > GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu) declare -n introduced in bash 4.3 is needed for alias support. Workaround at [1]. [1] https://lists.freedesktop.org/archives/intel-gfx/2017-January/118474.html >> But dim apply-branch is a supposed to be a drop-in replacement for git >> apply-mbox, so should be simple to integrate into another set of scripts >> to manage the mails. And if there's changes to dim needed to make that >> happen, we can do that (we push patches to it at a regular pace). > > The patches tool prepares a mbox file, then runs "git am". Shouldn't be > that hard to make it configurable ... N.b. dim currently doesn't do all its magic, such as adding Link: tag, if you apply more than one patch at a time. If you apply a multi-patch mbox, only the last one will get the Link: tag. BR, Jani. >> > Ok. How quickly could I start using drm-misc? I have some pending >> > patches for the 4.11 merge window. Any chance I can push them through >> > drm-misc-next? Or should I better send a pull req to Dave? >> >> If you want you can get started right away. I plan to type some small docs >> for this experiment, but the only thing you need is an fdo account with >> drm-misc commit rights. Simplest to ping me (and fdo admins) on >> #dri-devel. > > Ok. > > cheers, > Gerd > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi, > declare -n introduced in bash 4.3 is needed for alias > support. Workaround at [1]. > > [1] https://lists.freedesktop.org/archives/intel-gfx/2017-January/118474.html Works for me. Thanks. > N.b. dim currently doesn't do all its magic, such as adding Link: tag, > if you apply more than one patch at a time. If you apply a multi-patch > mbox, only the last one will get the Link: tag. Hmm, that is bad. One of the things the patches tool actually is very good at is applying a patch series. Grab the patches from the list, put them into a mbox file, in the correct order (which is a PITA to do manually with a MUA, especially in case there are replies with reviewed-by, ...). Does dim detect that a Link: tag is already present and doesn't add another one then? cheers, Gerd
On Tue, 31 Jan 2017, Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > >> declare -n introduced in bash 4.3 is needed for alias >> support. Workaround at [1]. >> >> [1] https://lists.freedesktop.org/archives/intel-gfx/2017-January/118474.html > > Works for me. Thanks. Thanks, pushed. >> N.b. dim currently doesn't do all its magic, such as adding Link: tag, >> if you apply more than one patch at a time. If you apply a multi-patch >> mbox, only the last one will get the Link: tag. > > Hmm, that is bad. Agreed. > One of the things the patches tool actually is very good at is applying > a patch series. Grab the patches from the list, put them into a mbox > file, in the correct order (which is a PITA to do manually with a MUA, > especially in case there are replies with reviewed-by, ...). Oh, it's a Notmuch based tool? Cool. I should add that to the Notmuch wiki. The notmuch-emacs interface lets you pipe all the open messages in a thread using "c-u |". So you can expand/collapse messages as you like, and pipe them all as mbox. But that doesn't work either because dim can't properly handle it. I have a vested interest to fix this, but I haven't gotten around to it... > Does dim detect that a Link: tag is already present and doesn't add > another one then? Nope. Patches welcome. ;) BR, Jani.
On Fr, 2017-01-27 at 14:53 +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote: > > On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote: > > > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > > > output"). qxl_num_crtc defaults to 4 and is configurable as a module > > > parameter. > > > > Picked up patches 1-3 for drm-qemu branch. > > > > Patch 4 doesn't apply and seems to have a dependency on out-of-tree > > changes, git am fails to do a 3way merge due to missing commits (trying > > to apply to 4.10-rc5). > > It needs the demidlayer that's already in drm-next ... Ok, added all four patches to drm-qemu. drm-qemu is based on drm-misc-next now and basically just a staging branch where I can test patches before pushing them to drm-misc-next. cheers, Gerd
Hi, > > Does dim detect that a Link: tag is already present and doesn't add > > another one then? > > Nope. Patches welcome. ;) For now I've settled to applying patches with the patches tool, a little shell script to rewrite "Message-id:" lines into patchwork links, and using dim to push updates. cheers, Gerd
Gerd Hoffmann <kraxel@redhat.com> writes: > On Fr, 2017-01-27 at 14:53 +0100, Daniel Vetter wrote: >> On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote: >> > On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote: >> > > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 >> > > output"). qxl_num_crtc defaults to 4 and is configurable as a module >> > > parameter. >> > >> > Picked up patches 1-3 for drm-qemu branch. >> > >> > Patch 4 doesn't apply and seems to have a dependency on out-of-tree >> > changes, git am fails to do a 3way merge due to missing commits (trying >> > to apply to 4.10-rc5). >> >> It needs the demidlayer that's already in drm-next ... > > Ok, added all four patches to drm-qemu. Thank you, Gerd!
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c index e6ade6aab54c..4ba2d2f81bd3 100644 --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c @@ -399,7 +399,7 @@ int qxl_fbdev_init(struct qxl_device *qdev) &qxl_fb_helper_funcs); ret = drm_fb_helper_init(qdev->ddev, &qfbdev->helper, - qxl_num_crtc /* num_crtc - QXL supports just 1 */, + qxl_num_crtc, QXLFB_CONN_LIMIT); if (ret) goto free;
No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 output"). qxl_num_crtc defaults to 4 and is configurable as a module parameter. Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> --- drivers/gpu/drm/qxl/qxl_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)