On 04/10/2022 13:55, Guillaume Ranquet wrote:
>> No. You said what the code is doing. I think I understand this. You
>> still do not need more compatibles. Your sentence did not clarify it
>> because it did not answer at all to question "why". Why do you need it?
>>
>> Sorry, the change looks not correct.
>>
>> Best regards,
>> Krzysztof
>>
>
> I need a new compatible to adress the specifics of mt8195 in the mtk_dpi driver,
> the change is in this series with:
> [PATCH v1 16/17] drm/mediatek: dpi: Add mt8195 hdmi to DPI driver [1]
But you do not have specifics of mt8195. I wrote it in the beginning.
>
> I then need to add that compatible to the "list" here in mtk_drm_drv.
No, you do not... I checked the driver and there is no single need... or
convince me you need.
> I don't see a way around this unless I rewrite the way mtk_drm_drv works?
Why rewrite? You have all compatibles in place.
>
> Maybe if I declare a new compatible that is generic to all mediatek
> dpi variants?
You were asked to use fallback. Don't create some fake fallbacks. Use
existing ones.
> and have all the dts specify the node with both the generic dpi and
> the specific compatible?
>
> dpi@xxx {
> compatible = "mediatek,dpi", "mediatek,mt8195-dpi";
I don't know what's this but certainly looks odd. Some wild-card
compatible in front (not fallback) and none are documented.
> ...
> }
>
> Then I can "collapse" all the dpi related nodes in mtk_drm_drv under
> "mediatek,dpi" ?
>
> I guess would have to do the change for all other components that are needed in
> mtk_drm_drv (mmsys, aal, ccor, color, dither, dsc, gamma, mutex...).
>
> That's the only trivial way I can think of implementing this with the
> current status
> of the mtk_drm stack.
>
> Do you have any other ideas in mind?
Use fallback of compatible device. That's the common pattern.
Everywhere, Mediatek as well.
Best regards,
Krzysztof
