Atmel HLCDC + Atomic operations: hook for internal atomic state change

Boris Brezillon boris.brezillon at free-electrons.com
Wed Feb 4 11:45:47 PST 2015


On Wed, 4 Feb 2015 12:49:19 -0500
Rob Clark <robdclark at gmail.com> wrote:

> On Wed, Feb 4, 2015 at 12:23 PM, Boris Brezillon
> <boris.brezillon at free-electrons.com> 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 just wrap drm_atomic_helper_commit() w/ your own fxn that did
> extra fixup and then called drm_atomic_helper_commit()?

Yes, that's something I considered, but this implies modifying/creating
a plane state (calling drm_atomic_get_plane_state and modifying the
discard area fields) after everything has been checked.
If that's fine, then I think I'll go for this solution.

Thanks.

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


More information about the dri-devel mailing list