[RFC 1/7] drm/atomic: initial support for asynchronous plane update

[Daniel Stone]

Hi,

On 2 May 2017 at 09:10, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote:
>> Do you know which hw would that be? I don't know. Maybe we should just
>> don't care for now and see how drivers will solve this to then extract
>> helpers like we did for atomic nonblocking commits.
>
> i915 is one. The only way to do true async updates is throught the CS flip
> command with a special bit set, and that one only works for the primary
> plane. All other updates are synced to vblank, i.e. the hw will keep
> scanning out the old address.
>
> But I checked the current code, it's no better than what you've done.
>
> More special is iirc rockchip (or some other arm-soc display ip), which on top
> also has an iommu which falls over if the mapping disappears right away.
> Easy solution is to not allow fb changes (but that kinda sucks), more
> involved is delaying the fb cleanup into a worker (but since we don't
> rate-limit this is tricky too ...).

Most ARM display IP these days has it (notable exception is VC4 and I
think also i.MX?), and will do that. Exynos also has no way to update
the base address during scanout, and will not like it if it starts
smashing into faults from its IOMMU.

Cheers,
Daniel