Hi Ville, On Wed, 4 Feb 2015 20:02:27 +0200 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Wed, Feb 04, 2015 at 06:23:15PM +0100, Boris Brezillon wrote: > > Hello, > > > > I'm currently adding support for atomic operations (or atomic > > modesetting) in the Atmel HLCDC driver. > > Everything is pretty much in place, and all the features provided by the > > current driver are working as expected. > > However, there's one feature I'd like to add (actually I was hoping > > atomic support could help me deal with this feature), and I not sure > > how to do it. > > > > The HLCDC IP provides a way to discard a specific area on the primary > > plane (in case at least one of the overlay is activated and alpha > > blending is disabled). > > Doing this will reduce the amount of data to transfer from the main > > memory to the Display Controller, and thus alleviate the load on the > > memory bus (since this link is quite limited on such hardware, > > this kind of optimization is really important). > > > > My problem here is that there is no way, in the current atomic > > implementation, to internally ask for a plane state modification. > > > > Is there a plan to add such hooks that would be called after the > > requested state modifications (i.e. operations done before the > > drm_atomic_commit call in all helper functions), but before the atomic > > checks begin (i.e. call to drm_atomic_check_only) ? > > Such hooks would let me ask for a primary plane update (modifying the > > discard area property) if needed. > > > > Maybe I'm totally mistaken in my approach to solve this problem, so > > please let me know if you see other solutions. > > So this looks pretty much exactly like the overlay optimization feature > in OMAPs. I don't really see why you need to treat is as some kind of > plane property. It's just an internal implementation detail so can't you > just compute the discard area at commit() time based on what planes are > going to be active? Or if you want to take it into account in some > bandwidth calculation you can compute it already at check() time. > Okay, I'll have a look at the OMAP driver, but I'd really like to apply the discard area setting as part of the primary plane atomic_update function (the discard area registers are part of the primary plane registers, and plane settings are updated by setting a specific bit to 1). I tried to update the primary plane discard settings as part of the atomic_update, but when nothing touches the primary plane (an update_plane on one of the overlay planes), the primary plane is kept unchanged, and thus the new primary settings are never applied. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
