Date   

Re: [PATCH 1/3] cip-security: Add packages for IEC-62443-4-2 Evaluation.

Venkata Pyla
 

Hi Jan,

On Thu, Jul 23, 2020 at 04:07 PM, Jan Kiszka wrote:

On 21.07.20 10:16, Venkata Pyla wrote: > From: Kazuhiro Hayashi kazuhiro3.hayashi@... > > Identified security packages are added to the target image > and that will be used for IEC-62443-4-2 evaluation > > Signed-off-by: Kazuhiro Hayashi kazuhiro3.hayashi@... > Signed-off-by: pvenkata2 venkata.pyla@... ^^^^^^^^^ Can you configure your git to add you written name here as well? It's in the email, yes, but it would be nicer to have it displayed as well.

sure, i didn't notice, it was missed in my git config


.../images/cip-core-image-security.bb | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 recipes-core/images/cip-core-image-security.bb

diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb new file mode 100644 index 0000000..8253952 --- /dev/null +++ b/recipes-core/images/cip-core-image-security.bb @@ -0,0 +1,37 @@ +# +# A reference image which includes security packages +# +# Copyright (c) Toshiba Corporation, 2020 +# +# Authors: +# Kazuhiro Hayashi kazuhiro3.hayashi@... +# +# SPDX-License-Identifier: MIT +# + +inherit image + +DESCRIPTION = "CIP Core image including security packages" + +# Use the same customizations as cip-core-image

That comment is not needed. It just creates the risk of becoming outdated if cip-core-image decides to do something else.

Understood, i will modify and resend this patch series.

+IMAGE_INSTALL += "customizations" + +# Debian packages that provide security features +IMAGE_PREINSTALL += " \ + openssl libssl1.1 \ + fail2ban \ + openssh-server openssh-sftp-server openssh-client \ + syslog-ng-core syslog-ng-mod-journal \ + aide aide-common \ + libnftables0 nftables \ + libpam-pkcs11 \ + chrony \ + tpm2-tools \ + tpm2-abrmd \ + libtss2-esys0 libtss2-udev \ + libpam-cracklib \ + acl \ + libauparse0 audispd-plugins auditd \ + uuid-runtime \ + sudo \ +"

Can you close https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/8 if this series obsoletes it? I have rebased the branch and sent the patches over mail, I think i should close this MR in gitlab, i will do that.

BTW, a cover letter would help structuring the patches together. And please add a tag like "[isar-cip-core]" in order to clarify the series target. That is all configurable in git format-patch/send-email.

Jan

-- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux


Resource on Debt workflow?

Mohammed Billoo <mab@...>
 

Hi,
 
I'm almost done getting SSL working between the BBB and hawkbit. The last piece of the puzzle is to get NTP working on the BBB (since I need valid time to ensure that the server certificate is valid). Unfortunately, I'm having a hard time understanding the proper way to add utilities or modify configurations in Deby. It's similar enough to Yocto where I tried creating bbappend recipes and failed miserably. I stumbled upon successfully adding openssl to the rfs, but don't know why it worked. Can anybody point me to a good resource that can describe the proper Deby workflow?
 
As an example, I want to install NTP and then modify its configuration so that it points to the hawkbit server.
 
Thanks
--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: [PATCH 4.19.y-cip 11/17] drm: of: Add drm_of_lvds_get_dual_link_pixel_order

Biju Das <biju.das.jz@...>
 

Hi Pavel,

Thanks for the feedback.

Subject: Re: [PATCH 4.19.y-cip 11/17] drm: of: Add
drm_of_lvds_get_dual_link_pixel_order

Hi!

commit 6529007522ded00b8912c079250620fa7a732166 upstream.

An LVDS dual-link connection is made of two links, with even pixels
transitting on one link, and odd pixels on the other link. The device
tree can be used to fully describe dual-link LVDS connections between
encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports, the
corresponding OF graph port nodes can be marked with either
dual-lvds-even-pixels or dual-lvds-odd-pixels, and that fully
describes an LVDS dual-link connection, including pixel order.
There is double-free bug here, AFAICT:

+for_each_child_of_node(port_node, endpoint) {
+struct device_node *remote_port;
+int current_pt;
+
+if (!of_node_name_eq(endpoint, "endpoint"))
+continue;
+
+remote_port = of_graph_get_remote_port(endpoint);
+if (!remote_port) {
+of_node_put(remote_port);
+return -EPIPE;
+}
+
+current_pt =
drm_of_lvds_get_port_pixels_type(remote_port);
+of_node_put(remote_port);
You have put remote_port here.

+if (pixels_type < 0)
+pixels_type = current_pt;
+
+/*
+ * Sanity check, ensure that all remote endpoints have the
same
+ * pixel type. We may lift this restriction later if we need to
+ * support multiple sinks with different dual-link
+ * configurations by passing the endpoints explicitly to
+ * drm_of_lvds_get_dual_link_pixel_order().
+ */
+if (!current_pt || pixels_type != current_pt) {
+of_node_put(remote_port);
+return -EINVAL;
And again here.

Now... it is only a problem in error path, so maybe easiest way is to fix it in
the mainline and then backport the fix here...
Yes I agree with you, there is double-free bug in error path. As you suggested, We should send a patch in mainline to fix this and backport here.

Cheers,
Biju


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647


Re: [PATCH 3/3] README: Add steps to build cip-security image

Jan Kiszka
 

On 21.07.20 10:16, Venkata Pyla wrote:
From: venkata <venkata.pyla@toshiba-tsip.com>
Signed-off-by: venkata <venkata.pyla@toshiba-tsip.com>
---
README.md | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/README.md b/README.md
index bbad1a0..b2c4166 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,16 @@ card, run
dd if=build/tmp/deploy/images/bbb/cip-core-image-cip-core-buster-bbb.wic.img \
of=/dev/<medium-device> bs=1M status=progress
+## Building Security target images
+Building images for QEMU x86-64bit machine
+
+ ./kas-docker --isar build --target cip-core-image-security kas.yml:board-qemu-amd64.yml
+
+Run the generated securiy images on QEMU (x86-64bit)
+
+ TARGET_IMAGE=cip-core-image-security ./start-qemu.sh amd64
+
+
## Community Resources
TBD
This patch is fine, but I'm missing 4/4: Add this image to CI (same comment as I had on the MR on gitlab).

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [PATCH 1/3] cip-security: Add packages for IEC-62443-4-2 Evaluation.

Jan Kiszka
 

On 21.07.20 10:16, Venkata Pyla wrote:
From: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Identified security packages are added to the target image
and that will be used for IEC-62443-4-2 evaluation
Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: pvenkata2 <venkata.pyla@toshiba-tsip.com>
^^^^^^^^^
Can you configure your git to add you written name here as well? It's in the email, yes, but it would be nicer to have it displayed as well.

---
.../images/cip-core-image-security.bb | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 recipes-core/images/cip-core-image-security.bb
diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
new file mode 100644
index 0000000..8253952
--- /dev/null
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -0,0 +1,37 @@
+#
+# A reference image which includes security packages
+#
+# Copyright (c) Toshiba Corporation, 2020
+#
+# Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit image
+
+DESCRIPTION = "CIP Core image including security packages"
+
+# Use the same customizations as cip-core-image
That comment is not needed. It just creates the risk of becoming outdated if cip-core-image decides to do something else.

+IMAGE_INSTALL += "customizations"
+
+# Debian packages that provide security features
+IMAGE_PREINSTALL += " \
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ sudo \
+"
Can you close https://gitlab.com/cip-project/cip-core/isar-cip-core/-/merge_requests/8 if this series obsoletes it?

BTW, a cover letter would help structuring the patches together. And please add a tag like "[isar-cip-core]" in order to clarify the series target. That is all configurable in git format-patch/send-email.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


CIP Patchwork

Chris Paterson
 

Hello all,

CIP has a Patchwork instance [0] that monitors the cip-dev mainline list for patches.

It doesn't look like it's particularly maintained, with most patches in the "new" state.
As a project, do we want to start maintaining Patchwork? Should we kill it off? Or just stick with the status-quo?

We briefly discussed this in the IRC meeting today, but I thought we should check with a wider audience before making a decision.

So, any thoughts?

[0] https://patchwork.kernel.org/project/cip-dev/list/

Kind regards, Chris


Re: CIP IRC weekly meeting today

Pavel Machek
 

Hi!

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I cannot attend the meeting today. Chris-san will host the meeting instead.
I should be able to attend the meeting, but in case reality
interferes:

I have reviewed patches for 4.19.134.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.
I cannot attend the meeting today. Chris-san will host the meeting instead.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=23&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/07/cip.2020-07-16-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Resource describing the Deby workflow?

Mohammed Billoo <mab@...>
 

Hi,

I'm almost done getting SSL working between the BBB and hawkbit. The last piece of the puzzle is to get NTP working on the BBB (since I need valid time to ensure that the server certificate is valid). Unfortunately, I'm having a hard time understanding the proper way to add utilities or modify configurations in Deby. It's similar enough to Yocto where I tried creating bbappend recipes and failed miserably. I stumbled upon successfully adding openssl to the rfs, but don't know why it worked. Can anybody point me to a good resource that can describe the proper Deby workflow?

As an example, I want to install NTP and then modify its configuration so that it points to the hawkbit server.

Thanks
--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: [PATCH 4.19.y-cip 00/17] Add RZ/G2E Dual LVDS display

Pavel Machek
 

Hi!

Add RZ/G2E Dual LVDS display support. All patches in this series are
cherry-picked from upstream kernel.
I could not find any issues besides double of_node_put in 11/.

It is currently being tested:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/169687006

If noone objects (and tests pass), I can apply/push the series.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip 11/17] drm: of: Add drm_of_lvds_get_dual_link_pixel_order

Pavel Machek
 

Hi!

commit 6529007522ded00b8912c079250620fa7a732166 upstream.

An LVDS dual-link connection is made of two links, with even
pixels transitting on one link, and odd pixels on the other
link. The device tree can be used to fully describe dual-link
LVDS connections between encoders and bridges/panels.
The sink of an LVDS dual-link connection is made of two ports,
the corresponding OF graph port nodes can be marked
with either dual-lvds-even-pixels or dual-lvds-odd-pixels,
and that fully describes an LVDS dual-link connection,
including pixel order.
There is double-free bug here, AFAICT:

+ for_each_child_of_node(port_node, endpoint) {
+ struct device_node *remote_port;
+ int current_pt;
+
+ if (!of_node_name_eq(endpoint, "endpoint"))
+ continue;
+
+ remote_port = of_graph_get_remote_port(endpoint);
+ if (!remote_port) {
+ of_node_put(remote_port);
+ return -EPIPE;
+ }
+
+ current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+ of_node_put(remote_port);
You have put remote_port here.

+ if (pixels_type < 0)
+ pixels_type = current_pt;
+
+ /*
+ * Sanity check, ensure that all remote endpoints have the same
+ * pixel type. We may lift this restriction later if we need to
+ * support multiple sinks with different dual-link
+ * configurations by passing the endpoints explicitly to
+ * drm_of_lvds_get_dual_link_pixel_order().
+ */
+ if (!current_pt || pixels_type != current_pt) {
+ of_node_put(remote_port);
+ return -EINVAL;
And again here.

Now... it is only a problem in error path, so maybe easiest way is to
fix it in the mainline and then backport the fix here...

Best regards,

Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


[PATCH 4.19.y-cip 17/17] arm64: dts: renesas: Add EK874 board with idk-2121wr display support

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit ae56c940f188c1dde440c8456229adaad733908e upstream.

The EK874 is advertised as compatible with panel IDK-2121WR from
Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
to work with the EK874, is the most convenient way to support the
EK874 when it's connected to the IDK-2121WR.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/1576590361-28244-7-git-send-email-fabrizio.castro@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 ++++++++++++++++++
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index c05feec80636..d22ede9e3ee4 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -4,7 +4,8 @@ dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-ex-idk-1110wr.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
-dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb
+dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-cat874.dtb r8a774c0-ek874.dtb \
+ r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-xs.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
new file mode 100644
index 000000000000..a7b27d09f6c2
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Silicon Linux RZ/G2E evaluation kit (EK874),
+ * connected to an Advantech IDK-2121WR 21.5" LVDS panel
+ *
+ * Copyright (C) 2019 Renesas Electronics Corp.
+ */
+
+#include "r8a774c0-ek874.dts"
+
+/ {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm5 0 50000>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+
+ power-supply = <&reg_12p0v>;
+ enable-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
+};
+
+&gpio0 {
+ /*
+ * When GP0_17 is low LVDS[01] are connected to the LVDS connector
+ * When GP0_17 is high LVDS[01] are connected to the LT8918L
+ */
+ lvds-connector-en-gpio{
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lvds-connector-en-gpio";
+ };
+};
+
+&lvds0 {
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in0>;
+ };
+ };
+ };
+};
+
+&lvds1 {
+ status = "okay";
+
+ clocks = <&cpg CPG_MOD 727>, <&x13_clk>, <&extal_clk>;
+ clock-names = "fck", "dclkin.0", "extal";
+
+ ports {
+ port@1 {
+ lvds1_out: endpoint {
+ remote-endpoint = <&panel_in1>;
+ };
+ };
+ };
+};
+
+&pfc {
+ pwm5_pins: pwm5 {
+ groups = "pwm5_a";
+ function = "pwm5";
+ };
+};
+
+&pwm5 {
+ pinctrl-0 = <&pwm5_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.17.1


[PATCH 4.19.y-cip 16/17] dt-bindings: display: Add idk-2121wr binding

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 8efef33eff5088ecc748e9d5b3bff6c1c955348f upstream.

Add binding for the idk-2121wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583869169-1006-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
.../display/panel/advantech,idk-2121wr.yaml | 122 ++++++++++++++++++
1 file changed, 122 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
new file mode 100644
index 000000000000..6b7fddc80c41
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
+
+maintainers:
+ - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+ - Thierry Reding <thierry.reding@gmail.com>
+
+description: |
+ The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
+ A dual-LVDS interface is a dual-link connection with even pixels traveling
+ on one link, and with odd pixels traveling on the other link.
+
+ The panel expects odd pixels on the first port, and even pixels on the
+ second port, therefore the ports must be marked accordingly (with either
+ dual-lvds-odd-pixels or dual-lvds-even-pixels).
+
+properties:
+ compatible:
+ items:
+ - const: advantech,idk-2121wr
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ width-mm:
+ const: 476
+
+ height-mm:
+ const: 268
+
+ data-mapping:
+ const: vesa-24
+
+ panel-timing: true
+
+ ports:
+ type: object
+ properties:
+ port@0:
+ type: object
+ description: The sink for odd pixels.
+ properties:
+ reg:
+ const: 0
+
+ dual-lvds-odd-pixels: true
+
+ required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+ type: object
+ description: The sink for even pixels.
+ properties:
+ reg:
+ const: 1
+
+ dual-lvds-even-pixels: true
+
+ required:
+ - reg
+ - dual-lvds-even-pixels
+
+additionalProperties: false
+
+required:
+ - compatible
+ - width-mm
+ - height-mm
+ - data-mapping
+ - panel-timing
+ - ports
+
+examples:
+ - |+
+ panel-lvds {
+ compatible = "advantech,idk-2121wr", "panel-lvds";
+
+ width-mm = <476>;
+ height-mm = <268>;
+
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <44>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in0: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in1: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
+
+...
--
2.17.1


[PATCH 4.19.y-cip 07/17] drm: Add drm_atomic_get_(old|new)_connector_for_encoder() helpers

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

commit 1b27fbdde1df172dba604855c45078d741f8c858 upstream.

Add functions to the atomic core to retrieve the old and new connectors
associated with an encoder in a drm_atomic_state. This is useful for
encoders and bridges that need to access the connector, for instance for
the drm_display_info.

The CRTC associated with the encoder can also be retrieved through the
connector state, and from it, the old and new CRTC states.

Changed in v4:
- Added to the set
Changed in v5:
- Fix up docbook (Daniel & Laurent)
Changed in v6:
- Updated commit subject (Sam)

Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-3-sean@poorly.run
Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-3-sean@poorly.run

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

[seanpaul removed WARNs from helpers and added docs to explain why
returning NULL might be valid]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190611205147.181298-1-sean@poorly.run
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/drm_atomic.c | 113 +++++++++++++++++++++++++++++++++++
include/drm/drm_atomic.h | 7 +++
include/drm/drm_connector.h | 9 +++
3 files changed, 129 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1a4b44923aec..d36742761ada 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1252,6 +1252,119 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_private_obj_state);

+/**
+ * drm_atomic_get_old_private_obj_state
+ * @state: global atomic state object
+ * @obj: private_obj to grab
+ *
+ * This function returns the old private object state for the given private_obj,
+ * or NULL if the private_obj is not part of the global atomic state.
+ */
+struct drm_private_state *
+drm_atomic_get_old_private_obj_state(struct drm_atomic_state *state,
+ struct drm_private_obj *obj)
+{
+ int i;
+
+ for (i = 0; i < state->num_private_objs; i++)
+ if (obj == state->private_objs[i].ptr)
+ return state->private_objs[i].old_state;
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_private_obj_state);
+
+/**
+ * drm_atomic_get_new_private_obj_state
+ * @state: global atomic state object
+ * @obj: private_obj to grab
+ *
+ * This function returns the new private object state for the given private_obj,
+ * or NULL if the private_obj is not part of the global atomic state.
+ */
+struct drm_private_state *
+drm_atomic_get_new_private_obj_state(struct drm_atomic_state *state,
+ struct drm_private_obj *obj)
+{
+ int i;
+
+ for (i = 0; i < state->num_private_objs; i++)
+ if (obj == state->private_objs[i].ptr)
+ return state->private_objs[i].new_state;
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_new_private_obj_state);
+
+/**
+ * drm_atomic_get_old_connector_for_encoder - Get old connector for an encoder
+ * @state: Atomic state
+ * @encoder: The encoder to fetch the connector state for
+ *
+ * This function finds and returns the connector that was connected to @encoder
+ * as specified by the @state.
+ *
+ * If there is no connector in @state which previously had @encoder connected to
+ * it, this function will return NULL. While this may seem like an invalid use
+ * case, it is sometimes useful to differentiate commits which had no prior
+ * connectors attached to @encoder vs ones that did (and to inspect their
+ * state). This is especially true in enable hooks because the pipeline has
+ * changed.
+ *
+ * Returns: The old connector connected to @encoder, or NULL if the encoder is
+ * not connected.
+ */
+struct drm_connector *
+drm_atomic_get_old_connector_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_old_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return connector;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_connector_for_encoder);
+
+/**
+ * drm_atomic_get_new_connector_for_encoder - Get new connector for an encoder
+ * @state: Atomic state
+ * @encoder: The encoder to fetch the connector state for
+ *
+ * This function finds and returns the connector that will be connected to
+ * @encoder as specified by the @state.
+ *
+ * If there is no connector in @state which will have @encoder connected to it,
+ * this function will return NULL. While this may seem like an invalid use case,
+ * it is sometimes useful to differentiate commits which have no connectors
+ * attached to @encoder vs ones that do (and to inspect their state). This is
+ * especially true in disable hooks because the pipeline will change.
+ *
+ * Returns: The new connector connected to @encoder, or NULL if the encoder is
+ * not connected.
+ */
+struct drm_connector *
+drm_atomic_get_new_connector_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return connector;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
+
/**
* drm_atomic_get_connector_state - get connector state
* @state: global atomic state object
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 1e713154f00e..c0b48e25a620 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -403,6 +403,13 @@ struct drm_private_state * __must_check
drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
struct drm_private_obj *obj);

+struct drm_connector *
+drm_atomic_get_old_connector_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder);
+struct drm_connector *
+drm_atomic_get_new_connector_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder);
+
/**
* drm_atomic_get_existing_crtc_state - get crtc state, if it exists
* @state: global atomic state object
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 97ea41dc678f..6f0a05b6581d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -397,6 +397,15 @@ struct drm_connector_state {
* Used by the atomic helpers to select the encoder, through the
* &drm_connector_helper_funcs.atomic_best_encoder or
* &drm_connector_helper_funcs.best_encoder callbacks.
+ *
+ * This is also used in the atomic helpers to map encoders to their
+ * current and previous connectors, see
+ * &drm_atomic_get_old_connector_for_encoder() and
+ * &drm_atomic_get_new_connector_for_encoder().
+ *
+ * NOTE: Atomic drivers must fill this out (either themselves or through
+ * helpers), for otherwise the GETCONNECTOR and GETENCODER IOCTLs will
+ * not return correct data to userspace.
*/
struct drm_encoder *best_encoder;

--
2.17.1


[PATCH 4.19.y-cip 09/17] drm: rcar-du: lvds: Get mode from state

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit 593885b085d699c9f49992c3ea50f372e0c7008d upstream.

The R-Car LVDS encoder driver implements the bridge .mode_set()
operation for the sole purpose of storing the mode in the LVDS private
data, to be used later when enabling the encoder.

Switch to the bridge .atomic_enable() and .atomic_disable() operations
in order to access the global atomic state, and get the mode from the
state instead. Remove both the unneeded .mode_set() operation and the
display_mode and mode fields storing state data from the rcar_lvds
private structure.

As a side effect we get the CRTC from the state, replace the CRTC
pointer retrieved through the bridge's encoder that shouldn't be used by
atomic drivers.

While at it, clarify a few error messages in rcar_lvds_get_lvds_mode()
and turn them into warnings as they are not fatal.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Tested-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 140 +++++++++++++++-------------
1 file changed, 74 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 2558067efe22..aa07af7d944f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -63,9 +63,6 @@ struct rcar_lvds {
struct clk *dotclkin[2]; /* External DU clocks */
} clocks;

- struct drm_display_mode display_mode;
- enum rcar_lvds_mode mode;
-
struct drm_bridge *companion;
bool dual_link;
};
@@ -398,10 +395,53 @@ EXPORT_SYMBOL_GPL(rcar_lvds_clk_disable);
* Bridge
*/

-static void rcar_lvds_enable(struct drm_bridge *bridge)
+static enum rcar_lvds_mode rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds,
+ const struct drm_connector *connector)
+{
+ const struct drm_display_info *info;
+ enum rcar_lvds_mode mode;
+
+ /*
+ * There is no API yet to retrieve LVDS mode from a bridge, only panels
+ * are supported.
+ */
+ if (!lvds->panel)
+ return RCAR_LVDS_MODE_JEIDA;
+
+ info = &connector->display_info;
+ if (!info->num_bus_formats || !info->bus_formats) {
+ dev_warn(lvds->dev,
+ "no LVDS bus format reported, using JEIDA\n");
+ return RCAR_LVDS_MODE_JEIDA;
+ }
+
+ switch (info->bus_formats[0]) {
+ case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+ case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+ mode = RCAR_LVDS_MODE_JEIDA;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+ mode = RCAR_LVDS_MODE_VESA;
+ break;
+ default:
+ dev_warn(lvds->dev,
+ "unsupported LVDS bus format 0x%04x, using JEIDA\n",
+ info->bus_formats[0]);
+ return RCAR_LVDS_MODE_JEIDA;
+ }
+
+ if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
+ mode |= RCAR_LVDS_MODE_MIRROR;
+
+ return mode;
+}
+
+static void __rcar_lvds_atomic_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state,
+ struct drm_crtc *crtc,
+ struct drm_connector *connector)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
- const struct drm_display_mode *mode = &lvds->display_mode;
u32 lvdhcr;
u32 lvdcr0;
int ret;
@@ -412,7 +452,8 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)

/* Enable the companion LVDS encoder in dual-link mode. */
if (lvds->dual_link && lvds->companion)
- lvds->companion->funcs->enable(lvds->companion);
+ __rcar_lvds_atomic_enable(lvds->companion, state, crtc,
+ connector);

/*
* Hardcode the channels and control signals routing for now.
@@ -448,18 +489,20 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
* PLL clock configuration on all instances but the companion in
* dual-link mode.
*/
- if (!lvds->dual_link || lvds->companion)
+ if (!lvds->dual_link || lvds->companion) {
+ const struct drm_crtc_state *crtc_state =
+ drm_atomic_get_new_crtc_state(state, crtc);
+ const struct drm_display_mode *mode =
+ &crtc_state->adjusted_mode;
+
lvds->info->pll_setup(lvds, mode->clock * 1000);
+ }

/* Set the LVDS mode and select the input. */
- lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+ lvdcr0 = rcar_lvds_get_lvds_mode(lvds, connector) << LVDCR0_LVMD_SHIFT;

if (lvds->bridge.encoder) {
- /*
- * FIXME: We should really retrieve the CRTC through the state,
- * but how do we get a state pointer?
- */
- if (drm_crtc_index(lvds->bridge.encoder->crtc) == 2)
+ if (drm_crtc_index(crtc) == 2)
lvdcr0 |= LVDCR0_DUSEL;
}

@@ -512,7 +555,21 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
}
}

-static void rcar_lvds_disable(struct drm_bridge *bridge)
+static void rcar_lvds_atomic_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector *connector;
+ struct drm_crtc *crtc;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
+ bridge->encoder);
+ crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
+
+ __rcar_lvds_atomic_enable(bridge, state, crtc, connector);
+}
+
+static void rcar_lvds_atomic_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);

@@ -527,7 +584,7 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)

/* Disable the companion LVDS encoder in dual-link mode. */
if (lvds->dual_link && lvds->companion)
- lvds->companion->funcs->disable(lvds->companion);
+ lvds->companion->funcs->atomic_disable(lvds->companion, state);

clk_disable_unprepare(lvds->clocks.mod);
}
@@ -550,54 +607,6 @@ static bool rcar_lvds_mode_fixup(struct drm_bridge *bridge,
return true;
}

-static void rcar_lvds_get_lvds_mode(struct rcar_lvds *lvds)
-{
- struct drm_display_info *info = &lvds->connector.display_info;
- enum rcar_lvds_mode mode;
-
- /*
- * There is no API yet to retrieve LVDS mode from a bridge, only panels
- * are supported.
- */
- if (!lvds->panel)
- return;
-
- if (!info->num_bus_formats || !info->bus_formats) {
- dev_err(lvds->dev, "no LVDS bus format reported\n");
- return;
- }
-
- switch (info->bus_formats[0]) {
- case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
- case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
- mode = RCAR_LVDS_MODE_JEIDA;
- break;
- case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
- mode = RCAR_LVDS_MODE_VESA;
- break;
- default:
- dev_err(lvds->dev, "unsupported LVDS bus format 0x%04x\n",
- info->bus_formats[0]);
- return;
- }
-
- if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
- mode |= RCAR_LVDS_MODE_MIRROR;
-
- lvds->mode = mode;
-}
-
-static void rcar_lvds_mode_set(struct drm_bridge *bridge,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
-
- lvds->display_mode = *adjusted_mode;
-
- rcar_lvds_get_lvds_mode(lvds);
-}
-
static int rcar_lvds_attach(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
@@ -639,10 +648,9 @@ static void rcar_lvds_detach(struct drm_bridge *bridge)
static const struct drm_bridge_funcs rcar_lvds_bridge_ops = {
.attach = rcar_lvds_attach,
.detach = rcar_lvds_detach,
- .enable = rcar_lvds_enable,
- .disable = rcar_lvds_disable,
+ .atomic_enable = rcar_lvds_atomic_enable,
+ .atomic_disable = rcar_lvds_atomic_disable,
.mode_fixup = rcar_lvds_mode_fixup,
- .mode_set = rcar_lvds_mode_set,
};

bool rcar_lvds_dual_link(struct drm_bridge *bridge)
--
2.17.1


[PATCH 4.19.y-cip 06/17] drm: rcar_lvds: Fix dual link mode operations

Biju Das <biju.das.jz@...>
 

From: Jacopo Mondi <jacopo+renesas@jmondi.org>

commit a53358a31c989c360ea59536d28762b9d2d68d19 upstream.

The R-Car LVDS encoder units support dual-link operations by splitting
the pixel output between the primary encoder and the companion encoder.

Currently the companion encoder fails at probe time, causing the
registration of the primary to fail as well, preventing the whole DU unit
from being registered at all.

Fix this by not bailing out from probe with error if the
"renesas,companion" property is not specified.

Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode")
Reported-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 0774bd00dfac..2558067efe22 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -666,10 +666,8 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)

/* Locate the companion LVDS encoder for dual-link operation, if any. */
companion = of_parse_phandle(dev->of_node, "renesas,companion", 0);
- if (!companion) {
- dev_err(dev, "Companion LVDS encoder not found\n");
- return -ENXIO;
- }
+ if (!companion)
+ return 0;

/*
* Sanity check: the companion encoder must have the same compatible
--
2.17.1


[PATCH 4.19.y-cip 03/17] dt-bindings: display: renesas: lvds: Add renesas,companion property

Biju Das <biju.das.jz@...>
 

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

commit f54b4df6b14fb5858bec605aee4356a2e801dddb upstream.

Add a new optional renesas,companion property to point to the companion
LVDS encoder. This is used to support dual-link operation where the main
LVDS encoder splits even-numbered and odd-numbered pixels between the
two LVDS encoders.

The new property doesn't control the mode of operation, it only
describes the relationship between the master and companion LVDS
encoders.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
.../bindings/display/bridge/renesas,lvds.txt | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
index d06c25e51e9a..10e2e8e9eb20 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -41,14 +41,24 @@ OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.

Each port shall have a single endpoint.

+Optional properties:
+
+- renesas,companion : phandle to the companion LVDS encoder. This property is
+ mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
+ the second encoder to be used as a companion in dual-link mode. It shall not
+ be set for any other LVDS encoder.
+

Example:

lvds0: lvds@feb90000 {
- compatible = "renesas,r8a7790-lvds";
- reg = <0 0xfeb90000 0 0x1c>;
- clocks = <&cpg CPG_MOD 726>;
- resets = <&cpg 726>;
+ compatible = "renesas,r8a77990-lvds";
+ reg = <0 0xfeb90000 0 0x20>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+
+ renesas,companion = <&lvds1>;

ports {
#address-cells = <1>;
--
2.17.1


[PATCH 4.19.y-cip 15/17] arm64: dts: renesas: rzg2: Add reset control properties for display

Biju Das <biju.das.jz@...>
 

From: Geert Uytterhoeven <geert+renesas@glider.be>

commit 721b76195b31467e56851fbab3855e700f281270 upstream.

Add reset control properties to the device nodes for the Display Units
on all supported RZ/G2 SoCs. Note that on these SoCs, there is only a
single reset for each pair of DU channels.

Join the clocks lines while at it, to increase uniformity.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20200218133019.22299-5-geert+renesas@glider.be
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 5 +++--
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 5 +++--
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 6 ++++--
3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 570093ce77be..86ad9b34810f 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2278,10 +2278,11 @@
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 724>,
- <&cpg CPG_MOD 723>,
+ clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>,
<&cpg CPG_MOD 722>;
clock-names = "du.0", "du.1", "du.2";
+ resets = <&cpg 724>, <&cpg 722>;
+ reset-names = "du.0", "du.2";
status = "disabled";

vsps = <&vspd0 &vspd1 &vspd2>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 5948f782ab48..5e4768fb6842 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -2103,10 +2103,11 @@
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 724>,
- <&cpg CPG_MOD 723>,
+ clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>,
<&cpg CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.3";
+ resets = <&cpg 724>, <&cpg 722>;
+ reset-names = "du.0", "du.3";
status = "disabled";

vsps = <&vspd0 0>, <&vspd1 0>, <&vspd0 1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 75d4fbd2579e..783a8cf16eaa 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1810,10 +1810,12 @@
reg = <0 0xfeb00000 0 0x40000>;
interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 724>,
- <&cpg CPG_MOD 723>;
+ clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>;
clock-names = "du.0", "du.1";
+ resets = <&cpg 724>;
+ reset-names = "du.0";
vsps = <&vspd0 0>, <&vspd1 0>;
+
status = "disabled";

ports {
--
2.17.1


[PATCH 4.19.y-cip 12/17] drm: rcar-du: lvds: Get dual link configuration from DT

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 65112cfa56c32030a7f04a8a4c28251b89b5cf26 upstream.

For dual-LVDS configurations, it is now possible to mark the
DT port nodes for the sink with boolean properties (like
dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers
know the encoders need to be configured in dual-LVDS mode.

Rework the implementation of rcar_lvds_parse_dt_companion
to make use of the DT markers while keeping backward
compatibility.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 54 ++++++++++++++++++++++++-----
1 file changed, 46 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index f81a0d730db8..12d2bbbb02f0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -670,7 +670,10 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
{
const struct of_device_id *match;
struct device_node *companion;
+ struct device_node *port0, *port1;
+ struct rcar_lvds *companion_lvds;
struct device *dev = lvds->dev;
+ int dual_link;
int ret = 0;

/* Locate the companion LVDS encoder for dual-link operation, if any. */
@@ -689,13 +692,54 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)
goto done;
}

+ /*
+ * We need to work out if the sink is expecting us to function in
+ * dual-link mode. We do this by looking at the DT port nodes we are
+ * connected to, if they are marked as expecting even pixels and
+ * odd pixels than we need to enable vertical stripe output.
+ */
+ port0 = of_graph_get_port_by_id(dev->of_node, 1);
+ port1 = of_graph_get_port_by_id(companion, 1);
+ dual_link = drm_of_lvds_get_dual_link_pixel_order(port0, port1);
+ of_node_put(port0);
+ of_node_put(port1);
+
+ if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS)
+ lvds->dual_link = true;
+ else if (lvds->next_bridge && lvds->next_bridge->timings)
+ /*
+ * Early dual-link bridge specific implementations populate the
+ * timings field of drm_bridge, read the dual_link flag off the
+ * bridge directly for backward compatibility.
+ */
+ lvds->dual_link = lvds->next_bridge->timings->dual_link;
+
+ if (!lvds->dual_link) {
+ dev_dbg(dev, "Single-link configuration detected\n");
+ goto done;
+ }
+
lvds->companion = of_drm_find_bridge(companion);
if (!lvds->companion) {
ret = -EPROBE_DEFER;
goto done;
}

- dev_dbg(dev, "Found companion encoder %pOF\n", companion);
+ dev_dbg(dev,
+ "Dual-link configuration detected (companion encoder %pOF)\n",
+ companion);
+
+ /*
+ * FIXME: We should not be messing with the companion encoder private
+ * data from the primary encoder, we should rather let the companion
+ * encoder work things out on its own. However, the companion encoder
+ * doesn't hold a reference to the primary encoder, and
+ * drm_of_lvds_get_dual_link_pixel_order needs to be given references
+ * to the output ports of both encoders, therefore leave it like this
+ * for the time being.
+ */
+ companion_lvds = bridge_to_rcar_lvds(lvds->companion);
+ companion_lvds->dual_link = true;

done:
of_node_put(companion);
@@ -712,13 +756,7 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
if (ret)
goto done;

- if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
- lvds->next_bridge)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
-
- if (lvds->dual_link)
+ if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
ret = rcar_lvds_parse_dt_companion(lvds);

done:
--
2.17.1


[PATCH 4.19.y-cip 10/17] drm: rcar-du: lvds: Improve identification of panels

Biju Das <biju.das.jz@...>
 

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

commit 990e378db4450f930aefbe8c31a50b8504fe0e8b upstream.

Dual-LVDS panels are mistakenly identified as bridges, this
commit replaces the current logic with a call to
drm_of_find_panel_or_bridge to sort that out.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 75 ++++-------------------------
1 file changed, 10 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index aa07af7d944f..f81a0d730db8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -20,6 +20,7 @@
#include <drm/drm_atomic_helper.h>
#include <drm/drm_bridge.h>
#include <drm/drm_crtc_helper.h>
+#include <drm/drm_of.h>
#include <drm/drm_panel.h>

#include "rcar_lvds.h"
@@ -704,79 +705,23 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds)

static int rcar_lvds_parse_dt(struct rcar_lvds *lvds)
{
- struct device_node *local_output = NULL;
- struct device_node *remote_input = NULL;
- struct device_node *remote = NULL;
- struct device_node *node;
- bool is_bridge = false;
- int ret = 0;
-
- local_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, 0);
- if (!local_output) {
- dev_dbg(lvds->dev, "unconnected port@1\n");
- ret = -ENODEV;
- goto done;
- }
-
- /*
- * Locate the connected entity and infer its type from the number of
- * endpoints.
- */
- remote = of_graph_get_remote_port_parent(local_output);
- if (!remote) {
- dev_dbg(lvds->dev, "unconnected endpoint %pOF\n", local_output);
- ret = -ENODEV;
- goto done;
- }
+ int ret;

- if (!of_device_is_available(remote)) {
- dev_dbg(lvds->dev, "connected entity %pOF is disabled\n",
- remote);
- ret = -ENODEV;
+ ret = drm_of_find_panel_or_bridge(lvds->dev->of_node, 1, 0,
+ &lvds->panel, &lvds->next_bridge);
+ if (ret)
goto done;
- }

- remote_input = of_graph_get_remote_endpoint(local_output);
-
- for_each_endpoint_of_node(remote, node) {
- if (node != remote_input) {
- /*
- * We've found one endpoint other than the input, this
- * must be a bridge.
- */
- is_bridge = true;
- of_node_put(node);
- break;
- }
- }
-
- if (is_bridge) {
- lvds->next_bridge = of_drm_find_bridge(remote);
- if (!lvds->next_bridge) {
- ret = -EPROBE_DEFER;
- goto done;
- }
-
- if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK)
- lvds->dual_link = lvds->next_bridge->timings
- ? lvds->next_bridge->timings->dual_link
- : false;
- } else {
- lvds->panel = of_drm_find_panel(remote);
- if (IS_ERR(lvds->panel)) {
- ret = PTR_ERR(lvds->panel);
- goto done;
- }
- }
+ if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) &&
+ lvds->next_bridge)
+ lvds->dual_link = lvds->next_bridge->timings
+ ? lvds->next_bridge->timings->dual_link
+ : false;

if (lvds->dual_link)
ret = rcar_lvds_parse_dt_companion(lvds);

done:
- of_node_put(local_output);
- of_node_put(remote_input);
- of_node_put(remote);
-
/*
* On D3/E3 the LVDS encoder provides a clock to the DU, which can be
* used for the DPAD output even when the LVDS output is not connected.
--
2.17.1

1841 - 1860 of 6828