[PATCH v2 0/3] drm/mediatek: Add support for OF graphs

[AngeloGioacchino Del Regno]

Il 06/05/24 12:56, AngeloGioacchino Del Regno ha scritto:
> Il 06/05/24 12:02, Michael Walle ha scritto:
>> Hi Angelo,
>>
>> On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
>>>>> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
>>>>> NIO-12L with both hardcoded paths, OF graph support and partially
>>>>> hardcoded paths (meaning main display through OF graph and external
>>>>> display hardcoded, because of OVL_ADAPTOR).
>>>>
>>>> Is that make sense for you to add the DTS changes of these boards into this 
>>>> serie ?
>>>> I asked because, IMHO, that could help to understand the serie.
>>>>
>>>
>>> Yes and no... but I imagine that you're asking this because you're trying to
>>> prepare something with a different SoC+board(s) combination :-)
>>>
>>> In that case, I'm preventively sorry because what follows here is not 100%
>>> perfectly tidy yet as I didn't mean to send the devicetree commits upstream
>>> before this series got picked....
>>>
>>> ... but there you go - I'm sure that you won't mind and that the example will
>>> be more than good enough for you.
>>
>> I've tested this series with the DSI0 output and it works. Nice! No
>> need for my DSI0 patch for the MT8395 anymore.
>>
>> But I can't get it to work with the DisplayPort output, that is the
>> dp_intf1/dp_tx interface. I don' know how the pipeline have to look
>> like. The functional spec seems to be ambiguous on this. The text
>> seem to refer to the second vdosys but there is also a diagram where
>> you can use the first vdosys and dsc0. If you have any pointers for
>> me, I'm all ears :)
>>
> 
> 
> The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR... which is
> a software thing and not HW, so that can't be described in devicetree.
> 
> The only thing this series won't deal with is exactly that.

Sorry, no, I got confused.

The series *does* already deal with that, as the pipeline is built before the check
for OVL_ADAPTOR components, so that will get probed.

What I got confused about is the fact that I promised myself to cleanup the support
for that OVL_ADAPTOR thing (which is unrelated to this series, even...), but again,
this series will still get that probed anyway.

Anyway.

The pipeline for DP1 should be simply

VDOSYS 1 -> MERGE 5 -> DP_INTF 1 -> DP

(eDP on VDOSYS 0 -> MERGE 0 --- DP on VDOSYS 1 -> MERGE 5)

Cheers,
Angelo

> 
> It's relatively easy, though, to add support for the OVL_ADAPTOR... as it would
> be just a matter of checking if any of the components in the pipeline contain a
> compatible that is in the OVL_ADAPTOR compatible list.
> 
> I'll try to add that up today, let's see what I can do.
>