Re: [PATCH 4/7] drm/panel: st7703: Add Panel Rotation Support
Hi,
On Mon, Feb 12, 2024 at 12:49:47PM -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add support for panel rotation to ST7703 based devices.
>
> Signed-off-by: Chris Morgan
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 939ba05c9b58..a3e142f156d5 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -62,6 +62,7 @@ struct st7703 {
>
> struct dentry *debugfs;
> const struct st7703_panel_desc *desc;
> + enum drm_panel_orientation orientation;
> };
>
> struct st7703_panel_desc {
> @@ -743,12 +744,20 @@ static int st7703_get_modes(struct drm_panel *panel,
> return 1;
> }
>
> +static enum drm_panel_orientation st7703_get_orientation(struct drm_panel
> *panel)
> +{
> + struct st7703 *st7703 = panel_to_st7703(panel);
> +
> + return st7703->orientation;
> +}
> +
> static const struct drm_panel_funcs st7703_drm_funcs = {
> .disable = st7703_disable,
> .unprepare = st7703_unprepare,
> .prepare = st7703_prepare,
> .enable= st7703_enable,
> .get_modes = st7703_get_modes,
> + .get_orientation = st7703_get_orientation,
> };
>
> static int allpixelson_set(void *data, u64 val)
> @@ -817,6 +826,10 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
> return dev_err_probe(dev, PTR_ERR(ctx->iovcc),
>"Failed to request iovcc regulator\n");
>
> + ret = of_drm_get_panel_orientation(dsi->dev.of_node, >orientation);
> + if (ret < 0)
> + return dev_err_probe(>dev, ret, "Failed to get
> orientation\n");
> +
> drm_panel_init(>panel, dev, _drm_funcs,
> DRM_MODE_CONNECTOR_DSI);
Reviewed-by: Guido Günther
Cheers,
-- Guido
>
> --
> 2.34.1
>
Re: [PATCH 3/7] dt-bindings: display: Document ST7703 panel rotation
Hi, On Mon, Feb 12, 2024 at 12:49:46PM -0600, Chris Morgan wrote: > From: Chris Morgan > > Document the rotation property for ST7703 based panels. > > Signed-off-by: Chris Morgan > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > index 8dfe8951bf5b..97e0d14790e3 100644 > --- > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > @@ -46,6 +46,8 @@ properties: > >backlight: true > > + rotation: true > + I'd avoid newlines here: backlight: true rotation: true (which also seems to match what other panels do). With that Reviewd-by: Guido Günther Cheers, -- Guido > required: >- compatible >- reg > -- > 2.34.1 >
Re: [PATCH 2/7] drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_EF, 0xff, 0xff, 0x01);
> +
> + return 0;
> +}
> +
> +static const struct drm_display_mode rgb10max3_panel_mode = {
> + .hdisplay = 720,
> + .hsync_start= 720 + 40,
> + .hsync_end = 720 + 40 + 10,
> + .htotal = 720 + 40 + 10 + 40,
> + .vdisplay = 1280,
> + .vsync_start= 1280 + 16,
> + .vsync_end = 1280 + 16 + 4,
> + .vtotal = 1280 + 16 + 4 + 14,
> + .clock = 63800,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> + .width_mm = 62,
> + .height_mm = 109,
> +};
> +
> +static const struct st7703_panel_desc rgb10max3_panel_desc = {
> + .mode = _panel_mode,
> + .lanes = 4,
> + .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> + MIPI_DSI_MODE_NO_EOT_PACKET | MIPI_DSI_MODE_LPM,
> + .format = MIPI_DSI_FMT_RGB888,
> + .init_sequence = rgb10max3_panel_init_sequence,
> +};
> +
> static int st7703_enable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> @@ -784,6 +874,7 @@ static void st7703_remove(struct mipi_dsi_device *dsi)
>
> static const struct of_device_id st7703_of_match[] = {
> { .compatible = "anbernic,rg353v-panel-v2", .data = _desc },
> + { .compatible = "powkiddy,rgb10max3-panel", .data =
> _panel_desc },
> { .compatible = "powkiddy,rgb30-panel", .data = _desc },
> { .compatible = "rocktech,jh057n00900", .data = _panel_desc
> },
> { .compatible = "xingbangda,xbd599", .data = _desc },
Reviewed-by: Guido Günther
Cheers,
-- Guido
> --
> 2.34.1
>
Re: [PATCH 1/7] dt-bindings: display: st7703: Add Powkiddy RGB10MAX3 panel
Hi, On Mon, Feb 12, 2024 at 12:49:44PM -0600, Chris Morgan wrote: > From: Chris Morgan > > The RGB10MAX3 panel is a panel specific to the Powkiddy RGB10MAX3 > handheld device that measures 5 inches diagonally with a resolution > of 720x1280. > > Signed-off-by: Chris Morgan > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > index 97cccd8a8479..8dfe8951bf5b 100644 > --- > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > @@ -22,6 +22,8 @@ properties: > enum: ># Anberic RG353V-V2 5.0" 640x480 TFT LCD panel >- anbernic,rg353v-panel-v2 > + # Powkiddy RGB10MAX3 5.0" 720x1280 TFT LCD panel > + - powkiddy,rgb10max3-panel ># Powkiddy RGB30 3.0" 720x720 TFT LCD panel >- powkiddy,rgb30-panel ># Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel Reviewed-by: Guido Günther Cheers, -- Guido > -- > 2.34.1 >
Re: [PATCH v3] drm/panel: st7703: Fix Panel Initialization for Anbernic RG353V-V2
Hi, On Sat, Feb 10, 2024 at 01:24:43AM +0100, Ao Zhong wrote: > This patch addresses an issue with the Anbernic RG353V-V2 panel > initialization that was caused by incorrect parameter. The correct > initialization sequence was derived by referencing the JELOS (Just > Enough Linux OS) BSP kernel's device tree for the V2 panel, which is > identified by the ID "38 21". The relevant device tree can be found at: > > https://github.com/JustEnoughLinuxOS/rk356x-kernel/blob/d4d7335a5ca18fc216a29712d5c6cecfb86147d2/arch/arm64/boot/dts/rockchip/rk3568-evb-rg353v.dtsi#L582 > > The proper initialization sequence was further informed by dissecting > instructions as outlined in the "Rockchip_DRM_Panel_Porting_Guide", > specifically in Chapter 3.3 of the document. > > https://web.archive.org/web/20240209211932if_/http://download.t-firefly.com/product/Board/Common/Document/Developer/Rockchip_Developer_Guide_DRM_Panel_Porting_CN.pdf > > Upon comparing the initialization sequence within the > rg353v2_init_sequence function against the device tree in the BSP > kernel, discrepancies were identified in two instructions. The relevant > instructions in the device tree are: > > 1. 15 00 03 b6 7f 7f corresponding to the ST7703_CMD_SETVCOM command >with parameters 7f 7f > 2. 39 00 05 b8 26 62 f0 63 corresponding to the ST7703_CMD_SETPOWER_EXT >command with parameters 26 62 f0 63 > > Adjusting the parameters to match those specified in the BSP kernel's > device tree allow the panel to initialize correctly. > > Signed-off-by: Ao Zhong > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index b55bafd1a8be..a346d6c3d283 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -357,8 +357,8 @@ static int rg353v2_init_sequence(struct st7703 *ctx) > 0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00); > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80); > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x0a, 0x0a); > - mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x92, 0x92); > - mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22, > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x7f, 0x7f); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x26, 0x62, > 0xf0, 0x63); > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, 0x33, 0x81, 0x05, > 0xf9, 0x0e, 0x0e, 0x20, 0x00, 0x00, 0x00, > 0x00, Reviewed-by: Guido Günther -- Guido > -- > 2.43.0 >
Re: [PATCH RESEND 1/1] drm/panel: st7703: Fix Panel Initialization for Anbernic RG353V-V2
Hi Ao, this doesn't say why that was changed but your cover letter has that information: > After correcting these parameters by referencing the > device tree in JELOS (which uses the BSP kernel for RK3566), the panel > started to work properly. Can you add that to the commit message and maybe add an URL as reference please? I've added Chris to the cc: list. He submitted the original rg353v2 and we don't want to break other devices. Chris, do you have any means to check these values? Cheers, -- Guido On Sun, Jan 28, 2024 at 03:10:48AM +0100, Ao Zhong wrote: > This patch resolves the issue with the panel initialization of the > Anbernic RG353V-V2 caused by incorrect parameters. > > Signed-off-by: Ao Zhong > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index b55bafd1a8be..a346d6c3d283 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -357,8 +357,8 @@ static int rg353v2_init_sequence(struct st7703 *ctx) > 0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00); > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80); > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x0a, 0x0a); > - mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x92, 0x92); > - mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22, > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x7f, 0x7f); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x26, 0x62, > 0xf0, 0x63); > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, 0x33, 0x81, 0x05, > 0xf9, 0x0e, 0x0e, 0x20, 0x00, 0x00, 0x00, 0x00, > -- > 2.43.0 >
Re: [PATCH 3/5] drm/panel: st7703: Add Powkiddy RGB30 Panel Support
Hi Chris,
On Fri, Oct 13, 2023 at 01:39:16PM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> The Powkiddy RGB30 4 inch panel is a 4 inch 720x720 DSI panel used in
> the Powkiddy RGB30 handheld gaming device. Add support for it.
>
> TODO: The panel seems to not resume properly from suspend. I've
> confirmed on the other ST7703 based devices it works correctly.
Regarding drm-misc-next has improvements regarding this prompted by the
PinePhone. Maybe that fixes suspend for you too?
Cheers,
-- Guido
>
> Signed-off-by: Chris Morgan
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 89 +++
> 1 file changed, 89 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6a3945639535..a9892a4447fb 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -433,6 +433,94 @@ static const struct st7703_panel_desc rg353v2_desc = {
> .init_sequence = rg353v2_init_sequence,
> };
>
> +static int rgb30panel_init_sequence(struct st7703 *ctx)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + /* Init sequence extracted from Powkiddy RGB30 BSP kernel. */
> +
> + /*
> + * For some reason this specific panel must be taken out of sleep
> + * before the full init sequence, or else it will not display.
> + */
> + mipi_dsi_dcs_exit_sleep_mode(dsi);
> + msleep(250);
> +
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xf1, 0x12, 0x83);
> + mipi_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, 0x90, 0x0a, 0x00,
> +0x00, 0x01, 0x4f, 0x01, 0x00, 0x00, 0x37);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22, 0xf0,
> +0x63);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, 0x10, 0x10, 0x28,
> +0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, 0x73, 0x73, 0x50, 0x50,
> +0x00, 0x00, 0x12, 0x70, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x46);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0b);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0x3c, 0x12, 0x30);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ, 0x07, 0x07, 0x0b, 0x0b,
> +0x03, 0x0b, 0x00, 0x00, 0x00, 0x00, 0xff, 0x00,
> +0xc0, 0x10);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, 0x36, 0x00, 0x32,
> +0x32, 0x77, 0xf1, 0xcc, 0xcc, 0x77, 0x77, 0x33,
> +0x33);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x0a, 0x0a);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x88, 0x88);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, 0xc8, 0x10, 0x0a, 0x10,
> +0x0f, 0xa1, 0x80, 0x12, 0x31, 0x23, 0x47, 0x86,
> +0xa1, 0x80, 0x47, 0x08, 0x00, 0x00, 0x0d, 0x00,
> +0x00, 0x00, 0x00, 0x00, 0x0d, 0x00, 0x00, 0x00,
> +0x48, 0x02, 0x8b, 0xaf, 0x46, 0x02, 0x88, 0x88,
> +0x88, 0x88, 0x88, 0x48, 0x13, 0x8b, 0xaf, 0x57,
> +0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x00, 0x00,
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, 0x96, 0x12, 0x01, 0x01,
> +0x01, 0x78, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x4f, 0x31, 0x8b, 0xa8, 0x31, 0x75, 0x88, 0x88,
> +0x88, 0x88, 0x88, 0x4f, 0x20, 0x8b, 0xa8, 0x20,
> +0x64, 0x88, 0x88, 0x88, 0x88, 0x88, 0x23, 0x00,
> +0x00, 0x01, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +0x00, 0x00, 0x40, 0xa1, 0x80, 0x00, 0x00, 0x00,
> +0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, 0x00, 0x0a, 0x0f,
> +0x29, 0x3b, 0x3f, 0x42, 0x39, 0x06, 0x0d, 0x10,
> +0x13, 0x15, 0x14, 0x15, 0x10, 0x17, 0x00, 0x0a,
> +0x0f, 0x29, 0x3b, 0x3f, 0x42, 0x39, 0x06, 0x0d,
> +0x10, 0x13, 0x15, 0x14, 0x15, 0x10, 0x17);
> +
> + return 0;
> +}
> +
> +static const struct drm_display_mode
Re: [PATCH v2 1/1] drm/panel: st7703: Fix timings when entering/exiting sleep
Hi,
On Mon, Feb 13, 2023 at 01:32:38PM +0100, Frank Oltmanns wrote:
> Fix flickering of the pinephone's XDB599 panel that happens after
> resume.
>
> Extend the delay after issuing the command to exit sleep mode from 60 to
> 120 msec as per the controller's specification.
>
> Introduce a 120 msec delay after issuing the command to enter sleep
> mode. This is needed in order for the controller to reliably finalize
> the sleep in sequence before switching of power supply.
>
> In contrast to the JH057N panel, the XBD599 panel does not require a 20
> msec delay after initialization and exiting sleep mode. Therefore, move
> the delay into the already existing device specific initialization
> function.
>
> The XDB599 does not require a 20 msec delay between the SETBGP and
> SETVCOM commands. Therefore, remove the delay from the device specific
> initialization function.
Thanks. Applied to drm-misc-next.
Cheers,
-- Guido
> Signed-off-by: Frank Oltmanns
> Cc: Ondrej Jirman
> Reported-by: Samuel Holland
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..c49f4ef883fc 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -126,6 +126,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x18, 0x00, 0x09, 0x0E, 0x29, 0x2D, 0x3C,
> 0x41,
> 0x37, 0x07, 0x0B, 0x0D, 0x10, 0x11, 0x0F,
> 0x10,
> 0x11, 0x18);
> + msleep(20);
>
> return 0;
> }
> @@ -273,7 +274,6 @@ static int xbd599_init_sequence(struct st7703 *ctx)
> mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP,
> 0x07, /* VREF_SEL = 4.2V */
> 0x07 /* NVREF_SEL = 4.2V */);
> - msleep(20);
>
> mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM,
> 0x2C, /* VCOMDC_F = -0.67V */
> @@ -350,16 +350,14 @@ static int st7703_enable(struct drm_panel *panel)
> return ret;
> }
>
> - msleep(20);
> -
> ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> if (ret < 0) {
> dev_err(ctx->dev, "Failed to exit sleep mode: %d\n", ret);
> return ret;
> }
>
> - /* Panel is operational 120 msec after reset */
> - msleep(60);
> + /* It takes the controller 120 msec to wake up after sleep. */
> + msleep(120);
>
> ret = mipi_dsi_dcs_set_display_on(dsi);
> if (ret)
> @@ -384,6 +382,9 @@ static int st7703_disable(struct drm_panel *panel)
> if (ret < 0)
> dev_err(ctx->dev, "Failed to enter sleep mode: %d\n", ret);
>
> + /* It takes the controller 120 msec to enter sleep mode. */
> + msleep(120);
> +
> return 0;
> }
>
> --
> 2.39.1
>
Re: [PATCH 1/1] drm/panel: st7703: Pick different reset sequence
Hi,
On Sat, Feb 11, 2023 at 06:17:48PM +0100, Frank Oltmanns wrote:
> From: Ondrej Jirman
>
> Switching to a different reset sequence, enabling IOVCC before enabling
> VCC.
>
> There also needs to be a delay after enabling the supplies and before
> deasserting the reset. The datasheet specifies 1ms after the supplies
> reach the required voltage. Use 10-20ms to also give the power supplies
> some time to reach the required voltage, too.
>
> This fixes intermittent panel initialization failures and screen
> corruption during resume from sleep on panel xingbangda,xbd599 (e.g.
> used in PinePhone).
Thanks, applied to drm-misc-next.
Cheers,
-- Guido
>
> Signed-off-by: Ondrej Jirman
> Signed-off-by: Frank Oltmanns
> Reported-by: Samuel Holland
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 25 ++-
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..45695aa51f62 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -411,29 +411,30 @@ static int st7703_prepare(struct drm_panel *panel)
> return 0;
>
> dev_dbg(ctx->dev, "Resetting the panel\n");
> - ret = regulator_enable(ctx->vcc);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + ret = regulator_enable(ctx->iovcc);
> if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> return ret;
> }
> - ret = regulator_enable(ctx->iovcc);
> +
> + ret = regulator_enable(ctx->vcc);
> if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> - goto disable_vcc;
> + dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + regulator_disable(ctx->iovcc);
> + return ret;
> }
>
> - gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> - usleep_range(20, 40);
> + /* Give power supplies time to stabilize before deasserting reset. */
> + usleep_range(1, 2);
> +
> gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> - msleep(20);
> + usleep_range(15000, 2);
>
> ctx->prepared = true;
>
> return 0;
> -
> -disable_vcc:
> - regulator_disable(ctx->vcc);
> - return ret;
> }
>
> static const u32 mantix_bus_formats[] = {
> --
> 2.39.1
>
Re: [PATCH 1/1] drm/panel: st7703: Pick different reset sequence
Hi,
On Sat, Feb 11, 2023 at 06:17:48PM +0100, Frank Oltmanns wrote:
> From: Ondrej Jirman
>
> Switching to a different reset sequence, enabling IOVCC before enabling
> VCC.
>
> There also needs to be a delay after enabling the supplies and before
> deasserting the reset. The datasheet specifies 1ms after the supplies
> reach the required voltage. Use 10-20ms to also give the power supplies
> some time to reach the required voltage, too.
>
> This fixes intermittent panel initialization failures and screen
> corruption during resume from sleep on panel xingbangda,xbd599 (e.g.
> used in PinePhone).
>
> Signed-off-by: Ondrej Jirman
> Signed-off-by: Frank Oltmanns
> Reported-by: Samuel Holland
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 25 ++-
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..45695aa51f62 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -411,29 +411,30 @@ static int st7703_prepare(struct drm_panel *panel)
> return 0;
>
> dev_dbg(ctx->dev, "Resetting the panel\n");
> - ret = regulator_enable(ctx->vcc);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + ret = regulator_enable(ctx->iovcc);
> if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> return ret;
> }
> - ret = regulator_enable(ctx->iovcc);
> +
> + ret = regulator_enable(ctx->vcc);
> if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> - goto disable_vcc;
> + dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + regulator_disable(ctx->iovcc);
> + return ret;
> }
>
> - gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> - usleep_range(20, 40);
> + /* Give power supplies time to stabilize before deasserting reset. */
> + usleep_range(1, 2);
> +
> gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> - msleep(20);
> + usleep_range(15000, 2);
>
> ctx->prepared = true;
>
> return 0;
> -
> -disable_vcc:
> - regulator_disable(ctx->vcc);
> - return ret;
> }
>
> static const u32 mantix_bus_formats[] = {
Reviewed-by: Guido Günther
Cheers,
-- Guido
> --
> 2.39.1
>
Re: [PATCH RFC] dt-bindings: display: document display panel occlusions
Hi Caleb,
thanks for putting this out.
On Mon, Oct 09, 2023 at 06:32:50PM +0100, Caleb Connolly wrote:
> Some display panels found in modern phones and laptops feature
> non-standard display shapes with features like rounded corners, notches
> (sections of the display that are cut-out from the edge), and cutouts
> (such as circular "hole punch" camera cutouts, or wider pill-shaped
> "islands").
>
> Some discussion has been underway previously on how best to describe
> these features [1][2], including a reference userspace implementation
> using SVG paths [3]. Using this previous discussion as a jumping off
> point, this RFC allows for describing the following display features:
>
> * Corner radius (on a per-corner basis)
> * Circular or pill-shaped cutouts
> * Notches with arbitrary shapes
The coordinate systems is 0,0 at top,left display corner?
> It's easy to make a case for only using rectangles to describe these
> missing parts of a display, however this severely limits their utility.
> Describing display occlusions as accurately as possible allows for a lot of
> useful UX features. For example, displaying a ring around a hole-punch
> camera when it's in use, or wrapping UI elements around a notch. These
> behaviours are only possible to implement when the dimensions are known
> with near pixel-perfect accuracy.
>
> Cutouts are described as rectangles with a width, height, and corner
> radius.
> A radius of half the width longest edge will definitionally be an ellipse.
> This simple description is suitable for describing hole-punch cameras,
> as well
> as pill-shaped cutouts. I'm not aware of any devices that can't be
> described like this.
I wonder if we shouldn't just use a closed SVG path and put this and notches
in one bucket that way. We need to indicate the "type" of a notch/cutout
anyway as there's e.g. ones which aren't fully opaque but "just" lower
resolution areas. We could start out with one type "fully opaque".
> Notches are a little more complicated, they usually feature convex and
> concave corners as well as straight lines. Here they are described as a
> sequence of optionally disjoint arcs, where the space between one arc ending
> and another starting is inferred to be a straight line.
gmobile is using a subset of a closed SVG path (so does Android
afaik). The upside of "just arcs" would be that bounding box is even simpler
but as this affects userspace I think getting a better approximation
using a path would be worth it and we could treat it the same as
cutouts.
> Each arc is described with an X and Y pixel coordinate, a radius, and a
> start and end point in degrees. These arcs can precisely describe the
> shape of a notch, and easily allow for a basic bounding box to be
> derived using the min/max coordinates specified in the path.
>
> Some displays feature partially occluded edges ("waterfall edges") where
> the screen bends, it may be useful for user interfaces to avoid placing
> certain UI elements like buttons too close to these edges. These edges
> are described by a distance from the edge where it begins to be
> occluded, and the number of degrees that the display curves (this
> directly affects how usable this edge of the screen is).
I've not yet seen a device with this on Linux. Would it make sense to
leave it out until we have those coming. E.g. are all waterfalls the
same or are some more usable for displaying information than others?
What is your plan on informing userspace about that? Feed it through DRM
via drm properties or would userspace poke at /sys and try to find the
right panel for the connector? drm would have the upside of not being
bound to device-tree using platforms.
Cheers,
-- Guido
>
> [1]:
> https://lore.kernel.org/dri-devel/f8747f99-0695-5be0-841f-4f72ba5d5...@connolly.tech/
> [2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/87
> [3]: https://gitlab.gnome.org/World/Phosh/gmobile
>
> Signed-off-by: Caleb Connolly
> ---
> Some folks have previously suggested that this information belongs in
> userspace and not in devicetree. I would like to be clear that
> devicetree is for describing hardware, and parts of a display which can
> never actually be seen are very much properties of the underlying
> hardware.
> ---
> base-commit: 268c4b354d66908697299063c44c0b553b01d935
>
> // Caleb (they/them)
> ---
> .../bindings/display/panel/panel-common.yaml | 7 +
> .../bindings/display/panel/panel-occlusions.yaml | 182
> +
> 2 files changed, 189 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> index 0a57a31f4f3d..6ea52a031872 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -150,6 +150,13 @@ properties:
>controller, this property contains a phandle that
Re: [PATCH v2 1/1] drm/panel: st7703: Fix timings when entering/exiting sleep
Hi,
On Mon, Feb 13, 2023 at 01:32:38PM +0100, Frank Oltmanns wrote:
> Fix flickering of the pinephone's XDB599 panel that happens after
> resume.
>
> Extend the delay after issuing the command to exit sleep mode from 60 to
> 120 msec as per the controller's specification.
>
> Introduce a 120 msec delay after issuing the command to enter sleep
> mode. This is needed in order for the controller to reliably finalize
> the sleep in sequence before switching of power supply.
>
> In contrast to the JH057N panel, the XBD599 panel does not require a 20
> msec delay after initialization and exiting sleep mode. Therefore, move
> the delay into the already existing device specific initialization
> function.
>
> The XDB599 does not require a 20 msec delay between the SETBGP and
> SETVCOM commands. Therefore, remove the delay from the device specific
> initialization function.
>
> Signed-off-by: Frank Oltmanns
> Cc: Ondrej Jirman
> Reported-by: Samuel Holland
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..c49f4ef883fc 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -126,6 +126,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x18, 0x00, 0x09, 0x0E, 0x29, 0x2D, 0x3C,
> 0x41,
> 0x37, 0x07, 0x0B, 0x0D, 0x10, 0x11, 0x0F,
> 0x10,
> 0x11, 0x18);
> + msleep(20);
>
> return 0;
> }
> @@ -273,7 +274,6 @@ static int xbd599_init_sequence(struct st7703 *ctx)
> mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP,
> 0x07, /* VREF_SEL = 4.2V */
> 0x07 /* NVREF_SEL = 4.2V */);
> - msleep(20);
>
> mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM,
> 0x2C, /* VCOMDC_F = -0.67V */
> @@ -350,16 +350,14 @@ static int st7703_enable(struct drm_panel *panel)
> return ret;
> }
>
> - msleep(20);
> -
> ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> if (ret < 0) {
> dev_err(ctx->dev, "Failed to exit sleep mode: %d\n", ret);
> return ret;
> }
>
> - /* Panel is operational 120 msec after reset */
> - msleep(60);
> + /* It takes the controller 120 msec to wake up after sleep. */
> + msleep(120);
>
> ret = mipi_dsi_dcs_set_display_on(dsi);
> if (ret)
> @@ -384,6 +382,9 @@ static int st7703_disable(struct drm_panel *panel)
> if (ret < 0)
> dev_err(ctx->dev, "Failed to enter sleep mode: %d\n", ret);
>
> + /* It takes the controller 120 msec to enter sleep mode. */
> + msleep(120);
> +
> return 0;
> }
Tested this patch on a Librem 5 devkit.
Reviewed-by: Guido Günther
Tested-by: Guido Günther
Cheers,
-- Guido
>
> --
> 2.39.1
>
Re: [PATCH] dt-bindings: mxsfb: Exclude i.MX8MQ from power-domains requirement
Hi,
On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
> i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
> requirement of power-domains, thou it's not required.
>
> Fixes: f62678a77d58 ("dt-bindings: mxsfb: Document i.MX8M/i.MX6SX/i.MX6SL
> power-domains property")
>
> Signed-off-by: David Heidelberg
> ---
> .../devicetree/bindings/display/fsl,lcdif.yaml| 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index fc11ab5fc465..2d868276b0f9 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -129,8 +129,15 @@ allOf:
>- fsl,imx8mp-lcdif
>- fsl,imx93-lcdif
> then:
> - required:
> -- power-domains
> + if:
> +properties:
> + compatible:
> +not:
> + contains:
> +const: fsl,imx8mq-lcdif
> + then:
> +required:
> + - power-domains
>
> examples:
>- |
> --
> 2.40.1
>
Thanks a lot to Marek and Liu for confirming!
Acked-by: Guido Günther
Cheers,
-- Guido
Re: [PATCH] drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY
Hi,
On Thu, Aug 03, 2023 at 08:01:37PM -0700, Randy Dunlap wrote:
> Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
> might not be set. This causes Kconfig warnings and a build error.
>
> WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
> Depends on [n]: GENERIC_PHY [=n]
> Selected by [y]:
> - DRM_NWL_MIPI_DSI [=y] && DRM_BRIDGE [=y] && DRM [=y] && COMMON_CLK [=y]
> && OF [=y] && HAS_IOMEM [=y]
> - DRM_SAMSUNG_DSIM [=y] && DRM [=y] && DRM_BRIDGE [=y] && COMMON_CLK [=y]
> && OF [=y] && HAS_IOMEM [=y]
>
> (drm/bridge/cadence/Kconfig was found by inspection.)
>
> aarch64-linux-ld: drivers/gpu/drm/bridge/samsung-dsim.o: in function
> `samsung_dsim_set_phy_ctrl':
> drivers/gpu/drm/bridge/samsung-dsim.c:731: undefined reference to
> `phy_mipi_dphy_get_default_config_for_hsclk'
>
> Prevent these warnings and build error by also selecting GENERIC_PHY
n> whenever selecting GENERIC_PHY_MIPI_DPHY.
>
> Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
> Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
> Fixes: 171b3b1e0f8b ("drm: bridge: samsung-dsim: Select
> GENERIC_PHY_MIPI_DPHY")
> Signed-off-by: Randy Dunlap
> Reported-by: Aleksandr Nogikh
> Link: lore.kernel.org/r/20230803144227.2187749-1-nog...@google.com
> Cc: Adam Ford
> Cc: Maxime Ripard
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Sam Ravnborg
> Cc: Neil Armstrong
> Cc: Andrzej Hajda
> Cc: Robert Foss
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/Kconfig |2 ++
> drivers/gpu/drm/bridge/cadence/Kconfig |1 +
> 2 files changed, 3 insertions(+)
>
> diff -- a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -4,6 +4,7 @@ config DRM_CDNS_DSI
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL_BRIDGE
> + select GENERIC_PHY
> select GENERIC_PHY_MIPI_DPHY
> depends on OF
> help
> diff -- a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -181,6 +181,7 @@ config DRM_NWL_MIPI_DSI
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL_BRIDGE
> + select GENERIC_PHY
> select GENERIC_PHY_MIPI_DPHY
> select MFD_SYSCON
> select MULTIPLEXER
> @@ -227,6 +228,7 @@ config DRM_SAMSUNG_DSIM
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL_BRIDGE
> + select GENERIC_PHY
> select GENERIC_PHY_MIPI_DPHY
> help
> The Samsung MIPI DSIM bridge controller driver.
>
For NWL:
Reviewed-by: Guido Günther
Cheers,
-- Guido
Re: [PATCH] dt-bindings: mxsfb: Exclude i.MX8MQ from power-domains requirement
Hi,
On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
> i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
> requirement of power-domains, thou it's not required.
>
> Fixes: f62678a77d58 ("dt-bindings: mxsfb: Document i.MX8M/i.MX6SX/i.MX6SL
> power-domains property")
>
> Signed-off-by: David Heidelberg
> ---
> .../devicetree/bindings/display/fsl,lcdif.yaml| 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index fc11ab5fc465..2d868276b0f9 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -129,8 +129,15 @@ allOf:
>- fsl,imx8mp-lcdif
>- fsl,imx93-lcdif
> then:
> - required:
> -- power-domains
> + if:
> +properties:
> + compatible:
> +not:
> + contains:
> +const: fsl,imx8mq-lcdif
> + then:
> +required:
> + - power-domains
We currently enable the mipi power domain for the mipi dphy and nwl
bridge only but not for LCDIF itself assuming it's not needed (as there's
other outputs LCDIF can drive). I *think* this is correct but maybe
Marek or Liu can confirm?
Cheers,
-- Guido
>
> examples:
>- |
> --
> 2.40.1
>
Re: [PATCH V3 1/3] dt-bindings: panel: Add Anbernic RG353V-V2 panel compatible
Hi Chris, could you check if these two modifications by Frank of the init sequence https://lore.kernel.org/dri-devel/20230211171748.36692-2-fr...@oltmanns.dev/ https://lore.kernel.org/dri-devel/20230213123238.76889-2-fr...@oltmanns.dev/ work for your panel too? Cheers, -- Guido On Wed, Apr 26, 2023 at 09:32:11AM -0500, Chris Morgan wrote: > From: Chris Morgan > > The Anbernic RG353V-V2 panel is a 3.5 inch 640x480 MIPI-DSI LCD panel. > It's based on the ST7703 LCD controller just like rocktech,jh057n00900. > It's used in a 2nd revision of the Anbernic RG353V handheld gaming > device. Like the first revision of the RG353V the control chip is known > but the panel itself is unknown, so name it for the device. > > Signed-off-by: Chris Morgan > Acked-by: Krzysztof Kozlowski > Acked-by: Guido Günther > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > index 09b5eb7542f8..150e81090af2 100644 > --- > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > @@ -20,6 +20,8 @@ allOf: > properties: >compatible: > enum: > + # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel > + - anbernic,rg353v-panel-v2 ># Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel >- rocktech,jh057n00900 ># Xingbangda XBD599 5.99" 720x1440 TFT LCD panel > -- > 2.34.1 > On Wed, Apr 26, 2023 at 09:32:12AM -0500, Chris Morgan wrote: > From: Chris Morgan > > A later revision of the datasheet for the ST7703 refers to this command > as "SETECO". > > Signed-off-by: Chris Morgan > Reviewed-by: Guido Günther > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index 6747ca237ced..fc55b5fbb67f 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -41,8 +41,8 @@ > #define ST7703_CMD_UNKNOWN_BF 0xBF > #define ST7703_CMD_SETSCR 0xC0 > #define ST7703_CMD_SETPOWER 0xC1 > +#define ST7703_CMD_SETECO 0xC6 > #define ST7703_CMD_SETPANEL 0xCC > -#define ST7703_CMD_UNKNOWN_C6 0xC6 > #define ST7703_CMD_SETGAMMA 0xE0 > #define ST7703_CMD_SETEQ 0xE3 > #define ST7703_CMD_SETGIP10xE9 > @@ -249,8 +249,7 @@ static int xbd599_init_sequence(struct st7703 *ctx) > * ESD_DET_TIME_SEL = 0 frames > */); > > - /* Undocumented command. */ > - mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_C6, 0x01, 0x00, 0xFF, > 0xFF, 0x00); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x01, 0x00, 0xFF, 0xFF, > 0x00); > > mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, > 0x74, /* VBTHS, VBTLS: VGH = 17V, VBL = -11V */ > -- > 2.34.1 > On Wed, Apr 26, 2023 at 09:32:13AM -0500, Chris Morgan wrote: > From: Chris Morgan > > The Anbernic RG353V-V2 is a 5 inch panel used in a new revision of the > Anbernic RG353V handheld gaming device. Add support for it. > > Unfortunately it appears this controller is not able to support 120hz > or 100hz mode like the first revision panel. > > Signed-off-by: Chris Morgan > Reviewed-by: Guido Günther > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 97 +++ > 1 file changed, 97 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index fc55b5fbb67f..3aa31f3d6157 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -28,6 +28,7 @@ > /* Manufacturer specific Commands send via DSI */ > #define ST7703_CMD_ALL_PIXEL_OFF 0x22 > #define ST7703_CMD_ALL_PIXEL_ON 0x23 > +#define ST7703_CMD_SETAPID0xB1 > #define ST7703_CMD_SETDISP0xB2 > #define ST7703_CMD_SETRGBIF 0xB3 > #define ST7703_CMD_SETCYC 0xB4 > @@ -42,11 +43,14 @@ > #define ST7703_CMD_SETSCR 0xC0 > #define ST7703_CMD_SETPOWER 0xC1 > #define ST7703_CMD_SETECO 0xC6 > +#define ST7703_CMD_SETIO 0xC7 > +#define ST7703_CMD_SETCABC0xC8 > #define ST7703_CMD_SETPANEL 0xCC > #define ST7703_CMD_SETGAMMA 0xE0 > #define ST7703_CMD_SETE
Re: [PATCH 1/1] drm/panel: st7703: Fix vertical refresh rate of XBD599
Hi,
On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote:
> Fix the XBD599 panel's slight visual stutter by correcting the pixel
> clock speed so that the panel's 60Hz vertical refresh rate is met.
>
> Set the clock speed using the underlying formula instead of a magic
> number. To have a consistent procedure for both panels, set the JH057N
> panel's clock also as a formula.
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..cd7d631f7573 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = {
> .vsync_start = 1440 + 20,
> .vsync_end = 1440 + 20 + 4,
> .vtotal = 1440 + 20 + 4 + 12,
> - .clock = 75276,
> + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 65,
> .height_mm = 130,
> @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = {
> .vsync_start = 1440 + 18,
> .vsync_end = 1440 + 18 + 10,
> .vtotal = 1440 + 18 + 10 + 17,
> - .clock = 69000,
> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 68,
> .height_mm = 136,
Reviewed-by: Guido Günther
(I've seen your other patches but it will be some days until I can test
the jh057n00900 panel).
Cheers,
-- Guido
> --
> 2.39.1
>
Re: [PATCH 0/1] drm/panel: st7703: Fix initialization failures on Xingbangda XBD599
Hi Frank, Thanks for giving this another spin! On Sat, Feb 11, 2023 at 06:17:47PM +0100, Frank Oltmanns wrote: > This patch fixes intermittent panel initialization failures and screen > corruption during resume from sleep on panel xingbangda,xbd599 (e.g. > used in PinePhone). > > It was originally submitted by Ondrej Jirman in July 2020: > https://lore.kernel.org/all/20200716123753.3552425-1-meg...@megous.com/ > > The original patchset contained two patches. One of them broke the panel > on the Purism Librem 5. Just for completeness: It's the Librem 5 Devkit, the Librem 5 uses the mantix,mlaf057we51-x panel. > This is the concluding message from Guido Günther in that thread: > https://lore.kernel.org/all/20200801110409.ga6...@bogon.m.sigxcpu.org/#t > > Guido wanted changes to the commit message. I updated it to adress his > requests. > > I send this patch in Ondřej's name with his consent. > > The patch is based on drm-next. > > Please let me know what you think. I'll retest this on the devkit on the next days, might be a moment until I get to that. Cheers, -- Guido
Re: [PATCH 2/2] drm/panel: st7703: Add support for Anbernic RG353V-V2 panel
Hi,
On Thu, Jan 19, 2023 at 05:04:15PM -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> The Anbernic RG353V-V2 is a 5 inch panel used in a new revision of the
> Anbernic RG353V handheld gaming device. Add support for it.
>
> Unfortunately it appears this controller is not able to support 120hz
> or 100hz mode like the first revision panel.
>
> Signed-off-by: Chris Morgan
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 102 +-
> 1 file changed, 99 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 86a472b01360..2ed0cdfa86de 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -28,6 +28,7 @@
> /* Manufacturer specific Commands send via DSI */
> #define ST7703_CMD_ALL_PIXEL_OFF 0x22
> #define ST7703_CMD_ALL_PIXEL_ON 0x23
> +#define ST7703_CMD_SETAPID0xB1
> #define ST7703_CMD_SETDISP0xB2
> #define ST7703_CMD_SETRGBIF 0xB3
> #define ST7703_CMD_SETCYC 0xB4
> @@ -41,12 +42,15 @@
> #define ST7703_CMD_UNKNOWN_BF 0xBF
> #define ST7703_CMD_SETSCR 0xC0
> #define ST7703_CMD_SETPOWER 0xC1
> +#define ST7703_CMD_SETECO 0xC6
> +#define ST7703_CMD_SETIO 0xC7
> +#define ST7703_CMD_SETCABC0xC8
> #define ST7703_CMD_SETPANEL 0xCC
> -#define ST7703_CMD_UNKNOWN_C6 0xC6
> #define ST7703_CMD_SETGAMMA 0xE0
> #define ST7703_CMD_SETEQ 0xE3
> #define ST7703_CMD_SETGIP10xE9
> #define ST7703_CMD_SETGIP20xEA
> +#define ST7703_CMD_UNKNOWN_EF 0xEF
>
> struct st7703 {
> struct device *dev;
> @@ -266,8 +270,7 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>* ESD_DET_TIME_SEL = 0 frames
>*/);
>
> - /* Undocumented command. */
> - dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_C6, 0x01, 0x00, 0xFF, 0xFF,
> 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x01, 0x00, 0xFF, 0xFF, 0x00);
Thanks for catching this! Would make sense to split that into a separate
commit. With that fixed
Reviewed-by: Guido Günther
-- Guido
>
> dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER,
> 0x74, /* VBTHS, VBTLS: VGH = 17V, VBL = -11V */
> @@ -355,6 +358,98 @@ static const struct st7703_panel_desc xbd599_desc = {
> .init_sequence = xbd599_init_sequence,
> };
>
> +static int rg353v2_init_sequence(struct st7703 *ctx)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + /*
> + * Init sequence was supplied by the panel vendor.
> + */
> +
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xf1, 0x12, 0x83);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETAPID, 0x00, 0x00, 0x00,
> +0xda, 0x80);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0x00, 0x13, 0x70);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, 0x10, 0x10, 0x28,
> +0x28, 0x03, 0xff, 0x00, 0x00, 0x00, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x0a, 0x0a);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x92, 0x92);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, 0x25, 0x22,
> +0xf0, 0x63);
> + mipi_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, 0x90, 0x0a,
> +0x00, 0x00, 0x01, 0x4f, 0x01, 0x00, 0x00, 0x37);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x47);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, 0x73, 0x73, 0x50, 0x50,
> +0x00, 0x00, 0x12, 0x50, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, 0x53, 0xc0, 0x32,
> +0x32, 0x77, 0xe1, 0xdd, 0xdd, 0x77, 0x77, 0x33,
> +0x33);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETECO, 0x82, 0x00, 0xbf, 0xff,
> +0x00, 0xff);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETIO, 0xb8, 0x00, 0x0a, 0x00,
> +0x00, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETCABC, 0x10, 0x40, 0x1e,
> +0x02);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0b);
> + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, 0x00, 0x07, 0x0d,
>
Re: [PATCH 1/2] dt-bindings: panel: Add compatible for Anbernic RG353V-V2 panel
Hi, On Thu, Jan 19, 2023 at 05:04:14PM -0600, Chris Morgan wrote: > From: Chris Morgan > > The Anbernic RG353V-V2 panel is a 5 inch 640x480 MIPI-DSI LCD panel. > It's based on the ST7703 LCD controller just like rocktech,jh057n00900. > It's used in a 2nd revision of the Anbernic RG353V handheld gaming > device. Like the first revision of the RG353V the control chip is known > but the panel itself is unknown, so name it for the device. > > Signed-off-by: Chris Morgan > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > index 09b5eb7542f8..150e81090af2 100644 > --- > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > @@ -20,6 +20,8 @@ allOf: > properties: >compatible: > enum: > + # Anberic RG353V-V2 5.0" 640x480 TFT LCD panel > + - anbernic,rg353v-panel-v2 ># Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel > - rocktech,jh057n00900 ># Xingbangda XBD599 5.99" 720x1440 TFT LCD panel Acked-by: Guido Günther Cheers, -- Guido > -- > 2.34.1 >
Re: [PATCH v2 02/13] drm/panel-sitronix-st7703: Drop custom DSI write macros
1.5MHz) */ > +0xCC, /* VGH2_L_DIV, VGL2_L_DIV (2.6MHz) */ > +0xCC, /* VGH2_R_DIV, VGL2_R_DIV (2.6MHz) */ > +0x77, /* VGH3_L_DIV, VGL3_L_DIV (4.5MHz) */ > +0x77 /* VGH3_R_DIV, VGL3_R_DIV (4.5MHz) */); > > /* Reference voltage. */ > - dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, > - 0x07, /* VREF_SEL = 4.2V */ > - 0x07 /* NVREF_SEL = 4.2V */); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, > +0x07, /* VREF_SEL = 4.2V */ > +0x07 /* NVREF_SEL = 4.2V */); > msleep(20); > > - dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, > - 0x2C, /* VCOMDC_F = -0.67V */ > - 0x2C /* VCOMDC_B = -0.67V */); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, > +0x2C, /* VCOMDC_F = -0.67V */ > +0x2C /* VCOMDC_B = -0.67V */); > > /* Undocumented command. */ > - dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00); > > /* This command is to set forward GIP timing. */ > - dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, > - 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12, > - 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38, > - 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00, > - 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88, > - 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64, > - 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > - 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, > +0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12, > +0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38, > +0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00, > +0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88, > +0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64, > +0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > +0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00); > > /* This command is to set backward GIP timing. */ > - dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, > - 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > - 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88, > - 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13, > - 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > - 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00, > - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A, > - 0xA5, 0x00, 0x00, 0x00, 0x00); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, > +0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > +0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88, > +0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13, > +0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > +0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00, > +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A, > +0xA5, 0x00, 0x00, 0x00, 0x00); > > /* Adjust the gamma characteristics of the panel. */ > - dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, > - 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35, > - 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12, > - 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, > - 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, > - 0x12, 0x18); > + mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, > +0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35, > +0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12, > +0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, > +0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, > +0x12, 0x18); > > return 0; > } > @@ -499,7 +482,7 @@ static int allpixelson_set(void *data, u64 val) > struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev); > > dev_dbg(ctx->dev, "Setting all pixels on\n"); > - dsi_generic_write_seq(dsi, ST7703_CMD_ALL_PIXEL_ON); > + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_ALL_PIXEL_ON); > msleep(val * 1000); > /* Reset the panel to get video back */ > drm_panel_disable(>panel); Reviewed-by: Guido Günther Cheers, -- Guido > -- > 2.38.1 >
Re: [PATCH v2 11/13] drm/panel-mantix-mlaf057we51: Drop custom DSI write macro
Hi,
On Sat, Jan 07, 2023 at 08:18:20PM +0100, Javier Martinez Canillas wrote:
> There is a macro for this already in the header, use
> that instead and delete the custom DSI write macro defined in the driver.
>
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Sam Ravnborg
> ---
>
> Changes in v2:
> - Add Sam Ravnborg's Reviewed-by tag.
>
> .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 24 +++
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> index 772e3b6acece..9243b2ad828d 100644
> --- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> @@ -45,14 +45,6 @@ static inline struct mantix *panel_to_mantix(struct
> drm_panel *panel)
> return container_of(panel, struct mantix, panel);
> }
>
> -#define dsi_generic_write_seq(dsi, seq...) do {
> \
> - static const u8 d[] = { seq }; \
> - int ret;\
> - ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> - if (ret < 0)\
> - return ret; \
> - } while (0)
> -
> static int mantix_init_sequence(struct mantix *ctx)
> {
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> @@ -61,18 +53,18 @@ static int mantix_init_sequence(struct mantix *ctx)
> /*
>* Init sequence was supplied by the panel vendor.
>*/
> - dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A);
> + mipi_dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A);
>
> - dsi_generic_write_seq(dsi, MANTIX_CMD_INT_CANCEL, 0x03);
> - dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x03);
> - dsi_generic_write_seq(dsi, 0x80, 0xA9, 0x00);
> + mipi_dsi_generic_write_seq(dsi, MANTIX_CMD_INT_CANCEL, 0x03);
> + mipi_dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A,
> 0x03);
> + mipi_dsi_generic_write_seq(dsi, 0x80, 0xA9, 0x00);
>
> - dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x09);
> - dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00, 0x64, 0x00, 0x00);
> + mipi_dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A,
> 0x09);
> + mipi_dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00, 0x64, 0x00, 0x00);
> msleep(20);
>
> - dsi_generic_write_seq(dsi, MANTIX_CMD_SPI_FINISH, 0xA5);
> - dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x00, 0x2F);
> + mipi_dsi_generic_write_seq(dsi, MANTIX_CMD_SPI_FINISH, 0xA5);
> + mipi_dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x00,
> 0x2F);
> msleep(20);
>
> dev_dbg(dev, "Panel init sequence done\n");
Would have been nice to be cc'ed on the changes to
include/drm/drm_mipi_dsi.h as well so one doesn't have to go and hunt
for changes on lore.kernel.org. Anyway:
Reviewed-by: Guido Günther
Cheers,
-- Guido
> --
> 2.38.1
>
Re: [PATCH 03/14] drm/panel-sitronix-st7703: Drop custom DSI write macros
Hi Javier,
Could you please also cc maintainers on the actual macro addition since
it's hard to review without seeing what the code gets changed to
(especially when there's multiple revisions). I assume
https://lore.kernel.org/dri-devel/20221228014757.3170486-2-javi...@redhat.com/
is the right one?
Cheers,
-- Guido
On Wed, Dec 28, 2022 at 02:47:46AM +0100, Javier Martinez Canillas wrote:
> There are macros for these already in the header, use
> that instead and delete the custom DSI write macros defined in the driver.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 83 ---
> 1 file changed, 33 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 86a472b01360..3e6655c2727e 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -73,14 +73,6 @@ static inline struct st7703 *panel_to_st7703(struct
> drm_panel *panel)
> return container_of(panel, struct st7703, panel);
> }
>
> -#define dsi_generic_write_seq(dsi, seq...) do {
> \
> - static const u8 d[] = { seq }; \
> - int ret;\
> - ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> - if (ret < 0)\
> - return ret; \
> - } while (0)
> -
> static int jh057n_init_sequence(struct st7703 *ctx)
> {
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> @@ -90,27 +82,27 @@ static int jh057n_init_sequence(struct st7703 *ctx)
>* resemble the ST7703 but the number of parameters often don't match
>* so it's likely a clone.
>*/
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETEXTC,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETEXTC,
> 0xF1, 0x12, 0x83);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETRGBIF,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETRGBIF,
> 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
> 0x00, 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETSCR,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETSCR,
> 0x73, 0x73, 0x50, 0x50, 0x00, 0x00, 0x08, 0x70,
> 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0x30);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETEQ,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETCYC, 0x80);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0x30);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETEQ,
> 0x07, 0x07, 0x0B, 0x0B, 0x03, 0x0B, 0x00, 0x00,
> 0x00, 0x00, 0xFF, 0x00, 0xC0, 0x10);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETBGP, 0x08, 0x08);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETBGP, 0x08, 0x08);
> msleep(20);
>
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETVCOM, 0x3F, 0x3F);
> - dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP1,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETVCOM, 0x3F, 0x3F);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11,
> 0x00);
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP1,
> 0x82, 0x10, 0x06, 0x05, 0x9E, 0x0A, 0xA5, 0x12,
> 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
> 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00,
> @@ -119,7 +111,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
> 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
> - dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP2,
> + mipi_dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP2,
> 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88,
> 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13,
> @@ -128,7 +120,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>
Re: [PATCH] drm/fourcc: add Vivante tile status modifiers
Hi,
On Fri, Sep 09, 2022 at 11:30:00AM +0200, Lucas Stach wrote:
> The tile status modifiers can be combined with all of the usual
> color buffer modifiers. When they are present an additional plane
> is added to the surfaces to share the tile status buffer. The
> TS modifiers describe the interpretation of the tag bits in this
> buffer.
>
> Signed-off-by: Lucas Stach
> ---
> include/uapi/drm/drm_fourcc.h | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0980678d502d..93b022498900 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -718,6 +718,35 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
>
> +/*
> + * Vivante TS (tile-status) buffer modifiers. They can be combined with all
> of
> + * the color buffer tiling modifiers defined above. When TS is present it's a
> + * separate buffer containing the clear/compression status of each tile. The
> + * modifiers are defined as VIVANTE_MOD_TS_c_s, where c is the color buffer
> + * tile size in bytes covered by one entry in the status buffer and s is the
> + * number of status bits per entry.
> + * We reserve the top 8 bits of the Vivante modifier space for tile status
> + * clear/compression modifiers, as future cores might add some more TS layout
> + * variations.
> + */
> +#define VIVANTE_MOD_TS_64_4 (1ULL << 48)
> +#define VIVANTE_MOD_TS_64_2 (2ULL << 48)
> +#define VIVANTE_MOD_TS_128_4 (3ULL << 48)
> +#define VIVANTE_MOD_TS_256_4 (4ULL << 48)
> +#define VIVANTE_MOD_TS_MASK (0xfULL << 48)
> +
> +/*
> + * Vivante compression modifiers. Those depend on a TS modifier being present
> + * as the TS bits get reinterpreted as compression tags instead of simple
> + * clear markers when compression is enabled.
> + */
> +#define VIVANTE_MOD_COMP_DEC400 (1ULL << 52)
> +#define VIVANTE_MOD_COMP_MASK (0xfULL << 52)
> +
> +/* Masking out the extension bits will yield the base modifier. */
> +#define VIVANTE_MOD_EXT_MASK (VIVANTE_MOD_TS_MASK | \
> + VIVANTE_MOD_COMP_MASK)
> +
> /* NVIDIA frame buffer modifiers */
>
> /*
Reviewed-by: Guido Günther
Cheers,
-- Guido
Re: [PATCH 2/2] drm/etnaviv: reap idle mapping if it doesn't match the softpin address
Hi,
On Thu, Jul 14, 2022 at 12:31:43PM +0200, Lucas Stach wrote:
> When a idle BO, which is held open by another process, gets freed by
> userspace and subsequently referenced again by e.g. importing it again,
> userspace may assign a different softpin VA than the last time around.
> As the kernel GEM object still exists, we likely have a idle mapping
> with the old VA still cached, if it hasn't been reaped in the meantime.
>
> As the context matches, we then simply try to resurrect this mapping by
> increasing the refcount. As the VA in this mapping does not match the
> new softpin address, we consequently fail the otherwise valid submit.
> Instead of failing, reap the idle mapping.
>
> Cc: sta...@vger.kernel.org # 5.19
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index cc386f8a7116..5cf13e52f7c9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -258,7 +258,12 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> if (mapping->use == 0) {
> mutex_lock(_context->lock);
> if (mapping->context == mmu_context)
> - mapping->use += 1;
> + if (va && mapping->iova != va) {
> + etnaviv_iommu_reap_mapping(mapping);
> + mapping = NULL;
> + } else {
> + mapping->use += 1;
> + }
> else
> mapping = NULL;
> mutex_unlock(_context->lock);
Reviewed-by: Guido Günther
Cheers,
-- Guido
> --
> 2.30.2
>
Re: [PATCH 1/2] drm/etnaviv: move idle mapping reaping into separate function
Hi,
On Thu, Jul 14, 2022 at 12:31:42PM +0200, Lucas Stach wrote:
> The same logic is already used in two different places and now
> it will also be needed outside of the compilation unit, so split
> it into a separate function.
>
> Cc: sta...@vger.kernel.org # 5.19
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 23 +++
> drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 1 +
> 2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index dc1aa738c4f1..55479cb8b1ac 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -135,6 +135,19 @@ static void etnaviv_iommu_remove_mapping(struct
> etnaviv_iommu_context *context,
> drm_mm_remove_node(>vram_node);
> }
>
> +void etnaviv_iommu_reap_mapping(struct etnaviv_vram_mapping *mapping)
> +{
> + struct etnaviv_iommu_context *context = mapping->context;
> +
> + lockdep_assert_held(>lock);
> + WARN_ON(mapping->use);
> +
> + etnaviv_iommu_remove_mapping(context, mapping);
> + etnaviv_iommu_context_put(mapping->context);
> + mapping->context = NULL;
> + list_del_init(>mmu_node);
> +}
> +
> static int etnaviv_iommu_find_iova(struct etnaviv_iommu_context *context,
> struct drm_mm_node *node, size_t size)
> {
> @@ -202,10 +215,7 @@ static int etnaviv_iommu_find_iova(struct
> etnaviv_iommu_context *context,
>* this mapping.
>*/
> list_for_each_entry_safe(m, n, , scan_node) {
> - etnaviv_iommu_remove_mapping(context, m);
> - etnaviv_iommu_context_put(m->context);
> - m->context = NULL;
> - list_del_init(>mmu_node);
> + etnaviv_iommu_reap_mapping(m);
> list_del_init(>scan_node);
> }
>
> @@ -257,10 +267,7 @@ static int etnaviv_iommu_insert_exact(struct
> etnaviv_iommu_context *context,
> }
>
> list_for_each_entry_safe(m, n, _list, scan_node) {
> - etnaviv_iommu_remove_mapping(context, m);
> - etnaviv_iommu_context_put(m->context);
> - m->context = NULL;
> - list_del_init(>mmu_node);
> + etnaviv_iommu_reap_mapping(m);
> list_del_init(>scan_node);
> }
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> index e4a0b7d09c2e..c01a147f0dfd 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
> @@ -91,6 +91,7 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu_context
> *context,
> struct etnaviv_vram_mapping *mapping, u64 va);
> void etnaviv_iommu_unmap_gem(struct etnaviv_iommu_context *context,
> struct etnaviv_vram_mapping *mapping);
> +void etnaviv_iommu_reap_mapping(struct etnaviv_vram_mapping *mapping);
>
> int etnaviv_iommu_get_suballoc_va(struct etnaviv_iommu_context *ctx,
> struct etnaviv_vram_mapping *mapping,
Reviewed-by: Guido Günther
Cheers,
-- Guido
> --
> 2.30.2
>
Re: [PATCH resend v8 1/5] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_mode_set()
Hi Liu,
On Fri, Apr 29, 2022 at 08:30:43PM +0800, Liu Ying wrote:
> Hi,
>
> On Fri, 2022-04-22 at 19:24 +0200, Guido Günther wrote:
> > Hi,
> > On Tue, Apr 19, 2022 at 09:08:48AM +0800, Liu Ying wrote:
> > > The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> > > works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> > > a MIPI DSI display or a LVDS display. So, this patch calls
> > > phy_set_mode() from nwl_dsi_mode_set() to set PHY mode to MIPI DPHY
> > > explicitly.
> > >
> > > Cc: Guido Günther
> > > Cc: Robert Chiras
> > > Cc: Martin Kepplinger
> > > Cc: Andrzej Hajda
> > > Cc: Neil Armstrong
> > > Cc: Laurent Pinchart
> > > Cc: Jonas Karlman
> > > Cc: Jernej Skrabec
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > Cc: NXP Linux Team
> > > Signed-off-by: Liu Ying
>
> Hope this patch won't fall through the cracks.
> Can someone please apply it to drm-misc-next? Robert?
Applied to drm-misc-next.
Cheers,
-- Guido
>
> Thanks,
> Liu Ying
>
> > > ---
> > > v7->v8:
> > > * Resend with Andrzej's and Jernej's mail addressed updated.
> > >
> > > v6->v7:
> > > * No change.
> > >
> > > v5->v6:
> > > * Rebase the series upon v5.17-rc1.
> > > * Set PHY mode in ->mode_set() instead of ->pre_enable() in the
> > > nwl-dsi
> > > bridge driver due to the rebase.
> > > * Drop Guido's R-b tag due to the rebase.
> > >
> > > v4->v5:
> > > * No change.
> > >
> > > v3->v4:
> > > * No change.
> > >
> > > v2->v3:
> > > * No change.
> > >
> > > v1->v2:
> > > * Add Guido's R-b tag.
> > >
> > > drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> > > b/drivers/gpu/drm/bridge/nwl-dsi.c
> > > index d5945501a5ee..85bab7372af1 100644
> > > --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> > > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > > @@ -666,6 +666,12 @@ static int nwl_dsi_mode_set(struct nwl_dsi
> > > *dsi)
> > > return ret;
> > > }
> > >
> > > + ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
> > > + if (ret < 0) {
> > > + DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n",
> > > ret);
> > > + goto uninit_phy;
> > > + }
> > > +
> > > ret = phy_configure(dsi->phy, phy_cfg);
> > > if (ret < 0) {
> > > DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n",
> > > ret);
> >
> > I can't currently test this but it still looks good so
> >
> > Reviewed-by: Guido Günther
> >
> > Cheers,
> > -- Guido
> >
> > > --
> > > 2.25.1
> > >
>
Re: [PATCH resend v8 1/5] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_mode_set()
Hi,
On Tue, Apr 19, 2022 at 09:08:48AM +0800, Liu Ying wrote:
> The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> a MIPI DSI display or a LVDS display. So, this patch calls
> phy_set_mode() from nwl_dsi_mode_set() to set PHY mode to MIPI DPHY
> explicitly.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Martin Kepplinger
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> v7->v8:
> * Resend with Andrzej's and Jernej's mail addressed updated.
>
> v6->v7:
> * No change.
>
> v5->v6:
> * Rebase the series upon v5.17-rc1.
> * Set PHY mode in ->mode_set() instead of ->pre_enable() in the nwl-dsi
> bridge driver due to the rebase.
> * Drop Guido's R-b tag due to the rebase.
>
> v4->v5:
> * No change.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Add Guido's R-b tag.
>
> drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index d5945501a5ee..85bab7372af1 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -666,6 +666,12 @@ static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
> return ret;
> }
>
> + ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n", ret);
> + goto uninit_phy;
> + }
> +
> ret = phy_configure(dsi->phy, phy_cfg);
> if (ret < 0) {
> DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n",
> ret);
I can't currently test this but it still looks good so
Reviewed-by: Guido Günther
Cheers,
-- Guido
> --
> 2.25.1
>
Re: [PATCH v7 1/5] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_mode_set()
Hi,
On Thu, Apr 14, 2022 at 02:48:54PM +0800, Liu Ying wrote:
> The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> a MIPI DSI display or a LVDS display. So, this patch calls
> phy_set_mode() from nwl_dsi_mode_set() to set PHY mode to MIPI DPHY
> explicitly.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Martin Kepplinger
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> v6->v7:
> * No change.
>
> v5->v6:
> * Rebase the series upon v5.17-rc1.
> * Set PHY mode in ->mode_set() instead of ->pre_enable() in the nwl-dsi
> bridge driver due to the rebase.
> * Drop Guido's R-b tag due to the rebase.
>
> v4->v5:
> * No change.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Add Guido's R-b tag.
>
> drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index d5945501a5ee..85bab7372af1 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -666,6 +666,12 @@ static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
> return ret;
> }
>
> + ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n", ret);
> + goto uninit_phy;
> + }
> +
> ret = phy_configure(dsi->phy, phy_cfg);
> if (ret < 0) {
> DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n", ret);
> --
> 2.25.1
>
Reviewed-by: Guido Günther
Cheers,
-- Guido
Re: [PATCH 1/4] drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem
Hi Lucas,
On Wed, Mar 23, 2022 at 05:08:22PM +0100, Lucas Stach wrote:
> When the mapping is already reaped the unmap must be a no-op, as we
> would otherwise try to remove the mapping twice, corrupting the involved
> data structures.
>
> Cc: sta...@vger.kernel.org # 5.4
> Signed-off-by: Lucas Stach
Whole series
Tested-by: Guido Günther
Acked-by: Guido Günther
The code changes look good to me too but I got some details wrong too many times
for a `Reviewed-by:`
Cheers,
-- Guido
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index 9fb1a2aadbcb..aabb997a74eb 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -286,6 +286,12 @@ void etnaviv_iommu_unmap_gem(struct
> etnaviv_iommu_context *context,
>
> mutex_lock(>lock);
>
> + /* Bail if the mapping has been reaped by another thread */
> + if (!mapping->context) {
> + mutex_unlock(>lock);
> + return;
> + }
> +
> /* If the vram node is on the mm, unmap and remove the node */
> if (mapping->vram_node.mm == >mm)
> etnaviv_iommu_remove_mapping(context, mapping);
> --
> 2.30.2
>
Re: [PATCH] drm/bridge: nwl-dsi: Remove superfluous write to NWL_DSI_IRQ_MASK register
Hi Liu,
On Wed, Feb 16, 2022 at 04:58:42PM +0800, Liu Ying wrote:
> To initialize register NWL_DSI_IRQ_MASK, it's enough to write it
> only once in function nwl_dsi_init_interrupts().
>
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index af07eeb47ca0..fcc4a2889ad4 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -333,17 +333,13 @@ static int nwl_dsi_config_dpi(struct nwl_dsi *dsi)
>
> static int nwl_dsi_init_interrupts(struct nwl_dsi *dsi)
> {
> - u32 irq_enable;
> -
> - nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK, 0x);
> - nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK2, 0x7);
> -
> - irq_enable = ~(u32)(NWL_DSI_TX_PKT_DONE_MASK |
> - NWL_DSI_RX_PKT_HDR_RCVD_MASK |
> - NWL_DSI_TX_FIFO_OVFLW_MASK |
> - NWL_DSI_HS_TX_TIMEOUT_MASK);
> + u32 irq_enable = ~(u32)(NWL_DSI_TX_PKT_DONE_MASK |
> + NWL_DSI_RX_PKT_HDR_RCVD_MASK |
> + NWL_DSI_TX_FIFO_OVFLW_MASK |
> + NWL_DSI_HS_TX_TIMEOUT_MASK);
>
> nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK, irq_enable);
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK2, 0x7);
Works fine here. I thought it was due to some hw quirk but can't find
any note in it so:
Reviewed-by: Guido Günther
Thanks,
-- Guido
>
> return nwl_dsi_clear_error(dsi);
> }
> --
> 2.25.1
>
Re: [PATCH v2 2/8] drm: bridge: nwl-dsi: Switch to devm_drm_of_get_bridge
Hi,
On Tue, Mar 01, 2022 at 07:42:41PM +0530, Jagan Teki wrote:
> devm_drm_of_get_bridge is capable of looking up the downstream
> bridge and panel and trying to add a panel bridge if the panel
> is found.
>
> Replace explicit finding calls with devm_drm_of_get_bridge.
>
> Cc: Guido Günther
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - split the patch
>
> drivers/gpu/drm/bridge/nwl-dsi.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 30aacd939dc3..c9e108a7eca2 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -916,22 +916,10 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
> *bridge,
> {
> struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> struct drm_bridge *panel_bridge;
> - struct drm_panel *panel;
> - int ret;
> -
> - ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
> - _bridge);
> - if (ret)
> - return ret;
> -
> - if (panel) {
> - panel_bridge = drm_panel_bridge_add(panel);
> - if (IS_ERR(panel_bridge))
> - return PTR_ERR(panel_bridge);
> - }
>
> - if (!panel_bridge)
> - return -EPROBE_DEFER;
> + panel_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node, 1,
> 0);
> + if (IS_ERR(panel_bridge))
> + return PTR_ERR(panel_bridge);
>
> return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags);
> }
Reviewed-by: Guido Günther
Thanks,
-- Guido
> --
> 2.25.1
>
Re: [PATCH v2] phy: dphy: Correct clk_pre parameter
Hi,
On Wed, Jan 19, 2022 at 10:37:14AM +0800, Liu Ying wrote:
> The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE
> parameter's unit is Unit Interval(UI) and the minimum value is 8. Also,
> kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy
> mentions that it should be in UI. However, the dphy core driver wrongly
> sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds.
> And, the kernel doc of the 'clk_pre' member wrongly says the minimum value
> is '8 UI', instead of 8.
>
> So, let's fix both the dphy core driver and the kernel doc of the 'clk_pre'
> member to correctly reflect the T-CLK-PRE parameter's unit and the minimum
> value according to the D-PHY specification.
>
> I'm assuming that all impacted custom drivers shall program values in
> TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY
> specification mentions that the frequency of TxByteClkHS is exactly 1/8
> the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant
> custom driver code is changed to program those values as
> DIV_ROUND_UP(cfg->clk_pre, BITS_PER_BYTE), then.
>
> Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK.
> Help is needed to test with other i.MX8mq, Meson and Rockchip platforms,
> as I don't have the hardwares.
>
> Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options")
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Kevin Hilman
> Cc: Jerome Brunet
> Cc: Martin Blumenstingl
> Cc: Heiko Stuebner
> Cc: Maxime Ripard
> Cc: Guido Günther
> Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK
> Signed-off-by: Liu Ying
> ---
> v1->v2:
> * Use BITS_PER_BYTE macro. (Andrzej)
> * Drop dsi argument from ui2bc() in nwl-dsi.c.
>
> drivers/gpu/drm/bridge/nwl-dsi.c | 12 +---
> drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c| 3 ++-
> drivers/phy/phy-core-mipi-dphy.c | 4 ++--
> drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 3 ++-
> include/linux/phy/phy-mipi-dphy.h| 2 +-
> 5 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index a7389a0facfb..af07eeb47ca0 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -7,6 +7,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -196,12 +197,9 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long
> ps)
> /*
> * ui2bc - UI time periods to byte clock cycles
> */
> -static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
> +static u32 ui2bc(unsigned int ui)
> {
> - u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> -
> - return DIV64_U64_ROUND_UP(ui * dsi->lanes,
> - dsi->mode.clock * 1000 * bpp);
> + return DIV_ROUND_UP(ui, BITS_PER_BYTE);
> }
>
> /*
> @@ -232,12 +230,12 @@ static int nwl_dsi_config_host(struct nwl_dsi *dsi)
> }
>
> /* values in byte clock cycles */
> - cycles = ui2bc(dsi, cfg->clk_pre);
> + cycles = ui2bc(cfg->clk_pre);
> DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_pre: 0x%x\n", cycles);
> nwl_dsi_write(dsi, NWL_DSI_CFG_T_PRE, cycles);
> cycles = ps2bc(dsi, cfg->lpx + cfg->clk_prepare + cfg->clk_zero);
> DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap (pre): 0x%x\n", cycles);
> - cycles += ui2bc(dsi, cfg->clk_pre);
> + cycles += ui2bc(cfg->clk_pre);
> DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_post: 0x%x\n", cycles);
> nwl_dsi_write(dsi, NWL_DSI_CFG_T_POST, cycles);
> cycles = ps2bc(dsi, cfg->hs_exit);
> diff --git a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> index cd2332bf0e31..fdbd64c03e12 100644
> --- a/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> +++ b/drivers/phy/amlogic/phy-meson-axg-mipi-dphy.c
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -250,7 +251,7 @@ static int phy_meson_axg_mipi_dphy_power_on(struct phy
> *phy)
>(DIV_ROUND_UP(priv->config.clk_zero, temp) << 16) |
>(DIV_ROUND_UP(priv->config.clk_prepare, temp) << 24));
> regmap_write(priv->regmap, MIPI_DSI_CLK_TIM1,
> -
Re: [PATCH 1/3] drm: bridge: nwl-dsi: Drop panel_bridge from nwl_dsi
Hi,
On Fri, Dec 10, 2021 at 11:18:17PM +0530, Jagan Teki wrote:
> panel_bridge pointer never used anywhere except the one it
> looked up at nwl_dsi_bridge_attach.
>
> Drop it from the nwl_dsi structure.
>
> Cc: Guido Günther
> Signed-off-by: Jagan Teki
Reviewed-by: Guido Günther
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index a7389a0facfb..6becdcdc99fe 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -65,7 +65,6 @@ struct nwl_dsi_transfer {
> struct nwl_dsi {
> struct drm_bridge bridge;
> struct mipi_dsi_host dsi_host;
> - struct drm_bridge *panel_bridge;
> struct device *dev;
> struct phy *phy;
> union phy_configure_opts phy_cfg;
> @@ -924,13 +923,11 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
> *bridge,
> if (IS_ERR(panel_bridge))
> return PTR_ERR(panel_bridge);
> }
> - dsi->panel_bridge = panel_bridge;
>
> - if (!dsi->panel_bridge)
> + if (!panel_bridge)
> return -EPROBE_DEFER;
>
> - return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge,
> - flags);
> + return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags);
> }
>
> static void nwl_dsi_bridge_detach(struct drm_bridge *bridge)
> --
> 2.25.1
>
Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails
Hi Sam,
On Thu, Oct 14, 2021 at 09:35:20PM +0200, Sam Ravnborg wrote:
> Hi Guido,
>
> > > >
> > > > + if (ret != -EPROBE_DEFER) {
> > > > #ifdef CONFIG_OF
> > > > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > > > - bridge->of_node, encoder->name, ret);
> > > > + DRM_ERROR("failed to attach bridge %pOF to encoder %s:
> > > > %d\n",
> > > > + bridge->of_node, encoder->name, ret);
> > >
> > > It would be better to use drm_probe_err().
> >
> > That's what i thought initially but since the rest here uses DRM_*
> > logging i stuck with it. Happy to change that though.
>
> If we continue to use the deprecated DRM_ logging functions then we will
> never get rid of them. And then I like the simplicity of
> drm_probe_err().
I wasn't aware those are deprecated. I'll fix that up in case this patch
is needed, which
https://lore.kernel.org/dri-devel/camty3zasn4k0wfrc_fnn2mina0gsu4nc1y1zvsoz8gusqcq...@mail.gmail.com/
makes it a bit look like it.
Cheers,
-- Guido
>
> In the end it is up to you.
>
> Sam
>
[PATCH] drm/bridge: nwl-dsi: Move bridge add/remove to dsi callbacks
Move the panel and bridge_{add,remove} from the bridge callbacks to the
DSI callbacks to make sure we don't indicate readiness to participate in
the display pipeline before the panel is attached.
This was prompted by commit fb8d617f8fd6 ("drm/bridge: Centralize error
message when bridge attach fails") which triggered
[drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
during boot.
Signed-off-by: Guido Günther
---
This was prompted by the discussion at
https://lore.kernel.org/dri-devel/00493cc61d1443dab1c131c46c5890f95f6f9b25.1634068657.git@sigxcpu.org/
drivers/gpu/drm/bridge/nwl-dsi.c | 64 ++--
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a7389a0facfb..77aa6f13afef 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -355,6 +355,9 @@ static int nwl_dsi_host_attach(struct mipi_dsi_host
*dsi_host,
{
struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi, dsi_host);
struct device *dev = dsi->dev;
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
+ int ret;
DRM_DEV_INFO(dev, "lanes=%u, format=0x%x flags=0x%lx\n", device->lanes,
device->format, device->mode_flags);
@@ -362,10 +365,43 @@ static int nwl_dsi_host_attach(struct mipi_dsi_host
*dsi_host,
if (device->lanes < 1 || device->lanes > 4)
return -EINVAL;
+ ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
+ _bridge);
+ if (ret)
+ return ret;
+
+ if (panel) {
+ panel_bridge = drm_panel_bridge_add(panel);
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
+ }
+ if (!panel_bridge)
+ return -EPROBE_DEFER;
+
+ dsi->panel_bridge = panel_bridge;
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->dsi_mode_flags = device->mode_flags;
+ /*
+* The DSI output has been properly configured, we can now safely
+* register the input to the bridge framework so that it can take place
+* in a display pipeline.
+*/
+ drm_bridge_add(>bridge);
+
+ return 0;
+}
+
+static int nwl_dsi_host_detach(struct mipi_dsi_host *dsi_host,
+ struct mipi_dsi_device *dev)
+{
+ struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi, dsi_host);
+
+ drm_bridge_remove(>bridge);
+ if (dsi->panel_bridge)
+ drm_panel_bridge_remove(dsi->panel_bridge);
+
return 0;
}
@@ -632,6 +668,7 @@ static ssize_t nwl_dsi_host_transfer(struct mipi_dsi_host
*dsi_host,
static const struct mipi_dsi_host_ops nwl_dsi_host_ops = {
.attach = nwl_dsi_host_attach,
+ .detach = nwl_dsi_host_detach,
.transfer = nwl_dsi_host_transfer,
};
@@ -910,35 +947,11 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
*bridge,
enum drm_bridge_attach_flags flags)
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
- struct drm_bridge *panel_bridge;
- struct drm_panel *panel;
- int ret;
-
- ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
- _bridge);
- if (ret)
- return ret;
-
- if (panel) {
- panel_bridge = drm_panel_bridge_add(panel);
- if (IS_ERR(panel_bridge))
- return PTR_ERR(panel_bridge);
- }
- dsi->panel_bridge = panel_bridge;
-
- if (!dsi->panel_bridge)
- return -EPROBE_DEFER;
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge,
flags);
}
-static void nwl_dsi_bridge_detach(struct drm_bridge *bridge)
-{ struct nwl_dsi *dsi = bridge_to_dsi(bridge);
-
- drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
-}
-
static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
struct drm_bridge_state
*bridge_state,
struct drm_crtc_state
*crtc_state,
@@ -984,7 +997,6 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs =
{
.mode_set = nwl_dsi_bridge_mode_set,
.mode_valid = nwl_dsi_bridge_mode_valid,
.attach = nwl_dsi_bridge_attach,
- .detach = nwl_dsi_bridge_detach,
};
static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
@@ -1210,7 +1222,6 @@ static int nwl_dsi_probe(struct platform_device *pdev)
return ret;
Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails
Hi,
On Wed, Oct 13, 2021 at 08:48:32AM +0200, Andrzej Hajda wrote:
> On 12.10.2021 22:47, Guido Günther wrote:
> > Hi Laurent,
> > On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote:
> > > Hi Guido,
> > >
> > > Thank you for the patch.
> > >
> > > On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > > > Otherwise logs are filled with
> > > >
> > > >[drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > > > /soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
> > > >
> > > > when the bridge isn't ready yet.
> > > >
> > > > Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge
> > > > attach fails")
> > > > Signed-off-by: Guido Günther
> > > > ---
> > > > drivers/gpu/drm/drm_bridge.c | 11 ++-
> > > > 1 file changed, 6 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > > index a8ed66751c2d..f0508e85ae98 100644
> > > > --- a/drivers/gpu/drm/drm_bridge.c
> > > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > > @@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder
> > > > *encoder, struct drm_bridge *bridge,
> > > > bridge->encoder = NULL;
> > > > list_del(>chain_node);
> > > > + if (ret != -EPROBE_DEFER) {
> > > > #ifdef CONFIG_OF
> > > > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > > > - bridge->of_node, encoder->name, ret);
> > > > + DRM_ERROR("failed to attach bridge %pOF to encoder %s:
> > > > %d\n",
> > > > + bridge->of_node, encoder->name, ret);
> > > > #else
> > > > - DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > > > - encoder->name, ret);
> > > > + DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > > > + encoder->name, ret);
> > > > #endif
> > > > -
> > > > + }
> > >
> > > This looks fine as such, but I'm concerned about the direction it's
> > > taking. Ideally, probe deferral should happen at probe time, way before
> > > the bridge is attached. Doing otherwise is a step in the wrong direction
> > > in my opinion, and something we'll end up regretting when we'll feel the
> > > pain it inflicts.
> >
> > The particular case I'm seeing this is the nwl driver probe deferrals if
> > the panel bridge isn't ready (which needs a bunch of components
> > (dsi, panel, backlight wrapped led, ...) and it probes fine later on so I
> > wonder where you see the actual error cause? That downstream of the
> > bridge isn't ready or that the display controller is already attaching
> > the bridge?
>
> So it is something wrong there, nwl should not publish bridge interface
> until it gather its resources (the panel in this case).
That helps, I'll look at that. Thanks!
-- Guido
>
> Regards
> Andrzej
>
>
> >
> > Cheers,
> > -- Guido
> >
> > >
> > > > return ret;
> > > > }
> > > > EXPORT_SYMBOL(drm_bridge_attach);
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
> > >
>
Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails
Hi,
On Tue, Oct 12, 2021 at 10:47:14PM +0200, Guido Günther wrote:
> Hi Laurent,
> On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote:
> > Hi Guido,
> >
> > Thank you for the patch.
> >
> > On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > > Otherwise logs are filled with
> > >
> > > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > > /soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
> > >
> > > when the bridge isn't ready yet.
> > >
> > > Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge
> > > attach fails")
> > > Signed-off-by: Guido Günther
> > > ---
> > > drivers/gpu/drm/drm_bridge.c | 11 ++-
> > > 1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index a8ed66751c2d..f0508e85ae98 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder *encoder,
> > > struct drm_bridge *bridge,
> > > bridge->encoder = NULL;
> > > list_del(>chain_node);
> > >
> > > + if (ret != -EPROBE_DEFER) {
> > > #ifdef CONFIG_OF
> > > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > > - bridge->of_node, encoder->name, ret);
> > > + DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > > + bridge->of_node, encoder->name, ret);
> > > #else
> > > - DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > > - encoder->name, ret);
> > > + DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > > + encoder->name, ret);
> > > #endif
> > > -
> > > + }
> >
> > This looks fine as such, but I'm concerned about the direction it's
> > taking. Ideally, probe deferral should happen at probe time, way before
> > the bridge is attached. Doing otherwise is a step in the wrong direction
> > in my opinion, and something we'll end up regretting when we'll feel the
> > pain it inflicts.
>
> The particular case I'm seeing this is the nwl driver probe deferrals if
> the panel bridge isn't ready (which needs a bunch of components
> (dsi, panel, backlight wrapped led, ...) and it probes fine later on so I
> wonder where you see the actual error cause? That downstream of the
> bridge isn't ready or that the display controller is already attaching
> the bridge?
I should add that mxsfb does a `dev_err_probe()` already when checking
the return value of `drm_bridge_attach()` so the error printed is
triggered by the additional check added in the above function while the
code path already ignored -EPROBE_DEFER before. This looks sensible to
me since upper layers can't known when all the downstream bridges are
done probing or am I missing something?
Cheers,
-- Guido
>
> Cheers,
> -- Guido
>
> >
> > > return ret;
> > > }
> > > EXPORT_SYMBOL(drm_bridge_attach);
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails
Hi Laurent,
On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote:
> Hi Guido,
>
> Thank you for the patch.
>
> On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > Otherwise logs are filled with
> >
> > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
> >
> > when the bridge isn't ready yet.
> >
> > Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge
> > attach fails")
> > Signed-off-by: Guido Günther
> > ---
> > drivers/gpu/drm/drm_bridge.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index a8ed66751c2d..f0508e85ae98 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder *encoder,
> > struct drm_bridge *bridge,
> > bridge->encoder = NULL;
> > list_del(>chain_node);
> >
> > + if (ret != -EPROBE_DEFER) {
> > #ifdef CONFIG_OF
> > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > - bridge->of_node, encoder->name, ret);
> > + DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > + bridge->of_node, encoder->name, ret);
> > #else
> > - DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > - encoder->name, ret);
> > + DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > + encoder->name, ret);
> > #endif
> > -
> > + }
>
> This looks fine as such, but I'm concerned about the direction it's
> taking. Ideally, probe deferral should happen at probe time, way before
> the bridge is attached. Doing otherwise is a step in the wrong direction
> in my opinion, and something we'll end up regretting when we'll feel the
> pain it inflicts.
The particular case I'm seeing this is the nwl driver probe deferrals if
the panel bridge isn't ready (which needs a bunch of components
(dsi, panel, backlight wrapped led, ...) and it probes fine later on so I
wonder where you see the actual error cause? That downstream of the
bridge isn't ready or that the display controller is already attaching
the bridge?
Cheers,
-- Guido
>
> > return ret;
> > }
> > EXPORT_SYMBOL(drm_bridge_attach);
>
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails
Hi,
On Tue, Oct 12, 2021 at 10:08:28PM +0200, Sam Ravnborg wrote:
> Hi Guido,
>
> On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > Otherwise logs are filled with
> >
> > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
> >
> > when the bridge isn't ready yet.
> >
> > Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge
> > attach fails")
> > Signed-off-by: Guido Günther
> > ---
> > drivers/gpu/drm/drm_bridge.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index a8ed66751c2d..f0508e85ae98 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder *encoder,
> > struct drm_bridge *bridge,
> > bridge->encoder = NULL;
> > list_del(>chain_node);
> >
> > + if (ret != -EPROBE_DEFER) {
> > #ifdef CONFIG_OF
> > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > - bridge->of_node, encoder->name, ret);
> > + DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > + bridge->of_node, encoder->name, ret);
>
> It would be better to use drm_probe_err().
That's what i thought initially but since the rest here uses DRM_*
logging i stuck with it. Happy to change that though.
Cheers,
-- Guido
>
> Sam
>
> > #else
> > - DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > - encoder->name, ret);
> > + DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> > + encoder->name, ret);
> > #endif
> > -
> > + }
> > return ret;
> > }
> > EXPORT_SYMBOL(drm_bridge_attach);
> > --
> > 2.33.0
>
[PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails
Otherwise logs are filled with
[drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
when the bridge isn't ready yet.
Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge attach
fails")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/drm_bridge.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index a8ed66751c2d..f0508e85ae98 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
bridge->encoder = NULL;
list_del(>chain_node);
+ if (ret != -EPROBE_DEFER) {
#ifdef CONFIG_OF
- DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+ DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
+ bridge->of_node, encoder->name, ret);
#else
- DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+ DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
+ encoder->name, ret);
#endif
-
+ }
return ret;
}
EXPORT_SYMBOL(drm_bridge_attach);
--
2.33.0
Re: [PATCH v3 0/5] mxsfb/nwl/panels: media bus format fixes
Hi Sam,
On Mon, Oct 11, 2021 at 06:56:00PM +0200, Sam Ravnborg wrote:
> Hi Guido,
>
> On Mon, Oct 11, 2021 at 03:41:22PM +0200, Guido Günther wrote:
> > commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
> > present") added bus format probing to mxsfb this exposed several issues in
> > the
> > display stack as used on the Librem 5:
> >
> > The nwl bridge and the panels didn't bother to set any media bus formats
> > and in
> > that case mxsfb would not pick a reasonable default. This series aims to fix
> > this.
> >
> > This series includes the patch from
> > https://lore.kernel.org/dri-devel/yvlyh%2fsgbritg%2...@qwark.sigxcpu.org/
> > with a `dev_warn` added.
> >
> > The patches are against 5.15-rc3. I've marked a single patch with a 'fixes'
> > which is enough to unbreak the display stack in 5.15.
> >
> > All patches of this series can be applied independently.
> >
> > Changes from v1:
> > - Review comment by Marek Vasut
> >
> > https://lore.kernel.org/dri-devel/67e6056a-6157-795d-908d-d65cc803c...@denx.de/
> > Improve warning message
> > - Move mxsfb patches to the end of the queue and the actual nwl fix to the
> > front.
> >
> > Changes from v2:
> > - Review comments by Lucas Stach
> >
> > https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m961c22bf2a437a16b29214913d6f0d523fbe88e2
> > Drop fixes tag from mxsfb driver and tweak commit message
> > - Add Reviewed-by from Lucas
> >
> > https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m9f3337a673ae1adbb1f0152a48270b0e1104b0c1
> >
> > https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m5706d5b93cb6879b6bb4a1810b88800fe4180f74
> >
> > https://lore.kernel.org/dri-devel/cover.1633332399.git@sigxcpu.org/T/#m961c22bf2a437a16b29214913d6f0d523fbe88e2
> > - Add Reviewd-by from Rober Foss
> >
> > https://lore.kernel.org/dri-devel/cag3jfyteqcpnzqrfsggcrnpdfsggqvibfhbezw+1hcf3-z9...@mail.gmail.com/
> >
> >
> >
> > Guido Günther (5):
> > drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
> > drm/panel: mantix: Add media bus format
> > drm/panel: st7703: Add media bus format
> > drm: mxsfb: Print failed bus format in hex
> > drm: mxsfb: Set fallback bus format when the bridge doesn't provide
> > one
>
> Full series are:
> Reviewed-by: Sam Ravnborg
Pushed the whole series to drm-misc-next.
Thanks,
-- Guido
>
> Sam
>
[PATCH v3 5/5] drm: mxsfb: Set fallback bus format when the bridge doesn't provide one
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi dsi panels.
Reported-by: Martin Kepplinger
Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d6abd2077114..e3fbb8b58d5d 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -369,6 +369,12 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
bus_format = bridge_state->input_bus_cfg.format;
+ if (bus_format == MEDIA_BUS_FMT_FIXED) {
+ dev_warn_once(drm->dev,
+ "Bridge does not provide bus format,
assuming MEDIA_BUS_FMT_RGB888_1X24.\n"
+ "Please fix bridge driver by handling
atomic_get_input_bus_fmts.\n");
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ }
}
/* If there is no bridge, use bus format from connector */
--
2.33.0
[PATCH v3 4/5] drm: mxsfb: Print failed bus format in hex
media-bus-formats.h has them in hexadecimal as well so matching with that file saves one conversion when debugging. Signed-off-by: Guido Günther Reviewed-by: Lucas Stach Reviewed-by: Robert Foss --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index af6c620adf6e..d6abd2077114 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -89,7 +89,7 @@ static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb, ctrl |= CTRL_BUS_WIDTH_24; break; default: - dev_err(drm->dev, "Unknown media bus format %d\n", bus_format); + dev_err(drm->dev, "Unknown media bus format 0x%x\n", bus_format); break; } -- 2.33.0
[PATCH v3 2/5] drm/panel: mantix: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index f0e9bce23c41..d6bcf1045255 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -232,6 +233,10 @@ static const struct drm_display_mode default_mode_ys = {
.height_mm = 130,
};
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -253,6 +258,10 @@ static int mantix_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v3 3/5] drm/panel: st7703: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index a2c303e5732c..73f69c929a75 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -453,6 +453,10 @@ static int st7703_prepare(struct drm_panel *panel)
return ret;
}
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int st7703_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -474,6 +478,10 @@ static int st7703_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v3 1/5] drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially output (see chapter 13.6 of the i.MX 8MQ reference
manual) - which matches what xsfb can input.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/bridge/nwl-dsi.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a251cc1f088f..27c80d36846b 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -1234,6 +1234,40 @@ static void nwl_dsi_bridge_detach(struct drm_bridge
*bridge)
drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
}
+static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state
*crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts, input_fmt;
+
+ *num_input_fmts = 0;
+
+ switch (output_fmt) {
+ /* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
+ case MEDIA_BUS_FMT_FIXED:
+ input_fmt = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ input_fmt = output_fmt;
+ break;
+ default:
+ return NULL;
+ }
+
+ input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+ input_fmts[0] = input_fmt;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -1241,6 +1275,7 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs
= {
.atomic_check = nwl_dsi_bridge_atomic_check,
.atomic_enable = nwl_dsi_bridge_atomic_enable,
.atomic_disable = nwl_dsi_bridge_atomic_disable,
+ .atomic_get_input_bus_fmts = nwl_bridge_atomic_get_input_bus_fmts,
.mode_set = nwl_dsi_bridge_mode_set,
.mode_valid = nwl_dsi_bridge_mode_valid,
.attach = nwl_dsi_bridge_attach,
--
2.33.0
[PATCH v3 0/5] mxsfb/nwl/panels: media bus format fixes
commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present") added bus format probing to mxsfb this exposed several issues in the
display stack as used on the Librem 5:
The nwl bridge and the panels didn't bother to set any media bus formats and in
that case mxsfb would not pick a reasonable default. This series aims to fix
this.
This series includes the patch from
https://lore.kernel.org/dri-devel/yvlyh%2fsgbritg%2...@qwark.sigxcpu.org/
with a `dev_warn` added.
The patches are against 5.15-rc3. I've marked a single patch with a 'fixes'
which is enough to unbreak the display stack in 5.15.
All patches of this series can be applied independently.
Changes from v1:
- Review comment by Marek Vasut
https://lore.kernel.org/dri-devel/67e6056a-6157-795d-908d-d65cc803c...@denx.de/
Improve warning message
- Move mxsfb patches to the end of the queue and the actual nwl fix to the
front.
Changes from v2:
- Review comments by Lucas Stach
https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m961c22bf2a437a16b29214913d6f0d523fbe88e2
Drop fixes tag from mxsfb driver and tweak commit message
- Add Reviewed-by from Lucas
https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m9f3337a673ae1adbb1f0152a48270b0e1104b0c1
https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m5706d5b93cb6879b6bb4a1810b88800fe4180f74
https://lore.kernel.org/dri-devel/cover.162399.git@sigxcpu.org/T/#m961c22bf2a437a16b29214913d6f0d523fbe88e2
- Add Reviewd-by from Rober Foss
https://lore.kernel.org/dri-devel/cag3jfyteqcpnzqrfsggcrnpdfsggqvibfhbezw+1hcf3-z9...@mail.gmail.com/
Guido Günther (5):
drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
drm/panel: mantix: Add media bus format
drm/panel: st7703: Add media bus format
drm: mxsfb: Print failed bus format in hex
drm: mxsfb: Set fallback bus format when the bridge doesn't provide
one
drivers/gpu/drm/bridge/nwl-dsi.c | 35 +++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 -
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +
4 files changed, 59 insertions(+), 1 deletion(-)
--
2.33.0
Re: [PATCH v2 5/5] drm: mxsfb: Set proper default bus format when using a bridge
Hi,
On Mon, Oct 04, 2021 at 09:58:37AM +0200, Lucas Stach wrote:
> Am Montag, dem 04.10.2021 um 09:27 +0200 schrieb Guido Günther:
> > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
> > that case.
> >
> > This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
> >
> > Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
> > present")
> >
> I don't think this qualifies for stable, so I would drop this tag, as
> the stable maintainers are quite trigger happy to pull in patches with
> a fixes tag. Also the subject isn't quite correct, this isn't setting a
> "proper" bus format, but rather adds a fallback. Other than that:
Adjusted for v3 (which I'll hold off a bit in case there are more
comments) and dropped the Fixes: tag which is on the nwl driver
only now. thanks!
-- Guido
>
> Reviewed-by: Lucas Stach
>
> Regards,
> Lucas
>
> > Reported-by: Martin Kepplinger
> > Signed-off-by: Guido Günther
>
> > ---
> > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > index d6abd2077114..e3fbb8b58d5d 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > @@ -369,6 +369,12 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> > drm_atomic_get_new_bridge_state(state,
> > mxsfb->bridge);
> > bus_format = bridge_state->input_bus_cfg.format;
> > + if (bus_format == MEDIA_BUS_FMT_FIXED) {
> > + dev_warn_once(drm->dev,
> > + "Bridge does not provide bus format,
> > assuming MEDIA_BUS_FMT_RGB888_1X24.\n"
> > + "Please fix bridge driver by handling
> > atomic_get_input_bus_fmts.\n");
> > + bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > + }
> > }
> >
> > /* If there is no bridge, use bus format from connector */
>
>
[PATCH v2 5/5] drm: mxsfb: Set proper default bus format when using a bridge
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Reported-by: Martin Kepplinger
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d6abd2077114..e3fbb8b58d5d 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -369,6 +369,12 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
bus_format = bridge_state->input_bus_cfg.format;
+ if (bus_format == MEDIA_BUS_FMT_FIXED) {
+ dev_warn_once(drm->dev,
+ "Bridge does not provide bus format,
assuming MEDIA_BUS_FMT_RGB888_1X24.\n"
+ "Please fix bridge driver by handling
atomic_get_input_bus_fmts.\n");
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ }
}
/* If there is no bridge, use bus format from connector */
--
2.33.0
[PATCH v2 4/5] drm: mxsfb: Print failed bus format in hex
media-bus-formats.h has them in hexadecimal as well so matching with that file saves one conversion when debugging. Signed-off-by: Guido Günther --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index af6c620adf6e..d6abd2077114 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -89,7 +89,7 @@ static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb, ctrl |= CTRL_BUS_WIDTH_24; break; default: - dev_err(drm->dev, "Unknown media bus format %d\n", bus_format); + dev_err(drm->dev, "Unknown media bus format 0x%x\n", bus_format); break; } -- 2.33.0
[PATCH v2 3/5] drm/panel: st7703: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index a2c303e5732c..73f69c929a75 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -453,6 +453,10 @@ static int st7703_prepare(struct drm_panel *panel)
return ret;
}
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int st7703_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -474,6 +478,10 @@ static int st7703_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v2 2/5] drm/panel: mantix: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index f0e9bce23c41..d6bcf1045255 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -232,6 +233,10 @@ static const struct drm_display_mode default_mode_ys = {
.height_mm = 130,
};
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -253,6 +258,10 @@ static int mantix_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v2 1/5] drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially output (see chapter 13.6 of the i.MX 8MQ reference
manual) - which matches what xsfb can input.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/nwl-dsi.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a251cc1f088f..27c80d36846b 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -1234,6 +1234,40 @@ static void nwl_dsi_bridge_detach(struct drm_bridge
*bridge)
drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
}
+static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state
*crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts, input_fmt;
+
+ *num_input_fmts = 0;
+
+ switch (output_fmt) {
+ /* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
+ case MEDIA_BUS_FMT_FIXED:
+ input_fmt = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ input_fmt = output_fmt;
+ break;
+ default:
+ return NULL;
+ }
+
+ input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+ input_fmts[0] = input_fmt;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -1241,6 +1275,7 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs
= {
.atomic_check = nwl_dsi_bridge_atomic_check,
.atomic_enable = nwl_dsi_bridge_atomic_enable,
.atomic_disable = nwl_dsi_bridge_atomic_disable,
+ .atomic_get_input_bus_fmts = nwl_bridge_atomic_get_input_bus_fmts,
.mode_set = nwl_dsi_bridge_mode_set,
.mode_valid = nwl_dsi_bridge_mode_valid,
.attach = nwl_dsi_bridge_attach,
--
2.33.0
[PATCH v2 0/5] mxsfb/nwl/panels: media bus format fixes
commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present") added bus format probing to mxsfb this exposed several issues in the
display stack as used on the Librem 5:
The nwl bridge and the panels didn't bother to set any media bus formats and in
that case mxsfb would not pick a reasonable default. This series aims to fix
this.
This series includes the patch from
https://lore.kernel.org/dri-devel/yvlyh%2fsgbritg%2...@qwark.sigxcpu.org/
with a `dev_warn` added.
The patches are against 5.15-rc3. I've marked a single patch with a 'fixes'
which is enough to unbreak the display stack in 5.15.
All patches of this series can be applied independently.
Changes from v1:
- Review comment by Marek Vasut
https://lore.kernel.org/dri-devel/67e6056a-6157-795d-908d-d65cc803c...@denx.de/
Improve warning message
- Move mxsfb patches to the end of the queue and the actual nwl fix to the
front.
Guido Günther (5):
drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
drm/panel: mantix: Add media bus format
drm/panel: st7703: Add media bus format
drm: mxsfb: Print failed bus format in hex
drm: mxsfb: Set proper default bus format when using a bridge
drivers/gpu/drm/bridge/nwl-dsi.c | 35 +++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 -
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +
4 files changed, 59 insertions(+), 1 deletion(-)
--
2.33.0
Re: [PATCH] drm: mxsfb: Set proper default bus format when using a bridge
Hi,
On Tue, Sep 28, 2021 at 11:27:49AM +0200, Lucas Stach wrote:
> Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
> > Hi,
> > On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> > > On 9/28/21 10:55 AM, Guido Günther wrote:
> > > > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > > > returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24)
> > > > in
> > > > that case.
> > > >
> > > > This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
> > > >
> > > > Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest
> > > > bridge if present")
> > > >
> > > > Signed-off-by: Guido Günther
> > > > ---
> > > >
> > > > I'll look at what needs to be done in nwl separately but this also
> > > > unbreaks other bridge seupts that don't to format negotiation yet.
> > > >
> > > > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > index af6c620adf6e..4ef94cf686b0 100644
> > > > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > > > @@ -369,6 +369,8 @@ static void mxsfb_crtc_atomic_enable(struct
> > > > drm_crtc *crtc,
> > > > drm_atomic_get_new_bridge_state(state,
> > > > mxsfb->bridge);
> > > > bus_format = bridge_state->input_bus_cfg.format;
> > > > + if (bus_format == MEDIA_BUS_FMT_FIXED)
> > > > + bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > >
> > > Shouldn't the NWL bridge return the correct format ?
> >
> > Yes it should and I'll send a separate patch for that but we currently
> > don't do anything meaningful at all if the bridge doesn't do format
> > negotiation and then fail setup in mxsfb_set_formats().
> >
> > I think we should at least preserve the status quo (as we do with the
> > non bridge case in b776b0f00f24 too).
> >
> > We could have a warning to spot drivers that don't do that yet and hence
> > the generic code returns MEDIA_BUS_FMT_FIXED.
> >
> That sounds sensible. Using a default format if we don't know what to
> do is going to be a unpleasant surprise for those with a display
> pipeline that doesn't work with the default format. So please add a
> dev_warn when we are doing this fallback.
>
> Also I would argue that the NWL fix is the patch that should go in the
> stable tree. This one should only be a additional safety net, so I
> would drop the Fixes tag.
Dropped and folded into the small series with other fixes needed to
get get the bus format propagated up from the panel.
Cheers,
-- Guido
>
> Regards,
> Lucas
>
[PATCH v1 2/5] drm: mxsfb: Set proper default bus format when using a bridge
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Reported-by: Martin Kepplinger
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d6abd2077114..f4be16f5c20b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -369,6 +369,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
bus_format = bridge_state->input_bus_cfg.format;
+ if (bus_format == MEDIA_BUS_FMT_FIXED) {
+ dev_warn_once(drm->dev,
+ "Bridge does not provide bus format.
Please fix.");
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ }
}
/* If there is no bridge, use bus format from connector */
--
2.33.0
[PATCH v1 3/5] drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially output (see chapter 13.6 of the i.MX 8MQ reference
manual) - which matches what xsfb can input.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/nwl-dsi.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a251cc1f088f..27c80d36846b 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -1234,6 +1234,40 @@ static void nwl_dsi_bridge_detach(struct drm_bridge
*bridge)
drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
}
+static u32 *nwl_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state
*crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts, input_fmt;
+
+ *num_input_fmts = 0;
+
+ switch (output_fmt) {
+ /* If MEDIA_BUS_FMT_FIXED is tested, return default bus format */
+ case MEDIA_BUS_FMT_FIXED:
+ input_fmt = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ input_fmt = output_fmt;
+ break;
+ default:
+ return NULL;
+ }
+
+ input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+ input_fmts[0] = input_fmt;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -1241,6 +1275,7 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs
= {
.atomic_check = nwl_dsi_bridge_atomic_check,
.atomic_enable = nwl_dsi_bridge_atomic_enable,
.atomic_disable = nwl_dsi_bridge_atomic_disable,
+ .atomic_get_input_bus_fmts = nwl_bridge_atomic_get_input_bus_fmts,
.mode_set = nwl_dsi_bridge_mode_set,
.mode_valid = nwl_dsi_bridge_mode_valid,
.attach = nwl_dsi_bridge_attach,
--
2.33.0
[PATCH v1 5/5] drm/panel: st7703: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index a2c303e5732c..73f69c929a75 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -453,6 +453,10 @@ static int st7703_prepare(struct drm_panel *panel)
return ret;
}
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int st7703_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -474,6 +478,10 @@ static int st7703_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v1 4/5] drm/panel: mantix: Add media bus format
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index f0e9bce23c41..d6bcf1045255 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -232,6 +233,10 @@ static const struct drm_display_mode default_mode_ys = {
.height_mm = 130,
};
+static const u32 mantix_bus_formats[] = {
+ MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -253,6 +258,10 @@ static int mantix_get_modes(struct drm_panel *panel,
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_display_info_set_bus_formats(>display_info,
+mantix_bus_formats,
+ARRAY_SIZE(mantix_bus_formats));
+
return 1;
}
--
2.33.0
[PATCH v1 1/5] drm: mxsfb: Print failed bus format in hex
media-bus-formats.h has them in hexadecimal as well so matching with that file saves one conversion when debugging. Signed-off-by: Guido Günther --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index af6c620adf6e..d6abd2077114 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -89,7 +89,7 @@ static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb, ctrl |= CTRL_BUS_WIDTH_24; break; default: - dev_err(drm->dev, "Unknown media bus format %d\n", bus_format); + dev_err(drm->dev, "Unknown media bus format 0x%x\n", bus_format); break; } -- 2.33.0
[PATCH v1 0/5] mxsfb/nwl/panels: media bus format fixes
commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present") added bus format probing to mxsfb this exposed several issues in the
display stack as used on the Librem 5:
The nwl bridge and the panels didn't bother to set any media bus formats and in
that case mxsfb would not pick a reasonable default. This series aims to fix
this.
This series includes the patch from
https://lore.kernel.org/dri-devel/yvlyh%2fsgbritg%2...@qwark.sigxcpu.org/
with a `dev_warn` added.
The patches are against 5.15-rc3. I've marked a single patch with a 'fixes'
which is enough to unbreak the display stack in 5.15.
Guido Günther (5):
drm: mxsfb: Print failed bus format in hex
drm: mxsfb: Set proper default bus format when using a bridge
drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
drm/panel: mantix: Add media bus format
drm/panel: st7703: Add media bus format
drivers/gpu/drm/bridge/nwl-dsi.c | 35 +++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 7 +++-
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +
4 files changed, 58 insertions(+), 1 deletion(-)
--
2.33.0
Re: [PATCH] drm: mxsfb: Set proper default bus format when using a bridge
Hi,
On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
> On 9/28/21 10:55 AM, Guido Günther wrote:
> > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
> > that case.
> >
> > This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
> >
> > Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
> > present")
> >
> > Signed-off-by: Guido Günther
> > ---
> >
> > I'll look at what needs to be done in nwl separately but this also
> > unbreaks other bridge seupts that don't to format negotiation yet.
> >
> > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > index af6c620adf6e..4ef94cf686b0 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > @@ -369,6 +369,8 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> > drm_atomic_get_new_bridge_state(state,
> > mxsfb->bridge);
> > bus_format = bridge_state->input_bus_cfg.format;
> > + if (bus_format == MEDIA_BUS_FMT_FIXED)
> > + bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>
> Shouldn't the NWL bridge return the correct format ?
Yes it should and I'll send a separate patch for that but we currently
don't do anything meaningful at all if the bridge doesn't do format
negotiation and then fail setup in mxsfb_set_formats().
I think we should at least preserve the status quo (as we do with the
non bridge case in b776b0f00f24 too).
We could have a warning to spot drivers that don't do that yet and hence
the generic code returns MEDIA_BUS_FMT_FIXED.
Cheers,
-- Guido
[PATCH] drm: mxsfb: Set proper default bus format when using a bridge
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Guido Günther
---
I'll look at what needs to be done in nwl separately but this also
unbreaks other bridge seupts that don't to format negotiation yet.
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index af6c620adf6e..4ef94cf686b0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -369,6 +369,8 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
bus_format = bridge_state->input_bus_cfg.format;
+ if (bus_format == MEDIA_BUS_FMT_FIXED)
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
}
/* If there is no bridge, use bus format from connector */
--
2.33.0
Re: [PATCH] drm: bridge: nwl-dsi: Drop unused nwl_dsi_plat_clk_config
Hi,
On Sun, Jul 04, 2021 at 03:04:33PM +0530, Jagan Teki wrote:
> nwl_dsi_plat_clk_config structure added in below commit but not
> used anywhere in the driver.
>
> commit <44cfc6233447c> ("drm/bridge: Add NWL MIPI DSI host controller
> support")
>
> Drop it.
Reviewed-by: Guido Günther
Cheers,
-- Guido
>
> Cc: Guido Günther
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 873995f0a741..d7986067eefe 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -48,12 +48,6 @@ enum transfer_direction {
> #define NWL_DSI_ENDPOINT_LCDIF 0
> #define NWL_DSI_ENDPOINT_DCSS 1
>
> -struct nwl_dsi_plat_clk_config {
> - const char *id;
> - struct clk *clk;
> - bool present;
> -};
> -
> struct nwl_dsi_transfer {
> const struct mipi_dsi_msg *msg;
> struct mipi_dsi_packet packet;
> --
> 2.25.1
>
Re: [PATCH v3 0/3] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()
Hi Liu, On Fri, Apr 23, 2021 at 05:26:40PM +0800, Liu Ying wrote: > Hi, > > This series aims to make the nwl-dsi bridge be able to connect with > more MIPI DSI panels. Some MIPI DSI panel drivers like 'raydium,rm68200' > send MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which > requires the MIPI DSI controller and PHY to be ready beforehand. > However, the existing nwl-dsi driver gets the MIPI DSI controller and > PHY ready in bridge_funcs->pre_enable(), which happens after the > panel_funcs->prepare(). So, this series shifts the bridge operation > ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set(). > > Patch 3/3 does the essential bridge operation shift. > > Patch 1/3 and 2/3 are split from the original single patch in v2 and > are needed by patch 3/3. This split-up helps clarify changes better. > The split-up is done in this way: > > 1) Patch 1/3 forces a full modeset when crtc_state->active is changed to >be true(which implies only connector's DPMS is brought out of "Off" >status, though not necessarily). This makes sure ->mode_set() and >->atomic_disable() will be called in pairs. > 2) Patch 2/3 removes a check on unchanged HS clock rate from ->mode_set(), >to make sure MIPI DSI controller and PHY are brought up and taken down >in pairs. > 3) Patch 3/3 shifts the bridge operation as the last step. Looks good to me and tested on imx8mq Librem 5 Devkit with https://lore.kernel.org/linux-arm-kernel/cover.1617968250.git@sigxcpu.org/ on top so Reviewed-by: Guido Günther Tested-by: Guido Günther Cheers, -- Guido > > > v2->v3: > * Split the single patch in v2 into 3 patches. (Neil) > > v1->v2: > * Fix a typo in commit message - s/unchange/unchanged/ > > > Liu Ying (3): > drm/bridge: nwl-dsi: Force a full modeset when crtc_state->active is > changed to be true > drm/bridge: nwl-dsi: Remove a check on unchanged HS clock rate from > ->mode_set() > drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in > ->mode_set() > > drivers/gpu/drm/bridge/nwl-dsi.c | 86 +--- > 1 file changed, 46 insertions(+), 40 deletions(-) > > -- > 2.25.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()
Hi,
On Tue, Dec 08, 2020 at 10:04:57AM +0100, Guido Günther wrote:
> Hi,
> On Fri, Dec 04, 2020 at 03:33:41PM +0800, Liu Ying wrote:
> > The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> > works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> > a MIPI DSI display or a LVDS display. So, this patch calls
> > phy_set_mode() from nwl_dsi_enable() to set PHY mode to MIPI DPHY
> > explicitly.
Should i pull this patch in via drm-misc-next or is the whole series
supposed to go via the phy tree?
Cheers,
-- Guido
> >
> > Cc: Guido Günther
> > Cc: Robert Chiras
> > Cc: Martin Kepplinger
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Laurent Pinchart
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: NXP Linux Team
> > Signed-off-by: Liu Ying
> > ---
> > drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> > b/drivers/gpu/drm/bridge/nwl-dsi.c
> > index 66b6740..be6bfc5 100644
> > --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > @@ -678,6 +678,12 @@ static int nwl_dsi_enable(struct nwl_dsi *dsi)
> > return ret;
> > }
> >
> > + ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n", ret);
> > + goto uninit_phy;
> > + }
> > +
> > ret = phy_configure(dsi->phy, phy_cfg);
> > if (ret < 0) {
> > DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n", ret);
>
> Reviewed-by: Guido Günther
> -- Guido
>
> > --
> > 2.7.4
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/1] drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge
It can take multiple iterations until all components for an attached DSI bridge are up leading to several: [3.796425] mxsfb 3032.lcd-controller: Cannot connect bridge: -517 [3.816952] mxsfb 3032.lcd-controller: [drm:mxsfb_probe [mxsfb]] *ERROR* failed to attach bridge: -517 Silence this by checking for -EPROBE_DEFER and using dev_err_probe() so we set a deferred reason in case a dependency fails to probe (which quickly happens on small config/DT changes due to the rather long probe chain which can include bridges, phys, panels, backights, leds, etc.). This also removes the only DRM_DEV_ERROR() usage, the rest of the driver uses dev_err(). Guido Günther (1): drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge drivers/gpu/drm/mxsfb/mxsfb_drv.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm: mxsfb: Silence -EPROBE_DEFER while waiting for bridge
It can take multiple iterations until all components for an attached DSI
bridge are up leading to several:
[3.796425] mxsfb 3032.lcd-controller: Cannot connect bridge: -517
[3.816952] mxsfb 3032.lcd-controller: [drm:mxsfb_probe [mxsfb]] *ERROR*
failed to attach bridge: -517
Silence this by checking for -EPROBE_DEFER and using dev_err_probe() so
we set a deferred reason in case a dependency fails to probe (which
quickly happens on small config/DT changes due to the rather long probe
chain which can include bridges, phys, panels, backights, leds, etc.).
This also removes the only DRM_DEV_ERROR() usage, the rest of the driver
uses dev_err().
Signed-off-by: Guido Günther
Fixes: c42001e357f7 ("drm: mxsfb: Use drm_panel_bridge")
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 6faf17b6408d..6da93551e2e5 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -134,11 +134,8 @@ static int mxsfb_attach_bridge(struct mxsfb_drm_private
*mxsfb)
return -ENODEV;
ret = drm_bridge_attach(>encoder, bridge, NULL, 0);
- if (ret) {
- DRM_DEV_ERROR(drm->dev,
- "failed to attach bridge: %d\n", ret);
- return ret;
- }
+ if (ret)
+ return dev_err_probe(drm->dev, ret, "Failed to attach
bridge\n");
mxsfb->bridge = bridge;
@@ -212,7 +209,8 @@ static int mxsfb_load(struct drm_device *drm,
ret = mxsfb_attach_bridge(mxsfb);
if (ret) {
- dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
goto err_vblank;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema
Hi,
On Fri, Dec 11, 2020 at 09:46:20AM +0800, Liu Ying wrote:
> This patch converts the mixel,mipi-dsi-phy binding to
> DT schema format using json-schema.
>
> Comparing to the plain text version, the new binding adds
> the 'assigned-clocks', 'assigned-clock-parents' and
> 'assigned-clock-rates' properites, otherwise 'make dtbs_check'
> would complain that there are mis-matches. Also, the new
> binding requires the 'power-domains' property since all potential
> SoCs that embed this PHY would provide a power domain for it.
> The example of the new binding takes reference to the latest
> dphy node in imx8mq.dtsi.
>
> Cc: Guido Günther
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Rob Herring
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> v2->v3:
> * Improve the 'clock-names' property by dropping 'items:'.
>
> v1->v2:
> * Newly introduced in v2. (Guido)
>
> .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 29 -
> .../bindings/phy/mixel,mipi-dsi-phy.yaml | 72
> ++
> 2 files changed, 72 insertions(+), 29 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> create mode 100644
> Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> deleted file mode 100644
> index 9b23407..
> --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Mixel DSI PHY for i.MX8
> -
> -The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 platforms (along the
> -MIPI-DSI IP from Northwest Logic). It represents the physical layer for the
> -electrical signals for DSI.
> -
> -Required properties:
> -- compatible: Must be:
> - - "fsl,imx8mq-mipi-dphy"
> -- clocks: Must contain an entry for each entry in clock-names.
> -- clock-names: Must contain the following entries:
> - - "phy_ref": phandle and specifier referring to the DPHY ref clock
> -- reg: the register range of the PHY controller
> -- #phy-cells: number of cells in PHY, as defined in
> - Documentation/devicetree/bindings/phy/phy-bindings.txt
> - this must be <0>
> -
> -Optional properties:
> -- power-domains: phandle to power domain
> -
> -Example:
> - dphy: dphy@30a0030 {
> - compatible = "fsl,imx8mq-mipi-dphy";
> - clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
> - clock-names = "phy_ref";
> - reg = <0x30a00300 0x100>;
> - power-domains = <_mipi0>;
> - #phy-cells = <0>;
> -};
> diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
> b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
> new file mode 100644
> index ..c34f2e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/mixel,mipi-dsi-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mixel DSI PHY for i.MX8
> +
> +maintainers:
> + - Guido Günther
> +
> +description: |
> + The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 platforms (along the
> + MIPI-DSI IP from Northwest Logic). It represents the physical layer for the
> + electrical signals for DSI.
> +
> +properties:
> + compatible:
> +enum:
> + - fsl,imx8mq-mipi-dphy
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +const: phy_ref
> +
> + assigned-clocks:
> +maxItems: 1
> +
> + assigned-clock-parents:
> +maxItems: 1
> +
> + assigned-clock-rates:
> +maxItems: 1
> +
> + "#phy-cells":
> +const: 0
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - assigned-clocks
> + - assigned-clock-parents
> + - assigned-clock-rates
> + - "#phy-cells"
> + - power-domains
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +dphy: dphy@30a0030 {
> +compatible = "fsl,imx8mq-mipi-dphy";
> +reg = <0x30a00300 0x100>;
> +clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
> +clock-names = "phy_ref";
> +assigned-clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
> +assigned-clock-parents = < IMX8MQ_VIDEO_PLL1_OUT>;
> +assigned-clock-rates = <2400>;
> +#phy-cells = <0>;
> +power-domains = <_mipi>;
> +};
Reviewed-by: Guido Günther
Thanks for the conversion!
-- Guido
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp
Hi, On Fri, Dec 11, 2020 at 09:46:21AM +0800, Liu Ying wrote: > Add support for Mixel MIPI DPHY + LVDS PHY combo IP > as found on Freescale i.MX8qxp SoC. > > Cc: Guido Günther > Cc: Kishon Vijay Abraham I > Cc: Vinod Koul > Cc: Rob Herring > Cc: NXP Linux Team > Signed-off-by: Liu Ying > --- > v2->v3: > * No change. > > v1->v2: > * Add the binding for i.MX8qxp Mixel combo PHY based on the converted binding. > (Guido) > > .../bindings/phy/mixel,mipi-dsi-phy.yaml | 41 > -- > 1 file changed, 38 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml > b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml > index c34f2e6..786cfd7 100644 > --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml > @@ -14,10 +14,14 @@ description: | >MIPI-DSI IP from Northwest Logic). It represents the physical layer for the >electrical signals for DSI. > > + The Mixel PHY IP block found on i.MX8qxp is a combo PHY that can work > + in either MIPI-DSI PHY mode or LVDS PHY mode. > + > properties: >compatible: > enum: >- fsl,imx8mq-mipi-dphy > + - fsl,imx8qxp-mipi-dphy > >reg: > maxItems: 1 > @@ -40,6 +44,11 @@ properties: >"#phy-cells": > const: 0 > > + fsl,syscon: > +$ref: /schemas/types.yaml#/definitions/phandle > +description: | > + A phandle which points to Control and Status Registers(CSR) module. > + >power-domains: > maxItems: 1 > > @@ -48,12 +57,38 @@ required: >- reg >- clocks >- clock-names > - - assigned-clocks > - - assigned-clock-parents > - - assigned-clock-rates >- "#phy-cells" >- power-domains > > +allOf: > + - if: > + properties: > +compatible: > + contains: > +const: fsl,imx8mq-mipi-dphy > +then: > + properties: > +fsl,syscon: false > + > + required: > +- assigned-clocks > +- assigned-clock-parents > +- assigned-clock-rates > + > + - if: > + properties: > +compatible: > + contains: > +const: fsl,imx8qxp-mipi-dphy > +then: > + properties: > +assigned-clocks: false > +assigned-clock-parents: false > +assigned-clock-rates: false > + > + required: > +- fsl,syscon > + > additionalProperties: false > > examples: Reviewed-by: Guido Günther Cheers, -- Guido > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi,
On Fri, Dec 11, 2020 at 09:46:22AM +0800, Liu Ying wrote:
> i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> by SCU firmware and the driver would call a SCU firmware function to
> configure the PHY mode. The single LVDS PHY has 4 data lanes to support
> a LVDS display. Also, with a master LVDS PHY and a slave LVDS PHY, they
> may work together to support a LVDS display with 8 data lanes(usually, dual
> LVDS link display). Note that this patch supports the LVDS PHY mode only
> for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> supported, so for now error would be returned from ->set_mode() if MIPI
> DPHY mode is passed over to it for the combo PHY.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> Guido, I also print invalid PHY mode from mixel_dphy_configure().
>
> v2->v3:
> * Improve readability of mixel_dphy_set_mode(). (Guido)
>
> v1->v2:
> * Print invalid PHY mode in dmesg. (Guido)
>
> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 269
> -
> 1 file changed, 258 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index a95572b..af1ecda 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -4,17 +4,31 @@
> * Copyright 2019 Purism SPC
> */
>
> +#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> +
> +/* Control and Status Registers(CSR) */
> +#define PHY_CTRL 0x00
> +#define CCM_MASKGENMASK(7, 5)
> +#define CCM(n) FIELD_PREP(CCM_MASK, (n))
> +#define CA_MASK GENMASK(4, 2)
> +#define CA(n) FIELD_PREP(CA_MASK, (n))
> +#define RFB BIT(1)
> +#define LVDS_EN BIT(0)
>
> /* DPHY registers */
> #define DPHY_PD_DPHY 0x00
> @@ -55,8 +69,15 @@
> #define PWR_ON 0
> #define PWR_OFF 1
>
> +#define MIN_VCO_FREQ 64000
> +#define MAX_VCO_FREQ 15
> +
> +#define MIN_LVDS_REFCLK_FREQ 2400
> +#define MAX_LVDS_REFCLK_FREQ 15000
> +
> enum mixel_dphy_devtype {
> MIXEL_IMX8MQ,
> + MIXEL_IMX8QXP,
> };
>
> struct mixel_dphy_devdata {
> @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> u8 reg_rxlprp;
> u8 reg_rxcdrp;
> u8 reg_rxhs_settle;
> + bool is_combo; /* MIPI DPHY and LVDS PHY combo */
> };
>
> static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata
> mixel_dphy_devdata[] = {
> .reg_rxlprp = 0x40,
> .reg_rxcdrp = 0x44,
> .reg_rxhs_settle = 0x48,
> + .is_combo = false,
> + },
> + [MIXEL_IMX8QXP] = {
> + .is_combo = true,
> },
> };
>
> @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> struct mixel_dphy_priv {
> struct mixel_dphy_cfg cfg;
> struct regmap *regmap;
> + struct regmap *lvds_regmap;
> struct clk *phy_ref_clk;
> const struct mixel_dphy_devdata *devdata;
> + struct imx_sc_ipc *ipc_handle;
> + bool is_slave;
> + int id;
> };
>
> static const struct regmap_config mixel_dphy_regmap_config = {
> @@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
> return 0;
> }
>
> -static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts
> *opts)
> +static int
> +mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts
> *opts)
> {
> struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> struct mixel_dphy_cfg cfg = { 0 };
> @@ -345,15 +376,121 @@ static int mixel_dphy_configure(struct phy *phy, union
> phy_configure_opts *opts)
> return 0;
> }
>
> +static int
> +mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts
> *opts)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + struct phy_configure_opts_lvds *lvds_opts = >lvds;
> + unsigned long data
Re: [PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi,
On Tue, Dec 08, 2020 at 06:03:05PM +0800, Liu Ying wrote:
> On Tue, 2020-12-08 at 10:24 +0100, Guido Günther wrote:
> > Hi Liu,
> > some minor comments inline:
> >
> > On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> > > i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> > > either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> > > by SCU firmware and the driver would call a SCU firmware function to
> > > configure the PHY mode. The single LVDS PHY has 4 data lanes to support
> > > a LVDS display. Also, with a master LVDS PHY and a slave LVDS PHY, they
> > > may work together to support a LVDS display with 8 data lanes(usually,
> > > dual
> > > LVDS link display). Note that this patch supports the LVDS PHY mode only
> > > for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> > > supported, so for now error would be returned from ->set_mode() if MIPI
> > > DPHY mode is passed over to it for the combo PHY.
> > >
> > > Cc: Guido Günther
> > > Cc: Robert Chiras
> > > Cc: Kishon Vijay Abraham I
> > > Cc: Vinod Koul
> > > Cc: Shawn Guo
> > > Cc: Sascha Hauer
> > > Cc: Pengutronix Kernel Team
> > > Cc: Fabio Estevam
> > > Cc: NXP Linux Team
> > > Signed-off-by: Liu Ying
> > > ---
> > > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266
> > > -
> > > 1 file changed, 255 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > index a95572b..37084a9 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > @@ -4,17 +4,31 @@
> > > * Copyright 2019 Purism SPC
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +
> > > +/* Control and Status Registers(CSR) */
> > > +#define PHY_CTRL 0x00
> > > +#define CCM_MASKGENMASK(7, 5)
> > > +#define CCM(n) FIELD_PREP(CCM_MASK, (n))
> > > +#define CA_MASK GENMASK(4, 2)
> > > +#define CA(n) FIELD_PREP(CA_MASK, (n))
> > > +#define RFB BIT(1)
> > > +#define LVDS_EN BIT(0)
> > >
> > > /* DPHY registers */
> > > #define DPHY_PD_DPHY 0x00
> > > @@ -55,8 +69,15 @@
> > > #define PWR_ON 0
> > > #define PWR_OFF 1
> > >
> > > +#define MIN_VCO_FREQ 64000
> > > +#define MAX_VCO_FREQ 15
> > > +
> > > +#define MIN_LVDS_REFCLK_FREQ 2400
> > > +#define MAX_LVDS_REFCLK_FREQ 15000
> > > +
> > > enum mixel_dphy_devtype {
> > > MIXEL_IMX8MQ,
> > > + MIXEL_IMX8QXP,
> > > };
> > >
> > > struct mixel_dphy_devdata {
> > > @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> > > u8 reg_rxlprp;
> > > u8 reg_rxcdrp;
> > > u8 reg_rxhs_settle;
> > > + bool is_combo; /* MIPI DPHY and LVDS PHY combo */
> > > };
> > >
> > > static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> > > @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata
> > > mixel_dphy_devdata[] = {
> > > .reg_rxlprp = 0x40,
> > > .reg_rxcdrp = 0x44,
> > > .reg_rxhs_settle = 0x48,
> > > + .is_combo = false,
> > > + },
> > > + [MIXEL_IMX8QXP] = {
> > > + .is_combo = true,
> > > },
> > > };
> > >
> > > @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> > > struct mixel_dphy_priv {
> > > struct mixel_dphy_cfg cfg;
> > > struct regmap *regmap;
> > > + struct regmap *lvds_regmap;
> > > struct clk *phy_ref_clk;
> > > const struct mixel_dphy_devdata *devdata;
> > > + struct imx_sc_ipc *ipc_handle;
> > > + bool is_slave;
> > &g
Re: [PATCH v2 6/6] dt-binding: display: mantix: Add compatible for panel from YS
Hi, On Mon, Dec 07, 2020 at 03:32:06PM -0600, Rob Herring wrote: > On Wed, 18 Nov 2020 09:29:53 +0100, Guido Günther wrote: > > This panel from Shenzhen Yashi Changhua Intelligent Technology Co > > uses the same driver IC but a different LCD. > > > > Signed-off-by: Guido Günther > > Reviewed-by: Linus Walleij > > --- > > .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > Acked-by: Rob Herring > Thanks! I've appplied the series to drm-misc-next now. Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi Liu,
some minor comments inline:
On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> by SCU firmware and the driver would call a SCU firmware function to
> configure the PHY mode. The single LVDS PHY has 4 data lanes to support
> a LVDS display. Also, with a master LVDS PHY and a slave LVDS PHY, they
> may work together to support a LVDS display with 8 data lanes(usually, dual
> LVDS link display). Note that this patch supports the LVDS PHY mode only
> for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> supported, so for now error would be returned from ->set_mode() if MIPI
> DPHY mode is passed over to it for the combo PHY.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266
> -
> 1 file changed, 255 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index a95572b..37084a9 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -4,17 +4,31 @@
> * Copyright 2019 Purism SPC
> */
>
> +#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> +
> +/* Control and Status Registers(CSR) */
> +#define PHY_CTRL 0x00
> +#define CCM_MASKGENMASK(7, 5)
> +#define CCM(n) FIELD_PREP(CCM_MASK, (n))
> +#define CA_MASK GENMASK(4, 2)
> +#define CA(n) FIELD_PREP(CA_MASK, (n))
> +#define RFB BIT(1)
> +#define LVDS_EN BIT(0)
>
> /* DPHY registers */
> #define DPHY_PD_DPHY 0x00
> @@ -55,8 +69,15 @@
> #define PWR_ON 0
> #define PWR_OFF 1
>
> +#define MIN_VCO_FREQ 64000
> +#define MAX_VCO_FREQ 15
> +
> +#define MIN_LVDS_REFCLK_FREQ 2400
> +#define MAX_LVDS_REFCLK_FREQ 15000
> +
> enum mixel_dphy_devtype {
> MIXEL_IMX8MQ,
> + MIXEL_IMX8QXP,
> };
>
> struct mixel_dphy_devdata {
> @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> u8 reg_rxlprp;
> u8 reg_rxcdrp;
> u8 reg_rxhs_settle;
> + bool is_combo; /* MIPI DPHY and LVDS PHY combo */
> };
>
> static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata
> mixel_dphy_devdata[] = {
> .reg_rxlprp = 0x40,
> .reg_rxcdrp = 0x44,
> .reg_rxhs_settle = 0x48,
> + .is_combo = false,
> + },
> + [MIXEL_IMX8QXP] = {
> + .is_combo = true,
> },
> };
>
> @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> struct mixel_dphy_priv {
> struct mixel_dphy_cfg cfg;
> struct regmap *regmap;
> + struct regmap *lvds_regmap;
> struct clk *phy_ref_clk;
> const struct mixel_dphy_devdata *devdata;
> + struct imx_sc_ipc *ipc_handle;
> + bool is_slave;
> + int id;
> };
>
> static const struct regmap_config mixel_dphy_regmap_config = {
> @@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
> return 0;
> }
>
> -static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts
> *opts)
> +static int
> +mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts
> *opts)
> {
> struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> struct mixel_dphy_cfg cfg = { 0 };
> @@ -345,15 +376,118 @@ static int mixel_dphy_configure(struct phy *phy, union
> phy_configure_opts *opts)
> return 0;
> }
>
> +static int
> +mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts
> *opts)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + struct phy_configure_opts_lvds *lvds_opts = >lvds;
> + unsigned long data_rate;
> + unsigned long fvco;
> + u32 rsc;
> + u32 co;
> + int ret;
> +
> + priv->is_slave = lvds_opts->is_slave;
> +
> + /* LVDS interface pins */
>
Re: [PATCH 3/4] dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp
Hi Liu, Since we now gain optional properties validation would become even more useful. Could you look into converting to YAML before adding more values? Cheers, -- Guido On Fri, Dec 04, 2020 at 03:33:43PM +0800, Liu Ying wrote: > Add support for Mixel MIPI DPHY + LVDS PHY combo IP > as found on Freescale i.MX8qxp SoC. > > Cc: Guido Günther > Cc: Kishon Vijay Abraham I > Cc: Vinod Koul > Cc: Rob Herring > Cc: NXP Linux Team > Signed-off-by: Liu Ying > --- > Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > index 9b23407..0afce99 100644 > --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > @@ -4,9 +4,13 @@ The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 > platforms (along the > MIPI-DSI IP from Northwest Logic). It represents the physical layer for the > electrical signals for DSI. > > +The Mixel PHY IP block found on i.MX8qxp is a combo PHY that can work > +in either MIPI-DSI PHY mode or LVDS PHY mode. > + > Required properties: > -- compatible: Must be: > +- compatible: Should be one of: >- "fsl,imx8mq-mipi-dphy" > + - "fsl,imx8qxp-mipi-dphy" > - clocks: Must contain an entry for each entry in clock-names. > - clock-names: Must contain the following entries: >- "phy_ref": phandle and specifier referring to the DPHY ref clock > @@ -14,6 +18,8 @@ Required properties: > - #phy-cells: number of cells in PHY, as defined in >Documentation/devicetree/bindings/phy/phy-bindings.txt >this must be <0> > +- fsl,syscon: Phandle to a system controller, as required by the PHY > + in i.MX8qxp SoC. > > Optional properties: > - power-domains: phandle to power domain > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()
Hi,
On Fri, Dec 04, 2020 at 03:33:41PM +0800, Liu Ying wrote:
> The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> a MIPI DSI display or a LVDS display. So, this patch calls
> phy_set_mode() from nwl_dsi_enable() to set PHY mode to MIPI DPHY
> explicitly.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Martin Kepplinger
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 66b6740..be6bfc5 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -678,6 +678,12 @@ static int nwl_dsi_enable(struct nwl_dsi *dsi)
> return ret;
> }
>
> + ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n", ret);
> + goto uninit_phy;
> + }
> +
> ret = phy_configure(dsi->phy, phy_cfg);
> if (ret < 0) {
> DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n", ret);
Reviewed-by: Guido Günther
-- Guido
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi Liu, On Fri, Dec 04, 2020 at 03:33:40PM +0800, Liu Ying wrote: > Hi, > > This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the > Freescale i.MX8qxp SoC. This looks good to me from the NWL and actual phy driver part. I'll comment in the individual patches but leave comments on the extension of the generic phy struct to someone knowledgeable with that part. What display controllers do you intend to drive that with? Cheers, -- Guido > > The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either > MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp > SCU firmware. The PHY driver would call a SCU function to configure the > mode. > > The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, > where it appears to be a single MIPI DPHY. > > > Patch 1/4 sets PHY mode in the Northwest Logic MIPI DSI host controller > bridge driver, since i.MX8qxp SoC embeds this controller IP to support > MIPI DSI displays together with the Mixel PHY. > > Patch 2/4 allows LVDS PHYs to be configured through the generic PHY functions > and through a custom structure added to the generic PHY configuration union. > > Patch 3/4 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. > > Patch 4/4 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. > > > Welcome comments, thanks. > > > Liu Ying (4): > drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable() > phy: Add LVDS configuration options > dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for > i.MX8qxp > phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode > support > > .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 8 +- > drivers/gpu/drm/bridge/nwl-dsi.c | 6 + > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 > - > include/linux/phy/phy-lvds.h | 48 > include/linux/phy/phy.h| 4 + > 5 files changed, 320 insertions(+), 12 deletions(-) > create mode 100644 include/linux/phy/phy-lvds.h > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions
Hi Linus, On Thu, Nov 19, 2020 at 09:35:17AM +0100, Linus Walleij wrote: > On Wed, Nov 18, 2020 at 9:29 AM Guido Günther wrote: > > > This adds new panel type to the mantix driver as found on the Librem 5 and > > fixes a glitch in the init sequence (affecting both panels). The fix is at > > the > > start of the series to make backporting simpler. > > It also adds a patch to make st7703 use dev_err_probe(). > > > > changes from v1 > > - as per review comments by Linus Walleij > > - fix alphabetical ordering in > > Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/ > > - add reviewed by to all except 5/6, thanks > > The whole v2 looks fine to me, I'd give the devicetree > maintainers some slack to review the DT patches then I can > apply the whole series unless you have commit access yourself, > just tell me. Thanks. Is 2 weeks enough slack? Checking what's the rule of thumb here. Cheers, -- Guido > > For all v2 patches: > Reviewed-by: Linus Walleij > > If you have time, please review my s6e63m0 series. > https://lore.kernel.org/dri-devel/20201117175621.870085-1-linus.wall...@linaro.org/ > https://lore.kernel.org/dri-devel/20201117175621.870085-2-linus.wall...@linaro.org/ > https://lore.kernel.org/dri-devel/20201117175621.870085-3-linus.wall...@linaro.org/ > > Yours, > Linus Walleij > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm/imx/dcss: Add interconnect support
This allows us to raise DRAM bandiwth to a high enough value for a
stable picture on i.mx8mq. We pick a bandwidth that should be sufficient
for 4k@60Hz.
Modelled like mdp5_kms.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 47 +++--
drivers/gpu/drm/imx/dcss/dcss-dev.h | 3 ++
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index c849533ca83e..e336f03448d6 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -15,6 +15,9 @@
#include "dcss-dev.h"
#include "dcss-kms.h"
+/* sufficient for 4K at 60 Hz */
+#define DCSS_BW_MAX GBps_to_icc(2)
+
static void dcss_clocks_enable(struct dcss_dev *dcss)
{
clk_prepare_enable(dcss->axi_clk);
@@ -162,6 +165,31 @@ static void dcss_clks_release(struct dcss_dev *dcss)
devm_clk_put(dcss->dev, dcss->apb_clk);
}
+static int dcss_init_icc(struct dcss_dev *dcss)
+{
+ int ret;
+ struct icc_path *icc_path;
+
+ /* Optional interconnect request */
+ icc_path = of_icc_get(dcss->dev, NULL);
+ if (IS_ERR(icc_path)) {
+ ret = PTR_ERR(icc_path);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ /* no interconnect support is not necessarily a fatal
+* condition, the platform may simply not have an
+* interconnect driver yet. But warn about it in case
+* bootloader didn't setup bus clocks high enough for
+* scanout.
+*/
+ dev_warn(dcss->dev, "No interconnect support may cause display
underflows!\n");
+ return 0;
+ }
+ dcss->icc_path = icc_path;
+ dcss->icc_peak_bw = DCSS_BW_MAX;
+ return 0;
+}
+
struct dcss_dev *dcss_dev_create(struct device *dev, bool hdmi_output)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -190,10 +218,14 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
dcss->devtype = devtype;
dcss->hdmi_output = hdmi_output;
+ ret = dcss_init_icc(dcss);
+ if (ret < 0)
+ goto err;
+
ret = dcss_clks_init(dcss);
if (ret) {
dev_err(dev, "clocks initialization failed\n");
- goto err;
+ goto icc_err;
}
dcss->of_port = of_graph_get_port_by_id(dev->of_node, 0);
@@ -223,7 +255,8 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool
hdmi_output)
clks_err:
dcss_clks_release(dcss);
-
+icc_err:
+ icc_put(dcss->icc_path);
err:
kfree(dcss);
@@ -243,6 +276,8 @@ void dcss_dev_destroy(struct dcss_dev *dcss)
dcss_clks_release(dcss);
+ icc_put(dcss->icc_path);
+
kfree(dcss);
}
@@ -267,6 +302,8 @@ int dcss_dev_suspend(struct device *dev)
dcss_clocks_disable(dcss);
+ icc_set_bw(dcss->icc_path, 0, 0);
+
return 0;
}
@@ -281,6 +318,8 @@ int dcss_dev_resume(struct device *dev)
return 0;
}
+ icc_set_bw(dcss->icc_path, 0, dcss->icc_peak_bw);
+
dcss_clocks_enable(dcss);
dcss_blkctl_cfg(dcss->blkctl);
@@ -307,6 +346,8 @@ int dcss_dev_runtime_suspend(struct device *dev)
dcss_clocks_disable(dcss);
+ icc_set_bw(dcss->icc_path, 0, 0);
+
return 0;
}
@@ -314,6 +355,8 @@ int dcss_dev_runtime_resume(struct device *dev)
{
struct dcss_dev *dcss = dcss_drv_dev_to_dcss(dev);
+ icc_set_bw(dcss->icc_path, 0, dcss->icc_peak_bw);
+
dcss_clocks_enable(dcss);
dcss_blkctl_cfg(dcss->blkctl);
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.h
b/drivers/gpu/drm/imx/dcss/dcss-dev.h
index c642ae17837f..1b35a6f0d0d4 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.h
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.h
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#define SET0x04
@@ -85,6 +86,8 @@ struct dcss_dev {
struct clk *pll_phy_ref_clk;
bool hdmi_output;
+ struct icc_path *icc_path;
+ u32 icc_peak_bw;
void (*disable_callback)(void *data);
struct completion disable_completion;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/1] drm/imx/dcss: Add interconnect support
This allows us to raise DRAM bandiwth to a high enough value for a stable picture on i.mx8mq. We pick a bandwidth that should be sufficient for 4k@60Hz. This was tested on a Librem 5 with the (not yet) mainline mhdp DP controller. Without that initial boot works fine but e.g. fb unblank results in a cyan screen. Modelled like mdp5_kms. Guido Günther (1): drm/imx/dcss: Add interconnect support drivers/gpu/drm/imx/dcss/dcss-dev.c | 47 +++-- drivers/gpu/drm/imx/dcss/dcss-dev.h | 3 ++ 2 files changed, 48 insertions(+), 2 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nwl-dsi: fixup mode only for LCDIF input, not DCSS
Hi Lukas,
On Tue, Nov 24, 2020 at 06:12:17PM +0100, Lukas F. Hartmann wrote:
> The fixup of HSYNC and VSYNC should not be done when the input source is
> DCSS, or internal display does not work on MNT Reform 2 (open hardware
> laptop based on NXP i.MX8M using DCSS->DSI->eDP for internal display).
>
> Signed-off-by: Lukas F. Hartmann
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 66b67402f..6735ab2a2 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -807,10 +807,16 @@ static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge
> *bridge,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> - /* At least LCDIF + NWL needs active high sync */
> - adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> - adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> + struct device_node *remote;
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
> + NWL_DSI_ENDPOINT_LCDIF);
> + if (remote) {
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> + }
When submitting the NWL driver i was told to not change properties based
on the endpoint. The argument is that this breaks when putting the
bridge into another chain and that there might be other bridges in
between. Maybe Laurent and Andrzej have a suggetion?
I intend to respin the input mux bridge
(https://lore.kernel.org/dri-devel/cover.1589548223.git@sigxcpu.org/)
at some point but even then we need to carry over the flags, so any
input on how that should best be done would be welcome.
Cheers,
-- Guido
>
> return true;
> }
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions
Hi, On Mon, Nov 23, 2020 at 10:48:26PM +0100, Sam Ravnborg wrote: > Hi Guido, > > On Wed, Nov 18, 2020 at 09:29:47AM +0100, Guido Günther wrote: > > This adds new panel type to the mantix driver as found on the Librem 5 and > > fixes a glitch in the init sequence (affecting both panels). The fix is at > > the > > start of the series to make backporting simpler. > > It also adds a patch to make st7703 use dev_err_probe(). > > > > changes from v1 > > - as per review comments by Linus Walleij > > - fix alphabetical ordering in > > Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/ > > - add reviewed by to all except 5/6, thanks > > > > Guido Günther (6): > > drm/panel: st7703: Use dev_err_probe > > drm/panel: mantix: Tweak init sequence > > drm/panel: mantix: Allow to specify default mode for different panels > > drm/panel: mantix: Support panel from Shenzhen Yashi Changhua > > Intelligent Technology Co > > dt-bindings: vendor-prefixes: Add ys vendor prefix > The above are all: > Reviewed-by: Sam Ravnborg > > > dt-binding: display: mantix: Add compatible for panel from YS > Please fix the subjects to read "dt-bindings" - just to be consistent. > With that: > Reviewed-by: Sam Ravnborg Fixed locally, thanks! -- Guido > > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions
Hi Linus, On Thu, Nov 19, 2020 at 09:35:17AM +0100, Linus Walleij wrote: > On Wed, Nov 18, 2020 at 9:29 AM Guido Günther wrote: > > > This adds new panel type to the mantix driver as found on the Librem 5 and > > fixes a glitch in the init sequence (affecting both panels). The fix is at > > the > > start of the series to make backporting simpler. > > It also adds a patch to make st7703 use dev_err_probe(). > > > > changes from v1 > > - as per review comments by Linus Walleij > > - fix alphabetical ordering in > > Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/ > > - add reviewed by to all except 5/6, thanks > > The whole v2 looks fine to me, I'd give the devicetree > maintainers some slack to review the DT patches then I can > apply the whole series unless you have commit access yourself, > just tell me. I have commit access, so i can push in a couple of days. Thanks! > > For all v2 patches: > Reviewed-by: Linus Walleij > > If you have time, please review my s6e63m0 series. > https://lore.kernel.org/dri-devel/20201117175621.870085-1-linus.wall...@linaro.org/ > https://lore.kernel.org/dri-devel/20201117175621.870085-2-linus.wall...@linaro.org/ > https://lore.kernel.org/dri-devel/20201117175621.870085-3-linus.wall...@linaro.org/ Done. The panel stuff is always scary with all those magic values. -- Guido > > Yours, > Linus Walleij > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/panel: s6e63m0: Fix and extend MCS table
Hi Linus, The whole series looks good to me code wise so Reviewed-by: Guido Günther but i have no means to test the changes. Cheers, -- Guido On Tue, Nov 17, 2020 at 06:56:19PM +0100, Linus Walleij wrote: > Fix up the format of the manufacturer command set table > to be TAB-indented and lowercase. Add the MCS_TEMP_SWIRE > command that we will make use of. > > Cc: Stephan Gerhold > Cc: Paweł Chmiel > Signed-off-by: Linus Walleij > --- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > index 210e70da3a15..8fce399fb97d 100644 > --- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > @@ -23,20 +23,21 @@ > #include "panel-samsung-s6e63m0.h" > > /* Manufacturer Command Set */ > -#define MCS_ELVSS_ON0xb1 > -#define MCS_MIECTL10xc0 > -#define MCS_BCMODE 0xc1 > +#define MCS_ELVSS_ON 0xb1 > +#define MCS_TEMP_SWIRE 0xb2 > +#define MCS_MIECTL1 0xc0 > +#define MCS_BCMODE 0xc1 > #define MCS_ERROR_CHECK 0xd5 > #define MCS_READ_ID1 0xda > #define MCS_READ_ID2 0xdb > #define MCS_READ_ID3 0xdc > #define MCS_LEVEL_2_KEY 0xf0 > #define MCS_MTP_KEY 0xf1 > -#define MCS_DISCTL 0xf2 > -#define MCS_SRCCTL 0xf6 > -#define MCS_IFCTL 0xf7 > -#define MCS_PANELCTL 0xF8 > -#define MCS_PGAMMACTL 0xfa > +#define MCS_DISCTL 0xf2 > +#define MCS_SRCCTL 0xf6 > +#define MCS_IFCTL0xf7 > +#define MCS_PANELCTL 0xf8 > +#define MCS_PGAMMACTL0xfa > > #define S6E63M0_LCD_ID_VALUE_M2 0xA4 > #define S6E63M0_LCD_ID_VALUE_SM2 0xB4 > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Hi, On Tue, Nov 17, 2020 at 09:42:33PM +0100, Linus Walleij wrote: > On Tue, Nov 17, 2020 at 6:49 PM Guido Günther wrote: > > > Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. > > > > Signed-off-by: Guido Günther > > --- > > 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 e40ee369f808..d0f3abf2f12c 100644 > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > @@ -1220,6 +1220,8 @@ patternProperties: > > description: Shenzhen Yangliming Electronic Technology Co., Ltd. > >"^yna,.*": > > description: YSH & ATIL > > + "^ys,.*": > > +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. > >"^yones-toptech,.*": > > description: Yones Toptech Co., Ltd. > >"^ysoft,.*": > > I think this should be in alphabetical order of the compatible string, i.e. > under yones. Messed that up during rebase. Fixed in v2. Thanks for the review! -- Guido > > Yours, > Linus Walleij > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] dt-binding: display: mantix: Add compatible for panel from YS
This panel from Shenzhen Yashi Changhua Intelligent Technology Co uses the same driver IC but a different LCD. Signed-off-by: Guido Günther Reviewed-by: Linus Walleij --- .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 51f423297ec8..9e78f2e60f99 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - mantix,mlaf057we51-x + - ys,ys57pss36bh5gq port: true reg: -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. Signed-off-by: Guido Günther --- 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 e40ee369f808..fbcba08450c5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1222,6 +1222,8 @@ patternProperties: description: YSH & ATIL "^yones-toptech,.*": description: Yones Toptech Co., Ltd. + "^ys,.*": +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. "^ysoft,.*": description: Y Soft Corporation a.s. "^zealz,.*": -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/panel: mantix: Tweak init sequence
We've seen some (non permanent) burn in and bad white balance
on some of the panels. Adding this bit from a vendor supplied
sequence fixes it.
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X
DSI panel")
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 0c5f22e95c2d..624d17b96a69 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -22,6 +22,7 @@
/* Manufacturer specific Commands send via DSI */
#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
#define MANTIX_CMD_INT_CANCEL 0x4C
+#define MANTIX_CMD_SPI_FINISH 0x90
struct mantix {
struct device *dev;
@@ -66,6 +67,10 @@ static int mantix_init_sequence(struct mantix *ctx)
dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00, 0x64, 0x00, 0x00);
msleep(20);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_SPI_FINISH, 0xA5);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x00, 0x2F);
+ msleep(20);
+
dev_dbg(dev, "Panel init sequence done\n");
return 0;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/panel: st7703: Use dev_err_probe
Less code and easier probe deferral debugging.
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 +++
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b30510b1696a..a2c303e5732c 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -530,10 +530,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(ctx->reset_gpio)) {
- dev_err(dev, "cannot get reset gpio\n");
- return PTR_ERR(ctx->reset_gpio);
- }
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), "Failed to
get reset gpio\n");
mipi_dsi_set_drvdata(dsi, ctx);
@@ -545,19 +543,13 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
dsi->lanes = ctx->desc->lanes;
ctx->vcc = devm_regulator_get(dev, "vcc");
- if (IS_ERR(ctx->vcc)) {
- ret = PTR_ERR(ctx->vcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request vcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->vcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->vcc), "Failed to request
vcc regulator\n");
+
ctx->iovcc = devm_regulator_get(dev, "iovcc");
- if (IS_ERR(ctx->iovcc)) {
- ret = PTR_ERR(ctx->iovcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request iovcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->iovcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->iovcc),
+"Failed to request iovcc regulator\n");
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co
The panel uses the same driver IC and has the same resolution but a
slightly different default mode. It seems it can work with the same
init sequence.
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index b057857165b0..30f28ad4df6b 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -205,6 +205,21 @@ static const struct drm_display_mode default_mode_mantix =
{
.height_mm = 130,
};
+static const struct drm_display_mode default_mode_ys = {
+ .hdisplay= 720,
+ .hsync_start = 720 + 45,
+ .hsync_end = 720 + 45 + 14,
+ .htotal = 720 + 45 + 14 + 25,
+ .vdisplay= 1440,
+ .vsync_start = 1440 + 175,
+ .vsync_end = 1440 + 175 + 8,
+ .vtotal = 1440 + 175 + 8 + 50,
+ .clock = 85298,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .width_mm= 65,
+ .height_mm = 130,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -326,6 +341,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
static const struct of_device_id mantix_of_match[] = {
{ .compatible = "mantix,mlaf057we51-x", .data = _mode_mantix },
+ { .compatible = "ys,ys57pss36bh5gq", .data = _mode_ys },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] drm/panel: mantix: Allow to specify default mode for different panels
This can be used to use different modes for differnt panels via OF
device match.
Signed-off-by: Guido Günther
Reviewed-by: Linus Walleij
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 624d17b96a69..b057857165b0 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,6 +35,8 @@ struct mantix {
struct regulator *avdd;
struct regulator *avee;
struct regulator *vddi;
+
+ const struct drm_display_mode *default_mode;
};
static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
@@ -187,7 +190,7 @@ static int mantix_prepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode default_mode_mantix = {
.hdisplay= 720,
.hsync_start = 720 + 45,
.hsync_end = 720 + 45 + 14,
@@ -208,11 +211,11 @@ static int mantix_get_modes(struct drm_panel *panel,
struct mantix *ctx = panel_to_mantix(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, _mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->default_mode);
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(_mode));
+ ctx->default_mode->hdisplay,
ctx->default_mode->vdisplay,
+ drm_mode_vrefresh(ctx->default_mode));
return -ENOMEM;
}
@@ -243,6 +246,7 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+ ctx->default_mode = of_device_get_match_data(dev);
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
@@ -293,8 +297,8 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
}
dev_info(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
-default_mode.hdisplay, default_mode.vdisplay,
-drm_mode_vrefresh(_mode),
+ctx->default_mode->hdisplay, ctx->default_mode->vdisplay,
+drm_mode_vrefresh(ctx->default_mode),
mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
return 0;
@@ -321,7 +325,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id mantix_of_match[] = {
- { .compatible = "mantix,mlaf057we51-x" },
+ { .compatible = "mantix,mlaf057we51-x", .data = _mode_mantix },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions
This adds new panel type to the mantix driver as found on the Librem 5 and fixes a glitch in the init sequence (affecting both panels). The fix is at the start of the series to make backporting simpler. It also adds a patch to make st7703 use dev_err_probe(). changes from v1 - as per review comments by Linus Walleij - fix alphabetical ordering in Documentation/devicetree/bindings/vendor-prefixes.yaml https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/ - add reviewed by to all except 5/6, thanks Guido Günther (6): drm/panel: st7703: Use dev_err_probe drm/panel: mantix: Tweak init sequence drm/panel: mantix: Allow to specify default mode for different panels drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co dt-bindings: vendor-prefixes: Add ys vendor prefix dt-binding: display: mantix: Add compatible for panel from YS .../display/panel/mantix,mlaf057we51-x.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 39 +++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 4 files changed, 43 insertions(+), 23 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/6] drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co
The panel uses the same driver IC and has the same resolution but a
slightly different default mode. It seems it can work with the same
init sequence.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index b057857165b0..30f28ad4df6b 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -205,6 +205,21 @@ static const struct drm_display_mode default_mode_mantix =
{
.height_mm = 130,
};
+static const struct drm_display_mode default_mode_ys = {
+ .hdisplay= 720,
+ .hsync_start = 720 + 45,
+ .hsync_end = 720 + 45 + 14,
+ .htotal = 720 + 45 + 14 + 25,
+ .vdisplay= 1440,
+ .vsync_start = 1440 + 175,
+ .vsync_end = 1440 + 175 + 8,
+ .vtotal = 1440 + 175 + 8 + 50,
+ .clock = 85298,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .width_mm= 65,
+ .height_mm = 130,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -326,6 +341,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
static const struct of_device_id mantix_of_match[] = {
{ .compatible = "mantix,mlaf057we51-x", .data = _mode_mantix },
+ { .compatible = "ys,ys57pss36bh5gq", .data = _mode_ys },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/6] drm/panel: mantix: Tweak init sequence
We've seen some (non permanent) burn in and bad white balance
on some of the panels. Adding this bit from a vendor supplied
sequence fixes it.
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X
DSI panel")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 0c5f22e95c2d..624d17b96a69 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -22,6 +22,7 @@
/* Manufacturer specific Commands send via DSI */
#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
#define MANTIX_CMD_INT_CANCEL 0x4C
+#define MANTIX_CMD_SPI_FINISH 0x90
struct mantix {
struct device *dev;
@@ -66,6 +67,10 @@ static int mantix_init_sequence(struct mantix *ctx)
dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00, 0x64, 0x00, 0x00);
msleep(20);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_SPI_FINISH, 0xA5);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x00, 0x2F);
+ msleep(20);
+
dev_dbg(dev, "Panel init sequence done\n");
return 0;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 6/6] dt-binding: display: mantix: Add compatible for panel from YS
This panel from Shenzhen Yashi Changhua Intelligent Technology Co uses the same driver IC but a different LCD. Signed-off-by: Guido Günther --- .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 51f423297ec8..9e78f2e60f99 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - mantix,mlaf057we51-x + - ys,ys57pss36bh5gq port: true reg: -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/6] drm/panel: mantix: Allow to specify default mode for different panels
This can be used to use different modes for differnt panels via OF
device match.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 624d17b96a69..b057857165b0 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,6 +35,8 @@ struct mantix {
struct regulator *avdd;
struct regulator *avee;
struct regulator *vddi;
+
+ const struct drm_display_mode *default_mode;
};
static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
@@ -187,7 +190,7 @@ static int mantix_prepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode default_mode_mantix = {
.hdisplay= 720,
.hsync_start = 720 + 45,
.hsync_end = 720 + 45 + 14,
@@ -208,11 +211,11 @@ static int mantix_get_modes(struct drm_panel *panel,
struct mantix *ctx = panel_to_mantix(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, _mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->default_mode);
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(_mode));
+ ctx->default_mode->hdisplay,
ctx->default_mode->vdisplay,
+ drm_mode_vrefresh(ctx->default_mode));
return -ENOMEM;
}
@@ -243,6 +246,7 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+ ctx->default_mode = of_device_get_match_data(dev);
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
@@ -293,8 +297,8 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
}
dev_info(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
-default_mode.hdisplay, default_mode.vdisplay,
-drm_mode_vrefresh(_mode),
+ctx->default_mode->hdisplay, ctx->default_mode->vdisplay,
+drm_mode_vrefresh(ctx->default_mode),
mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
return 0;
@@ -321,7 +325,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id mantix_of_match[] = {
- { .compatible = "mantix,mlaf057we51-x" },
+ { .compatible = "mantix,mlaf057we51-x", .data = _mode_mantix },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/6] drm/panel: st7703: Use dev_err_probe
Less code and easier probe deferral debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 +++
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b30510b1696a..a2c303e5732c 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -530,10 +530,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(ctx->reset_gpio)) {
- dev_err(dev, "cannot get reset gpio\n");
- return PTR_ERR(ctx->reset_gpio);
- }
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), "Failed to
get reset gpio\n");
mipi_dsi_set_drvdata(dsi, ctx);
@@ -545,19 +543,13 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
dsi->lanes = ctx->desc->lanes;
ctx->vcc = devm_regulator_get(dev, "vcc");
- if (IS_ERR(ctx->vcc)) {
- ret = PTR_ERR(ctx->vcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request vcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->vcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->vcc), "Failed to request
vcc regulator\n");
+
ctx->iovcc = devm_regulator_get(dev, "iovcc");
- if (IS_ERR(ctx->iovcc)) {
- ret = PTR_ERR(ctx->iovcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request iovcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->iovcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->iovcc),
+"Failed to request iovcc regulator\n");
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. Signed-off-by: Guido Günther --- 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 e40ee369f808..d0f3abf2f12c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1220,6 +1220,8 @@ patternProperties: description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": description: YSH & ATIL + "^ys,.*": +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. "^yones-toptech,.*": description: Yones Toptech Co., Ltd. "^ysoft,.*": -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/6] drm/panel: mantix and st7703 fixes and additions
This adds new panel type to the mantix driver as found on the Librem 5 and fixes a glitch in the init sequence (affecting both panels). The fix is at the start of the series to make backporting simpler. It also adds a patch to make st7703 use dev_err_probe(). Guido Günther (6): drm/panel: st7703: Use dev_err_probe drm/panel: mantix: Tweak init sequence drm/panel: mantix: Allow to specify default mode for different panels drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co dt-bindings: vendor-prefixes: Add ys vendor prefix dt-binding: display: mantix: Add compatible for panel from YS .../display/panel/mantix,mlaf057we51-x.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 39 +++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 4 files changed, 43 insertions(+), 23 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
