Linux clock framework development
 help / color / mirror / Atom feed
From: Liu Ying <victor.liu@nxp.com>
To: Marek Vasut <marek.vasut@mailbox.org>, dri-devel@lists.freedesktop.org
Cc: Abel Vesa <abelvesa@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Lucas Stach <l.stach@pengutronix.de>, Peng Fan <peng.fan@nxp.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Rob Herring <robh@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	devicetree@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
Subject: Re: [PATCH] drm/bridge: fsl-ldb: Parse register offsets from DT
Date: Tue, 4 Nov 2025 13:25:17 +0800	[thread overview]
Message-ID: <ac21053f-21d9-4844-9049-09deb3708a6d@nxp.com> (raw)
In-Reply-To: <3064e20f-92c8-4e3b-82bc-ef949f312826@mailbox.org>

On 11/04/2025, Marek Vasut wrote:
> On 11/4/25 3:26 AM, Liu Ying wrote:
> 
> Hello Liu,

Hello Marek,

> 
>>>>> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
>>>>> @@ -61,24 +61,16 @@ enum fsl_ldb_devtype {
>>>>>    };
>>>>>      struct fsl_ldb_devdata {
>>>>> -    u32 ldb_ctrl;
>>>>> -    u32 lvds_ctrl;
>>>>>        bool lvds_en_bit;
>>>>>        bool single_ctrl_reg;
>>>>
>>>> single_ctrl_reg can be dropped then, as it can be expressed by failing to
>>>> get the second register.
>>>>
>>>> Furthermore, with this done, lvds_en_bit is the only member left and hence
>>>> struct fsl_ldb_devdata can also be dropped, as IIRC there is no need to
>>>> use a structure for device data with only a flag.
>>> I plan to add more bits into the driver match data when adding the MX95,
>>> so I would like to retain these instead of removing them and the adding
>>> them back.
>>
>> i.MX95 LDB supports two LVDS channels.  Two DRM bridges are needed in single
>> or separate LDB mode, while one DRM bridge is needed in split LDB mode.
> 
> What do you refer to by "split LDB mode" , some interleaving or some such
> thing ?

I mean "Split Channel DI0" and "Split Channel DI1" use cases in the below
table in i.MX95 TRM.

+------------------------------------------------------------+
|Table: Channel Mapping                                      |
|------------------------------------------------------------|
|Use Case           |  LVDS Channel 0   |  LVDS Channel 1    |
|------------------------------------------------------------|
|Single Channel DI0 | DI0               | Disabled           |
|------------------------------------------------------------|
|Single Channel DI1 | Disabled          | DI1                |
|------------------------------------------------------------|
|Separate Channels  | DI0               | DI1                |
|------------------------------------------------------------|
|Dual Channels DI0  | DI0               | DI0                |
|------------------------------------------------------------|
|Dual Channels DI1  | DI1               | DI1                |
|------------------------------------------------------------|
|Split Channel DI0  | DI0 (first pixel) | DI0 (second pixel) |
|------------------------------------------------------------|
|Split Channel DI1  | DI1 (first pixel) | DI1 (second pixel) |
+------------------------------------------------------------+

> 
>> Also, each channel connects to a standalone LVDS PHY.  All these could make
>> it intrusive to support i.MX95 LDB in fsl-ldb.c.  Maybe, we could discuss
>> about this later, but IMO this patch should remove struct fsl_ldb_devdata.
>> It doesn't hurt if we really need to add it back.
> OK. The current integration seems to be working fine. Which exact case are
> you concerned about, do you have an example ?

At least, "Separate Channels" use case on i.MX95 EVK to support two IT6263
LVDS to HDMI bridges(see ite,it6263.yaml), meaning two active HDMI monitors.
That also means "Single Channel DI0" and "Single Channel DI1" should work
with one single HDMI monitor.

-- 
Regards,
Liu Ying

  reply	other threads:[~2025-11-04  5:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17 15:39 [PATCH] drm/bridge: fsl-ldb: Parse register offsets from DT Marek Vasut
2025-10-20  6:21 ` Liu Ying
2025-11-02 16:59   ` Marek Vasut
2025-11-04  2:26     ` Liu Ying
2025-11-04  3:07       ` Marek Vasut
2025-11-04  5:25         ` Liu Ying [this message]
2026-01-04 21:09           ` Marek Vasut

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=ac21053f-21d9-4844-9049-09deb3708a6d@nxp.com \
    --to=victor.liu@nxp.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=abelvesa@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=marek.vasut@mailbox.org \
    --cc=peng.fan@nxp.com \
    --cc=robh@kernel.org \
    --cc=shawnguo@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