Received-SPF: pass (google.com: domain of linux-kernel+bounces-169731-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <1b8fa907-b48f-4ebe-bc17-3de1d7c0d062@collabora.com>
Date: Mon, 6 May 2024 13:22:02 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Michael Walle <mwalle@kernel.org>,
 Alexandre Mergnat <amergnat@baylibre.com>, chunkuang.hu@kernel.org
Cc: robh@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
 p.zabel@pengutronix.de, airlied@gmail.com, daniel@ffwll.ch,
 maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de,
 matthias.bgg@gmail.com, shawn.sung@mediatek.com, yu-chang.lee@mediatek.com,
 ck.hu@mediatek.com, jitao.shi@mediatek.com, devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
 linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
 wenst@chromium.org, kernel@collabora.com
References: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
 <1fc23530-89ba-4e36-9e9a-a1289f56a9bc@baylibre.com>
 <608fdbde-ad06-45ec-9771-18aa9f002f2d@collabora.com>
 <D12H4GDJJEUF.1Y91H9RMUIX20@kernel.org>
 <50be68dc-b86a-4334-9f83-43c6fda2c271@collabora.com>
Content-Language: en-US
In-Reply-To: <50be68dc-b86a-4334-9f83-43c6fda2c271@collabora.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.
>