Re: Request for feedback - Sprite flip notification support

[Vijay Purushothaman <vijay.a.purushothaman@intel.com>]

On 2/5/2014 10:18 PM, Ville Syrjälä wrote:
> On Wed, Feb 05, 2014 at 09:25:36PM +0530, Vijay Purushothaman wrote:
>> On 2/5/2014 8:43 PM, Ville Syrjälä wrote:
>>> On Wed, Feb 05, 2014 at 08:35:11PM +0530, Vijay Purushothaman wrote:
>>>> Hello,
>>>>
>>>> In our current driver implementation we support flip notifications only
>>>> for primary plane. So, in a full screen video playback scenario where
>>>> only one sprite plane is active, the user space is forced to rely on
>>>> primary plane flip notification even though there is no real need for
>>>> this plane to be active. Ideally we should be able to support flip
>>>> notifications for any given plane. Switching off the primary plane (when
>>>> not used) will help in better memory self refresh & decent power savings..
>>>>
>>>> We do have a hack in android product trees which supports flip
>>>> notifications for one sprite plane. unfortunately this hack in its
>>>> current form cannot be considered for up streaming...
>>>>
>>>> My current thinking is to have an array of unpin_work items to match the
>>>> number of planes. Is anyone working on this or thought about this
>>>> scenario in detail? Any pointers / restrictions that needs to considered
>>>> for a generic implementation of this feature?
>>>
>>> The plan is to implement the nuclear page flip which will take care of
>>> all planes in the same way.
>>>
>> Thanks Ville. If the nuclear page flip is part of your bigger atomic
>> mode set framework, is there a way you can split this into smaller sets
>> for merge? Multiple product trees will benefit from the nuclear page flip.
>
> I've split things up already somewhat. Some has landed some has not.
>
> Currently I have my minimal "atomic update of sprite+primary during
> setplane" series I need to get in. It shouldn't need major work anymore,
> just some minor tweaks. But I realized I need to limit this to just
> pch platforms for now. Making it work reliably on gmch platforms
> require some extra interrupt related work. The main thing here is that
> it adds the mechanism to do the update atomically for the entire pipe.
>
> After that I need to post the last bits of my watermark update saga.
> This too will initially be limited to pch platforms only. Obviously
> watermarks need to updated correctly to avoid underruns when planes
> get shuffled around.
>
>> Is there anything that i can help with? Like testing your patches with
>> android user space?
>
> There's nothing to test at this point unless you want to test my old
> branch from year ago or something.
>
> What needs to be done:
> - review the latest atomic framework patches from Rob Clark
> - expose primary/cursor planes as drm_planes
>    * this could in theory be skipped, but it'll lead to cruft in the API
>      we need to maintain until the end of time. Also I think restructing
>      stuff internally to this direction will be a good idea anyway to make
>      the nuclear flip code neater. This more or less involves collecting
>      the plane state to some plane_config type of structure, and being
>      able to pre-compute that
> - try to collect the necessary missing bits from my last
>    atomic branch to implement the nuclear flip
>    * the flip helper thing to update an arbitrary collection of planes
>      atomically, maybe could be simplified a bit
>    * mechanism to queue nuclear flips and make them wait for the
>      GPU to finish writing to all the relevant buffers before issuing
>      the actual flips/updates
> - finally hook up the atomic ioctl to do the nuclear flip
>    * pre-pin all buffers, pre-compute plane configs, pre-compute
>      watermarks, check everything, wait for the GPU, and finally
>      do the update
>
> For the atomic modeset side some of that's the same really. There too we
> also need to pre-compute the plane configs and pre-pin buffers. Most of
> the rest we already pre-compute via the pipe config. One major thing
> left out of the pipe config pre-compute currently is PLLs. We compute
> that stuff way too late still. We also need to massage the modeset code
> some more to make it capable of modesetting multiple pipes at once.
>

Thanks for the detailed answer. This should solve most of the display 
issues in the product trees.. considering the amount of work involved 
this looks more like a long term solution. Would it be okay if we submit 
a short term solution for sprite flip notifications? This would help us 
to force a standard approach across multiple android product kernels. We 
can revert this fix once the atomic mode set / nuclear page flip is ready.

Thanks,
Vijay