RE: [PATCH v3 3/3] drm: adv7511: Drop dsi single lane support
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: 06 November 2024 19:25
> Subject: Re: [PATCH v3 3/3] drm: adv7511: Drop dsi single lane support
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Nov 06, 2024 at 06:49:30PM +, Biju Das wrote:
> > As per [1], ADV7535/7533 support only 2-, 3-, or 4-lane. Drop
> > unsupported 1-lane.
> >
> > [1]
> > https://www.analog.com/media/en/technical-documentation/data-sheets/AD
> > V7535.pdf
>
> No need for a line break, this should be
>
> [1]
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf
OK. Will add the link to ADV7533 as well.
>
> >
> > Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
> > Reported-by: Hien Huynh
>
> Reported-by is supposed to be immediately followed by a Closes: tag.
>
> With those fixed,
There is no report available on the weblink. It is just private chat we
discussed about the
out-of-bounds array issue. Check patch complained about missing Closes tag.
But as per [1], Closes tag report is not required for private bugs??
[1]
https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
I will send next version if it is OK for you without the Closes tag
Or
Will just remove Reported-by tag to make check patch happy.
Please let me know.
Cheers,
Biju
>
> Reviewed-by: Laurent Pinchart
>
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Biju Das
> > ---
> > Changes in v3:
> > - Updated commit header and description
> > - Updated fixes tag
> > - Dropped single lane support
> > Changes in v2:
> > - Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
> > - Dropped Archit Taneja invalid Mail address
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > index de55d687245a..ec360f8b7509 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > @@ -173,7 +173,7 @@ int adv7533_parse_dt(struct device_node *np,
> > struct adv7511 *adv)
> >
> > of_property_read_u32(np, "adi,dsi-lanes", &num_lanes);
> >
> > - if (num_lanes < 1 || num_lanes > 4)
> > + if (num_lanes < 2 || num_lanes > 4)
> > return -EINVAL;
> >
> > adv->num_dsi_lanes = num_lanes;
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v3 2/3] dt-bindings: display: adi,adv7533: Drop single lane support
Hi Geert,
Thanks for the feedback.
> -Original Message-
> From: Geert Uytterhoeven
> Sent: 06 November 2024 19:07
> Subject: Re: [PATCH v3 2/3] dt-bindings: display: adi,adv7533: Drop single
> lane support
>
> Hi Biju,
>
> On Wed, Nov 6, 2024 at 7:49 PM Biju Das wrote:
> > As per [1], ADV7535/7533 support only 2-, 3-, or 4-lane. Drop
> > unsupported 1-lane from bindings.
> >
> > [1]
> > https://www.analog.com/media/en/technical-documentation/data-sheets/AD
> > V7535.pdf
>
> The above is for ADV7535. Fortunately
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7533.pdf
> agrees ;-)
>
> > Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Biju Das
>
> With the description updated:
OK, I will add the links to both devices in the escription.
Cheers,
Biju
> Reviewed-by: Geert Uytterhoeven
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to
> journalists I just say "programmer" or something like that.
> -- Linus Torvalds
RE: [PATCH v3 1/3] drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: 06 November 2024 19:33
> Subject: Re: [PATCH v3 1/3] drm: adv7511: Fix use-after-free in
> adv7533_attach_dsi()
>
> On Wed, Nov 06, 2024 at 08:04:16PM +0100, Geert Uytterhoeven wrote:
> > Hi Biju,
> >
> > On Wed, Nov 6, 2024 at 7:49 PM Biju Das wrote:
> > > The host_node pointer assigned and freed in adv7533_parse_dt() and
> > > later adv7533_attach_dsi() uses the same. Fix this issue by freeing
> > > the host_node in adv7533_attach_dsi() instead of adv7533_parse_dt().
> > >
> > > Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI
> > > device")
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Biju Das
> > > ---
> > > Changes in v3:
> > > - Replace __free construct with readable of_node_put().
> > > Changes in v2:
> > > - Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
> > > - Dropped Archit Taneja invalid Mail address
> >
> > Thanks for the update!
> >
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > > @@ -143,6 +143,7 @@ int adv7533_attach_dsi(struct adv7511 *adv)
> > > };
> > >
> > > host = of_find_mipi_dsi_host_by_node(adv->host_node);
> > > + of_node_put(adv->host_node);
> >
> > This still looks fragile to me, as afterwards a pointer to a freed
> > node is left in struct adv7511.host_node. It would be safer to also
> > clear adv->host_node here.
> >
> > However, taking a look from a distance, the code looks like:
> >
> > static int adv7511_probe(struct i2c_client *i2c)
> > {
> > ...
> > adv7533_parse_dt(dev->of_node, adv7511);
> > ...
> > if (adv7511->info->has_dsi)
> > ret = adv7533_attach_dsi(adv7511);
> > ...
> > }
> >
> > The only reason adv7511.host_node exists is to pass it from
> > adv7533_parse_dt() to adv7533_attach_dsi().
> > So what about making this explicit?
> > 1. Let adv7533_parse_dt() return the host_node or an error pointer,
> > 2. Pass the host_node as a parameter to adv7533_attach_dsi(),
> > 3. Call of_node_put() in adv7511_probe() after use.
>
> Or, alternatively, if keeping the node pointer in the adv7511 structure is
> preferred, call
> of_node_put() at .remove() time.
We don't need to store unnecessary pointer if we handle the host_node pointer
in the probe().
I will go with Geert's suggestion.
Cheers,
Biju
>
> > > if (!host)
> > > return dev_err_probe(dev, -EPROBE_DEFER,
> > > "failed to find dsi host\n");
> > > @@ -181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct
> > > adv7511 *adv)
> > > if (!adv->host_node)
> > > return -ENODEV;
> > >
> > > - of_node_put(adv->host_node);
> > > -
> > > adv->use_timing_gen = !of_property_read_bool(np,
> > >
> > > "adi,disable-timing-generator");
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v3 2/3] dt-bindings: display: adi,adv7533: Drop single lane support
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: 06 November 2024 19:31
> Subject: Re: [PATCH v3 2/3] dt-bindings: display: adi,adv7533: Drop single
> lane support
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Nov 06, 2024 at 06:49:29PM +, Biju Das wrote:
> > As per [1], ADV7535/7533 support only 2-, 3-, or 4-lane. Drop
> > unsupported 1-lane from bindings.
> >
> > [1]
> > https://www.analog.com/media/en/technical-documentation/data-sheets/AD
> > V7535.pdf
>
> No need for a line break, you can write
>
> [1]
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf
Agreed. Will add the missing link for ADV7533 as well.
Cheers,
Biju
>
> >
> > Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Biju Das
>
> Reviewed-by: Laurent Pinchart
>
> > ---
> > v3:
> > * New patch.
> > ---
> > .../devicetree/bindings/display/bridge/adi,adv7533.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> > b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> > index df20a3c9c744..ec89115c74e4 100644
> > ---
> > a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yam
> > +++ l
> > @@ -90,7 +90,7 @@ properties:
> >adi,dsi-lanes:
> > description: Number of DSI data lanes connected to the DSI host.
> > $ref: /schemas/types.yaml#/definitions/uint32
> > -enum: [ 1, 2, 3, 4 ]
> > +enum: [ 2, 3, 4 ]
> >
> >"#sound-dai-cells":
> > const: 0
>
> --
> Regards,
>
> Laurent Pinchart
[PATCH v3 3/3] drm: adv7511: Drop dsi single lane support
As per [1], ADV7535/7533 support only 2-, 3-, or 4-lane. Drop
unsupported 1-lane.
[1]
https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf
Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
Reported-by: Hien Huynh
Cc: sta...@vger.kernel.org
Signed-off-by: Biju Das
---
Changes in v3:
- Updated commit header and description
- Updated fixes tag
- Dropped single lane support
Changes in v2:
- Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
- Dropped Archit Taneja invalid Mail address
---
drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index de55d687245a..ec360f8b7509 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -173,7 +173,7 @@ int adv7533_parse_dt(struct device_node *np, struct adv7511
*adv)
of_property_read_u32(np, "adi,dsi-lanes", &num_lanes);
- if (num_lanes < 1 || num_lanes > 4)
+ if (num_lanes < 2 || num_lanes > 4)
return -EINVAL;
adv->num_dsi_lanes = num_lanes;
--
2.43.0
[PATCH v3 2/3] dt-bindings: display: adi, adv7533: Drop single lane support
As per [1], ADV7535/7533 support only 2-, 3-, or 4-lane. Drop
unsupported 1-lane from bindings.
[1]
https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf
Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
Cc: sta...@vger.kernel.org
Signed-off-by: Biju Das
---
v3:
* New patch.
---
.../devicetree/bindings/display/bridge/adi,adv7533.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
index df20a3c9c744..ec89115c74e4 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
@@ -90,7 +90,7 @@ properties:
adi,dsi-lanes:
description: Number of DSI data lanes connected to the DSI host.
$ref: /schemas/types.yaml#/definitions/uint32
-enum: [ 1, 2, 3, 4 ]
+enum: [ 2, 3, 4 ]
"#sound-dai-cells":
const: 0
--
2.43.0
[PATCH v3 1/3] drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
The host_node pointer assigned and freed in adv7533_parse_dt()
and later adv7533_attach_dsi() uses the same. Fix this issue
by freeing the host_node in adv7533_attach_dsi() instead of
adv7533_parse_dt().
Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
Cc: sta...@vger.kernel.org
Signed-off-by: Biju Das
---
Changes in v3:
- Replace __free construct with readable of_node_put().
Changes in v2:
- Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
- Dropped Archit Taneja invalid Mail address
---
drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 4481489aaf5e..de55d687245a 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -143,6 +143,7 @@ int adv7533_attach_dsi(struct adv7511 *adv)
};
host = of_find_mipi_dsi_host_by_node(adv->host_node);
+ of_node_put(adv->host_node);
if (!host)
return dev_err_probe(dev, -EPROBE_DEFER,
"failed to find dsi host\n");
@@ -181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct adv7511
*adv)
if (!adv->host_node)
return -ENODEV;
- of_node_put(adv->host_node);
-
adv->use_timing_gen = !of_property_read_bool(np,
"adi,disable-timing-generator");
--
2.43.0
[PATCH v3 0/3] drm: adv7511: ADV7535 fixes
This patch series aims to fix 2 bugs in ADV7535 driver 1) use-after-free bug in adv7533_attach_dsi() 2) Drop unsupported single lane. Changes in v3: - Replace __free construct with readable of_node_put(). - Dropped single lane support from bindings and driver. changes in v2: - Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area. - Dropped invalid Mail address Archit Taneja . Biju Das (3): drm: adv7511: Fix use-after-free in adv7533_attach_dsi() dt-bindings: display: adi,adv7533: Drop single lane support drm: adv7511: Drop dsi single lane support .../devicetree/bindings/display/bridge/adi,adv7533.yaml | 2 +- drivers/gpu/drm/bridge/adv7511/adv7533.c | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) -- 2.43.0
RE: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes
Hi Laurent Pinchart,
> -Original Message-
> From: Laurent Pinchart
> Sent: 05 November 2024 16:06
> Subject: Re: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in
> clock_div_by_lanes
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Nov 05, 2024 at 11:12:19AM +, Biju Das wrote:
> > Fix out-of-bounds array in adv7511_dsi_config_timing_gen(), when dsi
> > lanes = 1.
>
> Does the hardware support using the internal timing generator with a single
> lane ? If so
> adv7511_dsi_config_timing_gen() should be fixed, otherwise that should be
> explained in the commit
> message, and mentioned with a comment in adv7533_parse_dt(). I would also
> print an error message in
> that case.
>
> If the internal timing generator can't be used with a single lane, the DT
> bindings should also be
> updated to document that.
As per [1], lanes = 1 is not supported in ADV7535/ADV7533.
I will update the code and binding to remove lanes=1 support.
[1]
https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf
Cheers,
Biju
>
> > Fixes: 78fa479d703c ("drm/bridge: adv7533: Use internal timing
> > generator")
> > Reported-by: Hien Huynh
> > Signed-off-by: Biju Das
> > ---
> > Changes in v2:
> > - Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
> > - Dropped Archit Taneja invalid Mail address
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
RE: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes
Hi Laurent Pinchart, > -Original Message- > From: dri-devel On Behalf Of > Laurent Pinchart > Sent: 06 November 2024 13:18 > Subject: Re: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in > clock_div_by_lanes > > On Wed, Nov 06, 2024 at 10:20:43AM +, Biju Das wrote: > > Hi Laurent Pinchart, > > > > Thanks for the feedback. > > > > > -Original Message- > > > From: Laurent Pinchart > > > Sent: 05 November 2024 16:06 > > > Subject: Re: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in > > > clock_div_by_lanes > > > > > > Hi Biju, > > > > > > Thank you for the patch. > > > > > > On Tue, Nov 05, 2024 at 11:12:19AM +, Biju Das wrote: > > > > Fix out-of-bounds array in adv7511_dsi_config_timing_gen(), when > > > > dsi lanes = 1. > > > > > > Does the hardware support using the internal timing generator with a > > > single lane ? If so > > > > As per the binding documentation [1], ADV7535 supports single lane. > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > > ee/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml?h > > =next-20241106 > > > > > adv7511_dsi_config_timing_gen() should be fixed, otherwise that > > > should be explained in the commit > > > > On RZ/G2L SMARC EVK platform, lanes=2,3,4 works ok, But with setting > > lanes=1, video is unstable by trying with clock_divider as 6,7 and 8 by > > updating the array and also > disabling internal timing generator. > > Is that an issue specific to that board, or to the chip in general ? If it's > specific to the board, > disabling 1 lane usage for everybody in the driver isn't the right option. At this moment, I do not know it is specific to board as with the current code with lane=1 and internal timing generator, it will lead to kernel crash. So looks like no one tested lane=1 with internal timing generator. Then the question is any user has tested lanes=1 by disabling internal generator?? Lane=1 corresponds to resolution 800x600@60 and below. Cheers, Biju
RE: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes
Hi Laurent Pinchart,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: 05 November 2024 16:06
> Subject: Re: [PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in
> clock_div_by_lanes
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Nov 05, 2024 at 11:12:19AM +, Biju Das wrote:
> > Fix out-of-bounds array in adv7511_dsi_config_timing_gen(), when dsi
> > lanes = 1.
>
> Does the hardware support using the internal timing generator with a single
> lane ? If so
As per the binding documentation [1], ADV7535 supports single lane.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml?h=next-20241106
> adv7511_dsi_config_timing_gen() should be fixed, otherwise that should be
> explained in the commit
On RZ/G2L SMARC EVK platform, lanes=2,3,4 works ok, But with setting lanes=1,
video is unstable
by trying with clock_divider as 6,7 and 8 by updating the array and also
disabling internal timing generator.
> message, and mentioned with a comment in adv7533_parse_dt(). I would also
> print an error message in
> that case.
OK, this can be done.
>
> If the internal timing generator can't be used with a single lane, the DT
> bindings should also be
> updated to document that.
Even single lane with or without internal timing generator does not work on
RZ/G2L.
So, any users of ADV 7535 tested single lane??
Cheers,
Biju
>
> > Fixes: 78fa479d703c ("drm/bridge: adv7533: Use internal timing
> > generator")
> > Reported-by: Hien Huynh
> > Signed-off-by: Biju Das
> > ---
> > Changes in v2:
> > - Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
> > - Dropped Archit Taneja invalid Mail address
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > index 3e57ba838e5e..0c2236e53af5 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > @@ -185,6 +185,9 @@ int adv7533_parse_dt(struct device_node *np, struct
> > adv7511 *adv)
> > adv->use_timing_gen = !of_property_read_bool(np,
> > "adi,disable-timing-generator");
> >
> > + if (adv->use_timing_gen && num_lanes == 1)
> > + return -EINVAL;
> > +
> > /* TODO: Check if these need to be parsed by DT or not */
> > adv->rgb = true;
> > adv->embedded_sync = false;
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v2 1/2] drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: 05 November 2024 16:02
> Subject: Re: [PATCH v2 1/2] drm: adv7511: Fix use-after-free in
> adv7533_attach_dsi()
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Nov 05, 2024 at 11:12:18AM +, Biju Das wrote:
> > The host_node pointer assigned and freed in adv7533_parse_dt() and
> > later adv7533_attach_dsi() uses the same. Fix this issue by freeing
> > the host_node in adv7533_attach_dsi() instead of adv7533_parse_dt().
> >
> > Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Biju Das
> > ---
> > Changes in v2:
> > - Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
> > - Dropped Archit Taneja invalid Mail address
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > index 4481489aaf5e..3e57ba838e5e 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> > @@ -133,6 +133,7 @@ int adv7533_patch_cec_registers(struct adv7511
> > *adv)
> >
> > int adv7533_attach_dsi(struct adv7511 *adv) {
> > + struct device_node *np __free(device_node) = adv->host_node;
>
> This raises so many red flags. The function will free the node while the
> adv->host_node variable still points to it, opening the door to
I agree, adv->host_node still points to it and open again the door to
use-after-free.
> use-after-free. Furthermore, there's nothing in the function name that hints
> it will do this, callers
> can get surprised by this behaviour.
By looking at [1], it can free the node pointer when it returns from the
function. As you
said there is no hints from function name. __free(device_node) just tells to
free the
random device node assigned to the local variable.
[1]
https://elixir.bootlin.com/linux/v6.12-rc5/source/include/linux/of.h#L138
>
> I'm sure you can do better than this and fix the problem with readable code,
> not cryptic and error-
> prone constructs :-)
Agreed. Will fix the problem with readable code.
Cheers,
Biju
>
> > struct device *dev = &adv->i2c_main->dev;
> > struct mipi_dsi_host *host;
> > struct mipi_dsi_device *dsi;
> > @@ -181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct
> > adv7511 *adv)
> > if (!adv->host_node)
> > return -ENODEV;
> >
> > - of_node_put(adv->host_node);
> > -
> > adv->use_timing_gen = !of_property_read_bool(np,
> > "adi,disable-timing-generator");
> >
>
> --
> Regards,
>
> Laurent Pinchart
[PATCH v2 1/2] drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
The host_node pointer assigned and freed in adv7533_parse_dt()
and later adv7533_attach_dsi() uses the same. Fix this issue
by freeing the host_node in adv7533_attach_dsi() instead of
adv7533_parse_dt().
Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
Cc: sta...@vger.kernel.org
Signed-off-by: Biju Das
---
Changes in v2:
- Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
- Dropped Archit Taneja invalid Mail address
---
drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 4481489aaf5e..3e57ba838e5e 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -133,6 +133,7 @@ int adv7533_patch_cec_registers(struct adv7511 *adv)
int adv7533_attach_dsi(struct adv7511 *adv)
{
+ struct device_node *np __free(device_node) = adv->host_node;
struct device *dev = &adv->i2c_main->dev;
struct mipi_dsi_host *host;
struct mipi_dsi_device *dsi;
@@ -181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct adv7511
*adv)
if (!adv->host_node)
return -ENODEV;
- of_node_put(adv->host_node);
-
adv->use_timing_gen = !of_property_read_bool(np,
"adi,disable-timing-generator");
--
2.43.0
[PATCH 1/2] drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
The host_node pointer assigned and freed in adv7533_parse_dt()
and later adv7533_attach_dsi() uses the same. Fix this issue
by freeing the host_node in adv7533_attach_dsi() instead of
adv7533_parse_dt().
Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device")
Signed-off-by: Biju Das
---
drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 4481489aaf5e..3e57ba838e5e 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -133,6 +133,7 @@ int adv7533_patch_cec_registers(struct adv7511 *adv)
int adv7533_attach_dsi(struct adv7511 *adv)
{
+ struct device_node *np __free(device_node) = adv->host_node;
struct device *dev = &adv->i2c_main->dev;
struct mipi_dsi_host *host;
struct mipi_dsi_device *dsi;
@@ -181,8 +182,6 @@ int adv7533_parse_dt(struct device_node *np, struct adv7511
*adv)
if (!adv->host_node)
return -ENODEV;
- of_node_put(adv->host_node);
-
adv->use_timing_gen = !of_property_read_bool(np,
"adi,disable-timing-generator");
--
2.43.0
[PATCH v2 2/2] drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes
Fix out-of-bounds array in adv7511_dsi_config_timing_gen(),
when dsi lanes = 1.
Fixes: 78fa479d703c ("drm/bridge: adv7533: Use internal timing generator")
Reported-by: Hien Huynh
Signed-off-by: Biju Das
---
Changes in v2:
- Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area.
- Dropped Archit Taneja invalid Mail address
---
drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 3e57ba838e5e..0c2236e53af5 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -185,6 +185,9 @@ int adv7533_parse_dt(struct device_node *np, struct adv7511
*adv)
adv->use_timing_gen = !of_property_read_bool(np,
"adi,disable-timing-generator");
+ if (adv->use_timing_gen && num_lanes == 1)
+ return -EINVAL;
+
/* TODO: Check if these need to be parsed by DT or not */
adv->rgb = true;
adv->embedded_sync = false;
--
2.43.0
[PATCH v2 0/2] drm: adv7511: ADV7535 fixes
This patch series aims to fix 2 bugs in ADV7535 driver 1) use-after-free bug in adv7533_attach_dsi() 2) out-of-bounds array in adv7511_dsi_config_timing_gen() for clock_div_by_lanes[]. changes in v2: * Added the tag "Cc: sta...@vger.kernel.org" in the sign-off area. * Dropped invalid Mail address Archit Taneja . Biju Das (2): drm: adv7511: Fix use-after-free in adv7533_attach_dsi() drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes drivers/gpu/drm/bridge/adv7511/adv7533.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.43.0
[PATCH 2/2] drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes
Fix out-of-bounds array in adv7511_dsi_config_timing_gen() for
clock_div_by_lanes[], when dsi lanes = 1.
Fixes: 78fa479d703c ("drm/bridge: adv7533: Use internal timing generator")
Reported-by: Hien Huynh
Signed-off-by: Biju Das
---
drivers/gpu/drm/bridge/adv7511/adv7533.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index 3e57ba838e5e..0c2236e53af5 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -185,6 +185,9 @@ int adv7533_parse_dt(struct device_node *np, struct adv7511
*adv)
adv->use_timing_gen = !of_property_read_bool(np,
"adi,disable-timing-generator");
+ if (adv->use_timing_gen && num_lanes == 1)
+ return -EINVAL;
+
/* TODO: Check if these need to be parsed by DT or not */
adv->rgb = true;
adv->embedded_sync = false;
--
2.43.0
[PATCH 0/2] drm: adv7511: ADV7535 fixes
This patch series aims to fix 2 bugs in ADV7535 driver 1) use-after-free bug in adv7533_attach_dsi() 2) out-of-bounds array in adv7511_dsi_config_timing_gen() for clock_div_by_lanes[]. Biju Das (2): drm: adv7511: Fix use-after-free in adv7533_attach_dsi() drm: adv7511: Fix out-of-bounds array in clock_div_by_lanes drivers/gpu/drm/bridge/adv7511/adv7533.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.43.0
RE: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
Hi Dmitry Baryshkov,
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 30 October 2024 03:17
> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
>
> On Tue, 29 Oct 2024 at 04:41, Liu Ying wrote:
> >
> > On 10/28/2024, Dmitry Baryshkov wrote:
> > > On Mon, Oct 28, 2024 at 11:12:00AM +, Biju Das wrote:
> > >> Hi Dmitry, Liu,
> > >>
> > >>> -Original Message-
> > >>> From: Dmitry Baryshkov
> > >>> Sent: 28 October 2024 10:20
> > >>> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI
> > >>> converter support
> > >>>
> > >>> Hi,
> > >>>
> > >>> On Mon, 28 Oct 2024 at 04:37, Liu Ying wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> This patch series aims to add ITE IT6263 LVDS to HDMI converter
> > >>>> on i.MX8MP EVK. Combined with LVDS receiver and HDMI 1.4a
> > >>>> transmitter, the IT6263 supports LVDS input and HDMI 1.4 output
> > >>>> by conversion function. IT6263 product link can be found at [1].
> > >>>>
> > >>>> Patch 1 is a preparation patch to allow display mode of an
> > >>>> existing panel to pass the added mode validation logic in patch 3.
> > >>>>
> > >>>> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to
> > >>>> find the next non-panel bridge, that is the IT6263 in this case.
> > >>>>
> > >>>> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > >>>> against "ldb" clock so that it can filter out unsupported display
> > >>>> modes read from EDID.
> > >>>>
> > >>>> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support,
> > >>>> as they are supported by IT6263(with LVDS data bit reversed order).
> > >>>>
> > >>>> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> > >>>>
> > >>>> Patch 6 supports getting dual-link LVDS pixel order for the sink
> > >>>> side as needed by IT6263 driver.
> > >>>>
> > >>>> Patch 7 documents jeida-30 and vesa-30 data mappings in
> > >>>> lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> > >>>>
> > >>>> Patch 8 extracts common dual-link LVDS display properties into
> > >>>> new lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> > >>>>
> > >>>> Patch 9 adds DT binding for IT6263.
> > >>>>
> > >>>> Patch 10 adds IT6263 bridge driver. Only video output is supported.
> > >>>>
> > >>>> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > >>>> IT6263 populated.
> > >>>>
> > >>>> Patch 12 enables the IT6263 bridge driver in defconfig.
> > >>>>
> > >>>> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> > >>>
> > >>> This has pretty complicated structure from the merging point of view.
> > >>>
> > >>> I propose we take patches 6, 8, 9 (without 30-bit formats, they
> > >>> can be dropped while applying), 11, 12
> > >>> (?) and 13 through drm-misc in one batch (once DT maintainers
> > >>> review the binding parts). This looks like a minimal set, having no
> > >>> extra dependencies.
> > >>
> > >>>
> > >>> The second set might be 4, 5 + new patch, re-adding 30-bit formats
> > >>> to
> > >>> IT6263 binding (no driver changes are necessary). This can go in
> > >>> separately, after an Ack from media maintainers.
> > >>>
> > >>> Of course both sets can go together if linux-media maintainers
> > >>> reacts quickly and ack merging media- formats patch through drm-misc
> > >>> tree.
> >
> > I'm fine with merging the two sets through drm-misc tree as long as
> > linux-media and dri-devel maintainers accept this. Up to them.
> >
> > >>>
> > >>> The rest of the patches don't have such strong dependencies and go in
> > >>> once ready / reviewed.
> > >>>
> > >>> WDYT?
> > >>
> > >> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
> > >>
> > >> 11 may have dependency on 1, 2 and 3 as it is SoC specific.
> > >
> > > Yes, of course, 10, not 11.
> > >
> > >> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.
> >
> > I think it would be good to directly support 30-bit formats in
> > IT6263 DT binding, not re-add them to it. This way, we'll have one
> > version of the binding, not two. So, a better first set would contain
> > patch 6, 7(one existing A-b from Krzysztof), 8, 9, 10, 12 and 13.
>
> I'm not sure that 7 can go without an ack from linux-media maintainers.
You mean in describing jeida-30 and vesa-30 format in
patch#7, is valid only if patch#4 is ok with media people
or they provide an ack for patch#7 to take it through drm tree?
Cheers,
Biju
RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
Hi Liu Ying, > -Original Message- > From: dri-devel On Behalf Of Liu > Ying > Sent: 29 October 2024 09:07 > Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS > display common properties > > On 10/29/2024, Biju Das wrote: > > Hi Liu Ying, > > Hi Biju, > > > > >> -Original Message- > >> From: dri-devel On Behalf > >> Of Liu Ying > >> Sent: 29 October 2024 08:02 > >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document > >> dual-link LVDS display common properties > >> > >> On 10/29/2024, Biju Das wrote: > >>> Hi Liu Ying, > >> > >> Hi Biju, > >> > >>> > >>>> -Original Message- > >>>> From: Liu Ying > >>>> Sent: 28 October 2024 02:38 > >>>> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link > >>>> LVDS display common properties > >>>> > >>>> Dual-link LVDS displays receive odd pixels and even pixels > >>>> separately from dual LVDS links. One link receives odd pixels and > >>>> the other receives even pixels. Some of those displays may also > >>>> use only one LVDS link to receive all pixels, being odd and even > >>>> agnostic. Document common properties for those > >> displays by extending LVDS display common properties defined in lvds.yaml. > >>>> > >>>> Suggested-by: Dmitry Baryshkov > >>>> Signed-off-by: Liu Ying > >>>> --- > >>>> v4: > >>>> * Squash change for advantech,idk-2121wr.yaml and > >>>> panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml. > >>>> (Rob) > >>>> * Improve description in lvds-dual-ports.yaml. (Krzysztof) > >>>> > >>>> v3: > >>>> * New patch. (Dmitry) > >>>> > >>>> .../bindings/display/lvds-dual-ports.yaml | 76 +++ > >>>> .../display/panel/advantech,idk-2121wr.yaml | 14 +--- > >>>> .../panel/panel-simple-lvds-dual-ports.yaml | 20 + > >>>> 3 files changed, 78 insertions(+), 32 deletions(-) create mode > >>>> 100644 > >>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>>> > >>>> diff --git > >>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>>> new file mode 100644 > >>>> index ..5f7a30640404 > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yam > >>>> +++ l > >>>> @@ -0,0 +1,76 @@ > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > >>>> +1.2 > >>>> +--- > >>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml# > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>> + > >>>> +title: Dual-link LVDS Display Common Properties > >>>> + > >>>> +maintainers: > >>>> + - Liu Ying > >>>> + > >>>> +description: | > >>>> + Common properties for LVDS displays with dual LVDS links. Extend > >>>> +LVDS display > >>>> + common properties defined in lvds.yaml. > >>>> + > >>>> + Dual-link LVDS displays receive odd pixels and even pixels > >>>> + separately from the dual LVDS links. One link receives odd > >>>> + pixels and the other receives even pixels. Some of those > >>>> + displays may also use only one LVDS link to receive all pixels, being > >>>> odd and even agnostic. > >>>> + > >>>> +allOf: > >>>> + - $ref: lvds.yaml# > >>>> + > >>>> +properties: > >>>> + ports: > >>>> +$ref: /schemas/graph.yaml#/properties/ports > >>>> + > >>>> +properties: > >>>> + port@0: > >>>> +$ref: /schemas/graph.yaml#/$defs/port-base > >>>> +unevaluatedProperties: false > >>>> +description: the first LVDS input link > >>>> + > >>>> +properties: > >>>> + dual-lvds-odd-pixels: > >>>> +
RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
Hi Liu Ying, > -Original Message- > From: dri-devel On Behalf Of Liu > Ying > Sent: 29 October 2024 08:02 > Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS > display common properties > > On 10/29/2024, Biju Das wrote: > > Hi Liu Ying, > > Hi Biju, > > > > >> -Original Message- > >> From: Liu Ying > >> Sent: 28 October 2024 02:38 > >> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link > >> LVDS display common properties > >> > >> Dual-link LVDS displays receive odd pixels and even pixels separately > >> from dual LVDS links. One link receives odd pixels and the other > >> receives even pixels. Some of those displays may also use only one > >> LVDS link to receive all pixels, being odd and even agnostic. Document > >> common properties for those > displays by extending LVDS display common properties defined in lvds.yaml. > >> > >> Suggested-by: Dmitry Baryshkov > >> Signed-off-by: Liu Ying > >> --- > >> v4: > >> * Squash change for advantech,idk-2121wr.yaml and > >> panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml. (Rob) > >> * Improve description in lvds-dual-ports.yaml. (Krzysztof) > >> > >> v3: > >> * New patch. (Dmitry) > >> > >> .../bindings/display/lvds-dual-ports.yaml | 76 +++ > >> .../display/panel/advantech,idk-2121wr.yaml | 14 +--- > >> .../panel/panel-simple-lvds-dual-ports.yaml | 20 + > >> 3 files changed, 78 insertions(+), 32 deletions(-) create mode > >> 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >> new file mode 100644 > >> index ..5f7a30640404 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >> @@ -0,0 +1,76 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Dual-link LVDS Display Common Properties > >> + > >> +maintainers: > >> + - Liu Ying > >> + > >> +description: | > >> + Common properties for LVDS displays with dual LVDS links. Extend > >> +LVDS display > >> + common properties defined in lvds.yaml. > >> + > >> + Dual-link LVDS displays receive odd pixels and even pixels > >> + separately from the dual LVDS links. One link receives odd pixels > >> + and the other receives even pixels. Some of those displays may > >> + also use only one LVDS link to receive all pixels, being odd and even > >> agnostic. > >> + > >> +allOf: > >> + - $ref: lvds.yaml# > >> + > >> +properties: > >> + ports: > >> +$ref: /schemas/graph.yaml#/properties/ports > >> + > >> +properties: > >> + port@0: > >> +$ref: /schemas/graph.yaml#/$defs/port-base > >> +unevaluatedProperties: false > >> +description: the first LVDS input link > >> + > >> +properties: > >> + dual-lvds-odd-pixels: > >> +type: boolean > >> +description: the first LVDS input link for odd pixels > >> + > >> + dual-lvds-even-pixels: > >> +type: boolean > >> +description: the first LVDS input link for even pixels > > > > > > port@0 we know it is first link > > port@1 we know it is second link. > > dual-lvds-odd-pixels: We know it is for odd pixels. > > dual-lvds-even-pixels: We know it is for odd pixels. > > > > Not sure, whether we can give common description and avoid the > > duplicate from port@1 ?? > > Yes, it'd better to use patternProperties. Thanks. > > --8<-- > patternProperties: > '^port@[01]$': > $ref: /schemas/graph.yaml#/$defs/port-base > unevaluatedProperties: false > description: | > port@0 is for the first LVDS input link. > port@1 is for the second LVDS input link. > > properties: > dual-lvds-odd-pixels: > type: boolean >
RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
Hi Liu Ying, > -Original Message- > From: dri-devel On Behalf Of Liu > Ying > Sent: 29 October 2024 07:35 > Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS > display common properties > > On 10/29/2024, Biju Das wrote: > > Hi Liu Ying, > > Hi Biju, > > > > >> -Original Message- > >> From: Liu Ying > >> Sent: 29 October 2024 07:13 > >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document > >> dual-link LVDS display common properties > >> > >> On 10/29/2024, Biju Das wrote: > >>> Hi Liu Ying, > >> > >> Hi Biju, > >> > >>> > >>>> -Original Message- > >>>> From: Liu Ying > >>>> Sent: 29 October 2024 06:17 > >>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document > >>>> dual-link LVDS display common properties > >>>> > >>>> On 10/28/2024, Liu Ying wrote: > >>>>> Dual-link LVDS displays receive odd pixels and even pixels > >>>>> separately from dual LVDS links. One link receives odd pixels and > >>>>> the other receives even pixels. Some of those displays may also > >>>>> use only one LVDS link to receive all pixels, being odd and even > >>>>> agnostic. > >>>>> Document common properties for those displays by extending LVDS > >>>>> display common properties defined in lvds.yaml. > >>>>> > >>>>> Suggested-by: Dmitry Baryshkov > >>>>> Signed-off-by: Liu Ying > >>>>> --- > >>>>> v4: > >>>>> * Squash change for advantech,idk-2121wr.yaml and > >>>>> panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml. > >>>>> (Rob) > >>>>> * Improve description in lvds-dual-ports.yaml. (Krzysztof) > >>>>> > >>>>> v3: > >>>>> * New patch. (Dmitry) > >>>>> > >>>>> .../bindings/display/lvds-dual-ports.yaml | 76 +++ > >>>>> .../display/panel/advantech,idk-2121wr.yaml | 14 +--- > >>>>> .../panel/panel-simple-lvds-dual-ports.yaml | 20 + > >>>>> 3 files changed, 78 insertions(+), 32 deletions(-) create mode > >>>>> 100644 > >>>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>>>> > >>>>> diff --git > >>>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>>>> new file mode 100644 > >>>>> index ..5f7a30640404 > >>>>> --- /dev/null > >>>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.ya > >>>>> +++ ml > >>>>> @@ -0,0 +1,76 @@ > >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > >>>>> +1.2 > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Dual-link LVDS Display Common Properties > >>>>> + > >>>>> +maintainers: > >>>>> + - Liu Ying > >>>>> + > >>>>> +description: | > >>>>> + Common properties for LVDS displays with dual LVDS links. > >>>>> +Extend LVDS display > >>>>> + common properties defined in lvds.yaml. > >>>>> + > >>>>> + Dual-link LVDS displays receive odd pixels and even pixels > >>>>> + separately from the dual LVDS links. One link receives odd > >>>>> + pixels and the other receives even pixels. Some of those > >>>>> + displays may also use only one LVDS link to receive all pixels, > >>>>> being odd and even agnostic. > >>>>> + > >>>>> +allOf: > >>>>> + - $ref: lvds.yaml# > >>>>> + > >>>>> +properties: > >>>>> + ports: > >>>>> +$ref: /schemas/graph.yaml#/properties/ports > >>>>> + > >>>>> +properties: > >>>>> + port@0: > >>>>> +
RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
Hi Liu Ying, > -Original Message- > From: Liu Ying > Sent: 28 October 2024 02:38 > Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS > display common properties > > Dual-link LVDS displays receive odd pixels and even pixels separately from > dual LVDS links. One link > receives odd pixels and the other receives even pixels. Some of those > displays may also use only one > LVDS link to receive all pixels, being odd and even agnostic. Document > common properties for those > displays by extending LVDS display common properties defined in lvds.yaml. > > Suggested-by: Dmitry Baryshkov > Signed-off-by: Liu Ying > --- > v4: > * Squash change for advantech,idk-2121wr.yaml and > panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml. (Rob) > * Improve description in lvds-dual-ports.yaml. (Krzysztof) > > v3: > * New patch. (Dmitry) > > .../bindings/display/lvds-dual-ports.yaml | 76 +++ > .../display/panel/advantech,idk-2121wr.yaml | 14 +--- > .../panel/panel-simple-lvds-dual-ports.yaml | 20 + > 3 files changed, 78 insertions(+), 32 deletions(-) create mode 100644 > Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > > diff --git a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > new file mode 100644 > index ..5f7a30640404 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > @@ -0,0 +1,76 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Dual-link LVDS Display Common Properties > + > +maintainers: > + - Liu Ying > + > +description: | > + Common properties for LVDS displays with dual LVDS links. Extend LVDS > +display > + common properties defined in lvds.yaml. > + > + Dual-link LVDS displays receive odd pixels and even pixels separately > + from the dual LVDS links. One link receives odd pixels and the other > + receives even pixels. Some of those displays may also use only one > + LVDS link to receive all pixels, being odd and even agnostic. > + > +allOf: > + - $ref: lvds.yaml# > + > +properties: > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > + > +properties: > + port@0: > +$ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > +description: the first LVDS input link > + > +properties: > + dual-lvds-odd-pixels: > +type: boolean > +description: the first LVDS input link for odd pixels > + > + dual-lvds-even-pixels: > +type: boolean > +description: the first LVDS input link for even pixels port@0 we know it is first link port@1 we know it is second link. dual-lvds-odd-pixels: We know it is for odd pixels. dual-lvds-even-pixels: We know it is for odd pixels. Not sure, whether we can give common description and avoid the duplicate from port@1 ?? > + > +oneOf: > + - required: [dual-lvds-odd-pixels] > + - required: [dual-lvds-even-pixels] > + - properties: > + dual-lvds-odd-pixels: false > + dual-lvds-even-pixels: false Why this is false here? oneOf is not sufficient? > + > + port@1: > +$ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > +description: the second LVDS input link > + > +properties: > + dual-lvds-odd-pixels: > +type: boolean > +description: the second LVDS input link for odd pixels > + > + dual-lvds-even-pixels: > +type: boolean > +description: the second LVDS input link for even pixels > + > +oneOf: > + - required: [dual-lvds-odd-pixels] > + - required: [dual-lvds-even-pixels] > + - properties: > + dual-lvds-odd-pixels: false > + dual-lvds-even-pixels: false Same as above?? Cheers, Biju > + > +required: > + - ports > + > +additionalProperties: true > + > +... > diff --git > a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml > b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml > index 2e8dbdb5a3d5..05ca3b2385f8 100644 > --- > a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml > +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121 > +++ wr.yaml > @@ -20,6 +20,7 @@ description: | >dual-lvds-odd-pixels or dual-lvds-even-pixels). > > allOf: > + - $ref: /schemas/display/lvds-dual-ports.yaml# >- $ref: panel-common.yaml# > > properties: > @@ -44,22 +45,10 @@ properties: > > properties: >port@0: > -$ref: /schemas/graph.yaml#/$defs/port-base > -unevaluatedProperties: false
RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
Hi Liu Ying, > -Original Message- > From: Liu Ying > Sent: 29 October 2024 07:13 > Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS > display common properties > > On 10/29/2024, Biju Das wrote: > > Hi Liu Ying, > > Hi Biju, > > > > >> -Original Message- > >> From: Liu Ying > >> Sent: 29 October 2024 06:17 > >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document > >> dual-link LVDS display common properties > >> > >> On 10/28/2024, Liu Ying wrote: > >>> Dual-link LVDS displays receive odd pixels and even pixels > >>> separately from dual LVDS links. One link receives odd pixels and > >>> the other receives even pixels. Some of those displays may also use > >>> only one LVDS link to receive all pixels, being odd and even agnostic. > >>> Document common properties for those displays by extending LVDS > >>> display common properties defined in lvds.yaml. > >>> > >>> Suggested-by: Dmitry Baryshkov > >>> Signed-off-by: Liu Ying > >>> --- > >>> v4: > >>> * Squash change for advantech,idk-2121wr.yaml and > >>> panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml. > >>> (Rob) > >>> * Improve description in lvds-dual-ports.yaml. (Krzysztof) > >>> > >>> v3: > >>> * New patch. (Dmitry) > >>> > >>> .../bindings/display/lvds-dual-ports.yaml | 76 +++ > >>> .../display/panel/advantech,idk-2121wr.yaml | 14 +--- > >>> .../panel/panel-simple-lvds-dual-ports.yaml | 20 + > >>> 3 files changed, 78 insertions(+), 32 deletions(-) create mode > >>> 100644 > >>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>> new file mode 100644 > >>> index ..5f7a30640404 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > >>> @@ -0,0 +1,76 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> + > >>> +title: Dual-link LVDS Display Common Properties > >>> + > >>> +maintainers: > >>> + - Liu Ying > >>> + > >>> +description: | > >>> + Common properties for LVDS displays with dual LVDS links. Extend > >>> +LVDS display > >>> + common properties defined in lvds.yaml. > >>> + > >>> + Dual-link LVDS displays receive odd pixels and even pixels > >>> + separately from the dual LVDS links. One link receives odd pixels > >>> + and the other receives even pixels. Some of those displays may > >>> + also use only one LVDS link to receive all pixels, being odd and even > >>> agnostic. > >>> + > >>> +allOf: > >>> + - $ref: lvds.yaml# > >>> + > >>> +properties: > >>> + ports: > >>> +$ref: /schemas/graph.yaml#/properties/ports > >>> + > >>> +properties: > >>> + port@0: > >>> +$ref: /schemas/graph.yaml#/$defs/port-base > >>> +unevaluatedProperties: false > >>> +description: the first LVDS input link > >>> + > >>> +properties: > >>> + dual-lvds-odd-pixels: > >>> +type: boolean > >>> +description: the first LVDS input link for odd pixels > >>> + > >>> + dual-lvds-even-pixels: > >>> +type: boolean > >>> +description: the first LVDS input link for even pixels > >>> + > >>> +oneOf: > >>> + - required: [dual-lvds-odd-pixels] > >>> + - required: [dual-lvds-even-pixels] > >>> + - properties: > >>> + dual-lvds-odd-pixels: false > >>> + dual-lvds-even-pixels: false > >>> + > >>> + port@1: > >>> +$ref: /schemas/graph.yaml#/$defs/port-base > &g
RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
Hi Liu Ying, > -Original Message- > From: Liu Ying > Sent: 29 October 2024 06:17 > Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS > display common properties > > On 10/28/2024, Liu Ying wrote: > > Dual-link LVDS displays receive odd pixels and even pixels separately > > from dual LVDS links. One link receives odd pixels and the other > > receives even pixels. Some of those displays may also use only one > > LVDS link to receive all pixels, being odd and even agnostic. > > Document common properties for those displays by extending LVDS > > display common properties defined in lvds.yaml. > > > > Suggested-by: Dmitry Baryshkov > > Signed-off-by: Liu Ying > > --- > > v4: > > * Squash change for advantech,idk-2121wr.yaml and > > panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml. (Rob) > > * Improve description in lvds-dual-ports.yaml. (Krzysztof) > > > > v3: > > * New patch. (Dmitry) > > > > .../bindings/display/lvds-dual-ports.yaml | 76 +++ > > .../display/panel/advantech,idk-2121wr.yaml | 14 +--- > > .../panel/panel-simple-lvds-dual-ports.yaml | 20 + > > 3 files changed, 78 insertions(+), 32 deletions(-) create mode > > 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > > b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > > new file mode 100644 > > index ..5f7a30640404 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml > > @@ -0,0 +1,76 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Dual-link LVDS Display Common Properties > > + > > +maintainers: > > + - Liu Ying > > + > > +description: | > > + Common properties for LVDS displays with dual LVDS links. Extend > > +LVDS display > > + common properties defined in lvds.yaml. > > + > > + Dual-link LVDS displays receive odd pixels and even pixels > > + separately from the dual LVDS links. One link receives odd pixels > > + and the other receives even pixels. Some of those displays may also > > + use only one LVDS link to receive all pixels, being odd and even > > agnostic. > > + > > +allOf: > > + - $ref: lvds.yaml# > > + > > +properties: > > + ports: > > +$ref: /schemas/graph.yaml#/properties/ports > > + > > +properties: > > + port@0: > > +$ref: /schemas/graph.yaml#/$defs/port-base > > +unevaluatedProperties: false > > +description: the first LVDS input link > > + > > +properties: > > + dual-lvds-odd-pixels: > > +type: boolean > > +description: the first LVDS input link for odd pixels > > + > > + dual-lvds-even-pixels: > > +type: boolean > > +description: the first LVDS input link for even pixels > > + > > +oneOf: > > + - required: [dual-lvds-odd-pixels] > > + - required: [dual-lvds-even-pixels] > > + - properties: > > + dual-lvds-odd-pixels: false > > + dual-lvds-even-pixels: false > > + > > + port@1: > > +$ref: /schemas/graph.yaml#/$defs/port-base > > +unevaluatedProperties: false > > +description: the second LVDS input link > > + > > +properties: > > + dual-lvds-odd-pixels: > > +type: boolean > > +description: the second LVDS input link for odd pixels > > + > > + dual-lvds-even-pixels: > > +type: boolean > > +description: the second LVDS input link for even pixels > > + > > +oneOf: > > + - required: [dual-lvds-odd-pixels] > > + - required: [dual-lvds-even-pixels] > > + - properties: > > + dual-lvds-odd-pixels: false > > + dual-lvds-even-pixels: false > > Hmm, I should require port@0 or port@1. For dual LVDS, you need 3 ports as common use case 2 input ports and 1 outport and all are required properties. Cheers, Biju > Will wait a while for comments and add this in next version. > > --8<-- > anyOf: > - required: > - port@0 > - required: > - port@1 > --8<-- > > > + > > +required: > > + - ports > > + > > +additionalProperties: true > > + > > +... > > [...] > > -- > Regards, > Liu Ying
RE: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
Hi Dmitry, Liu,
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 28 October 2024 10:20
> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
>
> Hi,
>
> On Mon, 28 Oct 2024 at 04:37, Liu Ying wrote:
> >
> > Hi,
> >
> > This patch series aims to add ITE IT6263 LVDS to HDMI converter on
> > i.MX8MP EVK. Combined with LVDS receiver and HDMI 1.4a transmitter,
> > the IT6263 supports LVDS input and HDMI 1.4 output by conversion
> > function. IT6263 product link can be found at [1].
> >
> > Patch 1 is a preparation patch to allow display mode of an existing
> > panel to pass the added mode validation logic in patch 3.
> >
> > Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
> > the next non-panel bridge, that is the IT6263 in this case.
> >
> > Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > against "ldb" clock so that it can filter out unsupported display
> > modes read from EDID.
> >
> > Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as
> > they are supported by IT6263(with LVDS data bit reversed order).
> >
> > Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> >
> > Patch 6 supports getting dual-link LVDS pixel order for the sink side
> > as needed by IT6263 driver.
> >
> > Patch 7 documents jeida-30 and vesa-30 data mappings in
> > lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> >
> > Patch 8 extracts common dual-link LVDS display properties into new
> > lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> >
> > Patch 9 adds DT binding for IT6263.
> >
> > Patch 10 adds IT6263 bridge driver. Only video output is supported.
> >
> > Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > IT6263 populated.
> >
> > Patch 12 enables the IT6263 bridge driver in defconfig.
> >
> > Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
>
> This has pretty complicated structure from the merging point of view.
>
> I propose we take patches 6, 8, 9 (without 30-bit formats, they can be
> dropped while applying), 11, 12
> (?) and 13 through drm-misc in one batch (once DT maintainers review the
> binding parts). This looks
> like a minimal set, having no extra dependencies.
>
> The second set might be 4, 5 + new patch, re-adding 30-bit formats to
> IT6263 binding (no driver changes are necessary). This can go in separately,
> after an Ack from media
> maintainers.
>
> Of course both sets can go together if linux-media maintainers reacts quickly
> and ack merging media-
> formats patch through drm-misc tree.
>
> The rest of the patches don't have such strong dependencies and go in once
> ready / reviewed.
>
> WDYT?
I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
11 may have dependency on 1, 2 and 3 as it is SoC specific.
Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.
Cheers,
Biju
RE: [PATCH v4 10/13] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying, Thanks for the patch. > -Original Message- > From: Liu Ying > Sent: 28 October 2024 02:38 > Subject: [PATCH v4 10/13] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > Add basic HDMI video output support. Currently, only RGB888 output pixel > format is supported. At the > LVDS input side, the driver supports single LVDS link and dual LVDS links > with "jeida-24" LVDS > mapping. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying > Reviewed-by: Biju Das > Acked-by: Maxime Ripard Tested on Renesas RZ/G3E SMARC EVK: Dual LVDS link: 1080p@60 Single LVDS link:720p@60 Tested-by: Biju Das Cheers, Biju > --- > v4: > * Use local variable reset_gpio in probe(). (Biju) > * Move pixel clock rate validation from mode_valid callback to > hdmi_tmds_char_rate_valid callback. (Maxime) > * Document IT6263 video processing throughput constraints by adding comments. > (Maxime) > * Fix LVDS 8-bit color depth macro BIT8. > * Drop 30-bit LVDS data bit order validation(30-bit LVDS data bit order is not > reversed). > * Collect Biju's R-b tag and Maxime's A-b tag. > > v3: > * Use HDMI connector framework. (Maxime) > * Control the missing HDMI_REG_AVI_INFOFRM_CTRL register. > * Validate the maximal HDMI TMDS character rate. (Dmitry) > * Get LVDS data mapping from data-mapping DT property. (Dmitry, Biju) > * Validate 30bit LVDS data bit order by checking data-mirror DT property. > * Use drm_of_lvds_get_dual_link_pixel_order_sink(). (Dmitry) > * Initialize a bridge connector instead of open coding. (Dmitry) > * Add a comment that IT6263 chip has no HPD IRQ support. (Dmitry) > * Use devm_drm_bridge_add() instead of drm_bridge_add(). (Dmitry) > * Fix a minor build warning reported by kernel test robot. > > v2: > * Add AVI inforframe support. (Maxime) > * Add DRM_MODE_CONNECTOR_HDMIA. (Biju) > * Rename it6263_reset() to it6263_hw_reset(). (Biju) > * Check number of LVDS link data lanes. (Biju) > > drivers/gpu/drm/bridge/Kconfig | 11 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ite-it6263.c | 898 > 3 files changed, 910 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index > 609f4d0ac93d..6b4664d91faa 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -90,6 +90,17 @@ config DRM_FSL_LDB > help > Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > > +config DRM_ITE_IT6263 > + tristate "ITE IT6263 LVDS/HDMI bridge" > + depends on OF > + select DRM_DISPLAY_HDMI_STATE_HELPER > + select DRM_DISPLAY_HELPER > + select DRM_BRIDGE_CONNECTOR > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + ITE IT6263 LVDS to HDMI bridge chip driver. > + > config DRM_ITE_IT6505 > tristate "ITE IT6505 DisplayPort bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile > b/drivers/gpu/drm/bridge/Makefile index > 3daf803ce80b..97304b429a53 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > a/drivers/gpu/drm/bridge/ite-it6263.c > b/drivers/gpu/drm/bridge/ite-it6263.c > new file mode 100644 > index ..cbabd4e20d3e > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6263.c > @@ -0,0 +1,898 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2024 NXP > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include #include > + > +#include > +#include > +#include #include > +#include #include > +#include #include #include > + #include > + > +/* > +--- > +-- > + * LVDS registers > + */ > + > +/* LVDS software reset registers */ > +#define LVDS_REG_05 0x05 > +#define REG_SOFT_P_RST BIT(1) > + > +/* LVDS
RE: [PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying, Thanks for the patch. > -Original Message- > From: Liu Ying > Sent: 28 October 2024 02:38 > Subject: [PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS > to HDMI converter > > Document ITE IT6263 LVDS to HDMI converter. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying Reviewed-by: Biju Das Cheers, Biju > --- > v4: > * Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for > port@1. > * Drop "data-mirror: true"(30-bit LVDS data bit order is not reversed). > > v3: > * Reference lvds-dual-ports.yaml. (Dmitry) > * Add data-mapping DT property. (Dmitry, Biju) > * Allow data-mirror. > * Drop ite,lvds-link-num-data-lanes DT property. (Dmitry, Biju) > > v2: > * Document number of LVDS link data lanes. (Biju) > * Simplify ports property by dropping "oneOf". (Rob) > > .../bindings/display/bridge/ite,it6263.yaml | 250 ++ > 1 file changed, 250 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > new file mode 100644 > index ..0a10e10d80ff > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > @@ -0,0 +1,250 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ITE IT6263 LVDS to HDMI converter > + > +maintainers: > + - Liu Ying > + > +description: | > + The IT6263 is a high-performance single-chip De-SSC(De-Spread > +Spectrum) LVDS > + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > +transmitter, > + the IT6263 supports LVDS input and HDMI 1.4 output by conversion function. > + The built-in LVDS receiver can support single-link and dual-link LVDS > +inputs, > + and the built-in HDMI transmitter is fully compliant with HDMI > +1.4a/3D, HDCP > + 1.2 and backward compatible with DVI 1.0 specification. > + > + The IT6263 also encodes and transmits up to 8 channels of I2S digital > + audio, with sampling rate up to 192KHz and sample size up to 24 bits. > + In addition, an S/PDIF input port takes in compressed audio of up to > 192KHz frame rate. > + > + The newly supported High-Bit Rate(HBR) audio by HDMI specifications > + v1.3 is provided by the IT6263 in two interfaces: the four I2S input > + ports or the S/PDIF input port. With both interfaces the highest > + possible HBR frame rate is supported at up to 768KHz. > + > +allOf: > + - $ref: /schemas/display/lvds-dual-ports.yaml# > + > +properties: > + compatible: > +const: ite,it6263 > + > + reg: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > +description: audio master clock > + > + clock-names: > +const: mclk > + > + data-mapping: > +enum: > + - jeida-18 > + - jeida-24 > + - jeida-30 > + - vesa-24 > + - vesa-30 > + > + reset-gpios: > +maxItems: 1 > + > + ivdd-supply: > +description: 1.8V digital logic power > + > + ovdd-supply: > +description: 3.3V I/O pin power > + > + txavcc18-supply: > +description: 1.8V HDMI analog frontend power > + > + txavcc33-supply: > +description: 3.3V HDMI analog frontend power > + > + pvcc1-supply: > +description: 1.8V HDMI frontend core PLL power > + > + pvcc2-supply: > +description: 1.8V HDMI frontend filter PLL power > + > + avcc-supply: > +description: 3.3V LVDS frontend power > + > + anvdd-supply: > +description: 1.8V LVDS frontend analog power > + > + apvdd-supply: > +description: 1.8V LVDS frontend PLL power > + > + "#sound-dai-cells": > +const: 0 > + > + ite,i2s-audio-fifo-sources: > +$ref: /schemas/types.yaml#/definitions/uint32-array > +minItems: 1 > +maxItems: 4 > +items: > + enum: [0, 1, 2, 3] > +description: > + Each array element indicates the pin number of an I2S serial data input > + line which is connected to an audio FIFO, from audio FIFO0 to FIFO3. > + > + ite,rl-channel-swap-audio-sources: > +$ref: /schemas/types.yaml#/definitions/uint32-array > +minItems: 1 > +maxItems: 4 > +uniqueItems: true > +items: > + enum: [0, 1, 2, 3] > +description: > + Each array element indicates an audio source
RE: [PATCH v3 12/15] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying, > -Original Message- > From: dri-devel On Behalf Of Liu > Ying > Sent: 25 October 2024 09:25 > Subject: Re: [PATCH v3 12/15] drm/bridge: Add ITE IT6263 LVDS to HDMI > converter > > On 10/24/2024, Biju Das wrote: > > Hi Liu Ying, > > Hi Biju, > > > > >> -Original Message- > >> From: Liu Ying > >> Sent: Monday, October 21, 2024 7:45 AM > >> Subject: [PATCH v3 12/15] drm/bridge: Add ITE IT6263 LVDS to HDMI > >> converter > >> > >> Add basic HDMI video output support. Currently, only RGB888 output > >> pixel format is supported. At the LVDS input side, the driver > >> supports single LVDS link and dual LVDS links with "jeida-24" LVDS mapping. > >> > >> Product link: > >> https://www.ite.com.tw/en/product/cate1/IT6263 > > > > Just a question, > > > > What is the maximum single link and dual link modes you have tested? > > With single LVDS link on i.MX8MP EVK, the highest pixel clock rate I tested > is 74.25MHz(1280x720@60). > i.MX8MP LVDS Display Bridge(LDB) supports the highest 80MHz pixel clock rate > with single LVDS link. > > With single LVDS link on i.MX8qxp MEK, the highest pixel clock rate I tested > is > 148.5MHz(1920x1080@60). i.MX8qxp LDB supports the highest 150MHz pixel clock > rate with single LVDS > link. > > With dual LVDS links on both i.MX8MP EVK and i.MX8qxp MEK, the highest pixel > clock rate I tested is > 148.5MHz(1920x1080@60). Thanks for the info. > > > > > On Renesas SMARC RZ/G3E platform I have tested with this patch set, > > > > Dual link :1080p@60 > > > > and > > > > Single link:720p@60 > > > > For single link > 720p@60, sometimes I get message > > "it6263 7-004c: failed to wait for video stable" > > I don't see this with i.MX8MP EVK and i.MX8qxp MEK. OK. Maybe MEK supports upto 150MHz pixel clock rate on the SoC side. > > > > > From SoC side, it can support max dot clock of 87MHz for single link. > > > > So just wondering other than reject modes greater than 87MHz from SOC > > side, do we need to limit any thing on bridge device for single link Case? > > Since IT6263 works with 1920x1080@60(148.5MHz pixel clock rate) on i.MX8qxp > MEK by using single LVDS > link, I'm currently fine with the existing clock rate validation against the > maximal 150MHz pixel > clock rate. I agree. Cheers, Biju
RE: [PATCH v3 12/15] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying, > -Original Message- > From: Liu Ying > Sent: Monday, October 21, 2024 7:45 AM > Subject: [PATCH v3 12/15] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > Add basic HDMI video output support. Currently, only RGB888 output pixel > format is supported. At the > LVDS input side, the driver supports single LVDS link and dual LVDS links > with "jeida-24" LVDS > mapping. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 Just a question, What is the maximum single link and dual link modes you have tested? On Renesas SMARC RZ/G3E platform I have tested with this patch set, Dual link :1080p@60 and Single link:720p@60 For single link > 720p@60, sometimes I get message "it6263 7-004c: failed to wait for video stable" >From SoC side, it can support max dot clock of 87MHz for single link. So just wondering other than reject modes greater than 87MHz from SOC side, do we need to limit any thing on bridge device for single link Case? Cheers, Biju > > Signed-off-by: Liu Ying > --- > v3: > * Use HDMI connector framework. (Maxime) > * Control the missing HDMI_REG_AVI_INFOFRM_CTRL register. > * Validate the maximal HDMI TMDS character rate. (Dmitry) > * Get LVDS data mapping from data-mapping DT property. (Dmitry, Biju) > * Validate 30bit LVDS data bit order by checking data-mirror DT property. > * Use drm_of_lvds_get_dual_link_pixel_order_sink(). (Dmitry) > * Initialize a bridge connector instead of open coding. (Dmitry) > * Add a comment that IT6263 chip has no HPD IRQ support. (Dmitry) > * Use devm_drm_bridge_add() instead of drm_bridge_add(). (Dmitry) > * Fix a minor build warning reported by kernel test robot. > > v2: > * Add AVI inforframe support. (Maxime) > * Add DRM_MODE_CONNECTOR_HDMIA. (Biju) > * Rename it6263_reset() to it6263_hw_reset(). (Biju) > * Check number of LVDS link data lanes. (Biju) > > drivers/gpu/drm/bridge/Kconfig | 11 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ite-it6263.c | 906 > 3 files changed, 918 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index > 609f4d0ac93d..6b4664d91faa 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -90,6 +90,17 @@ config DRM_FSL_LDB > help > Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > > +config DRM_ITE_IT6263 > + tristate "ITE IT6263 LVDS/HDMI bridge" > + depends on OF > + select DRM_DISPLAY_HDMI_STATE_HELPER > + select DRM_DISPLAY_HELPER > + select DRM_BRIDGE_CONNECTOR > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + ITE IT6263 LVDS to HDMI bridge chip driver. > + > config DRM_ITE_IT6505 > tristate "ITE IT6505 DisplayPort bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile > b/drivers/gpu/drm/bridge/Makefile index > 3daf803ce80b..97304b429a53 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > a/drivers/gpu/drm/bridge/ite-it6263.c > b/drivers/gpu/drm/bridge/ite-it6263.c > new file mode 100644 > index ..1ad7727742bf > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6263.c > @@ -0,0 +1,906 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2024 NXP > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include #include > + > +#include > +#include > +#include #include > +#include #include > +#include #include #include > + #include > + > +/* > +--- > +-- > + * LVDS registers > + */ > + > +/* LVDS software reset registers */ > +#define LVDS_REG_05 0x05 > +#define REG_SOFT_P_RST BIT(1) > + > +/* LVDS system configuration registers */ > +/* 0x0b */ > +#define LVDS_REG_0B 0x0b > +#define REG_SSC_PCLK_RF BIT(0) > +#define REG_LVDS_IN_SWAPBIT(1) > + > +/* LVDS test pattern gen control registers */ > +/* 0x2c */ > +#define LVDS_REG_2C 0x2c > +#define REG_COL_DEP GENMASK(1, 0) > +#define BIT8FIELD_PREP(REG_COL_DEP, 2) > +#define OUT_MAP BIT(4) > +#define JEIDA 0 > +#define REG_DESSC_ENB
[PATCH v2 0/2] Improvements/fixes on the DPI interface
This patch series aims to add fixes/improvements based on the latest RZ/G2UL hardware manual As per Table 33.4 Clock List, the maximum dot clock for the DPI interface is 83.5 MHz. so, reject modes higher than 83.5 MHz. Also drop DPI_OE macro as the bit definition is removed from the latest RZ/G2UL and RZ/G2L hardware manual. Changes in v2: * Added as a patch series as the patches fix the same driver * Added Fixes tag for patch#1 * Moved .mode_valid from crtc to encoder as the new state is not available in crtc and instead, we could check renc->output for .mode_valid() function of drm_encoder. * Dropped rzg2l_du_crtc_atomic_check(). Biju Das (2): drm: renesas: rz-du: Drop DU_MCR0_DPI_OE macro drm: renesas: rz-du: rzg2l_du_encoder: Fix max dot clock for DPI drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +--- .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 18 ++ 2 files changed, 19 insertions(+), 7 deletions(-) -- 2.43.0
[PATCH v2 1/2] drm: renesas: rz-du: Drop DU_MCR0_DPI_OE macro
The DPI_OE bit is removed from the latest RZ/G2UL and RZ/G2L hardware
manual. So, drop this macro.
Fixes: b330f1480172 ("drm: renesas: rz-du: Add RZ/G2UL DU Support")
Signed-off-by: Biju Das
---
v1->v2:
* Added Fixes tag.
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index c4c1474d487e..6e7aac6219be 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,7 +28,6 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
-#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -217,14 +216,9 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
- struct rzg2l_du_crtc_state *rstate =
to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
- u32 val = DU_MCR0_DI_EN;
- if (rstate->outputs & BIT(RZG2L_DU_OUTPUT_DPAD0))
- val |= DU_MCR0_DPI_OE;
-
- writel(start ? val : 0, rcdu->mmio + DU_MCR0);
+ writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
--
2.43.0
[PATCH v2 2/2] drm: renesas: rz-du: rzg2l_du_encoder: Fix max dot clock for DPI
As per the RZ/G2UL hardware manual Table 33.4 Clock List, the maximum
dot clock for the DPI interface is 83.5 MHz. Add mode_valid callback
to reject modes greater than 83.5 MHz.
Suggested-by: Laurent Pinchart
Signed-off-by: Biju Das
---
Changes in v2:
* Moved .mode_valid from crtc to encoder as the new state is not
available in crtc and instead, we could check renc->output for
.mode_valid() function of drm_encoder.
* Dropped rzg2l_du_crtc_atomic_check().
---
.../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
index 339cbaaea0b5..564ab4cb3d37 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,22 @@
static const struct drm_encoder_funcs rzg2l_du_encoder_funcs = {
};
+static enum drm_mode_status
+rzg2l_du_encoder_mode_valid(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode)
+{
+ struct rzg2l_du_encoder *renc = to_rzg2l_encoder(encoder);
+
+ if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static const struct drm_encoder_helper_funcs rzg2l_du_encoder_helper_funcs = {
+ .mode_valid = rzg2l_du_encoder_mode_valid,
+};
+
int rzg2l_du_encoder_init(struct rzg2l_du_device *rcdu,
enum rzg2l_du_output output,
struct device_node *enc_node)
@@ -48,6 +65,7 @@ int rzg2l_du_encoder_init(struct rzg2l_du_device *rcdu,
return PTR_ERR(renc);
renc->output = output;
+ drm_encoder_helper_add(&renc->base, &rzg2l_du_encoder_helper_funcs);
/* Attach the bridge to the encoder. */
ret = drm_bridge_attach(&renc->base, bridge, NULL,
--
2.43.0
RE: [PATCH] drm: renesas: rz-du: rzg2l_du_crtc: Fix max dot clock for DPI
Hi Laurent, I missed your response. Sorry for that. > From: Laurent Pinchart > Date: Mon, Oct 7, 2024 at 7:34 PM > Subject: Re: [PATCH] drm: renesas: rz-du: rzg2l_du_crtc: Fix max dot clock > for DPI > > > Hi Biju, > > Thank you for the patch. > > On Sat, Oct 05, 2024 at 04:37:31PM +0100, Biju Das wrote: > > As per the RZ/G2UL hardware manual Table 33.4 Clock List, the maximum > > dot clock for the DPI interface is 83.5 MHz. Add mode_valid callback > > to reject modes greater than 83.5 MHz. > > > > Signed-off-by: Biju Das > > --- > > Before applying the patch: > > root@smarc-rzg2ul:~# modetest -M rzg2l-du > > Encoders: > > id crtctypepossible crtcs possible clones > > 37 36 none0x0001 0x0001 > > > > Connectors: > > id encoder status namesize (mm) modes > > encoders > > 38 37 connected HDMI-A-1520x320 30 37 > > modes: > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) > > #0 1920x1080 59.72 1920 1968 2000 2080 1080 1082 1087 138000 flags: > > phsync, nvsync; type: > preferred, driver > > #1 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: > > phsync, pvsync; type: > driver > > #2 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: > > phsync, pvsync; type: > driver > > #3 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: > > phsync, pvsync; type: > driver > > #4 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: > > phsync, pvsync; type: > driver > > #5 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: > > phsync, pvsync; type: > driver > > #6 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: > > phsync, pvsync; type: driver > > #7 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: > > phsync, pvsync; type: userdef, > driver > > #8 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags: > > phsync, pvsync; type: driver > > #9 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: > > phsync, pvsync; type: driver > > ... > > After applying the patch: > > root@smarc-rzg2ul:~# modetest -M rzg2l-du > > Encoders: > > id crtctypepossible crtcs possible clones > > 37 36 none0x0001 0x0001 > > > > Connectors: > > id encoder status namesize (mm) modes > > encoders > > 38 37 connected HDMI-A-1520x320 23 37 > > modes: > > index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) > > #0 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: > > phsync, pvsync; type: driver > > #1 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags: > > phsync, pvsync; type: driver > > #2 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: > > phsync, pvsync; type: driver > > #3 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: > > phsync, pvsync; type: driver > > #4 1024x768 75.03 1024 1040 1136 1312 768 769 772 800 78750 flags: > > phsync, pvsync; type: driver > > #5 1024x768 70.07 1024 1048 1184 1328 768 771 777 806 75000 flags: > > nhsync, nvsync; type: driver > > #6 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: > > nhsync, nvsync; type: driver > > #7 1080x607 59.97 1080 1120 1232 1384 607 608 611 629 52210 flags: > > nhsync, pvsync; type: > > #8 832x624 74.55 832 864 928 1152 624 625 628 667 57284 flags: nhsync, > > nvsync; type: driver > > #9 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync, > > pvsync; type: driver > > ... > > --- > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 43 > > +++ > > 1 file changed, 43 insertions(+) > > > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c > > index 6e7aac6219be..650a2e40caf5 100644 > > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c > > @@ -248,6 +248,32 @@ static void rzg2l_du_crtc_stop(struct rzg2l_du_crtc > > *rcrtc) > > * CRTC Functions > > */ > > > > +static int rzg2l_du_crtc_atomic_check(struct drm_crtc *crtc, > > + struct drm_atomic_state
RE: [PATCH v3 12/15] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
define HDMI_REG_AVI_DB12 0x164
> +#define HDMI_REG_AVI_DB130x165
> +
> +#define HDMI_AVI_DB_CHUNK1_SIZE (HDMI_REG_AVI_DB5 -
> HDMI_REG_AVI_DB1 + 1)
> +#define HDMI_AVI_DB_CHUNK2_SIZE (HDMI_REG_AVI_DB13 -
> HDMI_REG_AVI_DB6 + 1)
> +
> +#define MAX_PIXEL_CLOCK_KHZ 15
> +#define HIGH_PIXEL_CLOCK_KHZ 8
> +#define MAX_HDMI_TMDS_CHAR_RATE_HZ 22500
> +
> +struct it6263 {
> + struct device *dev;
> + struct i2c_client *hdmi_i2c;
> + struct i2c_client *lvds_i2c;
> + struct regmap *hdmi_regmap;
> + struct regmap *lvds_regmap;
> + struct drm_bridge bridge;
> + struct drm_bridge *next_bridge;
> + struct gpio_desc *reset_gpio;
This can be dropped, since it is used only in probe().
With that fixed,
Reviewed-by: Biju Das
Cheers,
Biju
> + int lvds_data_mapping;
> + bool lvds_dual_link;
> + bool lvds_link12_swap;
> +};
> +
> +static inline struct it6263 *bridge_to_it6263(struct drm_bridge
> +*bridge) {
> + return container_of(bridge, struct it6263, bridge); }
> +
> +static bool it6263_hdmi_writeable_reg(struct device *dev, unsigned int
> +reg) {
> + switch (reg) {
> + case HDMI_REG_SW_RST:
> + case HDMI_REG_BANK_CTRL:
> + case HDMI_REG_DDC_MASTER_CTRL:
> + case HDMI_REG_DDC_HEADER:
> + case HDMI_REG_DDC_REQOFF:
> + case HDMI_REG_DDC_REQCOUNT:
> + case HDMI_REG_DDC_EDIDSEG:
> + case HDMI_REG_DDC_CMD:
> + case HDMI_REG_LVDS_PORT:
> + case HDMI_REG_LVDS_PORT_EN:
> + case HDMI_REG_AFE_DRV_CTRL:
> + case HDMI_REG_AFE_XP_CTRL:
> + case HDMI_REG_AFE_ISW_CTRL:
> + case HDMI_REG_AFE_IP_CTRL:
> + case HDMI_REG_INPUT_MODE:
> + case HDMI_REG_HDMI_MODE:
> + case HDMI_REG_GCP:
> + case HDMI_REG_PKT_GENERAL_CTRL:
> + case HDMI_REG_AVI_INFOFRM_CTRL:
> + case HDMI_REG_AVI_DB1:
> + case HDMI_REG_AVI_DB2:
> + case HDMI_REG_AVI_DB3:
> + case HDMI_REG_AVI_DB4:
> + case HDMI_REG_AVI_DB5:
> + case HDMI_REG_AVI_CSUM:
> + case HDMI_REG_AVI_DB6:
> + case HDMI_REG_AVI_DB7:
> + case HDMI_REG_AVI_DB8:
> + case HDMI_REG_AVI_DB9:
> + case HDMI_REG_AVI_DB10:
> + case HDMI_REG_AVI_DB11:
> + case HDMI_REG_AVI_DB12:
> + case HDMI_REG_AVI_DB13:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool it6263_hdmi_readable_reg(struct device *dev, unsigned int
> +reg) {
> + if (it6263_hdmi_writeable_reg(dev, reg))
> + return true;
> +
> + switch (reg) {
> + case HDMI_REG_SYS_STATUS:
> + case HDMI_REG_DDC_STATUS:
> + case HDMI_REG_DDC_READFIFO:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool it6263_hdmi_volatile_reg(struct device *dev, unsigned int
> +reg) {
> + switch (reg) {
> + case HDMI_REG_SW_RST:
> + case HDMI_REG_SYS_STATUS:
> + case HDMI_REG_DDC_STATUS:
> + case HDMI_REG_DDC_READFIFO:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static const struct regmap_range_cfg it6263_hdmi_range_cfg = {
> + .range_min = 0x00,
> + .range_max = HDMI_REG_AVI_DB13,
> + .selector_reg = HDMI_REG_BANK_CTRL,
> + .selector_mask = REG_BANK_SEL,
> + .selector_shift = 0,
> + .window_start = 0x00,
> + .window_len = 0x100,
> +};
> +
> +static const struct regmap_config it6263_hdmi_regmap_config = {
> + .name = "it6263-hdmi",
> + .reg_bits = 8,
> + .val_bits = 8,
> + .writeable_reg = it6263_hdmi_writeable_reg,
> + .readable_reg = it6263_hdmi_readable_reg,
> + .volatile_reg = it6263_hdmi_volatile_reg,
> + .max_register = HDMI_REG_AVI_DB13,
> + .ranges = &it6263_hdmi_range_cfg,
> + .num_ranges = 1,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static bool it6263_lvds_writeable_reg(struct device *dev, unsigned int
> +reg) {
> + switch (reg) {
> + case LVDS_REG_05:
> + case LVDS_REG_0B:
> + case LVDS_REG_2C:
> + case LVDS_REG_3C:
> + case LVDS_REG_3F:
> + case LVDS_REG_47:
> + case LVDS_REG_48:
> + case LVDS_REG_4F:
> + case LVDS_REG_52:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool it6263_lvds_readable_reg(struct device *dev, unsigned int
> +reg) {
> + return it6263_lvds_writeable_reg(dev, reg); }
> +
> +static bool it6263_lvds_volatile_reg(struct device *dev, unsigned int
> +reg) {
RE: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
Hi Liu Ying,
> -Original Message-
> From: Liu Ying
> Sent: Friday, October 18, 2024 8:38 AM
> To: Biju Das ; devicet...@vger.kernel.org;
> i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
> dri-devel@lists.freedesktop.org
> Cc: r...@kernel.org; krzk...@kernel.org; conor...@kernel.org;
> shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> andrzej.ha...@intel.com;
> neil.armstr...@linaro.org; rf...@kernel.org; laurent.pinchart
> ;
> jo...@kwiboo.se; jernej.skra...@gmail.com; maarten.lankho...@linux.intel.com;
> mrip...@kernel.org;
> tzimmerm...@suse.de; airl...@gmail.com; sim...@ffwll.ch; ma...@denx.de;
> ste...@agner.ch;
> dmitry.barysh...@linaro.org
> Subject: Re: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
>
> On 10/18/2024, Biju Das wrote:
> > Hi Liu Ying,
>
> Hi Biju,
>
> >
> > Thanks for the patch.
>
> Thanks for your review.
>
> >
> >> -Original Message-
> >> From: linux-arm-kernel
> >> On Behalf Of Liu Ying
> >> Sent: Friday, October 18, 2024 7:48 AM
> >> Subject: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
> >>
> >> Initialize a connector by calling drm_bridge_connector_init() for
> >> each encoder so that down stream bridge drivers don't need to create
> >> connectors any more.
> >>
> >> Signed-off-by: Liu Ying
> >> ---
> >> drivers/gpu/drm/mxsfb/Kconfig | 1 +
> >> drivers/gpu/drm/mxsfb/lcdif_drv.c | 17 -
> >> 2 files changed, 17 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/mxsfb/Kconfig
> >> b/drivers/gpu/drm/mxsfb/Kconfig index
> >> 264e74f45554..06c95e556380 100644
> >> --- a/drivers/gpu/drm/mxsfb/Kconfig
> >> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> >> @@ -27,6 +27,7 @@ config DRM_IMX_LCDIF
> >>depends on DRM && OF
> >>depends on COMMON_CLK
> >>depends on ARCH_MXC || COMPILE_TEST
> >> + select DRM_BRIDGE_CONNECTOR
> >>select DRM_CLIENT_SELECTION
> >>select DRM_MXS
> >>select DRM_KMS_HELPER
> >> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> index 58ccad9c425d..d4521da6675e 100644
> >> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> @@ -16,7 +16,9 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -56,6 +58,7 @@ static int lcdif_attach_bridge(struct lcdif_drm_private
> >> *lcdif)
> >>struct device_node *remote;
> >>struct of_endpoint of_ep;
> >>struct drm_encoder *encoder;
> >> + struct drm_connector *connector;
> >>
> >>remote = of_graph_get_remote_port_parent(ep);
> >>if (!of_device_is_available(remote)) { @@ -97,13 +100,25 @@
> >> static
> >> int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> >>return ret;
> >>}
> >>
> >> - ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> >> + ret = drm_bridge_attach(encoder, bridge, NULL,
> >> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >>if (ret) {
> >>of_node_put(ep);
> >>return dev_err_probe(dev, ret,
> >> "Failed to attach bridge for
> >> endpoint%u\n",
> >> of_ep.id);
> >>}
> >> +
> >> + connector = drm_bridge_connector_init(lcdif->drm, encoder);
> >> + if (IS_ERR(connector)) {
> >> + ret = PTR_ERR(connector);
> >> + dev_err(dev, "Failed to initialize bridge connector:
> >> %d\n",
> >> + ret);
> >> + of_node_put(ep);
> >> + return ret;
> >
> > Maybe same error path style like above??
> > of_node_put(ep);
> > return dev_err_probe(dev, PTR_ERR(connector),"Failed to
> > initialize
> > bridge connector");
>
> I thought about that and decided not to use dev_err_probe() because I don't
> think
> drm_bridge_connector_init() may return -EPROBE_DEFER, no?
Yes, you are correct.
Reviewed-by: Biju Das
Cheers,
Biju
>
> >
> > Cheers,
> > Biju
> >
> >> + }
> >> +
> >> + drm_connector_attach_encoder(connector, encoder);
> >>}
> >>
> >>return 0;
> >> --
> >> 2.34.1
> >>
> >
>
> --
> Regards,
> Liu Ying
RE: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
Hi Liu Ying,
Thanks for the patch.
> -Original Message-
> From: linux-arm-kernel On
> Behalf Of Liu Ying
> Sent: Friday, October 18, 2024 7:48 AM
> Subject: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
>
> Initialize a connector by calling drm_bridge_connector_init() for each
> encoder so that down stream
> bridge drivers don't need to create connectors any more.
>
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/mxsfb/Kconfig | 1 +
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 17 -
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index
> 264e74f45554..06c95e556380 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -27,6 +27,7 @@ config DRM_IMX_LCDIF
> depends on DRM && OF
> depends on COMMON_CLK
> depends on ARCH_MXC || COMPILE_TEST
> + select DRM_BRIDGE_CONNECTOR
> select DRM_CLIENT_SELECTION
> select DRM_MXS
> select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> index 58ccad9c425d..d4521da6675e 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -16,7 +16,9 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -56,6 +58,7 @@ static int lcdif_attach_bridge(struct lcdif_drm_private
> *lcdif)
> struct device_node *remote;
> struct of_endpoint of_ep;
> struct drm_encoder *encoder;
> + struct drm_connector *connector;
>
> remote = of_graph_get_remote_port_parent(ep);
> if (!of_device_is_available(remote)) { @@ -97,13 +100,25 @@
> static int
> lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> return ret;
> }
>
> - ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> + ret = drm_bridge_attach(encoder, bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret) {
> of_node_put(ep);
> return dev_err_probe(dev, ret,
>"Failed to attach bridge for
> endpoint%u\n",
>of_ep.id);
> }
> +
> + connector = drm_bridge_connector_init(lcdif->drm, encoder);
> + if (IS_ERR(connector)) {
> + ret = PTR_ERR(connector);
> + dev_err(dev, "Failed to initialize bridge connector:
> %d\n",
> + ret);
> + of_node_put(ep);
> + return ret;
Maybe same error path style like above??
of_node_put(ep);
return dev_err_probe(dev, PTR_ERR(connector),"Failed to
initialize bridge connector");
Cheers,
Biju
> + }
> +
> + drm_connector_attach_encoder(connector, encoder);
> }
>
> return 0;
> --
> 2.34.1
>
RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Dmitry, > -Original Message- > From: Dmitry Baryshkov > Sent: Monday, October 14, 2024 12:16 PM > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS > to HDMI converter > > On Mon, Oct 14, 2024 at 08:09:44AM +, Biju Das wrote: > > Hi Dmitry, > > > > > -Original Message- > > > From: Dmitry Baryshkov > > > Sent: Monday, October 14, 2024 9:04 AM > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE > > > IT6263 LVDS to HDMI converter > > > > > > On Mon, Oct 14, 2024 at 07:39:16AM +, Biju Das wrote: > > > > Hi Liu and Dmitry, > > > > > > > > > -Original Message- > > > > > From: Liu Ying > > > > > Sent: Monday, October 14, 2024 6:34 AM > > > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add > > > > > ITE > > > > > IT6263 LVDS to HDMI converter > > > > > > > > > > On 10/14/2024, Dmitry Baryshkov wrote: > > > > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote: > > > > > >> On 10/12/2024, Dmitry Baryshkov wrote: > > > > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote: > > > > > >>>> Document ITE IT6263 LVDS to HDMI converter. > > > > > >>>> > > > > > >>>> Product link: > > > > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263 > > > > > >>>> > > > > > >>>> Signed-off-by: Liu Ying > > > > > >>>> --- > > > > > >>>> v2: > > > > > >>>> * Document number of LVDS link data lanes. (Biju) > > > > > >>>> * Simplify ports property by dropping "oneOf". (Rob) > > > > > >>>> > > > > > >>>> .../bindings/display/bridge/ite,it6263.yaml | 276 > > > > > >>>> ++ > > > > > >>>> 1 file changed, 276 insertions(+) create mode 100644 > > > > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263 > > > > > >>>> .yam > > > > > >>>> l > > > > > >>>> > > > > > >>>> diff --git > > > > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it62 > > > > > >>>> 63.y > > > > > >>>> aml > > > > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it62 > > > > > >>>> 63.y > > > > > >>>> aml > > > > > >>>> new file mode 100644 > > > > > >>>> index ..bc2bbec07623 > > > > > >>>> --- /dev/null > > > > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite, > > > > > >>>> +++ it62 > > > > > >>>> +++ 63.y > > > > > >>>> +++ aml > > > > > >>>> @@ -0,0 +1,276 @@ > > > > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > >>>> +%YAML > > > > > >>>> +1.2 > > > > > >>>> +--- > > > > > >>>> +$id: > > > > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.ya > > > > > >>>> +ml# > > > > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > >>>> + > > > > > >>>> +title: ITE IT6263 LVDS to HDMI converter > > > > > >>>> + > > > > > >>>> +maintainers: > > > > > >>>> + - Liu Ying > > > > > >>>> + > > > > > >>>> +description: | > > > > > >>>> + The IT6263 is a high-performance single-chip > > > > > >>>> +De-SSC(De-Spread > > > > > >>>> +Spectrum) LVDS > > > > > >>>> + to HDMI converter. Combined with LVDS receiver and HDMI > > > > > >>>> +1.4a transmitter, > > > > > >>>> + the IT6263 supports LVDS input and HDMI 1.4 output by > > > > > >>>
RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Liu Ying > Sent: Monday, October 14, 2024 6:34 AM > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS > to HDMI converter > > On 10/14/2024, Dmitry Baryshkov wrote: > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote: > >> On 10/12/2024, Dmitry Baryshkov wrote: > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote: > Document ITE IT6263 LVDS to HDMI converter. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying > --- > v2: > * Document number of LVDS link data lanes. (Biju) > * Simplify ports property by dropping "oneOf". (Rob) > > .../bindings/display/bridge/ite,it6263.yaml | 276 ++ > 1 file changed, 276 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > diff --git > a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > new file mode 100644 > index ..bc2bbec07623 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > +++ aml > @@ -0,0 +1,276 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > +1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ITE IT6263 LVDS to HDMI converter > + > +maintainers: > + - Liu Ying > + > +description: | > + The IT6263 is a high-performance single-chip De-SSC(De-Spread > +Spectrum) LVDS > + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > +transmitter, > + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > function. > + The built-in LVDS receiver can support single-link and dual-link > +LVDS inputs, > + and the built-in HDMI transmitter is fully compliant with HDMI > +1.4a/3D, HDCP > + 1.2 and backward compatible with DVI 1.0 specification. > + > + The IT6263 also encodes and transmits up to 8 channels of I2S > + digital audio, with sampling rate up to 192KHz and sample size > + up to 24 bits. In addition, an S/PDIF input port takes in compressed > audio of up to 192KHz > frame rate. > + > + The newly supported High-Bit Rate(HBR) audio by HDMI > + specifications v1.3 is provided by the IT6263 in two interfaces: > + the four I2S input ports or the S/PDIF input port. With both > + interfaces the highest possible HBR frame rate is supported at up to > 768KHz. > + > +properties: > >>> > >>> No LVDS data-mapping support? > >> > >> It is enough to document number of LVDS link data lanes because OS > >> should be able to determine the data-mapping by looking at the number > >> and the data-mapping capability of the other side of the LVDS link. > > > > From what I can see, data-mapping is specified on the consumer sink > > side of the LVDS link. This means it should go to the bridge's device node. > > Then, I won't define data-lanes, because data-mapping implies it, e.g., > jeida-24 implies data lanes > 0/1/2/3, see lvds-data-mapping.yaml. > > Please let me know which one you prefer. For consistency, maybe use data-mapping. See [1] [1] https://elixir.bootlin.com/linux/v6.0-rc4/source/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml#L26 Cheers, Biju > > > > >> > >>> > + compatible: > +const: ite,it6263 > + > + reg: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > +description: audio master clock > + > + clock-names: > +const: mclk > + > + reset-gpios: > +maxItems: 1 > + > + ivdd-supply: > +description: 1.8V digital logic power > + > + ovdd-supply: > +description: 3.3V I/O pin power > + > + txavcc18-supply: > +description: 1.8V HDMI analog frontend power > + > + txavcc33-supply: > +description: 3.3V HDMI analog frontend power > + > + pvcc1-supply: > +description: 1.8V HDMI frontend core PLL power > + > + pvcc2-supply: > +description: 1.8V HDMI frontend filter PLL power > + > + avcc-supply: > +description: 3.3V LVDS frontend power > + > + anvdd-supply: > +description: 1.8V LVDS frontend analog power > + > + apvdd-supply: > +description: 1.8V LVDS frontend PLL power > + > + "#sound-dai-cells": > +const: 0 > + > + ite,lvds-link-num-data-lanes: > +$ref: /schemas/types.yaml#/definitions/uint8 > +enum: [3, 4, 5] > +des
RE: [PATCH v2 6/9] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying,
> -Original Message-
> From: Liu Ying
> Sent: Monday, October 14, 2024 8:18 AM
> Subject: Re: [PATCH v2 6/9] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
>
> On 10/14/2024, Dmitry Baryshkov wrote:
> > On Sat, Oct 12, 2024 at 03:35:40PM +0800, Liu Ying wrote:
> >> Add basic HDMI video output support. Currently, only RGB888 output
> >> pixel format is supported. At the LVDS input side, the driver
> >> supports single LVDS link and dual LVDS links with "jeida-24" LVDS
> >> mapping.
> >>
> >> Product link:
> >> https://www.ite.com.tw/en/product/cate1/IT6263
> >>
> >> Signed-off-by: Liu Ying
> >> ---
> >> v2:
> >> * Add AVI inforframe support. (Maxime)
> >> * Add DRM_MODE_CONNECTOR_HDMIA. (Biju)
> >> * Rename it6263_reset() to it6263_hw_reset(). (Biju)
> >> * Check number of LVDS link data lanes. (Biju)
> >>
> >> drivers/gpu/drm/bridge/Kconfig | 8 +
> >> drivers/gpu/drm/bridge/Makefile | 1 +
> >> drivers/gpu/drm/bridge/ite-it6263.c | 919
> >>
> >> 3 files changed, 928 insertions(+)
> >> create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c
> >>
> >
> > [...]
> >
> >> +static int it6263_parse_dt(struct it6263 *it) {
> >> + struct device *dev = it->dev;
> >> + struct device_node *port0, *port1;
> >> + int ret;
> >> +
> >> + ret = of_property_read_u8(dev->of_node, "ite,lvds-link-num-data-lanes",
> >> +&it->lvds_link_num_dlanes);
> >> + if (ret) {
> >> + dev_err(dev, "failed to get LVDS link number of data lanes:
> >> %d\n",
> >> + ret);
> >> + return ret;
> >> + }
> >> +
> >> + it->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 2, 0);
> >> + if (IS_ERR(it->next_bridge))
> >> + return dev_err_probe(dev, PTR_ERR(it->next_bridge),
> >> + "failed to get next bridge\n");
> >> +
> >> + port0 = of_graph_get_port_by_id(dev->of_node, 0);
> >> + port1 = of_graph_get_port_by_id(dev->of_node, 1);
> >> + if (port0 && port1) {
> >> + if (of_property_read_bool(port0, "dual-lvds-even-pixels") &&
> >> + of_property_read_bool(port1, "dual-lvds-odd-pixels")) {
> >> + it->lvds_dual_link = true;
> >> + it->lvds_link12_swap = true;
> >> + } else if (of_property_read_bool(port0, "dual-lvds-odd-pixels")
> >> &&
> >> + of_property_read_bool(port1,
> >> "dual-lvds-even-pixels")) {
> >> + it->lvds_dual_link = true;
> >> + }
> >> +
> >> + if (!it->lvds_dual_link) {
> >> + dev_err(dev,
> >> + "failed to get LVDS dual link pixel order\n");
> >> + ret = -EINVAL;
> >> + }
> >
> > Please use drm_of_lvds_get_dual_link_pixel_order(), it validates that
> > the DT definition is sound: one port for odd pixels, one port for even
> > pixels.
>
> It cannot be used, because it get the pixel order for the LVDS source not
> sink. IT6263 is the LVDS
> sink.
>
> * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
> * @port1: First DT port node of the Dual-link LVDS source
> * @port2: Second DT port node of the Dual-link LVDS source
Can't you use drm_of_lvds_get_dual_link_pixel_order() from host for the same
use case. See [1]?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c?h=next-20241011
lvds_bridge0: lvds-to-hdmi-bridge@4c {
compatible = "ite,it6263";
reg = <0x4c>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dual-lvds-odd-pixels;
lvds0_in0: endpoint@0 {
remote-endpoint = <&lvds0_out>;
};
};
port@1 {
reg = <1>;
dual-lvds-even-pixels;
lvds0_in1: endpoint@1 {
remote-endpoint = <&lvds1_out>;
};
};
port@2 {
reg = <2>;
it6263_out: endpoint@2 {
remote-endpoint =
<&lvds_to_hdmi_con_out>;
};
};
};
};
};
Cheers,
Biju
>
> >
> >> + } else if (port1) {
> >> + ret = -EINVAL;
> >> + dev_err(dev, "single input LVDS port1 is not supported\n");
> >> + } else if (!port0) {
> >> + ret = -EINVAL;
> >> + dev_err(dev, "no input LVDS port\n");
> >> + }
> >> +
> >> + of_node_put(port0);
> >> + of
RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Dmitry, > -Original Message- > From: Dmitry Baryshkov > Sent: Monday, October 14, 2024 9:04 AM > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS > to HDMI converter > > On Mon, Oct 14, 2024 at 07:39:16AM +, Biju Das wrote: > > Hi Liu and Dmitry, > > > > > -Original Message- > > > From: Liu Ying > > > Sent: Monday, October 14, 2024 6:34 AM > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE > > > IT6263 LVDS to HDMI converter > > > > > > On 10/14/2024, Dmitry Baryshkov wrote: > > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote: > > > >> On 10/12/2024, Dmitry Baryshkov wrote: > > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote: > > > >>>> Document ITE IT6263 LVDS to HDMI converter. > > > >>>> > > > >>>> Product link: > > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263 > > > >>>> > > > >>>> Signed-off-by: Liu Ying > > > >>>> --- > > > >>>> v2: > > > >>>> * Document number of LVDS link data lanes. (Biju) > > > >>>> * Simplify ports property by dropping "oneOf". (Rob) > > > >>>> > > > >>>> .../bindings/display/bridge/ite,it6263.yaml | 276 > > > >>>> ++ > > > >>>> 1 file changed, 276 insertions(+) create mode 100644 > > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yam > > > >>>> l > > > >>>> > > > >>>> diff --git > > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > > > >>>> aml > > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > > > >>>> aml > > > >>>> new file mode 100644 > > > >>>> index ..bc2bbec07623 > > > >>>> --- /dev/null > > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it62 > > > >>>> +++ 63.y > > > >>>> +++ aml > > > >>>> @@ -0,0 +1,276 @@ > > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > >>>> +%YAML > > > >>>> +1.2 > > > >>>> +--- > > > >>>> +$id: > > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > >>>> + > > > >>>> +title: ITE IT6263 LVDS to HDMI converter > > > >>>> + > > > >>>> +maintainers: > > > >>>> + - Liu Ying > > > >>>> + > > > >>>> +description: | > > > >>>> + The IT6263 is a high-performance single-chip > > > >>>> +De-SSC(De-Spread > > > >>>> +Spectrum) LVDS > > > >>>> + to HDMI converter. Combined with LVDS receiver and HDMI > > > >>>> +1.4a transmitter, > > > >>>> + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > > > >>>> function. > > > >>>> + The built-in LVDS receiver can support single-link and > > > >>>> +dual-link LVDS inputs, > > > >>>> + and the built-in HDMI transmitter is fully compliant with > > > >>>> +HDMI 1.4a/3D, HDCP > > > >>>> + 1.2 and backward compatible with DVI 1.0 specification. > > > >>>> + > > > >>>> + The IT6263 also encodes and transmits up to 8 channels of > > > >>>> + I2S digital audio, with sampling rate up to 192KHz and > > > >>>> + sample size up to 24 bits. In addition, an S/PDIF input port > > > >>>> + takes in compressed audio of up to 192KHz > > > frame rate. > > > >>>> + > > > >>>> + The newly supported High-Bit Rate(HBR) audio by HDMI > > > >>>> + specifications v1.3 is provided by the IT6263 in two interfaces: > > > >>>> + the four I2S input ports or the S/PDIF input port. With > > > >>>> + both interfaces the highest possible HBR frame rate is supported > &g
RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> -Original Message- > From: Biju Das > Sent: Monday, October 14, 2024 8:39 AM > To: Liu Ying ; Dmitry Baryshkov > > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; > linux-ker...@vger.kernel.org; > i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; > andrzej.ha...@intel.com; > neil.armstr...@linaro.org; rf...@kernel.org; laurent.pinchart > ; > jo...@kwiboo.se; jernej.skra...@gmail.com; airl...@gmail.com; sim...@ffwll.ch; > maarten.lankho...@linux.intel.com; mrip...@kernel.org; tzimmerm...@suse.de; > r...@kernel.org; > krzk...@kernel.org; conor...@kernel.org; shawn...@kernel.org; > s.ha...@pengutronix.de; > ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com; > w...@kernel.org; > quic_bjora...@quicinc.com; geert+rene...@glider.be; a...@arndb.de; > nfrapr...@collabora.com; > o.rem...@pengutronix.de; y.m...@phytec.de; ma...@denx.de; > isaac.sc...@ideasonboard.com > Subject: RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS > to HDMI converter > > Hi Liu and Dmitry, > > > -Original Message- > > From: Liu Ying > > Sent: Monday, October 14, 2024 6:34 AM > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE > > IT6263 LVDS to HDMI converter > > > > On 10/14/2024, Dmitry Baryshkov wrote: > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote: > > >> On 10/12/2024, Dmitry Baryshkov wrote: > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote: > > >>>> Document ITE IT6263 LVDS to HDMI converter. > > >>>> > > >>>> Product link: > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263 > > >>>> > > >>>> Signed-off-by: Liu Ying > > >>>> --- > > >>>> v2: > > >>>> * Document number of LVDS link data lanes. (Biju) > > >>>> * Simplify ports property by dropping "oneOf". (Rob) > > >>>> > > >>>> .../bindings/display/bridge/ite,it6263.yaml | 276 ++ > > >>>> 1 file changed, 276 insertions(+) create mode 100644 > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > >>>> > > >>>> diff --git > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam > > >>>> l > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam > > >>>> l > > >>>> new file mode 100644 > > >>>> index ..bc2bbec07623 > > >>>> --- /dev/null > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263 > > >>>> +++ .y > > >>>> +++ aml > > >>>> @@ -0,0 +1,276 @@ > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > > >>>> +1.2 > > >>>> +--- > > >>>> +$id: > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > >>>> + > > >>>> +title: ITE IT6263 LVDS to HDMI converter > > >>>> + > > >>>> +maintainers: > > >>>> + - Liu Ying > > >>>> + > > >>>> +description: | > > >>>> + The IT6263 is a high-performance single-chip De-SSC(De-Spread > > >>>> +Spectrum) LVDS > > >>>> + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > > >>>> +transmitter, > > >>>> + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > > >>>> function. > > >>>> + The built-in LVDS receiver can support single-link and > > >>>> +dual-link LVDS inputs, > > >>>> + and the built-in HDMI transmitter is fully compliant with HDMI > > >>>> +1.4a/3D, HDCP > > >>>> + 1.2 and backward compatible with DVI 1.0 specification. > > >>>> + > > >>>> + The IT6263 also encodes and transmits up to 8 channels of I2S > > >>>> + digital audio, with sampling rate up to 192KHz and sample size > > >>>> + up to 24 bits. In addition, an S/PDIF input port takes in > > >>>> + compressed audio of up to 192KHz > > frame rate. > > >>>> + > > >>>> + The newly suppo
RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu and Dmitry, > -Original Message- > From: Liu Ying > Sent: Monday, October 14, 2024 6:34 AM > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS > to HDMI converter > > On 10/14/2024, Dmitry Baryshkov wrote: > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote: > >> On 10/12/2024, Dmitry Baryshkov wrote: > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote: > Document ITE IT6263 LVDS to HDMI converter. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying > --- > v2: > * Document number of LVDS link data lanes. (Biju) > * Simplify ports property by dropping "oneOf". (Rob) > > .../bindings/display/bridge/ite,it6263.yaml | 276 ++ > 1 file changed, 276 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > diff --git > a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > new file mode 100644 > index ..bc2bbec07623 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > +++ aml > @@ -0,0 +1,276 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > +1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ITE IT6263 LVDS to HDMI converter > + > +maintainers: > + - Liu Ying > + > +description: | > + The IT6263 is a high-performance single-chip De-SSC(De-Spread > +Spectrum) LVDS > + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > +transmitter, > + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > function. > + The built-in LVDS receiver can support single-link and dual-link > +LVDS inputs, > + and the built-in HDMI transmitter is fully compliant with HDMI > +1.4a/3D, HDCP > + 1.2 and backward compatible with DVI 1.0 specification. > + > + The IT6263 also encodes and transmits up to 8 channels of I2S > + digital audio, with sampling rate up to 192KHz and sample size > + up to 24 bits. In addition, an S/PDIF input port takes in compressed > audio of up to 192KHz > frame rate. > + > + The newly supported High-Bit Rate(HBR) audio by HDMI > + specifications v1.3 is provided by the IT6263 in two interfaces: > + the four I2S input ports or the S/PDIF input port. With both > + interfaces the highest possible HBR frame rate is supported at up to > 768KHz. > + > +properties: > >>> > >>> No LVDS data-mapping support? > >> > >> It is enough to document number of LVDS link data lanes because OS > >> should be able to determine the data-mapping by looking at the number > >> and the data-mapping capability of the other side of the LVDS link. > > > > From what I can see, data-mapping is specified on the consumer sink > > side of the LVDS link. This means it should go to the bridge's device node. > > Then, I won't define data-lanes, because data-mapping implies it, e.g., > jeida-24 implies data lanes > 0/1/2/3, see lvds-data-mapping.yaml. > > Please let me know which one you prefer. Assume a top level use case where a user changes the format from JEDAI to VESA using On screen display or modetest(if some one adds support for lvds-mapping) then setting of the lvds data mapping should be dynamic. Maybe for initial version hardcode with JEDAI or VESA as default and provide a way to override the host driver and bridge with requested lvds-data mapping dynamically later?? Cheers, Biju
RE: [PATCH v2 6/9] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying, > -Original Message- > From: Liu Ying > Sent: Saturday, October 12, 2024 11:02 AM > To: Dmitry Baryshkov > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; > linux-ker...@vger.kernel.org; > Subject: Re: [PATCH v2 6/9] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > On 10/12/2024, Dmitry Baryshkov wrote: > > On Sat, Oct 12, 2024 at 03:35:40PM +0800, Liu Ying wrote: > >> Add basic HDMI video output support. Currently, only RGB888 output > >> pixel format is supported. At the LVDS input side, the driver > >> supports single LVDS link and dual LVDS links with "jeida-24" LVDS > >> mapping. > >> > >> Product link: > >> https://www.ite.com.tw/en/product/cate1/IT6263 > >> > >> Signed-off-by: Liu Ying > >> --- > >> v2: > >> * Add AVI inforframe support. (Maxime) > > > > Maxime asked to wire up the HDMI Connector framework. I have pushed > > the patch that converts lt9611.c driver. Please implement similar > > changes in your driver. > > Hmm, didn't fully get the meaning of "the new HDMI bridge infrastructure" > maxime asked. Ok, will take a look at lt9611.c. > > > > >> * Add DRM_MODE_CONNECTOR_HDMIA. (Biju) > >> * Rename it6263_reset() to it6263_hw_reset(). (Biju) > >> * Check number of LVDS link data lanes. (Biju) > >> > >> drivers/gpu/drm/bridge/Kconfig | 8 + > >> drivers/gpu/drm/bridge/Makefile | 1 + > >> drivers/gpu/drm/bridge/ite-it6263.c | 919 > >> > >> 3 files changed, 928 insertions(+) > >> create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > >> > >> diff --git a/drivers/gpu/drm/bridge/Kconfig > >> b/drivers/gpu/drm/bridge/Kconfig index 3eb955333c80..93f99682a090 > >> 100644 > >> --- a/drivers/gpu/drm/bridge/Kconfig > >> +++ b/drivers/gpu/drm/bridge/Kconfig > >> @@ -90,6 +90,14 @@ config DRM_FSL_LDB > >>help > >> Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > >> > >> +config DRM_ITE_IT6263 > >> + tristate "ITE IT6263 LVDS/HDMI bridge" > >> + depends on OF > >> + select DRM_KMS_HELPER > >> + select REGMAP_I2C > >> + help > >> +ITE IT6263 LVDS to HDMI bridge chip driver. > >> + > >> config DRM_ITE_IT6505 > >>tristate "ITE IT6505 DisplayPort bridge" > >>depends on OF > >> diff --git a/drivers/gpu/drm/bridge/Makefile > >> b/drivers/gpu/drm/bridge/Makefile index 7df87b582dca..f3776dd473fd > >> 100644 > >> --- a/drivers/gpu/drm/bridge/Makefile > >> +++ b/drivers/gpu/drm/bridge/Makefile > >> @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += > >> chrontel-ch7033.o > >> obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > >> obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > >> obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > >> +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > >> obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > >> obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > >> obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > >> a/drivers/gpu/drm/bridge/ite-it6263.c > >> b/drivers/gpu/drm/bridge/ite-it6263.c > >> new file mode 100644 > >> index ..9b3318792f15 > >> --- /dev/null > >> +++ b/drivers/gpu/drm/bridge/ite-it6263.c > >> @@ -0,0 +1,919 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * Copyright 2024 NXP > >> + */ > >> + > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> + > >> +#include > >> +#include > >> +#include #include > >> +#include #include #include > >> + #include #include > >> + > >> + > >> +/* > >> + > >> +- > >> + * LVDS registers > >> + */ > >> + > >> +/* LVDS software reset registers */ > >> +#define LVDS_REG_05 0x05 > >> +#define REG_SOFT_P_RST BIT(1) > >> + > >> +/* LVDS system configuration registers */ > >> +/* 0x0b */ > >> +#define LVDS_REG_0B 0x0b > >> +#define REG_SSC_PCLK_RF BIT(0) > >> +#define REG_LVDS_IN_SWAP BIT(1) > >> + > >> +/* LVDS test pattern gen control registers */ > >> +/* 0x2c */ > >> +#define LVDS_REG_2C 0x2c > >> +#define REG_COL_DEP GENMASK(1, 0) > >> +#define BIT8 FIELD_PREP(REG_COL_DEP, 2) > >> +#define OUT_MAP BIT(4) > >> +#define JEIDA0 > >> +#define REG_DESSC_ENBBIT(6) > >> +#define DMODEBIT(7) > >> +#define DISO BIT(7) > >> +#define SISO 0 > >> + > >> +#define LVDS_REG_3C 0x3c > >> +#define LVDS_REG_3F 0x3f > >> +#define LVDS_REG_47 0x47 > >> +#define LVDS_REG_48 0x48 > >> +#define LVDS_REG_4F 0x4f > >> +#define LVDS_REG_52
RE: [PATCH v2 6/9] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Dmitry Baryshkov, > -Original Message- > From: Dmitry Baryshkov > Sent: Saturday, October 12, 2024 9:45 AM > Subject: Re: [PATCH v2 6/9] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > On Sat, Oct 12, 2024 at 03:35:40PM +0800, Liu Ying wrote: > > Add basic HDMI video output support. Currently, only RGB888 output > > pixel format is supported. At the LVDS input side, the driver > > supports single LVDS link and dual LVDS links with "jeida-24" LVDS > > mapping. > > > > Product link: > > https://www.ite.com.tw/en/product/cate1/IT6263 > > > > Signed-off-by: Liu Ying > > --- > > v2: > > * Add AVI inforframe support. (Maxime) > > Maxime asked to wire up the HDMI Connector framework. I have pushed the patch > that converts lt9611.c > driver. Please implement similar changes in your driver. > > > * Add DRM_MODE_CONNECTOR_HDMIA. (Biju) > > * Rename it6263_reset() to it6263_hw_reset(). (Biju) > > * Check number of LVDS link data lanes. (Biju) > > > > drivers/gpu/drm/bridge/Kconfig | 8 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/ite-it6263.c | 919 > > > > 3 files changed, 928 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > > b/drivers/gpu/drm/bridge/Kconfig index 3eb955333c80..93f99682a090 > > 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -90,6 +90,14 @@ config DRM_FSL_LDB > > help > > Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > > > > +config DRM_ITE_IT6263 > > + tristate "ITE IT6263 LVDS/HDMI bridge" > > + depends on OF > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + help > > + ITE IT6263 LVDS to HDMI bridge chip driver. > > + > > config DRM_ITE_IT6505 > > tristate "ITE IT6505 DisplayPort bridge" > > depends on OF > > diff --git a/drivers/gpu/drm/bridge/Makefile > > b/drivers/gpu/drm/bridge/Makefile index 7df87b582dca..f3776dd473fd > > 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > > obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > > obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > > +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > > obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > > obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > > obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > > a/drivers/gpu/drm/bridge/ite-it6263.c > > b/drivers/gpu/drm/bridge/ite-it6263.c > > new file mode 100644 > > index ..9b3318792f15 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/ite-it6263.c > > @@ -0,0 +1,919 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright 2024 NXP > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include #include > > +#include #include #include > > + #include #include > > + > > + > > +/* > > +- > > + > > + * LVDS registers > > + */ > > + > > +/* LVDS software reset registers */ > > +#define LVDS_REG_050x05 > > +#define REG_SOFT_P_RSTBIT(1) > > + > > +/* LVDS system configuration registers */ > > +/* 0x0b */ > > +#define LVDS_REG_0B0x0b > > +#define REG_SSC_PCLK_RF BIT(0) > > +#define REG_LVDS_IN_SWAP BIT(1) > > + > > +/* LVDS test pattern gen control registers */ > > +/* 0x2c */ > > +#define LVDS_REG_2C0x2c > > +#define REG_COL_DEP GENMASK(1, 0) > > +#define BIT8 FIELD_PREP(REG_COL_DEP, 2) > > +#define OUT_MAP BIT(4) > > +#define JEIDA 0 > > +#define REG_DESSC_ENB BIT(6) > > +#define DMODE BIT(7) > > +#define DISO BIT(7) > > +#define SISO 0 > > + > > +#define LVDS_REG_3C0x3c > > +#define LVDS_REG_3F0x3f > > +#define LVDS_REG_470x47 > > +#define LVDS_REG_480x48 > > +#define LVDS_REG_4F0x4f > > +#define LVDS_REG_520x52 > > + > > +/* > > +- > > + > > + * HDMI registers are separated into three banks: > > + * 1) HDMI register common bank: 0x00 ~ 0x2f */ > > + > > +/* HDMI genernal registers */ > > +#define HDMI_REG_SW_RST0x04 > > +#define SOFTREF_RST BIT(5) > > +#define SOFTA
[PATCH] drm: renesas: rz-du: rzg2l_du_crtc: Fix max dot clock for DPI
As per the RZ/G2UL hardware manual Table 33.4 Clock List, the maximum
dot clock for the DPI interface is 83.5 MHz. Add mode_valid callback
to reject modes greater than 83.5 MHz.
Signed-off-by: Biju Das
---
Before applying the patch:
root@smarc-rzg2ul:~# modetest -M rzg2l-du
Encoders:
id crtctypepossible crtcs possible clones
37 36 none0x0001 0x0001
Connectors:
id encoder status namesize (mm) modes encoders
38 37 connected HDMI-A-1520x320 30 37
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 1920x1080 59.72 1920 1968 2000 2080 1080 1082 1087 138000 flags:
phsync, nvsync; type: preferred, driver
#1 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags:
phsync, pvsync; type: driver
#2 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags:
phsync, pvsync; type: driver
#3 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags:
phsync, pvsync; type: driver
#4 1280x1024 75.02 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags:
phsync, pvsync; type: driver
#5 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags:
phsync, pvsync; type: driver
#6 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync,
pvsync; type: driver
#7 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync,
pvsync; type: userdef, driver
#8 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync,
pvsync; type: driver
#9 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync,
pvsync; type: driver
...
After applying the patch:
root@smarc-rzg2ul:~# modetest -M rzg2l-du
Encoders:
id crtctypepossible crtcs possible clones
37 36 none0x0001 0x0001
Connectors:
id encoder status namesize (mm) modes encoders
38 37 connected HDMI-A-1520x320 23 37
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync,
pvsync; type: driver
#1 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync,
pvsync; type: driver
#2 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync,
pvsync; type: driver
#3 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync,
pvsync; type: driver
#4 1024x768 75.03 1024 1040 1136 1312 768 769 772 800 78750 flags: phsync,
pvsync; type: driver
#5 1024x768 70.07 1024 1048 1184 1328 768 771 777 806 75000 flags: nhsync,
nvsync; type: driver
#6 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync,
nvsync; type: driver
#7 1080x607 59.97 1080 1120 1232 1384 607 608 611 629 52210 flags: nhsync,
pvsync; type:
#8 832x624 74.55 832 864 928 1152 624 625 628 667 57284 flags: nhsync,
nvsync; type: driver
#9 800x600 75.00 800 816 896 1056 600 601 604 625 49500 flags: phsync,
pvsync; type: driver
...
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 6e7aac6219be..650a2e40caf5 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -248,6 +248,32 @@ static void rzg2l_du_crtc_stop(struct rzg2l_du_crtc *rcrtc)
* CRTC Functions
*/
+static int rzg2l_du_crtc_atomic_check(struct drm_crtc *crtc,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
+ crtc);
+ struct rzg2l_du_crtc_state *rstate = to_rzg2l_crtc_state(crtc_state);
+ struct drm_encoder *encoder;
+
+ /* Store the routes from the CRTC output to the DU outputs. */
+ rstate->outputs = 0;
+
+ drm_for_each_encoder_mask(encoder, crtc->dev,
+ crtc_state->encoder_mask) {
+ struct rzg2l_du_encoder *renc;
+
+ /* Skip the writeback encoder. */
+ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+
+ renc = to_rzg2l_encoder(encoder);
+ rstate->outputs |= BIT(renc->output);
+ }
+
+ return 0;
+}
+
static void rzg2l_du_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -295,10 +321,27 @@ static void rzg2l_du_crtc_atomic_flush(struct drm_crtc
*crtc,
rzg2l_du_vsp_atomic_flush(rcrtc);
}
+static enum drm_mode_status
+rzg2l_du_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
RE: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu Ying, > -Original Message- > From: linux-arm-kernel On > Behalf Of Liu Ying > Sent: Monday, September 30, 2024 6:29 AM > Subject: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > Add basic HDMI video output support. Currently, only RGB888 output pixel > format is supported. At the > LVDS input side, the driver supports single LVDS link and dual LVDS links > with "jeida-24" LVDS > mapping. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying I have tested this patch on Renesas RZ/G3E SMARC EVK in dual LVDS mode with JEDAI mapping. Please add me in loop when you send next version. So, that I can test and provide feedback. Tested-by: Biju Das Cheers, Biju > --- > drivers/gpu/drm/bridge/Kconfig | 8 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ite-it6263.c | 829 > 3 files changed, 838 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index > 3eb955333c80..93f99682a090 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -90,6 +90,14 @@ config DRM_FSL_LDB > help > Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > > +config DRM_ITE_IT6263 > + tristate "ITE IT6263 LVDS/HDMI bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + ITE IT6263 LVDS to HDMI bridge chip driver. > + > config DRM_ITE_IT6505 > tristate "ITE IT6505 DisplayPort bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile > b/drivers/gpu/drm/bridge/Makefile index > 7df87b582dca..f3776dd473fd 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > a/drivers/gpu/drm/bridge/ite-it6263.c > b/drivers/gpu/drm/bridge/ite-it6263.c > new file mode 100644 > index ..886588497bc1 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6263.c > @@ -0,0 +1,829 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2024 NXP > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include #include > +#include #include #include > + #include #include > + > + > +/* > +--- > +-- > + * LVDS registers > + */ > + > +/* LVDS software reset registers */ > +#define LVDS_REG_05 0x05 > +#define REG_SOFT_P_RST BIT(1) > + > +/* LVDS system configuration registers */ > +/* 0x0b */ > +#define LVDS_REG_0B 0x0b > +#define REG_SSC_PCLK_RF BIT(0) > +#define REG_LVDS_IN_SWAPBIT(1) > + > +/* LVDS test pattern gen control registers */ > +/* 0x2c */ > +#define LVDS_REG_2C 0x2c > +#define REG_COL_DEP GENMASK(1, 0) > +#define BIT8FIELD_PREP(REG_COL_DEP, 2) > +#define OUT_MAP BIT(4) > +#define JEIDA 0 > +#define REG_DESSC_ENB BIT(6) > +#define DMODE BIT(7) > +#define DISOBIT(7) > +#define SISO0 > + > +#define LVDS_REG_3C 0x3c > +#define LVDS_REG_3F 0x3f > +#define LVDS_REG_47 0x47 > +#define LVDS_REG_48 0x48 > +#define LVDS_REG_4F 0x4f > +#define LVDS_REG_52 0x52 > + > +/* > +--- > +-- > + * HDMI registers are separated into three banks: > + * 1) HDMI register common bank: 0x00 ~ 0x2f */ > + > +/* HDMI genernal registers */ > +#define HDMI_REG_SW_RST 0x04 > +#define SOFTREF_RST BIT(5) > +#define SOFTA_RST BIT(4) > +#define SOFTV_RST
[PATCH] drm: renesas: rz-du: Drop DU_MCR0_DPI_OE macro
The DPI_OE bit is removed from the latest RZ/G2UL and RZ/G2L hardware
manual. So, drop this macro.
Signed-off-by: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index c4c1474d487e..6e7aac6219be 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,7 +28,6 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
-#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -217,14 +216,9 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
- struct rzg2l_du_crtc_state *rstate =
to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
- u32 val = DU_MCR0_DI_EN;
- if (rstate->outputs & BIT(RZG2L_DU_OUTPUT_DPAD0))
- val |= DU_MCR0_DPI_OE;
-
- writel(start ? val : 0, rcdu->mmio + DU_MCR0);
+ writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
--
2.43.0
[PATCH] drm: renesas: rz-du: Drop DU_MCR0_DPI_OE macro
The DPI_OE bit is removed from the latest RZ/G2UL and RZ/G2L hardware
manual. So, drop this macro.
Signed-off-by: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index c4c1474d487e..6e7aac6219be 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,7 +28,6 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
-#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -217,14 +216,9 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
- struct rzg2l_du_crtc_state *rstate =
to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
- u32 val = DU_MCR0_DI_EN;
- if (rstate->outputs & BIT(RZG2L_DU_OUTPUT_DPAD0))
- val |= DU_MCR0_DPI_OE;
-
- writel(start ? val : 0, rcdu->mmio + DU_MCR0);
+ writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
--
2.43.0
RE: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Biju Das > Sent: Monday, September 30, 2024 10:04 AM > Subject: RE: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to > HDMI converter > > Hi Liu, > > thanks for the patch. > > > -Original Message- > > From: linux-arm-kernel > > On Behalf Of Liu Ying > > Sent: Monday, September 30, 2024 6:29 AM > > Subject: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS > > to HDMI converter > > > > Document ITE IT6263 LVDS to HDMI converter. > > > > Product link: > > https://www.ite.com.tw/en/product/cate1/IT6263 > > > > Signed-off-by: Liu Ying > > --- > > .../bindings/display/bridge/ite,it6263.yaml | 310 ++ > > 1 file changed, 310 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > new file mode 100644 > > index ..97fb81e5bc4a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > @@ -0,0 +1,310 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ITE IT6263 LVDS to HDMI converter > > + > > +maintainers: > > + - Liu Ying > > + > > +description: | > > + The IT6263 is a high-performance single-chip De-SSC(De-Spread > > +Spectrum) LVDS > > + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > > +transmitter, > > + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > > function. > > + The built-in LVDS receiver can support single-link and dual-link > > +LVDS inputs, > > + and the built-in HDMI transmitter is fully compliant with HDMI > > +1.4a/3D, HDCP > > + 1.2 and backward compatible with DVI 1.0 specification. > > + > > + The IT6263 also encodes and transmits up to 8 channels of I2S > > + digital audio, with sampling rate up to 192KHz and sample size up to 24 > > bits. > > + In addition, an S/PDIF input port takes in compressed audio of up to > > 192KHz frame rate. > > + > > + The newly supported High-Bit Rate(HBR) audio by HDMI specifications > > + v1.3 is provided by the IT6263 in two interfaces: the four I2S > > + input ports or the S/PDIF input port. With both interfaces the > > + highest possible HBR frame rate is supported at up to 768KHz. > > + > > +properties: > > + compatible: > > +const: ite,it6263 > > + > > + reg: > > +maxItems: 1 > > + > > + clocks: > > +maxItems: 1 > > +description: audio master clock > > + > > + clock-names: > > +const: mclk > > + > > + reset-gpios: > > +maxItems: 1 > > + > > + ivdd-supply: > > +description: 1.8V digital logic power > > + > > + ovdd-supply: > > +description: 3.3V I/O pin power > > + > > + txavcc18-supply: > > +description: 1.8V HDMI analog frontend power > > + > > + txavcc33-supply: > > +description: 3.3V HDMI analog frontend power > > + > > + pvcc1-supply: > > +description: 1.8V HDMI frontend core PLL power > > + > > + pvcc2-supply: > > +description: 1.8V HDMI frontend filter PLL power > > + > > + avcc-supply: > > +description: 3.3V LVDS frontend power > > + > > + anvdd-supply: > > +description: 1.8V LVDS frontend analog power > > + > > + apvdd-supply: > > +description: 1.8V LVDS frontend PLL power > > + > > + "#sound-dai-cells": > > +const: 0 > > + > > + ite,i2s-audio-fifo-sources: > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > +minItems: 1 > > +maxItems: 4 > > +items: > > + enum: [0, 1, 2, 3] > > +description: > > + Each array element indicates the pin number of an I2S serial data > > input > > + line which is connected to an audio FIFO, from audio FIFO0 to FIFO3. > > + > > + ite,rl-channel-swap-audio-sources: > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > +minItems: 1 > > +maxItems: 4 > > +uniqueItems: true > > +items: > > +
RE: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Biju Das > Sent: Monday, September 30, 2024 10:16 AM > Subject: RE: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > Hi Liu, > > Thanks for the patch. > > > -Original Message- > > From: linux-arm-kernel > > On Behalf Of Liu Ying > > Sent: Monday, September 30, 2024 6:29 AM > > Subject: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > > > Add basic HDMI video output support. Currently, only RGB888 output > > pixel format is supported. At the LVDS input side, the driver > > supports single LVDS link and dual LVDS links with "jeida-24" LVDS mapping. > > > > Product link: > > https://www.ite.com.tw/en/product/cate1/IT6263 > > > > Signed-off-by: Liu Ying > > --- > > drivers/gpu/drm/bridge/Kconfig | 8 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/ite-it6263.c | 829 > > > > 3 files changed, 838 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > > b/drivers/gpu/drm/bridge/Kconfig index > > 3eb955333c80..93f99682a090 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -90,6 +90,14 @@ config DRM_FSL_LDB > > help > > Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > > > > +config DRM_ITE_IT6263 > > + tristate "ITE IT6263 LVDS/HDMI bridge" > > + depends on OF > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + help > > + ITE IT6263 LVDS to HDMI bridge chip driver. > > + > > config DRM_ITE_IT6505 > > tristate "ITE IT6505 DisplayPort bridge" > > depends on OF > > diff --git a/drivers/gpu/drm/bridge/Makefile > > b/drivers/gpu/drm/bridge/Makefile index 7df87b582dca..f3776dd473fd > > 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > > obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > > obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > > +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > > obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > > obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > > obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > > a/drivers/gpu/drm/bridge/ite-it6263.c > > b/drivers/gpu/drm/bridge/ite-it6263.c > > new file mode 100644 > > index ..886588497bc1 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/ite-it6263.c > > @@ -0,0 +1,829 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright 2024 NXP > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include #include > > +#include #include #include > > + #include #include > > + > > + > > +/* > > +- > > +-- > > +-- > > + * LVDS registers > > + */ > > + > > +/* LVDS software reset registers */ > > +#define LVDS_REG_050x05 > > +#define REG_SOFT_P_RSTBIT(1) > > + > > +/* LVDS system configuration registers */ > > +/* 0x0b */ > > +#define LVDS_REG_0B0x0b > > +#define REG_SSC_PCLK_RF BIT(0) > > +#define REG_LVDS_IN_SWAP BIT(1) > > + > > +/* LVDS test pattern gen control registers */ > > +/* 0x2c */ > > +#define LVDS_REG_2C0x2c > > +#define REG_COL_DEP GENMASK(1, 0) > > +#define BIT8 FIELD_PREP(REG_COL_DEP, 2) > > +#define OUT_MAP BIT(4) > > +#define JEIDA 0 > > +#define REG_DESSC_ENB BIT(6) > > +#define DMODE BIT(7) > > +#define DISO BIT(7) > > +#define SISO 0 > > + > > +#define LVDS_REG_3C0x3c > > +#define LVDS_REG_3F0x3f > > +#define LVDS_REG_47
RE: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Liu Ying > Sent: Monday, September 30, 2024 10:49 AM > Subject: Re: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to > HDMI converter > > On 09/30/2024, Biju Das wrote: > > Hi Liu, > > Hi Biju, > > > > >> -Original Message- > >> From: Liu Ying > >> Sent: Monday, September 30, 2024 10:30 AM > >> Subject: Re: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 > >> LVDS to HDMI converter > >> > >> On 09/30/2024, Biju Das wrote: > >>> Hi Liu, > >> > >> Hi Biju, > >> > >>> > >>>> -Original Message- > >>>> From: Liu Ying > >>>> Sent: Monday, September 30, 2024 10:16 AM > >>>> Subject: Re: [PATCH 5/8] dt-bindings: display: bridge: Add ITE > >>>> IT6263 LVDS to HDMI converter > >>>> > >>>> On 09/30/2024, Biju Das wrote: > >>>>> Hi Liu, > >>>> > >>>> Hi Biju, > >>>> > >>>>> > >>>>> thanks for the patch. > >>>>> > >>>>>> -Original Message- > >>>>>> From: linux-arm-kernel > >>>>>> > >>>>>> On Behalf Of Liu Ying > >>>>>> Sent: Monday, September 30, 2024 6:29 AM > >>>>>> Subject: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 > >>>>>> LVDS to HDMI converter > >>>>>> > >>>>>> Document ITE IT6263 LVDS to HDMI converter. > >>>>>> > >>>>>> Product link: > >>>>>> https://www.ite.com.tw/en/product/cate1/IT6263 > >>>>>> > >>>>>> Signed-off-by: Liu Ying > >>>>>> --- > >>>>>> .../bindings/display/bridge/ite,it6263.yaml | 310 ++ > >>>>>> 1 file changed, 310 insertions(+) create mode 100644 > >>>>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >>>>>> > >>>>>> diff --git > >>>>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam > >>>>>> l > >>>>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam > >>>>>> l > >>>>>> new file mode 100644 > >>>>>> index ..97fb81e5bc4a > >>>>>> --- /dev/null > >>>>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263 > >>>>>> +++ .y > >>>>>> +++ am > >>>>>> +++ l > >>>>>> @@ -0,0 +1,310 @@ > >>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > >>>>>> +1.2 > >>>>>> +--- > >>>>>> +$id: > >>>>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > >>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>>> + > >>>>>> +title: ITE IT6263 LVDS to HDMI converter > >>>>>> + > >>>>>> +maintainers: > >>>>>> + - Liu Ying > >>>>>> + > >>>>>> +description: | > >>>>>> + The IT6263 is a high-performance single-chip De-SSC(De-Spread > >>>>>> +Spectrum) LVDS > >>>>>> + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > >>>>>> +transmitter, > >>>>>> + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > >>>>>> function. > >>>>>> + The built-in LVDS receiver can support single-link and > >>>>>> +dual-link LVDS inputs, > >>>>>> + and the built-in HDMI transmitter is fully compliant with HDMI > >>>>>> +1.4a/3D, HDCP > >>>>>> + 1.2 and backward compatible with DVI 1.0 specification. > >>>>>> + > >>>>>> + The IT6263 also encodes and transmits up to 8 channels of I2S > >>>>>> + digital audio, with sampling rate up to 192KHz and sample size up > >>>>>> to 24 bits. > >>>>>> + In addition, an S/PDIF input port takes in compressed audio of up > >>>>>> to 192KHz frame rate. >
RE: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Liu Ying > Sent: Monday, September 30, 2024 10:40 AM > Subject: Re: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > On 09/30/2024, Biju Das wrote: > > Hi Liu, > > Hi Biju, > > > > > Thanks for the patch. > > > >> -Original Message- > >> From: linux-arm-kernel > >> On Behalf Of Liu Ying > >> Sent: Monday, September 30, 2024 6:29 AM > >> Subject: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI > >> converter > >> > >> Add basic HDMI video output support. Currently, only RGB888 output > >> pixel format is supported. At the LVDS input side, the driver > >> supports single LVDS link and dual LVDS links with "jeida-24" LVDS mapping. > >> > >> Product link: > >> https://www.ite.com.tw/en/product/cate1/IT6263 > >> > >> Signed-off-by: Liu Ying > >> --- > >> drivers/gpu/drm/bridge/Kconfig | 8 + > >> drivers/gpu/drm/bridge/Makefile | 1 + > >> drivers/gpu/drm/bridge/ite-it6263.c | 829 > >> > >> 3 files changed, 838 insertions(+) > >> create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > >> > >> diff --git a/drivers/gpu/drm/bridge/Kconfig > >> + > >> + it->lvds_i2c = devm_i2c_new_dummy_device(dev, client->adapter, > >> + LVDS_INPUT_CTRL_I2C_ADDR); > >> + if (IS_ERR(it->lvds_i2c)) > >> + dev_err_probe(it->dev, PTR_ERR(it->lvds_i2c), > >> +"failed to allocate I2C device for LVDS\n"); > > > > Maybe use action_or_reset and call i2c_unregister_device(); > > devm_i2c_new_dummy_device() is called here. It is a dev managed function > call. Action > devm_i2c_release_dummy() is added in it already. Oops. I missed that. Cheers, Biju
RE: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Liu Ying > Sent: Monday, September 30, 2024 10:30 AM > Subject: Re: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to > HDMI converter > > On 09/30/2024, Biju Das wrote: > > Hi Liu, > > Hi Biju, > > > > >> -Original Message- > >> From: Liu Ying > >> Sent: Monday, September 30, 2024 10:16 AM > >> Subject: Re: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 > >> LVDS to HDMI converter > >> > >> On 09/30/2024, Biju Das wrote: > >>> Hi Liu, > >> > >> Hi Biju, > >> > >>> > >>> thanks for the patch. > >>> > >>>> -Original Message- > >>>> From: linux-arm-kernel > >>>> > >>>> On Behalf Of Liu Ying > >>>> Sent: Monday, September 30, 2024 6:29 AM > >>>> Subject: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 > >>>> LVDS to HDMI converter > >>>> > >>>> Document ITE IT6263 LVDS to HDMI converter. > >>>> > >>>> Product link: > >>>> https://www.ite.com.tw/en/product/cate1/IT6263 > >>>> > >>>> Signed-off-by: Liu Ying > >>>> --- > >>>> .../bindings/display/bridge/ite,it6263.yaml | 310 ++ > >>>> 1 file changed, 310 insertions(+) > >>>> create mode 100644 > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >>>> > >>>> diff --git > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >>>> new file mode 100644 > >>>> index ..97fb81e5bc4a > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > >>>> +++ am > >>>> +++ l > >>>> @@ -0,0 +1,310 @@ > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML > >>>> +1.2 > >>>> +--- > >>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>> + > >>>> +title: ITE IT6263 LVDS to HDMI converter > >>>> + > >>>> +maintainers: > >>>> + - Liu Ying > >>>> + > >>>> +description: | > >>>> + The IT6263 is a high-performance single-chip De-SSC(De-Spread > >>>> +Spectrum) LVDS > >>>> + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > >>>> +transmitter, > >>>> + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > >>>> function. > >>>> + The built-in LVDS receiver can support single-link and dual-link > >>>> +LVDS inputs, > >>>> + and the built-in HDMI transmitter is fully compliant with HDMI > >>>> +1.4a/3D, HDCP > >>>> + 1.2 and backward compatible with DVI 1.0 specification. > >>>> + > >>>> + The IT6263 also encodes and transmits up to 8 channels of I2S > >>>> + digital audio, with sampling rate up to 192KHz and sample size up to > >>>> 24 bits. > >>>> + In addition, an S/PDIF input port takes in compressed audio of up to > >>>> 192KHz frame rate. > >>>> + > >>>> + The newly supported High-Bit Rate(HBR) audio by HDMI > >>>> + specifications > >>>> + v1.3 is provided by the IT6263 in two interfaces: the four I2S > >>>> + input ports or the S/PDIF input port. With both interfaces the > >>>> + highest possible HBR frame rate is supported at up to 768KHz. > >>>> + > >>>> +properties: > >>>> + compatible: > >>>> +const: ite,it6263 > >>>> + > >>>> + reg: > >>>> +maxItems: 1 > >>>> + > >>>> + clocks: > >>>> +maxItems: 1 > >>>> +description: audio master clock > >>>> + > >>>> + clock-names: > >>>> +const: mclk > >>>> + > >>>> + reset-gpios: > >>>> +maxItems: 1 > >>>> + > >>>> + ivdd-supply: > >>>> +description
RE: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, > -Original Message- > From: Liu Ying > Sent: Monday, September 30, 2024 10:16 AM > Subject: Re: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to > HDMI converter > > On 09/30/2024, Biju Das wrote: > > Hi Liu, > > Hi Biju, > > > > > thanks for the patch. > > > >> -Original Message- > >> From: linux-arm-kernel > >> On Behalf Of Liu Ying > >> Sent: Monday, September 30, 2024 6:29 AM > >> Subject: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 > >> LVDS to HDMI converter > >> > >> Document ITE IT6263 LVDS to HDMI converter. > >> > >> Product link: > >> https://www.ite.com.tw/en/product/cate1/IT6263 > >> > >> Signed-off-by: Liu Ying > >> --- > >> .../bindings/display/bridge/ite,it6263.yaml | 310 ++ > >> 1 file changed, 310 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > >> new file mode 100644 > >> index ..97fb81e5bc4a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam > >> +++ l > >> @@ -0,0 +1,310 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: ITE IT6263 LVDS to HDMI converter > >> + > >> +maintainers: > >> + - Liu Ying > >> + > >> +description: | > >> + The IT6263 is a high-performance single-chip De-SSC(De-Spread > >> +Spectrum) LVDS > >> + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > >> +transmitter, > >> + the IT6263 supports LVDS input and HDMI 1.4 output by conversion > >> function. > >> + The built-in LVDS receiver can support single-link and dual-link > >> +LVDS inputs, > >> + and the built-in HDMI transmitter is fully compliant with HDMI > >> +1.4a/3D, HDCP > >> + 1.2 and backward compatible with DVI 1.0 specification. > >> + > >> + The IT6263 also encodes and transmits up to 8 channels of I2S > >> + digital audio, with sampling rate up to 192KHz and sample size up to 24 > >> bits. > >> + In addition, an S/PDIF input port takes in compressed audio of up to > >> 192KHz frame rate. > >> + > >> + The newly supported High-Bit Rate(HBR) audio by HDMI > >> + specifications > >> + v1.3 is provided by the IT6263 in two interfaces: the four I2S > >> + input ports or the S/PDIF input port. With both interfaces the > >> + highest possible HBR frame rate is supported at up to 768KHz. > >> + > >> +properties: > >> + compatible: > >> +const: ite,it6263 > >> + > >> + reg: > >> +maxItems: 1 > >> + > >> + clocks: > >> +maxItems: 1 > >> +description: audio master clock > >> + > >> + clock-names: > >> +const: mclk > >> + > >> + reset-gpios: > >> +maxItems: 1 > >> + > >> + ivdd-supply: > >> +description: 1.8V digital logic power > >> + > >> + ovdd-supply: > >> +description: 3.3V I/O pin power > >> + > >> + txavcc18-supply: > >> +description: 1.8V HDMI analog frontend power > >> + > >> + txavcc33-supply: > >> +description: 3.3V HDMI analog frontend power > >> + > >> + pvcc1-supply: > >> +description: 1.8V HDMI frontend core PLL power > >> + > >> + pvcc2-supply: > >> +description: 1.8V HDMI frontend filter PLL power > >> + > >> + avcc-supply: > >> +description: 3.3V LVDS frontend power > >> + > >> + anvdd-supply: > >> +description: 1.8V LVDS frontend analog power > >> + > >> + apvdd-supply: > >> +description: 1.8V LVDS frontend PLL power > >> + > >> + "#sound-dai-cells": > >> +const: 0 > >> + > >> + ite,i2s-audio-fifo-sources: > >> +$ref: /schemas/types.yaml#/definitions/uint32-array > >> +m
RE: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, Thanks for the patch. > -Original Message- > From: linux-arm-kernel On > Behalf Of Liu Ying > Sent: Monday, September 30, 2024 6:29 AM > Subject: [PATCH 6/8] drm/bridge: Add ITE IT6263 LVDS to HDMI converter > > Add basic HDMI video output support. Currently, only RGB888 output pixel > format is supported. At the > LVDS input side, the driver supports single LVDS link and dual LVDS links > with "jeida-24" LVDS > mapping. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying > --- > drivers/gpu/drm/bridge/Kconfig | 8 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ite-it6263.c | 829 > 3 files changed, 838 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index > 3eb955333c80..93f99682a090 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -90,6 +90,14 @@ config DRM_FSL_LDB > help > Support for i.MX8MP DPI-to-LVDS on-SoC encoder. > > +config DRM_ITE_IT6263 > + tristate "ITE IT6263 LVDS/HDMI bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + ITE IT6263 LVDS to HDMI bridge chip driver. > + > config DRM_ITE_IT6505 > tristate "ITE IT6505 DisplayPort bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile > b/drivers/gpu/drm/bridge/Makefile index > 7df87b582dca..f3776dd473fd 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o > +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o > obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o > obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o > obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git > a/drivers/gpu/drm/bridge/ite-it6263.c > b/drivers/gpu/drm/bridge/ite-it6263.c > new file mode 100644 > index ..886588497bc1 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it6263.c > @@ -0,0 +1,829 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2024 NXP > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include #include > +#include #include #include > + #include #include > + > + > +/* > +--- > +-- > + * LVDS registers > + */ > + > +/* LVDS software reset registers */ > +#define LVDS_REG_05 0x05 > +#define REG_SOFT_P_RST BIT(1) > + > +/* LVDS system configuration registers */ > +/* 0x0b */ > +#define LVDS_REG_0B 0x0b > +#define REG_SSC_PCLK_RF BIT(0) > +#define REG_LVDS_IN_SWAPBIT(1) > + > +/* LVDS test pattern gen control registers */ > +/* 0x2c */ > +#define LVDS_REG_2C 0x2c > +#define REG_COL_DEP GENMASK(1, 0) > +#define BIT8FIELD_PREP(REG_COL_DEP, 2) > +#define OUT_MAP BIT(4) > +#define JEIDA 0 > +#define REG_DESSC_ENB BIT(6) > +#define DMODE BIT(7) > +#define DISOBIT(7) > +#define SISO0 > + > +#define LVDS_REG_3C 0x3c > +#define LVDS_REG_3F 0x3f > +#define LVDS_REG_47 0x47 > +#define LVDS_REG_48 0x48 > +#define LVDS_REG_4F 0x4f > +#define LVDS_REG_52 0x52 > + > +/* > +--- > +-- > + * HDMI registers are separated into three banks: > + * 1) HDMI register common bank: 0x00 ~ 0x2f */ > + > +/* HDMI genernal registers */ > +#define HDMI_REG_SW_RST 0x04 > +#define SOFTREF_RST BIT(5) > +#define SOFTA_RST BIT(4) > +#define SOFTV_RST BIT(3) > +#define AUD_RST BIT(2) > +#define HDCP_RSTBIT(0) > +#define HDMI_RST_ALL(SOFTREF_RST | SOFTA_RST | > SOFTV_RST | \ > + AUD_RST | HDCP_RST) > + > +#define HDMI_REG_SYS_STATUS 0x0e > +#define HPDETECTBIT(6) > +#define TXVIDSTABLE BIT(4) > + > +#define HDMI_REG_BANK_CTRL 0x0f > +#define REG_BANK_SELBIT(0) > + > +/* HDMI System DDC control registers */ > +#define HDMI_REG_DDC_MASTER_CTRL 0x10 > +#define MASTER_SEL_HOST
RE: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
Hi Liu, thanks for the patch. > -Original Message- > From: linux-arm-kernel On > Behalf Of Liu Ying > Sent: Monday, September 30, 2024 6:29 AM > Subject: [PATCH 5/8] dt-bindings: display: bridge: Add ITE IT6263 LVDS to > HDMI converter > > Document ITE IT6263 LVDS to HDMI converter. > > Product link: > https://www.ite.com.tw/en/product/cate1/IT6263 > > Signed-off-by: Liu Ying > --- > .../bindings/display/bridge/ite,it6263.yaml | 310 ++ > 1 file changed, 310 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > new file mode 100644 > index ..97fb81e5bc4a > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml > @@ -0,0 +1,310 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ITE IT6263 LVDS to HDMI converter > + > +maintainers: > + - Liu Ying > + > +description: | > + The IT6263 is a high-performance single-chip De-SSC(De-Spread > +Spectrum) LVDS > + to HDMI converter. Combined with LVDS receiver and HDMI 1.4a > +transmitter, > + the IT6263 supports LVDS input and HDMI 1.4 output by conversion function. > + The built-in LVDS receiver can support single-link and dual-link LVDS > +inputs, > + and the built-in HDMI transmitter is fully compliant with HDMI > +1.4a/3D, HDCP > + 1.2 and backward compatible with DVI 1.0 specification. > + > + The IT6263 also encodes and transmits up to 8 channels of I2S digital > + audio, with sampling rate up to 192KHz and sample size up to 24 bits. > + In addition, an S/PDIF input port takes in compressed audio of up to > 192KHz frame rate. > + > + The newly supported High-Bit Rate(HBR) audio by HDMI specifications > + v1.3 is provided by the IT6263 in two interfaces: the four I2S input > + ports or the S/PDIF input port. With both interfaces the highest > + possible HBR frame rate is supported at up to 768KHz. > + > +properties: > + compatible: > +const: ite,it6263 > + > + reg: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > +description: audio master clock > + > + clock-names: > +const: mclk > + > + reset-gpios: > +maxItems: 1 > + > + ivdd-supply: > +description: 1.8V digital logic power > + > + ovdd-supply: > +description: 3.3V I/O pin power > + > + txavcc18-supply: > +description: 1.8V HDMI analog frontend power > + > + txavcc33-supply: > +description: 3.3V HDMI analog frontend power > + > + pvcc1-supply: > +description: 1.8V HDMI frontend core PLL power > + > + pvcc2-supply: > +description: 1.8V HDMI frontend filter PLL power > + > + avcc-supply: > +description: 3.3V LVDS frontend power > + > + anvdd-supply: > +description: 1.8V LVDS frontend analog power > + > + apvdd-supply: > +description: 1.8V LVDS frontend PLL power > + > + "#sound-dai-cells": > +const: 0 > + > + ite,i2s-audio-fifo-sources: > +$ref: /schemas/types.yaml#/definitions/uint32-array > +minItems: 1 > +maxItems: 4 > +items: > + enum: [0, 1, 2, 3] > +description: > + Each array element indicates the pin number of an I2S serial data input > + line which is connected to an audio FIFO, from audio FIFO0 to FIFO3. > + > + ite,rl-channel-swap-audio-sources: > +$ref: /schemas/types.yaml#/definitions/uint32-array > +minItems: 1 > +maxItems: 4 > +uniqueItems: true > +items: > + enum: [0, 1, 2, 3] > +description: > + Each array element indicates an audio source whose right channel and > left > + channel are swapped by this converter. For I2S, the element is the pin > + number of an I2S serial data input line. For S/PDIF, the element is > always > + 0. > + > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > + > +oneOf: > + - properties: > + port@0: > +$ref: /schemas/graph.yaml#/properties/port > +description: the first LVDS input link > + > + port@1: false > + > + port@2: > +$ref: /schemas/graph.yaml#/properties/port > +description: video port for the HDMI output > + > + port@3: > +$ref: /schemas/graph.yaml#/properties/port > +description: sound input port > + > +required: > + - port@0 > + - port@2 > + > + - properties: > + port@0: > +$ref: /schemas/graph.yaml#/$defs/port-base > +unevaluatedProperties: false > +description: the first LVDS input link > + > +properties: > + dual-lvds-odd-pixels: > +type: boolean > +description: the f
RE: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart
> Sent: Tuesday, August 27, 2024 11:23 PM
> Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
>
> Hi Biju,
>
> On Tue, Aug 27, 2024 at 04:43:12PM +, Biju Das wrote:
> > Hi Laurent and Tomi,
> >
> > Gentle ping. Are you happy with this patch?
>
> I've sent a pull request last Friday, see
> https://lore.kernel.org/r/20240822234445.ga23...@pendragon.ideasonboard.com
I believe the commit[1] won't apply any more as the source location is moved.
Shall I resend the patch or You will take care, please let me know.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git/commit/?h=drm-next-20240823&id=866dfbc953d46cf7682c6a434a4dd6249677fd68
Cheers,
Biju
>
> > > -Original Message-
> > > From: Laurent Pinchart
> > > Sent: Monday, December 18, 2023 10:39 AM
> > > Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in
> > > rcar_du_vsps_init()
> > >
> > > Hi Biju,
> > >
> > > Thank you for the patch.
> > >
> > > On Thu, Nov 16, 2023 at 12:24:24PM +, Biju Das wrote:
> > > > The rcar_du_vsps_init() doesn't free the np allocated by
> > > > of_parse_phandle_with_fixed_args() for the non-error case.
> > > >
> > > > Fix memory leak for the non-error case.
> > > >
> > > > While at it, replace the label 'error'->'done' as it applies to
> > > > non-error case as well and update the error check condition for
> > > > rcar_du_vsp_init() to avoid breakage in future, if it returns positive
> > > > value.
> > > >
> > > > Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from
> > > > the same VSP")
> > > > Signed-off-by: Biju Das
> > >
> > > Reviewed-by: Laurent Pinchart
> > >
> > >
> > > > ---
> > > > v1->v2:
> > > > * Replaced the label 'error'->'done' as it applies to non-error case as
> > > >well.
> > > > * Update the error check condition for rcar_du_vsp_init() to avoid
> > > >breakage in future, if it returns positive value.
> > > > ---
> > > > drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 10 --
> > > > 1 file changed, 4 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > index 70d8ad065bfa..4c8fe83dd610 100644
> > > > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > @@ -705,7 +705,7 @@ static int rcar_du_vsps_init(struct rcar_du_device
> > > > *rcdu)
> > > > ret = of_parse_phandle_with_fixed_args(np,
> > > > vsps_prop_name,
> > > >cells, i, &args);
> > > > if (ret < 0)
> > > > - goto error;
> > > > + goto done;
> > > >
> > > > /*
> > > > * Add the VSP to the list or update the corresponding
> > > > existing
> > > > @@
> > > > -743,13 +743,11 @@ static int rcar_du_vsps_init(struct rcar_du_device
> > > > *rcdu)
> > > > vsp->dev = rcdu;
> > > >
> > > > ret = rcar_du_vsp_init(vsp, vsps[i].np,
> > > > vsps[i].crtcs_mask);
> > > > - if (ret < 0)
> > > > - goto error;
> > > > + if (ret)
> > > > + goto done;
> > > > }
> > > >
> > > > - return 0;
> > > > -
> > > > -error:
> > > > +done:
> > > > for (i = 0; i < ARRAY_SIZE(vsps); ++i)
> > > > of_node_put(vsps[i].np);
> > > >
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
> -Original Message-
> From: Laurent Pinchart
> Sent: Tuesday, August 27, 2024 11:23 PM
> Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
>
> Hi Biju,
>
> On Tue, Aug 27, 2024 at 04:43:12PM +, Biju Das wrote:
> > Hi Laurent and Tomi,
> >
> > Gentle ping. Are you happy with this patch?
>
> I've sent a pull request last Friday, see
> https://lore.kernel.org/r/20240822234445.ga23...@pendragon.ideasonboard.com
That is nice.
Thanks,
Biju
>
> > > -Original Message-
> > > From: Laurent Pinchart
> > > Sent: Monday, December 18, 2023 10:39 AM
> > > Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in
> > > rcar_du_vsps_init()
> > >
> > > Hi Biju,
> > >
> > > Thank you for the patch.
> > >
> > > On Thu, Nov 16, 2023 at 12:24:24PM +, Biju Das wrote:
> > > > The rcar_du_vsps_init() doesn't free the np allocated by
> > > > of_parse_phandle_with_fixed_args() for the non-error case.
> > > >
> > > > Fix memory leak for the non-error case.
> > > >
> > > > While at it, replace the label 'error'->'done' as it applies to
> > > > non-error case as well and update the error check condition for
> > > > rcar_du_vsp_init() to avoid breakage in future, if it returns positive
> > > > value.
> > > >
> > > > Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from
> > > > the same VSP")
> > > > Signed-off-by: Biju Das
> > >
> > > Reviewed-by: Laurent Pinchart
> > >
> > >
> > > > ---
> > > > v1->v2:
> > > > * Replaced the label 'error'->'done' as it applies to non-error case as
> > > >well.
> > > > * Update the error check condition for rcar_du_vsp_init() to avoid
> > > >breakage in future, if it returns positive value.
> > > > ---
> > > > drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 10 --
> > > > 1 file changed, 4 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > index 70d8ad065bfa..4c8fe83dd610 100644
> > > > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > > > @@ -705,7 +705,7 @@ static int rcar_du_vsps_init(struct rcar_du_device
> > > > *rcdu)
> > > > ret = of_parse_phandle_with_fixed_args(np,
> > > > vsps_prop_name,
> > > >cells, i, &args);
> > > > if (ret < 0)
> > > > - goto error;
> > > > + goto done;
> > > >
> > > > /*
> > > > * Add the VSP to the list or update the corresponding
> > > > existing
> > > > @@
> > > > -743,13 +743,11 @@ static int rcar_du_vsps_init(struct rcar_du_device
> > > > *rcdu)
> > > > vsp->dev = rcdu;
> > > >
> > > > ret = rcar_du_vsp_init(vsp, vsps[i].np,
> > > > vsps[i].crtcs_mask);
> > > > - if (ret < 0)
> > > > - goto error;
> > > > + if (ret)
> > > > + goto done;
> > > > }
> > > >
> > > > - return 0;
> > > > -
> > > > -error:
> > > > +done:
> > > > for (i = 0; i < ARRAY_SIZE(vsps); ++i)
> > > > of_node_put(vsps[i].np);
> > > >
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
Hi Laurent and Tomi,
Gentle ping. Are you happy with this patch?
Cheers,
Biju
> -Original Message-
> From: Laurent Pinchart
> Sent: Monday, December 18, 2023 10:39 AM
> Subject: Re: [PATCH v2] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Thu, Nov 16, 2023 at 12:24:24PM +, Biju Das wrote:
> > The rcar_du_vsps_init() doesn't free the np allocated by
> > of_parse_phandle_with_fixed_args() for the non-error case.
> >
> > Fix memory leak for the non-error case.
> >
> > While at it, replace the label 'error'->'done' as it applies to
> > non-error case as well and update the error check condition for
> > rcar_du_vsp_init() to avoid breakage in future, if it returns positive
> > value.
> >
> > Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the
> > same VSP")
> > Signed-off-by: Biju Das
>
> Reviewed-by: Laurent Pinchart
>
> > ---
> > v1->v2:
> > * Replaced the label 'error'->'done' as it applies to non-error case as
> >well.
> > * Update the error check condition for rcar_du_vsp_init() to avoid
> >breakage in future, if it returns positive value.
> > ---
> > drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 10 --
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > index 70d8ad065bfa..4c8fe83dd610 100644
> > --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> > @@ -705,7 +705,7 @@ static int rcar_du_vsps_init(struct rcar_du_device
> > *rcdu)
> > ret = of_parse_phandle_with_fixed_args(np, vsps_prop_name,
> >cells, i, &args);
> > if (ret < 0)
> > - goto error;
> > + goto done;
> >
> > /*
> > * Add the VSP to the list or update the corresponding existing
> > @@
> > -743,13 +743,11 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> > vsp->dev = rcdu;
> >
> > ret = rcar_du_vsp_init(vsp, vsps[i].np, vsps[i].crtcs_mask);
> > - if (ret < 0)
> > - goto error;
> > + if (ret)
> > + goto done;
> > }
> >
> > - return 0;
> > -
> > -error:
> > +done:
> > for (i = 0; i < ARRAY_SIZE(vsps); ++i)
> > of_node_put(vsps[i].np);
> >
>
> --
> Regards,
>
> Laurent Pinchart
[PATCH] drm: renesas: rz-du: Add Kconfig dependency between RZG2L_DU and RZG2L_MIPI_DSI
Add Kconfig dependency between RZG2L_DU and RZG2L_MIPI_DSI, so that DSI module has functional dependency on DU. It is similar way that the R-Car MIPI DSI encoder is handled. While at it drop ARCH_RENESAS dependency as DRM_RZG2L_DU depend on ARCH_RZG2L. Suggested-by: Tomi Valkeinen Signed-off-by: Biju Das --- drivers/gpu/drm/renesas/rz-du/Kconfig | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/renesas/rz-du/Kconfig b/drivers/gpu/drm/renesas/rz-du/Kconfig index 8ec14271ebba..a9488f873436 100644 --- a/drivers/gpu/drm/renesas/rz-du/Kconfig +++ b/drivers/gpu/drm/renesas/rz-du/Kconfig @@ -11,10 +11,15 @@ config DRM_RZG2L_DU Choose this option if you have an RZ/G2L alike chipset. If M is selected the module will be called rzg2l-du-drm. -config DRM_RZG2L_MIPI_DSI - tristate "RZ/G2L MIPI DSI Encoder Support" - depends on DRM && DRM_BRIDGE && OF - depends on ARCH_RENESAS || COMPILE_TEST - select DRM_MIPI_DSI +config DRM_RZG2L_USE_MIPI_DSI + bool "RZ/G2L MIPI DSI Encoder Support" + depends on DRM_BRIDGE && OF + depends on DRM_RZG2L_DU || COMPILE_TEST + default DRM_RZG2L_DU help Enable support for the RZ/G2L Display Unit embedded MIPI DSI encoders. + +config DRM_RZG2L_MIPI_DSI + def_tristate DRM_RZG2L_DU + depends on DRM_RZG2L_USE_MIPI_DSI + select DRM_MIPI_DSI -- 2.43.0
RE: [PATCH v4 0/4] Add support for RZ/G2UL Display Unit
> -Original Message-
> From: Tomi Valkeinen
> Sent: Monday, August 26, 2024 10:51 AM
> Subject: Re: [PATCH v4 0/4] Add support for RZ/G2UL Display Unit
>
> Hi,
>
> On 23/08/2024 18:00, Laurent Pinchart wrote:
> > Hi Biju,
> >
> > On Fri, Aug 23, 2024 at 01:52:14PM +, Biju Das wrote:
> >> On Friday, August 23, 2024 2:15 PM, Laurent Pinchart wrote:
> >>> On Thu, Aug 22, 2024 at 05:23:13PM +0100, Biju Das wrote:
> >>>> This patch series aims to add support for RZ/G2UL DU.
> >>>>
> >>>> The LCD controller is composed of Frame Compression Processor
> >>>> (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
> >>>>
> >>>> The output of LCDC is connected display parallel interface (DPI)
> >>>> and supports a maximum resolution of WXGA along with 2 RPFs to
> >>>> support the blending of two picture layers and raster operations
> >>>> (ROPs)
> >>>>
> >>>> It is similar to LCDC IP on RZ/G2L SoCs, but does not have DSI interface.
> >>>>
> >>>> v3->v4:
> >>>> * Restored the ports property for RZ/G2UL and described port@0 for the
> >>>> DPI interface in bindings patch.
> >>>> * Restored tags from Geert and Conor as the change is trivial
> >>>> (Replaced port 1->0 from v2).
> >>>> * Used "&" instead of "==" in rzg2l_du_start_stop() for scalability.
> >>>> * Restored port variable in struct rzg2l_du_output_routing
> >>>> * Updated rzg2l_du_encoders_init() to handle port based on hardware
> >>>> indices.
> >>>> * Restored ports property in du node and used port@0 for connected
> >>>> DPI interface.
> >>>> v2->v3:
> >>>> * Split patch series based on subsystem from DU patch series [1].
> >>>> * Replaced ports->port property for RZ/G2UL as it supports only DPI
> >>>> and retained ports property for RZ/{G2L,V2L} as it supports both DSI
> >>>> and DPI output interface.
> >>>> * Added missing blank line before example.
> >>>> * Dropped tags from Conor and Geert as there are new changes in
> >>>> bindings
> >>>> * Avoided the line break in rzg2l_du_start_stop() for rstate.
> >>>> * Replaced port->du_output in struct rzg2l_du_output_routing and
> >>>> dropped using the port number to indicate the output type in
> >>>> rzg2l_du_encoders_init().
> >>>> * Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info.
> >>>>
> >>>> [1]
> >>>> https://lore.kernel.org/all/20240709135152.185042-1-biju.das.jz@bp.
> >>>> renesas.com/
> >>>> v1->v2:
> >>>> * Updated cover letter header "DU IP->Display Unit".
> >>>> * Updated commit description related to non ABI breakage for patch#3.
> >>>> * Added Ack from Conor for binding patches.
> >>>>
> >>>> Biju Das (4):
> >>>>dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
> >>>>drm: renesas: rz-du: Add RZ/G2UL DU Support
> >>>
> >>> The first two patches look good to me. Do you have access to
> >>> drm-misc, will you push them yourself, or do you expect a maintainer to
> >>> pick them up ?
> >>
> >> I don’t have access to drm-misc. I expect a maintainer to pick it
> >> up(Maybe via rcar-du tree or drm-misc tree), or else if it is ok, what is
> >> the procedure to get
> access for drm-misc tree??
> >
> > You can find instructions to request drm-misc commit access at
> > https://drm.pages.freedesktop.org/maintainer-tools/committer/commit-ac
> > cess.html
> >
> > Tomi, to avoid delays, could you push the first two patches to
> > drm-misc ?
>
> I have pushed the first two patches.
Thanks Tomi.
Cheers,
Biju
RE: [PATCH] drm: renesas: Move RZ/G2L MIPI DSI driver to rz-du
Hi Tomi, > -Original Message- > From: Tomi Valkeinen > Sent: Monday, August 26, 2024 10:50 AM > Subject: Re: [PATCH] drm: renesas: Move RZ/G2L MIPI DSI driver to rz-du > > Hi, > > On 23/08/2024 18:00, Laurent Pinchart wrote: > > On Fri, Aug 23, 2024 at 02:33:49PM +0100, Lad, Prabhakar wrote: > >> On Wed, Jun 26, 2024 at 6:51 AM Laurent Pinchart wrote: > >>> On Tue, Jun 25, 2024 at 01:32:44PM +0100, Prabhakar wrote: > From: Lad Prabhakar > > All the RZ/G2L DU specific components are located under the rz-du > folder, so it makes sense to move the RZ/G2L MIPI DSI driver there > instead of keeping it in the rcar-du folder. This change improves > the organization and modularity of the driver configuration by grouping > related settings > together. > >>> > >>> I was thinking the same the other day. Thanks for beating me at > >>> sending a patch :-) > >>> > >>> Reviewed-by: Laurent Pinchart > >>> > >>> > >>> Do you or Biju has committer rights to drm-misc to push this patch ? > >> > >> We dont, can you please queue this patch via your tree? > > > > I don't have other pending patches for DRM at the moment. Tomi, could > > you push this to drm-misc ? > > I have pushed this. Thanks. > > Should the DSI driver depend on the DU driver in the kconfig? It compiles > fine without the DU, but can > it ever be used alone? DSI driver mainlined first before DU. Now DU driver is available, from a functional Point we should add dependency. Will send a patch soon. Cheers, Biju
RE: [PATCH v4 0/4] Add support for RZ/G2UL Display Unit
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart
> Sent: Friday, August 23, 2024 4:00 PM
> Subject: Re: [PATCH v4 0/4] Add support for RZ/G2UL Display Unit
>
> Hi Biju,
>
> On Fri, Aug 23, 2024 at 01:52:14PM +, Biju Das wrote:
> > On Friday, August 23, 2024 2:15 PM, Laurent Pinchart wrote:
> > > On Thu, Aug 22, 2024 at 05:23:13PM +0100, Biju Das wrote:
> > > > This patch series aims to add support for RZ/G2UL DU.
> > > >
> > > > The LCD controller is composed of Frame Compression Processor
> > > > (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
> > > >
> > > > The output of LCDC is connected display parallel interface (DPI)
> > > > and supports a maximum resolution of WXGA along with 2 RPFs to
> > > > support the blending of two picture layers and raster operations
> > > > (ROPs)
> > > >
> > > > It is similar to LCDC IP on RZ/G2L SoCs, but does not have DSI
> > > > interface.
> > > >
> > > > v3->v4:
> > > > * Restored the ports property for RZ/G2UL and described port@0 for the
> > > >DPI interface in bindings patch.
> > > > * Restored tags from Geert and Conor as the change is trivial
> > > >(Replaced port 1->0 from v2).
> > > > * Used "&" instead of "==" in rzg2l_du_start_stop() for scalability.
> > > > * Restored port variable in struct rzg2l_du_output_routing
> > > > * Updated rzg2l_du_encoders_init() to handle port based on hardware
> > > > indices.
> > > > * Restored ports property in du node and used port@0 for connected
> > > >DPI interface.
> > > > v2->v3:
> > > > * Split patch series based on subsystem from DU patch series [1].
> > > > * Replaced ports->port property for RZ/G2UL as it supports only DPI
> > > >and retained ports property for RZ/{G2L,V2L} as it supports both DSI
> > > >and DPI output interface.
> > > > * Added missing blank line before example.
> > > > * Dropped tags from Conor and Geert as there are new changes in
> > > > bindings
> > > > * Avoided the line break in rzg2l_du_start_stop() for rstate.
> > > > * Replaced port->du_output in struct rzg2l_du_output_routing and
> > > >dropped using the port number to indicate the output type in
> > > >rzg2l_du_encoders_init().
> > > > * Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info.
> > > >
> > > > [1]
> > > > https://lore.kernel.org/all/20240709135152.185042-1-biju.das.jz@bp
> > > > .renesas.com/
> > > > v1->v2:
> > > > * Updated cover letter header "DU IP->Display Unit".
> > > > * Updated commit description related to non ABI breakage for patch#3.
> > > > * Added Ack from Conor for binding patches.
> > > >
> > > > Biju Das (4):
> > > > dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
> > > > drm: renesas: rz-du: Add RZ/G2UL DU Support
> > >
> > > The first two patches look good to me. Do you have access to
> > > drm-misc, will you push them yourself, or do you expect a maintainer to
> > > pick them up ?
> >
> > I don’t have access to drm-misc. I expect a maintainer to pick it
> > up(Maybe via rcar-du tree or drm-misc tree), or else if it is ok, what is
> > the procedure to get
> access for drm-misc tree??
>
> You can find instructions to request drm-misc commit access at
> https://drm.pages.freedesktop.org/maintainer-tools/committer/commit-access.html
Thanks for the link. Meantime, I have requested for access [1]
[1] https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/48
Cheers,
Biju
>
> Tomi, to avoid delays, could you push the first two patches to drm-misc ?
>
> > > > arm64: dts: renesas: r9a07g043u: Add DU node
> > > > arm64: dts: renesas: r9a07g043u11-smarc: Enable DU
> > > >
> > > > .../bindings/display/renesas,rzg2l-du.yaml| 32 -
> > > > arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 25
> > > > .../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +-
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 ++
> > > > drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 3 +-
> > > > 6 files changed, 185 insertions(+), 5 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v4 0/4] Add support for RZ/G2UL Display Unit
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart
> Sent: Friday, August 23, 2024 2:15 PM
> Subject: Re: [PATCH v4 0/4] Add support for RZ/G2UL Display Unit
>
> Hi Biju,
>
> On Thu, Aug 22, 2024 at 05:23:13PM +0100, Biju Das wrote:
> > This patch series aims to add support for RZ/G2UL DU.
> >
> > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > Video Signal Processor (VSPD), and Display Unit (DU).
> >
> > The output of LCDC is connected display parallel interface (DPI) and
> > supports a maximum resolution of WXGA along with 2 RPFs to support the
> > blending of two picture layers and raster operations (ROPs)
> >
> > It is similar to LCDC IP on RZ/G2L SoCs, but does not have DSI interface.
> >
> > v3->v4:
> > * Restored the ports property for RZ/G2UL and described port@0 for the
> >DPI interface in bindings patch.
> > * Restored tags from Geert and Conor as the change is trivial
> >(Replaced port 1->0 from v2).
> > * Used "&" instead of "==" in rzg2l_du_start_stop() for scalability.
> > * Restored port variable in struct rzg2l_du_output_routing
> > * Updated rzg2l_du_encoders_init() to handle port based on hardware
> > indices.
> > * Restored ports property in du node and used port@0 for connected
> >DPI interface.
> > v2->v3:
> > * Split patch series based on subsystem from DU patch series [1].
> > * Replaced ports->port property for RZ/G2UL as it supports only DPI
> >and retained ports property for RZ/{G2L,V2L} as it supports both DSI
> >and DPI output interface.
> > * Added missing blank line before example.
> > * Dropped tags from Conor and Geert as there are new changes in
> > bindings
> > * Avoided the line break in rzg2l_du_start_stop() for rstate.
> > * Replaced port->du_output in struct rzg2l_du_output_routing and
> >dropped using the port number to indicate the output type in
> >rzg2l_du_encoders_init().
> > * Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info.
> >
> > [1]
> > https://lore.kernel.org/all/20240709135152.185042-1-biju.das...@bp.ren
> > esas.com/
> > v1->v2:
> > * Updated cover letter header "DU IP->Display Unit".
> > * Updated commit description related to non ABI breakage for patch#3.
> > * Added Ack from Conor for binding patches.
> >
> > Biju Das (4):
> > dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
> > drm: renesas: rz-du: Add RZ/G2UL DU Support
>
> The first two patches look good to me. Do you have access to drm-misc, will
> you push them yourself, or
> do you expect a maintainer to pick them up ?
I don’t have access to drm-misc. I expect a maintainer to pick it up(Maybe via
rcar-du tree or
drm-misc tree), or else if it is ok, what is the procedure to get access for
drm-misc tree??
Cheers,
Biju
>
> > arm64: dts: renesas: r9a07g043u: Add DU node
> > arm64: dts: renesas: r9a07g043u11-smarc: Enable DU
> >
> > .../bindings/display/renesas,rzg2l-du.yaml| 32 -
> > arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 25
> > .../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +-
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 ++
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 3 +-
> > 6 files changed, 185 insertions(+), 5 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
[PATCH v4 2/4] drm: renesas: rz-du: Add RZ/G2UL DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI interface and supports a maximum resolution of WXGA along
with 2 RPFs to support the blending of two picture layers and raster
operations (ROPs).
The DU module is connected to VSPD. Add RZ/G2UL DU support.
Signed-off-by: Biju Das
---
v3->v4:
* Used "&" instead of "==" in rzg2l_du_start_stop() for scalability.
* Restored port variable in struct rzg2l_du_output_routing
* Updated rzg2l_du_encoders_init() to handle port based on hardware indices.
v2->v3:
* Avoided the line break in rzg2l_du_start_stop() for rstate.
* Replaced port->du_output in struct rzg2l_du_output_routing and
dropped using the port number to indicate the output type in
rzg2l_du_encoders_init().
* Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info
v1->v2:
* No change.
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +++-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 +++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 3 ++-
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 6e7aac6219be..c4c1474d487e 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,6 +28,7 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
+#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -216,9 +217,14 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
+ struct rzg2l_du_crtc_state *rstate =
to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
+ u32 val = DU_MCR0_DI_EN;
- writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
+ if (rstate->outputs & BIT(RZG2L_DU_OUTPUT_DPAD0))
+ val |= DU_MCR0_DPI_OE;
+
+ writel(start ? val : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index e5eca8691a33..bc7c381f92ac 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -25,6 +25,16 @@
* Device Information
*/
+static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
+ .channels_mask = BIT(0),
+ .routes = {
+ [RZG2L_DU_OUTPUT_DPAD0] = {
+ .possible_outputs = BIT(0),
+ .port = 0,
+ },
+ },
+};
+
static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
.channels_mask = BIT(0),
.routes = {
@@ -40,6 +50,7 @@ static const struct rzg2l_du_device_info
rzg2l_du_r9a07g044_info = {
};
static const struct of_device_id rzg2l_du_of_table[] = {
+ { .compatible = "renesas,r9a07g043u-du", .data =
&rzg2l_du_r9a07g043u_info },
{ .compatible = "renesas,r9a07g044-du", .data =
&rzg2l_du_r9a07g044_info },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
index 07b312b6f81e..b99217b4e05d 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
@@ -183,7 +183,8 @@ static int rzg2l_du_encoders_init(struct rzg2l_du_device
*rcdu)
/* Find the output route corresponding to the port number. */
for (i = 0; i < RZG2L_DU_OUTPUT_MAX; ++i) {
- if (rcdu->info->routes[i].port == ep.port) {
+ if (rcdu->info->routes[i].possible_outputs &&
+ rcdu->info->routes[i].port == ep.port) {
output = i;
break;
}
--
2.43.0
[PATCH v4 1/4] dt-bindings: display: renesas, rzg2l-du: Document RZ/G2UL DU bindings
Document DU found in RZ/G2UL SoC. The DU block is identical to RZ/G2L
SoC, but has only DPI interface.
While at it, add missing required property port@1 for RZ/G2L and RZ/V2L
SoCs. Currently there is no user for the DPI interface and hence there
won't be any ABI breakage for adding port@1 as required property for
RZ/G2L and RZ/V2L SoCs.
Acked-by: Conor Dooley
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Biju Das
---
v3->v4:
* Restored the ports property for RZ/G2UL and described port@0 for the
DPI interface.
* Restored tags from Geert and Conor as the change is trivial
(Replaced port 1->0 from v2).
v2->v3:
* Replaced ports->port property for RZ/G2UL as it supports only DPI.
and retained ports property for RZ/{G2L,V2L} as it supports both DSI
and DPI output interface.
* Added missing blank line before example.
* Dropped tags from Conor and Geert as there are new changes.
v1->v2:
* Updated commit description related to non ABI breakage.
* Added Ack from Conor.
---
.../bindings/display/renesas,rzg2l-du.yaml| 32 +--
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index 08e5b9478051..95e3d5e74b87 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
oneOf:
- enum:
+ - renesas,r9a07g043u-du # RZ/G2UL
- renesas,r9a07g044-du # RZ/G2{L,LC}
- items:
- enum:
@@ -60,9 +61,6 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
-required:
- - port@0
-
unevaluatedProperties: false
renesas,vsps:
@@ -88,6 +86,34 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: renesas,r9a07g043u-du
+then:
+ properties:
+ports:
+ properties:
+port@0:
+ description: DPI
+
+ required:
+- port@0
+else:
+ properties:
+ports:
+ properties:
+port@0:
+ description: DSI
+port@1:
+ description: DPI
+
+ required:
+- port@0
+- port@1
+
examples:
# RZ/G2L DU
- |
--
2.43.0
[PATCH v4 0/4] Add support for RZ/G2UL Display Unit
This patch series aims to add support for RZ/G2UL DU.
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
The output of LCDC is connected display parallel interface (DPI) and
supports a maximum resolution of WXGA along with 2 RPFs to support the
blending of two picture layers and raster operations (ROPs)
It is similar to LCDC IP on RZ/G2L SoCs, but does not have DSI interface.
v3->v4:
* Restored the ports property for RZ/G2UL and described port@0 for the
DPI interface in bindings patch.
* Restored tags from Geert and Conor as the change is trivial
(Replaced port 1->0 from v2).
* Used "&" instead of "==" in rzg2l_du_start_stop() for scalability.
* Restored port variable in struct rzg2l_du_output_routing
* Updated rzg2l_du_encoders_init() to handle port based on hardware indices.
* Restored ports property in du node and used port@0 for connected
DPI interface.
v2->v3:
* Split patch series based on subsystem from DU patch series [1].
* Replaced ports->port property for RZ/G2UL as it supports only DPI
and retained ports property for RZ/{G2L,V2L} as it supports both DSI
and DPI output interface.
* Added missing blank line before example.
* Dropped tags from Conor and Geert as there are new changes in bindings
* Avoided the line break in rzg2l_du_start_stop() for rstate.
* Replaced port->du_output in struct rzg2l_du_output_routing and
dropped using the port number to indicate the output type in
rzg2l_du_encoders_init().
* Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info.
[1]
https://lore.kernel.org/all/20240709135152.185042-1-biju.das...@bp.renesas.com/
v1->v2:
* Updated cover letter header "DU IP->Display Unit".
* Updated commit description related to non ABI breakage for patch#3.
* Added Ack from Conor for binding patches.
Biju Das (4):
dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
drm: renesas: rz-du: Add RZ/G2UL DU Support
arm64: dts: renesas: r9a07g043u: Add DU node
arm64: dts: renesas: r9a07g043u11-smarc: Enable DU
.../bindings/display/renesas,rzg2l-du.yaml| 32 -
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 25
.../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 3 +-
6 files changed, 185 insertions(+), 5 deletions(-)
--
2.43.0
RE: [PATCH v3 2/4] drm: renesas: rz-du: Add RZ/G2UL DU Support
Hi Geert Uytterhoeven,
Thanks for the feedback.
> -Original Message-
> From: Geert Uytterhoeven
> Sent: Thursday, August 22, 2024 1:31 PM
> Subject: Re: [PATCH v3 2/4] drm: renesas: rz-du: Add RZ/G2UL DU Support
>
> Hi Biju,
>
> On Mon, Aug 5, 2024 at 6:22 PM Biju Das wrote:
> > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > Video Signal Processor (VSPD), and Display Unit (DU).
> >
> > It has DPI interface and supports a maximum resolution of WXGA along
> > with 2 RPFs to support the blending of two picture layers and raster
> > operations (ROPs).
> >
> > The DU module is connected to VSPD. Add RZ/G2UL DU support.
> >
> > Signed-off-by: Biju Das
> > ---
> > v2->v3:
> > * Avoided the line break in rzg2l_du_start_stop() for rstate.
> > * Replaced port->du_output in struct rzg2l_du_output_routing and
> >dropped using the port number to indicate the output type in
> >rzg2l_du_encoders_init().
> > * Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info
>
> Thanks for your patch!
>
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> > @@ -183,8 +183,8 @@ static int rzg2l_du_encoders_init(struct
> > rzg2l_du_device *rcdu)
> >
> > /* Find the output route corresponding to the port number.
> > */
> > for (i = 0; i < RZG2L_DU_OUTPUT_MAX; ++i) {
> > - if (rcdu->info->routes[i].port == ep.port) {
> > - output = i;
> > + if (i == rcdu->info->routes[i].du_output) {
> > + output =
> > + rcdu->info->routes[i].du_output;
>
> Notwithstanding Laurent's comment, the above replacement is equivalent to the
> original "output = i;",
> so there is no need to change this line.
Agreed. I missed that.
Cheers,
Biju
>
> > break;
> > }
> > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to
> journalists I just say "programmer" or something like that.
> -- Linus Torvalds
RE: [PATCH v3 1/4] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
Hi Rob and all,
> -Original Message-
> From: Biju Das
> Sent: Monday, August 19, 2024 1:37 PM
> Subject: RE: [PATCH v3 1/4] dt-bindings: display: renesas,rzg2l-du: Document
> RZ/G2UL DU bindings
>
> Hi Laurent and Rob,
>
> Thanks for the feedback
>
> > -Original Message-
> > From: Laurent Pinchart
> > Sent: Tuesday, August 13, 2024 8:39 PM
> > Subject: Re: [PATCH v3 1/4] dt-bindings: display: renesas,rzg2l-du:
> > Document RZ/G2UL DU bindings
> >
> > Hi Rob,
> >
> > On Tue, Aug 13, 2024 at 10:32:20AM -0600, Rob Herring wrote:
> > > On Mon, Aug 05, 2024 at 04:52:35PM +0100, Biju Das wrote:
> > > > Document DU found in RZ/G2UL SoC. The DU block is identical to
> > > > RZ/G2L SoC, but has only DPI interface.
> > > >
> > > > While at it, add missing required property port@1 for RZ/G2L and
> > > > RZ/V2L SoCs. Currently there is no user for the DPI interface and
> > > > hence there won't be any ABI breakage for adding port@1 as
> > > > required property for RZ/G2L and RZ/V2L SoCs.
> > > >
> > > > Signed-off-by: Biju Das
> > > > ---
> > > > v2->v3:
> > > > * Replaced ports->port property for RZ/G2UL as it supports only DPI.
> > > >and retained ports property for RZ/{G2L,V2L} as it supports both DSI
> > > >and DPI output interface.
> > >
> > > Why? Having port and ports is just a needless complication.
> >
> > I agree that making the ports node mandatory, even when the device has
> > a single port, will simplify the bindings. In hindsight we should never
> > have made ports optional,
> but that can't be changed.
> >
> > > > * Added missing blank line before example.
> > > > * Dropped tags from Conor and Geert as there are new changes.
> > > > v1->v2:
> > > > * Updated commit description related to non ABI breakage.
> > > > * Added Ack from Conor.
> > > > ---
> > > > .../bindings/display/renesas,rzg2l-du.yaml| 35 +--
> > > > 1 file changed, 32 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > index 08e5b9478051..ca01bf26c4c0 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.y
> > > > +++ am
> > > > +++ l
> > > > @@ -18,6 +18,7 @@ properties:
> > > >compatible:
> > > > oneOf:
> > > >- enum:
> > > > + - renesas,r9a07g043u-du # RZ/G2UL
> > > >- renesas,r9a07g044-du # RZ/G2{L,LC}
> > > >- items:
> > > >- enum:
> > > > @@ -60,8 +61,9 @@ properties:
> > > > $ref: /schemas/graph.yaml#/properties/port
> > > > unevaluatedProperties: false
> > > >
> > > > -required:
> > > > - - port@0
> > > > + port:
> > > > +$ref: /schemas/graph.yaml#/properties/port
> > > > +description: Connection to the DU output video port.
> > > >
> > > > unevaluatedProperties: false
> > > >
> > > > @@ -83,11 +85,38 @@ required:
> > > >- clock-names
> > > >- resets
> > > >- power-domains
> > > > - - ports
> > > >- renesas,vsps
> > > >
> > > > additionalProperties: false
> > > >
> > > > +allOf:
> > > > + - if:
> > > > + properties:
> > > > +compatible:
> > > > + contains:
> > > > +const: renesas,r9a07g043u-du
> > > > +then:
> > > > + properties:
> > > > +port:
> > > > + description: DPI
> > >
> > > This is equivalent to 'port@0'. IMO, this case should have a 'port@1'
> > > node so that DPI interface is *always* the same port.
> >
> > That's what Biju did in the previous version, and I recommended to
> > number the ports based on hardware indices, not types. Mapping port
> > numbers to the hardware documentation makes it more consistent for DT
> > writers, makes the logic simpler to understand (in my opinion, based
> > on my experience with the R-Car
> > DU) on the driver side, but most importantly, type-based numbering
> > wouldn't scale as SoCs could have multiple ports of the same type (we've
> > seen that happening with R-
> Car).
>
> OK, I will send bindings based on hardware indices.
I get a warning, if I use ports and port@0 for single port. I don't see this
warning if I use ports and port@1
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi:169.9-178.5: Warning
(graph_child_address): /soc/display@1089/ports: graph node has single child
node 'port@0', #address-cells/#size-cells are not necessary
Can we fix the dt-schema to getting consistent results for single port usage
involving ports?
+ - if:
+ properties:
+compatible:
+ contains:
+const: renesas,r9a07g043u-du
+then:
+ properties:
+ports:
+ properties:
+port@0:
+ description: DPI
+
+ required:
+- port@0
Cheers,
Biju
RE: [PATCH v3 2/4] drm: renesas: rz-du: Add RZ/G2UL DU Support
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Tuesday, August 13, 2024 8:49 PM
> Subject: Re: [PATCH v3 2/4] drm: renesas: rz-du: Add RZ/G2UL DU Support
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Mon, Aug 05, 2024 at 04:52:36PM +0100, Biju Das wrote:
> > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > Video Signal Processor (VSPD), and Display Unit (DU).
> >
> > It has DPI interface and supports a maximum resolution of WXGA along
> > with 2 RPFs to support the blending of two picture layers and raster
> > operations (ROPs).
> >
> > The DU module is connected to VSPD. Add RZ/G2UL DU support.
> >
> > Signed-off-by: Biju Das
> > ---
> > v2->v3:
> > * Avoided the line break in rzg2l_du_start_stop() for rstate.
> > * Replaced port->du_output in struct rzg2l_du_output_routing and
> >dropped using the port number to indicate the output type in
> >rzg2l_du_encoders_init().
> > * Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info
> > v1->v2:
> > * No change.
> > ---
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +++-
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 18 --
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 5 +++--
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 4 ++--
> > 4 files changed, 28 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > index 6e7aac6219be..fd7675c7f181 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > @@ -28,6 +28,7 @@
> > #include "rzg2l_du_vsp.h"
> >
> > #define DU_MCR00x00
> > +#define DU_MCR0_DPI_OE BIT(0)
> > #define DU_MCR0_DI_EN BIT(8)
> >
> > #define DU_DITR0 0x10
> > @@ -216,9 +217,14 @@ static void rzg2l_du_crtc_put(struct
> > rzg2l_du_crtc *rcrtc)
> >
> > static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool
> > start) {
> > + struct rzg2l_du_crtc_state *rstate =
> > +to_rzg2l_crtc_state(rcrtc->crtc.state);
> > struct rzg2l_du_device *rcdu = rcrtc->dev;
> > + u32 val = DU_MCR0_DI_EN;
> >
> > - writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
> > + if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_DPAD0))
>
> Is output supposed to contain a single bit, or can it contain multiple bits ?
> In the first case I
> would rename it to output, in the second case you should probably use '&'
> instead of '=='.
It may contain multiple bits for the future SoCs. So, I will use '&' instead.
>
> > + val |= DU_MCR0_DPI_OE;
> > +
> > + writel(start ? val : 0, rcdu->mmio + DU_MCR0);
> > }
> >
> > static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc) diff
> > --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > index e5eca8691a33..69b8e216ee1a 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > @@ -25,21 +25,35 @@
> > * Device Information
> > */
> >
> > +static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
> > + .channels_mask = BIT(0),
> > + .routes = {
> > + [RZG2L_DU_OUTPUT_DSI0] = {
> > + .du_output = RZG2L_DU_OUTPUT_INVALID,
> > + },
>
> You can drop this entry, as well as the RZG2L_DU_OUTPUT_INVALID macro.
> See below.
OK.
>
> > + [RZG2L_DU_OUTPUT_DPAD0] = {
> > + .possible_outputs = BIT(0),
> > + .du_output = RZG2L_DU_OUTPUT_DPAD0,
> > + },
> > + },
> > +};
> > +
> > static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
> > .channels_mask = BIT(0),
> > .routes = {
> > [RZG2L_DU_OUTPUT_DSI0] = {
> > .possible_outputs = BIT(0),
> > - .port = 0,
> > + .du_output = RZG2L_DU_OUTPUT_DSI0,
> > },
> > [RZG2L_DU_OUTPUT_DPAD0] = {
> > .possible_outputs = BIT(0),
> > - .port = 1,
> > + .du_output = RZG2L_DU_OUTPUT_DPAD0,
> > }
> > }
> > };
RE: [PATCH v3 1/4] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
Hi Laurent and Rob,
Thanks for the feedback
> -Original Message-
> From: Laurent Pinchart
> Sent: Tuesday, August 13, 2024 8:39 PM
> Subject: Re: [PATCH v3 1/4] dt-bindings: display: renesas,rzg2l-du: Document
> RZ/G2UL DU bindings
>
> Hi Rob,
>
> On Tue, Aug 13, 2024 at 10:32:20AM -0600, Rob Herring wrote:
> > On Mon, Aug 05, 2024 at 04:52:35PM +0100, Biju Das wrote:
> > > Document DU found in RZ/G2UL SoC. The DU block is identical to
> > > RZ/G2L SoC, but has only DPI interface.
> > >
> > > While at it, add missing required property port@1 for RZ/G2L and
> > > RZ/V2L SoCs. Currently there is no user for the DPI interface and
> > > hence there won't be any ABI breakage for adding port@1 as required
> > > property for RZ/G2L and RZ/V2L SoCs.
> > >
> > > Signed-off-by: Biju Das
> > > ---
> > > v2->v3:
> > > * Replaced ports->port property for RZ/G2UL as it supports only DPI.
> > >and retained ports property for RZ/{G2L,V2L} as it supports both DSI
> > >and DPI output interface.
> >
> > Why? Having port and ports is just a needless complication.
>
> I agree that making the ports node mandatory, even when the device has a
> single port, will simplify
> the bindings. In hindsight we should never have made ports optional, but that
> can't be changed.
>
> > > * Added missing blank line before example.
> > > * Dropped tags from Conor and Geert as there are new changes.
> > > v1->v2:
> > > * Updated commit description related to non ABI breakage.
> > > * Added Ack from Conor.
> > > ---
> > > .../bindings/display/renesas,rzg2l-du.yaml| 35 +--
> > > 1 file changed, 32 insertions(+), 3 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > index 08e5b9478051..ca01bf26c4c0 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yam
> > > +++ l
> > > @@ -18,6 +18,7 @@ properties:
> > >compatible:
> > > oneOf:
> > >- enum:
> > > + - renesas,r9a07g043u-du # RZ/G2UL
> > >- renesas,r9a07g044-du # RZ/G2{L,LC}
> > >- items:
> > >- enum:
> > > @@ -60,8 +61,9 @@ properties:
> > > $ref: /schemas/graph.yaml#/properties/port
> > > unevaluatedProperties: false
> > >
> > > -required:
> > > - - port@0
> > > + port:
> > > +$ref: /schemas/graph.yaml#/properties/port
> > > +description: Connection to the DU output video port.
> > >
> > > unevaluatedProperties: false
> > >
> > > @@ -83,11 +85,38 @@ required:
> > >- clock-names
> > >- resets
> > >- power-domains
> > > - - ports
> > >- renesas,vsps
> > >
> > > additionalProperties: false
> > >
> > > +allOf:
> > > + - if:
> > > + properties:
> > > +compatible:
> > > + contains:
> > > +const: renesas,r9a07g043u-du
> > > +then:
> > > + properties:
> > > +port:
> > > + description: DPI
> >
> > This is equivalent to 'port@0'. IMO, this case should have a 'port@1'
> > node so that DPI interface is *always* the same port.
>
> That's what Biju did in the previous version, and I recommended to number the
> ports based on hardware
> indices, not types. Mapping port numbers to the hardware documentation makes
> it more consistent for DT
> writers, makes the logic simpler to understand (in my opinion, based on my
> experience with the R-Car
> DU) on the driver side, but most importantly, type-based numbering wouldn't
> scale as SoCs could have
> multiple ports of the same type (we've seen that happening with R-Car).
OK, I will send bindings based on hardware indices.
Cheers,
Biju
>
> > > +
> > > + required:
> > > +- port
> > > +else:
> > > + properties:
> > > +ports:
> > > + properties:
> > > +port@0:
> > > + description: DSI
> > > +port@1:
> > > + description: DPI
> > > +
> > > + required:
> > > +- port@0
> > > +- port@1
> > > + required:
> > > +- ports
> > > +
> > > examples:
> > ># RZ/G2L DU
> > >- |
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH 35/86] drm/renesas/rz-du: Run DRM default client setup
Hi Thomas Zimmermann,
> -Original Message-
> From: Thomas Zimmermann
> Sent: Friday, August 16, 2024 1:23 PM
> Subject: [PATCH 35/86] drm/renesas/rz-du: Run DRM default client setup
>
> Call drm_client_setup() to run the kernel's default client setup for DRM. Set
> fbdev_probe in struct
> drm_driver, so that the client setup can start the common fbdev client.
>
> The rz-du driver specifies a preferred color mode of 32. As this is the
> default if no format has been
> given, leave it out entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Biju Das
Tested-by: Biju Das
Cheers,
Biju
> ---
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> b/drivers/gpu/drm/renesas/rz-
> du/rzg2l_du_drv.c
> index e5eca8691a33..53f9e1b7fa87 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> @@ -13,6 +13,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -68,6 +69,7 @@ DEFINE_DRM_GEM_DMA_FOPS(rzg2l_du_fops);
> static const struct drm_driver rzg2l_du_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .dumb_create= rzg2l_du_dumb_create,
> + DRM_FBDEV_DMA_DRIVER_OPS,
> .fops = &rzg2l_du_fops,
> .name = "rzg2l-du",
> .desc = "Renesas RZ/G2L Display Unit",
> @@ -149,7 +151,7 @@ static int rzg2l_du_probe(struct platform_device *pdev)
>
> drm_info(&rcdu->ddev, "Device %s probed\n", dev_name(&pdev->dev));
>
> - drm_fbdev_dma_setup(&rcdu->ddev, 32);
> + drm_client_setup(&rcdu->ddev, NULL);
>
> return 0;
>
> --
> 2.46.0
[PATCH v3 0/4] Add support for RZ/G2UL Display Unit
This patch series aims to add support for RZ/G2UL DU.
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
The output of LCDC is connected display parallel interface (DPI) and
supports a maximum resolution of WXGA along with 2 RPFs to support the
blending of two picture layers and raster operations (ROPs)
It is similar to LCDC IP on RZ/G2L SoCs, but does not have DSI interface.
v2->v3:
* Split patch series based on subsystem from DU patch series [1].
* Replaced ports->port property for RZ/G2UL as it supports only DPI
and retained ports property for RZ/{G2L,V2L} as it supports both DSI
and DPI output interface.
* Added missing blank line before example.
* Dropped tags from Conor and Geert as there are new changes in bindings
* Avoided the line break in rzg2l_du_start_stop() for rstate.
* Replaced port->du_output in struct rzg2l_du_output_routing and
dropped using the port number to indicate the output type in
rzg2l_du_encoders_init().
* Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info.
[1]
https://lore.kernel.org/all/20240709135152.185042-1-biju.das...@bp.renesas.com/
v1->v2:
* Updated cover letter header "DU IP->Display Unit".
* Updated commit description related to non ABI breakage for patch#3.
* Added Ack from Conor for binding patches.
Biju Das (4):
dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
drm: renesas: rz-du: Add RZ/G2UL DU Support
arm64: dts: renesas: r9a07g043u: Add DU node
arm64: dts: renesas: r9a07g043u11-smarc: Enable DU
.../bindings/display/renesas,rzg2l-du.yaml| 35 +-
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 19 +++
.../boot/dts/renesas/r9a07g043u11-smarc.dts | 109 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 18 ++-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 5 +-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 4 +-
7 files changed, 188 insertions(+), 10 deletions(-)
--
2.43.0
[PATCH v3 2/4] drm: renesas: rz-du: Add RZ/G2UL DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI interface and supports a maximum resolution of WXGA along
with 2 RPFs to support the blending of two picture layers and raster
operations (ROPs).
The DU module is connected to VSPD. Add RZ/G2UL DU support.
Signed-off-by: Biju Das
---
v2->v3:
* Avoided the line break in rzg2l_du_start_stop() for rstate.
* Replaced port->du_output in struct rzg2l_du_output_routing and
dropped using the port number to indicate the output type in
rzg2l_du_encoders_init().
* Updated rzg2l_du_r9a07g043u_info and rzg2l_du_r9a07g044_info
v1->v2:
* No change.
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 8 +++-
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 18 --
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 5 +++--
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 4 ++--
4 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 6e7aac6219be..fd7675c7f181 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,6 +28,7 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
+#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -216,9 +217,14 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
+ struct rzg2l_du_crtc_state *rstate =
to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
+ u32 val = DU_MCR0_DI_EN;
- writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
+ if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_DPAD0))
+ val |= DU_MCR0_DPI_OE;
+
+ writel(start ? val : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index e5eca8691a33..69b8e216ee1a 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -25,21 +25,35 @@
* Device Information
*/
+static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
+ .channels_mask = BIT(0),
+ .routes = {
+ [RZG2L_DU_OUTPUT_DSI0] = {
+ .du_output = RZG2L_DU_OUTPUT_INVALID,
+ },
+ [RZG2L_DU_OUTPUT_DPAD0] = {
+ .possible_outputs = BIT(0),
+ .du_output = RZG2L_DU_OUTPUT_DPAD0,
+ },
+ },
+};
+
static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
.channels_mask = BIT(0),
.routes = {
[RZG2L_DU_OUTPUT_DSI0] = {
.possible_outputs = BIT(0),
- .port = 0,
+ .du_output = RZG2L_DU_OUTPUT_DSI0,
},
[RZG2L_DU_OUTPUT_DPAD0] = {
.possible_outputs = BIT(0),
- .port = 1,
+ .du_output = RZG2L_DU_OUTPUT_DPAD0,
}
}
};
static const struct of_device_id rzg2l_du_of_table[] = {
+ { .compatible = "renesas,r9a07g043u-du", .data =
&rzg2l_du_r9a07g043u_info },
{ .compatible = "renesas,r9a07g044-du", .data =
&rzg2l_du_r9a07g044_info },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
index 58806c2a8f2b..ab82b5c86d6e 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
@@ -29,7 +29,7 @@ enum rzg2l_du_output {
/*
* struct rzg2l_du_output_routing - Output routing specification
* @possible_outputs: bitmask of possible outputs
- * @port: device tree port number corresponding to this output route
+ * @du_output: DU output
*
* The DU has 2 possible outputs (DPAD0, DSI0). Output routing data
* specify the valid SoC outputs, which CRTC can drive the output, and the type
@@ -37,7 +37,7 @@ enum rzg2l_du_output {
*/
struct rzg2l_du_output_routing {
unsigned int possible_outputs;
- unsigned int port;
+ unsigned int du_output;
};
/*
@@ -53,6 +53,7 @@ struct rzg2l_du_device_info {
#define RZG2L_DU_MAX_CRTCS 1
#define RZG2L_DU_MAX_VSPS 1
#define RZG2L_DU_MAX_DSI 1
+#define RZG2L_DU_OUTPUT_INVALID-1
struct rzg2l_du_device {
struct device *dev;
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
index 07b312b6f81e..361350f2999e 100644
--- a/drivers/gpu/drm/re
[PATCH v3 1/4] dt-bindings: display: renesas, rzg2l-du: Document RZ/G2UL DU bindings
Document DU found in RZ/G2UL SoC. The DU block is identical to RZ/G2L
SoC, but has only DPI interface.
While at it, add missing required property port@1 for RZ/G2L and RZ/V2L
SoCs. Currently there is no user for the DPI interface and hence there
won't be any ABI breakage for adding port@1 as required property for
RZ/G2L and RZ/V2L SoCs.
Signed-off-by: Biju Das
---
v2->v3:
* Replaced ports->port property for RZ/G2UL as it supports only DPI.
and retained ports property for RZ/{G2L,V2L} as it supports both DSI
and DPI output interface.
* Added missing blank line before example.
* Dropped tags from Conor and Geert as there are new changes.
v1->v2:
* Updated commit description related to non ABI breakage.
* Added Ack from Conor.
---
.../bindings/display/renesas,rzg2l-du.yaml| 35 +--
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index 08e5b9478051..ca01bf26c4c0 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
oneOf:
- enum:
+ - renesas,r9a07g043u-du # RZ/G2UL
- renesas,r9a07g044-du # RZ/G2{L,LC}
- items:
- enum:
@@ -60,8 +61,9 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
-required:
- - port@0
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+description: Connection to the DU output video port.
unevaluatedProperties: false
@@ -83,11 +85,38 @@ required:
- clock-names
- resets
- power-domains
- - ports
- renesas,vsps
additionalProperties: false
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: renesas,r9a07g043u-du
+then:
+ properties:
+port:
+ description: DPI
+
+ required:
+- port
+else:
+ properties:
+ports:
+ properties:
+port@0:
+ description: DSI
+port@1:
+ description: DPI
+
+ required:
+- port@0
+- port@1
+ required:
+- ports
+
examples:
# RZ/G2L DU
- |
--
2.43.0
RE: [PATCH v2 3/9] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
Hi Laurent Pinchart,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Wednesday, July 31, 2024 2:47 PM
> Subject: Re: [PATCH v2 3/9] dt-bindings: display: renesas,rzg2l-du: Document
> RZ/G2UL DU bindings
>
> Hi Biju,
>
> On Mon, Jul 29, 2024 at 09:05:59AM +, Biju Das wrote:
> > On Saturday, July 27, 2024 1:50 AM, Laurent Pinchart wrote:
> > > On Tue, Jul 09, 2024 at 02:51:41PM +0100, Biju Das wrote:
> > > > Document DU found in RZ/G2UL SoC. The DU block is identical to
> > > > RZ/G2L SoC, but has only DPI interface.
> > > >
> > > > While at it, add missing required property port@1 for RZ/G2L and
> > > > RZ/V2L SoCs. Currently there is no user for the DPI interface and
> > > > hence there won't be any ABI breakage for adding port@1 as
> > > > required property for RZ/G2L and RZ/V2L SoCs.
> > > >
> > > > Signed-off-by: Biju Das
> > > > Acked-by: Conor Dooley
> > > > ---
> > > > v1->v2:
> > > > * Updated commit description related to non ABI breakage.
> > > > * Added Ack from Conor.
> > > > ---
> > > > .../bindings/display/renesas,rzg2l-du.yaml| 32 +--
> > > > 1 file changed, 29 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > index 08e5b9478051..c0fec282fa45 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.y
> > > > +++ aml
> > > > @@ -18,6 +18,7 @@ properties:
> > > >compatible:
> > > > oneOf:
> > > >- enum:
> > > > + - renesas,r9a07g043u-du # RZ/G2UL
> > > >- renesas,r9a07g044-du # RZ/G2{L,LC}
> > > >- items:
> > > >- enum:
> > > > @@ -60,9 +61,6 @@ properties:
> > > > $ref: /schemas/graph.yaml#/properties/port
> > > > unevaluatedProperties: false
> > > >
> > > > -required:
> > > > - - port@0
> > > > -
> > > > unevaluatedProperties: false
> > > >
> > > >renesas,vsps:
> > > > @@ -88,6 +86,34 @@ required:
> > > >
> > > > additionalProperties: false
> > > >
> > > > +allOf:
> > > > + - if:
> > > > + properties:
> > > > +compatible:
> > > > + contains:
> > > > +const: renesas,r9a07g043u-du
> > > > +then:
> > > > + properties:
> > > > +ports:
> > > > + properties:
> > > > +port@0: false
> > > > +port@1:
> > > > + description: DPI
> > > > +
> > > > + required:
> > > > +- port@1
> > >
> > > Why do you use port@1 for the DPI output here, and not port@0 ?
> >
> > Currently the output is based on port number and port = 1 corresponds to
> > DPI. See [1].
> >
> > For consistency, I documented bindings for RZ/G2L family DU's similar to
> > RZ/G2{H,M,N,E} DU [2].
> >
> > So please let me know, are you ok with this?
>
> I won't insist strongly, but I don't think that using the port number to
> indicate the output type is
> the best idea. In the R-Car DU driver at least, that wouldn't have scaled. We
> have multiple outputs of
> the same type on some SoCs. Furthemore, the same DU hardware channel number
> (i.e.
> the offset of the registers specific to that channel in the DU register
> space) is not the same across SoCs for the same output type. I recommend
> numbering the ports based on
> the hardware number of the output (the exact meaning of this is specific to
> your device, I haven't
> checked what it means for RZ/G2L), not on the output type.
OK, will update the bindings to use port for RZ/G2UL and Ports for RZ/{G2L,
V2L} as it has multiple DU outputs.
From the driver will remove using port number to indicate the output type.
- if (rcdu->info->routes[i].port == ep.port) {
- output = i;
+ if (i == rcdu->info->routes[i].du_output) {
+ output = rcdu->info->routes[i].du_output;
Cheers,
Biju
>
> > [1]
> > https://elixir.bootlin.com/linux/v6.10.2/source/drivers/gpu/drm/renesa
> > s/rz-du/rzg2l_du_kms.c#L187
> >
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr
> > ee/Documentation/devicetree/bindings/display/renesas,du.yaml?h=next-20
> > 240729#n546
> >
> > > > +else:
> > > > + properties:
> > > > +ports:
> > > > + properties:
> > > > +port@0:
> > > > + description: DSI
> > > > +port@1:
> > > > + description: DPI
> > > > +
> > > > + required:
> > > > +- port@0
> > > > +- port@1
> > >
> > > You're missing a blank line here.
> >
> > OK, will fix this'
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v2 8/9] arm64: dts: renesas: r9a07g043u: Add DU node
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Saturday, July 27, 2024 2:12 AM
> Subject: Re: [PATCH v2 8/9] arm64: dts: renesas: r9a07g043u: Add DU node
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Jul 09, 2024 at 02:51:46PM +0100, Biju Das wrote:
> > Add DU node to RZ/G2UL SoC DTSI.
> >
> > Signed-off-by: Biju Das
> > ---
> > v1->v2:
> > * No change.
> > ---
> > arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 25
> > +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > index d88bf23b0782..0a4f24d83791 100644
> > --- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > @@ -153,6 +153,31 @@ fcpvd: fcp@1088 {
> > resets = <&cpg R9A07G043_LCDC_RESET_N>;
> > };
> >
> > + du: display@1089 {
> > + compatible = "renesas,r9a07g043u-du";
> > + reg = <0 0x1089 0 0x1>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
> > +<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
> > +<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
> > + clock-names = "aclk", "pclk", "vclk";
> > + power-domains = <&cpg>;
> > + resets = <&cpg R9A07G043_LCDC_RESET_N>;
> > + renesas,vsps = <&vspd 0>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + reg = <1>;
>
> This may need to change depending on the outcome of the DT bindings
> discussion. Other than that,
Agreed.
Cheers,
Biju
>
> Reviewed-by: Laurent Pinchart
>
> > + du_out_rgb: endpoint {
> > + };
> > + };
> > + };
> > + };
> > +
> > irqc: interrupt-controller@110a {
> > compatible = "renesas,r9a07g043u-irqc",
> > "renesas,rzg2l-irqc";
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v2 6/9] arm64: dts: renesas: r9a07g043u: Add vspd node
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Saturday, July 27, 2024 2:08 AM
> Subject: Re: [PATCH v2 6/9] arm64: dts: renesas: r9a07g043u: Add vspd node
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Jul 09, 2024 at 02:51:44PM +0100, Biju Das wrote:
> > Add vspd node to RZ/G2UL SoC DTSI.
> >
> > Signed-off-by: Biju Das
> > ---
> > v1->v2:
> > * No change.
> > ---
> > arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > index 18ef297db933..15e84a5428ef 100644
> > --- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
> > @@ -129,6 +129,19 @@ csi2cru: endpoint@0 {
> > };
> > };
> >
> > + vspd: vsp@1087 {
> > + compatible = "renesas,r9a07g043u-vsp2",
> > "renesas,r9a07g044-vsp2";
> > + reg = <0 0x1087 0 0x1>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
> > +<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
> > +<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
> > + clock-names = "aclk", "pclk", "vclk";
> > + power-domains = <&cpg>;
> > + resets = <&cpg R9A07G043_LCDC_RESET_N>;
> > + renesas,fcp = <&fcpvd>;
>
> This patch looks fine, but I would move it after 7/9, as here you reference a
> node that doesn't exist
> yet.
Good catch. Will fix this in next version.
Cheers,
Biju
>
> Reviewed-by: Laurent Pinchart
>
> > + };
> > +
> > irqc: interrupt-controller@110a {
> > compatible = "renesas,r9a07g043u-irqc",
> > "renesas,rzg2l-irqc";
>
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH v2 5/9] drm: renesas: rz-du: Add RZ/G2UL DU Support
Hi Laurent,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Saturday, July 27, 2024 2:00 AM
> Subject: Re: [PATCH v2 5/9] drm: renesas: rz-du: Add RZ/G2UL DU Support
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Jul 09, 2024 at 02:51:43PM +0100, Biju Das wrote:
> > The LCD controller is composed of Frame Compression Processor (FCPVD),
> > Video Signal Processor (VSPD), and Display Unit (DU).
> >
> > It has DPI interface and supports a maximum resolution of WXGA along
> > with 2 RPFs to support the blending of two picture layers and raster
> > operations (ROPs).
> >
> > The DU module is connected to VSPD. Add RZ/G2UL DU support.
> >
> > Signed-off-by: Biju Das
> > ---
> > v1->v2:
> > * No change.
> > ---
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 9 -
> > drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 +++
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > index 6e7aac6219be..b1812f947252 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> > @@ -28,6 +28,7 @@
> > #include "rzg2l_du_vsp.h"
> >
> > #define DU_MCR00x00
> > +#define DU_MCR0_DPI_OE BIT(0)
> > #define DU_MCR0_DI_EN BIT(8)
> >
> > #define DU_DITR0 0x10
> > @@ -216,9 +217,15 @@ static void rzg2l_du_crtc_put(struct
> > rzg2l_du_crtc *rcrtc)
> >
> > static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool
> > start) {
> > + struct rzg2l_du_crtc_state *rstate =
> > + to_rzg2l_crtc_state(rcrtc->crtc.state);
>
> I think you can avoid the line break here.
OK, I will make it inlined.
>
> > struct rzg2l_du_device *rcdu = rcrtc->dev;
> > + u32 val = DU_MCR0_DI_EN;
> >
> > - writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
> > + if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_DPAD0))
> > + val |= DU_MCR0_DPI_OE;
> > +
> > + writel(start ? val : 0, rcdu->mmio + DU_MCR0);
> > }
> >
> > static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc) diff
> > --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > index e5eca8691a33..34534441b7ec 100644
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> > @@ -25,6 +25,16 @@
> > * Device Information
> > */
> >
> > +static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
> > + .channels_mask = BIT(0),
> > + .routes = {
> > + [RZG2L_DU_OUTPUT_DPAD0] = {
> > + .possible_outputs = BIT(0),
> > + .port = 1,
>
> This may need to be port 0 depending on the outcome of the discussion on the
> DT bindings.
Agreed.
Cheers,
Biju
RE: [PATCH v2 3/9] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
Hi Laurent Pinchart,
Thanks for the feedback.
> -Original Message-
> From: Laurent Pinchart
> Sent: Saturday, July 27, 2024 1:50 AM
> Subject: Re: [PATCH v2 3/9] dt-bindings: display: renesas,rzg2l-du: Document
> RZ/G2UL DU bindings
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Tue, Jul 09, 2024 at 02:51:41PM +0100, Biju Das wrote:
> > Document DU found in RZ/G2UL SoC. The DU block is identical to RZ/G2L
> > SoC, but has only DPI interface.
> >
> > While at it, add missing required property port@1 for RZ/G2L and
> > RZ/V2L SoCs. Currently there is no user for the DPI interface and
> > hence there won't be any ABI breakage for adding port@1 as required
> > property for RZ/G2L and RZ/V2L SoCs.
> >
> > Signed-off-by: Biju Das
> > Acked-by: Conor Dooley
> > ---
> > v1->v2:
> > * Updated commit description related to non ABI breakage.
> > * Added Ack from Conor.
> > ---
> > .../bindings/display/renesas,rzg2l-du.yaml| 32 +--
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > index 08e5b9478051..c0fec282fa45 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > @@ -18,6 +18,7 @@ properties:
> >compatible:
> > oneOf:
> >- enum:
> > + - renesas,r9a07g043u-du # RZ/G2UL
> >- renesas,r9a07g044-du # RZ/G2{L,LC}
> >- items:
> >- enum:
> > @@ -60,9 +61,6 @@ properties:
> > $ref: /schemas/graph.yaml#/properties/port
> > unevaluatedProperties: false
> >
> > -required:
> > - - port@0
> > -
> > unevaluatedProperties: false
> >
> >renesas,vsps:
> > @@ -88,6 +86,34 @@ required:
> >
> > additionalProperties: false
> >
> > +allOf:
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: renesas,r9a07g043u-du
> > +then:
> > + properties:
> > +ports:
> > + properties:
> > +port@0: false
> > +port@1:
> > + description: DPI
> > +
> > + required:
> > +- port@1
>
> Why do you use port@1 for the DPI output here, and not port@0 ?
Currently the output is based on port number and port = 1 corresponds to DPI.
See [1].
For consistency, I documented bindings for RZ/G2L family DU's similar to
RZ/G2{H,M,N,E} DU [2].
So please let me know, are you ok with this?
[1]
https://elixir.bootlin.com/linux/v6.10.2/source/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c#L187
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/display/renesas,du.yaml?h=next-20240729#n546
>
> > +else:
> > + properties:
> > +ports:
> > + properties:
> > +port@0:
> > + description: DSI
> > +port@1:
> > + description: DPI
> > +
> > + required:
> > +- port@0
> > +- port@1
>
> You're missing a blank line here.
OK, will fix this'
Cheers,
Biju
[PATCH v2 9/9] arm64: dts: renesas: r9a07g043u11-smarc: Enable DU
Enable DU and link with the HDMI add-on board connected with
the parallel connector on RZ/G2UL SMARC EVK.
Signed-off-by: Biju Das
---
v1->v2:
* No change.
---
.../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
b/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
index 8e0107df2d46..dda37cf4d3fd 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
@@ -35,4 +35,115 @@
/ {
model = "Renesas SMARC EVK based on r9a07g043u11";
compatible = "renesas,smarc-evk", "renesas,r9a07g043u11",
"renesas,r9a07g043";
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "d";
+
+ port {
+ hdmi_con_out: endpoint {
+ remote-endpoint = <&adv7513_out>;
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ ports {
+ port@1 {
+ du_out_rgb: endpoint {
+ remote-endpoint = <&adv7513_in>;
+ };
+ };
+ };
+};
+
+&i2c1 {
+ adv7513: adv7513@39 {
+ compatible = "adi,adv7513";
+ reg = <0x39>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+
+ avdd-supply = <®_1p8v>;
+ dvdd-supply = <®_1p8v>;
+ pvdd-supply = <®_1p8v>;
+ dvdd-3v-supply = <®_3p3v>;
+ bgvdd-supply = <®_1p8v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ adv7513_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ adv7513_out: endpoint {
+ remote-endpoint = <&hdmi_con_out>;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ du_pins: du {
+ data {
+ pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ drive-strength = <2>;
+ };
+
+ sync {
+ pinmux = , /* HSYNC */
+; /* VSYNC */
+ drive-strength = <2>;
+ };
+
+ de {
+ pinmux = ; /* DE */
+ drive-strength = <2>;
+ };
+
+ clk {
+ pinmux = ; /* CLK */
+ };
+ };
};
--
2.43.0
[PATCH v2 8/9] arm64: dts: renesas: r9a07g043u: Add DU node
Add DU node to RZ/G2UL SoC DTSI.
Signed-off-by: Biju Das
---
v1->v2:
* No change.
---
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
index d88bf23b0782..0a4f24d83791 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
@@ -153,6 +153,31 @@ fcpvd: fcp@1088 {
resets = <&cpg R9A07G043_LCDC_RESET_N>;
};
+ du: display@1089 {
+ compatible = "renesas,r9a07g043u-du";
+ reg = <0 0x1089 0 0x1>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G043_LCDC_RESET_N>;
+ renesas,vsps = <&vspd 0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ du_out_rgb: endpoint {
+ };
+ };
+ };
+ };
+
irqc: interrupt-controller@110a {
compatible = "renesas,r9a07g043u-irqc",
"renesas,rzg2l-irqc";
--
2.43.0
[PATCH v2 7/9] arm64: dts: renesas: r9a07g043u: Add fcpvd node
Add fcpvd node to RZ/G2UL SoC DTSI.
Signed-off-by: Biju Das
---
v1->v2:
* No change.
---
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
index 15e84a5428ef..d88bf23b0782 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
@@ -142,6 +142,17 @@ vspd: vsp@1087 {
renesas,fcp = <&fcpvd>;
};
+ fcpvd: fcp@1088 {
+ compatible = "renesas,r9a07g043u-fcpvd", "renesas,fcpv";
+ reg = <0 0x1088 0 0x1>;
+ clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G043_LCDC_RESET_N>;
+ };
+
irqc: interrupt-controller@110a {
compatible = "renesas,r9a07g043u-irqc",
"renesas,rzg2l-irqc";
--
2.43.0
[PATCH v2 6/9] arm64: dts: renesas: r9a07g043u: Add vspd node
Add vspd node to RZ/G2UL SoC DTSI.
Signed-off-by: Biju Das
---
v1->v2:
* No change.
---
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
index 18ef297db933..15e84a5428ef 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
@@ -129,6 +129,19 @@ csi2cru: endpoint@0 {
};
};
+ vspd: vsp@1087 {
+ compatible = "renesas,r9a07g043u-vsp2",
"renesas,r9a07g044-vsp2";
+ reg = <0 0x1087 0 0x1>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G043_LCDC_RESET_N>;
+ renesas,fcp = <&fcpvd>;
+ };
+
irqc: interrupt-controller@110a {
compatible = "renesas,r9a07g043u-irqc",
"renesas,rzg2l-irqc";
--
2.43.0
[PATCH v2 5/9] drm: renesas: rz-du: Add RZ/G2UL DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI interface and supports a maximum resolution of WXGA along
with 2 RPFs to support the blending of two picture layers and raster
operations (ROPs).
The DU module is connected to VSPD. Add RZ/G2UL DU support.
Signed-off-by: Biju Das
---
v1->v2:
* No change.
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 9 -
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 6e7aac6219be..b1812f947252 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,6 +28,7 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
+#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -216,9 +217,15 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
+ struct rzg2l_du_crtc_state *rstate =
+ to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
+ u32 val = DU_MCR0_DI_EN;
- writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
+ if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_DPAD0))
+ val |= DU_MCR0_DPI_OE;
+
+ writel(start ? val : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index e5eca8691a33..34534441b7ec 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -25,6 +25,16 @@
* Device Information
*/
+static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
+ .channels_mask = BIT(0),
+ .routes = {
+ [RZG2L_DU_OUTPUT_DPAD0] = {
+ .possible_outputs = BIT(0),
+ .port = 1,
+ },
+ },
+};
+
static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
.channels_mask = BIT(0),
.routes = {
@@ -40,6 +50,7 @@ static const struct rzg2l_du_device_info
rzg2l_du_r9a07g044_info = {
};
static const struct of_device_id rzg2l_du_of_table[] = {
+ { .compatible = "renesas,r9a07g043u-du", .data =
&rzg2l_du_r9a07g043u_info },
{ .compatible = "renesas,r9a07g044-du", .data =
&rzg2l_du_r9a07g044_info },
{ /* sentinel */ }
};
--
2.43.0
[PATCH v2 3/9] dt-bindings: display: renesas, rzg2l-du: Document RZ/G2UL DU bindings
Document DU found in RZ/G2UL SoC. The DU block is identical to RZ/G2L
SoC, but has only DPI interface.
While at it, add missing required property port@1 for RZ/G2L and RZ/V2L
SoCs. Currently there is no user for the DPI interface and hence there
won't be any ABI breakage for adding port@1 as required property for
RZ/G2L and RZ/V2L SoCs.
Signed-off-by: Biju Das
Acked-by: Conor Dooley
---
v1->v2:
* Updated commit description related to non ABI breakage.
* Added Ack from Conor.
---
.../bindings/display/renesas,rzg2l-du.yaml| 32 +--
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index 08e5b9478051..c0fec282fa45 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
oneOf:
- enum:
+ - renesas,r9a07g043u-du # RZ/G2UL
- renesas,r9a07g044-du # RZ/G2{L,LC}
- items:
- enum:
@@ -60,9 +61,6 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
-required:
- - port@0
-
unevaluatedProperties: false
renesas,vsps:
@@ -88,6 +86,34 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: renesas,r9a07g043u-du
+then:
+ properties:
+ports:
+ properties:
+port@0: false
+port@1:
+ description: DPI
+
+ required:
+- port@1
+else:
+ properties:
+ports:
+ properties:
+port@0:
+ description: DSI
+port@1:
+ description: DPI
+
+ required:
+- port@0
+- port@1
examples:
# RZ/G2L DU
- |
--
2.43.0
[PATCH v2 0/9] Add support for RZ/G2UL Display Unit
This patch series aims to add support for RZ/G2UL DU. The LCD controller is composed of Frame Compression Processor (FCPVD), Video Signal Processor (VSPD), and Display Unit (DU). The output of LCDC is connected display parallel interface (DPI) and supports a maximum resolution of WXGA along with 2 RPFs to support the blending of two picture layers and raster operations (ROPs) It is similar to LCDC IP on RZ/G2L SoCs, but does not have DSI interface. v1->v2: * Updated cover letter header "DU IP->Display Unit". * Updated commit description related to non ABI breakage for patch#3. * Added Ack from Conor for binding patches. Biju Das (9): media: dt-bindings: media: renesas,vsp1: Document RZ/G2UL VSPD bindings media: dt-bindings: media: renesas,fcp: Document RZ/G2UL FCPVD bindings dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings clk: renesas: r9a07g043: Add LCDC clock and reset entries drm: renesas: rz-du: Add RZ/G2UL DU Support arm64: dts: renesas: r9a07g043u: Add vspd node arm64: dts: renesas: r9a07g043u: Add fcpvd node arm64: dts: renesas: r9a07g043u: Add DU node arm64: dts: renesas: r9a07g043u11-smarc: Enable DU .../bindings/display/renesas,rzg2l-du.yaml| 32 - .../bindings/media/renesas,fcp.yaml | 2 + .../bindings/media/renesas,vsp1.yaml | 1 + arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 49 .../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++ drivers/clk/renesas/r9a07g043-cpg.c | 12 ++ drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 9 +- drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 ++ 8 files changed, 223 insertions(+), 4 deletions(-) -- 2.43.0
RE: [PATCH] drm: renesas: shmobile: shmo_drm_crtc: Fix PM imbalance if RPM_ACTIVE is true
Hi Maxime, > -Original Message- > From: Biju Das > Sent: Monday, July 8, 2024 10:01 AM > Subject: RE: [PATCH] drm: renesas: shmobile: shmo_drm_crtc: Fix PM imbalance > if RPM_ACTIVE is true > > Hi Maxime, > > > -Original Message- > > From: Maxime Ripard > > Sent: Monday, July 8, 2024 9:54 AM > > Subject: Re: [PATCH] drm: renesas: shmobile: shmo_drm_crtc: Fix PM > > imbalance if RPM_ACTIVE is true > > > > Hi, > > > > On Mon, Jul 08, 2024 at 09:27:09AM GMT, Biju Das wrote: > > > The pm_runtime_resume_and_get() returns 1 if RPM is active, in this > > > case it won't call a put. This will result in PM imbalance as it > > > treat this as an error and propagate this to caller and the caller > > > never calls corresponding put(). Fix this issue by checking error > > > condition only. > > > > > > Signed-off-by: Biju Das > > > --- > > > drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > > b/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > > index 2e2f37b9d0a4..42a5d6876bec 100644 > > > --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > > +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > > @@ -208,7 +208,7 @@ static void shmob_drm_crtc_atomic_enable(struct > > > drm_crtc *crtc, > > > int ret; > > > > > > ret = pm_runtime_resume_and_get(dev); > > > - if (ret) > > > + if (ret < 0) > > > return; > > > > The documentation of pm_runtime_resume_and_get says that: > > > > Resume @dev synchronously and if that is successful, increment its > > runtime PM usage counter. Return 0 if the runtime PM usage counter of > > @dev has been incremented or a negative error code otherwise. > > > > So it looks like it can't return 1, ever. Are you sure you're not > > confusing pm_runtime_resume_and_get with pm_runtime_get? > > It should be ret < 0 as ret = 1 corresponds to RPM_ACTIVE and the API does > not call put() when ret = > 1; see [1] and [2] > > [1] > https://elixir.bootlin.com/linux/v6.10-rc6/source/drivers/base/power/runtime.c#L778 > > [2] > https://elixir.bootlin.com/linux/v6.10-rc6/source/include/linux/pm_runtime.h#L431 > > Am I miss anything? Please let me know. the code for pm_runtime_resume_and_get() seems correct. Sorry for the noisy patch. https://elixir.bootlin.com/linux/latest/source/include/linux/pm_runtime.h#L436 Cheers, Biju
RE: [PATCH] drm: renesas: rcar-du: rcar_lvds: Fix PM imbalance if RPM_ACTIVE
Hi Geert, > -Original Message- > From: Geert Uytterhoeven > Sent: Monday, July 8, 2024 10:11 AM > Subject: Re: [PATCH] drm: renesas: rcar-du: rcar_lvds: Fix PM imbalance if > RPM_ACTIVE > > Hi Biju, > > On Mon, Jul 8, 2024 at 10:22 AM Biju Das wrote: > > The pm_runtime_resume_and_get() returns 1 if RPM is active, in this > > case it won't call a put. This will result in PM imbalance as it treat > > this as an error and propagate this to caller and the caller never > > calls corresponding put(). Fix this issue by checking error condition > > only. > > > > Signed-off-by: Biju Das > > Thanks for your patch, but the code for pm_runtime_resume_and_get() seems to > disagree? > https://elixir.bootlin.com/linux/latest/source/include/linux/pm_runtime.h#L436 Oops. Missed that. Sorry for the noisy patch. Cheers, Biju
RE: [PATCH] drm: renesas: shmobile: shmo_drm_crtc: Fix PM imbalance if RPM_ACTIVE is true
Hi Maxime, > -Original Message- > From: Maxime Ripard > Sent: Monday, July 8, 2024 9:54 AM > Subject: Re: [PATCH] drm: renesas: shmobile: shmo_drm_crtc: Fix PM imbalance > if RPM_ACTIVE is true > > Hi, > > On Mon, Jul 08, 2024 at 09:27:09AM GMT, Biju Das wrote: > > The pm_runtime_resume_and_get() returns 1 if RPM is active, in this > > case it won't call a put. This will result in PM imbalance as it treat > > this as an error and propagate this to caller and the caller never > > calls corresponding put(). Fix this issue by checking error condition > > only. > > > > Signed-off-by: Biju Das > > --- > > drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > b/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > index 2e2f37b9d0a4..42a5d6876bec 100644 > > --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c > > @@ -208,7 +208,7 @@ static void shmob_drm_crtc_atomic_enable(struct > > drm_crtc *crtc, > > int ret; > > > > ret = pm_runtime_resume_and_get(dev); > > - if (ret) > > + if (ret < 0) > > return; > > The documentation of pm_runtime_resume_and_get says that: > > Resume @dev synchronously and if that is successful, increment its > runtime PM usage counter. Return 0 if the runtime PM usage counter of > @dev has been incremented or a negative error code otherwise. > > So it looks like it can't return 1, ever. Are you sure you're not confusing > pm_runtime_resume_and_get > with pm_runtime_get? It should be ret < 0 as ret = 1 corresponds to RPM_ACTIVE and the API does not call put() when ret = 1; see [1] and [2] [1] https://elixir.bootlin.com/linux/v6.10-rc6/source/drivers/base/power/runtime.c#L778 [2] https://elixir.bootlin.com/linux/v6.10-rc6/source/include/linux/pm_runtime.h#L431 Am I miss anything? Please let me know. Cheers, Biju
[PATCH] drm: renesas: shmobile: shmo_drm_crtc: Fix PM imbalance if RPM_ACTIVE is true
The pm_runtime_resume_and_get() returns 1 if RPM is active, in this case it won't call a put. This will result in PM imbalance as it treat this as an error and propagate this to caller and the caller never calls corresponding put(). Fix this issue by checking error condition only. Signed-off-by: Biju Das --- drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c b/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c index 2e2f37b9d0a4..42a5d6876bec 100644 --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c @@ -208,7 +208,7 @@ static void shmob_drm_crtc_atomic_enable(struct drm_crtc *crtc, int ret; ret = pm_runtime_resume_and_get(dev); - if (ret) + if (ret < 0) return; /* Reset and enable the LCDC. */ -- 2.43.0
[PATCH] drm: renesas: rcar-du: rcar_lvds: Fix PM imbalance if RPM_ACTIVE
The pm_runtime_resume_and_get() returns 1 if RPM is active, in this case it won't call a put. This will result in PM imbalance as it treat this as an error and propagate this to caller and the caller never calls corresponding put(). Fix this issue by checking error condition only. Signed-off-by: Biju Das --- drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c b/drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c index 92ba43a6fe38..471a2d3bc203 100644 --- a/drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c @@ -361,7 +361,7 @@ static void rcar_lvds_enable(struct drm_bridge *bridge, int ret; ret = pm_runtime_resume_and_get(lvds->dev); - if (ret) + if (ret < 0) return; /* Enable the companion LVDS encoder in dual-link mode. */ @@ -550,7 +550,7 @@ int rcar_lvds_pclk_enable(struct drm_bridge *bridge, unsigned long freq, dev_dbg(lvds->dev, "enabling LVDS PLL, freq=%luHz\n", freq); ret = pm_runtime_resume_and_get(lvds->dev); - if (ret) + if (ret < 0) return ret; rcar_lvds_pll_setup_d3_e3(lvds, freq, dot_clk_only); -- 2.43.0
RE: [PATCH 3/9] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
Hi Conor, > -Original Message- > From: Conor Dooley > Sent: Tuesday, July 2, 2024 4:36 PM > To: Biju Das > Subject: Re: [PATCH 3/9] dt-bindings: display: renesas,rzg2l-du: Document > RZ/G2UL DU bindings > > On Tue, Jul 02, 2024 at 03:33:17PM +, Biju Das wrote: > > Hi Conor, > > > > Thanks for the feedback. > > > > > -Original Message- > > > From: Conor Dooley > > > Sent: Tuesday, July 2, 2024 3:51 PM > > > Subject: Re: [PATCH 3/9] dt-bindings: display: renesas,rzg2l-du: > > > Document RZ/G2UL DU bindings > > > > > > On Tue, Jul 02, 2024 at 10:46:13AM +0100, Biju Das wrote: > > > > Document DU found in RZ/G2UL SoC. The DU block is identical to > > > > RZ/G2L SoC, but has only DPI interface. > > > > > > > > While at it, add missing required property port@1 for RZ/G2L and > > > > RZ/V2L SoCs. > > > > > > A new required property is an ABI break, it deserves more of an > > > explanation than "in passing..." > > > > RZ/G2L LCDC documents both port@0 and port@1 that is described here in > > [1] > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > > ee/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml?h=n > > ext-20240702#n59 > > > > Unfortunately missed to add port@1 as required property. > > > > Currently there is no user for the DPI interface and there is no DPI > > interface support in display driver. So, there is nothing for ABI > > breakage. > > > > I will mention in the commit description that "currently there is no > > user for the DPI interface and hence there won't be any ABI breakage > > for adding > > port@1 as required property for RZ/G2L and RZ/V2L SoCs". > > That seems reasonable. You can add my Acked-by with that wording update. OK, will do. Thanks, Biju
RE: [PATCH 3/9] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
Hi Conor,
Thanks for the feedback.
> -Original Message-
> From: Conor Dooley
> Sent: Tuesday, July 2, 2024 3:51 PM
> Subject: Re: [PATCH 3/9] dt-bindings: display: renesas,rzg2l-du: Document
> RZ/G2UL DU bindings
>
> On Tue, Jul 02, 2024 at 10:46:13AM +0100, Biju Das wrote:
> > Document DU found in RZ/G2UL SoC. The DU block is identical to RZ/G2L
> > SoC, but has only DPI interface.
> >
> > While at it, add missing required property port@1 for RZ/G2L and
> > RZ/V2L SoCs.
>
> A new required property is an ABI break, it deserves more of an explanation
> than "in passing..."
RZ/G2L LCDC documents both port@0 and port@1 that is described here in [1]
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml?h=next-20240702#n59
Unfortunately missed to add port@1 as required property.
Currently there is no user for the DPI interface and there is
no DPI interface support in display driver. So, there is nothing
for ABI breakage.
I will mention in the commit description that
"currently there is no user for the DPI interface
and hence there won't be any ABI breakage for adding
port@1 as required property for RZ/G2L and RZ/V2L SoCs".
Cheers,
Biju
>
> >
> > Signed-off-by: Biju Das
> > ---
> > .../bindings/display/renesas,rzg2l-du.yaml| 32 +--
> > 1 file changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > index 08e5b9478051..c0fec282fa45 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > @@ -18,6 +18,7 @@ properties:
> >compatible:
> > oneOf:
> >- enum:
> > + - renesas,r9a07g043u-du # RZ/G2UL
> >- renesas,r9a07g044-du # RZ/G2{L,LC}
> >- items:
> >- enum:
> > @@ -60,9 +61,6 @@ properties:
> > $ref: /schemas/graph.yaml#/properties/port
> > unevaluatedProperties: false
> >
> > -required:
> > - - port@0
> > -
> > unevaluatedProperties: false
> >
> >renesas,vsps:
> > @@ -88,6 +86,34 @@ required:
> >
> > additionalProperties: false
> >
> > +allOf:
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: renesas,r9a07g043u-du
> > +then:
> > + properties:
> > +ports:
> > + properties:
> > +port@0: false
> > +port@1:
> > + description: DPI
> > +
> > + required:
> > +- port@1
> > +else:
> > + properties:
> > +ports:
> > + properties:
> > +port@0:
> > + description: DSI
> > +port@1:
> > + description: DPI
> > +
> > + required:
> > +- port@0
> > +- port@1
> > examples:
> ># RZ/G2L DU
> >- |
> > --
> > 2.43.0
> >
[PATCH 9/9] arm64: dts: renesas: r9a07g043u11-smarc: Enable DU
Enable DU and link with the HDMI add-on board connected with
the parallel connector on RZ/G2UL SMARC EVK.
Signed-off-by: Biju Das
---
.../boot/dts/renesas/r9a07g043u11-smarc.dts | 111 ++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
b/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
index 8e0107df2d46..dda37cf4d3fd 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u11-smarc.dts
@@ -35,4 +35,115 @@
/ {
model = "Renesas SMARC EVK based on r9a07g043u11";
compatible = "renesas,smarc-evk", "renesas,r9a07g043u11",
"renesas,r9a07g043";
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "d";
+
+ port {
+ hdmi_con_out: endpoint {
+ remote-endpoint = <&adv7513_out>;
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ ports {
+ port@1 {
+ du_out_rgb: endpoint {
+ remote-endpoint = <&adv7513_in>;
+ };
+ };
+ };
+};
+
+&i2c1 {
+ adv7513: adv7513@39 {
+ compatible = "adi,adv7513";
+ reg = <0x39>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+
+ avdd-supply = <®_1p8v>;
+ dvdd-supply = <®_1p8v>;
+ pvdd-supply = <®_1p8v>;
+ dvdd-3v-supply = <®_3p3v>;
+ bgvdd-supply = <®_1p8v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ adv7513_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ adv7513_out: endpoint {
+ remote-endpoint = <&hdmi_con_out>;
+ };
+ };
+ };
+ };
+};
+
+&pinctrl {
+ du_pins: du {
+ data {
+ pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ drive-strength = <2>;
+ };
+
+ sync {
+ pinmux = , /* HSYNC */
+; /* VSYNC */
+ drive-strength = <2>;
+ };
+
+ de {
+ pinmux = ; /* DE */
+ drive-strength = <2>;
+ };
+
+ clk {
+ pinmux = ; /* CLK */
+ };
+ };
};
--
2.43.0
[PATCH 8/9] arm64: dts: renesas: r9a07g043u: Add DU node
Add DU node to RZ/G2UL SoC DTSI.
Signed-off-by: Biju Das
---
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
index d88bf23b0782..0a4f24d83791 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
@@ -153,6 +153,31 @@ fcpvd: fcp@1088 {
resets = <&cpg R9A07G043_LCDC_RESET_N>;
};
+ du: display@1089 {
+ compatible = "renesas,r9a07g043u-du";
+ reg = <0 0x1089 0 0x1>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G043_LCDC_RESET_N>;
+ renesas,vsps = <&vspd 0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ du_out_rgb: endpoint {
+ };
+ };
+ };
+ };
+
irqc: interrupt-controller@110a {
compatible = "renesas,r9a07g043u-irqc",
"renesas,rzg2l-irqc";
--
2.43.0
[PATCH 7/9] arm64: dts: renesas: r9a07g043u: Add fcpvd node
Add fcpvd node to RZ/G2UL SoC DTSI.
Signed-off-by: Biju Das
---
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
index 15e84a5428ef..d88bf23b0782 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
@@ -142,6 +142,17 @@ vspd: vsp@1087 {
renesas,fcp = <&fcpvd>;
};
+ fcpvd: fcp@1088 {
+ compatible = "renesas,r9a07g043u-fcpvd", "renesas,fcpv";
+ reg = <0 0x1088 0 0x1>;
+ clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G043_LCDC_RESET_N>;
+ };
+
irqc: interrupt-controller@110a {
compatible = "renesas,r9a07g043u-irqc",
"renesas,rzg2l-irqc";
--
2.43.0
[PATCH 6/9] arm64: dts: renesas: r9a07g043u: Add vspd node
Add vspd node to RZ/G2UL SoC DTSI.
Signed-off-by: Biju Das
---
arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
index 18ef297db933..15e84a5428ef 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi
@@ -129,6 +129,19 @@ csi2cru: endpoint@0 {
};
};
+ vspd: vsp@1087 {
+ compatible = "renesas,r9a07g043u-vsp2",
"renesas,r9a07g044-vsp2";
+ reg = <0 0x1087 0 0x1>;
+ interrupts = ;
+ clocks = <&cpg CPG_MOD R9A07G043_LCDC_CLK_A>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_P>,
+<&cpg CPG_MOD R9A07G043_LCDC_CLK_D>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ resets = <&cpg R9A07G043_LCDC_RESET_N>;
+ renesas,fcp = <&fcpvd>;
+ };
+
irqc: interrupt-controller@110a {
compatible = "renesas,r9a07g043u-irqc",
"renesas,rzg2l-irqc";
--
2.43.0
[PATCH 5/9] drm: renesas: rz-du: Add RZ/G2UL DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI interface and supports a maximum resolution of WXGA along
with 2 RPFs to support the blending of two picture layers and raster
operations (ROPs).
The DU module is connected to VSPD. Add RZ/G2UL DU support.
Signed-off-by: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 9 -
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 11 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 6e7aac6219be..b1812f947252 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,6 +28,7 @@
#include "rzg2l_du_vsp.h"
#define DU_MCR00x00
+#define DU_MCR0_DPI_OE BIT(0)
#define DU_MCR0_DI_EN BIT(8)
#define DU_DITR0 0x10
@@ -216,9 +217,15 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
{
+ struct rzg2l_du_crtc_state *rstate =
+ to_rzg2l_crtc_state(rcrtc->crtc.state);
struct rzg2l_du_device *rcdu = rcrtc->dev;
+ u32 val = DU_MCR0_DI_EN;
- writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
+ if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_DPAD0))
+ val |= DU_MCR0_DPI_OE;
+
+ writel(start ? val : 0, rcdu->mmio + DU_MCR0);
}
static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index e5eca8691a33..34534441b7ec 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -25,6 +25,16 @@
* Device Information
*/
+static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
+ .channels_mask = BIT(0),
+ .routes = {
+ [RZG2L_DU_OUTPUT_DPAD0] = {
+ .possible_outputs = BIT(0),
+ .port = 1,
+ },
+ },
+};
+
static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
.channels_mask = BIT(0),
.routes = {
@@ -40,6 +50,7 @@ static const struct rzg2l_du_device_info
rzg2l_du_r9a07g044_info = {
};
static const struct of_device_id rzg2l_du_of_table[] = {
+ { .compatible = "renesas,r9a07g043u-du", .data =
&rzg2l_du_r9a07g043u_info },
{ .compatible = "renesas,r9a07g044-du", .data =
&rzg2l_du_r9a07g044_info },
{ /* sentinel */ }
};
--
2.43.0
