All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
@ 2021-05-05 10:02 ` Marek Vasut
  0 siblings, 0 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-05 10:02 UTC (permalink / raw)
  To: dri-devel
  Cc: ch, Marek Vasut, Douglas Anderson, Jagan Teki, Laurent Pinchart,
	Linus Walleij, Rob Herring, Sam Ravnborg, Stephen Boyd,
	devicetree

Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: devicetree@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Add compatible string for SN65DSI84, since this is now tested on it
V3: - Add 0x2c as valid i2c address
    - Switch to schemas/graph.yaml
    - Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
    - Indent example by 4 spaces
    - Handle dual-link LVDS with two ports and describe the second DSI
      channel-B port as well. Based on the register defaults of DSI83
      and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
      hardware is present in all the chips, so just reuse port@0 and 2
      for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
      that is supported
---
 .../bindings/display/bridge/ti,sn65dsi83.yaml | 171 ++++++++++++++++++
 1 file changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
new file mode 100644
index 000000000000..4e7df92446a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
+
+maintainers:
+  - Marek Vasut <marex@denx.de>
+
+description: |
+  Texas Instruments SN65DSI83 1x Single-link MIPI DSI
+  to 1x Single-link LVDS
+  https://www.ti.com/lit/gpn/sn65dsi83
+  Texas Instruments SN65DSI84 1x Single-link MIPI DSI
+  to 1x Dual-link or 2x Single-link LVDS
+  https://www.ti.com/lit/gpn/sn65dsi84
+
+properties:
+  compatible:
+    oneOf:
+      - const: ti,sn65dsi83
+      - const: ti,sn65dsi84
+
+  reg:
+    oneOf:
+      - const: 0x2c
+      - const: 0x2d
+
+  enable-gpios:
+    maxItems: 1
+    description: GPIO specifier for bridge_en pin (active high).
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for MIPI DSI Channel-A input
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            unevaluatedProperties: false
+
+            properties:
+              data-lanes:
+                description: array of physical DSI data lane indexes.
+                minItems: 1
+                maxItems: 4
+                items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for MIPI DSI Channel-B input
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            unevaluatedProperties: false
+
+            properties:
+              data-lanes:
+                description: array of physical DSI data lane indexes.
+                minItems: 1
+                maxItems: 4
+                items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for LVDS Channel-A output (panel or bridge).
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            description: LVDS Channel-A output endpoint
+            unevaluatedProperties: false
+
+      port@3:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for LVDS Channel-A output (panel or bridge).
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            description: LVDS Channel-B output endpoint
+            unevaluatedProperties: false
+
+    required:
+      - port@0
+      - port@2
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - ports
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ti,sn65dsi83
+    then:
+      properties:
+        ports:
+          properties:
+            port@1: false
+            port@3: false
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ti,sn65dsi84
+    then:
+      properties:
+        ports:
+          properties:
+            port@1: false
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        bridge@2d {
+            compatible = "ti,sn65dsi83";
+            reg = <0x2d>;
+
+            enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+
+                    endpoint {
+                        remote-endpoint = <&dsi0_out>;
+                        data-lanes = <1 2 3 4>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+
+                    endpoint {
+                        remote-endpoint = <&panel_in_lvds>;
+                    };
+                };
+            };
+        };
+    };
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
@ 2021-05-05 10:02 ` Marek Vasut
  0 siblings, 0 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-05 10:02 UTC (permalink / raw)
  To: dri-devel
  Cc: Marek Vasut, devicetree, ch, Douglas Anderson, Stephen Boyd,
	Rob Herring, Jagan Teki, Sam Ravnborg, Laurent Pinchart

Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: devicetree@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Add compatible string for SN65DSI84, since this is now tested on it
V3: - Add 0x2c as valid i2c address
    - Switch to schemas/graph.yaml
    - Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
    - Indent example by 4 spaces
    - Handle dual-link LVDS with two ports and describe the second DSI
      channel-B port as well. Based on the register defaults of DSI83
      and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
      hardware is present in all the chips, so just reuse port@0 and 2
      for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
      that is supported
---
 .../bindings/display/bridge/ti,sn65dsi83.yaml | 171 ++++++++++++++++++
 1 file changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
new file mode 100644
index 000000000000..4e7df92446a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -0,0 +1,171 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
+
+maintainers:
+  - Marek Vasut <marex@denx.de>
+
+description: |
+  Texas Instruments SN65DSI83 1x Single-link MIPI DSI
+  to 1x Single-link LVDS
+  https://www.ti.com/lit/gpn/sn65dsi83
+  Texas Instruments SN65DSI84 1x Single-link MIPI DSI
+  to 1x Dual-link or 2x Single-link LVDS
+  https://www.ti.com/lit/gpn/sn65dsi84
+
+properties:
+  compatible:
+    oneOf:
+      - const: ti,sn65dsi83
+      - const: ti,sn65dsi84
+
+  reg:
+    oneOf:
+      - const: 0x2c
+      - const: 0x2d
+
+  enable-gpios:
+    maxItems: 1
+    description: GPIO specifier for bridge_en pin (active high).
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for MIPI DSI Channel-A input
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            unevaluatedProperties: false
+
+            properties:
+              data-lanes:
+                description: array of physical DSI data lane indexes.
+                minItems: 1
+                maxItems: 4
+                items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for MIPI DSI Channel-B input
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            unevaluatedProperties: false
+
+            properties:
+              data-lanes:
+                description: array of physical DSI data lane indexes.
+                minItems: 1
+                maxItems: 4
+                items:
+                  - const: 1
+                  - const: 2
+                  - const: 3
+                  - const: 4
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for LVDS Channel-A output (panel or bridge).
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            description: LVDS Channel-A output endpoint
+            unevaluatedProperties: false
+
+      port@3:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Video port for LVDS Channel-A output (panel or bridge).
+
+        properties:
+          endpoint:
+            $ref: /schemas/graph.yaml#/$defs/endpoint-base
+            description: LVDS Channel-B output endpoint
+            unevaluatedProperties: false
+
+    required:
+      - port@0
+      - port@2
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - ports
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ti,sn65dsi83
+    then:
+      properties:
+        ports:
+          properties:
+            port@1: false
+            port@3: false
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ti,sn65dsi84
+    then:
+      properties:
+        ports:
+          properties:
+            port@1: false
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        bridge@2d {
+            compatible = "ti,sn65dsi83";
+            reg = <0x2d>;
+
+            enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+
+                    endpoint {
+                        remote-endpoint = <&dsi0_out>;
+                        data-lanes = <1 2 3 4>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+
+                    endpoint {
+                        remote-endpoint = <&panel_in_lvds>;
+                    };
+                };
+            };
+        };
+    };
-- 
2.30.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-05 10:02 ` Marek Vasut
  (?)
@ 2021-05-05 10:02 ` Marek Vasut
  2021-05-05 12:42   ` Linus Walleij
                     ` (4 more replies)
  -1 siblings, 5 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-05 10:02 UTC (permalink / raw)
  To: dri-devel
  Cc: Marek Vasut, Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
but easy to add.

The driver operates the chip via I2C bus. Currently the LVDS clock are
always derived from DSI clock lane, which is the usual mode of operation.
Support for clock from external oscillator is not implemented, but it is
easy to add if ever needed. Only RGB888 pixel format is implemented, the
LVDS666 is not supported, but could be added if needed.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Loic Poulain <loic.poulain@linaro.org>
Cc: Philippe Schenker <philippe.schenker@toradex.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Valentin Raevsky <valentin@compulab.co.il>
To: dri-devel@lists.freedesktop.org
---
V2: - Use dev_err_probe()
    - Set REG_RC_RESET as volatile
    - Wait for PLL stabilization by polling REG_RC_LVDS_PLL
    - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set
    - Add tested DSI84 support in dual-link mode
    - Correctly set VCOM
    - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85
      datasheets, with that all the reserved bits make far more sense
      as the DSI83 and DSI84 seems to be reduced version of DSI85
V3: - Handle the dual-link LVDS with two port panel or bridge
---
 drivers/gpu/drm/bridge/Kconfig        |  10 +
 drivers/gpu/drm/bridge/Makefile       |   1 +
 drivers/gpu/drm/bridge/ti-sn65dsi83.c | 639 ++++++++++++++++++++++++++
 3 files changed, 650 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e83b8ad0d71b..32204c5f25b7 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -278,6 +278,16 @@ config DRM_TI_TFP410
 	help
 	  Texas Instruments TFP410 DVI/HDMI Transmitter driver
 
+config DRM_TI_SN65DSI83
+	tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge"
+	depends on OF
+	select DRM_KMS_HELPER
+	select REGMAP_I2C
+	select DRM_PANEL
+	select DRM_MIPI_DSI
+	help
+	  Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver
+
 config DRM_TI_SN65DSI86
 	tristate "TI SN65DSI86 DSI to eDP bridge"
 	depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b00f3b2ad572..7bb4c9df0415 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
+obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
 obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
new file mode 100644
index 000000000000..471df09a1c07
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -0,0 +1,639 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI SN65DSI83,84,85 driver
+ *
+ * Currently supported:
+ * - SN65DSI83
+ *   = 1x Single-link DSI ~ 1x Single-link LVDS
+ *   - Supported
+ *   - Single-link LVDS mode tested
+ * - SN65DSI84
+ *   = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
+ *   - Supported
+ *   - Dual-link LVDS mode tested
+ *   - 2x Single-link LVDS mode unsupported
+ *     (should be easy to add by someone who has the HW)
+ * - SN65DSI85
+ *   = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
+ *   - Unsupported
+ *     (should be easy to add by someone who has the HW)
+ *
+ * Copyright (C) 2021 Marek Vasut <marex@denx.de>
+ *
+ * Based on previous work of:
+ * Valentin Raevsky <valentin@compulab.co.il>
+ * Philippe Schenker <philippe.schenker@toradex.com>
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_graph.h>
+#include <linux/regmap.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+#include <drm/drm_probe_helper.h>
+
+/* ID registers */
+#define REG_ID(n)				(0x00 + (n))
+/* Reset and clock registers */
+#define REG_RC_RESET				0x09
+#define  REG_RC_RESET_SOFT_RESET		BIT(0)
+#define REG_RC_LVDS_PLL				0x0a
+#define  REG_RC_LVDS_PLL_PLL_EN_STAT		BIT(7)
+#define  REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n)	(((n) & 0x7) << 1)
+#define  REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY	BIT(0)
+#define REG_RC_DSI_CLK				0x0b
+#define  REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n)	(((n) & 0x1f) << 3)
+#define  REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n)	((n) & 0x3)
+#define REG_RC_PLL_EN				0x0d
+#define  REG_RC_PLL_EN_PLL_EN			BIT(0)
+/* DSI registers */
+#define REG_DSI_LANE				0x10
+#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL	BIT(5) /* dual or 2x single */
+#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
+#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
+#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
+#define REG_DSI_EQ				0x11
+#define  REG_DSI_EQ_CHA_DSI_DATA_EQ(n)		(((n) & 0x3) << 6)
+#define  REG_DSI_EQ_CHA_DSI_CLK_EQ(n)		(((n) & 0x3) << 2)
+#define REG_DSI_CLK				0x12
+#define  REG_DSI_CLK_CHA_DSI_CLK_RANGE(n)	((n) & 0xff)
+/* LVDS registers */
+#define REG_LVDS_FMT				0x18
+#define  REG_LVDS_FMT_DE_NEG_POLARITY		BIT(7)
+#define  REG_LVDS_FMT_HS_NEG_POLARITY		BIT(6)
+#define  REG_LVDS_FMT_VS_NEG_POLARITY		BIT(5)
+#define  REG_LVDS_FMT_LVDS_LINK_CFG		BIT(4)	/* 0:AB 1:A-only */
+#define  REG_LVDS_FMT_CHA_24BPP_MODE		BIT(3)
+#define  REG_LVDS_FMT_CHB_24BPP_MODE		BIT(2)
+#define  REG_LVDS_FMT_CHA_24BPP_FORMAT1		BIT(1)
+#define  REG_LVDS_FMT_CHB_24BPP_FORMAT1		BIT(0)
+#define REG_LVDS_VCOM				0x19
+#define  REG_LVDS_VCOM_CHA_LVDS_VOCM		BIT(6)
+#define  REG_LVDS_VCOM_CHB_LVDS_VOCM		BIT(4)
+#define  REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(n)	(((n) & 0x3) << 2)
+#define  REG_LVDS_VCOM_CHB_LVDS_VOD_SWING(n)	((n) & 0x3)
+#define REG_LVDS_LANE				0x1a
+#define  REG_LVDS_LANE_EVEN_ODD_SWAP		BIT(6)
+#define  REG_LVDS_LANE_CHA_REVERSE_LVDS		BIT(5)
+#define  REG_LVDS_LANE_CHB_REVERSE_LVDS		BIT(4)
+#define  REG_LVDS_LANE_CHA_LVDS_TERM		BIT(1)
+#define  REG_LVDS_LANE_CHB_LVDS_TERM		BIT(0)
+#define REG_LVDS_CM				0x1b
+#define  REG_LVDS_CM_CHA_LVDS_CM_ADJUST(n)	(((n) & 0x3) << 4)
+#define  REG_LVDS_CM_CHB_LVDS_CM_ADJUST(n)	((n) & 0x3)
+/* Video registers */
+#define REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW	0x20
+#define REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH	0x21
+#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW	0x24
+#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH	0x25
+#define REG_VID_CHA_SYNC_DELAY_LOW		0x28
+#define REG_VID_CHA_SYNC_DELAY_HIGH		0x29
+#define REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW	0x2c
+#define REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH	0x2d
+#define REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW	0x30
+#define REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH	0x31
+#define REG_VID_CHA_HORIZONTAL_BACK_PORCH	0x34
+#define REG_VID_CHA_VERTICAL_BACK_PORCH		0x36
+#define REG_VID_CHA_HORIZONTAL_FRONT_PORCH	0x38
+#define REG_VID_CHA_VERTICAL_FRONT_PORCH	0x3a
+#define REG_VID_CHA_TEST_PATTERN		0x3c
+/* IRQ registers */
+#define REG_IRQ_GLOBAL				0xe0
+#define  REG_IRQ_GLOBAL_IRQ_EN			BIT(0)
+#define REG_IRQ_EN				0xe1
+#define  REG_IRQ_EN_CHA_SYNCH_ERR_EN		BIT(7)
+#define  REG_IRQ_EN_CHA_CRC_ERR_EN		BIT(6)
+#define  REG_IRQ_EN_CHA_UNC_ECC_ERR_EN		BIT(5)
+#define  REG_IRQ_EN_CHA_COR_ECC_ERR_EN		BIT(4)
+#define  REG_IRQ_EN_CHA_LLP_ERR_EN		BIT(3)
+#define  REG_IRQ_EN_CHA_SOT_BIT_ERR_EN		BIT(2)
+#define  REG_IRQ_EN_CHA_PLL_UNLOCK_EN		BIT(0)
+#define REG_IRQ_STAT				0xe5
+#define  REG_IRQ_STAT_CHA_SYNCH_ERR		BIT(7)
+#define  REG_IRQ_STAT_CHA_CRC_ERR		BIT(6)
+#define  REG_IRQ_STAT_CHA_UNC_ECC_ERR		BIT(5)
+#define  REG_IRQ_STAT_CHA_COR_ECC_ERR		BIT(4)
+#define  REG_IRQ_STAT_CHA_LLP_ERR		BIT(3)
+#define  REG_IRQ_STAT_CHA_SOT_BIT_ERR		BIT(2)
+#define  REG_IRQ_STAT_CHA_PLL_UNLOCK		BIT(0)
+
+enum sn65dsi83_model {
+	MODEL_SN65DSI83,
+	MODEL_SN65DSI84,
+};
+
+struct sn65dsi83 {
+	struct drm_bridge		bridge;
+	struct drm_display_mode		mode;
+	struct device			*dev;
+	struct regmap			*regmap;
+	struct device_node		*host_node;
+	struct mipi_dsi_device		*dsi;
+	struct drm_bridge		*panel_bridge;
+	struct gpio_desc		*enable_gpio;
+	int				dsi_lanes;
+	bool				lvds_dual_link;
+	bool				lvds_dual_link_even_odd_swap;
+};
+
+static const struct regmap_range sn65dsi83_readable_ranges[] = {
+	regmap_reg_range(REG_ID(0), REG_ID(8)),
+	regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_DSI_CLK),
+	regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
+	regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
+	regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
+	regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
+			 REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
+	regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
+			 REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
+	regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
+			 REG_VID_CHA_SYNC_DELAY_HIGH),
+	regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
+			 REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
+	regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
+			 REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
+	regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
+			 REG_VID_CHA_HORIZONTAL_BACK_PORCH),
+	regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
+			 REG_VID_CHA_VERTICAL_BACK_PORCH),
+	regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
+			 REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
+	regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
+			 REG_VID_CHA_VERTICAL_FRONT_PORCH),
+	regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
+	regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
+	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
+};
+
+static const struct regmap_access_table sn65dsi83_readable_table = {
+	.yes_ranges = sn65dsi83_readable_ranges,
+	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_readable_ranges),
+};
+
+static const struct regmap_range sn65dsi83_writeable_ranges[] = {
+	regmap_reg_range(REG_RC_RESET, REG_RC_DSI_CLK),
+	regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
+	regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
+	regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
+	regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
+			 REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
+	regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
+			 REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
+	regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
+			 REG_VID_CHA_SYNC_DELAY_HIGH),
+	regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
+			 REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
+	regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
+			 REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
+	regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
+			 REG_VID_CHA_HORIZONTAL_BACK_PORCH),
+	regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
+			 REG_VID_CHA_VERTICAL_BACK_PORCH),
+	regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
+			 REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
+	regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
+			 REG_VID_CHA_VERTICAL_FRONT_PORCH),
+	regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
+	regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
+	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
+};
+
+static const struct regmap_access_table sn65dsi83_writeable_table = {
+	.yes_ranges = sn65dsi83_writeable_ranges,
+	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_writeable_ranges),
+};
+
+static const struct regmap_range sn65dsi83_volatile_ranges[] = {
+	regmap_reg_range(REG_RC_RESET, REG_RC_RESET),
+	regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
+	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
+};
+
+static const struct regmap_access_table sn65dsi83_volatile_table = {
+	.yes_ranges = sn65dsi83_volatile_ranges,
+	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),
+};
+
+static const struct regmap_config sn65dsi83_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.rd_table = &sn65dsi83_readable_table,
+	.wr_table = &sn65dsi83_writeable_table,
+	.volatile_table = &sn65dsi83_volatile_table,
+	.cache_type = REGCACHE_RBTREE,
+	.max_register = REG_IRQ_STAT,
+};
+
+static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge)
+{
+	return container_of(bridge, struct sn65dsi83, bridge);
+}
+
+static int sn65dsi83_attach(struct drm_bridge *bridge,
+			    enum drm_bridge_attach_flags flags)
+{
+	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+	struct device *dev = ctx->dev;
+	struct mipi_dsi_device *dsi;
+	struct mipi_dsi_host *host;
+	int ret = 0;
+
+	const struct mipi_dsi_device_info info = {
+		.type = "sn65dsi83",
+		.channel = 0,
+		.node = NULL,
+	};
+
+	host = of_find_mipi_dsi_host_by_node(ctx->host_node);
+	if (!host) {
+		dev_err(dev, "failed to find dsi host\n");
+		return -EPROBE_DEFER;
+	}
+
+	dsi = mipi_dsi_device_register_full(host, &info);
+	if (IS_ERR(dsi)) {
+		return dev_err_probe(dev, PTR_ERR(dsi),
+				     "failed to create dsi device\n");
+	}
+
+	ctx->dsi = dsi;
+
+	dsi->lanes = ctx->dsi_lanes;
+	dsi->format = MIPI_DSI_FMT_RGB888;
+	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
+
+	ret = mipi_dsi_attach(dsi);
+	if (ret < 0) {
+		dev_err(dev, "failed to attach dsi to host\n");
+		goto err_dsi_attach;
+	}
+
+	return drm_bridge_attach(bridge->encoder, ctx->panel_bridge,
+				 &ctx->bridge, flags);
+
+err_dsi_attach:
+	mipi_dsi_device_unregister(dsi);
+	return ret;
+}
+
+static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
+{
+	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+
+	/*
+	 * Reset the chip, pull EN line low for t_reset=10ms,
+	 * then high for t_en=1ms.
+	 */
+	regcache_mark_dirty(ctx->regmap);
+	gpiod_set_value(ctx->enable_gpio, 0);
+	usleep_range(10000, 11000);
+	gpiod_set_value(ctx->enable_gpio, 1);
+	usleep_range(1000, 1100);
+}
+
+static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx)
+{
+	/*
+	 * The encoding of the LVDS_CLK_RANGE is as follows:
+	 * 000 - 25 MHz <= LVDS_CLK < 37.5 MHz
+	 * 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz
+	 * 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz
+	 * 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz
+	 * 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz
+	 * 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz
+	 * which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that
+	 * the ends of the ranges are clamped to the supported range. Since
+	 * sn65dsi83_mode_valid() already filters the valid modes and limits
+	 * the clock to 25..154 MHz, the range calculation can be simplified
+	 * as follows:
+	 */
+	int mode_clock = ctx->mode.clock;
+
+	if (ctx->lvds_dual_link)
+		mode_clock /= 2;
+
+	return (mode_clock - 12500) / 25000;
+}
+
+static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx)
+{
+	/*
+	 * The encoding of the CHA_DSI_CLK_RANGE is as follows:
+	 * 0x00 through 0x07 - Reserved
+	 * 0x08 - 40 <= DSI_CLK < 45 MHz
+	 * 0x09 - 45 <= DSI_CLK < 50 MHz
+	 * ...
+	 * 0x63 - 495 <= DSI_CLK < 500 MHz
+	 * 0x64 - 500 MHz
+	 * 0x65 through 0xFF - Reserved
+	 * which is DSI clock in 5 MHz steps, clamped to 40..500 MHz.
+	 * The DSI clock are calculated as:
+	 *  DSI_CLK = mode clock * bpp / dsi_data_lanes / 2
+	 * the 2 is there because the bus is DDR.
+	 */
+	return DIV_ROUND_UP(clamp((unsigned int)ctx->mode.clock *
+			    mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
+			    ctx->dsi_lanes / 2, 40000U, 500000U), 5000U);
+}
+
+static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
+{
+	/* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */
+	unsigned int dsi_div = mipi_dsi_pixel_format_to_bpp(ctx->dsi->format);
+
+	dsi_div /= ctx->dsi_lanes;
+
+	if (!ctx->lvds_dual_link)
+		dsi_div /= 2;
+
+	return dsi_div - 1;
+}
+
+static void sn65dsi83_enable(struct drm_bridge *bridge)
+{
+	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+	unsigned int pval;
+	u16 val;
+	int ret;
+
+	/* Clear reset, disable PLL */
+	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
+	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
+
+	/* Reference clock derived from DSI link clock. */
+	regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
+		REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
+		REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
+	regmap_write(ctx->regmap, REG_DSI_CLK,
+		REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
+	regmap_write(ctx->regmap, REG_RC_DSI_CLK,
+		REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
+
+	/* Set number of DSI lanes and LVDS link config. */
+	regmap_write(ctx->regmap, REG_DSI_LANE,
+		REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
+		REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
+		/* CHB is DSI85-only, set to default on DSI83/DSI84 */
+		REG_DSI_LANE_CHB_DSI_LANES(3));
+	/* No equalization. */
+	regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
+
+	/* RGB888 is the only format supported so far. */
+	val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
+	       REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
+	      (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
+	       REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
+	      REG_LVDS_FMT_CHA_24BPP_MODE;
+	if (ctx->lvds_dual_link)
+		val |= REG_LVDS_FMT_CHB_24BPP_MODE;
+	else
+		val |= REG_LVDS_FMT_LVDS_LINK_CFG;
+
+	regmap_write(ctx->regmap, REG_LVDS_FMT, val);
+	regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
+	regmap_write(ctx->regmap, REG_LVDS_LANE,
+		(ctx->lvds_dual_link_even_odd_swap ?
+		 REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
+		REG_LVDS_LANE_CHA_LVDS_TERM |
+		REG_LVDS_LANE_CHB_LVDS_TERM);
+	regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
+
+	regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
+			  &ctx->mode.hdisplay, 2);
+	regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
+			  &ctx->mode.vdisplay, 2);
+	val = 32 + 1;	/* 32 + 1 pixel clock to ensure proper operation */
+	regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);
+	val = ctx->mode.hsync_end - ctx->mode.hsync_start;
+	regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
+			  &val, 2);
+	val = ctx->mode.vsync_end - ctx->mode.vsync_start;
+	regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
+			  &val, 2);
+	regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
+		     ctx->mode.htotal - ctx->mode.hsync_end);
+	regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,
+		     ctx->mode.vtotal - ctx->mode.vsync_end);
+	regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
+		     ctx->mode.hsync_start - ctx->mode.hdisplay);
+	regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
+		     ctx->mode.vsync_start - ctx->mode.vdisplay);
+	regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
+
+	/* Enable PLL */
+	regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
+	usleep_range(3000, 4000);
+	ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
+					pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
+					1000, 100000);
+	if (ret) {
+		dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
+		/* On failure, disable PLL again and exit. */
+		regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
+		return;
+	}
+
+	/* Trigger reset after CSR register update. */
+	regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);
+
+	/* Clear all errors that got asserted during initialization. */
+	regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
+	regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
+}
+
+static void sn65dsi83_disable(struct drm_bridge *bridge)
+{
+	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+
+	/* Clear reset, disable PLL */
+	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
+	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
+}
+
+static void sn65dsi83_post_disable(struct drm_bridge *bridge)
+{
+	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+
+	/* Put the chip in reset, pull EN line low. */
+	gpiod_set_value(ctx->enable_gpio, 0);
+}
+
+static enum drm_mode_status
+sn65dsi83_mode_valid(struct drm_bridge *bridge,
+		     const struct drm_display_info *info,
+		     const struct drm_display_mode *mode)
+{
+	/* LVDS output clock range 25..154 MHz */
+	if (mode->clock < 25000)
+		return MODE_CLOCK_LOW;
+	if (mode->clock > 154000)
+		return MODE_CLOCK_HIGH;
+
+	return MODE_OK;
+}
+
+static void sn65dsi83_mode_set(struct drm_bridge *bridge,
+			       const struct drm_display_mode *mode,
+			       const struct drm_display_mode *adj)
+{
+	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+
+	ctx->mode = *adj;
+}
+
+static const struct drm_bridge_funcs sn65dsi83_funcs = {
+	.attach		= sn65dsi83_attach,
+	.pre_enable	= sn65dsi83_pre_enable,
+	.enable		= sn65dsi83_enable,
+	.disable	= sn65dsi83_disable,
+	.post_disable	= sn65dsi83_post_disable,
+	.mode_valid	= sn65dsi83_mode_valid,
+	.mode_set	= sn65dsi83_mode_set,
+};
+
+static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
+{
+	struct drm_bridge *panel_bridge;
+	struct device *dev = ctx->dev;
+	struct device_node *endpoint;
+	struct drm_panel *panel;
+	int ret;
+
+	endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
+	ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
+	ctx->host_node = of_graph_get_remote_port_parent(endpoint);
+	of_node_put(endpoint);
+
+	if (ctx->dsi_lanes < 0 || ctx->dsi_lanes > 4)
+		return -EINVAL;
+	if (!ctx->host_node)
+		return -ENODEV;
+
+	ctx->lvds_dual_link = false;
+	ctx->lvds_dual_link_even_odd_swap = false;
+	if (model != MODEL_SN65DSI83) {
+		struct device_node *port2, *port3;
+		int dual_link;
+
+		port2 = of_graph_get_port_by_id(dev->of_node, 2);
+		port3 = of_graph_get_port_by_id(dev->of_node, 3);
+		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
+		of_node_put(port2);
+		of_node_put(port3);
+
+		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
+			ctx->lvds_dual_link = true;
+			/* Odd pixels to LVDS Channel A, even pixels to B */
+			ctx->lvds_dual_link_even_odd_swap = false;
+		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
+			ctx->lvds_dual_link = true;
+			/* Even pixels to LVDS Channel A, odd pixels to B */
+			ctx->lvds_dual_link_even_odd_swap = true;
+		}
+	}
+
+	ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, &panel, &panel_bridge);
+	if (ret < 0)
+		return ret;
+	if (panel) {
+		panel_bridge = devm_drm_panel_bridge_add(dev, panel);
+		if (IS_ERR(panel_bridge))
+			return PTR_ERR(panel_bridge);
+	}
+
+	ctx->panel_bridge = panel_bridge;
+
+	return 0;
+}
+
+static int sn65dsi83_probe(struct i2c_client *client,
+			   const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	enum sn65dsi83_model model;
+	struct sn65dsi83 *ctx;
+	int ret;
+
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->dev = dev;
+
+	if (dev->of_node)
+		model = (enum sn65dsi83_model)of_device_get_match_data(dev);
+	else
+		model = id->driver_data;
+
+	ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(ctx->enable_gpio))
+		return PTR_ERR(ctx->enable_gpio);
+
+	ret = sn65dsi83_parse_dt(ctx, model);
+	if (ret)
+		return ret;
+
+	ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config);
+	if (IS_ERR(ctx->regmap))
+		return PTR_ERR(ctx->regmap);
+
+	dev_set_drvdata(dev, ctx);
+	i2c_set_clientdata(client, ctx);
+
+	ctx->bridge.funcs = &sn65dsi83_funcs;
+	ctx->bridge.of_node = dev->of_node;
+	drm_bridge_add(&ctx->bridge);
+
+	return 0;
+}
+
+static int sn65dsi83_remove(struct i2c_client *client)
+{
+	struct sn65dsi83 *ctx = i2c_get_clientdata(client);
+
+	mipi_dsi_detach(ctx->dsi);
+	mipi_dsi_device_unregister(ctx->dsi);
+	drm_bridge_remove(&ctx->bridge);
+	of_node_put(ctx->host_node);
+
+	return 0;
+}
+
+static struct i2c_device_id sn65dsi83_id[] = {
+	{ "ti,sn65dsi83", MODEL_SN65DSI83 },
+	{ "ti,sn65dsi84", MODEL_SN65DSI84 },
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, sn65dsi83_id);
+
+static const struct of_device_id sn65dsi83_match_table[] = {
+	{ .compatible = "ti,sn65dsi83", .data = (void *)MODEL_SN65DSI83 },
+	{ .compatible = "ti,sn65dsi84", .data = (void *)MODEL_SN65DSI84 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sn65dsi83_match_table);
+
+static struct i2c_driver sn65dsi83_driver = {
+	.probe = sn65dsi83_probe,
+	.remove = sn65dsi83_remove,
+	.id_table = sn65dsi83_id,
+	.driver = {
+		.name = "sn65dsi83",
+		.of_match_table = sn65dsi83_match_table,
+	},
+};
+module_i2c_driver(sn65dsi83_driver);
+
+MODULE_AUTHOR("Marek Vasut <marex@denx.de>");
+MODULE_DESCRIPTION("TI SN65DSI83 DSI to LVDS bridge driver");
+MODULE_LICENSE("GPL v2");
-- 
2.30.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
  2021-05-05 10:02 ` Marek Vasut
@ 2021-05-05 12:38   ` Linus Walleij
  -1 siblings, 0 replies; 34+ messages in thread
From: Linus Walleij @ 2021-05-05 12:38 UTC (permalink / raw)
  To: Marek Vasut
  Cc: open list:DRM PANEL DRIVERS, ch, Douglas Anderson, Jagan Teki,
	Laurent Pinchart, Rob Herring, Sam Ravnborg, Stephen Boyd,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Wed, May 5, 2021 at 12:03 PM Marek Vasut <marex@denx.de> wrote:

> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: devicetree@vger.kernel.org
> To: dri-devel@lists.freedesktop.org

This looks good to me:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
@ 2021-05-05 12:38   ` Linus Walleij
  0 siblings, 0 replies; 34+ messages in thread
From: Linus Walleij @ 2021-05-05 12:38 UTC (permalink / raw)
  To: Marek Vasut
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, ch,
	Douglas Anderson, open list:DRM PANEL DRIVERS, Stephen Boyd,
	Rob Herring, Jagan Teki, Sam Ravnborg, Laurent Pinchart

On Wed, May 5, 2021 at 12:03 PM Marek Vasut <marex@denx.de> wrote:

> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: devicetree@vger.kernel.org
> To: dri-devel@lists.freedesktop.org

This looks good to me:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-05 10:02 ` [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver Marek Vasut
@ 2021-05-05 12:42   ` Linus Walleij
  2021-05-06  9:45   ` Dave Stevenson
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 34+ messages in thread
From: Linus Walleij @ 2021-05-05 12:42 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, open list:DRM PANEL DRIVERS,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On Wed, May 5, 2021 at 12:03 PM Marek Vasut <marex@denx.de> wrote:

> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
>
> The driver operates the chip via I2C bus. Currently the LVDS clock are
> always derived from DSI clock lane, which is the usual mode of operation.
> Support for clock from external oscillator is not implemented, but it is
> easy to add if ever needed. Only RGB888 pixel format is implemented, the
> LVDS666 is not supported, but could be added if needed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Loic Poulain <loic.poulain@linaro.org>
> Cc: Philippe Schenker <philippe.schenker@toradex.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: Valentin Raevsky <valentin@compulab.co.il>
> To: dri-devel@lists.freedesktop.org

This looks very nice to me, despite the complex nature of the driver
it is a bliss to read this code with all nice comments and explanations.
I don't know the gory details as well as the bridge maintainers but from
my helicopter perspective, hats off.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-05 10:02 ` [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver Marek Vasut
  2021-05-05 12:42   ` Linus Walleij
@ 2021-05-06  9:45   ` Dave Stevenson
  2021-05-06 12:48     ` Marek Vasut
  2021-05-06 15:38   ` Frieder Schrempf
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 34+ messages in thread
From: Dave Stevenson @ 2021-05-06  9:45 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

Hi Marek

I'm taking an interest as there are a number of Raspberry Pi users
trying to get this chip up and running (not there quite yet).
A couple of fairly minor comments

On Wed, 5 May 2021 at 11:03, Marek Vasut <marex@denx.de> wrote:
>
> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
>
> The driver operates the chip via I2C bus. Currently the LVDS clock are
> always derived from DSI clock lane, which is the usual mode of operation.
> Support for clock from external oscillator is not implemented, but it is
> easy to add if ever needed. Only RGB888 pixel format is implemented, the
> LVDS666 is not supported, but could be added if needed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Loic Poulain <loic.poulain@linaro.org>
> Cc: Philippe Schenker <philippe.schenker@toradex.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: Valentin Raevsky <valentin@compulab.co.il>
> To: dri-devel@lists.freedesktop.org
> ---
> V2: - Use dev_err_probe()
>     - Set REG_RC_RESET as volatile
>     - Wait for PLL stabilization by polling REG_RC_LVDS_PLL
>     - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set
>     - Add tested DSI84 support in dual-link mode
>     - Correctly set VCOM
>     - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85
>       datasheets, with that all the reserved bits make far more sense
>       as the DSI83 and DSI84 seems to be reduced version of DSI85
> V3: - Handle the dual-link LVDS with two port panel or bridge
> ---
>  drivers/gpu/drm/bridge/Kconfig        |  10 +
>  drivers/gpu/drm/bridge/Makefile       |   1 +
>  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 639 ++++++++++++++++++++++++++
>  3 files changed, 650 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e83b8ad0d71b..32204c5f25b7 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -278,6 +278,16 @@ config DRM_TI_TFP410
>         help
>           Texas Instruments TFP410 DVI/HDMI Transmitter driver
>
> +config DRM_TI_SN65DSI83
> +       tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge"
> +       depends on OF
> +       select DRM_KMS_HELPER
> +       select REGMAP_I2C
> +       select DRM_PANEL
> +       select DRM_MIPI_DSI
> +       help
> +         Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver
> +
>  config DRM_TI_SN65DSI86
>         tristate "TI SN65DSI86 DSI to eDP bridge"
>         depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b00f3b2ad572..7bb4c9df0415 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o
>  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>  obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> new file mode 100644
> index 000000000000..471df09a1c07
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -0,0 +1,639 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TI SN65DSI83,84,85 driver
> + *
> + * Currently supported:
> + * - SN65DSI83
> + *   = 1x Single-link DSI ~ 1x Single-link LVDS
> + *   - Supported
> + *   - Single-link LVDS mode tested
> + * - SN65DSI84
> + *   = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
> + *   - Supported
> + *   - Dual-link LVDS mode tested
> + *   - 2x Single-link LVDS mode unsupported
> + *     (should be easy to add by someone who has the HW)
> + * - SN65DSI85
> + *   = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
> + *   - Unsupported
> + *     (should be easy to add by someone who has the HW)
> + *
> + * Copyright (C) 2021 Marek Vasut <marex@denx.de>
> + *
> + * Based on previous work of:
> + * Valentin Raevsky <valentin@compulab.co.il>
> + * Philippe Schenker <philippe.schenker@toradex.com>
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_graph.h>
> +#include <linux/regmap.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +/* ID registers */
> +#define REG_ID(n)                              (0x00 + (n))
> +/* Reset and clock registers */
> +#define REG_RC_RESET                           0x09
> +#define  REG_RC_RESET_SOFT_RESET               BIT(0)
> +#define REG_RC_LVDS_PLL                                0x0a
> +#define  REG_RC_LVDS_PLL_PLL_EN_STAT           BIT(7)
> +#define  REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n)     (((n) & 0x7) << 1)
> +#define  REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY       BIT(0)
> +#define REG_RC_DSI_CLK                         0x0b
> +#define  REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n)     (((n) & 0x1f) << 3)
> +#define  REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n)   ((n) & 0x3)
> +#define REG_RC_PLL_EN                          0x0d
> +#define  REG_RC_PLL_EN_PLL_EN                  BIT(0)
> +/* DSI registers */
> +#define REG_DSI_LANE                           0x10
> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL       BIT(5) /* dual or 2x single */

The bit name here seems a little odd.
Bits 5&6 are the DSI channel mode on SN65DSI85, not the LVDS link
config (which appears to be reg 0x18 bit 4)
DSI_CHANNEL_MODE
00 – Dual-channel DSI receiver
01 – Single channel DSI receiver (default)
10 – Two single channel DSI receivers
11 – Reserved
SN65DSI83 and 84 require it to be set to 01. You have that end result,
but using an odd register name that only documents one of the 2 bits.

Is it worth documenting bit 7 as being the '85 Dual DSI link
LEFT_RIGHT_PIXELS flag at the same time? The chip isn't supported in
dual DSI mode at present, but defining all the registers up front
seems reasonable.

> +#define  REG_DSI_LANE_CHA_DSI_LANES(n)         (((n) & 0x3) << 3)
> +#define  REG_DSI_LANE_CHB_DSI_LANES(n)         (((n) & 0x3) << 1)
> +#define  REG_DSI_LANE_SOT_ERR_TOL_DIS          BIT(0)
> +#define REG_DSI_EQ                             0x11
> +#define  REG_DSI_EQ_CHA_DSI_DATA_EQ(n)         (((n) & 0x3) << 6)
> +#define  REG_DSI_EQ_CHA_DSI_CLK_EQ(n)          (((n) & 0x3) << 2)
> +#define REG_DSI_CLK                            0x12
> +#define  REG_DSI_CLK_CHA_DSI_CLK_RANGE(n)      ((n) & 0xff)
> +/* LVDS registers */
> +#define REG_LVDS_FMT                           0x18
> +#define  REG_LVDS_FMT_DE_NEG_POLARITY          BIT(7)
> +#define  REG_LVDS_FMT_HS_NEG_POLARITY          BIT(6)
> +#define  REG_LVDS_FMT_VS_NEG_POLARITY          BIT(5)
> +#define  REG_LVDS_FMT_LVDS_LINK_CFG            BIT(4)  /* 0:AB 1:A-only */
> +#define  REG_LVDS_FMT_CHA_24BPP_MODE           BIT(3)
> +#define  REG_LVDS_FMT_CHB_24BPP_MODE           BIT(2)
> +#define  REG_LVDS_FMT_CHA_24BPP_FORMAT1                BIT(1)
> +#define  REG_LVDS_FMT_CHB_24BPP_FORMAT1                BIT(0)
> +#define REG_LVDS_VCOM                          0x19
> +#define  REG_LVDS_VCOM_CHA_LVDS_VOCM           BIT(6)
> +#define  REG_LVDS_VCOM_CHB_LVDS_VOCM           BIT(4)
> +#define  REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(n)   (((n) & 0x3) << 2)
> +#define  REG_LVDS_VCOM_CHB_LVDS_VOD_SWING(n)   ((n) & 0x3)
> +#define REG_LVDS_LANE                          0x1a
> +#define  REG_LVDS_LANE_EVEN_ODD_SWAP           BIT(6)
> +#define  REG_LVDS_LANE_CHA_REVERSE_LVDS                BIT(5)
> +#define  REG_LVDS_LANE_CHB_REVERSE_LVDS                BIT(4)
> +#define  REG_LVDS_LANE_CHA_LVDS_TERM           BIT(1)
> +#define  REG_LVDS_LANE_CHB_LVDS_TERM           BIT(0)
> +#define REG_LVDS_CM                            0x1b
> +#define  REG_LVDS_CM_CHA_LVDS_CM_ADJUST(n)     (((n) & 0x3) << 4)
> +#define  REG_LVDS_CM_CHB_LVDS_CM_ADJUST(n)     ((n) & 0x3)
> +/* Video registers */
> +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW     0x20
> +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH    0x21
> +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW  0x24
> +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH 0x25
> +#define REG_VID_CHA_SYNC_DELAY_LOW             0x28
> +#define REG_VID_CHA_SYNC_DELAY_HIGH            0x29
> +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW      0x2c
> +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH     0x2d
> +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW      0x30
> +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH     0x31
> +#define REG_VID_CHA_HORIZONTAL_BACK_PORCH      0x34
> +#define REG_VID_CHA_VERTICAL_BACK_PORCH                0x36
> +#define REG_VID_CHA_HORIZONTAL_FRONT_PORCH     0x38
> +#define REG_VID_CHA_VERTICAL_FRONT_PORCH       0x3a
> +#define REG_VID_CHA_TEST_PATTERN               0x3c
> +/* IRQ registers */
> +#define REG_IRQ_GLOBAL                         0xe0
> +#define  REG_IRQ_GLOBAL_IRQ_EN                 BIT(0)
> +#define REG_IRQ_EN                             0xe1
> +#define  REG_IRQ_EN_CHA_SYNCH_ERR_EN           BIT(7)
> +#define  REG_IRQ_EN_CHA_CRC_ERR_EN             BIT(6)
> +#define  REG_IRQ_EN_CHA_UNC_ECC_ERR_EN         BIT(5)
> +#define  REG_IRQ_EN_CHA_COR_ECC_ERR_EN         BIT(4)
> +#define  REG_IRQ_EN_CHA_LLP_ERR_EN             BIT(3)
> +#define  REG_IRQ_EN_CHA_SOT_BIT_ERR_EN         BIT(2)
> +#define  REG_IRQ_EN_CHA_PLL_UNLOCK_EN          BIT(0)
> +#define REG_IRQ_STAT                           0xe5
> +#define  REG_IRQ_STAT_CHA_SYNCH_ERR            BIT(7)
> +#define  REG_IRQ_STAT_CHA_CRC_ERR              BIT(6)
> +#define  REG_IRQ_STAT_CHA_UNC_ECC_ERR          BIT(5)
> +#define  REG_IRQ_STAT_CHA_COR_ECC_ERR          BIT(4)
> +#define  REG_IRQ_STAT_CHA_LLP_ERR              BIT(3)
> +#define  REG_IRQ_STAT_CHA_SOT_BIT_ERR          BIT(2)
> +#define  REG_IRQ_STAT_CHA_PLL_UNLOCK           BIT(0)
> +
> +enum sn65dsi83_model {
> +       MODEL_SN65DSI83,
> +       MODEL_SN65DSI84,
> +};
> +
> +struct sn65dsi83 {
> +       struct drm_bridge               bridge;
> +       struct drm_display_mode         mode;
> +       struct device                   *dev;
> +       struct regmap                   *regmap;
> +       struct device_node              *host_node;
> +       struct mipi_dsi_device          *dsi;
> +       struct drm_bridge               *panel_bridge;
> +       struct gpio_desc                *enable_gpio;
> +       int                             dsi_lanes;
> +       bool                            lvds_dual_link;
> +       bool                            lvds_dual_link_even_odd_swap;
> +};
> +
> +static const struct regmap_range sn65dsi83_readable_ranges[] = {
> +       regmap_reg_range(REG_ID(0), REG_ID(8)),
> +       regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_DSI_CLK),
> +       regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
> +       regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
> +       regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
> +       regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +                        REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
> +       regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +                        REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
> +       regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
> +                        REG_VID_CHA_SYNC_DELAY_HIGH),
> +       regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +                        REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
> +       regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +                        REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
> +       regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +                        REG_VID_CHA_HORIZONTAL_BACK_PORCH),
> +       regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
> +                        REG_VID_CHA_VERTICAL_BACK_PORCH),
> +       regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +                        REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
> +       regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +                        REG_VID_CHA_VERTICAL_FRONT_PORCH),
> +       regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
> +       regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
> +       regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_readable_table = {
> +       .yes_ranges = sn65dsi83_readable_ranges,
> +       .n_yes_ranges = ARRAY_SIZE(sn65dsi83_readable_ranges),
> +};
> +
> +static const struct regmap_range sn65dsi83_writeable_ranges[] = {
> +       regmap_reg_range(REG_RC_RESET, REG_RC_DSI_CLK),
> +       regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
> +       regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
> +       regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
> +       regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +                        REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
> +       regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +                        REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
> +       regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
> +                        REG_VID_CHA_SYNC_DELAY_HIGH),
> +       regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +                        REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
> +       regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +                        REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
> +       regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +                        REG_VID_CHA_HORIZONTAL_BACK_PORCH),
> +       regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
> +                        REG_VID_CHA_VERTICAL_BACK_PORCH),
> +       regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +                        REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
> +       regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +                        REG_VID_CHA_VERTICAL_FRONT_PORCH),
> +       regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
> +       regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
> +       regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_writeable_table = {
> +       .yes_ranges = sn65dsi83_writeable_ranges,
> +       .n_yes_ranges = ARRAY_SIZE(sn65dsi83_writeable_ranges),
> +};
> +
> +static const struct regmap_range sn65dsi83_volatile_ranges[] = {
> +       regmap_reg_range(REG_RC_RESET, REG_RC_RESET),
> +       regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
> +       regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_volatile_table = {
> +       .yes_ranges = sn65dsi83_volatile_ranges,
> +       .n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),
> +};
> +
> +static const struct regmap_config sn65dsi83_regmap_config = {
> +       .reg_bits = 8,
> +       .val_bits = 8,
> +       .rd_table = &sn65dsi83_readable_table,
> +       .wr_table = &sn65dsi83_writeable_table,
> +       .volatile_table = &sn65dsi83_volatile_table,
> +       .cache_type = REGCACHE_RBTREE,
> +       .max_register = REG_IRQ_STAT,
> +};
> +
> +static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge)
> +{
> +       return container_of(bridge, struct sn65dsi83, bridge);
> +}
> +
> +static int sn65dsi83_attach(struct drm_bridge *bridge,
> +                           enum drm_bridge_attach_flags flags)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +       struct device *dev = ctx->dev;
> +       struct mipi_dsi_device *dsi;
> +       struct mipi_dsi_host *host;
> +       int ret = 0;
> +
> +       const struct mipi_dsi_device_info info = {
> +               .type = "sn65dsi83",
> +               .channel = 0,
> +               .node = NULL,
> +       };
> +
> +       host = of_find_mipi_dsi_host_by_node(ctx->host_node);
> +       if (!host) {
> +               dev_err(dev, "failed to find dsi host\n");
> +               return -EPROBE_DEFER;
> +       }
> +
> +       dsi = mipi_dsi_device_register_full(host, &info);
> +       if (IS_ERR(dsi)) {
> +               return dev_err_probe(dev, PTR_ERR(dsi),
> +                                    "failed to create dsi device\n");
> +       }
> +
> +       ctx->dsi = dsi;
> +
> +       dsi->lanes = ctx->dsi_lanes;
> +       dsi->format = MIPI_DSI_FMT_RGB888;
> +       dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
> +
> +       ret = mipi_dsi_attach(dsi);
> +       if (ret < 0) {
> +               dev_err(dev, "failed to attach dsi to host\n");
> +               goto err_dsi_attach;
> +       }
> +
> +       return drm_bridge_attach(bridge->encoder, ctx->panel_bridge,
> +                                &ctx->bridge, flags);
> +
> +err_dsi_attach:
> +       mipi_dsi_device_unregister(dsi);
> +       return ret;
> +}
> +
> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +       /*
> +        * Reset the chip, pull EN line low for t_reset=10ms,
> +        * then high for t_en=1ms.
> +        */
> +       regcache_mark_dirty(ctx->regmap);
> +       gpiod_set_value(ctx->enable_gpio, 0);
> +       usleep_range(10000, 11000);
> +       gpiod_set_value(ctx->enable_gpio, 1);
> +       usleep_range(1000, 1100);
> +}

Whilst section 6.6 of the SN65DSI84 datasheet does list t_en as 1ms,
the initialization sequence listed in table 7.2 states
Init seq 3 - Set EN pin to Low
Wait 10 ms
Init seq 4 - Tie EN pin to High
Wait 10 ms

with the note that these are "Minimum recommended delay. It is fine to
exceed these."

Have you had alternate guidance from TI over that delay?

> +
> +static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx)
> +{
> +       /*
> +        * The encoding of the LVDS_CLK_RANGE is as follows:
> +        * 000 - 25 MHz <= LVDS_CLK < 37.5 MHz
> +        * 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz
> +        * 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz
> +        * 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz
> +        * 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz
> +        * 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz
> +        * which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that
> +        * the ends of the ranges are clamped to the supported range. Since
> +        * sn65dsi83_mode_valid() already filters the valid modes and limits
> +        * the clock to 25..154 MHz, the range calculation can be simplified
> +        * as follows:
> +        */
> +       int mode_clock = ctx->mode.clock;
> +
> +       if (ctx->lvds_dual_link)
> +               mode_clock /= 2;
> +
> +       return (mode_clock - 12500) / 25000;
> +}
> +
> +static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx)
> +{
> +       /*
> +        * The encoding of the CHA_DSI_CLK_RANGE is as follows:
> +        * 0x00 through 0x07 - Reserved
> +        * 0x08 - 40 <= DSI_CLK < 45 MHz
> +        * 0x09 - 45 <= DSI_CLK < 50 MHz
> +        * ...
> +        * 0x63 - 495 <= DSI_CLK < 500 MHz
> +        * 0x64 - 500 MHz
> +        * 0x65 through 0xFF - Reserved
> +        * which is DSI clock in 5 MHz steps, clamped to 40..500 MHz.
> +        * The DSI clock are calculated as:
> +        *  DSI_CLK = mode clock * bpp / dsi_data_lanes / 2
> +        * the 2 is there because the bus is DDR.
> +        */
> +       return DIV_ROUND_UP(clamp((unsigned int)ctx->mode.clock *
> +                           mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
> +                           ctx->dsi_lanes / 2, 40000U, 500000U), 5000U);
> +}
> +
> +static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
> +{
> +       /* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */
> +       unsigned int dsi_div = mipi_dsi_pixel_format_to_bpp(ctx->dsi->format);
> +
> +       dsi_div /= ctx->dsi_lanes;
> +
> +       if (!ctx->lvds_dual_link)
> +               dsi_div /= 2;
> +
> +       return dsi_div - 1;
> +}
> +
> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +       unsigned int pval;
> +       u16 val;
> +       int ret;
> +
> +       /* Clear reset, disable PLL */
> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +
> +       /* Reference clock derived from DSI link clock. */
> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);

(Checkpatch whinge for "Alignment should match open parenthesis" on
several lines through this function)

  Dave

> +       regmap_write(ctx->regmap, REG_DSI_CLK,
> +               REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
> +       regmap_write(ctx->regmap, REG_RC_DSI_CLK,
> +               REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
> +
> +       /* Set number of DSI lanes and LVDS link config. */
> +       regmap_write(ctx->regmap, REG_DSI_LANE,
> +               REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
> +               REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
> +               /* CHB is DSI85-only, set to default on DSI83/DSI84 */
> +               REG_DSI_LANE_CHB_DSI_LANES(3));
> +       /* No equalization. */
> +       regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
> +
> +       /* RGB888 is the only format supported so far. */
> +       val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
> +              REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
> +             (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
> +              REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
> +             REG_LVDS_FMT_CHA_24BPP_MODE;
> +       if (ctx->lvds_dual_link)
> +               val |= REG_LVDS_FMT_CHB_24BPP_MODE;
> +       else
> +               val |= REG_LVDS_FMT_LVDS_LINK_CFG;
> +
> +       regmap_write(ctx->regmap, REG_LVDS_FMT, val);
> +       regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
> +       regmap_write(ctx->regmap, REG_LVDS_LANE,
> +               (ctx->lvds_dual_link_even_odd_swap ?
> +                REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
> +               REG_LVDS_LANE_CHA_LVDS_TERM |
> +               REG_LVDS_LANE_CHB_LVDS_TERM);
> +       regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
> +
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +                         &ctx->mode.hdisplay, 2);
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +                         &ctx->mode.vdisplay, 2);
> +       val = 32 + 1;   /* 32 + 1 pixel clock to ensure proper operation */
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);
> +       val = ctx->mode.hsync_end - ctx->mode.hsync_start;
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +                         &val, 2);
> +       val = ctx->mode.vsync_end - ctx->mode.vsync_start;
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +                         &val, 2);
> +       regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +                    ctx->mode.htotal - ctx->mode.hsync_end);
> +       regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,
> +                    ctx->mode.vtotal - ctx->mode.vsync_end);
> +       regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +                    ctx->mode.hsync_start - ctx->mode.hdisplay);
> +       regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +                    ctx->mode.vsync_start - ctx->mode.vdisplay);
> +       regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
> +
> +       /* Enable PLL */
> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
> +       usleep_range(3000, 4000);
> +       ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
> +                                       pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
> +                                       1000, 100000);
> +       if (ret) {
> +               dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
> +               /* On failure, disable PLL again and exit. */
> +               regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +               return;
> +       }
> +
> +       /* Trigger reset after CSR register update. */
> +       regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);
> +
> +       /* Clear all errors that got asserted during initialization. */
> +       regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> +       regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> +}
> +
> +static void sn65dsi83_disable(struct drm_bridge *bridge)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +       /* Clear reset, disable PLL */
> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +}
> +
> +static void sn65dsi83_post_disable(struct drm_bridge *bridge)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +       /* Put the chip in reset, pull EN line low. */
> +       gpiod_set_value(ctx->enable_gpio, 0);
> +}
> +
> +static enum drm_mode_status
> +sn65dsi83_mode_valid(struct drm_bridge *bridge,
> +                    const struct drm_display_info *info,
> +                    const struct drm_display_mode *mode)
> +{
> +       /* LVDS output clock range 25..154 MHz */
> +       if (mode->clock < 25000)
> +               return MODE_CLOCK_LOW;
> +       if (mode->clock > 154000)
> +               return MODE_CLOCK_HIGH;
> +
> +       return MODE_OK;
> +}
> +
> +static void sn65dsi83_mode_set(struct drm_bridge *bridge,
> +                              const struct drm_display_mode *mode,
> +                              const struct drm_display_mode *adj)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +       ctx->mode = *adj;
> +}
> +
> +static const struct drm_bridge_funcs sn65dsi83_funcs = {
> +       .attach         = sn65dsi83_attach,
> +       .pre_enable     = sn65dsi83_pre_enable,
> +       .enable         = sn65dsi83_enable,
> +       .disable        = sn65dsi83_disable,
> +       .post_disable   = sn65dsi83_post_disable,
> +       .mode_valid     = sn65dsi83_mode_valid,
> +       .mode_set       = sn65dsi83_mode_set,
> +};
> +
> +static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
> +{
> +       struct drm_bridge *panel_bridge;
> +       struct device *dev = ctx->dev;
> +       struct device_node *endpoint;
> +       struct drm_panel *panel;
> +       int ret;
> +
> +       endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> +       ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
> +       ctx->host_node = of_graph_get_remote_port_parent(endpoint);
> +       of_node_put(endpoint);
> +
> +       if (ctx->dsi_lanes < 0 || ctx->dsi_lanes > 4)
> +               return -EINVAL;
> +       if (!ctx->host_node)
> +               return -ENODEV;
> +
> +       ctx->lvds_dual_link = false;
> +       ctx->lvds_dual_link_even_odd_swap = false;
> +       if (model != MODEL_SN65DSI83) {
> +               struct device_node *port2, *port3;
> +               int dual_link;
> +
> +               port2 = of_graph_get_port_by_id(dev->of_node, 2);
> +               port3 = of_graph_get_port_by_id(dev->of_node, 3);
> +               dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
> +               of_node_put(port2);
> +               of_node_put(port3);
> +
> +               if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
> +                       ctx->lvds_dual_link = true;
> +                       /* Odd pixels to LVDS Channel A, even pixels to B */
> +                       ctx->lvds_dual_link_even_odd_swap = false;
> +               } else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> +                       ctx->lvds_dual_link = true;
> +                       /* Even pixels to LVDS Channel A, odd pixels to B */
> +                       ctx->lvds_dual_link_even_odd_swap = true;
> +               }
> +       }
> +
> +       ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, &panel, &panel_bridge);
> +       if (ret < 0)
> +               return ret;
> +       if (panel) {
> +               panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> +               if (IS_ERR(panel_bridge))
> +                       return PTR_ERR(panel_bridge);
> +       }
> +
> +       ctx->panel_bridge = panel_bridge;
> +
> +       return 0;
> +}
> +
> +static int sn65dsi83_probe(struct i2c_client *client,
> +                          const struct i2c_device_id *id)
> +{
> +       struct device *dev = &client->dev;
> +       enum sn65dsi83_model model;
> +       struct sn65dsi83 *ctx;
> +       int ret;
> +
> +       ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +       if (!ctx)
> +               return -ENOMEM;
> +
> +       ctx->dev = dev;
> +
> +       if (dev->of_node)
> +               model = (enum sn65dsi83_model)of_device_get_match_data(dev);
> +       else
> +               model = id->driver_data;
> +
> +       ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW);
> +       if (IS_ERR(ctx->enable_gpio))
> +               return PTR_ERR(ctx->enable_gpio);
> +
> +       ret = sn65dsi83_parse_dt(ctx, model);
> +       if (ret)
> +               return ret;
> +
> +       ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config);
> +       if (IS_ERR(ctx->regmap))
> +               return PTR_ERR(ctx->regmap);
> +
> +       dev_set_drvdata(dev, ctx);
> +       i2c_set_clientdata(client, ctx);
> +
> +       ctx->bridge.funcs = &sn65dsi83_funcs;
> +       ctx->bridge.of_node = dev->of_node;
> +       drm_bridge_add(&ctx->bridge);
> +
> +       return 0;
> +}
> +
> +static int sn65dsi83_remove(struct i2c_client *client)
> +{
> +       struct sn65dsi83 *ctx = i2c_get_clientdata(client);
> +
> +       mipi_dsi_detach(ctx->dsi);
> +       mipi_dsi_device_unregister(ctx->dsi);
> +       drm_bridge_remove(&ctx->bridge);
> +       of_node_put(ctx->host_node);
> +
> +       return 0;
> +}
> +
> +static struct i2c_device_id sn65dsi83_id[] = {
> +       { "ti,sn65dsi83", MODEL_SN65DSI83 },
> +       { "ti,sn65dsi84", MODEL_SN65DSI84 },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(i2c, sn65dsi83_id);
> +
> +static const struct of_device_id sn65dsi83_match_table[] = {
> +       { .compatible = "ti,sn65dsi83", .data = (void *)MODEL_SN65DSI83 },
> +       { .compatible = "ti,sn65dsi84", .data = (void *)MODEL_SN65DSI84 },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, sn65dsi83_match_table);
> +
> +static struct i2c_driver sn65dsi83_driver = {
> +       .probe = sn65dsi83_probe,
> +       .remove = sn65dsi83_remove,
> +       .id_table = sn65dsi83_id,
> +       .driver = {
> +               .name = "sn65dsi83",
> +               .of_match_table = sn65dsi83_match_table,
> +       },
> +};
> +module_i2c_driver(sn65dsi83_driver);
> +
> +MODULE_AUTHOR("Marek Vasut <marex@denx.de>");
> +MODULE_DESCRIPTION("TI SN65DSI83 DSI to LVDS bridge driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.30.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06  9:45   ` Dave Stevenson
@ 2021-05-06 12:48     ` Marek Vasut
  2021-05-06 13:03       ` Laurent Pinchart
  2021-05-06 17:03       ` Dave Stevenson
  0 siblings, 2 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-06 12:48 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On 5/6/21 11:45 AM, Dave Stevenson wrote:
> Hi Marek

Hi,

> I'm taking an interest as there are a number of Raspberry Pi users
> trying to get this chip up and running (not there quite yet).
> A couple of fairly minor comments

Is there any readily available display unit / expansion board with this 
chip ?

[...]

>> +#define REG_DSI_LANE                           0x10
>> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL       BIT(5) /* dual or 2x single */
> 
> The bit name here seems a little odd.
> Bits 5&6 are the DSI channel mode on SN65DSI85, not the LVDS link
> config (which appears to be reg 0x18 bit 4)
> DSI_CHANNEL_MODE
> 00 – Dual-channel DSI receiver
> 01 – Single channel DSI receiver (default)
> 10 – Two single channel DSI receivers
> 11 – Reserved
> SN65DSI83 and 84 require it to be set to 01. You have that end result,
> but using an odd register name that only documents one of the 2 bits.
> 
> Is it worth documenting bit 7 as being the '85 Dual DSI link
> LEFT_RIGHT_PIXELS flag at the same time? The chip isn't supported in
> dual DSI mode at present, but defining all the registers up front
> seems reasonable.

Yes, let's fix those.

[...]

>> +       /*
>> +        * Reset the chip, pull EN line low for t_reset=10ms,
>> +        * then high for t_en=1ms.
>> +        */
>> +       regcache_mark_dirty(ctx->regmap);
>> +       gpiod_set_value(ctx->enable_gpio, 0);
>> +       usleep_range(10000, 11000);
>> +       gpiod_set_value(ctx->enable_gpio, 1);
>> +       usleep_range(1000, 1100);
>> +}
> 
> Whilst section 6.6 of the SN65DSI84 datasheet does list t_en as 1ms,
> the initialization sequence listed in table 7.2 states
> Init seq 3 - Set EN pin to Low
> Wait 10 ms
> Init seq 4 - Tie EN pin to High
> Wait 10 ms
> 
> with the note that these are "Minimum recommended delay. It is fine to
> exceed these."
> 
> Have you had alternate guidance from TI over that delay?

No, I trusted the timing diagrams in section 6.6 of the datasheet. I 
would like to believe those are correct, while the init sequence listing 
might be a copy-paste error.

[...]

>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>> +{
>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>> +       unsigned int pval;
>> +       u16 val;
>> +       int ret;
>> +
>> +       /* Clear reset, disable PLL */
>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>> +
>> +       /* Reference clock derived from DSI link clock. */
>> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
>> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
>> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> 
> (Checkpatch whinge for "Alignment should match open parenthesis" on
> several lines through this function)

Do you have any extra checkpatch settings somewhere ?
I get this on current next:

linux-2.6$ ./scripts/checkpatch.pl -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
total: 0 errors, 0 warnings, 625 lines checked

[...]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 12:48     ` Marek Vasut
@ 2021-05-06 13:03       ` Laurent Pinchart
  2021-05-06 14:57         ` Marek Vasut
  2021-05-06 17:03       ` Dave Stevenson
  1 sibling, 1 reply; 34+ messages in thread
From: Laurent Pinchart @ 2021-05-06 13:03 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Dave Stevenson, Douglas Anderson,
	DRI Development, Stephen Boyd, Philippe Schenker, Jagan Teki,
	Valentin Raevsky, Sam Ravnborg

Hi Marek,

On Thu, May 06, 2021 at 02:48:11PM +0200, Marek Vasut wrote:
> On 5/6/21 11:45 AM, Dave Stevenson wrote:
> > Hi Marek
> 
> Hi,
> 
> > I'm taking an interest as there are a number of Raspberry Pi users
> > trying to get this chip up and running (not there quite yet).
> > A couple of fairly minor comments
> 
> Is there any readily available display unit / expansion board with this 
> chip ?

For what it's worth, I have a board with a Raspberry Pi CM4 and a
SN65DSI83. It's a customer design, not an off-the-shelf part I'm afraid,
but I plan to eventually test your driver on it.

> [...]
> 
> >> +#define REG_DSI_LANE                           0x10
> >> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL       BIT(5) /* dual or 2x single */
> > 
> > The bit name here seems a little odd.
> > Bits 5&6 are the DSI channel mode on SN65DSI85, not the LVDS link
> > config (which appears to be reg 0x18 bit 4)
> > DSI_CHANNEL_MODE
> > 00 – Dual-channel DSI receiver
> > 01 – Single channel DSI receiver (default)
> > 10 – Two single channel DSI receivers
> > 11 – Reserved
> > SN65DSI83 and 84 require it to be set to 01. You have that end result,
> > but using an odd register name that only documents one of the 2 bits.
> > 
> > Is it worth documenting bit 7 as being the '85 Dual DSI link
> > LEFT_RIGHT_PIXELS flag at the same time? The chip isn't supported in
> > dual DSI mode at present, but defining all the registers up front
> > seems reasonable.
> 
> Yes, let's fix those.
> 
> [...]
> 
> >> +       /*
> >> +        * Reset the chip, pull EN line low for t_reset=10ms,
> >> +        * then high for t_en=1ms.
> >> +        */
> >> +       regcache_mark_dirty(ctx->regmap);
> >> +       gpiod_set_value(ctx->enable_gpio, 0);
> >> +       usleep_range(10000, 11000);
> >> +       gpiod_set_value(ctx->enable_gpio, 1);
> >> +       usleep_range(1000, 1100);
> >> +}
> > 
> > Whilst section 6.6 of the SN65DSI84 datasheet does list t_en as 1ms,
> > the initialization sequence listed in table 7.2 states
> > Init seq 3 - Set EN pin to Low
> > Wait 10 ms
> > Init seq 4 - Tie EN pin to High
> > Wait 10 ms
> > 
> > with the note that these are "Minimum recommended delay. It is fine to
> > exceed these."
> > 
> > Have you had alternate guidance from TI over that delay?
> 
> No, I trusted the timing diagrams in section 6.6 of the datasheet. I 
> would like to believe those are correct, while the init sequence listing 
> might be a copy-paste error.
> 
> [...]
> 
> >> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> >> +{
> >> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >> +       unsigned int pval;
> >> +       u16 val;
> >> +       int ret;
> >> +
> >> +       /* Clear reset, disable PLL */
> >> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> >> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >> +
> >> +       /* Reference clock derived from DSI link clock. */
> >> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> >> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> >> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> > 
> > (Checkpatch whinge for "Alignment should match open parenthesis" on
> > several lines through this function)
> 
> Do you have any extra checkpatch settings somewhere ?
> I get this on current next:
> 
> linux-2.6$ ./scripts/checkpatch.pl -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
> total: 0 errors, 0 warnings, 625 lines checked
> 
> [...]

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 13:03       ` Laurent Pinchart
@ 2021-05-06 14:57         ` Marek Vasut
  0 siblings, 0 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-06 14:57 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Loic Poulain, ch, Dave Stevenson, Douglas Anderson,
	DRI Development, Stephen Boyd, Philippe Schenker, Jagan Teki,
	Valentin Raevsky, Sam Ravnborg

On 5/6/21 3:03 PM, Laurent Pinchart wrote:
> Hi Marek,

Hi,

> On Thu, May 06, 2021 at 02:48:11PM +0200, Marek Vasut wrote:
>> On 5/6/21 11:45 AM, Dave Stevenson wrote:
>>> Hi Marek
>>
>> Hi,
>>
>>> I'm taking an interest as there are a number of Raspberry Pi users
>>> trying to get this chip up and running (not there quite yet).
>>> A couple of fairly minor comments
>>
>> Is there any readily available display unit / expansion board with this
>> chip ?
> 
> For what it's worth, I have a board with a Raspberry Pi CM4 and a
> SN65DSI83. It's a customer design, not an off-the-shelf part I'm afraid,
> but I plan to eventually test your driver on it.

Perfect

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-05 10:02 ` [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver Marek Vasut
  2021-05-05 12:42   ` Linus Walleij
  2021-05-06  9:45   ` Dave Stevenson
@ 2021-05-06 15:38   ` Frieder Schrempf
  2021-05-06 15:46     ` Marek Vasut
  2021-05-07 12:48   ` Dave Stevenson
       [not found]   ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.d251689f-a6ba-486d-bfa1-070ac0c167d5@emailsignatures365.codetwo.com>
  4 siblings, 1 reply; 34+ messages in thread
From: Frieder Schrempf @ 2021-05-06 15:38 UTC (permalink / raw)
  To: Marek Vasut, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 05.05.21 12:02, Marek Vasut wrote:
> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
> 
> The driver operates the chip via I2C bus. Currently the LVDS clock are
> always derived from DSI clock lane, which is the usual mode of operation.
> Support for clock from external oscillator is not implemented, but it is
> easy to add if ever needed. Only RGB888 pixel format is implemented, the
> LVDS666 is not supported, but could be added if needed.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Loic Poulain <loic.poulain@linaro.org>
> Cc: Philippe Schenker <philippe.schenker@toradex.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: Valentin Raevsky <valentin@compulab.co.il>
> To: dri-devel@lists.freedesktop.org
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work!

I have two remarks:

1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek).

2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it.

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>

> ---
> V2: - Use dev_err_probe()
>     - Set REG_RC_RESET as volatile
>     - Wait for PLL stabilization by polling REG_RC_LVDS_PLL
>     - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set
>     - Add tested DSI84 support in dual-link mode
>     - Correctly set VCOM
>     - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85
>       datasheets, with that all the reserved bits make far more sense
>       as the DSI83 and DSI84 seems to be reduced version of DSI85
> V3: - Handle the dual-link LVDS with two port panel or bridge
> ---
>  drivers/gpu/drm/bridge/Kconfig        |  10 +
>  drivers/gpu/drm/bridge/Makefile       |   1 +
>  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 639 ++++++++++++++++++++++++++
>  3 files changed, 650 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e83b8ad0d71b..32204c5f25b7 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -278,6 +278,16 @@ config DRM_TI_TFP410
>  	help
>  	  Texas Instruments TFP410 DVI/HDMI Transmitter driver
>  
> +config DRM_TI_SN65DSI83
> +	tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge"
> +	depends on OF
> +	select DRM_KMS_HELPER
> +	select REGMAP_I2C
> +	select DRM_PANEL
> +	select DRM_MIPI_DSI
> +	help
> +	  Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver
> +
>  config DRM_TI_SN65DSI86
>  	tristate "TI SN65DSI86 DSI to eDP bridge"
>  	depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b00f3b2ad572..7bb4c9df0415 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o
>  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>  obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> new file mode 100644
> index 000000000000..471df09a1c07
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -0,0 +1,639 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TI SN65DSI83,84,85 driver
> + *
> + * Currently supported:
> + * - SN65DSI83
> + *   = 1x Single-link DSI ~ 1x Single-link LVDS
> + *   - Supported
> + *   - Single-link LVDS mode tested
> + * - SN65DSI84
> + *   = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
> + *   - Supported
> + *   - Dual-link LVDS mode tested
> + *   - 2x Single-link LVDS mode unsupported
> + *     (should be easy to add by someone who has the HW)
> + * - SN65DSI85
> + *   = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
> + *   - Unsupported
> + *     (should be easy to add by someone who has the HW)
> + *
> + * Copyright (C) 2021 Marek Vasut <marex@denx.de>
> + *
> + * Based on previous work of:
> + * Valentin Raevsky <valentin@compulab.co.il>
> + * Philippe Schenker <philippe.schenker@toradex.com>
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_graph.h>
> +#include <linux/regmap.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +/* ID registers */
> +#define REG_ID(n)				(0x00 + (n))
> +/* Reset and clock registers */
> +#define REG_RC_RESET				0x09
> +#define  REG_RC_RESET_SOFT_RESET		BIT(0)
> +#define REG_RC_LVDS_PLL				0x0a
> +#define  REG_RC_LVDS_PLL_PLL_EN_STAT		BIT(7)
> +#define  REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n)	(((n) & 0x7) << 1)
> +#define  REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY	BIT(0)
> +#define REG_RC_DSI_CLK				0x0b
> +#define  REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n)	(((n) & 0x1f) << 3)
> +#define  REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n)	((n) & 0x3)
> +#define REG_RC_PLL_EN				0x0d
> +#define  REG_RC_PLL_EN_PLL_EN			BIT(0)
> +/* DSI registers */
> +#define REG_DSI_LANE				0x10
> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL	BIT(5) /* dual or 2x single */
> +#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
> +#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
> +#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
> +#define REG_DSI_EQ				0x11
> +#define  REG_DSI_EQ_CHA_DSI_DATA_EQ(n)		(((n) & 0x3) << 6)
> +#define  REG_DSI_EQ_CHA_DSI_CLK_EQ(n)		(((n) & 0x3) << 2)
> +#define REG_DSI_CLK				0x12
> +#define  REG_DSI_CLK_CHA_DSI_CLK_RANGE(n)	((n) & 0xff)
> +/* LVDS registers */
> +#define REG_LVDS_FMT				0x18
> +#define  REG_LVDS_FMT_DE_NEG_POLARITY		BIT(7)
> +#define  REG_LVDS_FMT_HS_NEG_POLARITY		BIT(6)
> +#define  REG_LVDS_FMT_VS_NEG_POLARITY		BIT(5)
> +#define  REG_LVDS_FMT_LVDS_LINK_CFG		BIT(4)	/* 0:AB 1:A-only */
> +#define  REG_LVDS_FMT_CHA_24BPP_MODE		BIT(3)
> +#define  REG_LVDS_FMT_CHB_24BPP_MODE		BIT(2)
> +#define  REG_LVDS_FMT_CHA_24BPP_FORMAT1		BIT(1)
> +#define  REG_LVDS_FMT_CHB_24BPP_FORMAT1		BIT(0)
> +#define REG_LVDS_VCOM				0x19
> +#define  REG_LVDS_VCOM_CHA_LVDS_VOCM		BIT(6)
> +#define  REG_LVDS_VCOM_CHB_LVDS_VOCM		BIT(4)
> +#define  REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(n)	(((n) & 0x3) << 2)
> +#define  REG_LVDS_VCOM_CHB_LVDS_VOD_SWING(n)	((n) & 0x3)
> +#define REG_LVDS_LANE				0x1a
> +#define  REG_LVDS_LANE_EVEN_ODD_SWAP		BIT(6)
> +#define  REG_LVDS_LANE_CHA_REVERSE_LVDS		BIT(5)
> +#define  REG_LVDS_LANE_CHB_REVERSE_LVDS		BIT(4)
> +#define  REG_LVDS_LANE_CHA_LVDS_TERM		BIT(1)
> +#define  REG_LVDS_LANE_CHB_LVDS_TERM		BIT(0)
> +#define REG_LVDS_CM				0x1b
> +#define  REG_LVDS_CM_CHA_LVDS_CM_ADJUST(n)	(((n) & 0x3) << 4)
> +#define  REG_LVDS_CM_CHB_LVDS_CM_ADJUST(n)	((n) & 0x3)
> +/* Video registers */
> +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW	0x20
> +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH	0x21
> +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW	0x24
> +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH	0x25
> +#define REG_VID_CHA_SYNC_DELAY_LOW		0x28
> +#define REG_VID_CHA_SYNC_DELAY_HIGH		0x29
> +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW	0x2c
> +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH	0x2d
> +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW	0x30
> +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH	0x31
> +#define REG_VID_CHA_HORIZONTAL_BACK_PORCH	0x34
> +#define REG_VID_CHA_VERTICAL_BACK_PORCH		0x36
> +#define REG_VID_CHA_HORIZONTAL_FRONT_PORCH	0x38
> +#define REG_VID_CHA_VERTICAL_FRONT_PORCH	0x3a
> +#define REG_VID_CHA_TEST_PATTERN		0x3c
> +/* IRQ registers */
> +#define REG_IRQ_GLOBAL				0xe0
> +#define  REG_IRQ_GLOBAL_IRQ_EN			BIT(0)
> +#define REG_IRQ_EN				0xe1
> +#define  REG_IRQ_EN_CHA_SYNCH_ERR_EN		BIT(7)
> +#define  REG_IRQ_EN_CHA_CRC_ERR_EN		BIT(6)
> +#define  REG_IRQ_EN_CHA_UNC_ECC_ERR_EN		BIT(5)
> +#define  REG_IRQ_EN_CHA_COR_ECC_ERR_EN		BIT(4)
> +#define  REG_IRQ_EN_CHA_LLP_ERR_EN		BIT(3)
> +#define  REG_IRQ_EN_CHA_SOT_BIT_ERR_EN		BIT(2)
> +#define  REG_IRQ_EN_CHA_PLL_UNLOCK_EN		BIT(0)
> +#define REG_IRQ_STAT				0xe5
> +#define  REG_IRQ_STAT_CHA_SYNCH_ERR		BIT(7)
> +#define  REG_IRQ_STAT_CHA_CRC_ERR		BIT(6)
> +#define  REG_IRQ_STAT_CHA_UNC_ECC_ERR		BIT(5)
> +#define  REG_IRQ_STAT_CHA_COR_ECC_ERR		BIT(4)
> +#define  REG_IRQ_STAT_CHA_LLP_ERR		BIT(3)
> +#define  REG_IRQ_STAT_CHA_SOT_BIT_ERR		BIT(2)
> +#define  REG_IRQ_STAT_CHA_PLL_UNLOCK		BIT(0)
> +
> +enum sn65dsi83_model {
> +	MODEL_SN65DSI83,
> +	MODEL_SN65DSI84,
> +};
> +
> +struct sn65dsi83 {
> +	struct drm_bridge		bridge;
> +	struct drm_display_mode		mode;
> +	struct device			*dev;
> +	struct regmap			*regmap;
> +	struct device_node		*host_node;
> +	struct mipi_dsi_device		*dsi;
> +	struct drm_bridge		*panel_bridge;
> +	struct gpio_desc		*enable_gpio;
> +	int				dsi_lanes;
> +	bool				lvds_dual_link;
> +	bool				lvds_dual_link_even_odd_swap;
> +};
> +
> +static const struct regmap_range sn65dsi83_readable_ranges[] = {
> +	regmap_reg_range(REG_ID(0), REG_ID(8)),
> +	regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_DSI_CLK),
> +	regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
> +	regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
> +	regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
> +	regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +			 REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +			 REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
> +	regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
> +			 REG_VID_CHA_SYNC_DELAY_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
> +			 REG_VID_CHA_VERTICAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +			 REG_VID_CHA_VERTICAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
> +	regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
> +	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_readable_table = {
> +	.yes_ranges = sn65dsi83_readable_ranges,
> +	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_readable_ranges),
> +};
> +
> +static const struct regmap_range sn65dsi83_writeable_ranges[] = {
> +	regmap_reg_range(REG_RC_RESET, REG_RC_DSI_CLK),
> +	regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
> +	regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
> +	regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
> +	regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +			 REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +			 REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
> +	regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
> +			 REG_VID_CHA_SYNC_DELAY_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
> +			 REG_VID_CHA_VERTICAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +			 REG_VID_CHA_VERTICAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
> +	regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
> +	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_writeable_table = {
> +	.yes_ranges = sn65dsi83_writeable_ranges,
> +	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_writeable_ranges),
> +};
> +
> +static const struct regmap_range sn65dsi83_volatile_ranges[] = {
> +	regmap_reg_range(REG_RC_RESET, REG_RC_RESET),
> +	regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
> +	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_volatile_table = {
> +	.yes_ranges = sn65dsi83_volatile_ranges,
> +	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),
> +};
> +
> +static const struct regmap_config sn65dsi83_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.rd_table = &sn65dsi83_readable_table,
> +	.wr_table = &sn65dsi83_writeable_table,
> +	.volatile_table = &sn65dsi83_volatile_table,
> +	.cache_type = REGCACHE_RBTREE,
> +	.max_register = REG_IRQ_STAT,
> +};
> +
> +static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge)
> +{
> +	return container_of(bridge, struct sn65dsi83, bridge);
> +}
> +
> +static int sn65dsi83_attach(struct drm_bridge *bridge,
> +			    enum drm_bridge_attach_flags flags)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +	struct device *dev = ctx->dev;
> +	struct mipi_dsi_device *dsi;
> +	struct mipi_dsi_host *host;
> +	int ret = 0;
> +
> +	const struct mipi_dsi_device_info info = {
> +		.type = "sn65dsi83",
> +		.channel = 0,
> +		.node = NULL,
> +	};
> +
> +	host = of_find_mipi_dsi_host_by_node(ctx->host_node);
> +	if (!host) {
> +		dev_err(dev, "failed to find dsi host\n");
> +		return -EPROBE_DEFER;
> +	}
> +
> +	dsi = mipi_dsi_device_register_full(host, &info);
> +	if (IS_ERR(dsi)) {
> +		return dev_err_probe(dev, PTR_ERR(dsi),
> +				     "failed to create dsi device\n");
> +	}
> +
> +	ctx->dsi = dsi;
> +
> +	dsi->lanes = ctx->dsi_lanes;
> +	dsi->format = MIPI_DSI_FMT_RGB888;
> +	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
> +
> +	ret = mipi_dsi_attach(dsi);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to attach dsi to host\n");
> +		goto err_dsi_attach;
> +	}
> +
> +	return drm_bridge_attach(bridge->encoder, ctx->panel_bridge,
> +				 &ctx->bridge, flags);
> +
> +err_dsi_attach:
> +	mipi_dsi_device_unregister(dsi);
> +	return ret;
> +}
> +
> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	/*
> +	 * Reset the chip, pull EN line low for t_reset=10ms,
> +	 * then high for t_en=1ms.
> +	 */
> +	regcache_mark_dirty(ctx->regmap);
> +	gpiod_set_value(ctx->enable_gpio, 0);
> +	usleep_range(10000, 11000);
> +	gpiod_set_value(ctx->enable_gpio, 1);
> +	usleep_range(1000, 1100);
> +}
> +
> +static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx)
> +{
> +	/*
> +	 * The encoding of the LVDS_CLK_RANGE is as follows:
> +	 * 000 - 25 MHz <= LVDS_CLK < 37.5 MHz
> +	 * 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz
> +	 * 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz
> +	 * 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz
> +	 * 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz
> +	 * 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz
> +	 * which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that
> +	 * the ends of the ranges are clamped to the supported range. Since
> +	 * sn65dsi83_mode_valid() already filters the valid modes and limits
> +	 * the clock to 25..154 MHz, the range calculation can be simplified
> +	 * as follows:
> +	 */
> +	int mode_clock = ctx->mode.clock;
> +
> +	if (ctx->lvds_dual_link)
> +		mode_clock /= 2;
> +
> +	return (mode_clock - 12500) / 25000;
> +}
> +
> +static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx)
> +{
> +	/*
> +	 * The encoding of the CHA_DSI_CLK_RANGE is as follows:
> +	 * 0x00 through 0x07 - Reserved
> +	 * 0x08 - 40 <= DSI_CLK < 45 MHz
> +	 * 0x09 - 45 <= DSI_CLK < 50 MHz
> +	 * ...
> +	 * 0x63 - 495 <= DSI_CLK < 500 MHz
> +	 * 0x64 - 500 MHz
> +	 * 0x65 through 0xFF - Reserved
> +	 * which is DSI clock in 5 MHz steps, clamped to 40..500 MHz.
> +	 * The DSI clock are calculated as:
> +	 *  DSI_CLK = mode clock * bpp / dsi_data_lanes / 2
> +	 * the 2 is there because the bus is DDR.
> +	 */
> +	return DIV_ROUND_UP(clamp((unsigned int)ctx->mode.clock *
> +			    mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
> +			    ctx->dsi_lanes / 2, 40000U, 500000U), 5000U);
> +}
> +
> +static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
> +{
> +	/* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */
> +	unsigned int dsi_div = mipi_dsi_pixel_format_to_bpp(ctx->dsi->format);
> +
> +	dsi_div /= ctx->dsi_lanes;
> +
> +	if (!ctx->lvds_dual_link)
> +		dsi_div /= 2;
> +
> +	return dsi_div - 1;
> +}
> +
> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +	unsigned int pval;
> +	u16 val;
> +	int ret;
> +
> +	/* Clear reset, disable PLL */
> +	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> +	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +
> +	/* Reference clock derived from DSI link clock. */
> +	regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> +		REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> +		REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> +	regmap_write(ctx->regmap, REG_DSI_CLK,
> +		REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
> +	regmap_write(ctx->regmap, REG_RC_DSI_CLK,
> +		REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
> +
> +	/* Set number of DSI lanes and LVDS link config. */
> +	regmap_write(ctx->regmap, REG_DSI_LANE,
> +		REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
> +		REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
> +		/* CHB is DSI85-only, set to default on DSI83/DSI84 */
> +		REG_DSI_LANE_CHB_DSI_LANES(3));
> +	/* No equalization. */
> +	regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
> +
> +	/* RGB888 is the only format supported so far. */
> +	val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
> +	       REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
> +	      (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
> +	       REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
> +	      REG_LVDS_FMT_CHA_24BPP_MODE;
> +	if (ctx->lvds_dual_link)
> +		val |= REG_LVDS_FMT_CHB_24BPP_MODE;
> +	else
> +		val |= REG_LVDS_FMT_LVDS_LINK_CFG;
> +
> +	regmap_write(ctx->regmap, REG_LVDS_FMT, val);
> +	regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
> +	regmap_write(ctx->regmap, REG_LVDS_LANE,
> +		(ctx->lvds_dual_link_even_odd_swap ?
> +		 REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
> +		REG_LVDS_LANE_CHA_LVDS_TERM |
> +		REG_LVDS_LANE_CHB_LVDS_TERM);
> +	regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
> +
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +			  &ctx->mode.hdisplay, 2);
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +			  &ctx->mode.vdisplay, 2);
> +	val = 32 + 1;	/* 32 + 1 pixel clock to ensure proper operation */
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);
> +	val = ctx->mode.hsync_end - ctx->mode.hsync_start;
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +			  &val, 2);
> +	val = ctx->mode.vsync_end - ctx->mode.vsync_start;
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +			  &val, 2);
> +	regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +		     ctx->mode.htotal - ctx->mode.hsync_end);
> +	regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,
> +		     ctx->mode.vtotal - ctx->mode.vsync_end);
> +	regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +		     ctx->mode.hsync_start - ctx->mode.hdisplay);
> +	regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +		     ctx->mode.vsync_start - ctx->mode.vdisplay);
> +	regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
> +
> +	/* Enable PLL */
> +	regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
> +	usleep_range(3000, 4000);
> +	ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
> +					pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
> +					1000, 100000);
> +	if (ret) {
> +		dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
> +		/* On failure, disable PLL again and exit. */
> +		regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +		return;
> +	}
> +
> +	/* Trigger reset after CSR register update. */
> +	regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);
> +
> +	/* Clear all errors that got asserted during initialization. */
> +	regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> +	regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> +}
> +
> +static void sn65dsi83_disable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	/* Clear reset, disable PLL */
> +	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> +	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +}
> +
> +static void sn65dsi83_post_disable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	/* Put the chip in reset, pull EN line low. */
> +	gpiod_set_value(ctx->enable_gpio, 0);
> +}
> +
> +static enum drm_mode_status
> +sn65dsi83_mode_valid(struct drm_bridge *bridge,
> +		     const struct drm_display_info *info,
> +		     const struct drm_display_mode *mode)
> +{
> +	/* LVDS output clock range 25..154 MHz */
> +	if (mode->clock < 25000)
> +		return MODE_CLOCK_LOW;
> +	if (mode->clock > 154000)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +
> +static void sn65dsi83_mode_set(struct drm_bridge *bridge,
> +			       const struct drm_display_mode *mode,
> +			       const struct drm_display_mode *adj)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	ctx->mode = *adj;
> +}
> +
> +static const struct drm_bridge_funcs sn65dsi83_funcs = {
> +	.attach		= sn65dsi83_attach,
> +	.pre_enable	= sn65dsi83_pre_enable,
> +	.enable		= sn65dsi83_enable,
> +	.disable	= sn65dsi83_disable,
> +	.post_disable	= sn65dsi83_post_disable,
> +	.mode_valid	= sn65dsi83_mode_valid,
> +	.mode_set	= sn65dsi83_mode_set,
> +};
> +
> +static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
> +{
> +	struct drm_bridge *panel_bridge;
> +	struct device *dev = ctx->dev;
> +	struct device_node *endpoint;
> +	struct drm_panel *panel;
> +	int ret;
> +
> +	endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> +	ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
> +	ctx->host_node = of_graph_get_remote_port_parent(endpoint);
> +	of_node_put(endpoint);
> +
> +	if (ctx->dsi_lanes < 0 || ctx->dsi_lanes > 4)
> +		return -EINVAL;
> +	if (!ctx->host_node)
> +		return -ENODEV;
> +
> +	ctx->lvds_dual_link = false;
> +	ctx->lvds_dual_link_even_odd_swap = false;
> +	if (model != MODEL_SN65DSI83) {
> +		struct device_node *port2, *port3;
> +		int dual_link;
> +
> +		port2 = of_graph_get_port_by_id(dev->of_node, 2);
> +		port3 = of_graph_get_port_by_id(dev->of_node, 3);
> +		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
> +		of_node_put(port2);
> +		of_node_put(port3);
> +
> +		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
> +			ctx->lvds_dual_link = true;
> +			/* Odd pixels to LVDS Channel A, even pixels to B */
> +			ctx->lvds_dual_link_even_odd_swap = false;
> +		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> +			ctx->lvds_dual_link = true;
> +			/* Even pixels to LVDS Channel A, odd pixels to B */
> +			ctx->lvds_dual_link_even_odd_swap = true;
> +		}
> +	}
> +
> +	ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, &panel, &panel_bridge);
> +	if (ret < 0)
> +		return ret;
> +	if (panel) {
> +		panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> +		if (IS_ERR(panel_bridge))
> +			return PTR_ERR(panel_bridge);
> +	}
> +
> +	ctx->panel_bridge = panel_bridge;
> +
> +	return 0;
> +}
> +
> +static int sn65dsi83_probe(struct i2c_client *client,
> +			   const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	enum sn65dsi83_model model;
> +	struct sn65dsi83 *ctx;
> +	int ret;
> +
> +	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ctx->dev = dev;
> +
> +	if (dev->of_node)
> +		model = (enum sn65dsi83_model)of_device_get_match_data(dev);
> +	else
> +		model = id->driver_data;
> +
> +	ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(ctx->enable_gpio))
> +		return PTR_ERR(ctx->enable_gpio);
> +
> +	ret = sn65dsi83_parse_dt(ctx, model);
> +	if (ret)
> +		return ret;
> +
> +	ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config);
> +	if (IS_ERR(ctx->regmap))
> +		return PTR_ERR(ctx->regmap);
> +
> +	dev_set_drvdata(dev, ctx);
> +	i2c_set_clientdata(client, ctx);
> +
> +	ctx->bridge.funcs = &sn65dsi83_funcs;
> +	ctx->bridge.of_node = dev->of_node;
> +	drm_bridge_add(&ctx->bridge);
> +
> +	return 0;
> +}
> +
> +static int sn65dsi83_remove(struct i2c_client *client)
> +{
> +	struct sn65dsi83 *ctx = i2c_get_clientdata(client);
> +
> +	mipi_dsi_detach(ctx->dsi);
> +	mipi_dsi_device_unregister(ctx->dsi);
> +	drm_bridge_remove(&ctx->bridge);
> +	of_node_put(ctx->host_node);
> +
> +	return 0;
> +}
> +
> +static struct i2c_device_id sn65dsi83_id[] = {
> +	{ "ti,sn65dsi83", MODEL_SN65DSI83 },
> +	{ "ti,sn65dsi84", MODEL_SN65DSI84 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(i2c, sn65dsi83_id);
> +
> +static const struct of_device_id sn65dsi83_match_table[] = {
> +	{ .compatible = "ti,sn65dsi83", .data = (void *)MODEL_SN65DSI83 },
> +	{ .compatible = "ti,sn65dsi84", .data = (void *)MODEL_SN65DSI84 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, sn65dsi83_match_table);
> +
> +static struct i2c_driver sn65dsi83_driver = {
> +	.probe = sn65dsi83_probe,
> +	.remove = sn65dsi83_remove,
> +	.id_table = sn65dsi83_id,
> +	.driver = {
> +		.name = "sn65dsi83",
> +		.of_match_table = sn65dsi83_match_table,
> +	},
> +};
> +module_i2c_driver(sn65dsi83_driver);
> +
> +MODULE_AUTHOR("Marek Vasut <marex@denx.de>");
> +MODULE_DESCRIPTION("TI SN65DSI83 DSI to LVDS bridge driver");
> +MODULE_LICENSE("GPL v2");
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 15:38   ` Frieder Schrempf
@ 2021-05-06 15:46     ` Marek Vasut
  2021-05-06 16:03       ` Frieder Schrempf
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-06 15:46 UTC (permalink / raw)
  To: Frieder Schrempf, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 5/6/21 5:38 PM, Frieder Schrempf wrote:
[...]
> Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work!
> 
> I have two remarks:
> 
> 1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek).

I suspect there is indeed something with the DSIM going on, I'll keep 
you posted if I find something out.

> 2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it.

Hmm, in that conversion supposed to happen in this bridge driver or 
should MXSFB handle the SPWG pixel format ? Or should the DSIM bridge do 
something about that ?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 15:46     ` Marek Vasut
@ 2021-05-06 16:03       ` Frieder Schrempf
  2021-05-06 20:51         ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Frieder Schrempf @ 2021-05-06 16:03 UTC (permalink / raw)
  To: Marek Vasut, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 06.05.21 17:46, Marek Vasut wrote:
> On 5/6/21 5:38 PM, Frieder Schrempf wrote:
> [...]
>> Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work!
>>
>> I have two remarks:
>>
>> 1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek).
> 
> I suspect there is indeed something with the DSIM going on, I'll keep you posted if I find something out.
> 
>> 2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it.
> 
> Hmm, in that conversion supposed to happen in this bridge driver or should MXSFB handle the SPWG pixel format ? Or should the DSIM bridge do something about that ?

As far as I understand it the conversion is already done by the DSI84 without any extra configuration necessary. The only thing that needs to be done is selecting the LVDS output format via CHx_24BPP_MODE and CHx_24BPP_FORMAT1 which the driver currently hardcodes to 24bpp aka MEDIA_BUS_FMT_RGB888_1X7X4_SPWG. I think the DSI input format is always 24bpp aka MEDIA_BUS_FMT_RGB888_1X24.

So I wonder where the format actually is evaluated. Could it be that it is passed down to the LCDIF and changes its output format which causes the data passed by DSIM to the DSI84 to already be in the SPWG format? If that's the case we maybe need a way to specify MEDIA_BUS_FMT_RGB888_1X24 as input bus format for the DSI84 so it doesn't pass on the panel's format? Only a wild guess, no idea if it really works like that.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 12:48     ` Marek Vasut
  2021-05-06 13:03       ` Laurent Pinchart
@ 2021-05-06 17:03       ` Dave Stevenson
  2021-05-06 20:49         ` Marek Vasut
  1 sibling, 1 reply; 34+ messages in thread
From: Dave Stevenson @ 2021-05-06 17:03 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On Thu, 6 May 2021 at 13:48, Marek Vasut <marex@denx.de> wrote:
>
> On 5/6/21 11:45 AM, Dave Stevenson wrote:
> > Hi Marek
>
> Hi,
>
> > I'm taking an interest as there are a number of Raspberry Pi users
> > trying to get this chip up and running (not there quite yet).
> > A couple of fairly minor comments
>
> Is there any readily available display unit / expansion board with this
> chip ?

Not that I'm aware of. It's a forum thread[1] where two different
users are trying to bring up the chip, each with their own boards. One
has just reported they have got it working with Jagan's patch set but
with a load of hacks to both bridge and DSI drivers.
If Laurent has a board then that may be a useful further test route.

I'm not 100% convinced that the Pi is doing exactly the right thing
with regard LP-11 state during initialisation, but hope to get into
the lab to check either tomorrow or early next week.

[1] https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=305690

> [...]
>
> >> +#define REG_DSI_LANE                           0x10
> >> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL       BIT(5) /* dual or 2x single */
> >
> > The bit name here seems a little odd.
> > Bits 5&6 are the DSI channel mode on SN65DSI85, not the LVDS link
> > config (which appears to be reg 0x18 bit 4)
> > DSI_CHANNEL_MODE
> > 00 – Dual-channel DSI receiver
> > 01 – Single channel DSI receiver (default)
> > 10 – Two single channel DSI receivers
> > 11 – Reserved
> > SN65DSI83 and 84 require it to be set to 01. You have that end result,
> > but using an odd register name that only documents one of the 2 bits.
> >
> > Is it worth documenting bit 7 as being the '85 Dual DSI link
> > LEFT_RIGHT_PIXELS flag at the same time? The chip isn't supported in
> > dual DSI mode at present, but defining all the registers up front
> > seems reasonable.
>
> Yes, let's fix those.
>
> [...]
>
> >> +       /*
> >> +        * Reset the chip, pull EN line low for t_reset=10ms,
> >> +        * then high for t_en=1ms.
> >> +        */
> >> +       regcache_mark_dirty(ctx->regmap);
> >> +       gpiod_set_value(ctx->enable_gpio, 0);
> >> +       usleep_range(10000, 11000);
> >> +       gpiod_set_value(ctx->enable_gpio, 1);
> >> +       usleep_range(1000, 1100);
> >> +}
> >
> > Whilst section 6.6 of the SN65DSI84 datasheet does list t_en as 1ms,
> > the initialization sequence listed in table 7.2 states
> > Init seq 3 - Set EN pin to Low
> > Wait 10 ms
> > Init seq 4 - Tie EN pin to High
> > Wait 10 ms
> >
> > with the note that these are "Minimum recommended delay. It is fine to
> > exceed these."
> >
> > Have you had alternate guidance from TI over that delay?
>
> No, I trusted the timing diagrams in section 6.6 of the datasheet. I
> would like to believe those are correct, while the init sequence listing
> might be a copy-paste error.

It's a tough one to call as to which is going to be correct. I just
thought I'd flag it.

> [...]
>
> >> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> >> +{
> >> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >> +       unsigned int pval;
> >> +       u16 val;
> >> +       int ret;
> >> +
> >> +       /* Clear reset, disable PLL */
> >> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> >> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >> +
> >> +       /* Reference clock derived from DSI link clock. */
> >> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> >> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> >> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> >
> > (Checkpatch whinge for "Alignment should match open parenthesis" on
> > several lines through this function)
>
> Do you have any extra checkpatch settings somewhere ?
> I get this on current next:
>
> linux-2.6$ ./scripts/checkpatch.pl -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
> total: 0 errors, 0 warnings, 625 lines checked

Sorry, yes "./scripts/checkpatch.pl --strict --codespell". Too much
working in the linux-media realms where --strict is required :-/

  Dave

> [...]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 17:03       ` Dave Stevenson
@ 2021-05-06 20:49         ` Marek Vasut
  2021-05-07  8:55           ` Dave Stevenson
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-06 20:49 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On 5/6/21 7:03 PM, Dave Stevenson wrote:
> On Thu, 6 May 2021 at 13:48, Marek Vasut <marex@denx.de> wrote:
>>
>> On 5/6/21 11:45 AM, Dave Stevenson wrote:
>>> Hi Marek
>>
>> Hi,
>>
>>> I'm taking an interest as there are a number of Raspberry Pi users
>>> trying to get this chip up and running (not there quite yet).
>>> A couple of fairly minor comments
>>
>> Is there any readily available display unit / expansion board with this
>> chip ?
> 
> Not that I'm aware of. It's a forum thread[1] where two different
> users are trying to bring up the chip, each with their own boards. One
> has just reported they have got it working with Jagan's patch set but
> with a load of hacks to both bridge and DSI drivers.
> If Laurent has a board then that may be a useful further test route.
> 
> I'm not 100% convinced that the Pi is doing exactly the right thing
> with regard LP-11 state during initialisation, but hope to get into
> the lab to check either tomorrow or early next week.

Good

> [1] https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=305690
> 
>> [...]
>>
>>>> +#define REG_DSI_LANE                           0x10
>>>> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL       BIT(5) /* dual or 2x single */
>>>
>>> The bit name here seems a little odd.
>>> Bits 5&6 are the DSI channel mode on SN65DSI85, not the LVDS link
>>> config (which appears to be reg 0x18 bit 4)
>>> DSI_CHANNEL_MODE
>>> 00 – Dual-channel DSI receiver
>>> 01 – Single channel DSI receiver (default)
>>> 10 – Two single channel DSI receivers
>>> 11 – Reserved
>>> SN65DSI83 and 84 require it to be set to 01. You have that end result,
>>> but using an odd register name that only documents one of the 2 bits.
>>>
>>> Is it worth documenting bit 7 as being the '85 Dual DSI link
>>> LEFT_RIGHT_PIXELS flag at the same time? The chip isn't supported in
>>> dual DSI mode at present, but defining all the registers up front
>>> seems reasonable.
>>
>> Yes, let's fix those.
>>
>> [...]
>>
>>>> +       /*
>>>> +        * Reset the chip, pull EN line low for t_reset=10ms,
>>>> +        * then high for t_en=1ms.
>>>> +        */
>>>> +       regcache_mark_dirty(ctx->regmap);
>>>> +       gpiod_set_value(ctx->enable_gpio, 0);
>>>> +       usleep_range(10000, 11000);
>>>> +       gpiod_set_value(ctx->enable_gpio, 1);
>>>> +       usleep_range(1000, 1100);
>>>> +}
>>>
>>> Whilst section 6.6 of the SN65DSI84 datasheet does list t_en as 1ms,
>>> the initialization sequence listed in table 7.2 states
>>> Init seq 3 - Set EN pin to Low
>>> Wait 10 ms
>>> Init seq 4 - Tie EN pin to High
>>> Wait 10 ms
>>>
>>> with the note that these are "Minimum recommended delay. It is fine to
>>> exceed these."
>>>
>>> Have you had alternate guidance from TI over that delay?
>>
>> No, I trusted the timing diagrams in section 6.6 of the datasheet. I
>> would like to believe those are correct, while the init sequence listing
>> might be a copy-paste error.
> 
> It's a tough one to call as to which is going to be correct. I just
> thought I'd flag it.
> 
>> [...]
>>
>>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>>>> +{
>>>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>> +       unsigned int pval;
>>>> +       u16 val;
>>>> +       int ret;
>>>> +
>>>> +       /* Clear reset, disable PLL */
>>>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>>>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>> +
>>>> +       /* Reference clock derived from DSI link clock. */
>>>> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
>>>> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
>>>> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
>>>
>>> (Checkpatch whinge for "Alignment should match open parenthesis" on
>>> several lines through this function)
>>
>> Do you have any extra checkpatch settings somewhere ?
>> I get this on current next:
>>
>> linux-2.6$ ./scripts/checkpatch.pl -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
>> total: 0 errors, 0 warnings, 625 lines checked
> 
> Sorry, yes "./scripts/checkpatch.pl --strict --codespell". Too much
> working in the linux-media realms where --strict is required :-/

So I can add a variable , assign it the value of 
sn65dsi83_get_lvds_range(ctx) and then do 
REG_RC_LVDS_PLL_LVDS_CLK_RANGE(val), but that doesn't really improve the 
readability at all, it just adds extra indirection.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 16:03       ` Frieder Schrempf
@ 2021-05-06 20:51         ` Marek Vasut
  2021-05-07  9:17           ` Dave Stevenson
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-06 20:51 UTC (permalink / raw)
  To: Frieder Schrempf, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 5/6/21 6:03 PM, Frieder Schrempf wrote:
> On 06.05.21 17:46, Marek Vasut wrote:
>> On 5/6/21 5:38 PM, Frieder Schrempf wrote:
>> [...]
>>> Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work!
>>>
>>> I have two remarks:
>>>
>>> 1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek).
>>
>> I suspect there is indeed something with the DSIM going on, I'll keep you posted if I find something out.
>>
>>> 2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it.
>>
>> Hmm, in that conversion supposed to happen in this bridge driver or should MXSFB handle the SPWG pixel format ? Or should the DSIM bridge do something about that ?
> 
> As far as I understand it the conversion is already done by the DSI84 without any extra configuration necessary. The only thing that needs to be done is selecting the LVDS output format via CHx_24BPP_MODE and CHx_24BPP_FORMAT1 which the driver currently hardcodes to 24bpp aka MEDIA_BUS_FMT_RGB888_1X7X4_SPWG. I think the DSI input format is always 24bpp aka MEDIA_BUS_FMT_RGB888_1X24.

The DSI is MEDIA_BUS_FMT_RGB888_1X24, yes.

So maybe this bridge driver has to somehow deal with 
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ? Except I haven't seen such a thing 
implemented in other bridge drivers, so input would be welcome on this.

> So I wonder where the format actually is evaluated. Could it be that it is passed down to the LCDIF and changes its output format which causes the data passed by DSIM to the DSI84 to already be in the SPWG format? If that's the case we maybe need a way to specify MEDIA_BUS_FMT_RGB888_1X24 as input bus format for the DSI84 so it doesn't pass on the panel's format? Only a wild guess, no idea if it really works like that.

I _think_ the bridge must somehow handle the 
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG <-> MEDIA_BUS_FMT_RGB888_1X24 conversion.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
  2021-05-05 10:02 ` Marek Vasut
@ 2021-05-07  1:00   ` Rob Herring
  -1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2021-05-07  1:00 UTC (permalink / raw)
  To: Marek Vasut
  Cc: dri-devel, ch, Douglas Anderson, Jagan Teki, Laurent Pinchart,
	Linus Walleij, Sam Ravnborg, Stephen Boyd, devicetree

On Wed, May 05, 2021 at 12:02:17PM +0200, Marek Vasut wrote:
> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: devicetree@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Add compatible string for SN65DSI84, since this is now tested on it
> V3: - Add 0x2c as valid i2c address
>     - Switch to schemas/graph.yaml
>     - Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
>     - Indent example by 4 spaces
>     - Handle dual-link LVDS with two ports and describe the second DSI
>       channel-B port as well. Based on the register defaults of DSI83
>       and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
>       hardware is present in all the chips, so just reuse port@0 and 2
>       for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
>       that is supported
> ---
>  .../bindings/display/bridge/ti,sn65dsi83.yaml | 171 ++++++++++++++++++
>  1 file changed, 171 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> new file mode 100644
> index 000000000000..4e7df92446a9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -0,0 +1,171 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
> +
> +maintainers:
> +  - Marek Vasut <marex@denx.de>
> +
> +description: |
> +  Texas Instruments SN65DSI83 1x Single-link MIPI DSI
> +  to 1x Single-link LVDS
> +  https://www.ti.com/lit/gpn/sn65dsi83
> +  Texas Instruments SN65DSI84 1x Single-link MIPI DSI
> +  to 1x Dual-link or 2x Single-link LVDS
> +  https://www.ti.com/lit/gpn/sn65dsi84
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: ti,sn65dsi83
> +      - const: ti,sn65dsi84

Use 'enum' instead of oneOf+const.

> +
> +  reg:
> +    oneOf:
> +      - const: 0x2c
> +      - const: 0x2d

Ditto

> +
> +  enable-gpios:
> +    maxItems: 1
> +    description: GPIO specifier for bridge_en pin (active high).
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for MIPI DSI Channel-A input
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base

This should actually be video-interfaces.yaml since you use one of the 
properties from it.

> +            unevaluatedProperties: false
> +
> +            properties:
> +              data-lanes:
> +                description: array of physical DSI data lane indexes.
> +                minItems: 1
> +                maxItems: 4
> +                items:
> +                  - const: 1
> +                  - const: 2
> +                  - const: 3
> +                  - const: 4
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for MIPI DSI Channel-B input
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            unevaluatedProperties: false
> +
> +            properties:
> +              data-lanes:
> +                description: array of physical DSI data lane indexes.
> +                minItems: 1
> +                maxItems: 4
> +                items:
> +                  - const: 1
> +                  - const: 2
> +                  - const: 3
> +                  - const: 4
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for LVDS Channel-A output (panel or bridge).
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: LVDS Channel-A output endpoint
> +            unevaluatedProperties: false

No need for 'endpoint' unless you have extra properties in it.

> +
> +      port@3:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for LVDS Channel-A output (panel or bridge).
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: LVDS Channel-B output endpoint
> +            unevaluatedProperties: false

Ditto

> +
> +    required:
> +      - port@0
> +      - port@2
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - ports
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,sn65dsi83
> +    then:
> +      properties:
> +        ports:
> +          properties:
> +            port@1: false
> +            port@3: false
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,sn65dsi84
> +    then:
> +      properties:
> +        ports:
> +          properties:
> +            port@1: false
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        bridge@2d {
> +            compatible = "ti,sn65dsi83";
> +            reg = <0x2d>;
> +
> +            enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +
> +                    endpoint {
> +                        remote-endpoint = <&dsi0_out>;
> +                        data-lanes = <1 2 3 4>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +
> +                    endpoint {
> +                        remote-endpoint = <&panel_in_lvds>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
@ 2021-05-07  1:00   ` Rob Herring
  0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2021-05-07  1:00 UTC (permalink / raw)
  To: Marek Vasut
  Cc: devicetree, ch, Douglas Anderson, dri-devel, Stephen Boyd,
	Jagan Teki, Sam Ravnborg, Laurent Pinchart

On Wed, May 05, 2021 at 12:02:17PM +0200, Marek Vasut wrote:
> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: devicetree@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Add compatible string for SN65DSI84, since this is now tested on it
> V3: - Add 0x2c as valid i2c address
>     - Switch to schemas/graph.yaml
>     - Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
>     - Indent example by 4 spaces
>     - Handle dual-link LVDS with two ports and describe the second DSI
>       channel-B port as well. Based on the register defaults of DSI83
>       and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
>       hardware is present in all the chips, so just reuse port@0 and 2
>       for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
>       that is supported
> ---
>  .../bindings/display/bridge/ti,sn65dsi83.yaml | 171 ++++++++++++++++++
>  1 file changed, 171 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> new file mode 100644
> index 000000000000..4e7df92446a9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -0,0 +1,171 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
> +
> +maintainers:
> +  - Marek Vasut <marex@denx.de>
> +
> +description: |
> +  Texas Instruments SN65DSI83 1x Single-link MIPI DSI
> +  to 1x Single-link LVDS
> +  https://www.ti.com/lit/gpn/sn65dsi83
> +  Texas Instruments SN65DSI84 1x Single-link MIPI DSI
> +  to 1x Dual-link or 2x Single-link LVDS
> +  https://www.ti.com/lit/gpn/sn65dsi84
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: ti,sn65dsi83
> +      - const: ti,sn65dsi84

Use 'enum' instead of oneOf+const.

> +
> +  reg:
> +    oneOf:
> +      - const: 0x2c
> +      - const: 0x2d

Ditto

> +
> +  enable-gpios:
> +    maxItems: 1
> +    description: GPIO specifier for bridge_en pin (active high).
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for MIPI DSI Channel-A input
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base

This should actually be video-interfaces.yaml since you use one of the 
properties from it.

> +            unevaluatedProperties: false
> +
> +            properties:
> +              data-lanes:
> +                description: array of physical DSI data lane indexes.
> +                minItems: 1
> +                maxItems: 4
> +                items:
> +                  - const: 1
> +                  - const: 2
> +                  - const: 3
> +                  - const: 4
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for MIPI DSI Channel-B input
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            unevaluatedProperties: false
> +
> +            properties:
> +              data-lanes:
> +                description: array of physical DSI data lane indexes.
> +                minItems: 1
> +                maxItems: 4
> +                items:
> +                  - const: 1
> +                  - const: 2
> +                  - const: 3
> +                  - const: 4
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for LVDS Channel-A output (panel or bridge).
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: LVDS Channel-A output endpoint
> +            unevaluatedProperties: false

No need for 'endpoint' unless you have extra properties in it.

> +
> +      port@3:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Video port for LVDS Channel-A output (panel or bridge).
> +
> +        properties:
> +          endpoint:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: LVDS Channel-B output endpoint
> +            unevaluatedProperties: false

Ditto

> +
> +    required:
> +      - port@0
> +      - port@2
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - ports
> +
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,sn65dsi83
> +    then:
> +      properties:
> +        ports:
> +          properties:
> +            port@1: false
> +            port@3: false
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,sn65dsi84
> +    then:
> +      properties:
> +        ports:
> +          properties:
> +            port@1: false
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        bridge@2d {
> +            compatible = "ti,sn65dsi83";
> +            reg = <0x2d>;
> +
> +            enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +
> +                    endpoint {
> +                        remote-endpoint = <&dsi0_out>;
> +                        data-lanes = <1 2 3 4>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +
> +                    endpoint {
> +                        remote-endpoint = <&panel_in_lvds>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 20:49         ` Marek Vasut
@ 2021-05-07  8:55           ` Dave Stevenson
  0 siblings, 0 replies; 34+ messages in thread
From: Dave Stevenson @ 2021-05-07  8:55 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On Thu, 6 May 2021 at 21:49, Marek Vasut <marex@denx.de> wrote:
>
> On 5/6/21 7:03 PM, Dave Stevenson wrote:
> > On Thu, 6 May 2021 at 13:48, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 5/6/21 11:45 AM, Dave Stevenson wrote:
> >>> Hi Marek
> >>
> >> Hi,
> >>
> >>> I'm taking an interest as there are a number of Raspberry Pi users
> >>> trying to get this chip up and running (not there quite yet).
> >>> A couple of fairly minor comments
> >>
> >> Is there any readily available display unit / expansion board with this
> >> chip ?
> >
> > Not that I'm aware of. It's a forum thread[1] where two different
> > users are trying to bring up the chip, each with their own boards. One
> > has just reported they have got it working with Jagan's patch set but
> > with a load of hacks to both bridge and DSI drivers.
> > If Laurent has a board then that may be a useful further test route.
> >
> > I'm not 100% convinced that the Pi is doing exactly the right thing
> > with regard LP-11 state during initialisation, but hope to get into
> > the lab to check either tomorrow or early next week.
>
> Good
>
> > [1] https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=305690
> >
> >> [...]
> >>
> >>>> +#define REG_DSI_LANE                           0x10
> >>>> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL       BIT(5) /* dual or 2x single */
> >>>
> >>> The bit name here seems a little odd.
> >>> Bits 5&6 are the DSI channel mode on SN65DSI85, not the LVDS link
> >>> config (which appears to be reg 0x18 bit 4)
> >>> DSI_CHANNEL_MODE
> >>> 00 – Dual-channel DSI receiver
> >>> 01 – Single channel DSI receiver (default)
> >>> 10 – Two single channel DSI receivers
> >>> 11 – Reserved
> >>> SN65DSI83 and 84 require it to be set to 01. You have that end result,
> >>> but using an odd register name that only documents one of the 2 bits.
> >>>
> >>> Is it worth documenting bit 7 as being the '85 Dual DSI link
> >>> LEFT_RIGHT_PIXELS flag at the same time? The chip isn't supported in
> >>> dual DSI mode at present, but defining all the registers up front
> >>> seems reasonable.
> >>
> >> Yes, let's fix those.
> >>
> >> [...]
> >>
> >>>> +       /*
> >>>> +        * Reset the chip, pull EN line low for t_reset=10ms,
> >>>> +        * then high for t_en=1ms.
> >>>> +        */
> >>>> +       regcache_mark_dirty(ctx->regmap);
> >>>> +       gpiod_set_value(ctx->enable_gpio, 0);
> >>>> +       usleep_range(10000, 11000);
> >>>> +       gpiod_set_value(ctx->enable_gpio, 1);
> >>>> +       usleep_range(1000, 1100);
> >>>> +}
> >>>
> >>> Whilst section 6.6 of the SN65DSI84 datasheet does list t_en as 1ms,
> >>> the initialization sequence listed in table 7.2 states
> >>> Init seq 3 - Set EN pin to Low
> >>> Wait 10 ms
> >>> Init seq 4 - Tie EN pin to High
> >>> Wait 10 ms
> >>>
> >>> with the note that these are "Minimum recommended delay. It is fine to
> >>> exceed these."
> >>>
> >>> Have you had alternate guidance from TI over that delay?
> >>
> >> No, I trusted the timing diagrams in section 6.6 of the datasheet. I
> >> would like to believe those are correct, while the init sequence listing
> >> might be a copy-paste error.
> >
> > It's a tough one to call as to which is going to be correct. I just
> > thought I'd flag it.
> >
> >> [...]
> >>
> >>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> >>>> +{
> >>>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >>>> +       unsigned int pval;
> >>>> +       u16 val;
> >>>> +       int ret;
> >>>> +
> >>>> +       /* Clear reset, disable PLL */
> >>>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> >>>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >>>> +
> >>>> +       /* Reference clock derived from DSI link clock. */
> >>>> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> >>>> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> >>>> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> >>>
> >>> (Checkpatch whinge for "Alignment should match open parenthesis" on
> >>> several lines through this function)
> >>
> >> Do you have any extra checkpatch settings somewhere ?
> >> I get this on current next:
> >>
> >> linux-2.6$ ./scripts/checkpatch.pl -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
> >> total: 0 errors, 0 warnings, 625 lines checked
> >
> > Sorry, yes "./scripts/checkpatch.pl --strict --codespell". Too much
> > working in the linux-media realms where --strict is required :-/
>
> So I can add a variable , assign it the value of
> sn65dsi83_get_lvds_range(ctx) and then do
> REG_RC_LVDS_PLL_LVDS_CLK_RANGE(val), but that doesn't really improve the
> readability at all, it just adds extra indirection.

Unless drm is sticking hard to the older limit, "bdc48fa11e46
checkpatch/coding-style: deprecate 80-column warning" allows you up to
100 chars.
Just going with the natural indentation is therefore fine and makes
checkpatch happy even in strict mode.

  Dave

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-06 20:51         ` Marek Vasut
@ 2021-05-07  9:17           ` Dave Stevenson
  2021-05-08 20:10             ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Dave Stevenson @ 2021-05-07  9:17 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, Laurent Pinchart, ch, Douglas Anderson,
	DRI Development, Stephen Boyd, Philippe Schenker,
	Frieder Schrempf, Valentin Raevsky, Sam Ravnborg, Jagan Teki

On Thu, 6 May 2021 at 21:51, Marek Vasut <marex@denx.de> wrote:
>
> On 5/6/21 6:03 PM, Frieder Schrempf wrote:
> > On 06.05.21 17:46, Marek Vasut wrote:
> >> On 5/6/21 5:38 PM, Frieder Schrempf wrote:
> >> [...]
> >>> Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work!
> >>>
> >>> I have two remarks:
> >>>
> >>> 1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek).
> >>
> >> I suspect there is indeed something with the DSIM going on, I'll keep you posted if I find something out.
> >>
> >>> 2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it.
> >>
> >> Hmm, in that conversion supposed to happen in this bridge driver or should MXSFB handle the SPWG pixel format ? Or should the DSIM bridge do something about that ?
> >
> > As far as I understand it the conversion is already done by the DSI84 without any extra configuration necessary. The only thing that needs to be done is selecting the LVDS output format via CHx_24BPP_MODE and CHx_24BPP_FORMAT1 which the driver currently hardcodes to 24bpp aka MEDIA_BUS_FMT_RGB888_1X7X4_SPWG. I think the DSI input format is always 24bpp aka MEDIA_BUS_FMT_RGB888_1X24.
>
> The DSI is MEDIA_BUS_FMT_RGB888_1X24, yes.
>
> So maybe this bridge driver has to somehow deal with
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ? Except I haven't seen such a thing
> implemented in other bridge drivers, so input would be welcome on this.

I'm claiming no knowledge of whether this is the correct approach or
not, but Toshiba TC358775 is also a DSI to LVDS bridge which appears
to handle both formats.
https://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/bridge/tc358775.c#L457

> > So I wonder where the format actually is evaluated. Could it be that it is passed down to the LCDIF and changes its output format which causes the data passed by DSIM to the DSI84 to already be in the SPWG format? If that's the case we maybe need a way to specify MEDIA_BUS_FMT_RGB888_1X24 as input bus format for the DSI84 so it doesn't pass on the panel's format? Only a wild guess, no idea if it really works like that.
>
> I _think_ the bridge must somehow handle the
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG <-> MEDIA_BUS_FMT_RGB888_1X24 conversion.

I've not looked at where the interchange happens, but as you're
setting the DSI format in struct mipi_dsi_device to
MIPI_DSI_FMT_RGB888 doesn't that provide the configuration side to the
DSI transmitter?
Otherwise presumably it needs to support the atomic_get_input_bus_fmts
and/or atomic_get_output_bus_fmts functions in drm_bridge_funcs.

  Dave

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-05 10:02 ` [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver Marek Vasut
                     ` (2 preceding siblings ...)
  2021-05-06 15:38   ` Frieder Schrempf
@ 2021-05-07 12:48   ` Dave Stevenson
  2021-05-08 20:16     ` Marek Vasut
       [not found]   ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.d251689f-a6ba-486d-bfa1-070ac0c167d5@emailsignatures365.codetwo.com>
  4 siblings, 1 reply; 34+ messages in thread
From: Dave Stevenson @ 2021-05-07 12:48 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On Wed, 5 May 2021 at 11:03, Marek Vasut <marex@denx.de> wrote:
>
> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
>
> The driver operates the chip via I2C bus. Currently the LVDS clock are
> always derived from DSI clock lane, which is the usual mode of operation.
> Support for clock from external oscillator is not implemented, but it is
> easy to add if ever needed. Only RGB888 pixel format is implemented, the
> LVDS666 is not supported, but could be added if needed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Loic Poulain <loic.poulain@linaro.org>
> Cc: Philippe Schenker <philippe.schenker@toradex.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: Valentin Raevsky <valentin@compulab.co.il>
> To: dri-devel@lists.freedesktop.org
> ---
<snip>
> +
> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +       /*
> +        * Reset the chip, pull EN line low for t_reset=10ms,
> +        * then high for t_en=1ms.
> +        */
> +       regcache_mark_dirty(ctx->regmap);
> +       gpiod_set_value(ctx->enable_gpio, 0);
> +       usleep_range(10000, 11000);
> +       gpiod_set_value(ctx->enable_gpio, 1);
> +       usleep_range(1000, 1100);
> +}
> +
<snip>
> +
> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> +{
> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +       unsigned int pval;
> +       u16 val;
> +       int ret;
> +
> +       /* Clear reset, disable PLL */
> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);

Sorry, a further thread of discussion coming from the investigations
I've been involved with.

You've powered up in pre_enable, and are sending the I2C writes in enable.

From the docs for drm_bridge_funcs->enable[1]

 * The bridge can assume that the display pipe (i.e. clocks and timing
 * signals) feeding it is running when this callback is called. This
 * callback must enable the display link feeding the next bridge in the
 * chain if there is one.

So video is running when enable is called, and the DSI data lanes may
be HS. (Someone correct me if that is an incorrect reading of the
text).

The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
seq 8 as being "Change DSI data lanes to HS state and start DSI video
stream", AFTER all the I2C has been completed except reading back
registers and checking for errors.
With video running you don't fulfil the second part of init seq 2 "the
DSI data lanes MUST be driven to LP11 state"

My investigations have been over delaying starting the DSI video
stream until after enable, but reading the descriptive text for enable
I believe the Pi is correct to be sending video at that point.
I guess there is some ambiguity as to whether the clock lane is going
to be in HS mode during pre_enable. On the Pi the PHY and clocks will
be enabled prior to pre_enable to allow for sending DSI commands
during pre_enable, but it may not be true on other platforms.

  Dave

[1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_bridge.h#L256

> +
> +       /* Reference clock derived from DSI link clock. */
> +       regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> +               REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> +               REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> +       regmap_write(ctx->regmap, REG_DSI_CLK,
> +               REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
> +       regmap_write(ctx->regmap, REG_RC_DSI_CLK,
> +               REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
> +
> +       /* Set number of DSI lanes and LVDS link config. */
> +       regmap_write(ctx->regmap, REG_DSI_LANE,
> +               REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
> +               REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
> +               /* CHB is DSI85-only, set to default on DSI83/DSI84 */
> +               REG_DSI_LANE_CHB_DSI_LANES(3));
> +       /* No equalization. */
> +       regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
> +
> +       /* RGB888 is the only format supported so far. */
> +       val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
> +              REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
> +             (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
> +              REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
> +             REG_LVDS_FMT_CHA_24BPP_MODE;
> +       if (ctx->lvds_dual_link)
> +               val |= REG_LVDS_FMT_CHB_24BPP_MODE;
> +       else
> +               val |= REG_LVDS_FMT_LVDS_LINK_CFG;
> +
> +       regmap_write(ctx->regmap, REG_LVDS_FMT, val);
> +       regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
> +       regmap_write(ctx->regmap, REG_LVDS_LANE,
> +               (ctx->lvds_dual_link_even_odd_swap ?
> +                REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
> +               REG_LVDS_LANE_CHA_LVDS_TERM |
> +               REG_LVDS_LANE_CHB_LVDS_TERM);
> +       regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
> +
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +                         &ctx->mode.hdisplay, 2);
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +                         &ctx->mode.vdisplay, 2);
> +       val = 32 + 1;   /* 32 + 1 pixel clock to ensure proper operation */
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);
> +       val = ctx->mode.hsync_end - ctx->mode.hsync_start;
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +                         &val, 2);
> +       val = ctx->mode.vsync_end - ctx->mode.vsync_start;
> +       regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +                         &val, 2);
> +       regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +                    ctx->mode.htotal - ctx->mode.hsync_end);
> +       regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,
> +                    ctx->mode.vtotal - ctx->mode.vsync_end);
> +       regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +                    ctx->mode.hsync_start - ctx->mode.hdisplay);
> +       regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +                    ctx->mode.vsync_start - ctx->mode.vdisplay);
> +       regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
> +
> +       /* Enable PLL */
> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
> +       usleep_range(3000, 4000);
> +       ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
> +                                       pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
> +                                       1000, 100000);
> +       if (ret) {
> +               dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
> +               /* On failure, disable PLL again and exit. */
> +               regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +               return;
> +       }
> +
> +       /* Trigger reset after CSR register update. */
> +       regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);
> +
> +       /* Clear all errors that got asserted during initialization. */
> +       regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> +       regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> +}
> +

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-07  9:17           ` Dave Stevenson
@ 2021-05-08 20:10             ` Marek Vasut
  0 siblings, 0 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-08 20:10 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Loic Poulain, Laurent Pinchart, ch, Douglas Anderson,
	DRI Development, Stephen Boyd, Philippe Schenker,
	Frieder Schrempf, Valentin Raevsky, Sam Ravnborg, Jagan Teki

On 5/7/21 11:17 AM, Dave Stevenson wrote:
> On Thu, 6 May 2021 at 21:51, Marek Vasut <marex@denx.de> wrote:
>>
>> On 5/6/21 6:03 PM, Frieder Schrempf wrote:
>>> On 06.05.21 17:46, Marek Vasut wrote:
>>>> On 5/6/21 5:38 PM, Frieder Schrempf wrote:
>>>> [...]
>>>>> Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work!
>>>>>
>>>>> I have two remarks:
>>>>>
>>>>> 1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek).
>>>>
>>>> I suspect there is indeed something with the DSIM going on, I'll keep you posted if I find something out.
>>>>
>>>>> 2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it.
>>>>
>>>> Hmm, in that conversion supposed to happen in this bridge driver or should MXSFB handle the SPWG pixel format ? Or should the DSIM bridge do something about that ?
>>>
>>> As far as I understand it the conversion is already done by the DSI84 without any extra configuration necessary. The only thing that needs to be done is selecting the LVDS output format via CHx_24BPP_MODE and CHx_24BPP_FORMAT1 which the driver currently hardcodes to 24bpp aka MEDIA_BUS_FMT_RGB888_1X7X4_SPWG. I think the DSI input format is always 24bpp aka MEDIA_BUS_FMT_RGB888_1X24.
>>
>> The DSI is MEDIA_BUS_FMT_RGB888_1X24, yes.
>>
>> So maybe this bridge driver has to somehow deal with
>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ? Except I haven't seen such a thing
>> implemented in other bridge drivers, so input would be welcome on this.
> 
> I'm claiming no knowledge of whether this is the correct approach or
> not, but Toshiba TC358775 is also a DSI to LVDS bridge which appears
> to handle both formats.
> https://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/bridge/tc358775.c#L457

That's what quick git grep points you to, yes. Except that driver does 
not patch the bus pixel format for the DSI in any way, it just passes 
whatever bus pixel format it got from the panel/output bridge through.

You need something like drm_display_info_set_bus_formats() called somewhere.

>>> So I wonder where the format actually is evaluated. Could it be that it is passed down to the LCDIF and changes its output format which causes the data passed by DSIM to the DSI84 to already be in the SPWG format? If that's the case we maybe need a way to specify MEDIA_BUS_FMT_RGB888_1X24 as input bus format for the DSI84 so it doesn't pass on the panel's format? Only a wild guess, no idea if it really works like that.
>>
>> I _think_ the bridge must somehow handle the
>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG <-> MEDIA_BUS_FMT_RGB888_1X24 conversion.
> 
> I've not looked at where the interchange happens, but as you're
> setting the DSI format in struct mipi_dsi_device to
> MIPI_DSI_FMT_RGB888 doesn't that provide the configuration side to the
> DSI transmitter?
> Otherwise presumably it needs to support the atomic_get_input_bus_fmts
> and/or atomic_get_output_bus_fmts functions in drm_bridge_funcs.

That doesn't work either, but see above, I think you need 
drm_display_info_set_bus_formats() .

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-07 12:48   ` Dave Stevenson
@ 2021-05-08 20:16     ` Marek Vasut
  2021-05-10  9:58       ` Dave Stevenson
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-08 20:16 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On 5/7/21 2:48 PM, Dave Stevenson wrote:

[...]

>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>> +{
>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>> +       unsigned int pval;
>> +       u16 val;
>> +       int ret;
>> +
>> +       /* Clear reset, disable PLL */
>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> 
> Sorry, a further thread of discussion coming from the investigations
> I've been involved with.
> 
> You've powered up in pre_enable, and are sending the I2C writes in enable.
> 
>>From the docs for drm_bridge_funcs->enable[1]
> 
>   * The bridge can assume that the display pipe (i.e. clocks and timing
>   * signals) feeding it is running when this callback is called. This
>   * callback must enable the display link feeding the next bridge in the
>   * chain if there is one.
> 
> So video is running when enable is called, and the DSI data lanes may
> be HS. (Someone correct me if that is an incorrect reading of the
> text).
> 
> The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
> seq 8 as being "Change DSI data lanes to HS state and start DSI video
> stream", AFTER all the I2C has been completed except reading back
> registers and checking for errors.
> With video running you don't fulfil the second part of init seq 2 "the
> DSI data lanes MUST be driven to LP11 state"
> 
> My investigations have been over delaying starting the DSI video
> stream until after enable, but reading the descriptive text for enable
> I believe the Pi is correct to be sending video at that point.
> I guess there is some ambiguity as to whether the clock lane is going
> to be in HS mode during pre_enable. On the Pi the PHY and clocks will
> be enabled prior to pre_enable to allow for sending DSI commands
> during pre_enable, but it may not be true on other platforms.

You have to make sure the clock lane is running and in HS mode when 
configuring the DSI83, otherwise the internal DSI83 state machine won't 
be able to operate.

[...]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-08 20:16     ` Marek Vasut
@ 2021-05-10  9:58       ` Dave Stevenson
  2021-05-10 11:16         ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Dave Stevenson @ 2021-05-10  9:58 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On Sat, 8 May 2021 at 21:26, Marek Vasut <marex@denx.de> wrote:
>
> On 5/7/21 2:48 PM, Dave Stevenson wrote:
>
> [...]
>
> >> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> >> +{
> >> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >> +       unsigned int pval;
> >> +       u16 val;
> >> +       int ret;
> >> +
> >> +       /* Clear reset, disable PLL */
> >> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> >> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >
> > Sorry, a further thread of discussion coming from the investigations
> > I've been involved with.
> >
> > You've powered up in pre_enable, and are sending the I2C writes in enable.
> >
> >>From the docs for drm_bridge_funcs->enable[1]
> >
> >   * The bridge can assume that the display pipe (i.e. clocks and timing
> >   * signals) feeding it is running when this callback is called. This
> >   * callback must enable the display link feeding the next bridge in the
> >   * chain if there is one.
> >
> > So video is running when enable is called, and the DSI data lanes may
> > be HS. (Someone correct me if that is an incorrect reading of the
> > text).
> >
> > The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
> > seq 8 as being "Change DSI data lanes to HS state and start DSI video
> > stream", AFTER all the I2C has been completed except reading back
> > registers and checking for errors.
> > With video running you don't fulfil the second part of init seq 2 "the
> > DSI data lanes MUST be driven to LP11 state"
> >
> > My investigations have been over delaying starting the DSI video
> > stream until after enable, but reading the descriptive text for enable
> > I believe the Pi is correct to be sending video at that point.
> > I guess there is some ambiguity as to whether the clock lane is going
> > to be in HS mode during pre_enable. On the Pi the PHY and clocks will
> > be enabled prior to pre_enable to allow for sending DSI commands
> > during pre_enable, but it may not be true on other platforms.
>
> You have to make sure the clock lane is running and in HS mode when
> configuring the DSI83, otherwise the internal DSI83 state machine won't
> be able to operate.

Indeed, but my reading of the documentation says that neither
pre_enable nor enable give you the state that you require.
You need a hook in the middle, an option to ask for clock lanes during
pre_enable or no video during enable, or an amendment to the docs over
the state during enable.

Having the data lanes in HS mode does appear to stop the DSI83
accepting the I2C setup commands.

  Dave

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-10  9:58       ` Dave Stevenson
@ 2021-05-10 11:16         ` Marek Vasut
  2021-05-10 18:04           ` Dave Stevenson
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-10 11:16 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On 5/10/21 11:58 AM, Dave Stevenson wrote:
> On Sat, 8 May 2021 at 21:26, Marek Vasut <marex@denx.de> wrote:
>>
>> On 5/7/21 2:48 PM, Dave Stevenson wrote:
>>
>> [...]
>>
>>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>>>> +{
>>>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>> +       unsigned int pval;
>>>> +       u16 val;
>>>> +       int ret;
>>>> +
>>>> +       /* Clear reset, disable PLL */
>>>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>>>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>
>>> Sorry, a further thread of discussion coming from the investigations
>>> I've been involved with.
>>>
>>> You've powered up in pre_enable, and are sending the I2C writes in enable.
>>>
>>> >From the docs for drm_bridge_funcs->enable[1]
>>>
>>>    * The bridge can assume that the display pipe (i.e. clocks and timing
>>>    * signals) feeding it is running when this callback is called. This
>>>    * callback must enable the display link feeding the next bridge in the
>>>    * chain if there is one.
>>>
>>> So video is running when enable is called, and the DSI data lanes may
>>> be HS. (Someone correct me if that is an incorrect reading of the
>>> text).
>>>
>>> The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
>>> seq 8 as being "Change DSI data lanes to HS state and start DSI video
>>> stream", AFTER all the I2C has been completed except reading back
>>> registers and checking for errors.
>>> With video running you don't fulfil the second part of init seq 2 "the
>>> DSI data lanes MUST be driven to LP11 state"
>>>
>>> My investigations have been over delaying starting the DSI video
>>> stream until after enable, but reading the descriptive text for enable
>>> I believe the Pi is correct to be sending video at that point.
>>> I guess there is some ambiguity as to whether the clock lane is going
>>> to be in HS mode during pre_enable. On the Pi the PHY and clocks will
>>> be enabled prior to pre_enable to allow for sending DSI commands
>>> during pre_enable, but it may not be true on other platforms.
>>
>> You have to make sure the clock lane is running and in HS mode when
>> configuring the DSI83, otherwise the internal DSI83 state machine won't
>> be able to operate.
> 
> Indeed, but my reading of the documentation says that neither
> pre_enable nor enable give you the state that you require.
> You need a hook in the middle, an option to ask for clock lanes during
> pre_enable or no video during enable, or an amendment to the docs over
> the state during enable.
> 
> Having the data lanes in HS mode does appear to stop the DSI83
> accepting the I2C setup commands.

Uhh, that is new. Is that what you observed in your lab ?

I saw the DSI83 behave this way if the clock lane was stopped, but the 
data lanes had no impact. Was your clock lane running when the DSI83 was 
not accepting i2c commands ? Does your DSI83 source clock from it or 
from external Xtal ?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-10 11:16         ` Marek Vasut
@ 2021-05-10 18:04           ` Dave Stevenson
  2021-05-10 19:29             ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Dave Stevenson @ 2021-05-10 18:04 UTC (permalink / raw)
  To: Marek Vasut
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On Mon, 10 May 2021 at 12:16, Marek Vasut <marex@denx.de> wrote:
>
> On 5/10/21 11:58 AM, Dave Stevenson wrote:
> > On Sat, 8 May 2021 at 21:26, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 5/7/21 2:48 PM, Dave Stevenson wrote:
> >>
> >> [...]
> >>
> >>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> >>>> +{
> >>>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >>>> +       unsigned int pval;
> >>>> +       u16 val;
> >>>> +       int ret;
> >>>> +
> >>>> +       /* Clear reset, disable PLL */
> >>>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> >>>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> >>>
> >>> Sorry, a further thread of discussion coming from the investigations
> >>> I've been involved with.
> >>>
> >>> You've powered up in pre_enable, and are sending the I2C writes in enable.
> >>>
> >>> >From the docs for drm_bridge_funcs->enable[1]
> >>>
> >>>    * The bridge can assume that the display pipe (i.e. clocks and timing
> >>>    * signals) feeding it is running when this callback is called. This
> >>>    * callback must enable the display link feeding the next bridge in the
> >>>    * chain if there is one.
> >>>
> >>> So video is running when enable is called, and the DSI data lanes may
> >>> be HS. (Someone correct me if that is an incorrect reading of the
> >>> text).
> >>>
> >>> The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
> >>> seq 8 as being "Change DSI data lanes to HS state and start DSI video
> >>> stream", AFTER all the I2C has been completed except reading back
> >>> registers and checking for errors.
> >>> With video running you don't fulfil the second part of init seq 2 "the
> >>> DSI data lanes MUST be driven to LP11 state"
> >>>
> >>> My investigations have been over delaying starting the DSI video
> >>> stream until after enable, but reading the descriptive text for enable
> >>> I believe the Pi is correct to be sending video at that point.
> >>> I guess there is some ambiguity as to whether the clock lane is going
> >>> to be in HS mode during pre_enable. On the Pi the PHY and clocks will
> >>> be enabled prior to pre_enable to allow for sending DSI commands
> >>> during pre_enable, but it may not be true on other platforms.
> >>
> >> You have to make sure the clock lane is running and in HS mode when
> >> configuring the DSI83, otherwise the internal DSI83 state machine won't
> >> be able to operate.
> >
> > Indeed, but my reading of the documentation says that neither
> > pre_enable nor enable give you the state that you require.
> > You need a hook in the middle, an option to ask for clock lanes during
> > pre_enable or no video during enable, or an amendment to the docs over
> > the state during enable.
> >
> > Having the data lanes in HS mode does appear to stop the DSI83
> > accepting the I2C setup commands.
>
> Uhh, that is new. Is that what you observed in your lab ?
>
> I saw the DSI83 behave this way if the clock lane was stopped, but the
> data lanes had no impact. Was your clock lane running when the DSI83 was
> not accepting i2c commands ? Does your DSI83 source clock from it or
> from external Xtal ?

I haven't got into the lab as yet, and I don't have a DSI83 myself.
This is relaying experimentation from others.
They're using the DSI clock lane as the clock source.Yes the clock
lane on the Pi is started before any of the enable bridge calls.

In the vc4 driver[1] it runs through the all pre-enables, configures
register DISP0_CTRL including setting bit DSI_DISP0_ENABLE which
starts it requesting pixels from the pipeline, and then calls all the
enables. With that behaviour it fails to start the DSI83.

If the DSI83 I2C setup code is moved from enable to pre_enable then it
works, or if patch [2] is used to move the setting of the
DSI_DISP0_ENABLE bit to after enable it also works.

Sorry life is all rather up in the air with working from home. I'll go
into the lab and try to confirm that DSI_DISP0_ENABLE does what the
documentation implies it does.
Those who do have hardware now have it working on the Pi, although
with a version of Jagan's driver rather than yours. We're trying to
figure out the diffs with yours.

If you have it working reliably on other platforms that you believe
are following the docs during pre_enable and enable, then I'm happy to
drop out of the discussions for now. We can revisit it once we have
determined exactly why it's being fussy on the Pi.

Cheers
  Dave

[1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_dsi.c#L1072
[2] https://github.com/6by9/linux/commit/b939eaffc47cc84ebfea6bf1ab10ae1ec9fa58c2

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-10 18:04           ` Dave Stevenson
@ 2021-05-10 19:29             ` Marek Vasut
  0 siblings, 0 replies; 34+ messages in thread
From: Marek Vasut @ 2021-05-10 19:29 UTC (permalink / raw)
  To: Dave Stevenson
  Cc: Loic Poulain, ch, Douglas Anderson, DRI Development,
	Stephen Boyd, Philippe Schenker, Jagan Teki, Valentin Raevsky,
	Sam Ravnborg, Laurent Pinchart

On 5/10/21 8:04 PM, Dave Stevenson wrote:

Hi,
[...]
>>>>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>>>>>> +{
>>>>>> +       struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>>>> +       unsigned int pval;
>>>>>> +       u16 val;
>>>>>> +       int ret;
>>>>>> +
>>>>>> +       /* Clear reset, disable PLL */
>>>>>> +       regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>>>>>> +       regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>>>
>>>>> Sorry, a further thread of discussion coming from the investigations
>>>>> I've been involved with.
>>>>>
>>>>> You've powered up in pre_enable, and are sending the I2C writes in enable.
>>>>>
>>>>> >From the docs for drm_bridge_funcs->enable[1]
>>>>>
>>>>>     * The bridge can assume that the display pipe (i.e. clocks and timing
>>>>>     * signals) feeding it is running when this callback is called. This
>>>>>     * callback must enable the display link feeding the next bridge in the
>>>>>     * chain if there is one.
>>>>>
>>>>> So video is running when enable is called, and the DSI data lanes may
>>>>> be HS. (Someone correct me if that is an incorrect reading of the
>>>>> text).
>>>>>
>>>>> The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
>>>>> seq 8 as being "Change DSI data lanes to HS state and start DSI video
>>>>> stream", AFTER all the I2C has been completed except reading back
>>>>> registers and checking for errors.
>>>>> With video running you don't fulfil the second part of init seq 2 "the
>>>>> DSI data lanes MUST be driven to LP11 state"
>>>>>
>>>>> My investigations have been over delaying starting the DSI video
>>>>> stream until after enable, but reading the descriptive text for enable
>>>>> I believe the Pi is correct to be sending video at that point.
>>>>> I guess there is some ambiguity as to whether the clock lane is going
>>>>> to be in HS mode during pre_enable. On the Pi the PHY and clocks will
>>>>> be enabled prior to pre_enable to allow for sending DSI commands
>>>>> during pre_enable, but it may not be true on other platforms.
>>>>
>>>> You have to make sure the clock lane is running and in HS mode when
>>>> configuring the DSI83, otherwise the internal DSI83 state machine won't
>>>> be able to operate.
>>>
>>> Indeed, but my reading of the documentation says that neither
>>> pre_enable nor enable give you the state that you require.
>>> You need a hook in the middle, an option to ask for clock lanes during
>>> pre_enable or no video during enable, or an amendment to the docs over
>>> the state during enable.
>>>
>>> Having the data lanes in HS mode does appear to stop the DSI83
>>> accepting the I2C setup commands.
>>
>> Uhh, that is new. Is that what you observed in your lab ?
>>
>> I saw the DSI83 behave this way if the clock lane was stopped, but the
>> data lanes had no impact. Was your clock lane running when the DSI83 was
>> not accepting i2c commands ? Does your DSI83 source clock from it or
>> from external Xtal ?
> 
> I haven't got into the lab as yet, and I don't have a DSI83 myself.
> This is relaying experimentation from others.
> They're using the DSI clock lane as the clock source.Yes the clock
> lane on the Pi is started before any of the enable bridge calls.
> 
> In the vc4 driver[1] it runs through the all pre-enables, configures
> register DISP0_CTRL including setting bit DSI_DISP0_ENABLE which
> starts it requesting pixels from the pipeline, and then calls all the
> enables. With that behaviour it fails to start the DSI83.
> 
> If the DSI83 I2C setup code is moved from enable to pre_enable then it
> works, or if patch [2] is used to move the setting of the
> DSI_DISP0_ENABLE bit to after enable it also works.

The pre_enable option won't work on MX8M and I suspect Exynos5, because 
that DSIM PHY only enables the DSI HS clock in its bridge enable 
(whether that is OK or not, I cannot tell, I am hoping someone can 
clarify that).

> Sorry life is all rather up in the air with working from home. I'll go
> into the lab and try to confirm that DSI_DISP0_ENABLE does what the
> documentation implies it does.
> Those who do have hardware now have it working on the Pi, although
> with a version of Jagan's driver rather than yours. We're trying to
> figure out the diffs with yours.

All right, if you figure it out, I'd be interested to know what it is.

> If you have it working reliably on other platforms that you believe
> are following the docs during pre_enable and enable, then I'm happy to
> drop out of the discussions for now. We can revisit it once we have
> determined exactly why it's being fussy on the Pi.

Since you have one working setup and another non-working, and the only 
difference is the DSI83 bridge driver, it should be possible to find the 
difference easily.

I had a look at the driver from Jagan again, and there is no 
configuration in pre_enable either, so the pre_enable is likely not the 
reason why it works for you. Maybe the extra mdelays the driver adds all 
over the place are the reason ?

> Cheers
>    Dave
> 
> [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_dsi.c#L1072
> [2] https://github.com/6by9/linux/commit/b939eaffc47cc84ebfea6bf1ab10ae1ec9fa58c2
> 

[...]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
       [not found]     ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.81349e00-3f39-4654-ab28-8c85568d0c51@emailsignatures365.codetwo.com>
@ 2021-05-17 13:23       ` Mike Looijmans
  2021-05-25 10:53         ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Mike Looijmans @ 2021-05-17 13:23 UTC (permalink / raw)
  To: Marek Vasut, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

Hi Marek,

I'm testing your driver, some remarks below.


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 05-05-2021 12:02, Marek Vasut wrote:
> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
>
> The driver operates the chip via I2C bus. Currently the LVDS clock are
> always derived from DSI clock lane, which is the usual mode of operation.
> Support for clock from external oscillator is not implemented, but it is
> easy to add if ever needed. Only RGB888 pixel format is implemented, the
> LVDS666 is not supported, but could be added if needed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Loic Poulain <loic.poulain@linaro.org>
> Cc: Philippe Schenker <philippe.schenker@toradex.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stephen Boyd <swboyd@chromium.org>
> Cc: Valentin Raevsky <valentin@compulab.co.il>
> To: dri-devel@lists.freedesktop.org
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> ---
> V2: - Use dev_err_probe()
>      - Set REG_RC_RESET as volatile
>      - Wait for PLL stabilization by polling REG_RC_LVDS_PLL
>      - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set
>      - Add tested DSI84 support in dual-link mode
>      - Correctly set VCOM
>      - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85
>        datasheets, with that all the reserved bits make far more sense
>        as the DSI83 and DSI84 seems to be reduced version of DSI85
> V3: - Handle the dual-link LVDS with two port panel or bridge
> ---
>   drivers/gpu/drm/bridge/Kconfig        |  10 +
>   drivers/gpu/drm/bridge/Makefile       |   1 +
>   drivers/gpu/drm/bridge/ti-sn65dsi83.c | 639 ++++++++++++++++++++++++++
>   3 files changed, 650 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e83b8ad0d71b..32204c5f25b7 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -278,6 +278,16 @@ config DRM_TI_TFP410
>   	help
>   	  Texas Instruments TFP410 DVI/HDMI Transmitter driver
>   
> +config DRM_TI_SN65DSI83
> +	tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge"
> +	depends on OF
> +	select DRM_KMS_HELPER
> +	select REGMAP_I2C
> +	select DRM_PANEL
> +	select DRM_MIPI_DSI
> +	help
> +	  Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver
> +
>   config DRM_TI_SN65DSI86
>   	tristate "TI SN65DSI86 DSI to eDP bridge"
>   	depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b00f3b2ad572..7bb4c9df0415 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>   obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
>   obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
>   obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o
>   obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>   obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>   obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> new file mode 100644
> index 000000000000..471df09a1c07
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -0,0 +1,639 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TI SN65DSI83,84,85 driver
> + *
> + * Currently supported:
> + * - SN65DSI83
> + *   = 1x Single-link DSI ~ 1x Single-link LVDS
> + *   - Supported
> + *   - Single-link LVDS mode tested
> + * - SN65DSI84
> + *   = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS
> + *   - Supported
> + *   - Dual-link LVDS mode tested
> + *   - 2x Single-link LVDS mode unsupported
> + *     (should be easy to add by someone who has the HW)
> + * - SN65DSI85
> + *   = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS
> + *   - Unsupported
> + *     (should be easy to add by someone who has the HW)
> + *
> + * Copyright (C) 2021 Marek Vasut <marex@denx.de>
> + *
> + * Based on previous work of:
> + * Valentin Raevsky <valentin@compulab.co.il>
> + * Philippe Schenker <philippe.schenker@toradex.com>
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_graph.h>
> +#include <linux/regmap.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +/* ID registers */
> +#define REG_ID(n)				(0x00 + (n))
> +/* Reset and clock registers */
> +#define REG_RC_RESET				0x09
> +#define  REG_RC_RESET_SOFT_RESET		BIT(0)
> +#define REG_RC_LVDS_PLL				0x0a
> +#define  REG_RC_LVDS_PLL_PLL_EN_STAT		BIT(7)
> +#define  REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n)	(((n) & 0x7) << 1)
> +#define  REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY	BIT(0)
> +#define REG_RC_DSI_CLK				0x0b
> +#define  REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n)	(((n) & 0x1f) << 3)
> +#define  REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n)	((n) & 0x3)
> +#define REG_RC_PLL_EN				0x0d
> +#define  REG_RC_PLL_EN_PLL_EN			BIT(0)
> +/* DSI registers */
> +#define REG_DSI_LANE				0x10
> +#define  REG_DSI_LANE_LVDS_LINK_CFG_DUAL	BIT(5) /* dual or 2x single */
> +#define  REG_DSI_LANE_CHA_DSI_LANES(n)		(((n) & 0x3) << 3)
> +#define  REG_DSI_LANE_CHB_DSI_LANES(n)		(((n) & 0x3) << 1)
> +#define  REG_DSI_LANE_SOT_ERR_TOL_DIS		BIT(0)
> +#define REG_DSI_EQ				0x11
> +#define  REG_DSI_EQ_CHA_DSI_DATA_EQ(n)		(((n) & 0x3) << 6)
> +#define  REG_DSI_EQ_CHA_DSI_CLK_EQ(n)		(((n) & 0x3) << 2)
> +#define REG_DSI_CLK				0x12
> +#define  REG_DSI_CLK_CHA_DSI_CLK_RANGE(n)	((n) & 0xff)
> +/* LVDS registers */
> +#define REG_LVDS_FMT				0x18
> +#define  REG_LVDS_FMT_DE_NEG_POLARITY		BIT(7)
> +#define  REG_LVDS_FMT_HS_NEG_POLARITY		BIT(6)
> +#define  REG_LVDS_FMT_VS_NEG_POLARITY		BIT(5)
> +#define  REG_LVDS_FMT_LVDS_LINK_CFG		BIT(4)	/* 0:AB 1:A-only */
> +#define  REG_LVDS_FMT_CHA_24BPP_MODE		BIT(3)
> +#define  REG_LVDS_FMT_CHB_24BPP_MODE		BIT(2)
> +#define  REG_LVDS_FMT_CHA_24BPP_FORMAT1		BIT(1)
> +#define  REG_LVDS_FMT_CHB_24BPP_FORMAT1		BIT(0)
> +#define REG_LVDS_VCOM				0x19
> +#define  REG_LVDS_VCOM_CHA_LVDS_VOCM		BIT(6)
> +#define  REG_LVDS_VCOM_CHB_LVDS_VOCM		BIT(4)
> +#define  REG_LVDS_VCOM_CHA_LVDS_VOD_SWING(n)	(((n) & 0x3) << 2)
> +#define  REG_LVDS_VCOM_CHB_LVDS_VOD_SWING(n)	((n) & 0x3)
> +#define REG_LVDS_LANE				0x1a
> +#define  REG_LVDS_LANE_EVEN_ODD_SWAP		BIT(6)
> +#define  REG_LVDS_LANE_CHA_REVERSE_LVDS		BIT(5)
> +#define  REG_LVDS_LANE_CHB_REVERSE_LVDS		BIT(4)
> +#define  REG_LVDS_LANE_CHA_LVDS_TERM		BIT(1)
> +#define  REG_LVDS_LANE_CHB_LVDS_TERM		BIT(0)
> +#define REG_LVDS_CM				0x1b
> +#define  REG_LVDS_CM_CHA_LVDS_CM_ADJUST(n)	(((n) & 0x3) << 4)
> +#define  REG_LVDS_CM_CHB_LVDS_CM_ADJUST(n)	((n) & 0x3)
> +/* Video registers */
> +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW	0x20
> +#define REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH	0x21
> +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW	0x24
> +#define REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH	0x25
> +#define REG_VID_CHA_SYNC_DELAY_LOW		0x28
> +#define REG_VID_CHA_SYNC_DELAY_HIGH		0x29
> +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW	0x2c
> +#define REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH	0x2d
> +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW	0x30
> +#define REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH	0x31
> +#define REG_VID_CHA_HORIZONTAL_BACK_PORCH	0x34
> +#define REG_VID_CHA_VERTICAL_BACK_PORCH		0x36
> +#define REG_VID_CHA_HORIZONTAL_FRONT_PORCH	0x38
> +#define REG_VID_CHA_VERTICAL_FRONT_PORCH	0x3a
> +#define REG_VID_CHA_TEST_PATTERN		0x3c
> +/* IRQ registers */
> +#define REG_IRQ_GLOBAL				0xe0
> +#define  REG_IRQ_GLOBAL_IRQ_EN			BIT(0)
> +#define REG_IRQ_EN				0xe1
> +#define  REG_IRQ_EN_CHA_SYNCH_ERR_EN		BIT(7)
> +#define  REG_IRQ_EN_CHA_CRC_ERR_EN		BIT(6)
> +#define  REG_IRQ_EN_CHA_UNC_ECC_ERR_EN		BIT(5)
> +#define  REG_IRQ_EN_CHA_COR_ECC_ERR_EN		BIT(4)
> +#define  REG_IRQ_EN_CHA_LLP_ERR_EN		BIT(3)
> +#define  REG_IRQ_EN_CHA_SOT_BIT_ERR_EN		BIT(2)
> +#define  REG_IRQ_EN_CHA_PLL_UNLOCK_EN		BIT(0)
> +#define REG_IRQ_STAT				0xe5
> +#define  REG_IRQ_STAT_CHA_SYNCH_ERR		BIT(7)
> +#define  REG_IRQ_STAT_CHA_CRC_ERR		BIT(6)
> +#define  REG_IRQ_STAT_CHA_UNC_ECC_ERR		BIT(5)
> +#define  REG_IRQ_STAT_CHA_COR_ECC_ERR		BIT(4)
> +#define  REG_IRQ_STAT_CHA_LLP_ERR		BIT(3)
> +#define  REG_IRQ_STAT_CHA_SOT_BIT_ERR		BIT(2)
> +#define  REG_IRQ_STAT_CHA_PLL_UNLOCK		BIT(0)
> +
> +enum sn65dsi83_model {
> +	MODEL_SN65DSI83,
> +	MODEL_SN65DSI84,
> +};
> +
> +struct sn65dsi83 {
> +	struct drm_bridge		bridge;
> +	struct drm_display_mode		mode;
> +	struct device			*dev;
> +	struct regmap			*regmap;
> +	struct device_node		*host_node;
> +	struct mipi_dsi_device		*dsi;
> +	struct drm_bridge		*panel_bridge;
> +	struct gpio_desc		*enable_gpio;
> +	int				dsi_lanes;
> +	bool				lvds_dual_link;
> +	bool				lvds_dual_link_even_odd_swap;
> +};
> +
> +static const struct regmap_range sn65dsi83_readable_ranges[] = {
> +	regmap_reg_range(REG_ID(0), REG_ID(8)),
> +	regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_DSI_CLK),
> +	regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
> +	regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
> +	regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
> +	regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +			 REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +			 REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
> +	regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
> +			 REG_VID_CHA_SYNC_DELAY_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
> +			 REG_VID_CHA_VERTICAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +			 REG_VID_CHA_VERTICAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
> +	regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
> +	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_readable_table = {
> +	.yes_ranges = sn65dsi83_readable_ranges,
> +	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_readable_ranges),
> +};
> +
> +static const struct regmap_range sn65dsi83_writeable_ranges[] = {
> +	regmap_reg_range(REG_RC_RESET, REG_RC_DSI_CLK),
> +	regmap_reg_range(REG_RC_PLL_EN, REG_RC_PLL_EN),
> +	regmap_reg_range(REG_DSI_LANE, REG_DSI_CLK),
> +	regmap_reg_range(REG_LVDS_FMT, REG_LVDS_CM),
> +	regmap_reg_range(REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +			 REG_VID_CHA_ACTIVE_LINE_LENGTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +			 REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH),
> +	regmap_reg_range(REG_VID_CHA_SYNC_DELAY_LOW,
> +			 REG_VID_CHA_SYNC_DELAY_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_HSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +			 REG_VID_CHA_VSYNC_PULSE_WIDTH_HIGH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_BACK_PORCH,
> +			 REG_VID_CHA_VERTICAL_BACK_PORCH),
> +	regmap_reg_range(REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +			 REG_VID_CHA_HORIZONTAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +			 REG_VID_CHA_VERTICAL_FRONT_PORCH),
> +	regmap_reg_range(REG_VID_CHA_TEST_PATTERN, REG_VID_CHA_TEST_PATTERN),
> +	regmap_reg_range(REG_IRQ_GLOBAL, REG_IRQ_EN),
> +	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_writeable_table = {
> +	.yes_ranges = sn65dsi83_writeable_ranges,
> +	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_writeable_ranges),
> +};
> +
> +static const struct regmap_range sn65dsi83_volatile_ranges[] = {
> +	regmap_reg_range(REG_RC_RESET, REG_RC_RESET),
> +	regmap_reg_range(REG_RC_LVDS_PLL, REG_RC_LVDS_PLL),
> +	regmap_reg_range(REG_IRQ_STAT, REG_IRQ_STAT),
> +};
> +
> +static const struct regmap_access_table sn65dsi83_volatile_table = {
> +	.yes_ranges = sn65dsi83_volatile_ranges,
> +	.n_yes_ranges = ARRAY_SIZE(sn65dsi83_volatile_ranges),
> +};
> +
> +static const struct regmap_config sn65dsi83_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.rd_table = &sn65dsi83_readable_table,
> +	.wr_table = &sn65dsi83_writeable_table,
> +	.volatile_table = &sn65dsi83_volatile_table,
> +	.cache_type = REGCACHE_RBTREE,
> +	.max_register = REG_IRQ_STAT,
> +};
> +
> +static struct sn65dsi83 *bridge_to_sn65dsi83(struct drm_bridge *bridge)
> +{
> +	return container_of(bridge, struct sn65dsi83, bridge);
> +}
> +
> +static int sn65dsi83_attach(struct drm_bridge *bridge,
> +			    enum drm_bridge_attach_flags flags)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +	struct device *dev = ctx->dev;
> +	struct mipi_dsi_device *dsi;
> +	struct mipi_dsi_host *host;
> +	int ret = 0;
> +
> +	const struct mipi_dsi_device_info info = {
> +		.type = "sn65dsi83",
> +		.channel = 0,
> +		.node = NULL,
> +	};
> +
> +	host = of_find_mipi_dsi_host_by_node(ctx->host_node);
> +	if (!host) {
> +		dev_err(dev, "failed to find dsi host\n");
> +		return -EPROBE_DEFER;
> +	}
> +
> +	dsi = mipi_dsi_device_register_full(host, &info);
> +	if (IS_ERR(dsi)) {
> +		return dev_err_probe(dev, PTR_ERR(dsi),
> +				     "failed to create dsi device\n");
> +	}
> +
> +	ctx->dsi = dsi;
> +
> +	dsi->lanes = ctx->dsi_lanes;
> +	dsi->format = MIPI_DSI_FMT_RGB888;
> +	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
> +
> +	ret = mipi_dsi_attach(dsi);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to attach dsi to host\n");
> +		goto err_dsi_attach;
> +	}
> +
> +	return drm_bridge_attach(bridge->encoder, ctx->panel_bridge,
> +				 &ctx->bridge, flags);
> +
> +err_dsi_attach:
> +	mipi_dsi_device_unregister(dsi);
> +	return ret;
> +}
> +
> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	/*
> +	 * Reset the chip, pull EN line low for t_reset=10ms,
> +	 * then high for t_en=1ms.
> +	 */
> +	regcache_mark_dirty(ctx->regmap);
> +	gpiod_set_value(ctx->enable_gpio, 0);
> +	usleep_range(10000, 11000);
> +	gpiod_set_value(ctx->enable_gpio, 1);
> +	usleep_range(1000, 1100);
Taking the chip out of reset here is not needed and may even disrupt 
things, as the DSI hasn't set up anything yet so the clock may not be 
running. I'd move this all into enable and get rid of the pre_enable 
call. Similar for post_disable.
> +}
> +
> +static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx)
> +{
> +	/*
> +	 * The encoding of the LVDS_CLK_RANGE is as follows:
> +	 * 000 - 25 MHz <= LVDS_CLK < 37.5 MHz
> +	 * 001 - 37.5 MHz <= LVDS_CLK < 62.5 MHz
> +	 * 010 - 62.5 MHz <= LVDS_CLK < 87.5 MHz
> +	 * 011 - 87.5 MHz <= LVDS_CLK < 112.5 MHz
> +	 * 100 - 112.5 MHz <= LVDS_CLK < 137.5 MHz
> +	 * 101 - 137.5 MHz <= LVDS_CLK <= 154 MHz
> +	 * which is a range of 12.5MHz..162.5MHz in 50MHz steps, except that
> +	 * the ends of the ranges are clamped to the supported range. Since
> +	 * sn65dsi83_mode_valid() already filters the valid modes and limits
> +	 * the clock to 25..154 MHz, the range calculation can be simplified
> +	 * as follows:
> +	 */
> +	int mode_clock = ctx->mode.clock;
> +
> +	if (ctx->lvds_dual_link)
> +		mode_clock /= 2;
> +
> +	return (mode_clock - 12500) / 25000;
> +}
> +
> +static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx)
> +{
> +	/*
> +	 * The encoding of the CHA_DSI_CLK_RANGE is as follows:
> +	 * 0x00 through 0x07 - Reserved
> +	 * 0x08 - 40 <= DSI_CLK < 45 MHz
> +	 * 0x09 - 45 <= DSI_CLK < 50 MHz
> +	 * ...
> +	 * 0x63 - 495 <= DSI_CLK < 500 MHz
> +	 * 0x64 - 500 MHz
> +	 * 0x65 through 0xFF - Reserved
> +	 * which is DSI clock in 5 MHz steps, clamped to 40..500 MHz.
> +	 * The DSI clock are calculated as:
> +	 *  DSI_CLK = mode clock * bpp / dsi_data_lanes / 2
> +	 * the 2 is there because the bus is DDR.
> +	 */
> +	return DIV_ROUND_UP(clamp((unsigned int)ctx->mode.clock *
> +			    mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
> +			    ctx->dsi_lanes / 2, 40000U, 500000U), 5000U);
> +}
> +
> +static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
> +{
> +	/* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */
> +	unsigned int dsi_div = mipi_dsi_pixel_format_to_bpp(ctx->dsi->format);
> +
> +	dsi_div /= ctx->dsi_lanes;
> +
> +	if (!ctx->lvds_dual_link)
> +		dsi_div /= 2;
> +
> +	return dsi_div - 1;
> +}
> +
> +static void sn65dsi83_enable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +	unsigned int pval;
> +	u16 val;
> +	int ret;
> +
> +	/* Clear reset, disable PLL */
> +	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
Writing 0 to the RESET register is a no-op. Has no effect whatsoever, 
just wasting time and code.
> +	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +
> +	/* Reference clock derived from DSI link clock. */
> +	regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
> +		REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
> +		REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
> +	regmap_write(ctx->regmap, REG_DSI_CLK,
> +		REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
> +	regmap_write(ctx->regmap, REG_RC_DSI_CLK,
> +		REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
> +
> +	/* Set number of DSI lanes and LVDS link config. */
> +	regmap_write(ctx->regmap, REG_DSI_LANE,
> +		REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
> +		REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
> +		/* CHB is DSI85-only, set to default on DSI83/DSI84 */
> +		REG_DSI_LANE_CHB_DSI_LANES(3));
> +	/* No equalization. */
> +	regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
> +
> +	/* RGB888 is the only format supported so far. */
> +	val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
> +	       REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
> +	      (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
> +	       REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
> +	      REG_LVDS_FMT_CHA_24BPP_MODE;
> +	if (ctx->lvds_dual_link)
> +		val |= REG_LVDS_FMT_CHB_24BPP_MODE;
> +	else
> +		val |= REG_LVDS_FMT_LVDS_LINK_CFG;
> +
> +	regmap_write(ctx->regmap, REG_LVDS_FMT, val);
> +	regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
> +	regmap_write(ctx->regmap, REG_LVDS_LANE,
> +		(ctx->lvds_dual_link_even_odd_swap ?
> +		 REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
> +		REG_LVDS_LANE_CHA_LVDS_TERM |
> +		REG_LVDS_LANE_CHB_LVDS_TERM);
> +	regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
> +
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
> +			  &ctx->mode.hdisplay, 2);

I think this ignores the endian format of the data. So this would only 
work on little-endian systems, right?


> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
> +			  &ctx->mode.vdisplay, 2);
> +	val = 32 + 1;	/* 32 + 1 pixel clock to ensure proper operation */
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);
> +	val = ctx->mode.hsync_end - ctx->mode.hsync_start;
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW,
> +			  &val, 2);
> +	val = ctx->mode.vsync_end - ctx->mode.vsync_start;
> +	regmap_bulk_write(ctx->regmap, REG_VID_CHA_VSYNC_PULSE_WIDTH_LOW,
> +			  &val, 2);
> +	regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> +		     ctx->mode.htotal - ctx->mode.hsync_end);
> +	regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_BACK_PORCH,
> +		     ctx->mode.vtotal - ctx->mode.vsync_end);
> +	regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_FRONT_PORCH,
> +		     ctx->mode.hsync_start - ctx->mode.hdisplay);
> +	regmap_write(ctx->regmap, REG_VID_CHA_VERTICAL_FRONT_PORCH,
> +		     ctx->mode.vsync_start - ctx->mode.vdisplay);
> +	regmap_write(ctx->regmap, REG_VID_CHA_TEST_PATTERN, 0x00);
> +
> +	/* Enable PLL */
> +	regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
> +	usleep_range(3000, 4000);
> +	ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
> +					pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
> +					1000, 100000);
> +	if (ret) {
> +		dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
> +		/* On failure, disable PLL again and exit. */
> +		regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +		return;
> +	}
> +
> +	/* Trigger reset after CSR register update. */
> +	regmap_write(ctx->regmap, REG_RC_RESET, REG_RC_RESET_SOFT_RESET);
> +
> +	/* Clear all errors that got asserted during initialization. */
> +	regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> +	regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
Just write 0xFF to the IRQ_STAT register. Then there's no need to read 
it first.
> +}
> +
> +static void sn65dsi83_disable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	/* Clear reset, disable PLL */
> +	regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
Writing 0 to the RESET register is a no-op. Has no effect whatsoever, 
just wasting time and code.
> +	regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
> +}
> +
> +static void sn65dsi83_post_disable(struct drm_bridge *bridge)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	/* Put the chip in reset, pull EN line low. */
> +	gpiod_set_value(ctx->enable_gpio, 0);
See my remark on pre_enable, just move this bit into disable.
> +}
> +
> +static enum drm_mode_status
> +sn65dsi83_mode_valid(struct drm_bridge *bridge,
> +		     const struct drm_display_info *info,
> +		     const struct drm_display_mode *mode)
> +{
> +	/* LVDS output clock range 25..154 MHz */
> +	if (mode->clock < 25000)
> +		return MODE_CLOCK_LOW;
> +	if (mode->clock > 154000)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +
> +static void sn65dsi83_mode_set(struct drm_bridge *bridge,
> +			       const struct drm_display_mode *mode,
> +			       const struct drm_display_mode *adj)
> +{
> +	struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> +
> +	ctx->mode = *adj;
> +}
> +
> +static const struct drm_bridge_funcs sn65dsi83_funcs = {
> +	.attach		= sn65dsi83_attach,
> +	.pre_enable	= sn65dsi83_pre_enable,
> +	.enable		= sn65dsi83_enable,
> +	.disable	= sn65dsi83_disable,
> +	.post_disable	= sn65dsi83_post_disable,
> +	.mode_valid	= sn65dsi83_mode_valid,
> +	.mode_set	= sn65dsi83_mode_set,
> +};
> +
> +static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
> +{
> +	struct drm_bridge *panel_bridge;
> +	struct device *dev = ctx->dev;
> +	struct device_node *endpoint;
> +	struct drm_panel *panel;
> +	int ret;
> +
> +	endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> +	ctx->dsi_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
> +	ctx->host_node = of_graph_get_remote_port_parent(endpoint);
> +	of_node_put(endpoint);
> +
> +	if (ctx->dsi_lanes < 0 || ctx->dsi_lanes > 4)
> +		return -EINVAL;
> +	if (!ctx->host_node)
> +		return -ENODEV;
> +
> +	ctx->lvds_dual_link = false;
> +	ctx->lvds_dual_link_even_odd_swap = false;
> +	if (model != MODEL_SN65DSI83) {
> +		struct device_node *port2, *port3;
> +		int dual_link;
> +
> +		port2 = of_graph_get_port_by_id(dev->of_node, 2);
> +		port3 = of_graph_get_port_by_id(dev->of_node, 3);
> +		dual_link = drm_of_lvds_get_dual_link_pixel_order(port2, port3);
> +		of_node_put(port2);
> +		of_node_put(port3);
> +
> +		if (dual_link == DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS) {
> +			ctx->lvds_dual_link = true;
> +			/* Odd pixels to LVDS Channel A, even pixels to B */
> +			ctx->lvds_dual_link_even_odd_swap = false;
> +		} else if (dual_link == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> +			ctx->lvds_dual_link = true;
> +			/* Even pixels to LVDS Channel A, odd pixels to B */
> +			ctx->lvds_dual_link_even_odd_swap = true;
> +		}
> +	}
> +
> +	ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, &panel, &panel_bridge);
> +	if (ret < 0)
> +		return ret;
> +	if (panel) {
> +		panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> +		if (IS_ERR(panel_bridge))
> +			return PTR_ERR(panel_bridge);
> +	}
> +
> +	ctx->panel_bridge = panel_bridge;
> +
> +	return 0;
> +}
> +
> +static int sn65dsi83_probe(struct i2c_client *client,
> +			   const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	enum sn65dsi83_model model;
> +	struct sn65dsi83 *ctx;
> +	int ret;
> +
> +	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ctx->dev = dev;
> +
> +	if (dev->of_node)
> +		model = (enum sn65dsi83_model)of_device_get_match_data(dev);
> +	else
> +		model = id->driver_data;
> +
> +	ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(ctx->enable_gpio))
> +		return PTR_ERR(ctx->enable_gpio);
> +
> +	ret = sn65dsi83_parse_dt(ctx, model);
> +	if (ret)
> +		return ret;
> +
> +	ctx->regmap = devm_regmap_init_i2c(client, &sn65dsi83_regmap_config);
> +	if (IS_ERR(ctx->regmap))
> +		return PTR_ERR(ctx->regmap);
> +
> +	dev_set_drvdata(dev, ctx);
> +	i2c_set_clientdata(client, ctx);
> +
> +	ctx->bridge.funcs = &sn65dsi83_funcs;
> +	ctx->bridge.of_node = dev->of_node;
> +	drm_bridge_add(&ctx->bridge);
> +
> +	return 0;
> +}
> +
> +static int sn65dsi83_remove(struct i2c_client *client)
> +{
> +	struct sn65dsi83 *ctx = i2c_get_clientdata(client);
> +
> +	mipi_dsi_detach(ctx->dsi);
> +	mipi_dsi_device_unregister(ctx->dsi);
> +	drm_bridge_remove(&ctx->bridge);
> +	of_node_put(ctx->host_node);
> +
> +	return 0;
> +}
> +
> +static struct i2c_device_id sn65dsi83_id[] = {
> +	{ "ti,sn65dsi83", MODEL_SN65DSI83 },
> +	{ "ti,sn65dsi84", MODEL_SN65DSI84 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(i2c, sn65dsi83_id);
> +
> +static const struct of_device_id sn65dsi83_match_table[] = {
> +	{ .compatible = "ti,sn65dsi83", .data = (void *)MODEL_SN65DSI83 },
> +	{ .compatible = "ti,sn65dsi84", .data = (void *)MODEL_SN65DSI84 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, sn65dsi83_match_table);
> +
> +static struct i2c_driver sn65dsi83_driver = {
> +	.probe = sn65dsi83_probe,
> +	.remove = sn65dsi83_remove,
> +	.id_table = sn65dsi83_id,
> +	.driver = {
> +		.name = "sn65dsi83",
> +		.of_match_table = sn65dsi83_match_table,
> +	},
> +};
> +module_i2c_driver(sn65dsi83_driver);
> +
> +MODULE_AUTHOR("Marek Vasut <marex@denx.de>");
> +MODULE_DESCRIPTION("TI SN65DSI83 DSI to LVDS bridge driver");
> +MODULE_LICENSE("GPL v2");

-- 
Mike Looijmans


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-17 13:23       ` [V3, " Mike Looijmans
@ 2021-05-25 10:53         ` Marek Vasut
  2021-05-25 12:08           ` Mike Looijmans
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-25 10:53 UTC (permalink / raw)
  To: Mike Looijmans, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 5/17/21 3:23 PM, Mike Looijmans wrote:

Which system/soc are you testing this on ?

[...]

>> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
>> +{
>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>> +
>> +    /*
>> +     * Reset the chip, pull EN line low for t_reset=10ms,
>> +     * then high for t_en=1ms.
>> +     */
>> +    regcache_mark_dirty(ctx->regmap);
>> +    gpiod_set_value(ctx->enable_gpio, 0);
>> +    usleep_range(10000, 11000);
>> +    gpiod_set_value(ctx->enable_gpio, 1);
>> +    usleep_range(1000, 1100);
> Taking the chip out of reset here is not needed and may even disrupt 
> things, as the DSI hasn't set up anything yet so the clock may not be 
> running. I'd move this all into enable and get rid of the pre_enable 
> call. Similar for post_disable.

I am still waiting for someone to confirm the behavior of the DSI clock 
and data lanes in pre_enable/enable() . The datasheet says the HS clock 
have to be running and data lanes must be in LP state during init, but I 
don't think that is guaranteed currently in either pre_enable or enable.

[...]

>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>> +{
>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>> +    unsigned int pval;
>> +    u16 val;
>> +    int ret;
>> +
>> +    /* Clear reset, disable PLL */
>> +    regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
> Writing 0 to the RESET register is a no-op. Has no effect whatsoever, 
> just wasting time and code.

I would rather keep it to make sure the register is initialized.

>> +    regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>> +
>> +    /* Reference clock derived from DSI link clock. */
>> +    regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
>> +        REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
>> +        REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
>> +    regmap_write(ctx->regmap, REG_DSI_CLK,
>> +        REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
>> +    regmap_write(ctx->regmap, REG_RC_DSI_CLK,
>> +        REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
>> +
>> +    /* Set number of DSI lanes and LVDS link config. */
>> +    regmap_write(ctx->regmap, REG_DSI_LANE,
>> +        REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
>> +        REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
>> +        /* CHB is DSI85-only, set to default on DSI83/DSI84 */
>> +        REG_DSI_LANE_CHB_DSI_LANES(3));
>> +    /* No equalization. */
>> +    regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
>> +
>> +    /* RGB888 is the only format supported so far. */
>> +    val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
>> +           REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
>> +          (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
>> +           REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
>> +          REG_LVDS_FMT_CHA_24BPP_MODE;
>> +    if (ctx->lvds_dual_link)
>> +        val |= REG_LVDS_FMT_CHB_24BPP_MODE;
>> +    else
>> +        val |= REG_LVDS_FMT_LVDS_LINK_CFG;
>> +
>> +    regmap_write(ctx->regmap, REG_LVDS_FMT, val);
>> +    regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
>> +    regmap_write(ctx->regmap, REG_LVDS_LANE,
>> +        (ctx->lvds_dual_link_even_odd_swap ?
>> +         REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
>> +        REG_LVDS_LANE_CHA_LVDS_TERM |
>> +        REG_LVDS_LANE_CHB_LVDS_TERM);
>> +    regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
>> +
>> +    regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
>> +              &ctx->mode.hdisplay, 2);
> 
> I think this ignores the endian format of the data. So this would only 
> work on little-endian systems, right?

Likely, can you double-check that ?
Some cpu_to_le16() could help here then.

>> +    regmap_bulk_write(ctx->regmap, 
>> REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
>> +              &ctx->mode.vdisplay, 2);
>> +    val = 32 + 1;    /* 32 + 1 pixel clock to ensure proper operation */
>> +    regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, &val, 2);
>> +    val = ctx->mode.hsync_end - ctx->mode.hsync_start;

[...]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-25 10:53         ` Marek Vasut
@ 2021-05-25 12:08           ` Mike Looijmans
  2021-05-25 13:00             ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Mike Looijmans @ 2021-05-25 12:08 UTC (permalink / raw)
  To: Marek Vasut, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

See below...


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 25-05-2021 12:53, Marek Vasut wrote:
> On 5/17/21 3:23 PM, Mike Looijmans wrote:
>
> Which system/soc are you testing this on ?

On a raspberry-pi 4 at the moment.

>
> [...]
>
>>> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
>>> +{
>>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>> +
>>> +    /*
>>> +     * Reset the chip, pull EN line low for t_reset=10ms,
>>> +     * then high for t_en=1ms.
>>> +     */
>>> +    regcache_mark_dirty(ctx->regmap);
>>> +    gpiod_set_value(ctx->enable_gpio, 0);
>>> +    usleep_range(10000, 11000);
>>> +    gpiod_set_value(ctx->enable_gpio, 1);
>>> +    usleep_range(1000, 1100);
>> Taking the chip out of reset here is not needed and may even disrupt 
>> things, as the DSI hasn't set up anything yet so the clock may not be 
>> running. I'd move this all into enable and get rid of the pre_enable 
>> call. Similar for post_disable.
>
> I am still waiting for someone to confirm the behavior of the DSI 
> clock and data lanes in pre_enable/enable() . The datasheet says the 
> HS clock have to be running and data lanes must be in LP state during 
> init, but I don't think that is guaranteed currently in either 
> pre_enable or enable.

Neither is suited. pre-enable may have nothing, while enable has the 
data lanes sending video according to the docs. So on many systems 
either this driver or the DSI driver will need changes to make it work 
properly.

On the raspberrypi, the DSI has the clock running in pre-enable, hence 
putting everything in pre-enable instead of in enable makes the chip work.

Alternatively, one can modify the RPi DSI code to start sending data 
after the enable calls. That also works on my setup, with everything in 
enable.

The major point here is that you should pick one and only one callback: 
pre-enable or enable. The GPIO reset code as well as writing the 
registers should be done in that one method.

Same for (post)disable for symmetry. There's no point keeping the chip 
awake after a disable.


It's pretty likely for a DSI driver to have the clock active in order to 
allow the panel driver to send MIPI commands and things like that. So 
everything in pre_enable makes sense.

I don't know how the platform you're testing on is behaving in this respect?


>
> [...]
>
>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>>> +{
>>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>> +    unsigned int pval;
>>> +    u16 val;
>>> +    int ret;
>>> +
>>> +    /* Clear reset, disable PLL */
>>> +    regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>> Writing 0 to the RESET register is a no-op. Has no effect whatsoever, 
>> just wasting time and code.
>
> I would rather keep it to make sure the register is initialized.

Why? It's marked "volatile" so the regmap cache will not touch it. On 
the I2C level, there's absolutely no reason to do this.

>
>>> +    regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>> +
>>> +    /* Reference clock derived from DSI link clock. */
>>> +    regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
>>> + REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
>>> +        REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
>>> +    regmap_write(ctx->regmap, REG_DSI_CLK,
>>> + REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
>>> +    regmap_write(ctx->regmap, REG_RC_DSI_CLK,
>>> + REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
>>> +
>>> +    /* Set number of DSI lanes and LVDS link config. */
>>> +    regmap_write(ctx->regmap, REG_DSI_LANE,
>>> +        REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
>>> +        REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
>>> +        /* CHB is DSI85-only, set to default on DSI83/DSI84 */
>>> +        REG_DSI_LANE_CHB_DSI_LANES(3));
>>> +    /* No equalization. */
>>> +    regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
>>> +
>>> +    /* RGB888 is the only format supported so far. */
>>> +    val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
>>> +           REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
>>> +          (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
>>> +           REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
>>> +          REG_LVDS_FMT_CHA_24BPP_MODE;
>>> +    if (ctx->lvds_dual_link)
>>> +        val |= REG_LVDS_FMT_CHB_24BPP_MODE;
>>> +    else
>>> +        val |= REG_LVDS_FMT_LVDS_LINK_CFG;
>>> +
>>> +    regmap_write(ctx->regmap, REG_LVDS_FMT, val);
>>> +    regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
>>> +    regmap_write(ctx->regmap, REG_LVDS_LANE,
>>> +        (ctx->lvds_dual_link_even_odd_swap ?
>>> +         REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
>>> +        REG_LVDS_LANE_CHA_LVDS_TERM |
>>> +        REG_LVDS_LANE_CHB_LVDS_TERM);
>>> +    regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
>>> +
>>> +    regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
>>> +              &ctx->mode.hdisplay, 2);
>>
>> I think this ignores the endian format of the data. So this would 
>> only work on little-endian systems, right?
>
> Likely, can you double-check that ?
> Some cpu_to_le16() could help here then.

I'd add a small helper function that does the endian conversion and 
register write, e.g.

static int sn65dsi83_write16bit(struct sn65dsi83 *ctx, unsigned int reg, 
u16 value)


>>> +    regmap_bulk_write(ctx->regmap, 
>>> REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW,
>>> +              &ctx->mode.vdisplay, 2);
>>> +    val = 32 + 1;    /* 32 + 1 pixel clock to ensure proper 
>>> operation */
>>> +    regmap_bulk_write(ctx->regmap, REG_VID_CHA_SYNC_DELAY_LOW, 
>>> &val, 2);
>>> +    val = ctx->mode.hsync_end - ctx->mode.hsync_start;
>
> [...]


-- 
Mike Looijmans


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-25 12:08           ` Mike Looijmans
@ 2021-05-25 13:00             ` Marek Vasut
  2021-05-25 14:23               ` Mike Looijmans
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-25 13:00 UTC (permalink / raw)
  To: Mike Looijmans, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 5/25/21 2:08 PM, Mike Looijmans wrote:
> See below...

You can just comment inline and skip this top-post.

> Met vriendelijke groet / kind regards,
> 
> Mike Looijmans
> System Expert
> 
> 
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
> 
> T: +31 (0) 499 33 69 69
> E: mike.looijmans@topicproducts.com
> W: www.topic.nl
> 
> Please consider the environment before printing this e-mail
> On 25-05-2021 12:53, Marek Vasut wrote:
>> On 5/17/21 3:23 PM, Mike Looijmans wrote:
>>
>> Which system/soc are you testing this on ?
> 
> On a raspberry-pi 4 at the moment.

Ah, OK, it seems this bridge is popular on RPi.
Is there some adapter board with such a bridge for RPi available ?

>> [...]
>>
>>>> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
>>>> +{
>>>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>> +
>>>> +    /*
>>>> +     * Reset the chip, pull EN line low for t_reset=10ms,
>>>> +     * then high for t_en=1ms.
>>>> +     */
>>>> +    regcache_mark_dirty(ctx->regmap);
>>>> +    gpiod_set_value(ctx->enable_gpio, 0);
>>>> +    usleep_range(10000, 11000);
>>>> +    gpiod_set_value(ctx->enable_gpio, 1);
>>>> +    usleep_range(1000, 1100);
>>> Taking the chip out of reset here is not needed and may even disrupt 
>>> things, as the DSI hasn't set up anything yet so the clock may not be 
>>> running. I'd move this all into enable and get rid of the pre_enable 
>>> call. Similar for post_disable.
>>
>> I am still waiting for someone to confirm the behavior of the DSI 
>> clock and data lanes in pre_enable/enable() . The datasheet says the 
>> HS clock have to be running and data lanes must be in LP state during 
>> init, but I don't think that is guaranteed currently in either 
>> pre_enable or enable.
> 
> Neither is suited. pre-enable may have nothing, while enable has the 
> data lanes sending video according to the docs. So on many systems 
> either this driver or the DSI driver will need changes to make it work 
> properly.
> 
> On the raspberrypi, the DSI has the clock running in pre-enable, hence 
> putting everything in pre-enable instead of in enable makes the chip work.

I think someone from the RPi foundation mentioned this before.

> Alternatively, one can modify the RPi DSI code to start sending data 
> after the enable calls. That also works on my setup, with everything in 
> enable.
> 
> The major point here is that you should pick one and only one callback: 
> pre-enable or enable. The GPIO reset code as well as writing the 
> registers should be done in that one method.

Why , please elaborate ? It seems to be if there was no need for those 
two callbacks, there would be no two callbacks in the API in the first 
place. There is a chance you will get disable()->enable() sequence 
without going through post_disable()->pre_enable() as far as I can tell.

> Same for (post)disable for symmetry. There's no point keeping the chip 
> awake after a disable.
> 
> 
> It's pretty likely for a DSI driver to have the clock active in order to 
> allow the panel driver to send MIPI commands and things like that. So 
> everything in pre_enable makes sense.

That's how the RPi behaves, on MX8M the DSI clock are active only in 
enable. But that might be wrong, see below.

> I don't know how the platform you're testing on is behaving in this 
> respect?

iMX8M{M,N}.

And I suspect the DSI behaves differently than on RPi. And that is why I 
would like to get some clarification on what (clock, data, LP and HS) is 
enabled where from the maintainers.

>> [...]
>>
>>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>>>> +{
>>>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>> +    unsigned int pval;
>>>> +    u16 val;
>>>> +    int ret;
>>>> +
>>>> +    /* Clear reset, disable PLL */
>>>> +    regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>>> Writing 0 to the RESET register is a no-op. Has no effect whatsoever, 
>>> just wasting time and code.
>>
>> I would rather keep it to make sure the register is initialized.
> 
> Why? It's marked "volatile" so the regmap cache will not touch it. On 
> the I2C level, there's absolutely no reason to do this.

It still does trigger a write into the hardware.

>>>> +    regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>> +
>>>> +    /* Reference clock derived from DSI link clock. */
>>>> +    regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
>>>> + REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
>>>> +        REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
>>>> +    regmap_write(ctx->regmap, REG_DSI_CLK,
>>>> + REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
>>>> +    regmap_write(ctx->regmap, REG_RC_DSI_CLK,
>>>> + REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
>>>> +
>>>> +    /* Set number of DSI lanes and LVDS link config. */
>>>> +    regmap_write(ctx->regmap, REG_DSI_LANE,
>>>> +        REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
>>>> +        REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
>>>> +        /* CHB is DSI85-only, set to default on DSI83/DSI84 */
>>>> +        REG_DSI_LANE_CHB_DSI_LANES(3));
>>>> +    /* No equalization. */
>>>> +    regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
>>>> +
>>>> +    /* RGB888 is the only format supported so far. */
>>>> +    val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
>>>> +           REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
>>>> +          (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
>>>> +           REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
>>>> +          REG_LVDS_FMT_CHA_24BPP_MODE;
>>>> +    if (ctx->lvds_dual_link)
>>>> +        val |= REG_LVDS_FMT_CHB_24BPP_MODE;
>>>> +    else
>>>> +        val |= REG_LVDS_FMT_LVDS_LINK_CFG;
>>>> +
>>>> +    regmap_write(ctx->regmap, REG_LVDS_FMT, val);
>>>> +    regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
>>>> +    regmap_write(ctx->regmap, REG_LVDS_LANE,
>>>> +        (ctx->lvds_dual_link_even_odd_swap ?
>>>> +         REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
>>>> +        REG_LVDS_LANE_CHA_LVDS_TERM|
>>>> +        REG_LVDS_LANE_CHB_LVDS_TERM);
>>>> +    regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
>>>> +
>>>> +    regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
>>>> +              &ctx->mode.hdisplay, 2);
>>>
>>> I think this ignores the endian format of the data. So this would 
>>> only work on little-endian systems, right?
>>
>> Likely, can you double-check that ?
>> Some cpu_to_le16() could help here then.
> 
> I'd add a small helper function that does the endian conversion and 
> register write, e.g.
> 
> static int sn65dsi83_write16bit(struct sn65dsi83 *ctx, unsigned int reg, 
> u16 value)

That just adds unnecessary indirection and makes the code harder to 
read, so I won't do that. val = cpu_to_le16(...) looks good enough and 
there are already such sequences, i.e. val = ... ; regmap_bulk_write(...);

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-25 13:00             ` Marek Vasut
@ 2021-05-25 14:23               ` Mike Looijmans
  2021-05-25 14:42                 ` Marek Vasut
  0 siblings, 1 reply; 34+ messages in thread
From: Mike Looijmans @ 2021-05-25 14:23 UTC (permalink / raw)
  To: Marek Vasut, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

Comments inline.

(Without this top-post, the company mail server will inject a signature 
in some weird location.)


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 25-05-2021 15:00, Marek Vasut wrote:
> On 5/25/21 2:08 PM, Mike Looijmans wrote:
>> On 25-05-2021 12:53, Marek Vasut wrote:
>>> On 5/17/21 3:23 PM, Mike Looijmans wrote:
>>>
>>> Which system/soc are you testing this on ?
>>
>> On a raspberry-pi 4 at the moment.
>
> Ah, OK, it seems this bridge is popular on RPi.
> Is there some adapter board with such a bridge for RPi available ?

Nope, but about 4 subscribers on the RPi forum have created their own 
PCB. I'm working for a company that did their own PCB too and my job for 
them is to get it to work...

The DSI-to-LVDS bridge is a lot cheaper (and simpler) than a 
HDMI-to-LVDS bridge. In hardware that is.

>
>>> [...]
>>>
>>>>> +static void sn65dsi83_pre_enable(struct drm_bridge *bridge)
>>>>> +{
>>>>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>>> +
>>>>> +    /*
>>>>> +     * Reset the chip, pull EN line low for t_reset=10ms,
>>>>> +     * then high for t_en=1ms.
>>>>> +     */
>>>>> +    regcache_mark_dirty(ctx->regmap);
>>>>> +    gpiod_set_value(ctx->enable_gpio, 0);
>>>>> +    usleep_range(10000, 11000);
>>>>> +    gpiod_set_value(ctx->enable_gpio, 1);
>>>>> +    usleep_range(1000, 1100);
>>>> Taking the chip out of reset here is not needed and may even 
>>>> disrupt things, as the DSI hasn't set up anything yet so the clock 
>>>> may not be running. I'd move this all into enable and get rid of 
>>>> the pre_enable call. Similar for post_disable.
>>>
>>> I am still waiting for someone to confirm the behavior of the DSI 
>>> clock and data lanes in pre_enable/enable() . The datasheet says the 
>>> HS clock have to be running and data lanes must be in LP state 
>>> during init, but I don't think that is guaranteed currently in 
>>> either pre_enable or enable.
>>
>> Neither is suited. pre-enable may have nothing, while enable has the 
>> data lanes sending video according to the docs. So on many systems 
>> either this driver or the DSI driver will need changes to make it 
>> work properly.
>>
>> On the raspberrypi, the DSI has the clock running in pre-enable, 
>> hence putting everything in pre-enable instead of in enable makes the 
>> chip work.
>
> I think someone from the RPi foundation mentioned this before.

Yeah, he mentioned mentioning this on the RPi forum too.

>
>> Alternatively, one can modify the RPi DSI code to start sending data 
>> after the enable calls. That also works on my setup, with everything 
>> in enable.
>>
>> The major point here is that you should pick one and only one 
>> callback: pre-enable or enable. The GPIO reset code as well as 
>> writing the registers should be done in that one method.
>
> Why , please elaborate ? It seems to be if there was no need for those 
> two callbacks, there would be no two callbacks in the API in the first 
> place. There is a chance you will get disable()->enable() sequence 
> without going through post_disable()->pre_enable() as far as I can tell.

The datasheet states that "the DSI CLK lanes MUST be in HS state and the 
DSI data lanes MUST be driven to LP11 state" when the reset de-asserts 
(goes high) and when the CSR registers are being written.

Your driver now de-asserts the reset in the pre_enable and writes the 
CSR registers in enable. This is the "least likely to work" option.

Both the reset and the CSR writing are to be done in the same context. 
So either everything in "pre_enable", or everything in "enable". Which 
one is correct is up to the maintainers, I also don't know which is 
best. The other callback can just remain unused.

If the choice is to do the chip initialization in "pre_enable" then do 
all the de-initialization in "post_disable". If the choice is to do the 
chip initialization in "enable" then do all the de-initialization in 
"disable".

If for some platform the choice happens to be wrong, it's a very simple 
patch (just change the "ops" pointers) to change it and make it work for 
that platform.

Alternatively, it's possible to make it a runtime choice through 
devicetree or so as to whether the CSR initializes at "enable" or 
"pre-enable".


>
>> Same for (post)disable for symmetry. There's no point keeping the 
>> chip awake after a disable.
>>
>>
>> It's pretty likely for a DSI driver to have the clock active in order 
>> to allow the panel driver to send MIPI commands and things like that. 
>> So everything in pre_enable makes sense.
>
> That's how the RPi behaves, on MX8M the DSI clock are active only in 
> enable. But that might be wrong, see below.
>
>> I don't know how the platform you're testing on is behaving in this 
>> respect?
>
> iMX8M{M,N}.
>
> And I suspect the DSI behaves differently than on RPi. And that is why 
> I would like to get some clarification on what (clock, data, LP and 
> HS) is enabled where from the maintainers.

Suspect so. As I wrote before, any DSI that adheres to the documentation 
would never work with this chip. The chip won't work without clock and 
it also won't work if the DSI is already sending video data is my 
experience.


>
>>> [...]
>>>
>>>>> +static void sn65dsi83_enable(struct drm_bridge *bridge)
>>>>> +{
>>>>> +    struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
>>>>> +    unsigned int pval;
>>>>> +    u16 val;
>>>>> +    int ret;
>>>>> +
>>>>> +    /* Clear reset, disable PLL */
>>>>> +    regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
>>>> Writing 0 to the RESET register is a no-op. Has no effect 
>>>> whatsoever, just wasting time and code.
>>>
>>> I would rather keep it to make sure the register is initialized.
>>
>> Why? It's marked "volatile" so the regmap cache will not touch it. On 
>> the I2C level, there's absolutely no reason to do this.
>
> It still does trigger a write into the hardware.

And in hardware it does absolutely nothing. It says so in the datasheet. 
And even so, the chip's reset has just been asserted, so you can be 
pretty sure it's in a well-defined state already.

>
>>>>> +    regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>>> +
>>>>> +    /* Reference clock derived from DSI link clock. */
>>>>> +    regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
>>>>> + REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
>>>>> +        REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
>>>>> +    regmap_write(ctx->regmap, REG_DSI_CLK,
>>>>> + REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
>>>>> +    regmap_write(ctx->regmap, REG_RC_DSI_CLK,
>>>>> + REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
>>>>> +
>>>>> +    /* Set number of DSI lanes and LVDS link config. */
>>>>> +    regmap_write(ctx->regmap, REG_DSI_LANE,
>>>>> +        REG_DSI_LANE_LVDS_LINK_CFG_DUAL |
>>>>> +        REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
>>>>> +        /* CHB is DSI85-only, set to default on DSI83/DSI84 */
>>>>> +        REG_DSI_LANE_CHB_DSI_LANES(3));
>>>>> +    /* No equalization. */
>>>>> +    regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
>>>>> +
>>>>> +    /* RGB888 is the only format supported so far. */
>>>>> +    val = (ctx->mode.flags & DRM_MODE_FLAG_NHSYNC ?
>>>>> +           REG_LVDS_FMT_HS_NEG_POLARITY : 0) |
>>>>> +          (ctx->mode.flags & DRM_MODE_FLAG_NVSYNC ?
>>>>> +           REG_LVDS_FMT_VS_NEG_POLARITY : 0) |
>>>>> +          REG_LVDS_FMT_CHA_24BPP_MODE;
>>>>> +    if (ctx->lvds_dual_link)
>>>>> +        val |= REG_LVDS_FMT_CHB_24BPP_MODE;
>>>>> +    else
>>>>> +        val |= REG_LVDS_FMT_LVDS_LINK_CFG;
>>>>> +
>>>>> +    regmap_write(ctx->regmap, REG_LVDS_FMT, val);
>>>>> +    regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
>>>>> +    regmap_write(ctx->regmap, REG_LVDS_LANE,
>>>>> +        (ctx->lvds_dual_link_even_odd_swap ?
>>>>> +         REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
>>>>> +        REG_LVDS_LANE_CHA_LVDS_TERM|
>>>>> +        REG_LVDS_LANE_CHB_LVDS_TERM);
>>>>> +    regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
>>>>> +
>>>>> +    regmap_bulk_write(ctx->regmap, 
>>>>> REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW,
>>>>> +              &ctx->mode.hdisplay, 2);
>>>>
>>>> I think this ignores the endian format of the data. So this would 
>>>> only work on little-endian systems, right?
>>>
>>> Likely, can you double-check that ?
>>> Some cpu_to_le16() could help here then.
>>
>> I'd add a small helper function that does the endian conversion and 
>> register write, e.g.
>>
>> static int sn65dsi83_write16bit(struct sn65dsi83 *ctx, unsigned int 
>> reg, u16 value)
>
> That just adds unnecessary indirection and makes the code harder to 
> read, so I won't do that. val = cpu_to_le16(...) looks good enough and 
> there are already such sequences, i.e. val = ... ; 
> regmap_bulk_write(...);

I'd think the indirection would make it easier to read the code, but 
it's up to you really.

__le16 val = cpu_to_le16(ctx->mode.hdisplay);
regmap_bulk_write(ctx->regmap, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW, &val, 
sizeof(val));

versus

sn65dsi83_write16bit(ctx, REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW, 
ctx->mode.hdisplay);

-- 
Mike Looijmans


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-25 14:23               ` Mike Looijmans
@ 2021-05-25 14:42                 ` Marek Vasut
  2021-05-25 15:16                   ` Mike Looijmans
  0 siblings, 1 reply; 34+ messages in thread
From: Marek Vasut @ 2021-05-25 14:42 UTC (permalink / raw)
  To: Mike Looijmans, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart

On 5/25/21 4:23 PM, Mike Looijmans wrote:

Hi,

[...]

>>>> Which system/soc are you testing this on ?
>>>
>>> On a raspberry-pi 4 at the moment.
>>
>> Ah, OK, it seems this bridge is popular on RPi.
>> Is there some adapter board with such a bridge for RPi available ?
> 
> Nope, but about 4 subscribers on the RPi forum have created their own 
> PCB. I'm working for a company that did their own PCB too and my job for 
> them is to get it to work...
> 
> The DSI-to-LVDS bridge is a lot cheaper (and simpler) than a 
> HDMI-to-LVDS bridge. In hardware that is.

Oh, I see

[...]

>>> Alternatively, one can modify the RPi DSI code to start sending data 
>>> after the enable calls. That also works on my setup, with everything 
>>> in enable.
>>>
>>> The major point here is that you should pick one and only one 
>>> callback: pre-enable or enable. The GPIO reset code as well as 
>>> writing the registers should be done in that one method.
>>
>> Why , please elaborate ? It seems to be if there was no need for those 
>> two callbacks, there would be no two callbacks in the API in the first 
>> place. There is a chance you will get disable()->enable() sequence 
>> without going through post_disable()->pre_enable() as far as I can tell.
> 
> The datasheet states that "the DSI CLK lanes MUST be in HS state and the 
> DSI data lanes MUST be driven to LP11 state" when the reset de-asserts 
> (goes high) and when the CSR registers are being written.
> 
> Your driver now de-asserts the reset in the pre_enable and writes the 
> CSR registers in enable. This is the "least likely to work" option.

Understood. However, it seems to work on iMX8MM and MN just fine.

Is there a problem on the RPi, that the driver does not work on it ?

> Both the reset and the CSR writing are to be done in the same context. 
> So either everything in "pre_enable", or everything in "enable". Which 
> one is correct is up to the maintainers, I also don't know which is 
> best. The other callback can just remain unused.
> 
> If the choice is to do the chip initialization in "pre_enable" then do 
> all the de-initialization in "post_disable". If the choice is to do the 
> chip initialization in "enable" then do all the de-initialization in 
> "disable".
> 
> If for some platform the choice happens to be wrong, it's a very simple 
> patch (just change the "ops" pointers) to change it and make it work for 
> that platform.
> 
> Alternatively, it's possible to make it a runtime choice through 
> devicetree or so as to whether the CSR initializes at "enable" or 
> "pre-enable".

That would mean you encode policy in DT, so not an option.

I would suggest we stop this discussion until there is input from the 
maintainers. It could even be there is an API missing for configuring 
the clock/data/LP/HS modes which needs to be added.

>>> Same for (post)disable for symmetry. There's no point keeping the 
>>> chip awake after a disable.
>>>
>>>
>>> It's pretty likely for a DSI driver to have the clock active in order 
>>> to allow the panel driver to send MIPI commands and things like that. 
>>> So everything in pre_enable makes sense.
>>
>> That's how the RPi behaves, on MX8M the DSI clock are active only in 
>> enable. But that might be wrong, see below.
>>
>>> I don't know how the platform you're testing on is behaving in this 
>>> respect?
>>
>> iMX8M{M,N}.
>>
>> And I suspect the DSI behaves differently than on RPi. And that is why 
>> I would like to get some clarification on what (clock, data, LP and 
>> HS) is enabled where from the maintainers.
> 
> Suspect so.

Yes

> As I wrote before, any DSI that adheres to the documentation 
> would never work with this chip. The chip won't work without clock and 
> it also won't work if the DSI is already sending video data is my 
> experience.

The later part would mean this driver could never work on iMX8M, but it 
does, on multiple iMX8MM and MN. So the chip must be tolerant at least 
toward data on the data lanes when it is being configured.

[...]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [V3, 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
  2021-05-25 14:42                 ` Marek Vasut
@ 2021-05-25 15:16                   ` Mike Looijmans
  0 siblings, 0 replies; 34+ messages in thread
From: Mike Looijmans @ 2021-05-25 15:16 UTC (permalink / raw)
  To: Marek Vasut, dri-devel
  Cc: Loic Poulain, ch, Douglas Anderson, Stephen Boyd,
	Philippe Schenker, Jagan Teki, Valentin Raevsky, Sam Ravnborg,
	Laurent Pinchart


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 25-05-2021 16:42, Marek Vasut wrote:
> On 5/25/21 4:23 PM, Mike Looijmans wrote:
>
> [...]
>
>>>> Alternatively, one can modify the RPi DSI code to start sending 
>>>> data after the enable calls. That also works on my setup, with 
>>>> everything in enable.
>>>>
>>>> The major point here is that you should pick one and only one 
>>>> callback: pre-enable or enable. The GPIO reset code as well as 
>>>> writing the registers should be done in that one method.
>>>
>>> Why , please elaborate ? It seems to be if there was no need for 
>>> those two callbacks, there would be no two callbacks in the API in 
>>> the first place. There is a chance you will get disable()->enable() 
>>> sequence without going through post_disable()->pre_enable() as far 
>>> as I can tell.
>>
>> The datasheet states that "the DSI CLK lanes MUST be in HS state and 
>> the DSI data lanes MUST be driven to LP11 state" when the reset 
>> de-asserts (goes high) and when the CSR registers are being written.
>>
>> Your driver now de-asserts the reset in the pre_enable and writes the 
>> CSR registers in enable. This is the "least likely to work" option.
>
> Understood. However, it seems to work on iMX8MM and MN just fine.
>
> Is there a problem on the RPi, that the driver does not work on it ?

On the RPi, without any changes, the board won't output anything. Only 
the test pattern works (using i2cset to enable it). There are two ways 
to make it work:
- Use the current RPi DSI driver as is, and move all initialization code 
in the sn65dsi83 driver to the "pre_enable" callback.

- Change the RPi DSI driver to not send any video data until after 
"enable" and move all initialization code in the sn65dsi83 driver to the 
"enable" callback.


There's also a bug in the RPi DSI driver that it does not call the 
mode_set and mode_valid methods, so it needed workarounds for that too. 
But that should be fixed in the RPi DSI driver and not in your code.

It's a surprise to me then that it works on the iMX. On the RPi it 
absolutely won't work if the DSI is sending video data when the CSR 
registers are being written. It does not seem to matter whether the data 
lanes are in LP00 or LP11 state though, either mode appears to work.

Maybe the iMX is still in a command mode and doesn't actually start 
sending video until after the "enable" callback?


Given that the test-pattern mode does work regardless of the data lane 
state, it appears that the DSI input of the sn65dsi83 chip goes berserk 
when the video data arrives before the CSR registers were written. It 
won't recover from that without a full reset.


>
>> Both the reset and the CSR writing are to be done in the same 
>> context. So either everything in "pre_enable", or everything in 
>> "enable". Which one is correct is up to the maintainers, I also don't 
>> know which is best. The other callback can just remain unused.
>>
>> If the choice is to do the chip initialization in "pre_enable" then 
>> do all the de-initialization in "post_disable". If the choice is to 
>> do the chip initialization in "enable" then do all the 
>> de-initialization in "disable".
>>
>> If for some platform the choice happens to be wrong, it's a very 
>> simple patch (just change the "ops" pointers) to change it and make 
>> it work for that platform.
>>
>> Alternatively, it's possible to make it a runtime choice through 
>> devicetree or so as to whether the CSR initializes at "enable" or 
>> "pre-enable".
>
> That would mean you encode policy in DT, so not an option.
>
> I would suggest we stop this discussion until there is input from the 
> maintainers. It could even be there is an API missing for configuring 
> the clock/data/LP/HS modes which needs to be added.

Agree...

There's no easy way out here. Adding a "post_pre_enable" or 
"pre_enable_clock_up_data_down" callback is not going to make it I guess...

> [...]


-- 
Mike Looijmans


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2021-05-25 15:16 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-05 10:02 [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings Marek Vasut
2021-05-05 10:02 ` Marek Vasut
2021-05-05 10:02 ` [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver Marek Vasut
2021-05-05 12:42   ` Linus Walleij
2021-05-06  9:45   ` Dave Stevenson
2021-05-06 12:48     ` Marek Vasut
2021-05-06 13:03       ` Laurent Pinchart
2021-05-06 14:57         ` Marek Vasut
2021-05-06 17:03       ` Dave Stevenson
2021-05-06 20:49         ` Marek Vasut
2021-05-07  8:55           ` Dave Stevenson
2021-05-06 15:38   ` Frieder Schrempf
2021-05-06 15:46     ` Marek Vasut
2021-05-06 16:03       ` Frieder Schrempf
2021-05-06 20:51         ` Marek Vasut
2021-05-07  9:17           ` Dave Stevenson
2021-05-08 20:10             ` Marek Vasut
2021-05-07 12:48   ` Dave Stevenson
2021-05-08 20:16     ` Marek Vasut
2021-05-10  9:58       ` Dave Stevenson
2021-05-10 11:16         ` Marek Vasut
2021-05-10 18:04           ` Dave Stevenson
2021-05-10 19:29             ` Marek Vasut
     [not found]   ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.d251689f-a6ba-486d-bfa1-070ac0c167d5@emailsignatures365.codetwo.com>
     [not found]     ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.81349e00-3f39-4654-ab28-8c85568d0c51@emailsignatures365.codetwo.com>
2021-05-17 13:23       ` [V3, " Mike Looijmans
2021-05-25 10:53         ` Marek Vasut
2021-05-25 12:08           ` Mike Looijmans
2021-05-25 13:00             ` Marek Vasut
2021-05-25 14:23               ` Mike Looijmans
2021-05-25 14:42                 ` Marek Vasut
2021-05-25 15:16                   ` Mike Looijmans
2021-05-05 12:38 ` [PATCH V3 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings Linus Walleij
2021-05-05 12:38   ` Linus Walleij
2021-05-07  1:00 ` Rob Herring
2021-05-07  1:00   ` Rob Herring

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.