Linux kernel and device drivers for NXP i.MX platforms
 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 v2] drm/bridge: fsl-ldb: Parse register offsets from DT
Date: Tue, 4 Nov 2025 13:37:19 +0800	[thread overview]
Message-ID: <673c5737-6a8b-4008-962f-5d63ef5684b4@nxp.com> (raw)
In-Reply-To: <0c4bb240-6f5d-46c2-8a0d-7446ad3a9d31@mailbox.org>

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

Hello Marek,

> 
>>> @@ -61,24 +62,13 @@ enum fsl_ldb_devtype {
>>>   };
>>>     struct fsl_ldb_devdata {
>>> -    u32 ldb_ctrl;
>>> -    u32 lvds_ctrl;
>>>       bool lvds_en_bit;
>>> -    bool single_ctrl_reg;
>>>   };
>>>     static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
>>
>> As I pointed out in v1 comment, this patch should remove struct
>> fsl_ldb_devdata.
> 
> The lvds_en_bit is still needed , and I plan to add MX95 support here,
> which would extend this again. Going back and forth makes little sense.

lvds_en_bit is indeed needed and it doesn't have to be in struct
fsl_ldb_devdata.  Given that it's not clear if i.MX95 LDB support would
be in fsl-ldb.c or not and it's trivial to add struct fsl_ldb_devdata
back if needed, I think this patch should remove struct fsl_ldb_devdata.

> 
> [...]
> 
>>> @@ -309,6 +302,27 @@ static int fsl_ldb_probe(struct platform_device *pdev)
>>>       fsl_ldb->dev = &pdev->dev;
>>>       fsl_ldb->bridge.of_node = dev->of_node;
>>>   +    /* No "reg-names" property likely means single-register LDB */
>>> +    idx = of_property_match_string(dev->of_node, "reg-names", "ldb");
>>
>> You don't need to match reg-names.  Instead, just call of_property_read_reg()
>> twice to get the first reg and the second reg by passing indexes 0 and 1 to it.
>> If the second reg is not found, then set fsl_ldb->single_ctrl_reg to true.
> 
> This wouldn't work if the two entries were ordered the other way around in,
> DT, i.e. first "ldb" second "lvds" and vice-versa. That's why properties
> with multiple values also have the -names property that goes with them.

Isn't the order checked by schema fsl,ldb.yaml?  Let the schema do it's job.
"ldb" is the first item and "lvds" is the second one.  If you swap the two
for the example in the schema, dt_binding_check would complain:

DTC [C] Documentation/devicetree/bindings/display/bridge/fsl,ldb.example.dtb
Documentation/devicetree/bindings/display/bridge/fsl,ldb.example.dtb: bridge@5c (fsl,imx8mp-ldb): reg-names:0: 'ldb' was expected
	from schema $id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml#
Documentation/devicetree/bindings/display/bridge/fsl,ldb.example.dtb: bridge@5c (fsl,imx8mp-ldb): reg-names:1: 'lvds' was expected
	from schema $id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml#

-- 
Regards,
Liu Ying

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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02 17:02 [PATCH v2] drm/bridge: fsl-ldb: Parse register offsets from DT Marek Vasut
2025-11-03 15:55 ` Luca Ceresoli
2025-11-03 23:08   ` Marek Vasut
2025-11-05 18:03     ` Luca Ceresoli
2026-01-04 21:39       ` Marek Vasut
2025-11-04  2:39 ` Liu Ying
2025-11-04  3:13   ` Marek Vasut
2025-11-04  5:37     ` Liu Ying [this message]

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=673c5737-6a8b-4008-962f-5d63ef5684b4@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