[PATCH v11 0/7] drm/lsdc: add drm driver for loongson display controller

[PATCH v11 0/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

There is a display controller in loongson's LS2K1000 SoC and LS7A1000
bridge chip, the display controller is a PCI device in those chips. It
has two display pipes but with only one hardware cursor. Each way has
a DVO interface which provide RGB888 signals, vertical & horizontal
synchronisations, data enable and the pixel clock. Each CRTC is able to
scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
2048x2048 according to the hardware spec. Loongson display controllers
are simple which require scanout buffers to be physically contiguous.

For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
which is typically 64MB or more. In this case, VRAM helper based driver
is suppose to be used. While LS2K1000 is a SoC, only system memory is
available, therefore CMA helper based driver is intend to be used. It is
possible to use VRAM helper based solution by carving out part of system
memory as VRAM though.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space, They are used to emulate two way i2c.
One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
GPIO hardwared, they grab i2c adapter from other module, either general
purpose GPIO emulated i2c or hardware i2c adapter.

    +------+            +-----------------------------------+
    | DDR4 |            |  +-------------------+            |
    +------+            |  | PCIe Root complex |   LS7A1000 |
       || MC0           |  +--++---------++----+            |
  +----------+  HT 3.0  |     ||         ||                 |
  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +----------+          | +--------+  +-+--+-+    +---------+   +------+
       || MC1           +---------------|--|----------------+
    +------+                            |  |
    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
                      +-------+                      +------+

The above picture give a simple usage of LS7A1000, note that the encoder
is not necessary adv7125 or tfp410, other candicates can be ch7034b,
sil9022, ite66121 and lt8618 etc.

v2: Fixup warnings reported by kernel test robot

v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
    more details about lsdc.

v4:
   1) Add dts required and explain why device tree is required.
   2) Give more description about lsdc and VRAM helper based driver.
   3) Fix warnings reported by kernel test robot.
   4) Introduce stride_alignment member into struct lsdc_chip_desc, the
      stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.

v5:
   1) Using writel and readl replace writeq and readq, to fix kernel test
      robot report build error on other archtecture.
   2) Set default fb format to XRGB8888 at crtc reset time.

v6:
   1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
   2) Explain why tiny drm driver is not suitable for us.
   3) Give a short description of the trival dirty uppdate implement based
      on CMA helper.

v7:
   1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
   2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
   3) Remove lsdc_pixpll_print(), part of it move to debugfs.
   4) Set prefer_shadow to true if vram based driver is in using.
   5) Replace double blank lines with single line in all files.
   6) Verbose cmd line parameter is replaced with drm_dbg()
   7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
   8) Get edid from dtb support is removed as suggested by Maxime Ripard
   9) Fix typos and various improvement

v8:
   1) Drop damage update implement and its command line.
   2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
   3) Deduce DC's identification from its compatible property.
   4) Drop the board specific dts patch.
   5) Add documention about the display controller device node.

v9:
   1) Fix the warnings reported by checkpatch script and fix typos

v10:
   1) Pass `make dt_binding_check` validation
   2) Fix warnings reported by kernel test robot

v11:
   1) Convert the driver to use drm bridge and of graph framework.
   2) Dump register value support through debugfs.

Below is a brief introduction of loongson's CPU, bridge chip and SoC.
LS2K1000 is a double core 1.0Ghz mips64r2 compatible SoC[1]. LS7A1000 is
a bridge chip made by Loongson corporation which act as north and/or south
bridge of loongson's desktop and server level processor. It is equivalent
to AMD RS780E+SB710 or something like that. More details can be read from
its user manual[2].

This bridge chip is typically use with LS3A3000, LS3A4000 and LS3A5000 cpu.
LS3A3000 is 4 core 1.45gHz mips64r2 compatible cpu.
LS3A4000 is 4 core 1.8gHz mips64r5 compatible cpu[3].
LS3A5000 is 4 core 2.5gHz loongarch cpu[4].

Nearly all loongson cpu has the hardware maintain the cache coherency,
except for early version of ls2k1000 or ls3a2000. This is the most distinct
feature from other Mips cpu.

[1] https://wiki.debian.org/InstallingDebianOn/Lemote/Loongson2K1000
[2] https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanual-EN.html
[3] https://ee-paper.com/loongson-3a4000-3b4000-motherboard-products-are-compatible-with-uos-system/
[4] https://loongson.github.io/LoongArch-Documentation/Loongson-3A5000-usermanual-EN.html
[5] https://github.com/loongson-community/pmon

suijingfeng (7):
  MIPS: Loongson64: dts: update the display controller device node
  MIPS: Loongson64: dts: introduce ls3A4000 evaluation board
  MIPS: Loongson64: dts: introduce lemote A1901 motherboard
  MIPS: Loongson64: dts: introduce ls2k1000 pai evaluation board
  dt-bindings: display: Add Loongson display controller
  MIPS: Loongson64: defconfig: enable display bridge drivers on Loongson64
  drm/lsdc: add drm driver for loongson display controller

 .../loongson/loongson,display-controller.yaml | 230 +++++++
 arch/mips/boot/dts/loongson/lemote_a1901.dts  |  92 +++
 .../boot/dts/loongson/loongson64-2k1000.dtsi  |  24 +
 arch/mips/boot/dts/loongson/ls2k1000_pai.dts  | 102 ++++
 .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 136 +++++
 arch/mips/boot/dts/loongson/ls7a-pch.dtsi     |  36 +-
 arch/mips/configs/loongson2k_defconfig        |   5 +
 arch/mips/configs/loongson3_defconfig         |   5 +
 drivers/gpu/drm/Kconfig                       |   2 +
 drivers/gpu/drm/Makefile                      |   1 +
 drivers/gpu/drm/lsdc/Kconfig                  |  23 +
 drivers/gpu/drm/lsdc/Makefile                 |  13 +
 drivers/gpu/drm/lsdc/lsdc_crtc.c              | 396 ++++++++++++
 drivers/gpu/drm/lsdc/lsdc_drv.c               | 547 +++++++++++++++++
 drivers/gpu/drm/lsdc/lsdc_drv.h               | 197 ++++++
 drivers/gpu/drm/lsdc/lsdc_i2c.c               | 235 +++++++
 drivers/gpu/drm/lsdc/lsdc_i2c.h               |  42 ++
 drivers/gpu/drm/lsdc/lsdc_irq.c               |  58 ++
 drivers/gpu/drm/lsdc/lsdc_irq.h               |  18 +
 drivers/gpu/drm/lsdc/lsdc_output.c            | 262 ++++++++
 drivers/gpu/drm/lsdc/lsdc_output.h            |  24 +
 drivers/gpu/drm/lsdc/lsdc_pci_drv.c           | 328 ++++++++++
 drivers/gpu/drm/lsdc/lsdc_plane.c             | 470 ++++++++++++++
 drivers/gpu/drm/lsdc/lsdc_pll.c               | 574 ++++++++++++++++++
 drivers/gpu/drm/lsdc/lsdc_pll.h               |  88 +++
 drivers/gpu/drm/lsdc/lsdc_regs.h              | 220 +++++++
 26 files changed, 4123 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
 create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts
 create mode 100644 arch/mips/boot/dts/loongson/ls2k1000_pai.dts
 create mode 100644 arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
 create mode 100644 drivers/gpu/drm/lsdc/Kconfig
 create mode 100644 drivers/gpu/drm/lsdc/Makefile
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.h
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.h
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.h
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_pci_drv.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h
 create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h

-- 
2.25.1

[PATCH v11 1/7] MIPS: Loongson64: dts: update the display controller device node

[Sui Jingfeng]

From: suijingfeng <suijingfeng@loongson.cn>

The display controller is a pci device, it is used in ls2k1000 SoC and
LS7A1000 bridge. Its PCI vendor id is 0x0014, Tts PCI device id is 0x7a06.
In order to let the driver to know which chip the DC is contained in,
the compatible of the display controller is named according to the chip's
name.

For LS7A1000, there are 4 dedicated GPIOs whose control register is
located at the DC register space. They are used to emulate i2c for reading
edid from the monitor. One for DVO0, another for DVO1.

LS2K1000 and LS2K0500 SoC don't have such GPIOs, they grab i2c adapter
from other module, either general purpose GPIO emulated i2c or hardware
i2c adapter.

Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
---
 .../boot/dts/loongson/loongson64-2k1000.dtsi  | 24 +++++++++++++
 arch/mips/boot/dts/loongson/ls7a-pch.dtsi     | 36 ++++++++++++++++---
 2 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
index 8143a61111e3..b168cccc3399 100644
--- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -198,6 +198,30 @@ sata@8,0 {
 				interrupt-parent = <&liointc0>;
 			};
 
+			lsdc: display-controller@6,0 {
+				compatible = "loongson,ls2k1000-dc";
+
+				reg = <0x3000 0x0 0x0 0x0 0x0>;
+				interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+				interrupt-parent = <&liointc0>;
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+						dc_out_rgb0: endpoint {
+						};
+					};
+					port@1 {
+						reg = <1>;
+						dc_out_rgb1: endpoint {
+						};
+					};
+				};
+			};
+
 			pci_bridge@9,0 {
 				compatible = "pci0014,7a19.0",
 						   "pci0014,7a19",
diff --git a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
index 2f45fce2cdc4..fcea73006f7a 100644
--- a/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/ls7a-pch.dtsi
@@ -160,15 +160,41 @@ gpu@6,0 {
 				interrupt-parent = <&pic>;
 			};
 
-			dc@6,1 {
-				compatible = "pci0014,7a06.0",
-						   "pci0014,7a06",
-						   "pciclass030000",
-						   "pciclass0300";
+			lsdc: display-controller@6,1 {
+				compatible = "loongson,ls7a1000-dc";
 
 				reg = <0x3100 0x0 0x0 0x0 0x0>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
 				interrupt-parent = <&pic>;
+
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				i2c6: i2c-gpio@0 {
+					compatible = "lsdc,i2c-gpio-0";
+					reg = <6>;
+				};
+
+				i2c7: i2c-gpio@1 {
+					compatible = "lsdc,i2c-gpio-1";
+					reg = <7>;
+				};
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+						dc_out_rgb0: endpoint {
+						};
+					};
+					port@1 {
+						reg = <1>;
+						dc_out_rgb1: endpoint {
+						};
+					};
+				};
 			};
 
 			hda@7,0 {
-- 
2.25.1

[PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Sui Jingfeng]

From: suijingfeng <suijingfeng@loongson.cn>

The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
therefore can play with discrete graphics card.

While the integrated display copntroller is equipped with a VGA output
and a DVI output, the VGA is connect to the DVO0 output port of the
display controller, the DVI is connected to DVO1 output port of the
display controller.

    +------+            +-----------------------------------+
    | DDR4 |            |  +-------------------+            |
    +------+            |  | PCIe Root complex |   LS7A1000 |
       || MC0           |  +--++---------++----+            |
  +----------+  HT 3.0  |     ||         ||                 |
  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +----------+          | +--------+  +-+--+-+    +---------+   +------+
       || MC1           +---------------|--|----------------+
    +------+                            |  |
    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
                      +-------+                      +------+

Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
---
 .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 136 ++++++++++++++++++
 1 file changed, 136 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts

diff --git a/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
new file mode 100644
index 000000000000..f467eddccdac
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "loongson64g-package.dtsi"
+#include "ls7a-pch.dtsi"
+
+/ {
+	compatible = "loongson,loongson64g-4core-ls7a";
+	model = "LS3A4000_7A1000_EVB_BOARD_V1.4";
+
+	vga-encoder {
+		compatible = "adi,adv7123", "dumb-vga-dac";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				adv7123_in: endpoint {
+					remote-endpoint = <&dc_out_rgb0>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				adv7123_out: endpoint {
+					remote-endpoint = <&vga_connector_in>;
+				};
+			};
+		};
+	};
+
+	vga-connector {
+		compatible = "vga-connector";
+		label = "vga";
+
+		ddc-i2c-bus = <&i2c6>;
+
+		port {
+			vga_connector_in: endpoint {
+				remote-endpoint = <&adv7123_out>;
+			};
+		};
+	};
+
+	tfp410: dvi-encoder {
+		compatible = "ti,tfp410";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				tfp410_in: endpoint {
+					pclk-sample = <1>;
+					bus-width = <24>;
+					remote-endpoint = <&dc_out_rgb1>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				tfp410_out: endpoint {
+					remote-endpoint = <&dvi_connector_in>;
+				};
+			};
+		};
+	};
+
+	dvi-connector {
+		compatible = "dvi-connector";
+		label = "dvi";
+		digital;
+
+		ddc-i2c-bus = <&i2c7>;
+
+		port {
+			dvi_connector_in: endpoint {
+				remote-endpoint = <&tfp410_out>;
+			};
+		};
+	};
+};
+
+&package0 {
+	htvec: interrupt-controller@efdfb000080 {
+		compatible = "loongson,htvec-1.0";
+		reg = <0xefd 0xfb000080 0x40>;
+		interrupt-controller;
+		#interrupt-cells = <1>;
+
+		interrupt-parent = <&liointc>;
+		interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
+			     <25 IRQ_TYPE_LEVEL_HIGH>,
+			     <26 IRQ_TYPE_LEVEL_HIGH>,
+			     <27 IRQ_TYPE_LEVEL_HIGH>,
+			     <28 IRQ_TYPE_LEVEL_HIGH>,
+			     <29 IRQ_TYPE_LEVEL_HIGH>,
+			     <30 IRQ_TYPE_LEVEL_HIGH>,
+			     <31 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+&pch {
+	msi: msi-controller@2ff00000 {
+		compatible = "loongson,pch-msi-1.0";
+		reg = <0 0x2ff00000 0 0x8>;
+		interrupt-controller;
+		msi-controller;
+		loongson,msi-base-vec = <64>;
+		loongson,msi-num-vecs = <192>;
+		interrupt-parent = <&htvec>;
+	};
+};
+
+&lsdc {
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			endpoint {
+				remote-endpoint = <&adv7123_in>;
+			};
+		};
+
+		port@1 {
+			endpoint {
+				remote-endpoint = <&tfp410_in>;
+			};
+		};
+	};
+};
-- 
2.25.1

[PATCH v11 3/7] MIPS: Loongson64: dts: introduce lemote A1901 motherboard

[Sui Jingfeng]

From: suijingfeng <suijingfeng@loongson.cn>

This board is made by LEMOTE corporation, it has two name, one
is LX-6901, another is A1901.

This board has only one VGA output which is connected to the DVO1 of
the display controller.

    +------+            +-----------------------------------+
    | DDR4 |            |  +-------------------+            |
    +------+            |  | PCIe Root complex |   LS7A1000 |
       || MC0           |  +--++---------++----+            |
  +----------+  HT 3.0  |     ||         ||                 |
  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
  +----------+          | +--------+  +-+--+-+    +---------+   +------+
       || MC1           +---------------|--|----------------+
    +------+                            |  |
    | DDR4 |       DVO0 is not get used |  |  DVO1   +-------+
    +------+       <--------------------+  +-------->|ADV7125|---> VGA
                                                     +-------+
The model property added can provided board specific information,
mips kernel use it as machine name.

$ cat /proc/cpuinfo

system type             : Generic Loongson64 System
machine                 : LX-6901  <-------------------- notice here
processor               : 0
cpu model               : ICT Loongson-3 V0.1  FPU V0.1
BogoMIPS                : 3594.02
tlb_entries             : 2112
isa                     : mips64r2
ASEs implemented        : vz msa loongson-ext2
...

Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
---
 arch/mips/boot/dts/loongson/lemote_a1901.dts | 92 ++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts

diff --git a/arch/mips/boot/dts/loongson/lemote_a1901.dts b/arch/mips/boot/dts/loongson/lemote_a1901.dts
new file mode 100644
index 000000000000..f0443bc43af9
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/lemote_a1901.dts
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "loongson64g-package.dtsi"
+#include "ls7a-pch.dtsi"
+
+/ {
+	model = "LX-6901";
+
+	vga-encoder {
+		compatible = "adi,adv7123", "dumb-vga-dac";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				adv7123_in: endpoint {
+					remote-endpoint = <&dc_out_rgb1>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				adv7123_out: endpoint {
+					remote-endpoint = <&vga_connector_in>;
+				};
+			};
+		};
+	};
+
+	vga-connector {
+		compatible = "vga-connector";
+		label = "vga";
+
+		ddc-i2c-bus = <&i2c7>;
+
+		port {
+			vga_connector_in: endpoint {
+				remote-endpoint = <&adv7123_out>;
+			};
+		};
+	};
+};
+
+&package0 {
+	htvec: interrupt-controller@efdfb000080 {
+		compatible = "loongson,htvec-1.0";
+		reg = <0xefd 0xfb000080 0x40>;
+		interrupt-controller;
+		#interrupt-cells = <1>;
+
+		interrupt-parent = <&liointc>;
+		interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
+			     <25 IRQ_TYPE_LEVEL_HIGH>,
+			     <26 IRQ_TYPE_LEVEL_HIGH>,
+			     <27 IRQ_TYPE_LEVEL_HIGH>,
+			     <28 IRQ_TYPE_LEVEL_HIGH>,
+			     <29 IRQ_TYPE_LEVEL_HIGH>,
+			     <30 IRQ_TYPE_LEVEL_HIGH>,
+			     <31 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+&pch {
+	msi: msi-controller@2ff00000 {
+		compatible = "loongson,pch-msi-1.0";
+		reg = <0 0x2ff00000 0 0x8>;
+		interrupt-controller;
+		msi-controller;
+		loongson,msi-base-vec = <64>;
+		loongson,msi-num-vecs = <192>;
+		interrupt-parent = <&htvec>;
+	};
+};
+
+&lsdc {
+	ports {
+		port@0 {
+			status = "disabled";
+		};
+
+		port@1 {
+			status = "ok";
+			endpoint {
+				remote-endpoint = <&adv7123_in>;
+			};
+		};
+	};
+};
-- 
2.25.1

[PATCH v11 4/7] MIPS: Loongson64: dts: introduce ls2k1000 pai evaluation board

[Sui Jingfeng]

From: suijingfeng <suijingfeng@loongson.cn>

   ___________________                           ____________________
  |            -------|                         |                    |
  |  CRTC0 --> | DVO0 ------------------------> | 1024x600 DPI Panel |
  |  _   _     -------|  | Which panel to use   |____________________|
  | | | | |           |  | with this board is a  ___________________
  | |_| |_|           |  | choice of the user   |                   |
  |                   |  +--------------------> | 800x480 DPI Panel |
  |   DC In LS2K1000  |                         |___________________|
  |  _   _            |     +------+
  | | | | |           <---->| i2c1 |-----------+
  | |_| |_|           |     +------+           |
  |                   |        |               |               _________
  |            -------|    +---------+         |              |         |
  |  CRTC1 --> | DVO1 ---> | sii9022 | --> HDMI connector --> | Monitor |
  |            -------|    +---------+                        |_________|
  |___________________|

The sii9022 HDMI transmitter working in transparent mode, in this case
the edid is read from the monitor directly, not through sil9022's ddc
channel. The PMON[2] firmware of this board is responsible for configure
the sii9022 encoder at boot time. Due to i2c driver for lsk2000 SoC is
not upstream yet, we simply replace the sii9022 with a 1024x768 panel.

The i2c0 is not get used by lsdc driver for this board, so there no
need to worry about DVO0.

[1] https://wiki.debian.org/InstallingDebianOn/Lemote/Loongson2K1000
[2] https://github.com/loongson-community/pmon

Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
---
 arch/mips/boot/dts/loongson/ls2k1000_pai.dts | 102 +++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/ls2k1000_pai.dts

diff --git a/arch/mips/boot/dts/loongson/ls2k1000_pai.dts b/arch/mips/boot/dts/loongson/ls2k1000_pai.dts
new file mode 100644
index 000000000000..0b0172d90677
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/ls2k1000_pai.dts
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include "loongson64-2k1000.dtsi"
+
+/ {
+	model = "LS2K1000_PAI_UDB_V1.5";
+
+	panel: display@0 {
+		compatible = "hontron,070JII2135-A2", "panel-dpi";
+		label = "LCD070CG1024600+DC21";
+
+		rotation = <0>;
+		width-mm = <86>;
+		height-mm = <154>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			panel_in: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&dc_out_rgb0>;
+			};
+		};
+
+		panel-timing {
+			clock-frequency = <51200000>;
+			hactive = <1024>;
+			vactive = <600>;
+			hsync-len = <4>;
+			hfront-porch = <160>;
+			hback-porch = <156>;
+			vfront-porch = <11>;
+			vback-porch = <23>;
+			vsync-len = <1>;
+
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+	};
+
+	monitor: display@1 {
+		compatible = "panel-dpi";
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			monitor_in: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&dc_out_rgb1>;
+			};
+		};
+
+		panel-timing {
+			clock-frequency = <65000000>;
+			hactive = <1024>;
+			vactive = <768>;
+			hfront-porch = <24>;
+			hsync-len = <136>;
+			hback-porch = <160>;
+			vfront-porch = <3>;
+			vback-porch = <6>;
+			vsync-len = <29>;
+
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+	};
+};
+
+&lsdc {
+	ports {
+		port@0 {
+			endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+
+		port@1 {
+			endpoint {
+				remote-endpoint = <&monitor_in>;
+			};
+		};
+	};
+};
-- 
2.25.1

[PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

From: suijingfeng <suijingfeng@loongson.cn>

Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
---
 .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
 1 file changed, 230 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml

diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
new file mode 100644
index 000000000000..7be63346289e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
@@ -0,0 +1,230 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
+
+maintainers:
+  - Sui Jingfeng <suijingfeng@loongson.cn>
+
+description: |+
+
+  Loongson display controllers are simple which require scanout buffers
+  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
+  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
+  with a dedicated video RAM which is 64MB or more, precise size can be
+  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
+  chip.
+
+  LSDC has two display pipes, each way has a DVO interface which provide
+  RGB888 signals, vertical & horizontal synchronisations, data enable and
+  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
+  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
+
+  For LS7A1000, there are 4 dedicated GPIOs whose control register is
+  located at the DC register space. They are used to emulate two way i2c,
+  One for DVO0, another for DVO1.
+
+  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
+  general purpose GPIO emulated i2c or hardware i2c in the SoC.
+
+  LSDC's display pipeline have several components as below description,
+
+  The display controller in LS7A1000:
+     ___________________                                     _________
+    |            -------|                                   |         |
+    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
+    |  _   _     -------|        ^             ^            |_________|
+    | | | | |    -------|        |             |
+    | |_| |_|    | i2c0 <--------+-------------+
+    |            -------|
+    |   DC IN LS7A1000  |
+    |  _   _     -------|
+    | | | | |    | i2c1 <--------+-------------+
+    | |_| |_|    -------|        |             |             _________
+    |            -------|        |             |            |         |
+    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
+    |            -------|                                   |_________|
+    |___________________|
+
+  Simple usage of LS7A1000 with LS3A4000 CPU:
+
+    +------+            +-----------------------------------+
+    | DDR4 |            |  +-------------------+            |
+    +------+            |  | PCIe Root complex |   LS7A1000 |
+       || MC0           |  +--++---------++----+            |
+  +----------+  HT 3.0  |     ||         ||                 |
+  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
+  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
+  +----------+          | +--------+  +-+--+-+    +---------+   +------+
+       || MC1           +---------------|--|----------------+
+    +------+                            |  |
+    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
+    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
+                      +-------+                      +------+
+
+  The display controller in LS2K1000/LS2K0500:
+     ___________________                                     _________
+    |            -------|                                   |         |
+    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
+    |  _   _     -------|        ^              ^           |_________|
+    | | | | |           |        |              |
+    | |_| |_|           |     +------+          |
+    |                   <---->| i2c0 |<---------+
+    |   DC IN LS2K1000  |     +------+
+    |  _   _            |     +------+
+    | | | | |           <---->| i2c1 |----------+
+    | |_| |_|           |     +------+          |            _________
+    |            -------|        |              |           |         |
+    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
+    |            -------|                                   |_________|
+    |___________________|
+
+properties:
+  $nodename:
+    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
+
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - loongson,ls7a1000-dc
+              - loongson,ls2k1000-dc
+              - loongson,ls2k0500-dc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  i2c-gpio@0:
+    description: |
+      Built-in GPIO emulate i2c exported for external display bridge
+      configuration, onitor detection and edid read back etc, for ls7a1000
+      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
+      used to specify a I2c adapter bus number, if you don't specify one
+      i2c driver core will dynamically assign a bus number. Please specify
+      it only when its bus number matters. Bus number greater than 6 is safe
+      because ls7a1000 bridge have 6 hardware I2C controller integrated.
+
+  i2c-gpio@1:
+    description: |
+      Built-in GPIO emulate i2c exported for external display bridge
+      configuration, onitor detection and edid read back etc, for ls7a1000
+      only. Its compatible must be lsdc,i2c-gpio-1.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: output port node connected with DPI panels or external encoders, with only one endpoint.
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: output port node connected with DPI panels or external encoders, with only one endpoint.
+
+    required:
+      - port@0
+      - port@1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    bus {
+
+        #address-cells = <3>;
+        #size-cells = <2>;
+        #interrupt-cells = <2>;
+
+        display-controller@6,1 {
+            compatible = "loongson,ls7a1000-dc";
+            reg = <0x3100 0x0 0x0 0x0 0x0>;
+            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
+
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            i2c-gpio@0 {
+                compatible = "lsdc,i2c-gpio-0";
+                reg = <6>;
+                sda = <0>;
+                scl = <1>;
+            };
+
+            i2c-gpio@1 {
+                compatible = "lsdc,i2c-gpio-1";
+                reg = <7>;
+                sda = <2>;
+                scl = <3>;
+            };
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port@0 {
+                    reg = <0>;
+                    endpoint {
+                            remote-endpoint = <&vga_encoder_in>;
+                    };
+                };
+                port@1 {
+                    reg = <1>;
+                    endpoint {
+                            remote-endpoint = <&dvi_encoder_in>;
+                    };
+                };
+            };
+        };
+    };
+
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    bus {
+
+        #address-cells = <3>;
+        #size-cells = <2>;
+        #interrupt-cells = <2>;
+
+        display-controller@6,0 {
+            compatible = "loongson,ls2k1000-dc";
+            reg = <0x3100 0x0 0x0 0x0 0x0>;
+            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port@0 {
+                    reg = <0>;
+                    endpoint {
+                            remote-endpoint = <&panel_in>;
+                    };
+                };
+                port@1 {
+                    reg = <1>;
+                    endpoint {
+                            remote-endpoint = <&hdmi_encoder_in>;
+                    };
+                };
+            };
+        };
+    };
+...
-- 
2.25.1

[PATCH v11 6/7] MIPS: Loongson64: defconfig: enable display bridge drivers on Loongson64

[Sui Jingfeng]

From: suijingfeng <suijingfeng@loongson.cn>

ls3A4000 evb board is shipped with adv7123 and tfp410 while ls2k1000
PI board use a DPI panel from FORLINX and a sii9022 HDMI transmitter.

Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Sui Jingfeng <15330273260@189.cn>
---
 arch/mips/configs/loongson2k_defconfig | 5 +++++
 arch/mips/configs/loongson3_defconfig  | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/arch/mips/configs/loongson2k_defconfig b/arch/mips/configs/loongson2k_defconfig
index e948ca487e2d..0a97c332a5c3 100644
--- a/arch/mips/configs/loongson2k_defconfig
+++ b/arch/mips/configs/loongson2k_defconfig
@@ -243,6 +243,11 @@ CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=y
+CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SIMPLE_BRIDGE=m
+CONFIG_DRM_TI_TFP410=m
 CONFIG_FB_RADEON=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=m
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 25ecd15bc952..35e2fc998768 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -280,6 +280,11 @@ CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
 CONFIG_DRM_RADEON=m
+CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SIMPLE_BRIDGE=m
+CONFIG_DRM_TI_TFP410=m
 CONFIG_DRM_QXL=y
 CONFIG_DRM_VIRTIO_GPU=y
 CONFIG_FB=y
-- 
2.25.1

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> From: suijingfeng <suijingfeng@loongson.cn>
> 

Needs a commit message.

> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> Signed-off-by: Sui Jingfeng <15330273260@189.cn>

Same person? Don't need both emails.

> ---
>  .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
>  1 file changed, 230 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> new file mode 100644
> index 000000000000..7be63346289e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> @@ -0,0 +1,230 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
> +
> +maintainers:
> +  - Sui Jingfeng <suijingfeng@loongson.cn>
> +
> +description: |+
> +
> +  Loongson display controllers are simple which require scanout buffers
> +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
> +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
> +  with a dedicated video RAM which is 64MB or more, precise size can be
> +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
> +  chip.
> +
> +  LSDC has two display pipes, each way has a DVO interface which provide
> +  RGB888 signals, vertical & horizontal synchronisations, data enable and
> +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
> +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
> +
> +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
> +  located at the DC register space. They are used to emulate two way i2c,
> +  One for DVO0, another for DVO1.
> +
> +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
> +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
> +
> +  LSDC's display pipeline have several components as below description,
> +
> +  The display controller in LS7A1000:
> +     ___________________                                     _________
> +    |            -------|                                   |         |
> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> +    |  _   _     -------|        ^             ^            |_________|
> +    | | | | |    -------|        |             |
> +    | |_| |_|    | i2c0 <--------+-------------+
> +    |            -------|
> +    |   DC IN LS7A1000  |
> +    |  _   _     -------|
> +    | | | | |    | i2c1 <--------+-------------+
> +    | |_| |_|    -------|        |             |             _________
> +    |            -------|        |             |            |         |
> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> +    |            -------|                                   |_________|
> +    |___________________|
> +
> +  Simple usage of LS7A1000 with LS3A4000 CPU:
> +
> +    +------+            +-----------------------------------+
> +    | DDR4 |            |  +-------------------+            |
> +    +------+            |  | PCIe Root complex |   LS7A1000 |
> +       || MC0           |  +--++---------++----+            |
> +  +----------+  HT 3.0  |     ||         ||                 |
> +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
> +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
> +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
> +       || MC1           +---------------|--|----------------+
> +    +------+                            |  |
> +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
> +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
> +                      +-------+                      +------+
> +
> +  The display controller in LS2K1000/LS2K0500:
> +     ___________________                                     _________
> +    |            -------|                                   |         |
> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> +    |  _   _     -------|        ^              ^           |_________|
> +    | | | | |           |        |              |
> +    | |_| |_|           |     +------+          |
> +    |                   <---->| i2c0 |<---------+
> +    |   DC IN LS2K1000  |     +------+
> +    |  _   _            |     +------+
> +    | | | | |           <---->| i2c1 |----------+
> +    | |_| |_|           |     +------+          |            _________
> +    |            -------|        |              |           |         |
> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> +    |            -------|                                   |_________|
> +    |___________________|
> +
> +properties:
> +  $nodename:
> +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
> +
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - loongson,ls7a1000-dc
> +              - loongson,ls2k1000-dc
> +              - loongson,ls2k0500-dc
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  i2c-gpio@0:
> +    description: |
> +      Built-in GPIO emulate i2c exported for external display bridge

If you have i2c-gpio, that belongs at the DT top-level, not here.

> +      configuration, onitor detection and edid read back etc, for ls7a1000
> +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be

No, there's a defined i2c-gpio compatible already.

> +      used to specify a I2c adapter bus number, if you don't specify one
> +      i2c driver core will dynamically assign a bus number. Please specify

Bus numbers are a linux detail not relevant to DT binding.

> +      it only when its bus number matters. Bus number greater than 6 is safe
> +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
> +
> +  i2c-gpio@1:
> +    description: |
> +      Built-in GPIO emulate i2c exported for external display bridge
> +      configuration, onitor detection and edid read back etc, for ls7a1000
> +      only. Its compatible must be lsdc,i2c-gpio-1.
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    bus {
> +
> +        #address-cells = <3>;
> +        #size-cells = <2>;
> +        #interrupt-cells = <2>;
> +
> +        display-controller@6,1 {
> +            compatible = "loongson,ls7a1000-dc";
> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> +
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            i2c-gpio@0 {
> +                compatible = "lsdc,i2c-gpio-0";
> +                reg = <6>;
> +                sda = <0>;
> +                scl = <1>;
> +            };
> +
> +            i2c-gpio@1 {
> +                compatible = "lsdc,i2c-gpio-1";
> +                reg = <7>;
> +                sda = <2>;
> +                scl = <3>;
> +            };
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                port@0 {
> +                    reg = <0>;
> +                    endpoint {
> +                            remote-endpoint = <&vga_encoder_in>;
> +                    };
> +                };
> +                port@1 {
> +                    reg = <1>;
> +                    endpoint {
> +                            remote-endpoint = <&dvi_encoder_in>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    bus {
> +
> +        #address-cells = <3>;
> +        #size-cells = <2>;
> +        #interrupt-cells = <2>;
> +
> +        display-controller@6,0 {
> +            compatible = "loongson,ls2k1000-dc";
> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                port@0 {
> +                    reg = <0>;
> +                    endpoint {
> +                            remote-endpoint = <&panel_in>;
> +                    };
> +                };
> +                port@1 {
> +                    reg = <1>;
> +                    endpoint {
> +                            remote-endpoint = <&hdmi_encoder_in>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +...
> -- 
> 2.25.1
> 
> 

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

On 2022/3/22 07:20, Rob Herring wrote:
> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>> From: suijingfeng <suijingfeng@loongson.cn>
>>
> Needs a commit message.
>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> Same person? Don't need both emails.

Yes,  suijingfeng@loongson.cn is my company's email. But it can not be 
used to send patches to dri-devel,

when send patches with this email, the patch will not be shown on patch 
works.

Emails  are either blocked or got  rejected  by loongson's mail server.  
It can only receive emails

from you and other people, but not dri-devel. so have to use my personal 
email(15330273260@189.cn) to send patches.

>> ---
>>   .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
>>   1 file changed, 230 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>> new file mode 100644
>> index 000000000000..7be63346289e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>> @@ -0,0 +1,230 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
>> +
>> +maintainers:
>> +  - Sui Jingfeng <suijingfeng@loongson.cn>
>> +
>> +description: |+
>> +
>> +  Loongson display controllers are simple which require scanout buffers
>> +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
>> +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
>> +  with a dedicated video RAM which is 64MB or more, precise size can be
>> +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
>> +  chip.
>> +
>> +  LSDC has two display pipes, each way has a DVO interface which provide
>> +  RGB888 signals, vertical & horizontal synchronisations, data enable and
>> +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
>> +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
>> +
>> +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
>> +  located at the DC register space. They are used to emulate two way i2c,
>> +  One for DVO0, another for DVO1.
>> +
>> +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
>> +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
>> +
>> +  LSDC's display pipeline have several components as below description,
>> +
>> +  The display controller in LS7A1000:
>> +     ___________________                                     _________
>> +    |            -------|                                   |         |
>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>> +    |  _   _     -------|        ^             ^            |_________|
>> +    | | | | |    -------|        |             |
>> +    | |_| |_|    | i2c0 <--------+-------------+
>> +    |            -------|
>> +    |   DC IN LS7A1000  |
>> +    |  _   _     -------|
>> +    | | | | |    | i2c1 <--------+-------------+
>> +    | |_| |_|    -------|        |             |             _________
>> +    |            -------|        |             |            |         |
>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>> +    |            -------|                                   |_________|
>> +    |___________________|
>> +
>> +  Simple usage of LS7A1000 with LS3A4000 CPU:
>> +
>> +    +------+            +-----------------------------------+
>> +    | DDR4 |            |  +-------------------+            |
>> +    +------+            |  | PCIe Root complex |   LS7A1000 |
>> +       || MC0           |  +--++---------++----+            |
>> +  +----------+  HT 3.0  |     ||         ||                 |
>> +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>> +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>> +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
>> +       || MC1           +---------------|--|----------------+
>> +    +------+                            |  |
>> +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>> +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>> +                      +-------+                      +------+
>> +
>> +  The display controller in LS2K1000/LS2K0500:
>> +     ___________________                                     _________
>> +    |            -------|                                   |         |
>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>> +    |  _   _     -------|        ^              ^           |_________|
>> +    | | | | |           |        |              |
>> +    | |_| |_|           |     +------+          |
>> +    |                   <---->| i2c0 |<---------+
>> +    |   DC IN LS2K1000  |     +------+
>> +    |  _   _            |     +------+
>> +    | | | | |           <---->| i2c1 |----------+
>> +    | |_| |_|           |     +------+          |            _________
>> +    |            -------|        |              |           |         |
>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>> +    |            -------|                                   |_________|
>> +    |___________________|
>> +
>> +properties:
>> +  $nodename:
>> +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
>> +
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - loongson,ls7a1000-dc
>> +              - loongson,ls2k1000-dc
>> +              - loongson,ls2k0500-dc
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  '#address-cells':
>> +    const: 1
>> +
>> +  '#size-cells':
>> +    const: 0
>> +
>> +  i2c-gpio@0:
>> +    description: |
>> +      Built-in GPIO emulate i2c exported for external display bridge
> If you have i2c-gpio, that belongs at the DT top-level, not here.
>
>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>> +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
> No, there's a defined i2c-gpio compatible already.

This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
LSDC register space, not general purpose GPIOs with separate control register resource.
So i think it is the child node of display-controller@6,1, it belongs to LSDC.
It seems that put it at the DT top-level break the hierarchy and relationship.

>> +      used to specify a I2c adapter bus number, if you don't specify one
>> +      i2c driver core will dynamically assign a bus number. Please specify
> Bus numbers are a linux detail not relevant to DT binding.
>
>> +      it only when its bus number matters. Bus number greater than 6 is safe
>> +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
>> +
>> +  i2c-gpio@1:
>> +    description: |
>> +      Built-in GPIO emulate i2c exported for external display bridge
>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>> +      only. Its compatible must be lsdc,i2c-gpio-1.
>> +
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port@0:
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>> +
>> +      port@1:
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>> +
>> +    required:
>> +      - port@0
>> +      - port@1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - interrupts
>> +  - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/interrupt-controller/irq.h>
>> +    bus {
>> +
>> +        #address-cells = <3>;
>> +        #size-cells = <2>;
>> +        #interrupt-cells = <2>;
>> +
>> +        display-controller@6,1 {
>> +            compatible = "loongson,ls7a1000-dc";
>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            i2c-gpio@0 {
>> +                compatible = "lsdc,i2c-gpio-0";
>> +                reg = <6>;
>> +                sda = <0>;
>> +                scl = <1>;
>> +            };
>> +
>> +            i2c-gpio@1 {
>> +                compatible = "lsdc,i2c-gpio-1";
>> +                reg = <7>;
>> +                sda = <2>;
>> +                scl = <3>;
>> +            };
>> +
>> +            ports {
>> +                #address-cells = <1>;
>> +                #size-cells = <0>;
>> +                port@0 {
>> +                    reg = <0>;
>> +                    endpoint {
>> +                            remote-endpoint = <&vga_encoder_in>;
>> +                    };
>> +                };
>> +                port@1 {
>> +                    reg = <1>;
>> +                    endpoint {
>> +                            remote-endpoint = <&dvi_encoder_in>;
>> +                    };
>> +                };
>> +            };
>> +        };
>> +    };
>> +
>> +  - |
>> +    #include <dt-bindings/interrupt-controller/irq.h>
>> +    bus {
>> +
>> +        #address-cells = <3>;
>> +        #size-cells = <2>;
>> +        #interrupt-cells = <2>;
>> +
>> +        display-controller@6,0 {
>> +            compatible = "loongson,ls2k1000-dc";
>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> +            ports {
>> +                #address-cells = <1>;
>> +                #size-cells = <0>;
>> +                port@0 {
>> +                    reg = <0>;
>> +                    endpoint {
>> +                            remote-endpoint = <&panel_in>;
>> +                    };
>> +                };
>> +                port@1 {
>> +                    reg = <1>;
>> +                    endpoint {
>> +                            remote-endpoint = <&hdmi_encoder_in>;
>> +                    };
>> +                };
>> +            };
>> +        };
>> +    };
>> +...
>> -- 
>> 2.25.1
>>
>>

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Jiaxun Yang]

在 2022/3/21 16:29, Sui Jingfeng 写道:
> From: suijingfeng <suijingfeng@loongson.cn>
>
> The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
> mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
> therefore can play with discrete graphics card.

Hi Jingfeng,

As we've discussed before if you are going to introduce new dts then you 
*MUST*
include it in makefile and wire it up in code.

A dts file doing nothing lying in the tree is just suspicious.

Thanks.
- Jiaxun

>
> While the integrated display copntroller is equipped with a VGA output
> and a DVI output, the VGA is connect to the DVO0 output port of the
> display controller, the DVI is connected to DVO1 output port of the
> display controller.
>
>      +------+            +-----------------------------------+
>      | DDR4 |            |  +-------------------+            |
>      +------+            |  | PCIe Root complex |   LS7A1000 |
>         || MC0           |  +--++---------++----+            |
>    +----------+  HT 3.0  |     ||         ||                 |
>    | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>    |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>    +----------+          | +--------+  +-+--+-+    +---------+   +------+
>         || MC1           +---------------|--|----------------+
>      +------+                            |  |
>      | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>      +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>                        +-------+                      +------+
>
> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> ---
>   .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 136 ++++++++++++++++++
>   1 file changed, 136 insertions(+)
>   create mode 100644 arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
>
> diff --git a/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
> new file mode 100644
> index 000000000000..f467eddccdac
> --- /dev/null
> +++ b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
> @@ -0,0 +1,136 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include "loongson64g-package.dtsi"
> +#include "ls7a-pch.dtsi"
> +
> +/ {
> +	compatible = "loongson,loongson64g-4core-ls7a";
> +	model = "LS3A4000_7A1000_EVB_BOARD_V1.4";
> +
> +	vga-encoder {
> +		compatible = "adi,adv7123", "dumb-vga-dac";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +				adv7123_in: endpoint {
> +					remote-endpoint = <&dc_out_rgb0>;
> +				};
> +			};
> +
> +			port@1 {
> +				reg = <1>;
> +				adv7123_out: endpoint {
> +					remote-endpoint = <&vga_connector_in>;
> +				};
> +			};
> +		};
> +	};
> +
> +	vga-connector {
> +		compatible = "vga-connector";
> +		label = "vga";
> +
> +		ddc-i2c-bus = <&i2c6>;
> +
> +		port {
> +			vga_connector_in: endpoint {
> +				remote-endpoint = <&adv7123_out>;
> +			};
> +		};
> +	};
> +
> +	tfp410: dvi-encoder {
> +		compatible = "ti,tfp410";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +				tfp410_in: endpoint {
> +					pclk-sample = <1>;
> +					bus-width = <24>;
> +					remote-endpoint = <&dc_out_rgb1>;
> +				};
> +			};
> +
> +			port@1 {
> +				reg = <1>;
> +				tfp410_out: endpoint {
> +					remote-endpoint = <&dvi_connector_in>;
> +				};
> +			};
> +		};
> +	};
> +
> +	dvi-connector {
> +		compatible = "dvi-connector";
> +		label = "dvi";
> +		digital;
> +
> +		ddc-i2c-bus = <&i2c7>;
> +
> +		port {
> +			dvi_connector_in: endpoint {
> +				remote-endpoint = <&tfp410_out>;
> +			};
> +		};
> +	};
> +};
> +
> +&package0 {
> +	htvec: interrupt-controller@efdfb000080 {
> +		compatible = "loongson,htvec-1.0";
> +		reg = <0xefd 0xfb000080 0x40>;
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +
> +		interrupt-parent = <&liointc>;
> +		interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
> +			     <25 IRQ_TYPE_LEVEL_HIGH>,
> +			     <26 IRQ_TYPE_LEVEL_HIGH>,
> +			     <27 IRQ_TYPE_LEVEL_HIGH>,
> +			     <28 IRQ_TYPE_LEVEL_HIGH>,
> +			     <29 IRQ_TYPE_LEVEL_HIGH>,
> +			     <30 IRQ_TYPE_LEVEL_HIGH>,
> +			     <31 IRQ_TYPE_LEVEL_HIGH>;
> +	};
> +};
> +
> +&pch {
> +	msi: msi-controller@2ff00000 {
> +		compatible = "loongson,pch-msi-1.0";
> +		reg = <0 0x2ff00000 0 0x8>;
> +		interrupt-controller;
> +		msi-controller;
> +		loongson,msi-base-vec = <64>;
> +		loongson,msi-num-vecs = <192>;
> +		interrupt-parent = <&htvec>;
> +	};
> +};
> +
> +&lsdc {
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port@0 {
> +			endpoint {
> +				remote-endpoint = <&adv7123_in>;
> +			};
> +		};
> +
> +		port@1 {
> +			endpoint {
> +				remote-endpoint = <&tfp410_in>;
> +			};
> +		};
> +	};
> +};

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Jiaxun Yang]

在 2022/3/22 2:33, Sui Jingfeng 写道:
>
> On 2022/3/22 07:20, Rob Herring wrote:
>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>
>> Needs a commit message.
>>
>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>> Same person? Don't need both emails.
>
> Yes,  suijingfeng@loongson.cn is my company's email. But it can not be 
> used to send patches to dri-devel,
>
> when send patches with this email, the patch will not be shown on 
> patch works.
>
> Emails  are either blocked or got  rejected  by loongson's mail 
> server.  It can only receive emails
>
> from you and other people, but not dri-devel. so have to use my 
> personal email(15330273260@189.cn) to send patches.
In this case you can just use your company's email to sign-off
code and sending with your personal email. It's common practice.

If you don't want to receiving kernel email in your company mailbox,
you can add a entry in .mailmap .

Thanks.
- Jiaxun

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Sui Jingfeng]

On 2022/3/22 21:05, Jiaxun Yang wrote:
>
>
> 在 2022/3/21 16:29, Sui Jingfeng 写道:
>> From: suijingfeng <suijingfeng@loongson.cn>
>>
>> The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
>> mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
>> therefore can play with discrete graphics card.
>
> Hi Jingfeng,
>
> As we've discussed before if you are going to introduce new dts then 
> you *MUST*
> include it in makefile and wire it up in code.
>
> A dts file doing nothing lying in the tree is just suspicious.
>
> Thanks.
> - Jiaxun
>
Hi, Jiaxun,

I know what you means, but it is the kernel side developer's job.
I am just a naive graphic driver developer,I can not care so much.
Below is my private patch which can be used to built specific dts
into the linux kernel, therefore make the verification easier.


diff --git a/arch/mips/boot/dts/loongson/Makefile b/arch/mips/boot/dts/loongson/Makefile
index 5c6433e441ee..99b66675c4a1 100644
--- a/arch/mips/boot/dts/loongson/Makefile
+++ b/arch/mips/boot/dts/loongson/Makefile
@@ -1,9 +1,22 @@
  # SPDX-License-Identifier: GPL-2.0
-dtb-$(CONFIG_MACH_LOONGSON64)	+= loongson64_2core_2k1000.dtb
-dtb-$(CONFIG_MACH_LOONGSON64)	+= loongson64c_4core_ls7a.dtb
-dtb-$(CONFIG_MACH_LOONGSON64)	+= loongson64c_4core_rs780e.dtb
-dtb-$(CONFIG_MACH_LOONGSON64)	+= loongson64c_8core_rs780e.dtb
-dtb-$(CONFIG_MACH_LOONGSON64)	+= loongson64g_4core_ls7a.dtb
-dtb-$(CONFIG_MACH_LOONGSON64)	+= loongson64v_4core_virtio.dtb
+
+dtb-$(CONFIG_LOONGSON64_LS2K1000_PAI_V1_5)	+= ls2k1000_pai.dtb
+dtb-$(CONFIG_LOONGSON64_LS2K1000_EVB_V1_2)	+= ls2k1000_evb.dtb
+dtb-$(CONFIG_LOONGSON64_LS2K1000_GENERIC)	+= loongson64_2core_2k1000.dtb
+
+dtb-$(CONFIG_LOONGSON64_LS3A3000_LS7A1000)	+= loongson64c_4core_ls7a.dtb
+dtb-$(CONFIG_LOONGSON64_LS3A3000_RS780E)	+= loongson64c_4core_rs780e.dtb
+dtb-$(CONFIG_LOONGSON64_LS3B3000_RS780E)	+= loongson64c_8core_rs780e.dtb
+
+dtb-$(CONFIG_LOONGSON64_LS3A4000_7A1000_LEMOTE_A1901) += lemote_a1901.dtb
+dtb-$(CONFIG_LOONGSON64_LS3A4000_7A1000_EVB_V1_4) += ls3a4000_7a1000_evb.dtb
+dtb-$(CONFIG_LOONGSON64_LS3A4000_7A1000_GENERIC)  += loongson64g_4core_ls7a.dtb
+
+dtb-$(CONFIG_LOONGSON64_BOARD_DEFAULT)	+= loongson64_2core_2k1000.dtb
+dtb-$(CONFIG_LOONGSON64_BOARD_DEFAULT)	+= loongson64c_4core_ls7a.dtb
+dtb-$(CONFIG_LOONGSON64_BOARD_DEFAULT)	+= loongson64c_4core_rs780e.dtb
+dtb-$(CONFIG_LOONGSON64_BOARD_DEFAULT)	+= loongson64c_8core_rs780e.dtb
+dtb-$(CONFIG_LOONGSON64_BOARD_DEFAULT)	+= loongson64g_4core_ls7a.dtb
+dtb-$(CONFIG_LOONGSON64_BOARD_DEFAULT)	+= loongson64v_4core_virtio.dtb
  
  obj-$(CONFIG_BUILTIN_DTB)	+= $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h b/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
index 8be710557bdb..605bfa47b4b9 100644
--- a/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
+++ b/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
@@ -8,10 +8,10 @@
  #ifndef __ASM_MACH_LOONGSON64_BUILTIN_DTBS_H_
  #define __ASM_MACH_LOONGSON64_BUILTIN_DTBS_H_
  
-extern u32 __dtb_loongson64_2core_2k1000_begin[];
-extern u32 __dtb_loongson64c_4core_ls7a_begin[];
-extern u32 __dtb_loongson64c_4core_rs780e_begin[];
-extern u32 __dtb_loongson64c_8core_rs780e_begin[];
-extern u32 __dtb_loongson64g_4core_ls7a_begin[];
-extern u32 __dtb_loongson64v_4core_virtio_begin[];
+extern u32 __weak __dtb_loongson64_2core_2k1000_begin[];
+extern u32 __weak __dtb_loongson64c_4core_ls7a_begin[];
+extern u32 __weak __dtb_loongson64c_4core_rs780e_begin[];
+extern u32 __weak __dtb_loongson64c_8core_rs780e_begin[];
+extern u32 __weak __dtb_loongson64g_4core_ls7a_begin[];
+extern u32 __weak __dtb_loongson64v_4core_virtio_begin[];
  #endif
diff --git a/arch/mips/loongson64/Kconfig b/arch/mips/loongson64/Kconfig
index 517f1f8e81fb..7030185ed0c6 100644
--- a/arch/mips/loongson64/Kconfig
+++ b/arch/mips/loongson64/Kconfig
@@ -12,4 +12,43 @@ config RS780_HPET
  	  Note: This driver is doing some dangerous hack. Please only enable
  	  it on RS780E systems.
  
+choice
+	prompt "Board type"
+	depends on MACH_LOONGSON64
+	depends on BUILTIN_DTB
+	help
+	 pick a device tree that matches the target board.
+
+config LOONGSON64_BOARD_DEFAULT
+	bool "Default"
+
+config LOONGSON64_LS3A4000_7A1000_LEMOTE_A1901
+	bool "LEMOTE A1901 LS3A4000 board"
+
+config LOONGSON64_LS3A4000_7A1000_EVB_V1_4
+	bool "LS3A4000 LS7A1000 evaluation board v1.4"
+
+config LOONGSON64_LS3A4000_7A1000_GENERIC
+	bool "LS3A4000 LS7A1000 generic board"
+
+config LOONGSON64_LS3A3000_LS7A1000
+	bool "LS3A3000 LS7A1000 generic board"
+
+config LOONGSON64_LS3A3000_RS780E
+	bool "LS3A3000 RS780E generic board"
+
+config LOONGSON64_LS3B3000_RS780E
+	bool "LS3B3000 RS780E generic board"
+
+config LOONGSON64_LS2K1000_PAI_V1_5
+	bool "LS2K1000 PAI board V1.5"
+
+config LOONGSON64_LS2K1000_EVB_V1_2
+	bool "LS2K1000 evaluation board V1.2"
+
+config LOONGSON64_LS2K1000_GENERIC
+	bool "LS2K1000 generic"
+
+endchoice
+
  endif # MACH_LOONGSON64
diff --git a/arch/mips/loongson64/setup.c b/arch/mips/loongson64/setup.c
index cb10d14da433..f8859039a4e0 100644
--- a/arch/mips/loongson64/setup.c
+++ b/arch/mips/loongson64/setup.c
@@ -16,6 +16,13 @@ void *loongson_fdt_blob;
  
  void __init plat_mem_setup(void)
  {
+	void *fdt;
+
+	fdt = get_fdt();
+
+	if (fdt)
+		loongson_fdt_blob = fdt;
+
  	if (loongson_fdt_blob)
  		__dt_setup_arch(loongson_fdt_blob);
  }

>>
>> While the integrated display copntroller is equipped with a VGA output
>> and a DVI output, the VGA is connect to the DVO0 output port of the
>> display controller, the DVI is connected to DVO1 output port of the
>> display controller.
>>
>>      +------+            +-----------------------------------+
>>      | DDR4 |            |  +-------------------+            |
>>      +------+            |  | PCIe Root complex |   LS7A1000 |
>>         || MC0           |  +--++---------++----+            |
>>    +----------+  HT 3.0  |     ||         ||                 |
>>    | LS3A4000 |<-------->| +---++---+  +--++--+ +---------+   +------+
>>    |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| 
>> VRAM |
>>    +----------+          | +--------+  +-+--+-+    +---------+ +------+
>>         || MC1           +---------------|--|----------------+
>>      +------+                            |  |
>>      | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>      +------+   VGA <--|ADV7125|<--------+ +-------->|TFP410|--> 
>> DVI/HDMI
>>                        +-------+                      +------+
>>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>> ---
>>   .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 136 ++++++++++++++++++
>>   1 file changed, 136 insertions(+)
>>   create mode 100644 arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
>>
>> diff --git a/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts 
>> b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
>> new file mode 100644
>> index 000000000000..f467eddccdac
>> --- /dev/null
>> +++ b/arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts
>> @@ -0,0 +1,136 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +/dts-v1/;
>> +
>> +#include "loongson64g-package.dtsi"
>> +#include "ls7a-pch.dtsi"
>> +
>> +/ {
>> +    compatible = "loongson,loongson64g-4core-ls7a";
>> +    model = "LS3A4000_7A1000_EVB_BOARD_V1.4";
>> +
>> +    vga-encoder {
>> +        compatible = "adi,adv7123", "dumb-vga-dac";
>> +
>> +        ports {
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            port@0 {
>> +                reg = <0>;
>> +                adv7123_in: endpoint {
>> +                    remote-endpoint = <&dc_out_rgb0>;
>> +                };
>> +            };
>> +
>> +            port@1 {
>> +                reg = <1>;
>> +                adv7123_out: endpoint {
>> +                    remote-endpoint = <&vga_connector_in>;
>> +                };
>> +            };
>> +        };
>> +    };
>> +
>> +    vga-connector {
>> +        compatible = "vga-connector";
>> +        label = "vga";
>> +
>> +        ddc-i2c-bus = <&i2c6>;
>> +
>> +        port {
>> +            vga_connector_in: endpoint {
>> +                remote-endpoint = <&adv7123_out>;
>> +            };
>> +        };
>> +    };
>> +
>> +    tfp410: dvi-encoder {
>> +        compatible = "ti,tfp410";
>> +
>> +        ports {
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            port@0 {
>> +                reg = <0>;
>> +                tfp410_in: endpoint {
>> +                    pclk-sample = <1>;
>> +                    bus-width = <24>;
>> +                    remote-endpoint = <&dc_out_rgb1>;
>> +                };
>> +            };
>> +
>> +            port@1 {
>> +                reg = <1>;
>> +                tfp410_out: endpoint {
>> +                    remote-endpoint = <&dvi_connector_in>;
>> +                };
>> +            };
>> +        };
>> +    };
>> +
>> +    dvi-connector {
>> +        compatible = "dvi-connector";
>> +        label = "dvi";
>> +        digital;
>> +
>> +        ddc-i2c-bus = <&i2c7>;
>> +
>> +        port {
>> +            dvi_connector_in: endpoint {
>> +                remote-endpoint = <&tfp410_out>;
>> +            };
>> +        };
>> +    };
>> +};
>> +
>> +&package0 {
>> +    htvec: interrupt-controller@efdfb000080 {
>> +        compatible = "loongson,htvec-1.0";
>> +        reg = <0xefd 0xfb000080 0x40>;
>> +        interrupt-controller;
>> +        #interrupt-cells = <1>;
>> +
>> +        interrupt-parent = <&liointc>;
>> +        interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <25 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <26 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <27 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <28 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <29 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <30 IRQ_TYPE_LEVEL_HIGH>,
>> +                 <31 IRQ_TYPE_LEVEL_HIGH>;
>> +    };
>> +};
>> +
>> +&pch {
>> +    msi: msi-controller@2ff00000 {
>> +        compatible = "loongson,pch-msi-1.0";
>> +        reg = <0 0x2ff00000 0 0x8>;
>> +        interrupt-controller;
>> +        msi-controller;
>> +        loongson,msi-base-vec = <64>;
>> +        loongson,msi-num-vecs = <192>;
>> +        interrupt-parent = <&htvec>;
>> +    };
>> +};
>> +
>> +&lsdc {
>> +    ports {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        port@0 {
>> +            endpoint {
>> +                remote-endpoint = <&adv7123_in>;
>> +            };
>> +        };
>> +
>> +        port@1 {
>> +            endpoint {
>> +                remote-endpoint = <&tfp410_in>;
>> +            };
>> +        };
>> +    };
>> +};
>

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

On 2022/3/22 21:08, Jiaxun Yang wrote:
>
>
> 在 2022/3/22 2:33, Sui Jingfeng 写道:
>>
>> On 2022/3/22 07:20, Rob Herring wrote:
>>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>
>>> Needs a commit message.
>>>
>>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>>> Same person? Don't need both emails.
>>
>> Yes,  suijingfeng@loongson.cn is my company's email. But it can not 
>> be used to send patches to dri-devel,
>>
>> when send patches with this email, the patch will not be shown on 
>> patch works.
>>
>> Emails  are either blocked or got  rejected  by loongson's mail 
>> server.  It can only receive emails
>>
>> from you and other people, but not dri-devel. so have to use my 
>> personal email(15330273260@189.cn) to send patches.
> In this case you can just use your company's email to sign-off
> code and sending with your personal email. It's common practice.
>
> If you don't want to receiving kernel email in your company mailbox,
> you can add a entry in .mailmap .
>
|I'm using `git send-email -7 --cover-letter --annotate -v11` command to 
send patches, it will automatically sign off patches with the my private 
emails. |

> Thanks.
> - Jiaxun

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Jiaxun Yang]

在 2022/3/22 13:38, Sui Jingfeng 写道:
>
> On 2022/3/22 21:05, Jiaxun Yang wrote:
>>
>>
>> 在 2022/3/21 16:29, Sui Jingfeng 写道:
>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>
>>> The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
>>> mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 slot,
>>> therefore can play with discrete graphics card.
>>
>> Hi Jingfeng,
>>
>> As we've discussed before if you are going to introduce new dts then 
>> you *MUST*
>> include it in makefile and wire it up in code.
>>
>> A dts file doing nothing lying in the tree is just suspicious.
>>
>> Thanks.
>> - Jiaxun
>>
> Hi, Jiaxun,
>
> I know what you means, but it is the kernel side developer's job.
> I am just a naive graphic driver developer,I can not care so much.
> Below is my private patch which can be used to built specific dts
> into the linux kernel, therefore make the verification easier.
Hi Jingfeng,

In kernel world we take care all the stuff we touched ourself :-)

If you are not confident with them please drop those DTS from the patchset
besides the generic one. I can do the rest for you after getting this 
set merged.

Thanks.
- Jiaxun

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Jiaxun Yang]

在 2022/3/22 13:54, Sui Jingfeng 写道:
>
> On 2022/3/22 21:08, Jiaxun Yang wrote:
>>
>>
>> 在 2022/3/22 2:33, Sui Jingfeng 写道:
>>>
>>> On 2022/3/22 07:20, Rob Herring wrote:
>>>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>>
>>>> Needs a commit message.
>>>>
>>>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>>>> Same person? Don't need both emails.
>>>
>>> Yes,  suijingfeng@loongson.cn is my company's email. But it can not 
>>> be used to send patches to dri-devel,
>>>
>>> when send patches with this email, the patch will not be shown on 
>>> patch works.
>>>
>>> Emails  are either blocked or got  rejected  by loongson's mail 
>>> server.  It can only receive emails
>>>
>>> from you and other people, but not dri-devel. so have to use my 
>>> personal email(15330273260@189.cn) to send patches.
>> In this case you can just use your company's email to sign-off
>> code and sending with your personal email. It's common practice.
>>
>> If you don't want to receiving kernel email in your company mailbox,
>> you can add a entry in .mailmap .
>>
> |I'm using `git send-email -7 --cover-letter --annotate -v11` command 
> to send patches, it will automatically sign off patches with the my 
> private emails. |
The alternative solution is:

git format-patch -7 -v11 --cover-letter
git send-email ./*.patch

Thanks.
- Jiaxun

>
>> Thanks.
>> - Jiaxun

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Tue, Mar 22, 2022 at 09:54:08PM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/22 21:08, Jiaxun Yang wrote:
> > 
> > 
> > 在 2022/3/22 2:33, Sui Jingfeng 写道:
> > > 
> > > On 2022/3/22 07:20, Rob Herring wrote:
> > > > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > > > From: suijingfeng <suijingfeng@loongson.cn>
> > > > > 
> > > > Needs a commit message.
> > > > 
> > > > > Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> > > > > Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> > > > Same person? Don't need both emails.
> > > 
> > > Yes,  suijingfeng@loongson.cn is my company's email. But it can not
> > > be used to send patches to dri-devel,
> > > 
> > > when send patches with this email, the patch will not be shown on
> > > patch works.
> > > 
> > > Emails  are either blocked or got  rejected  by loongson's mail
> > > server.  It can only receive emails
> > > 
> > > from you and other people, but not dri-devel. so have to use my
> > > personal email(15330273260@189.cn) to send patches.
> > In this case you can just use your company's email to sign-off
> > code and sending with your personal email. It's common practice.
> > 
> > If you don't want to receiving kernel email in your company mailbox,
> > you can add a entry in .mailmap .
> > 
> |I'm using `git send-email -7 --cover-letter --annotate -v11` command to
> send patches, it will automatically sign off patches with the my private
> emails. |

I think that is only if you set your git config author to your private 
email. Pretty much anything git might automatically do can be turned 
off.

Rob

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Rob Herring]

On Tue, Mar 22, 2022 at 12:29:16AM +0800, Sui Jingfeng wrote:
> From: suijingfeng <suijingfeng@loongson.cn>
> 
> There is a display controller in loongson's LS2K1000 SoC and LS7A1000
> bridge chip, the display controller is a PCI device in those chips. It
> has two display pipes but with only one hardware cursor. Each way has
> a DVO interface which provide RGB888 signals, vertical & horizontal
> synchronisations, data enable and the pixel clock. Each CRTC is able to
> scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
> 2048x2048 according to the hardware spec. Loongson display controllers
> are simple which require scanout buffers to be physically contiguous.
> 
> For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
> which is typically 64MB or more. In this case, VRAM helper based driver
> is intend to be used. While LS2K1000 is a SoC, only system memory is
> available. Therefore CMA helper based driver is intend to be used. It is
> possible to use VRAM helper based solution by carving out part of system
> memory as VRAM though.
> 
> For LS7A1000, there are 4 dedicated GPIOs whose control register is
> located at the DC register space, They are used to emulate two way i2c.
> One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
> GPIO hardwared, they grab i2c adapter from other module, either general
> purpose GPIO emulated i2c or hardware i2c adapter.
> 
>     +------+            +-----------------------------------+
>     | DDR4 |            |  +-------------------+            |
>     +------+            |  | PCIe Root complex |   LS7A1000 |
>        || MC0           |  +--++---------++----+            |
>   +----------+  HT 3.0  |     ||         ||                 |
>   | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>   |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>   +----------+          | +--------+  +-+--+-+    +---------+   +------+
>        || MC1           +---------------|--|----------------+
>     +------+                            |  |
>     | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>     +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>                       +-------+                      +------+
> 
> The above picture give a simple usage of LS7A1000, note that the encoder
> is not necessary adv7125 or tfp410, other candicates can be ch7034b,
> sil9022, ite66121 and lt8618 etc.
> 
> v2: Fixup warnings reported by kernel test robot
> 
> v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
>     more details about lsdc.
> 
> v4:
>    1) Add dts required and explain why device tree is required.
>    2) Give more description about lsdc and VRAM helper based driver.
>    3) Fix warnings reported by kernel test robot.
>    4) Introduce stride_alignment member into struct lsdc_chip_desc, the
>       stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.
> 
> v5:
>    1) Using writel and readl replace writeq and readq, to fix kernel test
>       robot report build error on other archtecture.
>    2) Set default fb format to XRGB8888 at crtc reset time.
> 
> v6:
>    1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
>    2) Explain why tiny drm driver is not suitable for us.
>    3) Give a short description of the trival dirty uppdate implement based
>       on CMA helper.
> 
> v7:
>    1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
>    2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
>    3) Remove lsdc_pixpll_print(), part of it move to debugfs.
>    4) Set prefer_shadow to true if vram based driver is in using.
>    5) Replace double blank lines with single line in all files.
>    6) Verbose cmd line parameter is replaced with drm_dbg()
>    7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
>    8) Get edid from dtb support is removed as suggested by Maxime Ripard
>    9) Fix typos and various improvement
> 
> v8:
>    1) Drop damage update implement and its command line.
>    2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
>    3) Deduce DC's identification from its compatible property.
>    4) Drop the board specific dts patch.
>    5) Add documention about the display controller device node.
> 
> v9:
>    1) Fix the warnings reported by checkpatch script and fix typos
> 
> v10:
>    1) Pass `make dt_binding_check` validation
>    2) Fix warnings reported by kernel test robot
> 
> v11:
>    1) Convert the driver to use drm bridge and of graph framework.
>    2) Dump register value support through debugfs.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> ---
>  drivers/gpu/drm/Kconfig             |   2 +
>  drivers/gpu/drm/Makefile            |   1 +
>  drivers/gpu/drm/lsdc/Kconfig        |  23 ++
>  drivers/gpu/drm/lsdc/Makefile       |  13 +
>  drivers/gpu/drm/lsdc/lsdc_crtc.c    | 396 +++++++++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_drv.c     | 547 ++++++++++++++++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_drv.h     | 197 ++++++++++
>  drivers/gpu/drm/lsdc/lsdc_i2c.c     | 235 ++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_i2c.h     |  42 ++
>  drivers/gpu/drm/lsdc/lsdc_irq.c     |  58 +++
>  drivers/gpu/drm/lsdc/lsdc_irq.h     |  18 +
>  drivers/gpu/drm/lsdc/lsdc_output.c  | 262 +++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_output.h  |  24 ++
>  drivers/gpu/drm/lsdc/lsdc_pci_drv.c | 328 ++++++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_plane.c   | 470 +++++++++++++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_pll.c     | 574 ++++++++++++++++++++++++++++
>  drivers/gpu/drm/lsdc/lsdc_pll.h     |  88 +++++
>  drivers/gpu/drm/lsdc/lsdc_regs.h    | 220 +++++++++++
>  18 files changed, 3498 insertions(+)
>  create mode 100644 drivers/gpu/drm/lsdc/Kconfig
>  create mode 100644 drivers/gpu/drm/lsdc/Makefile
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.h
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.h
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.h
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_pci_drv.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h
>  create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h

[...]

> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.c b/drivers/gpu/drm/lsdc/lsdc_i2c.c
> new file mode 100644
> index 000000000000..55beed9266fa
> --- /dev/null
> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.c
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KMS driver for Loongson display controller

Not really a useful comment since every file has the same one.

> + * Copyright (C) 2022 Loongson Corporation
> + */
> +
> +/*
> + * Authors:
> + *      Sui Jingfeng <suijingfeng@loongson.cn>
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/pci.h>
> +
> +#include "lsdc_drv.h"
> +#include "lsdc_regs.h"
> +#include "lsdc_i2c.h"
> +
> +/*
> + * ls7a_gpio_i2c_set - set the state of a gpio pin indicated by mask
> + * @mask: gpio pin mask
> + */
> +static void ls7a_gpio_i2c_set(struct lsdc_i2c * const li2c, int mask, int state)
> +{
> +	unsigned long flags;
> +	u8 val;
> +
> +	spin_lock_irqsave(&li2c->reglock, flags);

What are you protecting? Doesn't the caller serialize calls to these 
functions?

> +
> +	if (state) {
> +		val = readb(li2c->dir_reg);
> +		val |= mask;
> +		writeb(val, li2c->dir_reg);
> +	} else {
> +		val = readb(li2c->dir_reg);
> +		val &= ~mask;
> +		writeb(val, li2c->dir_reg);
> +
> +		val = readb(li2c->dat_reg);
> +		if (state)

This condition is never true. We're in the 'else' because !state.

> +			val |= mask;
> +		else
> +			val &= ~mask;
> +		writeb(val, li2c->dat_reg);

Shouldn't you set the data register low first and then change the 
direction? Otherwise, you may be driving high for a moment. However, if 
high is always done by setting the direction as input, why write the 
data register each time? I'm assuming whatever is written to the dat_reg 
is maintained regardless of pin state.

> +	}
> +
> +	spin_unlock_irqrestore(&li2c->reglock, flags);
> +}
> +
> +/*
> + * ls7a_gpio_i2c_get - read value back from gpio pin
> + * @mask: gpio pin mask
> + */
> +static int ls7a_gpio_i2c_get(struct lsdc_i2c * const li2c, int mask)
> +{
> +	unsigned long flags;
> +	u8 val;
> +
> +	spin_lock_irqsave(&li2c->reglock, flags);
> +
> +	/* first set this pin as input */
> +	val = readb(li2c->dir_reg);
> +	val |= mask;
> +	writeb(val, li2c->dir_reg);
> +
> +	/* then get level state from this pin */
> +	val = readb(li2c->dat_reg);
> +
> +	spin_unlock_irqrestore(&li2c->reglock, flags);
> +
> +	return (val & mask) ? 1 : 0;
> +}
> +
> +/* set the state on the i2c->sda pin */
> +static void ls7a_i2c_set_sda(void *i2c, int state)
> +{
> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
> +
> +	return ls7a_gpio_i2c_set(li2c, li2c->sda, state);
> +}
> +
> +/* set the state on the i2c->scl pin */
> +static void ls7a_i2c_set_scl(void *i2c, int state)
> +{
> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
> +
> +	return ls7a_gpio_i2c_set(li2c, li2c->scl, state);
> +}
> +
> +/* read the value from the i2c->sda pin */
> +static int ls7a_i2c_get_sda(void *i2c)
> +{
> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
> +
> +	return ls7a_gpio_i2c_get(li2c, li2c->sda);
> +}
> +
> +/* read the value from the i2c->scl pin */
> +static int ls7a_i2c_get_scl(void *i2c)
> +{
> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
> +
> +	return ls7a_gpio_i2c_get(li2c, li2c->scl);
> +}
> +
> +/*
> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
> + *
> + * @index : output channel index, 0 for DVO0, 1 for DVO1
> + */
> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
> +{
> +	char compat[32] = {0};
> +	unsigned int udelay = 5;
> +	unsigned int timeout = 2200;
> +	int nr = -1;
> +	struct i2c_adapter *adapter;
> +	struct lsdc_i2c *li2c;
> +	struct device_node *i2c_np;
> +	int ret;
> +
> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
> +	if (!li2c)
> +		return ERR_PTR(-ENOMEM);
> +
> +	li2c->index = index;
> +	li2c->dev = dev;
> +
> +	if (index == 0) {
> +		li2c->sda = 0x01;
> +		li2c->scl = 0x02;
> +	} else if (index == 1) {
> +		li2c->sda = 0x04;
> +		li2c->scl = 0x08;

Just require this to be in DT rather than having some default.

> +	}
> +
> +	spin_lock_init(&li2c->reglock);
> +
> +	snprintf(compat, sizeof(compat), "lsdc,i2c-gpio-%d", index);

compatible values shouldn't have an index and you shouldn't need a 
index in DT. You need to iterate over child nodes with matching 
compatible.

> +	i2c_np = of_find_compatible_node(dev->of_node, NULL, compat);
> +	if (i2c_np) {
> +		u32 sda, scl;
> +
> +		dev_dbg(dev, "Has %s property in the DT", compat);
> +
> +		/*  */
> +		ret = of_property_read_u32(i2c_np, "sda", &sda);

Custom properties need a vendor prefix.

> +		if (ret == 0)
> +			li2c->sda = 1 << sda;
> +
> +		ret = of_property_read_u32(i2c_np, "scl", &scl);
> +		if (ret == 0)
> +			li2c->scl = 1 << scl;
> +
> +		/* Optional properties which made the driver more flexible */
> +		of_property_read_u32(i2c_np, "udelay", &udelay);
> +		of_property_read_u32(i2c_np, "timeout", &timeout);

These aren't documented. Do you really need them in DT?

> +		of_property_read_u32(i2c_np, "reg", &nr);
> +	}
> +
> +	dev_dbg(dev, "%s: sda=%u, scl=%u, nr=%d, udelay=%u, timeout=%u\n",
> +		compat, li2c->sda, li2c->scl, nr, udelay, timeout);
> +
> +	li2c->reg_base = base;
> +
> +	li2c->dir_reg = li2c->reg_base + LS7A_DC_GPIO_DIR_REG;
> +	li2c->dat_reg = li2c->reg_base + LS7A_DC_GPIO_DAT_REG;
> +
> +	li2c->bit.setsda = ls7a_i2c_set_sda;
> +	li2c->bit.setscl = ls7a_i2c_set_scl;
> +	li2c->bit.getsda = ls7a_i2c_get_sda;
> +	li2c->bit.getscl = ls7a_i2c_get_scl;
> +	li2c->bit.udelay = udelay;
> +	li2c->bit.timeout = usecs_to_jiffies(timeout);
> +	li2c->bit.data = li2c;
> +
> +	adapter = &li2c->adapter;
> +	adapter->algo_data = &li2c->bit;
> +	adapter->owner = THIS_MODULE;
> +	adapter->class = I2C_CLASS_DDC;
> +	adapter->dev.parent = dev;
> +	adapter->nr = nr;
> +	if (i2c_np) {
> +		adapter->dev.of_node = i2c_np;
> +		of_node_put(i2c_np);
> +	}
> +
> +	strscpy(adapter->name, &compat[5], sizeof(adapter->name));
> +
> +	i2c_set_adapdata(adapter, li2c);
> +
> +	ret = i2c_bit_add_numbered_bus(adapter);

Why do you care what the bus number is? You shouldn't need to.

> +	if (ret) {
> +		if (i2c_np)
> +			of_node_put(i2c_np);
> +
> +		devm_kfree(dev, li2c);
> +		return ERR_PTR(ret);
> +	}
> +
> +	return li2c;
> +}
> +
> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c)
> +{
> +	struct i2c_adapter *adapter;
> +
> +	if (li2c) {
> +		adapter = &li2c->adapter;
> +
> +		if (adapter && adapter->dev.of_node)
> +			of_node_put(adapter->dev.of_node);
> +
> +		devm_kfree(ddev->dev, li2c);
> +	}
> +}
> +
> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
> +					 unsigned int index)
> +{
> +	const struct lsdc_chip_desc * const descp = ldev->desc;
> +	struct lsdc_i2c *li2c;
> +
> +	if (index >= descp->num_of_crtc) {
> +		drm_err(ldev->ddev, "I2c adapter is no more than %u, %u\n",
> +			descp->num_of_crtc, index);
> +		return NULL;
> +	}
> +
> +	li2c = ldev->li2c[index];
> +	if (li2c)
> +		return &li2c->adapter;
> +
> +	return NULL;
> +}
> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.h b/drivers/gpu/drm/lsdc/lsdc_i2c.h
> new file mode 100644
> index 000000000000..4ab825143eb4
> --- /dev/null
> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * KMS driver for Loongson display controller
> + * Copyright (C) 2022 Loongson Corporation
> + */
> +
> +/*
> + * Authors:
> + *      Sui Jingfeng <suijingfeng@loongson.cn>
> + */
> +
> +#ifndef __LSDC_I2C__
> +#define __LSDC_I2C__
> +
> +#include <linux/i2c.h>
> +#include <linux/i2c-algo-bit.h>
> +#include <linux/pci.h>
> +
> +struct lsdc_i2c {
> +	struct device *dev;
> +	struct i2c_adapter adapter;
> +	struct i2c_algo_bit_data bit;
> +	/* @reglock: protects concurrent register access */
> +	spinlock_t reglock;
> +	void __iomem *reg_base;
> +	void __iomem *dir_reg;
> +	void __iomem *dat_reg;
> +	int index;
> +	/* pin bit mask */
> +	u8 sda;
> +	u8 scl;
> +};
> +
> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c);
> +
> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev,
> +				      void *base,
> +				      unsigned int index);
> +
> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
> +					 unsigned int index);
> +#endif

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/22 07:20, Rob Herring wrote:
> > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > From: suijingfeng <suijingfeng@loongson.cn>
> > > 
> > Needs a commit message.
> > 
> > > Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> > > Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> > Same person? Don't need both emails.
> 
> Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
> to send patches to dri-devel,
> 
> when send patches with this email, the patch will not be shown on patch
> works.
> 
> Emails  are either blocked or got  rejected  by loongson's mail server.  It
> can only receive emails
> 
> from you and other people, but not dri-devel. so have to use my personal
> email(15330273260@189.cn) to send patches.
> 
> > > ---
> > >   .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
> > >   1 file changed, 230 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > new file mode 100644
> > > index 000000000000..7be63346289e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > @@ -0,0 +1,230 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
> > > +
> > > +maintainers:
> > > +  - Sui Jingfeng <suijingfeng@loongson.cn>
> > > +
> > > +description: |+
> > > +
> > > +  Loongson display controllers are simple which require scanout buffers
> > > +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
> > > +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
> > > +  with a dedicated video RAM which is 64MB or more, precise size can be
> > > +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
> > > +  chip.
> > > +
> > > +  LSDC has two display pipes, each way has a DVO interface which provide
> > > +  RGB888 signals, vertical & horizontal synchronisations, data enable and
> > > +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
> > > +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
> > > +
> > > +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
> > > +  located at the DC register space. They are used to emulate two way i2c,
> > > +  One for DVO0, another for DVO1.
> > > +
> > > +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
> > > +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
> > > +
> > > +  LSDC's display pipeline have several components as below description,
> > > +
> > > +  The display controller in LS7A1000:
> > > +     ___________________                                     _________
> > > +    |            -------|                                   |         |
> > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > +    |  _   _     -------|        ^             ^            |_________|
> > > +    | | | | |    -------|        |             |
> > > +    | |_| |_|    | i2c0 <--------+-------------+
> > > +    |            -------|
> > > +    |   DC IN LS7A1000  |
> > > +    |  _   _     -------|
> > > +    | | | | |    | i2c1 <--------+-------------+
> > > +    | |_| |_|    -------|        |             |             _________
> > > +    |            -------|        |             |            |         |
> > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > +    |            -------|                                   |_________|
> > > +    |___________________|
> > > +
> > > +  Simple usage of LS7A1000 with LS3A4000 CPU:
> > > +
> > > +    +------+            +-----------------------------------+
> > > +    | DDR4 |            |  +-------------------+            |
> > > +    +------+            |  | PCIe Root complex |   LS7A1000 |
> > > +       || MC0           |  +--++---------++----+            |
> > > +  +----------+  HT 3.0  |     ||         ||                 |
> > > +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
> > > +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
> > > +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
> > > +       || MC1           +---------------|--|----------------+
> > > +    +------+                            |  |
> > > +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
> > > +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
> > > +                      +-------+                      +------+
> > > +
> > > +  The display controller in LS2K1000/LS2K0500:
> > > +     ___________________                                     _________
> > > +    |            -------|                                   |         |
> > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > +    |  _   _     -------|        ^              ^           |_________|
> > > +    | | | | |           |        |              |
> > > +    | |_| |_|           |     +------+          |
> > > +    |                   <---->| i2c0 |<---------+
> > > +    |   DC IN LS2K1000  |     +------+
> > > +    |  _   _            |     +------+
> > > +    | | | | |           <---->| i2c1 |----------+
> > > +    | |_| |_|           |     +------+          |            _________
> > > +    |            -------|        |              |           |         |
> > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > +    |            -------|                                   |_________|
> > > +    |___________________|
> > > +
> > > +properties:
> > > +  $nodename:
> > > +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
> > > +
> > > +  compatible:
> > > +    oneOf:
> > > +      - items:
> > > +          - enum:
> > > +              - loongson,ls7a1000-dc
> > > +              - loongson,ls2k1000-dc
> > > +              - loongson,ls2k0500-dc
> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +  interrupts:
> > > +    maxItems: 1
> > > +
> > > +  '#address-cells':
> > > +    const: 1
> > > +
> > > +  '#size-cells':
> > > +    const: 0
> > > +
> > > +  i2c-gpio@0:
> > > +    description: |
> > > +      Built-in GPIO emulate i2c exported for external display bridge
> > If you have i2c-gpio, that belongs at the DT top-level, not here.
> > 
> > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
> > No, there's a defined i2c-gpio compatible already.
> 
> This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
> By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
> adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
> LSDC register space, not general purpose GPIOs with separate control register resource.
> So i think it is the child node of display-controller@6,1, it belongs to LSDC.
> It seems that put it at the DT top-level break the hierarchy and relationship.

Okay, I see. Then just 'i2c' for the node names. You need a reference to 
i2c-controller.yaml for these nodes too.

The compatible should not have an index in it.


> 
> > > +      used to specify a I2c adapter bus number, if you don't specify one
> > > +      i2c driver core will dynamically assign a bus number. Please specify
> > Bus numbers are a linux detail not relevant to DT binding.
> > 
> > > +      it only when its bus number matters. Bus number greater than 6 is safe
> > > +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
> > > +
> > > +  i2c-gpio@1:
> > > +    description: |
> > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > +      only. Its compatible must be lsdc,i2c-gpio-1.
> > > +
> > > +  ports:
> > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > +
> > > +    properties:
> > > +      port@0:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > +
> > > +      port@1:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > +
> > > +    required:
> > > +      - port@0
> > > +      - port@1
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - interrupts
> > > +  - ports
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > +    bus {
> > > +
> > > +        #address-cells = <3>;
> > > +        #size-cells = <2>;
> > > +        #interrupt-cells = <2>;
> > > +
> > > +        display-controller@6,1 {
> > > +            compatible = "loongson,ls7a1000-dc";
> > > +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> > > +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> > > +
> > > +            #address-cells = <1>;
> > > +            #size-cells = <0>;
> > > +
> > > +            i2c-gpio@0 {
> > > +                compatible = "lsdc,i2c-gpio-0";
> > > +                reg = <6>;

'reg' needs to be documented with some description of what 6 and 7 
represent. If they are the control register offset, then make the 
address translatable (use 'ranges' and define the size).

> > > +                sda = <0>;
> > > +                scl = <1>;

These need a vendor prefix.

> > > +            };
> > > +
> > > +            i2c-gpio@1 {
> > > +                compatible = "lsdc,i2c-gpio-1";
> > > +                reg = <7>;
> > > +                sda = <2>;
> > > +                scl = <3>;
> > > +            };
> > > +
> > > +            ports {
> > > +                #address-cells = <1>;
> > > +                #size-cells = <0>;
> > > +                port@0 {
> > > +                    reg = <0>;
> > > +                    endpoint {
> > > +                            remote-endpoint = <&vga_encoder_in>;
> > > +                    };
> > > +                };
> > > +                port@1 {
> > > +                    reg = <1>;
> > > +                    endpoint {
> > > +                            remote-endpoint = <&dvi_encoder_in>;
> > > +                    };
> > > +                };
> > > +            };
> > > +        };
> > > +    };
> > > +
> > > +  - |
> > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > +    bus {
> > > +
> > > +        #address-cells = <3>;
> > > +        #size-cells = <2>;
> > > +        #interrupt-cells = <2>;
> > > +
> > > +        display-controller@6,0 {
> > > +            compatible = "loongson,ls2k1000-dc";
> > > +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> > > +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> > > +
> > > +            ports {
> > > +                #address-cells = <1>;
> > > +                #size-cells = <0>;
> > > +                port@0 {
> > > +                    reg = <0>;
> > > +                    endpoint {
> > > +                            remote-endpoint = <&panel_in>;
> > > +                    };
> > > +                };
> > > +                port@1 {
> > > +                    reg = <1>;
> > > +                    endpoint {
> > > +                            remote-endpoint = <&hdmi_encoder_in>;
> > > +                    };
> > > +                };
> > > +            };
> > > +        };
> > > +    };
> > > +...
> > > -- 
> > > 2.25.1
> > > 
> > > 

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Sui Jingfeng]

On 2022/3/23 00:06, Jiaxun Yang wrote:
>
>
> 在 2022/3/22 13:38, Sui Jingfeng 写道:
>>
>> On 2022/3/22 21:05, Jiaxun Yang wrote:
>>>
>>>
>>> 在 2022/3/21 16:29, Sui Jingfeng 写道:
>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>
>>>> The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
>>>> mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe GEN2 x8 
>>>> slot,
>>>> therefore can play with discrete graphics card.
>>>
>>> Hi Jingfeng,
>>>
>>> As we've discussed before if you are going to introduce new dts then 
>>> you *MUST*
>>> include it in makefile and wire it up in code.
>>>
>>> A dts file doing nothing lying in the tree is just suspicious.
>>>
>>> Thanks.
>>> - Jiaxun
>>>
>> Hi, Jiaxun,
>>
>> I know what you means, but it is the kernel side developer's job.
>> I am just a naive graphic driver developer,I can not care so much.
>> Below is my private patch which can be used to built specific dts
>> into the linux kernel, therefore make the verification easier.
> Hi Jingfeng,
>
> In kernel world we take care all the stuff we touched ourself :-)
>
> If you are not confident with them please drop those DTS from the 
> patchset
> besides the generic one. I can do the rest for you after getting this 
> set merged.
>
> Thanks.
> - Jiaxun
>
Hi, Jiaxun

Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
How does the kernel get the dtb is another big issue, either from built-in
dtb or pass from the firmware(pmon and uefi etc). This should be
solved with another patch carefully. Providing board specific dts
helps to code review, it helps reviewers understand that there are
variant boards and have to be express with different OF graph.

Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
Suppose loongson have 1000+ different board, do you want built all
of them into vmlinuz?

Besides, ls7a1000 and ls2k1000 lack a i2c driver, gpio driver,
pwm driver, clk driver, can you pay more attention to salve those
problems, please ?

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Jiaxun Yang]

在 2022/3/23 1:53, Sui Jingfeng 写道:
> Hi, Jiaxun
>
> Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
> How does the kernel get the dtb is another big issue, either from 
> built-in
> dtb or pass from the firmware(pmon and uefi etc). This should be
> solved with another patch carefully. Providing board specific dts
> helps to code review, it helps reviewers understand that there are
> variant boards and have to be express with different OF graph.
Hi,

I insist my taste on those code. If the only intention is to demonstrate
the usage of the driver then please just leave them in dt document
or commit message.

>
> Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
> Suppose loongson have 1000+ different board, do you want built all
> of them into vmlinuz?
Note that we are supporting all those boards on "platform" bias. Which
means if they share similar design then they will use the same DTS.
If we have a new design then unfortunately our kernel binary must grow.

For those who intended to build a size-optimized kernel they will be
able to disable unused DTS in Kconfig.

If you want to blame somebody for the problem then please don't
blame us. We tried very hard to fit all those stuff into kernel's model
of devices. You should blame those who did the initial design of
Loongson's boot interface that failed to introduce a proper way
to describe the platform.

>
> Besides, ls7a1000 and ls2k1000 lack a i2c driver, gpio driver,
> pwm driver, clk driver, can you pay more attention to salve those
> problems, please ?
Are you trying to make a TODO list for your colleague :-)

We , community developers, don't owe you anything. So please
don't expect anything from us. I lost access to most Loongson
devices since I'm currently study abroad, but I'm determined to
keep platform code in a good shape. That's my duty as a maintainer.

Thanks.
- Jiaxun

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Sui Jingfeng]

On 2022/3/23 10:29, Jiaxun Yang wrote:
>
>
> 在 2022/3/23 1:53, Sui Jingfeng 写道:
>> Hi, Jiaxun
>>
>> Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
>> How does the kernel get the dtb is another big issue, either from 
>> built-in
>> dtb or pass from the firmware(pmon and uefi etc). This should be
>> solved with another patch carefully. Providing board specific dts
>> helps to code review, it helps reviewers understand that there are
>> variant boards and have to be express with different OF graph.
> Hi,
>
> I insist my taste on those code. If the only intention is to demonstrate
> the usage of the driver then please just leave them in dt document
> or commit message.
>
>>
>> Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
>> Suppose loongson have 1000+ different board, do you want built all
>> of them into vmlinuz?
> Note that we are supporting all those boards on "platform" bias. Which
> means if they share similar design then they will use the same DTS.
> If we have a new design then unfortunately our kernel binary must grow.
>
> For those who intended to build a size-optimized kernel they will be
> able to disable unused DTS in Kconfig.
>
> If you want to blame somebody for the problem then please don't
> blame us. We tried very hard to fit all those stuff into kernel's model
> of devices. You should blame those who did the initial design of
> Loongson's boot interface that failed to introduce a proper way
> to describe the platform.
>
>>
>> Besides, ls7a1000 and ls2k1000 lack a i2c driver, gpio driver,
>> pwm driver, clk driver, can you pay more attention to salve those
>> problems, please ?
> Are you trying to make a TODO list for your colleague :-)
>
> We , community developers, don't owe you anything. So please
> don't expect anything from us. I lost access to most Loongson
> devices since I'm currently study abroad, but I'm determined to
> keep platform code in a good shape. That's my duty as a maintainer.
>
> Thanks.
> - Jiaxun

Providing a few board specific dts doesn't hurt anybody.

Can we leave the problem(passing correct dts to the kernel) untouched and

solve it in the feature with a another patch, ok?

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Jiaxun Yang]

在2022年3月23日三月 上午3:07，Sui Jingfeng写道：
> On 2022/3/23 10:29, Jiaxun Yang wrote:
>>
>>
>> 在 2022/3/23 1:53, Sui Jingfeng 写道:
>>> Hi, Jiaxun
>>>
>>> Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
>>> How does the kernel get the dtb is another big issue, either from 
>>> built-in
>>> dtb or pass from the firmware(pmon and uefi etc). This should be
>>> solved with another patch carefully. Providing board specific dts
>>> helps to code review, it helps reviewers understand that there are
>>> variant boards and have to be express with different OF graph.
>> Hi,
>>
>> I insist my taste on those code. If the only intention is to demonstrate
>> the usage of the driver then please just leave them in dt document
>> or commit message.
>>
>>>
>>> Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
>>> Suppose loongson have 1000+ different board, do you want built all
>>> of them into vmlinuz?
>> Note that we are supporting all those boards on "platform" bias. Which
>> means if they share similar design then they will use the same DTS.
>> If we have a new design then unfortunately our kernel binary must grow.
>>
>> For those who intended to build a size-optimized kernel they will be
>> able to disable unused DTS in Kconfig.
>>
>> If you want to blame somebody for the problem then please don't
>> blame us. We tried very hard to fit all those stuff into kernel's model
>> of devices. You should blame those who did the initial design of
>> Loongson's boot interface that failed to introduce a proper way
>> to describe the platform.
>>
>>>
>>> Besides, ls7a1000 and ls2k1000 lack a i2c driver, gpio driver,
>>> pwm driver, clk driver, can you pay more attention to salve those
>>> problems, please ?
>> Are you trying to make a TODO list for your colleague :-)
>>
>> We , community developers, don't owe you anything. So please
>> don't expect anything from us. I lost access to most Loongson
>> devices since I'm currently study abroad, but I'm determined to
>> keep platform code in a good shape. That's my duty as a maintainer.
>>
>> Thanks.
>> - Jiaxun
>
> Providing a few board specific dts doesn't hurt anybody.

There are a lot of things that don't hurt anybody but we shouldn't do.

The standard of reviewing the code is not "doesn't hurt anybody". It's "do the right thing".

Please reference:
https://www.kernel.org/doc/html/latest/process/6.Followthrough.html

>
> Can we leave the problem(passing correct dts to the kernel) untouched and
>
> solve it in the feature with a another patch, ok?

Then please drop platform DTS part.

I must NAK this part, sorry.

Thanks
-- 
- Jiaxun

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:55, Rob Herring wrote:
> On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
>> On 2022/3/22 07:20, Rob Herring wrote:
>>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>
>>> Needs a commit message.
>>>
>>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>>> Same person? Don't need both emails.
>> Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
>> to send patches to dri-devel,
>>
>> when send patches with this email, the patch will not be shown on patch
>> works.
>>
>> Emails  are either blocked or got  rejected  by loongson's mail server.  It
>> can only receive emails
>>
>> from you and other people, but not dri-devel. so have to use my personal
>> email(15330273260@189.cn) to send patches.
>>
>>>> ---
>>>>    .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
>>>>    1 file changed, 230 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>> new file mode 100644
>>>> index 000000000000..7be63346289e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>> @@ -0,0 +1,230 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
>>>> +
>>>> +maintainers:
>>>> +  - Sui Jingfeng <suijingfeng@loongson.cn>
>>>> +
>>>> +description: |+
>>>> +
>>>> +  Loongson display controllers are simple which require scanout buffers
>>>> +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
>>>> +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
>>>> +  with a dedicated video RAM which is 64MB or more, precise size can be
>>>> +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
>>>> +  chip.
>>>> +
>>>> +  LSDC has two display pipes, each way has a DVO interface which provide
>>>> +  RGB888 signals, vertical & horizontal synchronisations, data enable and
>>>> +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
>>>> +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
>>>> +
>>>> +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
>>>> +  located at the DC register space. They are used to emulate two way i2c,
>>>> +  One for DVO0, another for DVO1.
>>>> +
>>>> +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
>>>> +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
>>>> +
>>>> +  LSDC's display pipeline have several components as below description,
>>>> +
>>>> +  The display controller in LS7A1000:
>>>> +     ___________________                                     _________
>>>> +    |            -------|                                   |         |
>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>> +    |  _   _     -------|        ^             ^            |_________|
>>>> +    | | | | |    -------|        |             |
>>>> +    | |_| |_|    | i2c0 <--------+-------------+
>>>> +    |            -------|
>>>> +    |   DC IN LS7A1000  |
>>>> +    |  _   _     -------|
>>>> +    | | | | |    | i2c1 <--------+-------------+
>>>> +    | |_| |_|    -------|        |             |             _________
>>>> +    |            -------|        |             |            |         |
>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>> +    |            -------|                                   |_________|
>>>> +    |___________________|
>>>> +
>>>> +  Simple usage of LS7A1000 with LS3A4000 CPU:
>>>> +
>>>> +    +------+            +-----------------------------------+
>>>> +    | DDR4 |            |  +-------------------+            |
>>>> +    +------+            |  | PCIe Root complex |   LS7A1000 |
>>>> +       || MC0           |  +--++---------++----+            |
>>>> +  +----------+  HT 3.0  |     ||         ||                 |
>>>> +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>>> +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>>> +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>>> +       || MC1           +---------------|--|----------------+
>>>> +    +------+                            |  |
>>>> +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>>> +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>>> +                      +-------+                      +------+
>>>> +
>>>> +  The display controller in LS2K1000/LS2K0500:
>>>> +     ___________________                                     _________
>>>> +    |            -------|                                   |         |
>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>> +    |  _   _     -------|        ^              ^           |_________|
>>>> +    | | | | |           |        |              |
>>>> +    | |_| |_|           |     +------+          |
>>>> +    |                   <---->| i2c0 |<---------+
>>>> +    |   DC IN LS2K1000  |     +------+
>>>> +    |  _   _            |     +------+
>>>> +    | | | | |           <---->| i2c1 |----------+
>>>> +    | |_| |_|           |     +------+          |            _________
>>>> +    |            -------|        |              |           |         |
>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>> +    |            -------|                                   |_________|
>>>> +    |___________________|
>>>> +
>>>> +properties:
>>>> +  $nodename:
>>>> +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
>>>> +
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - items:
>>>> +          - enum:
>>>> +              - loongson,ls7a1000-dc
>>>> +              - loongson,ls2k1000-dc
>>>> +              - loongson,ls2k0500-dc
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  interrupts:
>>>> +    maxItems: 1
>>>> +
>>>> +  '#address-cells':
>>>> +    const: 1
>>>> +
>>>> +  '#size-cells':
>>>> +    const: 0
>>>> +
>>>> +  i2c-gpio@0:
>>>> +    description: |
>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>> If you have i2c-gpio, that belongs at the DT top-level, not here.
>>>
>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>> +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
>>> No, there's a defined i2c-gpio compatible already.
>> This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
>> By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
>> adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
>> LSDC register space, not general purpose GPIOs with separate control register resource.
>> So i think it is the child node of display-controller@6,1, it belongs to LSDC.
>> It seems that put it at the DT top-level break the hierarchy and relationship.
> Okay, I see. Then just 'i2c' for the node names. You need a reference to
> i2c-controller.yaml for these nodes too.
>
> The compatible should not have an index in it.
OK, i will fix this at the next version. thanks.
>>>> +      used to specify a I2c adapter bus number, if you don't specify one
>>>> +      i2c driver core will dynamically assign a bus number. Please specify
>>> Bus numbers are a linux detail not relevant to DT binding.
>>>
>>>> +      it only when its bus number matters. Bus number greater than 6 is safe
>>>> +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
>>>> +
>>>> +  i2c-gpio@1:
>>>> +    description: |
>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>> +      only. Its compatible must be lsdc,i2c-gpio-1.
>>>> +
>>>> +  ports:
>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> +    properties:
>>>> +      port@0:
>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>> +
>>>> +      port@1:
>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>> +
>>>> +    required:
>>>> +      - port@0
>>>> +      - port@1
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +  - interrupts
>>>> +  - ports
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>> +    bus {
>>>> +
>>>> +        #address-cells = <3>;
>>>> +        #size-cells = <2>;
>>>> +        #interrupt-cells = <2>;
>>>> +
>>>> +        display-controller@6,1 {
>>>> +            compatible = "loongson,ls7a1000-dc";
>>>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>>>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>>>> +
>>>> +            #address-cells = <1>;
>>>> +            #size-cells = <0>;
>>>> +
>>>> +            i2c-gpio@0 {
>>>> +                compatible = "lsdc,i2c-gpio-0";
>>>> +                reg = <6>;
> 'reg' needs to be documented with some description of what 6 and 7
> represent. If they are the control register offset, then make the
> address translatable (use 'ranges' and define the size).

By design, the reg property is used to specify a I2c adapter bus number,
if we don't specify one, i2c driver core will dynamically assign a bus number.
then the nr of the i2c adapter will started from 0. I want is start from 6
to avoid potential conflict feature hardware I2C driver.

Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
but its driver is not up-streamed yet. By default these hardware I2C controller's
nr is started from 0.

Even through i2c driver core can dynamically generate a number, i still want it
to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
i2c7 is for display pipe 1. This follow the convention and flexible enough.

>>>> +                sda = <0>;
>>>> +                scl = <1>;
> These need a vendor prefix.
OK, i will fix this at the next version, thanks
>>>> +            };
>>>> +
>>>> +            i2c-gpio@1 {
>>>> +                compatible = "lsdc,i2c-gpio-1";
>>>> +                reg = <7>;
>>>> +                sda = <2>;
>>>> +                scl = <3>;
>>>> +            };
>>>> +
>>>> +            ports {
>>>> +                #address-cells = <1>;
>>>> +                #size-cells = <0>;
>>>> +                port@0 {
>>>> +                    reg = <0>;
>>>> +                    endpoint {
>>>> +                            remote-endpoint = <&vga_encoder_in>;
>>>> +                    };
>>>> +                };
>>>> +                port@1 {
>>>> +                    reg = <1>;
>>>> +                    endpoint {
>>>> +                            remote-endpoint = <&dvi_encoder_in>;
>>>> +                    };
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +
>>>> +  - |
>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>> +    bus {
>>>> +
>>>> +        #address-cells = <3>;
>>>> +        #size-cells = <2>;
>>>> +        #interrupt-cells = <2>;
>>>> +
>>>> +        display-controller@6,0 {
>>>> +            compatible = "loongson,ls2k1000-dc";
>>>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>>>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>>>> +
>>>> +            ports {
>>>> +                #address-cells = <1>;
>>>> +                #size-cells = <0>;
>>>> +                port@0 {
>>>> +                    reg = <0>;
>>>> +                    endpoint {
>>>> +                            remote-endpoint = <&panel_in>;
>>>> +                    };
>>>> +                };
>>>> +                port@1 {
>>>> +                    reg = <1>;
>>>> +                    endpoint {
>>>> +                            remote-endpoint = <&hdmi_encoder_in>;
>>>> +                    };
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +...
>>>> -- 
>>>> 2.25.1
>>>>
>>>>

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
>> +/*
>> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
>> + *
>> + * @index : output channel index, 0 for DVO0, 1 for DVO1
>> + */
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
>> +{
>> +	char compat[32] = {0};
>> +	unsigned int udelay = 5;
>> +	unsigned int timeout = 2200;
>> +	int nr = -1;
>> +	struct i2c_adapter *adapter;
>> +	struct lsdc_i2c *li2c;
>> +	struct device_node *i2c_np;
>> +	int ret;
>> +
>> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
>> +	if (!li2c)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	li2c->index = index;
>> +	li2c->dev = dev;
>> +
>> +	if (index == 0) {
>> +		li2c->sda = 0x01;
>> +		li2c->scl = 0x02;
>> +	} else if (index == 1) {
>> +		li2c->sda = 0x04;
>> +		li2c->scl = 0x08;
> Just require this to be in DT rather than having some default.
>
By design,  I am try very hard to let the code NOT fully  DT dependent. DT is nice , easy to learn and use.
But kernel side developer plan to follow UEFI + ACPI Specification on LS3A5000 + LS7A1000 platform. See [1]
There will no DT support then, provide a convention support  make the driver more flexible. I want the
driver works with minimal requirement. The driver just works on simple boards by put the following dc device
node in arch/mips/dts/loongson/loongson64g_4core_ls7a.dts,

             lsdc: display-controller@6,1 {
                 compatible = "loongson,ls7a1000-dc";

                 reg = <0x3100 0x0 0x0 0x0 0x0>;
                 interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
                 interrupt-parent = <&pic>;
             };

[1] 
https://lwn.net/Articles/869541/#:~:text=LoongArch%20is%20a%20new%20RISC%20ISA%2C%20which%20is,revision%20of%20ACPI%20Specification%20%28current%20revision%20is%206.4%29.

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
> This condition is never true. We're in the 'else' because !state.

Thanks for your sharp eyes,  after the gpio emulate i2c driver works, i do not pay much
attention to it and get hurry to do other things. I will fix this issue at next version
and reply other problem at a letter time.

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Sui Jingfeng]

On 2022/3/23 10:29, Jiaxun Yang wrote:
> If you want to blame somebody for the problem then please don't
> blame us. We tried very hard to fit all those stuff into kernel's model
> of devices. You should blame those who did the initial design of
> Loongson's boot interface that failed to introduce a proper way
> to describe the platform. 

I am not blame anybody, please do not misleading.
I am report problem and try to seek a better solution.

I have my intention and ideas, i just don't want to solve
all of the problems in one shot.

I could provide one more patch wire all board specific dts up.
But i don't know what's the opinions of other reviewers, does
this is plausible?

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
>> +/*
>> + * ls7a_gpio_i2c_set - set the state of a gpio pin indicated by mask
>> + * @mask: gpio pin mask
>> + */
>> +static void ls7a_gpio_i2c_set(struct lsdc_i2c * const li2c, int mask, int state)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
> What are you protecting? Doesn't the caller serialize calls to these
> functions?
>
This driver is ported from my work from my downstream work.

Maxime also ask this question before, but i did not answer.
He is right, protect single register access is not necessary.
uncached access have done the job itself.
so i remove it in V11 of my patch set.

There are two way GPIO emulated i2c, I want the code between
spin_lock_irqsave(&li2c->reglock, flags) and spin_unlock_irqrestore(&li2c->reglock, flags);
finished in a atomic way, without any disruption.

The two i2c should not have any influence each other.
I write it by gut feeling, and luckily it works very well in practice.

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
>> +
>> +	if (state) {
>> +		val = readb(li2c->dir_reg);
>> +		val |= mask;
>> +		writeb(val, li2c->dir_reg);
>> +	} else {
>> +		val = readb(li2c->dir_reg);
>> +		val &= ~mask;
>> +		writeb(val, li2c->dir_reg);
>> +
>> +		val = readb(li2c->dat_reg);
>> +		if (state)
> This condition is never true. We're in the 'else' because !state.
>
>> +			val |= mask;
>> +		else
>> +			val &= ~mask;
>> +		writeb(val, li2c->dat_reg);
> Shouldn't you set the data register low first and then change the
> direction? Otherwise, you may be driving high for a moment. However, if
> high is always done by setting the direction as input, why write the
> data register each time? I'm assuming whatever is written to the dat_reg
> is maintained regardless of pin state.

To be honest, i have rewrite GPIO emulated i2c several times.
Either give data first, then give the direction
or give the direction first, then the data
will be OK in practice.

In the theory, the GPIO data should be given before the GPIO direction,
I was told doing that way when learning Single-Chip Microcomputer (AT89S52).

But the high "MUST" be done by setting the direction as input.
It is "MUST" not "CAN" because writing code as the following
way works in practice.

         if (state) {
                 val = readb(li2c->dir_reg);
                 val |= mask;
                 writeb(val, li2c->dir_reg);
         } else {
                // ...
         }

If the adjust the above code by first set the detection as output,
then set the GPIO data register with high voltage level("1"). as
the following demonstrate code,

         if (state) {
		/* First set this pin as output */
		val = readb(li2c->dir_reg);
		val |= mask;
		writeb(val, li2c->dir_reg);

		/* Then, set the state to high */
		val = readb(li2c->dat_reg);
		val |= mask;
		writeb(val, li2c->dat_reg);
         } else {
                // ...
         }

Then i2c6 will NOT work as exacted, i2c7 will work, so strangely.
It may because the GPIO is open drained, not Push-pull output.
Output high is achieved by externalpull up resistance on the PCB.

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Jiaxun Yang]

在2022年3月23日三月 上午7:07，Sui Jingfeng写道：
> On 2022/3/23 10:29, Jiaxun Yang wrote:
>> If you want to blame somebody for the problem then please don't
>> blame us. We tried very hard to fit all those stuff into kernel's model
>> of devices. You should blame those who did the initial design of
>> Loongson's boot interface that failed to introduce a proper way
>> to describe the platform. 
>
> I am not blame anybody, please do not misleading.
Your language seems to be aggressive from my point of view.

> I am report problem and try to seek a better solution.
>
> I have my intention and ideas, i just don't want to solve
> all of the problems in one shot.
If so please just drop this part from the patch. I've repeated several times.

>
> I could provide one more patch wire all board specific dts up.
> But i don't know what's the opinions of other reviewers, does
> this is plausible?
Please carefully read section 6.1 about how should you work with reviewers.
https://www.kernel.org/doc/html/latest/process/6.Followthrough.html

Thanks.
-- 
- Jiaxun

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Rob Herring]

On Wed, Mar 23, 2022 at 09:53:14AM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/23 00:06, Jiaxun Yang wrote:
> > 
> > 
> > 在 2022/3/22 13:38, Sui Jingfeng 写道:
> > > 
> > > On 2022/3/22 21:05, Jiaxun Yang wrote:
> > > > 
> > > > 
> > > > 在 2022/3/21 16:29, Sui Jingfeng 写道:
> > > > > From: suijingfeng <suijingfeng@loongson.cn>
> > > > > 
> > > > > The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
> > > > > mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe
> > > > > GEN2 x8 slot,
> > > > > therefore can play with discrete graphics card.
> > > > 
> > > > Hi Jingfeng,
> > > > 
> > > > As we've discussed before if you are going to introduce new dts
> > > > then you *MUST*
> > > > include it in makefile and wire it up in code.
> > > > 
> > > > A dts file doing nothing lying in the tree is just suspicious.
> > > > 
> > > > Thanks.
> > > > - Jiaxun
> > > > 
> > > Hi, Jiaxun,
> > > 
> > > I know what you means, but it is the kernel side developer's job.
> > > I am just a naive graphic driver developer,I can not care so much.
> > > Below is my private patch which can be used to built specific dts
> > > into the linux kernel, therefore make the verification easier.
> > Hi Jingfeng,
> > 
> > In kernel world we take care all the stuff we touched ourself :-)
> > 
> > If you are not confident with them please drop those DTS from the
> > patchset
> > besides the generic one. I can do the rest for you after getting this
> > set merged.
> > 
> > Thanks.
> > - Jiaxun
> > 
> Hi, Jiaxun
> 
> Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
> How does the kernel get the dtb is another big issue, either from built-in
> dtb or pass from the firmware(pmon and uefi etc). This should be
> solved with another patch carefully. Providing board specific dts
> helps to code review, it helps reviewers understand that there are
> variant boards and have to be express with different OF graph.

Built-in DTBs are for legacy bootloaders that don't understand DT. I 
would not expect a new platform to need this.

> 
> Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
> Suppose loongson have 1000+ different board, do you want built all
> of them into vmlinuz?

The point was to add the .dts to Makefile so it builds, not so it is 
built-in. How are you testing those build with dtc and dtschema if not 
added to kbuild?

Rob

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/23 04:55, Rob Herring wrote:
> > On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
> > > On 2022/3/22 07:20, Rob Herring wrote:
> > > > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > > > From: suijingfeng <suijingfeng@loongson.cn>
> > > > > 
> > > > Needs a commit message.
> > > > 
> > > > > Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> > > > > Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> > > > Same person? Don't need both emails.
> > > Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
> > > to send patches to dri-devel,
> > > 
> > > when send patches with this email, the patch will not be shown on patch
> > > works.
> > > 
> > > Emails  are either blocked or got  rejected  by loongson's mail server.  It
> > > can only receive emails
> > > 
> > > from you and other people, but not dri-devel. so have to use my personal
> > > email(15330273260@189.cn) to send patches.
> > > 
> > > > > ---
> > > > >    .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
> > > > >    1 file changed, 230 insertions(+)
> > > > >    create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..7be63346289e
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > @@ -0,0 +1,230 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
> > > > > +
> > > > > +maintainers:
> > > > > +  - Sui Jingfeng <suijingfeng@loongson.cn>
> > > > > +
> > > > > +description: |+
> > > > > +
> > > > > +  Loongson display controllers are simple which require scanout buffers
> > > > > +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
> > > > > +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
> > > > > +  with a dedicated video RAM which is 64MB or more, precise size can be
> > > > > +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
> > > > > +  chip.
> > > > > +
> > > > > +  LSDC has two display pipes, each way has a DVO interface which provide
> > > > > +  RGB888 signals, vertical & horizontal synchronisations, data enable and
> > > > > +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
> > > > > +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
> > > > > +
> > > > > +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
> > > > > +  located at the DC register space. They are used to emulate two way i2c,
> > > > > +  One for DVO0, another for DVO1.
> > > > > +
> > > > > +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
> > > > > +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
> > > > > +
> > > > > +  LSDC's display pipeline have several components as below description,
> > > > > +
> > > > > +  The display controller in LS7A1000:
> > > > > +     ___________________                                     _________
> > > > > +    |            -------|                                   |         |
> > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > +    |  _   _     -------|        ^             ^            |_________|
> > > > > +    | | | | |    -------|        |             |
> > > > > +    | |_| |_|    | i2c0 <--------+-------------+
> > > > > +    |            -------|
> > > > > +    |   DC IN LS7A1000  |
> > > > > +    |  _   _     -------|
> > > > > +    | | | | |    | i2c1 <--------+-------------+
> > > > > +    | |_| |_|    -------|        |             |             _________
> > > > > +    |            -------|        |             |            |         |
> > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > +    |            -------|                                   |_________|
> > > > > +    |___________________|
> > > > > +
> > > > > +  Simple usage of LS7A1000 with LS3A4000 CPU:
> > > > > +
> > > > > +    +------+            +-----------------------------------+
> > > > > +    | DDR4 |            |  +-------------------+            |
> > > > > +    +------+            |  | PCIe Root complex |   LS7A1000 |
> > > > > +       || MC0           |  +--++---------++----+            |
> > > > > +  +----------+  HT 3.0  |     ||         ||                 |
> > > > > +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
> > > > > +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
> > > > > +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
> > > > > +       || MC1           +---------------|--|----------------+
> > > > > +    +------+                            |  |
> > > > > +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
> > > > > +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
> > > > > +                      +-------+                      +------+
> > > > > +
> > > > > +  The display controller in LS2K1000/LS2K0500:
> > > > > +     ___________________                                     _________
> > > > > +    |            -------|                                   |         |
> > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > +    |  _   _     -------|        ^              ^           |_________|
> > > > > +    | | | | |           |        |              |
> > > > > +    | |_| |_|           |     +------+          |
> > > > > +    |                   <---->| i2c0 |<---------+
> > > > > +    |   DC IN LS2K1000  |     +------+
> > > > > +    |  _   _            |     +------+
> > > > > +    | | | | |           <---->| i2c1 |----------+
> > > > > +    | |_| |_|           |     +------+          |            _________
> > > > > +    |            -------|        |              |           |         |
> > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > +    |            -------|                                   |_________|
> > > > > +    |___________________|
> > > > > +
> > > > > +properties:
> > > > > +  $nodename:
> > > > > +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
> > > > > +
> > > > > +  compatible:
> > > > > +    oneOf:
> > > > > +      - items:
> > > > > +          - enum:
> > > > > +              - loongson,ls7a1000-dc
> > > > > +              - loongson,ls2k1000-dc
> > > > > +              - loongson,ls2k0500-dc
> > > > > +
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  interrupts:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  '#address-cells':
> > > > > +    const: 1
> > > > > +
> > > > > +  '#size-cells':
> > > > > +    const: 0
> > > > > +
> > > > > +  i2c-gpio@0:
> > > > > +    description: |
> > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > If you have i2c-gpio, that belongs at the DT top-level, not here.
> > > > 
> > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
> > > > No, there's a defined i2c-gpio compatible already.
> > > This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
> > > By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
> > > adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
> > > LSDC register space, not general purpose GPIOs with separate control register resource.
> > > So i think it is the child node of display-controller@6,1, it belongs to LSDC.
> > > It seems that put it at the DT top-level break the hierarchy and relationship.
> > Okay, I see. Then just 'i2c' for the node names. You need a reference to
> > i2c-controller.yaml for these nodes too.
> > 
> > The compatible should not have an index in it.
> OK, i will fix this at the next version. thanks.
> > > > > +      used to specify a I2c adapter bus number, if you don't specify one
> > > > > +      i2c driver core will dynamically assign a bus number. Please specify
> > > > Bus numbers are a linux detail not relevant to DT binding.
> > > > 
> > > > > +      it only when its bus number matters. Bus number greater than 6 is safe
> > > > > +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
> > > > > +
> > > > > +  i2c-gpio@1:
> > > > > +    description: |
> > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > +      only. Its compatible must be lsdc,i2c-gpio-1.
> > > > > +
> > > > > +  ports:
> > > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > > +
> > > > > +    properties:
> > > > > +      port@0:
> > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > +
> > > > > +      port@1:
> > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > +
> > > > > +    required:
> > > > > +      - port@0
> > > > > +      - port@1
> > > > > +
> > > > > +required:
> > > > > +  - compatible
> > > > > +  - reg
> > > > > +  - interrupts
> > > > > +  - ports
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > +  - |
> > > > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > > > +    bus {
> > > > > +
> > > > > +        #address-cells = <3>;
> > > > > +        #size-cells = <2>;
> > > > > +        #interrupt-cells = <2>;
> > > > > +
> > > > > +        display-controller@6,1 {
> > > > > +            compatible = "loongson,ls7a1000-dc";
> > > > > +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> > > > > +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> > > > > +
> > > > > +            #address-cells = <1>;
> > > > > +            #size-cells = <0>;
> > > > > +
> > > > > +            i2c-gpio@0 {
> > > > > +                compatible = "lsdc,i2c-gpio-0";
> > > > > +                reg = <6>;
> > 'reg' needs to be documented with some description of what 6 and 7
> > represent. If they are the control register offset, then make the
> > address translatable (use 'ranges' and define the size).
> 
> By design, the reg property is used to specify a I2c adapter bus number,
> if we don't specify one, i2c driver core will dynamically assign a bus number.
> then the nr of the i2c adapter will started from 0. I want is start from 6
> to avoid potential conflict feature hardware I2C driver.
> 
> Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
> but its driver is not up-streamed yet. By default these hardware I2C controller's
> nr is started from 0.

Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in 
that way.

> Even through i2c driver core can dynamically generate a number, i still want it
> to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
> i2c7 is for display pipe 1. This follow the convention and flexible enough.

You may want that, but that is not how the kernel works. Specific 
numbers are not guaranteed. I'm sure you've seen this for disks, network 
interfaces, etc.

Rob

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Rob Herring]

On Wed, Mar 23, 2022 at 12:12:43PM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/23 04:49, Rob Herring wrote:
> > > +/*
> > > + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
> > > + *
> > > + * @index : output channel index, 0 for DVO0, 1 for DVO1
> > > + */
> > > +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
> > > +{
> > > +	char compat[32] = {0};
> > > +	unsigned int udelay = 5;
> > > +	unsigned int timeout = 2200;
> > > +	int nr = -1;
> > > +	struct i2c_adapter *adapter;
> > > +	struct lsdc_i2c *li2c;
> > > +	struct device_node *i2c_np;
> > > +	int ret;
> > > +
> > > +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
> > > +	if (!li2c)
> > > +		return ERR_PTR(-ENOMEM);
> > > +
> > > +	li2c->index = index;
> > > +	li2c->dev = dev;
> > > +
> > > +	if (index == 0) {
> > > +		li2c->sda = 0x01;
> > > +		li2c->scl = 0x02;
> > > +	} else if (index == 1) {
> > > +		li2c->sda = 0x04;
> > > +		li2c->scl = 0x08;
> > Just require this to be in DT rather than having some default.
> > 
> By design,  I am try very hard to let the code NOT fully  DT dependent. DT is nice , easy to learn and use.
> But kernel side developer plan to follow UEFI + ACPI Specification on LS3A5000 + LS7A1000 platform. See [1]
> There will no DT support then, provide a convention support  make the driver more flexible. I want the
> driver works with minimal requirement. The driver just works on simple boards by put the following dc device
> node in arch/mips/dts/loongson/loongson64g_4core_ls7a.dts,

Pick DT or ACPI for the platform, not both. We don't need to have both 
in the kernel to support.

Rob

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
> On Tue, Mar 22, 2022 at 12:29:16AM +0800, Sui Jingfeng wrote:
>> From: suijingfeng <suijingfeng@loongson.cn>
>>
>> There is a display controller in loongson's LS2K1000 SoC and LS7A1000
>> bridge chip, the display controller is a PCI device in those chips. It
>> has two display pipes but with only one hardware cursor. Each way has
>> a DVO interface which provide RGB888 signals, vertical & horizontal
>> synchronisations, data enable and the pixel clock. Each CRTC is able to
>> scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
>> 2048x2048 according to the hardware spec. Loongson display controllers
>> are simple which require scanout buffers to be physically contiguous.
>>
>> For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
>> which is typically 64MB or more. In this case, VRAM helper based driver
>> is intend to be used. While LS2K1000 is a SoC, only system memory is
>> available. Therefore CMA helper based driver is intend to be used. It is
>> possible to use VRAM helper based solution by carving out part of system
>> memory as VRAM though.
>>
>> For LS7A1000, there are 4 dedicated GPIOs whose control register is
>> located at the DC register space, They are used to emulate two way i2c.
>> One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
>> GPIO hardwared, they grab i2c adapter from other module, either general
>> purpose GPIO emulated i2c or hardware i2c adapter.
>>
>>      +------+            +-----------------------------------+
>>      | DDR4 |            |  +-------------------+            |
>>      +------+            |  | PCIe Root complex |   LS7A1000 |
>>         || MC0           |  +--++---------++----+            |
>>    +----------+  HT 3.0  |     ||         ||                 |
>>    | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>    |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>    +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>         || MC1           +---------------|--|----------------+
>>      +------+                            |  |
>>      | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>      +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>                        +-------+                      +------+
>>
>> The above picture give a simple usage of LS7A1000, note that the encoder
>> is not necessary adv7125 or tfp410, other candicates can be ch7034b,
>> sil9022, ite66121 and lt8618 etc.
>>
>> v2: Fixup warnings reported by kernel test robot
>>
>> v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
>>      more details about lsdc.
>>
>> v4:
>>     1) Add dts required and explain why device tree is required.
>>     2) Give more description about lsdc and VRAM helper based driver.
>>     3) Fix warnings reported by kernel test robot.
>>     4) Introduce stride_alignment member into struct lsdc_chip_desc, the
>>        stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.
>>
>> v5:
>>     1) Using writel and readl replace writeq and readq, to fix kernel test
>>        robot report build error on other archtecture.
>>     2) Set default fb format to XRGB8888 at crtc reset time.
>>
>> v6:
>>     1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
>>     2) Explain why tiny drm driver is not suitable for us.
>>     3) Give a short description of the trival dirty uppdate implement based
>>        on CMA helper.
>>
>> v7:
>>     1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
>>     2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
>>     3) Remove lsdc_pixpll_print(), part of it move to debugfs.
>>     4) Set prefer_shadow to true if vram based driver is in using.
>>     5) Replace double blank lines with single line in all files.
>>     6) Verbose cmd line parameter is replaced with drm_dbg()
>>     7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
>>     8) Get edid from dtb support is removed as suggested by Maxime Ripard
>>     9) Fix typos and various improvement
>>
>> v8:
>>     1) Drop damage update implement and its command line.
>>     2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
>>     3) Deduce DC's identification from its compatible property.
>>     4) Drop the board specific dts patch.
>>     5) Add documention about the display controller device node.
>>
>> v9:
>>     1) Fix the warnings reported by checkpatch script and fix typos
>>
>> v10:
>>     1) Pass `make dt_binding_check` validation
>>     2) Fix warnings reported by kernel test robot
>>
>> v11:
>>     1) Convert the driver to use drm bridge and of graph framework.
>>     2) Dump register value support through debugfs.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> ---
>>   drivers/gpu/drm/Kconfig             |   2 +
>>   drivers/gpu/drm/Makefile            |   1 +
>>   drivers/gpu/drm/lsdc/Kconfig        |  23 ++
>>   drivers/gpu/drm/lsdc/Makefile       |  13 +
>>   drivers/gpu/drm/lsdc/lsdc_crtc.c    | 396 +++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_drv.c     | 547 ++++++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_drv.h     | 197 ++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_i2c.c     | 235 ++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_i2c.h     |  42 ++
>>   drivers/gpu/drm/lsdc/lsdc_irq.c     |  58 +++
>>   drivers/gpu/drm/lsdc/lsdc_irq.h     |  18 +
>>   drivers/gpu/drm/lsdc/lsdc_output.c  | 262 +++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_output.h  |  24 ++
>>   drivers/gpu/drm/lsdc/lsdc_pci_drv.c | 328 ++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_plane.c   | 470 +++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_pll.c     | 574 ++++++++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_pll.h     |  88 +++++
>>   drivers/gpu/drm/lsdc/lsdc_regs.h    | 220 +++++++++++
>>   18 files changed, 3498 insertions(+)
>>   create mode 100644 drivers/gpu/drm/lsdc/Kconfig
>>   create mode 100644 drivers/gpu/drm/lsdc/Makefile
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pci_drv.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h
> [...]
>
>> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.c b/drivers/gpu/drm/lsdc/lsdc_i2c.c
>> new file mode 100644
>> index 000000000000..55beed9266fa
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.c
>> @@ -0,0 +1,235 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * KMS driver for Loongson display controller
> Not really a useful comment since every file has the same one.
>
>> + * Copyright (C) 2022 Loongson Corporation
>> + */
>> +
>> +/*
>> + * Authors:
>> + *      Sui Jingfeng <suijingfeng@loongson.cn>
>> + */
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/pci.h>
>> +
>> +#include "lsdc_drv.h"
>> +#include "lsdc_regs.h"
>> +#include "lsdc_i2c.h"
>> +
>> +/*
>> + * ls7a_gpio_i2c_set - set the state of a gpio pin indicated by mask
>> + * @mask: gpio pin mask
>> + */
>> +static void ls7a_gpio_i2c_set(struct lsdc_i2c * const li2c, int mask, int state)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
> What are you protecting? Doesn't the caller serialize calls to these
> functions?
>
>> +
>> +	if (state) {
>> +		val = readb(li2c->dir_reg);
>> +		val |= mask;
>> +		writeb(val, li2c->dir_reg);
>> +	} else {
>> +		val = readb(li2c->dir_reg);
>> +		val &= ~mask;
>> +		writeb(val, li2c->dir_reg);
>> +
>> +		val = readb(li2c->dat_reg);
>> +		if (state)
> This condition is never true. We're in the 'else' because !state.
>
>> +			val |= mask;
>> +		else
>> +			val &= ~mask;
>> +		writeb(val, li2c->dat_reg);
> Shouldn't you set the data register low first and then change the
> direction? Otherwise, you may be driving high for a moment. However, if
> high is always done by setting the direction as input, why write the
> data register each time? I'm assuming whatever is written to the dat_reg
> is maintained regardless of pin state.
>
When the pin is input, i am not sure value written to it will be preserved.

I'm worry about it get flushed by the external input value.

Because the output data register is same with the input data register( 
offset is  0x1650).

The hardware designer do not provided a  separation.

>> +	}
>> +
>> +	spin_unlock_irqrestore(&li2c->reglock, flags);
>> +}
>> +
>> +/*
>> + * ls7a_gpio_i2c_get - read value back from gpio pin
>> + * @mask: gpio pin mask
>> + */
>> +static int ls7a_gpio_i2c_get(struct lsdc_i2c * const li2c, int mask)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
>> +
>> +	/* first set this pin as input */
>> +	val = readb(li2c->dir_reg);
>> +	val |= mask;
>> +	writeb(val, li2c->dir_reg);
>> +
>> +	/* then get level state from this pin */
>> +	val = readb(li2c->dat_reg);
>> +
>> +	spin_unlock_irqrestore(&li2c->reglock, flags);
>> +
>> +	return (val & mask) ? 1 : 0;
>> +}
>> +
>> +/* set the state on the i2c->sda pin */
>> +static void ls7a_i2c_set_sda(void *i2c, int state)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_set(li2c, li2c->sda, state);
>> +}
>> +
>> +/* set the state on the i2c->scl pin */
>> +static void ls7a_i2c_set_scl(void *i2c, int state)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_set(li2c, li2c->scl, state);
>> +}
>> +
>> +/* read the value from the i2c->sda pin */
>> +static int ls7a_i2c_get_sda(void *i2c)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_get(li2c, li2c->sda);
>> +}
>> +
>> +/* read the value from the i2c->scl pin */
>> +static int ls7a_i2c_get_scl(void *i2c)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_get(li2c, li2c->scl);
>> +}
>> +
>> +/*
>> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
>> + *
>> + * @index : output channel index, 0 for DVO0, 1 for DVO1
>> + */
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
>> +{
>> +	char compat[32] = {0};
>> +	unsigned int udelay = 5;
>> +	unsigned int timeout = 2200;
>> +	int nr = -1;
>> +	struct i2c_adapter *adapter;
>> +	struct lsdc_i2c *li2c;
>> +	struct device_node *i2c_np;
>> +	int ret;
>> +
>> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
>> +	if (!li2c)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	li2c->index = index;
>> +	li2c->dev = dev;
>> +
>> +	if (index == 0) {
>> +		li2c->sda = 0x01;
>> +		li2c->scl = 0x02;
>> +	} else if (index == 1) {
>> +		li2c->sda = 0x04;
>> +		li2c->scl = 0x08;
> Just require this to be in DT rather than having some default.
>
>> +	}
>> +
>> +	spin_lock_init(&li2c->reglock);
>> +
>> +	snprintf(compat, sizeof(compat), "lsdc,i2c-gpio-%d", index);
> compatible values shouldn't have an index and you shouldn't need a
> index in DT. You need to iterate over child nodes with matching
> compatible.
>
>> +	i2c_np = of_find_compatible_node(dev->of_node, NULL, compat);
>> +	if (i2c_np) {
>> +		u32 sda, scl;
>> +
>> +		dev_dbg(dev, "Has %s property in the DT", compat);
>> +
>> +		/*  */
>> +		ret = of_property_read_u32(i2c_np, "sda", &sda);
> Custom properties need a vendor prefix.
>
>> +		if (ret == 0)
>> +			li2c->sda = 1 << sda;
>> +
>> +		ret = of_property_read_u32(i2c_np, "scl", &scl);
>> +		if (ret == 0)
>> +			li2c->scl = 1 << scl;
>> +
>> +		/* Optional properties which made the driver more flexible */
>> +		of_property_read_u32(i2c_np, "udelay", &udelay);
>> +		of_property_read_u32(i2c_np, "timeout", &timeout);
> These aren't documented. Do you really need them in DT?

Yes, in very rare case:

When debugging, sometimes one way I2C works, another way I2C not on 
specific board.

and you want to see what will happen if you change it from 5 to 2.

modify device tree is enough, have to recompile the kernel and driver 
modules every time.

It is optional through.

Please do not ask me to document such a easy thing,
DT itself is a documention, human readable,  it already speak for itself.
>> +		of_property_read_u32(i2c_np, "reg", &nr);
>> +	}
>> +
>> +	dev_dbg(dev, "%s: sda=%u, scl=%u, nr=%d, udelay=%u, timeout=%u\n",
>> +		compat, li2c->sda, li2c->scl, nr, udelay, timeout);
>> +
>> +	li2c->reg_base = base;
>> +
>> +	li2c->dir_reg = li2c->reg_base + LS7A_DC_GPIO_DIR_REG;
>> +	li2c->dat_reg = li2c->reg_base + LS7A_DC_GPIO_DAT_REG;
>> +
>> +	li2c->bit.setsda = ls7a_i2c_set_sda;
>> +	li2c->bit.setscl = ls7a_i2c_set_scl;
>> +	li2c->bit.getsda = ls7a_i2c_get_sda;
>> +	li2c->bit.getscl = ls7a_i2c_get_scl;
>> +	li2c->bit.udelay = udelay;
>> +	li2c->bit.timeout = usecs_to_jiffies(timeout);
>> +	li2c->bit.data = li2c;
>> +
>> +	adapter = &li2c->adapter;
>> +	adapter->algo_data = &li2c->bit;
>> +	adapter->owner = THIS_MODULE;
>> +	adapter->class = I2C_CLASS_DDC;
>> +	adapter->dev.parent = dev;
>> +	adapter->nr = nr;
>> +	if (i2c_np) {
>> +		adapter->dev.of_node = i2c_np;
>> +		of_node_put(i2c_np);
>> +	}
>> +
>> +	strscpy(adapter->name, &compat[5], sizeof(adapter->name));
>> +
>> +	i2c_set_adapdata(adapter, li2c);
>> +
>> +	ret = i2c_bit_add_numbered_bus(adapter);
> Why do you care what the bus number is? You shouldn't need to.
>
>> +	if (ret) {
>> +		if (i2c_np)
>> +			of_node_put(i2c_np);
>> +
>> +		devm_kfree(dev, li2c);
>> +		return ERR_PTR(ret);
>> +	}
>> +
>> +	return li2c;
>> +}
>> +
>> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c)
>> +{
>> +	struct i2c_adapter *adapter;
>> +
>> +	if (li2c) {
>> +		adapter = &li2c->adapter;
>> +
>> +		if (adapter && adapter->dev.of_node)
>> +			of_node_put(adapter->dev.of_node);
>> +
>> +		devm_kfree(ddev->dev, li2c);
>> +	}
>> +}
>> +
>> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
>> +					 unsigned int index)
>> +{
>> +	const struct lsdc_chip_desc * const descp = ldev->desc;
>> +	struct lsdc_i2c *li2c;
>> +
>> +	if (index >= descp->num_of_crtc) {
>> +		drm_err(ldev->ddev, "I2c adapter is no more than %u, %u\n",
>> +			descp->num_of_crtc, index);
>> +		return NULL;
>> +	}
>> +
>> +	li2c = ldev->li2c[index];
>> +	if (li2c)
>> +		return &li2c->adapter;
>> +
>> +	return NULL;
>> +}
>> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.h b/drivers/gpu/drm/lsdc/lsdc_i2c.h
>> new file mode 100644
>> index 000000000000..4ab825143eb4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.h
>> @@ -0,0 +1,42 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * KMS driver for Loongson display controller
>> + * Copyright (C) 2022 Loongson Corporation
>> + */
>> +
>> +/*
>> + * Authors:
>> + *      Sui Jingfeng <suijingfeng@loongson.cn>
>> + */
>> +
>> +#ifndef __LSDC_I2C__
>> +#define __LSDC_I2C__
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/i2c-algo-bit.h>
>> +#include <linux/pci.h>
>> +
>> +struct lsdc_i2c {
>> +	struct device *dev;
>> +	struct i2c_adapter adapter;
>> +	struct i2c_algo_bit_data bit;
>> +	/* @reglock: protects concurrent register access */
>> +	spinlock_t reglock;
>> +	void __iomem *reg_base;
>> +	void __iomem *dir_reg;
>> +	void __iomem *dat_reg;
>> +	int index;
>> +	/* pin bit mask */
>> +	u8 sda;
>> +	u8 scl;
>> +};
>> +
>> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c);
>> +
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev,
>> +				      void *base,
>> +				      unsigned int index);
>> +
>> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
>> +					 unsigned int index);
>> +#endif

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

On 2022/3/23 21:03, Rob Herring wrote:
> On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
>> On 2022/3/23 04:55, Rob Herring wrote:
>>> On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
>>>> On 2022/3/22 07:20, Rob Herring wrote:
>>>>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>>>
>>>>> Needs a commit message.
>>>>>
>>>>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>>>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>>>>> Same person? Don't need both emails.
>>>> Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
>>>> to send patches to dri-devel,
>>>>
>>>> when send patches with this email, the patch will not be shown on patch
>>>> works.
>>>>
>>>> Emails  are either blocked or got  rejected  by loongson's mail server.  It
>>>> can only receive emails
>>>>
>>>> from you and other people, but not dri-devel. so have to use my personal
>>>> email(15330273260@189.cn) to send patches.
>>>>
>>>>>> ---
>>>>>>     .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
>>>>>>     1 file changed, 230 insertions(+)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..7be63346289e
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>> @@ -0,0 +1,230 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Sui Jingfeng <suijingfeng@loongson.cn>
>>>>>> +
>>>>>> +description: |+
>>>>>> +
>>>>>> +  Loongson display controllers are simple which require scanout buffers
>>>>>> +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
>>>>>> +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
>>>>>> +  with a dedicated video RAM which is 64MB or more, precise size can be
>>>>>> +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
>>>>>> +  chip.
>>>>>> +
>>>>>> +  LSDC has two display pipes, each way has a DVO interface which provide
>>>>>> +  RGB888 signals, vertical & horizontal synchronisations, data enable and
>>>>>> +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
>>>>>> +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
>>>>>> +
>>>>>> +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
>>>>>> +  located at the DC register space. They are used to emulate two way i2c,
>>>>>> +  One for DVO0, another for DVO1.
>>>>>> +
>>>>>> +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
>>>>>> +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
>>>>>> +
>>>>>> +  LSDC's display pipeline have several components as below description,
>>>>>> +
>>>>>> +  The display controller in LS7A1000:
>>>>>> +     ___________________                                     _________
>>>>>> +    |            -------|                                   |         |
>>>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>>>> +    |  _   _     -------|        ^             ^            |_________|
>>>>>> +    | | | | |    -------|        |             |
>>>>>> +    | |_| |_|    | i2c0 <--------+-------------+
>>>>>> +    |            -------|
>>>>>> +    |   DC IN LS7A1000  |
>>>>>> +    |  _   _     -------|
>>>>>> +    | | | | |    | i2c1 <--------+-------------+
>>>>>> +    | |_| |_|    -------|        |             |             _________
>>>>>> +    |            -------|        |             |            |         |
>>>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>>>> +    |            -------|                                   |_________|
>>>>>> +    |___________________|
>>>>>> +
>>>>>> +  Simple usage of LS7A1000 with LS3A4000 CPU:
>>>>>> +
>>>>>> +    +------+            +-----------------------------------+
>>>>>> +    | DDR4 |            |  +-------------------+            |
>>>>>> +    +------+            |  | PCIe Root complex |   LS7A1000 |
>>>>>> +       || MC0           |  +--++---------++----+            |
>>>>>> +  +----------+  HT 3.0  |     ||         ||                 |
>>>>>> +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>>>>> +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>>>>> +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>>>>> +       || MC1           +---------------|--|----------------+
>>>>>> +    +------+                            |  |
>>>>>> +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>>>>> +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>>>>> +                      +-------+                      +------+
>>>>>> +
>>>>>> +  The display controller in LS2K1000/LS2K0500:
>>>>>> +     ___________________                                     _________
>>>>>> +    |            -------|                                   |         |
>>>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>>>> +    |  _   _     -------|        ^              ^           |_________|
>>>>>> +    | | | | |           |        |              |
>>>>>> +    | |_| |_|           |     +------+          |
>>>>>> +    |                   <---->| i2c0 |<---------+
>>>>>> +    |   DC IN LS2K1000  |     +------+
>>>>>> +    |  _   _            |     +------+
>>>>>> +    | | | | |           <---->| i2c1 |----------+
>>>>>> +    | |_| |_|           |     +------+          |            _________
>>>>>> +    |            -------|        |              |           |         |
>>>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>>>> +    |            -------|                                   |_________|
>>>>>> +    |___________________|
>>>>>> +
>>>>>> +properties:
>>>>>> +  $nodename:
>>>>>> +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
>>>>>> +
>>>>>> +  compatible:
>>>>>> +    oneOf:
>>>>>> +      - items:
>>>>>> +          - enum:
>>>>>> +              - loongson,ls7a1000-dc
>>>>>> +              - loongson,ls2k1000-dc
>>>>>> +              - loongson,ls2k0500-dc
>>>>>> +
>>>>>> +  reg:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  interrupts:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  '#address-cells':
>>>>>> +    const: 1
>>>>>> +
>>>>>> +  '#size-cells':
>>>>>> +    const: 0
>>>>>> +
>>>>>> +  i2c-gpio@0:
>>>>>> +    description: |
>>>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>>> If you have i2c-gpio, that belongs at the DT top-level, not here.
>>>>>
>>>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>>>> +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
>>>>> No, there's a defined i2c-gpio compatible already.
>>>> This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
>>>> By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
>>>> adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
>>>> LSDC register space, not general purpose GPIOs with separate control register resource.
>>>> So i think it is the child node of display-controller@6,1, it belongs to LSDC.
>>>> It seems that put it at the DT top-level break the hierarchy and relationship.
>>> Okay, I see. Then just 'i2c' for the node names. You need a reference to
>>> i2c-controller.yaml for these nodes too.
>>>
>>> The compatible should not have an index in it.
>> OK, i will fix this at the next version. thanks.
>>>>>> +      used to specify a I2c adapter bus number, if you don't specify one
>>>>>> +      i2c driver core will dynamically assign a bus number. Please specify
>>>>> Bus numbers are a linux detail not relevant to DT binding.
>>>>>
>>>>>> +      it only when its bus number matters. Bus number greater than 6 is safe
>>>>>> +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
>>>>>> +
>>>>>> +  i2c-gpio@1:
>>>>>> +    description: |
>>>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>>>> +      only. Its compatible must be lsdc,i2c-gpio-1.
>>>>>> +
>>>>>> +  ports:
>>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>>>> +
>>>>>> +    properties:
>>>>>> +      port@0:
>>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>>>> +
>>>>>> +      port@1:
>>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>>>> +
>>>>>> +    required:
>>>>>> +      - port@0
>>>>>> +      - port@1
>>>>>> +
>>>>>> +required:
>>>>>> +  - compatible
>>>>>> +  - reg
>>>>>> +  - interrupts
>>>>>> +  - ports
>>>>>> +
>>>>>> +additionalProperties: false
>>>>>> +
>>>>>> +examples:
>>>>>> +  - |
>>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>>> +    bus {
>>>>>> +
>>>>>> +        #address-cells = <3>;
>>>>>> +        #size-cells = <2>;
>>>>>> +        #interrupt-cells = <2>;
>>>>>> +
>>>>>> +        display-controller@6,1 {
>>>>>> +            compatible = "loongson,ls7a1000-dc";
>>>>>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>>>>>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> +
>>>>>> +            #address-cells = <1>;
>>>>>> +            #size-cells = <0>;
>>>>>> +
>>>>>> +            i2c-gpio@0 {
>>>>>> +                compatible = "lsdc,i2c-gpio-0";
>>>>>> +                reg = <6>;
>>> 'reg' needs to be documented with some description of what 6 and 7
>>> represent. If they are the control register offset, then make the
>>> address translatable (use 'ranges' and define the size).
>> By design, the reg property is used to specify a I2c adapter bus number,
>> if we don't specify one, i2c driver core will dynamically assign a bus number.
>> then the nr of the i2c adapter will started from 0. I want is start from 6
>> to avoid potential conflict feature hardware I2C driver.
>>
>> Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
>> but its driver is not up-streamed yet. By default these hardware I2C controller's
>> nr is started from 0.
> Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in
> that way.
Then,  can i use something like lsdc,nr = <6> ?
>> Even through i2c driver core can dynamically generate a number, i still want it
>> to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
>> i2c7 is for display pipe 1. This follow the convention and flexible enough.
> You may want that, but that is not how the kernel works. Specific
> numbers are not guaranteed. I'm sure you've seen this for disks, network
> interfaces, etc.
>
> Rob

2c_bit_add_numbered_bus() will guarantee it for you as long as If no 
devices have pre-been declared for this bus.

you can read the comment of 2c_bit_add_numbered_bus() at 
drivers/i2c/i2c-core-base.c

Re: [PATCH v11 2/7] MIPS: Loongson64: dts: introduce ls3A4000 evaluation board

[Sui Jingfeng]

On 2022/3/23 20:53, Rob Herring wrote:
> On Wed, Mar 23, 2022 at 09:53:14AM +0800, Sui Jingfeng wrote:
>> On 2022/3/23 00:06, Jiaxun Yang wrote:
>>>
>>> 在 2022/3/22 13:38, Sui Jingfeng 写道:
>>>> On 2022/3/22 21:05, Jiaxun Yang wrote:
>>>>>
>>>>> 在 2022/3/21 16:29, Sui Jingfeng 写道:
>>>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>>>
>>>>>> The board name is LS3A4000_7A1000_EVB_BOARD_V1.4, it consist of 1.8Ghz
>>>>>> mips64r5 4-core CPU and LS7A1000 bridge chip. It has PCIe
>>>>>> GEN2 x8 slot,
>>>>>> therefore can play with discrete graphics card.
>>>>> Hi Jingfeng,
>>>>>
>>>>> As we've discussed before if you are going to introduce new dts
>>>>> then you *MUST*
>>>>> include it in makefile and wire it up in code.
>>>>>
>>>>> A dts file doing nothing lying in the tree is just suspicious.
>>>>>
>>>>> Thanks.
>>>>> - Jiaxun
>>>>>
>>>> Hi, Jiaxun,
>>>>
>>>> I know what you means, but it is the kernel side developer's job.
>>>> I am just a naive graphic driver developer,I can not care so much.
>>>> Below is my private patch which can be used to built specific dts
>>>> into the linux kernel, therefore make the verification easier.
>>> Hi Jingfeng,
>>>
>>> In kernel world we take care all the stuff we touched ourself :-)
>>>
>>> If you are not confident with them please drop those DTS from the
>>> patchset
>>> besides the generic one. I can do the rest for you after getting this
>>> set merged.
>>>
>>> Thanks.
>>> - Jiaxun
>>>
>> Hi, Jiaxun
>>
>> Build all dts into vmlinuz will make the vmlinuz bigger and bigger.
>> How does the kernel get the dtb is another big issue, either from built-in
>> dtb or pass from the firmware(pmon and uefi etc). This should be
>> solved with another patch carefully. Providing board specific dts
>> helps to code review, it helps reviewers understand that there are
>> variant boards and have to be express with different OF graph.
> Built-in DTBs are for legacy bootloaders that don't understand DT. I
> would not expect a new platform to need this.
>
>> Now, there are about 6 dts under arch/mips/boot/dts/loongson/,
>> Suppose loongson have 1000+ different board, do you want built all
>> of them into vmlinuz?
> The point was to add the .dts to Makefile so it builds, not so it is
> built-in. How are you testing those build with dtc and dtschema if not
> added to kbuild?
OK, i see the key point.
> Rob

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 21:11, Rob Herring wrote:
> On Wed, Mar 23, 2022 at 12:12:43PM +0800, Sui Jingfeng wrote:
>> On 2022/3/23 04:49, Rob Herring wrote:
>>>> +/*
>>>> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
>>>> + *
>>>> + * @index : output channel index, 0 for DVO0, 1 for DVO1
>>>> + */
>>>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
>>>> +{
>>>> +	char compat[32] = {0};
>>>> +	unsigned int udelay = 5;
>>>> +	unsigned int timeout = 2200;
>>>> +	int nr = -1;
>>>> +	struct i2c_adapter *adapter;
>>>> +	struct lsdc_i2c *li2c;
>>>> +	struct device_node *i2c_np;
>>>> +	int ret;
>>>> +
>>>> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
>>>> +	if (!li2c)
>>>> +		return ERR_PTR(-ENOMEM);
>>>> +
>>>> +	li2c->index = index;
>>>> +	li2c->dev = dev;
>>>> +
>>>> +	if (index == 0) {
>>>> +		li2c->sda = 0x01;
>>>> +		li2c->scl = 0x02;
>>>> +	} else if (index == 1) {
>>>> +		li2c->sda = 0x04;
>>>> +		li2c->scl = 0x08;
>>> Just require this to be in DT rather than having some default.
>>>
>> By design,  I am try very hard to let the code NOT fully  DT dependent. DT is nice , easy to learn and use.
>> But kernel side developer plan to follow UEFI + ACPI Specification on LS3A5000 + LS7A1000 platform. See [1]
>> There will no DT support then, provide a convention support  make the driver more flexible. I want the
>> driver works with minimal requirement. The driver just works on simple boards by put the following dc device
>> node in arch/mips/dts/loongson/loongson64g_4core_ls7a.dts,
> Pick DT or ACPI for the platform, not both. We don't need to have both
> in the kernel to support.
>
> Rob

Hi Rob,

We can only choose DT currently, we love DT, but it is kernel side developer's choice.
We just avoid deep coupling which tend to lost flexibility.
All I can and should do is make the drivers works, writing code beautiful does not
means it can works like a charm.

 From what i am understanding, DT is not a strict specification, but in return flexible.
Force every driver comply with what already have is tend to prohibit innovation.
It just too late to do so.

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
>> +	}
>> +
>> +	spin_lock_init(&li2c->reglock);
>> +
>> +	snprintf(compat, sizeof(compat), "lsdc,i2c-gpio-%d", index);
> compatible values shouldn't have an index and you shouldn't need a
> index in DT. You need to iterate over child nodes with matching
> compatible.

Why compatible values shouldn't have an index, does devicetree
specification prohibit this? [1]

The recommended format is "manufacturer,model", where manufacturer is a string describing the name
of the manufacturer (such as a stock ticker symbol), and model specifies the model number. [1]

[1] https://www.devicetree.org/specifications/

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Thu, Mar 24, 2022 at 09:48:19AM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/23 21:03, Rob Herring wrote:
> > On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
> > > On 2022/3/23 04:55, Rob Herring wrote:
> > > > On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
> > > > > On 2022/3/22 07:20, Rob Herring wrote:
> > > > > > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > > > > > From: suijingfeng <suijingfeng@loongson.cn>
> > > > > > > 
> > > > > > Needs a commit message.
> > > > > > 
> > > > > > > Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> > > > > > > Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> > > > > > Same person? Don't need both emails.
> > > > > Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
> > > > > to send patches to dri-devel,
> > > > > 
> > > > > when send patches with this email, the patch will not be shown on patch
> > > > > works.
> > > > > 
> > > > > Emails  are either blocked or got  rejected  by loongson's mail server.  It
> > > > > can only receive emails
> > > > > 
> > > > > from you and other people, but not dri-devel. so have to use my personal
> > > > > email(15330273260@189.cn) to send patches.
> > > > > 
> > > > > > > ---
> > > > > > >     .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
> > > > > > >     1 file changed, 230 insertions(+)
> > > > > > >     create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > 
> > > > > > > diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..7be63346289e
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > @@ -0,0 +1,230 @@
> > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Sui Jingfeng <suijingfeng@loongson.cn>
> > > > > > > +
> > > > > > > +description: |+
> > > > > > > +
> > > > > > > +  Loongson display controllers are simple which require scanout buffers
> > > > > > > +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
> > > > > > > +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
> > > > > > > +  with a dedicated video RAM which is 64MB or more, precise size can be
> > > > > > > +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
> > > > > > > +  chip.
> > > > > > > +
> > > > > > > +  LSDC has two display pipes, each way has a DVO interface which provide
> > > > > > > +  RGB888 signals, vertical & horizontal synchronisations, data enable and
> > > > > > > +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
> > > > > > > +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
> > > > > > > +
> > > > > > > +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
> > > > > > > +  located at the DC register space. They are used to emulate two way i2c,
> > > > > > > +  One for DVO0, another for DVO1.
> > > > > > > +
> > > > > > > +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
> > > > > > > +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
> > > > > > > +
> > > > > > > +  LSDC's display pipeline have several components as below description,
> > > > > > > +
> > > > > > > +  The display controller in LS7A1000:
> > > > > > > +     ___________________                                     _________
> > > > > > > +    |            -------|                                   |         |
> > > > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > > > +    |  _   _     -------|        ^             ^            |_________|
> > > > > > > +    | | | | |    -------|        |             |
> > > > > > > +    | |_| |_|    | i2c0 <--------+-------------+
> > > > > > > +    |            -------|
> > > > > > > +    |   DC IN LS7A1000  |
> > > > > > > +    |  _   _     -------|
> > > > > > > +    | | | | |    | i2c1 <--------+-------------+
> > > > > > > +    | |_| |_|    -------|        |             |             _________
> > > > > > > +    |            -------|        |             |            |         |
> > > > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > > > +    |            -------|                                   |_________|
> > > > > > > +    |___________________|
> > > > > > > +
> > > > > > > +  Simple usage of LS7A1000 with LS3A4000 CPU:
> > > > > > > +
> > > > > > > +    +------+            +-----------------------------------+
> > > > > > > +    | DDR4 |            |  +-------------------+            |
> > > > > > > +    +------+            |  | PCIe Root complex |   LS7A1000 |
> > > > > > > +       || MC0           |  +--++---------++----+            |
> > > > > > > +  +----------+  HT 3.0  |     ||         ||                 |
> > > > > > > +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
> > > > > > > +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
> > > > > > > +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
> > > > > > > +       || MC1           +---------------|--|----------------+
> > > > > > > +    +------+                            |  |
> > > > > > > +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
> > > > > > > +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
> > > > > > > +                      +-------+                      +------+
> > > > > > > +
> > > > > > > +  The display controller in LS2K1000/LS2K0500:
> > > > > > > +     ___________________                                     _________
> > > > > > > +    |            -------|                                   |         |
> > > > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > > > +    |  _   _     -------|        ^              ^           |_________|
> > > > > > > +    | | | | |           |        |              |
> > > > > > > +    | |_| |_|           |     +------+          |
> > > > > > > +    |                   <---->| i2c0 |<---------+
> > > > > > > +    |   DC IN LS2K1000  |     +------+
> > > > > > > +    |  _   _            |     +------+
> > > > > > > +    | | | | |           <---->| i2c1 |----------+
> > > > > > > +    | |_| |_|           |     +------+          |            _________
> > > > > > > +    |            -------|        |              |           |         |
> > > > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > > > +    |            -------|                                   |_________|
> > > > > > > +    |___________________|
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  $nodename:
> > > > > > > +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
> > > > > > > +
> > > > > > > +  compatible:
> > > > > > > +    oneOf:
> > > > > > > +      - items:
> > > > > > > +          - enum:
> > > > > > > +              - loongson,ls7a1000-dc
> > > > > > > +              - loongson,ls2k1000-dc
> > > > > > > +              - loongson,ls2k0500-dc
> > > > > > > +
> > > > > > > +  reg:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  interrupts:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > > +  '#address-cells':
> > > > > > > +    const: 1
> > > > > > > +
> > > > > > > +  '#size-cells':
> > > > > > > +    const: 0
> > > > > > > +
> > > > > > > +  i2c-gpio@0:
> > > > > > > +    description: |
> > > > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > > If you have i2c-gpio, that belongs at the DT top-level, not here.
> > > > > > 
> > > > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > > > +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
> > > > > > No, there's a defined i2c-gpio compatible already.
> > > > > This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
> > > > > By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
> > > > > adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
> > > > > LSDC register space, not general purpose GPIOs with separate control register resource.
> > > > > So i think it is the child node of display-controller@6,1, it belongs to LSDC.
> > > > > It seems that put it at the DT top-level break the hierarchy and relationship.
> > > > Okay, I see. Then just 'i2c' for the node names. You need a reference to
> > > > i2c-controller.yaml for these nodes too.
> > > > 
> > > > The compatible should not have an index in it.
> > > OK, i will fix this at the next version. thanks.
> > > > > > > +      used to specify a I2c adapter bus number, if you don't specify one
> > > > > > > +      i2c driver core will dynamically assign a bus number. Please specify
> > > > > > Bus numbers are a linux detail not relevant to DT binding.
> > > > > > 
> > > > > > > +      it only when its bus number matters. Bus number greater than 6 is safe
> > > > > > > +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
> > > > > > > +
> > > > > > > +  i2c-gpio@1:
> > > > > > > +    description: |
> > > > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > > > +      only. Its compatible must be lsdc,i2c-gpio-1.
> > > > > > > +
> > > > > > > +  ports:
> > > > > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > > > > +
> > > > > > > +    properties:
> > > > > > > +      port@0:
> > > > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > > > +
> > > > > > > +      port@1:
> > > > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > > > +
> > > > > > > +    required:
> > > > > > > +      - port@0
> > > > > > > +      - port@1
> > > > > > > +
> > > > > > > +required:
> > > > > > > +  - compatible
> > > > > > > +  - reg
> > > > > > > +  - interrupts
> > > > > > > +  - ports
> > > > > > > +
> > > > > > > +additionalProperties: false
> > > > > > > +
> > > > > > > +examples:
> > > > > > > +  - |
> > > > > > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > > > > > +    bus {
> > > > > > > +
> > > > > > > +        #address-cells = <3>;
> > > > > > > +        #size-cells = <2>;
> > > > > > > +        #interrupt-cells = <2>;
> > > > > > > +
> > > > > > > +        display-controller@6,1 {
> > > > > > > +            compatible = "loongson,ls7a1000-dc";
> > > > > > > +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> > > > > > > +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > > +
> > > > > > > +            #address-cells = <1>;
> > > > > > > +            #size-cells = <0>;
> > > > > > > +
> > > > > > > +            i2c-gpio@0 {
> > > > > > > +                compatible = "lsdc,i2c-gpio-0";
> > > > > > > +                reg = <6>;
> > > > 'reg' needs to be documented with some description of what 6 and 7
> > > > represent. If they are the control register offset, then make the
> > > > address translatable (use 'ranges' and define the size).
> > > By design, the reg property is used to specify a I2c adapter bus number,
> > > if we don't specify one, i2c driver core will dynamically assign a bus number.
> > > then the nr of the i2c adapter will started from 0. I want is start from 6
> > > to avoid potential conflict feature hardware I2C driver.
> > > 
> > > Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
> > > but its driver is not up-streamed yet. By default these hardware I2C controller's
> > > nr is started from 0.
> > Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in
> > that way.
> Then,  can i use something like lsdc,nr = <6> ?
> > > Even through i2c driver core can dynamically generate a number, i still want it
> > > to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
> > > i2c7 is for display pipe 1. This follow the convention and flexible enough.
> > You may want that, but that is not how the kernel works. Specific
> > numbers are not guaranteed. I'm sure you've seen this for disks, network
> > interfaces, etc.
> > 
> > Rob
> 
> 2c_bit_add_numbered_bus() will guarantee it for you as long as If no devices
> have pre-been declared for this bus.
> 
> you can read the comment of 2c_bit_add_numbered_bus() at
> drivers/i2c/i2c-core-base.c

I didn't say it wasn't possible. It is not best practice. Grep 
i2c_bit_add_numbered_bus and see how many users there are. Even if the 
kernel allows specifying bus numbers, your Linux bus numbers don't 
belong in DT.

Rob

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Rob Herring]

On Thu, Mar 24, 2022 at 09:39:49AM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/23 04:49, Rob Herring wrote:
> > On Tue, Mar 22, 2022 at 12:29:16AM +0800, Sui Jingfeng wrote:
> > > From: suijingfeng <suijingfeng@loongson.cn>
> > > 
> > > There is a display controller in loongson's LS2K1000 SoC and LS7A1000
> > > bridge chip, the display controller is a PCI device in those chips. It
> > > has two display pipes but with only one hardware cursor. Each way has
> > > a DVO interface which provide RGB888 signals, vertical & horizontal
> > > synchronisations, data enable and the pixel clock. Each CRTC is able to
> > > scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
> > > 2048x2048 according to the hardware spec. Loongson display controllers
> > > are simple which require scanout buffers to be physically contiguous.

[...]

> > > +			val |= mask;
> > > +		else
> > > +			val &= ~mask;
> > > +		writeb(val, li2c->dat_reg);
> > Shouldn't you set the data register low first and then change the
> > direction? Otherwise, you may be driving high for a moment. However, if
> > high is always done by setting the direction as input, why write the
> > data register each time? I'm assuming whatever is written to the dat_reg
> > is maintained regardless of pin state.
> > 
> When the pin is input, i am not sure value written to it will be preserved.
> 
> I'm worry about it get flushed by the external input value.
> 
> Because the output data register is same with the input data register(
> offset is  0x1650).
> 
> The hardware designer do not provided a  separation.

Usually for GPIO data registers the read value is current pin state 
regardless of direction and the written value is what to drive as an 
output. But your h/w could be different.


> > > +
> > > +		/* Optional properties which made the driver more flexible */
> > > +		of_property_read_u32(i2c_np, "udelay", &udelay);
> > > +		of_property_read_u32(i2c_np, "timeout", &timeout);
> > These aren't documented. Do you really need them in DT?
> 
> Yes, in very rare case:
> 
> When debugging, sometimes one way I2C works, another way I2C not on specific
> board.

This is not specific to you, so why do you solve it in a way that only 
works for you? If you want to add tuning parameters to the i2c bit 
algorithm, why don't you do so in a way that works for all users? I'm 
sure the I2C maintainer and others have some opinion on this, but 
they'll never see it hidden away in some display driver.


> and you want to see what will happen if you change it from 5 to 2.
> 
> modify device tree is enough, have to recompile the kernel and driver
> modules every time.

Modifying the DT is not the easiest way to debug either.


> It is optional through.

Lots of properties are optional, what's your point?


> Please do not ask me to document such a easy thing,

Everything must be documented. There's nothing more to discuss.


> DT itself is a documention, human readable,  it already speak for itself.

It is machine readable too. Undocumented properties generate warnings 
now.

Rob

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Rob Herring]

On Thu, Mar 24, 2022 at 03:32:01PM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/23 04:49, Rob Herring wrote:
> > > +	}
> > > +
> > > +	spin_lock_init(&li2c->reglock);
> > > +
> > > +	snprintf(compat, sizeof(compat), "lsdc,i2c-gpio-%d", index);
> > compatible values shouldn't have an index and you shouldn't need a
> > index in DT. You need to iterate over child nodes with matching
> > compatible.
> 
> Why compatible values shouldn't have an index, does devicetree
> specification prohibit this? [1]

Probably not explicitly, but that's fundamentally not how compatible 
works. 'compatible' defines WHAT the device is, not WHICH device and 
that is used for matching devices to drivers. Drivers work on multiple 
instances.

> The recommended format is "manufacturer,model", where manufacturer is a string describing the name
> of the manufacturer (such as a stock ticker symbol), and model specifies the model number. [1]

I don't see anything saying to put the instance in there, do you?

> 
> [1] https://www.devicetree.org/specifications/
> 

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

On 2022/3/24 21:26, Rob Herring wrote:
> On Thu, Mar 24, 2022 at 09:48:19AM +0800, Sui Jingfeng wrote:
>> On 2022/3/23 21:03, Rob Herring wrote:
>>> On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
>>>> On 2022/3/23 04:55, Rob Herring wrote:
>>>>> On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
>>>>>> On 2022/3/22 07:20, Rob Herring wrote:
>>>>>>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>>>>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>>>>>
>>>>>>> Needs a commit message.
>>>>>>>
>>>>>>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>>>>>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>>>>>>> Same person? Don't need both emails.
>>>>>> Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
>>>>>> to send patches to dri-devel,
>>>>>>
>>>>>> when send patches with this email, the patch will not be shown on patch
>>>>>> works.
>>>>>>
>>>>>> Emails  are either blocked or got  rejected  by loongson's mail server.  It
>>>>>> can only receive emails
>>>>>>
>>>>>> from you and other people, but not dri-devel. so have to use my personal
>>>>>> email(15330273260@189.cn) to send patches.
>>>>>>
>>>>>>>> ---
>>>>>>>>      .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
>>>>>>>>      1 file changed, 230 insertions(+)
>>>>>>>>      create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..7be63346289e
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>>> @@ -0,0 +1,230 @@
>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>> +%YAML 1.2
>>>>>>>> +---
>>>>>>>> +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>> +
>>>>>>>> +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
>>>>>>>> +
>>>>>>>> +maintainers:
>>>>>>>> +  - Sui Jingfeng <suijingfeng@loongson.cn>
>>>>>>>> +
>>>>>>>> +description: |+
>>>>>>>> +
>>>>>>>> +  Loongson display controllers are simple which require scanout buffers
>>>>>>>> +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
>>>>>>>> +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
>>>>>>>> +  with a dedicated video RAM which is 64MB or more, precise size can be
>>>>>>>> +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
>>>>>>>> +  chip.
>>>>>>>> +
>>>>>>>> +  LSDC has two display pipes, each way has a DVO interface which provide
>>>>>>>> +  RGB888 signals, vertical & horizontal synchronisations, data enable and
>>>>>>>> +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
>>>>>>>> +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
>>>>>>>> +
>>>>>>>> +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
>>>>>>>> +  located at the DC register space. They are used to emulate two way i2c,
>>>>>>>> +  One for DVO0, another for DVO1.
>>>>>>>> +
>>>>>>>> +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
>>>>>>>> +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
>>>>>>>> +
>>>>>>>> +  LSDC's display pipeline have several components as below description,
>>>>>>>> +
>>>>>>>> +  The display controller in LS7A1000:
>>>>>>>> +     ___________________                                     _________
>>>>>>>> +    |            -------|                                   |         |
>>>>>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>>>>>> +    |  _   _     -------|        ^             ^            |_________|
>>>>>>>> +    | | | | |    -------|        |             |
>>>>>>>> +    | |_| |_|    | i2c0 <--------+-------------+
>>>>>>>> +    |            -------|
>>>>>>>> +    |   DC IN LS7A1000  |
>>>>>>>> +    |  _   _     -------|
>>>>>>>> +    | | | | |    | i2c1 <--------+-------------+
>>>>>>>> +    | |_| |_|    -------|        |             |             _________
>>>>>>>> +    |            -------|        |             |            |         |
>>>>>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>>>>>> +    |            -------|                                   |_________|
>>>>>>>> +    |___________________|
>>>>>>>> +
>>>>>>>> +  Simple usage of LS7A1000 with LS3A4000 CPU:
>>>>>>>> +
>>>>>>>> +    +------+            +-----------------------------------+
>>>>>>>> +    | DDR4 |            |  +-------------------+            |
>>>>>>>> +    +------+            |  | PCIe Root complex |   LS7A1000 |
>>>>>>>> +       || MC0           |  +--++---------++----+            |
>>>>>>>> +  +----------+  HT 3.0  |     ||         ||                 |
>>>>>>>> +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>>>>>>> +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>>>>>>> +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>>>>>>> +       || MC1           +---------------|--|----------------+
>>>>>>>> +    +------+                            |  |
>>>>>>>> +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>>>>>>> +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>>>>>>> +                      +-------+                      +------+
>>>>>>>> +
>>>>>>>> +  The display controller in LS2K1000/LS2K0500:
>>>>>>>> +     ___________________                                     _________
>>>>>>>> +    |            -------|                                   |         |
>>>>>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>>>>>> +    |  _   _     -------|        ^              ^           |_________|
>>>>>>>> +    | | | | |           |        |              |
>>>>>>>> +    | |_| |_|           |     +------+          |
>>>>>>>> +    |                   <---->| i2c0 |<---------+
>>>>>>>> +    |   DC IN LS2K1000  |     +------+
>>>>>>>> +    |  _   _            |     +------+
>>>>>>>> +    | | | | |           <---->| i2c1 |----------+
>>>>>>>> +    | |_| |_|           |     +------+          |            _________
>>>>>>>> +    |            -------|        |              |           |         |
>>>>>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>>>>>> +    |            -------|                                   |_________|
>>>>>>>> +    |___________________|
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> +  $nodename:
>>>>>>>> +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
>>>>>>>> +
>>>>>>>> +  compatible:
>>>>>>>> +    oneOf:
>>>>>>>> +      - items:
>>>>>>>> +          - enum:
>>>>>>>> +              - loongson,ls7a1000-dc
>>>>>>>> +              - loongson,ls2k1000-dc
>>>>>>>> +              - loongson,ls2k0500-dc
>>>>>>>> +
>>>>>>>> +  reg:
>>>>>>>> +    maxItems: 1
>>>>>>>> +
>>>>>>>> +  interrupts:
>>>>>>>> +    maxItems: 1
>>>>>>>> +
>>>>>>>> +  '#address-cells':
>>>>>>>> +    const: 1
>>>>>>>> +
>>>>>>>> +  '#size-cells':
>>>>>>>> +    const: 0
>>>>>>>> +
>>>>>>>> +  i2c-gpio@0:
>>>>>>>> +    description: |
>>>>>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>>>>> If you have i2c-gpio, that belongs at the DT top-level, not here.
>>>>>>>
>>>>>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>>>>>> +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
>>>>>>> No, there's a defined i2c-gpio compatible already.
>>>>>> This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
>>>>>> By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
>>>>>> adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
>>>>>> LSDC register space, not general purpose GPIOs with separate control register resource.
>>>>>> So i think it is the child node of display-controller@6,1, it belongs to LSDC.
>>>>>> It seems that put it at the DT top-level break the hierarchy and relationship.
>>>>> Okay, I see. Then just 'i2c' for the node names. You need a reference to
>>>>> i2c-controller.yaml for these nodes too.
>>>>>
>>>>> The compatible should not have an index in it.
>>>> OK, i will fix this at the next version. thanks.
>>>>>>>> +      used to specify a I2c adapter bus number, if you don't specify one
>>>>>>>> +      i2c driver core will dynamically assign a bus number. Please specify
>>>>>>> Bus numbers are a linux detail not relevant to DT binding.
>>>>>>>
>>>>>>>> +      it only when its bus number matters. Bus number greater than 6 is safe
>>>>>>>> +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
>>>>>>>> +
>>>>>>>> +  i2c-gpio@1:
>>>>>>>> +    description: |
>>>>>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>>>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>>>>>> +      only. Its compatible must be lsdc,i2c-gpio-1.
>>>>>>>> +
>>>>>>>> +  ports:
>>>>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>>>>>> +
>>>>>>>> +    properties:
>>>>>>>> +      port@0:
>>>>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>>>>>> +
>>>>>>>> +      port@1:
>>>>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>>>>>> +
>>>>>>>> +    required:
>>>>>>>> +      - port@0
>>>>>>>> +      - port@1
>>>>>>>> +
>>>>>>>> +required:
>>>>>>>> +  - compatible
>>>>>>>> +  - reg
>>>>>>>> +  - interrupts
>>>>>>>> +  - ports
>>>>>>>> +
>>>>>>>> +additionalProperties: false
>>>>>>>> +
>>>>>>>> +examples:
>>>>>>>> +  - |
>>>>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>>> +    bus {
>>>>>>>> +
>>>>>>>> +        #address-cells = <3>;
>>>>>>>> +        #size-cells = <2>;
>>>>>>>> +        #interrupt-cells = <2>;
>>>>>>>> +
>>>>>>>> +        display-controller@6,1 {
>>>>>>>> +            compatible = "loongson,ls7a1000-dc";
>>>>>>>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>>>>>>>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>> +
>>>>>>>> +            #address-cells = <1>;
>>>>>>>> +            #size-cells = <0>;
>>>>>>>> +
>>>>>>>> +            i2c-gpio@0 {
>>>>>>>> +                compatible = "lsdc,i2c-gpio-0";
>>>>>>>> +                reg = <6>;
>>>>> 'reg' needs to be documented with some description of what 6 and 7
>>>>> represent. If they are the control register offset, then make the
>>>>> address translatable (use 'ranges' and define the size).
>>>> By design, the reg property is used to specify a I2c adapter bus number,
>>>> if we don't specify one, i2c driver core will dynamically assign a bus number.
>>>> then the nr of the i2c adapter will started from 0. I want is start from 6
>>>> to avoid potential conflict feature hardware I2C driver.
>>>>
>>>> Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
>>>> but its driver is not up-streamed yet. By default these hardware I2C controller's
>>>> nr is started from 0.
>>> Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in
>>> that way.
>> Then,  can i use something like lsdc,nr = <6> ?
>>>> Even through i2c driver core can dynamically generate a number, i still want it
>>>> to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
>>>> i2c7 is for display pipe 1. This follow the convention and flexible enough.
>>> You may want that, but that is not how the kernel works. Specific
>>> numbers are not guaranteed. I'm sure you've seen this for disks, network
>>> interfaces, etc.
>>>
>>> Rob
>> 2c_bit_add_numbered_bus() will guarantee it for you as long as If no devices
>> have pre-been declared for this bus.
>>
>> you can read the comment of 2c_bit_add_numbered_bus() at
>> drivers/i2c/i2c-core-base.c
> I didn't say it wasn't possible. It is not best practice. Grep
> i2c_bit_add_numbered_bus and see how many users there are.

i2c-gpio.c at drivers/i2c/busses/ just do the same thing.


+ nvidia,bpmp-bus-id: + $ref: /schemas/types.yaml#/definitions/uint32 + 
description: Indicates the I2C bus number this DT node represents, + as 
defined by the BPMP firmware.

> Even if the kernel allows specifying bus numbers,your Linux bus numbers don't
> belong in DT.

Again, Does does devicetree specification prohibit this?

Nvidia also put i2c bus number in the DT, we learn that from nvidia. [1][2]

[1] Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml

[2] 
https://lore.kernel.org/all/20211208143306.534700-1-thierry.reding@gmail.com/


>
> Rob

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Sat, Mar 26, 2022 at 06:04:46PM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/24 21:26, Rob Herring wrote:
> > On Thu, Mar 24, 2022 at 09:48:19AM +0800, Sui Jingfeng wrote:
> > > On 2022/3/23 21:03, Rob Herring wrote:
> > > > On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
> > > > > On 2022/3/23 04:55, Rob Herring wrote:
> > > > > > On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
> > > > > > > On 2022/3/22 07:20, Rob Herring wrote:
> > > > > > > > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > > > > > > > From: suijingfeng <suijingfeng@loongson.cn>
> > > > > > > > > 
> > > > > > > > Needs a commit message.
> > > > > > > > 
> > > > > > > > > Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> > > > > > > > > Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> > > > > > > > Same person? Don't need both emails.
> > > > > > > Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
> > > > > > > to send patches to dri-devel,
> > > > > > > 
> > > > > > > when send patches with this email, the patch will not be shown on patch
> > > > > > > works.
> > > > > > > 
> > > > > > > Emails  are either blocked or got  rejected  by loongson's mail server.  It
> > > > > > > can only receive emails
> > > > > > > 
> > > > > > > from you and other people, but not dri-devel. so have to use my personal
> > > > > > > email(15330273260@189.cn) to send patches.
> > > > > > > 
> > > > > > > > > ---
> > > > > > > > >      .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
> > > > > > > > >      1 file changed, 230 insertions(+)
> > > > > > > > >      create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > > > 
> > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..7be63346289e
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > > > @@ -0,0 +1,230 @@
> > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > > > +%YAML 1.2
> > > > > > > > > +---
> > > > > > > > > +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
> > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > +
> > > > > > > > > +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
> > > > > > > > > +
> > > > > > > > > +maintainers:
> > > > > > > > > +  - Sui Jingfeng <suijingfeng@loongson.cn>
> > > > > > > > > +
> > > > > > > > > +description: |+
> > > > > > > > > +
> > > > > > > > > +  Loongson display controllers are simple which require scanout buffers
> > > > > > > > > +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
> > > > > > > > > +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
> > > > > > > > > +  with a dedicated video RAM which is 64MB or more, precise size can be
> > > > > > > > > +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
> > > > > > > > > +  chip.
> > > > > > > > > +
> > > > > > > > > +  LSDC has two display pipes, each way has a DVO interface which provide
> > > > > > > > > +  RGB888 signals, vertical & horizontal synchronisations, data enable and
> > > > > > > > > +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
> > > > > > > > > +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
> > > > > > > > > +
> > > > > > > > > +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
> > > > > > > > > +  located at the DC register space. They are used to emulate two way i2c,
> > > > > > > > > +  One for DVO0, another for DVO1.
> > > > > > > > > +
> > > > > > > > > +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
> > > > > > > > > +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
> > > > > > > > > +
> > > > > > > > > +  LSDC's display pipeline have several components as below description,
> > > > > > > > > +
> > > > > > > > > +  The display controller in LS7A1000:
> > > > > > > > > +     ___________________                                     _________
> > > > > > > > > +    |            -------|                                   |         |
> > > > > > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > > > > > +    |  _   _     -------|        ^             ^            |_________|
> > > > > > > > > +    | | | | |    -------|        |             |
> > > > > > > > > +    | |_| |_|    | i2c0 <--------+-------------+
> > > > > > > > > +    |            -------|
> > > > > > > > > +    |   DC IN LS7A1000  |
> > > > > > > > > +    |  _   _     -------|
> > > > > > > > > +    | | | | |    | i2c1 <--------+-------------+
> > > > > > > > > +    | |_| |_|    -------|        |             |             _________
> > > > > > > > > +    |            -------|        |             |            |         |
> > > > > > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > > > > > +    |            -------|                                   |_________|
> > > > > > > > > +    |___________________|
> > > > > > > > > +
> > > > > > > > > +  Simple usage of LS7A1000 with LS3A4000 CPU:
> > > > > > > > > +
> > > > > > > > > +    +------+            +-----------------------------------+
> > > > > > > > > +    | DDR4 |            |  +-------------------+            |
> > > > > > > > > +    +------+            |  | PCIe Root complex |   LS7A1000 |
> > > > > > > > > +       || MC0           |  +--++---------++----+            |
> > > > > > > > > +  +----------+  HT 3.0  |     ||         ||                 |
> > > > > > > > > +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
> > > > > > > > > +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
> > > > > > > > > +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
> > > > > > > > > +       || MC1           +---------------|--|----------------+
> > > > > > > > > +    +------+                            |  |
> > > > > > > > > +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
> > > > > > > > > +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
> > > > > > > > > +                      +-------+                      +------+
> > > > > > > > > +
> > > > > > > > > +  The display controller in LS2K1000/LS2K0500:
> > > > > > > > > +     ___________________                                     _________
> > > > > > > > > +    |            -------|                                   |         |
> > > > > > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > > > > > +    |  _   _     -------|        ^              ^           |_________|
> > > > > > > > > +    | | | | |           |        |              |
> > > > > > > > > +    | |_| |_|           |     +------+          |
> > > > > > > > > +    |                   <---->| i2c0 |<---------+
> > > > > > > > > +    |   DC IN LS2K1000  |     +------+
> > > > > > > > > +    |  _   _            |     +------+
> > > > > > > > > +    | | | | |           <---->| i2c1 |----------+
> > > > > > > > > +    | |_| |_|           |     +------+          |            _________
> > > > > > > > > +    |            -------|        |              |           |         |
> > > > > > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > > > > > +    |            -------|                                   |_________|
> > > > > > > > > +    |___________________|
> > > > > > > > > +
> > > > > > > > > +properties:
> > > > > > > > > +  $nodename:
> > > > > > > > > +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
> > > > > > > > > +
> > > > > > > > > +  compatible:
> > > > > > > > > +    oneOf:
> > > > > > > > > +      - items:
> > > > > > > > > +          - enum:
> > > > > > > > > +              - loongson,ls7a1000-dc
> > > > > > > > > +              - loongson,ls2k1000-dc
> > > > > > > > > +              - loongson,ls2k0500-dc
> > > > > > > > > +
> > > > > > > > > +  reg:
> > > > > > > > > +    maxItems: 1
> > > > > > > > > +
> > > > > > > > > +  interrupts:
> > > > > > > > > +    maxItems: 1
> > > > > > > > > +
> > > > > > > > > +  '#address-cells':
> > > > > > > > > +    const: 1
> > > > > > > > > +
> > > > > > > > > +  '#size-cells':
> > > > > > > > > +    const: 0
> > > > > > > > > +
> > > > > > > > > +  i2c-gpio@0:
> > > > > > > > > +    description: |
> > > > > > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > > > > If you have i2c-gpio, that belongs at the DT top-level, not here.
> > > > > > > > 
> > > > > > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > > > > > +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
> > > > > > > > No, there's a defined i2c-gpio compatible already.
> > > > > > > This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
> > > > > > > By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
> > > > > > > adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
> > > > > > > LSDC register space, not general purpose GPIOs with separate control register resource.
> > > > > > > So i think it is the child node of display-controller@6,1, it belongs to LSDC.
> > > > > > > It seems that put it at the DT top-level break the hierarchy and relationship.
> > > > > > Okay, I see. Then just 'i2c' for the node names. You need a reference to
> > > > > > i2c-controller.yaml for these nodes too.
> > > > > > 
> > > > > > The compatible should not have an index in it.
> > > > > OK, i will fix this at the next version. thanks.
> > > > > > > > > +      used to specify a I2c adapter bus number, if you don't specify one
> > > > > > > > > +      i2c driver core will dynamically assign a bus number. Please specify
> > > > > > > > Bus numbers are a linux detail not relevant to DT binding.
> > > > > > > > 
> > > > > > > > > +      it only when its bus number matters. Bus number greater than 6 is safe
> > > > > > > > > +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
> > > > > > > > > +
> > > > > > > > > +  i2c-gpio@1:
> > > > > > > > > +    description: |
> > > > > > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > > > > > +      only. Its compatible must be lsdc,i2c-gpio-1.
> > > > > > > > > +
> > > > > > > > > +  ports:
> > > > > > > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > > > > > > +
> > > > > > > > > +    properties:
> > > > > > > > > +      port@0:
> > > > > > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > > > > > +
> > > > > > > > > +      port@1:
> > > > > > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > > > > > +
> > > > > > > > > +    required:
> > > > > > > > > +      - port@0
> > > > > > > > > +      - port@1
> > > > > > > > > +
> > > > > > > > > +required:
> > > > > > > > > +  - compatible
> > > > > > > > > +  - reg
> > > > > > > > > +  - interrupts
> > > > > > > > > +  - ports
> > > > > > > > > +
> > > > > > > > > +additionalProperties: false
> > > > > > > > > +
> > > > > > > > > +examples:
> > > > > > > > > +  - |
> > > > > > > > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > > > > > > > +    bus {
> > > > > > > > > +
> > > > > > > > > +        #address-cells = <3>;
> > > > > > > > > +        #size-cells = <2>;
> > > > > > > > > +        #interrupt-cells = <2>;
> > > > > > > > > +
> > > > > > > > > +        display-controller@6,1 {
> > > > > > > > > +            compatible = "loongson,ls7a1000-dc";
> > > > > > > > > +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> > > > > > > > > +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > > > > +
> > > > > > > > > +            #address-cells = <1>;
> > > > > > > > > +            #size-cells = <0>;
> > > > > > > > > +
> > > > > > > > > +            i2c-gpio@0 {
> > > > > > > > > +                compatible = "lsdc,i2c-gpio-0";
> > > > > > > > > +                reg = <6>;
> > > > > > 'reg' needs to be documented with some description of what 6 and 7
> > > > > > represent. If they are the control register offset, then make the
> > > > > > address translatable (use 'ranges' and define the size).
> > > > > By design, the reg property is used to specify a I2c adapter bus number,
> > > > > if we don't specify one, i2c driver core will dynamically assign a bus number.
> > > > > then the nr of the i2c adapter will started from 0. I want is start from 6
> > > > > to avoid potential conflict feature hardware I2C driver.
> > > > > 
> > > > > Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
> > > > > but its driver is not up-streamed yet. By default these hardware I2C controller's
> > > > > nr is started from 0.
> > > > Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in
> > > > that way.
> > > Then,  can i use something like lsdc,nr = <6> ?
> > > > > Even through i2c driver core can dynamically generate a number, i still want it
> > > > > to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
> > > > > i2c7 is for display pipe 1. This follow the convention and flexible enough.
> > > > You may want that, but that is not how the kernel works. Specific
> > > > numbers are not guaranteed. I'm sure you've seen this for disks, network
> > > > interfaces, etc.
> > > > 
> > > > Rob
> > > 2c_bit_add_numbered_bus() will guarantee it for you as long as If no devices
> > > have pre-been declared for this bus.
> > > 
> > > you can read the comment of 2c_bit_add_numbered_bus() at
> > > drivers/i2c/i2c-core-base.c
> > I didn't say it wasn't possible. It is not best practice. Grep
> > i2c_bit_add_numbered_bus and see how many users there are.
> 
> i2c-gpio.c at drivers/i2c/busses/ just do the same thing.

No, the id for i2c-gpio nodes (any DT node without 'reg') will be -1 
which means dynamically assigned.


> + nvidia,bpmp-bus-id: + $ref: /schemas/types.yaml#/definitions/uint32 +
> description: Indicates the I2C bus number this DT node represents, + as
> defined by the BPMP firmware.

The key difference is the numbering is defined by the BPMP firmware.


> > Even if the kernel allows specifying bus numbers,your Linux bus numbers don't
> > belong in DT.
> 
> Again, Does does devicetree specification prohibit this?

No. The spec is not the last word on what's allowed or not. Lots of 
patterns exist already which we can't change, but that doesn't mean they 
should be copied by new users.

Rob

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Sui Jingfeng]

On 2022/3/28 22:04, Rob Herring wrote:
> On Sat, Mar 26, 2022 at 06:04:46PM +0800, Sui Jingfeng wrote:
>> On 2022/3/24 21:26, Rob Herring wrote:
>>> On Thu, Mar 24, 2022 at 09:48:19AM +0800, Sui Jingfeng wrote:
>>>> On 2022/3/23 21:03, Rob Herring wrote:
>>>>> On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
>>>>>> On 2022/3/23 04:55, Rob Herring wrote:
>>>>>>> On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
>>>>>>>> On 2022/3/22 07:20, Rob Herring wrote:
>>>>>>>>> On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
>>>>>>>>>> From: suijingfeng <suijingfeng@loongson.cn>
>>>>>>>>>>
>>>>>>>>> Needs a commit message.
>>>>>>>>>
>>>>>>>>>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>>>>>>>>>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>>>>>>>>> Same person? Don't need both emails.
>>>>>>>> Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
>>>>>>>> to send patches to dri-devel,
>>>>>>>>
>>>>>>>> when send patches with this email, the patch will not be shown on patch
>>>>>>>> works.
>>>>>>>>
>>>>>>>> Emails  are either blocked or got  rejected  by loongson's mail server.  It
>>>>>>>> can only receive emails
>>>>>>>>
>>>>>>>> from you and other people, but not dri-devel. so have to use my personal
>>>>>>>> email(15330273260@189.cn) to send patches.
>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>       .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
>>>>>>>>>>       1 file changed, 230 insertions(+)
>>>>>>>>>>       create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..7be63346289e
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
>>>>>>>>>> @@ -0,0 +1,230 @@
>>>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>>>> +%YAML 1.2
>>>>>>>>>> +---
>>>>>>>>>> +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
>>>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>>> +
>>>>>>>>>> +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
>>>>>>>>>> +
>>>>>>>>>> +maintainers:
>>>>>>>>>> +  - Sui Jingfeng <suijingfeng@loongson.cn>
>>>>>>>>>> +
>>>>>>>>>> +description: |+
>>>>>>>>>> +
>>>>>>>>>> +  Loongson display controllers are simple which require scanout buffers
>>>>>>>>>> +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
>>>>>>>>>> +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
>>>>>>>>>> +  with a dedicated video RAM which is 64MB or more, precise size can be
>>>>>>>>>> +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
>>>>>>>>>> +  chip.
>>>>>>>>>> +
>>>>>>>>>> +  LSDC has two display pipes, each way has a DVO interface which provide
>>>>>>>>>> +  RGB888 signals, vertical & horizontal synchronisations, data enable and
>>>>>>>>>> +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
>>>>>>>>>> +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
>>>>>>>>>> +
>>>>>>>>>> +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
>>>>>>>>>> +  located at the DC register space. They are used to emulate two way i2c,
>>>>>>>>>> +  One for DVO0, another for DVO1.
>>>>>>>>>> +
>>>>>>>>>> +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
>>>>>>>>>> +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
>>>>>>>>>> +
>>>>>>>>>> +  LSDC's display pipeline have several components as below description,
>>>>>>>>>> +
>>>>>>>>>> +  The display controller in LS7A1000:
>>>>>>>>>> +     ___________________                                     _________
>>>>>>>>>> +    |            -------|                                   |         |
>>>>>>>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>>>>>>>> +    |  _   _     -------|        ^             ^            |_________|
>>>>>>>>>> +    | | | | |    -------|        |             |
>>>>>>>>>> +    | |_| |_|    | i2c0 <--------+-------------+
>>>>>>>>>> +    |            -------|
>>>>>>>>>> +    |   DC IN LS7A1000  |
>>>>>>>>>> +    |  _   _     -------|
>>>>>>>>>> +    | | | | |    | i2c1 <--------+-------------+
>>>>>>>>>> +    | |_| |_|    -------|        |             |             _________
>>>>>>>>>> +    |            -------|        |             |            |         |
>>>>>>>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>>>>>>>> +    |            -------|                                   |_________|
>>>>>>>>>> +    |___________________|
>>>>>>>>>> +
>>>>>>>>>> +  Simple usage of LS7A1000 with LS3A4000 CPU:
>>>>>>>>>> +
>>>>>>>>>> +    +------+            +-----------------------------------+
>>>>>>>>>> +    | DDR4 |            |  +-------------------+            |
>>>>>>>>>> +    +------+            |  | PCIe Root complex |   LS7A1000 |
>>>>>>>>>> +       || MC0           |  +--++---------++----+            |
>>>>>>>>>> +  +----------+  HT 3.0  |     ||         ||                 |
>>>>>>>>>> +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>>>>>>>>> +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>>>>>>>>> +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>>>>>>>>> +       || MC1           +---------------|--|----------------+
>>>>>>>>>> +    +------+                            |  |
>>>>>>>>>> +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>>>>>>>>> +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>>>>>>>>> +                      +-------+                      +------+
>>>>>>>>>> +
>>>>>>>>>> +  The display controller in LS2K1000/LS2K0500:
>>>>>>>>>> +     ___________________                                     _________
>>>>>>>>>> +    |            -------|                                   |         |
>>>>>>>>>> +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
>>>>>>>>>> +    |  _   _     -------|        ^              ^           |_________|
>>>>>>>>>> +    | | | | |           |        |              |
>>>>>>>>>> +    | |_| |_|           |     +------+          |
>>>>>>>>>> +    |                   <---->| i2c0 |<---------+
>>>>>>>>>> +    |   DC IN LS2K1000  |     +------+
>>>>>>>>>> +    |  _   _            |     +------+
>>>>>>>>>> +    | | | | |           <---->| i2c1 |----------+
>>>>>>>>>> +    | |_| |_|           |     +------+          |            _________
>>>>>>>>>> +    |            -------|        |              |           |         |
>>>>>>>>>> +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
>>>>>>>>>> +    |            -------|                                   |_________|
>>>>>>>>>> +    |___________________|
>>>>>>>>>> +
>>>>>>>>>> +properties:
>>>>>>>>>> +  $nodename:
>>>>>>>>>> +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
>>>>>>>>>> +
>>>>>>>>>> +  compatible:
>>>>>>>>>> +    oneOf:
>>>>>>>>>> +      - items:
>>>>>>>>>> +          - enum:
>>>>>>>>>> +              - loongson,ls7a1000-dc
>>>>>>>>>> +              - loongson,ls2k1000-dc
>>>>>>>>>> +              - loongson,ls2k0500-dc
>>>>>>>>>> +
>>>>>>>>>> +  reg:
>>>>>>>>>> +    maxItems: 1
>>>>>>>>>> +
>>>>>>>>>> +  interrupts:
>>>>>>>>>> +    maxItems: 1
>>>>>>>>>> +
>>>>>>>>>> +  '#address-cells':
>>>>>>>>>> +    const: 1
>>>>>>>>>> +
>>>>>>>>>> +  '#size-cells':
>>>>>>>>>> +    const: 0
>>>>>>>>>> +
>>>>>>>>>> +  i2c-gpio@0:
>>>>>>>>>> +    description: |
>>>>>>>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>>>>>>> If you have i2c-gpio, that belongs at the DT top-level, not here.
>>>>>>>>>
>>>>>>>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>>>>>>>> +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
>>>>>>>>> No, there's a defined i2c-gpio compatible already.
>>>>>>>> This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
>>>>>>>> By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
>>>>>>>> adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
>>>>>>>> LSDC register space, not general purpose GPIOs with separate control register resource.
>>>>>>>> So i think it is the child node of display-controller@6,1, it belongs to LSDC.
>>>>>>>> It seems that put it at the DT top-level break the hierarchy and relationship.
>>>>>>> Okay, I see. Then just 'i2c' for the node names. You need a reference to
>>>>>>> i2c-controller.yaml for these nodes too.
>>>>>>>
>>>>>>> The compatible should not have an index in it.
>>>>>> OK, i will fix this at the next version. thanks.
>>>>>>>>>> +      used to specify a I2c adapter bus number, if you don't specify one
>>>>>>>>>> +      i2c driver core will dynamically assign a bus number. Please specify
>>>>>>>>> Bus numbers are a linux detail not relevant to DT binding.
>>>>>>>>>
>>>>>>>>>> +      it only when its bus number matters. Bus number greater than 6 is safe
>>>>>>>>>> +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
>>>>>>>>>> +
>>>>>>>>>> +  i2c-gpio@1:
>>>>>>>>>> +    description: |
>>>>>>>>>> +      Built-in GPIO emulate i2c exported for external display bridge
>>>>>>>>>> +      configuration, onitor detection and edid read back etc, for ls7a1000
>>>>>>>>>> +      only. Its compatible must be lsdc,i2c-gpio-1.
>>>>>>>>>> +
>>>>>>>>>> +  ports:
>>>>>>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>>>>>>>> +
>>>>>>>>>> +    properties:
>>>>>>>>>> +      port@0:
>>>>>>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>>>>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>>>>>>>> +
>>>>>>>>>> +      port@1:
>>>>>>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>>>>>>> +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
>>>>>>>>>> +
>>>>>>>>>> +    required:
>>>>>>>>>> +      - port@0
>>>>>>>>>> +      - port@1
>>>>>>>>>> +
>>>>>>>>>> +required:
>>>>>>>>>> +  - compatible
>>>>>>>>>> +  - reg
>>>>>>>>>> +  - interrupts
>>>>>>>>>> +  - ports
>>>>>>>>>> +
>>>>>>>>>> +additionalProperties: false
>>>>>>>>>> +
>>>>>>>>>> +examples:
>>>>>>>>>> +  - |
>>>>>>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>>>>> +    bus {
>>>>>>>>>> +
>>>>>>>>>> +        #address-cells = <3>;
>>>>>>>>>> +        #size-cells = <2>;
>>>>>>>>>> +        #interrupt-cells = <2>;
>>>>>>>>>> +
>>>>>>>>>> +        display-controller@6,1 {
>>>>>>>>>> +            compatible = "loongson,ls7a1000-dc";
>>>>>>>>>> +            reg = <0x3100 0x0 0x0 0x0 0x0>;
>>>>>>>>>> +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>> +
>>>>>>>>>> +            #address-cells = <1>;
>>>>>>>>>> +            #size-cells = <0>;
>>>>>>>>>> +
>>>>>>>>>> +            i2c-gpio@0 {
>>>>>>>>>> +                compatible = "lsdc,i2c-gpio-0";
>>>>>>>>>> +                reg = <6>;
>>>>>>> 'reg' needs to be documented with some description of what 6 and 7
>>>>>>> represent. If they are the control register offset, then make the
>>>>>>> address translatable (use 'ranges' and define the size).
>>>>>> By design, the reg property is used to specify a I2c adapter bus number,
>>>>>> if we don't specify one, i2c driver core will dynamically assign a bus number.
>>>>>> then the nr of the i2c adapter will started from 0. I want is start from 6
>>>>>> to avoid potential conflict feature hardware I2C driver.
>>>>>>
>>>>>> Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
>>>>>> but its driver is not up-streamed yet. By default these hardware I2C controller's
>>>>>> nr is started from 0.
>>>>> Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in
>>>>> that way.
>>>> Then,  can i use something like lsdc,nr = <6> ?
>>>>>> Even through i2c driver core can dynamically generate a number, i still want it
>>>>>> to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
>>>>>> i2c7 is for display pipe 1. This follow the convention and flexible enough.
>>>>> You may want that, but that is not how the kernel works. Specific
>>>>> numbers are not guaranteed. I'm sure you've seen this for disks, network
>>>>> interfaces, etc.
>>>>>
>>>>> Rob
>>>> 2c_bit_add_numbered_bus() will guarantee it for you as long as If no devices
>>>> have pre-been declared for this bus.
>>>>
>>>> you can read the comment of 2c_bit_add_numbered_bus() at
>>>> drivers/i2c/i2c-core-base.c
>>> I didn't say it wasn't possible. It is not best practice. Grep
>>> i2c_bit_add_numbered_bus and see how many users there are.
>> i2c-gpio.c at drivers/i2c/busses/ just do the same thing.
> No, the id for i2c-gpio nodes (any DT node without 'reg') will be -1
> which means dynamically assigned.
>
>
>> + nvidia,bpmp-bus-id: + $ref: /schemas/types.yaml#/definitions/uint32 +
>> description: Indicates the I2C bus number this DT node represents, + as
>> defined by the BPMP firmware.
> The key difference is the numbering is defined by the BPMP firmware.
>
Bus numbers are a linux detail, I am not sure it is relevant to BPMP firmware.
and BPMP firmware is not relevant here.

The point is you applied that patch, you are admit the fact that bus numbers
could be in DT.

>>> Even if the kernel allows specifying bus numbers,your Linux bus numbers don't
>>> belong in DT.
>> Again, Does does devicetree specification prohibit this?
> No. The spec is not the last word on what's allowed or not. Lots of
> patterns exist already which we can't change, but that doesn't mean they
> should be copied by new users.
>
> Rob

We develop that part by our own, only find that there are someone do the 
same thing when it got push back.

We believe that it is very flexible actually, anyway if you still don't 
change you mind we can rewrite it.

I have resend my patches,  see it at 
https://patchwork.freedesktop.org/series/101843/

Please take spare time to review it if you would like, thanks you.

Re: [PATCH v11 5/7] dt-bindings: display: Add Loongson display controller

[Rob Herring]

On Tue, Mar 29, 2022 at 10:02:11AM +0800, Sui Jingfeng wrote:
> 
> On 2022/3/28 22:04, Rob Herring wrote:
> > On Sat, Mar 26, 2022 at 06:04:46PM +0800, Sui Jingfeng wrote:
> > > On 2022/3/24 21:26, Rob Herring wrote:
> > > > On Thu, Mar 24, 2022 at 09:48:19AM +0800, Sui Jingfeng wrote:
> > > > > On 2022/3/23 21:03, Rob Herring wrote:
> > > > > > On Wed, Mar 23, 2022 at 11:38:55AM +0800, Sui Jingfeng wrote:
> > > > > > > On 2022/3/23 04:55, Rob Herring wrote:
> > > > > > > > On Tue, Mar 22, 2022 at 10:33:45AM +0800, Sui Jingfeng wrote:
> > > > > > > > > On 2022/3/22 07:20, Rob Herring wrote:
> > > > > > > > > > On Tue, Mar 22, 2022 at 12:29:14AM +0800, Sui Jingfeng wrote:
> > > > > > > > > > > From: suijingfeng <suijingfeng@loongson.cn>
> > > > > > > > > > > 
> > > > > > > > > > Needs a commit message.
> > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
> > > > > > > > > > > Signed-off-by: Sui Jingfeng <15330273260@189.cn>
> > > > > > > > > > Same person? Don't need both emails.
> > > > > > > > > Yes,  suijingfeng@loongson.cn is my company's email. But it can not be used
> > > > > > > > > to send patches to dri-devel,
> > > > > > > > > 
> > > > > > > > > when send patches with this email, the patch will not be shown on patch
> > > > > > > > > works.
> > > > > > > > > 
> > > > > > > > > Emails  are either blocked or got  rejected  by loongson's mail server.  It
> > > > > > > > > can only receive emails
> > > > > > > > > 
> > > > > > > > > from you and other people, but not dri-devel. so have to use my personal
> > > > > > > > > email(15330273260@189.cn) to send patches.
> > > > > > > > > 
> > > > > > > > > > > ---
> > > > > > > > > > >       .../loongson/loongson,display-controller.yaml | 230 ++++++++++++++++++
> > > > > > > > > > >       1 file changed, 230 insertions(+)
> > > > > > > > > > >       create mode 100644 Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..7be63346289e
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/Documentation/devicetree/bindings/display/loongson/loongson,display-controller.yaml
> > > > > > > > > > > @@ -0,0 +1,230 @@
> > > > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > > > > > > +%YAML 1.2
> > > > > > > > > > > +---
> > > > > > > > > > > +$id: http://devicetree.org/schemas/display/loongson/loongson,display-controller.yaml#
> > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +title: Loongson LS7A1000/LS2K1000/LS2K0500 Display Controller Device Tree Bindings
> > > > > > > > > > > +
> > > > > > > > > > > +maintainers:
> > > > > > > > > > > +  - Sui Jingfeng <suijingfeng@loongson.cn>
> > > > > > > > > > > +
> > > > > > > > > > > +description: |+
> > > > > > > > > > > +
> > > > > > > > > > > +  Loongson display controllers are simple which require scanout buffers
> > > > > > > > > > > +  to be physically contiguous. LS2K1000/LS2K0500 is a SOC, only system
> > > > > > > > > > > +  memory is available. LS7A1000/LS7A2000 is bridge chip which is equipped
> > > > > > > > > > > +  with a dedicated video RAM which is 64MB or more, precise size can be
> > > > > > > > > > > +  read from the PCI BAR 2 of the GPU device(0x0014:0x7A15) in the bridge
> > > > > > > > > > > +  chip.
> > > > > > > > > > > +
> > > > > > > > > > > +  LSDC has two display pipes, each way has a DVO interface which provide
> > > > > > > > > > > +  RGB888 signals, vertical & horizontal synchronisations, data enable and
> > > > > > > > > > > +  the pixel clock. LSDC has two CRTC, each CRTC is able to scanout from
> > > > > > > > > > > +  1920x1080 resolution at 60Hz. Each CRTC has two FB address registers.
> > > > > > > > > > > +
> > > > > > > > > > > +  For LS7A1000, there are 4 dedicated GPIOs whose control register is
> > > > > > > > > > > +  located at the DC register space. They are used to emulate two way i2c,
> > > > > > > > > > > +  One for DVO0, another for DVO1.
> > > > > > > > > > > +
> > > > > > > > > > > +  LS2K1000 and LS2K0500 SoC grab i2c adapter from other module, either
> > > > > > > > > > > +  general purpose GPIO emulated i2c or hardware i2c in the SoC.
> > > > > > > > > > > +
> > > > > > > > > > > +  LSDC's display pipeline have several components as below description,
> > > > > > > > > > > +
> > > > > > > > > > > +  The display controller in LS7A1000:
> > > > > > > > > > > +     ___________________                                     _________
> > > > > > > > > > > +    |            -------|                                   |         |
> > > > > > > > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > > > > > > > +    |  _   _     -------|        ^             ^            |_________|
> > > > > > > > > > > +    | | | | |    -------|        |             |
> > > > > > > > > > > +    | |_| |_|    | i2c0 <--------+-------------+
> > > > > > > > > > > +    |            -------|
> > > > > > > > > > > +    |   DC IN LS7A1000  |
> > > > > > > > > > > +    |  _   _     -------|
> > > > > > > > > > > +    | | | | |    | i2c1 <--------+-------------+
> > > > > > > > > > > +    | |_| |_|    -------|        |             |             _________
> > > > > > > > > > > +    |            -------|        |             |            |         |
> > > > > > > > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > > > > > > > +    |            -------|                                   |_________|
> > > > > > > > > > > +    |___________________|
> > > > > > > > > > > +
> > > > > > > > > > > +  Simple usage of LS7A1000 with LS3A4000 CPU:
> > > > > > > > > > > +
> > > > > > > > > > > +    +------+            +-----------------------------------+
> > > > > > > > > > > +    | DDR4 |            |  +-------------------+            |
> > > > > > > > > > > +    +------+            |  | PCIe Root complex |   LS7A1000 |
> > > > > > > > > > > +       || MC0           |  +--++---------++----+            |
> > > > > > > > > > > +  +----------+  HT 3.0  |     ||         ||                 |
> > > > > > > > > > > +  | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
> > > > > > > > > > > +  |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
> > > > > > > > > > > +  +----------+          | +--------+  +-+--+-+    +---------+   +------+
> > > > > > > > > > > +       || MC1           +---------------|--|----------------+
> > > > > > > > > > > +    +------+                            |  |
> > > > > > > > > > > +    | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
> > > > > > > > > > > +    +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
> > > > > > > > > > > +                      +-------+                      +------+
> > > > > > > > > > > +
> > > > > > > > > > > +  The display controller in LS2K1000/LS2K0500:
> > > > > > > > > > > +     ___________________                                     _________
> > > > > > > > > > > +    |            -------|                                   |         |
> > > > > > > > > > > +    |  CRTC0 --> | DVO0 ----> Encoder0 ---> Connector0 ---> | Monitor |
> > > > > > > > > > > +    |  _   _     -------|        ^              ^           |_________|
> > > > > > > > > > > +    | | | | |           |        |              |
> > > > > > > > > > > +    | |_| |_|           |     +------+          |
> > > > > > > > > > > +    |                   <---->| i2c0 |<---------+
> > > > > > > > > > > +    |   DC IN LS2K1000  |     +------+
> > > > > > > > > > > +    |  _   _            |     +------+
> > > > > > > > > > > +    | | | | |           <---->| i2c1 |----------+
> > > > > > > > > > > +    | |_| |_|           |     +------+          |            _________
> > > > > > > > > > > +    |            -------|        |              |           |         |
> > > > > > > > > > > +    |  CRTC1 --> | DVO1 ----> Encoder1 ---> Connector1 ---> |  Panel  |
> > > > > > > > > > > +    |            -------|                                   |_________|
> > > > > > > > > > > +    |___________________|
> > > > > > > > > > > +
> > > > > > > > > > > +properties:
> > > > > > > > > > > +  $nodename:
> > > > > > > > > > > +    pattern: "^display-controller@[0-9a-f],[0-9a-f]$"
> > > > > > > > > > > +
> > > > > > > > > > > +  compatible:
> > > > > > > > > > > +    oneOf:
> > > > > > > > > > > +      - items:
> > > > > > > > > > > +          - enum:
> > > > > > > > > > > +              - loongson,ls7a1000-dc
> > > > > > > > > > > +              - loongson,ls2k1000-dc
> > > > > > > > > > > +              - loongson,ls2k0500-dc
> > > > > > > > > > > +
> > > > > > > > > > > +  reg:
> > > > > > > > > > > +    maxItems: 1
> > > > > > > > > > > +
> > > > > > > > > > > +  interrupts:
> > > > > > > > > > > +    maxItems: 1
> > > > > > > > > > > +
> > > > > > > > > > > +  '#address-cells':
> > > > > > > > > > > +    const: 1
> > > > > > > > > > > +
> > > > > > > > > > > +  '#size-cells':
> > > > > > > > > > > +    const: 0
> > > > > > > > > > > +
> > > > > > > > > > > +  i2c-gpio@0:
> > > > > > > > > > > +    description: |
> > > > > > > > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > > > > > > If you have i2c-gpio, that belongs at the DT top-level, not here.
> > > > > > > > > > 
> > > > > > > > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > > > > > > > +      only. Its compatible must be lsdc,i2c-gpio-0. The reg property can be
> > > > > > > > > > No, there's a defined i2c-gpio compatible already.
> > > > > > > > > This is different from the i2c-gpio already defined under drivers/i2c/busses/i2c-gpio.c,
> > > > > > > > > By design, my i2c-gpio is vendor specific properties, lsdc device driver create the i2c
> > > > > > > > > adapter at runtime. These are 4 dedicated GPIOs whose control register is located at the
> > > > > > > > > LSDC register space, not general purpose GPIOs with separate control register resource.
> > > > > > > > > So i think it is the child node of display-controller@6,1, it belongs to LSDC.
> > > > > > > > > It seems that put it at the DT top-level break the hierarchy and relationship.
> > > > > > > > Okay, I see. Then just 'i2c' for the node names. You need a reference to
> > > > > > > > i2c-controller.yaml for these nodes too.
> > > > > > > > 
> > > > > > > > The compatible should not have an index in it.
> > > > > > > OK, i will fix this at the next version. thanks.
> > > > > > > > > > > +      used to specify a I2c adapter bus number, if you don't specify one
> > > > > > > > > > > +      i2c driver core will dynamically assign a bus number. Please specify
> > > > > > > > > > Bus numbers are a linux detail not relevant to DT binding.
> > > > > > > > > > 
> > > > > > > > > > > +      it only when its bus number matters. Bus number greater than 6 is safe
> > > > > > > > > > > +      because ls7a1000 bridge have 6 hardware I2C controller integrated.
> > > > > > > > > > > +
> > > > > > > > > > > +  i2c-gpio@1:
> > > > > > > > > > > +    description: |
> > > > > > > > > > > +      Built-in GPIO emulate i2c exported for external display bridge
> > > > > > > > > > > +      configuration, onitor detection and edid read back etc, for ls7a1000
> > > > > > > > > > > +      only. Its compatible must be lsdc,i2c-gpio-1.
> > > > > > > > > > > +
> > > > > > > > > > > +  ports:
> > > > > > > > > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > > > > > > > > +
> > > > > > > > > > > +    properties:
> > > > > > > > > > > +      port@0:
> > > > > > > > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > > > > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > > > > > > > +
> > > > > > > > > > > +      port@1:
> > > > > > > > > > > +        $ref: /schemas/graph.yaml#/properties/port
> > > > > > > > > > > +        description: output port node connected with DPI panels or external encoders, with only one endpoint.
> > > > > > > > > > > +
> > > > > > > > > > > +    required:
> > > > > > > > > > > +      - port@0
> > > > > > > > > > > +      - port@1
> > > > > > > > > > > +
> > > > > > > > > > > +required:
> > > > > > > > > > > +  - compatible
> > > > > > > > > > > +  - reg
> > > > > > > > > > > +  - interrupts
> > > > > > > > > > > +  - ports
> > > > > > > > > > > +
> > > > > > > > > > > +additionalProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +examples:
> > > > > > > > > > > +  - |
> > > > > > > > > > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > > > > > > > > > +    bus {
> > > > > > > > > > > +
> > > > > > > > > > > +        #address-cells = <3>;
> > > > > > > > > > > +        #size-cells = <2>;
> > > > > > > > > > > +        #interrupt-cells = <2>;
> > > > > > > > > > > +
> > > > > > > > > > > +        display-controller@6,1 {
> > > > > > > > > > > +            compatible = "loongson,ls7a1000-dc";
> > > > > > > > > > > +            reg = <0x3100 0x0 0x0 0x0 0x0>;
> > > > > > > > > > > +            interrupts = <28 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > > > > > > +
> > > > > > > > > > > +            #address-cells = <1>;
> > > > > > > > > > > +            #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > +            i2c-gpio@0 {
> > > > > > > > > > > +                compatible = "lsdc,i2c-gpio-0";
> > > > > > > > > > > +                reg = <6>;
> > > > > > > > 'reg' needs to be documented with some description of what 6 and 7
> > > > > > > > represent. If they are the control register offset, then make the
> > > > > > > > address translatable (use 'ranges' and define the size).
> > > > > > > By design, the reg property is used to specify a I2c adapter bus number,
> > > > > > > if we don't specify one, i2c driver core will dynamically assign a bus number.
> > > > > > > then the nr of the i2c adapter will started from 0. I want is start from 6
> > > > > > > to avoid potential conflict feature hardware I2C driver.
> > > > > > > 
> > > > > > > Because LS7A1000 bridge chip have 6 hardware I2C controller integrated,
> > > > > > > but its driver is not up-streamed yet. By default these hardware I2C controller's
> > > > > > > nr is started from 0.
> > > > > > Linux's numbering doesn't belong in DT. So no, you can't use 'reg' in
> > > > > > that way.
> > > > > Then,  can i use something like lsdc,nr = <6> ?
> > > > > > > Even through i2c driver core can dynamically generate a number, i still want it
> > > > > > > to be fixed and keep consistent and explicit. That is, i2c6 is for display pipe 0,
> > > > > > > i2c7 is for display pipe 1. This follow the convention and flexible enough.
> > > > > > You may want that, but that is not how the kernel works. Specific
> > > > > > numbers are not guaranteed. I'm sure you've seen this for disks, network
> > > > > > interfaces, etc.
> > > > > > 
> > > > > > Rob
> > > > > 2c_bit_add_numbered_bus() will guarantee it for you as long as If no devices
> > > > > have pre-been declared for this bus.
> > > > > 
> > > > > you can read the comment of 2c_bit_add_numbered_bus() at
> > > > > drivers/i2c/i2c-core-base.c
> > > > I didn't say it wasn't possible. It is not best practice. Grep
> > > > i2c_bit_add_numbered_bus and see how many users there are.
> > > i2c-gpio.c at drivers/i2c/busses/ just do the same thing.
> > No, the id for i2c-gpio nodes (any DT node without 'reg') will be -1
> > which means dynamically assigned.
> > 
> > 
> > > + nvidia,bpmp-bus-id: + $ref: /schemas/types.yaml#/definitions/uint32 +
> > > description: Indicates the I2C bus number this DT node represents, + as
> > > defined by the BPMP firmware.
> > The key difference is the numbering is defined by the BPMP firmware.
> > 
> Bus numbers are a linux detail, I am not sure it is relevant to BPMP firmware.
> and BPMP firmware is not relevant here.
> 

Read the review of it[1]. The key part is this:

> +The BPMP firmware defines no single global name-/numbering-space for such
> +services. Put another way, the numbering scheme for I2C buses is distinct from
> +the numbering scheme for any other service the BPMP may provide (e.g. a future
> +hypothetical SPI bus service). As such, child device nodes will have no reg
> +property, and the BPMP node will have no #address-cells or #size-cells property.

> My understanding is that the I2C bus number is passed as part of the
> request to the BPMP firmware. Does that not count as addressing? Could
> we not represent that generically using a device tree hierarchy? I'm
> thinking something along these lines:


The bus numbers are NOT defined by Linux nor defined in the DT.

> The point is you applied that patch, you are admit the fact that bus numbers
> could be in DT.

That actually is not an argument for your patch. There are lots of 
things we accepted in the past that now will be rejected. This case 
however is not something that changed. You may still find examples as 
bindings didn't always get reviewed (very well).


> > > > Even if the kernel allows specifying bus numbers,your Linux bus numbers don't
> > > > belong in DT.
> > > Again, Does does devicetree specification prohibit this?
> > No. The spec is not the last word on what's allowed or not. Lots of
> > patterns exist already which we can't change, but that doesn't mean they
> > should be copied by new users.
> > 
> > Rob
> 
> We develop that part by our own, only find that there are someone do the
> same thing when it got push back.
> 
> We believe that it is very flexible actually, anyway if you still don't
> change you mind we can rewrite it.
> 
> I have resend my patches,  see it at
> https://patchwork.freedesktop.org/series/101843/

Don't send new versions when the discussion on the prior one is ongoing. 
Though in this case there is nothing more to discuss.

Rob

[1] https://lore.kernel.org/all/20160726100302.GE2433@ulmo.ba.sec/

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui Jingfeng]

On 2022/3/23 21:11, Rob Herring wrote:
> On Wed, Mar 23, 2022 at 12:12:43PM +0800, Sui Jingfeng wrote:
>> On 2022/3/23 04:49, Rob Herring wrote:
>>>> +/*
>>>> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
>>>> + *
>>>> + * @index : output channel index, 0 for DVO0, 1 for DVO1
>>>> + */
>>>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
>>>> +{
>>>> +	char compat[32] = {0};
>>>> +	unsigned int udelay = 5;
>>>> +	unsigned int timeout = 2200;
>>>> +	int nr = -1;
>>>> +	struct i2c_adapter *adapter;
>>>> +	struct lsdc_i2c *li2c;
>>>> +	struct device_node *i2c_np;
>>>> +	int ret;
>>>> +
>>>> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
>>>> +	if (!li2c)
>>>> +		return ERR_PTR(-ENOMEM);
>>>> +
>>>> +	li2c->index = index;
>>>> +	li2c->dev = dev;
>>>> +
>>>> +	if (index == 0) {
>>>> +		li2c->sda = 0x01;
>>>> +		li2c->scl = 0x02;
>>>> +	} else if (index == 1) {
>>>> +		li2c->sda = 0x04;
>>>> +		li2c->scl = 0x08;
>>> Just require this to be in DT rather than having some default.
>>>
>> By design,  I am try very hard to let the code NOT fully  DT dependent. DT is nice , easy to learn and use.
>> But kernel side developer plan to follow UEFI + ACPI Specification on LS3A5000 + LS7A1000 platform. See [1]
>> There will no DT support then, provide a convention support  make the driver more flexible. I want the
>> driver works with minimal requirement. The driver just works on simple boards by put the following dc device
>> node in arch/mips/dts/loongson/loongson64g_4core_ls7a.dts,
> Pick DT or ACPI for the platform, not both. We don't need to have both
> in the kernel to support.
>
> Rob

Hi, everybody

I have send new version of my patch,  there may still have flaws though.

Would you like to help to review it again?

https://patchwork.freedesktop.org/series/102104/

@Rob @Maxime  @Krzysztof

I have  correct many issues as you guys mentioned  before,

if something get ignored and I may miss the point,  would like to 
mention it again

on my new patches?  because mails received previously got lost(flushed 
by new mails).

I can only reply to new reviews.

Thanks for your time.

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[Sui jingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
> On Tue, Mar 22, 2022 at 12:29:16AM +0800, Sui Jingfeng wrote:
>> From: suijingfeng <suijingfeng@loongson.cn>
>>
>> There is a display controller in loongson's LS2K1000 SoC and LS7A1000
>> bridge chip, the display controller is a PCI device in those chips. It
>> has two display pipes but with only one hardware cursor. Each way has
>> a DVO interface which provide RGB888 signals, vertical & horizontal
>> synchronisations, data enable and the pixel clock. Each CRTC is able to
>> scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
>> 2048x2048 according to the hardware spec. Loongson display controllers
>> are simple which require scanout buffers to be physically contiguous.
>>
>> For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
>> which is typically 64MB or more. In this case, VRAM helper based driver
>> is intend to be used. While LS2K1000 is a SoC, only system memory is
>> available. Therefore CMA helper based driver is intend to be used. It is
>> possible to use VRAM helper based solution by carving out part of system
>> memory as VRAM though.
>>
>> For LS7A1000, there are 4 dedicated GPIOs whose control register is
>> located at the DC register space, They are used to emulate two way i2c.
>> One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
>> GPIO hardwared, they grab i2c adapter from other module, either general
>> purpose GPIO emulated i2c or hardware i2c adapter.
>>
>>      +------+            +-----------------------------------+
>>      | DDR4 |            |  +-------------------+            |
>>      +------+            |  | PCIe Root complex |   LS7A1000 |
>>         || MC0           |  +--++---------++----+            |
>>    +----------+  HT 3.0  |     ||         ||                 |
>>    | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>    |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>    +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>         || MC1           +---------------|--|----------------+
>>      +------+                            |  |
>>      | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>      +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>                        +-------+                      +------+
>>
>> The above picture give a simple usage of LS7A1000, note that the encoder
>> is not necessary adv7125 or tfp410, other candicates can be ch7034b,
>> sil9022, ite66121 and lt8618 etc.
>>
>> v2: Fixup warnings reported by kernel test robot
>>
>> v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
>>      more details about lsdc.
>>
>> v4:
>>     1) Add dts required and explain why device tree is required.
>>     2) Give more description about lsdc and VRAM helper based driver.
>>     3) Fix warnings reported by kernel test robot.
>>     4) Introduce stride_alignment member into struct lsdc_chip_desc, the
>>        stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.
>>
>> v5:
>>     1) Using writel and readl replace writeq and readq, to fix kernel test
>>        robot report build error on other archtecture.
>>     2) Set default fb format to XRGB8888 at crtc reset time.
>>
>> v6:
>>     1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
>>     2) Explain why tiny drm driver is not suitable for us.
>>     3) Give a short description of the trival dirty uppdate implement based
>>        on CMA helper.
>>
>> v7:
>>     1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
>>     2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
>>     3) Remove lsdc_pixpll_print(), part of it move to debugfs.
>>     4) Set prefer_shadow to true if vram based driver is in using.
>>     5) Replace double blank lines with single line in all files.
>>     6) Verbose cmd line parameter is replaced with drm_dbg()
>>     7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
>>     8) Get edid from dtb support is removed as suggested by Maxime Ripard
>>     9) Fix typos and various improvement
>>
>> v8:
>>     1) Drop damage update implement and its command line.
>>     2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
>>     3) Deduce DC's identification from its compatible property.
>>     4) Drop the board specific dts patch.
>>     5) Add documention about the display controller device node.
>>
>> v9:
>>     1) Fix the warnings reported by checkpatch script and fix typos
>>
>> v10:
>>     1) Pass `make dt_binding_check` validation
>>     2) Fix warnings reported by kernel test robot
>>
>> v11:
>>     1) Convert the driver to use drm bridge and of graph framework.
>>     2) Dump register value support through debugfs.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> ---
>>   drivers/gpu/drm/Kconfig             |   2 +
>>   drivers/gpu/drm/Makefile            |   1 +
>>   drivers/gpu/drm/lsdc/Kconfig        |  23 ++
>>   drivers/gpu/drm/lsdc/Makefile       |  13 +
>>   drivers/gpu/drm/lsdc/lsdc_crtc.c    | 396 +++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_drv.c     | 547 ++++++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_drv.h     | 197 ++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_i2c.c     | 235 ++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_i2c.h     |  42 ++
>>   drivers/gpu/drm/lsdc/lsdc_irq.c     |  58 +++
>>   drivers/gpu/drm/lsdc/lsdc_irq.h     |  18 +
>>   drivers/gpu/drm/lsdc/lsdc_output.c  | 262 +++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_output.h  |  24 ++
>>   drivers/gpu/drm/lsdc/lsdc_pci_drv.c | 328 ++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_plane.c   | 470 +++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_pll.c     | 574 ++++++++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_pll.h     |  88 +++++
>>   drivers/gpu/drm/lsdc/lsdc_regs.h    | 220 +++++++++++
>>   18 files changed, 3498 insertions(+)
>>   create mode 100644 drivers/gpu/drm/lsdc/Kconfig
>>   create mode 100644 drivers/gpu/drm/lsdc/Makefile
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pci_drv.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h
> [...]
>
>> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.c b/drivers/gpu/drm/lsdc/lsdc_i2c.c
>> new file mode 100644
>> index 000000000000..55beed9266fa
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.c
>> @@ -0,0 +1,235 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * KMS driver for Loongson display controller
> Not really a useful comment since every file has the same one.
>
>> + * Copyright (C) 2022 Loongson Corporation
>> + */
>> +
>> +/*
>> + * Authors:
>> + *      Sui Jingfeng <suijingfeng@loongson.cn>
>> + */
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/pci.h>
>> +
>> +#include "lsdc_drv.h"
>> +#include "lsdc_regs.h"
>> +#include "lsdc_i2c.h"
>> +
>> +/*
>> + * ls7a_gpio_i2c_set - set the state of a gpio pin indicated by mask
>> + * @mask: gpio pin mask
>> + */
>> +static void ls7a_gpio_i2c_set(struct lsdc_i2c * const li2c, int mask, int state)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
> What are you protecting? Doesn't the caller serialize calls to these
> functions?

Hi,  there are some old ls7a1000 bridge chip product still in use at 
china market,

The display controller in old ls7a1000 bridge chip does not support 
concurrent  register access properly,

when two or more threads writing the dc registers at the same time, the  
ls7a1000 bridge chip will hung.

But the hung only happen at low occurrence, wrap register access with 
spin lock is more stable in practice

for old ls7a1000 bridge chip.

>> +
>> +	if (state) {
>> +		val = readb(li2c->dir_reg);
>> +		val |= mask;
>> +		writeb(val, li2c->dir_reg);
>> +	} else {
>> +		val = readb(li2c->dir_reg);
>> +		val &= ~mask;
>> +		writeb(val, li2c->dir_reg);
>> +
>> +		val = readb(li2c->dat_reg);
>> +		if (state)
> This condition is never true. We're in the 'else' because !state.
>
>> +			val |= mask;
>> +		else
>> +			val &= ~mask;
>> +		writeb(val, li2c->dat_reg);
> Shouldn't you set the data register low first and then change the
> direction? Otherwise, you may be driving high for a moment. However, if
> high is always done by setting the direction as input, why write the
> data register each time? I'm assuming whatever is written to the dat_reg
> is maintained regardless of pin state.
>
>> +	}
>> +
>> +	spin_unlock_irqrestore(&li2c->reglock, flags);
>> +}
>> +
>> +/*
>> + * ls7a_gpio_i2c_get - read value back from gpio pin
>> + * @mask: gpio pin mask
>> + */
>> +static int ls7a_gpio_i2c_get(struct lsdc_i2c * const li2c, int mask)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
>> +
>> +	/* first set this pin as input */
>> +	val = readb(li2c->dir_reg);
>> +	val |= mask;
>> +	writeb(val, li2c->dir_reg);
>> +
>> +	/* then get level state from this pin */
>> +	val = readb(li2c->dat_reg);
>> +
>> +	spin_unlock_irqrestore(&li2c->reglock, flags);
>> +
>> +	return (val & mask) ? 1 : 0;
>> +}
>> +
>> +/* set the state on the i2c->sda pin */
>> +static void ls7a_i2c_set_sda(void *i2c, int state)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_set(li2c, li2c->sda, state);
>> +}
>> +
>> +/* set the state on the i2c->scl pin */
>> +static void ls7a_i2c_set_scl(void *i2c, int state)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_set(li2c, li2c->scl, state);
>> +}
>> +
>> +/* read the value from the i2c->sda pin */
>> +static int ls7a_i2c_get_sda(void *i2c)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_get(li2c, li2c->sda);
>> +}
>> +
>> +/* read the value from the i2c->scl pin */
>> +static int ls7a_i2c_get_scl(void *i2c)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_get(li2c, li2c->scl);
>> +}
>> +
>> +/*
>> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
>> + *
>> + * @index : output channel index, 0 for DVO0, 1 for DVO1
>> + */
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
>> +{
>> +	char compat[32] = {0};
>> +	unsigned int udelay = 5;
>> +	unsigned int timeout = 2200;
>> +	int nr = -1;
>> +	struct i2c_adapter *adapter;
>> +	struct lsdc_i2c *li2c;
>> +	struct device_node *i2c_np;
>> +	int ret;
>> +
>> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
>> +	if (!li2c)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	li2c->index = index;
>> +	li2c->dev = dev;
>> +
>> +	if (index == 0) {
>> +		li2c->sda = 0x01;
>> +		li2c->scl = 0x02;
>> +	} else if (index == 1) {
>> +		li2c->sda = 0x04;
>> +		li2c->scl = 0x08;
> Just require this to be in DT rather than having some default.
>
>> +	}
>> +
>> +	spin_lock_init(&li2c->reglock);
>> +
>> +	snprintf(compat, sizeof(compat), "lsdc,i2c-gpio-%d", index);
> compatible values shouldn't have an index and you shouldn't need a
> index in DT. You need to iterate over child nodes with matching
> compatible.
>
>> +	i2c_np = of_find_compatible_node(dev->of_node, NULL, compat);
>> +	if (i2c_np) {
>> +		u32 sda, scl;
>> +
>> +		dev_dbg(dev, "Has %s property in the DT", compat);
>> +
>> +		/*  */
>> +		ret = of_property_read_u32(i2c_np, "sda", &sda);
> Custom properties need a vendor prefix.
>
>> +		if (ret == 0)
>> +			li2c->sda = 1 << sda;
>> +
>> +		ret = of_property_read_u32(i2c_np, "scl", &scl);
>> +		if (ret == 0)
>> +			li2c->scl = 1 << scl;
>> +
>> +		/* Optional properties which made the driver more flexible */
>> +		of_property_read_u32(i2c_np, "udelay", &udelay);
>> +		of_property_read_u32(i2c_np, "timeout", &timeout);
> These aren't documented. Do you really need them in DT?
>
>> +		of_property_read_u32(i2c_np, "reg", &nr);
>> +	}
>> +
>> +	dev_dbg(dev, "%s: sda=%u, scl=%u, nr=%d, udelay=%u, timeout=%u\n",
>> +		compat, li2c->sda, li2c->scl, nr, udelay, timeout);
>> +
>> +	li2c->reg_base = base;
>> +
>> +	li2c->dir_reg = li2c->reg_base + LS7A_DC_GPIO_DIR_REG;
>> +	li2c->dat_reg = li2c->reg_base + LS7A_DC_GPIO_DAT_REG;
>> +
>> +	li2c->bit.setsda = ls7a_i2c_set_sda;
>> +	li2c->bit.setscl = ls7a_i2c_set_scl;
>> +	li2c->bit.getsda = ls7a_i2c_get_sda;
>> +	li2c->bit.getscl = ls7a_i2c_get_scl;
>> +	li2c->bit.udelay = udelay;
>> +	li2c->bit.timeout = usecs_to_jiffies(timeout);
>> +	li2c->bit.data = li2c;
>> +
>> +	adapter = &li2c->adapter;
>> +	adapter->algo_data = &li2c->bit;
>> +	adapter->owner = THIS_MODULE;
>> +	adapter->class = I2C_CLASS_DDC;
>> +	adapter->dev.parent = dev;
>> +	adapter->nr = nr;
>> +	if (i2c_np) {
>> +		adapter->dev.of_node = i2c_np;
>> +		of_node_put(i2c_np);
>> +	}
>> +
>> +	strscpy(adapter->name, &compat[5], sizeof(adapter->name));
>> +
>> +	i2c_set_adapdata(adapter, li2c);
>> +
>> +	ret = i2c_bit_add_numbered_bus(adapter);
> Why do you care what the bus number is? You shouldn't need to.
>
>> +	if (ret) {
>> +		if (i2c_np)
>> +			of_node_put(i2c_np);
>> +
>> +		devm_kfree(dev, li2c);
>> +		return ERR_PTR(ret);
>> +	}
>> +
>> +	return li2c;
>> +}
>> +
>> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c)
>> +{
>> +	struct i2c_adapter *adapter;
>> +
>> +	if (li2c) {
>> +		adapter = &li2c->adapter;
>> +
>> +		if (adapter && adapter->dev.of_node)
>> +			of_node_put(adapter->dev.of_node);
>> +
>> +		devm_kfree(ddev->dev, li2c);
>> +	}
>> +}
>> +
>> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
>> +					 unsigned int index)
>> +{
>> +	const struct lsdc_chip_desc * const descp = ldev->desc;
>> +	struct lsdc_i2c *li2c;
>> +
>> +	if (index >= descp->num_of_crtc) {
>> +		drm_err(ldev->ddev, "I2c adapter is no more than %u, %u\n",
>> +			descp->num_of_crtc, index);
>> +		return NULL;
>> +	}
>> +
>> +	li2c = ldev->li2c[index];
>> +	if (li2c)
>> +		return &li2c->adapter;
>> +
>> +	return NULL;
>> +}
>> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.h b/drivers/gpu/drm/lsdc/lsdc_i2c.h
>> new file mode 100644
>> index 000000000000..4ab825143eb4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.h
>> @@ -0,0 +1,42 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * KMS driver for Loongson display controller
>> + * Copyright (C) 2022 Loongson Corporation
>> + */
>> +
>> +/*
>> + * Authors:
>> + *      Sui Jingfeng <suijingfeng@loongson.cn>
>> + */
>> +
>> +#ifndef __LSDC_I2C__
>> +#define __LSDC_I2C__
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/i2c-algo-bit.h>
>> +#include <linux/pci.h>
>> +
>> +struct lsdc_i2c {
>> +	struct device *dev;
>> +	struct i2c_adapter adapter;
>> +	struct i2c_algo_bit_data bit;
>> +	/* @reglock: protects concurrent register access */
>> +	spinlock_t reglock;
>> +	void __iomem *reg_base;
>> +	void __iomem *dir_reg;
>> +	void __iomem *dat_reg;
>> +	int index;
>> +	/* pin bit mask */
>> +	u8 sda;
>> +	u8 scl;
>> +};
>> +
>> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c);
>> +
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev,
>> +				      void *base,
>> +				      unsigned int index);
>> +
>> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
>> +					 unsigned int index);
>> +#endif

Re: [PATCH v11 7/7] drm/lsdc: add drm driver for loongson display controller

[suijingfeng]

On 2022/3/23 04:49, Rob Herring wrote:
> On Tue, Mar 22, 2022 at 12:29:16AM +0800, Sui Jingfeng wrote:
>> From: suijingfeng <suijingfeng@loongson.cn>
>>
>> There is a display controller in loongson's LS2K1000 SoC and LS7A1000
>> bridge chip, the display controller is a PCI device in those chips. It
>> has two display pipes but with only one hardware cursor. Each way has
>> a DVO interface which provide RGB888 signals, vertical & horizontal
>> synchronisations, data enable and the pixel clock. Each CRTC is able to
>> scanout from 1920x1080 resolution at 60Hz, the maxmium resolution is
>> 2048x2048 according to the hardware spec. Loongson display controllers
>> are simple which require scanout buffers to be physically contiguous.
>>
>> For LS7A1000 bridge chip, the DC is equipped with a dedicated video RAM
>> which is typically 64MB or more. In this case, VRAM helper based driver
>> is intend to be used. While LS2K1000 is a SoC, only system memory is
>> available. Therefore CMA helper based driver is intend to be used. It is
>> possible to use VRAM helper based solution by carving out part of system
>> memory as VRAM though.
>>
>> For LS7A1000, there are 4 dedicated GPIOs whose control register is
>> located at the DC register space, They are used to emulate two way i2c.
>> One for DVO0, another for DVO1. LS2K1000 and LS2K0500 SoC don't have such
>> GPIO hardwared, they grab i2c adapter from other module, either general
>> purpose GPIO emulated i2c or hardware i2c adapter.
>>
>>      +------+            +-----------------------------------+
>>      | DDR4 |            |  +-------------------+            |
>>      +------+            |  | PCIe Root complex |   LS7A1000 |
>>         || MC0           |  +--++---------++----+            |
>>    +----------+  HT 3.0  |     ||         ||                 |
>>    | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>    |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>    +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>         || MC1           +---------------|--|----------------+
>>      +------+                            |  |
>>      | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>      +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>                        +-------+                      +------+
>>
>> The above picture give a simple usage of LS7A1000, note that the encoder
>> is not necessary adv7125 or tfp410, other candicates can be ch7034b,
>> sil9022, ite66121 and lt8618 etc.
>>
>> v2: Fixup warnings reported by kernel test robot
>>
>> v3: Fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
>>      more details about lsdc.
>>
>> v4:
>>     1) Add dts required and explain why device tree is required.
>>     2) Give more description about lsdc and VRAM helper based driver.
>>     3) Fix warnings reported by kernel test robot.
>>     4) Introduce stride_alignment member into struct lsdc_chip_desc, the
>>        stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.
>>
>> v5:
>>     1) Using writel and readl replace writeq and readq, to fix kernel test
>>        robot report build error on other archtecture.
>>     2) Set default fb format to XRGB8888 at crtc reset time.
>>
>> v6:
>>     1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
>>     2) Explain why tiny drm driver is not suitable for us.
>>     3) Give a short description of the trival dirty uppdate implement based
>>        on CMA helper.
>>
>> v7:
>>     1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
>>     2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
>>     3) Remove lsdc_pixpll_print(), part of it move to debugfs.
>>     4) Set prefer_shadow to true if vram based driver is in using.
>>     5) Replace double blank lines with single line in all files.
>>     6) Verbose cmd line parameter is replaced with drm_dbg()
>>     7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
>>     8) Get edid from dtb support is removed as suggested by Maxime Ripard
>>     9) Fix typos and various improvement
>>
>> v8:
>>     1) Drop damage update implement and its command line.
>>     2) Drop DRM_LSDC_VRAM_DRIVER config option as suggested by Maxime.
>>     3) Deduce DC's identification from its compatible property.
>>     4) Drop the board specific dts patch.
>>     5) Add documention about the display controller device node.
>>
>> v9:
>>     1) Fix the warnings reported by checkpatch script and fix typos
>>
>> v10:
>>     1) Pass `make dt_binding_check` validation
>>     2) Fix warnings reported by kernel test robot
>>
>> v11:
>>     1) Convert the driver to use drm bridge and of graph framework.
>>     2) Dump register value support through debugfs.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> Signed-off-by: Sui Jingfeng <15330273260@189.cn>
>> Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
>> ---
>>   drivers/gpu/drm/Kconfig             |   2 +
>>   drivers/gpu/drm/Makefile            |   1 +
>>   drivers/gpu/drm/lsdc/Kconfig        |  23 ++
>>   drivers/gpu/drm/lsdc/Makefile       |  13 +
>>   drivers/gpu/drm/lsdc/lsdc_crtc.c    | 396 +++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_drv.c     | 547 ++++++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_drv.h     | 197 ++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_i2c.c     | 235 ++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_i2c.h     |  42 ++
>>   drivers/gpu/drm/lsdc/lsdc_irq.c     |  58 +++
>>   drivers/gpu/drm/lsdc/lsdc_irq.h     |  18 +
>>   drivers/gpu/drm/lsdc/lsdc_output.c  | 262 +++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_output.h  |  24 ++
>>   drivers/gpu/drm/lsdc/lsdc_pci_drv.c | 328 ++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_plane.c   | 470 +++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_pll.c     | 574 ++++++++++++++++++++++++++++
>>   drivers/gpu/drm/lsdc/lsdc_pll.h     |  88 +++++
>>   drivers/gpu/drm/lsdc/lsdc_regs.h    | 220 +++++++++++
>>   18 files changed, 3498 insertions(+)
>>   create mode 100644 drivers/gpu/drm/lsdc/Kconfig
>>   create mode 100644 drivers/gpu/drm/lsdc/Makefile
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_output.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pci_drv.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h
>>   create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h
> [...]
>
>> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.c b/drivers/gpu/drm/lsdc/lsdc_i2c.c
>> new file mode 100644
>> index 000000000000..55beed9266fa
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.c
>> @@ -0,0 +1,235 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * KMS driver for Loongson display controller
> Not really a useful comment since every file has the same one.
>
>> + * Copyright (C) 2022 Loongson Corporation
>> + */
>> +
>> +/*
>> + * Authors:
>> + *      Sui Jingfeng <suijingfeng@loongson.cn>
>> + */
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/pci.h>
>> +
>> +#include "lsdc_drv.h"
>> +#include "lsdc_regs.h"
>> +#include "lsdc_i2c.h"
>> +
>> +/*
>> + * ls7a_gpio_i2c_set - set the state of a gpio pin indicated by mask
>> + * @mask: gpio pin mask
>> + */
>> +static void ls7a_gpio_i2c_set(struct lsdc_i2c * const li2c, int mask, int state)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
> What are you protecting? Doesn't the caller serialize calls to these
> functions?
>
>> +
>> +	if (state) {
>> +		val = readb(li2c->dir_reg);
>> +		val |= mask;
>> +		writeb(val, li2c->dir_reg);
>> +	} else {
>> +		val = readb(li2c->dir_reg);
>> +		val &= ~mask;
>> +		writeb(val, li2c->dir_reg);
>> +
>> +		val = readb(li2c->dat_reg);
>> +		if (state)
> This condition is never true. We're in the 'else' because !state.
>
>> +			val |= mask;
>> +		else
>> +			val &= ~mask;
>> +		writeb(val, li2c->dat_reg);
> Shouldn't you set the data register low first and then change the
> direction? Otherwise, you may be driving high for a moment. However, if
> high is always done by setting the direction as input,

Setting the direction as input will get high, because the external
pull-up resistor will pull the level up.

> why write the
> data register each time? I'm assuming whatever is written to the dat_reg
> is maintained regardless of pin state.
>
Because we have only one data reg corresponding two direction(input and 
output).

our DC hardware design engineer is not good. :(

Value written to the dat_reg will get flushed when pin state changed.

Changed from output to input, for example. Otherwise, how can we read the pin level state back?

>> +	}
>> +
>> +	spin_unlock_irqrestore(&li2c->reglock, flags);
>> +}
>> +
>> +/*
>> + * ls7a_gpio_i2c_get - read value back from gpio pin
>> + * @mask: gpio pin mask
>> + */
>> +static int ls7a_gpio_i2c_get(struct lsdc_i2c * const li2c, int mask)
>> +{
>> +	unsigned long flags;
>> +	u8 val;
>> +
>> +	spin_lock_irqsave(&li2c->reglock, flags);
>> +
>> +	/* first set this pin as input */
>> +	val = readb(li2c->dir_reg);
>> +	val |= mask;
>> +	writeb(val, li2c->dir_reg);
>> +
>> +	/* then get level state from this pin */
>> +	val = readb(li2c->dat_reg);
>> +
>> +	spin_unlock_irqrestore(&li2c->reglock, flags);
>> +
>> +	return (val & mask) ? 1 : 0;
>> +}
>> +
>> +/* set the state on the i2c->sda pin */
>> +static void ls7a_i2c_set_sda(void *i2c, int state)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_set(li2c, li2c->sda, state);
>> +}
>> +
>> +/* set the state on the i2c->scl pin */
>> +static void ls7a_i2c_set_scl(void *i2c, int state)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_set(li2c, li2c->scl, state);
>> +}
>> +
>> +/* read the value from the i2c->sda pin */
>> +static int ls7a_i2c_get_sda(void *i2c)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_get(li2c, li2c->sda);
>> +}
>> +
>> +/* read the value from the i2c->scl pin */
>> +static int ls7a_i2c_get_scl(void *i2c)
>> +{
>> +	struct lsdc_i2c * const li2c = (struct lsdc_i2c *)i2c;
>> +
>> +	return ls7a_gpio_i2c_get(li2c, li2c->scl);
>> +}
>> +
>> +/*
>> + * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
>> + *
>> + * @index : output channel index, 0 for DVO0, 1 for DVO1
>> + */
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
>> +{
>> +	char compat[32] = {0};
>> +	unsigned int udelay = 5;
>> +	unsigned int timeout = 2200;
>> +	int nr = -1;
>> +	struct i2c_adapter *adapter;
>> +	struct lsdc_i2c *li2c;
>> +	struct device_node *i2c_np;
>> +	int ret;
>> +
>> +	li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
>> +	if (!li2c)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	li2c->index = index;
>> +	li2c->dev = dev;
>> +
>> +	if (index == 0) {
>> +		li2c->sda = 0x01;
>> +		li2c->scl = 0x02;
>> +	} else if (index == 1) {
>> +		li2c->sda = 0x04;
>> +		li2c->scl = 0x08;
> Just require this to be in DT rather than having some default.
>
If only this driver  be used in embedded environment(like arms and 
risc-v), relay on DT solely is the right way.

But Loongson display controller have been applied in both PC class 
desktop(using UEFI+ACPI) and  embedded environment(using DT),  this is 
the key difference. I suddenly realize that  i didn't explain this fact 
clearly at that time.

The default code works in almost 99% case, through.

>> +	}
>> +
>> +	spin_lock_init(&li2c->reglock);
>> +
>> +	snprintf(compat, sizeof(compat), "lsdc,i2c-gpio-%d", index);
> compatible values shouldn't have an index and you shouldn't need a
> index in DT. You need to iterate over child nodes with matching
> compatible.
>
>> +	i2c_np = of_find_compatible_node(dev->of_node, NULL, compat);
>> +	if (i2c_np) {
>> +		u32 sda, scl;
>> +
>> +		dev_dbg(dev, "Has %s property in the DT", compat);
>> +
>> +		/*  */
>> +		ret = of_property_read_u32(i2c_np, "sda", &sda);
> Custom properties need a vendor prefix.
>
>> +		if (ret == 0)
>> +			li2c->sda = 1 << sda;
>> +
>> +		ret = of_property_read_u32(i2c_np, "scl", &scl);
>> +		if (ret == 0)
>> +			li2c->scl = 1 << scl;
>> +
>> +		/* Optional properties which made the driver more flexible */
>> +		of_property_read_u32(i2c_np, "udelay", &udelay);
>> +		of_property_read_u32(i2c_np, "timeout", &timeout);
> These aren't documented. Do you really need them in DT?
>
>> +		of_property_read_u32(i2c_np, "reg", &nr);
>> +	}
>> +
>> +	dev_dbg(dev, "%s: sda=%u, scl=%u, nr=%d, udelay=%u, timeout=%u\n",
>> +		compat, li2c->sda, li2c->scl, nr, udelay, timeout);
>> +
>> +	li2c->reg_base = base;
>> +
>> +	li2c->dir_reg = li2c->reg_base + LS7A_DC_GPIO_DIR_REG;
>> +	li2c->dat_reg = li2c->reg_base + LS7A_DC_GPIO_DAT_REG;
>> +
>> +	li2c->bit.setsda = ls7a_i2c_set_sda;
>> +	li2c->bit.setscl = ls7a_i2c_set_scl;
>> +	li2c->bit.getsda = ls7a_i2c_get_sda;
>> +	li2c->bit.getscl = ls7a_i2c_get_scl;
>> +	li2c->bit.udelay = udelay;
>> +	li2c->bit.timeout = usecs_to_jiffies(timeout);
>> +	li2c->bit.data = li2c;
>> +
>> +	adapter = &li2c->adapter;
>> +	adapter->algo_data = &li2c->bit;
>> +	adapter->owner = THIS_MODULE;
>> +	adapter->class = I2C_CLASS_DDC;
>> +	adapter->dev.parent = dev;
>> +	adapter->nr = nr;
>> +	if (i2c_np) {
>> +		adapter->dev.of_node = i2c_np;
>> +		of_node_put(i2c_np);
>> +	}
>> +
>> +	strscpy(adapter->name, &compat[5], sizeof(adapter->name));
>> +
>> +	i2c_set_adapdata(adapter, li2c);
>> +
>> +	ret = i2c_bit_add_numbered_bus(adapter);
> Why do you care what the bus number is? You shouldn't need to.

Yes, we didn't need that. the i2c core will allocate one for us automatically.

Your advice is valuable, thanks your kindness review.

>> +	if (ret) {
>> +		if (i2c_np)
>> +			of_node_put(i2c_np);
>> +
>> +		devm_kfree(dev, li2c);
>> +		return ERR_PTR(ret);
>> +	}
>> +
>> +	return li2c;
>> +}
>> +
>> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c)
>> +{
>> +	struct i2c_adapter *adapter;
>> +
>> +	if (li2c) {
>> +		adapter = &li2c->adapter;
>> +
>> +		if (adapter && adapter->dev.of_node)
>> +			of_node_put(adapter->dev.of_node);
>> +
>> +		devm_kfree(ddev->dev, li2c);
>> +	}
>> +}
>> +
>> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
>> +					 unsigned int index)
>> +{
>> +	const struct lsdc_chip_desc * const descp = ldev->desc;
>> +	struct lsdc_i2c *li2c;
>> +
>> +	if (index >= descp->num_of_crtc) {
>> +		drm_err(ldev->ddev, "I2c adapter is no more than %u, %u\n",
>> +			descp->num_of_crtc, index);
>> +		return NULL;
>> +	}
>> +
>> +	li2c = ldev->li2c[index];
>> +	if (li2c)
>> +		return &li2c->adapter;
>> +
>> +	return NULL;
>> +}
>> diff --git a/drivers/gpu/drm/lsdc/lsdc_i2c.h b/drivers/gpu/drm/lsdc/lsdc_i2c.h
>> new file mode 100644
>> index 000000000000..4ab825143eb4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lsdc/lsdc_i2c.h
>> @@ -0,0 +1,42 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * KMS driver for Loongson display controller
>> + * Copyright (C) 2022 Loongson Corporation
>> + */
>> +
>> +/*
>> + * Authors:
>> + *      Sui Jingfeng <suijingfeng@loongson.cn>
>> + */
>> +
>> +#ifndef __LSDC_I2C__
>> +#define __LSDC_I2C__
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/i2c-algo-bit.h>
>> +#include <linux/pci.h>
>> +
>> +struct lsdc_i2c {
>> +	struct device *dev;
>> +	struct i2c_adapter adapter;
>> +	struct i2c_algo_bit_data bit;
>> +	/* @reglock: protects concurrent register access */
>> +	spinlock_t reglock;
>> +	void __iomem *reg_base;
>> +	void __iomem *dir_reg;
>> +	void __iomem *dat_reg;
>> +	int index;
>> +	/* pin bit mask */
>> +	u8 sda;
>> +	u8 scl;
>> +};
>> +
>> +void lsdc_destroy_i2c(struct drm_device *ddev, struct lsdc_i2c *li2c);
>> +
>> +struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev,
>> +				      void *base,
>> +				      unsigned int index);
>> +
>> +struct i2c_adapter *lsdc_get_i2c_adapter(struct lsdc_device *ldev,
>> +					 unsigned int index);
>> +#endif