Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
personal messages follow:
Thomas: I merged some of the vmware patches I saw, I got to [6/8] drm/vmwgfx: Refactor resource management it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on top of this tree, or point me to what I missed that makes it all magically work!
Alex/Ben: -next trees if you have anything interesting.
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window! I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
Imre: merged the monotonic timestamps, please confirm it was okay!
Thierry: congrats I merged tegra, thanks for the hard work!
Maarten: merged some of the TTM patches, you might want to send me a summary of any other TH reviewed that I haven't picked up on yet.
Anyone else that sent stuff and can't find it and it needs to be in here, do let me know!
Dave.
On 11/20/2012 07:39 AM, Dave Airlie wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
personal messages follow:
Thomas: I merged some of the vmware patches I saw, I got to [6/8] drm/vmwgfx: Refactor resource management it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on top of this tree, or point me to what I missed that makes it all magically work!
It appears they conflicted with the TTM sync_obj_arg removal patches. Please apply
[PATCH -next 0/5] drm/ttm: Get rid of a number of atomic read-modify-write ops addons (This is the diff for the latest version of Get rid of a number of atomic read-modify-write ops)
[PATCH -next 0/3] vmwgfx stuff for -next rebased (This is the patches 6/8 that didn't apply previously)
[PATCH -next] drm/ttm: Optimize vm locking using kref_get_unless_zero (Small patch that gets rid of a write lock around buffer object unreferences)
Thanks, Thomas
On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
I don't the atomic stuff is quite ready for merging yet. However my code is more or less feature complete now. I have implemented everything I planned to originally, apart from adding more properties for various things. And as I mentioned before, Weston is now running quite nicely on top of my kernel branch.
What's still missing is some refactoring, and possibly some fixes. And hardly anyone has commented on it, so please everyone have a look and let me know what you think. Maybe I need to start a blog to get people interested...
Oh and there's now that 8byte get_user() issue that needs to be sorted out on x86-32.
As far as the i915 specific stuff goes, I need to get someone to look at the GPU sync stuff. And then there's the bigger question of whether we could do the whole atomic page flip thing via the ring, but that's not something that we need to worry about today.
On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
I don't the atomic stuff is quite ready for merging yet. However my code is more or less feature complete now. I have implemented everything I planned to originally, apart from adding more properties for various things. And as I mentioned before, Weston is now running quite nicely on top of my kernel branch.
What's still missing is some refactoring, and possibly some fixes. And hardly anyone has commented on it, so please everyone have a look and let me know what you think. Maybe I need to start a blog to get people interested...
it would be nice to at least pull in the object and signed property type stuff from my branch, since that is effecting userspace facing API..
All the plane/crtc/etc state object stuff doesn't effect abi so could come later, I suppose. It does touch a lot of drivers even if they aren't converted to 'atomic', but OTOH I think it makes things much cleaner and easier to 'atomicify' a driver without duplicating so much stuff in each driver. So long term I still think it is the right thing. But not sure how much more time I'll spend on it in the near term.
BR, -R
Oh and there's now that 8byte get_user() issue that needs to be sorted out on x86-32.
As far as the i915 specific stuff goes, I need to get someone to look at the GPU sync stuff. And then there's the bigger question of whether we could do the whole atomic page flip thing via the ring, but that's not something that we need to worry about today.
-- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Nov 20, 2012 at 11:27:20AM -0600, Rob Clark wrote:
On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
I don't the atomic stuff is quite ready for merging yet. However my code is more or less feature complete now. I have implemented everything I planned to originally, apart from adding more properties for various things. And as I mentioned before, Weston is now running quite nicely on top of my kernel branch.
What's still missing is some refactoring, and possibly some fixes. And hardly anyone has commented on it, so please everyone have a look and let me know what you think. Maybe I need to start a blog to get people interested...
it would be nice to at least pull in the object and signed property type stuff from my branch, since that is effecting userspace facing API..
Yeah, I still need to go over your code properly. What I remember from the last time I looked at it was that the signed property type is fine by me, the dynamic flag I don't really agree with, since you probably can't set it for most things anyway, and the state stuff is touching a lot of places at the same time, which is somehting I've been trying to avoid at this stage.
All the plane/crtc/etc state object stuff doesn't effect abi so could come later, I suppose. It does touch a lot of drivers even if they aren't converted to 'atomic', but OTOH I think it makes things much cleaner and easier to 'atomicify' a driver without duplicating so much stuff in each driver. So long term I still think it is the right thing. But not sure how much more time I'll spend on it in the near term.
I don't really want to push a huge change to all code paths at the same time. The current setcrtc/pageflip code is known to work (sort of at least), so if something were to regress we'd possibly have to back out the whole thing. So I'd like to get the atomic stuff in as a separate thing first.
Once it's in we can start to fix the state handling, and also start calling into the atomic code from the legacy code paths.
Another detail we nee to figure out is the actual properties that we're using. I personally don't like the crtc.SRC_X and crtc.SRC_Y properties that my code has for example. They don't behave like the plane properties with the same names, so maybe we should use different names for them. Well, idelly we wouldn't even have them, but moving all scanout duties over to planes is another thing I really don't want to tie into the atomic stuff at this point in time. I suppose we can't deprecate any properties easily, so we need to make sure we can all live with the ones we add initially.
On Tue, Nov 20, 2012 at 11:53 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Nov 20, 2012 at 11:27:20AM -0600, Rob Clark wrote:
On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
I don't the atomic stuff is quite ready for merging yet. However my code is more or less feature complete now. I have implemented everything I planned to originally, apart from adding more properties for various things. And as I mentioned before, Weston is now running quite nicely on top of my kernel branch.
What's still missing is some refactoring, and possibly some fixes. And hardly anyone has commented on it, so please everyone have a look and let me know what you think. Maybe I need to start a blog to get people interested...
it would be nice to at least pull in the object and signed property type stuff from my branch, since that is effecting userspace facing API..
Yeah, I still need to go over your code properly. What I remember from the last time I looked at it was that the signed property type is fine by me, the dynamic flag I don't really agree with, since you probably can't set it for most things anyway, and the state stuff is touching a lot of places at the same time, which is somehting I've been trying to avoid at this stage.
The dynamic flag is a bit of an optimization. It is really only intended to be set for properties that can always be changed without risk of fail. There is no obligation for a driver to set it, since it should be an opt-in sort of thing for the driver. Which also means that it is safe to add at a later stage, so I don't mind leaving it for later. But object and signed property types would be good to have from the beginning.
All the plane/crtc/etc state object stuff doesn't effect abi so could come later, I suppose. It does touch a lot of drivers even if they aren't converted to 'atomic', but OTOH I think it makes things much cleaner and easier to 'atomicify' a driver without duplicating so much stuff in each driver. So long term I still think it is the right thing. But not sure how much more time I'll spend on it in the near term.
I don't really want to push a huge change to all code paths at the same time. The current setcrtc/pageflip code is known to work (sort of at least), so if something were to regress we'd possibly have to back out the whole thing. So I'd like to get the atomic stuff in as a separate thing first.
true, although most of the changes for drivers with the state stuff, before they migrate to atomic, are just braindead search/replace stuff, so not much risk of breaking things. Just a pain to merge through a bunch of different driver trees, that is all.
Once it's in we can start to fix the state handling, and also start calling into the atomic code from the legacy code paths.
yeah, handling legacy ioctls with "atomicified" drivers is an issue.. mainly with the setplane ioctl because we never really defined if it was async or not or what the meaning is if it is called and the driver is still pending a flip. The good news is there aren't many users of that API yet. And if we pass the flags to the atomic fxns to indicate if the update should be async or not, we could just not pass the async flag in the legacy setplane path. So I think this is doable.. but maybe a bit more risky.
We could always handle conversion of legacy paths to atomic as a later patch, if that helps reduce the risk.
Another detail we nee to figure out is the actual properties that we're using. I personally don't like the crtc.SRC_X and crtc.SRC_Y properties that my code has for example. They don't behave like the plane properties with the same names, so maybe we should use different names for them. Well, idelly we wouldn't even have them, but moving all scanout duties over to planes is another thing I really don't want to tie into the atomic stuff at this point in time. I suppose we can't deprecate any properties easily, so we need to make sure we can all live with the ones we add initially.
hmm, maybe it is a good idea to give different property names for crtc src x/y. I guess it isn't completely different from plane SRC_X/Y except there is no scaling and CRTC_X/Y is always 0,0..
OTOH, separating plane and crtc would be a generally nice thing to do and maybe avoids some hacks. So I wouldn't object to trying to do that first before converting stuff to properties/atomic, or at least as part of the properties/atomic changes. I think it should not be a big deal for existing drivers to create a dummy plane that can only be bound to a single crtc. And it would mean any userspace that supports the atomic ioctl also understands hw where scanout engine is decoupled from crtc. I hadn't thought about it much yet, but decoupling the scanout engine from crtc as part of the atomic ioctl avoids an intermediate generation of userspace clients of the API that we have to support forever.
BR, -R
-- Ville Syrjälä Intel OTC
On Tue, Nov 20, 2012 at 7:39 AM, Dave Airlie airlied@gmail.com wrote:
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window!
Yeah, winding down, no big stuff pending, just a few small bits&pieces. If we'll see an -rc7 release, I'll run another manual QA cycle, otherwise I'll just send you a -fixes pull with it somewhen next week.
I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
I've noticed that you didn't merge "drm: don't unnecessarily enable the polling work" (note there's a v2 follow-up). Anything wrong with it or just overlooked?
Also, there's my small series to integrate some of the helper in-line kerneldoc into Laurent DRM DocBook, starting with "drm/doc: Helpers are not a Midlayer!". So of the patches depended upon the dp helper refactor, but now that's merged they should apply.
Another thing is the clock_monotonic timestamp stuff for pageflips/vblanks. I'll poke Imre about this again, but I guess we'll postpone that for 3.9. Otherwise I don't see anything missing.
Cheers, Daniel
On Wed, Nov 21, 2012 at 8:28 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Nov 20, 2012 at 7:39 AM, Dave Airlie airlied@gmail.com wrote:
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window!
Yeah, winding down, no big stuff pending, just a few small bits&pieces. If we'll see an -rc7 release, I'll run another manual QA cycle, otherwise I'll just send you a -fixes pull with it somewhen next week.
I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
I've noticed that you didn't merge "drm: don't unnecessarily enable the polling work" (note there's a v2 follow-up). Anything wrong with it or just overlooked?
I thought I did, a4f968d8e50cb7810e08ebb9bf4c8f2b769fdac7
I applied the wrong one and rebased it out, then got the right one later.
Also, there's my small series to integrate some of the helper in-line kerneldoc into Laurent DRM DocBook, starting with "drm/doc: Helpers are not a Midlayer!". So of the patches depended upon the dp helper refactor, but now that's merged they should apply.
Okay I'll pick them up.
Another thing is the clock_monotonic timestamp stuff for pageflips/vblanks. I'll poke Imre about this again, but I guess we'll postpone that for 3.9. Otherwise I don't see anything missing.
I merged this, at least the core stuff. It just seemed like it might go somewhere if it was in the tree :-)
Dave.
On Wed, Nov 21, 2012 at 12:11 PM, Dave Airlie airlied@gmail.com wrote:
On Wed, Nov 21, 2012 at 8:28 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Nov 20, 2012 at 7:39 AM, Dave Airlie airlied@gmail.com wrote:
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window!
Yeah, winding down, no big stuff pending, just a few small bits&pieces. If we'll see an -rc7 release, I'll run another manual QA cycle, otherwise I'll just send you a -fixes pull with it somewhen next week.
I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
I've noticed that you didn't merge "drm: don't unnecessarily enable the polling work" (note there's a v2 follow-up). Anything wrong with it or just overlooked?
I thought I did, a4f968d8e50cb7810e08ebb9bf4c8f2b769fdac7
I applied the wrong one and rebased it out, then got the right one later.
Yeah, missed that one.
Also, there's my small series to integrate some of the helper in-line kerneldoc into Laurent DRM DocBook, starting with "drm/doc: Helpers are not a Midlayer!". So of the patches depended upon the dp helper refactor, but now that's merged they should apply.
Okay I'll pick them up.
Another thing is the clock_monotonic timestamp stuff for pageflips/vblanks. I'll poke Imre about this again, but I guess we'll postpone that for 3.9. Otherwise I don't see anything missing.
I merged this, at least the core stuff. It just seemed like it might go somewhere if it was in the tree :-)
Yeah, missed those too. I'll go and harp about updating the i-g-t testcases now ;-)
Thanks, Daniel
On Tue, Nov 20, 2012 at 12:39 AM, Dave Airlie airlied@gmail.com wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
personal messages follow:
Thomas: I merged some of the vmware patches I saw, I got to [6/8] drm/vmwgfx: Refactor resource management it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on top of this tree, or point me to what I missed that makes it all magically work!
Alex/Ben: -next trees if you have anything interesting.
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window! I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
Imre: merged the monotonic timestamps, please confirm it was okay!
Thierry: congrats I merged tegra, thanks for the hard work!
Maarten: merged some of the TTM patches, you might want to send me a summary of any other TH reviewed that I haven't picked up on yet.
Anyone else that sent stuff and can't find it and it needs to be in here, do let me know!
I've got a couple patchsets that I suppose need to come in through a few different trees. Dave, maybe for drivers where you don't get pull req's from other trees (udl, i2c, not sure about shmob, imx, or vmwgfx) these could be merged directly via drm tree. For intel/nouveau/radeon/etc, it would be nice if the respective tree maintainers would pull in the patch for their driver.
First series, removing legacy drm_connector property fxns and converting everything to use the newer object property fxns. The driver patches have no dependency on drm core. The last patch on drm core cannot be merged until the driver patches are merged. So maybe leave that last one for 3.9 and try and get all the driver patches in 3.8? Let me know if I need to rebase or update any other new code to get rid of legacy drm_connector property fxn usage.
bffa1b5 drm/i2c: drm_connector_property -> drm_object_property f921b8a drm/vmwgfx: drm_connector_property -> drm_object_property 696cfcf drm/udl: drm_connector_property -> drm_object_property 6745d89 drm/shmob: drm_connector_property -> drm_object_property f4f1593 drm/radeon: drm_connector_property -> drm_object_property 52673d8 drm/nouveau: drm_connector_property -> drm_object_property 7830a92 drm/gma500: drm_connector_property -> drm_object_property 493663d drm/i915: drm_connector_property -> drm_object_property a4aac9a drm: remove legacy drm_connector_property fxns
Second series, the drm_send_vblank_event() helper. The drm core patch which adds this fxn is in drm-next now, so when various driver trees have rebased on latest drm-next they can merge their corresponding driver patch to use the new helper:
8669e97 drm/imx: use drm_send_vblank_event() helper 1b85506 drm/shmob: use drm_send_vblank_event() helper 8efe90e drm/exynos: use drm_send_vblank_event() helper 9438973 drm/radeon: use drm_send_vblank_event() helper 49e6038 drm/nouveau: use drm_send_vblank_event() helper 6af9075 drm/i915: use drm_send_vblank_event() helper
BR, -R
Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Nov 21, 2012 at 11:23 AM, Rob Clark robdclark@gmail.com wrote:
On Tue, Nov 20, 2012 at 12:39 AM, Dave Airlie airlied@gmail.com wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
personal messages follow:
Thomas: I merged some of the vmware patches I saw, I got to [6/8] drm/vmwgfx: Refactor resource management it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on top of this tree, or point me to what I missed that makes it all magically work!
Alex/Ben: -next trees if you have anything interesting.
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window! I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
Imre: merged the monotonic timestamps, please confirm it was okay!
Thierry: congrats I merged tegra, thanks for the hard work!
Maarten: merged some of the TTM patches, you might want to send me a summary of any other TH reviewed that I haven't picked up on yet.
Anyone else that sent stuff and can't find it and it needs to be in here, do let me know!
I've got a couple patchsets that I suppose need to come in through a few different trees. Dave, maybe for drivers where you don't get pull req's from other trees (udl, i2c, not sure about shmob, imx, or vmwgfx) these could be merged directly via drm tree. For intel/nouveau/radeon/etc, it would be nice if the respective tree maintainers would pull in the patch for their driver.
I'm not sure if its worth the effort to try and push all the individual patches through the various driver trees it it's all part of one larger patch set. Seems like it would be easier to just push the whole set together.
First series, removing legacy drm_connector property fxns and converting everything to use the newer object property fxns. The driver patches have no dependency on drm core. The last patch on drm core cannot be merged until the driver patches are merged. So maybe leave that last one for 3.9 and try and get all the driver patches in 3.8? Let me know if I need to rebase or update any other new code to get rid of legacy drm_connector property fxn usage.
bffa1b5 drm/i2c: drm_connector_property -> drm_object_property f921b8a drm/vmwgfx: drm_connector_property -> drm_object_property 696cfcf drm/udl: drm_connector_property -> drm_object_property 6745d89 drm/shmob: drm_connector_property -> drm_object_property f4f1593 drm/radeon: drm_connector_property -> drm_object_property 52673d8 drm/nouveau: drm_connector_property -> drm_object_property 7830a92 drm/gma500: drm_connector_property -> drm_object_property 493663d drm/i915: drm_connector_property -> drm_object_property a4aac9a drm: remove legacy drm_connector_property fxns
I'm fine with the radeon parts of this just going in via your tree or drm directly unless you want me to pick it up specifically.
Second series, the drm_send_vblank_event() helper. The drm core patch which adds this fxn is in drm-next now, so when various driver trees have rebased on latest drm-next they can merge their corresponding driver patch to use the new helper:
8669e97 drm/imx: use drm_send_vblank_event() helper 1b85506 drm/shmob: use drm_send_vblank_event() helper 8efe90e drm/exynos: use drm_send_vblank_event() helper 9438973 drm/radeon: use drm_send_vblank_event() helper 49e6038 drm/nouveau: use drm_send_vblank_event() helper 6af9075 drm/i915: use drm_send_vblank_event() helper
Same with this one.
Alex
On Wed, Nov 21, 2012 at 11:05 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Wed, Nov 21, 2012 at 11:23 AM, Rob Clark robdclark@gmail.com wrote:
On Tue, Nov 20, 2012 at 12:39 AM, Dave Airlie airlied@gmail.com wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
personal messages follow:
Thomas: I merged some of the vmware patches I saw, I got to [6/8] drm/vmwgfx: Refactor resource management it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on top of this tree, or point me to what I missed that makes it all magically work!
Alex/Ben: -next trees if you have anything interesting.
Daniel: I've pulled -next from you, I'm hoping that is all you have for this merge window! I've also merge the polling rework, I'll have to spend a bit of time testing it I suppose now.
Imre: merged the monotonic timestamps, please confirm it was okay!
Thierry: congrats I merged tegra, thanks for the hard work!
Maarten: merged some of the TTM patches, you might want to send me a summary of any other TH reviewed that I haven't picked up on yet.
Anyone else that sent stuff and can't find it and it needs to be in here, do let me know!
I've got a couple patchsets that I suppose need to come in through a few different trees. Dave, maybe for drivers where you don't get pull req's from other trees (udl, i2c, not sure about shmob, imx, or vmwgfx) these could be merged directly via drm tree. For intel/nouveau/radeon/etc, it would be nice if the respective tree maintainers would pull in the patch for their driver.
I'm not sure if its worth the effort to try and push all the individual patches through the various driver trees it it's all part of one larger patch set. Seems like it would be easier to just push the whole set together.
I'm ok with either approach.. I'm just rebasing the i915 for danvet, but others can go directly via drm tree if Dave prefers.
BR, -R
First series, removing legacy drm_connector property fxns and converting everything to use the newer object property fxns. The driver patches have no dependency on drm core. The last patch on drm core cannot be merged until the driver patches are merged. So maybe leave that last one for 3.9 and try and get all the driver patches in 3.8? Let me know if I need to rebase or update any other new code to get rid of legacy drm_connector property fxn usage.
bffa1b5 drm/i2c: drm_connector_property -> drm_object_property f921b8a drm/vmwgfx: drm_connector_property -> drm_object_property 696cfcf drm/udl: drm_connector_property -> drm_object_property 6745d89 drm/shmob: drm_connector_property -> drm_object_property f4f1593 drm/radeon: drm_connector_property -> drm_object_property 52673d8 drm/nouveau: drm_connector_property -> drm_object_property 7830a92 drm/gma500: drm_connector_property -> drm_object_property 493663d drm/i915: drm_connector_property -> drm_object_property a4aac9a drm: remove legacy drm_connector_property fxns
I'm fine with the radeon parts of this just going in via your tree or drm directly unless you want me to pick it up specifically.
Second series, the drm_send_vblank_event() helper. The drm core patch which adds this fxn is in drm-next now, so when various driver trees have rebased on latest drm-next they can merge their corresponding driver patch to use the new helper:
8669e97 drm/imx: use drm_send_vblank_event() helper 1b85506 drm/shmob: use drm_send_vblank_event() helper 8efe90e drm/exynos: use drm_send_vblank_event() helper 9438973 drm/radeon: use drm_send_vblank_event() helper 49e6038 drm/nouveau: use drm_send_vblank_event() helper 6af9075 drm/i915: use drm_send_vblank_event() helper
Same with this one.
Alex
On Tue, Nov 20, 2012 at 1:39 AM, Dave Airlie airlied@gmail.com wrote:
Okay just pushed out a bunch of -next queued stuff,
I've been stuck on another project for a couple of weeks and haven't really being paying enough attention to -next, so this is a heads up, if someone has something big they want merged this window and I haven't seen it yet or merged it yet, you should probably mention it in a reply to this mail with a summary of where you think its at. (e.g. atomic nuclear modesetting flipping).
personal messages follow:
Thomas: I merged some of the vmware patches I saw, I got to [6/8] drm/vmwgfx: Refactor resource management it didn't apply, it wasn't trivial, so you need to resend the 6/7/8 on top of this tree, or point me to what I missed that makes it all magically work!
Alex/Ben: -next trees if you have anything interesting.
We have some stuff internally to push out, but with internal schedules and the US holiday this week, I'm not sure when I'll be able to get that into a -next tree. I'll keep you updated.
Alex
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Daniel Vetter -
Dave Airlie -
Rob Clark -
Thomas Hellstrom -
Ville Syrjälä