public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Phong LE <ple@baylibre.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] drm/bridge: Add fwnode based helpers to get the next bridge
Date: Sat, 9 Mar 2024 20:03:14 +0800	[thread overview]
Message-ID: <28492cfb-5327-46d5-8c08-233f1786ff44@linux.dev> (raw)
In-Reply-To: <CAA8EJpp3yd33pYweL_exrXMJ3g-m7-yjJrjiVMVMevOadBtt8g@mail.gmail.com>

Hi,


On 2024/3/9 18:39, Dmitry Baryshkov wrote:
>> The code path of "creating a connector" plus the code path of "not creating a connector"
>> forms a 'side-by-side' implementation imo.
>>
>> Besides, I have repeated many times: the DT already speak everything.
>> Device drivers can completely know if there is a display connector OF device created and how many
>> display bridges in the whole chain. If there are connector device node in the DT, then it should
>> has a device driver bound to it(instead of create it manually) for a perfect implementation. As
>> you told me we should not*over play*  the device-driver model, right?
> Please, don't mix the connector node in DT and the drm_connector. If
> you check the code, you will see that the driver for hdmi-connector,
> dp-connector and other such devices creates a drm_bridge.


OK, I'm not mixed them, I'm very clear from the very beginning. I have checked
the code years ago. Let's make it clear by iterating one more time:

If DT contains one or more HDMI connector node, then there will be one or
more display connector platform devices created by OF core, Then, according to
your "don't overplay device-driver model" criterion or modern drm bridge standard,
we shouldn't create a display connector instance in the drm birdge driver, right?

As otherwise we will have two display connector driver (or code) for a single entity,
right?

Another side effect is that
when you create a hdmi display connector instance manually without reference to the
DT, then *you made an assumption!*. But there are users who have don't a different
need(or  different typology), for example, they need to read edid directly from the
KMS driver side. This may because the i2c bus is directly connected to the connector
part, but the display bridge's I2C slave interface. sii9022, it66121 and tfp410 support
this kind of usage.

So the real problem is that it is a policy level code  when you creating a hdmi
display connector instance manually without reference to the DT in a common drm bridge
driver, not a mechanism.


  parent reply	other threads:[~2024-03-09 12:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07 17:23 [PATCH v2 0/4] drm/bridge: Allow using fwnode API to get the next bridge Sui Jingfeng
2024-03-07 17:23 ` [PATCH v2 1/4] drm/bridge: Add fwnode based helpers " Sui Jingfeng
2024-03-07 18:43   ` Dmitry Baryshkov
2024-03-07 19:20     ` Sui Jingfeng
2024-03-07 19:30       ` Sui Jingfeng
2024-03-07 19:37       ` Dmitry Baryshkov
2024-03-07 20:32         ` Sui Jingfeng
2024-03-07 20:40           ` Dmitry Baryshkov
2024-03-07 21:09             ` Sui Jingfeng
2024-03-07 21:13               ` Sui Jingfeng
2024-03-09  9:33             ` Sui Jingfeng
2024-03-09 10:39               ` Dmitry Baryshkov
2024-03-09 11:25                 ` Sui Jingfeng
2024-03-09 12:50                   ` Dmitry Baryshkov
2024-03-09 12:03                 ` Sui Jingfeng [this message]
2024-03-09 13:29                   ` Dmitry Baryshkov
2024-03-07 17:23 ` [PATCH v2 2/4] drm/bridge: simple-bridge: Use fwnode API to acquire device properties Sui Jingfeng
2024-03-07 17:23 ` [PATCH v2 3/4] drm-bridge: display-connector: " Sui Jingfeng
2024-03-07 17:23 ` [PATCH v2 4/4] drm-bridge: it66121: " Sui Jingfeng
2024-03-07 19:31   ` Dmitry Baryshkov
2024-03-07 19:39     ` Sui Jingfeng

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=28492cfb-5327-46d5-8c08-233f1786ff44@linux.dev \
    --to=sui.jingfeng@linux.dev \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=ple@baylibre.com \
    --cc=rfoss@kernel.org \
    --cc=tzimmermann@suse.de \
    /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