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.
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.
Cheers,
Angelo
