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.

Applied, thanks for patches.

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

Hi Jan,

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

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).

Adding cip security image to CI,
i need some suggestions to use the current format present in .gitlab-ci.yml

Currently i have the below problem for using script deploy-cip-core.sh:
1. image name formation in the script should have another variable
.../$IMG_PREFIX-cip-core-$RELEASE-$TARGET
where $IMG_PREFIX is default to "cip-core-image" if not specified
for security image it will be passed as 4th argument "cip-core-image-security"
2. currently scrit is expecting the image format in *.wic.img so,
for qemu i think we should have wks file to generate image with format .wic.img

or for this security image do we need to deploy it seperatley?
please guide me

Thanks

Jan

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

On 23.07.20 15:13, Venkata Pyla wrote:

Hi Jan,
sorry i am resending this mail
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@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.

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@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.

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.

Got it,
i was sending the patches to the community for the first time so i was missing some basic stuff.
next time i will do care of it,
thanks for showing patience on me

Don't worry. The submission looked fairly good otherwise, not like first-time!

BTW, I'm still ambivalent whether to do UI (MRs) or cip-dev based patch reviews for isar-cip-core. As contributions increase, you contributors need to express your preference. I'm used to both by now, I have troubles with both by now. However, we just need to consolidate over one system because we can't couple them reasonably.

And then we should document the current state of affairs, I know. There is a CONTRIBUTING guild missing for this repo.

Jan

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

Hi Jan,

sorry i am resending this mail

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@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.

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@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.

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.

Got it,
i was sending the patches to the community for the first time so i was missing some basic stuff.
next time i will do care of it,
thanks for showing patience on me

Jan

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

Hi Jan,

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

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

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

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

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

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

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.

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

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

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

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

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

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

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