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

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: Atmel HLCDC + Atomic operations: hook for internal atomic state change
Date: Wed, 4 Feb 2015 20:02:27 +0200	[thread overview]
Message-ID: <20150204180227.GB9152@intel.com> (raw)
In-Reply-To: <20150204182315.723a4991@bbrezillon>

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.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel