[PATCH 0/7] prepare for atomic.. the great propertyification
On Thu, Jul 24, 2014 at 10:56:07AM -0400, Rob Clark wrote: [snip] > ok, it's entirely possibly that I'm missunderstanding a bit your proposal.. Yeah I get that feeling a bit too. I'll cut out the technical details for now and will try to concentrate on one example. Maybe that clarifies. [snip] > >> > So here's my proposal for how to get this in without breaking the world > >> > > >> > 1. We add a complete new set of ->atomic_foo driver entry points to all > >> > relevant objects. So instead of changing all the set_prop functions in a > >> > flag-day like operation we just add a new interface. I haven't double > >> > checked, but I guess that means per-obj ->atomic_set_prop functions plus > >> > a > >> > global ->atomic_check and ->atomic_commit. > >> > >> that sounds much worse > > > > Why that? Afaics your patch only changes the interfaces but leaves the > > semantics the same (i915 does set_config_internal all over the place in > > set_prop). So essentially you have both interface, but merged into one. > > And especially for the set_prop the semantics our different. > > well, it was the doubling up of code paths in core for handling legacy > and atomic side-by-side that I was trying to avoid > > I do remember seeing i915 set_config_internal (looks like it has been > refactored into intel_set_mode()).. iirc, it was all on > connector->set_prop(), so it would essentially be it's own > atomic/transaction. So currently our set_prop functions work like that: 1. We parse the property, sanity check it and store it in the relevant object structure. 2. We check whether (after all the checking and parsing) there has been an actual change in configuration. E.g. for the audio stuff if the use sets back to "auto" we check whether the old config matches the new autoconfig state or not. So it's not just "has the prop value changed", we actually diff the resulting hw config. 3. If there is a change, we update the hw state with a call to mode_set iff the pipe is on. There's a few reasons why this works and why it looks like that. - Our internal mode set code currently doesn't notice changes in property values. We plan to fix this eventually by shuffling the compute_config code around, but that's a lot of work. - Our internal mode set function _always_ forces a full modeset on the crtc you pass it (besides doing modeset on other crtcs where tracked state has changed). We need to have this hack to make the above set_prop sequence work. Now with atomic we want completely different semantics: - Set_prop only updates state. We need to drop the state computation and diffing and the forced mode_set. - The eventual commit will force a mode_set. Note that calling ->set_config will not be enough since that doesn't have the "force full mode-set" hack which the internal version has. And we can't do this since userspace uses set_crtc/->set_config to update frontbuffers which absolutely must not result in a full modeset. So looking just at the ->set_prop function we have 2 completely different semantics. Now I agree that with your patch i915 keeps on working. But the problem I have is converting i915 over to the new world. Since you've removed the old entry point I am left with no other choice than to convert everything at once. And there's a lot more than just the hdmi audio property - page_flip has slightly different semantics with atomic, update_plane dito, set-crtc the same. Which means I either have to convert i915 in one go (impossible given the usual churn I face) or I just end up implementing the infrastructure I've asked for (which means I get to reinstante all the old legacy ioctl paths). Since with the doubled-up entry points I can e.g. just convert hdmi set_prop to atomic, which means I have a minimal use-case to validate the core infrastructure in i915 (i.e. the state diffing we need to improve in the mode_set code) and can ignore all the nonsense in the tv connectors and sdvo encoders and plane props and crtcs props and hacked-up other crap we have all around. It's still going to be a major pain, but I expect the transition to be much more smoothly. My experience with the universal plane stuff really is that even slight semantic differences in the interfaces bite you hard and there's no way to work around that. The only sane way really is to have parallel entry points with helpers so that transitioned drivers can remap legacy interfaces to the more powerful new ones. I hope this explains a bit better where I see the big risk with your approach and what exactly I'm proposing. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 0/7] prepare for atomic.. the great propertyification
On Fri, Jul 25, 2014 at 4:15 AM, Daniel Vetter wrote: > On Thu, Jul 24, 2014 at 10:56:07AM -0400, Rob Clark wrote: > [snip] > >> ok, it's entirely possibly that I'm missunderstanding a bit your proposal.. > > Yeah I get that feeling a bit too. I'll cut out the technical details for > now and will try to concentrate on one example. Maybe that clarifies. > > > [snip] > >> >> > So here's my proposal for how to get this in without breaking the world >> >> > >> >> > 1. We add a complete new set of ->atomic_foo driver entry points to all >> >> > relevant objects. So instead of changing all the set_prop functions in a >> >> > flag-day like operation we just add a new interface. I haven't double >> >> > checked, but I guess that means per-obj ->atomic_set_prop functions >> >> > plus a >> >> > global ->atomic_check and ->atomic_commit. >> >> >> >> that sounds much worse >> > >> > Why that? Afaics your patch only changes the interfaces but leaves the >> > semantics the same (i915 does set_config_internal all over the place in >> > set_prop). So essentially you have both interface, but merged into one. >> > And especially for the set_prop the semantics our different. >> >> well, it was the doubling up of code paths in core for handling legacy >> and atomic side-by-side that I was trying to avoid >> >> I do remember seeing i915 set_config_internal (looks like it has been >> refactored into intel_set_mode()).. iirc, it was all on >> connector->set_prop(), so it would essentially be it's own >> atomic/transaction. > > So currently our set_prop functions work like that: > 1. We parse the property, sanity check it and store it in the relevant > object structure. > 2. We check whether (after all the checking and parsing) there has been an > actual change in configuration. E.g. for the audio stuff if the use sets > back to "auto" we check whether the old config matches the new autoconfig > state or not. So it's not just "has the prop value changed", we actually > diff the resulting hw config. > 3. If there is a change, we update the hw state with a call to mode_set > iff the pipe is on. > > There's a few reasons why this works and why it looks like that. > - Our internal mode set code currently doesn't notice changes in property > values. We plan to fix this eventually by shuffling the compute_config > code around, but that's a lot of work. > - Our internal mode set function _always_ forces a full modeset on the > crtc you pass it (besides doing modeset on other crtcs where tracked > state has changed). We need to have this hack to make the above set_prop > sequence work. > > Now with atomic we want completely different semantics: > - Set_prop only updates state. We need to drop the state computation and > diffing and the forced mode_set. So probably the first thing, is that we need to bring connectors into the atomic game.. probably that is something that i915 should take the lead on, since you actually have a bunch of connector properties which, from the sounds of it, should play by atomic rules. I don't have anything as complicated in msm, and wasn't entirely sure what would be needed for connectors, so I punted on that part. That said, crtc_state->set_config, etc, flags should be what you need to know if you need a full modeset or not. You just need your connector's set_prop to grab the appropriate crtc_state and set the appropriate flag(s). So I'm not sure that I see any fundamental problem here[*]. [*] well, combining connector changes w/ connector property changes perhaps.. you may actually need your ->atomic_check() step to propagate the "I need a modeset" flag from connector to crtc.. but otoh a connector change is a full modeset, so maybe not. > - The eventual commit will force a mode_set. Note that calling > ->set_config will not be enough since that doesn't have the "force full > mode-set" hack which the internal version has. And we can't do this > since userspace uses set_crtc/->set_config to update frontbuffers which > absolutely must not result in a full modeset. > > So looking just at the ->set_prop function we have 2 completely different > semantics. Now I agree that with your patch i915 keeps on working. But the > problem I have is converting i915 over to the new world. Since you've > removed the old entry point I am left with no other choice than to convert > everything at once. And there's a lot more than just the hdmi audio > property - page_flip has slightly different semantics with atomic, > update_plane dito, set-crtc the same. > > Which means I either have to convert i915 in one go (impossible given the > usual churn I face) or I just end up implementing the infrastructure I've > asked for (which means I get to reinstante all the old legacy ioctl > paths). Since with the doubled-up entry points I can e.g. just convert > hdmi set_prop to atomic, which means I have a minimal use-case to validate > the core infrastructure in i915 (i.e. the state diffing we need to
[PATCH 0/7] prepare for atomic.. the great propertyification
On Thu, Jul 24, 2014 at 09:36:20AM -0400, Rob Clark wrote: > On Thu, Jul 24, 2014 at 8:25 AM, Daniel Vetter wrote: > > On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: > >> This is mostly just a rebase+resend. Was going to send it a bit earlier > >> but had a few things to fix up as a result of the rebase. > >> > >> At this point, I think next steps are roughly: > >> 1) introduce plane->mutex > >> 2) decide what we want to do about events > >> 3) add actual ioctl > >> > >> I think we could shoot for merging this series next, and then adding > >> plane->mutex in 3.18? > >> > >> Before we add the ioctl, I think we want to sort out events for updates > >> to non-primary layers, and what the interface to drivers should look like. > >> Ie. just add event to ->update_plane() or should we completely ditch > >> ->page_flip() and ->update_plane()? > >> > >> Technically, I think we could get away without a new API and just let > >> drivers grab all the events in their ->atomic_commit(), but I suspect > >> core could provide something more useful to drivers. I guess it would > >> be useful to have a few more drivers converted over to see what makes > >> sense. > > > > Ok so we've had a lot of discussions about this on irc and overall I'm not > > terribly happy with what this looks like. I have a few concerns: > > > > - The entire atomic conversion for drivers is monolithic, at least at the > > interface level. So if you want to do this step-by-step you're forced to > > add hacks and e.g. bypass pageflips until that's implemented. E.g. on > > i915 I see no chance that we'll get atomic ready for all cases (so > > nonblocking flips and multi-crtc and everything on all platforms) in one > > go. > > So, there interface is *intended* to be monolithic, in a way.. many > years ago, I started by adding side by side atomic vs legacy paths, > and it was pretty ugly in core. I'm much happier with the current > iteration. > > A slightly later iteration preserved atomic helpers (so drivers could > do completely their own thing). I ended up dropping that because most > of what atomic does is manage the interface to whatever is doing > modeset/pageflip/whatever. I completely expect some changes around > the commit stuff.. that part is intended to either be > wrapped/extended by the driver or replaced. Possibly it could be made > more clear what drivers are expected to use vs extend or replace. I > expect this to evolve a bit as more drivers are converted. > > Note that the current atomic "layer" results in 1:1 conversion from > old userspace API to legacy vfuncs. This way what is on top of atomic > API and what is beneath (ie. the driver) has same code paths either > way (old or new userspace, converted or not driver). The edge cases > don't come in until atomic ioctl is exposed, and for that I expect a > driver flag to enable the new ioctl. You could even set the flag > based on hw generation if you want. > > > - Related to that is that we force legacy ioctls through atomic. E.g. on > > older i915 platforms I very much expect that we won't ever convert the > > pageflip code to atomic for them and just not support atomic flips of > > cursor + primary plane. At least not at the beginning. I know that's > > different from my stance a year ago, but I've become a bit more > > realistic. > > > > - The entire conversion is monolithic and we can't do it on a > > driver-by-driver basis. Everyone has to go through the new atomic > > interfaces on a flag day. drm is much bigger now and forcing everyone to > > convert at the same time is really risky. Again I know I've changed my > > mind again, but drm is a lot bigger and there's a lot more drivers that > > implement pageflip and cursors, i.e. stuff that's special. > > the only flag day part is plugging in atomic functions and couple > vfunc API changes around set_prop().. the current design allows for > conversion on driver by driver basis. > > > - The separation between interface marshalling code in the drm core and > > helper functions for drivers to implement stuff is fuzzy at best. Thus > > far we've had an excellent seperation in this are for kms, I don't think > > it's vise to throw that out. > > Interface marshalling should not be helper. Everyone needs the same > thing, since what is on top is the same. Erhm I've certainly not meant the interface marshalling to be a helper. This started with "The separation ..." after all, so I want inteface marshilling as fixed code in the drm core, and everything else outside in a separate drm_atomic_helper.c module. > > So here's my proposal for how to get this in without breaking the world > > > > 1. We add a complete new set of ->atomic_foo driver entry points to all > > relevant objects. So instead of changing all the set_prop functions in a > > flag-day like operation we just add a new interface. I haven't double > > checked, but I guess that means per-obj ->atomic_set_prop
[PATCH 0/7] prepare for atomic.. the great propertyification
On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: > This is mostly just a rebase+resend. Was going to send it a bit earlier > but had a few things to fix up as a result of the rebase. > > At this point, I think next steps are roughly: > 1) introduce plane->mutex > 2) decide what we want to do about events > 3) add actual ioctl > > I think we could shoot for merging this series next, and then adding > plane->mutex in 3.18? > > Before we add the ioctl, I think we want to sort out events for updates > to non-primary layers, and what the interface to drivers should look like. > Ie. just add event to ->update_plane() or should we completely ditch > ->page_flip() and ->update_plane()? > > Technically, I think we could get away without a new API and just let > drivers grab all the events in their ->atomic_commit(), but I suspect > core could provide something more useful to drivers. I guess it would > be useful to have a few more drivers converted over to see what makes > sense. Ok so we've had a lot of discussions about this on irc and overall I'm not terribly happy with what this looks like. I have a few concerns: - The entire atomic conversion for drivers is monolithic, at least at the interface level. So if you want to do this step-by-step you're forced to add hacks and e.g. bypass pageflips until that's implemented. E.g. on i915 I see no chance that we'll get atomic ready for all cases (so nonblocking flips and multi-crtc and everything on all platforms) in one go. - Related to that is that we force legacy ioctls through atomic. E.g. on older i915 platforms I very much expect that we won't ever convert the pageflip code to atomic for them and just not support atomic flips of cursor + primary plane. At least not at the beginning. I know that's different from my stance a year ago, but I've become a bit more realistic. - The entire conversion is monolithic and we can't do it on a driver-by-driver basis. Everyone has to go through the new atomic interfaces on a flag day. drm is much bigger now and forcing everyone to convert at the same time is really risky. Again I know I've changed my mind again, but drm is a lot bigger and there's a lot more drivers that implement pageflip and cursors, i.e. stuff that's special. - The separation between interface marshalling code in the drm core and helper functions for drivers to implement stuff is fuzzy at best. Thus far we've had an excellent seperation in this are for kms, I don't think it's vise to throw that out. So here's my proposal for how to get this in without breaking the world 1. We add a complete new set of ->atomic_foo driver entry points to all relevant objects. So instead of changing all the set_prop functions in a flag-day like operation we just add a new interface. I haven't double checked, but I guess that means per-obj ->atomic_set_prop functions plus a global ->atomic_check and ->atomic_commit. 2. We add a new drm_atomic_helper.c library which provides functions to implement all the legacy interfaces (page_flip, update_plane, set_prop) using atomic interfaces. We should be able to 1:1 reuse Rob's code for this, but instead of changing the actual current interface code we put that into helpers. We don't need anything for cursor ioctls since cursor plane helpers already map the legacy cursor ioctls. 3. Rob's current code reuses the existing ->update_plane, ->pageflip and other entry points to implement the atomic commit helper functions. Imo that's a bad layering violation, and if we plug helpers in there we can't use them. Instead I think we should add a new per-plane ->atomic_commit functions clearly marked as optional. Maybe even as part of an opaque plane_helper_funcs pointer like we have with crtc/encoder/connector and crtc helpers. msm would then implement it's atomic commit function in there (since it's the only driver currently supporting atomic for real). 3b. We could adjust crtc helpers to use the plane commit hook instead of the set_base function when avialable. 4. We do a pimped atomic helper based upon crtc helpers and the above plane commit function added in 3. It would essentially implement what Rob's current helper does, i.e. Step 1: Shut down all crtcs which change using the crtc helpers. This step is obviously optional and ommitted when there's nothing to do. Step 2: Loop over all planes and call ->plane_commit or whatever we will call the interface added in 3. above. Step 3: Enable all crtcs that need enabling. 5. We start converting drivers. Every driver can convert at it's own pace, opting in for atomic behaviour step-by-step. 6. We optionally use the atomic interface in the fb helper. It's imo important to keep the code here parallel so that drivers can convert at their own leisure. 7. We add the atomic ioctl. 8. Various cleanups once 5. is completed for all drivers - which will likely take at least a year: - Remove ->set_base from crtc helpers. - Remove legacy
[PATCH 0/7] prepare for atomic.. the great propertyification
On Thu, Jul 24, 2014 at 10:00 AM, Daniel Vetter wrote: > On Thu, Jul 24, 2014 at 09:36:20AM -0400, Rob Clark wrote: >> On Thu, Jul 24, 2014 at 8:25 AM, Daniel Vetter wrote: >> > On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: >> >> This is mostly just a rebase+resend. Was going to send it a bit earlier >> >> but had a few things to fix up as a result of the rebase. >> >> >> >> At this point, I think next steps are roughly: >> >> 1) introduce plane->mutex >> >> 2) decide what we want to do about events >> >> 3) add actual ioctl >> >> >> >> I think we could shoot for merging this series next, and then adding >> >> plane->mutex in 3.18? >> >> >> >> Before we add the ioctl, I think we want to sort out events for updates >> >> to non-primary layers, and what the interface to drivers should look like. >> >> Ie. just add event to ->update_plane() or should we completely ditch >> >> ->page_flip() and ->update_plane()? >> >> >> >> Technically, I think we could get away without a new API and just let >> >> drivers grab all the events in their ->atomic_commit(), but I suspect >> >> core could provide something more useful to drivers. I guess it would >> >> be useful to have a few more drivers converted over to see what makes >> >> sense. >> > >> > Ok so we've had a lot of discussions about this on irc and overall I'm not >> > terribly happy with what this looks like. I have a few concerns: >> > >> > - The entire atomic conversion for drivers is monolithic, at least at the >> > interface level. So if you want to do this step-by-step you're forced to >> > add hacks and e.g. bypass pageflips until that's implemented. E.g. on >> > i915 I see no chance that we'll get atomic ready for all cases (so >> > nonblocking flips and multi-crtc and everything on all platforms) in one >> > go. >> >> So, there interface is *intended* to be monolithic, in a way.. many >> years ago, I started by adding side by side atomic vs legacy paths, >> and it was pretty ugly in core. I'm much happier with the current >> iteration. >> >> A slightly later iteration preserved atomic helpers (so drivers could >> do completely their own thing). I ended up dropping that because most >> of what atomic does is manage the interface to whatever is doing >> modeset/pageflip/whatever. I completely expect some changes around >> the commit stuff.. that part is intended to either be >> wrapped/extended by the driver or replaced. Possibly it could be made >> more clear what drivers are expected to use vs extend or replace. I >> expect this to evolve a bit as more drivers are converted. >> >> Note that the current atomic "layer" results in 1:1 conversion from >> old userspace API to legacy vfuncs. This way what is on top of atomic >> API and what is beneath (ie. the driver) has same code paths either >> way (old or new userspace, converted or not driver). The edge cases >> don't come in until atomic ioctl is exposed, and for that I expect a >> driver flag to enable the new ioctl. You could even set the flag >> based on hw generation if you want. >> >> > - Related to that is that we force legacy ioctls through atomic. E.g. on >> > older i915 platforms I very much expect that we won't ever convert the >> > pageflip code to atomic for them and just not support atomic flips of >> > cursor + primary plane. At least not at the beginning. I know that's >> > different from my stance a year ago, but I've become a bit more >> > realistic. >> > >> > - The entire conversion is monolithic and we can't do it on a >> > driver-by-driver basis. Everyone has to go through the new atomic >> > interfaces on a flag day. drm is much bigger now and forcing everyone to >> > convert at the same time is really risky. Again I know I've changed my >> > mind again, but drm is a lot bigger and there's a lot more drivers that >> > implement pageflip and cursors, i.e. stuff that's special. >> >> the only flag day part is plugging in atomic functions and couple >> vfunc API changes around set_prop().. the current design allows for >> conversion on driver by driver basis. >> >> > - The separation between interface marshalling code in the drm core and >> > helper functions for drivers to implement stuff is fuzzy at best. Thus >> > far we've had an excellent seperation in this are for kms, I don't think >> > it's vise to throw that out. >> >> Interface marshalling should not be helper. Everyone needs the same >> thing, since what is on top is the same. > > Erhm I've certainly not meant the interface marshalling to be a helper. > This started with "The separation ..." after all, so I want inteface > marshilling as fixed code in the drm core, and everything else outside in > a separate drm_atomic_helper.c module. ok, it's entirely possibly that I'm missunderstanding a bit your proposal.. >> > So here's my proposal for how to get this in without breaking the world >> > >> > 1. We add a complete new set of ->atomic_foo driver entry points
[PATCH 0/7] prepare for atomic.. the great propertyification
On Thu, Jul 24, 2014 at 8:25 AM, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 03:38:13PM -0400, Rob Clark wrote: >> This is mostly just a rebase+resend. Was going to send it a bit earlier >> but had a few things to fix up as a result of the rebase. >> >> At this point, I think next steps are roughly: >> 1) introduce plane->mutex >> 2) decide what we want to do about events >> 3) add actual ioctl >> >> I think we could shoot for merging this series next, and then adding >> plane->mutex in 3.18? >> >> Before we add the ioctl, I think we want to sort out events for updates >> to non-primary layers, and what the interface to drivers should look like. >> Ie. just add event to ->update_plane() or should we completely ditch >> ->page_flip() and ->update_plane()? >> >> Technically, I think we could get away without a new API and just let >> drivers grab all the events in their ->atomic_commit(), but I suspect >> core could provide something more useful to drivers. I guess it would >> be useful to have a few more drivers converted over to see what makes >> sense. > > Ok so we've had a lot of discussions about this on irc and overall I'm not > terribly happy with what this looks like. I have a few concerns: > > - The entire atomic conversion for drivers is monolithic, at least at the > interface level. So if you want to do this step-by-step you're forced to > add hacks and e.g. bypass pageflips until that's implemented. E.g. on > i915 I see no chance that we'll get atomic ready for all cases (so > nonblocking flips and multi-crtc and everything on all platforms) in one > go. So, there interface is *intended* to be monolithic, in a way.. many years ago, I started by adding side by side atomic vs legacy paths, and it was pretty ugly in core. I'm much happier with the current iteration. A slightly later iteration preserved atomic helpers (so drivers could do completely their own thing). I ended up dropping that because most of what atomic does is manage the interface to whatever is doing modeset/pageflip/whatever. I completely expect some changes around the commit stuff.. that part is intended to either be wrapped/extended by the driver or replaced. Possibly it could be made more clear what drivers are expected to use vs extend or replace. I expect this to evolve a bit as more drivers are converted. Note that the current atomic "layer" results in 1:1 conversion from old userspace API to legacy vfuncs. This way what is on top of atomic API and what is beneath (ie. the driver) has same code paths either way (old or new userspace, converted or not driver). The edge cases don't come in until atomic ioctl is exposed, and for that I expect a driver flag to enable the new ioctl. You could even set the flag based on hw generation if you want. > - Related to that is that we force legacy ioctls through atomic. E.g. on > older i915 platforms I very much expect that we won't ever convert the > pageflip code to atomic for them and just not support atomic flips of > cursor + primary plane. At least not at the beginning. I know that's > different from my stance a year ago, but I've become a bit more > realistic. > > - The entire conversion is monolithic and we can't do it on a > driver-by-driver basis. Everyone has to go through the new atomic > interfaces on a flag day. drm is much bigger now and forcing everyone to > convert at the same time is really risky. Again I know I've changed my > mind again, but drm is a lot bigger and there's a lot more drivers that > implement pageflip and cursors, i.e. stuff that's special. the only flag day part is plugging in atomic functions and couple vfunc API changes around set_prop().. the current design allows for conversion on driver by driver basis. > - The separation between interface marshalling code in the drm core and > helper functions for drivers to implement stuff is fuzzy at best. Thus > far we've had an excellent seperation in this are for kms, I don't think > it's vise to throw that out. Interface marshalling should not be helper. Everyone needs the same thing, since what is on top is the same. > So here's my proposal for how to get this in without breaking the world > > 1. We add a complete new set of ->atomic_foo driver entry points to all > relevant objects. So instead of changing all the set_prop functions in a > flag-day like operation we just add a new interface. I haven't double > checked, but I guess that means per-obj ->atomic_set_prop functions plus a > global ->atomic_check and ->atomic_commit. that sounds much worse > 2. We add a new drm_atomic_helper.c library which provides functions to > implement all the legacy interfaces (page_flip, update_plane, set_prop) > using atomic interfaces. We should be able to 1:1 reuse Rob's code for > this, but instead of changing the actual current interface code we put > that into helpers. So, I've started ripping out page_flip.. now w/ primary plane helpers we can do
[PATCH 0/7] prepare for atomic.. the great propertyification
This is mostly just a rebase+resend. Was going to send it a bit earlier but had a few things to fix up as a result of the rebase. At this point, I think next steps are roughly: 1) introduce plane->mutex 2) decide what we want to do about events 3) add actual ioctl I think we could shoot for merging this series next, and then adding plane->mutex in 3.18? Before we add the ioctl, I think we want to sort out events for updates to non-primary layers, and what the interface to drivers should look like. Ie. just add event to ->update_plane() or should we completely ditch ->page_flip() and ->update_plane()? Technically, I think we could get away without a new API and just let drivers grab all the events in their ->atomic_commit(), but I suspect core could provide something more useful to drivers. I guess it would be useful to have a few more drivers converted over to see what makes sense. Rob Clark (5): drm: add atomic fxns drm: split propvals out and blob property support drm: convert plane to properties/state drm: convert crtc to properties/state drm/msm: add atomic support Sean Paul (1): drm: Fix up the atomic legacy paths so they work Ville Syrj?l? (1): drm: Refactor object property check code drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/armada/armada_crtc.c| 14 +- drivers/gpu/drm/armada/armada_output.c |3 +- drivers/gpu/drm/armada/armada_overlay.c | 14 +- drivers/gpu/drm/ast/ast_drv.c |6 + drivers/gpu/drm/ast/ast_drv.h |1 + drivers/gpu/drm/ast/ast_mode.c |1 + drivers/gpu/drm/cirrus/cirrus_drv.c |6 + drivers/gpu/drm/cirrus/cirrus_drv.h |1 + drivers/gpu/drm/cirrus/cirrus_mode.c|1 + drivers/gpu/drm/drm_atomic.c| 733 +++ drivers/gpu/drm/drm_crtc.c | 1351 ++- drivers/gpu/drm/drm_fb_helper.c | 55 +- drivers/gpu/drm/drm_irq.c |8 +- drivers/gpu/drm/drm_modeset_lock.c | 28 + drivers/gpu/drm/drm_plane_helper.c |2 + drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 +- drivers/gpu/drm/exynos/exynos_drm_drv.c |7 + drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +- drivers/gpu/drm/gma500/cdv_intel_crt.c |4 +- drivers/gpu/drm/gma500/cdv_intel_display.c |1 + drivers/gpu/drm/gma500/cdv_intel_dp.c |7 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c |7 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 +- drivers/gpu/drm/gma500/psb_drv.c|7 + drivers/gpu/drm/gma500/psb_drv.h|1 + drivers/gpu/drm/gma500/psb_intel_display.c |1 + drivers/gpu/drm/gma500/psb_intel_drv.h |4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 23 +- drivers/gpu/drm/i2c/ch7006_drv.c|4 +- drivers/gpu/drm/i915/i915_drv.c |8 + drivers/gpu/drm/i915/intel_crt.c|4 +- drivers/gpu/drm/i915/intel_display.c|6 +- drivers/gpu/drm/i915/intel_dp.c |7 +- drivers/gpu/drm/i915/intel_drv.h|1 + drivers/gpu/drm/i915/intel_hdmi.c |7 +- drivers/gpu/drm/i915/intel_lvds.c |4 +- drivers/gpu/drm/i915/intel_sdvo.c | 23 +- drivers/gpu/drm/i915/intel_sprite.c |1 + drivers/gpu/drm/i915/intel_tv.c | 12 +- drivers/gpu/drm/mgag200/mgag200_drv.c |7 + drivers/gpu/drm/mgag200/mgag200_drv.h |1 + drivers/gpu/drm/mgag200/mgag200_mode.c |1 + drivers/gpu/drm/msm/Makefile|1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 66 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c |6 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h |1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 14 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 65 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |6 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +- drivers/gpu/drm/msm/msm_atomic.c| 141 +++ drivers/gpu/drm/msm/msm_drv.c | 26 + drivers/gpu/drm/msm/msm_drv.h |8 + drivers/gpu/drm/msm/msm_gem.c | 24 +- drivers/gpu/drm/msm/msm_gem.h | 13 + drivers/gpu/drm/msm/msm_kms.h |1 + drivers/gpu/drm/nouveau/dispnv04/crtc.c |1 + drivers/gpu/drm/nouveau/dispnv04/overlay.c | 13 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |3 +- drivers/gpu/drm/nouveau/nouveau_connector.c |7 +- drivers/gpu/drm/nouveau/nouveau_drm.c |7 + drivers/gpu/drm/nouveau/nouveau_drm.h |1 + drivers/gpu/drm/nouveau/nv50_display.c |1 + drivers/gpu/drm/omapdrm/omap_crtc.c | 16 +-
