Re: [PATCH] drm/rockchip: rgb: don't count non-existent devices when determining subdrivers
Am Dienstag, 21. Januar 2020, 23:48:28 CET schrieb Heiko Stuebner: > From: Heiko Stuebner > > rockchip_drm_endpoint_is_subdriver() may also return error codes. > For example if the target-node is in the disabled state, so no > platform-device is getting created for it. > > In that case current code would count that as external rgb device, > which in turn would make probing the rockchip-drm device fail. > > So only count the target as rgb device if the function actually > returns 0. > > Signed-off-by: Heiko Stuebner applied to drm-misc-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/panel: add panel driver for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is 5.0" 720x1280 DSI display. There are two variants
with essentially the same name, LTK050H3146W and LTK050H3146W-A2.
They differ in their init sequence and mode details.
changes in v2:
- add display variants
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk050h3146w.c| 697 ++
3 files changed, 709 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..d56258b9fcaf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -137,6 +137,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK050H3146W
+ tristate "Leadtek LTK050H3146W panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Leadtek LTK050H3146W
+ TFT-LCD modules. The panel has a 720x1280 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_LEADTEK_LTK500HD1829
tristate "Leadtek LTK500HD1829 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..2335a1e32ae0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
new file mode 100644
index ..43fbedf01b85
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -0,0 +1,697 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct ltk050h3146w_cmd {
+ char cmd;
+ char data;
+};
+
+struct ltk050h3146w;
+struct ltk050h3146w_desc {
+ const struct drm_display_mode *mode;
+ int (*init)(struct ltk050h3146w *ctx);
+};
+
+struct ltk050h3146w {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vci;
+ struct regulator *iovcc;
+ const struct ltk050h3146w_desc *panel_desc;
+ bool prepared;
+};
+
+static const struct ltk050h3146w_cmd page1_cmds[] = {
+ { 0x22, 0x0A }, /* BGR SS GS */
+ { 0x31, 0x00 }, /* column inversion */
+ { 0x53, 0xA2 }, /* VCOM1 */
+ { 0x55, 0xA2 }, /* VCOM2 */
+ { 0x50, 0x81 }, /* VREG1OUT=5V */
+ { 0x51, 0x85 }, /* VREG2OUT=-5V */
+ { 0x62, 0x0D }, /* EQT Time setting */
+/*
+ * For whatever reason the vendor init selected page 1 here _again_
+ * Is this supposed to be page 2?
+ */
+ { 0xA0, 0x00 },
+ { 0xA1, 0x1A },
+ { 0xA2, 0x28 },
+ { 0xA3, 0x13 },
+ { 0xA4, 0x16 },
+ { 0xA5, 0x29 },
+ { 0xA6, 0x1D },
+ { 0xA7, 0x1E },
+ { 0xA8, 0x84 },
+ { 0xA9, 0x1C },
+ { 0xAA, 0x28 },
+ { 0xAB, 0x75 },
+ { 0xAC, 0x1A },
+ { 0xAD, 0x19 },
+ { 0xAE, 0x4D },
+ { 0xAF, 0x22 },
+ { 0xB0, 0x28 },
+ { 0xB1, 0x54 },
+ { 0xB2, 0x66 },
+ { 0xB3, 0x39 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x1A },
+ { 0xC2, 0x28 },
+ { 0xC3, 0x13 },
+ { 0xC4, 0x16 },
+ { 0xC5, 0x29 },
+ { 0xC6, 0x1D },
+ { 0xC7, 0x1E },
+ { 0xC8, 0x84 },
+ { 0xC9, 0x1C },
+ { 0xCA, 0x28 },
+ { 0xCB, 0x75 },
+ { 0xCC, 0x1A },
+ { 0xCD, 0x19 },
+ { 0xCE, 0x4D },
+ { 0xCF, 0x22 },
+ { 0xD0, 0x28 },
+ { 0xD1, 0x54 },
+ { 0xD2, 0x66 },
+ { 0xD3, 0x39 },
+};
+
+static const struct ltk050h3146w_cmd page3_cmds[] = {
+ { 0x01, 0x00 },
+ { 0x02, 0x00 },
+ { 0x03, 0x73 },
+ { 0x04, 0x00 },
+ { 0x05, 0x00 },
+ { 0x06, 0x0a },
+ { 0x07, 0x00 },
+ { 0x08, 0x0
[PATCH v2 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is a 5.0" 720x1280 DSI display.
changes in v2:
- add display variants
Signed-off-by: Heiko Stuebner
---
.../display/panel/leadtek,ltk050h3146w.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
new file mode 100644
index ..a372bdc5bde1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - leadtek,ltk050h3146w
+ - leadtek,ltk050h3146w-a2
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk050h3146w";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_1v8>;
+vci-supply = <_lcd>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/panel: add panel driver for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is 5.0" 720x1280 DSI display. There are two variants
with essentially the same name, LTK050H3146W and LTK050H3146W-A2.
They differ in their init sequence and mode details.
changes in v2:
- add display variants
changes in v3:
- fixed indentation and artifacts found by Sam
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk050h3146w.c| 691 ++
3 files changed, 703 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..d56258b9fcaf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -137,6 +137,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK050H3146W
+ tristate "Leadtek LTK050H3146W panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Leadtek LTK050H3146W
+ TFT-LCD modules. The panel has a 720x1280 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_LEADTEK_LTK500HD1829
tristate "Leadtek LTK500HD1829 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..2335a1e32ae0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
new file mode 100644
index ..5a7a31c8513e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct ltk050h3146w_cmd {
+ char cmd;
+ char data;
+};
+
+struct ltk050h3146w;
+struct ltk050h3146w_desc {
+ const struct drm_display_mode *mode;
+ int (*init)(struct ltk050h3146w *ctx);
+};
+
+struct ltk050h3146w {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vci;
+ struct regulator *iovcc;
+ const struct ltk050h3146w_desc *panel_desc;
+ bool prepared;
+};
+
+static const struct ltk050h3146w_cmd page1_cmds[] = {
+ { 0x22, 0x0A }, /* BGR SS GS */
+ { 0x31, 0x00 }, /* column inversion */
+ { 0x53, 0xA2 }, /* VCOM1 */
+ { 0x55, 0xA2 }, /* VCOM2 */
+ { 0x50, 0x81 }, /* VREG1OUT=5V */
+ { 0x51, 0x85 }, /* VREG2OUT=-5V */
+ { 0x62, 0x0D }, /* EQT Time setting */
+/*
+ * The vendor init selected page 1 here _again_
+ * Is this supposed to be page 2?
+ */
+ { 0xA0, 0x00 },
+ { 0xA1, 0x1A },
+ { 0xA2, 0x28 },
+ { 0xA3, 0x13 },
+ { 0xA4, 0x16 },
+ { 0xA5, 0x29 },
+ { 0xA6, 0x1D },
+ { 0xA7, 0x1E },
+ { 0xA8, 0x84 },
+ { 0xA9, 0x1C },
+ { 0xAA, 0x28 },
+ { 0xAB, 0x75 },
+ { 0xAC, 0x1A },
+ { 0xAD, 0x19 },
+ { 0xAE, 0x4D },
+ { 0xAF, 0x22 },
+ { 0xB0, 0x28 },
+ { 0xB1, 0x54 },
+ { 0xB2, 0x66 },
+ { 0xB3, 0x39 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x1A },
+ { 0xC2, 0x28 },
+ { 0xC3, 0x13 },
+ { 0xC4, 0x16 },
+ { 0xC5, 0x29 },
+ { 0xC6, 0x1D },
+ { 0xC7, 0x1E },
+ { 0xC8, 0x84 },
+ { 0xC9, 0x1C },
+ { 0xCA, 0x28 },
+ { 0xCB, 0x75 },
+ { 0xCC, 0x1A },
+ { 0xCD, 0x19 },
+ { 0xCE, 0x4D },
+ { 0xCF, 0x22 },
+ { 0xD0, 0x28 },
+ { 0xD1, 0x54 },
+ { 0xD2, 0x66 },
+ { 0xD3, 0x39 },
+};
+
+static const struct ltk050h3146w_cmd page3_cmds[] = {
+ { 0x01, 0x00 },
+ { 0x02, 0x00 },
+ { 0x03, 0x73 },
+ { 0x04, 0x00 },
+ { 0x05, 0x00 },
+ { 0x06, 0x0a },
+ { 0x0
[PATCH v3 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is a 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
Sam said he had applied this to drm-misc-next already,
but I can't see it so far, so included for completenes.
.../display/panel/leadtek,ltk050h3146w.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
new file mode 100644
index ..a372bdc5bde1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - leadtek,ltk050h3146w
+ - leadtek,ltk050h3146w-a2
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk050h3146w";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_1v8>;
+vci-supply = <_lcd>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: display: convert rockchip rk3066 hdmi bindings to yaml
On Fri, 3 Apr 2020 15:36:30 +0200, Johan Jonker wrote: > Current dts files with 'hdmi' nodes for rk3066 are manually verified. > In order to automate this process rockchip,rk3066-hdmi.txt > has to be converted to yaml. > > Signed-off-by: Johan Jonker > Reviewed-by: Rob Herring > > [...] Applied, thanks! [1/1] dt-bindings: display: convert rockchip rk3066 hdmi bindings to yaml commit: 8eea6e26fc2eda6922e5008ccb7f55bc1775d5b3 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: display: convert rockchip rk3066 hdmi bindings to yaml
Hi Johan, Am Freitag, 3. April 2020, 15:36:30 CEST schrieb Johan Jonker: > Current dts files with 'hdmi' nodes for rk3066 are manually verified. > In order to automate this process rockchip,rk3066-hdmi.txt > has to be converted to yaml. > > Signed-off-by: Johan Jonker > +++ > b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml > @@ -0,0 +1,140 @@ > +# SPDX-License-Identifier: GPL-2.0 checkpatch complains about the licensing: -:100: WARNING:SPDX_LICENSE_TAG: DT binding documents should be licensed (GPL-2.0-only OR BSD-2-Clause) #100: FILE: Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml:1: +# SPDX-License-Identifier: GPL-2.0 please consider adapting the license accordingly Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock
Am Donnerstag, 2. April 2020, 15:13:10 CEST schrieb Ville Syrjälä:
> On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> > Hi,
> >
> > Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > The currently listed dotclock disagrees with the currently
> > > listed vrefresh rate. Change the dotclock to match the vrefresh.
> > >
> > > Someone tell me which (if either) of the dotclock or vreresh is
> > > correct?
> >
> > The values came that way from the vendor .
> > And lookin at other Leadtek display datasheets, 60Hz should be the
> > correct refresh rate.
> >
> > The display is also running happily at the 69MHz of
> > your patch, so
> >
> > Tested-by: Heiko Stuebner
>
> Thanks for confirming.
>
> I think this patch the last one with a huge difference between
> vrefresh and clock. So once this goes in I'm thinking of declaring
> the remaining patches as not important and pushing ahead with the
> mode dieting. Can someone ack this so I can get it in?
hmm, not sure which one you want, so please pick one
Acked-by: Heiko Stuebner
or for the address I use whan applying drm-misc commits:
Acked-by: Heiko Stuebner
Heiko
> > >
> > > Cc: Heiko Stuebner
> > > Cc: Sam Ravnborg
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > index 76ecf2de9c44..113ab9c0396b 100644
> > > --- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
> > > @@ -377,7 +377,7 @@ static const struct drm_display_mode default_mode = {
> > > .vsync_end = 1280 + 30 + 4,
> > > .vtotal = 1280 + 30 + 4 + 12,
> > > .vrefresh = 60,
> > > - .clock = 41600,
> > > + .clock = 69217,
> > > .width_mm = 62,
> > > .height_mm = 110,
> > > };
> > >
> >
> >
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel: add panel driver for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK500HD1829W is 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk050h3146w.c| 589 ++
3 files changed, 601 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..d56258b9fcaf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -137,6 +137,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK050H3146W
+ tristate "Leadtek LTK050H3146W panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Leadtek LTK050H3146W
+ TFT-LCD modules. The panel has a 720x1280 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_LEADTEK_LTK500HD1829
tristate "Leadtek LTK500HD1829 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..2335a1e32ae0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
new file mode 100644
index ..d7afcdf5538a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct ltk050h3146w_cmd {
+ char cmd;
+ char data;
+};
+
+static const struct ltk050h3146w_cmd page1_cmds[] = {
+ { 0x22, 0x0A }, /* BGR SS GS */
+ { 0x31, 0x00 }, /* column inversion */
+ { 0x53, 0x8A }, /* VCOM1 */
+ { 0x55, 0xA2 }, /* VCOM2 */
+ { 0x50, 0x81 }, /* VREG1OUT=5V */
+ { 0x51, 0x85 }, /* VREG2OUT=-5V */
+ { 0x62, 0x0D }, /* EQT Time setting */
+/*
+ * For whatever reason the vendor init selected page 1 here _again_
+ * Is this supposed to be page 2?
+ */
+ { 0xA0, 0x00 },
+ { 0xA1, 0x1A },
+ { 0xA2, 0x28 },
+ { 0xA3, 0x13 },
+ { 0xA4, 0x16 },
+ { 0xA5, 0x29 },
+ { 0xA6, 0x1D },
+ { 0xA7, 0x1E },
+ { 0xA8, 0x84 },
+ { 0xA9, 0x1C },
+ { 0xAA, 0x28 },
+ { 0xAB, 0x75 },
+ { 0xAC, 0x1A },
+ { 0xAD, 0x19 },
+ { 0xAE, 0x4D },
+ { 0xAF, 0x22 },
+ { 0xB0, 0x28 },
+ { 0xB1, 0x54 },
+ { 0xB2, 0x66 },
+ { 0xB3, 0x39 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x1A },
+ { 0xC2, 0x28 },
+ { 0xC3, 0x13 },
+ { 0xC4, 0x16 },
+ { 0xC5, 0x29 },
+ { 0xC6, 0x1D },
+ { 0xC7, 0x1E },
+ { 0xC8, 0x84 },
+ { 0xC9, 0x1C },
+ { 0xCA, 0x28 },
+ { 0xCB, 0x75 },
+ { 0xCC, 0x1A },
+ { 0xCD, 0x19 },
+ { 0xCE, 0x4D },
+ { 0xCF, 0x22 },
+ { 0xD0, 0x28 },
+ { 0xD1, 0x54 },
+ { 0xD2, 0x66 },
+ { 0xD3, 0x39 },
+};
+
+static const struct ltk050h3146w_cmd page3_cmds[] = {
+ { 0x01, 0x00 },
+ { 0x02, 0x00 },
+ { 0x03, 0x73 },
+ { 0x04, 0x00 },
+ { 0x05, 0x00 },
+ { 0x06, 0x0a },
+ { 0x07, 0x00 },
+ { 0x08, 0x00 },
+ { 0x09, 0x01 },
+ { 0x0a, 0x00 },
+ { 0x0b, 0x00 },
+ { 0x0c, 0x01 },
+ { 0x0d, 0x00 },
+ { 0x0e, 0x00 },
+ { 0x0f, 0x1d },
+ { 0x10, 0x1d },
+ { 0x11, 0x00 },
+ { 0x12, 0x00 },
+ { 0x13, 0x00 },
+ { 0x14, 0x00 },
+ { 0x15, 0x00 },
+ { 0x16, 0x00 },
+ { 0x17, 0x00 },
+ { 0x18, 0x00 },
+ { 0x19, 0x00 },
+ { 0x1a, 0x00 },
+ { 0x1b, 0x00 },
+ { 0x1c, 0x00 },
+ { 0x1d, 0x00 },
+ { 0x1e, 0x40 },
+ { 0x1f, 0x80 },
+ { 0x20, 0x06 },
+ { 0x21, 0x02 },
+ { 0x2
[PATCH 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is a 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
.../display/panel/leadtek,ltk050h3146w.yaml | 49 +++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
new file mode 100644
index ..91a0212b63b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: leadtek,ltk050h3146w
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk050h3146w";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_1v8>;
+vci-supply = <_lcd>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Remove unneeded semicolon
On Fri, 24 Apr 2020 15:44:10 +0800, Zheng Bin wrote: > Fixes coccicheck warning: > > drivers/gpu/drm/rockchip/cdn-dp-reg.c:604:2-3: Unneeded semicolon > drivers/gpu/drm/rockchip/cdn-dp-reg.c:622:2-3: Unneeded semicolon > drivers/gpu/drm/rockchip/cdn-dp-reg.c:703:2-3: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: Zheng Bin > > [...] Applied, thanks! [1/1] drm/rockchip: Remove unneeded semicolon commit: 611e22b1d9f61a8742c99433de9ff40795574c61 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static
On Sun, 26 Apr 2020 18:16:53 +0200, Enric Balletbo i Serra wrote: > This fixes the following warning detected when running make with W=1 > > drivers/gpu/drm/rockchip//cdn-dp-core.c:1112:5: warning: no previous > prototype for ‘cdn_dp_suspend’ [-Wmissing-prototypes] > > drivers/gpu/drm/rockchip//cdn-dp-core.c:1126:5: warning: no previous > prototype for ‘cdn_dp_resume’ [-Wmissing-prototypes] > > [...] Applied, thanks! [1/1] drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static commit: 7c49abb4c2f8853520abc05b7f7e8b751fbb3086 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: innolux p097pfg dpms off/on fails (on gru-scarlet) with dw-mipi-dsi
Hi Samuel, Am Montag, 31. August 2020, 02:47:56 CEST schrieb Samuel Dionne-Riel: > I have an Asus Chromebook Tablet CT100PA, which I will refer to as > "dumo" from this point on, which is a specific variant of gru-scarlet. > As far as I am aware, all gru-scarlet are the same, except for the > display, and in turn the different scarlets with the innolux panel > are the same. > > I do not have the hardware to verify the kingdisplay variant's > behaviour, though I don't really expect it to fail the same way, but it > is still a possibility that there is a root cause that could cause a > similar failure. as I said in that chat yesterday, this really looks like an issue with how the dw-mipi-dsi handles powering on and off via the "hack" in mode_set, which doesn't get called again in non-atomic contexts. --- Reproducing the text from the paste from yesterday DRM component enablement is complex and runs in 3 stages: - mode_set goes outwards from crtc -> bridges -> panel - pre_enable goes inwards panel -> bridges -> crtc - enables again goes outwards crtc -> bridges -> panel The pre_enable callback for panels is meant to do its powerup which includes sending its init-sequence - see struct drm_panel documentation. But this in turn generally requires the dsi controller to be up and running. With pre_enable only running inwards the dsi-controller pre_enable only runs _after_ the panel's pre_enable, making panels unable to receive their init sequences. dw_mipi_dsi solved this "creatively" by putting the relevant commands into the mode_set (including clocks and phy setup) and in all-atomic environments this seems to work "ok", as mode_set gets call on every unblank of the display. But this solution stops working once applications use non-atomic modesetting, like X11 with the patch applied to v5.4 to block it from using atomic modesetting or an old qt (v5.9) in this case. Here only the pre_enable and enable callbacks gets called without invoking mode_set before, resulting in display output breaking after the first time the display gets disabled (like blanked due inactivity). For the short term fix this by simply not disabling the dw-dsi parts. --- And while I wanted to tackle that problem at some point, so far I haven't found the time to do so. I've added Yannick and Angelo who also worked on the driver, maybe they have more ideas. Heiko > The display will apparently suspend (right wording?) fine with DPMS, > but will not resume (wording?) fine. This has been an issue since the > introduction of the driver and the introduction of the device (scarlet) > to the kernel, and is still on 5.9-rc2. > > Doing the following: > > $ xset dpms force off # standby, or suspend > $ xset dpms force on > > Pretty much instantly the following messages are logged: > > [ 53.731851] dw-mipi-dsi-rockchip ff96.mipi: failed to write command > FIFO > [ 53.739815] panel-innolux-p079zca ff96.mipi.0: failed to write command > 0 > > Then 120 seconds later, this pair of WARN: > > [ 173.754168] [ cut here ] > [ 173.759343] pclk_mipi_dsi1 already disabled > [ 173.764076] WARNING: CPU: 2 PID: 5182 at drivers/clk/clk.c:952 > clk_core_disable+0x2c/0x94 > [ 173.773216] Modules linked in: > [ 173.776639] CPU: 2 PID: 5182 Comm: X Not tainted 5.9.0-rc2 #1-mobile-nixos > [ 173.784323] Hardware name: Google Scarlet (DT) > [ 173.789292] pstate: 4085 (nZcv daIf -PAN -UAO BTYPE=--) > [ 173.795522] pc : clk_core_disable+0x2c/0x94 > [ 173.800199] lr : clk_core_disable+0x2c/0x94 > [ 173.804871] sp : 800011d3ba20 > [ 173.808573] x29: 800011d3ba20 x28: 0028 > [ 173.814514] x27: c32bdf00 x26: 0038 > [ 173.820455] x25: 800010d2e2eb x24: edece000 > [ 173.826395] x23: f0bea680 x22: 0001 > [ 173.832326] x21: ef82e0e0 x20: f0986500 > [ 173.838266] x19: f0986500 x18: > [ 173.844198] x17: x16: > [ 173.850137] x15: 000a x14: 000b962f > [ 173.856077] x13: 800091d3b76f x12: 0006 > [ 173.862008] x11: x10: 0030 > [ 173.867939] x9 : 800011d3b77d x8 : > [ 173.873869] x7 : 0008 x6 : 80001118811e > [ 173.879809] x5 : f5589e48 x4 : > [ 173.885741] x3 : 0027 x2 : 0027 > [ 173.891680] x1 : e5c3ee40 x0 : 001f > [ 173.897612] Call trace: > [ 173.900349] clk_core_disable+0x2c/0x94 > [ 173.904637] clk_core_disable_lock+0x20/0x34 > [ 173.909413] clk_disable+0x1c/0x28 > [ 173.913220] dw_mipi_dsi_bridge_post_disable+0x80/0x120 > [ 173.919065] drm_atomic_bridge_chain_post_disable+0x74/0x98
Re: [PATCH] drm/bridge/synopsys: dsi: fix initialization sequence
Am Freitag, 18. September 2020, 13:46:53 CEST schrieb Yannick Fertre:
> The current driver calls drm_bridge_add(), to add the dsi bridge
> to the global bridge list, in dw_mipi_dsi_host_attach().
> Thus, it relies on the probing of panel or bridge sub-nodes to
> trigger the execution of dsi host attach() that will, in turn,
> call dw_mipi_dsi_host_attach().
> This causes an incomplete driver initialization if the panel or
> the next bridge is not present as sub-node, e.g. because it is an
> i2c device, thus sub-node of the respective i2c controller.
Actually the drm_of_find_panel_or_bridge() works on of-graph nodes,
so having an remote-port pointing to the i2c/spi/whatever driver
should just work - and no need for the driver to be a subnode itself.
And while my memory is fuzzy, I think I remember Andrzej requesting
only registering the bridge once we know something is connected,
aka when it calls dsi_attach.
Heiko
>
> Move the relevant code from host attach() to probe(), and the
> corresponding code from detach() to remove().
>
> Signed-off-by: Antonio Borneo
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 73 ---
> 1 file changed, 48 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 6b268f9445b3..aa74abddc79f 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -314,9 +314,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
> *host,
> {
> struct dw_mipi_dsi *dsi = host_to_dsi(host);
> const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> - struct drm_bridge *bridge;
> - struct drm_panel *panel;
> - int ret;
> + int ret = -ENODEV;
>
> if (device->lanes > dsi->plat_data->max_data_lanes) {
> dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
> @@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
> *host,
> dsi->format = device->format;
> dsi->mode_flags = device->mode_flags;
>
> - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> - , );
> - if (ret)
> - return ret;
> -
> - if (panel) {
> - bridge = drm_panel_bridge_add_typed(panel,
> - DRM_MODE_CONNECTOR_DSI);
> - if (IS_ERR(bridge))
> - return PTR_ERR(bridge);
> - }
> -
> - dsi->panel_bridge = bridge;
> -
> - drm_bridge_add(>bridge);
> -
> if (pdata->host_ops && pdata->host_ops->attach) {
> ret = pdata->host_ops->attach(pdata->priv_data, device);
> if (ret < 0)
> @@ -367,10 +349,6 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
> *host,
> return ret;
> }
>
> - drm_of_panel_bridge_remove(host->dev->of_node, 1, 0);
> -
> - drm_bridge_remove(>bridge);
> -
> return 0;
> }
>
> @@ -1105,6 +1083,9 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> struct device *dev = >dev;
> struct reset_control *apb_rst;
> struct dw_mipi_dsi *dsi;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> + int i, nb_endpoints;
> int ret;
>
> dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> @@ -1172,8 +1153,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> ret = mipi_dsi_host_register(>dsi_host);
> if (ret) {
> dev_err(dev, "Failed to register MIPI host: %d\n", ret);
> - dw_mipi_dsi_debugfs_remove(dsi);
> - return ERR_PTR(ret);
> + goto err_pmr_enable;
> }
>
> dsi->bridge.driver_private = dsi;
> @@ -1182,11 +1162,54 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dsi->bridge.of_node = pdev->dev.of_node;
> #endif
>
> + /* Get number of endpoints */
> + nb_endpoints = of_graph_get_endpoint_count(pdev->dev.of_node);
> + if (!nb_endpoints) {
> + ret = -ENODEV;
> + goto err_host_reg;
> + }
> +
> + for (i = 1; i < nb_endpoints; i++) {
> + ret = drm_of_find_panel_or_bridge(pdev->dev.of_node, i, 0,
> + , );
> + if (!ret)
> + break;
> + else if (ret == -EPROBE_DEFER)
> + goto err_host_reg;
> + }
> +
> + /* check if an error is returned >> no panel or bridge detected */
> + if (ret)
> + goto err_host_reg;
> +
> + if (panel) {
> + bridge = drm_panel_bridge_add_typed(panel,
> DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR(bridge)) {
> + ret = PTR_ERR(bridge);
> + goto err_host_reg;
> + }
> + }
> +
> + dsi->panel_bridge = bridge;
> +
> +
Re: [PATCH] drm/rockchip: Add per-pixel alpha support for the PX30 VOP
On Thu, 16 Apr 2020 16:05:26 +0200, Paul Kocialkowski wrote: > Compared to its predecessors, the PX30 VOP has a different register layout > for enabling per-pixel alpha. Instead of src_alpha_ctl and dst_alpha_ctl, > there is a single alpha control register. This register takes some fields > from src_alpha_ctl, but with a different layout. > > Add support for the required fields to the PX30 VOP window descriptions, > which makes per-pixel-alpha formats behave correctly. Applied, thanks! [1/1] drm/rockchip: Add per-pixel alpha support for the PX30 VOP commit: 2aae8ed1f390a42ec752e4403ffca877fb3260e1 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: vop: fix vop full rgb24 r/b color error
Hi Sandy,
Am Freitag, 19. Juni 2020, 04:12:51 CEST schrieb Sandy Huang:
> RGB888 format msb is red component and the lsb is blue component,
> at vop full platform this is swapped, and this is different from vop
> lite and vop next, so add this patch to fix it.
just me struggling with color formats ... and wondering why this never
came up so far - with Version 3 being all major SoCs of the last years.
So I guess the reason that nobody noticed so far is, that most things
will use ARGB888 instead of RGB888?
One implementation nit below as well.
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index c80f7d9fd13f..1c17048ad737 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -132,6 +132,7 @@ struct vop_win {
>
> struct rockchip_rgb;
> struct vop {
> + uint32_t version;
> struct drm_crtc crtc;
> struct device *dev;
> struct drm_device *drm_dev;
> @@ -989,6 +990,12 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
> VOP_WIN_SET(vop, win, dsp_st, dsp_st);
>
> rb_swap = has_rb_swapped(fb->format->format);
> + /*
> + * VOP full need to do rb swap to show rgb888/bgr888 format color
> correctly
> + */
one-line-comment?
/* VOP-full needs rb_swap for correctly showing rgb888/bgr888 */
> + if ((fb->format->format == DRM_FORMAT_RGB888 || fb->format->format ==
> DRM_FORMAT_BGR888) &&
> + VOP_MAJOR(vop->version) == 3)
> + rb_swap = !rb_swap;
can we move this into the existing has_rb_swapped() function?
Like doing
rb_swap = has_rb_swapped(vop, fb->format->format)
and adding your conditional to the end there?
Thanks
Heiko
> VOP_WIN_SET(vop, win, rb_swap, rb_swap);
>
> /*
> @@ -2091,6 +2098,7 @@ static int vop_bind(struct device *dev, struct device
> *master, void *data)
> vop->dev = dev;
> vop->data = vop_data;
> vop->drm_dev = drm_dev;
> + vop->version = vop_data->version;
> dev_set_drvdata(dev, vop);
>
> vop_win_init(vop);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] panfrost: Add compatible string for bifrost
Am Donnerstag, 11. Juni 2020, 10:58:44 CEST schrieb Tomeu Vizoso:
> Mesa now supports some Bifrost devices, so enable it.
>
> Signed-off-by: Tomeu Vizoso
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 882fecc33fdb..8ff8e140f91e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -677,6 +677,7 @@ static const struct of_device_id dt_match[] = {
> { .compatible = "arm,mali-t830", .data = _data, },
> { .compatible = "arm,mali-t860", .data = _data, },
> { .compatible = "arm,mali-t880", .data = _data, },
> + { .compatible = "arm,mali-bifrost", .data = _data, },
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
on a PX30-board (sibling of rk3326) with a 720x1280 panel and
glmark2 running all tests
Tested-by: Heiko Stuebner
and as this is the generic compatible from the binding:
Reviewed-by: Heiko Stuebner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] panfrost: Make sure GPU is powered on when reading GPU_LATEST_FLUSH_ID
Am Donnerstag, 11. Juni 2020, 10:58:43 CEST schrieb Tomeu Vizoso: > Bifrost devices do support the flush reduction feature, so on first job > submit we were trying to read the register while still powered off. > > If the GPU is powered off, the feature doesn't bring any benefit, so > don't try to read. > > Signed-off-by: Tomeu Vizoso on a PX30-board (sibling of rk3326) with a 720x1280 panel and glmark2 running all tests Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (subset) [PATCH v5 0/7] Enable rk3066a HDMI sound
On Wed, 18 Nov 2020 14:58:15 +0100, Johan Jonker wrote: > First fix some legacy things in clk-rk3188.c that was never updated, > because probably nobody used rk3066a I2S before in the mainline kernel. > Update the rk3066a HDMI documents with a #sound-dai-cells property. > Include the code for sound in the HDMI driver. > Add a simple-sound-card compatible node to rk3066a.dtsi, > because I2S0 and HDMI TX are connected internally. > And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file. > > [...] Applied, thanks! [1/7] clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks commit: 5868491e1257786628fdd2457dfb77609f49f91d [2/7] clk: rockchip: fix i2s gate bits on rk3066 and rk3188 commit: caa2fd752ecb80faf7a2e1cdadc737187934675e Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Avoid uninitialized use of endpoint id in LVDS
On Tue, 10 Nov 2020 21:04:30 +0100, Paul Kocialkowski wrote: > In the Rockchip DRM LVDS component driver, the endpoint id provided to > drm_of_find_panel_or_bridge is grabbed from the endpoint's reg property. > > However, the property may be missing in the case of a single endpoint. > Initialize the endpoint_id variable to 0 to avoid using an > uninitialized variable in that case. Applied, thanks! [1/1] drm/rockchip: Avoid uninitialized use of endpoint id in LVDS commit: aec9fe892812ed10d0bffcf309d2a8fc380d8ce6 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] PWM backlight interpolation adjustments
On Wed, 21 Oct 2020 22:04:42 -0700, Alexandru Stan wrote: > I was trying to adjust the brightness-levels for the trogdor boards: > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209 > Like on a lot of panels, trogdor's low end needs to be cropped, > and now that we have the interpolation stuff I wanted to make use of it > and bake in even the curve that's customary to have on chromebooks. > > I found the current behavior of the pwm_bl driver a little unintuitive > and non-linear. See patch 1 for a suggested fix for this. > > [...] Applied, thanks! [1/1] ARM: dts: rockchip: Remove 0 point from brightness-levels on rk3288-veyron commit: 225c59b9235a421cdb219be5fbc13126a49714a6 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge
From: Heiko Stuebner
The Innolux n116bge panel has an eDP connector and 3*6 bits bus format.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b2da..a0b65d263dce 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2265,6 +2265,8 @@ static const struct panel_desc innolux_n116bge = {
.width = 256,
.height = 144,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
};
static const struct drm_display_mode innolux_n125hce_gn1_mode = {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge
On Sat, 9 Jan 2021 14:09:51 +0100, Heiko Stuebner wrote: > The Innolux n116bge panel has an eDP connector and 3*6 bits bus format. Applied, thanks! [1/1] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge commit: 87969bcd49480508568070fd93d7367f03316aa9 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/rockchip: dsi: add own additional pclk handling
From: Heiko Stuebner
In a followup patch, we'll need to access the pclk ourself to enable some
functionality, so get and store it in the rockchip dw-dsi variant as well.
Clocks are refcounted, so possible cascading enablements are
no problem.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 24a71091759c..18e112e30f6e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -223,6 +223,7 @@ struct dw_mipi_dsi_rockchip {
void __iomem *base;
struct regmap *grf_regmap;
+ struct clk *pclk;
struct clk *pllref_clk;
struct clk *grf_clk;
struct clk *phy_cfg_clk;
@@ -1051,6 +1052,13 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
return ret;
}
+ dsi->pclk = devm_clk_get(dev, "pclk");
+ if (IS_ERR(dsi->pclk)) {
+ ret = PTR_ERR(dsi->pclk);
+ DRM_DEV_ERROR(dev, "Unable to get pclk: %d\n", ret);
+ return ret;
+ }
+
dsi->pllref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(dsi->pllref_clk)) {
if (dsi->phy) {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] arm64: dts: rockchip: add #phy-cells to mipi-dsi1
From: Heiko Stuebner
The dsi controller includes access to the dphy which might be used
not only for dsi output but also for csi input on dsi1, so add the
necessary #phy-cells to allow it to be used as phy.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index edbbf35fe19e..5d2178cb3e38 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1865,6 +1865,7 @@ mipi_dsi1: mipi@ff968000 {
rockchip,grf = <>;
#address-cells = <1>;
#size-cells = <0>;
+ #phy-cells = <0>;
status = "disabled";
ports {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/rockchip: dsi: add ability to work as a phy instead of full dsi
From: Heiko Stuebner
SoCs like the rk3288 and rk3399 have 3 mipi dphys on them. One is TX-
only, one is RX-only and one can be configured to do either TX or RX.
The RX phy is statically connected to the first Image Signal Processor,
the TX phy is statically connected to the first DSI controller and
the TXRX phy is connected to both the second DSI controller as well
as the second ISP.
The RX dphy is controlled externally through registers in the "General
Register Files", while the other two are controlled through the
"Configuration and Test Interface" inside their DSI controller's
io-memory area.
The Rockchip dw-dsi controller already controls these dphys for the
TX case in the driver, but when we want to also allow configuration
for RX to the ISP from the media subsystem we need to expose phy-
functionality instead.
So add a bit of infrastructure to allow the dsi driver to work as a
phy and make sure it can be only one or the other at a time.
Similarly as the dsi-controller will be part of the drm-graph when
active, add an empty component to the drm-graph when in phy-mode
to make the rest of the drm-graph not wait for it.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/Kconfig | 2 +
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 334 ++
2 files changed, 336 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index cb25c0e8fc9b..3094d4533ad6 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -9,6 +9,8 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+ select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI
+ select GENERIC_PHY_MIPI_DPHY if ROCKCHIP_DW_MIPI_DSI
select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 18e112e30f6e..5988a105c141 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -125,7 +126,9 @@
#define BANDGAP_AND_BIAS_CONTROL 0x20
#define TERMINATION_RESISTER_CONTROL 0x21
#define AFE_BIAS_BANDGAP_ANALOG_PROGRAMMABILITY0x22
+#define HS_RX_CONTROL_OF_LANE_CLK 0x34
#define HS_RX_CONTROL_OF_LANE_00x44
+#define HS_RX_CONTROL_OF_LANE_10x54
#define HS_TX_CLOCK_LANE_REQUEST_STATE_TIME_CONTROL0x60
#define HS_TX_CLOCK_LANE_PREPARE_STATE_TIME_CONTROL0x61
#define HS_TX_CLOCK_LANE_HS_ZERO_STATE_TIME_CONTROL0x62
@@ -137,6 +140,9 @@
#define HS_TX_DATA_LANE_HS_ZERO_STATE_TIME_CONTROL 0x72
#define HS_TX_DATA_LANE_TRAIL_STATE_TIME_CONTROL 0x73
#define HS_TX_DATA_LANE_EXIT_STATE_TIME_CONTROL0x74
+#define HS_RX_DATA_LANE_THS_SETTLE_CONTROL 0x75
+#define HS_RX_CONTROL_OF_LANE_20x84
+#define HS_RX_CONTROL_OF_LANE_30x94
#define DW_MIPI_NEEDS_PHY_CFG_CLK BIT(0)
#define DW_MIPI_NEEDS_GRF_CLK BIT(1)
@@ -171,11 +177,19 @@
#define RK3399_TXRX_MASTERSLAVEZ BIT(7)
#define RK3399_TXRX_ENABLECLK BIT(6)
#define RK3399_TXRX_BASEDIRBIT(5)
+#define RK3399_TXRX_SRC_SEL_ISP0 BIT(4)
+#define RK3399_TXRX_TURNREQUESTGENMASK(3, 0)
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
#define to_dsi(nm) container_of(nm, struct dw_mipi_dsi_rockchip, nm)
+enum {
+ DW_DSI_USAGE_IDLE,
+ DW_DSI_USAGE_DSI,
+ DW_DSI_USAGE_PHY,
+};
+
enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -213,6 +227,10 @@ struct rockchip_dw_dsi_chip_data {
u32 lanecfg2_grf_reg;
u32 lanecfg2;
+ int (*dphy_rx_init)(struct phy *phy);
+ int (*dphy_rx_power_on)(struct phy *phy);
+ int (*dphy_rx_power_off)(struct phy *phy);
+
unsigned int flags;
unsigned int max_data_lanes;
};
@@ -236,6 +254,12 @@ struct dw_mipi_dsi_rockchip {
struct phy *phy;
union phy_configure_opts phy_opts;
+ /* being a phy for other mipi hosts */
+ unsigned int usage_mode;
+ struct mutex usage_mutex;
+ struct phy *dphy;
+ struct phy_configure_opts_mipi_dphy dphy_config;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -965,6 +989,17 @@ static int dw_mipi_dsi_rockchip_host_attach(void
*priv_data,
struct device *second;
int ret;
+ mutex_lock(>usage_mutex);
+
+ if (dsi->usage_mode != DW_DSI_USAGE_IDLE) {
+
[PATCH 2/6] dt-bindings: display: rockchip-dsi: add optional #phy-cells property
From: Heiko Stuebner The Rockchip DSI controller on some SoCs also controls a bidrectional dphy, which would be connected to an Image Signal Processor as a phy in the rx configuration. So allow a #phy-cells property for the dsi controller. Signed-off-by: Heiko Stuebner --- .../bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 151be3bba06f..39792f051d2d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -23,6 +23,7 @@ Required properties: Optional properties: - phys: from general PHY binding: the phandle for the PHY device. - phy-names: Should be "dphy" if phys references an external phy. +- #phy-cells: Defined when used as ISP phy, should be 0. - power-domains: a phandle to mipi dsi power domain node. - resets: list of phandle + reset specifier pairs, as described in [3]. - reset-names: string reset name, must be "apb". -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] arm64: dts: rockchip: add isp1 node on rk3399
From: Heiko Stuebner
ISP1 is supplied by the tx1rx1 dphy, that is controlled from
inside the dsi1 controller, so include the necessary phy-link
for it.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 26
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 7c661d84df25..98cec9387300 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1756,6 +1756,32 @@ isp0_mmu: iommu@ff914000 {
rockchip,disable-mmu-reset;
};
+ isp1: isp1@ff92 {
+ compatible = "rockchip,rk3399-cif-isp";
+ reg = <0x0 0xff92 0x0 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_ISP1>,
+< ACLK_ISP1_WRAPPER>,
+< HCLK_ISP1_WRAPPER>;
+ clock-names = "isp", "aclk", "hclk";
+ iommus = <_mmu>;
+ phys = <_dsi1>;
+ phy-names = "dphy";
+ power-domains = < RK3399_PD_ISP1>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+
isp1_mmu: iommu@ff924000 {
compatible = "rockchip,iommu";
reg = <0x0 0xff924000 0x0 0x100>, <0x0 0xff925000 0x0 0x100>;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Support second Image Signal Processor on rk3399
The rk3399 has two ISPs and right now only the first one is usable. The second ISP is connected to the TXRX dphy on the soc. The phy of ISP1 is only accessible through the DSI controller's io-memory, so this series adds support for simply using the dsi controller is a phy if needed. That solution is needed at least on rk3399 and rk3288 but no-one has looked at camera support on rk3288 at all, so right now only implement the rk3399 specifics. Heiko Stuebner (6): drm/rockchip: dsi: add own additional pclk handling dt-bindings: display: rockchip-dsi: add optional #phy-cells property drm/rockchip: dsi: add ability to work as a phy instead of full dsi arm64: dts: rockchip: add #phy-cells to mipi-dsi1 arm64: dts: rockchip: add cif clk-control pinctrl for rk3399 arm64: dts: rockchip: add isp1 node on rk3399 .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 ++ drivers/gpu/drm/rockchip/Kconfig | 2 + .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 342 ++ 4 files changed, 384 insertions(+) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
From: Heiko Stuebner
This enables variant a of the clkout signal for camera applications
and also the cifclkin pinctrl setting.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 5d2178cb3e38..7c661d84df25 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -2102,6 +2102,18 @@ clk_32k: clk-32k {
};
};
+ cif {
+ cif_clkin: cif-clkin {
+ rockchip,pins =
+ <2 RK_PB2 3 _pull_none>;
+ };
+
+ cif_clkouta: cif-clkouta {
+ rockchip,pins =
+ <2 RK_PB3 3 _pull_none>;
+ };
+ };
+
edp {
edp_hpd: edp-hpd {
rockchip,pins =
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/rockchip: dsi: move all lane config except LCDC mux to bind()
On Sun, 18 Apr 2021 19:04:10 -0700, Thomas Hebb wrote: > When we first enable the DSI encoder, we currently program some per-chip > configuration that we look up in rk3399_chip_data based on the device > tree compatible we match. This data configures various parameters of the > MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a > dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan > out from. > > [...] Applied, thanks! [1/1] drm/rockchip: dsi: move all lane config except LCDC mux to bind() commit: 43c2de1002d2b70fb5941fa14e97a34e3dc214d4 Best regards, -- Heiko Stuebner
Re: [RESEND PATCH] drm/rockchip: dsi: remove extra component_del() call
On Sun, 18 Apr 2021 19:03:04 -0700, Thomas Hebb wrote:
> commit cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") added
> this devcnt field and call to component_del(). However, these both
> appear to be erroneous changes left over from an earlier version of the
> patch. In the version merged, nothing ever modifies devcnt, meaning
> component_del() runs unconditionally and in addition to the
> component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second
> call fails to delete anything and produces a warning in dmesg.
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: dsi: remove extra component_del() call
commit: b354498bbe65c917d521b3b56317ddc9ab217425
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: remove unused function
On Thu, 15 Apr 2021 16:47:01 +0800, Jiapeng Chong wrote: > Fix the following clang warning: > > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:320:20: warning: unused > function 'dsi_set' [-Wunused-function]. Applied, thanks! [1/1] drm/rockchip: remove unused function commit: 7455cedf7c4d4d5d808913e14d859705612c54ce Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: cdn-dp-core: add MODULE_FIRMWARE macro
On Thu, 6 May 2021 10:29:51 +0100, Peter Robinson wrote: > The CDP DP component of the rockchip GPU driver requires firmware > so define MODULE_FIRMWARE for rockchip/dptx.bin so the details > are available in the module info. Applied, thanks! [1/1] drm/rockchip: cdn-dp-core: add MODULE_FIRMWARE macro commit: c0677e41a47fbb37c4ed7200e5c7f610a2ffbd4b Best regards, -- Heiko Stuebner
Re: [PATCH v3 0/5] drm: rockchip: various ports for older VOPs
On Fri, 28 May 2021 15:05:49 +0200, Alex Bee wrote: > this is v3 of a series I posted almost 1 year ago. I considered now all > feedback I got at that time. > It mainly ports existining functionality to older SoCs - most importantly > enables alpha blending for RK3036, RK3066, RK3126 and RK3188 > > Note some of the patches are required to let VOP correctly process the > data that comes from the video decoder - I recently posted a series that > adds support for those older SoCs at [1]. > > [...] Applied, thanks! [1/5] drm: rockchip: add scaling for RK3036 win1 commit: 53c2710c0d92e615c9fffcc64aa963dfa0e100a7 [2/5] drm: rockchip: add missing registers for RK3188 commit: ab64b448a175b8a5a4bd323b8f74758c2574482c [3/5] drm: rockchip: add missing registers for RK3066 commit: 742203cd56d150eb7884eb45abb7d9dbc2bdbf04 [4/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188 commit: d099fa672cbe8766d9182e0fd04c65058200128a [5/5] drm: rockchip: set alpha_en to 0 if it is not used commit: 046e0db975695540c9d9898cdbf0b60533d28afb Best regards, -- Heiko Stuebner
Re: [PATCH -next] drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write()
On Wed, 19 May 2021 21:49:28 +0800, Yang Yingliang wrote: > After calling clk_prepare_enable(), clk_disable_unprepare() need > be called when calling regmap_write() failed. Applied, thanks! [1/1] drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write() commit: ae41d925c75b53798f289c69ee8d9f7d36432f6d Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result
On Tue, 15 Sep 2020 17:20:49 +0100, Colin King wrote: > The variable bit_per_pix is a u8 and is promoted in the multiplication > to an int type and then sign extended to a u64. If the result of the > int multiplication is greater than 0x7fff then the upper 32 bits will > be set to 1 as a result of the sign extension. Avoid this by casting > tu_size_reg to u64 to avoid sign extension and also a potential overflow. Applied, thanks! [1/1] drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result commit: ce0cb93a5adb283f577cd4661f511047b5e39028 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: Fix an error handling path
On Sat, 1 May 2021 17:13:16 +0200, Christophe JAILLET wrote: > 'ret' is know to be 0 a this point. Checking the return value of > 'phy_init()' and 'phy_set_mode()' was intended instead. > > So add the missing assignments. Applied, thanks! [1/1] drm/rockchip: Fix an error handling path commit: 3dfa159f6b0c054eb63673fbf643a5f2cc862e63 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop_reg: add PX30 version info
On Sun, 31 Jan 2021 13:50:16 +0100, Johan Jonker wrote: > To reduce memory various Rockchip VOP versions share > common reg structures. However more recent added SoCs not > always have to same futures as the old ones. > Add PX30 missing version info, so all VOP version checks > work correct if needed in the future. Applied, thanks! [1/1] drm/rockchip: vop_reg: add PX30 version info commit: 872b68e9750eddd086b93a6004ebe82c64aef670 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/panel: add rotation support for Elida KD35T133 panels
On Fri, 2 Apr 2021 15:48:47 -0500, Chris Morgan wrote: > Update the panel to allow setting the rotation value in device tree. > Tested on an Odroid Go Advance, where the panel is by default rotated 270 > degrees. Applied, thanks! [1/1] drm/panel: add rotation support for Elida KD35T133 panels commit: 610d9c311b1387f8c4ac602fee1f2a1cb0508707 Best regards, -- Heiko Stuebner
[PATCH v2 0/6] Support second Image Signal Processor on rk3399
The rk3399 has two ISPs and right now only the first one is usable. The second ISP is connected to the TXRX dphy on the soc. The phy of ISP1 is only accessible through the DSI controller's io-memory, so this series adds support for simply using the dsi controller is a phy if needed. That solution is needed at least on rk3399 and rk3288 but no-one has looked at camera support on rk3288 at all, so right now only implement the rk3399 specifics. changes in v2: - enable grf-clock also for init callback to not break if for example hdmi is connected on boot and disabled the grf clock during its probe - add Sebastian's Tested-by - add Rob's Ack for the phy-cells property Heiko Stuebner (6): drm/rockchip: dsi: add own additional pclk handling dt-bindings: display: rockchip-dsi: add optional #phy-cells property drm/rockchip: dsi: add ability to work as a phy instead of full dsi arm64: dts: rockchip: add #phy-cells to mipi-dsi1 arm64: dts: rockchip: add cif clk-control pinctrl for rk3399 arm64: dts: rockchip: add isp1 node on rk3399 .../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 ++ drivers/gpu/drm/rockchip/Kconfig | 2 + .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 349 ++ 4 files changed, 391 insertions(+) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] arm64: dts: rockchip: add cif clk-control pinctrl for rk3399
From: Heiko Stuebner
This enables variant a of the clkout signal for camera applications
and also the cifclkin pinctrl setting.
Signed-off-by: Heiko Stuebner
Tested-by: Sebastian Fricke
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 5d2178cb3e38..7c661d84df25 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -2102,6 +2102,18 @@ clk_32k: clk-32k {
};
};
+ cif {
+ cif_clkin: cif-clkin {
+ rockchip,pins =
+ <2 RK_PB2 3 _pull_none>;
+ };
+
+ cif_clkouta: cif-clkouta {
+ rockchip,pins =
+ <2 RK_PB3 3 _pull_none>;
+ };
+ };
+
edp {
edp_hpd: edp-hpd {
rockchip,pins =
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/rockchip: dsi: add ability to work as a phy instead of full dsi
From: Heiko Stuebner
SoCs like the rk3288 and rk3399 have 3 mipi dphys on them. One is TX-
only, one is RX-only and one can be configured to do either TX or RX.
The RX phy is statically connected to the first Image Signal Processor,
the TX phy is statically connected to the first DSI controller and
the TXRX phy is connected to both the second DSI controller as well
as the second ISP.
The RX dphy is controlled externally through registers in the "General
Register Files", while the other two are controlled through the
"Configuration and Test Interface" inside their DSI controller's
io-memory area.
The Rockchip dw-dsi controller already controls these dphys for the
TX case in the driver, but when we want to also allow configuration
for RX to the ISP from the media subsystem we need to expose phy-
functionality instead.
So add a bit of infrastructure to allow the dsi driver to work as a
phy and make sure it can be only one or the other at a time.
Similarly as the dsi-controller will be part of the drm-graph when
active, add an empty component to the drm-graph when in phy-mode
to make the rest of the drm-graph not wait for it.
Signed-off-by: Heiko Stuebner
Tested-by: Sebastian Fricke
---
drivers/gpu/drm/rockchip/Kconfig | 2 +
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 341 ++
2 files changed, 343 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index cb25c0e8fc9b..3094d4533ad6 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -9,6 +9,8 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+ select GENERIC_PHY if ROCKCHIP_DW_MIPI_DSI
+ select GENERIC_PHY_MIPI_DPHY if ROCKCHIP_DW_MIPI_DSI
select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 18e112e30f6e..e322749a5279 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -125,7 +126,9 @@
#define BANDGAP_AND_BIAS_CONTROL 0x20
#define TERMINATION_RESISTER_CONTROL 0x21
#define AFE_BIAS_BANDGAP_ANALOG_PROGRAMMABILITY0x22
+#define HS_RX_CONTROL_OF_LANE_CLK 0x34
#define HS_RX_CONTROL_OF_LANE_00x44
+#define HS_RX_CONTROL_OF_LANE_10x54
#define HS_TX_CLOCK_LANE_REQUEST_STATE_TIME_CONTROL0x60
#define HS_TX_CLOCK_LANE_PREPARE_STATE_TIME_CONTROL0x61
#define HS_TX_CLOCK_LANE_HS_ZERO_STATE_TIME_CONTROL0x62
@@ -137,6 +140,9 @@
#define HS_TX_DATA_LANE_HS_ZERO_STATE_TIME_CONTROL 0x72
#define HS_TX_DATA_LANE_TRAIL_STATE_TIME_CONTROL 0x73
#define HS_TX_DATA_LANE_EXIT_STATE_TIME_CONTROL0x74
+#define HS_RX_DATA_LANE_THS_SETTLE_CONTROL 0x75
+#define HS_RX_CONTROL_OF_LANE_20x84
+#define HS_RX_CONTROL_OF_LANE_30x94
#define DW_MIPI_NEEDS_PHY_CFG_CLK BIT(0)
#define DW_MIPI_NEEDS_GRF_CLK BIT(1)
@@ -171,11 +177,19 @@
#define RK3399_TXRX_MASTERSLAVEZ BIT(7)
#define RK3399_TXRX_ENABLECLK BIT(6)
#define RK3399_TXRX_BASEDIRBIT(5)
+#define RK3399_TXRX_SRC_SEL_ISP0 BIT(4)
+#define RK3399_TXRX_TURNREQUESTGENMASK(3, 0)
#define HIWORD_UPDATE(val, mask) (val | (mask) << 16)
#define to_dsi(nm) container_of(nm, struct dw_mipi_dsi_rockchip, nm)
+enum {
+ DW_DSI_USAGE_IDLE,
+ DW_DSI_USAGE_DSI,
+ DW_DSI_USAGE_PHY,
+};
+
enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -213,6 +227,10 @@ struct rockchip_dw_dsi_chip_data {
u32 lanecfg2_grf_reg;
u32 lanecfg2;
+ int (*dphy_rx_init)(struct phy *phy);
+ int (*dphy_rx_power_on)(struct phy *phy);
+ int (*dphy_rx_power_off)(struct phy *phy);
+
unsigned int flags;
unsigned int max_data_lanes;
};
@@ -236,6 +254,12 @@ struct dw_mipi_dsi_rockchip {
struct phy *phy;
union phy_configure_opts phy_opts;
+ /* being a phy for other mipi hosts */
+ unsigned int usage_mode;
+ struct mutex usage_mutex;
+ struct phy *dphy;
+ struct phy_configure_opts_mipi_dphy dphy_config;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -965,6 +989,17 @@ static int dw_mipi_dsi_rockchip_host_attach(void
*priv_data,
struct device *second;
int ret;
+ mutex_lock(>usage_mutex);
+
+ if (dsi->usage_mode != DW_DSI_USA
[PATCH 4/6] arm64: dts: rockchip: add #phy-cells to mipi-dsi1
From: Heiko Stuebner
The dsi controller includes access to the dphy which might be used
not only for dsi output but also for csi input on dsi1, so add the
necessary #phy-cells to allow it to be used as phy.
Signed-off-by: Heiko Stuebner
Tested-by: Sebastian Fricke
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index edbbf35fe19e..5d2178cb3e38 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1865,6 +1865,7 @@ mipi_dsi1: mipi@ff968000 {
rockchip,grf = <>;
#address-cells = <1>;
#size-cells = <0>;
+ #phy-cells = <0>;
status = "disabled";
ports {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] arm64: dts: rockchip: add isp1 node on rk3399
From: Heiko Stuebner
ISP1 is supplied by the tx1rx1 dphy, that is controlled from
inside the dsi1 controller, so include the necessary phy-link
for it.
Signed-off-by: Heiko Stuebner
Tested-by: Sebastian Fricke
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 26
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 7c661d84df25..98cec9387300 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1756,6 +1756,32 @@ isp0_mmu: iommu@ff914000 {
rockchip,disable-mmu-reset;
};
+ isp1: isp1@ff92 {
+ compatible = "rockchip,rk3399-cif-isp";
+ reg = <0x0 0xff92 0x0 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_ISP1>,
+< ACLK_ISP1_WRAPPER>,
+< HCLK_ISP1_WRAPPER>;
+ clock-names = "isp", "aclk", "hclk";
+ iommus = <_mmu>;
+ phys = <_dsi1>;
+ phy-names = "dphy";
+ power-domains = < RK3399_PD_ISP1>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+
isp1_mmu: iommu@ff924000 {
compatible = "rockchip,iommu";
reg = <0x0 0xff924000 0x0 0x100>, <0x0 0xff925000 0x0 0x100>;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] dt-bindings: display: rockchip-dsi: add optional #phy-cells property
From: Heiko Stuebner The Rockchip DSI controller on some SoCs also controls a bidrectional dphy, which would be connected to an Image Signal Processor as a phy in the rx configuration. So allow a #phy-cells property for the dsi controller. Signed-off-by: Heiko Stuebner Acked-by: Rob Herring Tested-by: Sebastian Fricke --- .../bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 151be3bba06f..39792f051d2d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -23,6 +23,7 @@ Required properties: Optional properties: - phys: from general PHY binding: the phandle for the PHY device. - phy-names: Should be "dphy" if phys references an external phy. +- #phy-cells: Defined when used as ISP phy, should be 0. - power-domains: a phandle to mipi dsi power domain node. - resets: list of phandle + reset specifier pairs, as described in [3]. - reset-names: string reset name, must be "apb". -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/rockchip: dsi: add own additional pclk handling
From: Heiko Stuebner
In a followup patch, we'll need to access the pclk ourself to enable some
functionality, so get and store it in the rockchip dw-dsi variant as well.
Clocks are refcounted, so possible cascading enablements are
no problem.
Signed-off-by: Heiko Stuebner
Tested-by: Sebastian Fricke
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 24a71091759c..18e112e30f6e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -223,6 +223,7 @@ struct dw_mipi_dsi_rockchip {
void __iomem *base;
struct regmap *grf_regmap;
+ struct clk *pclk;
struct clk *pllref_clk;
struct clk *grf_clk;
struct clk *phy_cfg_clk;
@@ -1051,6 +1052,13 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
return ret;
}
+ dsi->pclk = devm_clk_get(dev, "pclk");
+ if (IS_ERR(dsi->pclk)) {
+ ret = PTR_ERR(dsi->pclk);
+ DRM_DEV_ERROR(dev, "Unable to get pclk: %d\n", ret);
+ return ret;
+ }
+
dsi->pllref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(dsi->pllref_clk)) {
if (dsi->phy) {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Cope with endpoints that haven't been registered yet
Hi Jonathan,
Am Dienstag, 16. März 2021, 19:27:53 CET schrieb Jonathan McDowell:
> The Rockchip RGB CRTC output driver attempts to avoid probing Rockchip
> subdrivers to see if they're a connected panel or bridge. However part
> of its checks assumes that if no OF platform device is found then it
> can't be a valid bridge or panel. This causes issues with I2C controlled
> bridges that have not yet been registered to the point they can be
> found.
>
> Change this to return EPROBE_DEFER instead of ENODEV and don't ignore
> such devices. The subsequent call to drm_of_find_panel_or_bridge() will
> return EPROBE_DEFER as well if there's actually a valid device we should
> wait for.
>
> Signed-off-by: Jonathan McDowell
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 8 ++--
> drivers/gpu/drm/rockchip/rockchip_rgb.c | 7 ---
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 212bd87c0c4a..b0d63a566501 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -270,11 +270,15 @@ int rockchip_drm_endpoint_is_subdriver(struct
> device_node *ep)
> if (!node)
> return -ENODEV;
>
> - /* status disabled will prevent creation of platform-devices */
> + /*
> + * status disabled will prevent creation of platform-devices,
> + * but equally we can't rely on the driver having been registered
> + * yet (e.g. I2C bridges).
> + */
> pdev = of_find_device_by_node(node);
> of_node_put(node);
> if (!pdev)
> - return -ENODEV;
> + return -EPROBE_DEFER;
In general, how does that relate to i2c-bridge-drivers, as
of_find_device_by_node supposedly only acts on platform-devices?
Also if that points to a disabled bridge (hdmi, etc) that would likely make
it probe-defer indefinitly, as that device will never become available?
Maybe we could do something like of_device_is_available() which checks
the status property of the node. So something like:
pdev = of_find_device_by_node(node);
if (!pdev) {
bool avail = of_device_is_available(node);
of_node_put(node);
/* if disabled
if (!avail)
return -ENODEV;
else
return -EPROBE_DEFER;
}
of_node_put(node);
Though I still do not understand how that should actually pick up on
i2c devices at all.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: kd35t133: allow using non-continuous dsi clock
On Sat, 6 Feb 2021 14:50:20 +0100, Heiko Stuebner wrote:
> The panel is able to work when dsi clock is non-continuous, thus
> the system power consumption can be reduced using such feature.
>
> Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags.
>
> Also the flag actually becomes necessary after
> commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for
> non-continuous HS clock")
> and without it the panel only emits stripes instead of output.
Applied, thanks!
[1/1] drm/panel: kd35t133: allow using non-continuous dsi clock
commit: 54dab3a718f7094532daf7d25cd14121a0e00e34
Best regards,
--
Heiko Stuebner
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Require the YTR modifier for AFBC
On Tue, 11 Aug 2020 16:26:31 -0400, Alyssa Rosenzweig wrote: > The AFBC decoder used in the Rockchip VOP assumes the use of the > YUV-like colourspace transform (YTR). YTR is lossless for RGB(A) > buffers, which covers the RGBA8 and RGB565 formats supported in > vop_convert_afbc_format. Use of YTR is signaled with the > AFBC_FORMAT_MOD_YTR modifier, which prior to this commit was missing. As > such, a producer would have to generate buffers that do not use YTR, > which the VOP would erroneously decode as YTR, leading to severe visual > corruption. > > [...] Applied, thanks! [1/1] drm/rockchip: Require the YTR modifier for AFBC commit: 0de764474e6e0a74bd75715fed227d82dcda054c Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: kd35t133: allow using non-continuous dsi clock
The panel is able to work when dsi clock is non-continuous, thus
the system power consumption can be reduced using such feature.
Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags.
Also the flag actually becomes necessary after
commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for non-continuous
HS clock")
and without it the panel only emits stripes instead of output.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index bc36aa3c1123..fe5ac3ef9018 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -265,7 +265,8 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 1;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS;
drm_panel_init(>panel, >dev, _funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support second Image Signal Processor on rk3399
Hi Sebastian, Am Samstag, 13. Februar 2021, 12:19:57 CET schrieb Sebastian Fricke: > On 11.02.2021 15:42, Heiko Stübner wrote: > >Am Donnerstag, 11. Februar 2021, 06:25:15 CET schrieb Sebastian Fricke: > >> On 10.02.2021 12:15, Heiko Stübner wrote: > >> >Am Freitag, 5. Februar 2021, 15:55:56 CET schrieb Heiko Stübner: > >> >> I did some tests myself today as well and can confirm your > >> >> hdmi related finding - at least when plugged in on boot. > >> >> > >> >> I tried some combinations of camera vs. hdmi and it seems > >> >> really only when hdmi is plugged in on boot > >> > > >> >as you can see in v2, it should work now even with hdmi > >> >connected on boot. My patch ignored the grf-clock when > >> >doing the grf-based init. > >> > > >> >All clocks are on during boot and I guess the hdmi-driver > >> >did disable it after its probe. The phy_power_on functions > >> >did handle it correctly already, so it was only happening > >> >with hdmi connected on boot. > >> > >> Thank you very much for solving that problem, I've tested the scenarios > >> described below and it works like a charm. (With your V2) > >> > > >> > > >> >Btw. do you plan on submitting your ov13850 driver > >> >soonish? > >> > >> Actually, I have posted the patch already see here: > >> https://patchwork.kernel.org/project/linux-media/patch/20210130182313.32903-2-sebastian.fri...@posteo.net/ > > > >very cool to see > > > >> I currently review the requested changes and questions and will soon > >> post a second version, but I expect quite some time until it is actually > >> merged. > > > >could you Cc me on future versions? > > Sure will do :) by the way, you could also answer the v2 series with a Tested-by: Sebastian Fricke so we get some coverage :-) Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Implement mmap as GEM object function
On Thu, 24 Jun 2021 11:55:02 +0200, Thomas Zimmermann wrote: > Moving the driver-specific mmap code into a GEM object function allows > for using DRM helpers for various mmap callbacks. > > The respective rockchip functions are being removed. The file_operations > structure fops is now being created by the helper macro > DEFINE_DRM_GEM_FOPS(). Applied, thanks! Looks good on a general glance, but of course I don't have a firm grasp on all drm internals, so hopefully all these tests we have will suffice :-) . [1/1] drm/rockchip: Implement mmap as GEM object function commit: f8b5307074f8be80a9806d85b01e5ba933dd0360 Best regards, -- Heiko Stuebner
Re: [PATCH v3 2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
Am Dienstag, 28. September 2021, 23:35:50 CEST schrieb Brian Norris:
> Since commit 43c2de1002d2, we perform most HW configuration in the
> bind() function. This configuration may be lost on suspend/resume, so we
> need to call it again. That may lead to errors like this after system
> suspend/resume:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet).
>
> Note that early mailing list versions of this driver borrowed Rockchip's
> downstream/BSP solution, to do HW configuration in mode_set() (which
> *is* called at the appropriate pre-enable() times),
not always though. In non-atomic settings .mode_set actually doesn't
seem to be called every time. I've experienced this when drm disables
atomic when X11 is running.
So having real suspend/resume callbacks makes quite a lot of sense :-)
Heiko
> but that was
> discarded along the way. I've avoided that still, because mode_set()
> documentation doesn't suggest this kind of purpose as far as I can tell.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Cc:
> Signed-off-by: Brian Norris
> ---
>
> Changes in v3:
> - New patch, to fix related PM issue discovered after patch 1
>
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 45676b23c019..21c67343cc6c 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -268,6 +268,8 @@ struct dw_mipi_dsi_rockchip {
> struct dw_mipi_dsi *dmd;
> const struct rockchip_dw_dsi_chip_data *cdata;
> struct dw_mipi_dsi_plat_data pdata;
> +
> + bool dsi_bound;
> };
>
> struct dphy_pll_parameter_map {
> @@ -964,6 +966,8 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> goto out_pm_runtime;
> }
>
> + dsi->dsi_bound = true;
> +
> return 0;
>
> out_pm_runtime:
> @@ -983,6 +987,8 @@ static void dw_mipi_dsi_rockchip_unbind(struct device
> *dev,
> if (dsi->is_slave)
> return;
>
> + dsi->dsi_bound = false;
> +
> dw_mipi_dsi_unbind(dsi->dmd);
>
> clk_disable_unprepare(dsi->pllref_clk);
> @@ -1277,6 +1283,36 @@ static const struct phy_ops dw_mipi_dsi_dphy_ops = {
> .exit = dw_mipi_dsi_dphy_exit,
> };
>
> +static int __maybe_unused dw_mipi_dsi_rockchip_resume(struct device *dev)
> +{
> + struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
> + int ret;
> +
> + /*
> + * Re-configure DSI state, if we were previously initialized. We need
> + * to do this before rockchip_drm_drv tries to re-enable() any panels.
> + */
> + if (dsi->dsi_bound) {
> + ret = clk_prepare_enable(dsi->grf_clk);
> + if (ret) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk:
> %d\n", ret);
> + return ret;
> + }
> +
> + dw_mipi_dsi_rockchip_config(dsi);
> + if (dsi->slave)
> + dw_mipi_dsi_rockchip_config(dsi->slave);
> +
> + clk_disable_unprepare(dsi->grf_clk);
> + }
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops dw_mipi_dsi_rockchip_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, dw_mipi_dsi_rockchip_resume)
> +};
> +
> static int dw_mipi_dsi_rockchip_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -1594,6 +1630,7 @@ struct platform_driver dw_mipi_dsi_rockchip_driver = {
> .remove = dw_mipi_dsi_rockchip_remove,
> .driver = {
> .of_match_table = dw_mipi_dsi_rockchip_dt_ids,
> + .pm = _mipi_dsi_rockchip_pm_ops,
> .name = "dw-mipi-dsi-rockchip",
> },
> };
>
Re: [PATCH] drm/rockchip: vop: Add timeout for DSP hold
On Fri, 8 Oct 2021 15:31:04 -0700, Brian Norris wrote: > If hardware is malfunctioning (e.g., misconfigured clocks?), we can get > stuck here forever, holding various DRM locks and eventually locking up > the entire system. It's better to complain loudly and move on, than to > lock up the system. > > In local tests, this operation takes less than 20ms. Applied, thanks! [1/1] drm/rockchip: vop: Add timeout for DSP hold commit: 085af7d28897deb08a4f64a29e55525f963cc041 Best regards, -- Heiko Stuebner
Re: [PATCH v3 0/4] Fix Rockchip MIPI DSI display init timeouts
On Tue, 28 Sep 2021 14:35:48 -0700, Brian Norris wrote:
> The Rockchip DSI driver has had a number of bugs over time and has
> usually only worked by chance. A number of users have noticed that
> things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
> lane config except LCDC mux to bind()"), although it was fixing several
> real issues of its own that had been present forever in the upstream
> driver (but notably, not in the downstream/BSP driver).
>
> [...]
Applied, thanks!
[1/4] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
commit: 514db871922f103886ad4d221cf406b4fcc5e74a
[2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
commit: e584cdc1549932f87a2707b56bc588cfac5d89e0
[3/4] drm/rockchip: dsi: Fix unbalanced clock on probe error
commit: 251888398753924059f3bb247a44153a2853137f
[4/4] drm/rockchip: dsi: Disable PLL clock on bind error
commit: 5a614570172e1c9f59035d259dd735acd4f1c01b
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: remove of_match_ptr() from vop_driver_dt_match
On Tue, 8 Jun 2021 00:38:00 +0530, Souptick Joarder wrote:
> kernel test robot throws warning when CONFIG_OF not set.
>
> >> drivers/gpu/drm/rockchip/rockchip_vop_reg.c:1038:34:
> warning: unused variable 'vop_driver_dt_match' [-Wunused-const-variable]
>static const struct of_device_id vop_driver_dt_match[] = {
>
> Fixed it by removing of_match_ptr().
Applied, thanks!
[1/1] drm/rockchip: remove of_match_ptr() from vop_driver_dt_match
commit: 87185cc823693933308bd33a190032e9c262c75f
Best regards,
--
Heiko Stuebner
Re: [PATCH v2] drm/rockchip: remove of_match_ptr()
On Tue, 8 Jun 2021 00:18:36 +0530, Souptick Joarder wrote:
> Kernel test robot throws below warning when CONFIG_OF
> is not set.
>
> >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34:
> warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable]
>static const struct of_device_id rockchip_dp_dt_ids[] = {
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: remove of_match_ptr()
commit: f7fc7a79bdbf20f2edef69dc62666a4f0cdac0e3
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: dsi: make hstt_table static
On Fri, 6 Aug 2021 10:57:44 +0800, Jiapeng Chong wrote: > This symbol is not used outside of dw-mipi-dsi-rockchip.c, so marks > it static. > > Fix the following sparse warning: > > drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:646:13: warning: symbol > 'hstt_table' was not declared. Should it be static? Applied, thanks! [1/1] drm/rockchip: dsi: make hstt_table static commit: adfeef9370ff8b53c5f73cda3a63531d92b1ca64 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: remove unused psr_list{,_lock}
On Wed, 15 Sep 2021 13:50:11 -0700, Brian Norris wrote:
> Some leftover cleanup from commit 6c836d965bad ("drm/rockchip: Use the
> helpers for PSR").
Applied, thanks!
[1/1] drm/rockchip: remove unused psr_list{,_lock}
commit: d3e2ec6cd1636ced67c6f57d95d8ad24f964691d
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: Check iommu itself instead of it's parent for device_is_available
On Sun, 27 Jun 2021 16:47:37 +0800, Andy Yan wrote: > When iommu itself is disabled in dts, we should > fallback to non-iommu buffer, check iommu parent > is meanless here. Applied, thanks! [1/1] drm/rockchip: Check iommu itself instead of it's parent for device_is_available commit: e1202c7a65b10258f9a11c1d2613c2aa91fe11cd Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to drm_bridge_attach
On Mon, 13 Sep 2021 14:51:08 +0200, Alex Bee wrote:
> Commit a25b988ff83f ("drm/bridge: Extend bridge API to disable connector
> creation")
> added DRM_BRIDGE_ATTACH_NO_CONNECTOR bridge flag and all bridges handle
> this flag in some way since then.
> Newly added bridge drivers must no longer contain the connector creation and
> will fail probing if this flag isn't set.
>
> In order to be able to connect to those newly added bridges as well,
> make use of drm_bridge_connector API and have the connector initialized
> by the display controller.
Applied, thanks!
[1/1] drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to drm_bridge_attach
commit: 2e87bf389e1396b9f1360e1a7cdc27f423f56463
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: dsi: Fix duplicate included linux/phy/phy.h
On Fri, 20 Aug 2021 18:18:49 +0800, Jiapeng Chong wrote: > Clean up the following includecheck warning: > > ./drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c: linux/phy/phy.h is > included more than once. Applied, thanks! [1/1] drm/rockchip: dsi: Fix duplicate included linux/phy/phy.h commit: d90def98f90fb166191f19b41620e1a54b6dac75 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: handle non-platform devices in rockchip_drm_endpoint_is_subdriver
On Tue, 14 Sep 2021 17:07:56 +0200, Alex Bee wrote: > As discussed at [1] rockchip_drm_endpoint_is_subdriver will currently always > return -ENODEV for non-platform-devices (e.g. external i2c bridges), what > makes them never being considered in rockchip_rgb_init. > > As suggested at [1] this additionally adds a of_device_is_available for > the node found, which will work for both platform and non-platform devices. > Also we can return early for non-platform-devices if they are enabled, > as rockchip_sub_drivers contains exclusively platform-devices. > > [...] Applied, thanks! [1/1] drm/rockchip: handle non-platform devices in rockchip_drm_endpoint_is_subdriver commit: 37825e07ab413187e1ea078bc33dcdb835008be2 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: Make use of the helper function devm_platform_ioremap_resource()
On Tue, 31 Aug 2021 21:57:21 +0800, Cai Huoqing wrote: > Use the devm_platform_ioremap_resource() helper instead of > calling platform_get_resource() and devm_ioremap_resource() > separately Applied, thanks! [1/1] drm/rockchip: Make use of the helper function devm_platform_ioremap_resource() commit: 61735698103fafb5bc0df4ab208fc140c27cabc6 Best regards, -- Heiko Stuebner
Re: [PATCH v3] drm/rockchip: Update crtc fixup to account for fractional clk change
On Thu, 16 Sep 2021 15:29:07 -0500, Chris Morgan wrote:
> After commit 928f9e268611 ("clk: fractional-divider: Hide
> clk_fractional_divider_ops from wide audience") was merged it appears
> that the DSI panel on my Odroid Go Advance stopped working. Upon closer
> examination of the problem, it looks like it was the fixup in the
> rockchip_drm_vop.c file was causing the issue. The changes made to the
> clk driver appear to change some assumptions made in the fixup.
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: Update crtc fixup to account for fractional clk change
commit: e93a3ccf76996df53ff6c2c03626b70bb0b0d55d
Best regards,
--
Heiko Stuebner
Re: [PATCH v2] drm/rockchip: cdn-dp-core: Fix cdn_dp_resume unused warning
On Fri, 10 Sep 2021 20:43:18 -0700, Palmer Dabbelt wrote: > cdn_dp_resume is only used under PM_SLEEP, and now that it's static an > unused function warning is triggered undner !PM_SLEEP. This marks the > function as possibly unused, to avoid triggering compiler warnings. Applied, thanks! [1/1] drm/rockchip: cdn-dp-core: Fix cdn_dp_resume unused warning commit: f7c57a4566115657c16fd6603b6ef8a21bae5194 Best regards, -- Heiko Stuebner
Re: [PATCH 01/12] dt-bindings: display: rockchip: Add compatible for rk3568 HDMI
Hi, Am Mittwoch, 17. November 2021, 15:33:36 CET schrieb Sascha Hauer: > From: Benjamin Gaignard > > Define a new compatible for rk3568 HDMI. > This version of HDMI hardware block needs two new clocks hclk_vio and hclk > to provide phy reference clocks. > > Signed-off-by: Benjamin Gaignard > Reviewed-by: Rob Herring > Link: > https://lore.kernel.org/r/20210707120323.401785-2-benjamin.gaign...@collabora.com > Signed-off-by: Sascha Hauer > --- > .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > index da3b889ad8fcd..53fa42479d5b7 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > @@ -23,6 +23,7 @@ properties: >- rockchip,rk3288-dw-hdmi >- rockchip,rk3328-dw-hdmi >- rockchip,rk3399-dw-hdmi > + - rockchip,rk3568-dw-hdmi > >reg-io-width: > const: 4 > @@ -49,8 +50,11 @@ properties: >- vpll >- enum: >- grf > + - hclk_vio I don't believe this clock should be here: (1) the rk3568 dts node later in the series doesn't use it at all (2) generally vio-clocks are part of the interconnect where the ip block connects to, so right now we just enable it as critical on all socs and if someone actually models the interconnect (where also the qos [quality of service configs] nodes would play into), it would need to be included there. Heiko > + - vpll > + - enum: > + - hclk >- vpll > - - const: vpll > >ddc-i2c-bus: > $ref: /schemas/types.yaml#/definitions/phandle >
Re: [PATCH 07/18] dt-bindings: display: rockchip: dw-hdmi: Allow "ref" as clock name
Am Mittwoch, 8. Dezember 2021, 16:12:19 CET schrieb Sascha Hauer: > "vpll" is a misnomer. A clock input to a device should be named after > the usage in the device, not after the clock that drives it. On the > rk3568 the same clock is driven by the HPLL. > To fix that, this patch renames the vpll clock to ref clock. The clock > name "vpll" is left for compatibility to old device trees. Can't we just say that the binding only takes the "ref" name, but the code still allows "vpll". I think I remember Rob suggesting something similar in the past. I don't think that we need to keep the binding(-validation) compatible with old devicetrees, but the kernel itself should stay compatible. Heiko > > Signed-off-by: Sascha Hauer > --- > .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > index 6e09dd2ee05ac..2ab6578033da2 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml > @@ -48,10 +48,14 @@ properties: >- cec >- grf >- vpll > + - ref >- enum: >- grf >- vpll > - - const: vpll > + - ref > + - enum: > + - vpll > + - ref > >ddc-i2c-bus: > $ref: /schemas/types.yaml#/definitions/phandle >
Re: (subset) [PATCH v6 0/5] Add GPU for RK356x SoCs
On Wed, 9 Feb 2022 22:55:44 +0100, Michael Riesch wrote: > This series aims to bring the GPU support for the RK356x mainline. In > conjunction with the VOP2/HDMI TX patches v4 [0]) it has been tested > successfully on a RK3568 EVB1 with weston and glmark2-es2-wayland. > > It should be noted that on the RK3568 EVB1 the supply of the GPU power > domain needs to be set to "always-on" in the device tree. There is an > ongoing discussion to provide a clean solution [1], in the meantime one > has to apply a hack. > > [...] Applied to drm-misc-next, thanks! [1/5] dt-bindings: gpu: mali-bifrost: describe clocks for the rk356x gpu commit: f1775c26e8b8809d922a29bb5e3df6ea503d2fa0 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v6 0/5] Add GPU for RK356x SoCs
On Wed, 9 Feb 2022 22:55:44 +0100, Michael Riesch wrote: > This series aims to bring the GPU support for the RK356x mainline. In > conjunction with the VOP2/HDMI TX patches v4 [0]) it has been tested > successfully on a RK3568 EVB1 with weston and glmark2-es2-wayland. > > It should be noted that on the RK3568 EVB1 the supply of the GPU power > domain needs to be set to "always-on" in the device tree. There is an > ongoing discussion to provide a clean solution [1], in the meantime one > has to apply a hack. > > [...] Applied, thanks! [2/5] arm64: dts: rockchip: add gpu node to rk356x commit: 810028668c6d9da25664195d6b906c98a8169f72 [3/5] arm64: dts: rockchip: add cooling map and trip points for gpu to rk356x commit: c0a7259fad2df72469b602418083516c2cb3a7af [4/5] arm64: dts: rockchip: enable the gpu on quartz64-a commit: 6ac383456452378de07e55fc687069d1898a567d [5/5] arm64: dts: rockchip: enable the gpu on rk3568-evb1-v10 commit: 679f048a10d8322d79010e0e52f18a6c17bdf306 [6] arm64: dts: rockchip: enable the tsadc on rk3568-evb1-v10 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 00/27] drm/rockchip: RK356x VOP2 support
On Wed, 26 Jan 2022 15:55:22 +0100, Sascha Hauer wrote: > This is v4 of adding RK356x VOP2 support. Due to popular demand I added > a changelog to each patch, at least starting with changes to v3, I > didn't care to add the older changes as well. I hopefully integrated all > feedback I received to v3. Additionally I added some patches to the HDMI > driver to support resolutions up to 4k@60Hz. The patches are mostly > taken from the downstream kernel. Some have been send to public lists, > but were never applied upstream for reasons I do not know. The patches > are a bit more intrusive than needed for my case, but are present in the > downstream kernel for a long time, so I decided just to take them > instead of stripping them down to my needs. With these patches I > successfully used the driver with 4k@30Hz. 4k@60Hz doesn't work for me, > I hope this is due to my low quality cable. > > [...] Applied, thanks! [11/27] clk: rockchip: rk3568: Add more PLL rates commit: 842f4cb7263953020f4e2f2f0005fc3e6fc56144 [24/27] clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop* commit: ff3187eabb5ce478d15b6ed62eb286756adefac3 [25/27] clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock commit: 6e69052f01d9131388cfcfaee929120118a267f4 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v4 00/27] drm/rockchip: RK356x VOP2 support
On Wed, 26 Jan 2022 15:55:22 +0100, Sascha Hauer wrote: > This is v4 of adding RK356x VOP2 support. Due to popular demand I added > a changelog to each patch, at least starting with changes to v3, I > didn't care to add the older changes as well. I hopefully integrated all > feedback I received to v3. Additionally I added some patches to the HDMI > driver to support resolutions up to 4k@60Hz. The patches are mostly > taken from the downstream kernel. Some have been send to public lists, > but were never applied upstream for reasons I do not know. The patches > are a bit more intrusive than needed for my case, but are present in the > downstream kernel for a long time, so I decided just to take them > instead of stripping them down to my needs. With these patches I > successfully used the driver with 4k@30Hz. 4k@60Hz doesn't work for me, > I hope this is due to my low quality cable. > > [...] Applied, thanks! [18/27] arm64: dts: rockchip: rk3399: reorder hmdi clocks commit: 2e8a8b5955a000cc655f7e368670518cbb77fe58 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop: Correct RK3399 VOP register fields
On Wed, 19 Jan 2022 16:11:22 -0800, Brian Norris wrote:
> Commit 7707f7227f09 ("drm/rockchip: Add support for afbc") switched up
> the rk3399_vop_big[] register windows, but it did so incorrectly.
>
> The biggest problem is in rk3288_win23_data[] vs.
> rk3368_win23_data[] .format field:
>
> RK3288's format: VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1)
> RK3368's format: VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5)
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop: Correct RK3399 VOP register fields
commit: 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070
Best regards,
--
Heiko Stuebner
Re: (subset) [PATCH v2 0/3] (Re)enable DP/HDMI audio for RK3399 Gru
On Fri, 14 Jan 2022 15:02:06 -0800, Brian Norris wrote: > This series fixes DP/HDMI audio for RK3399 Gru systems. > > First, there was a regression with the switch to SPDIF. Patch 1 can be > taken separately as a regression fix if desired. But it's not quite so > useful (at least on Chrome OS systems) without the second part. > > Second, jack detection was never upstreamed, because the hdmi-codec > dependencies were still being worked out when this platform was first > supported. > > [...] Applied as fix for 5.17, thanks! [1/3] arm64: dts: rockchip: Switch RK3399-Gru DP to SPDIF output commit: b5fbaf7d779f5f02b7f75b080e7707222573be2a Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/4] Some cleanup of vop2 driver
On Fri, 13 Oct 2023 20:20:01 +0800, Andy Yan wrote: > From: Andy Yan > > This is a preparation for the upcoming support for rk3588 vop. > Patch 1 remove unused struct > Patch 2 remove NR_LAYERS macro to support more layers on rk3588 > Patch 3 are plane format fix > Patch 4 is a format rename > > [...] Applied, thanks! [1/4] drm/rockchip: remove unused struct in vop2 commit: ac1c11c23fc51c1ba51a3ed586df40ffe6b1de35 [2/4] drm/rockchip: remove NR_LAYERS macro on vop2 commit: dc00748adcf03d754bf43035c668bc5b20fb6597 So I've picked up the pretty straight-forward patches for now. Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map()
On Wed, 11 Oct 2023 11:01:48 +0300, Dan Carpenter wrote: > The "ret" variable is declared as ssize_t and it can hold negative error > codes but the "rk_obj->base.size" variable is type size_t. This means > that when we compare them, they are both type promoted to size_t and the > negative error code becomes a high unsigned value and is treated as > success. Add a cast to fix this. > > > [...] Applied, thanks! [1/1] drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map() commit: 6471da5ee311d53ef46eebcb7725bc94266cc0cf Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/5] Add Support for RK3566 Powkiddy RGB30
On Fri, 13 Oct 2023 13:39:13 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB30 handheld gaming console. > > Chris Morgan (5): > dt-bindings: vendor-prefixes: document Powkiddy > dt-bindings: panel: Add Powkiddy RGB30 panel compatible > drm/panel: st7703: Add Powkiddy RGB30 Panel Support > dt-bindings: arm64: rockchip: add Powkiddy RGB30 > arm64: dts: rockchip: add support for Powkiddy RGB30 > > [...] Applied, thanks! [1/5] dt-bindings: vendor-prefixes: document Powkiddy commit: 00e395c8edf7fb6fa0830125d91c2b4bc381eefd [2/5] dt-bindings: panel: Add Powkiddy RGB30 panel compatible commit: daee0320a13724e5a584726b693eee87bbd96172 [3/5] drm/panel: st7703: Add Powkiddy RGB30 Panel Support commit: 636a989eb4d022e1756009592445aedaaf7424d8 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/5] Add Support for RK3566 Powkiddy RGB30
On Fri, 13 Oct 2023 13:39:13 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RGB30 handheld gaming console. > > Chris Morgan (5): > dt-bindings: vendor-prefixes: document Powkiddy > dt-bindings: panel: Add Powkiddy RGB30 panel compatible > drm/panel: st7703: Add Powkiddy RGB30 Panel Support > dt-bindings: arm64: rockchip: add Powkiddy RGB30 > arm64: dts: rockchip: add support for Powkiddy RGB30 > > [...] Applied, thanks! [4/5] dt-bindings: arm64: rockchip: add Powkiddy RGB30 commit: 64d0de4f65c2951ccdc7a7aebe8a7e3455946f5f [5/5] arm64: dts: rockchip: add support for Powkiddy RGB30 commit: 1e9ac3e8a6a9d4da9efbad2d8e95cc1140e0e23f Best regards, -- Heiko Stuebner
Re: [PATCH] drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode
On Wed, 18 Oct 2023 11:52:12 +0800, Liu Ying wrote: > In order to support burst mode, vendor drivers set lane_mbps higher than > bandwidth through DPI interface. So, calculate horizontal component lane > byte clock cycle(lbcc) based on lane_mbps instead of pixel clock rate for > burst mode. > > Applied, thanks! [1/1] drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst mode commit: 93e82bb4de0196c4caeca1d8a6eef67863981d8f Best regards, -- Heiko Stuebner
Re: [PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
On Mon, 23 Oct 2023 17:37:13 +, Jonas Karlman wrote: > This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced > by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. > Also include 10-bit 4:4:4 support since VOP can support that also. > > First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. > Second patch adds support for displaying the new fourcc formats. > > [...] Applied, thanks! [1/2] drm/fourcc: Add NV20 and NV30 YUV formats commit: 728c15b4b5f3369cbde73d5e0f14701ab370f985 [2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support commit: d4b384228562848e4b76b608a5876c92160e993c Best regards, -- Heiko Stuebner
Re: [PATCH v3 0/4] Add more format for vop2 driver
On Wed, 18 Oct 2023 17:41:22 +0800, Andy Yan wrote: > From: Andy Yan > > > This is a preparation for the upcoming support for rk3588 vop. > > Patch 1 make the bpp calculation covery more format > Patch 2 remove formats that are unsupported by cluster windows > Patch 3 add more formats > Patch 4 is a format table rename > > [...] Applied, thanks! [1/4] drm/rockchip: fix vop format bpp calculation commit: 45ad07c7053df0b67e13d8deb574920d11651fb2 [2/4] drm/rockchip: remove the unsupported format of vop2 cluster window commit: 01d5a75370a60c3a8d691347ae6ebb2a9f8dc44a [3/4] drm/rockchip: Add more format supported by vop2 commit: bfd8a5c228fa3bb97884f77529c09e8745da08b9 [4/4] drm/rockchip: rename windows format for vop2 commit: 215737e37d07ade8952048339e37aec6c6f82223 I've adapted the patch subjects slightly to match the current drm/rockchip: vop: ... drm/rockchip: vop2: ... formats. Best regards, -- Heiko Stuebner
Re: (subset) [PATCH 0/5] rockchip: Add Powkiddy RK2023
On Wed, 18 Oct 2023 11:18:43 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RK2023, which is extremely similar to > existing devices from Anbernic. > > Chris Morgan (5): > dt-bindings: display: panel: Update NewVision NV3051D compatibles > drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support > clk: rockchip: rk3568: Add PLL rate for 115.2MHz > dt-bindings: arm: rockchip: Add Powkiddy RK2023 > arm64: dts: rockchip: add Powkiddy RK2023 > > [...] Applied, thanks! [3/5] clk: rockchip: rk3568: Add PLL rate for 115.2MHz commit: ccf59682a0287b81015dc1939203fac70b818c6b I've gone forward and grabbed the PLL rate already, so it can go together with the other rate addition from the fixes series. Best regards, -- Heiko Stuebner
Re: [PATCH 1/3] drm/panel: ltk050h3146w: add mipi_dsi_device.mode_flags to of_match_data
On Mon, 31 Jan 2022 17:47:21 +0100, quentin.sch...@theobroma-systems.com wrote: > From: Quentin Schulz > > To prepare for a new display to be supported by this driver which has a > slightly different set of DSI mode related flags, let's move the > currently hardcoded mode flags to the .data field of of_device_id > structure. > > [...] Applied, thanks! [1/3] drm/panel: ltk050h3146w: add mipi_dsi_device.mode_flags to of_match_data commit: 99403d747ae8c7b3bfb5cd14c8908930ec6801c6 [2/3] drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant commit: e5f9d543419c78ac58f3b3557bc5a76b20ff600b [3/3] dt-bindings: ltk050h3146w: add compatible for LTK050H3148W-CTA6 variant commit: 29d8e38c36cb662331a833699c359ec1af1edbec Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Demote message in mod_supported to drm_dbg_kms
On Mon, 9 Oct 2023 12:37:53 +0200, Michael Tretter wrote: > Checking if a modifier is supported by a plane is normal behavior. It is > normal that a plane may not support certain modifiers. Failing the check > doesn't justify an error message in the kernel log and may mislead > users. > > Demote the error message to drm_dbg_kms to only print the message if the > respective debug messages are enabled. This is similar to the behavior > in rockchip_drm_vop.c. > > [...] Applied, thanks! [1/1] drm/rockchip: vop2: Demote message in mod_supported to drm_dbg_kms commit: eb23cffdd7f085149799e5eda12a9aff792cc34d Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe()
On Sat, 2 Sep 2023 19:34:31 +0200, Christophe JAILLET wrote: > cdn_dp_audio_codec_init() can fail. So add some error handling. > > If component_add() fails, the previous cdn_dp_audio_codec_init() call > should be undone, as already done in the remove function. > > Applied, thanks! [1/1] drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe() commit: 44b968d0d0868b7a9b7a5c64464ada464ff4d532 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: Convert to use maple tree register cache
On Sun, 01 Oct 2023 01:42:50 +0200, Mark Brown wrote: > The maple tree register cache is based on a much more modern data structure > than the rbtree cache and makes optimisation choices which are probably > more appropriate for modern systems than those made by the rbtree cache. > > Applied, thanks! [1/1] drm/rockchip: vop2: Convert to use maple tree register cache commit: 3d59c22bbb8d03f3f14e6d0845d44c146fb48f35 Best regards, -- Heiko Stuebner
Re: [PATCH -next] drm/rockchip: remove redundant of_match_ptr
On Mon, 31 Jul 2023 20:53:04 +0800, Zhu Wang wrote: > The driver depends on CONFIG_OF, so it is not necessary to use > of_match_ptr here. > > Even for drivers that do not depend on CONFIG_OF, it's almost always > better to leave out the of_match_ptr(), since the only thing it can > possibly do is to save a few bytes of .text if a driver can be used both > with and without it. Hence we remove of_match_ptr. > > [...] Applied, thanks! [1/1] drm/rockchip: remove redundant of_match_ptr commit: 63a06c9fe30bf84d1ab6f07d0e408bd1d4ccaf85 Best regards, -- Heiko Stuebner
Re: [PATCH -next] drm/rockchip: dsi: Use devm_platform_get_and_ioremap_resource()
On Fri, 21 Apr 2023 16:13:03 +0800, Yang Li wrote: > Convert platform_get_resource(), devm_ioremap_resource() to a single > call to devm_platform_get_and_ioremap_resource(), as this is exactly > what this function does. > > Applied, thanks! [1/1] drm/rockchip: dsi: Use devm_platform_get_and_ioremap_resource() commit: 253a1d33e5cfdf62525f5d6ed2bf03acbadd1582 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/3] add Pine64 touch panel support to rockpro64
On Wed, 11 May 2022 07:35:13 -0400, Peter Geis wrote: > Good Morning, > > Apologies Heiko on taking so long for this v2. > > This patch series adds support for the Pine64 touch panel to the > rockpro64 single board computer. > This panel attaches to the dsi port and includes an i2c touch screen. > > [...] Applied, thanks! [1/3] dt-bindings: display: panel: feiyang, fy07024di26a30d: make reset gpio optional commit: d0956e2c520c9d730979a9669f27a77d40acac13 [2/3] drm/panel: feiyang-fy07024di26a30d: make reset gpio optional commit: de5db71e4c8c35ed5e92006e3064ce9230881ece Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/3] add Pine64 touch panel support to rockpro64
On Wed, 11 May 2022 07:35:13 -0400, Peter Geis wrote: > Good Morning, > > Apologies Heiko on taking so long for this v2. > > This patch series adds support for the Pine64 touch panel to the > rockpro64 single board computer. > This panel attaches to the dsi port and includes an i2c touch screen. > > [...] Applied, thanks! [3/3] arm64: dts: rockchip: add pine64 touch panel display to rockpro64 ... for 5.20 . The binding- and driver-change most likely won't reach drm-main and thus the next merge-window in time, so I've put the dts patch on a branch for 5.20 instead. I've also made some ordering changes and dropped both the "force X to vopY" parts. DT is a hardware-description and not a configuration space ;-) . And a devicetree should definitly not try to work around implementation deficits of the kernel driver. Both VOPs are capable of driving both hdmi and dsi with their relevant deficiencies being in terms of resolution or clock rates I guess, so anything related to selecting a matching VOP should be done in code in the kernel. Best regards, -- Heiko Stuebner
Re: [PATCH] drm/rockchip: vop2: unlock on error path in vop2_crtc_atomic_enable()
On Mon, 9 May 2022 12:05:05 +0300, Dan Carpenter wrote: > This error path needs an unlock before returning. Applied, thanks! [1/1] drm/rockchip: vop2: unlock on error path in vop2_crtc_atomic_enable() commit: 98526c5bbe3267d447ddd076b685439e3e1396c6 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/3] RK356x VOP2: Change register space names
On Wed, 11 May 2022 10:21:06 +0200, Sascha Hauer wrote: > The VOP2 driver sitting in next uses named register spaces, but the > binding lacks documentation for that. Add the missing documentation > and while at it take the opportunity to rename the register spaces > from too generic "regs" to "vop" and from "gamma_lut" to better looking > "gamma-lut". > > Changes since v1: > - Fix dt_binding_check errors > > [...] Applied, thanks! [1/3] dt-bindings: display: rockchip: make reg-names mandatory for VOP2 commit: 54eb8d446e710b5f77969bd34f0a162cf86b8d29 [2/3] drm: rockchip: Change register space names commit: 5ee8c8f930ba7d20717c4fc2d9f1ce0e757d1155 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support
On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote: > It's v11 time. There's only one small change to v10. Discussion seems to > have settled now. Is there anything left that prevents the series from > being merged? I'd really like to have it in during the next merge > window. > > This series still depends on: > drm/rockchip: Refactor IOMMU initialisation > (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html) > arm64: dts: rockchip: add basic dts for the radxa rock3 model a > > [...] Applied for 5.20. The vop2 dt-binding header is going through the drm tree and the reg-names addition is going through drm-misc-next-fixes into the 5.19-rc kernels and this is a big bunch of dt changes so I'm leaving them for 5.20. [16/24] arm64: dts: rockchip: rk356x: Add VOP2 nodes commit: 9b3c9f6e57ef26b8478da64e3d49d0438291a98a [17/24] arm64: dts: rockchip: rk356x: Add HDMI nodes commit: db24799d31e7149bd8495a5f41c408434ca1a654 [18/24] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi commit: f2cdaaae9b947970842196ac93d71b0daad3e629 [19/24] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a commit: 97d7309a70b03d01a154c4308f423b020f7d397e [20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a commit: 281f94d9cbac31c1c112d09883bc42021435f1ad Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v2 0/3] RK356x VOP2: Change register space names
On Wed, 11 May 2022 10:21:06 +0200, Sascha Hauer wrote: > The VOP2 driver sitting in next uses named register spaces, but the > binding lacks documentation for that. Add the missing documentation > and while at it take the opportunity to rename the register spaces > from too generic "regs" to "vop" and from "gamma_lut" to better looking > "gamma-lut". > > Changes since v1: > - Fix dt_binding_check errors > > [...] Applied, thanks! [3/3] arm64: dts: rockchip: rk356x: Change VOP2 register space names applied as fixup to [16/24] arm64: dts: rockchip: rk356x: Add VOP2 nodes commit: 9b3c9f6e57ef26b8478da64e3d49d0438291a98a Best regards, -- Heiko Stuebner
Re: [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support
Am Freitag, 22. April 2022, 09:28:17 CEST schrieb Sascha Hauer: > It's v11 time. There's only one small change to v10. Discussion seems to > have settled now. Is there anything left that prevents the series from > being merged? I'd really like to have it in during the next merge > window. > > This series still depends on: > drm/rockchip: Refactor IOMMU initialisation > (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html) > arm64: dts: rockchip: add basic dts for the radxa rock3 model a > > Sascha I've now picked up everything except the hdmi-rate stuff in some way. The driver changes will go into 5.19 and the DT-changes into 5.20. I'll now move the series out of my focus and would expect further hdmi rate voodoo to start a new series :-) . Thanks to all involved for working on this. Heiko
Re: [PATCH v2 1/3] dt-bindings: display: rockchip: make reg-names mandatory for VOP2
Hi Rob, Krzysztof,
Am Mittwoch, 11. Mai 2022, 10:21:07 CEST schrieb Sascha Hauer:
> The VOP2 driver relies on reg-names properties, but these are not
> documented. Add the missing documentation, make reg-names mandatory
> and increase minItems to 2 as always both register spaces are needed.
>
> Signed-off-by: Sascha Hauer
does this look ok now?
Thanks
Heiko
> ---
>
> Notes:
> Changes since v1:
> - Drop minItems
> - Add reg-names properties to example
>
> .../bindings/display/rockchip/rockchip-vop2.yaml | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> index 655d9b327f7d3..fba45091d9092 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> @@ -22,7 +22,6 @@ properties:
>- rockchip,rk3568-vop
>
>reg:
> -minItems: 1
> items:
>- description:
>Must contain one entry corresponding to the base address and length
> @@ -31,6 +30,11 @@ properties:
>Can optionally contain a second entry corresponding to
>the CRTC gamma LUT address.
>
> + reg-names:
> +items:
> + - const: vop
> + - const: gamma-lut
> +
>interrupts:
> maxItems: 1
> description:
> @@ -86,6 +90,7 @@ properties:
> required:
>- compatible
>- reg
> + - reg-names
>- interrupts
>- clocks
>- clock-names
> @@ -104,6 +109,7 @@ examples:
> vop: vop@fe04 {
> compatible = "rockchip,rk3568-vop";
> reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0
> 0x1000>;
> +reg-names = "vop", "gamma-lut";
> interrupts = ;
> clocks = < ACLK_VOP>,
> < HCLK_VOP>,
>
Re: [PATCH][next] drm/rockchip: Fix spelling mistake "aligened" -> "aligned"
Hi, Am Freitag, 13. Mai 2022, 15:53:41 CEST schrieb Colin Ian King: > There is a spelling mistake in a drm_err message. Fix it. > > Signed-off-by: Colin Ian King didn't you sent the same patch some days ago already? Which is applied to drm-misc-next in [0]. Just want to make sure I didn't miss anything. Thanks Heiko [0] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f0eaf60c67738da8aae786bda74a2fffeca6d7cc > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > index 0b49fed16535..04e8e22a8640 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > @@ -1202,7 +1202,7 @@ static void vop2_plane_atomic_update(struct drm_plane > *plane, >*/ > stride = (fb->pitches[0] << 3) / bpp; > if ((stride & 0x3f) && (xmirror || rotate_90 || rotate_270)) > - drm_err(vop2->drm, "vp%d %s stride[%d] not 64 pixel > aligened\n", > + drm_err(vop2->drm, "vp%d %s stride[%d] not 64 pixel > aligned\n", > vp->id, win->data->name, stride); > > rb_swap = vop2_afbc_rb_swap(fb->format->format); >
Re: [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state()
Am Freitag, 24. Juni 2022, 19:57:53 CEST schrieb Brian Norris: > On Fri, Jun 24, 2022 at 12:23 AM Heiko Stuebner wrote: > > The interesting question would be, do we want some fixes tag for it? > > I'm not aware of any currently-upstream code that will hit this [1]. > I've hit it in out-of-tree code (or, code that I submitted to > dri-devel, but wasn't accepted as-is), and this is the "belt and > braces" part -- the primary fix is that we should avoid calling things > like drm_atomic_get_crtc_state() at inappropriate times. > > So, is the "extra safety" check really something that should go to > -stable? (Because let's be honest, everything with a Fixes tag goes > there.) Maybe? > > Anyway, if you want to "blame" anything, this commit actually dropped > the safety check: > > 4e257d9eee23 drm/rockchip: get rid of rockchip_drm_crtc_mode_config I tend to think, if we know that connection we should also include it :-) . I wouldn't include a cc-stable for the reason you mentioned, but to me it makes sense if someone reading the git history in the future can easily know that information - so it doesn't hurt :-) . So I'll add that when applying. Thanks for supplying the origin commit Heiko > > Brian > > [1] But I'm not omniscient. So maybe it's good to have anyway. >
Re: [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state()
On Fri, 17 Jun 2022 17:26:52 -0700, Brian Norris wrote: > It's possible for users to try to duplicate the CRTC state even when the > state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other > users of __drm_atomic_helper_crtc_duplicate_state()) already guard this > with a WARN_ON() instead of crashing, so let's do that here too. Applied, thanks! [1/1] drm/rockchip: vop: Don't crash for invalid duplicate_state() commit: 1449110b0dade8b638d2c17ab7c5b0ff696bfccb Best regards, -- Heiko Stuebner
