This patchset adds support for the LVDS encoder inside R-Car M3-W+ SoC.
Hardware is the same as on other R-Car Gen-3 chips.
Nikita Yushchenko (3):
drm: rcar-du: lvds: Add r8a77961 support
arm64: dts: renesas: r8a77961: Add lvds0 device node
dt-bindings: display: bridge: renesas,lvds: Document r8a77961 bindings
.../bindings/display/bridge/renesas,lvds.yaml | 1 +
arch/arm64/boot/dts/renesas/r8a77961.dtsi | 27 +++++++++++++++++++
drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
3 files changed, 29 insertions(+)
--
2.30.2
The M3-W+ SoC has the same LVDS encoder as other R-Car Gen3 chips.
Add support for M3-W+ (R8A77961) SoC to the LVDS encoder driver.
Signed-off-by: Nikita Yushchenko <[email protected]>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 72a272cfc11e..8dbfbbd3cad1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -901,6 +901,7 @@ static const struct of_device_id rcar_lvds_of_table[] = {
{ .compatible = "renesas,r8a7793-lvds", .data = &rcar_lvds_gen2_info },
{ .compatible = "renesas,r8a7795-lvds", .data = &rcar_lvds_gen3_info },
{ .compatible = "renesas,r8a7796-lvds", .data = &rcar_lvds_gen3_info },
+ { .compatible = "renesas,r8a77961-lvds", .data = &rcar_lvds_gen3_info },
{ .compatible = "renesas,r8a77965-lvds", .data = &rcar_lvds_gen3_info },
{ .compatible = "renesas,r8a77970-lvds", .data = &rcar_lvds_r8a77970_info },
{ .compatible = "renesas,r8a77980-lvds", .data = &rcar_lvds_gen3_info },
--
2.30.2
Add the missing lvds0 node for the R-Car M3-W+ SoC.
Signed-off-by: Nikita Yushchenko <[email protected]>
---
arch/arm64/boot/dts/renesas/r8a77961.dtsi | 27 +++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index 86d59e7e1a87..a34d5b1d6431 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -2718,6 +2718,33 @@ du_out_hdmi0: endpoint {
port@2 {
reg = <2>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds@feb90000 {
+ compatible = "renesas,r8a77961-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint = <&du_out_lvds0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
--
2.30.2
Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
bindings.
Signed-off-by: Nikita Yushchenko <[email protected]>
---
.../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
index acfc327f70a7..ca5443e5c2e3 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
@@ -27,6 +27,7 @@ properties:
- renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders
- renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders
- renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders
+ - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders
- renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders
- renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders
- renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders
--
2.30.2
Hi Nikita,
Thank you for the patch.
On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
> bindings.
>
> Signed-off-by: Nikita Yushchenko <[email protected]>
> ---
> .../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> index acfc327f70a7..ca5443e5c2e3 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> @@ -27,6 +27,7 @@ properties:
> - renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders
> - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders
> - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders
> + - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders
I'll move this line after the next to keep them sorted. No need to
resubmit.
Reviewed-by: Laurent Pinchart <[email protected]>
> - renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders
> - renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders
> - renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders
--
Regards,
Laurent Pinchart
Hi Nikita,
Thank you for the patch.
On Fri, Dec 24, 2021 at 08:23:07AM +0300, Nikita Yushchenko wrote:
> The M3-W+ SoC has the same LVDS encoder as other R-Car Gen3 chips.
> Add support for M3-W+ (R8A77961) SoC to the LVDS encoder driver.
>
> Signed-off-by: Nikita Yushchenko <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 72a272cfc11e..8dbfbbd3cad1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -901,6 +901,7 @@ static const struct of_device_id rcar_lvds_of_table[] = {
> { .compatible = "renesas,r8a7793-lvds", .data = &rcar_lvds_gen2_info },
> { .compatible = "renesas,r8a7795-lvds", .data = &rcar_lvds_gen3_info },
> { .compatible = "renesas,r8a7796-lvds", .data = &rcar_lvds_gen3_info },
> + { .compatible = "renesas,r8a77961-lvds", .data = &rcar_lvds_gen3_info },
> { .compatible = "renesas,r8a77965-lvds", .data = &rcar_lvds_gen3_info },
> { .compatible = "renesas,r8a77970-lvds", .data = &rcar_lvds_r8a77970_info },
> { .compatible = "renesas,r8a77980-lvds", .data = &rcar_lvds_gen3_info },
--
Regards,
Laurent Pinchart
Hi Nikita,
Thank you for the patch.
On Fri, Dec 24, 2021 at 08:23:08AM +0300, Nikita Yushchenko wrote:
> Add the missing lvds0 node for the R-Car M3-W+ SoC.
>
> Signed-off-by: Nikita Yushchenko <[email protected]>
> ---
> arch/arm64/boot/dts/renesas/r8a77961.dtsi | 27 +++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> index 86d59e7e1a87..a34d5b1d6431 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> @@ -2718,6 +2718,33 @@ du_out_hdmi0: endpoint {
> port@2 {
> reg = <2>;
> du_out_lvds0: endpoint {
> + remote-endpoint = <&lvds0_in>;
> + };
> + };
> + };
> + };
> +
> + lvds0: lvds@feb90000 {
> + compatible = "renesas,r8a77961-lvds";
> + reg = <0 0xfeb90000 0 0x14>;
> + clocks = <&cpg CPG_MOD 727>;
> + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> + resets = <&cpg 727>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_in: endpoint {
> + remote-endpoint = <&du_out_lvds0>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + lvds0_out: endpoint {
> };
Endpoints must have a remote-endpoint property. Let's drop the endpoint
here and keep the port only, the endpoint can be declared in board
files.
If you're fine with this change I can make it when applying the patch.
Reviewed-by: Laurent Pinchart <[email protected]>
> };
> };
--
Regards,
Laurent Pinchart
Hi.
Thank you for looking at this.
>> + port@1 {
>> + reg = <1>;
>> + lvds0_out: endpoint {
>> };
>
> Endpoints must have a remote-endpoint property. Let's drop the endpoint
> here and keep the port only, the endpoint can be declared in board
> files.
>
> If you're fine with this change I can make it when applying the patch.
This empty endpoint is currently defined in dtsi files for other r-car gen3 SoCs. Goal here is to
define lvds0_out label that is then used in extension board dtsi files to link to the port.
In this patch I just used the same approach as in files laying nearby.
If this approach is not appropriate, then perhaps need to fix it in files for all SoCs, to make it
possible for extension board dtsi to be compatible with all of them.
Nikita
Hi Nikita,
On Wed, Dec 29, 2021 at 08:04:18PM +0300, Nikita Yushchenko wrote:
> Hi.
>
> Thank you for looking at this.
>
> >> + port@1 {
> >> + reg = <1>;
> >> + lvds0_out: endpoint {
> >> };
> >
> > Endpoints must have a remote-endpoint property. Let's drop the endpoint
> > here and keep the port only, the endpoint can be declared in board
> > files.
> >
> > If you're fine with this change I can make it when applying the patch.
>
> This empty endpoint is currently defined in dtsi files for other r-car
> gen3 SoCs.
>
> Goal here is to define lvds0_out label that is then used in extension
> board dtsi files to link to the port.
>
> In this patch I just used the same approach as in files laying nearby.
>
> If this approach is not appropriate, then perhaps need to fix it in
> files for all SoCs, to make it possible for extension board dtsi to be
> compatible with all of them.
I'm writing a patch to drop those right now :-) I'll CC you.
--
Regards,
Laurent Pinchart
>> If this approach is not appropriate, then perhaps need to fix it in
>> files for all SoCs, to make it possible for extension board dtsi to be
>> compatible with all of them.
>
> I'm writing a patch to drop those right now :-) I'll CC you.
Ok.
But, are you sure that empty nodes like these are that bad?
I was going to suggest a movement in opposite direction - adding more such nodes, so they could form a
sort of API for dts plugins describing e.g. displays connectable to boards based on different SoCs.
Nikita
Hi Nikita,
On Wed, Dec 29, 2021 at 08:19:10PM +0300, Nikita Yushchenko wrote:
> >> If this approach is not appropriate, then perhaps need to fix it in
> >> files for all SoCs, to make it possible for extension board dtsi to be
> >> compatible with all of them.
> >
> > I'm writing a patch to drop those right now :-) I'll CC you.
And of course I hit the send button too fast, sorry :-S
https://lore.kernel.org/linux-renesas-soc/[email protected]/T/#t
> Ok.
>
> But, are you sure that empty nodes like these are that bad?
>
> I was going to suggest a movement in opposite direction - adding more such nodes, so they could form a
> sort of API for dts plugins describing e.g. displays connectable to boards based on different SoCs.
Endpoints are meant to model a link between two ports, so an endpoint
shouldn't exist in isolation. The issue with creating named endpoints in
SoC files is that you can't tell there what remote devices may exist, so
the endpoint may or may not match the actual hardware design of a board.
I think it's better to create endpoints on both sides together in
overlays.
https://lore.kernel.org/linux-renesas-soc/[email protected]/T/#t
--
Regards,
Laurent Pinchart
Endpoints are meant to model a link between two ports, so an endpoint
> shouldn't exist in isolation. The issue with creating named endpoints in
> SoC files is that you can't tell there what remote devices may exist, so
> the endpoint may or may not match the actual hardware design of a board.
> I think it's better to create endpoints on both sides together in
> overlays.
>
> https://lore.kernel.org/linux-renesas-soc/[email protected]/T/#t
What I don't like here is: details of particular SoC (such as "panel gets video from port@1 of &lvds1)
leak into per-panel DT fragment.
This limits possibilities to share DT fragments between different use cases. In the patch pointed by the
above URL, you have to reference both board and panel in the dts file name.
I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or
defined "interface entities" between this and "neighbor" DT fragment.
Such as:
- SoC's DT fragment defines a named port/endpoint to export video stream at
- board's DT fragment defines a named panel node corresponding to panel plugged into board's physical
connector, and connects endpoints with SoC's video export,
- panel's DT fragment extends the panel node from board with video mode information for this particular
panel.
And similar for backlight, power, and whatever else exposed on the physical panel connector.
So for the board's physical connector there is a set of board-DT-provided entities for use by DT
fragment of whatever component plugged to the connector, without direct references to final SoC
interfaces. And possibility to reuse DT fragments between boards, and probably have a library of DT
fragments for hardware currently available in the market, usable with different boards where that
hardware can be connected.
Nikita
Hi Nikito,
On Thu, Dec 30, 2021 at 12:12:04AM +0300, Nikita Yushchenko wrote:
> Endpoints are meant to model a link between two ports, so an endpoint
> > shouldn't exist in isolation. The issue with creating named endpoints in
> > SoC files is that you can't tell there what remote devices may exist, so
> > the endpoint may or may not match the actual hardware design of a board.
> > I think it's better to create endpoints on both sides together in
> > overlays.
> >
> > https://lore.kernel.org/linux-renesas-soc/[email protected]/T/#t
>
> What I don't like here is: details of particular SoC (such as "panel gets video from port@1 of &lvds1)
> leak into per-panel DT fragment.
>
> This limits possibilities to share DT fragments between different use cases. In the patch pointed by the
> above URL, you have to reference both board and panel in the dts file name.
>
> I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or
> defined "interface entities" between this and "neighbor" DT fragment.
>
> Such as:
> - SoC's DT fragment defines a named port/endpoint to export video stream at
> - board's DT fragment defines a named panel node corresponding to panel plugged into board's physical
> connector, and connects endpoints with SoC's video export,
> - panel's DT fragment extends the panel node from board with video mode information for this particular
> panel.
>
> And similar for backlight, power, and whatever else exposed on the physical panel connector.
>
> So for the board's physical connector there is a set of board-DT-provided entities for use by DT
> fragment of whatever component plugged to the connector, without direct references to final SoC
> interfaces. And possibility to reuse DT fragments between boards, and probably have a library of DT
> fragments for hardware currently available in the market, usable with different boards where that
> hardware can be connected.
I agree it's annoying, but we'll have a similar problem, just the other
way around, with an endpoint defined in the SoC dtsi. Many R-Car SoCs
have two LVDS encoders, and you can attach a panel to either of them.
Some boards use LVDS0, some boards use LVDS1, and some boards could even
use both.
A real solution for this problem will require a new concept. The "DT
connector" proposal is related to this problem space. There's also a
proprietary implementation in the Rapsberry Pi boot loader of a
mechanism to support parametrized overlays ([2] and [3], or [4] for an
example of how a panel reset or backlight GPIO can be parametrized).
[1] https://lwn.net/Articles/689783/
[2] https://www.raspberrypi.com/documentation/computers/configuration.html#part3
[3] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L122
[4] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L312
--
Regards,
Laurent Pinchart
>> I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or
>> defined "interface entities" between this and "neighbor" DT fragment.
>>
>> Such as:
>> - SoC's DT fragment defines a named port/endpoint to export video stream at
>> - board's DT fragment defines a named panel node corresponding to panel plugged into board's physical
>> connector, and connects endpoints with SoC's video export,
>> - panel's DT fragment extends the panel node from board with video mode information for this particular
>> panel.
>> ...
>
> I agree it's annoying, but we'll have a similar problem, just the other
> way around, with an endpoint defined in the SoC dtsi. Many R-Car SoCs
> have two LVDS encoders, and you can attach a panel to either of them.
> Some boards use LVDS0, some boards use LVDS1, and some boards could even
> use both.
The case of "some boards use LVDS0, some boards use LVDS1" is directly addressed by what I'm trying to
suggest. The per-board DT fragment can completely hide board's connection details, without a need for
any new concept.
The case of "some boards could even use both" indeed needs a some way to parametrize panel's DT
fragment, and perhaps load two instances of it with different parameters. To some extent this is doable
via preprocessor magic and multiple includes, although this approach has obvious disadvantages.
> A real solution for this problem will require a new concept. The "DT
> connector" proposal is related to this problem space. There's also a
> proprietary implementation in the Rapsberry Pi boot loader of a
> mechanism to support parametrized overlays ([2] and [3], or [4] for an
> example of how a panel reset or backlight GPIO can be parametrized).
So the problem is already recognized for years... what stops from wider adoption of this or similar
solutions?
And - if/while that is not being done - can't we at least try to follow more portable DT coding pattern
while staying within existing concepts?
Nikita
Hi Nikita,
On Thu, Dec 30, 2021 at 08:30:43AM +0300, Nikita Yushchenko wrote:
> >> I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or
> >> defined "interface entities" between this and "neighbor" DT fragment.
> >>
> >> Such as:
> >> - SoC's DT fragment defines a named port/endpoint to export video stream at
> >> - board's DT fragment defines a named panel node corresponding to panel plugged into board's physical
> >> connector, and connects endpoints with SoC's video export,
> >> - panel's DT fragment extends the panel node from board with video mode information for this particular
> >> panel.
> >> ...
> >
> > I agree it's annoying, but we'll have a similar problem, just the other
> > way around, with an endpoint defined in the SoC dtsi. Many R-Car SoCs
> > have two LVDS encoders, and you can attach a panel to either of them.
> > Some boards use LVDS0, some boards use LVDS1, and some boards could even
> > use both.
>
> The case of "some boards use LVDS0, some boards use LVDS1" is directly addressed by what I'm trying to
> suggest. The per-board DT fragment can completely hide board's connection details, without a need for
> any new concept.
We could do this by adding a label to the port instead of the endpoint
in the SoC .dtsi.
lvds0: lvds@.... {
...
ports {
port@0 {
lvds0_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};
lvds_out_panel_port: port@1 {
};
};
It would however likely be better do add the label to port@1 in the
board .dts though, as usage of a particular LVDS output is a board
property, not an SoC property.
Then, in the overlay,
panel {
port {
panel_in: endpoint {
remote_endpoint <&lvds_out_panel>;
};
};
};
&lvds_out_panel_port {
lvds_out_panel: endpoint {
remote-endpoint = <&panel_in>;
};
};
There's one caveat though: The LVDS DT nodes are disabled in the SoC
.dtsi, so the overlay would need to have
&lvds0 {
status = "okay";
};
and that would need to reference the correct lvds node. Without
parameterized overlays, I don't think we can solve this issue neatly
(especially given that panels will often have control GPIOs, or
GPIO-controlled regulators, that could be wired to different SoC GPIOs
on different boards).
> The case of "some boards could even use both" indeed needs a some way to parametrize panel's DT
> fragment, and perhaps load two instances of it with different parameters. To some extent this is doable
> via preprocessor magic and multiple includes, although this approach has obvious disadvantages.
>
> > A real solution for this problem will require a new concept. The "DT
> > connector" proposal is related to this problem space. There's also a
> > proprietary implementation in the Rapsberry Pi boot loader of a
> > mechanism to support parametrized overlays ([2] and [3], or [4] for an
> > example of how a panel reset or backlight GPIO can be parametrized).
>
> So the problem is already recognized for years... what stops from
> wider adoption of this or similar solutions?
Someone to continue working on it I suppose :-)
> And - if/while that is not being done - can't we at least try to
> follow more portable DT coding pattern while staying within existing
> concepts?
We could use a label for the port node as shown above. It's not a
complete solution, but it may help. I'm not sure how to solve the
enabling of the lvds encoder DT node though.
--
Regards,
Laurent Pinchart
On Fri, 24 Dec 2021 08:23:09 +0300, Nikita Yushchenko wrote:
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
> bindings.
>
> Signed-off-by: Nikita Yushchenko <[email protected]>
> ---
> .../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <[email protected]>
Hi Laurent,
On Wed, Dec 29, 2021 at 5:56 PM Laurent Pinchart
<[email protected]> wrote:
> On Fri, Dec 24, 2021 at 08:23:08AM +0300, Nikita Yushchenko wrote:
> > Add the missing lvds0 node for the R-Car M3-W+ SoC.
> >
> > Signed-off-by: Nikita Yushchenko <[email protected]>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 27 +++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > index 86d59e7e1a87..a34d5b1d6431 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > @@ -2718,6 +2718,33 @@ du_out_hdmi0: endpoint {
> > port@2 {
> > reg = <2>;
> > du_out_lvds0: endpoint {
> > + remote-endpoint = <&lvds0_in>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + lvds0: lvds@feb90000 {
> > + compatible = "renesas,r8a77961-lvds";
> > + reg = <0 0xfeb90000 0 0x14>;
> > + clocks = <&cpg CPG_MOD 727>;
> > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> > + resets = <&cpg 727>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + lvds0_in: endpoint {
> > + remote-endpoint = <&du_out_lvds0>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + lvds0_out: endpoint {
> > };
>
> Endpoints must have a remote-endpoint property. Let's drop the endpoint
> here and keep the port only, the endpoint can be declared in board
> files.
>
> If you're fine with this change I can make it when applying the patch.
Isn't this patch for me to apply to renesas-devel?
> Reviewed-by: Laurent Pinchart <[email protected]>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Geert,
On Mon, Jan 10, 2022 at 09:43:58AM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2021 at 5:56 PM Laurent Pinchart wrote:
> > On Fri, Dec 24, 2021 at 08:23:08AM +0300, Nikita Yushchenko wrote:
> > > Add the missing lvds0 node for the R-Car M3-W+ SoC.
> > >
> > > Signed-off-by: Nikita Yushchenko <[email protected]>
> > > ---
> > > arch/arm64/boot/dts/renesas/r8a77961.dtsi | 27 +++++++++++++++++++++++
> > > 1 file changed, 27 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > > index 86d59e7e1a87..a34d5b1d6431 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> > > @@ -2718,6 +2718,33 @@ du_out_hdmi0: endpoint {
> > > port@2 {
> > > reg = <2>;
> > > du_out_lvds0: endpoint {
> > > + remote-endpoint = <&lvds0_in>;
> > > + };
> > > + };
> > > + };
> > > + };
> > > +
> > > + lvds0: lvds@feb90000 {
> > > + compatible = "renesas,r8a77961-lvds";
> > > + reg = <0 0xfeb90000 0 0x14>;
> > > + clocks = <&cpg CPG_MOD 727>;
> > > + power-domains = <&sysc R8A77961_PD_ALWAYS_ON>;
> > > + resets = <&cpg 727>;
> > > + status = "disabled";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > + reg = <0>;
> > > + lvds0_in: endpoint {
> > > + remote-endpoint = <&du_out_lvds0>;
> > > + };
> > > + };
> > > + port@1 {
> > > + reg = <1>;
> > > + lvds0_out: endpoint {
> > > };
> >
> > Endpoints must have a remote-endpoint property. Let's drop the endpoint
> > here and keep the port only, the endpoint can be declared in board
> > files.
> >
> > If you're fine with this change I can make it when applying the patch.
>
> Isn't this patch for me to apply to renesas-devel?
Even better indeed :-)
> > Reviewed-by: Laurent Pinchart <[email protected]>
--
Regards,
Laurent Pinchart
On Fri, Dec 24, 2021 at 6:23 AM Nikita Yushchenko
<[email protected]> wrote:
> Add the missing lvds0 node for the R-Car M3-W+ SoC.
>
> Signed-off-by: Nikita Yushchenko <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
i.e. will queue in renesas-devel for v5.18.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi
> i.e. will queue in renesas-devel for v5.18.
that is, for current + 2 ?
Hi Nikita,
On Mon, Jan 10, 2022 at 10:51 AM Nikita Yushchenko
<[email protected]> wrote:
> > i.e. will queue in renesas-devel for v5.18.
>
> that is, for current + 2 ?
That is correct, as the merge window for v5.17 has already opened.
The deadline for new features to be accepted for v5.17 in the soc
tree was around v5.16-rc6.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
>>>> + port@1 {
>>>> + reg = <1>;
>>>> + lvds0_out: endpoint {
>>>> };
>>>
>>> Endpoints must have a remote-endpoint property. Let's drop the endpoint
>>> here and keep the port only, the endpoint can be declared in board
>>> files.
>>>
>>> If you're fine with this change I can make it when applying the patch.
>>
>> This empty endpoint is currently defined in dtsi files for other r-car
>> gen3 SoCs.
>>
>> Goal here is to define lvds0_out label that is then used in extension
>> board dtsi files to link to the port.
>>
>> In this patch I just used the same approach as in files laying nearby.
>>
>> If this approach is not appropriate, then perhaps need to fix it in
>> files for all SoCs, to make it possible for extension board dtsi to be
>> compatible with all of them.
>
> I'm writing a patch to drop those right now :-) I'll CC you.
This is not the only place where rcag-gen3 dtsi files are using empty-endpoint pattern.
du rgb port is defined in the same way.
And, I've submitted a patch some weeks ago [1] that hooked into that.
[1] https://lore.kernel.org/lkml/[email protected]/
Since there was no reply, I am about to resubmit it.
But, perhaps need to do something with empty-endpoint pattern first?
Nikita
Hi Nikita,
On Wed, Jan 12, 2022 at 10:10 PM Nikita Yushchenko
<[email protected]> wrote:
> > I'm writing a patch to drop those right now :-) I'll CC you.
>
> This is not the only place where rcag-gen3 dtsi files are using empty-endpoint pattern.
>
> du rgb port is defined in the same way.
>
> And, I've submitted a patch some weeks ago [1] that hooked into that.
>
> [1] https://lore.kernel.org/lkml/[email protected]/
>
> Since there was no reply, I am about to resubmit it.
> But, perhaps need to do something with empty-endpoint pattern first?
No need to resend for now, it is still in my review backlog
(Hi Xmas/NY ;-).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Laurent,
On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart
<[email protected]> wrote:
> On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
> > bindings.
> >
> > Signed-off-by: Nikita Yushchenko <[email protected]>
> > ---
> > .../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > index acfc327f70a7..ca5443e5c2e3 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > @@ -27,6 +27,7 @@ properties:
> > - renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders
> > - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders
> > - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders
> > + - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders
>
> I'll move this line after the next to keep them sorted. No need to
> resubmit.
Any chance this will happen soon? Same for patch 1/3 .
Patch 2/3 is already queued in soc/for-next.
Thank you!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
> > > bindings.
> > >
> > > Signed-off-by: Nikita Yushchenko <[email protected]>
> > > ---
> > > .../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > > index acfc327f70a7..ca5443e5c2e3 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > > @@ -27,6 +27,7 @@ properties:
> > > - renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders
> > > - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders
> > > - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders
> > > + - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders
> >
> > I'll move this line after the next to keep them sorted. No need to
> > resubmit.
>
> Any chance this will happen soon? Same for patch 1/3 .
> Patch 2/3 is already queued in soc/for-next.
Oops. I can send a pull request right away, but we're already at -rc6,
so I'm afraid it will get delayed to v5.19.
--
Regards,
Laurent Pinchart
On Thu, Mar 03, 2022 at 11:14:24AM +0200, Laurent Pinchart wrote:
> On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > > > Document the R-Car M3-W+ (R8A77961) SoC in the R-Car LVDS encoder
> > > > bindings.
> > > >
> > > > Signed-off-by: Nikita Yushchenko <[email protected]>
> > > > ---
> > > > .../devicetree/bindings/display/bridge/renesas,lvds.yaml | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > > > index acfc327f70a7..ca5443e5c2e3 100644
> > > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> > > > @@ -27,6 +27,7 @@ properties:
> > > > - renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders
> > > > - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders
> > > > - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders
> > > > + - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders
> > >
> > > I'll move this line after the next to keep them sorted. No need to
> > > resubmit.
> >
> > Any chance this will happen soon? Same for patch 1/3 .
> > Patch 2/3 is already queued in soc/for-next.
>
> Oops. I can send a pull request right away, but we're already at -rc6,
> so I'm afraid it will get delayed to v5.19.
The patch has been merged in the drm-next branch, thanks to Dave being
very reactive before the tree freeze period begins. Thank you Dave.
--
Regards,
Laurent Pinchart