Re: [PATCH] drm: rcar-du: add modifiers support

[Daniel Stone <daniel@fooishbar.org>]

Hi Esaki-san,

On Tue, 30 Nov 2021 at 08:44, Esaki Tomohito <etom@igel.co.jp> wrote:
> On 2021/11/18 23:05, Laurent Pinchart wrote:
> > On Thu, Nov 18, 2021 at 01:02:11PM +0000, Daniel Stone wrote:
> >> Laurent's concern is that the DRM core should handle this rather than
> >> open-coding in every driver, which I agree with. Some drivers (e.g.
> >> radeon, maybe legacy NV?) do not support modifiers, and _also_ do
> >> magic inference of the actual layout of the underlying buffer.
> >> However, these drivers are legacy and we do not accept any new
> >> addition of inferring layout without modifiers.
> >>
> >> I think the best way forward here is:
> >>    - add a new mode_config.cannot_support_modifiers flag, and enable
> >> this in radeon (plus any other drivers in the same boat)
> >
> > Is there an easy way to identify the drivers that need this ?
>
> Should I find a driver that has not use drm_plane_funcs?

I don't think there's a good way to systematically audit it. The only
two I know are radeon (i.e. pre-amdgpu) and nouveau (pre-nv50), both
of which pass no modifiers to drm_universal_plane_init(), but do have
magic back channels to communicate tiling information. If anyone knows
of any others, well, I guess we'll find out. :)

> >>    - change drm_universal_plane_init() to advertise the LINEAR modifier
> >> when NULL is passed as the modifier list (including installing a
> >> default .format_mod_supported hook)

... except when cannot_support_modifiers is set.

> >>    - remove the mode_config.allow_fb_modifiers hook and always
> >> advertise modifier support, unless
> >> mode_config.cannot_support_modifiers is set
> >
> > Looks good to me.
>
> I agree with this way, I'll try to create a patches.

Thanks a lot! :)

Cheers,
Daniel