Received-SPF: pass (google.com: domain of linux-kernel+bounces-169714-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <50be68dc-b86a-4334-9f83-43c6fda2c271@collabora.com>
Date: Mon, 6 May 2024 12:56:58 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs
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>
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Content-Language: en-US
In-Reply-To: <D12H4GDJJEUF.1Y91H9RMUIX20@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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