From: "Michael Walle" <michael@walle.cc>
To: "AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.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>
Subject: Re: [PATCH v4 3/3] drm/mediatek: Implement OF graphs support for display paths
Date: Mon, 03 Jun 2024 09:42:31 +0200 [thread overview]
Message-ID: <D1Q7OPR0TRFG.1WLSI7EBAPUWX@walle.cc> (raw)
In-Reply-To: <84cd0ac7-99d9-42cb-af79-a0fba09c1ebb@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
Hi Angelo,
> >> Implement OF graphs support to the mediatek-drm drivers, allowing to
> >> stop hardcoding the paths, and preventing this driver to get a huge
> >> amount of arrays for each board and SoC combination, also paving the
> >> way to share the same mtk_mmsys_driver_data between multiple SoCs,
> >> making it more straightforward to add support for new chips.
> >
> > paths might be optional, see comment in mtk_drm_kms_init(). But with
> > this patch, you'll get an -EINVAL with a disabled path. See my
> > proposals how to fix that below.
>
> I might not be understanding the reason behind allowing that but, per my logic, if
> a board does have a path, then it's written in devicetree and enabled - otherwise,
> it should not be there at all, in principle.
>
>
> Can you explain a bit more extensively the reason(s) why we need to account
> for disabled paths?
Paths should be (and this was already supported before this patch
with the hardcoded paths) disabled with the status property. This
way you can have a common board configuration where all the paths
are already described but are disabled. An overlay (or maybe another
dts variant) can then just enable the pipeline/output port by
overwriting the status property.
Also, this is the usual DT usage, as a node with status = "disabled"
should just be skipped. Without handling this, the current code will
return -EINVAL during probe (IIRC, my vacation might have reset my
memory :o).
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
next prev parent reply other threads:[~2024-06-03 7:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 8:11 [PATCH v4 0/3] drm/mediatek: Add support for OF graphs AngeloGioacchino Del Regno
2024-05-16 8:11 ` [PATCH v4 1/3] dt-bindings: display: mediatek: Add OF graph support for board path AngeloGioacchino Del Regno
2024-05-20 15:34 ` Alexandre Mergnat
2024-05-16 8:11 ` [PATCH v4 2/3] dt-bindings: arm: mediatek: mmsys: " AngeloGioacchino Del Regno
2024-05-16 9:23 ` CK Hu (胡俊光)
2024-05-16 9:42 ` AngeloGioacchino Del Regno
2024-05-19 17:18 ` Alexandre Mergnat
2024-05-20 10:53 ` AngeloGioacchino Del Regno
2024-05-20 11:49 ` Alexandre Mergnat
2024-05-20 11:55 ` AngeloGioacchino Del Regno
2024-05-20 15:33 ` Alexandre Mergnat
2024-05-16 8:11 ` [PATCH v4 3/3] drm/mediatek: Implement OF graphs support for display paths AngeloGioacchino Del Regno
2024-05-17 9:49 ` Michael Walle
2024-05-20 9:45 ` AngeloGioacchino Del Regno
2024-06-03 7:42 ` Michael Walle [this message]
2024-05-20 15:34 ` Alexandre Mergnat
2024-06-06 23:25 ` [PATCH v4 0/3] drm/mediatek: Add support for OF graphs Nícolas F. R. A. Prado
2024-06-10 8:39 ` AngeloGioacchino Del Regno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D1Q7OPR0TRFG.1WLSI7EBAPUWX@walle.cc \
--to=michael@walle.cc \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=ck.hu@mediatek.com \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jitao.shi@mediatek.com \
--cc=kernel@collabora.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=shawn.sung@mediatek.com \
--cc=tzimmermann@suse.de \
--cc=wenst@chromium.org \
--cc=yu-chang.lee@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).