[PATCH 3/4] drm/tiny: add simple-dbi driver
Add a driver for generic MIPI DBI panels initialized with MIPI DCS
commands.
Currently a ST7789V-based panel is added to it. This panel has its
configuration pre-programmed into the controller, so no vendor-specific
configuration is needed.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/tiny/Kconfig | 12 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/simple-dbi.c | 244 ++
3 files changed, 257 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d31be274a2bd..6cfc57b68a46 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -144,6 +144,18 @@ config TINYDRM_REPAPER
If M is selected the module will be called repaper.
+config TINYDRM_SIMPLE_DBI
+ tristate "DRM support for generic MIPI DBI panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ help
+ DRM driver for generic DBI panels that are MIPI DCS compatible
+ and needs no vendor-specific setup commands.
+
+ If M is selected the module will be called simple-dbi.
+
config TINYDRM_ST7586
tristate "DRM support for Sitronix ST7586 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index e09942895c77..2553de651aa3 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
+obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
b/drivers/gpu/drm/tiny/simple-dbi.c
new file mode 100644
index ..2b207e43d500
--- /dev/null
+++ b/drivers/gpu/drm/tiny/simple-dbi.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for display panels with configuration preset and needs only
+ * standard MIPI DCS commands to bring up.
+ *
+ * Copyright (C) 2021 Sipeed
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
+#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
+#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
+#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
+
+struct simple_dbi_cfg {
+ const struct drm_display_mode mode;
+ unsigned int left_offset;
+ unsigned int top_offset;
+ bool inverted;
+ bool write_only;
+ bool bgr;
+ bool right_to_left;
+ bool bottom_to_top;
+};
+
+struct simple_dbi_priv {
+ struct mipi_dbi_dev dbidev; /* Must be first for .release() */
+ const struct simple_dbi_cfg *cfg;
+};
+
+static void simple_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct simple_dbi_priv *priv = container_of(dbidev,
+ struct simple_dbi_priv,
+ dbidev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ int ret, idx;
+ u8 addr_mode = 0x00;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_reset(dbidev);
+ if (ret)
+ goto out_exit;
+
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(5);
+
+ /* Currently tinydrm supports 16bit only now */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+
+ if (priv->cfg->inverted)
+ mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVERT_MODE);
+ else
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_INVERT_MODE);
+
+ if (priv->cfg->bgr)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_BGR;
+
+ if (priv->cfg->right_to_left)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_RTL;
+
+ if (priv->cfg->bottom_to_top)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_BTT;
+
+ switch (dbidev->rotation) {
+ default:
+ break;
+ case 90:
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_REVERSE;
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_RTL;
+ break;
+ case 180:
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_RTL;
+ addr_mode ^= MIP
[PATCH 0/4] Add simple-dbi tinydrm driver
This patchset adds a tinydrm driver called simple-dbi, which is a driver that utilizes only standardized commands in MIPI DCS to activate a MIPI DBI panel that requires no extra configuration, usually because the configuration is pre-programmed into the OTP of the LCD controller. Icenowy Zheng (4): dt-bindings: vendor-prefixes: add Zhishengxin dt-bindings: display: add binding for simple-dbi panels drm/tiny: add simple-dbi driver MAINTAINERS: add simple-dbi driver .../bindings/display/simple-dbi.yaml | 72 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 + drivers/gpu/drm/tiny/Kconfig | 12 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/simple-dbi.c | 244 ++ 6 files changed, 338 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/simple-dbi.yaml create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c -- 2.30.2
[PATCH 1/4] dt-bindings: vendor-prefixes: add Zhishengxin
Shenzhen Zhishengxin Technology Co., Ltd. is a LCD module supplier. Add vendor prefix for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 62cb1d9341f5..d8fdec851f38 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1334,6 +1334,8 @@ patternProperties: description: Zinitix Co., Ltd "^zkmagic,.*": description: Shenzhen Zkmagic Technology Co., Ltd. + "^zsx,.*": +description: Shenzhen Zhishengxin Technology Co., Ltd. "^zte,.*": description: ZTE Corp. "^zyxel,.*": -- 2.30.2
[PATCH 2/4] dt-bindings: display: add binding for simple-dbi panels
As we're going to introduce a driver for MIPI DBI panels that need only
standard MIPI-DCS commands to initialize (usually because the controller
has some configuration pre-programmed), add a DT binding file for it,
which now includes only one DBI Type C Option 3 panel, ZSX154-B1206.
Signed-off-by: Icenowy Zheng
---
.../bindings/display/simple-dbi.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/simple-dbi.yaml
diff --git a/Documentation/devicetree/bindings/display/simple-dbi.yaml
b/Documentation/devicetree/bindings/display/simple-dbi.yaml
new file mode 100644
index ..f49b0fda0935
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/simple-dbi.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/simple-dbi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MIPI DCS-compatible DBI panels Device Tree Bindings
+
+maintainers:
+ - Icenowy Zheng
+
+description:
+ This binding is for display panels that utilizes MIPI DBI Type C, follows
+ MIPI DCS and needs no vendor-specific initialization commands.
+
+properties:
+ compatible:
+oneOf:
+ - description:
+ Zhishengxin ZSX154-B1206 1.54" 240x240 SPI LCD
+items:
+ - const: zsx,zsx154-b1206
+
+ spi-max-frequency:
+maximum: 3000
+
+ dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+ backlight: true
+ reg: true
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+ - if:
+ properties:
+compatible:
+ contains:
+const: zsx,zsx154-b1206
+
+then:
+ required:
+- dc-gpios
+- reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0 {
+compatible = "zsx,zsx154-b1206";
+reg = <0>;
+spi-max-frequency = <3000>;
+dc-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&r_pio 2 21 GPIO_ACTIVE_HIGH>;
+};
+};
+
+...
--
2.30.2
[PATCH 4/4] MAINTAINERS: add simple-dbi driver
As I pushed the simple-dbi driver, add myself as the maintainer now. Signed-off-by: Icenowy Zheng --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3a00771b9fe2..e05c4910c062 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5803,6 +5803,13 @@ S: Maintained F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c +DRM DRIVER FOR GENERIC MIPI-DBI LCD PANELS +M: Icenowy Zheng +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/simple-dbi.yaml +F: drivers/gpu/drm/tiny/simple-dbi.c + DRM DRIVER FOR GENERIC USB DISPLAY M: Noralf Trønnes S: Maintained -- 2.30.2
Re: [PATCH 3/4] drm/tiny: add simple-dbi driver
在 2021-08-02星期一的 14:35 +0800，Icenowy Zheng写道：
> Add a driver for generic MIPI DBI panels initialized with MIPI DCS
> commands.
>
> Currently a ST7789V-based panel is added to it. This panel has its
> configuration pre-programmed into the controller, so no vendor-
> specific
> configuration is needed.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/gpu/drm/tiny/Kconfig | 12 ++
> drivers/gpu/drm/tiny/Makefile | 1 +
> drivers/gpu/drm/tiny/simple-dbi.c | 244
> ++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
>
> diff --git a/drivers/gpu/drm/tiny/Kconfig
> b/drivers/gpu/drm/tiny/Kconfig
> index d31be274a2bd..6cfc57b68a46 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -144,6 +144,18 @@ config TINYDRM_REPAPER
>
> If M is selected the module will be called repaper.
>
> +config TINYDRM_SIMPLE_DBI
> + tristate "DRM support for generic MIPI DBI panels"
> + depends on DRM && SPI
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DBI
> + help
> + DRM driver for generic DBI panels that are MIPI DCS
> compatible
> + and needs no vendor-specific setup commands.
> +
> + If M is selected the module will be called simple-dbi.
> +
> config TINYDRM_ST7586
> tristate "DRM support for Sitronix ST7586 display panels"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile
> b/drivers/gpu/drm/tiny/Makefile
> index e09942895c77..2553de651aa3 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+=
> mi0283qt.o
> obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
> obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
> +obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
> diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
> b/drivers/gpu/drm/tiny/simple-dbi.c
> new file mode 100644
> index ..2b207e43d500
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/simple-dbi.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DRM driver for display panels with configuration preset and needs
> only
> + * standard MIPI DCS commands to bring up.
> + *
> + * Copyright (C) 2021 Sipeed
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
> +#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
> +#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
> +#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
> +
> +struct simple_dbi_cfg {
> + const struct drm_display_mode mode;
> + unsigned int left_offset;
> + unsigned int top_offset;
> + bool inverted;
> + bool write_only;
> + bool bgr;
> + bool right_to_left;
> + bool bottom_to_top;
> +};
> +
> +struct simple_dbi_priv {
> + struct mipi_dbi_dev dbidev; /* Must be first for
> .release() */
> + const struct simple_dbi_cfg *cfg;
> +};
> +
> +static void simple_dbi_pipe_enable(struct drm_simple_display_pipe
> *pipe,
> + struct drm_crtc_state *crtc_state,
> + struct drm_plane_state *plane_state)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe-
> >crtc.dev);
> + struct simple_dbi_priv *priv = container_of(dbidev,
> + struct
> simple_dbi_priv,
> + dbidev);
> + struct mipi_dbi *dbi = &dbidev->dbi;
> + int ret, idx;
> + u8 addr_mode = 0x00;
> +
> + if (!drm_dev_enter(pipe->crtc.dev, &idx))
> + return;
> +
> + DRM_DEBUG_KMS("\n");
> +
> + ret = mipi_dbi_poweron_reset(dbidev);
> + if (ret)
> + goto out_exit;
> +
> + mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
> + msleep(5);
> +
> + /* Currently tinydrm supports 16bit only now */
> + mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
> + MIPI_DCS_PIXEL_FMT_16BIT);
> +
> + if (priv->cfg->inverted)
> + mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVE
Re: [PATCH 3/4] drm/tiny: add simple-dbi driver
在 2021-08-02星期一的 17:08 +0200，Thomas Zimmermann写道：
> Hi
>
> Am 02.08.21 um 08:35 schrieb Icenowy Zheng:
> > Add a driver for generic MIPI DBI panels initialized with MIPI DCS
> > commands.
> >
> > Currently a ST7789V-based panel is added to it. This panel has its
> > configuration pre-programmed into the controller, so no vendor-
> > specific
> > configuration is needed.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/tiny/Kconfig | 12 ++
> > drivers/gpu/drm/tiny/Makefile | 1 +
> > drivers/gpu/drm/tiny/simple-dbi.c | 244
> > ++
> > 3 files changed, 257 insertions(+)
> > create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
> >
> > diff --git a/drivers/gpu/drm/tiny/Kconfig
> > b/drivers/gpu/drm/tiny/Kconfig
> > index d31be274a2bd..6cfc57b68a46 100644
> > --- a/drivers/gpu/drm/tiny/Kconfig
> > +++ b/drivers/gpu/drm/tiny/Kconfig
> > @@ -144,6 +144,18 @@ config TINYDRM_REPAPER
> >
> > If M is selected the module will be called repaper.
> >
> > +config TINYDRM_SIMPLE_DBI
> > + tristate "DRM support for generic MIPI DBI panels"
> > + depends on DRM && SPI
> > + select DRM_KMS_HELPER
> > + select DRM_KMS_CMA_HELPER
> > + select DRM_MIPI_DBI
> > + help
> > + DRM driver for generic DBI panels that are MIPI DCS
> > compatible
> > + and needs no vendor-specific setup commands.
> > +
> > + If M is selected the module will be called simple-dbi.
> > +
> > config TINYDRM_ST7586
> > tristate "DRM support for Sitronix ST7586 display panels"
> > depends on DRM && SPI
> > diff --git a/drivers/gpu/drm/tiny/Makefile
> > b/drivers/gpu/drm/tiny/Makefile
> > index e09942895c77..2553de651aa3 100644
> > --- a/drivers/gpu/drm/tiny/Makefile
> > +++ b/drivers/gpu/drm/tiny/Makefile
> > @@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+=
> > mi0283qt.o
> > obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
> > obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> > obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
> > +obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
> > diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
> > b/drivers/gpu/drm/tiny/simple-dbi.c
> > new file mode 100644
> > index ..2b207e43d500
> > --- /dev/null
> > +++ b/drivers/gpu/drm/tiny/simple-dbi.c
> > @@ -0,0 +1,244 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * DRM driver for display panels with configuration preset and
> > needs only
> > + * standard MIPI DCS commands to bring up.
> > + *
> > + * Copyright (C) 2021 Sipeed
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
> > +#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
> > +#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
> > +#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
> > +
> > +struct simple_dbi_cfg {
> > + const struct drm_display_mode mode;
> > + unsigned int left_offset;
> > + unsigned int top_offset;
> > + bool inverted;
> > + bool write_only;
> > + bool bgr;
> > + bool right_to_left;
> > + bool bottom_to_top;
> > +};
> > +
> > +struct simple_dbi_priv {
> > + struct mipi_dbi_dev dbidev; /* Must be first for
> > .release() */
>
> Which release?
Ah, some copy-n-paste waste.
Will drop this in v2.
>
> > + const struct simple_dbi_cfg *cfg;
> > +};
> > +
> > +static void simple_dbi_pipe_enable(struct drm_simple_display_pipe
> > *pipe,
> > + struct drm_crtc_state *crtc_state,
> > + struct drm_plane_state
> > *plane_state)
> > +{
> > + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe-
> > >crtc.dev);
> > + struct simple_dbi_priv *priv = container_of(dbidev,
> > + struct
> > simple_dbi_priv,
> > + dbidev
[PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
Attaching the panel can fail, so cleanup work is necessary, otherwise
a pointer to freed struct drm_panel* will remain in drm_panel code.
Do the cleanup if panel attaching failed.
Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD
panel")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..f9c1f7bc8218 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -227,7 +227,13 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
}
static int feiyang_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: k101-im2ba02: Make use of the helper function dev_err_probe()
在 2021-09-16星期四的 18:42 +0800，Cai Huoqing写道：
> When possible use dev_err_probe help to properly deal with the
> PROBE_DEFER error, the benefit is that DEFER issue will be logged
> in the devices_deferred debugfs file.
> And using dev_err_probe() can reduce code size, and the error value
> gets printed.
>
> Signed-off-by: Cai Huoqing
Looks good to me, and thanks for pointing out this helper.
Acked-by: Icenowy Zheng
> ---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> index 2a602aee61c3..cb0bb3076099 100644
> --- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> +++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> @@ -456,16 +456,13 @@ static int k101_im2ba02_dsi_probe(struct
> mipi_dsi_device *dsi)
>
> ret = devm_regulator_bulk_get(&dsi->dev, ARRAY_SIZE(ctx-
> >supplies),
> ctx->supplies);
> - if (ret < 0) {
> - dev_err(&dsi->dev, "Couldn't get regulators\n");
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(&dsi->dev, ret, "Couldn't get
> regulators\n");
>
> ctx->reset = devm_gpiod_get(&dsi->dev, "reset",
> GPIOD_OUT_LOW);
> - if (IS_ERR(ctx->reset)) {
> - dev_err(&dsi->dev, "Couldn't get our reset GPIO\n");
> - return PTR_ERR(ctx->reset);
> - }
> + if (IS_ERR(ctx->reset))
> + return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
> + "Couldn't get our reset
> GPIO\n");
>
> drm_panel_init(&ctx->panel, &dsi->dev, &k101_im2ba02_funcs,
> DRM_MODE_CONNECTOR_DSI);
[PATCH] drm/panel: ilitek-ili9881c: fix attach failure cleanup
When mipi_dsi_attach() fails (e.g. got a -EPROBE_DEFER), the panel should
be removed, otherwise a pointer to it will be kept and then lead to
use-after-free when DRM panel codes are called (e.g. the panel is probed
again).
Fix this by adding cleanup code after mipi_dsi_attach() failure.
Fixes: 26aec25593c2 ("drm/panel: Add Ilitek ILI9881c panel driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0145129d7c66..22f2268f00f7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -674,7 +674,13 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
}
static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
于 2021年1月6日 GMT+08:00 下午5:47:20, Jagan Teki 写到:
>On Sat, Nov 28, 2020 at 6:23 PM Icenowy Zheng wrote:
>>
>> Attaching the panel can fail, so cleanup work is necessary, otherwise
>> a pointer to freed struct drm_panel* will remain in drm_panel code.
>>
>> Do the cleanup if panel attaching failed.
>>
>> Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D
>MIPI-DSI LCD panel")
>
>The fact that this has failed to probe due to recent changes in
>sun6i_mipi_dsi.c I don't know how to put that into the commit message.
It's not related, we shouldn't assume this panel driver will always
be used with sunxi SoCs.
It's a panel driver bug that cannot deal with -EPROBE_DEFER well.
>> Signed-off-by: Icenowy Zheng
>> ---
>
>Reviewed-by: Jagan Teki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the clock rate") prevents some panel and bridges from
>working with
>> > sun4i driver.
>> >
>> > Unfortunately, dotclock frequency for some modes are not achievable
>on
>> > sunxi hardware, and there's a slight deviation in rate returned by
>> > clk_round_rate(), so they fail this check.
>> >
>> > Experiments show that panels and bridges work fine with this slight
>> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP
>panel
>> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and
>works just
>> > fine.
>> >
>> > This patch adds a 1% tolerence to the dot clock check when bridge
>is
>> > connected.
>> >
>> > Signed-off-by: Vasily Khoruzhick
>>
>> I'm not sure we want to make exceptions for all the hardware
>> combination we face, but we should go for something more generic (and
>> easier to maintain instead).
>>
>> IIRC, from the previous discussion, HDMI had a tolerancy requirement
>> in the standard. Do you know if there's such a thing for eDP? That
>> would solve the issue for all the eDP displays at once.
>
>I don't have access to eDP standard - vesa.org says it's available to
>members only.
Try out to grab an old version?
I remember 1.0 is open.
>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard 写到: >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: >> > > Maybe instead of edp-connector one would introduce integrator's >specific >> > > connector, for example with compatible >"olimex,teres-edp-connector" >> > > which should follow edp abstract connector rules? This will be at >least >> > > consistent with below presentation[1] - eDP requirements depends >on >> > > integrator. Then if olimex has standard way of dealing with >panels >> > > present in olimex/teres platforms the driver would then create >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I >guess. >> > > Anyway it still looks fishy for me :), maybe because I am not >> > > familiarized with details of these platforms. >> > >> > That makes sense yes >> >> Actually, it makes no sense at all. Current implementation for >anx6345 >> driver works fine as is with any panel specified assuming panel >delays >> are long enough for connected panel. It just doesn't use panel >timings >> from the driver. Creating a platform driver for connector itself >looks >> redundant since it can't be reused, it doesn't describe actual >> hardware and it's just defeats purpose of DT by introducing >> board-specific code. > >I'm not sure where you got the idea that the purpose of DT is to not >have any board-specific code. > >It's perfectly fine to have some, that's even why there's a compatible >assigned to each and every board. > >What the DT is about is allowing us to have a generic behaviour that >we can detect: we can have a given behaviour for a given board, and a >separate one for another one, and this will be evaluated at runtime. > >This is *exactly* what this is about: we can have a compatible that >sets a given, more specific, behaviour (olimex,teres-edp-connector) >while saying that this is compatible with the generic behaviour >(edp-connector). That way, any OS will know what quirk to apply if >needed, and if not that it can use the generic behaviour. > >And we could create a generic driver, for the generic behaviour if >needed. > >> There's another issue: if we introduce edp-connector we'll have to >> specify power up delays somewhere (in dts? or in platform driver?), >so >> edp-connector doesn't really solve the issue of multiple panels with >> same motherboard. > >And that's what that compatible is about :) Maybe we can introduce a connector w/o any driver just like hdmi-connector? > >> I'd say DT overlays should be preferred solution here, not another >> connector binding. > >Overlays are a way to apply a device tree dynamically. It's orthogonal >to the binding. > >Maxime > >-- >Maxime Ripard, Bootlin >Embedded Linux and Kernel engineering >https://bootlin.com -- 使用 K-9 Mail 发送自我的Android设备。
[PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6,1
On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is currently
always used by nouveau) fails, but the BIOS declares 2 HWSQ entries and
entry 1 works.
Add a quirk to use HWSQ entry 1.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index e8c445eb11004..2691d0e0cf9f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct
drm_device *dev,
if (!hwsq_offset)
return 0;
+#ifdef __powerpc__
+ /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
+ if (of_machine_is_compatible("PowerBook6,1"))
+ return load_nv17_hwsq_ucode_entry(dev, bios,
+ hwsq_offset + sz, 1);
+#endif
+
/* always use entry 0? */
return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset + sz, 0);
}
--
2.30.2
Re: [PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6,1
在 2022-02-14星期一的 11:07 -0500，Ilia Mirkin写道：
> I'm not saying this is wrong, but could you file a bug at
> gitlab.freedesktop.org/drm/nouveau/-/issues and include the VBIOS
> (/sys/kernel/debug/dri/0/vbios.rom)? That would make it easier to
> review the full situation.
Created at https://gitlab.freedesktop.org/drm/nouveau/-/issues/158 .
>
> On Mon, Feb 14, 2022 at 11:03 AM Icenowy Zheng wrote:
> >
> > On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is
> > currently
> > always used by nouveau) fails, but the BIOS declares 2 HWSQ entries
> > and
> > entry 1 works.
> >
> > Add a quirk to use HWSQ entry 1.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > index e8c445eb11004..2691d0e0cf9f1 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > @@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct
> > drm_device *dev,
> > if (!hwsq_offset)
> > return 0;
> >
> > +#ifdef __powerpc__
> > + /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
> > + if (of_machine_is_compatible("PowerBook6,1"))
> > + return load_nv17_hwsq_ucode_entry(dev, bios,
> > + hwsq_offset + sz,
> > 1);
> > +#endif
> > +
> > /* always use entry 0? */
> > return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset +
> > sz, 0);
> > }
> > --
> > 2.30.2
> >
Re: [PATCH] drm/sun4i: mixer: fix scanline for V3s and D1
在 2022-05-22星期日的 10:36 +0200，Jernej Škrabec写道：
> Hi!
>
> Dne sobota, 21. maj 2022 ob 15:34:43 CEST je Genfu Pan napisal(a):
> > Accrording the SDK from Allwinner, the scanline value of yuv and
> > rgb for
> > V3s are both 1024.
>
> s/scanline value/scanline length/
>
> Which SDK? All SDKs that I have or found on internet don't mention
> YUV nor RGB
> scanline limit. That doesn't mean there is none, I'm just unable to
> verify
> your claim. Did you test this by yourself? Also, please make YUV
> scanline
> change separate patch with fixes tag.
BTW I think chip manuals all say that the chip supports NxN resolution
in DE2 chapter, e.g. the V3 datasheet says DE2 "Output size up to
1024x1024".
However there's no information about D1's second mixer.
>
> > The is also the same for mixer 1 of D1. Currently the
> > scanline value of rgb is hardcoded to 2048 for all SOCs.
> >
> > Change the scanline_yuv property of V3s to 1024. > Add the
> > scanline_rgb
> > property to the mixer config and replace the hardcoded value with
> > it before
> > scaling.
>
> I guess RGB scanline patch would also need fixes tag, since it fixes
> existing
> bug.
>
> >
> > Signed-off-by: Genfu Pan
> > ---
> > drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 -
> > drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
> > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 3 +--
> > 3 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 875a1156c..e64e08207
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -567,6 +567,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_a83t_mixer0_cfg = { .ccsc = CCSC_MIXER0_LAYOUT,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -575,6 +576,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_a83t_mixer1_cfg = { .ccsc = CCSC_MIXER1_LAYOUT,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -584,6 +586,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_h3_mixer0_cfg
> > = { .mod_rate = 43200,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -593,6 +596,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_r40_mixer0_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -602,6 +606,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_r40_mixer1_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -610,7 +615,8 @@ static const struct sun8i_mixer_cfg
> > sun8i_v3s_mixer_cfg
> > = { .vi_num = 2,
> > .ui_num = 1,
> > .scaler_mask = 0x3,
> > - .scanline_yuv = 2048,
> > + .scanline_yuv = 1024,
> > + .scanline_rgb = 1024,
> > .ccsc = CCSC_MIXER0_LAYOUT,
> > .mod_rate = 15000,
> > };
> > @@ -620,6 +626,7 @@ static const struct sun8i_mixer_cfg
> > sun20i_d1_mixer0_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -629,6 +636,7 @@ static const struct sun8i_mixer_cfg
> > sun20i_d1_mixer1_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x1,
> > .scanline_yuv = 1024,
> > + .scanline_rgb = 1024,
> > .ui_num = 0,
> > .vi_num = 1,
> > };
> > @@ -638,6 +646,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_a64_mixer0_cfg = { .mod_rate = 29700,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 4096,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -647,6 +656,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_a64_mixer1_cfg = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -657,6 +667,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_h6_mixer0_cfg
> > = { .mod_rate = 6,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 4096,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
Re: [Lima] [RFC v1 0/1] drm: lima: devfreq and cooling device support
于 2019年12月24日 GMT+08:00 下午7:28:41, Martin Blumenstingl 写到: >Hi Alyssa, > >On Mon, Dec 16, 2019 at 4:48 PM Alyssa Rosenzweig > wrote: >> >> If so much code is being duplicated over, I'm wondering if it makes >> sense for us to move some of the common devfreq code to core DRM >> helpers? >if you have any recommendation where to put it then please let me know >(I am not familiar with the DRM subsystem at all) > >my initial idea was that the devfreq logic needs the same information >that the scheduler needs (whether we're submitting something to be >executed, there was a timeout, ...). >however, looking at drivers/gpu/drm/scheduler/ this seems pretty >stand-alone so I'm not sure it should go there >also the Mali-4x0 GPUs have some "PMU" which *may* be used instead of It's optional. We cannot promise its existance on a given hardware, and I heard that at least on Allwinner H5 Mali PMU is broken. >polling the statistics internally >so this is where I realize that with my current knowledge I don't know >enough about lima, panfrost, DRM or the devfreq subsystem to get a >good idea where to put the code. > > >Martin >___ >lima mailing list >l...@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/lima -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > Hi Wens, > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng wrote: > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > This commit, although claimed as a refactor, in fact changed the > > formula. > > > > By expanding the original formula, we can find that the const 10 is > > not > > substracted, instead it's added to the value (because 10 is > > negative > > when calculating hsa, and hsa itself is negative when calculating > > hblk). > > This breaks the similar pattern to other formulas, so restoring the > > original formula is more proper. > > > > Signed-off-by: Icenowy Zheng > > --- > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > sun6i_dsi *dsi, > > (mode->hsync_start - mode->hdisplay) * > > Bpp - HFP_PACKET_OVERHEAD); > > > > /* > > -* The blanking is set using a sync event (4 bytes) > > -* and a blanking packet (4 bytes + payload + 2 > > -* bytes). Its minimal size is therefore 10 bytes. > > +* hblk seems to be the line + porches length. > > */ > > -#define HBLK_PACKET_OVERHEAD 10 > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > - (mode->htotal - (mode->hsync_end - mode- > > >hsync_start)) * Bpp - > > - HBLK_PACKET_OVERHEAD); > > + hblk = mode->htotal * Bpp - hsa; > > The original formula is correct according to BSP [1] and work with my > panels which I have tested before. May be the horizontal timings on > panels you have leads to negative value. Do you tested the same timing with BSP kernel? It's quite difficult to get a negative value here, because the value is quite big (includes mode->hdisplay * Bpp). Strangely, only change the formula here back makes the timing translated from FEX file works (tested on PineTab and PinePhone production ver). The translation rule is from [1]. So I still insist on the patch because it's needed by experiment. [1] http://linux-sunxi.org/LCD > > [1] > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道： > 在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > > Hi Wens, > > > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng > > wrote: > > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > > > This commit, although claimed as a refactor, in fact changed the > > > formula. > > > > > > By expanding the original formula, we can find that the const 10 > > > is > > > not > > > substracted, instead it's added to the value (because 10 is > > > negative > > > when calculating hsa, and hsa itself is negative when calculating > > > hblk). > > > This breaks the similar pattern to other formulas, so restoring > > > the > > > original formula is more proper. > > > > > > Signed-off-by: Icenowy Zheng > > > --- > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > > sun6i_dsi *dsi, > > > (mode->hsync_start - mode->hdisplay) * > > > Bpp - HFP_PACKET_OVERHEAD); > > > > > > /* > > > -* The blanking is set using a sync event (4 > > > bytes) > > > -* and a blanking packet (4 bytes + payload + 2 > > > -* bytes). Its minimal size is therefore 10 > > > bytes. > > > +* hblk seems to be the line + porches length. > > > */ > > > -#define HBLK_PACKET_OVERHEAD 10 > > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > > - (mode->htotal - (mode->hsync_end - > > > mode- > > > > hsync_start)) * Bpp - > > > - HBLK_PACKET_OVERHEAD); > > > + hblk = mode->htotal * Bpp - hsa; > > > > The original formula is correct according to BSP [1] and work with > > my > > panels which I have tested before. May be the horizontal timings on > > panels you have leads to negative value. > > Do you tested the same timing with BSP kernel? > > It's quite difficult to get a negative value here, because the value > is > quite big (includes mode->hdisplay * Bpp). By re-checking with the BSP source code, I found that the constant in the HFP formula is indeed wrong -- it should be 16, not 6. > > Strangely, only change the formula here back makes the timing > translated from FEX file works (tested on PineTab and PinePhone > production ver). The translation rule is from [1]. > > So I still insist on the patch because it's needed by experiment. > > [1] http://linux-sunxi.org/LCD > > > [1] > > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
[PATCH v2 0/3] drm/sun4i: dsi: misc fixes
This patchset contains several fixes to the sun6i_mipi_dsi driver. First, it's a rebased version of video start delay porch fix from Jagan Teki. The next patch fixes the overhead of HFP packet, according to the source code of BSP [1]. The final patch fixes DCS long write, which fixes initialization issue with a panel with ST7703 controller (XBD599 panel used by PinePhone). This seems to be a misread of [2]. (The formula in [2] is para_num+1, and the code of the sun6i_mipi_dsi driver uses tx_len, which is the length including the command; thus tx_len is equal to para_num+1, so it shouldn't be added with 1 for another time.) Icenowy Zheng (2): drm/sun4i: dsi: fix the overhead of the horizontal front porch drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet length Jagan Teki (1): drm/sun4i: dsi: Fix video start delay computation [1] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L920 [2] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L227 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) -- 2.21.0
[PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
From: Jagan Teki The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <---><><--><--> //| // | // |.. <- [hv]display -> <- [hv]sync_start > <- [hv]sync_end --> < [hv]total --> <- lcd_[xy] > <- lcd_[hv]spw -> <-- lcd_[hv]bp -> < lcd_[hv]t --> The DSI driver misinterpreted the vbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the vertical front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x84/0x98) [] (dump_stack) from [] (__warn+0xfc/0x114) [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x40/0x6c) [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [] (restore_fbdev_mode_atomic) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x54) [] (drm_fb_helper_set_par) from [] (fbcon_init+0x560/0x5ac) [] (fbcon_init) from [] (visual_init+0xbc/0x104) [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) [] (do_bind_con_driver) from [] (do_take_over_console+0x13c/0x1c4) [] (do_take_over_console) from [] (do_fbcon_takeover+0x74/0xcc) [] (do_fbcon_takeover) from [] (notifier_call_chain+0x44/0x84) [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x48/0x60) [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x18/0x20) [] (blocking_notifier_call_chain) from [] (register_framebuffer+0x1e0/0x2f8) [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) [] (drm_fbdev_client_hotplug) from [] (drm_fbdev_generic_setup+0x88/0x118) [] (drm_fbdev_generic_setup) from [] (sun4i_drv_bind+0x128/0x160) [] (sun4i_drv_bind) from [] (try_to_bring_up_master+0x164/0x1a0) [] (try_to_bring_up_master) from [] (__component_add+0x94/0x140) [] (__component_add) from [] (sun6i_dsi_probe+0x144/0x234) [] (sun6i_dsi_probe) from [] (platform_drv_probe+0x48/0x9c) [] (platform_drv_probe) from [] (really_probe+0x1dc/0x2c8) [] (really_probe) from [] (driver_probe_device+0x60/0x160) [] (driver_probe_device) from [] (bus_for_each_drv+0x74/0xb8) [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x420) [] (process_one_work) from [] (worker_thread+0x274/0x5a0) [] (worker_thread) from [] (kthread+0x11c/0x14c) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 9fc0: 9fe0: 0013 ---[ end trace 495200a78b24980e ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer Signed-off-by: Jagan Teki --- Th
[PATCH v2 3/3] drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet length
The packet length of DCS long write packet should not be added with 1
when constructing long write packet.
Fix this.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 8fe8051c34e6..c958ca9bae63 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -832,8 +832,8 @@ static u32 sun6i_dsi_dcs_build_pkt_hdr(struct sun6i_dsi
*dsi,
u32 pkt = msg->type;
if (msg->type == MIPI_DSI_DCS_LONG_WRITE) {
- pkt |= ((msg->tx_len + 1) & 0x) << 8;
- pkt |= (((msg->tx_len + 1) >> 8) & 0x) << 16;
+ pkt |= ((msg->tx_len) & 0x) << 8;
+ pkt |= (((msg->tx_len) >> 8) & 0x) << 16;
} else {
pkt |= (((u8 *)msg->tx_buf)[0] << 8);
if (msg->tx_len > 1)
--
2.21.0
[PATCH v2 2/3] drm/sun4i: dsi: fix the overhead of the horizontal front porch
The formula in the BSP kernel indicates that a 16-byte overhead is used when sending the HFP. However, this value is currently set to 6 in the sun6i_mipi_dsi driver, which makes some panels flashing. Fix this overhead value. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index b8a0d0501ca7..8fe8051c34e6 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -569,11 +569,12 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); /* -* The frontporch is set using a blanking packet (4 -* bytes + payload + 2 bytes). Its minimal size is -* therefore 6 bytes +* The frontporch is set using a sync event (4 bytes) +* and two blanking packets (each one is 4 bytes + +* payload + 2 bytes). Its minimal size is therefore +* 16 bytes */ -#define HFP_PACKET_OVERHEAD6 +#define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); -- 2.21.0
Re: [PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
于 2019年10月7日 GMT+08:00 下午7:51:48, Maxime Ripard 写到: >On Mon, Oct 07, 2019 at 12:03:00AM +0800, Icenowy Zheng wrote: >> From: Jagan Teki >> >> The LCD timing definitions between Linux DRM vs Allwinner are >different, >> below diagram shows this clear differences. >> >>Active Front Sync Back >>Region Porch >Porch >> ><---><><--><--> >> //| >> // | >> // |.. > >> >> <- [hv]display -> >> <- [hv]sync_start > >> <- [hv]sync_end --> >> < [hv]total >--> >> >> <- lcd_[xy] > <- lcd_[hv]spw -> >><-- lcd_[hv]bp -> >> < lcd_[hv]t >--> >> >> The DSI driver misinterpreted the vbp term from the BSP code to refer >> only to the backporch, when in fact it was backporch + sync. Thus the >> driver incorrectly used the vertical front porch plus sync in its >> calculation of the DRQ set bit value, when it should not have >included >> the sync timing. >> >> Including additional sync timings leads to flip_done timed out as: >> >> WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 >> [CRTC:46:crtc-0] vblank wait timed out >> Modules linked in: >> CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted >5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 >> Hardware name: Allwinner sun8i Family >> Workqueue: events deferred_probe_work_func >> [] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >> [] (show_stack) from [] (dump_stack+0x84/0x98) >> [] (dump_stack) from [] (__warn+0xfc/0x114) >> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) >> [] (warn_slowpath_fmt) from [] >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) >> [] (drm_atomic_helper_wait_for_vblanks.part.1) from >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) >> [] (drm_atomic_helper_commit_tail_rpm) from [] >(commit_tail+0x40/0x6c) >> [] (commit_tail) from [] >(drm_atomic_helper_commit+0xbc/0x128) >> [] (drm_atomic_helper_commit) from [] >(restore_fbdev_mode_atomic+0x1cc/0x1dc) >> [] (restore_fbdev_mode_atomic) from [] >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) >> [] (drm_fb_helper_restore_fbdev_mode_unlocked) from >[] (drm_fb_helper_set_par+0x30/0x54) >> [] (drm_fb_helper_set_par) from [] >(fbcon_init+0x560/0x5ac) >> [] (fbcon_init) from [] (visual_init+0xbc/0x104) >> [] (visual_init) from [] >(do_bind_con_driver+0x1b0/0x390) >> [] (do_bind_con_driver) from [] >(do_take_over_console+0x13c/0x1c4) >> [] (do_take_over_console) from [] >(do_fbcon_takeover+0x74/0xcc) >> [] (do_fbcon_takeover) from [] >(notifier_call_chain+0x44/0x84) >> [] (notifier_call_chain) from [] >(__blocking_notifier_call_chain+0x48/0x60) >> [] (__blocking_notifier_call_chain) from [] >(blocking_notifier_call_chain+0x18/0x20) >> [] (blocking_notifier_call_chain) from [] >(register_framebuffer+0x1e0/0x2f8) >> [] (register_framebuffer) from [] >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) >> [] (__drm_fb_helper_initial_config_and_unlock) from >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) >> [] (drm_fbdev_client_hotplug) from [] >(drm_fbdev_generic_setup+0x88/0x118) >> [] (drm_fbdev_generic_setup) from [] >(sun4i_drv_bind+0x128/0x160) >> [] (sun4i_drv_bind) from [] >(try_to_bring_up_master+0x164/0x1a0) >> [] (try_to_bring_up_master) from [] >(__component_add+0x94/0x140) >> [] (__component_add) from [] >(sun6i_dsi_probe+0x144/0x234) >> [] (sun6i_dsi_probe) from [] >(platform_drv_probe+0x48/0x9c) >> [] (platform_drv_probe) from [] >(really_probe+0x1dc/0x2c8) >> [] (really_probe) from [] >(driver_probe_device+0x60/0x160) >> [] (driver_probe_device) from [] >(bus_for_each_drv+0x74/0xb8) >> [] (bus_for_each_drv) from [] >(__device_attach+0xd0/0x13c) >> [] (__device_attach) from [] >(bus_probe_device+0x84/0x8c) >> [] (bus_probe_device) from [] >(deferred_probe_work_func+0x64/0x90) >> [] (deferred_probe_work_func) fro
Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>> Current code tries to store the link rate (in bps, which is a big
>> number) in a u8, which surely overflow. Then it's converted back to
>> bandwidth code (which is thus 0) and written to the chip.
>>
>> The code sometimes works because the chip will automatically fallback
>to
>> the lowest possible DP link rate (1.62Gbps) when get the invalid
>value.
>> However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps
>link,
>> it failed.
>>
>> As we had already read the link bandwidth as bandwidth code in
>earlier
>> code (to check whether it is supported), use it when setting
>bandwidth,
>> instead of converting it to link rate and then converting back.
>>
>> Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5")
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> index 56f55c53abfd..2dfa2fd2a23b 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> @@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct
>anx6345 *anx6345)
>> if (err)
>> return err;
>>
>> -dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
>> -dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
>> +dpcd[0] = dp_bw;
>
>Why do you make this assignment and not use dp_bw directly in the call?
Because the dpcd array is then written as a continous array
back to DPCD.
>
>> err = regmap_write(anx6345->map[I2C_IDX_DPTX],
>> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
> ^^
>> if (err)
>> --
>> 2.24.1
>
>BTW, my version is only a bit more verbose:
>
>https://patchwork.freedesktop.org/patch/354344/
>
> Torsten
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
Current code tries to store the link rate (in bps, which is a big
number) in a u8, which surely overflow. Then it's converted back to
bandwidth code (which is thus 0) and written to the chip.
The code sometimes works because the chip will automatically fallback to
the lowest possible DP link rate (1.62Gbps) when get the invalid value.
However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps link,
it failed.
As we had already read the link bandwidth as bandwidth code in earlier
code (to check whether it is supported), use it when setting bandwidth,
instead of converting it to link rate and then converting back.
Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 56f55c53abfd..2dfa2fd2a23b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct anx6345 *anx6345)
if (err)
return err;
- dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
- dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
+ dpcd[0] = dp_bw;
err = regmap_write(anx6345->map[I2C_IDX_DPTX],
SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
if (err)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
于 2020年2月26日 GMT+08:00 下午6:58:43, Thomas Zimmermann 写到:
>Hi Iceynow,
>
>Torsten asked me to merge your patch via drm-misc-next. I'd add the
>additional cc and fixes tags that Torsten listed. Are you OK with that?
I think this fixes a driver (and a board) available in 5.6.
Maybe it should enter fixes?
>
>Best regards
>Thomas
>
>Am 22.02.20 um 03:43 schrieb Icenowy Zheng:
>>
>>
>> 于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>>> On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>>>> Current code tries to store the link rate (in bps, which is a big
>>>> number) in a u8, which surely overflow. Then it's converted back to
>>>> bandwidth code (which is thus 0) and written to the chip.
>>>>
>>>> The code sometimes works because the chip will automatically
>fallback
>>> to
>>>> the lowest possible DP link rate (1.62Gbps) when get the invalid
>>> value.
>>>> However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps
>>> link,
>>>> it failed.
>>>>
>>>> As we had already read the link bandwidth as bandwidth code in
>>> earlier
>>>> code (to check whether it is supported), use it when setting
>>> bandwidth,
>>>> instead of converting it to link rate and then converting back.
>>>>
>>>> Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for
>v5.5")
>>>> Signed-off-by: Icenowy Zheng
>>>> ---
>>>> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> index 56f55c53abfd..2dfa2fd2a23b 100644
>>>> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> @@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct
>>> anx6345 *anx6345)
>>>>if (err)
>>>>return err;
>>>>
>>>> - dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
>>>> - dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
>>>> + dpcd[0] = dp_bw;
>>>
>>> Why do you make this assignment and not use dp_bw directly in the
>call?
>>
>> Because the dpcd array is then written as a continous array
>> back to DPCD.
>>
>>>
>>>>err = regmap_write(anx6345->map[I2C_IDX_DPTX],
>>>> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
>>> ^^
>>>>if (err)
>>>> --
>>>> 2.24.1
>>>
>>> BTW, my version is only a bit more verbose:
>>>
>>> https://patchwork.freedesktop.org/patch/354344/
>>>
>>> Torsten
>>
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
于 2020年3月3日 GMT+08:00 上午4:34:22, 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?
dotclock is correct and vrefresh is only a placeholder value.
>
>Cc: Icenowy Zheng
>Cc: Sam Ravnborg
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>index fddbfddf6566..8debee85f4ec 100644
>--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
>*panel)
> }
>
> static const struct drm_display_mode k101_im2ba02_default_mode = {
>- .clock = 7,
>+ .clock = 67286,
> .vrefresh = 60,
>
> .hdisplay = 800,
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
于 2020年3月6日 GMT+08:00 上午2:29:33, Vasily Khoruzhick 写到: >On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > wrote: >> >> Hi Vasily, > >CC: Icenowy and Ondrej >> >> Would you mind to check which firmware version is running the anx7688 >in >> PinePhone, I think should be easy to check with i2c-tools. > >Icenowy, Ondrej, can you guys please check anx7688 firmware version? At 0x2c, 0x80 is 0x01, 0x81 is 0x25 01.25, right? > >> Thanks in advance, >> Enric >> >> [snip] -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道： > Hi Ondrej, > > On 5/3/20 20:35, Ondřej Jirman wrote: > > Hi, > > > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: > > > On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > > > wrote: > > > > Hi Vasily, > > > > > > CC: Icenowy and Ondrej > > > > Would you mind to check which firmware version is running the > > > > anx7688 in > > > > PinePhone, I think should be easy to check with i2c-tools. > > > > > > Icenowy, Ondrej, can you guys please check anx7688 firmware > > > version? > > > > i2cget 0 0x28 0x00 w > > 0x > > > > i2cget 0 0x28 0x02 w > > 0x7688 > > > > i2cget 0 0x28 0x80 w > > 0x > > > > Can you check the value for 0x81 too? root@ice-pinephone [ ~ ] # i2cdump 0 0x28 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x28, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 00 05 05???v?.?? 10: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000... 20: 00 00 00 00 00 00 00 00 00 00 00 24 f2 e4 ff 00...$??.. 30: 06 40 00 04 94 11 20 ff ff 03 00 bf ff ff 10 01?@.??? ..?.?..?? 40: 72 a4 00 09 00 08 05 84 15 40 17 00 00 0a 00 e0r?.?.@?..?.? 50: 00 00 00 0a 10 00 e0 df ff ff 00 00 00 10 71 00...??.??.?q. 60: 10 10 04 29 2d 21 10 01 09 13 00 03 e8 13 88 00???)-!.. 70: 00 19 18 83 16 5c 11 00 ff 00 00 0d 04 38 42 07.\???8B? 80: 00 00 00 00 00 74 1b 19 44 08 75 00 00 00 00 00.t??D?u. 90: 01 02 00 00 00 00 03 00 ff 30 00 59 01 00 00 00???..0.Y?... a0: 00 ff fe ff ff 00 00 00 00 00 00 00 00 00 00 02..?? b0: 00 00 00 00 00 00 40 00 28 00 00 00 00 44 08 00..@.(D?. c0: 00 00 00 00 80 00 10 01 0a 10 18 00 00 fd 00 00?.?..?.. d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 50 10 08 50 00 02 00 70 00 00 30 10 0b 02 1c 01P??P.?.p..0? f0: 00 0b 07 00 94 11 7f 00 00 00 00 00 00 01 0e ff.??.???..??. root@ice-pinephone [ ~ ] # i2cdump 0 0x2c No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x2c, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 29 1f 88 76 00 ac 11 00 11 20 10 10 00 00 00 00)??v.??.? ?? 10: 03 00 ff 8f ff 7f 00 00 00 00 05 00 10 0a 0c 00?..?.??.???. 20: 00 00 00 00 99 06 c0 00 00 00 00 00 00 00 02 00???...?. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 80: 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00?%.. 90: 0f 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00??.. a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Thanks, > Enric > > > > regards, > > o. > > > > > > Thanks in advance, > > > > Enric > > > > > > > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b8e9ef79cab9..038a2180d34b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1102,6 +1102,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..62816b34de31
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+ description: regulator that supplies the VCC voltage
+ iovcc-supply:
+ description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+&dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <&backlight>;
+iovcc-supply = <®_dldo2>;
+vcc-supply = <®_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++
3 files changed, 377 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index da3b84602cdd..d648f40469c7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -413,6 +413,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 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 the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af1e2a3cc5fc..d9645f079e59 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,4 +44,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..68a5d8bb7f26
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-xingbangda-xbd599"
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
+ 0x00, 0x0
[PATCH 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&r_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <®_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -188,6 +221,10 @@ &r_pio {
*/
};
+&r_pwm {
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
于 2020年3月14日 GMT+08:00 下午4:00:00, Sam Ravnborg 写到:
>Hi Icenowy
>
>A few details in the following.
>
> Sam
>
>On Thu, Mar 12, 2020 at 12:33:27AM +0800, Icenowy Zheng wrote:
>> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
>> Xingbangda, which is used on PinePhone final assembled phones.
>>
>> Add support for it.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/panel/Kconfig | 9 +
>> drivers/gpu/drm/panel/Makefile| 1 +
>> .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367
>++
>> 3 files changed, 377 insertions(+)
>> create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
>>
>> +++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
>> @@ -0,0 +1,367 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Xingbangda XBD599 MIPI-DSI panel driver
>> + *
>> + * Copyright (C) 2019 Icenowy Zheng
>2020?
The work started at Mid 2019.
Is 2019-2020 okay?
>
>> + *
>> + * Based on panel-rocktech-jh057n00900.c, which is:
>> + * Copyright (C) Purism SPC 2019
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>Sort alphabetically.
>
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRV_NAME "panel-xingbangda-xbd599"
>No reason for this indirection, it is only used once
>
>> +
>> +/* Manufacturer specific Commands send via DSI */
>> +#define ST7703_CMD_ALL_PIXEL_OFF 0x22
>> +#define ST7703_CMD_ALL_PIXEL_ON 0x23
>> +#define ST7703_CMD_SETDISP 0xB2
>> +#define ST7703_CMD_SETRGBIF 0xB3
>> +#define ST7703_CMD_SETCYC0xB4
>> +#define ST7703_CMD_SETBGP0xB5
>> +#define ST7703_CMD_SETVCOM 0xB6
>> +#define ST7703_CMD_SETOTP0xB7
>> +#define ST7703_CMD_SETPOWER_EXT 0xB8
>> +#define ST7703_CMD_SETEXTC 0xB9
>> +#define ST7703_CMD_SETMIPI 0xBA
>> +#define ST7703_CMD_SETVDC0xBC
>> +#define ST7703_CMD_SETSCR0xC0
>> +#define ST7703_CMD_SETPOWER 0xC1
>> +#define ST7703_CMD_UNK_C60xC6
>> +#define ST7703_CMD_SETPANEL 0xCC
>> +#define ST7703_CMD_SETGAMMA 0xE0
>> +#define ST7703_CMD_SETEQ 0xE3
>> +#define ST7703_CMD_SETGIP1 0xE9
>> +#define ST7703_CMD_SETGIP2 0xEA
>> +
>> +static const char * const regulator_names[] = {
>> +"iovcc",
>> +"vcc",
>> +};
>> +
>> +struct xbd599 {
>> +struct device *dev;
>> +struct drm_panel panel;
>> +struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
>> +bool prepared;
>> +};
>> +
>> +static inline struct xbd599 *panel_to_xbd599(struct drm_panel
>*panel)
>> +{
>> +return container_of(panel, struct xbd599, panel);
>> +}
>> +
>> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do {\
>> +static const u8 d[] = { seq }; \
>> +int ret;\
>> +ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
>> +if (ret < 0)\
>> +return ret; \
>> +} while (0)
>> +
>> +static int xbd599_init_sequence(struct xbd599 *ctx)
>> +{
>> +struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +struct device *dev = ctx->dev;
>> +int ret;
>> +
>> +/*
>> + * Init sequence was supplied by the panel vendor.
>> + */
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
>> + 0xF1, 0x12, 0x83);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
>> + 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
>> + 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
>> + 0x00, 0x00, 0x37);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
>> + 0x25, 0x22, 0x20, 0x03);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
>> + 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
>> + 0x00, 0x00);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
>> + 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70,
>&g
[PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Example fix.
- Format fix.
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..b27bcf11198f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+description: regulator that supplies the VCC voltage
+ iovcc-supply:
+description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <&backlight>;
+iovcc-supply = <®_dldo2>;
+vcc-supply = <®_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- No changes in v2. drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- No changes in v2. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 23ca95bee298..0d9e966eff19 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1106,6 +1106,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 470 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Raised copyright info to 2020.
- Sort panel operation functions.
- Sort inclusion.
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++
3 files changed, 376 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..cf0c59015a44 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -433,6 +433,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 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 the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..c84ed5215984 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -46,4 +46,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..8d56b6579111
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02,
[PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&r_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <®_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <®_dldo2>;
+ vcc-supply = <®_ldo_io0>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -188,6 +221,10 @@ &r_pio {
*/
};
+&r_pwm {
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
在 2020-03-16星期一的 21:35 +0800，Icenowy Zheng写道：
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Add its device nodes.
>
> Signed-off-by: Icenowy Zheng
> ---
> No changes in v2.
>
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37
> +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index cefda145c3c9..96d9150423e0 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -16,6 +16,15 @@ aliases {
> serial0 = &uart0;
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&r_pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42
> 46 51 56 62 68 75 83 91 100>;
Should I drop the 0 here and replace it with 14?
I have heard community complaining about setting 0 to brightness make
the screen black.
(I think in this situation bl_power or blank the DSI panel can still
totally shut down the backlight).
> + default-brightness-level = <15>;
> + enable-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> + power-supply = <®_ldo_io0>;
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -84,6 +93,30 @@ &dai {
> status = "okay";
> };
>
> +&de {
> + status = "okay";
> +};
> +
> +&dphy {
> + status = "okay";
> +};
> +
> +&dsi {
> + vcc-dsi-supply = <®_dldo1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + panel@0 {
> + compatible = "xingbangda,xbd599";
> + reg = <0>;
> + reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> + iovcc-supply = <®_dldo2>;
> + vcc-supply = <®_ldo_io0>;
> + backlight = <&backlight>;
> + };
> +};
> +
> &ehci0 {
> status = "okay";
> };
> @@ -188,6 +221,10 @@ &r_pio {
>*/
> };
>
> +&r_pwm {
> + status = "okay";
> +};
> +
> &r_rsb {
> status = "okay";
>
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet
Add the device tree binding for Pine64's PineTab tablet, which uses Allwinner A64 SoC. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..159060b65c5d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -636,6 +636,11 @@ properties: - const: pine64,pinebook - const: allwinner,sun50i-a64 + - description: Pine64 PineTab +items: + - const: pine64,pinetab + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 3dab8150dae7..a6d53bbbe33d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -335,6 +335,8 @@ patternProperties: description: Fastrax Oy "^fcs,.*": description: Fairchild Semiconductor + "^feixin,.*": +description: Shenzhen Feixin Photoelectic Co., Ltd "^feiyang,.*": description: Shenzhen Fly Young Technology Co.,LTD. "^firefly,.*": -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] arm64: dts: allwinner: a64: add support for PineTab
PineTab is a 10.1" tablet by Pine64 with Allwinner A64 inside.
It includes the following peripherals:
USB:
- A microUSB Type-B port connected to the OTG-capable USB PHY of
Allwinner A64. The ID pin is connected to a GPIO of the A64 SoC, and the
Vbus is connected to the Vbus of AXP803 PMIC. These enables OTG
functionality on this port.
- A USB Type-A port is connected to the internal hub attached to the
non-OTG USB PHY of Allwinner A64.
- There are reserved pins for an external keyboard connected to the
internal hub.
Power:
- The microUSB port has its Vbus connected to AXP803, mentioned above.
- A DC jack (of a strange size, 2.5mm outer diameter) is connected to
the ACIN of AXP803.
- A Li-Polymer battery is connected to the battery pins of AXP803.
Storage:
- An tradition Pine64 eMMC slot is on the board, mounted with an eMMC
module by factory.
- An external microSD slot is hidden under a protect case.
Display:
- A MIPI-DSI LCD panel (800x1280) is connected to the DSI port of A64 SoC.
- A mini HDMI port.
Input:
- A touch panel attached to a Goodix GT9271 touch controller.
- Volume keys connected to the LRADC of the A64 SoC.
Camera:
- An OV5640 CMOS camera is at rear, connected to the CSI bus of A64 SoC.
- A GC2145 CMOS camera is at front, shares the same CSI bus with OV5640.
Audio:
- A headphone jack is conencted to the SoC's internal codec.
- A speaker connected is to the Line Out port of SoC's internal codec, via
an amplifier.
Misc:
- Debug UART is muxed with the headphone jack, with the switch next to
the microSD slot.
- A bosch BMA223 accelerometer is connected to the I2C bus of A64 SoC.
- Wi-Fi and Bluetooth are available via a RTL8723CS chip, similar to the
one in Pinebook.
This commit adds a basically usable device tree for it, implementing
most of the features mentioned above. HDMI is not supported now because
bad LCD-HDMI coexistence situation of mainline A64 display driver, and
the front camera currently lacks a driver and a facility to share the
bus with the rear one.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../boot/dts/allwinner/sun50i-a64-pinetab.dts | 461 ++
2 files changed, 462 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index cf4f78617c3f..6dad63881cd3 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
new file mode 100644
index ..1dfa3668636e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PineTab";
+ compatible = "pine64,pinetab", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &rtl8723cs;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <&vdd_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = <&pio 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Rear camera */
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&csi_mclk_pin>;
+ clocks = <&ccu CLK_CSI_MCLK>;
+ c
[PATCH 2/5] dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel.
Add device tree binding for it.
Signed-off-by: Icenowy Zheng
---
.../display/panel/feixin,k101-im2ba02.yaml| 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
new file mode 100644
index ..7176d14893ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feixin,k101-im2ba02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feixin K101 IM2BA02 10.1" MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: feixin,k101-im2ba02
+ reg: true
+ backlight: true
+ reset-gpios: true
+ avdd-supply:
+ description: regulator that supplies the AVDD voltage
+ dvdd-supply:
+ description: regulator that supplies the DVDD voltage
+ cvdd-supply:
+ description: regulator that supplies the CVDD voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - avdd-supply
+ - dvdd-supply
+ - cvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+&dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "feixin,k101-im2ba02";
+reg = <0>;
+avdd-supply = <®_dc1sw>;
+dvdd-supply = <®_dc1sw>;
+cvdd-supply = <®_ldo_io1>;
+reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <&backlight>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/panel: Add Feixin K101 IM2BA02 panel
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel.
Add a panel driver for it.
Signed-off-by: Icenowy Zheng
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 548 ++
4 files changed, 564 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 908399316455..ef7d13125344 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5218,6 +5218,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
+M: Icenowy Zheng
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+F: Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+
DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..4641ec804e5e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIXIN_K101_IM2BA02
+ tristate "Feixin K101 IM2BA02 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 the Feixin K101 IM2BA02
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_FEIYANG_FY07024DI26A30D
tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..442c17ccc62e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
new file mode 100644
index ..45a62bdabb3f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -0,0 +1,548 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define K101_IM2BA02_INIT_CMD_LEN 2
+
+struct k101_im2ba02 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct regulator*cvdd;
+ struct gpio_desc*reset;
+};
+
+static inline struct k101_im2ba02 *panel_to_k101_im2ba02(struct drm_panel
*panel)
+{
+ return container_of(panel, struct k101_im2ba02, panel);
+}
+
+struct k101_im2ba02_init_cmd {
+ u8 data[K101_IM2BA02_INIT_CMD_LEN];
+};
+
+static const struct k101_im2ba02_init_cmd k101_im2ba02_init_cmds[] = {
+ /* Switch to page 0 */
+ { .data = { 0xE0, 0x00 } },
+
+ /* Seems to be some password */
+ { .data = { 0xE1, 0x93} },
+ { .data = { 0xE2, 0x65 } },
+ { .data = { 0xE3, 0xF8 } },
+
+ /* Lane number, 0x02 - 3 lanes, 0x03 - 4 lanes */
+ { .data = { 0x80, 0x03 } },
+
+ /* Sequence control */
+ { .data = { 0x70, 0x02 } },
+ { .data = { 0x71, 0x23 } },
+ { .data = { 0x72, 0x06 } },
+
+ /* Switch to page 1 */
+ { .data = { 0xE0, 0x01 } },
+
+ /* Set VCOM */
+ { .data = { 0x00, 0x00 } },
+ { .data = { 0x01, 0x66 } },
+ /* Set VCOM_Reverse */
+ { .data = { 0x03, 0x00 } },
+ { .data = { 0x04, 0x25 } },
+
+ /* Set Gamma Power, VG[MS][PN] */
+ { .data = { 0x17, 0x00 } },
+ { .data = { 0x18, 0x6D } },
+ { .data = { 0x19, 0x00 } },
+ { .data = { 0x1A, 0x00 } },
+ { .data = { 0x1B, 0xBF } }, /* VGMN = -4.5V */
+ { .data = { 0x1C, 0x00 } },
+
+ /* Set Gate Power */
+ { .data = { 0x1F, 0x3E } }, /* VGH_R = 15V */
+ { .data = { 0x20, 0x28 } }, /* VGL_R = -11V */
+ { .data = { 0x21, 0x28 } }, /* VGL_R2 = -11V */
+ { .data = { 0x22, 0x0E } }, /* PA[6:4] = 0, PA[0] = 0 */
+
+ /* Set Panel */
+ { .data = { 0x37, 0x09 } }
[PATCH 0/5] Add support for Pine64 PineTab
This patchset tries to add support for the PineTab tablet from Pine64. As it uses a specific MIPI-DSI panel, the support of the panel should be introduced first, with its DT binding. Then a device tree is added. Thanks to the community's contributions these years, we now have most of the functionalities of the tablet available in this device tree. Icenowy Zheng (5): dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel drm/panel: Add Feixin K101 IM2BA02 panel dt-bindings: arm: sunxi: add binding for PineTab tablet arm64: dts: allwinner: a64: add support for PineTab .../devicetree/bindings/arm/sunxi.yaml| 5 + .../display/panel/feixin,k101-im2ba02.yaml| 54 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + arch/arm64/boot/dts/allwinner/Makefile| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 461 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 548 ++ 9 files changed, 1087 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/panel: Add Feixin K101 IM2BA02 panel
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel.
Add a panel driver for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Use regulator_bulk.
- Small code fixes.
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++
4 files changed, 542 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 98cf0b034f61..2ec9ae62478a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5251,6 +5251,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
+M: Icenowy Zheng
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+F: Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+
DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..4641ec804e5e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIXIN_K101_IM2BA02
+ tristate "Feixin K101 IM2BA02 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 the Feixin K101 IM2BA02
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_FEIYANG_FY07024DI26A30D
tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..442c17ccc62e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
new file mode 100644
index ..fddbfddf6566
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -0,0 +1,526 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define K101_IM2BA02_INIT_CMD_LEN 2
+
+static const char * const regulator_names[] = {
+ "dvdd",
+ "avdd",
+ "cvdd"
+};
+
+struct k101_im2ba02 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ struct gpio_desc*reset;
+};
+
+static inline struct k101_im2ba02 *panel_to_k101_im2ba02(struct drm_panel
*panel)
+{
+ return container_of(panel, struct k101_im2ba02, panel);
+}
+
+struct k101_im2ba02_init_cmd {
+ u8 data[K101_IM2BA02_INIT_CMD_LEN];
+};
+
+static const struct k101_im2ba02_init_cmd k101_im2ba02_init_cmds[] = {
+ /* Switch to page 0 */
+ { .data = { 0xE0, 0x00 } },
+
+ /* Seems to be some password */
+ { .data = { 0xE1, 0x93} },
+ { .data = { 0xE2, 0x65 } },
+ { .data = { 0xE3, 0xF8 } },
+
+ /* Lane number, 0x02 - 3 lanes, 0x03 - 4 lanes */
+ { .data = { 0x80, 0x03 } },
+
+ /* Sequence control */
+ { .data = { 0x70, 0x02 } },
+ { .data = { 0x71, 0x23 } },
+ { .data = { 0x72, 0x06 } },
+
+ /* Switch to page 1 */
+ { .data = { 0xE0, 0x01 } },
+
+ /* Set VCOM */
+ { .data = { 0x00, 0x00 } },
+ { .data = { 0x01, 0x66 } },
+ /* Set VCOM_Reverse */
+ { .data = { 0x03, 0x00 } },
+ { .data = { 0x04, 0x25 } },
+
+ /* Set Gamma Power, VG[MS][PN] */
+ { .data = { 0x17, 0x00 } },
+ { .data = { 0x18, 0x6D } },
+ { .data = { 0x19, 0x00 } },
+ { .data = { 0x1A, 0x00 } },
+ { .data = { 0x1B, 0xBF } }, /* VGMN = -4.5V */
+ { .data = { 0x1C, 0x00 } },
+
+ /* Set Gate Power */
+ { .data = { 0x1F, 0x3E } }, /* VGH_R = 15V */
+ { .data = { 0x20, 0x28 } }, /* VGL_R = -11V */
+ { .data = { 0x21, 0x28 } }, /* VGL_R2 = -
[PATCH v2 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by: Icenowy Zheng Acked-by: Sam Ravnborg Acked-by: Rob Herring --- Changes in v2: - Added ACKs from Sam and Rob. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 97c0a06b35cd..07d52254427b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -337,6 +337,8 @@ patternProperties: description: Fastrax Oy "^fcs,.*": description: Fairchild Semiconductor + "^feixin,.*": +description: Shenzhen Feixin Photoelectic Co., Ltd "^feiyang,.*": description: Shenzhen Fly Young Technology Co.,LTD. "^firefly,.*": -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm64: dts: allwinner: a64: add support for PineTab
PineTab is a 10.1" tablet by Pine64 with Allwinner A64 inside.
It includes the following peripherals:
USB:
- A microUSB Type-B port connected to the OTG-capable USB PHY of
Allwinner A64. The ID pin is connected to a GPIO of the A64 SoC, and the
Vbus is connected to the Vbus of AXP803 PMIC. These enables OTG
functionality on this port.
- A USB Type-A port is connected to the internal hub attached to the
non-OTG USB PHY of Allwinner A64.
- There are reserved pins for an external keyboard connected to the
internal hub.
Power:
- The microUSB port has its Vbus connected to AXP803, mentioned above.
- A DC jack (of a strange size, 2.5mm outer diameter) is connected to
the ACIN of AXP803.
- A Li-Polymer battery is connected to the battery pins of AXP803.
Storage:
- An tradition Pine64 eMMC slot is on the board, mounted with an eMMC
module by factory.
- An external microSD slot is hidden under a protect case.
Display:
- A MIPI-DSI LCD panel (800x1280) is connected to the DSI port of A64 SoC.
- A mini HDMI port.
Input:
- A touch panel attached to a Goodix GT9271 touch controller.
- Volume keys connected to the LRADC of the A64 SoC.
Camera:
- An OV5640 CMOS camera is at rear, connected to the CSI bus of A64 SoC.
- A GC2145 CMOS camera is at front, shares the same CSI bus with OV5640.
Audio:
- A headphone jack is conencted to the SoC's internal codec.
- A speaker connected is to the Line Out port of SoC's internal codec, via
an amplifier.
Misc:
- Debug UART is muxed with the headphone jack, with the switch next to
the microSD slot.
- A bosch BMA223 accelerometer is connected to the I2C bus of A64 SoC.
- Wi-Fi and Bluetooth are available via a RTL8723CS chip, similar to the
one in Pinebook.
This commit adds a basically usable device tree for it, implementing
most of the features mentioned above. HDMI is not supported now because
bad LCD-HDMI coexistence situation of mainline A64 display driver, the
front camera currently lacks a driver and a facility to share the bus
with the rear one, and the accelerometer currently lacks a DT binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Remove I2C pinmuxes.
- Dropped binding-less accelerometer.
- Used exponent curve for backlight.
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 ++
2 files changed, 461 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index cf4f78617c3f..6dad63881cd3 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
new file mode 100644
index ..c76c94855f43
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -0,0 +1,460 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+#include "sun50i-a64-cpu-opp.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PineTab";
+ compatible = "pine64,pinetab", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &rtl8723cs;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <&vdd_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = <&pio 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = <&pio 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Rear camera */
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
[PATCH v2 0/5] Add support for Pine64 PineTab
This patchset tries to add support for the PineTab tablet from Pine64. As it uses a specific MIPI-DSI panel, the support of the panel should be introduced first, with its DT binding. Then a device tree is added. Compared to v1 of the patchset, the accelerometer support is temporarily removed because a DT binding is lacked (although a proper driver exists). Icenowy Zheng (5): dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel drm/panel: Add Feixin K101 IM2BA02 panel dt-bindings: arm: sunxi: add binding for PineTab tablet arm64: dts: allwinner: a64: add support for PineTab .../devicetree/bindings/arm/sunxi.yaml| 5 + .../display/panel/feixin,k101-im2ba02.yaml| 55 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + arch/arm64/boot/dts/allwinner/Makefile| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++ 9 files changed, 1065 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel.
Add device tree binding for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Set backlight property to optional. (Technically this panel requires
backlight, but theortically it can be not adjustable.)
- Tweaked the example to pass schema check.
.../display/panel/feixin,k101-im2ba02.yaml| 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
new file mode 100644
index ..be1ecce9c3c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feixin,k101-im2ba02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feixin K101 IM2BA02 10.1" MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: feixin,k101-im2ba02
+ reg: true
+ backlight: true
+ reset-gpios: true
+ avdd-supply:
+ description: regulator that supplies the AVDD voltage
+ dvdd-supply:
+ description: regulator that supplies the DVDD voltage
+ cvdd-supply:
+ description: regulator that supplies the CVDD voltage
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - cvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "feixin,k101-im2ba02";
+reg = <0>;
+avdd-supply = <®_dc1sw>;
+dvdd-supply = <®_dc1sw>;
+cvdd-supply = <®_ldo_io1>;
+reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <&backlight>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet
Add the device tree binding for Pine64's PineTab tablet, which uses Allwinner A64 SoC. Signed-off-by: Icenowy Zheng Reviewed-by: Rob Herring --- Changes in v2: - Added Review tag by Rob. Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..159060b65c5d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -636,6 +636,11 @@ properties: - const: pine64,pinebook - const: allwinner,sun50i-a64 + - description: Pine64 PineTab +items: + - const: pine64,pinetab + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/lima: allow to retry when allocating memory for BO
Currently, when allocating the memory for BO by Mesa, the lima kernel
driver set only GFP_DMA32 flag; and this allocation may fail when the
memory is relatively adequate, thus retrying is needed.
Add the GFP flags for retrying memory allocation.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/lima/lima_object.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_object.c
b/drivers/gpu/drm/lima/lima_object.c
index 87123b1d083c..1389aa1b948b 100644
--- a/drivers/gpu/drm/lima/lima_object.c
+++ b/drivers/gpu/drm/lima/lima_object.c
@@ -91,7 +91,9 @@ struct lima_bo *lima_bo_create(struct lima_device *dev, u32
size,
goto err_out;
}
} else {
- mapping_set_gfp_mask(bo->gem.filp->f_mapping, GFP_DMA32);
+ mapping_set_gfp_mask(bo->gem.filp->f_mapping,
+GFP_DMA32 | __GFP_RETRY_MAYFAIL |
+__GFP_NOWARN);
bo->pages = drm_gem_get_pages(&bo->gem);
if (IS_ERR(bo->pages)) {
ret = ERR_CAST(bo->pages);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] Revert "drm/sun4i: dsi: Change the start delay calculation"
This reverts commit da676c6aa6413d59ab0a80c97bbc273025e640b2.
The original commit adds a start parameter to the calculation of the
start delay according to some old BSP versions from Allwinner. However,
there're two ways to add this delay -- add it in DSI controller or add
it in the TCON. Add it in both controllers won't work.
The code before this commit is picked from new versions of BSP kernel,
which has a comment for the 1 that says "put start_delay to tcon". By
checking the sun4i_tcon0_mode_set_cpu() in sun4i_tcon driver, it has
already added this delay, so we shouldn't repeat to add the delay in DSI
controller, otherwise the timing won't match.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 1636344ba9ec..c86e11631ebc 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -365,8 +365,7 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
- u16 start = clamp(mode->vtotal - mode->vdisplay - 10, 8, 100);
- u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
+ u16 delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
if (delay > mode->vtotal)
delay = delay % mode->vtotal;
--
2.21.0
[PATCH 2/3] drm/sun4i: dsi: fix DRQ calculation
According to the BSP source code, when calculating the magic DRQ value
outside burst mode, a formula of "lcd_ht - lcd_x - lcd_hbp", which is
interpreted as right margin (HFP value). However, currently the
sun6i_mipi_dsi driver code calculates it wrongly as HFP + sync length,
which lead to timing error.
Fix the DRQ calculation by change it to use HFP.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index c86e11631ebc..2d3e822a7739 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -436,9 +436,9 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
SUN6I_DSI_BURST_LINE_SYNC_POINT(SUN6I_DSI_SYNC_POINT));
val = SUN6I_DSI_TCON_DRQ_ENABLE_MODE;
- } else if ((mode->hsync_end - mode->hdisplay) > 20) {
+ } else if ((mode->hsync_start - mode->hdisplay) > 20) {
/* Maagic */
- u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
+ u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
drq *= mipi_dsi_pixel_format_to_bpp(device->format);
drq /= 32;
--
2.21.0
[PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. This commit, although claimed as a refactor, in fact changed the formula. By expanding the original formula, we can find that the const 10 is not substracted, instead it's added to the value (because 10 is negative when calculating hsa, and hsa itself is negative when calculating hblk). This breaks the similar pattern to other formulas, so restoring the original formula is more proper. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 2d3e822a7739..cb5fd19c0d0d 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); /* -* The blanking is set using a sync event (4 bytes) -* and a blanking packet (4 bytes + payload + 2 -* bytes). Its minimal size is therefore 10 bytes. +* hblk seems to be the line + porches length. */ -#define HBLK_PACKET_OVERHEAD 10 - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + hblk = mode->htotal * Bpp - hsa; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.21.0
[PATCH 0/3] drm/sun4i: dsi: misc timing fixes
This patchset fixes some portion of timing calculation in sun6i_mipi_dsi driver according to the BSP driver. Two of the patches are reverting, one is fixing some misread of the BSP source code, another is fixing a wrong refactor that actually breaks the formula. The other non-reverting patch is fixing a porch error which is usually seen in the original driver commit. Most of porch errors are then fixed, but this one gets ignored. By applying these patches, several DSI panels are tested to be driven properly by the timing provided by the vendor, including the LCD panel of PinePhone "Don't Be Evil" DevKit, the final PinePhone panel and the panel on PineTab. Without these patches they need dirty timing hacks to work. Icenowy Zheng (3): Revert "drm/sun4i: dsi: Change the start delay calculation" drm/sun4i: dsi: fix DRQ calculation Revert "drm/sun4i: dsi: Rework a bit the hblk calculation" drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) -- 2.21.0
Re: [PATCH 0/3] drm/sun4i: dsi: misc timing fixes
在 2019-10-02三的 12:36 +0200，Maxime Ripard写道： > Hi, > > On Tue, Oct 01, 2019 at 04:02:50PM +0800, Icenowy Zheng wrote: > > This patchset fixes some portion of timing calculation in > > sun6i_mipi_dsi > > driver according to the BSP driver. > > > > Two of the patches are reverting, one is fixing some misread of the > > BSP > > source code, another is fixing a wrong refactor that actually > > breaks the > > formula. > > > > The other non-reverting patch is fixing a porch error which is > > usually > > seen in the original driver commit. Most of porch errors are then > > fixed, > > but this one gets ignored. > > > > By applying these patches, several DSI panels are tested to be > > driven > > properly by the timing provided by the vendor, including the LCD > > panel > > of PinePhone "Don't Be Evil" DevKit, the final PinePhone panel and > > the > > panel on PineTab. Without these patches they need dirty timing > > hacks to > > work. > > Thanks for going after that issue. Can you provide references to the > BSP on the various patches? For patch 1: [1] for setting delay 1 in DSI controller, [2] for setting real delay in TCON controller. For patch 2: [3] Patch 3 is reverting a breaking change, so I didn't check it in the BSP. It can be verified by mathmatical calculation. [1] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L730 [2] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_lcd.c#L369 [3] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L780 > > Ideally, having the panel drivers, and the panel datasheet would > help. > > Thanks! > Maxime > > PS: where can we get one of those devices?
Re: [PATCH v11 1/7] drm/sun4i: dsi: Fix TCON DRQ set bits
于 2019年10月3日 GMT+08:00 下午2:45:21, Jagan Teki 写到: >The LCD timing definitions between Linux DRM vs Allwinner are >different, >below diagram shows this clear differences. > > Active Front Sync Back > Region Porch Porch ><---><><--><--> > //| > // | >// |.. > > ><- [hv]display -> ><- [hv]sync_start > ><- [hv]sync_end --> >< [hv]total >--> > ><- lcd_[xy] ><- lcd_[hv]spw -> > <-- lcd_[hv]bp -> >< lcd_[hv]t >--> > >The DSI driver misinterpreted the hbp term from the BSP code to refer >only to the backporch, when in fact it was backporch + sync. Thus the >driver incorrectly used the horizontal front porch plus sync in its >calculation of the DRQ set bit value, when it should not have included >the sync timing. > >Including additional sync timings leads to flip_done timed out as: I don't think attaching this error infomation is useful at all. It's just timing mismatch. > >WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 >[CRTC:46:crtc-0] vblank wait timed out >Modules linked in: >CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted >5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 >Hardware name: Allwinner sun8i Family >Workqueue: events deferred_probe_work_func >[] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >[] (show_stack) from [] (dump_stack+0x84/0x98) >[] (dump_stack) from [] (__warn+0xfc/0x114) >[] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) >[] (warn_slowpath_fmt) from [] >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) >[] (drm_atomic_helper_wait_for_vblanks.part.1) from >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) >[] (drm_atomic_helper_commit_tail_rpm) from [] >(commit_tail+0x40/0x6c) >[] (commit_tail) from [] >(drm_atomic_helper_commit+0xbc/0x128) >[] (drm_atomic_helper_commit) from [] >(restore_fbdev_mode_atomic+0x1cc/0x1dc) >[] (restore_fbdev_mode_atomic) from [] >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) >[] (drm_fb_helper_restore_fbdev_mode_unlocked) from >[] (drm_fb_helper_set_par+0x30/0x54) >[] (drm_fb_helper_set_par) from [] >(fbcon_init+0x560/0x5ac) >[] (fbcon_init) from [] (visual_init+0xbc/0x104) >[] (visual_init) from [] >(do_bind_con_driver+0x1b0/0x390) >[] (do_bind_con_driver) from [] >(do_take_over_console+0x13c/0x1c4) >[] (do_take_over_console) from [] >(do_fbcon_takeover+0x74/0xcc) >[] (do_fbcon_takeover) from [] >(notifier_call_chain+0x44/0x84) >[] (notifier_call_chain) from [] >(__blocking_notifier_call_chain+0x48/0x60) >[] (__blocking_notifier_call_chain) from [] >(blocking_notifier_call_chain+0x18/0x20) >[] (blocking_notifier_call_chain) from [] >(register_framebuffer+0x1e0/0x2f8) >[] (register_framebuffer) from [] >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) >[] (__drm_fb_helper_initial_config_and_unlock) from >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) >[] (drm_fbdev_client_hotplug) from [] >(drm_fbdev_generic_setup+0x88/0x118) >[] (drm_fbdev_generic_setup) from [] >(sun4i_drv_bind+0x128/0x160) >[] (sun4i_drv_bind) from [] >(try_to_bring_up_master+0x164/0x1a0) >[] (try_to_bring_up_master) from [] >(__component_add+0x94/0x140) >[] (__component_add) from [] >(sun6i_dsi_probe+0x144/0x234) >[] (sun6i_dsi_probe) from [] >(platform_drv_probe+0x48/0x9c) >[] (platform_drv_probe) from [] >(really_probe+0x1dc/0x2c8) >[] (really_probe) from [] >(driver_probe_device+0x60/0x160) >[] (driver_probe_device) from [] >(bus_for_each_drv+0x74/0xb8) >[] (bus_for_each_drv) from [] >(__device_attach+0xd0/0x13c) >[] (__device_attach) from [] >(bus_probe_device+0x84/0x8c) >[] (bus_probe_device) from [] >(deferred_probe_work_func+0x64/0x90) >[] (deferred_probe_work_func) from [] >(process_one_work+0x204/0x420) >[] (process_one_work) from [] >(worker_thread+0x274/0x5a0) >[] (worker_thread) from [] (kthread+0x11c/0x14c) >[] (kthread) from [] (ret_from_fork+0x14/0x2c) >Exception stack(0xde539fb0 to 0xde539ff8) >9fa0: > >9fc0: > >9fe0: 0013 >---[ end trace b57eb1e5c64c6b8b ]--- >random: fast init done >[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] >flip_done timed out >[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* >[CONNECTOR:48:DSI-1] flip_done timed out >[drm:drm_atomic_helper_wait_f
Re: [PATCH v11 2/7] drm/sun4i: dsi: Update start value in video start delay
于 2019年10月3日 GMT+08:00 下午2:45:22, Jagan Teki 写到:
>start value in video start delay was changed in
>commit da676c6aa641 ("drm/sun4i: dsi: Change the start delay
>calculation")
>to match the legacy BSP driver [1].
>
>So, using this existing start delay computation gives the wrong
>start delay value for the "bananapi,s070wv20-ct16" panel. Due to
>this the panel trigger below flip_done timed out as during kernel
>bootup:
>
>WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429
>drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0
> [CRTC:46:crtc-0] vblank wait timed out
> Modules linked in:
>CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW
>5.1.0-next-20190514-00025-gf928bc7cc146 #15
> Hardware name: Allwinner sun8i Family
> Workqueue: events deferred_probe_work_func
>[] (unwind_backtrace) from []
>(show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0x98)
> [] (dump_stack) from [] (__warn+0xfc/0x114)
> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68)
>[] (warn_slowpath_fmt) from []
>(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0)
>[] (drm_atomic_helper_wait_for_vblanks.part.1) from
>[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c)
>[] (drm_atomic_helper_commit_tail_rpm) from []
>(commit_tail+0x40/0x6c)
>[] (commit_tail) from []
>(drm_atomic_helper_commit+0xbc/0x128)
>[] (drm_atomic_helper_commit) from []
>(restore_fbdev_mode_atomic+0x1cc/0x1dc)
>[] (restore_fbdev_mode_atomic) from []
>(drm_fb_helper_pan_display+0xac/0x1d0)
>[] (drm_fb_helper_pan_display) from []
>(fb_pan_display+0xcc/0x134)
>[] (fb_pan_display) from []
>(bit_update_start+0x14/0x30)
>[] (bit_update_start) from []
>(fbcon_switch+0x3d8/0x4e0)
>[] (fbcon_switch) from []
>(redraw_screen+0x174/0x238)
>[] (redraw_screen) from []
>(fbcon_prepare_logo+0x3c4/0x400)
>[] (fbcon_prepare_logo) from []
>(fbcon_init+0x3c8/0x5ac)
> [] (fbcon_init) from [] (visual_init+0xbc/0x104)
>[] (visual_init) from []
>(do_bind_con_driver+0x1b0/0x390)
>[] (do_bind_con_driver) from []
>(do_take_over_console+0x13c/0x1c4)
>[] (do_take_over_console) from []
>(do_fbcon_takeover+0x74/0xcc)
>[] (do_fbcon_takeover) from []
>(notifier_call_chain+0x44/0x84)
>[] (notifier_call_chain) from []
>(__blocking_notifier_call_chain+0x48/0x60)
>[] (__blocking_notifier_call_chain) from []
>(blocking_notifier_call_chain+0x18/0x20)
>[] (blocking_notifier_call_chain) from []
>(register_framebuffer+0x1e0/0x2f8)
>[] (register_framebuffer) from []
>(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c)
>[] (__drm_fb_helper_initial_config_and_unlock) from
>[] (drm_fbdev_client_hotplug+0xe8/0x1b8)
>[] (drm_fbdev_client_hotplug) from []
>(drm_fbdev_generic_setup+0x88/0x118)
>[] (drm_fbdev_generic_setup) from []
>(sun4i_drv_bind+0x128/0x160)
>[] (sun4i_drv_bind) from []
>(try_to_bring_up_master+0x164/0x1a0)
>[] (try_to_bring_up_master) from []
>(__component_add+0x94/0x140)
>[] (__component_add) from []
>(sun6i_dsi_probe+0x144/0x234)
>[] (sun6i_dsi_probe) from []
>(platform_drv_probe+0x48/0x9c)
>[] (platform_drv_probe) from []
>(really_probe+0x1dc/0x2c8)
>[] (really_probe) from []
>(driver_probe_device+0x60/0x160)
>[] (driver_probe_device) from []
>(bus_for_each_drv+0x74/0xb8)
>[] (bus_for_each_drv) from []
>(__device_attach+0xd0/0x13c)
>[] (__device_attach) from []
>(bus_probe_device+0x84/0x8c)
>[] (bus_probe_device) from []
>(deferred_probe_work_func+0x64/0x90)
>[] (deferred_probe_work_func) from []
>(process_one_work+0x204/0x420)
>[] (process_one_work) from []
>(worker_thread+0x274/0x5a0)
> [] (worker_thread) from [] (kthread+0x11c/0x14c)
> [] (kthread) from [] (ret_from_fork+0x14/0x2c)
> Exception stack(0xde539fb0 to 0xde539ff8)
>9fa0:
>
>9fc0:
>
> 9fe0: 0013
> ---[ end trace 755e10f62b83f396 ]---
> Console: switching to colour frame buffer device 100x30
>[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0]
>flip_done timed out
>[drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
>[CONNECTOR:48:DSI-1] flip_done timed out
>[drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
>[PLANE:30:plane-0] flip_done timed out
>
>To fix this, adjust the start delay computation according to the
>new BSP code [2].
>
>Unfortunately we don't have any evidence or documentation for this
>reassignment to 1 in new bsp, but it is working with below mainline
>supported panels in A33, A64.
>- bananapi,s070wv20-ct16
>- feiyang,fy07024di26a30d
>- techstar,ts8550b
>
>So, use the start as per new bsp code since it is working in all
>the supported panels.
>
>[1]
>https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/legacy/disp/de_bsp/de/ebios/de_dsi.c#L682
>[2]
>https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/lowlevel_sun8iw5/de_dsi.c#L807
>
>Signed-off-by: Jagan Teki
>---
> drivers/gp
Re: [PATCH v11 4/7] dt-bindings: sun6i-dsi: Add VCC-DSI supply property
于 2019年10月3日 GMT+08:00 下午7:47:33, Maxime Ripard 写到: >On Thu, Oct 03, 2019 at 12:15:24PM +0530, Jagan Teki wrote: >> Allwinner MIPI DSI controllers are supplied with SoC DSI >> power rails via VCC-DSI pin. >> >> Some board still work without supplying this but give more >> faith on datasheet and hardware schematics and document this >> supply property in required property list. >> >> Reviewed-by: Rob Herring >> Tested-by: Merlijn Wajer >> Signed-off-by: Jagan Teki >> --- >> .../bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml | 3 >+++ >> 1 file changed, 3 insertions(+) >> >> diff --git >a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >> index 47950fced28d..9d4c25b104f6 100644 >> --- >a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >> +++ >b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml >> @@ -36,6 +36,9 @@ properties: >>resets: >> maxItems: 1 >> >> + vcc-dsi-supply: >> +description: VCC-DSI power supply of the DSI encoder >> + > >The driver treats it as mandatory, so I've added it to the binding, as >suggested by the commit log. No. The regulator_get function will return dummy regulator, rather than fail, if the regulator is not specified. > >Maxime -- 使用 K-9 Mail 发送自我的Android设备。
Re: [linux-sunxi] [PATCH 1/3] Revert "drm/sun4i: dsi: Change the start delay calculation"
于 2019年10月3日 GMT+08:00 下午9:19:16, Maxime Ripard 写到: >On Thu, Oct 03, 2019 at 12:38:43PM +0530, Jagan Teki wrote: >> On Tue, Oct 1, 2019 at 1:33 PM Icenowy Zheng wrote: >> > >> > This reverts commit da676c6aa6413d59ab0a80c97bbc273025e640b2. >> > >> > The original commit adds a start parameter to the calculation of >the >> > start delay according to some old BSP versions from Allwinner. >However, >> > there're two ways to add this delay -- add it in DSI controller or >add >> > it in the TCON. Add it in both controllers won't work. >> > >> > The code before this commit is picked from new versions of BSP >kernel, >> > which has a comment for the 1 that says "put start_delay to tcon". >By >> > checking the sun4i_tcon0_mode_set_cpu() in sun4i_tcon driver, it >has >> > already added this delay, so we shouldn't repeat to add the delay >in DSI >> > controller, otherwise the timing won't match. >> >> Thanks for this change. look like this is proper reason for adding + >> 1. also adding bsp code links here might help for future reference. >> >> Otherwise, >> >> Reviewed-by: Jagan Teki > >The commit log was better in this one. I ended up merging this one, >with your R-b. Please note that Jagan's v11 3/7 is still needed. > >Maxime -- 使用 K-9 Mail 发送自我的Android设备。
[PATCH] drm/rockchip: kick firmware-based framebuffer when initializing
Since U-Boot now supports EFI and FB passing via EFI GOP, when booting rockchip SoCs via EFI, a EFI FB is available. However, currently when re-initializing display pipeline, the EFI FB is not removed, lead to fbcon not working (because the EFI FB is no longer bound to the display pipeline although it's still /dev/fb0 and fbcon is bound to it). Add some code for removing firmware-based FB when initializing KMS of rockchipdrm. Tested on Pinebook Pro (RK3399) with U-Boot patchset for initializing eDP display applied. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 212bd87c0c4a..3905fce6ce0b 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -158,6 +158,9 @@ static int rockchip_drm_bind(struct device *dev) */ drm_dev->irq_enabled = true; + /* Remove early framebuffers (ie. efifb) */ + drm_fb_helper_remove_conflicting_framebuffers(NULL, "rockchipdrmfb", false); + ret = rockchip_drm_fbdev_init(drm_dev); if (ret) goto err_unbind_all; -- 2.30.2
Re: [PATCH] drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID
在 2023-06-14星期三的 14:31 -0700，Doug Anderson写道：
> Hi,
>
> On Wed, Jun 14, 2023 at 1:22 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 13/06/23 01:32, Douglas Anderson ha scritto:
> > > In order to read the EDID from an eDP panel, you not only need to
> > > power on the bridge chip itself but also the panel. In the ps8640
> > > driver, this was made to work by having the bridge chip manually
> > > power
> > > the panel on by calling pre_enable() on everything connectorward
> > > on
> > > the bridge chain. This worked OK, but...
> > >
> > > ...when trying to do the same thing on ti-sn65dsi86, feedback was
> > > that
> > > this wasn't a great idea. As a result, we designed the "DP AUX"
> > > bus. With the design we ended up with the panel driver itself was
> > > in
> > > charge of reading the EDID. The panel driver could power itself
> > > on and
> > > the bridge chip was able to power itself on because it
> > > implemented the
> > > DP AUX bus.
> > >
> > > Despite the fact that we came up with a new scheme, implemented
> > > in on
> > > ti-sn65dsi86, and even implemented it on parade-ps8640, we still
> > > kept
> > > the old code around. This was because the new scheme required a
> > > DT
> > > change. Previously the panel was a simple "platform_device" and
> > > in DT
> > > at the top level. With the new design the panel needs to be
> > > listed in
> > > DT under the DP controller node. The old code allowed us to
> > > properly
> > > fetch EDIDs with ps8640 with the old DTs.
> > >
> > > Unfortunately, the old code stopped working as of commit
> > > 102e80d1fa2c
> > > ("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs").
> > > There
> > > are cases at bootup where connector->state->state is NULL and the
> > > kernel crashed at:
> > > * drm_atomic_bridge_chain_pre_enable
> > > * drm_atomic_get_old_bridge_state
> > > * drm_atomic_get_old_private_obj_state
> > >
> > > A bit of digging was done to see if there was an easy fix but
> > > there
> > > was nothing obvious. Instead, the only device using ps8640 the
> > > "old"
> > > way had its DT updated so that the panel was no longer a simple
> > > "platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek:
> > > mt8173-elm: Move display to ps8640 auxiliary bus") and commit
> > > 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel
> > > model
> > > number in DT").
> > >
> > > Let's delete the old, crashing code so nobody gets tempted to
> > > copy it
> > > or figure out how it works (since it doesn't).
> > >
> > > NOTE: from a device tree "purist" point of view, we're supposed
> > > to
> > > keep old device trees working and this patch is technically
> > > "against
> > > policy". Reasons I'm still proposing it anyway:
> > > 1. Officially, old mt8173-elm device trees worked via the "little
> > > white lie" approach. The DT would list an
> > > arbitrary/representative
> > > panel that would be used for power sequencing. The mode
> > > information
> > > in the panel driver would then be ignored / overridden by the
> > > EDID
> > > reading code in ps8640. I don't feel too terrible breaking
> > > DTs that
> > > contained the wrong "compatible" string to begin with. NOTE
> > > that
> > > any old device trees that _didn't_ lie about their compatible
> > > will
> > > still work because the mode information will come from the
> > > hardcoded panels in panel-edp.
> > > 2. The only users of the old code were Chromebooks and
> > > Chromebooks
> > > don't bake their DTs into the BIOS (they are bundled with the
> > > kernel). Thus we don't need to worry about breaking someone
> > > using
> > > an old DT with a new kernel.
> > > 3. The old code was crashing anyway. If someone wants to fix the
> > > old
> > > code instead of deleting it then they have my blessing, but
> > > without
> > > a proper fix the old code isn't useful.
> > >
> > > I'll list this as "Fixing" the code that made the old code start
> > > failing. There's not lots of reason to bring this back any
> > > further
> > > than that.
> >
> > Hoping to see removal of non-aux EDID reading code from all drivers
> > that can
> > support aux-bus is exactly why I moved Elm to the proper... aux-
> > bus.. so...
> >
> > Yes! Let's go!
> >
> > >
> > > Fixes: 102e80d1fa2c ("drm/bridge: ps8640: Use atomic variants of
> > > drm_bridge_funcs")
> >
> > ...but this Fixes tag will cause this commit to be backported to
> > kernel versions
> > before my commit moving Elm to aux-bus, and break display on those.
> >
> > I would suggest to either find a different Fixes tag, or don't add
> > any, since
> > technically this is a deprecation commit. We could imply that the
> > old technique
> > is deprecated since kernel version X.Y and get away with it.
> >
> > Otherwise, if you want it backported *anyway*, the safest way would
> > be to Cc it
> > to stable and explicitly say which versions should it be backported
> > to.
>
> The problem is tha
Re: [PATCH 1/3] clk: sunxi-ng: add support for rate resetting notifier
在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> From: Icenowy Zheng
>
> In some situaitons, we will want a clock rate be kept while its
> parent
> can change, for example, to make dual-head work on A64, TCON0 clock
> needs to be kept for LCD display and its parent (or grandparent)
> PLL-Video0 need to be changed for HDMI display. (There's a quirk on
> A64
> that HDMI PHY can only use PLL-Video0, not PLL-Video1).
>
> Add a notifier helper to create such kind of rate keeping notifier by
> reset the rate after the parent changed.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/clk/sunxi-ng/ccu_common.c | 22 ++
> drivers/clk/sunxi-ng/ccu_common.h | 12
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-
> ng/ccu_common.c
> index 8d28a7a079d0..434fa46ad460 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.c
> +++ b/drivers/clk/sunxi-ng/ccu_common.c
> @@ -87,6 +87,28 @@ int ccu_pll_notifier_register(struct ccu_pll_nb
> *pll_nb)
> }
> EXPORT_SYMBOL_NS_GPL(ccu_pll_notifier_register, SUNXI_CCU);
>
> +static int ccu_rate_reset_notifier_cb(struct notifier_block *nb,
> + unsigned long event, void
> *data)
> +{
> + struct ccu_rate_reset_nb *rate_reset =
> to_ccu_rate_reset_nb(nb);
> +
> + if (event == PRE_RATE_CHANGE) {
> + rate_reset->saved_rate = clk_get_rate(rate_reset-
> >target_clk);
In fact I think we should have a better way to save the intended clock
rate ;-)
> + } else if (event == POST_RATE_CHANGE) {
> + clk_set_rate(rate_reset->target_clk, rate_reset-
> >saved_rate);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +int ccu_rate_reset_notifier_register(struct ccu_rate_reset_nb
> *rate_reset_nb)
> +{
> + rate_reset_nb->clk_nb.notifier_call =
> ccu_rate_reset_notifier_cb;
> +
> + return clk_notifier_register(rate_reset_nb->common->hw.clk,
> + &rate_reset_nb->clk_nb);
> +}
> +
> static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device
> *dev,
> struct device_node *node, void __iomem
> *reg,
> const struct sunxi_ccu_desc *desc)
> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-
> ng/ccu_common.h
> index fbf16c6b896d..6b0b05fae123 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.h
> +++ b/drivers/clk/sunxi-ng/ccu_common.h
> @@ -69,4 +69,16 @@ int devm_sunxi_ccu_probe(struct device *dev, void
> __iomem *reg,
> void of_sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
> const struct sunxi_ccu_desc *desc);
>
> +struct ccu_rate_reset_nb {
> + struct notifier_block clk_nb;
> + struct ccu_common *common;
> +
> + struct clk *target_clk;
> + unsigned long saved_rate;
> +};
> +
> +#define to_ccu_rate_reset_nb(_nb) container_of(_nb, struct
> ccu_rate_reset_nb, clk_nb)
> +
> +int ccu_rate_reset_notifier_register(struct ccu_rate_reset_nb
> *rate_reset_nb);
> +
> #endif /* _COMMON_H_ */
>
Re: [PATCH 2/3] clk: sunxi-ng: a64: keep tcon0 clock rate when pll-video0's rate changes
在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> From: Icenowy Zheng
>
> Notify TCON0 clock (and in consequence PLL-MIPI by
> CLK_SET_RATE_PARENT)
> to reset when PLL-Video0 changes (because of HDMI PHY clk which is a
> child of PLL-Video0 and has CLK_SET_RATE_PARENT set). In this way we
> can
> get clock tree to satisfy both pipelines.
Well for fixing one's patch that contains SoB, use the following
format:
Signed-off-by: A
[B: fixed something]
Signed-off-by: B
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> index ef567775fc95..93beedb0428e 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -943,6 +943,17 @@ static struct ccu_mux_nb sun50i_a64_cpu_nb = {
> .bypass_index = 1, /* index of 24 MHz oscillator */
> };
>
> +/*
> + * Since PLL-Video0 is an ancestor of both tcon0 and HDMI PYH, tcon0
> clock will
> + * conflict with HDMI PHY clock which is on another display
> pipeline.
> + *
> + * Therefore, a notifier is required to restore the rate of TCON0
> when the rate
> + * of PLL-Video0 changed.
> + */
> +static struct ccu_rate_reset_nb sun50i_a64_pll_video0_reset_tcon0_nb
> = {
> + .common = &pll_video0_clk.common,
> +};
> +
> static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> {
> void __iomem *reg;
> @@ -978,6 +989,10 @@ static int sun50i_a64_ccu_probe(struct
> platform_device *pdev)
> ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> &sun50i_a64_cpu_nb);
>
> + /* Reset the rate of TCON0 clock when PLL-VIDEO0 is changed
> */
> + sun50i_a64_pll_video0_reset_tcon0_nb.target_clk =
> tcon0_clk.common.hw.clk;
> + ccu_rate_reset_notifier_register(&sun50i_a64_pll_video0_reset
> _tcon0_nb);
> +
> return 0;
> }
>
>
Re: [PATCH 2/3] clk: sunxi-ng: a64: keep tcon0 clock rate when pll-video0's rate changes
在 2023-08-07星期一的 11:48 +0200，Frank Oltmanns写道：
>
> On 2023-08-07 at 17:43:52 +0800, Icenowy Zheng
> wrote:
> > 在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> > > From: Icenowy Zheng
> > >
> > > Notify TCON0 clock (and in consequence PLL-MIPI by
> > > CLK_SET_RATE_PARENT)
> > > to reset when PLL-Video0 changes (because of HDMI PHY clk which
> > > is a
> > > child of PLL-Video0 and has CLK_SET_RATE_PARENT set). In this way
> > > we
> > > can
> > > get clock tree to satisfy both pipelines.
> >
> > Well for fixing one's patch that contains SoB, use the following
> > format:
> >
> > Signed-off-by: A
> > [B: fixed something]
> > Signed-off-by: B
>
> Ah, okay. Will do. But I keep A in the "From: " line, correct?
Yes.
>
> Thanks,
> Frank
>
> > > ---
> > > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > index ef567775fc95..93beedb0428e 100644
> > > --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > @@ -943,6 +943,17 @@ static struct ccu_mux_nb sun50i_a64_cpu_nb =
> > > {
> > > .bypass_index = 1, /* index of 24 MHz oscillator */
> > > };
> > >
> > > +/*
> > > + * Since PLL-Video0 is an ancestor of both tcon0 and HDMI PYH,
> > > tcon0
> > > clock will
> > > + * conflict with HDMI PHY clock which is on another display
> > > pipeline.
> > > + *
> > > + * Therefore, a notifier is required to restore the rate of
> > > TCON0
> > > when the rate
> > > + * of PLL-Video0 changed.
> > > + */
> > > +static struct ccu_rate_reset_nb
> > > sun50i_a64_pll_video0_reset_tcon0_nb
> > > = {
> > > + .common = &pll_video0_clk.common,
> > > +};
> > > +
> > > static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> > > {
> > > void __iomem *reg;
> > > @@ -978,6 +989,10 @@ static int sun50i_a64_ccu_probe(struct
> > > platform_device *pdev)
> > > ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> > > &sun50i_a64_cpu_nb);
> > >
> > > + /* Reset the rate of TCON0 clock when PLL-VIDEO0 is
> > > changed
> > > */
> > > + sun50i_a64_pll_video0_reset_tcon0_nb.target_clk =
> > > tcon0_clk.common.hw.clk;
> > > + ccu_rate_reset_notifier_register(&sun50i_a64_pll_video0_r
> > > eset
> > > _tcon0_nb);
> > > +
> > > return 0;
> > > }
> > >
> > >
[PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
Currently a specific panel number is used in the Elm DTSI, which is
corresponded to a 12" panel. However, according to the official Chrome
OS devices document, Elm refers to Acer Chromebook R13, which, as the
name specifies, uses a 13.3" panel, which comes with EDID information.
As the kernel currently prioritizes the hardcoded timing parameters
matched with the panel number compatible, a wrong timing will be applied
to the 13.3" panel on Acer Chromebook R13, which leads to blank display.
Because the Elm DTSI is shared with Hana board, and Hana corresponds to
multiple devices from 11" to 14", a certain panel model number shouldn't
be present, and driving the panel according to its EDID information is
necessary.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index d452cab28c67..737737528eed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -285,7 +285,7 @@ ps8640_out: endpoint {
aux-bus {
panel: panel {
- compatible = "lg,lp120up1";
+ compatible = "edp-panel";
power-supply = <&panel_fixed_3v3>;
backlight = <&backlight>;
--
2.39.1
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-26星期五的 07:24 -0700，Doug Anderson写道：
> Hi,
>
> On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote:
> >
> > Currently a specific panel number is used in the Elm DTSI, which is
> > corresponded to a 12" panel. However, according to the official
> > Chrome
> > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > the
> > name specifies, uses a 13.3" panel, which comes with EDID
> > information.
> >
> > As the kernel currently prioritizes the hardcoded timing parameters
> > matched with the panel number compatible, a wrong timing will be
> > applied
> > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > display.
> >
> > Because the Elm DTSI is shared with Hana board, and Hana
> > corresponds to
> > multiple devices from 11" to 14", a certain panel model number
> > shouldn't
> > be present, and driving the panel according to its EDID information
> > is
> > necessary.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> We went through a bunch of back-and-forth here but in the end in the
> ChromeOS tree we have "edp-panel" as the "compatible" here in the
> ChromeOS 5.15 tree and this makes sense.
I only have Elm, so I am curious that do all Hana's only rely on panel
EDID to use different displays?
BTW The Chrome OS document say that Elm and Hana are both board based
on Oak baseboard, should the DTSI be renamed mt8173-oak.dtsi, and still
let mt8173-elm.dts include it and then set model information?
>
> Reviewed-by: Douglas Anderson
>
> ...in theory one would wish for a "Fixes" tag, but I think in
> previous
> discussions it was decided that it was too complicated. Hardcoding
> the
> other compatible string has always been technically wrong, but I
> guess
> it worked at some point in time. The more correct way (as you're
> doing
> here) needs the DP AUX bus support and the generic eDP panels, both
> of
> which are significantly newer than the elm dts. So I guess leaving no
> "Fixes" tag is OK, or perhaps you could do the somewhat weak:
Well I remembered when I was developing the support for Pine64
Pinebook, which is also an ARM64 laptop with an eDP panel (via a DPI-
eDP bridge, ANX6345). At first I didn't use any panel node in the DT,
and the kernel maintainers argued to the bridge that seems to be
connected to nothing (because DP is a discoverable port), and
fortunately 2 Pinebook SKUs (11.6" and 14") is finally reduced to one,
and it's then possible to hardcode a panel model in the Pinebook DT.
According to my memory, the need to specify the panel is to properly
handle eDP panel power up timing, because it's not a very standard
thing. (Well, in my memory, when I was testing that code, on a
(engineering sample) 14" Pinebook, the EDID timing overrided the
hardcoded 11.6" timing and it properly works, the 14" panel is 1366x768
but the 11.6" panel is 1920x1080.)
(BTW when I checked the DT of Olimex TERES-I, which uses the same DPI-
eDP bridge, it is still in the status of a dangling bridge, and of
course it works ;-) )
>
> Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display
> to ps8640 auxiliary bus")
Well this sound quite reasonable, as the kernel should have proper AUX
support at this commit.
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> Il 26/05/23 16:24, Doug Anderson ha scritto:
> > Hi,
> >
> > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > wrote:
> > >
> > > Currently a specific panel number is used in the Elm DTSI, which
> > > is
> > > corresponded to a 12" panel. However, according to the official
> > > Chrome
> > > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > > the
> > > name specifies, uses a 13.3" panel, which comes with EDID
> > > information.
> > >
> > > As the kernel currently prioritizes the hardcoded timing
> > > parameters
> > > matched with the panel number compatible, a wrong timing will be
> > > applied
> > > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > > display.
> > >
> > > Because the Elm DTSI is shared with Hana board, and Hana
> > > corresponds to
> > > multiple devices from 11" to 14", a certain panel model number
> > > shouldn't
> > > be present, and driving the panel according to its EDID
> > > information is
> > > necessary.
> > >
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > We went through a bunch of back-and-forth here but in the end in
> > the
> > ChromeOS tree we have "edp-panel" as the "compatible" here in the
> > ChromeOS 5.15 tree and this makes sense.
> >
> > Reviewed-by: Douglas Anderson
> >
> > ...in theory one would wish for a "Fixes" tag, but I think in
> > previous
> > discussions it was decided that it was too complicated. Hardcoding
> > the
> > other compatible string has always been technically wrong, but I
> > guess
> > it worked at some point in time. The more correct way (as you're
> > doing
> > here) needs the DP AUX bus support and the generic eDP panels, both
> > of
> > which are significantly newer than the elm dts. So I guess leaving
> > no
> > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
> >
> > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
> > display
> > to ps8640 auxiliary bus")
>
> I remember I didn't change the compatible to panel-edp because it
> didn't
> work at that time, but it does now... I'm not sure what actually
> fixed that
> and if the commit(s) was/were backported to that suggested point, so
> I
> would leave the Fixes tag out, as that may break older kernel.
Well at least I developed this patch on v6.3.
(In fact the same kernel config do not boot to system at all on
v6.0/v6.1 when I do make olddefconfig then build)
>
> Anyway, for this commit:
>
> Reviewed-by: AngeloGioacchino Del Regno
>
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-29星期一的 18:28 +0200，Matthias Brugger写道：
>
>
> On 29/05/2023 10:45, Icenowy Zheng wrote:
> > 在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> > > Il 26/05/23 16:24, Doug Anderson ha scritto:
> > > > Hi,
> > > >
> > > > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > > > wrote:
> > > > >
> > > > > Currently a specific panel number is used in the Elm DTSI,
> > > > > which
> > > > > is
> > > > > corresponded to a 12" panel. However, according to the
> > > > > official
> > > > > Chrome
> > > > > OS devices document, Elm refers to Acer Chromebook R13,
> > > > > which, as
> > > > > the
> > > > > name specifies, uses a 13.3" panel, which comes with EDID
> > > > > information.
> > > > >
> > > > > As the kernel currently prioritizes the hardcoded timing
> > > > > parameters
> > > > > matched with the panel number compatible, a wrong timing will
> > > > > be
> > > > > applied
> > > > > to the 13.3" panel on Acer Chromebook R13, which leads to
> > > > > blank
> > > > > display.
> > > > >
> > > > > Because the Elm DTSI is shared with Hana board, and Hana
> > > > > corresponds to
> > > > > multiple devices from 11" to 14", a certain panel model
> > > > > number
> > > > > shouldn't
> > > > > be present, and driving the panel according to its EDID
> > > > > information is
> > > > > necessary.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng
> > > > > ---
> > > > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > We went through a bunch of back-and-forth here but in the end
> > > > in
> > > > the
> > > > ChromeOS tree we have "edp-panel" as the "compatible" here in
> > > > the
> > > > ChromeOS 5.15 tree and this makes sense.
> > > >
> > > > Reviewed-by: Douglas Anderson
> > > >
> > > > ...in theory one would wish for a "Fixes" tag, but I think in
> > > > previous
> > > > discussions it was decided that it was too complicated.
> > > > Hardcoding
> > > > the
> > > > other compatible string has always been technically wrong, but
> > > > I
> > > > guess
> > > > it worked at some point in time. The more correct way (as
> > > > you're
> > > > doing
> > > > here) needs the DP AUX bus support and the generic eDP panels,
> > > > both
> > > > of
> > > > which are significantly newer than the elm dts. So I guess
> > > > leaving
> > > > no
> > > > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
> > > >
> > > > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
> > > > display
> > > > to ps8640 auxiliary bus")
> > >
> > > I remember I didn't change the compatible to panel-edp because it
> > > didn't
> > > work at that time, but it does now... I'm not sure what actually
> > > fixed that
> > > and if the commit(s) was/were backported to that suggested point,
> > > so
> > > I
> > > would leave the Fixes tag out, as that may break older kernel.
> >
> > Well at least I developed this patch on v6.3.
> >
> > (In fact the same kernel config do not boot to system at all on
> > v6.0/v6.1 when I do make olddefconfig then build)
> >
>
> I applied the patch without the fixes tag. Lets stay on the secure
> side to not
> break older kernels.
Well I think this patch is at least meaningful to get backported to
v6.3.
Should we cc sta...@vger.kernel.org ?
>
> Regards,
> Matthias
>
> > >
> > > Anyway, for this commit:
> > >
> > > Reviewed-by: AngeloGioacchino Del Regno
> > >
> >
[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
30.11.2016, 17:28, "Jean-Francois Moine" :
> On Wed, 30 Nov 2016 10:20:21 +0200
> Laurent Pinchart wrote:
>
>> Â > Well, I don't see what this connector can be.
>> Â > May you give me a DT example?
>>
>> Â Sure.
>>
>> Â arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>> Â Â Â Â Â Â Â Â Â /* HDMI encoder */
>>
>> Â Â Â Â Â Â Â Â Â hdmi at 39 {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â compatible = "adi,adv7511w";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â reg = <0x39>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â interrupt-parent = <&gpio3>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â adi,input-depth = <8>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â adi,input-colorspace = "rgb";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â adi,input-clock = "1x";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â adi,input-style = <1>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â adi,input-justification = "evenly";
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ports {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #address-cells = <1>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #size-cells = <0>;
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â port at 0 {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â reg = <0>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> adv7511_in: endpoint {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> Â Â Â remote-endpoint = <&du_out_rgb>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â port at 1 {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â reg = <1>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> adv7511_out: endpoint {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> Â Â Â remote-endpoint = <&hdmi_con>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â };
>>
>> Â Â Â Â Â Â Â Â Â /* HDMI connector */
>>
>> Â Â Â Â Â Â Â Â Â hdmi-out {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â compatible = "hdmi-connector";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â type = "a";
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â port {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â hdmi_con: endpoint {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> remote-endpoint = <&adv7511_out>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â };
>
> Hi Laurent,
>
> Sorry for I don't see the interest:
> - it is obvious that the HDMI connector is a 'hdmi-connector'!
Yes, it means the wire between the HDMI pins on the SoC and the connector ;-)
> - the physical connector type may be changed on any board by a soldering
> Â Â iron or a connector to connector cable.
I can always alter the devices on a board ;-)
But I should also alter the dt after altering the board.
> - what does the software do with the connector type?
> - why not to put the connector information in the HDMI device?
>
> And, if I follow you, the graph of ports could also be used to describe
> the way the various parts of the SoCs are powered, to describe the pin
> connections, to describe the USB connectors, to describe the board
> internal hubs and bridges...
>
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
30.11.2016, 18:44, "Jean-Francois Moine" :
> On Wed, 30 Nov 2016 11:52:25 +0200
> Laurent Pinchart wrote:
>
>>  Hi Jean-François,
>>
>> Â On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
>> Â > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
>> Â > >> Well, I don't see what this connector can be.
>> Â > >> May you give me a DT example?
>> Â > >
>> Â > > Sure.
>> Â > >
>> Â > > arch/arm/boot/dts/r8a7791-koelsch.dts
>> Â > >
>> Â > > /* HDMI encoder */
>
> Â Â Â Â Â Â Â Â [snip]
>> Â > > /* HDMI connector */
>> Â > >
>> Â > > hdmi-out {
>> Â > > compatible = "hdmi-connector";
>> Â > > type = "a";
>> Â > >
>> Â > > port {
>> Â > > hdmi_con: endpoint {
>> Â > > remote-endpoint = <&adv7511_out>;
>> Â > > };
>> Â > > };
>> Â > > };
>
> Â Â Â Â Â Â Â Â [snip]
>> Â > - what does the software do with the connector type?
>>
>> Â That's up to the software to decide, the DT bindings should describe the
>> Â hardware in the most accurate and usable way for the OS as possible. One
>> of my
>> Â longer term goals is to add connector drivers to handle DDC and HPD when
>> Â they're not handled by the encoder (they are in the above example).
>>
>> Â If the DDC was connected to a general-purpose I2C bus of the SoC, and the
>> HPD
>> Â to a GPIO, we would have
>>
>> Â Â Â Â Â Â Â Â Â hdmi-out {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â compatible = "hdmi-connector";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â type = "a";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â /* I2C bus and GPIO references are made up
>> for the example */
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ddc-i2c-bus = <&i2c4>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â port {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â hdmi_con: endpoint {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> remote-endpoint = <&adv7511_out>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
>> Â Â Â Â Â Â Â Â Â };
>>
>> Â and both HPD and EDID reading should be handled by the connector driver.
>
> Â Â Â Â Â Â Â Â [snip]
>
> Hi Laurent,
>
> OK. I understand. This connector complexity should be added in all DTs,
> and the same code would be used.
>
> Actually, for component binding, I use drm_of_component_probe():
>
> - from the DRM master, loop on the "ports" phandle array and bind the
> Â Â CRTCs,
>
> - for each CRTC, loop on the first remote port level and bind the
> Â Â encoders/connectors
>
> Now, this should be:
>
> - from the DRM master, loop on the first remote ports level and bind
> Â Â the CRTCs,
>
> - for each CRTC, loop on the second remote port level and bind the
> Â Â encoders (and bridges?),
>
> - for each encoder, loop on the third remote port level and bind the
> Â Â connectors.
>
> Then, it would be nice to have a generic function for doing this job.
>
> Otherwise, from your description:
>
>> Â Â Â Â Â Â Â Â Â hdmi-out {
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â compatible = "hdmi-connector";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â type = "a";
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â /* I2C bus and GPIO references are made up
>> for the example */
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ddc-i2c-bus = <&i2c4>;
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>
> the "hdmi-connector" is a big piece of software. It must handle a lot
> of more and more exotic connectors.
> So, I hope that you have written a "simple-hdmi-connector" which does
> nothing but setting the connector type.
> Where is it?
I suddenly thought about something...
If a DVI connector instead of a HDMI connector is soldered, how should such a
device tree be written?
How about solder a HDMI-to-VGA bridge on the board? (Maybe there should be
"dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge" drivers?)
>
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 9/9] [DO NOT MERGE] ARM: dts: sun6i: Enable 7" LCD panel on Sinlinx SinA31s
07.10.2016, 00:06, "Chen-Yu Tsai" :
> Sinlinx SinA31s comes with an optional 7" 1024x600 LCD panel with
> capacitive touch panel that bolts on to the board.
>
> Enable the display using a panel with close timings. This patch is more
> of a proof of concept. The LCD panel has no markings whatsoever, and
> the timings are not exactly the same, and as a result the display produces
> glitch lines sometimes.
As you say, you can use the panel of SinA33...
>
> Signed-off-by: Chen-Yu Tsai
> ---
> Â arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 30 ++
> Â 1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> index 6ead2f5c847a..2d5cf8c9a12f 100644
> --- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> +++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
> @@ -63,6 +63,23 @@
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â gpios = <&pio 7 13
> GPIO_ACTIVE_HIGH>; /* PH13 */
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â };
> Â Â Â Â Â Â Â Â Â };
> +
> + panel: panel {
> + compatible = "avic,tm070ddh03", "simple-panel";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_lcd>;
> + };
> + };
> + };
> Â };
>
> Â &ehci0 {
> @@ -148,6 +165,19 @@
> Â Â Â Â Â Â Â Â Â regulator-name = "vcc-gmac-phy";
> Â };
>
> +&tcon0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd0_rgb888_pins>;
> + status = "okay";
> +};
> +
> +&tcon0_out {
> + tcon0_out_lcd: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&panel_input>;
> + };
> +};
> +
> Â &usbphy {
> Â Â Â Â Â Â Â Â Â status = "okay";
> Â };
> --
> 2.9.3
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[PATCH v3 09/11] ARM: dts: sun8i: add DE2 nodes for V3s SoC
From: Icenowy Zheng
Allwinner V3s SoC features a "Display Engine 2.0" with only one TCON
which have RGB LCD output.
Add device nodes for it as well as the TCON.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Change the size of de2_clocks regs according to the binding example.
arch/arm/boot/dts/sun8i-v3s.dtsi | 87
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 71075969e5e6..ae23746731a8 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -41,6 +41,10 @@
*/
#include
+#include
+#include
+#include
+#include
/ {
#address-cells = <1>;
@@ -59,6 +63,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-v3s-display-engine";
+ allwinner,pipelines = <&de2_mixer0>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -93,6 +103,83 @@
#size-cells = <1>;
ranges;
+ de2_clocks: clock@0100 {
+ compatible = "allwinner,sun50i-h5-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ de2_mixer0: mixer@0110 {
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x0110 0x10>;
+ clocks = <&de2_clocks CLK_MIXER0>,
+<&de2_clocks CLK_BUS_MIXER0>;
+ clock-names = "mod",
+ "bus";
+ resets = <&de2_clocks RST_MIXER0>;
+ assigned-clocks = <&de2_clocks CLK_MIXER0>;
+ assigned-clock-rates = <15000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ tcon0: lcd-controller@01c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>,
+<&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
From: Icenowy Zheng
Allwinner "Display Engine 2.0" contains some clock controls in it.
In order to add them as clock drivers, we need a device tree binding.
Add the binding here.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Fill the address space length of DE2 CCU to 0x10, just reach the start of
mixer0.
.../devicetree/bindings/clock/sun8i-de2.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt
b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
new file mode 100644
index ..34cf79c05f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
@@ -0,0 +1,31 @@
+Allwinner Display Engine 2.0 Clock Control Binding
+--
+
+Required properties :
+- compatible: must contain one of the following compatibles:
+ - "allwinner,sun8i-a83t-de2-clk"
+ - "allwinner,sun50i-a64-de2-clk"
+ - "allwinner,sun50i-h5-de2-clk"
+
+- reg: Must contain the registers base address and length
+- clocks: phandle to the clocks feeding the display engine subsystem.
+ Three are needed:
+ - "mod": the display engine module clock
+ - "bus": the bus clock for the whole display engine subsystem
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset control for the display engine subsystem.
+- #clock-cells : must contain 1
+- #reset-cells : must contain 1
+
+Example:
+de2_clocks: clock@0100 {
+ compatible = "allwinner,sun50i-a64-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/11] drm/sun4i: add support for Allwinner DE2 mixers
Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
with mixers to do graphic processing and feed data to TCON, like the old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Refactored patch in v3.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 4 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 156 +++
drivers/gpu/drm/sun4i/sun8i_layer.h | 35
drivers/gpu/drm/sun4i/sun8i_mixer.c | 386
drivers/gpu/drm/sun4i/sun8i_mixer.h | 131
6 files changed, 722 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1db1068b9be1..7625c2dad1bb 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,11 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_layer.o
sun4i-backend-y += sun4i_backend.o
+sun8i-mixer-y += sun8i_layer.o
+sun8i-mixer-y += sun8i_mixer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER) += sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..5cc4a7f8a7ae
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "sun4i_crtc.h"
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+#include "sunxi_layer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
+
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+ .atomic_check = sun8i_mixer_layer_atomic_check,
+ .atomic_disable = sun8i_mixer_layer_atomic_disable,
+ .atomic_update = sun8i_mixer_layer_atomic_update,
+};
+
+static const struct drm_plane_funcs sun8i_mixer_layer_funcs = {
+ .atomic_de
[PATCH v3 08/11] drm/sun4i: tcon: add support for V3s TCON
From: Icenowy Zheng
Allwinner V3s SoC features a TCON without channel 1.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 68c0b754cdb5..736b28e47281 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -176,7 +176,8 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
- of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
+ of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
}
static int compare_of(struct device *dev, void *data)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2f330e4e2ead..1a710d7d6a74 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -613,11 +613,16 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
/* nothing is supported */
};
+static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
+ /* nothing is supported */
+};
+
static const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
{ .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks },
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks
},
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
+ { .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/11] Initial Allwinner Display Engine 2.0 Support
This patchset is the initial patchset for Allwinner DE2 support. It contains the support of clocks in DE2 and the mixers in DE2. The SoC used to develop this patchset is V3s, as V3s is the simplest one of the SoCs that have DE2. (Allwinner V3s features only one mixer, although its clock control unit contains support for second mixer's clock; and its only video output is RGB LCD, which is already supported in our TCON driver) The last patch is only a testing patch, it shouldn't be merged; and for the patch to be really usable, the RFC fix of the TCON driver [1] is needed. No HDMI, TV encoder or other internal bridges' support is included in this patchset, which makes it currently not usable on H3. Thanks to Jean-Francois Moine and Jernej Skrabec for their efforts to discover the internal of DE2! [1] https://lists.freedesktop.org/archives/dri-devel/2016-December/126264.html Icenowy Zheng (11): dt-bindings: add binding for the Allwinner DE2 CCU clk: sunxi-ng: add support for DE2 CCU dt-bindings: add bindings for DE2 on V3s SoC drm/sun4i: abstruct the layer type drm/sun4i: abstract a mixer type drm/sun4i: add support for Allwinner DE2 mixers drm/sun4i: Add compatible string for V3s display engine drm/sun4i: tcon: add support for V3s TCON ARM: dts: sun8i: add DE2 nodes for V3s SoC ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC [DO NOT MERGE] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++ .../bindings/display/sunxi/sun4i-drm.txt | 37 +- arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 ++ arch/arm/boot/dts/sun8i-v3s.dtsi | 96 + drivers/clk/sunxi-ng/Kconfig | 5 + drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 204 +++ drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 ++ drivers/gpu/drm/sun4i/Kconfig | 20 ++ drivers/gpu/drm/sun4i/Makefile | 10 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 26 +- drivers/gpu/drm/sun4i/sun4i_backend.h | 5 - drivers/gpu/drm/sun4i/sun4i_crtc.c | 31 +- drivers/gpu/drm/sun4i/sun4i_crtc.h | 10 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +- drivers/gpu/drm/sun4i/sun4i_drv.h | 3 +- drivers/gpu/drm/sun4i/sun4i_layer.c| 22 +- drivers/gpu/drm/sun4i/sun4i_layer.h| 6 +- drivers/gpu/drm/sun4i/sun4i_tcon.c | 7 +- drivers/gpu/drm/sun4i/sun4i_tv.c | 8 +- drivers/gpu/drm/sun4i/sun8i_layer.c| 156 + drivers/gpu/drm/sun4i/sun8i_layer.h| 35 ++ drivers/gpu/drm/sun4i/sun8i_mixer.c| 386 + drivers/gpu/drm/sun4i/sun8i_mixer.h| 131 +++ drivers/gpu/drm/sun4i/sunxi_layer.h| 17 + drivers/gpu/drm/sun4i/sunxi_mixer.h| 22 ++ include/dt-bindings/clock/sun8i-de2.h | 54 +++ include/dt-bindings/reset/sun8i-de2.h | 50 +++ 28 files changed, 1391 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h create mode 100644 drivers/gpu/drm/sun4i/sunxi_mixer.h create mode 100644 include/dt-bindings/clock/sun8i-de2.h create mode 100644 include/dt-bindings/reset/sun8i-de2.h -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/11] drm/sun4i: abstract a mixer type
As we are going to add support for the Allwinner DE2 mixer in sun4i-drm
driver, we will finally have two types of display mixers -- the DE1
backend and the DE2 mixer. They both do some display blending and feed
graphics data to TCON, so I choose to call them both "mixer" here.
Abstract the mixer type to void * and a ops struct, which contains
functions that should be called outside the mixer-specified code (in
TCON, CRTC or TV Encoder code).
A dedicated Kconfig option is also added to control whether
sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c) should
be built. As we removed the codes in CRTC code that directly call the
layer code, we can now extract the layer part and combine it with the
backend part into a new module, sun4i-backend.ko.
Signed-off-by: Icenowy Zheng
---
Refactored patch in v3.
drivers/gpu/drm/sun4i/Kconfig | 10 ++
drivers/gpu/drm/sun4i/Makefile| 6 --
drivers/gpu/drm/sun4i/sun4i_backend.c | 26 +++---
drivers/gpu/drm/sun4i/sun4i_backend.h | 5 -
drivers/gpu/drm/sun4i/sun4i_crtc.c| 14 +++---
drivers/gpu/drm/sun4i/sun4i_crtc.h| 7 ---
drivers/gpu/drm/sun4i/sun4i_drv.h | 3 ++-
drivers/gpu/drm/sun4i/sun4i_layer.c | 7 +++
drivers/gpu/drm/sun4i/sun4i_layer.h | 6 +++---
drivers/gpu/drm/sun4i/sun4i_tcon.c| 2 +-
drivers/gpu/drm/sun4i/sun4i_tv.c | 8 +++-
drivers/gpu/drm/sun4i/sunxi_mixer.h | 22 ++
12 files changed, 78 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sunxi_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index a4b357db8856..5a8227f37cc4 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -12,3 +12,13 @@ config DRM_SUN4I
Choose this option if you have an Allwinner SoC with a
Display Engine. If M is selected the module will be called
sun4i-drm.
+
+config DRM_SUN4I_BACKEND
+ tristate "Support for Allwinner A10 Display Engine Backend"
+ depends on DRM_SUN4I
+ default DRM_SUN4I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ original Allwinner Display Engine, which has a backend to
+ do some alpha blending and feed graphics to TCON. If M is
+ selected the module will be called sun4i-backend.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 59b757350a1f..1db1068b9be1 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -5,9 +5,11 @@ sun4i-tcon-y += sun4i_tcon.o
sun4i-tcon-y += sun4i_rgb.o
sun4i-tcon-y += sun4i_dotclock.o
sun4i-tcon-y += sun4i_crtc.o
-sun4i-tcon-y += sun4i_layer.o
+
+sun4i-backend-y += sun4i_layer.o
+sun4i-backend-y += sun4i_backend.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
-obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
+obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index d660741ba475..35ea51b686e6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -23,6 +23,8 @@
#include "sun4i_backend.h"
#include "sun4i_drv.h"
+#include "sun4i_layer.h"
+#include "sunxi_mixer.h"
static const u32 sunxi_rgb2yuv_coef[12] = {
0x0107, 0x0204, 0x0064, 0x0108,
@@ -30,9 +32,10 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
0x01c1, 0x3e88, 0x3fb8, 0x0808
};
-void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
+static void sun4i_backend_apply_color_correction(void *mixer)
{
int i;
+ struct sun4i_backend *backend = mixer;
DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
@@ -44,27 +47,28 @@ void sun4i_backend_apply_color_correction(struct
sun4i_backend *backend)
regmap_write(backend->regs, SUN4I_BACKEND_OCRCOEF_REG(i),
sunxi_rgb2yuv_coef[i]);
}
-EXPORT_SYMBOL(sun4i_backend_apply_color_correction);
-void sun4i_backend_disable_color_correction(struct sun4i_backend *backend)
+static void sun4i_backend_disable_color_correction(void *mixer)
{
+ struct sun4i_backend *backend = mixer;
+
DRM_DEBUG_DRIVER("Disabling color correction\n");
/* Disable color correction */
regmap_update_bits(backend->regs, SUN4I_BACKEND_OCCTL_REG,
SUN4I_BACKEND_OCCTL_ENABLE, 0);
}
-EXPORT_SYMBOL(sun4i_backend_disable_color_correction);
-void sun4i_backend_commit(struct sun4i_backend *backend)
+static void sun4i_backend_commit(void *mixer)
{
+ struct sun4i_backend *backend = mixer;
+
[PATCH v3 04/11] drm/sun4i: abstract the layer type
As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
driver, we will finally have two types of layer.
Abstract the layer type to void * and a ops struct, which contains the
only function used by crtc -- get the drm_plane struct of the layer.
Signed-off-by: Icenowy Zheng
---
Refactored patch in v3.
drivers/gpu/drm/sun4i/sun4i_crtc.c | 19 +++
drivers/gpu/drm/sun4i/sun4i_crtc.h | 3 ++-
drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++-
drivers/gpu/drm/sun4i/sun4i_layer.h | 2 +-
drivers/gpu/drm/sun4i/sunxi_layer.h | 17 +
5 files changed, 49 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3c876c3a356a..33854ee7f636 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -29,6 +29,7 @@
#include "sun4i_crtc.h"
#include "sun4i_drv.h"
#include "sun4i_layer.h"
+#include "sunxi_layer.h"
#include "sun4i_tcon.h"
static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
scrtc->tcon = tcon;
/* Create our layers */
- scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
+ scrtc->layers = (void **)sun4i_layers_init(drm, scrtc);
if (IS_ERR(scrtc->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
@@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
/* find primary and cursor planes for drm_crtc_init_with_planes */
for (i = 0; scrtc->layers[i]; i++) {
- struct sun4i_layer *layer = scrtc->layers[i];
+ void *layer = scrtc->layers[i];
+ struct drm_plane *plane = scrtc->layer_ops->get_plane(layer);
- switch (layer->plane.type) {
+ switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
- primary = &layer->plane;
+ primary = plane;
break;
case DRM_PLANE_TYPE_CURSOR:
- cursor = &layer->plane;
+ cursor = plane;
break;
default:
break;
@@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
/* Set possible_crtcs to this crtc for overlay planes */
for (i = 0; scrtc->layers[i]; i++) {
uint32_t possible_crtcs = BIT(drm_crtc_index(&scrtc->crtc));
- struct sun4i_layer *layer = scrtc->layers[i];
+ void *layer = scrtc->layers[i];
+ struct drm_plane *plane = scrtc->layer_ops->get_plane(layer);
- if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
- layer->plane.possible_crtcs = possible_crtcs;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ plane->possible_crtcs = possible_crtcs;
}
return scrtc;
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h
b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index 230cb8f0d601..a4036ee44cf8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -19,7 +19,8 @@ struct sun4i_crtc {
struct sun4i_backend*backend;
struct sun4i_tcon *tcon;
- struct sun4i_layer **layers;
+ void**layers;
+ const struct sunxi_layer_ops*layer_ops;
};
static inline struct sun4i_crtc *drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index f26bde5b9117..bc4a70d6968b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -16,7 +16,9 @@
#include
#include "sun4i_backend.h"
+#include "sun4i_crtc.h"
#include "sun4i_layer.h"
+#include "sunxi_layer.h"
struct sun4i_plane_desc {
enum drm_plane_type type;
@@ -100,6 +102,17 @@ static const struct sun4i_plane_desc
sun4i_backend_planes[] = {
},
};
+static struct drm_plane *sun4i_layer_get_plane(void *layer)
+{
+ struct sun4i_layer *sun4i_layer = layer;
+
+ return &sun4i_layer->plane;
+}
+
+static const struct sunxi_layer_ops layer_ops = {
+ .get_plane = sun4i_layer_get_plane,
+};
+
static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
struct sun4i_backend *backend,
const struct sun4i_plane_desc
*plane)
@@ -129,9 +142,10 @@ static stru
[PATCH v3 07/11] drm/sun4i: Add compatible string for V3s display engine
Allwinner V3s features the new "Display Engine 2.0", which can now also
be driven with our subdrivers in sun4i-drm.
Add the compatible string for in sun4i_drv.c, in order to make the
display engine and its components probed.
Signed-off-by: Icenowy Zheng
---
Patch splited in v3.
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8ddd72cd5873..68c0b754cdb5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -294,6 +294,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-display-engine" },
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+ { .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/11] dt-bindings: add bindings for DE2 on V3s SoC
From: Icenowy Zheng Allwinner V3s SoC have a display engine which have a different pipeline with older SoCs. Add document for it (new compatibles and the new "mixer" part). The paragraph of TCON is also refactored, for furtherly add TCONs in A83T/H3/A64/H5 that have only a channel 1 (used for HDMI or TV Encoder). Signed-off-by: Icenowy Zheng --- Changes in v3: - Remove the description of having a BE directly as allwinner,pipeline. .../bindings/display/sunxi/sun4i-drm.txt | 37 +++--- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index b82c00449468..38de5e96f359 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -31,11 +31,11 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun8i-a33-tcon + * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - - clocks: phandles to the clocks feeding the TCON. Three are needed: + - clocks: phandles to the clocks feeding the TCON - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 - resets: phandles to the reset controllers driving the encoder - "lcd": the reset line for the TCON channel 0 @@ -52,7 +52,12 @@ Required properties: second the block connected to the TCON channel 1 (usually the TV encoder) -On SoCs other than the A33, there is one more clock required: +On TCONs that have a channel 0 (currently all TCONs supported), there +is one more clock required: + - 'tcon-ch0': The clock driving the TCON channel 0 + +On TCONs that have a channel 1 (currently all TCONs except the ones in +A33 and V3s), there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 DRC @@ -137,6 +142,26 @@ Required properties: Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoints, the second one the outputs +Display Engine 2.0 Mixer + + +The DE2 mixer have many functionalities, currently only layer blending is +supported. + +Required properties: + - compatible: value must be one of: +* allwinner,sun8i-v3s-de2-mixer + - reg: base address and size of the memory-mapped region. + - clocks: phandles to the clocks feeding the frontend and backend +* bus: the backend interface clock +* ram: the backend DRAM clock + - clock-names: the clock names mentioned above + - resets: phandles to the reset controllers driving the backend + +- ports: A ports node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. The + first port should be the input endpoints, the second one the output + Display Engine Pipeline --- @@ -151,9 +176,13 @@ Required properties: * allwinner,sun6i-a31-display-engine * allwinner,sun6i-a31s-display-engine * allwinner,sun8i-a33-display-engine +* allwinner,sun8i-v3s-display-engine - allwinner,pipelines: list of phandle to the display engine -frontends available. +pipeline entry point. For SoCs with original DE (currently +all SoCs supported by display engine except V3s), this +phandle should be a display frontend; for SoCs with DE2, +this phandle should be a mixer. Example: -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/11] [DO NOT MERGE] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero
From: Icenowy Zheng
A 480x272 QiaoDian QD43003C0-40-7LED panel is available from Lichee Pi.
This commit connects this panel to Lichee Pi Zero.
Lichee Pi also provides a 800x480 panel without accurate model number,
so do not merge this patch. It will finally come as device tree overlay.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..7ae72bf63cd0 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -75,6 +75,28 @@
gpios = <&pio 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
};
};
+
+ panel: panel {
+ compatible = "qiaodian,qd43003c0-40", "simple-panel";
+ enable-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* Should be
backlight */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
+};
+
+&de {
+ status = "okay";
};
&mmc0 {
@@ -86,6 +108,20 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+ status = "okay";
+
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
&uart0 {
pinctrl-0 = <&uart0_pins_a>;
pinctrl-names = "default";
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/11] ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC
From: Icenowy Zheng
Allwinner V3s SoC features a set of pins that have functionality of RGB
LCD, the pins are at different pin ban than other SoCs.
Add pinctrl node for them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index ae23746731a8..ac783a8a4fd3 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -297,6 +297,15 @@
function = "i2c0";
};
+ lcd_rgb666_pins: lcd_rgb666@0 {
+ pins = "PE0", "PE1", "PE2", "PE3", "PE4",
+ "PE5", "PE6", "PE7", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15", "PE16", "PE17", "PE18", "PE19",
+ "PE23", "PE24";
+ function = "lcd";
+ };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/11] clk: sunxi-ng: add support for DE2 CCU
From: Icenowy Zheng
The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
management unit for its subunits, like the DE CCU in A80.
Add a sunxi-ng style driver for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Rename sunxi-de2-ccu to sun8i-de2-ccu.
drivers/clk/sunxi-ng/Kconfig | 5 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 204 ++
drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 +
include/dt-bindings/clock/sun8i-de2.h | 54 +
include/dt-bindings/reset/sun8i-de2.h | 50 +
6 files changed, 342 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h
create mode 100644 include/dt-bindings/clock/sun8i-de2.h
create mode 100644 include/dt-bindings/reset/sun8i-de2.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 8af8f4be8e3b..778c141dd966 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -140,6 +140,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
+config SUN8I_DE2_CCU
+ bool "Support for the Allwinner SoCs DE2 CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_GATE
+
config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 6feaac0c5600..8bf3afaefde4 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o
obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o
obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-usb.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
new file mode 100644
index ..43d7bd15e38b
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (c) 2016 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_reset.h"
+
+#include "ccu-sun8i-de2.h"
+
+static SUNXI_CCU_GATE(bus_mixer0_clk, "bus-mixer0", "bus-de",
+ 0x04, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1", "bus-de",
+ 0x04, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de",
+ 0x04, BIT(2), 0);
+
+static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div",
+ 0x00, BIT(0), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(mixer1_clk, "mixer1", "mixer1-div",
+ 0x00, BIT(1), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div",
+ 0x00, BIT(2), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
+ CLK_SET_RATE_PARENT);
+
+static struct ccu_common *sunxi_de2_clks[] = {
+ &mixer0_clk.common,
+ &mixer1_clk.common,
+ &wb_clk.common,
+
+ &bus_mixer0_clk.common,
+ &bus_mixer1_clk.common,
+ &bus_wb_clk.common,
+
+ &mixer0_div_clk.common,
+ &mixer1_div_clk.common,
+ &wb_div_clk.common,
+};
+
+static struct clk_hw_onecell_data sunxi_de2_hw_clks = {
+ .hws= {
+ [CLK_MIXER0]= &mixer0_clk.common.hw,
+ [CLK_MIXER1]= &mixer1_clk.common.hw,
+ [CLK_WB]= &wb_clk.common.hw,
+
+ [CLK_BUS_MIXER0]= &bus_mixer0_clk.
Re: [PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
在 2017年04月03日 23:33, Rob Herring 写道:
On Thu, Mar 30, 2017 at 03:46:03AM +0800, Icenowy Zheng wrote:
From: Icenowy Zheng
Allwinner "Display Engine 2.0" contains some clock controls in it.
In order to add them as clock drivers, we need a device tree binding.
Add the binding here.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Fill the address space length of DE2 CCU to 0x10, just reach the start of
mixer0.
Why? You waste virtual memory space making this bigger than it needs to
be. Not an issue so much for 64-bit.
.../devicetree/bindings/clock/sun8i-de2.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt
b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
new file mode 100644
index ..34cf79c05f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
@@ -0,0 +1,31 @@
+Allwinner Display Engine 2.0 Clock Control Binding
+--
+
+Required properties :
+- compatible: must contain one of the following compatibles:
+ - "allwinner,sun8i-a83t-de2-clk"
+ - "allwinner,sun50i-a64-de2-clk"
+ - "allwinner,sun50i-h5-de2-clk"
+
+- reg: Must contain the registers base address and length
+- clocks: phandle to the clocks feeding the display engine subsystem.
+ Three are needed:
+ - "mod": the display engine module clock
+ - "bus": the bus clock for the whole display engine subsystem
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset control for the display engine subsystem.
+- #clock-cells : must contain 1
+- #reset-cells : must contain 1
+
+Example:
+de2_clocks: clock@0100 {
Drop the leading 0s. dtc in linux-next will now warn on this with W=1
compile. Looks like sunxi has a lot of them. Please fix so we don't keep
repeating this same copy-n-paste.
Thanks ;-)
I will try to kill them all ;-)
+ compatible = "allwinner,sun50i-a64-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/11] drm/sun4i: abstract the layer type
在 2017年04月05日 03:28, Sean Paul 写道:
On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote:
As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
driver, we will finally have two types of layer.
Abstract the layer type to void * and a ops struct, which contains the
only function used by crtc -- get the drm_plane struct of the layer.
Signed-off-by: Icenowy Zheng
---
Refactored patch in v3.
drivers/gpu/drm/sun4i/sun4i_crtc.c | 19 +++
drivers/gpu/drm/sun4i/sun4i_crtc.h | 3 ++-
drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++-
drivers/gpu/drm/sun4i/sun4i_layer.h | 2 +-
drivers/gpu/drm/sun4i/sunxi_layer.h | 17 +
5 files changed, 49 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3c876c3a356a..33854ee7f636 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -29,6 +29,7 @@
#include "sun4i_crtc.h"
#include "sun4i_drv.h"
#include "sun4i_layer.h"
+#include "sunxi_layer.h"
#include "sun4i_tcon.h"
static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
scrtc->tcon = tcon;
/* Create our layers */
- scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
+ scrtc->layers = (void **)sun4i_layers_init(drm, scrtc);
if (IS_ERR(scrtc->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
@@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
/* find primary and cursor planes for drm_crtc_init_with_planes */
for (i = 0; scrtc->layers[i]; i++) {
- struct sun4i_layer *layer = scrtc->layers[i];
+ void *layer = scrtc->layers[i];
+ struct drm_plane *plane = scrtc->layer_ops->get_plane(layer);
- switch (layer->plane.type) {
+ switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
- primary = &layer->plane;
+ primary = plane;
break;
case DRM_PLANE_TYPE_CURSOR:
- cursor = &layer->plane;
+ cursor = plane;
break;
default:
break;
@@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
/* Set possible_crtcs to this crtc for overlay planes */
for (i = 0; scrtc->layers[i]; i++) {
uint32_t possible_crtcs = BIT(drm_crtc_index(&scrtc->crtc));
- struct sun4i_layer *layer = scrtc->layers[i];
+ void *layer = scrtc->layers[i];
+ struct drm_plane *plane = scrtc->layer_ops->get_plane(layer);
- if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
- layer->plane.possible_crtcs = possible_crtcs;
+ if (plane->type == DRM_PLANE_TYPE_OVERLAY)
+ plane->possible_crtcs = possible_crtcs;
}
return scrtc;
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h
b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index 230cb8f0d601..a4036ee44cf8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -19,7 +19,8 @@ struct sun4i_crtc {
struct sun4i_backend*backend;
struct sun4i_tcon *tcon;
- struct sun4i_layer **layers;
+ void**layers;
+ const struct sunxi_layer_ops*layer_ops;
I think you should probably take a different approach to abstract the layer
type. How about creating
struct sunxi_layer {
struct drm_plane plane;
}
base and then subclassing that for sun4i and sun8i? By doing this you can avoid
the nasty casting and you can also get rid of the get_plane() hook and
layer_ops.
For the situation that using ** things are easily to get weird.
Sean
};
static inline struct sun4i_crtc *drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index f26bde5b9117..bc4a70d6968b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -16,7 +16,9 @@
#include
#include "sun4i_backend.h"
+#include "sun4i_crtc.h"
#include "sun4i_layer.h"
+#include "sunxi_layer.h"
struct sun4i_plane_desc {
enum drm_plane_type type;
@@ -100,6 +102,17 @@ static const struct sun4i_plane_desc
sun4i_backend_planes[] = {
},
};
+static struct drm_plane *sun4i_layer_get_plane(void *layer)
+{
+
Re: [linux-sunxi] Re: [PATCH v3 04/11] drm/sun4i: abstract the layer type
2017年4月5日 10:27于 Chen-Yu Tsai 写道：
>
> On Wed, Apr 5, 2017 at 3:53 AM, Icenowy Zheng wrote:
> >
> >
> > 在 2017年04月05日 03:28, Sean Paul 写道:
> >>
> >> On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote:
> >>>
> >>> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
> >>> driver, we will finally have two types of layer.
> >>>
> >>> Abstract the layer type to void * and a ops struct, which contains the
> >>> only function used by crtc -- get the drm_plane struct of the layer.
> >>>
> >>> Signed-off-by: Icenowy Zheng
> >>> ---
> >>> Refactored patch in v3.
> >>>
> >>> drivers/gpu/drm/sun4i/sun4i_crtc.c | 19 +++
> >>> drivers/gpu/drm/sun4i/sun4i_crtc.h | 3 ++-
> >>> drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++-
> >>> drivers/gpu/drm/sun4i/sun4i_layer.h | 2 +-
> >>> drivers/gpu/drm/sun4i/sunxi_layer.h | 17 +
> >>> 5 files changed, 49 insertions(+), 11 deletions(-)
> >>> create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> >>> index 3c876c3a356a..33854ee7f636 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> >>> @@ -29,6 +29,7 @@
> >>> #include "sun4i_crtc.h"
> >>> #include "sun4i_drv.h"
> >>> #include "sun4i_layer.h"
> >>> +#include "sunxi_layer.h"
> >>> #include "sun4i_tcon.h"
> >>>
> >>> static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
> >>> @@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device
> >>> *drm,
> >>> scrtc->tcon = tcon;
> >>>
> >>> /* Create our layers */
> >>> - scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
> >>> + scrtc->layers = (void **)sun4i_layers_init(drm, scrtc);
> >>> if (IS_ERR(scrtc->layers)) {
> >>> dev_err(drm->dev, "Couldn't create the planes\n");
> >>> return NULL;
> >>> @@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct
> >>> drm_device *drm,
> >>>
> >>> /* find primary and cursor planes for drm_crtc_init_with_planes
> >>> */
> >>> for (i = 0; scrtc->layers[i]; i++) {
> >>> - struct sun4i_layer *layer = scrtc->layers[i];
> >>> + void *layer = scrtc->layers[i];
> >>> + struct drm_plane *plane =
> >>> scrtc->layer_ops->get_plane(layer);
> >>>
> >>> - switch (layer->plane.type) {
> >>> + switch (plane->type) {
> >>> case DRM_PLANE_TYPE_PRIMARY:
> >>> - primary = &layer->plane;
> >>> + primary = plane;
> >>> break;
> >>> case DRM_PLANE_TYPE_CURSOR:
> >>> - cursor = &layer->plane;
> >>> + cursor = plane;
> >>> break;
> >>> default:
> >>> break;
> >>> @@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct
> >>> drm_device *drm,
> >>> /* Set possible_crtcs to this crtc for overlay planes */
> >>> for (i = 0; scrtc->layers[i]; i++) {
> >>> uint32_t possible_crtcs =
> >>> BIT(drm_crtc_index(&scrtc->crtc));
> >>> - struct sun4i_layer *layer = scrtc->layers[i];
> >>> + void *layer = scrtc->layers[i];
> >>> + struct drm_plane *plane =
> >>> scrtc->layer_ops->get_plane(layer);
> >>>
> >>> - if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
> >>> - layer->plane.possible_crtcs = possible_crtcs;
> >>> + if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> >>> + plane->possible_crtcs
[PATCH v4 08/11] drm/sun4i: tcon: add support for V3s TCON
Allwinner V3s SoC features a TCON without channel 1.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 68c0b754cdb5..736b28e47281 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -176,7 +176,8 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
- of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
+ of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
}
static int compare_of(struct device *dev, void *data)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f50ecb75c177..e85a726a9c36 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -533,11 +533,16 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
/* nothing is supported */
};
+static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
+ /* nothing is supported */
+};
+
static const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
{ .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks },
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks
},
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
+ { .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
--
2.12.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
with mixers to do graphic processing and feed data to TCON, like the old
backends and frontends.
Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
Currently a lot of functions are still missing -- more investigations
are needed to gain enough information for them.
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Killed some dead code according to Jernej.
drivers/gpu/drm/sun4i/Kconfig | 10 +
drivers/gpu/drm/sun4i/Makefile | 4 +
drivers/gpu/drm/sun4i/sun8i_layer.c | 142 ++
drivers/gpu/drm/sun4i/sun8i_layer.h | 36
drivers/gpu/drm/sun4i/sun8i_mixer.c | 381
drivers/gpu/drm/sun4i/sun8i_mixer.h | 131 +
6 files changed, 704 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 5a8227f37cc4..15557484520d 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
original Allwinner Display Engine, which has a backend to
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+
+config DRM_SUN4I_SUN8I_MIXER
+ tristate "Support for Allwinner Display Engine 2.0 Mixer"
+ depends on DRM_SUN4I
+ default MACH_SUN8I
+ help
+ Choose this option if you have an Allwinner SoC with the
+ Allwinner Display Engine 2.0, which has a mixer to do some
+ graphics mixture and feed graphics to TCON, If M is
+ selected the module will be called sun8i-mixer.
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 1db1068b9be1..7625c2dad1bb 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,7 +9,11 @@ sun4i-tcon-y += sun4i_crtc.o
sun4i-backend-y += sun4i_layer.o
sun4i-backend-y += sun4i_backend.o
+sun8i-mixer-y += sun8i_layer.o
+sun8i-mixer-y += sun8i_mixer.o
+
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
+obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER) += sun8i-mixer.o
obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
b/drivers/gpu/drm/sun4i/sun8i_layer.c
new file mode 100644
index ..d70a90d963b0
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) Icenowy Zheng
+ *
+ * Based on sun4i_layer.h, which is:
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "sun4i_crtc.h"
+#include "sun8i_layer.h"
+#include "sun8i_mixer.h"
+
+struct sun8i_plane_desc {
+ enum drm_plane_type type;
+ const uint32_t *formats;
+ uint32_tnformats;
+};
+
+static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
+
+static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_layer_enable(mixer, layer->id, false);
+}
+
+static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ struct sun8i_mixer *mixer = layer->mixer;
+
+ sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
+ sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
+ sun8i_mixer_layer_enable(mixer, layer->id, true);
+}
+
+static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
+ .atomic_check = sun8i_mixer_layer_atomic_check,
+ .atomic_disable = sun8i_mixer_layer_atomic_disable,
+ .atomic_update = sun8i_mixer_layer_atomic_update,
+};
+
+static const struct drm_plane_funcs sun8i_mixer_layer_funcs = {
+ .atomic_destroy_stat
[PATCH v4 00/11] Initial Allwinner Display Engine 2.0 Support
This patchset is the initial patchset for Allwinner DE2 support. It contains the support of clocks in DE2 and the mixers in DE2. The SoC used to develop this patchset is V3s, as V3s is the simplest one of the SoCs that have DE2. (Allwinner V3s features only one mixer, although its clock control unit contains support for second mixer's clock; and its only video output is RGB LCD, which is already supported in our TCON driver) The last patch is only a testing patch, it shouldn't be merged; and for the patch to be really usable, the RFC fix of the TCON driver [1] is needed. No HDMI, TV encoder or other internal bridges' support is included in this patchset, which makes it currently not usable on H3. Thanks to Jean-Francois Moine and Jernej Skrabec for their efforts to discover the internal of DE2! [1] https://lists.freedesktop.org/archives/dri-devel/2016-December/126264.html Icenowy Zheng (11): dt-bindings: add binding for the Allwinner DE2 CCU clk: sunxi-ng: add support for DE2 CCU dt-bindings: add bindings for DE2 on V3s SoC drm/sun4i: return only planes for layers created drm/sun4i: abstract a engine type drm/sun4i: add support for Allwinner DE2 mixers drm/sun4i: Add compatible string for V3s display engine drm/sun4i: tcon: add support for V3s TCON ARM: dts: sun8i: add DE2 nodes for V3s SoC ARM: dts: sun8i: add pinmux for LCD pins of V3s SoC [DO NOT MERGE] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero .../devicetree/bindings/clock/sun8i-de2.txt| 31 ++ .../bindings/display/sunxi/sun4i-drm.txt | 29 +- arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 ++ arch/arm/boot/dts/sun8i-v3s.dtsi | 96 ++ drivers/clk/sunxi-ng/Kconfig | 5 + drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 218 drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 ++ drivers/gpu/drm/sun4i/Kconfig | 20 ++ drivers/gpu/drm/sun4i/Makefile | 10 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 26 +- drivers/gpu/drm/sun4i/sun4i_backend.h | 5 - drivers/gpu/drm/sun4i/sun4i_crtc.c | 35 +- drivers/gpu/drm/sun4i/sun4i_crtc.h | 8 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +- drivers/gpu/drm/sun4i/sun4i_drv.h | 3 +- drivers/gpu/drm/sun4i/sun4i_layer.c| 18 +- drivers/gpu/drm/sun4i/sun4i_layer.h| 7 +- drivers/gpu/drm/sun4i/sun4i_tcon.c | 7 +- drivers/gpu/drm/sun4i/sun4i_tv.c | 11 +- drivers/gpu/drm/sun4i/sun8i_layer.c| 142 drivers/gpu/drm/sun4i/sun8i_layer.h| 36 ++ drivers/gpu/drm/sun4i/sun8i_mixer.c| 381 + drivers/gpu/drm/sun4i/sun8i_mixer.h| 131 +++ drivers/gpu/drm/sun4i/sunxi_engine.h | 35 ++ include/dt-bindings/clock/sun8i-de2.h | 54 +++ include/dt-bindings/reset/sun8i-de2.h | 50 +++ 27 files changed, 1371 insertions(+), 56 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h create mode 100644 include/dt-bindings/clock/sun8i-de2.h create mode 100644 include/dt-bindings/reset/sun8i-de2.h -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/11] [DO NOT MERGE] ARM: dts: sun8i: enable LCD panel of Lichee Pi Zero
A 480x272 QiaoDian QD43003C0-40-7LED panel is available from Lichee Pi.
This commit connects this panel to Lichee Pi Zero.
Lichee Pi also provides a 800x480 panel without accurate model number,
so do not merge this patch. It will finally come as device tree overlay.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 36 +++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..7ae72bf63cd0 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -75,6 +75,28 @@
gpios = <&pio 6 2 GPIO_ACTIVE_LOW>; /* PG2 */
};
};
+
+ panel: panel {
+ compatible = "qiaodian,qd43003c0-40", "simple-panel";
+ enable-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* Should be
backlight */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
+};
+
+&de {
+ status = "okay";
};
&mmc0 {
@@ -86,6 +108,20 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+ status = "okay";
+
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
&uart0 {
pinctrl-0 = <&uart0_pins_a>;
pinctrl-names = "default";
--
2.12.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/11] dt-bindings: add bindings for DE2 on V3s SoC
Allwinner V3s SoC have a display engine which have a different pipeline with older SoCs. Add document for it (new compatibles and the new "mixer" part). Signed-off-by: Icenowy Zheng --- Changes in v4: - Removed the refactor at TCON chapter. Changes in v3: - Remove the description of having a BE directly as allwinner,pipeline. .../bindings/display/sunxi/sun4i-drm.txt | 29 -- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 57a8d0610062..7da80e26d61b 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -31,6 +31,7 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun8i-a33-tcon + * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the TCON. Three are needed: @@ -52,7 +53,7 @@ Required properties: second the block connected to the TCON channel 1 (usually the TV encoder) -On SoCs other than the A33, there is one more clock required: +On SoCs other than the A33 and V3s, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 DRC @@ -138,6 +139,26 @@ Required properties: Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoints, the second one the outputs +Display Engine 2.0 Mixer + + +The DE2 mixer have many functionalities, currently only layer blending is +supported. + +Required properties: + - compatible: value must be one of: +* allwinner,sun8i-v3s-de2-mixer + - reg: base address and size of the memory-mapped region. + - clocks: phandles to the clocks feeding the frontend and backend +* bus: the backend interface clock +* ram: the backend DRAM clock + - clock-names: the clock names mentioned above + - resets: phandles to the reset controllers driving the backend + +- ports: A ports node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. The + first port should be the input endpoints, the second one the output + Display Engine Pipeline --- @@ -152,9 +173,13 @@ Required properties: * allwinner,sun6i-a31-display-engine * allwinner,sun6i-a31s-display-engine * allwinner,sun8i-a33-display-engine +* allwinner,sun8i-v3s-display-engine - allwinner,pipelines: list of phandle to the display engine -frontends available. +pipeline entry point. For SoCs with original DE (currently +all SoCs supported by display engine except V3s), this +phandle should be a display frontend; for SoCs with DE2, +this phandle should be a mixer. Example: -- 2.12.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/11] clk: sunxi-ng: add support for DE2 CCU
The "Display Engine 2.0" in Allwinner newer SoCs contains a clock
management unit for its subunits, like the DE CCU in A80.
Add a sunxi-ng style driver for it.
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Fixed the inconsistence between mixer_div clocks' number and real clock.
Changes in v2:
- Rename sunxi-de2-ccu to sun8i-de2-ccu.
drivers/clk/sunxi-ng/Kconfig | 5 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 218 ++
drivers/clk/sunxi-ng/ccu-sun8i-de2.h | 28 +
include/dt-bindings/clock/sun8i-de2.h | 54 +
include/dt-bindings/reset/sun8i-de2.h | 50
6 files changed, 356 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-de2.h
create mode 100644 include/dt-bindings/clock/sun8i-de2.h
create mode 100644 include/dt-bindings/reset/sun8i-de2.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index fbd3f8cd5c22..7c7f55dc7f65 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -140,6 +140,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
+config SUN8I_DE2_CCU
+ bool "Support for the Allwinner SoCs DE2 CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_GATE
+
config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..be616279450e 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_SUN8I_A23_CCU) += ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
obj-$(CONFIG_SUN8I_R_CCU) += ccu-sun8i-r.o
obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o
obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
new file mode 100644
index ..30fe42635635
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_reset.h"
+
+#include "ccu-sun8i-de2.h"
+
+static SUNXI_CCU_GATE(bus_mixer0_clk, "bus-mixer0", "bus-de",
+ 0x04, BIT(0), 0);
+static SUNXI_CCU_GATE(bus_mixer1_clk, "bus-mixer1", "bus-de",
+ 0x04, BIT(1), 0);
+static SUNXI_CCU_GATE(bus_wb_clk, "bus-wb", "bus-de",
+ 0x04, BIT(2), 0);
+
+static SUNXI_CCU_GATE(mixer0_clk, "mixer0", "mixer0-div",
+ 0x00, BIT(0), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(mixer1_clk, "mixer1", "mixer1-div",
+ 0x00, BIT(1), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_GATE(wb_clk, "wb", "wb-div",
+ 0x00, BIT(2), CLK_SET_RATE_PARENT);
+
+static SUNXI_CCU_M(mixer0_div_clk, "mixer0-div", "de", 0x0c, 0, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(mixer1_div_clk, "mixer1-div", "de", 0x0c, 4, 4,
+ CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M(wb_div_clk, "wb-div", "de", 0x0c, 8, 4,
+ CLK_SET_RATE_PARENT);
+
+static struct ccu_common *sunxi_de2_clks[] = {
+ &mixer0_clk.common,
+ &mixer1_clk.common,
+ &wb_clk.common,
+
+ &bus_mixer0_clk.common,
+ &bus_mixer1_clk.common,
+ &bus_wb_clk.common,
+
+ &mixer0_div_clk.common,
+ &mixer1_div_clk.common,
+ &wb_div_clk.common,
+};
+
+static struct clk_hw_onecell_data sunxi_de2_hw_clks = {
+ .hws= {
+ [CLK_MIXER0]= &mixer0_clk.common.hw,
+ [CLK_MIXER1]= &mixer1_clk.common.hw,
+ [CLK_WB]= &wb_clk.common.hw,
+
+ [CLK_BUS_MIX
