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

[Ville Syrjälä]

On Wed, Feb 04, 2015 at 08:58:40PM +0100, Boris Brezillon wrote:
> Hi Ville,
> 
> On Wed, 4 Feb 2015 20:02:27 +0200
> Ville Syrjälä <ville.syrjala at linux.intel.com> 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,

Well, I don't know if they actually implement it. I just recall
implementing it years ago for the n900, but I have the recollection
that it never went upstream.

-- 
Ville Syrjälä
Intel OTC