[PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.

Changes for v8:
* fixed comment lines
* fixed commit messages
* fixed video mode bits
* collect Marek Ack
* fixed video mode bit names
* update input formats logic
* added imx8mplus support

Changes for v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic

Changes for v6:
* handle previous bridge for exynos dsi while attaching bridge 

Changes for v5:
* bridge changes to support multi-arch
* updated and clear commit messages
* add hw_type via plat data
* removed unneeded quirk
* rebased on linux-next

Changes for v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build
* update init handling to ensure host init done on first cmd transfer

Changes for v3:
* fix the mult-arch build
* fix dsi host init
* updated commit messages

Changes for v2:
* fix bridge handling
* fix dsi host init
* correct the commit messages

Patch 0001:	Fix MIPI_DSI*_NO_* mode bits

Patch 0002:	Properly name HSA/HBP/HFP/HSE bits

Patch 0003: 	Samsung DSIM bridge

Patch 0004:	PHY optional

Patch 0005:	OF-graph or Child node lookup

Patch 0006: 	DSI host initialization 

Patch 0007:	atomic check

Patch 0008:	PMS_P offset via plat data

Patch 0009:	atomic_get_input_bus_fmts

Patch 0010:	input_bus_flags

Patch 0011:	document fsl,imx8mm-mipi-dsim

Patch 0012:	add i.MX8M Mini/Nano DSIM support

Patch 0013:	document fsl,imx8mp-mipi-dsim

Patch 0014:	add i.MX8M Plus DSIM support

Tested in Engicam i.Core MX8M Mini SoM.

Repo:
https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v8

Any inputs?
Jagan.

Jagan Teki (13):
  drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
  drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits
  drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
  drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
  drm: bridge: samsung-dsim: Mark PHY as optional
  drm: bridge: samsung-dsim: Handle proper DSI host initialization
  drm: bridge: samsung-dsim: Add atomic_check
  drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset
  drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
  drm: bridge: samsung-dsim: Add input_bus_flags
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support
  drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

Marek Vasut (1):
  drm: bridge: samsung-dsim: Add i.MX8M Plus support

 .../bindings/display/exynos/exynos_dsim.txt   |    2 +
 MAINTAINERS                                   |    9 +
 drivers/gpu/drm/bridge/Kconfig                |   12 +
 drivers/gpu/drm/bridge/Makefile               |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1908 +++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1766 +--------------
 include/drm/bridge/samsung-dsim.h             |  116 +
 8 files changed, 2162 insertions(+), 1653 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1

[PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.

Changes for v8:
* fixed comment lines
* fixed commit messages
* fixed video mode bits
* collect Marek Ack
* fixed video mode bit names
* update input formats logic
* added imx8mplus support

Changes for v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic

Changes for v6:
* handle previous bridge for exynos dsi while attaching bridge 

Changes for v5:
* bridge changes to support multi-arch
* updated and clear commit messages
* add hw_type via plat data
* removed unneeded quirk
* rebased on linux-next

Changes for v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build
* update init handling to ensure host init done on first cmd transfer

Changes for v3:
* fix the mult-arch build
* fix dsi host init
* updated commit messages

Changes for v2:
* fix bridge handling
* fix dsi host init
* correct the commit messages

Patch 0001:	Fix MIPI_DSI*_NO_* mode bits

Patch 0002:	Properly name HSA/HBP/HFP/HSE bits

Patch 0003: 	Samsung DSIM bridge

Patch 0004:	PHY optional

Patch 0005:	OF-graph or Child node lookup

Patch 0006: 	DSI host initialization 

Patch 0007:	atomic check

Patch 0008:	PMS_P offset via plat data

Patch 0009:	atomic_get_input_bus_fmts

Patch 0010:	input_bus_flags

Patch 0011:	document fsl,imx8mm-mipi-dsim

Patch 0012:	add i.MX8M Mini/Nano DSIM support

Patch 0013:	document fsl,imx8mp-mipi-dsim

Patch 0014:	add i.MX8M Plus DSIM support

Tested in Engicam i.Core MX8M Mini SoM.

Repo:
https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v8

Any inputs?
Jagan.

Jagan Teki (13):
  drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
  drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits
  drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
  drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
  drm: bridge: samsung-dsim: Mark PHY as optional
  drm: bridge: samsung-dsim: Handle proper DSI host initialization
  drm: bridge: samsung-dsim: Add atomic_check
  drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset
  drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
  drm: bridge: samsung-dsim: Add input_bus_flags
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support
  drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

Marek Vasut (1):
  drm: bridge: samsung-dsim: Add i.MX8M Plus support

 .../bindings/display/exynos/exynos_dsim.txt   |    2 +
 MAINTAINERS                                   |    9 +
 drivers/gpu/drm/bridge/Kconfig                |   12 +
 drivers/gpu/drm/bridge/Makefile               |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1908 +++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1766 +--------------
 include/drm/bridge/samsung-dsim.h             |  116 +
 8 files changed, 2162 insertions(+), 1653 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.

Changes for v8:
* fixed comment lines
* fixed commit messages
* fixed video mode bits
* collect Marek Ack
* fixed video mode bit names
* update input formats logic
* added imx8mplus support

Changes for v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic

Changes for v6:
* handle previous bridge for exynos dsi while attaching bridge 

Changes for v5:
* bridge changes to support multi-arch
* updated and clear commit messages
* add hw_type via plat data
* removed unneeded quirk
* rebased on linux-next

Changes for v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build
* update init handling to ensure host init done on first cmd transfer

Changes for v3:
* fix the mult-arch build
* fix dsi host init
* updated commit messages

Changes for v2:
* fix bridge handling
* fix dsi host init
* correct the commit messages

Patch 0001:	Fix MIPI_DSI*_NO_* mode bits

Patch 0002:	Properly name HSA/HBP/HFP/HSE bits

Patch 0003: 	Samsung DSIM bridge

Patch 0004:	PHY optional

Patch 0005:	OF-graph or Child node lookup

Patch 0006: 	DSI host initialization 

Patch 0007:	atomic check

Patch 0008:	PMS_P offset via plat data

Patch 0009:	atomic_get_input_bus_fmts

Patch 0010:	input_bus_flags

Patch 0011:	document fsl,imx8mm-mipi-dsim

Patch 0012:	add i.MX8M Mini/Nano DSIM support

Patch 0013:	document fsl,imx8mp-mipi-dsim

Patch 0014:	add i.MX8M Plus DSIM support

Tested in Engicam i.Core MX8M Mini SoM.

Repo:
https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v8

Any inputs?
Jagan.

Jagan Teki (13):
  drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
  drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits
  drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
  drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
  drm: bridge: samsung-dsim: Mark PHY as optional
  drm: bridge: samsung-dsim: Handle proper DSI host initialization
  drm: bridge: samsung-dsim: Add atomic_check
  drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset
  drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
  drm: bridge: samsung-dsim: Add input_bus_flags
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support
  drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

Marek Vasut (1):
  drm: bridge: samsung-dsim: Add i.MX8M Plus support

 .../bindings/display/exynos/exynos_dsim.txt   |    2 +
 MAINTAINERS                                   |    9 +
 drivers/gpu/drm/bridge/Kconfig                |   12 +
 drivers/gpu/drm/bridge/Makefile               |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1908 +++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1766 +--------------
 include/drm/bridge/samsung-dsim.h             |  116 +
 8 files changed, 2162 insertions(+), 1653 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1

[PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
0 = Enable and 1 = Disable.

The logic for checking these mode flags was correct before
the MIPI_DSI*_NO_* mode flag conversion.

Fix the MIPI_DSI*_NO_* mode flags handling.

Fixes: 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
features")
Cc: Nicolas Boichat <drinkcat@chromium.org>
Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..b5305b145ddb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 			reg |= DSIM_AUTO_MODE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
 			reg |= DSIM_HSE_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
 			reg |= DSIM_HFP_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
 			reg |= DSIM_HBP_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
 			reg |= DSIM_HSA_MODE;
 	}
 
-	if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
+	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
 		reg |= DSIM_EOT_DISABLE;
 
 	switch (dsi->format) {
-- 
2.25.1

[PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
0 = Enable and 1 = Disable.

The logic for checking these mode flags was correct before
the MIPI_DSI*_NO_* mode flag conversion.

Fix the MIPI_DSI*_NO_* mode flags handling.

Fixes: 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
features")
Cc: Nicolas Boichat <drinkcat@chromium.org>
Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..b5305b145ddb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 			reg |= DSIM_AUTO_MODE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
 			reg |= DSIM_HSE_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
 			reg |= DSIM_HFP_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
 			reg |= DSIM_HBP_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
 			reg |= DSIM_HSA_MODE;
 	}
 
-	if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
+	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
 		reg |= DSIM_EOT_DISABLE;
 
 	switch (dsi->format) {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
0 = Enable and 1 = Disable.

The logic for checking these mode flags was correct before
the MIPI_DSI*_NO_* mode flag conversion.

Fix the MIPI_DSI*_NO_* mode flags handling.

Fixes: 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
features")
Cc: Nicolas Boichat <drinkcat@chromium.org>
Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..b5305b145ddb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 			reg |= DSIM_AUTO_MODE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
 			reg |= DSIM_HSE_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
 			reg |= DSIM_HFP_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
 			reg |= DSIM_HBP_MODE;
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
 			reg |= DSIM_HSA_MODE;
 	}
 
-	if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
+	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
 		reg |= DSIM_EOT_DISABLE;
 
 	switch (dsi->format) {
-- 
2.25.1

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> 0 = Enable and 1 = Disable.

Oh I see, that's confusing... IMHO you might want to change the
register macro name... (but if that's what the datasheet uses, it
might not be ideal either). At the _very_ least, I'd add a comment in
the code so the next person doesn't attempt to "fix" it again...

BTW, are you sure DSIM_HSE_MODE is correct now?

>
> The logic for checking these mode flags was correct before
> the MIPI_DSI*_NO_* mode flag conversion.
>
> Fix the MIPI_DSI*_NO_* mode flags handling.
>
> Fixes: 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
> features")
> Cc: Nicolas Boichat <drinkcat@chromium.org>
> Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index ec673223d6b7..b5305b145ddb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>                         reg |= DSIM_AUTO_MODE;
>                 if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
>                         reg |= DSIM_HSE_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
>                         reg |= DSIM_HFP_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
>                         reg |= DSIM_HBP_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
>                         reg |= DSIM_HSA_MODE;
>         }
>
> -       if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
> +       if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
>                 reg |= DSIM_EOT_DISABLE;
>
>         switch (dsi->format) {
> --
> 2.25.1
>

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> 0 = Enable and 1 = Disable.

Oh I see, that's confusing... IMHO you might want to change the
register macro name... (but if that's what the datasheet uses, it
might not be ideal either). At the _very_ least, I'd add a comment in
the code so the next person doesn't attempt to "fix" it again...

BTW, are you sure DSIM_HSE_MODE is correct now?

>
> The logic for checking these mode flags was correct before
> the MIPI_DSI*_NO_* mode flag conversion.
>
> Fix the MIPI_DSI*_NO_* mode flags handling.
>
> Fixes: 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
> features")
> Cc: Nicolas Boichat <drinkcat@chromium.org>
> Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index ec673223d6b7..b5305b145ddb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>                         reg |= DSIM_AUTO_MODE;
>                 if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
>                         reg |= DSIM_HSE_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
>                         reg |= DSIM_HFP_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
>                         reg |= DSIM_HBP_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
>                         reg |= DSIM_HSA_MODE;
>         }
>
> -       if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
> +       if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
>                 reg |= DSIM_EOT_DISABLE;
>
>         switch (dsi->format) {
> --
> 2.25.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> 0 = Enable and 1 = Disable.

Oh I see, that's confusing... IMHO you might want to change the
register macro name... (but if that's what the datasheet uses, it
might not be ideal either). At the _very_ least, I'd add a comment in
the code so the next person doesn't attempt to "fix" it again...

BTW, are you sure DSIM_HSE_MODE is correct now?

>
> The logic for checking these mode flags was correct before
> the MIPI_DSI*_NO_* mode flag conversion.
>
> Fix the MIPI_DSI*_NO_* mode flags handling.
>
> Fixes: 0f3b68b66a6d ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
> features")
> Cc: Nicolas Boichat <drinkcat@chromium.org>
> Reported-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index ec673223d6b7..b5305b145ddb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>                         reg |= DSIM_AUTO_MODE;
>                 if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
>                         reg |= DSIM_HSE_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
>                         reg |= DSIM_HFP_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
>                         reg |= DSIM_HBP_MODE;
> -               if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
> +               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
>                         reg |= DSIM_HSA_MODE;
>         }
>
> -       if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
> +       if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
>                 reg |= DSIM_EOT_DISABLE;
>
>         switch (dsi->format) {
> --
> 2.25.1
>

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > 0 = Enable and 1 = Disable.
>
> Oh I see, that's confusing... IMHO you might want to change the
> register macro name... (but if that's what the datasheet uses, it
> might not be ideal either). At the _very_ least, I'd add a comment in
> the code so the next person doesn't attempt to "fix" it again...

02/14 on the same series doing the name change.
https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/

>
> BTW, are you sure DSIM_HSE_MODE is correct now?

Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
initially observed this issue on the imx8m platform.

Jagan.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > 0 = Enable and 1 = Disable.
>
> Oh I see, that's confusing... IMHO you might want to change the
> register macro name... (but if that's what the datasheet uses, it
> might not be ideal either). At the _very_ least, I'd add a comment in
> the code so the next person doesn't attempt to "fix" it again...

02/14 on the same series doing the name change.
https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/

>
> BTW, are you sure DSIM_HSE_MODE is correct now?

Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
initially observed this issue on the imx8m platform.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > 0 = Enable and 1 = Disable.
>
> Oh I see, that's confusing... IMHO you might want to change the
> register macro name... (but if that's what the datasheet uses, it
> might not be ideal either). At the _very_ least, I'd add a comment in
> the code so the next person doesn't attempt to "fix" it again...

02/14 on the same series doing the name change.
https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/

>
> BTW, are you sure DSIM_HSE_MODE is correct now?

Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
initially observed this issue on the imx8m platform.

Jagan.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Fri, Nov 11, 2022 at 4:49 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> >
> > On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > > 0 = Enable and 1 = Disable.
> >
> > Oh I see, that's confusing... IMHO you might want to change the
> > register macro name... (but if that's what the datasheet uses, it
> > might not be ideal either). At the _very_ least, I'd add a comment in
> > the code so the next person doesn't attempt to "fix" it again...
>
> 02/14 on the same series doing the name change.
> https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/

Oh thanks I wasn't cc'ed on that one, makes sense.

You can add my reviewed tag to this one, as my HSE comment doesn't change this.

Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

But please double check HSE.

>
> >
> > BTW, are you sure DSIM_HSE_MODE is correct now?
>
> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> initially observed this issue on the imx8m platform.

I'll repeat, are you sure about HSE specifically? You invert the
polarity for HBP, HFP, and HSA, which makes sense given your patch
02/14.

I'm concerned about HSE. Is the bit really a disable bit?
MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
should not do `reg |= DSIM_HSE_DISABLE;`, probably.

Thanks,

>
> Jagan.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Fri, Nov 11, 2022 at 4:49 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> >
> > On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > > 0 = Enable and 1 = Disable.
> >
> > Oh I see, that's confusing... IMHO you might want to change the
> > register macro name... (but if that's what the datasheet uses, it
> > might not be ideal either). At the _very_ least, I'd add a comment in
> > the code so the next person doesn't attempt to "fix" it again...
>
> 02/14 on the same series doing the name change.
> https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/

Oh thanks I wasn't cc'ed on that one, makes sense.

You can add my reviewed tag to this one, as my HSE comment doesn't change this.

Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

But please double check HSE.

>
> >
> > BTW, are you sure DSIM_HSE_MODE is correct now?
>
> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> initially observed this issue on the imx8m platform.

I'll repeat, are you sure about HSE specifically? You invert the
polarity for HBP, HFP, and HSA, which makes sense given your patch
02/14.

I'm concerned about HSE. Is the bit really a disable bit?
MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
should not do `reg |= DSIM_HSE_DISABLE;`, probably.

Thanks,

>
> Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Fri, Nov 11, 2022 at 4:49 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> >
> > On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >
> > > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > > 0 = Enable and 1 = Disable.
> >
> > Oh I see, that's confusing... IMHO you might want to change the
> > register macro name... (but if that's what the datasheet uses, it
> > might not be ideal either). At the _very_ least, I'd add a comment in
> > the code so the next person doesn't attempt to "fix" it again...
>
> 02/14 on the same series doing the name change.
> https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/

Oh thanks I wasn't cc'ed on that one, makes sense.

You can add my reviewed tag to this one, as my HSE comment doesn't change this.

Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

But please double check HSE.

>
> >
> > BTW, are you sure DSIM_HSE_MODE is correct now?
>
> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> initially observed this issue on the imx8m platform.

I'll repeat, are you sure about HSE specifically? You invert the
polarity for HBP, HFP, and HSA, which makes sense given your patch
02/14.

I'm concerned about HSE. Is the bit really a disable bit?
MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
should not do `reg |= DSIM_HSE_DISABLE;`, probably.

Thanks,

>
> Jagan.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

On Fri, Nov 11, 2022 at 5:42 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Fri, Nov 11, 2022 at 4:49 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > > > 0 = Enable and 1 = Disable.
> > >
> > > Oh I see, that's confusing... IMHO you might want to change the
> > > register macro name... (but if that's what the datasheet uses, it
> > > might not be ideal either). At the _very_ least, I'd add a comment in
> > > the code so the next person doesn't attempt to "fix" it again...
> >
> > 02/14 on the same series doing the name change.
> > https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/
>
> Oh thanks I wasn't cc'ed on that one, makes sense.
>
> You can add my reviewed tag to this one, as my HSE comment doesn't change this.
>
> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
>
> But please double check HSE.
>
> >
> > >
> > > BTW, are you sure DSIM_HSE_MODE is correct now?
> >
> > Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> > initially observed this issue on the imx8m platform.
>
> I'll repeat, are you sure about HSE specifically? You invert the
> polarity for HBP, HFP, and HSA, which makes sense given your patch
> 02/14.
>
> I'm concerned about HSE. Is the bit really a disable bit?
> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> should not do `reg |= DSIM_HSE_DISABLE;`, probably.

HSE typically enables bit logic, unlike other bits which are disabled bits.

HseDisableMod:
In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
start packet to MIPI DSI slave at
MIPI DSI spec 1.1r02. This bit transfers Hsync end packet in Vsync
pulse and Vporch area (optional).
0 = Disables transfer
1 = Enables transfer

HfpDisableMode:
Specifies HFP disable mode. If this bit set, DSI master ignores HFP
area in Video mode.
0 = Enables
1 = Disables

I think the naming of 'HseDisableMod' is misleading in the datasheet,
but I have used it as per the spec.

Jagan.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

On Fri, Nov 11, 2022 at 5:42 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Fri, Nov 11, 2022 at 4:49 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > > > 0 = Enable and 1 = Disable.
> > >
> > > Oh I see, that's confusing... IMHO you might want to change the
> > > register macro name... (but if that's what the datasheet uses, it
> > > might not be ideal either). At the _very_ least, I'd add a comment in
> > > the code so the next person doesn't attempt to "fix" it again...
> >
> > 02/14 on the same series doing the name change.
> > https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/
>
> Oh thanks I wasn't cc'ed on that one, makes sense.
>
> You can add my reviewed tag to this one, as my HSE comment doesn't change this.
>
> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
>
> But please double check HSE.
>
> >
> > >
> > > BTW, are you sure DSIM_HSE_MODE is correct now?
> >
> > Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> > initially observed this issue on the imx8m platform.
>
> I'll repeat, are you sure about HSE specifically? You invert the
> polarity for HBP, HFP, and HSA, which makes sense given your patch
> 02/14.
>
> I'm concerned about HSE. Is the bit really a disable bit?
> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> should not do `reg |= DSIM_HSE_DISABLE;`, probably.

HSE typically enables bit logic, unlike other bits which are disabled bits.

HseDisableMod:
In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
start packet to MIPI DSI slave at
MIPI DSI spec 1.1r02. This bit transfers Hsync end packet in Vsync
pulse and Vporch area (optional).
0 = Disables transfer
1 = Enables transfer

HfpDisableMode:
Specifies HFP disable mode. If this bit set, DSI master ignores HFP
area in Video mode.
0 = Enables
1 = Disables

I think the naming of 'HseDisableMod' is misleading in the datasheet,
but I have used it as per the spec.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Jagan Teki]

On Fri, Nov 11, 2022 at 5:42 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Fri, Nov 11, 2022 at 4:49 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > On Fri, Nov 11, 2022 at 6:19 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > On Fri, Nov 11, 2022 at 2:40 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > > >
> > > > HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> > > > 0 = Enable and 1 = Disable.
> > >
> > > Oh I see, that's confusing... IMHO you might want to change the
> > > register macro name... (but if that's what the datasheet uses, it
> > > might not be ideal either). At the _very_ least, I'd add a comment in
> > > the code so the next person doesn't attempt to "fix" it again...
> >
> > 02/14 on the same series doing the name change.
> > https://lore.kernel.org/all/20221110183853.3678209-3-jagan@amarulasolutions.com/
>
> Oh thanks I wasn't cc'ed on that one, makes sense.
>
> You can add my reviewed tag to this one, as my HSE comment doesn't change this.
>
> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
>
> But please double check HSE.
>
> >
> > >
> > > BTW, are you sure DSIM_HSE_MODE is correct now?
> >
> > Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> > initially observed this issue on the imx8m platform.
>
> I'll repeat, are you sure about HSE specifically? You invert the
> polarity for HBP, HFP, and HSA, which makes sense given your patch
> 02/14.
>
> I'm concerned about HSE. Is the bit really a disable bit?
> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> should not do `reg |= DSIM_HSE_DISABLE;`, probably.

HSE typically enables bit logic, unlike other bits which are disabled bits.

HseDisableMod:
In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
start packet to MIPI DSI slave at
MIPI DSI spec 1.1r02. This bit transfers Hsync end packet in Vsync
pulse and Vporch area (optional).
0 = Disables transfer
1 = Enables transfer

HfpDisableMode:
Specifies HFP disable mode. If this bit set, DSI master ignores HFP
area in Video mode.
0 = Enables
1 = Disables

I think the naming of 'HseDisableMod' is misleading in the datasheet,
but I have used it as per the spec.

Jagan.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Vasut]

On 11/11/22 13:12, Nicolas Boichat wrote:

[...]

>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>
>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>> initially observed this issue on the imx8m platform.
> 
> I'll repeat, are you sure about HSE specifically? You invert the
> polarity for HBP, HFP, and HSA, which makes sense given your patch
> 02/14.
> 
> I'm concerned about HSE. Is the bit really a disable bit?
> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> should not do `reg |= DSIM_HSE_DISABLE;`, probably.

I suspect the HSE bit is a misnomer, but its handling in the driver is 
correct.

i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
Page 5436

23 HseDisableMode

In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync 
start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit 
transfers Hsync end packet in Vsync pulse and Vporch area (optional).

0 = Disables transfer
1 = Enables transfer

In command mode, this bit is ignored.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Vasut]

On 11/11/22 13:12, Nicolas Boichat wrote:

[...]

>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>
>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>> initially observed this issue on the imx8m platform.
> 
> I'll repeat, are you sure about HSE specifically? You invert the
> polarity for HBP, HFP, and HSA, which makes sense given your patch
> 02/14.
> 
> I'm concerned about HSE. Is the bit really a disable bit?
> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> should not do `reg |= DSIM_HSE_DISABLE;`, probably.

I suspect the HSE bit is a misnomer, but its handling in the driver is 
correct.

i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
Page 5436

23 HseDisableMode

In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync 
start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit 
transfers Hsync end packet in Vsync pulse and Vporch area (optional).

0 = Disables transfer
1 = Enables transfer

In command mode, this bit is ignored.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Vasut]

On 11/11/22 13:12, Nicolas Boichat wrote:

[...]

>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>
>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>> initially observed this issue on the imx8m platform.
> 
> I'll repeat, are you sure about HSE specifically? You invert the
> polarity for HBP, HFP, and HSA, which makes sense given your patch
> 02/14.
> 
> I'm concerned about HSE. Is the bit really a disable bit?
> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> should not do `reg |= DSIM_HSE_DISABLE;`, probably.

I suspect the HSE bit is a misnomer, but its handling in the driver is 
correct.

i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
Page 5436

23 HseDisableMode

In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync 
start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit 
transfers Hsync end packet in Vsync pulse and Vporch area (optional).

0 = Disables transfer
1 = Enables transfer

In command mode, this bit is ignored.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/11/22 13:12, Nicolas Boichat wrote:
>
> [...]
>
> >>> BTW, are you sure DSIM_HSE_MODE is correct now?
> >>
> >> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> >> initially observed this issue on the imx8m platform.
> >
> > I'll repeat, are you sure about HSE specifically? You invert the
> > polarity for HBP, HFP, and HSA, which makes sense given your patch
> > 02/14.
> >
> > I'm concerned about HSE. Is the bit really a disable bit?
> > MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> > should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>
> I suspect the HSE bit is a misnomer, but its handling in the driver is
> correct.
>
> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
> Page 5436
>
> 23 HseDisableMode
>
> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>
> 0 = Disables transfer
> 1 = Enables transfer
>
> In command mode, this bit is ignored.

Okay. I'd suggest adding a comment in the code, it'd be so tempting to
attempt to "fix" this as the if/or pattern looks different from the
others.

But it's up to you all.

Thanks,

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/11/22 13:12, Nicolas Boichat wrote:
>
> [...]
>
> >>> BTW, are you sure DSIM_HSE_MODE is correct now?
> >>
> >> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> >> initially observed this issue on the imx8m platform.
> >
> > I'll repeat, are you sure about HSE specifically? You invert the
> > polarity for HBP, HFP, and HSA, which makes sense given your patch
> > 02/14.
> >
> > I'm concerned about HSE. Is the bit really a disable bit?
> > MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> > should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>
> I suspect the HSE bit is a misnomer, but its handling in the driver is
> correct.
>
> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
> Page 5436
>
> 23 HseDisableMode
>
> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>
> 0 = Disables transfer
> 1 = Enables transfer
>
> In command mode, this bit is ignored.

Okay. I'd suggest adding a comment in the code, it'd be so tempting to
attempt to "fix" this as the if/or pattern looks different from the
others.

But it's up to you all.

Thanks,

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Nicolas Boichat]

On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/11/22 13:12, Nicolas Boichat wrote:
>
> [...]
>
> >>> BTW, are you sure DSIM_HSE_MODE is correct now?
> >>
> >> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
> >> initially observed this issue on the imx8m platform.
> >
> > I'll repeat, are you sure about HSE specifically? You invert the
> > polarity for HBP, HFP, and HSA, which makes sense given your patch
> > 02/14.
> >
> > I'm concerned about HSE. Is the bit really a disable bit?
> > MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
> > should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>
> I suspect the HSE bit is a misnomer, but its handling in the driver is
> correct.
>
> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
> Page 5436
>
> 23 HseDisableMode
>
> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>
> 0 = Disables transfer
> 1 = Enables transfer
>
> In command mode, this bit is ignored.

Okay. I'd suggest adding a comment in the code, it'd be so tempting to
attempt to "fix" this as the if/or pattern looks different from the
others.

But it's up to you all.

Thanks,

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Vasut]

On 11/14/22 02:11, Nicolas Boichat wrote:
> On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/11/22 13:12, Nicolas Boichat wrote:
>>
>> [...]
>>
>>>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>>>
>>>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>>>> initially observed this issue on the imx8m platform.
>>>
>>> I'll repeat, are you sure about HSE specifically? You invert the
>>> polarity for HBP, HFP, and HSA, which makes sense given your patch
>>> 02/14.
>>>
>>> I'm concerned about HSE. Is the bit really a disable bit?
>>> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
>>> should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>>
>> I suspect the HSE bit is a misnomer, but its handling in the driver is
>> correct.
>>
>> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
>> Page 5436
>>
>> 23 HseDisableMode
>>
>> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
>> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
>> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>>
>> 0 = Disables transfer
>> 1 = Enables transfer
>>
>> In command mode, this bit is ignored.
> 
> Okay. I'd suggest adding a comment in the code, it'd be so tempting to
> attempt to "fix" this as the if/or pattern looks different from the
> others.
> 
> But it's up to you all.

I agree. Clearly the discrepancy is confusing and leads to mistakes.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Vasut]

On 11/14/22 02:11, Nicolas Boichat wrote:
> On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/11/22 13:12, Nicolas Boichat wrote:
>>
>> [...]
>>
>>>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>>>
>>>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>>>> initially observed this issue on the imx8m platform.
>>>
>>> I'll repeat, are you sure about HSE specifically? You invert the
>>> polarity for HBP, HFP, and HSA, which makes sense given your patch
>>> 02/14.
>>>
>>> I'm concerned about HSE. Is the bit really a disable bit?
>>> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
>>> should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>>
>> I suspect the HSE bit is a misnomer, but its handling in the driver is
>> correct.
>>
>> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
>> Page 5436
>>
>> 23 HseDisableMode
>>
>> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
>> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
>> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>>
>> 0 = Disables transfer
>> 1 = Enables transfer
>>
>> In command mode, this bit is ignored.
> 
> Okay. I'd suggest adding a comment in the code, it'd be so tempting to
> attempt to "fix" this as the if/or pattern looks different from the
> others.
> 
> But it's up to you all.

I agree. Clearly the discrepancy is confusing and leads to mistakes.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Vasut]

On 11/14/22 02:11, Nicolas Boichat wrote:
> On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/11/22 13:12, Nicolas Boichat wrote:
>>
>> [...]
>>
>>>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>>>
>>>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>>>> initially observed this issue on the imx8m platform.
>>>
>>> I'll repeat, are you sure about HSE specifically? You invert the
>>> polarity for HBP, HFP, and HSA, which makes sense given your patch
>>> 02/14.
>>>
>>> I'm concerned about HSE. Is the bit really a disable bit?
>>> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
>>> should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>>
>> I suspect the HSE bit is a misnomer, but its handling in the driver is
>> correct.
>>
>> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
>> Page 5436
>>
>> 23 HseDisableMode
>>
>> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
>> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
>> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>>
>> 0 = Disables transfer
>> 1 = Enables transfer
>>
>> In command mode, this bit is ignored.
> 
> Okay. I'd suggest adding a comment in the code, it'd be so tempting to
> attempt to "fix" this as the if/or pattern looks different from the
> others.
> 
> But it's up to you all.

I agree. Clearly the discrepancy is confusing and leads to mistakes.

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Frieder Schrempf]

On 14.11.22 04:16, Marek Vasut wrote:
> On 11/14/22 02:11, Nicolas Boichat wrote:
>> On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 11/11/22 13:12, Nicolas Boichat wrote:
>>>
>>> [...]
>>>
>>>>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>>>>
>>>>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>>>>> initially observed this issue on the imx8m platform.
>>>>
>>>> I'll repeat, are you sure about HSE specifically? You invert the
>>>> polarity for HBP, HFP, and HSA, which makes sense given your patch
>>>> 02/14.
>>>>
>>>> I'm concerned about HSE. Is the bit really a disable bit?
>>>> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
>>>> should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>>>
>>> I suspect the HSE bit is a misnomer, but its handling in the driver is
>>> correct.
>>>
>>> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
>>> Page 5436
>>>
>>> 23 HseDisableMode
>>>
>>> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
>>> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
>>> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>>>
>>> 0 = Disables transfer
>>> 1 = Enables transfer
>>>
>>> In command mode, this bit is ignored.
>>
>> Okay. I'd suggest adding a comment in the code, it'd be so tempting to
>> attempt to "fix" this as the if/or pattern looks different from the
>> others.
>>
>> But it's up to you all.
> 
> I agree. Clearly the discrepancy is confusing and leads to mistakes.

+1 for a comment in the code that explains the misnamed bit.

Otherwise:

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

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Frieder Schrempf]

On 14.11.22 04:16, Marek Vasut wrote:
> On 11/14/22 02:11, Nicolas Boichat wrote:
>> On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 11/11/22 13:12, Nicolas Boichat wrote:
>>>
>>> [...]
>>>
>>>>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>>>>
>>>>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>>>>> initially observed this issue on the imx8m platform.
>>>>
>>>> I'll repeat, are you sure about HSE specifically? You invert the
>>>> polarity for HBP, HFP, and HSA, which makes sense given your patch
>>>> 02/14.
>>>>
>>>> I'm concerned about HSE. Is the bit really a disable bit?
>>>> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
>>>> should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>>>
>>> I suspect the HSE bit is a misnomer, but its handling in the driver is
>>> correct.
>>>
>>> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
>>> Page 5436
>>>
>>> 23 HseDisableMode
>>>
>>> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
>>> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
>>> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>>>
>>> 0 = Disables transfer
>>> 1 = Enables transfer
>>>
>>> In command mode, this bit is ignored.
>>
>> Okay. I'd suggest adding a comment in the code, it'd be so tempting to
>> attempt to "fix" this as the if/or pattern looks different from the
>> others.
>>
>> But it's up to you all.
> 
> I agree. Clearly the discrepancy is confusing and leads to mistakes.

+1 for a comment in the code that explains the misnamed bit.

Otherwise:

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 01/14] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Frieder Schrempf]

On 14.11.22 04:16, Marek Vasut wrote:
> On 11/14/22 02:11, Nicolas Boichat wrote:
>> On Sun, Nov 13, 2022 at 8:29 AM Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 11/11/22 13:12, Nicolas Boichat wrote:
>>>
>>> [...]
>>>
>>>>>> BTW, are you sure DSIM_HSE_MODE is correct now?
>>>>>
>>>>> Yes, we have tested in imx8m platforms as well. Sébastien Szymanski
>>>>> initially observed this issue on the imx8m platform.
>>>>
>>>> I'll repeat, are you sure about HSE specifically? You invert the
>>>> polarity for HBP, HFP, and HSA, which makes sense given your patch
>>>> 02/14.
>>>>
>>>> I'm concerned about HSE. Is the bit really a disable bit?
>>>> MIPI_DSI_MODE_VIDEO_HSE is supposed to be an enable flag, so you
>>>> should not do `reg |= DSIM_HSE_DISABLE;`, probably.
>>>
>>> I suspect the HSE bit is a misnomer, but its handling in the driver is
>>> correct.
>>>
>>> i.MX 8M Plus Applications Processor Reference Manual, Rev. 1, 06/2021
>>> Page 5436
>>>
>>> 23 HseDisableMode
>>>
>>> In Vsync pulse and Vporch area, MIPI DSI master transfers only Hsync
>>> start packet to MIPI DSI slave at MIPI DSI spec 1.1r02. This bit
>>> transfers Hsync end packet in Vsync pulse and Vporch area (optional).
>>>
>>> 0 = Disables transfer
>>> 1 = Enables transfer
>>>
>>> In command mode, this bit is ignored.
>>
>> Okay. I'd suggest adding a comment in the code, it'd be so tempting to
>> attempt to "fix" this as the if/or pattern looks different from the
>> others.
>>
>> But it's up to you all.
> 
> I agree. Clearly the discrepancy is confusing and leads to mistakes.

+1 for a comment in the code that explains the misnamed bit.

Otherwise:

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

[PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
conversion as 'disable mode bit' due to its bit definition,
0 = Enable and 1 = Disable.

Fix the naming convention of the mode bits.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index b5305b145ddb..fce7f0a7e4ee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -75,10 +75,10 @@
 #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
 #define DSIM_SUB_VC			(((x) & 0x3) << 16)
 #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
-#define DSIM_HSA_MODE			(1 << 20)
-#define DSIM_HBP_MODE			(1 << 21)
-#define DSIM_HFP_MODE			(1 << 22)
-#define DSIM_HSE_MODE			(1 << 23)
+#define DSIM_HSA_DISABLE		(1 << 20)
+#define DSIM_HBP_DISABLE		(1 << 21)
+#define DSIM_HFP_DISABLE		(1 << 22)
+#define DSIM_HSE_DISABLE		(1 << 23)
 #define DSIM_AUTO_MODE			(1 << 24)
 #define DSIM_VIDEO_MODE			(1 << 25)
 #define DSIM_BURST_MODE			(1 << 26)
@@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
 			reg |= DSIM_AUTO_MODE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
-			reg |= DSIM_HSE_MODE;
+			reg |= DSIM_HSE_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
-			reg |= DSIM_HFP_MODE;
+			reg |= DSIM_HFP_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
-			reg |= DSIM_HBP_MODE;
+			reg |= DSIM_HBP_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
-			reg |= DSIM_HSA_MODE;
+			reg |= DSIM_HSA_DISABLE;
 	}
 
 	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
-- 
2.25.1

[PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
conversion as 'disable mode bit' due to its bit definition,
0 = Enable and 1 = Disable.

Fix the naming convention of the mode bits.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index b5305b145ddb..fce7f0a7e4ee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -75,10 +75,10 @@
 #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
 #define DSIM_SUB_VC			(((x) & 0x3) << 16)
 #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
-#define DSIM_HSA_MODE			(1 << 20)
-#define DSIM_HBP_MODE			(1 << 21)
-#define DSIM_HFP_MODE			(1 << 22)
-#define DSIM_HSE_MODE			(1 << 23)
+#define DSIM_HSA_DISABLE		(1 << 20)
+#define DSIM_HBP_DISABLE		(1 << 21)
+#define DSIM_HFP_DISABLE		(1 << 22)
+#define DSIM_HSE_DISABLE		(1 << 23)
 #define DSIM_AUTO_MODE			(1 << 24)
 #define DSIM_VIDEO_MODE			(1 << 25)
 #define DSIM_BURST_MODE			(1 << 26)
@@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
 			reg |= DSIM_AUTO_MODE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
-			reg |= DSIM_HSE_MODE;
+			reg |= DSIM_HSE_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
-			reg |= DSIM_HFP_MODE;
+			reg |= DSIM_HFP_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
-			reg |= DSIM_HBP_MODE;
+			reg |= DSIM_HBP_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
-			reg |= DSIM_HSA_MODE;
+			reg |= DSIM_HSA_DISABLE;
 	}
 
 	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
conversion as 'disable mode bit' due to its bit definition,
0 = Enable and 1 = Disable.

Fix the naming convention of the mode bits.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index b5305b145ddb..fce7f0a7e4ee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -75,10 +75,10 @@
 #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
 #define DSIM_SUB_VC			(((x) & 0x3) << 16)
 #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
-#define DSIM_HSA_MODE			(1 << 20)
-#define DSIM_HBP_MODE			(1 << 21)
-#define DSIM_HFP_MODE			(1 << 22)
-#define DSIM_HSE_MODE			(1 << 23)
+#define DSIM_HSA_DISABLE		(1 << 20)
+#define DSIM_HBP_DISABLE		(1 << 21)
+#define DSIM_HFP_DISABLE		(1 << 22)
+#define DSIM_HSE_DISABLE		(1 << 23)
 #define DSIM_AUTO_MODE			(1 << 24)
 #define DSIM_VIDEO_MODE			(1 << 25)
 #define DSIM_BURST_MODE			(1 << 26)
@@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
 			reg |= DSIM_AUTO_MODE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
-			reg |= DSIM_HSE_MODE;
+			reg |= DSIM_HSE_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
-			reg |= DSIM_HFP_MODE;
+			reg |= DSIM_HFP_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
-			reg |= DSIM_HBP_MODE;
+			reg |= DSIM_HBP_DISABLE;
 		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
-			reg |= DSIM_HSA_MODE;
+			reg |= DSIM_HSA_DISABLE;
 	}
 
 	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
-- 
2.25.1

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
> 
> Fix the naming convention of the mode bits.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
>   1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index b5305b145ddb..fce7f0a7e4ee 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -75,10 +75,10 @@
>   #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
>   #define DSIM_SUB_VC			(((x) & 0x3) << 16)
>   #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
> -#define DSIM_HSA_MODE			(1 << 20)
> -#define DSIM_HBP_MODE			(1 << 21)
> -#define DSIM_HFP_MODE			(1 << 22)
> -#define DSIM_HSE_MODE			(1 << 23)
> +#define DSIM_HSA_DISABLE		(1 << 20)
> +#define DSIM_HBP_DISABLE		(1 << 21)
> +#define DSIM_HFP_DISABLE		(1 << 22)
> +#define DSIM_HSE_DISABLE		(1 << 23)

Those four bits are called Hxx_DISABLE_MODE in the MX8M{M,N,P}RM at 
least, so keep both suffixes .

A separate patch which turns those bits to BIT() macro would be nice.

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
> 
> Fix the naming convention of the mode bits.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
>   1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index b5305b145ddb..fce7f0a7e4ee 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -75,10 +75,10 @@
>   #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
>   #define DSIM_SUB_VC			(((x) & 0x3) << 16)
>   #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
> -#define DSIM_HSA_MODE			(1 << 20)
> -#define DSIM_HBP_MODE			(1 << 21)
> -#define DSIM_HFP_MODE			(1 << 22)
> -#define DSIM_HSE_MODE			(1 << 23)
> +#define DSIM_HSA_DISABLE		(1 << 20)
> +#define DSIM_HBP_DISABLE		(1 << 21)
> +#define DSIM_HFP_DISABLE		(1 << 22)
> +#define DSIM_HSE_DISABLE		(1 << 23)

Those four bits are called Hxx_DISABLE_MODE in the MX8M{M,N,P}RM at 
least, so keep both suffixes .

A separate patch which turns those bits to BIT() macro would be nice.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
> 
> Fix the naming convention of the mode bits.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
>   1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index b5305b145ddb..fce7f0a7e4ee 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -75,10 +75,10 @@
>   #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
>   #define DSIM_SUB_VC			(((x) & 0x3) << 16)
>   #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
> -#define DSIM_HSA_MODE			(1 << 20)
> -#define DSIM_HBP_MODE			(1 << 21)
> -#define DSIM_HFP_MODE			(1 << 22)
> -#define DSIM_HSE_MODE			(1 << 23)
> +#define DSIM_HSA_DISABLE		(1 << 20)
> +#define DSIM_HBP_DISABLE		(1 << 21)
> +#define DSIM_HFP_DISABLE		(1 << 22)
> +#define DSIM_HSE_DISABLE		(1 << 23)

Those four bits are called Hxx_DISABLE_MODE in the MX8M{M,N,P}RM at 
least, so keep both suffixes .

A separate patch which turns those bits to BIT() macro would be nice.

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

On Sun, Nov 13, 2022 at 5:55 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
> > HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> > conversion as 'disable mode bit' due to its bit definition,
> > 0 = Enable and 1 = Disable.
> >
> > Fix the naming convention of the mode bits.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
> >   1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index b5305b145ddb..fce7f0a7e4ee 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -75,10 +75,10 @@
> >   #define DSIM_MAIN_PIX_FORMAT_RGB565 (0x4 << 12)
> >   #define DSIM_SUB_VC                 (((x) & 0x3) << 16)
> >   #define DSIM_MAIN_VC                        (((x) & 0x3) << 18)
> > -#define DSIM_HSA_MODE                        (1 << 20)
> > -#define DSIM_HBP_MODE                        (1 << 21)
> > -#define DSIM_HFP_MODE                        (1 << 22)
> > -#define DSIM_HSE_MODE                        (1 << 23)
> > +#define DSIM_HSA_DISABLE             (1 << 20)
> > +#define DSIM_HBP_DISABLE             (1 << 21)
> > +#define DSIM_HFP_DISABLE             (1 << 22)
> > +#define DSIM_HSE_DISABLE             (1 << 23)
>
> Those four bits are called Hxx_DISABLE_MODE in the MX8M{M,N,P}RM at
> least, so keep both suffixes .

Okay, I will update the suffixes.

>
> A separate patch which turns those bits to BIT() macro would be nice.

I plan to do this conversion for all bits once this basic patchset
merges. I hope it is okay with it.

Jagan.

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

On Sun, Nov 13, 2022 at 5:55 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
> > HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> > conversion as 'disable mode bit' due to its bit definition,
> > 0 = Enable and 1 = Disable.
> >
> > Fix the naming convention of the mode bits.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
> >   1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index b5305b145ddb..fce7f0a7e4ee 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -75,10 +75,10 @@
> >   #define DSIM_MAIN_PIX_FORMAT_RGB565 (0x4 << 12)
> >   #define DSIM_SUB_VC                 (((x) & 0x3) << 16)
> >   #define DSIM_MAIN_VC                        (((x) & 0x3) << 18)
> > -#define DSIM_HSA_MODE                        (1 << 20)
> > -#define DSIM_HBP_MODE                        (1 << 21)
> > -#define DSIM_HFP_MODE                        (1 << 22)
> > -#define DSIM_HSE_MODE                        (1 << 23)
> > +#define DSIM_HSA_DISABLE             (1 << 20)
> > +#define DSIM_HBP_DISABLE             (1 << 21)
> > +#define DSIM_HFP_DISABLE             (1 << 22)
> > +#define DSIM_HSE_DISABLE             (1 << 23)
>
> Those four bits are called Hxx_DISABLE_MODE in the MX8M{M,N,P}RM at
> least, so keep both suffixes .

Okay, I will update the suffixes.

>
> A separate patch which turns those bits to BIT() macro would be nice.

I plan to do this conversion for all bits once this basic patchset
merges. I hope it is okay with it.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

On Sun, Nov 13, 2022 at 5:55 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
> > HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> > conversion as 'disable mode bit' due to its bit definition,
> > 0 = Enable and 1 = Disable.
> >
> > Fix the naming convention of the mode bits.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
> >   1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index b5305b145ddb..fce7f0a7e4ee 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -75,10 +75,10 @@
> >   #define DSIM_MAIN_PIX_FORMAT_RGB565 (0x4 << 12)
> >   #define DSIM_SUB_VC                 (((x) & 0x3) << 16)
> >   #define DSIM_MAIN_VC                        (((x) & 0x3) << 18)
> > -#define DSIM_HSA_MODE                        (1 << 20)
> > -#define DSIM_HBP_MODE                        (1 << 21)
> > -#define DSIM_HFP_MODE                        (1 << 22)
> > -#define DSIM_HSE_MODE                        (1 << 23)
> > +#define DSIM_HSA_DISABLE             (1 << 20)
> > +#define DSIM_HBP_DISABLE             (1 << 21)
> > +#define DSIM_HFP_DISABLE             (1 << 22)
> > +#define DSIM_HSE_DISABLE             (1 << 23)
>
> Those four bits are called Hxx_DISABLE_MODE in the MX8M{M,N,P}RM at
> least, so keep both suffixes .

Okay, I will update the suffixes.

>
> A separate patch which turns those bits to BIT() macro would be nice.

I plan to do this conversion for all bits once this basic patchset
merges. I hope it is okay with it.

Jagan.

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Frieder Schrempf]

On 10.11.22 19:38, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
> 
> Fix the naming convention of the mode bits.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index b5305b145ddb..fce7f0a7e4ee 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -75,10 +75,10 @@
>  #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
>  #define DSIM_SUB_VC			(((x) & 0x3) << 16)
>  #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
> -#define DSIM_HSA_MODE			(1 << 20)
> -#define DSIM_HBP_MODE			(1 << 21)
> -#define DSIM_HFP_MODE			(1 << 22)
> -#define DSIM_HSE_MODE			(1 << 23)
> +#define DSIM_HSA_DISABLE		(1 << 20)
> +#define DSIM_HBP_DISABLE		(1 << 21)
> +#define DSIM_HFP_DISABLE		(1 << 22)
> +#define DSIM_HSE_DISABLE		(1 << 23)
>  #define DSIM_AUTO_MODE			(1 << 24)
>  #define DSIM_VIDEO_MODE			(1 << 25)
>  #define DSIM_BURST_MODE			(1 << 26)
> @@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
>  			reg |= DSIM_AUTO_MODE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> -			reg |= DSIM_HSE_MODE;
> +			reg |= DSIM_HSE_DISABLE;

Please add a comment to explain that the DSIM_HSE_DISABLE bit as named
in the datasheet actually has inverted logic (set = HSE enabled).

>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
> -			reg |= DSIM_HFP_MODE;
> +			reg |= DSIM_HFP_DISABLE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
> -			reg |= DSIM_HBP_MODE;
> +			reg |= DSIM_HBP_DISABLE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
> -			reg |= DSIM_HSA_MODE;
> +			reg |= DSIM_HSA_DISABLE;
>  	}
>  
>  	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Frieder Schrempf]

On 10.11.22 19:38, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
> 
> Fix the naming convention of the mode bits.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index b5305b145ddb..fce7f0a7e4ee 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -75,10 +75,10 @@
>  #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
>  #define DSIM_SUB_VC			(((x) & 0x3) << 16)
>  #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
> -#define DSIM_HSA_MODE			(1 << 20)
> -#define DSIM_HBP_MODE			(1 << 21)
> -#define DSIM_HFP_MODE			(1 << 22)
> -#define DSIM_HSE_MODE			(1 << 23)
> +#define DSIM_HSA_DISABLE		(1 << 20)
> +#define DSIM_HBP_DISABLE		(1 << 21)
> +#define DSIM_HFP_DISABLE		(1 << 22)
> +#define DSIM_HSE_DISABLE		(1 << 23)
>  #define DSIM_AUTO_MODE			(1 << 24)
>  #define DSIM_VIDEO_MODE			(1 << 25)
>  #define DSIM_BURST_MODE			(1 << 26)
> @@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
>  			reg |= DSIM_AUTO_MODE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> -			reg |= DSIM_HSE_MODE;
> +			reg |= DSIM_HSE_DISABLE;

Please add a comment to explain that the DSIM_HSE_DISABLE bit as named
in the datasheet actually has inverted logic (set = HSE enabled).

>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
> -			reg |= DSIM_HFP_MODE;
> +			reg |= DSIM_HFP_DISABLE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
> -			reg |= DSIM_HBP_MODE;
> +			reg |= DSIM_HBP_DISABLE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
> -			reg |= DSIM_HSA_MODE;
> +			reg |= DSIM_HSA_DISABLE;
>  	}
>  
>  	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Frieder Schrempf]

On 10.11.22 19:38, Jagan Teki wrote:
> HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> conversion as 'disable mode bit' due to its bit definition,
> 0 = Enable and 1 = Disable.
> 
> Fix the naming convention of the mode bits.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index b5305b145ddb..fce7f0a7e4ee 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -75,10 +75,10 @@
>  #define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
>  #define DSIM_SUB_VC			(((x) & 0x3) << 16)
>  #define DSIM_MAIN_VC			(((x) & 0x3) << 18)
> -#define DSIM_HSA_MODE			(1 << 20)
> -#define DSIM_HBP_MODE			(1 << 21)
> -#define DSIM_HFP_MODE			(1 << 22)
> -#define DSIM_HSE_MODE			(1 << 23)
> +#define DSIM_HSA_DISABLE		(1 << 20)
> +#define DSIM_HBP_DISABLE		(1 << 21)
> +#define DSIM_HFP_DISABLE		(1 << 22)
> +#define DSIM_HSE_DISABLE		(1 << 23)
>  #define DSIM_AUTO_MODE			(1 << 24)
>  #define DSIM_VIDEO_MODE			(1 << 25)
>  #define DSIM_BURST_MODE			(1 << 26)
> @@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
>  			reg |= DSIM_AUTO_MODE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> -			reg |= DSIM_HSE_MODE;
> +			reg |= DSIM_HSE_DISABLE;

Please add a comment to explain that the DSIM_HSE_DISABLE bit as named
in the datasheet actually has inverted logic (set = HSE enabled).

>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
> -			reg |= DSIM_HFP_MODE;
> +			reg |= DSIM_HFP_DISABLE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
> -			reg |= DSIM_HBP_MODE;
> +			reg |= DSIM_HBP_DISABLE;
>  		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
> -			reg |= DSIM_HSA_MODE;
> +			reg |= DSIM_HSA_DISABLE;
>  	}
>  
>  	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

On Mon, Dec 5, 2022 at 5:29 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 10.11.22 19:38, Jagan Teki wrote:
> > HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> > conversion as 'disable mode bit' due to its bit definition,
> > 0 = Enable and 1 = Disable.
> >
> > Fix the naming convention of the mode bits.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index b5305b145ddb..fce7f0a7e4ee 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -75,10 +75,10 @@
> >  #define DSIM_MAIN_PIX_FORMAT_RGB565  (0x4 << 12)
> >  #define DSIM_SUB_VC                  (((x) & 0x3) << 16)
> >  #define DSIM_MAIN_VC                 (((x) & 0x3) << 18)
> > -#define DSIM_HSA_MODE                        (1 << 20)
> > -#define DSIM_HBP_MODE                        (1 << 21)
> > -#define DSIM_HFP_MODE                        (1 << 22)
> > -#define DSIM_HSE_MODE                        (1 << 23)
> > +#define DSIM_HSA_DISABLE             (1 << 20)
> > +#define DSIM_HBP_DISABLE             (1 << 21)
> > +#define DSIM_HFP_DISABLE             (1 << 22)
> > +#define DSIM_HSE_DISABLE             (1 << 23)
> >  #define DSIM_AUTO_MODE                       (1 << 24)
> >  #define DSIM_VIDEO_MODE                      (1 << 25)
> >  #define DSIM_BURST_MODE                      (1 << 26)
> > @@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
> >               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
> >                       reg |= DSIM_AUTO_MODE;
> >               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> > -                     reg |= DSIM_HSE_MODE;
> > +                     reg |= DSIM_HSE_DISABLE;
>
> Please add a comment to explain that the DSIM_HSE_DISABLE bit as named
> in the datasheet actually has inverted logic (set = HSE enabled).

Yes, I have the V9 series with all relevant fixes and updates -
waiting for the responses on the host init patch 06/14

Jagan.

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

On Mon, Dec 5, 2022 at 5:29 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 10.11.22 19:38, Jagan Teki wrote:
> > HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> > conversion as 'disable mode bit' due to its bit definition,
> > 0 = Enable and 1 = Disable.
> >
> > Fix the naming convention of the mode bits.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index b5305b145ddb..fce7f0a7e4ee 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -75,10 +75,10 @@
> >  #define DSIM_MAIN_PIX_FORMAT_RGB565  (0x4 << 12)
> >  #define DSIM_SUB_VC                  (((x) & 0x3) << 16)
> >  #define DSIM_MAIN_VC                 (((x) & 0x3) << 18)
> > -#define DSIM_HSA_MODE                        (1 << 20)
> > -#define DSIM_HBP_MODE                        (1 << 21)
> > -#define DSIM_HFP_MODE                        (1 << 22)
> > -#define DSIM_HSE_MODE                        (1 << 23)
> > +#define DSIM_HSA_DISABLE             (1 << 20)
> > +#define DSIM_HBP_DISABLE             (1 << 21)
> > +#define DSIM_HFP_DISABLE             (1 << 22)
> > +#define DSIM_HSE_DISABLE             (1 << 23)
> >  #define DSIM_AUTO_MODE                       (1 << 24)
> >  #define DSIM_VIDEO_MODE                      (1 << 25)
> >  #define DSIM_BURST_MODE                      (1 << 26)
> > @@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
> >               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
> >                       reg |= DSIM_AUTO_MODE;
> >               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> > -                     reg |= DSIM_HSE_MODE;
> > +                     reg |= DSIM_HSE_DISABLE;
>
> Please add a comment to explain that the DSIM_HSE_DISABLE bit as named
> in the datasheet actually has inverted logic (set = HSE enabled).

Yes, I have the V9 series with all relevant fixes and updates -
waiting for the responses on the host init patch 06/14

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 02/14] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits

[Jagan Teki]

On Mon, Dec 5, 2022 at 5:29 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 10.11.22 19:38, Jagan Teki wrote:
> > HSA/HBP/HFP/HSE mode bits in Exynos DSI host specify a naming
> > conversion as 'disable mode bit' due to its bit definition,
> > 0 = Enable and 1 = Disable.
> >
> > Fix the naming convention of the mode bits.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index b5305b145ddb..fce7f0a7e4ee 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -75,10 +75,10 @@
> >  #define DSIM_MAIN_PIX_FORMAT_RGB565  (0x4 << 12)
> >  #define DSIM_SUB_VC                  (((x) & 0x3) << 16)
> >  #define DSIM_MAIN_VC                 (((x) & 0x3) << 18)
> > -#define DSIM_HSA_MODE                        (1 << 20)
> > -#define DSIM_HBP_MODE                        (1 << 21)
> > -#define DSIM_HFP_MODE                        (1 << 22)
> > -#define DSIM_HSE_MODE                        (1 << 23)
> > +#define DSIM_HSA_DISABLE             (1 << 20)
> > +#define DSIM_HBP_DISABLE             (1 << 21)
> > +#define DSIM_HFP_DISABLE             (1 << 22)
> > +#define DSIM_HSE_DISABLE             (1 << 23)
> >  #define DSIM_AUTO_MODE                       (1 << 24)
> >  #define DSIM_VIDEO_MODE                      (1 << 25)
> >  #define DSIM_BURST_MODE                      (1 << 26)
> > @@ -804,13 +804,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
> >               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
> >                       reg |= DSIM_AUTO_MODE;
> >               if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> > -                     reg |= DSIM_HSE_MODE;
> > +                     reg |= DSIM_HSE_DISABLE;
>
> Please add a comment to explain that the DSIM_HSE_DISABLE bit as named
> in the datasheet actually has inverted logic (set = HSE enabled).

Yes, I have the V9 series with all relevant fixes and updates -
waiting for the responses on the host init patch 06/14

Jagan.

[PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Jagan Teki]

Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.

In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.

This patch is trying to differentiate platform-specific and bridge driver
code by maintaining exynos platform glue code in exynos_drm_dsi.c driver
and common bridge driver code in samsung-dsim.c providing that the new
platform-specific glue should be supported in the bridge driver, unlike
exynos platform drm drivers.

- Add samsung_dsim_plat_data for keeping platform-specific attributes like
  host_ops, irq_ops, and hw_type.

- Initialize the plat_data hooks for exynos platform in exynos_drm_dsi.c.

- samsung_dsim_probe is the common probe call across exynos_drm_dsi.c and
  samsung-dsim.c.

- plat_data hooks like host_ops and irq_ops are invoked during the
  respective bridge call chains.

v8:
* update the commit message head

v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic

v6:
* handle previous bridge pointer for exynos dsi

v5:
* [mszyprow] reworked driver initialization using the same approach as in
  drivers/gpu/drm/{exynos/exynos_dp.c, bridge/analogix/analogix_dp_core.c},
  removed weak functions, moved exynos_dsi_driver back to exynos_drm_dsi.c
  and restored integration with exynos_drm custom initialization.
* updated the commit message [Jagan]

v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build

v3:
* restore gpio related fixes
* restore proper bridge chain
* rework initialization issue
* fix header includes in proper way

v2:
* fixed exynos dsi driver conversion (Marek Szyprowski)
* updated commit message
* updated MAINTAINERS file

v1:
* don't maintain component_ops in bridge driver
* don't maintain platform glue code in bridge driver
* add platform-specific glue code and make a common bridge

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 MAINTAINERS                             |    9 +
 drivers/gpu/drm/bridge/Kconfig          |   12 +
 drivers/gpu/drm/bridge/Makefile         |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c   | 1703 ++++++++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig          |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1766 ++---------------------
 include/drm/bridge/samsung-dsim.h       |  113 ++
 7 files changed, 1952 insertions(+), 1653 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ae989b32ebb..ba7a6721443c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6624,6 +6624,15 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc
 F:	Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
 F:	drivers/gpu/drm/panel/panel-samsung-db7430.c
 
+DRM DRIVER FOR SAMSUNG MIPI DSIM BRIDGE
+M:	Jagan Teki <jagan@amarulasolutions.com>
+M:	Marek Szyprowski <m.szyprowski@samsung.com>
+M:	Inki Dae <inki.dae@samsung.com
+S:	Maintained
+T:	git git://anongit.freedesktop.org/drm/drm-misc
+F:	drivers/gpu/drm/bridge/samsung-dsim.c
+F:	include/drm/bridge/samsung-dsim.h
+
 DRM DRIVER FOR SAMSUNG S6D27A1 PANELS
 M:	Markuss Broks <markuss.broks@gmail.com>
 S:	Maintained
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 57946d80b02d..8e85dac9f53e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -231,6 +231,18 @@ config DRM_PARADE_PS8640
 	  The PS8640 is a high-performance and low-power
 	  MIPI DSI to eDP converter
 
+config DRM_SAMSUNG_DSIM
+	tristate "Samsung MIPI DSIM bridge driver"
+	depends on COMMON_CLK
+	depends on OF && HAS_IOMEM
+	select DRM_KMS_HELPER
+	select DRM_MIPI_DSI
+	select DRM_PANEL_BRIDGE
+	help
+	  The Samsung MIPI DSIM bridge controller driver.
+	  This MIPI DSIM bridge can be found it on Exynos SoCs and
+	  NXP's i.MX8M Mini/Nano.
+
 config DRM_SIL_SII8620
 	tristate "Silicon Image SII8620 HDMI/MHL bridge"
 	depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 1884803c6860..dae843723991 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
+obj-$(CONFIG_DRM_SAMSUNG_DSIM) += samsung-dsim.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
new file mode 100644
index 000000000000..b63e0479e71d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -0,0 +1,1703 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Samsung MIPI DSIM bridge driver.
+ *
+ * Copyright (C) 2021 Amarula Solutions(India)
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ *
+ * Based on exynos_drm_dsi from
+ * Tomasz Figa <t.figa@samsung.com>
+ */
+
+#include <asm/unaligned.h>
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/of_device.h>
+#include <linux/phy/phy.h>
+
+#include <video/mipi_display.h>
+
+#include <drm/bridge/samsung-dsim.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+
+/* returns true iff both arguments logically differs */
+#define NEQV(a, b) (!(a) ^ !(b))
+
+/* DSIM_STATUS */
+#define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
+#define DSIM_STOP_STATE_CLK		(1 << 8)
+#define DSIM_TX_READY_HS_CLK		(1 << 10)
+#define DSIM_PLL_STABLE			(1 << 31)
+
+/* DSIM_SWRST */
+#define DSIM_FUNCRST			(1 << 16)
+#define DSIM_SWRST			(1 << 0)
+
+/* DSIM_TIMEOUT */
+#define DSIM_LPDR_TIMEOUT(x)		((x) << 0)
+#define DSIM_BTA_TIMEOUT(x)		((x) << 16)
+
+/* DSIM_CLKCTRL */
+#define DSIM_ESC_PRESCALER(x)		(((x) & 0xffff) << 0)
+#define DSIM_ESC_PRESCALER_MASK		(0xffff << 0)
+#define DSIM_LANE_ESC_CLK_EN_CLK	(1 << 19)
+#define DSIM_LANE_ESC_CLK_EN_DATA(x)	(((x) & 0xf) << 20)
+#define DSIM_LANE_ESC_CLK_EN_DATA_MASK	(0xf << 20)
+#define DSIM_BYTE_CLKEN			(1 << 24)
+#define DSIM_BYTE_CLK_SRC(x)		(((x) & 0x3) << 25)
+#define DSIM_BYTE_CLK_SRC_MASK		(0x3 << 25)
+#define DSIM_PLL_BYPASS			(1 << 27)
+#define DSIM_ESC_CLKEN			(1 << 28)
+#define DSIM_TX_REQUEST_HSCLK		(1 << 31)
+
+/* DSIM_CONFIG */
+#define DSIM_LANE_EN_CLK		(1 << 0)
+#define DSIM_LANE_EN(x)			(((x) & 0xf) << 1)
+#define DSIM_NUM_OF_DATA_LANE(x)	(((x) & 0x3) << 5)
+#define DSIM_SUB_PIX_FORMAT(x)		(((x) & 0x7) << 8)
+#define DSIM_MAIN_PIX_FORMAT_MASK	(0x7 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB888	(0x7 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB666	(0x6 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB666_P	(0x5 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
+#define DSIM_SUB_VC			(((x) & 0x3) << 16)
+#define DSIM_MAIN_VC			(((x) & 0x3) << 18)
+#define DSIM_HSA_DISABLE		(1 << 20)
+#define DSIM_HBP_DISABLE		(1 << 21)
+#define DSIM_HFP_DISABLE		(1 << 22)
+#define DSIM_HSE_DISABLE		(1 << 23)
+#define DSIM_AUTO_MODE			(1 << 24)
+#define DSIM_VIDEO_MODE			(1 << 25)
+#define DSIM_BURST_MODE			(1 << 26)
+#define DSIM_SYNC_INFORM		(1 << 27)
+#define DSIM_EOT_DISABLE		(1 << 28)
+#define DSIM_MFLUSH_VS			(1 << 29)
+/* This flag is valid only for exynos3250/3472/5260/5430 */
+#define DSIM_CLKLANE_STOP		(1 << 30)
+
+/* DSIM_ESCMODE */
+#define DSIM_TX_TRIGGER_RST		(1 << 4)
+#define DSIM_TX_LPDT_LP			(1 << 6)
+#define DSIM_CMD_LPDT_LP		(1 << 7)
+#define DSIM_FORCE_BTA			(1 << 16)
+#define DSIM_FORCE_STOP_STATE		(1 << 20)
+#define DSIM_STOP_STATE_CNT(x)		(((x) & 0x7ff) << 21)
+#define DSIM_STOP_STATE_CNT_MASK	(0x7ff << 21)
+
+/* DSIM_MDRESOL */
+#define DSIM_MAIN_STAND_BY		(1 << 31)
+#define DSIM_MAIN_VRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 16)
+#define DSIM_MAIN_HRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 0)
+
+/* DSIM_MVPORCH */
+#define DSIM_CMD_ALLOW(x)		((x) << 28)
+#define DSIM_STABLE_VFP(x)		((x) << 16)
+#define DSIM_MAIN_VBP(x)		((x) << 0)
+#define DSIM_CMD_ALLOW_MASK		(0xf << 28)
+#define DSIM_STABLE_VFP_MASK		(0x7ff << 16)
+#define DSIM_MAIN_VBP_MASK		(0x7ff << 0)
+
+/* DSIM_MHPORCH */
+#define DSIM_MAIN_HFP(x)		((x) << 16)
+#define DSIM_MAIN_HBP(x)		((x) << 0)
+#define DSIM_MAIN_HFP_MASK		((0xffff) << 16)
+#define DSIM_MAIN_HBP_MASK		((0xffff) << 0)
+
+/* DSIM_MSYNC */
+#define DSIM_MAIN_VSA(x)		((x) << 22)
+#define DSIM_MAIN_HSA(x)		((x) << 0)
+#define DSIM_MAIN_VSA_MASK		((0x3ff) << 22)
+#define DSIM_MAIN_HSA_MASK		((0xffff) << 0)
+
+/* DSIM_SDRESOL */
+#define DSIM_SUB_STANDY(x)		((x) << 31)
+#define DSIM_SUB_VRESOL(x)		((x) << 16)
+#define DSIM_SUB_HRESOL(x)		((x) << 0)
+#define DSIM_SUB_STANDY_MASK		((0x1) << 31)
+#define DSIM_SUB_VRESOL_MASK		((0x7ff) << 16)
+#define DSIM_SUB_HRESOL_MASK		((0x7ff) << 0)
+
+/* DSIM_INTSRC */
+#define DSIM_INT_PLL_STABLE		(1 << 31)
+#define DSIM_INT_SW_RST_RELEASE		(1 << 30)
+#define DSIM_INT_SFR_FIFO_EMPTY		(1 << 29)
+#define DSIM_INT_SFR_HDR_FIFO_EMPTY	(1 << 28)
+#define DSIM_INT_BTA			(1 << 25)
+#define DSIM_INT_FRAME_DONE		(1 << 24)
+#define DSIM_INT_RX_TIMEOUT		(1 << 21)
+#define DSIM_INT_BTA_TIMEOUT		(1 << 20)
+#define DSIM_INT_RX_DONE		(1 << 18)
+#define DSIM_INT_RX_TE			(1 << 17)
+#define DSIM_INT_RX_ACK			(1 << 16)
+#define DSIM_INT_RX_ECC_ERR		(1 << 15)
+#define DSIM_INT_RX_CRC_ERR		(1 << 14)
+
+/* DSIM_FIFOCTRL */
+#define DSIM_RX_DATA_FULL		(1 << 25)
+#define DSIM_RX_DATA_EMPTY		(1 << 24)
+#define DSIM_SFR_HEADER_FULL		(1 << 23)
+#define DSIM_SFR_HEADER_EMPTY		(1 << 22)
+#define DSIM_SFR_PAYLOAD_FULL		(1 << 21)
+#define DSIM_SFR_PAYLOAD_EMPTY		(1 << 20)
+#define DSIM_I80_HEADER_FULL		(1 << 19)
+#define DSIM_I80_HEADER_EMPTY		(1 << 18)
+#define DSIM_I80_PAYLOAD_FULL		(1 << 17)
+#define DSIM_I80_PAYLOAD_EMPTY		(1 << 16)
+#define DSIM_SD_HEADER_FULL		(1 << 15)
+#define DSIM_SD_HEADER_EMPTY		(1 << 14)
+#define DSIM_SD_PAYLOAD_FULL		(1 << 13)
+#define DSIM_SD_PAYLOAD_EMPTY		(1 << 12)
+#define DSIM_MD_HEADER_FULL		(1 << 11)
+#define DSIM_MD_HEADER_EMPTY		(1 << 10)
+#define DSIM_MD_PAYLOAD_FULL		(1 << 9)
+#define DSIM_MD_PAYLOAD_EMPTY		(1 << 8)
+#define DSIM_RX_FIFO			(1 << 4)
+#define DSIM_SFR_FIFO			(1 << 3)
+#define DSIM_I80_FIFO			(1 << 2)
+#define DSIM_SD_FIFO			(1 << 1)
+#define DSIM_MD_FIFO			(1 << 0)
+
+/* DSIM_PHYACCHR */
+#define DSIM_AFC_EN			(1 << 14)
+#define DSIM_AFC_CTL(x)			(((x) & 0x7) << 5)
+
+/* DSIM_PLLCTRL */
+#define DSIM_FREQ_BAND(x)		((x) << 24)
+#define DSIM_PLL_EN			(1 << 23)
+#define DSIM_PLL_P(x)			((x) << 13)
+#define DSIM_PLL_M(x)			((x) << 4)
+#define DSIM_PLL_S(x)			((x) << 1)
+
+/* DSIM_PHYCTRL */
+#define DSIM_PHYCTRL_ULPS_EXIT(x)	(((x) & 0x1ff) << 0)
+#define DSIM_PHYCTRL_B_DPHYCTL_VREG_LP	(1 << 30)
+#define DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP	(1 << 14)
+
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x)		((x) << 8)
+#define DSIM_PHYTIMING_HS_EXIT(x)	((x) << 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x)	((x) << 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)	((x) << 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)	((x) << 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x)	((x) << 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x)	((x) << 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x)	((x) << 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)	((x) << 0)
+
+#define DSI_MAX_BUS_WIDTH		4
+#define DSI_NUM_VIRTUAL_CHANNELS	4
+#define DSI_TX_FIFO_SIZE		2048
+#define DSI_RX_FIFO_SIZE		256
+#define DSI_XFER_TIMEOUT_MS		100
+#define DSI_RX_FIFO_EMPTY		0x30800002
+
+#define OLD_SCLK_MIPI_CLK_NAME		"pll_clk"
+
+static const char *const clk_names[5] = {
+	"bus_clk",
+	"sclk_mipi",
+	"phyclk_mipidphy0_bitclkdiv8",
+	"phyclk_mipidphy0_rxclkesc0",
+	"sclk_rgb_vclk_to_dsim0"
+};
+
+enum samsung_dsim_transfer_type {
+	EXYNOS_DSI_TX,
+	EXYNOS_DSI_RX,
+};
+
+enum reg_idx {
+	DSIM_STATUS_REG,	/* Status register */
+	DSIM_SWRST_REG,		/* Software reset register */
+	DSIM_CLKCTRL_REG,	/* Clock control register */
+	DSIM_TIMEOUT_REG,	/* Time out register */
+	DSIM_CONFIG_REG,	/* Configuration register */
+	DSIM_ESCMODE_REG,	/* Escape mode register */
+	DSIM_MDRESOL_REG,
+	DSIM_MVPORCH_REG,	/* Main display Vporch register */
+	DSIM_MHPORCH_REG,	/* Main display Hporch register */
+	DSIM_MSYNC_REG,		/* Main display sync area register */
+	DSIM_INTSRC_REG,	/* Interrupt source register */
+	DSIM_INTMSK_REG,	/* Interrupt mask register */
+	DSIM_PKTHDR_REG,	/* Packet Header FIFO register */
+	DSIM_PAYLOAD_REG,	/* Payload FIFO register */
+	DSIM_RXFIFO_REG,	/* Read FIFO register */
+	DSIM_FIFOCTRL_REG,	/* FIFO status and control register */
+	DSIM_PLLCTRL_REG,	/* PLL control register */
+	DSIM_PHYCTRL_REG,
+	DSIM_PHYTIMING_REG,
+	DSIM_PHYTIMING1_REG,
+	DSIM_PHYTIMING2_REG,
+	NUM_REGS
+};
+
+static const unsigned int exynos_reg_ofs[] = {
+	[DSIM_STATUS_REG] =  0x00,
+	[DSIM_SWRST_REG] =  0x04,
+	[DSIM_CLKCTRL_REG] =  0x08,
+	[DSIM_TIMEOUT_REG] =  0x0c,
+	[DSIM_CONFIG_REG] =  0x10,
+	[DSIM_ESCMODE_REG] =  0x14,
+	[DSIM_MDRESOL_REG] =  0x18,
+	[DSIM_MVPORCH_REG] =  0x1c,
+	[DSIM_MHPORCH_REG] =  0x20,
+	[DSIM_MSYNC_REG] =  0x24,
+	[DSIM_INTSRC_REG] =  0x2c,
+	[DSIM_INTMSK_REG] =  0x30,
+	[DSIM_PKTHDR_REG] =  0x34,
+	[DSIM_PAYLOAD_REG] =  0x38,
+	[DSIM_RXFIFO_REG] =  0x3c,
+	[DSIM_FIFOCTRL_REG] =  0x44,
+	[DSIM_PLLCTRL_REG] =  0x4c,
+	[DSIM_PHYCTRL_REG] =  0x5c,
+	[DSIM_PHYTIMING_REG] =  0x64,
+	[DSIM_PHYTIMING1_REG] =  0x68,
+	[DSIM_PHYTIMING2_REG] =  0x6c,
+};
+
+static const unsigned int exynos5433_reg_ofs[] = {
+	[DSIM_STATUS_REG] = 0x04,
+	[DSIM_SWRST_REG] = 0x0C,
+	[DSIM_CLKCTRL_REG] = 0x10,
+	[DSIM_TIMEOUT_REG] = 0x14,
+	[DSIM_CONFIG_REG] = 0x18,
+	[DSIM_ESCMODE_REG] = 0x1C,
+	[DSIM_MDRESOL_REG] = 0x20,
+	[DSIM_MVPORCH_REG] = 0x24,
+	[DSIM_MHPORCH_REG] = 0x28,
+	[DSIM_MSYNC_REG] = 0x2C,
+	[DSIM_INTSRC_REG] = 0x34,
+	[DSIM_INTMSK_REG] = 0x38,
+	[DSIM_PKTHDR_REG] = 0x3C,
+	[DSIM_PAYLOAD_REG] = 0x40,
+	[DSIM_RXFIFO_REG] = 0x44,
+	[DSIM_FIFOCTRL_REG] = 0x4C,
+	[DSIM_PLLCTRL_REG] = 0x94,
+	[DSIM_PHYCTRL_REG] = 0xA4,
+	[DSIM_PHYTIMING_REG] = 0xB4,
+	[DSIM_PHYTIMING1_REG] = 0xB8,
+	[DSIM_PHYTIMING2_REG] = 0xBC,
+};
+
+enum reg_value_idx {
+	RESET_TYPE,
+	PLL_TIMER,
+	STOP_STATE_CNT,
+	PHYCTRL_ULPS_EXIT,
+	PHYCTRL_VREG_LP,
+	PHYCTRL_SLEW_UP,
+	PHYTIMING_LPX,
+	PHYTIMING_HS_EXIT,
+	PHYTIMING_CLK_PREPARE,
+	PHYTIMING_CLK_ZERO,
+	PHYTIMING_CLK_POST,
+	PHYTIMING_CLK_TRAIL,
+	PHYTIMING_HS_PREPARE,
+	PHYTIMING_HS_ZERO,
+	PHYTIMING_HS_TRAIL
+};
+
+static const unsigned int reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x0af),
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x27),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x09),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
+static const unsigned int exynos5422_reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0xaf),
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x08),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0d),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x30),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x0a),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0c),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x11),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0d),
+};
+
+static const unsigned int exynos5433_reg_values[] = {
+	[RESET_TYPE] = DSIM_FUNCRST,
+	[PLL_TIMER] = 22200,
+	[STOP_STATE_CNT] = 0xa,
+	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
+	[PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
+	[PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x09),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0b),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x10),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
+};
+
+static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
+	.reg_ofs = exynos_reg_ofs,
+	.plltmr_reg = 0x50,
+	.has_freqband = 1,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 1000,
+	.wait_for_reset = 1,
+	.num_bits_resol = 11,
+	.reg_values = reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
+	.reg_ofs = exynos_reg_ofs,
+	.plltmr_reg = 0x50,
+	.has_freqband = 1,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 1000,
+	.wait_for_reset = 1,
+	.num_bits_resol = 11,
+	.reg_values = reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
+	.reg_ofs = exynos_reg_ofs,
+	.plltmr_reg = 0x58,
+	.num_clks = 2,
+	.max_freq = 1000,
+	.wait_for_reset = 1,
+	.num_bits_resol = 11,
+	.reg_values = reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 5,
+	.max_freq = 1500,
+	.wait_for_reset = 0,
+	.num_bits_resol = 12,
+	.reg_values = exynos5433_reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 1500,
+	.wait_for_reset = 1,
+	.num_bits_resol = 12,
+	.reg_values = exynos5422_reg_values,
+};
+
+static const struct samsung_dsim_driver_data *
+samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
+	[SAMSUNG_DSIM_TYPE_EXYNOS3250] = &exynos3_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_EXYNOS4210] = &exynos4_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_EXYNOS5410] = &exynos5_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
+};
+
+static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
+{
+	return container_of(h, struct samsung_dsim, dsi_host);
+}
+
+static inline struct samsung_dsim *bridge_to_dsi(struct drm_bridge *b)
+{
+	return container_of(b, struct samsung_dsim, bridge);
+}
+
+static inline void samsung_dsim_write(struct samsung_dsim *dsi,
+				      enum reg_idx idx, u32 val)
+{
+	writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
+}
+
+static inline u32 samsung_dsim_read(struct samsung_dsim *dsi, enum reg_idx idx)
+{
+	return readl(dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
+}
+
+static void samsung_dsim_wait_for_reset(struct samsung_dsim *dsi)
+{
+	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
+		return;
+
+	dev_err(dsi->dev, "timeout waiting for reset\n");
+}
+
+static void samsung_dsim_reset(struct samsung_dsim *dsi)
+{
+	u32 reset_val = dsi->driver_data->reg_values[RESET_TYPE];
+
+	reinit_completion(&dsi->completed);
+	samsung_dsim_write(dsi, DSIM_SWRST_REG, reset_val);
+}
+
+#ifndef MHZ
+#define MHZ	(1000*1000)
+#endif
+
+static unsigned long samsung_dsim_pll_find_pms(struct samsung_dsim *dsi,
+					       unsigned long fin,
+					       unsigned long fout,
+					       u8 *p, u16 *m, u8 *s)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	unsigned long best_freq = 0;
+	u32 min_delta = 0xffffffff;
+	u8 p_min, p_max;
+	u8 _p, best_p;
+	u16 _m, best_m;
+	u8 _s, best_s;
+
+	p_min = DIV_ROUND_UP(fin, (12 * MHZ));
+	p_max = fin / (6 * MHZ);
+
+	for (_p = p_min; _p <= p_max; ++_p) {
+		for (_s = 0; _s <= 5; ++_s) {
+			u64 tmp;
+			u32 delta;
+
+			tmp = (u64)fout * (_p << _s);
+			do_div(tmp, fin);
+			_m = tmp;
+			if (_m < 41 || _m > 125)
+				continue;
+
+			tmp = (u64)_m * fin;
+			do_div(tmp, _p);
+			if (tmp < 500 * MHZ ||
+					tmp > driver_data->max_freq * MHZ)
+				continue;
+
+			tmp = (u64)_m * fin;
+			do_div(tmp, _p << _s);
+
+			delta = abs(fout - tmp);
+			if (delta < min_delta) {
+				best_p = _p;
+				best_m = _m;
+				best_s = _s;
+				min_delta = delta;
+				best_freq = tmp;
+			}
+		}
+	}
+
+	if (best_freq) {
+		*p = best_p;
+		*m = best_m;
+		*s = best_s;
+	}
+
+	return best_freq;
+}
+
+static unsigned long samsung_dsim_set_pll(struct samsung_dsim *dsi,
+					  unsigned long freq)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	unsigned long fin, fout;
+	int timeout;
+	u8 p, s;
+	u16 m;
+	u32 reg;
+
+	fin = dsi->pll_clk_rate;
+	fout = samsung_dsim_pll_find_pms(dsi, fin, freq, &p, &m, &s);
+	if (!fout) {
+		dev_err(dsi->dev,
+			"failed to find PLL PMS for requested frequency\n");
+		return 0;
+	}
+	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
+
+	writel(driver_data->reg_values[PLL_TIMER],
+			dsi->reg_base + driver_data->plltmr_reg);
+
+	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+	if (driver_data->has_freqband) {
+		static const unsigned long freq_bands[] = {
+			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
+			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
+			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
+			770 * MHZ, 870 * MHZ, 950 * MHZ,
+		};
+		int band;
+
+		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
+			if (fout < freq_bands[band])
+				break;
+
+		dev_dbg(dsi->dev, "band %d\n", band);
+
+		reg |= DSIM_FREQ_BAND(band);
+	}
+
+	samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
+
+	timeout = 1000;
+	do {
+		if (timeout-- == 0) {
+			dev_err(dsi->dev, "PLL failed to stabilize\n");
+			return 0;
+		}
+		reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
+	} while ((reg & DSIM_PLL_STABLE) == 0);
+
+	return fout;
+}
+
+static int samsung_dsim_enable_clock(struct samsung_dsim *dsi)
+{
+	unsigned long hs_clk, byte_clk, esc_clk;
+	unsigned long esc_div;
+	u32 reg;
+
+	hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
+	if (!hs_clk) {
+		dev_err(dsi->dev, "failed to configure DSI PLL\n");
+		return -EFAULT;
+	}
+
+	byte_clk = hs_clk / 8;
+	esc_div = DIV_ROUND_UP(byte_clk, dsi->esc_clk_rate);
+	esc_clk = byte_clk / esc_div;
+
+	if (esc_clk > 20 * MHZ) {
+		++esc_div;
+		esc_clk = byte_clk / esc_div;
+	}
+
+	dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu, esc_clk = %lu\n",
+		hs_clk, byte_clk, esc_clk);
+
+	reg = samsung_dsim_read(dsi, DSIM_CLKCTRL_REG);
+	reg &= ~(DSIM_ESC_PRESCALER_MASK | DSIM_LANE_ESC_CLK_EN_CLK
+			| DSIM_LANE_ESC_CLK_EN_DATA_MASK | DSIM_PLL_BYPASS
+			| DSIM_BYTE_CLK_SRC_MASK);
+	reg |= DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN
+			| DSIM_ESC_PRESCALER(esc_div)
+			| DSIM_LANE_ESC_CLK_EN_CLK
+			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
+			| DSIM_BYTE_CLK_SRC(0)
+			| DSIM_TX_REQUEST_HSCLK;
+	samsung_dsim_write(dsi, DSIM_CLKCTRL_REG, reg);
+
+	return 0;
+}
+
+static void samsung_dsim_set_phy_ctrl(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	const unsigned int *reg_values = driver_data->reg_values;
+	u32 reg;
+
+	if (driver_data->has_freqband)
+		return;
+
+	/* B D-PHY: D-PHY Master & Slave Analog Block control */
+	reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
+		reg_values[PHYCTRL_SLEW_UP];
+	samsung_dsim_write(dsi, DSIM_PHYCTRL_REG, reg);
+
+	/*
+	 * T LPX: Transmitted length of any Low-Power state period
+	 * T HS-EXIT: Time that the transmitter drives LP-11 following a HS
+	 *	burst
+	 */
+	reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
+	samsung_dsim_write(dsi, DSIM_PHYTIMING_REG, reg);
+
+	/*
+	 * T CLK-PREPARE: Time that the transmitter drives the Clock Lane LP-00
+	 *	Line state immediately before the HS-0 Line state starting the
+	 *	HS transmission
+	 * T CLK-ZERO: Time that the transmitter drives the HS-0 state prior to
+	 *	transmitting the Clock.
+	 * T CLK_POST: Time that the transmitter continues to send HS clock
+	 *	after the last associated Data Lane has transitioned to LP Mode
+	 *	Interval is defined as the period from the end of T HS-TRAIL to
+	 *	the beginning of T CLK-TRAIL
+	 * T CLK-TRAIL: Time that the transmitter drives the HS-0 state after
+	 *	the last payload clock bit of a HS transmission burst
+	 */
+	reg = reg_values[PHYTIMING_CLK_PREPARE] |
+		reg_values[PHYTIMING_CLK_ZERO] |
+		reg_values[PHYTIMING_CLK_POST] |
+		reg_values[PHYTIMING_CLK_TRAIL];
+
+	samsung_dsim_write(dsi, DSIM_PHYTIMING1_REG, reg);
+
+	/*
+	 * T HS-PREPARE: Time that the transmitter drives the Data Lane LP-00
+	 *	Line state immediately before the HS-0 Line state starting the
+	 *	HS transmission
+	 * T HS-ZERO: Time that the transmitter drives the HS-0 state prior to
+	 *	transmitting the Sync sequence.
+	 * T HS-TRAIL: Time that the transmitter drives the flipped differential
+	 *	state after last payload data bit of a HS transmission burst
+	 */
+	reg = reg_values[PHYTIMING_HS_PREPARE] | reg_values[PHYTIMING_HS_ZERO] |
+		reg_values[PHYTIMING_HS_TRAIL];
+	samsung_dsim_write(dsi, DSIM_PHYTIMING2_REG, reg);
+}
+
+static void samsung_dsim_disable_clock(struct samsung_dsim *dsi)
+{
+	u32 reg;
+
+	reg = samsung_dsim_read(dsi, DSIM_CLKCTRL_REG);
+	reg &= ~(DSIM_LANE_ESC_CLK_EN_CLK | DSIM_LANE_ESC_CLK_EN_DATA_MASK
+			| DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN);
+	samsung_dsim_write(dsi, DSIM_CLKCTRL_REG, reg);
+
+	reg = samsung_dsim_read(dsi, DSIM_PLLCTRL_REG);
+	reg &= ~DSIM_PLL_EN;
+	samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
+}
+
+static void samsung_dsim_enable_lane(struct samsung_dsim *dsi, u32 lane)
+{
+	u32 reg = samsung_dsim_read(dsi, DSIM_CONFIG_REG);
+
+	reg |= (DSIM_NUM_OF_DATA_LANE(dsi->lanes - 1) | DSIM_LANE_EN_CLK |
+			DSIM_LANE_EN(lane));
+	samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
+}
+
+static int samsung_dsim_init_link(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	int timeout;
+	u32 reg;
+	u32 lanes_mask;
+
+	/* Initialize FIFO pointers */
+	reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
+	reg &= ~0x1f;
+	samsung_dsim_write(dsi, DSIM_FIFOCTRL_REG, reg);
+
+	usleep_range(9000, 11000);
+
+	reg |= 0x1f;
+	samsung_dsim_write(dsi, DSIM_FIFOCTRL_REG, reg);
+	usleep_range(9000, 11000);
+
+	/* DSI configuration */
+	reg = 0;
+
+	/*
+	 * The first bit of mode_flags specifies display configuration.
+	 * If this bit is set[= MIPI_DSI_MODE_VIDEO], dsi will support video
+	 * mode, otherwise it will support command mode.
+	 */
+	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
+		reg |= DSIM_VIDEO_MODE;
+
+		/*
+		 * The user manual describes that following bits are ignored in
+		 * command mode.
+		 */
+		if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
+			reg |= DSIM_MFLUSH_VS;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+			reg |= DSIM_SYNC_INFORM;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+			reg |= DSIM_BURST_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
+			reg |= DSIM_AUTO_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
+			reg |= DSIM_HSE_DISABLE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
+			reg |= DSIM_HFP_DISABLE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
+			reg |= DSIM_HBP_DISABLE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
+			reg |= DSIM_HSA_DISABLE;
+	}
+
+	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
+		reg |= DSIM_EOT_DISABLE;
+
+	switch (dsi->format) {
+	case MIPI_DSI_FMT_RGB888:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
+		break;
+	case MIPI_DSI_FMT_RGB666:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB666;
+		break;
+	case MIPI_DSI_FMT_RGB666_PACKED:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB666_P;
+		break;
+	case MIPI_DSI_FMT_RGB565:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB565;
+		break;
+	default:
+		dev_err(dsi->dev, "invalid pixel format\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Use non-continuous clock mode if the periparal wants and
+	 * host controller supports
+	 *
+	 * In non-continous clock mode, host controller will turn off
+	 * the HS clock between high-speed transmissions to reduce
+	 * power consumption.
+	 */
+	if (driver_data->has_clklane_stop &&
+			dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+		reg |= DSIM_CLKLANE_STOP;
+	}
+	samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
+
+	lanes_mask = BIT(dsi->lanes) - 1;
+	samsung_dsim_enable_lane(dsi, lanes_mask);
+
+	/* Check clock and data lane state are stop state */
+	timeout = 100;
+	do {
+		if (timeout-- == 0) {
+			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
+			return -EFAULT;
+		}
+
+		reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
+		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
+		    != DSIM_STOP_STATE_DAT(lanes_mask))
+			continue;
+	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
+
+	reg = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
+	reg &= ~DSIM_STOP_STATE_CNT_MASK;
+	reg |= DSIM_STOP_STATE_CNT(driver_data->reg_values[STOP_STATE_CNT]);
+	samsung_dsim_write(dsi, DSIM_ESCMODE_REG, reg);
+
+	reg = DSIM_BTA_TIMEOUT(0xff) | DSIM_LPDR_TIMEOUT(0xffff);
+	samsung_dsim_write(dsi, DSIM_TIMEOUT_REG, reg);
+
+	return 0;
+}
+
+static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
+{
+	struct drm_display_mode *m = &dsi->mode;
+	unsigned int num_bits_resol = dsi->driver_data->num_bits_resol;
+	u32 reg;
+
+	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
+		reg = DSIM_CMD_ALLOW(0xf)
+			| DSIM_STABLE_VFP(m->vsync_start - m->vdisplay)
+			| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
+		samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
+
+		reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
+			| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
+		samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
+
+		reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
+			| DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
+		samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
+	}
+	reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
+		DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
+
+	samsung_dsim_write(dsi, DSIM_MDRESOL_REG, reg);
+
+	dev_dbg(dsi->dev, "LCD size = %dx%d\n", m->hdisplay, m->vdisplay);
+}
+
+static void samsung_dsim_set_display_enable(struct samsung_dsim *dsi, bool enable)
+{
+	u32 reg;
+
+	reg = samsung_dsim_read(dsi, DSIM_MDRESOL_REG);
+	if (enable)
+		reg |= DSIM_MAIN_STAND_BY;
+	else
+		reg &= ~DSIM_MAIN_STAND_BY;
+	samsung_dsim_write(dsi, DSIM_MDRESOL_REG, reg);
+}
+
+static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
+{
+	int timeout = 2000;
+
+	do {
+		u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
+
+		if (!(reg & DSIM_SFR_HEADER_FULL))
+			return 0;
+
+		if (!cond_resched())
+			usleep_range(950, 1050);
+	} while (--timeout);
+
+	return -ETIMEDOUT;
+}
+
+static void samsung_dsim_set_cmd_lpm(struct samsung_dsim *dsi, bool lpm)
+{
+	u32 v = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
+
+	if (lpm)
+		v |= DSIM_CMD_LPDT_LP;
+	else
+		v &= ~DSIM_CMD_LPDT_LP;
+
+	samsung_dsim_write(dsi, DSIM_ESCMODE_REG, v);
+}
+
+static void samsung_dsim_force_bta(struct samsung_dsim *dsi)
+{
+	u32 v = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
+
+	v |= DSIM_FORCE_BTA;
+	samsung_dsim_write(dsi, DSIM_ESCMODE_REG, v);
+}
+
+static void samsung_dsim_send_to_fifo(struct samsung_dsim *dsi,
+				      struct samsung_dsim_transfer *xfer)
+{
+	struct device *dev = dsi->dev;
+	struct mipi_dsi_packet *pkt = &xfer->packet;
+	const u8 *payload = pkt->payload + xfer->tx_done;
+	u16 length = pkt->payload_length - xfer->tx_done;
+	bool first = !xfer->tx_done;
+	u32 reg;
+
+	dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
+		xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
+
+	if (length > DSI_TX_FIFO_SIZE)
+		length = DSI_TX_FIFO_SIZE;
+
+	xfer->tx_done += length;
+
+	/* Send payload */
+	while (length >= 4) {
+		reg = get_unaligned_le32(payload);
+		samsung_dsim_write(dsi, DSIM_PAYLOAD_REG, reg);
+		payload += 4;
+		length -= 4;
+	}
+
+	reg = 0;
+	switch (length) {
+	case 3:
+		reg |= payload[2] << 16;
+		fallthrough;
+	case 2:
+		reg |= payload[1] << 8;
+		fallthrough;
+	case 1:
+		reg |= payload[0];
+		samsung_dsim_write(dsi, DSIM_PAYLOAD_REG, reg);
+		break;
+	}
+
+	/* Send packet header */
+	if (!first)
+		return;
+
+	reg = get_unaligned_le32(pkt->header);
+	if (samsung_dsim_wait_for_hdr_fifo(dsi)) {
+		dev_err(dev, "waiting for header FIFO timed out\n");
+		return;
+	}
+
+	if (NEQV(xfer->flags & MIPI_DSI_MSG_USE_LPM,
+		 dsi->state & DSIM_STATE_CMD_LPM)) {
+		samsung_dsim_set_cmd_lpm(dsi, xfer->flags & MIPI_DSI_MSG_USE_LPM);
+		dsi->state ^= DSIM_STATE_CMD_LPM;
+	}
+
+	samsung_dsim_write(dsi, DSIM_PKTHDR_REG, reg);
+
+	if (xfer->flags & MIPI_DSI_MSG_REQ_ACK)
+		samsung_dsim_force_bta(dsi);
+}
+
+static void samsung_dsim_read_from_fifo(struct samsung_dsim *dsi,
+					struct samsung_dsim_transfer *xfer)
+{
+	u8 *payload = xfer->rx_payload + xfer->rx_done;
+	bool first = !xfer->rx_done;
+	struct device *dev = dsi->dev;
+	u16 length;
+	u32 reg;
+
+	if (first) {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+
+		switch (reg & 0x3f) {
+		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+			if (xfer->rx_len >= 2) {
+				payload[1] = reg >> 16;
+				++xfer->rx_done;
+			}
+			fallthrough;
+		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+			payload[0] = reg >> 8;
+			++xfer->rx_done;
+			xfer->rx_len = xfer->rx_done;
+			xfer->result = 0;
+			goto clear_fifo;
+		case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+			dev_err(dev, "DSI Error Report: 0x%04x\n", (reg >> 8) & 0xffff);
+			xfer->result = 0;
+			goto clear_fifo;
+		}
+
+		length = (reg >> 8) & 0xffff;
+		if (length > xfer->rx_len) {
+			dev_err(dev,
+				"response too long (%u > %u bytes), stripping\n",
+				xfer->rx_len, length);
+			length = xfer->rx_len;
+		} else if (length < xfer->rx_len)
+			xfer->rx_len = length;
+	}
+
+	length = xfer->rx_len - xfer->rx_done;
+	xfer->rx_done += length;
+
+	/* Receive payload */
+	while (length >= 4) {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+		payload[0] = (reg >>  0) & 0xff;
+		payload[1] = (reg >>  8) & 0xff;
+		payload[2] = (reg >> 16) & 0xff;
+		payload[3] = (reg >> 24) & 0xff;
+		payload += 4;
+		length -= 4;
+	}
+
+	if (length) {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+		switch (length) {
+		case 3:
+			payload[2] = (reg >> 16) & 0xff;
+			fallthrough;
+		case 2:
+			payload[1] = (reg >> 8) & 0xff;
+			fallthrough;
+		case 1:
+			payload[0] = reg & 0xff;
+		}
+	}
+
+	if (xfer->rx_done == xfer->rx_len)
+		xfer->result = 0;
+
+clear_fifo:
+	length = DSI_RX_FIFO_SIZE / 4;
+	do {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+		if (reg == DSI_RX_FIFO_EMPTY)
+			break;
+	} while (--length);
+}
+
+static void samsung_dsim_transfer_start(struct samsung_dsim *dsi)
+{
+	unsigned long flags;
+	struct samsung_dsim_transfer *xfer;
+	bool start = false;
+
+again:
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	if (list_empty(&dsi->transfer_list)) {
+		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+		return;
+	}
+
+	xfer = list_first_entry(&dsi->transfer_list,
+				struct samsung_dsim_transfer, list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (xfer->packet.payload_length &&
+	    xfer->tx_done == xfer->packet.payload_length)
+		/* waiting for RX */
+		return;
+
+	samsung_dsim_send_to_fifo(dsi, xfer);
+
+	if (xfer->packet.payload_length || xfer->rx_len)
+		return;
+
+	xfer->result = 0;
+	complete(&xfer->completed);
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	list_del_init(&xfer->list);
+	start = !list_empty(&dsi->transfer_list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (start)
+		goto again;
+}
+
+static bool samsung_dsim_transfer_finish(struct samsung_dsim *dsi)
+{
+	struct samsung_dsim_transfer *xfer;
+	unsigned long flags;
+	bool start = true;
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	if (list_empty(&dsi->transfer_list)) {
+		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+		return false;
+	}
+
+	xfer = list_first_entry(&dsi->transfer_list,
+				struct samsung_dsim_transfer, list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	dev_dbg(dsi->dev,
+		"> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
+		xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
+		xfer->rx_done);
+
+	if (xfer->tx_done != xfer->packet.payload_length)
+		return true;
+
+	if (xfer->rx_done != xfer->rx_len)
+		samsung_dsim_read_from_fifo(dsi, xfer);
+
+	if (xfer->rx_done != xfer->rx_len)
+		return true;
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	list_del_init(&xfer->list);
+	start = !list_empty(&dsi->transfer_list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (!xfer->rx_len)
+		xfer->result = 0;
+	complete(&xfer->completed);
+
+	return start;
+}
+
+static void samsung_dsim_remove_transfer(struct samsung_dsim *dsi,
+					 struct samsung_dsim_transfer *xfer)
+{
+	unsigned long flags;
+	bool start;
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	if (!list_empty(&dsi->transfer_list) &&
+	    xfer == list_first_entry(&dsi->transfer_list,
+				     struct samsung_dsim_transfer, list)) {
+		list_del_init(&xfer->list);
+		start = !list_empty(&dsi->transfer_list);
+		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+		if (start)
+			samsung_dsim_transfer_start(dsi);
+		return;
+	}
+
+	list_del_init(&xfer->list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+}
+
+static int samsung_dsim_transfer(struct samsung_dsim *dsi,
+				 struct samsung_dsim_transfer *xfer)
+{
+	unsigned long flags;
+	bool stopped;
+
+	xfer->tx_done = 0;
+	xfer->rx_done = 0;
+	xfer->result = -ETIMEDOUT;
+	init_completion(&xfer->completed);
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	stopped = list_empty(&dsi->transfer_list);
+	list_add_tail(&xfer->list, &dsi->transfer_list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (stopped)
+		samsung_dsim_transfer_start(dsi);
+
+	wait_for_completion_timeout(&xfer->completed,
+				    msecs_to_jiffies(DSI_XFER_TIMEOUT_MS));
+	if (xfer->result == -ETIMEDOUT) {
+		struct mipi_dsi_packet *pkt = &xfer->packet;
+
+		samsung_dsim_remove_transfer(dsi, xfer);
+		dev_err(dsi->dev, "xfer timed out: %*ph %*ph\n", 4, pkt->header,
+			(int)pkt->payload_length, pkt->payload);
+		return -ETIMEDOUT;
+	}
+
+	/* Also covers hardware timeout condition */
+	return xfer->result;
+}
+
+static irqreturn_t samsung_dsim_irq(int irq, void *dev_id)
+{
+	struct samsung_dsim *dsi = dev_id;
+	u32 status;
+
+	status = samsung_dsim_read(dsi, DSIM_INTSRC_REG);
+	if (!status) {
+		static unsigned long j;
+
+		if (printk_timed_ratelimit(&j, 500))
+			dev_warn(dsi->dev, "spurious interrupt\n");
+		return IRQ_HANDLED;
+	}
+	samsung_dsim_write(dsi, DSIM_INTSRC_REG, status);
+
+	if (status & DSIM_INT_SW_RST_RELEASE) {
+		u32 mask = ~(DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
+			DSIM_INT_SFR_HDR_FIFO_EMPTY | DSIM_INT_RX_ECC_ERR |
+			DSIM_INT_SW_RST_RELEASE);
+		samsung_dsim_write(dsi, DSIM_INTMSK_REG, mask);
+		complete(&dsi->completed);
+		return IRQ_HANDLED;
+	}
+
+	if (!(status & (DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
+			DSIM_INT_PLL_STABLE)))
+		return IRQ_HANDLED;
+
+	if (samsung_dsim_transfer_finish(dsi))
+		samsung_dsim_transfer_start(dsi);
+
+	return IRQ_HANDLED;
+}
+
+static void samsung_dsim_enable_irq(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+
+	enable_irq(dsi->irq);
+
+	if (pdata->irq_ops && pdata->irq_ops->enable)
+		pdata->irq_ops->enable(dsi);
+}
+
+static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+
+	if (pdata->irq_ops && pdata->irq_ops->disable)
+		pdata->irq_ops->disable(dsi);
+
+	disable_irq(dsi->irq);
+}
+
+static int samsung_dsim_init(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+
+	samsung_dsim_reset(dsi);
+	samsung_dsim_enable_irq(dsi);
+
+	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
+		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
+
+	samsung_dsim_enable_clock(dsi);
+	if (driver_data->wait_for_reset)
+		samsung_dsim_wait_for_reset(dsi);
+	samsung_dsim_set_phy_ctrl(dsi);
+	samsung_dsim_init_link(dsi);
+
+	return 0;
+}
+
+static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
+					   struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+	int ret;
+
+	if (dsi->state & DSIM_STATE_ENABLED)
+		return;
+
+	ret = pm_runtime_resume_and_get(dsi->dev);
+	if (ret < 0) {
+		dev_err(dsi->dev, "failed to enable DSI device.\n");
+		return;
+	}
+
+	dsi->state |= DSIM_STATE_ENABLED;
+}
+
+static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
+				       struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	samsung_dsim_set_display_mode(dsi);
+	samsung_dsim_set_display_enable(dsi, true);
+
+	dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
+}
+
+static void samsung_dsim_atomic_disable(struct drm_bridge *bridge,
+					struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	if (!(dsi->state & DSIM_STATE_ENABLED))
+		return;
+
+	dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
+}
+
+static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
+					     struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	samsung_dsim_set_display_enable(dsi, false);
+
+	dsi->state &= ~DSIM_STATE_ENABLED;
+	pm_runtime_put_sync(dsi->dev);
+}
+
+static void samsung_dsim_mode_set(struct drm_bridge *bridge,
+				  const struct drm_display_mode *mode,
+				  const struct drm_display_mode *adjusted_mode)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	drm_mode_copy(&dsi->mode, adjusted_mode);
+}
+
+static int samsung_dsim_attach(struct drm_bridge *bridge,
+			       enum drm_bridge_attach_flags flags)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+	struct drm_bridge *previous = bridge;
+
+	/**
+	 * FIXME:
+	 * This has to remove once the bridge chain order is compatible
+	 * with Exynos DSI drivers.
+	 *
+	 * DRM bridge chain ordering is not compatible with Exynos DSI
+	 * drivers because DSI sink devices typically want the DSI host
+	 * powered up and configured before they are powered up.
+	 *
+	 * Passing NULL to the previous bridge makes Exynos DSI drivers
+	 * work which is exactly done before.
+	 */
+	if (!(dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM))
+		previous = NULL;
+
+	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, previous,
+				 flags);
+}
+
+static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
+	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
+	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
+	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
+	.atomic_enable			= samsung_dsim_atomic_enable,
+	.atomic_disable			= samsung_dsim_atomic_disable,
+	.atomic_post_disable		= samsung_dsim_atomic_post_disable,
+	.mode_set			= samsung_dsim_mode_set,
+	.attach				= samsung_dsim_attach,
+};
+
+static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
+				    struct mipi_dsi_device *device)
+{
+	struct samsung_dsim *dsi = host_to_dsi(host);
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+	struct device *dev = dsi->dev;
+	struct drm_panel *panel;
+	int ret;
+
+	panel = of_drm_find_panel(device->dev.of_node);
+	if (!IS_ERR(panel)) {
+		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
+	} else {
+		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
+		if (!dsi->out_bridge)
+			dsi->out_bridge = ERR_PTR(-EINVAL);
+	}
+
+	if (IS_ERR(dsi->out_bridge)) {
+		ret = PTR_ERR(dsi->out_bridge);
+		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
+		return ret;
+	}
+
+	DRM_DEV_INFO(dev, "Attached %s device\n", device->name);
+
+	drm_bridge_add(&dsi->bridge);
+
+	if (pdata->host_ops && pdata->host_ops->attach) {
+		ret = pdata->host_ops->attach(dsi, device);
+		if (ret < 0)
+			return ret;
+	}
+
+	dsi->lanes = device->lanes;
+	dsi->format = device->format;
+	dsi->mode_flags = device->mode_flags;
+
+	return 0;
+}
+
+static int samsung_dsim_host_detach(struct mipi_dsi_host *host,
+				    struct mipi_dsi_device *device)
+{
+	struct samsung_dsim *dsi = host_to_dsi(host);
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+	int ret;
+
+	if (dsi->out_bridge->funcs->detach)
+		dsi->out_bridge->funcs->detach(dsi->out_bridge);
+
+	dsi->out_bridge = NULL;
+
+	if (pdata->host_ops && pdata->host_ops->detach) {
+		ret = pdata->host_ops->detach(dsi, device);
+		if (ret < 0)
+			return ret;
+	}
+
+	drm_bridge_remove(&dsi->bridge);
+
+	return 0;
+}
+
+static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
+					  const struct mipi_dsi_msg *msg)
+{
+	struct samsung_dsim *dsi = host_to_dsi(host);
+	struct samsung_dsim_transfer xfer;
+	int ret;
+
+	if (!(dsi->state & DSIM_STATE_ENABLED))
+		return -EINVAL;
+
+	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
+		ret = samsung_dsim_init(dsi);
+		if (ret)
+			return ret;
+		dsi->state |= DSIM_STATE_INITIALIZED;
+	}
+
+	ret = mipi_dsi_create_packet(&xfer.packet, msg);
+	if (ret < 0)
+		return ret;
+
+	xfer.rx_len = msg->rx_len;
+	xfer.rx_payload = msg->rx_buf;
+	xfer.flags = msg->flags;
+
+	ret = samsung_dsim_transfer(dsi, &xfer);
+	return (ret < 0) ? ret : xfer.rx_done;
+}
+
+static const struct mipi_dsi_host_ops samsung_dsim_ops = {
+	.attach = samsung_dsim_host_attach,
+	.detach = samsung_dsim_host_detach,
+	.transfer = samsung_dsim_host_transfer,
+};
+
+static int samsung_dsim_of_read_u32(const struct device_node *np,
+				    const char *propname, u32 *out_value)
+{
+	int ret = of_property_read_u32(np, propname, out_value);
+
+	if (ret < 0)
+		pr_err("%pOF: failed to get '%s' property\n", np, propname);
+
+	return ret;
+}
+
+static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
+{
+	struct device *dev = dsi->dev;
+	struct device_node *node = dev->of_node;
+	int ret;
+
+	ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
+				       &dsi->pll_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
+				       &dsi->burst_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
+				       &dsi->esc_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static int samsung_dsim_register_host(struct samsung_dsim *dsi)
+{
+	return mipi_dsi_host_register(&dsi->dsi_host);
+}
+
+static void samsung_dsim_unregister_host(struct samsung_dsim *dsi)
+{
+	mipi_dsi_host_unregister(&dsi->dsi_host);
+}
+
+static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
+	.register_host = samsung_dsim_register_host,
+	.unregister_host = samsung_dsim_unregister_host,
+};
+
+int samsung_dsim_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct samsung_dsim *dsi;
+	int ret, i;
+
+	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
+	if (!dsi)
+		return -ENOMEM;
+
+	init_completion(&dsi->completed);
+	spin_lock_init(&dsi->transfer_lock);
+	INIT_LIST_HEAD(&dsi->transfer_list);
+
+	dsi->dsi_host.ops = &samsung_dsim_ops;
+	dsi->dsi_host.dev = dev;
+
+	dsi->dev = dev;
+	dsi->plat_data = of_device_get_match_data(dev);
+	dsi->driver_data = samsung_dsim_types[dsi->plat_data->hw_type];
+
+	dsi->supplies[0].supply = "vddcore";
+	dsi->supplies[1].supply = "vddio";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
+				      dsi->supplies);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get regulators\n");
+
+	dsi->clks = devm_kcalloc(dev, dsi->driver_data->num_clks,
+				 sizeof(*dsi->clks), GFP_KERNEL);
+	if (!dsi->clks)
+		return -ENOMEM;
+
+	for (i = 0; i < dsi->driver_data->num_clks; i++) {
+		dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
+		if (IS_ERR(dsi->clks[i])) {
+			if (strcmp(clk_names[i], "sclk_mipi") == 0) {
+				dsi->clks[i] = devm_clk_get(dev, OLD_SCLK_MIPI_CLK_NAME);
+				if (!IS_ERR(dsi->clks[i]))
+					continue;
+			}
+
+			dev_info(dev, "failed to get the clock: %s\n", clk_names[i]);
+			return PTR_ERR(dsi->clks[i]);
+		}
+	}
+
+	dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(dsi->reg_base))
+		return PTR_ERR(dsi->reg_base);
+
+	dsi->phy = devm_phy_get(dev, "dsim");
+	if (IS_ERR(dsi->phy)) {
+		dev_info(dev, "failed to get dsim phy\n");
+		return PTR_ERR(dsi->phy);
+	}
+
+	dsi->irq = platform_get_irq(pdev, 0);
+	if (dsi->irq < 0)
+		return dsi->irq;
+
+	ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
+					samsung_dsim_irq,
+					IRQF_ONESHOT | IRQF_NO_AUTOEN,
+					dev_name(dev), dsi);
+	if (ret) {
+		dev_err(dev, "failed to request dsi irq\n");
+		return ret;
+	}
+
+	ret = samsung_dsim_parse_dt(dsi);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, dsi);
+
+	pm_runtime_enable(dev);
+
+	dsi->bridge.funcs = &samsung_dsim_bridge_funcs;
+	dsi->bridge.of_node = dev->of_node;
+	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
+
+	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
+		ret = dsi->plat_data->host_ops->register_host(dsi);
+
+	if (ret)
+		goto err_disable_runtime;
+
+	return 0;
+
+err_disable_runtime:
+	pm_runtime_disable(dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(samsung_dsim_probe);
+
+int samsung_dsim_remove(struct platform_device *pdev)
+{
+	struct samsung_dsim *dsi = platform_get_drvdata(pdev);
+
+	pm_runtime_disable(&pdev->dev);
+
+	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->unregister_host)
+		dsi->plat_data->host_ops->unregister_host(dsi);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(samsung_dsim_remove);
+
+static int __maybe_unused samsung_dsim_suspend(struct device *dev)
+{
+	struct samsung_dsim *dsi = dev_get_drvdata(dev);
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	int ret, i;
+
+	usleep_range(10000, 20000);
+
+	if (dsi->state & DSIM_STATE_INITIALIZED) {
+		dsi->state &= ~DSIM_STATE_INITIALIZED;
+
+		samsung_dsim_disable_clock(dsi);
+
+		samsung_dsim_disable_irq(dsi);
+	}
+
+	dsi->state &= ~DSIM_STATE_CMD_LPM;
+
+	phy_power_off(dsi->phy);
+
+	for (i = driver_data->num_clks - 1; i > -1; i--)
+		clk_disable_unprepare(dsi->clks[i]);
+
+	ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+	if (ret < 0)
+		dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
+
+	return 0;
+}
+
+static int __maybe_unused samsung_dsim_resume(struct device *dev)
+{
+	struct samsung_dsim *dsi = dev_get_drvdata(dev);
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	int ret, i;
+
+	ret = regulator_bulk_enable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+	if (ret < 0) {
+		dev_err(dsi->dev, "cannot enable regulators %d\n", ret);
+		return ret;
+	}
+
+	for (i = 0; i < driver_data->num_clks; i++) {
+		ret = clk_prepare_enable(dsi->clks[i]);
+		if (ret < 0)
+			goto err_clk;
+	}
+
+	ret = phy_power_on(dsi->phy);
+	if (ret < 0) {
+		dev_err(dsi->dev, "cannot enable phy %d\n", ret);
+		goto err_clk;
+	}
+
+	return 0;
+
+err_clk:
+	while (--i > -1)
+		clk_disable_unprepare(dsi->clks[i]);
+	regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+
+	return ret;
+}
+
+const struct dev_pm_ops samsung_dsim_pm_ops = {
+	SET_RUNTIME_PM_OPS(samsung_dsim_suspend, samsung_dsim_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+};
+EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
+
+static const struct of_device_id samsung_dsim_of_match[] = {
+	{ /* sentinel. */ }
+};
+MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
+
+static struct platform_driver samsung_dsim_driver = {
+	.probe = samsung_dsim_probe,
+	.remove = samsung_dsim_remove,
+	.driver = {
+		   .name = "samsung-dsim",
+		   .owner = THIS_MODULE,
+		   .pm = &samsung_dsim_pm_ops,
+		   .of_match_table = samsung_dsim_of_match,
+	},
+};
+
+module_platform_driver(samsung_dsim_driver);
+
+MODULE_AUTHOR("Jagan Teki <jagan@amarulasolutions.com>");
+MODULE_DESCRIPTION("Samsung MIPI DSIM controller bridge");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 3d2f025d4fd4..a65acfed15b9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -59,6 +59,7 @@ config DRM_EXYNOS_DSI
 	depends on DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || DRM_EXYNOS7_DECON
 	select DRM_MIPI_DSI
 	select DRM_PANEL
+	select DRM_SAMSUNG_DSIM
 	default n
 	help
 	  This enables support for Exynos MIPI-DSI device.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index fce7f0a7e4ee..5f403703d133 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1,1351 +1,83 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Samsung SoC MIPI DSI Master driver.
+ * Samsung MIPI DSIM glue for Exynos SoCs.
  *
  * Copyright (c) 2014 Samsung Electronics Co., Ltd
  *
  * Contacts: Tomasz Figa <t.figa@samsung.com>
-*/
+ */
 
-#include <linux/clk.h>
-#include <linux/delay.h>
 #include <linux/component.h>
 #include <linux/gpio/consumer.h>
-#include <linux/irq.h>
 #include <linux/of_device.h>
-#include <linux/of_graph.h>
-#include <linux/phy/phy.h>
-#include <linux/regulator/consumer.h>
 
-#include <asm/unaligned.h>
-
-#include <video/mipi_display.h>
-#include <video/videomode.h>
-
-#include <drm/drm_atomic_helper.h>
-#include <drm/drm_bridge.h>
-#include <drm/drm_mipi_dsi.h>
-#include <drm/drm_panel.h>
-#include <drm/drm_print.h>
+#include <drm/bridge/samsung-dsim.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_simple_kms_helper.h>
 
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
 
-/* returns true iff both arguments logically differs */
-#define NEQV(a, b) (!(a) ^ !(b))
-
-/* DSIM_STATUS */
-#define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
-#define DSIM_STOP_STATE_CLK		(1 << 8)
-#define DSIM_TX_READY_HS_CLK		(1 << 10)
-#define DSIM_PLL_STABLE			(1 << 31)
-
-/* DSIM_SWRST */
-#define DSIM_FUNCRST			(1 << 16)
-#define DSIM_SWRST			(1 << 0)
-
-/* DSIM_TIMEOUT */
-#define DSIM_LPDR_TIMEOUT(x)		((x) << 0)
-#define DSIM_BTA_TIMEOUT(x)		((x) << 16)
-
-/* DSIM_CLKCTRL */
-#define DSIM_ESC_PRESCALER(x)		(((x) & 0xffff) << 0)
-#define DSIM_ESC_PRESCALER_MASK		(0xffff << 0)
-#define DSIM_LANE_ESC_CLK_EN_CLK	(1 << 19)
-#define DSIM_LANE_ESC_CLK_EN_DATA(x)	(((x) & 0xf) << 20)
-#define DSIM_LANE_ESC_CLK_EN_DATA_MASK	(0xf << 20)
-#define DSIM_BYTE_CLKEN			(1 << 24)
-#define DSIM_BYTE_CLK_SRC(x)		(((x) & 0x3) << 25)
-#define DSIM_BYTE_CLK_SRC_MASK		(0x3 << 25)
-#define DSIM_PLL_BYPASS			(1 << 27)
-#define DSIM_ESC_CLKEN			(1 << 28)
-#define DSIM_TX_REQUEST_HSCLK		(1 << 31)
-
-/* DSIM_CONFIG */
-#define DSIM_LANE_EN_CLK		(1 << 0)
-#define DSIM_LANE_EN(x)			(((x) & 0xf) << 1)
-#define DSIM_NUM_OF_DATA_LANE(x)	(((x) & 0x3) << 5)
-#define DSIM_SUB_PIX_FORMAT(x)		(((x) & 0x7) << 8)
-#define DSIM_MAIN_PIX_FORMAT_MASK	(0x7 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB888	(0x7 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB666	(0x6 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB666_P	(0x5 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
-#define DSIM_SUB_VC			(((x) & 0x3) << 16)
-#define DSIM_MAIN_VC			(((x) & 0x3) << 18)
-#define DSIM_HSA_DISABLE		(1 << 20)
-#define DSIM_HBP_DISABLE		(1 << 21)
-#define DSIM_HFP_DISABLE		(1 << 22)
-#define DSIM_HSE_DISABLE		(1 << 23)
-#define DSIM_AUTO_MODE			(1 << 24)
-#define DSIM_VIDEO_MODE			(1 << 25)
-#define DSIM_BURST_MODE			(1 << 26)
-#define DSIM_SYNC_INFORM		(1 << 27)
-#define DSIM_EOT_DISABLE		(1 << 28)
-#define DSIM_MFLUSH_VS			(1 << 29)
-/* This flag is valid only for exynos3250/3472/5260/5430 */
-#define DSIM_CLKLANE_STOP		(1 << 30)
-
-/* DSIM_ESCMODE */
-#define DSIM_TX_TRIGGER_RST		(1 << 4)
-#define DSIM_TX_LPDT_LP			(1 << 6)
-#define DSIM_CMD_LPDT_LP		(1 << 7)
-#define DSIM_FORCE_BTA			(1 << 16)
-#define DSIM_FORCE_STOP_STATE		(1 << 20)
-#define DSIM_STOP_STATE_CNT(x)		(((x) & 0x7ff) << 21)
-#define DSIM_STOP_STATE_CNT_MASK	(0x7ff << 21)
-
-/* DSIM_MDRESOL */
-#define DSIM_MAIN_STAND_BY		(1 << 31)
-#define DSIM_MAIN_VRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 16)
-#define DSIM_MAIN_HRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 0)
-
-/* DSIM_MVPORCH */
-#define DSIM_CMD_ALLOW(x)		((x) << 28)
-#define DSIM_STABLE_VFP(x)		((x) << 16)
-#define DSIM_MAIN_VBP(x)		((x) << 0)
-#define DSIM_CMD_ALLOW_MASK		(0xf << 28)
-#define DSIM_STABLE_VFP_MASK		(0x7ff << 16)
-#define DSIM_MAIN_VBP_MASK		(0x7ff << 0)
-
-/* DSIM_MHPORCH */
-#define DSIM_MAIN_HFP(x)		((x) << 16)
-#define DSIM_MAIN_HBP(x)		((x) << 0)
-#define DSIM_MAIN_HFP_MASK		((0xffff) << 16)
-#define DSIM_MAIN_HBP_MASK		((0xffff) << 0)
-
-/* DSIM_MSYNC */
-#define DSIM_MAIN_VSA(x)		((x) << 22)
-#define DSIM_MAIN_HSA(x)		((x) << 0)
-#define DSIM_MAIN_VSA_MASK		((0x3ff) << 22)
-#define DSIM_MAIN_HSA_MASK		((0xffff) << 0)
-
-/* DSIM_SDRESOL */
-#define DSIM_SUB_STANDY(x)		((x) << 31)
-#define DSIM_SUB_VRESOL(x)		((x) << 16)
-#define DSIM_SUB_HRESOL(x)		((x) << 0)
-#define DSIM_SUB_STANDY_MASK		((0x1) << 31)
-#define DSIM_SUB_VRESOL_MASK		((0x7ff) << 16)
-#define DSIM_SUB_HRESOL_MASK		((0x7ff) << 0)
-
-/* DSIM_INTSRC */
-#define DSIM_INT_PLL_STABLE		(1 << 31)
-#define DSIM_INT_SW_RST_RELEASE		(1 << 30)
-#define DSIM_INT_SFR_FIFO_EMPTY		(1 << 29)
-#define DSIM_INT_SFR_HDR_FIFO_EMPTY	(1 << 28)
-#define DSIM_INT_BTA			(1 << 25)
-#define DSIM_INT_FRAME_DONE		(1 << 24)
-#define DSIM_INT_RX_TIMEOUT		(1 << 21)
-#define DSIM_INT_BTA_TIMEOUT		(1 << 20)
-#define DSIM_INT_RX_DONE		(1 << 18)
-#define DSIM_INT_RX_TE			(1 << 17)
-#define DSIM_INT_RX_ACK			(1 << 16)
-#define DSIM_INT_RX_ECC_ERR		(1 << 15)
-#define DSIM_INT_RX_CRC_ERR		(1 << 14)
-
-/* DSIM_FIFOCTRL */
-#define DSIM_RX_DATA_FULL		(1 << 25)
-#define DSIM_RX_DATA_EMPTY		(1 << 24)
-#define DSIM_SFR_HEADER_FULL		(1 << 23)
-#define DSIM_SFR_HEADER_EMPTY		(1 << 22)
-#define DSIM_SFR_PAYLOAD_FULL		(1 << 21)
-#define DSIM_SFR_PAYLOAD_EMPTY		(1 << 20)
-#define DSIM_I80_HEADER_FULL		(1 << 19)
-#define DSIM_I80_HEADER_EMPTY		(1 << 18)
-#define DSIM_I80_PAYLOAD_FULL		(1 << 17)
-#define DSIM_I80_PAYLOAD_EMPTY		(1 << 16)
-#define DSIM_SD_HEADER_FULL		(1 << 15)
-#define DSIM_SD_HEADER_EMPTY		(1 << 14)
-#define DSIM_SD_PAYLOAD_FULL		(1 << 13)
-#define DSIM_SD_PAYLOAD_EMPTY		(1 << 12)
-#define DSIM_MD_HEADER_FULL		(1 << 11)
-#define DSIM_MD_HEADER_EMPTY		(1 << 10)
-#define DSIM_MD_PAYLOAD_FULL		(1 << 9)
-#define DSIM_MD_PAYLOAD_EMPTY		(1 << 8)
-#define DSIM_RX_FIFO			(1 << 4)
-#define DSIM_SFR_FIFO			(1 << 3)
-#define DSIM_I80_FIFO			(1 << 2)
-#define DSIM_SD_FIFO			(1 << 1)
-#define DSIM_MD_FIFO			(1 << 0)
-
-/* DSIM_PHYACCHR */
-#define DSIM_AFC_EN			(1 << 14)
-#define DSIM_AFC_CTL(x)			(((x) & 0x7) << 5)
-
-/* DSIM_PLLCTRL */
-#define DSIM_FREQ_BAND(x)		((x) << 24)
-#define DSIM_PLL_EN			(1 << 23)
-#define DSIM_PLL_P(x)			((x) << 13)
-#define DSIM_PLL_M(x)			((x) << 4)
-#define DSIM_PLL_S(x)			((x) << 1)
-
-/* DSIM_PHYCTRL */
-#define DSIM_PHYCTRL_ULPS_EXIT(x)	(((x) & 0x1ff) << 0)
-#define DSIM_PHYCTRL_B_DPHYCTL_VREG_LP	(1 << 30)
-#define DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP	(1 << 14)
-
-/* DSIM_PHYTIMING */
-#define DSIM_PHYTIMING_LPX(x)		((x) << 8)
-#define DSIM_PHYTIMING_HS_EXIT(x)	((x) << 0)
-
-/* DSIM_PHYTIMING1 */
-#define DSIM_PHYTIMING1_CLK_PREPARE(x)	((x) << 24)
-#define DSIM_PHYTIMING1_CLK_ZERO(x)	((x) << 16)
-#define DSIM_PHYTIMING1_CLK_POST(x)	((x) << 8)
-#define DSIM_PHYTIMING1_CLK_TRAIL(x)	((x) << 0)
-
-/* DSIM_PHYTIMING2 */
-#define DSIM_PHYTIMING2_HS_PREPARE(x)	((x) << 16)
-#define DSIM_PHYTIMING2_HS_ZERO(x)	((x) << 8)
-#define DSIM_PHYTIMING2_HS_TRAIL(x)	((x) << 0)
-
-#define DSI_MAX_BUS_WIDTH		4
-#define DSI_NUM_VIRTUAL_CHANNELS	4
-#define DSI_TX_FIFO_SIZE		2048
-#define DSI_RX_FIFO_SIZE		256
-#define DSI_XFER_TIMEOUT_MS		100
-#define DSI_RX_FIFO_EMPTY		0x30800002
-
-#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
-
-static const char *const clk_names[5] = { "bus_clk", "sclk_mipi",
-	"phyclk_mipidphy0_bitclkdiv8", "phyclk_mipidphy0_rxclkesc0",
-	"sclk_rgb_vclk_to_dsim0" };
-
-enum exynos_dsi_transfer_type {
-	EXYNOS_DSI_TX,
-	EXYNOS_DSI_RX,
-};
-
-struct exynos_dsi_transfer {
-	struct list_head list;
-	struct completion completed;
-	int result;
-	struct mipi_dsi_packet packet;
-	u16 flags;
-	u16 tx_done;
-
-	u8 *rx_payload;
-	u16 rx_len;
-	u16 rx_done;
-};
-
-#define DSIM_STATE_ENABLED		BIT(0)
-#define DSIM_STATE_INITIALIZED		BIT(1)
-#define DSIM_STATE_CMD_LPM		BIT(2)
-#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
-
-struct exynos_dsi_driver_data {
-	const unsigned int *reg_ofs;
-	unsigned int plltmr_reg;
-	unsigned int has_freqband:1;
-	unsigned int has_clklane_stop:1;
-	unsigned int num_clks;
-	unsigned int max_freq;
-	unsigned int wait_for_reset;
-	unsigned int num_bits_resol;
-	const unsigned int *reg_values;
-};
-
 struct exynos_dsi {
 	struct drm_encoder encoder;
-	struct mipi_dsi_host dsi_host;
-	struct drm_bridge bridge;
-	struct drm_bridge *out_bridge;
-	struct device *dev;
-	struct drm_display_mode mode;
-
-	void __iomem *reg_base;
-	struct phy *phy;
-	struct clk **clks;
-	struct regulator_bulk_data supplies[2];
-	int irq;
 	struct gpio_desc *te_gpio;
-
-	u32 pll_clk_rate;
-	u32 burst_clk_rate;
-	u32 esc_clk_rate;
-	u32 lanes;
-	u32 mode_flags;
-	u32 format;
-
-	int state;
-	struct drm_property *brightness;
-	struct completion completed;
-
-	spinlock_t transfer_lock; /* protects transfer_list */
-	struct list_head transfer_list;
-
-	const struct exynos_dsi_driver_data *driver_data;
-};
-
-#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
-
-static inline struct exynos_dsi *bridge_to_dsi(struct drm_bridge *b)
-{
-	return container_of(b, struct exynos_dsi, bridge);
-}
-
-enum reg_idx {
-	DSIM_STATUS_REG,	/* Status register */
-	DSIM_SWRST_REG,		/* Software reset register */
-	DSIM_CLKCTRL_REG,	/* Clock control register */
-	DSIM_TIMEOUT_REG,	/* Time out register */
-	DSIM_CONFIG_REG,	/* Configuration register */
-	DSIM_ESCMODE_REG,	/* Escape mode register */
-	DSIM_MDRESOL_REG,
-	DSIM_MVPORCH_REG,	/* Main display Vporch register */
-	DSIM_MHPORCH_REG,	/* Main display Hporch register */
-	DSIM_MSYNC_REG,		/* Main display sync area register */
-	DSIM_INTSRC_REG,	/* Interrupt source register */
-	DSIM_INTMSK_REG,	/* Interrupt mask register */
-	DSIM_PKTHDR_REG,	/* Packet Header FIFO register */
-	DSIM_PAYLOAD_REG,	/* Payload FIFO register */
-	DSIM_RXFIFO_REG,	/* Read FIFO register */
-	DSIM_FIFOCTRL_REG,	/* FIFO status and control register */
-	DSIM_PLLCTRL_REG,	/* PLL control register */
-	DSIM_PHYCTRL_REG,
-	DSIM_PHYTIMING_REG,
-	DSIM_PHYTIMING1_REG,
-	DSIM_PHYTIMING2_REG,
-	NUM_REGS
 };
 
-static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
-				    u32 val)
-{
-
-	writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
-}
-
-static inline u32 exynos_dsi_read(struct exynos_dsi *dsi, enum reg_idx idx)
-{
-	return readl(dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
-}
-
-static const unsigned int exynos_reg_ofs[] = {
-	[DSIM_STATUS_REG] =  0x00,
-	[DSIM_SWRST_REG] =  0x04,
-	[DSIM_CLKCTRL_REG] =  0x08,
-	[DSIM_TIMEOUT_REG] =  0x0c,
-	[DSIM_CONFIG_REG] =  0x10,
-	[DSIM_ESCMODE_REG] =  0x14,
-	[DSIM_MDRESOL_REG] =  0x18,
-	[DSIM_MVPORCH_REG] =  0x1c,
-	[DSIM_MHPORCH_REG] =  0x20,
-	[DSIM_MSYNC_REG] =  0x24,
-	[DSIM_INTSRC_REG] =  0x2c,
-	[DSIM_INTMSK_REG] =  0x30,
-	[DSIM_PKTHDR_REG] =  0x34,
-	[DSIM_PAYLOAD_REG] =  0x38,
-	[DSIM_RXFIFO_REG] =  0x3c,
-	[DSIM_FIFOCTRL_REG] =  0x44,
-	[DSIM_PLLCTRL_REG] =  0x4c,
-	[DSIM_PHYCTRL_REG] =  0x5c,
-	[DSIM_PHYTIMING_REG] =  0x64,
-	[DSIM_PHYTIMING1_REG] =  0x68,
-	[DSIM_PHYTIMING2_REG] =  0x6c,
-};
-
-static const unsigned int exynos5433_reg_ofs[] = {
-	[DSIM_STATUS_REG] = 0x04,
-	[DSIM_SWRST_REG] = 0x0C,
-	[DSIM_CLKCTRL_REG] = 0x10,
-	[DSIM_TIMEOUT_REG] = 0x14,
-	[DSIM_CONFIG_REG] = 0x18,
-	[DSIM_ESCMODE_REG] = 0x1C,
-	[DSIM_MDRESOL_REG] = 0x20,
-	[DSIM_MVPORCH_REG] = 0x24,
-	[DSIM_MHPORCH_REG] = 0x28,
-	[DSIM_MSYNC_REG] = 0x2C,
-	[DSIM_INTSRC_REG] = 0x34,
-	[DSIM_INTMSK_REG] = 0x38,
-	[DSIM_PKTHDR_REG] = 0x3C,
-	[DSIM_PAYLOAD_REG] = 0x40,
-	[DSIM_RXFIFO_REG] = 0x44,
-	[DSIM_FIFOCTRL_REG] = 0x4C,
-	[DSIM_PLLCTRL_REG] = 0x94,
-	[DSIM_PHYCTRL_REG] = 0xA4,
-	[DSIM_PHYTIMING_REG] = 0xB4,
-	[DSIM_PHYTIMING1_REG] = 0xB8,
-	[DSIM_PHYTIMING2_REG] = 0xBC,
-};
-
-enum reg_value_idx {
-	RESET_TYPE,
-	PLL_TIMER,
-	STOP_STATE_CNT,
-	PHYCTRL_ULPS_EXIT,
-	PHYCTRL_VREG_LP,
-	PHYCTRL_SLEW_UP,
-	PHYTIMING_LPX,
-	PHYTIMING_HS_EXIT,
-	PHYTIMING_CLK_PREPARE,
-	PHYTIMING_CLK_ZERO,
-	PHYTIMING_CLK_POST,
-	PHYTIMING_CLK_TRAIL,
-	PHYTIMING_HS_PREPARE,
-	PHYTIMING_HS_ZERO,
-	PHYTIMING_HS_TRAIL
-};
-
-static const unsigned int reg_values[] = {
-	[RESET_TYPE] = DSIM_SWRST,
-	[PLL_TIMER] = 500,
-	[STOP_STATE_CNT] = 0xf,
-	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x0af),
-	[PHYCTRL_VREG_LP] = 0,
-	[PHYCTRL_SLEW_UP] = 0,
-	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
-	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
-	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
-	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x27),
-	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
-	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
-	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x09),
-	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
-	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
-};
-
-static const unsigned int exynos5422_reg_values[] = {
-	[RESET_TYPE] = DSIM_SWRST,
-	[PLL_TIMER] = 500,
-	[STOP_STATE_CNT] = 0xf,
-	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0xaf),
-	[PHYCTRL_VREG_LP] = 0,
-	[PHYCTRL_SLEW_UP] = 0,
-	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x08),
-	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0d),
-	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
-	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x30),
-	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
-	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x0a),
-	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0c),
-	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x11),
-	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0d),
-};
-
-static const unsigned int exynos5433_reg_values[] = {
-	[RESET_TYPE] = DSIM_FUNCRST,
-	[PLL_TIMER] = 22200,
-	[STOP_STATE_CNT] = 0xa,
-	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
-	[PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
-	[PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
-	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
-	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
-	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
-	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
-	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
-	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x09),
-	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0b),
-	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x10),
-	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
-};
-
-static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
-	.reg_ofs = exynos_reg_ofs,
-	.plltmr_reg = 0x50,
-	.has_freqband = 1,
-	.has_clklane_stop = 1,
-	.num_clks = 2,
-	.max_freq = 1000,
-	.wait_for_reset = 1,
-	.num_bits_resol = 11,
-	.reg_values = reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
-	.reg_ofs = exynos_reg_ofs,
-	.plltmr_reg = 0x50,
-	.has_freqband = 1,
-	.has_clklane_stop = 1,
-	.num_clks = 2,
-	.max_freq = 1000,
-	.wait_for_reset = 1,
-	.num_bits_resol = 11,
-	.reg_values = reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
-	.reg_ofs = exynos_reg_ofs,
-	.plltmr_reg = 0x58,
-	.num_clks = 2,
-	.max_freq = 1000,
-	.wait_for_reset = 1,
-	.num_bits_resol = 11,
-	.reg_values = reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
-	.reg_ofs = exynos5433_reg_ofs,
-	.plltmr_reg = 0xa0,
-	.has_clklane_stop = 1,
-	.num_clks = 5,
-	.max_freq = 1500,
-	.wait_for_reset = 0,
-	.num_bits_resol = 12,
-	.reg_values = exynos5433_reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
-	.reg_ofs = exynos5433_reg_ofs,
-	.plltmr_reg = 0xa0,
-	.has_clklane_stop = 1,
-	.num_clks = 2,
-	.max_freq = 1500,
-	.wait_for_reset = 1,
-	.num_bits_resol = 12,
-	.reg_values = exynos5422_reg_values,
-};
-
-static const struct of_device_id exynos_dsi_of_match[] = {
-	{ .compatible = "samsung,exynos3250-mipi-dsi",
-	  .data = &exynos3_dsi_driver_data },
-	{ .compatible = "samsung,exynos4210-mipi-dsi",
-	  .data = &exynos4_dsi_driver_data },
-	{ .compatible = "samsung,exynos5410-mipi-dsi",
-	  .data = &exynos5_dsi_driver_data },
-	{ .compatible = "samsung,exynos5422-mipi-dsi",
-	  .data = &exynos5422_dsi_driver_data },
-	{ .compatible = "samsung,exynos5433-mipi-dsi",
-	  .data = &exynos5433_dsi_driver_data },
-	{ }
-};
-
-static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
-{
-	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
-		return;
-
-	dev_err(dsi->dev, "timeout waiting for reset\n");
-}
-
-static void exynos_dsi_reset(struct exynos_dsi *dsi)
-{
-	u32 reset_val = dsi->driver_data->reg_values[RESET_TYPE];
-
-	reinit_completion(&dsi->completed);
-	exynos_dsi_write(dsi, DSIM_SWRST_REG, reset_val);
-}
-
-#ifndef MHZ
-#define MHZ	(1000*1000)
-#endif
-
-static unsigned long exynos_dsi_pll_find_pms(struct exynos_dsi *dsi,
-		unsigned long fin, unsigned long fout, u8 *p, u16 *m, u8 *s)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	unsigned long best_freq = 0;
-	u32 min_delta = 0xffffffff;
-	u8 p_min, p_max;
-	u8 _p, best_p;
-	u16 _m, best_m;
-	u8 _s, best_s;
-
-	p_min = DIV_ROUND_UP(fin, (12 * MHZ));
-	p_max = fin / (6 * MHZ);
-
-	for (_p = p_min; _p <= p_max; ++_p) {
-		for (_s = 0; _s <= 5; ++_s) {
-			u64 tmp;
-			u32 delta;
-
-			tmp = (u64)fout * (_p << _s);
-			do_div(tmp, fin);
-			_m = tmp;
-			if (_m < 41 || _m > 125)
-				continue;
-
-			tmp = (u64)_m * fin;
-			do_div(tmp, _p);
-			if (tmp < 500 * MHZ ||
-					tmp > driver_data->max_freq * MHZ)
-				continue;
-
-			tmp = (u64)_m * fin;
-			do_div(tmp, _p << _s);
-
-			delta = abs(fout - tmp);
-			if (delta < min_delta) {
-				best_p = _p;
-				best_m = _m;
-				best_s = _s;
-				min_delta = delta;
-				best_freq = tmp;
-			}
-		}
-	}
-
-	if (best_freq) {
-		*p = best_p;
-		*m = best_m;
-		*s = best_s;
-	}
-
-	return best_freq;
-}
-
-static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
-					unsigned long freq)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	unsigned long fin, fout;
-	int timeout;
-	u8 p, s;
-	u16 m;
-	u32 reg;
-
-	fin = dsi->pll_clk_rate;
-	fout = exynos_dsi_pll_find_pms(dsi, fin, freq, &p, &m, &s);
-	if (!fout) {
-		dev_err(dsi->dev,
-			"failed to find PLL PMS for requested frequency\n");
-		return 0;
-	}
-	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
-
-	writel(driver_data->reg_values[PLL_TIMER],
-			dsi->reg_base + driver_data->plltmr_reg);
-
-	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
-
-	if (driver_data->has_freqband) {
-		static const unsigned long freq_bands[] = {
-			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
-			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
-			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
-			770 * MHZ, 870 * MHZ, 950 * MHZ,
-		};
-		int band;
-
-		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
-			if (fout < freq_bands[band])
-				break;
-
-		dev_dbg(dsi->dev, "band %d\n", band);
-
-		reg |= DSIM_FREQ_BAND(band);
-	}
-
-	exynos_dsi_write(dsi, DSIM_PLLCTRL_REG, reg);
-
-	timeout = 1000;
-	do {
-		if (timeout-- == 0) {
-			dev_err(dsi->dev, "PLL failed to stabilize\n");
-			return 0;
-		}
-		reg = exynos_dsi_read(dsi, DSIM_STATUS_REG);
-	} while ((reg & DSIM_PLL_STABLE) == 0);
-
-	return fout;
-}
-
-static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
-{
-	unsigned long hs_clk, byte_clk, esc_clk;
-	unsigned long esc_div;
-	u32 reg;
-
-	hs_clk = exynos_dsi_set_pll(dsi, dsi->burst_clk_rate);
-	if (!hs_clk) {
-		dev_err(dsi->dev, "failed to configure DSI PLL\n");
-		return -EFAULT;
-	}
-
-	byte_clk = hs_clk / 8;
-	esc_div = DIV_ROUND_UP(byte_clk, dsi->esc_clk_rate);
-	esc_clk = byte_clk / esc_div;
-
-	if (esc_clk > 20 * MHZ) {
-		++esc_div;
-		esc_clk = byte_clk / esc_div;
-	}
-
-	dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu, esc_clk = %lu\n",
-		hs_clk, byte_clk, esc_clk);
-
-	reg = exynos_dsi_read(dsi, DSIM_CLKCTRL_REG);
-	reg &= ~(DSIM_ESC_PRESCALER_MASK | DSIM_LANE_ESC_CLK_EN_CLK
-			| DSIM_LANE_ESC_CLK_EN_DATA_MASK | DSIM_PLL_BYPASS
-			| DSIM_BYTE_CLK_SRC_MASK);
-	reg |= DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN
-			| DSIM_ESC_PRESCALER(esc_div)
-			| DSIM_LANE_ESC_CLK_EN_CLK
-			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
-			| DSIM_BYTE_CLK_SRC(0)
-			| DSIM_TX_REQUEST_HSCLK;
-	exynos_dsi_write(dsi, DSIM_CLKCTRL_REG, reg);
-
-	return 0;
-}
-
-static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	const unsigned int *reg_values = driver_data->reg_values;
-	u32 reg;
-
-	if (driver_data->has_freqband)
-		return;
-
-	/* B D-PHY: D-PHY Master & Slave Analog Block control */
-	reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
-		reg_values[PHYCTRL_SLEW_UP];
-	exynos_dsi_write(dsi, DSIM_PHYCTRL_REG, reg);
-
-	/*
-	 * T LPX: Transmitted length of any Low-Power state period
-	 * T HS-EXIT: Time that the transmitter drives LP-11 following a HS
-	 *	burst
-	 */
-	reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
-	exynos_dsi_write(dsi, DSIM_PHYTIMING_REG, reg);
-
-	/*
-	 * T CLK-PREPARE: Time that the transmitter drives the Clock Lane LP-00
-	 *	Line state immediately before the HS-0 Line state starting the
-	 *	HS transmission
-	 * T CLK-ZERO: Time that the transmitter drives the HS-0 state prior to
-	 *	transmitting the Clock.
-	 * T CLK_POST: Time that the transmitter continues to send HS clock
-	 *	after the last associated Data Lane has transitioned to LP Mode
-	 *	Interval is defined as the period from the end of T HS-TRAIL to
-	 *	the beginning of T CLK-TRAIL
-	 * T CLK-TRAIL: Time that the transmitter drives the HS-0 state after
-	 *	the last payload clock bit of a HS transmission burst
-	 */
-	reg = reg_values[PHYTIMING_CLK_PREPARE] |
-		reg_values[PHYTIMING_CLK_ZERO] |
-		reg_values[PHYTIMING_CLK_POST] |
-		reg_values[PHYTIMING_CLK_TRAIL];
-
-	exynos_dsi_write(dsi, DSIM_PHYTIMING1_REG, reg);
-
-	/*
-	 * T HS-PREPARE: Time that the transmitter drives the Data Lane LP-00
-	 *	Line state immediately before the HS-0 Line state starting the
-	 *	HS transmission
-	 * T HS-ZERO: Time that the transmitter drives the HS-0 state prior to
-	 *	transmitting the Sync sequence.
-	 * T HS-TRAIL: Time that the transmitter drives the flipped differential
-	 *	state after last payload data bit of a HS transmission burst
-	 */
-	reg = reg_values[PHYTIMING_HS_PREPARE] | reg_values[PHYTIMING_HS_ZERO] |
-		reg_values[PHYTIMING_HS_TRAIL];
-	exynos_dsi_write(dsi, DSIM_PHYTIMING2_REG, reg);
-}
-
-static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
-{
-	u32 reg;
-
-	reg = exynos_dsi_read(dsi, DSIM_CLKCTRL_REG);
-	reg &= ~(DSIM_LANE_ESC_CLK_EN_CLK | DSIM_LANE_ESC_CLK_EN_DATA_MASK
-			| DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN);
-	exynos_dsi_write(dsi, DSIM_CLKCTRL_REG, reg);
-
-	reg = exynos_dsi_read(dsi, DSIM_PLLCTRL_REG);
-	reg &= ~DSIM_PLL_EN;
-	exynos_dsi_write(dsi, DSIM_PLLCTRL_REG, reg);
-}
-
-static void exynos_dsi_enable_lane(struct exynos_dsi *dsi, u32 lane)
-{
-	u32 reg = exynos_dsi_read(dsi, DSIM_CONFIG_REG);
-	reg |= (DSIM_NUM_OF_DATA_LANE(dsi->lanes - 1) | DSIM_LANE_EN_CLK |
-			DSIM_LANE_EN(lane));
-	exynos_dsi_write(dsi, DSIM_CONFIG_REG, reg);
-}
-
-static int exynos_dsi_init_link(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	int timeout;
-	u32 reg;
-	u32 lanes_mask;
-
-	/* Initialize FIFO pointers */
-	reg = exynos_dsi_read(dsi, DSIM_FIFOCTRL_REG);
-	reg &= ~0x1f;
-	exynos_dsi_write(dsi, DSIM_FIFOCTRL_REG, reg);
-
-	usleep_range(9000, 11000);
-
-	reg |= 0x1f;
-	exynos_dsi_write(dsi, DSIM_FIFOCTRL_REG, reg);
-	usleep_range(9000, 11000);
-
-	/* DSI configuration */
-	reg = 0;
-
-	/*
-	 * The first bit of mode_flags specifies display configuration.
-	 * If this bit is set[= MIPI_DSI_MODE_VIDEO], dsi will support video
-	 * mode, otherwise it will support command mode.
-	 */
-	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
-		reg |= DSIM_VIDEO_MODE;
-
-		/*
-		 * The user manual describes that following bits are ignored in
-		 * command mode.
-		 */
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
-			reg |= DSIM_MFLUSH_VS;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
-			reg |= DSIM_SYNC_INFORM;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
-			reg |= DSIM_BURST_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
-			reg |= DSIM_AUTO_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
-			reg |= DSIM_HSE_DISABLE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
-			reg |= DSIM_HFP_DISABLE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
-			reg |= DSIM_HBP_DISABLE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
-			reg |= DSIM_HSA_DISABLE;
-	}
-
-	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
-		reg |= DSIM_EOT_DISABLE;
-
-	switch (dsi->format) {
-	case MIPI_DSI_FMT_RGB888:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
-		break;
-	case MIPI_DSI_FMT_RGB666:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB666;
-		break;
-	case MIPI_DSI_FMT_RGB666_PACKED:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB666_P;
-		break;
-	case MIPI_DSI_FMT_RGB565:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB565;
-		break;
-	default:
-		dev_err(dsi->dev, "invalid pixel format\n");
-		return -EINVAL;
-	}
-
-	/*
-	 * Use non-continuous clock mode if the periparal wants and
-	 * host controller supports
-	 *
-	 * In non-continous clock mode, host controller will turn off
-	 * the HS clock between high-speed transmissions to reduce
-	 * power consumption.
-	 */
-	if (driver_data->has_clklane_stop &&
-			dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
-		reg |= DSIM_CLKLANE_STOP;
-	}
-	exynos_dsi_write(dsi, DSIM_CONFIG_REG, reg);
-
-	lanes_mask = BIT(dsi->lanes) - 1;
-	exynos_dsi_enable_lane(dsi, lanes_mask);
-
-	/* Check clock and data lane state are stop state */
-	timeout = 100;
-	do {
-		if (timeout-- == 0) {
-			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
-			return -EFAULT;
-		}
-
-		reg = exynos_dsi_read(dsi, DSIM_STATUS_REG);
-		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
-		    != DSIM_STOP_STATE_DAT(lanes_mask))
-			continue;
-	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
-
-	reg = exynos_dsi_read(dsi, DSIM_ESCMODE_REG);
-	reg &= ~DSIM_STOP_STATE_CNT_MASK;
-	reg |= DSIM_STOP_STATE_CNT(driver_data->reg_values[STOP_STATE_CNT]);
-	exynos_dsi_write(dsi, DSIM_ESCMODE_REG, reg);
-
-	reg = DSIM_BTA_TIMEOUT(0xff) | DSIM_LPDR_TIMEOUT(0xffff);
-	exynos_dsi_write(dsi, DSIM_TIMEOUT_REG, reg);
-
-	return 0;
-}
-
-static void exynos_dsi_set_display_mode(struct exynos_dsi *dsi)
-{
-	struct drm_display_mode *m = &dsi->mode;
-	unsigned int num_bits_resol = dsi->driver_data->num_bits_resol;
-	u32 reg;
-
-	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
-		reg = DSIM_CMD_ALLOW(0xf)
-			| DSIM_STABLE_VFP(m->vsync_start - m->vdisplay)
-			| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
-		exynos_dsi_write(dsi, DSIM_MVPORCH_REG, reg);
-
-		reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
-			| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
-		exynos_dsi_write(dsi, DSIM_MHPORCH_REG, reg);
-
-		reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
-			| DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
-		exynos_dsi_write(dsi, DSIM_MSYNC_REG, reg);
-	}
-	reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
-		DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
-
-	exynos_dsi_write(dsi, DSIM_MDRESOL_REG, reg);
-
-	dev_dbg(dsi->dev, "LCD size = %dx%d\n", m->hdisplay, m->vdisplay);
-}
-
-static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
-{
-	u32 reg;
-
-	reg = exynos_dsi_read(dsi, DSIM_MDRESOL_REG);
-	if (enable)
-		reg |= DSIM_MAIN_STAND_BY;
-	else
-		reg &= ~DSIM_MAIN_STAND_BY;
-	exynos_dsi_write(dsi, DSIM_MDRESOL_REG, reg);
-}
-
-static int exynos_dsi_wait_for_hdr_fifo(struct exynos_dsi *dsi)
-{
-	int timeout = 2000;
-
-	do {
-		u32 reg = exynos_dsi_read(dsi, DSIM_FIFOCTRL_REG);
-
-		if (!(reg & DSIM_SFR_HEADER_FULL))
-			return 0;
-
-		if (!cond_resched())
-			usleep_range(950, 1050);
-	} while (--timeout);
-
-	return -ETIMEDOUT;
-}
-
-static void exynos_dsi_set_cmd_lpm(struct exynos_dsi *dsi, bool lpm)
-{
-	u32 v = exynos_dsi_read(dsi, DSIM_ESCMODE_REG);
-
-	if (lpm)
-		v |= DSIM_CMD_LPDT_LP;
-	else
-		v &= ~DSIM_CMD_LPDT_LP;
-
-	exynos_dsi_write(dsi, DSIM_ESCMODE_REG, v);
-}
-
-static void exynos_dsi_force_bta(struct exynos_dsi *dsi)
-{
-	u32 v = exynos_dsi_read(dsi, DSIM_ESCMODE_REG);
-	v |= DSIM_FORCE_BTA;
-	exynos_dsi_write(dsi, DSIM_ESCMODE_REG, v);
-}
-
-static void exynos_dsi_send_to_fifo(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
-{
-	struct device *dev = dsi->dev;
-	struct mipi_dsi_packet *pkt = &xfer->packet;
-	const u8 *payload = pkt->payload + xfer->tx_done;
-	u16 length = pkt->payload_length - xfer->tx_done;
-	bool first = !xfer->tx_done;
-	u32 reg;
-
-	dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
-		xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
-
-	if (length > DSI_TX_FIFO_SIZE)
-		length = DSI_TX_FIFO_SIZE;
-
-	xfer->tx_done += length;
-
-	/* Send payload */
-	while (length >= 4) {
-		reg = get_unaligned_le32(payload);
-		exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
-		payload += 4;
-		length -= 4;
-	}
-
-	reg = 0;
-	switch (length) {
-	case 3:
-		reg |= payload[2] << 16;
-		fallthrough;
-	case 2:
-		reg |= payload[1] << 8;
-		fallthrough;
-	case 1:
-		reg |= payload[0];
-		exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
-		break;
-	}
-
-	/* Send packet header */
-	if (!first)
-		return;
-
-	reg = get_unaligned_le32(pkt->header);
-	if (exynos_dsi_wait_for_hdr_fifo(dsi)) {
-		dev_err(dev, "waiting for header FIFO timed out\n");
-		return;
-	}
-
-	if (NEQV(xfer->flags & MIPI_DSI_MSG_USE_LPM,
-		 dsi->state & DSIM_STATE_CMD_LPM)) {
-		exynos_dsi_set_cmd_lpm(dsi, xfer->flags & MIPI_DSI_MSG_USE_LPM);
-		dsi->state ^= DSIM_STATE_CMD_LPM;
-	}
-
-	exynos_dsi_write(dsi, DSIM_PKTHDR_REG, reg);
-
-	if (xfer->flags & MIPI_DSI_MSG_REQ_ACK)
-		exynos_dsi_force_bta(dsi);
-}
-
-static void exynos_dsi_read_from_fifo(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
-{
-	u8 *payload = xfer->rx_payload + xfer->rx_done;
-	bool first = !xfer->rx_done;
-	struct device *dev = dsi->dev;
-	u16 length;
-	u32 reg;
-
-	if (first) {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-
-		switch (reg & 0x3f) {
-		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
-		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
-			if (xfer->rx_len >= 2) {
-				payload[1] = reg >> 16;
-				++xfer->rx_done;
-			}
-			fallthrough;
-		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
-		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
-			payload[0] = reg >> 8;
-			++xfer->rx_done;
-			xfer->rx_len = xfer->rx_done;
-			xfer->result = 0;
-			goto clear_fifo;
-		case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
-			dev_err(dev, "DSI Error Report: 0x%04x\n",
-				(reg >> 8) & 0xffff);
-			xfer->result = 0;
-			goto clear_fifo;
-		}
-
-		length = (reg >> 8) & 0xffff;
-		if (length > xfer->rx_len) {
-			dev_err(dev,
-				"response too long (%u > %u bytes), stripping\n",
-				xfer->rx_len, length);
-			length = xfer->rx_len;
-		} else if (length < xfer->rx_len)
-			xfer->rx_len = length;
-	}
-
-	length = xfer->rx_len - xfer->rx_done;
-	xfer->rx_done += length;
-
-	/* Receive payload */
-	while (length >= 4) {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-		payload[0] = (reg >>  0) & 0xff;
-		payload[1] = (reg >>  8) & 0xff;
-		payload[2] = (reg >> 16) & 0xff;
-		payload[3] = (reg >> 24) & 0xff;
-		payload += 4;
-		length -= 4;
-	}
-
-	if (length) {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-		switch (length) {
-		case 3:
-			payload[2] = (reg >> 16) & 0xff;
-			fallthrough;
-		case 2:
-			payload[1] = (reg >> 8) & 0xff;
-			fallthrough;
-		case 1:
-			payload[0] = reg & 0xff;
-		}
-	}
-
-	if (xfer->rx_done == xfer->rx_len)
-		xfer->result = 0;
-
-clear_fifo:
-	length = DSI_RX_FIFO_SIZE / 4;
-	do {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-		if (reg == DSI_RX_FIFO_EMPTY)
-			break;
-	} while (--length);
-}
-
-static void exynos_dsi_transfer_start(struct exynos_dsi *dsi)
-{
-	unsigned long flags;
-	struct exynos_dsi_transfer *xfer;
-	bool start = false;
-
-again:
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	if (list_empty(&dsi->transfer_list)) {
-		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-		return;
-	}
-
-	xfer = list_first_entry(&dsi->transfer_list,
-					struct exynos_dsi_transfer, list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (xfer->packet.payload_length &&
-	    xfer->tx_done == xfer->packet.payload_length)
-		/* waiting for RX */
-		return;
-
-	exynos_dsi_send_to_fifo(dsi, xfer);
-
-	if (xfer->packet.payload_length || xfer->rx_len)
-		return;
-
-	xfer->result = 0;
-	complete(&xfer->completed);
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	list_del_init(&xfer->list);
-	start = !list_empty(&dsi->transfer_list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (start)
-		goto again;
-}
-
-static bool exynos_dsi_transfer_finish(struct exynos_dsi *dsi)
-{
-	struct exynos_dsi_transfer *xfer;
-	unsigned long flags;
-	bool start = true;
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	if (list_empty(&dsi->transfer_list)) {
-		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-		return false;
-	}
-
-	xfer = list_first_entry(&dsi->transfer_list,
-					struct exynos_dsi_transfer, list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	dev_dbg(dsi->dev,
-		"> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
-		xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
-		xfer->rx_done);
-
-	if (xfer->tx_done != xfer->packet.payload_length)
-		return true;
-
-	if (xfer->rx_done != xfer->rx_len)
-		exynos_dsi_read_from_fifo(dsi, xfer);
-
-	if (xfer->rx_done != xfer->rx_len)
-		return true;
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	list_del_init(&xfer->list);
-	start = !list_empty(&dsi->transfer_list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (!xfer->rx_len)
-		xfer->result = 0;
-	complete(&xfer->completed);
-
-	return start;
-}
-
-static void exynos_dsi_remove_transfer(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
+static void exynos_dsi_enable_irq(struct samsung_dsim *dsim)
 {
-	unsigned long flags;
-	bool start;
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	if (!list_empty(&dsi->transfer_list) &&
-	    xfer == list_first_entry(&dsi->transfer_list,
-				     struct exynos_dsi_transfer, list)) {
-		list_del_init(&xfer->list);
-		start = !list_empty(&dsi->transfer_list);
-		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-		if (start)
-			exynos_dsi_transfer_start(dsi);
-		return;
-	}
+	struct exynos_dsi *dsi = dsim->priv;
 
-	list_del_init(&xfer->list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+	if (dsi->te_gpio)
+		enable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static int exynos_dsi_transfer(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
+static void exynos_dsi_disable_irq(struct samsung_dsim *dsim)
 {
-	unsigned long flags;
-	bool stopped;
+	struct exynos_dsi *dsi = dsim->priv;
 
-	xfer->tx_done = 0;
-	xfer->rx_done = 0;
-	xfer->result = -ETIMEDOUT;
-	init_completion(&xfer->completed);
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	stopped = list_empty(&dsi->transfer_list);
-	list_add_tail(&xfer->list, &dsi->transfer_list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (stopped)
-		exynos_dsi_transfer_start(dsi);
-
-	wait_for_completion_timeout(&xfer->completed,
-				    msecs_to_jiffies(DSI_XFER_TIMEOUT_MS));
-	if (xfer->result == -ETIMEDOUT) {
-		struct mipi_dsi_packet *pkt = &xfer->packet;
-		exynos_dsi_remove_transfer(dsi, xfer);
-		dev_err(dsi->dev, "xfer timed out: %*ph %*ph\n", 4, pkt->header,
-			(int)pkt->payload_length, pkt->payload);
-		return -ETIMEDOUT;
-	}
-
-	/* Also covers hardware timeout condition */
-	return xfer->result;
+	if (dsi->te_gpio)
+		disable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
-{
-	struct exynos_dsi *dsi = dev_id;
-	u32 status;
-
-	status = exynos_dsi_read(dsi, DSIM_INTSRC_REG);
-	if (!status) {
-		static unsigned long int j;
-		if (printk_timed_ratelimit(&j, 500))
-			dev_warn(dsi->dev, "spurious interrupt\n");
-		return IRQ_HANDLED;
-	}
-	exynos_dsi_write(dsi, DSIM_INTSRC_REG, status);
-
-	if (status & DSIM_INT_SW_RST_RELEASE) {
-		u32 mask = ~(DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
-			DSIM_INT_SFR_HDR_FIFO_EMPTY | DSIM_INT_RX_ECC_ERR |
-			DSIM_INT_SW_RST_RELEASE);
-		exynos_dsi_write(dsi, DSIM_INTMSK_REG, mask);
-		complete(&dsi->completed);
-		return IRQ_HANDLED;
-	}
-
-	if (!(status & (DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
-			DSIM_INT_PLL_STABLE)))
-		return IRQ_HANDLED;
-
-	if (exynos_dsi_transfer_finish(dsi))
-		exynos_dsi_transfer_start(dsi);
-
-	return IRQ_HANDLED;
-}
+static const struct samsung_dsim_irq_ops samsung_dsim_exynos_host_irq = {
+	.enable = exynos_dsi_enable_irq,
+	.disable = exynos_dsi_disable_irq,
+};
 
 static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 {
-	struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
+	struct samsung_dsim *dsim = (struct samsung_dsim *)dev_id;
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 
-	if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
+	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
 		exynos_drm_crtc_te_handler(encoder->crtc);
 
 	return IRQ_HANDLED;
 }
 
-static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+static int exynos_dsi_register_te_irq(struct samsung_dsim *dsim, struct device *panel)
 {
-	enable_irq(dsi->irq);
-
-	if (dsi->te_gpio)
-		enable_irq(gpiod_to_irq(dsi->te_gpio));
-}
-
-static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
-{
-	if (dsi->te_gpio)
-		disable_irq(gpiod_to_irq(dsi->te_gpio));
-
-	disable_irq(dsi->irq);
-}
-
-static int exynos_dsi_init(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-
-	exynos_dsi_reset(dsi);
-	exynos_dsi_enable_irq(dsi);
-
-	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
-		exynos_dsi_enable_lane(dsi, BIT(dsi->lanes) - 1);
-
-	exynos_dsi_enable_clock(dsi);
-	if (driver_data->wait_for_reset)
-		exynos_dsi_wait_for_reset(dsi);
-	exynos_dsi_set_phy_ctrl(dsi);
-	exynos_dsi_init_link(dsi);
-
-	return 0;
-}
-
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
-				      struct device *panel)
-{
-	int ret;
+	struct exynos_dsi *dsi = dsim->priv;
 	int te_gpio_irq;
+	int ret;
 
-	dsi->te_gpio = gpiod_get_optional(panel, "te", GPIOD_IN);
+	dsi->te_gpio = devm_gpiod_get_optional(panel, "te", GPIOD_IN);
 	if (!dsi->te_gpio) {
 		return 0;
 	} else if (IS_ERR(dsi->te_gpio)) {
-		dev_err(dsi->dev, "gpio request failed with %ld\n",
-				PTR_ERR(dsi->te_gpio));
+		dev_err(dsim->dev, "gpio request failed with %ld\n",
+			PTR_ERR(dsi->te_gpio));
 		return PTR_ERR(dsi->te_gpio);
 	}
 
 	te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
 
 	ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
-				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", dsi);
+				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE",
+				   dsim);
 	if (ret) {
-		dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
+		dev_err(dsim->dev, "request interrupt failed with %d\n", ret);
 		gpiod_put(dsi->te_gpio);
 		return ret;
 	}
@@ -1353,128 +85,25 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	return 0;
 }
 
-static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
+static void exynos_dsi_unregister_te_irq(struct samsung_dsim *dsim)
 {
+	struct exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio) {
 		free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
 		gpiod_put(dsi->te_gpio);
 	}
 }
 
-static void exynos_dsi_atomic_pre_enable(struct drm_bridge *bridge,
-					 struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-	int ret;
-
-	if (dsi->state & DSIM_STATE_ENABLED)
-		return;
-
-	ret = pm_runtime_resume_and_get(dsi->dev);
-	if (ret < 0) {
-		dev_err(dsi->dev, "failed to enable DSI device.\n");
-		return;
-	}
-
-	dsi->state |= DSIM_STATE_ENABLED;
-}
-
-static void exynos_dsi_atomic_enable(struct drm_bridge *bridge,
-				     struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	exynos_dsi_set_display_mode(dsi);
-	exynos_dsi_set_display_enable(dsi, true);
-
-	dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
-
-	return;
-}
-
-static void exynos_dsi_atomic_disable(struct drm_bridge *bridge,
-				      struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	if (!(dsi->state & DSIM_STATE_ENABLED))
-		return;
-
-	dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
-}
-
-static void exynos_dsi_atomic_post_disable(struct drm_bridge *bridge,
-					   struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	exynos_dsi_set_display_enable(dsi, false);
-
-	dsi->state &= ~DSIM_STATE_ENABLED;
-	pm_runtime_put_sync(dsi->dev);
-}
-
-static void exynos_dsi_mode_set(struct drm_bridge *bridge,
-				const struct drm_display_mode *mode,
-				const struct drm_display_mode *adjusted_mode)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	drm_mode_copy(&dsi->mode, adjusted_mode);
-}
-
-static int exynos_dsi_attach(struct drm_bridge *bridge,
-			     enum drm_bridge_attach_flags flags)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
-}
-
-static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
-	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
-	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
-	.atomic_reset			= drm_atomic_helper_bridge_reset,
-	.atomic_pre_enable		= exynos_dsi_atomic_pre_enable,
-	.atomic_enable			= exynos_dsi_atomic_enable,
-	.atomic_disable			= exynos_dsi_atomic_disable,
-	.atomic_post_disable		= exynos_dsi_atomic_post_disable,
-	.mode_set			= exynos_dsi_mode_set,
-	.attach				= exynos_dsi_attach,
-};
-
-MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
-
-static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
+static int exynos_dsi_host_attach(struct samsung_dsim *dsim,
 				  struct mipi_dsi_device *device)
 {
-	struct exynos_dsi *dsi = host_to_dsi(host);
-	struct device *dev = dsi->dev;
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm = encoder->dev;
-	struct drm_panel *panel;
 	int ret;
 
-	panel = of_drm_find_panel(device->dev.of_node);
-	if (!IS_ERR(panel)) {
-		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
-	} else {
-		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
-		if (!dsi->out_bridge)
-			dsi->out_bridge = ERR_PTR(-EINVAL);
-	}
-
-	if (IS_ERR(dsi->out_bridge)) {
-		ret = PTR_ERR(dsi->out_bridge);
-		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
-		return ret;
-	}
-
-	DRM_DEV_INFO(dev, "Attached %s device\n", device->name);
-
-	drm_bridge_add(&dsi->bridge);
-
-	drm_bridge_attach(encoder, &dsi->bridge, NULL, 0);
+	drm_bridge_attach(encoder, &dsim->bridge, NULL, 0);
 
 	/*
 	 * This is a temporary solution and should be made by more generic way.
@@ -1483,18 +112,18 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
 	 * TE interrupt handler.
 	 */
 	if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO)) {
-		ret = exynos_dsi_register_te_irq(dsi, &device->dev);
+		ret = exynos_dsi_register_te_irq(dsim, &device->dev);
 		if (ret)
 			return ret;
 	}
 
 	mutex_lock(&drm->mode_config.mutex);
 
-	dsi->lanes = device->lanes;
-	dsi->format = device->format;
-	dsi->mode_flags = device->mode_flags;
+	dsim->lanes = device->lanes;
+	dsim->format = device->format;
+	dsim->mode_flags = device->mode_flags;
 	exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
-			!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
+			!(dsim->mode_flags & MIPI_DSI_MODE_VIDEO);
 
 	mutex_unlock(&drm->mode_config.mutex);
 
@@ -1504,100 +133,34 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
 	return 0;
 }
 
-static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
+static int exynos_dsi_host_detach(struct samsung_dsim *dsim,
 				  struct mipi_dsi_device *device)
 {
-	struct exynos_dsi *dsi = host_to_dsi(host);
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_device *drm = dsi->encoder.dev;
 
-	if (dsi->out_bridge->funcs->detach)
-		dsi->out_bridge->funcs->detach(dsi->out_bridge);
-	dsi->out_bridge = NULL;
-
 	if (drm->mode_config.poll_enabled)
 		drm_kms_helper_hotplug_event(drm);
 
-	exynos_dsi_unregister_te_irq(dsi);
-
-	drm_bridge_remove(&dsi->bridge);
+	exynos_dsi_unregister_te_irq(dsim);
 
 	return 0;
 }
 
-static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
-					 const struct mipi_dsi_msg *msg)
-{
-	struct exynos_dsi *dsi = host_to_dsi(host);
-	struct exynos_dsi_transfer xfer;
-	int ret;
-
-	if (!(dsi->state & DSIM_STATE_ENABLED))
-		return -EINVAL;
-
-	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-		ret = exynos_dsi_init(dsi);
-		if (ret)
-			return ret;
-		dsi->state |= DSIM_STATE_INITIALIZED;
-	}
-
-	ret = mipi_dsi_create_packet(&xfer.packet, msg);
-	if (ret < 0)
-		return ret;
-
-	xfer.rx_len = msg->rx_len;
-	xfer.rx_payload = msg->rx_buf;
-	xfer.flags = msg->flags;
-
-	ret = exynos_dsi_transfer(dsi, &xfer);
-	return (ret < 0) ? ret : xfer.rx_done;
-}
+static int exynos_dsi_register_host(struct samsung_dsim *dsim);
+static void exynos_dsi_unregister_host(struct samsung_dsim *dsim);
 
-static const struct mipi_dsi_host_ops exynos_dsi_ops = {
+static const struct samsung_dsim_host_ops samsung_dsim_exynos_host_ops = {
+	.register_host = exynos_dsi_register_host,
+	.unregister_host = exynos_dsi_unregister_host,
 	.attach = exynos_dsi_host_attach,
 	.detach = exynos_dsi_host_detach,
-	.transfer = exynos_dsi_host_transfer,
 };
 
-static int exynos_dsi_of_read_u32(const struct device_node *np,
-				  const char *propname, u32 *out_value)
-{
-	int ret = of_property_read_u32(np, propname, out_value);
-
-	if (ret < 0)
-		pr_err("%pOF: failed to get '%s' property\n", np, propname);
-
-	return ret;
-}
-
-static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
+static int exynos_dsi_bind(struct device *dev, struct device *master, void *data)
 {
-	struct device *dev = dsi->dev;
-	struct device_node *node = dev->of_node;
-	int ret;
-
-	ret = exynos_dsi_of_read_u32(node, "samsung,pll-clock-frequency",
-				     &dsi->pll_clk_rate);
-	if (ret < 0)
-		return ret;
-
-	ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
-				     &dsi->burst_clk_rate);
-	if (ret < 0)
-		return ret;
-
-	ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
-				     &dsi->esc_clk_rate);
-	if (ret < 0)
-		return ret;
-
-	return 0;
-}
-
-static int exynos_dsi_bind(struct device *dev, struct device *master,
-				void *data)
-{
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
+	struct samsung_dsim *dsim = dev_get_drvdata(dev);
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm_dev = data;
 	int ret;
@@ -1608,17 +171,16 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
 	if (ret < 0)
 		return ret;
 
-	return mipi_dsi_host_register(&dsi->dsi_host);
+	return mipi_dsi_host_register(&dsim->dsi_host);
 }
 
-static void exynos_dsi_unbind(struct device *dev, struct device *master,
-				void *data)
+static void exynos_dsi_unbind(struct device *dev, struct device *master, void *data)
 {
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
+	struct samsung_dsim *dsim = dev_get_drvdata(dev);
 
-	exynos_dsi_atomic_disable(&dsi->bridge, NULL);
+	dsim->bridge.funcs->atomic_disable(&dsim->bridge, NULL);
 
-	mipi_dsi_host_unregister(&dsi->dsi_host);
+	mipi_dsi_host_unregister(&dsim->dsi_host);
 }
 
 static const struct component_ops exynos_dsi_component_ops = {
@@ -1626,188 +188,86 @@ static const struct component_ops exynos_dsi_component_ops = {
 	.unbind	= exynos_dsi_unbind,
 };
 
-static int exynos_dsi_probe(struct platform_device *pdev)
+static int exynos_dsi_register_host(struct samsung_dsim *dsim)
 {
-	struct device *dev = &pdev->dev;
-	struct exynos_dsi *dsi;
-	int ret, i;
+	struct exynos_dsi *exynos_dsi;
 
-	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
-	if (!dsi)
+	exynos_dsi = devm_kzalloc(dsim->dev, sizeof(*exynos_dsi), GFP_KERNEL);
+	if (!exynos_dsi)
 		return -ENOMEM;
 
-	init_completion(&dsi->completed);
-	spin_lock_init(&dsi->transfer_lock);
-	INIT_LIST_HEAD(&dsi->transfer_list);
+	dsim->priv = exynos_dsi;
 
-	dsi->dsi_host.ops = &exynos_dsi_ops;
-	dsi->dsi_host.dev = dev;
-
-	dsi->dev = dev;
-	dsi->driver_data = of_device_get_match_data(dev);
-
-	dsi->supplies[0].supply = "vddcore";
-	dsi->supplies[1].supply = "vddio";
-	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
-				      dsi->supplies);
-	if (ret)
-		return dev_err_probe(dev, ret, "failed to get regulators\n");
-
-	dsi->clks = devm_kcalloc(dev,
-			dsi->driver_data->num_clks, sizeof(*dsi->clks),
-			GFP_KERNEL);
-	if (!dsi->clks)
-		return -ENOMEM;
-
-	for (i = 0; i < dsi->driver_data->num_clks; i++) {
-		dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
-		if (IS_ERR(dsi->clks[i])) {
-			if (strcmp(clk_names[i], "sclk_mipi") == 0) {
-				dsi->clks[i] = devm_clk_get(dev,
-							OLD_SCLK_MIPI_CLK_NAME);
-				if (!IS_ERR(dsi->clks[i]))
-					continue;
-			}
-
-			dev_info(dev, "failed to get the clock: %s\n",
-					clk_names[i]);
-			return PTR_ERR(dsi->clks[i]);
-		}
-	}
-
-	dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
-	if (IS_ERR(dsi->reg_base))
-		return PTR_ERR(dsi->reg_base);
-
-	dsi->phy = devm_phy_get(dev, "dsim");
-	if (IS_ERR(dsi->phy)) {
-		dev_info(dev, "failed to get dsim phy\n");
-		return PTR_ERR(dsi->phy);
-	}
-
-	dsi->irq = platform_get_irq(pdev, 0);
-	if (dsi->irq < 0)
-		return dsi->irq;
-
-	ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
-					exynos_dsi_irq,
-					IRQF_ONESHOT | IRQF_NO_AUTOEN,
-					dev_name(dev), dsi);
-	if (ret) {
-		dev_err(dev, "failed to request dsi irq\n");
-		return ret;
-	}
-
-	ret = exynos_dsi_parse_dt(dsi);
-	if (ret)
-		return ret;
-
-	platform_set_drvdata(pdev, dsi);
-
-	pm_runtime_enable(dev);
-
-	dsi->bridge.funcs = &exynos_dsi_bridge_funcs;
-	dsi->bridge.of_node = dev->of_node;
-	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
-
-	ret = component_add(dev, &exynos_dsi_component_ops);
-	if (ret)
-		goto err_disable_runtime;
-
-	return 0;
-
-err_disable_runtime:
-	pm_runtime_disable(dev);
-
-	return ret;
+	return component_add(dsim->dev, &exynos_dsi_component_ops);
 }
 
-static int exynos_dsi_remove(struct platform_device *pdev)
+static void exynos_dsi_unregister_host(struct samsung_dsim *dsim)
 {
-	pm_runtime_disable(&pdev->dev);
-
-	component_del(&pdev->dev, &exynos_dsi_component_ops);
-
-	return 0;
+	component_del(dsim->dev, &exynos_dsi_component_ops);
 }
 
-static int __maybe_unused exynos_dsi_suspend(struct device *dev)
-{
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	int ret, i;
-
-	usleep_range(10000, 20000);
-
-	if (dsi->state & DSIM_STATE_INITIALIZED) {
-		dsi->state &= ~DSIM_STATE_INITIALIZED;
-
-		exynos_dsi_disable_clock(dsi);
-
-		exynos_dsi_disable_irq(dsi);
-	}
-
-	dsi->state &= ~DSIM_STATE_CMD_LPM;
-
-	phy_power_off(dsi->phy);
-
-	for (i = driver_data->num_clks - 1; i > -1; i--)
-		clk_disable_unprepare(dsi->clks[i]);
-
-	ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
-	if (ret < 0)
-		dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
-
-	return 0;
-}
-
-static int __maybe_unused exynos_dsi_resume(struct device *dev)
-{
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	int ret, i;
-
-	ret = regulator_bulk_enable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
-	if (ret < 0) {
-		dev_err(dsi->dev, "cannot enable regulators %d\n", ret);
-		return ret;
-	}
-
-	for (i = 0; i < driver_data->num_clks; i++) {
-		ret = clk_prepare_enable(dsi->clks[i]);
-		if (ret < 0)
-			goto err_clk;
-	}
+static const struct samsung_dsim_plat_data exynos3250_dsi_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_EXYNOS3250,
+	.host_ops = &samsung_dsim_exynos_host_ops,
+	.irq_ops = &samsung_dsim_exynos_host_irq,
+};
 
-	ret = phy_power_on(dsi->phy);
-	if (ret < 0) {
-		dev_err(dsi->dev, "cannot enable phy %d\n", ret);
-		goto err_clk;
-	}
+static const struct samsung_dsim_plat_data exynos4210_dsi_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_EXYNOS4210,
+	.host_ops = &samsung_dsim_exynos_host_ops,
+	.irq_ops = &samsung_dsim_exynos_host_irq,
+};
 
-	return 0;
+static const struct samsung_dsim_plat_data exynos5410_dsi_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_EXYNOS5410,
+	.host_ops = &samsung_dsim_exynos_host_ops,
+	.irq_ops = &samsung_dsim_exynos_host_irq,
+};
 
-err_clk:
-	while (--i > -1)
-		clk_disable_unprepare(dsi->clks[i]);
-	regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+static const struct samsung_dsim_plat_data exynos5422_dsi_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_EXYNOS5422,
+	.host_ops = &samsung_dsim_exynos_host_ops,
+	.irq_ops = &samsung_dsim_exynos_host_irq,
+};
 
-	return ret;
-}
+static const struct samsung_dsim_plat_data exynos5433_dsi_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_EXYNOS5433,
+	.host_ops = &samsung_dsim_exynos_host_ops,
+	.irq_ops = &samsung_dsim_exynos_host_irq,
+};
 
-static const struct dev_pm_ops exynos_dsi_pm_ops = {
-	SET_RUNTIME_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume, NULL)
-	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
-				pm_runtime_force_resume)
+static const struct of_device_id exynos_dsi_of_match[] = {
+	{
+		.compatible = "samsung,exynos3250-mipi-dsi",
+		.data = &exynos3250_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos4210-mipi-dsi",
+		.data = &exynos4210_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos5410-mipi-dsi",
+		.data = &exynos5410_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos5422-mipi-dsi",
+		.data = &exynos5422_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos5433-mipi-dsi",
+		.data = &exynos5433_dsi_pdata,
+	},
+	{ /* sentinel. */ }
 };
+MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
 
 struct platform_driver dsi_driver = {
-	.probe = exynos_dsi_probe,
-	.remove = exynos_dsi_remove,
+	.probe = samsung_dsim_probe,
+	.remove = samsung_dsim_remove,
 	.driver = {
 		   .name = "exynos-dsi",
 		   .owner = THIS_MODULE,
-		   .pm = &exynos_dsi_pm_ops,
+		   .pm = &samsung_dsim_pm_ops,
 		   .of_match_table = exynos_dsi_of_match,
 	},
 };
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
new file mode 100644
index 000000000000..b8132bf8e36f
--- /dev/null
+++ b/include/drm/bridge/samsung-dsim.h
@@ -0,0 +1,113 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2022 Amarula Solutions(India)
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#ifndef __SAMSUNG_DSIM__
+#define __SAMSUNG_DSIM__
+
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_mipi_dsi.h>
+
+struct samsung_dsim;
+
+#define DSIM_STATE_ENABLED		BIT(0)
+#define DSIM_STATE_INITIALIZED		BIT(1)
+#define DSIM_STATE_CMD_LPM		BIT(2)
+#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
+
+enum samsung_dsim_type {
+	SAMSUNG_DSIM_TYPE_EXYNOS3250,
+	SAMSUNG_DSIM_TYPE_EXYNOS4210,
+	SAMSUNG_DSIM_TYPE_EXYNOS5410,
+	SAMSUNG_DSIM_TYPE_EXYNOS5422,
+	SAMSUNG_DSIM_TYPE_EXYNOS5433,
+	SAMSUNG_DSIM_TYPE_IMX8MM,
+	SAMSUNG_DSIM_TYPE_COUNT,
+};
+
+struct samsung_dsim_transfer {
+	struct list_head list;
+	struct completion completed;
+	int result;
+	struct mipi_dsi_packet packet;
+	u16 flags;
+	u16 tx_done;
+
+	u8 *rx_payload;
+	u16 rx_len;
+	u16 rx_done;
+};
+
+struct samsung_dsim_driver_data {
+	const unsigned int *reg_ofs;
+	unsigned int plltmr_reg;
+	unsigned int has_freqband:1;
+	unsigned int has_clklane_stop:1;
+	unsigned int num_clks;
+	unsigned int max_freq;
+	unsigned int wait_for_reset;
+	unsigned int num_bits_resol;
+	const unsigned int *reg_values;
+};
+
+struct samsung_dsim_host_ops {
+	int (*register_host)(struct samsung_dsim *priv);
+	void (*unregister_host)(struct samsung_dsim *priv);
+	int (*attach)(struct samsung_dsim *priv, struct mipi_dsi_device *device);
+	int (*detach)(struct samsung_dsim *priv, struct mipi_dsi_device *device);
+};
+
+struct samsung_dsim_irq_ops {
+	void (*enable)(struct samsung_dsim *priv);
+	void (*disable)(struct samsung_dsim *priv);
+};
+
+struct samsung_dsim_plat_data {
+	enum samsung_dsim_type hw_type;
+	const struct samsung_dsim_host_ops *host_ops;
+	const struct samsung_dsim_irq_ops *irq_ops;
+};
+
+struct samsung_dsim {
+	struct mipi_dsi_host dsi_host;
+	struct drm_bridge bridge;
+	struct drm_bridge *out_bridge;
+	struct device *dev;
+	struct drm_display_mode mode;
+
+	void __iomem *reg_base;
+	struct phy *phy;
+	struct clk **clks;
+	struct regulator_bulk_data supplies[2];
+	int irq;
+
+	u32 pll_clk_rate;
+	u32 burst_clk_rate;
+	u32 esc_clk_rate;
+	u32 lanes;
+	u32 mode_flags;
+	u32 format;
+
+	int state;
+	struct drm_property *brightness;
+	struct completion completed;
+
+	spinlock_t transfer_lock; /* protects transfer_list */
+	struct list_head transfer_list;
+
+	const struct samsung_dsim_driver_data *driver_data;
+	const struct samsung_dsim_plat_data *plat_data;
+
+	void *priv;
+};
+
+extern int samsung_dsim_probe(struct platform_device *pdev);
+extern int samsung_dsim_remove(struct platform_device *pdev);
+extern const struct dev_pm_ops samsung_dsim_pm_ops;
+
+#endif /* __SAMSUNG_DSIM__ */
-- 
2.25.1

Re: [PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:

[...]

> +static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
> +{
> +	int timeout = 2000;
> +
> +	do {
> +		u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
> +
> +		if (!(reg & DSIM_SFR_HEADER_FULL))

Seems that unless I wait for DSIM_SFR_HEADER_EMPTY here, there may be 
some command transfer corruption if very short commands are transferred 
in rapid succession. This can be triggered with icn6211 driver for example.

> +			return 0;
> +
> +		if (!cond_resched())
> +			usleep_range(950, 1050);
> +	} while (--timeout);
> +
> +	return -ETIMEDOUT;
> +}

[...]

Re: [PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:

[...]

> +static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
> +{
> +	int timeout = 2000;
> +
> +	do {
> +		u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
> +
> +		if (!(reg & DSIM_SFR_HEADER_FULL))

Seems that unless I wait for DSIM_SFR_HEADER_EMPTY here, there may be 
some command transfer corruption if very short commands are transferred 
in rapid succession. This can be triggered with icn6211 driver for example.

> +			return 0;
> +
> +		if (!cond_resched())
> +			usleep_range(950, 1050);
> +	} while (--timeout);
> +
> +	return -ETIMEDOUT;
> +}

[...]


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:

[...]

> +static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
> +{
> +	int timeout = 2000;
> +
> +	do {
> +		u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
> +
> +		if (!(reg & DSIM_SFR_HEADER_FULL))

Seems that unless I wait for DSIM_SFR_HEADER_EMPTY here, there may be 
some command transfer corruption if very short commands are transferred 
in rapid succession. This can be triggered with icn6211 driver for example.

> +			return 0;
> +
> +		if (!cond_resched())
> +			usleep_range(950, 1050);
> +	} while (--timeout);
> +
> +	return -ETIMEDOUT;
> +}

[...]

Re: [PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Jagan Teki]

On Thu, Nov 17, 2022 at 10:31 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
>
> [...]
>
> > +static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
> > +{
> > +     int timeout = 2000;
> > +
> > +     do {
> > +             u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
> > +
> > +             if (!(reg & DSIM_SFR_HEADER_FULL))
>
> Seems that unless I wait for DSIM_SFR_HEADER_EMPTY here, there may be
> some command transfer corruption if very short commands are transferred
> in rapid succession. This can be triggered with icn6211 driver for example.

Not aware of this test, maybe adjusting or fixing the wait code on top
of this initial support later make sense.

Thanks,
Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Jagan Teki]

On Thu, Nov 17, 2022 at 10:31 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
>
> [...]
>
> > +static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
> > +{
> > +     int timeout = 2000;
> > +
> > +     do {
> > +             u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
> > +
> > +             if (!(reg & DSIM_SFR_HEADER_FULL))
>
> Seems that unless I wait for DSIM_SFR_HEADER_EMPTY here, there may be
> some command transfer corruption if very short commands are transferred
> in rapid succession. This can be triggered with icn6211 driver for example.

Not aware of this test, maybe adjusting or fixing the wait code on top
of this initial support later make sense.

Thanks,
Jagan.

Re: [PATCH v8 03/14] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Jagan Teki]

On Thu, Nov 17, 2022 at 10:31 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
>
> [...]
>
> > +static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
> > +{
> > +     int timeout = 2000;
> > +
> > +     do {
> > +             u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
> > +
> > +             if (!(reg & DSIM_SFR_HEADER_FULL))
>
> Seems that unless I wait for DSIM_SFR_HEADER_EMPTY here, there may be
> some command transfer corruption if very short commands are transferred
> in rapid succession. This can be triggered with icn6211 driver for example.

Not aware of this test, maybe adjusting or fixing the wait code on top
of this initial support later make sense.

Thanks,
Jagan.

[PATCH v8 04/14] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices

[Jagan Teki]

The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.

The OF-graph interface represents the child devices via
remote and associated endpoint numbers like

dsi {
   compatible = "fsl,imx8mm-mipi-dsim";

   ports {
	port@0 {
	     reg = <0>;

	     dsi_in_lcdif: endpoint@0 {
		  reg = <0>;
		  remote-endpoint = <&lcdif_out_dsi>;
	     };
	};

	port@1 {
	     reg = <1>;

	     dsi_out_bridge: endpoint {
		  remote-endpoint = <&bridge_in_dsi>;
	     };
	};
};

The child node interface represents the child devices via
conventional child nodes on given DSI parent like

dsi {
   compatible = "samsung,exynos5433-mipi-dsi";

   ports {
        port@0 {
             reg = <0>;

             dsi_to_mic: endpoint {
                  remote-endpoint = <&mic_to_dsi>;
             };
        };
   };

   panel@0 {
        reg = <0>;
   };
};

As Samsung DSIM bridge is common DSI IP across all Exynos DSI
and NXP i.MX8M host controllers, this patch adds support to
lookup the child devices whether its bindings on the associated
host represent OF-graph or child node interfaces.

v8, v7, v6, v5, v4, v3:
* none

v2:
* new patch

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 38 +++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index b63e0479e71d..1c1a824b4ea7 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1356,18 +1356,52 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
 	struct samsung_dsim *dsi = host_to_dsi(host);
 	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
 	struct device *dev = dsi->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *remote;
 	struct drm_panel *panel;
 	int ret;
 
-	panel = of_drm_find_panel(device->dev.of_node);
+	/**
+	 * Devices can also be child nodes when we also control that device
+	 * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
+	 *
+	 * Lookup for a child node of the given parent that isn't either port
+	 * or ports.
+	 */
+	for_each_available_child_of_node(np, remote) {
+		if (of_node_name_eq(remote, "port") ||
+		    of_node_name_eq(remote, "ports"))
+			continue;
+
+		goto of_find_panel_or_bridge;
+	}
+
+	/*
+	 * of_graph_get_remote_node() produces a noisy error message if port
+	 * node isn't found and the absence of the port is a legit case here,
+	 * so at first we silently check whether graph presents in the
+	 * device-tree node.
+	 */
+	if (!of_graph_is_present(np))
+		return -ENODEV;
+
+	remote = of_graph_get_remote_node(np, 1, 0);
+
+of_find_panel_or_bridge:
+	if (!remote)
+		return -ENODEV;
+
+	panel = of_drm_find_panel(remote);
 	if (!IS_ERR(panel)) {
 		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
 	} else {
-		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
+		dsi->out_bridge = of_drm_find_bridge(remote);
 		if (!dsi->out_bridge)
 			dsi->out_bridge = ERR_PTR(-EINVAL);
 	}
 
+	of_node_put(remote);
+
 	if (IS_ERR(dsi->out_bridge)) {
 		ret = PTR_ERR(dsi->out_bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
-- 
2.25.1

[PATCH v8 04/14] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices

[Jagan Teki]

The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.

The OF-graph interface represents the child devices via
remote and associated endpoint numbers like

dsi {
   compatible = "fsl,imx8mm-mipi-dsim";

   ports {
	port@0 {
	     reg = <0>;

	     dsi_in_lcdif: endpoint@0 {
		  reg = <0>;
		  remote-endpoint = <&lcdif_out_dsi>;
	     };
	};

	port@1 {
	     reg = <1>;

	     dsi_out_bridge: endpoint {
		  remote-endpoint = <&bridge_in_dsi>;
	     };
	};
};

The child node interface represents the child devices via
conventional child nodes on given DSI parent like

dsi {
   compatible = "samsung,exynos5433-mipi-dsi";

   ports {
        port@0 {
             reg = <0>;

             dsi_to_mic: endpoint {
                  remote-endpoint = <&mic_to_dsi>;
             };
        };
   };

   panel@0 {
        reg = <0>;
   };
};

As Samsung DSIM bridge is common DSI IP across all Exynos DSI
and NXP i.MX8M host controllers, this patch adds support to
lookup the child devices whether its bindings on the associated
host represent OF-graph or child node interfaces.

v8, v7, v6, v5, v4, v3:
* none

v2:
* new patch

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 38 +++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index b63e0479e71d..1c1a824b4ea7 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1356,18 +1356,52 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
 	struct samsung_dsim *dsi = host_to_dsi(host);
 	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
 	struct device *dev = dsi->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *remote;
 	struct drm_panel *panel;
 	int ret;
 
-	panel = of_drm_find_panel(device->dev.of_node);
+	/**
+	 * Devices can also be child nodes when we also control that device
+	 * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
+	 *
+	 * Lookup for a child node of the given parent that isn't either port
+	 * or ports.
+	 */
+	for_each_available_child_of_node(np, remote) {
+		if (of_node_name_eq(remote, "port") ||
+		    of_node_name_eq(remote, "ports"))
+			continue;
+
+		goto of_find_panel_or_bridge;
+	}
+
+	/*
+	 * of_graph_get_remote_node() produces a noisy error message if port
+	 * node isn't found and the absence of the port is a legit case here,
+	 * so at first we silently check whether graph presents in the
+	 * device-tree node.
+	 */
+	if (!of_graph_is_present(np))
+		return -ENODEV;
+
+	remote = of_graph_get_remote_node(np, 1, 0);
+
+of_find_panel_or_bridge:
+	if (!remote)
+		return -ENODEV;
+
+	panel = of_drm_find_panel(remote);
 	if (!IS_ERR(panel)) {
 		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
 	} else {
-		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
+		dsi->out_bridge = of_drm_find_bridge(remote);
 		if (!dsi->out_bridge)
 			dsi->out_bridge = ERR_PTR(-EINVAL);
 	}
 
+	of_node_put(remote);
+
 	if (IS_ERR(dsi->out_bridge)) {
 		ret = PTR_ERR(dsi->out_bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 04/14] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices

[Jagan Teki]

The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.

The OF-graph interface represents the child devices via
remote and associated endpoint numbers like

dsi {
   compatible = "fsl,imx8mm-mipi-dsim";

   ports {
	port@0 {
	     reg = <0>;

	     dsi_in_lcdif: endpoint@0 {
		  reg = <0>;
		  remote-endpoint = <&lcdif_out_dsi>;
	     };
	};

	port@1 {
	     reg = <1>;

	     dsi_out_bridge: endpoint {
		  remote-endpoint = <&bridge_in_dsi>;
	     };
	};
};

The child node interface represents the child devices via
conventional child nodes on given DSI parent like

dsi {
   compatible = "samsung,exynos5433-mipi-dsi";

   ports {
        port@0 {
             reg = <0>;

             dsi_to_mic: endpoint {
                  remote-endpoint = <&mic_to_dsi>;
             };
        };
   };

   panel@0 {
        reg = <0>;
   };
};

As Samsung DSIM bridge is common DSI IP across all Exynos DSI
and NXP i.MX8M host controllers, this patch adds support to
lookup the child devices whether its bindings on the associated
host represent OF-graph or child node interfaces.

v8, v7, v6, v5, v4, v3:
* none

v2:
* new patch

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 38 +++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index b63e0479e71d..1c1a824b4ea7 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1356,18 +1356,52 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
 	struct samsung_dsim *dsi = host_to_dsi(host);
 	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
 	struct device *dev = dsi->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *remote;
 	struct drm_panel *panel;
 	int ret;
 
-	panel = of_drm_find_panel(device->dev.of_node);
+	/**
+	 * Devices can also be child nodes when we also control that device
+	 * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
+	 *
+	 * Lookup for a child node of the given parent that isn't either port
+	 * or ports.
+	 */
+	for_each_available_child_of_node(np, remote) {
+		if (of_node_name_eq(remote, "port") ||
+		    of_node_name_eq(remote, "ports"))
+			continue;
+
+		goto of_find_panel_or_bridge;
+	}
+
+	/*
+	 * of_graph_get_remote_node() produces a noisy error message if port
+	 * node isn't found and the absence of the port is a legit case here,
+	 * so at first we silently check whether graph presents in the
+	 * device-tree node.
+	 */
+	if (!of_graph_is_present(np))
+		return -ENODEV;
+
+	remote = of_graph_get_remote_node(np, 1, 0);
+
+of_find_panel_or_bridge:
+	if (!remote)
+		return -ENODEV;
+
+	panel = of_drm_find_panel(remote);
 	if (!IS_ERR(panel)) {
 		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
 	} else {
-		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
+		dsi->out_bridge = of_drm_find_bridge(remote);
 		if (!dsi->out_bridge)
 			dsi->out_bridge = ERR_PTR(-EINVAL);
 	}
 
+	of_node_put(remote);
+
 	if (IS_ERR(dsi->out_bridge)) {
 		ret = PTR_ERR(dsi->out_bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
-- 
2.25.1

[PATCH v8 05/14] drm: bridge: samsung-dsim: Mark PHY as optional

[Jagan Teki]

In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.

So, mark the phy get as optional.

v8:
* collect Marek Ack

v7, v6, v5, v4, v3, v2:
* none

v1:
* new patch

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 1c1a824b4ea7..bb1f45fd5a88 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1584,7 +1584,7 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	if (IS_ERR(dsi->reg_base))
 		return PTR_ERR(dsi->reg_base);
 
-	dsi->phy = devm_phy_get(dev, "dsim");
+	dsi->phy = devm_phy_optional_get(dev, "dsim");
 	if (IS_ERR(dsi->phy)) {
 		dev_info(dev, "failed to get dsim phy\n");
 		return PTR_ERR(dsi->phy);
-- 
2.25.1

[PATCH v8 05/14] drm: bridge: samsung-dsim: Mark PHY as optional

[Jagan Teki]

In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.

So, mark the phy get as optional.

v8:
* collect Marek Ack

v7, v6, v5, v4, v3, v2:
* none

v1:
* new patch

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 1c1a824b4ea7..bb1f45fd5a88 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1584,7 +1584,7 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	if (IS_ERR(dsi->reg_base))
 		return PTR_ERR(dsi->reg_base);
 
-	dsi->phy = devm_phy_get(dev, "dsim");
+	dsi->phy = devm_phy_optional_get(dev, "dsim");
 	if (IS_ERR(dsi->phy)) {
 		dev_info(dev, "failed to get dsim phy\n");
 		return PTR_ERR(dsi->phy);
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 05/14] drm: bridge: samsung-dsim: Mark PHY as optional

[Jagan Teki]

In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.

So, mark the phy get as optional.

v8:
* collect Marek Ack

v7, v6, v5, v4, v3, v2:
* none

v1:
* new patch

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 1c1a824b4ea7..bb1f45fd5a88 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1584,7 +1584,7 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	if (IS_ERR(dsi->reg_base))
 		return PTR_ERR(dsi->reg_base);
 
-	dsi->phy = devm_phy_get(dev, "dsim");
+	dsi->phy = devm_phy_optional_get(dev, "dsim");
 	if (IS_ERR(dsi->phy)) {
 		dev_info(dev, "failed to get dsim phy\n");
 		return PTR_ERR(dsi->phy);
-- 
2.25.1

[PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.

Host transfer() is usually triggered for downstream DSI panels or
bridges and I2C-configured-DSI bridges miss these host initialization
as these downstream bridges use bridge operations hooks like pre_enable,
and enable in order to initialize or set up the host.

This patch is trying to handle the host init handler to satisfy all
downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
flag to ensure that host init is also done on first cmd transfer, this
helps existing DSI panels work on exynos platform (form Marek
Szyprowski).

v8, v7, v6, v5:
* none

v4:
* update init handling to ensure host init done on first cmd transfer

v3:
* none

v2:
* check initialized state in samsung_dsim_init

v1:
* keep DSI init in host transfer

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
 include/drm/bridge/samsung-dsim.h     |  5 +++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index bb1f45fd5a88..ec7e01ae02ea 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
 	disable_irq(dsi->irq);
 }
 
-static int samsung_dsim_init(struct samsung_dsim *dsi)
+static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
 {
 	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
 
+	if (dsi->state & flag)
+		return 0;
+
 	samsung_dsim_reset(dsi);
-	samsung_dsim_enable_irq(dsi);
+
+	if (!(dsi->state & DSIM_STATE_INITIALIZED))
+		samsung_dsim_enable_irq(dsi);
 
 	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
 		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
@@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
 	samsung_dsim_set_phy_ctrl(dsi);
 	samsung_dsim_init_link(dsi);
 
+	dsi->state |= flag;
+
 	return 0;
 }
 
@@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
 	}
 
 	dsi->state |= DSIM_STATE_ENABLED;
+
+	ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+	if (ret)
+		return;
 }
 
 static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
@@ -1458,12 +1469,9 @@ static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
 	if (!(dsi->state & DSIM_STATE_ENABLED))
 		return -EINVAL;
 
-	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-		ret = samsung_dsim_init(dsi);
-		if (ret)
-			return ret;
-		dsi->state |= DSIM_STATE_INITIALIZED;
-	}
+	ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
+	if (ret)
+		return ret;
 
 	ret = mipi_dsi_create_packet(&xfer.packet, msg);
 	if (ret < 0)
@@ -1653,6 +1661,7 @@ static int __maybe_unused samsung_dsim_suspend(struct device *dev)
 
 	if (dsi->state & DSIM_STATE_INITIALIZED) {
 		dsi->state &= ~DSIM_STATE_INITIALIZED;
+		dsi->state &= ~DSIM_STATE_REINITIALIZED;
 
 		samsung_dsim_disable_clock(dsi);
 
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index b8132bf8e36f..0c5a905f3de7 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -17,8 +17,9 @@ struct samsung_dsim;
 
 #define DSIM_STATE_ENABLED		BIT(0)
 #define DSIM_STATE_INITIALIZED		BIT(1)
-#define DSIM_STATE_CMD_LPM		BIT(2)
-#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
+#define DSIM_STATE_REINITIALIZED	BIT(2)
+#define DSIM_STATE_CMD_LPM		BIT(3)
+#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(4)
 
 enum samsung_dsim_type {
 	SAMSUNG_DSIM_TYPE_EXYNOS3250,
-- 
2.25.1

[PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.

Host transfer() is usually triggered for downstream DSI panels or
bridges and I2C-configured-DSI bridges miss these host initialization
as these downstream bridges use bridge operations hooks like pre_enable,
and enable in order to initialize or set up the host.

This patch is trying to handle the host init handler to satisfy all
downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
flag to ensure that host init is also done on first cmd transfer, this
helps existing DSI panels work on exynos platform (form Marek
Szyprowski).

v8, v7, v6, v5:
* none

v4:
* update init handling to ensure host init done on first cmd transfer

v3:
* none

v2:
* check initialized state in samsung_dsim_init

v1:
* keep DSI init in host transfer

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
 include/drm/bridge/samsung-dsim.h     |  5 +++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index bb1f45fd5a88..ec7e01ae02ea 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
 	disable_irq(dsi->irq);
 }
 
-static int samsung_dsim_init(struct samsung_dsim *dsi)
+static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
 {
 	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
 
+	if (dsi->state & flag)
+		return 0;
+
 	samsung_dsim_reset(dsi);
-	samsung_dsim_enable_irq(dsi);
+
+	if (!(dsi->state & DSIM_STATE_INITIALIZED))
+		samsung_dsim_enable_irq(dsi);
 
 	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
 		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
@@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
 	samsung_dsim_set_phy_ctrl(dsi);
 	samsung_dsim_init_link(dsi);
 
+	dsi->state |= flag;
+
 	return 0;
 }
 
@@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
 	}
 
 	dsi->state |= DSIM_STATE_ENABLED;
+
+	ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+	if (ret)
+		return;
 }
 
 static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
@@ -1458,12 +1469,9 @@ static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
 	if (!(dsi->state & DSIM_STATE_ENABLED))
 		return -EINVAL;
 
-	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-		ret = samsung_dsim_init(dsi);
-		if (ret)
-			return ret;
-		dsi->state |= DSIM_STATE_INITIALIZED;
-	}
+	ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
+	if (ret)
+		return ret;
 
 	ret = mipi_dsi_create_packet(&xfer.packet, msg);
 	if (ret < 0)
@@ -1653,6 +1661,7 @@ static int __maybe_unused samsung_dsim_suspend(struct device *dev)
 
 	if (dsi->state & DSIM_STATE_INITIALIZED) {
 		dsi->state &= ~DSIM_STATE_INITIALIZED;
+		dsi->state &= ~DSIM_STATE_REINITIALIZED;
 
 		samsung_dsim_disable_clock(dsi);
 
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index b8132bf8e36f..0c5a905f3de7 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -17,8 +17,9 @@ struct samsung_dsim;
 
 #define DSIM_STATE_ENABLED		BIT(0)
 #define DSIM_STATE_INITIALIZED		BIT(1)
-#define DSIM_STATE_CMD_LPM		BIT(2)
-#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
+#define DSIM_STATE_REINITIALIZED	BIT(2)
+#define DSIM_STATE_CMD_LPM		BIT(3)
+#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(4)
 
 enum samsung_dsim_type {
 	SAMSUNG_DSIM_TYPE_EXYNOS3250,
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.

Host transfer() is usually triggered for downstream DSI panels or
bridges and I2C-configured-DSI bridges miss these host initialization
as these downstream bridges use bridge operations hooks like pre_enable,
and enable in order to initialize or set up the host.

This patch is trying to handle the host init handler to satisfy all
downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
flag to ensure that host init is also done on first cmd transfer, this
helps existing DSI panels work on exynos platform (form Marek
Szyprowski).

v8, v7, v6, v5:
* none

v4:
* update init handling to ensure host init done on first cmd transfer

v3:
* none

v2:
* check initialized state in samsung_dsim_init

v1:
* keep DSI init in host transfer

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
 include/drm/bridge/samsung-dsim.h     |  5 +++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index bb1f45fd5a88..ec7e01ae02ea 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
 	disable_irq(dsi->irq);
 }
 
-static int samsung_dsim_init(struct samsung_dsim *dsi)
+static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
 {
 	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
 
+	if (dsi->state & flag)
+		return 0;
+
 	samsung_dsim_reset(dsi);
-	samsung_dsim_enable_irq(dsi);
+
+	if (!(dsi->state & DSIM_STATE_INITIALIZED))
+		samsung_dsim_enable_irq(dsi);
 
 	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
 		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
@@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
 	samsung_dsim_set_phy_ctrl(dsi);
 	samsung_dsim_init_link(dsi);
 
+	dsi->state |= flag;
+
 	return 0;
 }
 
@@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
 	}
 
 	dsi->state |= DSIM_STATE_ENABLED;
+
+	ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+	if (ret)
+		return;
 }
 
 static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
@@ -1458,12 +1469,9 @@ static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
 	if (!(dsi->state & DSIM_STATE_ENABLED))
 		return -EINVAL;
 
-	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-		ret = samsung_dsim_init(dsi);
-		if (ret)
-			return ret;
-		dsi->state |= DSIM_STATE_INITIALIZED;
-	}
+	ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
+	if (ret)
+		return ret;
 
 	ret = mipi_dsi_create_packet(&xfer.packet, msg);
 	if (ret < 0)
@@ -1653,6 +1661,7 @@ static int __maybe_unused samsung_dsim_suspend(struct device *dev)
 
 	if (dsi->state & DSIM_STATE_INITIALIZED) {
 		dsi->state &= ~DSIM_STATE_INITIALIZED;
+		dsi->state &= ~DSIM_STATE_REINITIALIZED;
 
 		samsung_dsim_disable_clock(dsi);
 
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index b8132bf8e36f..0c5a905f3de7 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -17,8 +17,9 @@ struct samsung_dsim;
 
 #define DSIM_STATE_ENABLED		BIT(0)
 #define DSIM_STATE_INITIALIZED		BIT(1)
-#define DSIM_STATE_CMD_LPM		BIT(2)
-#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
+#define DSIM_STATE_REINITIALIZED	BIT(2)
+#define DSIM_STATE_CMD_LPM		BIT(3)
+#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(4)
 
 enum samsung_dsim_type {
 	SAMSUNG_DSIM_TYPE_EXYNOS3250,
-- 
2.25.1

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> DSI host initialization handling in previous exynos dsi driver has
> some pitfalls. It initializes the host during host transfer() hook
> that is indeed not the desired call flow for I2C and any other DSI
> configured downstream bridges.
> 
> Host transfer() is usually triggered for downstream DSI panels or
> bridges and I2C-configured-DSI bridges miss these host initialization
> as these downstream bridges use bridge operations hooks like pre_enable,
> and enable in order to initialize or set up the host.
> 
> This patch is trying to handle the host init handler to satisfy all
> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> flag to ensure that host init is also done on first cmd transfer, this
> helps existing DSI panels work on exynos platform (form Marek
> Szyprowski).
> 
> v8, v7, v6, v5:
> * none
> 
> v4:
> * update init handling to ensure host init done on first cmd transfer
> 
> v3:
> * none
> 
> v2:
> * check initialized state in samsung_dsim_init
> 
> v1:
> * keep DSI init in host transfer
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>   include/drm/bridge/samsung-dsim.h     |  5 +++--
>   2 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index bb1f45fd5a88..ec7e01ae02ea 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
>   	disable_irq(dsi->irq);
>   }
>   
> -static int samsung_dsim_init(struct samsung_dsim *dsi)
> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
>   {
>   	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>   
> +	if (dsi->state & flag)
> +		return 0;
> +
>   	samsung_dsim_reset(dsi);
> -	samsung_dsim_enable_irq(dsi);
> +
> +	if (!(dsi->state & DSIM_STATE_INITIALIZED))
> +		samsung_dsim_enable_irq(dsi);
>   
>   	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>   		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   	samsung_dsim_set_phy_ctrl(dsi);
>   	samsung_dsim_init_link(dsi);
>   
> +	dsi->state |= flag;
> +
>   	return 0;
>   }
>   
> @@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>   	}
>   
>   	dsi->state |= DSIM_STATE_ENABLED;
> +
> +	ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> +	if (ret)
> +		return;
>   }
>   
>   static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> @@ -1458,12 +1469,9 @@ static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>   	if (!(dsi->state & DSIM_STATE_ENABLED))
>   		return -EINVAL;
>   
> -	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> -		ret = samsung_dsim_init(dsi);
> -		if (ret)
> -			return ret;
> -		dsi->state |= DSIM_STATE_INITIALIZED;
> -	}
> +	ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);

This triggers full controller reset and reprogramming upon first command 
transfer, is such heavy handed reload really necessary ?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> DSI host initialization handling in previous exynos dsi driver has
> some pitfalls. It initializes the host during host transfer() hook
> that is indeed not the desired call flow for I2C and any other DSI
> configured downstream bridges.
> 
> Host transfer() is usually triggered for downstream DSI panels or
> bridges and I2C-configured-DSI bridges miss these host initialization
> as these downstream bridges use bridge operations hooks like pre_enable,
> and enable in order to initialize or set up the host.
> 
> This patch is trying to handle the host init handler to satisfy all
> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> flag to ensure that host init is also done on first cmd transfer, this
> helps existing DSI panels work on exynos platform (form Marek
> Szyprowski).
> 
> v8, v7, v6, v5:
> * none
> 
> v4:
> * update init handling to ensure host init done on first cmd transfer
> 
> v3:
> * none
> 
> v2:
> * check initialized state in samsung_dsim_init
> 
> v1:
> * keep DSI init in host transfer
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>   include/drm/bridge/samsung-dsim.h     |  5 +++--
>   2 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index bb1f45fd5a88..ec7e01ae02ea 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
>   	disable_irq(dsi->irq);
>   }
>   
> -static int samsung_dsim_init(struct samsung_dsim *dsi)
> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
>   {
>   	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>   
> +	if (dsi->state & flag)
> +		return 0;
> +
>   	samsung_dsim_reset(dsi);
> -	samsung_dsim_enable_irq(dsi);
> +
> +	if (!(dsi->state & DSIM_STATE_INITIALIZED))
> +		samsung_dsim_enable_irq(dsi);
>   
>   	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>   		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   	samsung_dsim_set_phy_ctrl(dsi);
>   	samsung_dsim_init_link(dsi);
>   
> +	dsi->state |= flag;
> +
>   	return 0;
>   }
>   
> @@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>   	}
>   
>   	dsi->state |= DSIM_STATE_ENABLED;
> +
> +	ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> +	if (ret)
> +		return;
>   }
>   
>   static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> @@ -1458,12 +1469,9 @@ static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>   	if (!(dsi->state & DSIM_STATE_ENABLED))
>   		return -EINVAL;
>   
> -	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> -		ret = samsung_dsim_init(dsi);
> -		if (ret)
> -			return ret;
> -		dsi->state |= DSIM_STATE_INITIALIZED;
> -	}
> +	ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);

This triggers full controller reset and reprogramming upon first command 
transfer, is such heavy handed reload really necessary ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> DSI host initialization handling in previous exynos dsi driver has
> some pitfalls. It initializes the host during host transfer() hook
> that is indeed not the desired call flow for I2C and any other DSI
> configured downstream bridges.
> 
> Host transfer() is usually triggered for downstream DSI panels or
> bridges and I2C-configured-DSI bridges miss these host initialization
> as these downstream bridges use bridge operations hooks like pre_enable,
> and enable in order to initialize or set up the host.
> 
> This patch is trying to handle the host init handler to satisfy all
> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> flag to ensure that host init is also done on first cmd transfer, this
> helps existing DSI panels work on exynos platform (form Marek
> Szyprowski).
> 
> v8, v7, v6, v5:
> * none
> 
> v4:
> * update init handling to ensure host init done on first cmd transfer
> 
> v3:
> * none
> 
> v2:
> * check initialized state in samsung_dsim_init
> 
> v1:
> * keep DSI init in host transfer
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>   include/drm/bridge/samsung-dsim.h     |  5 +++--
>   2 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index bb1f45fd5a88..ec7e01ae02ea 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
>   	disable_irq(dsi->irq);
>   }
>   
> -static int samsung_dsim_init(struct samsung_dsim *dsi)
> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int flag)
>   {
>   	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>   
> +	if (dsi->state & flag)
> +		return 0;
> +
>   	samsung_dsim_reset(dsi);
> -	samsung_dsim_enable_irq(dsi);
> +
> +	if (!(dsi->state & DSIM_STATE_INITIALIZED))
> +		samsung_dsim_enable_irq(dsi);
>   
>   	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>   		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   	samsung_dsim_set_phy_ctrl(dsi);
>   	samsung_dsim_init_link(dsi);
>   
> +	dsi->state |= flag;
> +
>   	return 0;
>   }
>   
> @@ -1269,6 +1276,10 @@ static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>   	}
>   
>   	dsi->state |= DSIM_STATE_ENABLED;
> +
> +	ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> +	if (ret)
> +		return;
>   }
>   
>   static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> @@ -1458,12 +1469,9 @@ static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>   	if (!(dsi->state & DSIM_STATE_ENABLED))
>   		return -EINVAL;
>   
> -	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> -		ret = samsung_dsim_init(dsi);
> -		if (ret)
> -			return ret;
> -		dsi->state |= DSIM_STATE_INITIALIZED;
> -	}
> +	ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);

This triggers full controller reset and reprogramming upon first command 
transfer, is such heavy handed reload really necessary ?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

On 17.11.2022 05:58, Marek Vasut wrote:
> On 11/10/22 19:38, Jagan Teki wrote:
>> DSI host initialization handling in previous exynos dsi driver has
>> some pitfalls. It initializes the host during host transfer() hook
>> that is indeed not the desired call flow for I2C and any other DSI
>> configured downstream bridges.
>>
>> Host transfer() is usually triggered for downstream DSI panels or
>> bridges and I2C-configured-DSI bridges miss these host initialization
>> as these downstream bridges use bridge operations hooks like pre_enable,
>> and enable in order to initialize or set up the host.
>>
>> This patch is trying to handle the host init handler to satisfy all
>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>> flag to ensure that host init is also done on first cmd transfer, this
>> helps existing DSI panels work on exynos platform (form Marek
>> Szyprowski).
>>
>> v8, v7, v6, v5:
>> * none
>>
>> v4:
>> * update init handling to ensure host init done on first cmd transfer
>>
>> v3:
>> * none
>>
>> v2:
>> * check initialized state in samsung_dsim_init
>>
>> v1:
>> * keep DSI init in host transfer
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>   include/drm/bridge/samsung-dsim.h     |  5 +++--
>>   2 files changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index bb1f45fd5a88..ec7e01ae02ea 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct 
>> samsung_dsim *dsi)
>>       disable_irq(dsi->irq);
>>   }
>>   -static int samsung_dsim_init(struct samsung_dsim *dsi)
>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int 
>> flag)
>>   {
>>       const struct samsung_dsim_driver_data *driver_data = 
>> dsi->driver_data;
>>   +    if (dsi->state & flag)
>> +        return 0;
>> +
>>       samsung_dsim_reset(dsi);
>> -    samsung_dsim_enable_irq(dsi);
>> +
>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>> +        samsung_dsim_enable_irq(dsi);
>>         if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>           samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct 
>> samsung_dsim *dsi)
>>       samsung_dsim_set_phy_ctrl(dsi);
>>       samsung_dsim_init_link(dsi);
>>   +    dsi->state |= flag;
>> +
>>       return 0;
>>   }
>>   @@ -1269,6 +1276,10 @@ static void 
>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>       }
>>         dsi->state |= DSIM_STATE_ENABLED;
>> +
>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>> +    if (ret)
>> +        return;
>>   }
>>     static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>> @@ -1458,12 +1469,9 @@ static ssize_t 
>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>       if (!(dsi->state & DSIM_STATE_ENABLED))
>>           return -EINVAL;
>>   -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>> -        ret = samsung_dsim_init(dsi);
>> -        if (ret)
>> -            return ret;
>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>> -    }
>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>
> This triggers full controller reset and reprogramming upon first 
> command transfer, is such heavy handed reload really necessary ?

Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM 
DSI. If this is a real issue for you, then maybe the driver could do the 
initialization conditionally, in prepare() callback in case of IMX and 
on the first transfer in case of Exynos?


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

On 17.11.2022 05:58, Marek Vasut wrote:
> On 11/10/22 19:38, Jagan Teki wrote:
>> DSI host initialization handling in previous exynos dsi driver has
>> some pitfalls. It initializes the host during host transfer() hook
>> that is indeed not the desired call flow for I2C and any other DSI
>> configured downstream bridges.
>>
>> Host transfer() is usually triggered for downstream DSI panels or
>> bridges and I2C-configured-DSI bridges miss these host initialization
>> as these downstream bridges use bridge operations hooks like pre_enable,
>> and enable in order to initialize or set up the host.
>>
>> This patch is trying to handle the host init handler to satisfy all
>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>> flag to ensure that host init is also done on first cmd transfer, this
>> helps existing DSI panels work on exynos platform (form Marek
>> Szyprowski).
>>
>> v8, v7, v6, v5:
>> * none
>>
>> v4:
>> * update init handling to ensure host init done on first cmd transfer
>>
>> v3:
>> * none
>>
>> v2:
>> * check initialized state in samsung_dsim_init
>>
>> v1:
>> * keep DSI init in host transfer
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>   include/drm/bridge/samsung-dsim.h     |  5 +++--
>>   2 files changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index bb1f45fd5a88..ec7e01ae02ea 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct 
>> samsung_dsim *dsi)
>>       disable_irq(dsi->irq);
>>   }
>>   -static int samsung_dsim_init(struct samsung_dsim *dsi)
>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int 
>> flag)
>>   {
>>       const struct samsung_dsim_driver_data *driver_data = 
>> dsi->driver_data;
>>   +    if (dsi->state & flag)
>> +        return 0;
>> +
>>       samsung_dsim_reset(dsi);
>> -    samsung_dsim_enable_irq(dsi);
>> +
>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>> +        samsung_dsim_enable_irq(dsi);
>>         if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>           samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct 
>> samsung_dsim *dsi)
>>       samsung_dsim_set_phy_ctrl(dsi);
>>       samsung_dsim_init_link(dsi);
>>   +    dsi->state |= flag;
>> +
>>       return 0;
>>   }
>>   @@ -1269,6 +1276,10 @@ static void 
>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>       }
>>         dsi->state |= DSIM_STATE_ENABLED;
>> +
>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>> +    if (ret)
>> +        return;
>>   }
>>     static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>> @@ -1458,12 +1469,9 @@ static ssize_t 
>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>       if (!(dsi->state & DSIM_STATE_ENABLED))
>>           return -EINVAL;
>>   -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>> -        ret = samsung_dsim_init(dsi);
>> -        if (ret)
>> -            return ret;
>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>> -    }
>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>
> This triggers full controller reset and reprogramming upon first 
> command transfer, is such heavy handed reload really necessary ?

Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM 
DSI. If this is a real issue for you, then maybe the driver could do the 
initialization conditionally, in prepare() callback in case of IMX and 
on the first transfer in case of Exynos?


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

On 17.11.2022 05:58, Marek Vasut wrote:
> On 11/10/22 19:38, Jagan Teki wrote:
>> DSI host initialization handling in previous exynos dsi driver has
>> some pitfalls. It initializes the host during host transfer() hook
>> that is indeed not the desired call flow for I2C and any other DSI
>> configured downstream bridges.
>>
>> Host transfer() is usually triggered for downstream DSI panels or
>> bridges and I2C-configured-DSI bridges miss these host initialization
>> as these downstream bridges use bridge operations hooks like pre_enable,
>> and enable in order to initialize or set up the host.
>>
>> This patch is trying to handle the host init handler to satisfy all
>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>> flag to ensure that host init is also done on first cmd transfer, this
>> helps existing DSI panels work on exynos platform (form Marek
>> Szyprowski).
>>
>> v8, v7, v6, v5:
>> * none
>>
>> v4:
>> * update init handling to ensure host init done on first cmd transfer
>>
>> v3:
>> * none
>>
>> v2:
>> * check initialized state in samsung_dsim_init
>>
>> v1:
>> * keep DSI init in host transfer
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>   include/drm/bridge/samsung-dsim.h     |  5 +++--
>>   2 files changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index bb1f45fd5a88..ec7e01ae02ea 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct 
>> samsung_dsim *dsi)
>>       disable_irq(dsi->irq);
>>   }
>>   -static int samsung_dsim_init(struct samsung_dsim *dsi)
>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int 
>> flag)
>>   {
>>       const struct samsung_dsim_driver_data *driver_data = 
>> dsi->driver_data;
>>   +    if (dsi->state & flag)
>> +        return 0;
>> +
>>       samsung_dsim_reset(dsi);
>> -    samsung_dsim_enable_irq(dsi);
>> +
>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>> +        samsung_dsim_enable_irq(dsi);
>>         if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>           samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct 
>> samsung_dsim *dsi)
>>       samsung_dsim_set_phy_ctrl(dsi);
>>       samsung_dsim_init_link(dsi);
>>   +    dsi->state |= flag;
>> +
>>       return 0;
>>   }
>>   @@ -1269,6 +1276,10 @@ static void 
>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>       }
>>         dsi->state |= DSIM_STATE_ENABLED;
>> +
>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>> +    if (ret)
>> +        return;
>>   }
>>     static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>> @@ -1458,12 +1469,9 @@ static ssize_t 
>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>       if (!(dsi->state & DSIM_STATE_ENABLED))
>>           return -EINVAL;
>>   -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>> -        ret = samsung_dsim_init(dsi);
>> -        if (ret)
>> -            return ret;
>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>> -    }
>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>
> This triggers full controller reset and reprogramming upon first 
> command transfer, is such heavy handed reload really necessary ?

Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM 
DSI. If this is a real issue for you, then maybe the driver could do the 
initialization conditionally, in prepare() callback in case of IMX and 
on the first transfer in case of Exynos?


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/17/22 14:04, Marek Szyprowski wrote:
> On 17.11.2022 05:58, Marek Vasut wrote:
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> DSI host initialization handling in previous exynos dsi driver has
>>> some pitfalls. It initializes the host during host transfer() hook
>>> that is indeed not the desired call flow for I2C and any other DSI
>>> configured downstream bridges.
>>>
>>> Host transfer() is usually triggered for downstream DSI panels or
>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>> and enable in order to initialize or set up the host.
>>>
>>> This patch is trying to handle the host init handler to satisfy all
>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>> flag to ensure that host init is also done on first cmd transfer, this
>>> helps existing DSI panels work on exynos platform (form Marek
>>> Szyprowski).
>>>
>>> v8, v7, v6, v5:
>>> * none
>>>
>>> v4:
>>> * update init handling to ensure host init done on first cmd transfer
>>>
>>> v3:
>>> * none
>>>
>>> v2:
>>> * check initialized state in samsung_dsim_init
>>>
>>> v1:
>>> * keep DSI init in host transfer
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>    include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>    2 files changed, 20 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>> samsung_dsim *dsi)
>>>        disable_irq(dsi->irq);
>>>    }
>>>    -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>> flag)
>>>    {
>>>        const struct samsung_dsim_driver_data *driver_data =
>>> dsi->driver_data;
>>>    +    if (dsi->state & flag)
>>> +        return 0;
>>> +
>>>        samsung_dsim_reset(dsi);
>>> -    samsung_dsim_enable_irq(dsi);
>>> +
>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> +        samsung_dsim_enable_irq(dsi);
>>>          if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>            samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>> samsung_dsim *dsi)
>>>        samsung_dsim_set_phy_ctrl(dsi);
>>>        samsung_dsim_init_link(dsi);
>>>    +    dsi->state |= flag;
>>> +
>>>        return 0;
>>>    }
>>>    @@ -1269,6 +1276,10 @@ static void
>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>        }
>>>          dsi->state |= DSIM_STATE_ENABLED;
>>> +
>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>> +    if (ret)
>>> +        return;
>>>    }
>>>      static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>        if (!(dsi->state & DSIM_STATE_ENABLED))
>>>            return -EINVAL;
>>>    -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>> -        ret = samsung_dsim_init(dsi);
>>> -        if (ret)
>>> -            return ret;
>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>> -    }
>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>
>> This triggers full controller reset and reprogramming upon first
>> command transfer, is such heavy handed reload really necessary ?
> 
> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> DSI. If this is a real issue for you, then maybe the driver could do the
> initialization conditionally, in prepare() callback in case of IMX and
> on the first transfer in case of Exynos?

That's odd , it does actually break panel support for me, without this 
double reset the panel works again. But I have to wonder, why would such 
a full reset be necessary at all , even on the exynos ?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/17/22 14:04, Marek Szyprowski wrote:
> On 17.11.2022 05:58, Marek Vasut wrote:
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> DSI host initialization handling in previous exynos dsi driver has
>>> some pitfalls. It initializes the host during host transfer() hook
>>> that is indeed not the desired call flow for I2C and any other DSI
>>> configured downstream bridges.
>>>
>>> Host transfer() is usually triggered for downstream DSI panels or
>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>> and enable in order to initialize or set up the host.
>>>
>>> This patch is trying to handle the host init handler to satisfy all
>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>> flag to ensure that host init is also done on first cmd transfer, this
>>> helps existing DSI panels work on exynos platform (form Marek
>>> Szyprowski).
>>>
>>> v8, v7, v6, v5:
>>> * none
>>>
>>> v4:
>>> * update init handling to ensure host init done on first cmd transfer
>>>
>>> v3:
>>> * none
>>>
>>> v2:
>>> * check initialized state in samsung_dsim_init
>>>
>>> v1:
>>> * keep DSI init in host transfer
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>    include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>    2 files changed, 20 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>> samsung_dsim *dsi)
>>>        disable_irq(dsi->irq);
>>>    }
>>>    -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>> flag)
>>>    {
>>>        const struct samsung_dsim_driver_data *driver_data =
>>> dsi->driver_data;
>>>    +    if (dsi->state & flag)
>>> +        return 0;
>>> +
>>>        samsung_dsim_reset(dsi);
>>> -    samsung_dsim_enable_irq(dsi);
>>> +
>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> +        samsung_dsim_enable_irq(dsi);
>>>          if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>            samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>> samsung_dsim *dsi)
>>>        samsung_dsim_set_phy_ctrl(dsi);
>>>        samsung_dsim_init_link(dsi);
>>>    +    dsi->state |= flag;
>>> +
>>>        return 0;
>>>    }
>>>    @@ -1269,6 +1276,10 @@ static void
>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>        }
>>>          dsi->state |= DSIM_STATE_ENABLED;
>>> +
>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>> +    if (ret)
>>> +        return;
>>>    }
>>>      static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>        if (!(dsi->state & DSIM_STATE_ENABLED))
>>>            return -EINVAL;
>>>    -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>> -        ret = samsung_dsim_init(dsi);
>>> -        if (ret)
>>> -            return ret;
>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>> -    }
>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>
>> This triggers full controller reset and reprogramming upon first
>> command transfer, is such heavy handed reload really necessary ?
> 
> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> DSI. If this is a real issue for you, then maybe the driver could do the
> initialization conditionally, in prepare() callback in case of IMX and
> on the first transfer in case of Exynos?

That's odd , it does actually break panel support for me, without this 
double reset the panel works again. But I have to wonder, why would such 
a full reset be necessary at all , even on the exynos ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/17/22 14:04, Marek Szyprowski wrote:
> On 17.11.2022 05:58, Marek Vasut wrote:
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> DSI host initialization handling in previous exynos dsi driver has
>>> some pitfalls. It initializes the host during host transfer() hook
>>> that is indeed not the desired call flow for I2C and any other DSI
>>> configured downstream bridges.
>>>
>>> Host transfer() is usually triggered for downstream DSI panels or
>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>> and enable in order to initialize or set up the host.
>>>
>>> This patch is trying to handle the host init handler to satisfy all
>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>> flag to ensure that host init is also done on first cmd transfer, this
>>> helps existing DSI panels work on exynos platform (form Marek
>>> Szyprowski).
>>>
>>> v8, v7, v6, v5:
>>> * none
>>>
>>> v4:
>>> * update init handling to ensure host init done on first cmd transfer
>>>
>>> v3:
>>> * none
>>>
>>> v2:
>>> * check initialized state in samsung_dsim_init
>>>
>>> v1:
>>> * keep DSI init in host transfer
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>    include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>    2 files changed, 20 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>> samsung_dsim *dsi)
>>>        disable_irq(dsi->irq);
>>>    }
>>>    -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>> flag)
>>>    {
>>>        const struct samsung_dsim_driver_data *driver_data =
>>> dsi->driver_data;
>>>    +    if (dsi->state & flag)
>>> +        return 0;
>>> +
>>>        samsung_dsim_reset(dsi);
>>> -    samsung_dsim_enable_irq(dsi);
>>> +
>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> +        samsung_dsim_enable_irq(dsi);
>>>          if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>            samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>> samsung_dsim *dsi)
>>>        samsung_dsim_set_phy_ctrl(dsi);
>>>        samsung_dsim_init_link(dsi);
>>>    +    dsi->state |= flag;
>>> +
>>>        return 0;
>>>    }
>>>    @@ -1269,6 +1276,10 @@ static void
>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>        }
>>>          dsi->state |= DSIM_STATE_ENABLED;
>>> +
>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>> +    if (ret)
>>> +        return;
>>>    }
>>>      static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>        if (!(dsi->state & DSIM_STATE_ENABLED))
>>>            return -EINVAL;
>>>    -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>> -        ret = samsung_dsim_init(dsi);
>>> -        if (ret)
>>> -            return ret;
>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>> -    }
>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>
>> This triggers full controller reset and reprogramming upon first
>> command transfer, is such heavy handed reload really necessary ?
> 
> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> DSI. If this is a real issue for you, then maybe the driver could do the
> initialization conditionally, in prepare() callback in case of IMX and
> on the first transfer in case of Exynos?

That's odd , it does actually break panel support for me, without this 
double reset the panel works again. But I have to wonder, why would such 
a full reset be necessary at all , even on the exynos ?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>
> On 11/17/22 14:04, Marek Szyprowski wrote:
> > On 17.11.2022 05:58, Marek Vasut wrote:
> >> On 11/10/22 19:38, Jagan Teki wrote:
> >>> DSI host initialization handling in previous exynos dsi driver has
> >>> some pitfalls. It initializes the host during host transfer() hook
> >>> that is indeed not the desired call flow for I2C and any other DSI
> >>> configured downstream bridges.
> >>>
> >>> Host transfer() is usually triggered for downstream DSI panels or
> >>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>> and enable in order to initialize or set up the host.
> >>>
> >>> This patch is trying to handle the host init handler to satisfy all
> >>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>> flag to ensure that host init is also done on first cmd transfer, this
> >>> helps existing DSI panels work on exynos platform (form Marek
> >>> Szyprowski).
> >>>
> >>> v8, v7, v6, v5:
> >>> * none
> >>>
> >>> v4:
> >>> * update init handling to ensure host init done on first cmd transfer
> >>>
> >>> v3:
> >>> * none
> >>>
> >>> v2:
> >>> * check initialized state in samsung_dsim_init
> >>>
> >>> v1:
> >>> * keep DSI init in host transfer
> >>>
> >>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>> ---
> >>>    drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>    include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>    2 files changed, 20 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>> samsung_dsim *dsi)
> >>>        disable_irq(dsi->irq);
> >>>    }
> >>>    -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>> flag)
> >>>    {
> >>>        const struct samsung_dsim_driver_data *driver_data =
> >>> dsi->driver_data;
> >>>    +    if (dsi->state & flag)
> >>> +        return 0;
> >>> +
> >>>        samsung_dsim_reset(dsi);
> >>> -    samsung_dsim_enable_irq(dsi);
> >>> +
> >>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>> +        samsung_dsim_enable_irq(dsi);
> >>>          if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>            samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>> samsung_dsim *dsi)
> >>>        samsung_dsim_set_phy_ctrl(dsi);
> >>>        samsung_dsim_init_link(dsi);
> >>>    +    dsi->state |= flag;
> >>> +
> >>>        return 0;
> >>>    }
> >>>    @@ -1269,6 +1276,10 @@ static void
> >>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>        }
> >>>          dsi->state |= DSIM_STATE_ENABLED;
> >>> +
> >>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>> +    if (ret)
> >>> +        return;
> >>>    }
> >>>      static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>        if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>            return -EINVAL;
> >>>    -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>> -        ret = samsung_dsim_init(dsi);
> >>> -        if (ret)
> >>> -            return ret;
> >>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>> -    }
> >>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>
> >> This triggers full controller reset and reprogramming upon first
> >> command transfer, is such heavy handed reload really necessary ?
> >
> > Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> > DSI. If this is a real issue for you, then maybe the driver could do the
> > initialization conditionally, in prepare() callback in case of IMX and
> > on the first transfer in case of Exynos?
>
> That's odd , it does actually break panel support for me, without this
> double reset the panel works again. But I have to wonder, why would such
> a full reset be necessary at all , even on the exynos ?

Is it breaking samsung_dsim_reset from host_transfer? maybe checking
whether a reset is required before calling it might fix the issue.  I
agree with double initialization is odd but it seems it is required on
some panels in Exynos, I think tweaking them and adjusting the panel
code might resolve this discrepancy.

Jagan.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>
> On 11/17/22 14:04, Marek Szyprowski wrote:
> > On 17.11.2022 05:58, Marek Vasut wrote:
> >> On 11/10/22 19:38, Jagan Teki wrote:
> >>> DSI host initialization handling in previous exynos dsi driver has
> >>> some pitfalls. It initializes the host during host transfer() hook
> >>> that is indeed not the desired call flow for I2C and any other DSI
> >>> configured downstream bridges.
> >>>
> >>> Host transfer() is usually triggered for downstream DSI panels or
> >>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>> and enable in order to initialize or set up the host.
> >>>
> >>> This patch is trying to handle the host init handler to satisfy all
> >>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>> flag to ensure that host init is also done on first cmd transfer, this
> >>> helps existing DSI panels work on exynos platform (form Marek
> >>> Szyprowski).
> >>>
> >>> v8, v7, v6, v5:
> >>> * none
> >>>
> >>> v4:
> >>> * update init handling to ensure host init done on first cmd transfer
> >>>
> >>> v3:
> >>> * none
> >>>
> >>> v2:
> >>> * check initialized state in samsung_dsim_init
> >>>
> >>> v1:
> >>> * keep DSI init in host transfer
> >>>
> >>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>> ---
> >>>    drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>    include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>    2 files changed, 20 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>> samsung_dsim *dsi)
> >>>        disable_irq(dsi->irq);
> >>>    }
> >>>    -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>> flag)
> >>>    {
> >>>        const struct samsung_dsim_driver_data *driver_data =
> >>> dsi->driver_data;
> >>>    +    if (dsi->state & flag)
> >>> +        return 0;
> >>> +
> >>>        samsung_dsim_reset(dsi);
> >>> -    samsung_dsim_enable_irq(dsi);
> >>> +
> >>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>> +        samsung_dsim_enable_irq(dsi);
> >>>          if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>            samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>> samsung_dsim *dsi)
> >>>        samsung_dsim_set_phy_ctrl(dsi);
> >>>        samsung_dsim_init_link(dsi);
> >>>    +    dsi->state |= flag;
> >>> +
> >>>        return 0;
> >>>    }
> >>>    @@ -1269,6 +1276,10 @@ static void
> >>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>        }
> >>>          dsi->state |= DSIM_STATE_ENABLED;
> >>> +
> >>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>> +    if (ret)
> >>> +        return;
> >>>    }
> >>>      static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>        if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>            return -EINVAL;
> >>>    -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>> -        ret = samsung_dsim_init(dsi);
> >>> -        if (ret)
> >>> -            return ret;
> >>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>> -    }
> >>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>
> >> This triggers full controller reset and reprogramming upon first
> >> command transfer, is such heavy handed reload really necessary ?
> >
> > Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> > DSI. If this is a real issue for you, then maybe the driver could do the
> > initialization conditionally, in prepare() callback in case of IMX and
> > on the first transfer in case of Exynos?
>
> That's odd , it does actually break panel support for me, without this
> double reset the panel works again. But I have to wonder, why would such
> a full reset be necessary at all , even on the exynos ?

Is it breaking samsung_dsim_reset from host_transfer? maybe checking
whether a reset is required before calling it might fix the issue.  I
agree with double initialization is odd but it seems it is required on
some panels in Exynos, I think tweaking them and adjusting the panel
code might resolve this discrepancy.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>
> On 11/17/22 14:04, Marek Szyprowski wrote:
> > On 17.11.2022 05:58, Marek Vasut wrote:
> >> On 11/10/22 19:38, Jagan Teki wrote:
> >>> DSI host initialization handling in previous exynos dsi driver has
> >>> some pitfalls. It initializes the host during host transfer() hook
> >>> that is indeed not the desired call flow for I2C and any other DSI
> >>> configured downstream bridges.
> >>>
> >>> Host transfer() is usually triggered for downstream DSI panels or
> >>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>> and enable in order to initialize or set up the host.
> >>>
> >>> This patch is trying to handle the host init handler to satisfy all
> >>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>> flag to ensure that host init is also done on first cmd transfer, this
> >>> helps existing DSI panels work on exynos platform (form Marek
> >>> Szyprowski).
> >>>
> >>> v8, v7, v6, v5:
> >>> * none
> >>>
> >>> v4:
> >>> * update init handling to ensure host init done on first cmd transfer
> >>>
> >>> v3:
> >>> * none
> >>>
> >>> v2:
> >>> * check initialized state in samsung_dsim_init
> >>>
> >>> v1:
> >>> * keep DSI init in host transfer
> >>>
> >>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>> ---
> >>>    drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>    include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>    2 files changed, 20 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>> samsung_dsim *dsi)
> >>>        disable_irq(dsi->irq);
> >>>    }
> >>>    -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>> flag)
> >>>    {
> >>>        const struct samsung_dsim_driver_data *driver_data =
> >>> dsi->driver_data;
> >>>    +    if (dsi->state & flag)
> >>> +        return 0;
> >>> +
> >>>        samsung_dsim_reset(dsi);
> >>> -    samsung_dsim_enable_irq(dsi);
> >>> +
> >>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>> +        samsung_dsim_enable_irq(dsi);
> >>>          if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>            samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>> samsung_dsim *dsi)
> >>>        samsung_dsim_set_phy_ctrl(dsi);
> >>>        samsung_dsim_init_link(dsi);
> >>>    +    dsi->state |= flag;
> >>> +
> >>>        return 0;
> >>>    }
> >>>    @@ -1269,6 +1276,10 @@ static void
> >>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>        }
> >>>          dsi->state |= DSIM_STATE_ENABLED;
> >>> +
> >>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>> +    if (ret)
> >>> +        return;
> >>>    }
> >>>      static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>        if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>            return -EINVAL;
> >>>    -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>> -        ret = samsung_dsim_init(dsi);
> >>> -        if (ret)
> >>> -            return ret;
> >>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>> -    }
> >>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>
> >> This triggers full controller reset and reprogramming upon first
> >> command transfer, is such heavy handed reload really necessary ?
> >
> > Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> > DSI. If this is a real issue for you, then maybe the driver could do the
> > initialization conditionally, in prepare() callback in case of IMX and
> > on the first transfer in case of Exynos?
>
> That's odd , it does actually break panel support for me, without this
> double reset the panel works again. But I have to wonder, why would such
> a full reset be necessary at all , even on the exynos ?

Is it breaking samsung_dsim_reset from host_transfer? maybe checking
whether a reset is required before calling it might fix the issue.  I
agree with double initialization is odd but it seems it is required on
some panels in Exynos, I think tweaking them and adjusting the panel
code might resolve this discrepancy.

Jagan.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/23/22 21:09, Jagan Teki wrote:
> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>> configured downstream bridges.
>>>>>
>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>> and enable in order to initialize or set up the host.
>>>>>
>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>> Szyprowski).
>>>>>
>>>>> v8, v7, v6, v5:
>>>>> * none
>>>>>
>>>>> v4:
>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>
>>>>> v3:
>>>>> * none
>>>>>
>>>>> v2:
>>>>> * check initialized state in samsung_dsim_init
>>>>>
>>>>> v1:
>>>>> * keep DSI init in host transfer
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>     include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>     2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>> samsung_dsim *dsi)
>>>>>         disable_irq(dsi->irq);
>>>>>     }
>>>>>     -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>> flag)
>>>>>     {
>>>>>         const struct samsung_dsim_driver_data *driver_data =
>>>>> dsi->driver_data;
>>>>>     +    if (dsi->state & flag)
>>>>> +        return 0;
>>>>> +
>>>>>         samsung_dsim_reset(dsi);
>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>> +
>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>           if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>             samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>> samsung_dsim *dsi)
>>>>>         samsung_dsim_set_phy_ctrl(dsi);
>>>>>         samsung_dsim_init_link(dsi);
>>>>>     +    dsi->state |= flag;
>>>>> +
>>>>>         return 0;
>>>>>     }
>>>>>     @@ -1269,6 +1276,10 @@ static void
>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>         }
>>>>>           dsi->state |= DSIM_STATE_ENABLED;
>>>>> +
>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>> +    if (ret)
>>>>> +        return;
>>>>>     }
>>>>>       static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>         if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>             return -EINVAL;
>>>>>     -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>> -        ret = samsung_dsim_init(dsi);
>>>>> -        if (ret)
>>>>> -            return ret;
>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>> -    }
>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>
>>>> This triggers full controller reset and reprogramming upon first
>>>> command transfer, is such heavy handed reload really necessary ?
>>>
>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>> initialization conditionally, in prepare() callback in case of IMX and
>>> on the first transfer in case of Exynos?
>>
>> That's odd , it does actually break panel support for me, without this
>> double reset the panel works again. But I have to wonder, why would such
>> a full reset be necessary at all , even on the exynos ?
> 
> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> whether a reset is required before calling it might fix the issue.  I
> agree with double initialization is odd but it seems it is required on
> some panels in Exynos, I think tweaking them and adjusting the panel
> code might resolve this discrepancy.

Can someone provide further details on the exynos problem ?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/23/22 21:09, Jagan Teki wrote:
> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>> configured downstream bridges.
>>>>>
>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>> and enable in order to initialize or set up the host.
>>>>>
>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>> Szyprowski).
>>>>>
>>>>> v8, v7, v6, v5:
>>>>> * none
>>>>>
>>>>> v4:
>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>
>>>>> v3:
>>>>> * none
>>>>>
>>>>> v2:
>>>>> * check initialized state in samsung_dsim_init
>>>>>
>>>>> v1:
>>>>> * keep DSI init in host transfer
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>     include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>     2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>> samsung_dsim *dsi)
>>>>>         disable_irq(dsi->irq);
>>>>>     }
>>>>>     -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>> flag)
>>>>>     {
>>>>>         const struct samsung_dsim_driver_data *driver_data =
>>>>> dsi->driver_data;
>>>>>     +    if (dsi->state & flag)
>>>>> +        return 0;
>>>>> +
>>>>>         samsung_dsim_reset(dsi);
>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>> +
>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>           if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>             samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>> samsung_dsim *dsi)
>>>>>         samsung_dsim_set_phy_ctrl(dsi);
>>>>>         samsung_dsim_init_link(dsi);
>>>>>     +    dsi->state |= flag;
>>>>> +
>>>>>         return 0;
>>>>>     }
>>>>>     @@ -1269,6 +1276,10 @@ static void
>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>         }
>>>>>           dsi->state |= DSIM_STATE_ENABLED;
>>>>> +
>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>> +    if (ret)
>>>>> +        return;
>>>>>     }
>>>>>       static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>         if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>             return -EINVAL;
>>>>>     -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>> -        ret = samsung_dsim_init(dsi);
>>>>> -        if (ret)
>>>>> -            return ret;
>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>> -    }
>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>
>>>> This triggers full controller reset and reprogramming upon first
>>>> command transfer, is such heavy handed reload really necessary ?
>>>
>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>> initialization conditionally, in prepare() callback in case of IMX and
>>> on the first transfer in case of Exynos?
>>
>> That's odd , it does actually break panel support for me, without this
>> double reset the panel works again. But I have to wonder, why would such
>> a full reset be necessary at all , even on the exynos ?
> 
> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> whether a reset is required before calling it might fix the issue.  I
> agree with double initialization is odd but it seems it is required on
> some panels in Exynos, I think tweaking them and adjusting the panel
> code might resolve this discrepancy.

Can someone provide further details on the exynos problem ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 11/23/22 21:09, Jagan Teki wrote:
> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>> configured downstream bridges.
>>>>>
>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>> and enable in order to initialize or set up the host.
>>>>>
>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>> Szyprowski).
>>>>>
>>>>> v8, v7, v6, v5:
>>>>> * none
>>>>>
>>>>> v4:
>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>
>>>>> v3:
>>>>> * none
>>>>>
>>>>> v2:
>>>>> * check initialized state in samsung_dsim_init
>>>>>
>>>>> v1:
>>>>> * keep DSI init in host transfer
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>     include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>     2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>> samsung_dsim *dsi)
>>>>>         disable_irq(dsi->irq);
>>>>>     }
>>>>>     -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>> flag)
>>>>>     {
>>>>>         const struct samsung_dsim_driver_data *driver_data =
>>>>> dsi->driver_data;
>>>>>     +    if (dsi->state & flag)
>>>>> +        return 0;
>>>>> +
>>>>>         samsung_dsim_reset(dsi);
>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>> +
>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>           if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>             samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>> samsung_dsim *dsi)
>>>>>         samsung_dsim_set_phy_ctrl(dsi);
>>>>>         samsung_dsim_init_link(dsi);
>>>>>     +    dsi->state |= flag;
>>>>> +
>>>>>         return 0;
>>>>>     }
>>>>>     @@ -1269,6 +1276,10 @@ static void
>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>         }
>>>>>           dsi->state |= DSIM_STATE_ENABLED;
>>>>> +
>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>> +    if (ret)
>>>>> +        return;
>>>>>     }
>>>>>       static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>         if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>             return -EINVAL;
>>>>>     -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>> -        ret = samsung_dsim_init(dsi);
>>>>> -        if (ret)
>>>>> -            return ret;
>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>> -    }
>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>
>>>> This triggers full controller reset and reprogramming upon first
>>>> command transfer, is such heavy handed reload really necessary ?
>>>
>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>> initialization conditionally, in prepare() callback in case of IMX and
>>> on the first transfer in case of Exynos?
>>
>> That's odd , it does actually break panel support for me, without this
>> double reset the panel works again. But I have to wonder, why would such
>> a full reset be necessary at all , even on the exynos ?
> 
> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> whether a reset is required before calling it might fix the issue.  I
> agree with double initialization is odd but it seems it is required on
> some panels in Exynos, I think tweaking them and adjusting the panel
> code might resolve this discrepancy.

Can someone provide further details on the exynos problem ?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/23/22 21:09, Jagan Teki wrote:
> > On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>> configured downstream bridges.
> >>>>>
> >>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>> and enable in order to initialize or set up the host.
> >>>>>
> >>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>> Szyprowski).
> >>>>>
> >>>>> v8, v7, v6, v5:
> >>>>> * none
> >>>>>
> >>>>> v4:
> >>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>
> >>>>> v3:
> >>>>> * none
> >>>>>
> >>>>> v2:
> >>>>> * check initialized state in samsung_dsim_init
> >>>>>
> >>>>> v1:
> >>>>> * keep DSI init in host transfer
> >>>>>
> >>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>     include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>     2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>> samsung_dsim *dsi)
> >>>>>         disable_irq(dsi->irq);
> >>>>>     }
> >>>>>     -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>> flag)
> >>>>>     {
> >>>>>         const struct samsung_dsim_driver_data *driver_data =
> >>>>> dsi->driver_data;
> >>>>>     +    if (dsi->state & flag)
> >>>>> +        return 0;
> >>>>> +
> >>>>>         samsung_dsim_reset(dsi);
> >>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>> +
> >>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>           if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>             samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>> samsung_dsim *dsi)
> >>>>>         samsung_dsim_set_phy_ctrl(dsi);
> >>>>>         samsung_dsim_init_link(dsi);
> >>>>>     +    dsi->state |= flag;
> >>>>> +
> >>>>>         return 0;
> >>>>>     }
> >>>>>     @@ -1269,6 +1276,10 @@ static void
> >>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>         }
> >>>>>           dsi->state |= DSIM_STATE_ENABLED;
> >>>>> +
> >>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>> +    if (ret)
> >>>>> +        return;
> >>>>>     }
> >>>>>       static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>         if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>             return -EINVAL;
> >>>>>     -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>> -        ret = samsung_dsim_init(dsi);
> >>>>> -        if (ret)
> >>>>> -            return ret;
> >>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>> -    }
> >>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>
> >>>> This triggers full controller reset and reprogramming upon first
> >>>> command transfer, is such heavy handed reload really necessary ?
> >>>
> >>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>> initialization conditionally, in prepare() callback in case of IMX and
> >>> on the first transfer in case of Exynos?
> >>
> >> That's odd , it does actually break panel support for me, without this
> >> double reset the panel works again. But I have to wonder, why would such
> >> a full reset be necessary at all , even on the exynos ?
> >
> > Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> > whether a reset is required before calling it might fix the issue.  I
> > agree with double initialization is odd but it seems it is required on
> > some panels in Exynos, I think tweaking them and adjusting the panel
> > code might resolve this discrepancy.
>
> Can someone provide further details on the exynos problem ?

If I'm correct this sequence is required in order to work the existing
panel/bridges on exynos. Adjusting these panel/bridge codes can
possibly fix the sequence further.

Marek Szyprowski, please add if you have anything.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/23/22 21:09, Jagan Teki wrote:
> > On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>> configured downstream bridges.
> >>>>>
> >>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>> and enable in order to initialize or set up the host.
> >>>>>
> >>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>> Szyprowski).
> >>>>>
> >>>>> v8, v7, v6, v5:
> >>>>> * none
> >>>>>
> >>>>> v4:
> >>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>
> >>>>> v3:
> >>>>> * none
> >>>>>
> >>>>> v2:
> >>>>> * check initialized state in samsung_dsim_init
> >>>>>
> >>>>> v1:
> >>>>> * keep DSI init in host transfer
> >>>>>
> >>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>     include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>     2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>> samsung_dsim *dsi)
> >>>>>         disable_irq(dsi->irq);
> >>>>>     }
> >>>>>     -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>> flag)
> >>>>>     {
> >>>>>         const struct samsung_dsim_driver_data *driver_data =
> >>>>> dsi->driver_data;
> >>>>>     +    if (dsi->state & flag)
> >>>>> +        return 0;
> >>>>> +
> >>>>>         samsung_dsim_reset(dsi);
> >>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>> +
> >>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>           if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>             samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>> samsung_dsim *dsi)
> >>>>>         samsung_dsim_set_phy_ctrl(dsi);
> >>>>>         samsung_dsim_init_link(dsi);
> >>>>>     +    dsi->state |= flag;
> >>>>> +
> >>>>>         return 0;
> >>>>>     }
> >>>>>     @@ -1269,6 +1276,10 @@ static void
> >>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>         }
> >>>>>           dsi->state |= DSIM_STATE_ENABLED;
> >>>>> +
> >>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>> +    if (ret)
> >>>>> +        return;
> >>>>>     }
> >>>>>       static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>         if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>             return -EINVAL;
> >>>>>     -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>> -        ret = samsung_dsim_init(dsi);
> >>>>> -        if (ret)
> >>>>> -            return ret;
> >>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>> -    }
> >>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>
> >>>> This triggers full controller reset and reprogramming upon first
> >>>> command transfer, is such heavy handed reload really necessary ?
> >>>
> >>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>> initialization conditionally, in prepare() callback in case of IMX and
> >>> on the first transfer in case of Exynos?
> >>
> >> That's odd , it does actually break panel support for me, without this
> >> double reset the panel works again. But I have to wonder, why would such
> >> a full reset be necessary at all , even on the exynos ?
> >
> > Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> > whether a reset is required before calling it might fix the issue.  I
> > agree with double initialization is odd but it seems it is required on
> > some panels in Exynos, I think tweaking them and adjusting the panel
> > code might resolve this discrepancy.
>
> Can someone provide further details on the exynos problem ?

If I'm correct this sequence is required in order to work the existing
panel/bridges on exynos. Adjusting these panel/bridge codes can
possibly fix the sequence further.

Marek Szyprowski, please add if you have anything.

Jagan.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/23/22 21:09, Jagan Teki wrote:
> > On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>> configured downstream bridges.
> >>>>>
> >>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>> and enable in order to initialize or set up the host.
> >>>>>
> >>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>> Szyprowski).
> >>>>>
> >>>>> v8, v7, v6, v5:
> >>>>> * none
> >>>>>
> >>>>> v4:
> >>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>
> >>>>> v3:
> >>>>> * none
> >>>>>
> >>>>> v2:
> >>>>> * check initialized state in samsung_dsim_init
> >>>>>
> >>>>> v1:
> >>>>> * keep DSI init in host transfer
> >>>>>
> >>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>     include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>     2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>> samsung_dsim *dsi)
> >>>>>         disable_irq(dsi->irq);
> >>>>>     }
> >>>>>     -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>> flag)
> >>>>>     {
> >>>>>         const struct samsung_dsim_driver_data *driver_data =
> >>>>> dsi->driver_data;
> >>>>>     +    if (dsi->state & flag)
> >>>>> +        return 0;
> >>>>> +
> >>>>>         samsung_dsim_reset(dsi);
> >>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>> +
> >>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>           if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>             samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>> samsung_dsim *dsi)
> >>>>>         samsung_dsim_set_phy_ctrl(dsi);
> >>>>>         samsung_dsim_init_link(dsi);
> >>>>>     +    dsi->state |= flag;
> >>>>> +
> >>>>>         return 0;
> >>>>>     }
> >>>>>     @@ -1269,6 +1276,10 @@ static void
> >>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>         }
> >>>>>           dsi->state |= DSIM_STATE_ENABLED;
> >>>>> +
> >>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>> +    if (ret)
> >>>>> +        return;
> >>>>>     }
> >>>>>       static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>         if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>             return -EINVAL;
> >>>>>     -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>> -        ret = samsung_dsim_init(dsi);
> >>>>> -        if (ret)
> >>>>> -            return ret;
> >>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>> -    }
> >>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>
> >>>> This triggers full controller reset and reprogramming upon first
> >>>> command transfer, is such heavy handed reload really necessary ?
> >>>
> >>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>> initialization conditionally, in prepare() callback in case of IMX and
> >>> on the first transfer in case of Exynos?
> >>
> >> That's odd , it does actually break panel support for me, without this
> >> double reset the panel works again. But I have to wonder, why would such
> >> a full reset be necessary at all , even on the exynos ?
> >
> > Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> > whether a reset is required before calling it might fix the issue.  I
> > agree with double initialization is odd but it seems it is required on
> > some panels in Exynos, I think tweaking them and adjusting the panel
> > code might resolve this discrepancy.
>
> Can someone provide further details on the exynos problem ?

If I'm correct this sequence is required in order to work the existing
panel/bridges on exynos. Adjusting these panel/bridge codes can
possibly fix the sequence further.

Marek Szyprowski, please add if you have anything.

Jagan.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

Hi,

Sorry for delay, I was on a sick leave last 2 weeks.

On 28.11.2022 15:43, Jagan Teki wrote:
> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>> On 11/23/22 21:09, Jagan Teki wrote:
>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>> configured downstream bridges.
>>>>>>>
>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>
>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>> Szyprowski).
>>>>>>>
>>>>>>> v8, v7, v6, v5:
>>>>>>> * none
>>>>>>>
>>>>>>> v4:
>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>
>>>>>>> v3:
>>>>>>> * none
>>>>>>>
>>>>>>> v2:
>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>
>>>>>>> v1:
>>>>>>> * keep DSI init in host transfer
>>>>>>>
>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>>      drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>      include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>      2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>> samsung_dsim *dsi)
>>>>>>>          disable_irq(dsi->irq);
>>>>>>>      }
>>>>>>>      -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>> flag)
>>>>>>>      {
>>>>>>>          const struct samsung_dsim_driver_data *driver_data =
>>>>>>> dsi->driver_data;
>>>>>>>      +    if (dsi->state & flag)
>>>>>>> +        return 0;
>>>>>>> +
>>>>>>>          samsung_dsim_reset(dsi);
>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>> +
>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>            if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>              samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>> samsung_dsim *dsi)
>>>>>>>          samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>          samsung_dsim_init_link(dsi);
>>>>>>>      +    dsi->state |= flag;
>>>>>>> +
>>>>>>>          return 0;
>>>>>>>      }
>>>>>>>      @@ -1269,6 +1276,10 @@ static void
>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>          }
>>>>>>>            dsi->state |= DSIM_STATE_ENABLED;
>>>>>>> +
>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>> +    if (ret)
>>>>>>> +        return;
>>>>>>>      }
>>>>>>>        static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>          if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>              return -EINVAL;
>>>>>>>      -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>> -        if (ret)
>>>>>>> -            return ret;
>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>> -    }
>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>> on the first transfer in case of Exynos?
>>>> That's odd , it does actually break panel support for me, without this
>>>> double reset the panel works again. But I have to wonder, why would such
>>>> a full reset be necessary at all , even on the exynos ?
>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>> whether a reset is required before calling it might fix the issue.  I
>>> agree with double initialization is odd but it seems it is required on
>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>> code might resolve this discrepancy.
>> Can someone provide further details on the exynos problem ?
> If I'm correct this sequence is required in order to work the existing
> panel/bridges on exynos. Adjusting these panel/bridge codes can
> possibly fix the sequence further.
>
> Marek Szyprowski, please add if you have anything.


Well, frankly speaking the double initialization is not a correct 
sequence, but this is the only one that actually works on Exynos based 
boards with DSI panels after moving the initialization to bridge's 
.prepare() callback. I've already explained this and shared the results 
of my investigation in my replies to the previous versions of this 
patchset. The original Exynos DSI driver does the initialization on the 
first DSI command. This however doesn't work for Jagan with I2C 
controlled panels/bridges, so he moved the initialization to the 
.prepare() callback, what broke the Exynos case (in-short - all tested 
panels works fine only if the DSI host initialization is done AFTER 
turning the panel's power on). For more information, see this thread: 
https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/

Now, the more I think of it, the more I'm convinced that we simply 
should add a hack based on the HW type: do the initialization in 
.prepare() for non-Exynos case and before the first transfer for the 
Exynos case, as there is no way to detect the panel/next bridge type 
(I2C or DSI controlled).


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

Hi,

Sorry for delay, I was on a sick leave last 2 weeks.

On 28.11.2022 15:43, Jagan Teki wrote:
> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>> On 11/23/22 21:09, Jagan Teki wrote:
>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>> configured downstream bridges.
>>>>>>>
>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>
>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>> Szyprowski).
>>>>>>>
>>>>>>> v8, v7, v6, v5:
>>>>>>> * none
>>>>>>>
>>>>>>> v4:
>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>
>>>>>>> v3:
>>>>>>> * none
>>>>>>>
>>>>>>> v2:
>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>
>>>>>>> v1:
>>>>>>> * keep DSI init in host transfer
>>>>>>>
>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>>      drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>      include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>      2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>> samsung_dsim *dsi)
>>>>>>>          disable_irq(dsi->irq);
>>>>>>>      }
>>>>>>>      -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>> flag)
>>>>>>>      {
>>>>>>>          const struct samsung_dsim_driver_data *driver_data =
>>>>>>> dsi->driver_data;
>>>>>>>      +    if (dsi->state & flag)
>>>>>>> +        return 0;
>>>>>>> +
>>>>>>>          samsung_dsim_reset(dsi);
>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>> +
>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>            if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>              samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>> samsung_dsim *dsi)
>>>>>>>          samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>          samsung_dsim_init_link(dsi);
>>>>>>>      +    dsi->state |= flag;
>>>>>>> +
>>>>>>>          return 0;
>>>>>>>      }
>>>>>>>      @@ -1269,6 +1276,10 @@ static void
>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>          }
>>>>>>>            dsi->state |= DSIM_STATE_ENABLED;
>>>>>>> +
>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>> +    if (ret)
>>>>>>> +        return;
>>>>>>>      }
>>>>>>>        static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>          if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>              return -EINVAL;
>>>>>>>      -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>> -        if (ret)
>>>>>>> -            return ret;
>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>> -    }
>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>> on the first transfer in case of Exynos?
>>>> That's odd , it does actually break panel support for me, without this
>>>> double reset the panel works again. But I have to wonder, why would such
>>>> a full reset be necessary at all , even on the exynos ?
>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>> whether a reset is required before calling it might fix the issue.  I
>>> agree with double initialization is odd but it seems it is required on
>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>> code might resolve this discrepancy.
>> Can someone provide further details on the exynos problem ?
> If I'm correct this sequence is required in order to work the existing
> panel/bridges on exynos. Adjusting these panel/bridge codes can
> possibly fix the sequence further.
>
> Marek Szyprowski, please add if you have anything.


Well, frankly speaking the double initialization is not a correct 
sequence, but this is the only one that actually works on Exynos based 
boards with DSI panels after moving the initialization to bridge's 
.prepare() callback. I've already explained this and shared the results 
of my investigation in my replies to the previous versions of this 
patchset. The original Exynos DSI driver does the initialization on the 
first DSI command. This however doesn't work for Jagan with I2C 
controlled panels/bridges, so he moved the initialization to the 
.prepare() callback, what broke the Exynos case (in-short - all tested 
panels works fine only if the DSI host initialization is done AFTER 
turning the panel's power on). For more information, see this thread: 
https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/

Now, the more I think of it, the more I'm convinced that we simply 
should add a hack based on the HW type: do the initialization in 
.prepare() for non-Exynos case and before the first transfer for the 
Exynos case, as there is no way to detect the panel/next bridge type 
(I2C or DSI controlled).


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

Hi,

Sorry for delay, I was on a sick leave last 2 weeks.

On 28.11.2022 15:43, Jagan Teki wrote:
> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>> On 11/23/22 21:09, Jagan Teki wrote:
>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>> configured downstream bridges.
>>>>>>>
>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>
>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>> Szyprowski).
>>>>>>>
>>>>>>> v8, v7, v6, v5:
>>>>>>> * none
>>>>>>>
>>>>>>> v4:
>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>
>>>>>>> v3:
>>>>>>> * none
>>>>>>>
>>>>>>> v2:
>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>
>>>>>>> v1:
>>>>>>> * keep DSI init in host transfer
>>>>>>>
>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>>      drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>      include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>      2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>> samsung_dsim *dsi)
>>>>>>>          disable_irq(dsi->irq);
>>>>>>>      }
>>>>>>>      -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>> flag)
>>>>>>>      {
>>>>>>>          const struct samsung_dsim_driver_data *driver_data =
>>>>>>> dsi->driver_data;
>>>>>>>      +    if (dsi->state & flag)
>>>>>>> +        return 0;
>>>>>>> +
>>>>>>>          samsung_dsim_reset(dsi);
>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>> +
>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>            if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>              samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>> samsung_dsim *dsi)
>>>>>>>          samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>          samsung_dsim_init_link(dsi);
>>>>>>>      +    dsi->state |= flag;
>>>>>>> +
>>>>>>>          return 0;
>>>>>>>      }
>>>>>>>      @@ -1269,6 +1276,10 @@ static void
>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>          }
>>>>>>>            dsi->state |= DSIM_STATE_ENABLED;
>>>>>>> +
>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>> +    if (ret)
>>>>>>> +        return;
>>>>>>>      }
>>>>>>>        static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>          if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>              return -EINVAL;
>>>>>>>      -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>> -        if (ret)
>>>>>>> -            return ret;
>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>> -    }
>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>> on the first transfer in case of Exynos?
>>>> That's odd , it does actually break panel support for me, without this
>>>> double reset the panel works again. But I have to wonder, why would such
>>>> a full reset be necessary at all , even on the exynos ?
>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>> whether a reset is required before calling it might fix the issue.  I
>>> agree with double initialization is odd but it seems it is required on
>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>> code might resolve this discrepancy.
>> Can someone provide further details on the exynos problem ?
> If I'm correct this sequence is required in order to work the existing
> panel/bridges on exynos. Adjusting these panel/bridge codes can
> possibly fix the sequence further.
>
> Marek Szyprowski, please add if you have anything.


Well, frankly speaking the double initialization is not a correct 
sequence, but this is the only one that actually works on Exynos based 
boards with DSI panels after moving the initialization to bridge's 
.prepare() callback. I've already explained this and shared the results 
of my investigation in my replies to the previous versions of this 
patchset. The original Exynos DSI driver does the initialization on the 
first DSI command. This however doesn't work for Jagan with I2C 
controlled panels/bridges, so he moved the initialization to the 
.prepare() callback, what broke the Exynos case (in-short - all tested 
panels works fine only if the DSI host initialization is done AFTER 
turning the panel's power on). For more information, see this thread: 
https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/

Now, the more I think of it, the more I'm convinced that we simply 
should add a hack based on the HW type: do the initialization in 
.prepare() for non-Exynos case and before the first transfer for the 
Exynos case, as there is no way to detect the panel/next bridge type 
(I2C or DSI controlled).


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 12/2/22 11:52, Marek Szyprowski wrote:
> Hi,
> 
> Sorry for delay, I was on a sick leave last 2 weeks.
> 
> On 28.11.2022 15:43, Jagan Teki wrote:
>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>> configured downstream bridges.
>>>>>>>>
>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>
>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>> Szyprowski).
>>>>>>>>
>>>>>>>> v8, v7, v6, v5:
>>>>>>>> * none
>>>>>>>>
>>>>>>>> v4:
>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>
>>>>>>>> v3:
>>>>>>>> * none
>>>>>>>>
>>>>>>>> v2:
>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>
>>>>>>>> v1:
>>>>>>>> * keep DSI init in host transfer
>>>>>>>>
>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>> ---
>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>> samsung_dsim *dsi)
>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>       }
>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>> flag)
>>>>>>>>       {
>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>> dsi->driver_data;
>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>> +        return 0;
>>>>>>>> +
>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>> +
>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>> samsung_dsim *dsi)
>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>       +    dsi->state |= flag;
>>>>>>>> +
>>>>>>>>           return 0;
>>>>>>>>       }
>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>           }
>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>> +
>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>> +    if (ret)
>>>>>>>> +        return;
>>>>>>>>       }
>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>               return -EINVAL;
>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>> -        if (ret)
>>>>>>>> -            return ret;
>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>> -    }
>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>> on the first transfer in case of Exynos?
>>>>> That's odd , it does actually break panel support for me, without this
>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>> a full reset be necessary at all , even on the exynos ?
>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>> whether a reset is required before calling it might fix the issue.  I
>>>> agree with double initialization is odd but it seems it is required on
>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>> code might resolve this discrepancy.
>>> Can someone provide further details on the exynos problem ?
>> If I'm correct this sequence is required in order to work the existing
>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>> possibly fix the sequence further.
>>
>> Marek Szyprowski, please add if you have anything.
> 
> 
> Well, frankly speaking the double initialization is not a correct
> sequence, but this is the only one that actually works on Exynos based
> boards with DSI panels after moving the initialization to bridge's
> .prepare() callback.

Somehow, I suspect this is related to the LP11 mode handling, which 
differs for different panels, right ? I think the RPi people worked on 
fixing that.

+CC Dave

> I've already explained this and shared the results
> of my investigation in my replies to the previous versions of this
> patchset. The original Exynos DSI driver does the initialization on the
> first DSI command. This however doesn't work for Jagan with I2C
> controlled panels/bridges, so he moved the initialization to the
> .prepare() callback, what broke the Exynos case (in-short - all tested
> panels works fine only if the DSI host initialization is done AFTER
> turning the panel's power on). For more information, see this thread:
> https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/
> 
> Now, the more I think of it, the more I'm convinced that we simply
> should add a hack based on the HW type: do the initialization in
> .prepare() for non-Exynos case and before the first transfer for the
> Exynos case, as there is no way to detect the panel/next bridge type
> (I2C or DSI controlled).

Let's see what Dave has to say about this, maybe there is some further help.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 12/2/22 11:52, Marek Szyprowski wrote:
> Hi,
> 
> Sorry for delay, I was on a sick leave last 2 weeks.
> 
> On 28.11.2022 15:43, Jagan Teki wrote:
>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>> configured downstream bridges.
>>>>>>>>
>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>
>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>> Szyprowski).
>>>>>>>>
>>>>>>>> v8, v7, v6, v5:
>>>>>>>> * none
>>>>>>>>
>>>>>>>> v4:
>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>
>>>>>>>> v3:
>>>>>>>> * none
>>>>>>>>
>>>>>>>> v2:
>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>
>>>>>>>> v1:
>>>>>>>> * keep DSI init in host transfer
>>>>>>>>
>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>> ---
>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>> samsung_dsim *dsi)
>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>       }
>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>> flag)
>>>>>>>>       {
>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>> dsi->driver_data;
>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>> +        return 0;
>>>>>>>> +
>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>> +
>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>> samsung_dsim *dsi)
>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>       +    dsi->state |= flag;
>>>>>>>> +
>>>>>>>>           return 0;
>>>>>>>>       }
>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>           }
>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>> +
>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>> +    if (ret)
>>>>>>>> +        return;
>>>>>>>>       }
>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>               return -EINVAL;
>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>> -        if (ret)
>>>>>>>> -            return ret;
>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>> -    }
>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>> on the first transfer in case of Exynos?
>>>>> That's odd , it does actually break panel support for me, without this
>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>> a full reset be necessary at all , even on the exynos ?
>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>> whether a reset is required before calling it might fix the issue.  I
>>>> agree with double initialization is odd but it seems it is required on
>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>> code might resolve this discrepancy.
>>> Can someone provide further details on the exynos problem ?
>> If I'm correct this sequence is required in order to work the existing
>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>> possibly fix the sequence further.
>>
>> Marek Szyprowski, please add if you have anything.
> 
> 
> Well, frankly speaking the double initialization is not a correct
> sequence, but this is the only one that actually works on Exynos based
> boards with DSI panels after moving the initialization to bridge's
> .prepare() callback.

Somehow, I suspect this is related to the LP11 mode handling, which 
differs for different panels, right ? I think the RPi people worked on 
fixing that.

+CC Dave

> I've already explained this and shared the results
> of my investigation in my replies to the previous versions of this
> patchset. The original Exynos DSI driver does the initialization on the
> first DSI command. This however doesn't work for Jagan with I2C
> controlled panels/bridges, so he moved the initialization to the
> .prepare() callback, what broke the Exynos case (in-short - all tested
> panels works fine only if the DSI host initialization is done AFTER
> turning the panel's power on). For more information, see this thread:
> https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/
> 
> Now, the more I think of it, the more I'm convinced that we simply
> should add a hack based on the HW type: do the initialization in
> .prepare() for non-Exynos case and before the first transfer for the
> Exynos case, as there is no way to detect the panel/next bridge type
> (I2C or DSI controlled).

Let's see what Dave has to say about this, maybe there is some further help.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Vasut]

On 12/2/22 11:52, Marek Szyprowski wrote:
> Hi,
> 
> Sorry for delay, I was on a sick leave last 2 weeks.
> 
> On 28.11.2022 15:43, Jagan Teki wrote:
>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>> configured downstream bridges.
>>>>>>>>
>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>
>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>> Szyprowski).
>>>>>>>>
>>>>>>>> v8, v7, v6, v5:
>>>>>>>> * none
>>>>>>>>
>>>>>>>> v4:
>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>
>>>>>>>> v3:
>>>>>>>> * none
>>>>>>>>
>>>>>>>> v2:
>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>
>>>>>>>> v1:
>>>>>>>> * keep DSI init in host transfer
>>>>>>>>
>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>> ---
>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>> samsung_dsim *dsi)
>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>       }
>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>> flag)
>>>>>>>>       {
>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>> dsi->driver_data;
>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>> +        return 0;
>>>>>>>> +
>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>> +
>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>> samsung_dsim *dsi)
>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>       +    dsi->state |= flag;
>>>>>>>> +
>>>>>>>>           return 0;
>>>>>>>>       }
>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>           }
>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>> +
>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>> +    if (ret)
>>>>>>>> +        return;
>>>>>>>>       }
>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>               return -EINVAL;
>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>> -        if (ret)
>>>>>>>> -            return ret;
>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>> -    }
>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>> on the first transfer in case of Exynos?
>>>>> That's odd , it does actually break panel support for me, without this
>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>> a full reset be necessary at all , even on the exynos ?
>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>> whether a reset is required before calling it might fix the issue.  I
>>>> agree with double initialization is odd but it seems it is required on
>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>> code might resolve this discrepancy.
>>> Can someone provide further details on the exynos problem ?
>> If I'm correct this sequence is required in order to work the existing
>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>> possibly fix the sequence further.
>>
>> Marek Szyprowski, please add if you have anything.
> 
> 
> Well, frankly speaking the double initialization is not a correct
> sequence, but this is the only one that actually works on Exynos based
> boards with DSI panels after moving the initialization to bridge's
> .prepare() callback.

Somehow, I suspect this is related to the LP11 mode handling, which 
differs for different panels, right ? I think the RPi people worked on 
fixing that.

+CC Dave

> I've already explained this and shared the results
> of my investigation in my replies to the previous versions of this
> patchset. The original Exynos DSI driver does the initialization on the
> first DSI command. This however doesn't work for Jagan with I2C
> controlled panels/bridges, so he moved the initialization to the
> .prepare() callback, what broke the Exynos case (in-short - all tested
> panels works fine only if the DSI host initialization is done AFTER
> turning the panel's power on). For more information, see this thread:
> https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/
> 
> Now, the more I think of it, the more I'm convinced that we simply
> should add a hack based on the HW type: do the initialization in
> .prepare() for non-Exynos case and before the first transfer for the
> Exynos case, as there is no way to detect the panel/next bridge type
> (I2C or DSI controlled).

Let's see what Dave has to say about this, maybe there is some further help.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Dave Stevenson]

Hi Marek

On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>
> On 12/2/22 11:52, Marek Szyprowski wrote:
> > Hi,
> >
> > Sorry for delay, I was on a sick leave last 2 weeks.
> >
> > On 28.11.2022 15:43, Jagan Teki wrote:
> >> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>> configured downstream bridges.
> >>>>>>>>
> >>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>
> >>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>> Szyprowski).
> >>>>>>>>
> >>>>>>>> v8, v7, v6, v5:
> >>>>>>>> * none
> >>>>>>>>
> >>>>>>>> v4:
> >>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>
> >>>>>>>> v3:
> >>>>>>>> * none
> >>>>>>>>
> >>>>>>>> v2:
> >>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>
> >>>>>>>> v1:
> >>>>>>>> * keep DSI init in host transfer
> >>>>>>>>
> >>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>> ---
> >>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>> samsung_dsim *dsi)
> >>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>       }
> >>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>> flag)
> >>>>>>>>       {
> >>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>> dsi->driver_data;
> >>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>> +        return 0;
> >>>>>>>> +
> >>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>> +
> >>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>> samsung_dsim *dsi)
> >>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>       +    dsi->state |= flag;
> >>>>>>>> +
> >>>>>>>>           return 0;
> >>>>>>>>       }
> >>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>           }
> >>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>> +
> >>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>> +    if (ret)
> >>>>>>>> +        return;
> >>>>>>>>       }
> >>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>               return -EINVAL;
> >>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>> -        if (ret)
> >>>>>>>> -            return ret;
> >>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>> -    }
> >>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>> on the first transfer in case of Exynos?
> >>>>> That's odd , it does actually break panel support for me, without this
> >>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>> a full reset be necessary at all , even on the exynos ?
> >>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>> whether a reset is required before calling it might fix the issue.  I
> >>>> agree with double initialization is odd but it seems it is required on
> >>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>> code might resolve this discrepancy.
> >>> Can someone provide further details on the exynos problem ?
> >> If I'm correct this sequence is required in order to work the existing
> >> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >> possibly fix the sequence further.
> >>
> >> Marek Szyprowski, please add if you have anything.
> >
> >
> > Well, frankly speaking the double initialization is not a correct
> > sequence, but this is the only one that actually works on Exynos based
> > boards with DSI panels after moving the initialization to bridge's
> > .prepare() callback.
>
> Somehow, I suspect this is related to the LP11 mode handling, which
> differs for different panels, right ? I think the RPi people worked on
> fixing that.
>
> +CC Dave

Yes. I've just sent out a v3 of that patch set.

Hopefully setting the pre_enable_prev_first flag on your peripheral's
drm_bridge, or prepare_prev_first if a drm_panel, will result in a
more sensible initialisation order for your panel.

Note that host_transfer should ensure that the host is initialised, as
it is valid to call it with the host in any state. If it has to
initialise, then it should deinitialise once the transfer has
completed.

Dave

> > I've already explained this and shared the results
> > of my investigation in my replies to the previous versions of this
> > patchset. The original Exynos DSI driver does the initialization on the
> > first DSI command. This however doesn't work for Jagan with I2C
> > controlled panels/bridges, so he moved the initialization to the
> > .prepare() callback, what broke the Exynos case (in-short - all tested
> > panels works fine only if the DSI host initialization is done AFTER
> > turning the panel's power on). For more information, see this thread:
> > https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/
> >
> > Now, the more I think of it, the more I'm convinced that we simply
> > should add a hack based on the HW type: do the initialization in
> > .prepare() for non-Exynos case and before the first transfer for the
> > Exynos case, as there is no way to detect the panel/next bridge type
> > (I2C or DSI controlled).
>
> Let's see what Dave has to say about this, maybe there is some further help.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Dave Stevenson]

Hi Marek

On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>
> On 12/2/22 11:52, Marek Szyprowski wrote:
> > Hi,
> >
> > Sorry for delay, I was on a sick leave last 2 weeks.
> >
> > On 28.11.2022 15:43, Jagan Teki wrote:
> >> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>> configured downstream bridges.
> >>>>>>>>
> >>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>
> >>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>> Szyprowski).
> >>>>>>>>
> >>>>>>>> v8, v7, v6, v5:
> >>>>>>>> * none
> >>>>>>>>
> >>>>>>>> v4:
> >>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>
> >>>>>>>> v3:
> >>>>>>>> * none
> >>>>>>>>
> >>>>>>>> v2:
> >>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>
> >>>>>>>> v1:
> >>>>>>>> * keep DSI init in host transfer
> >>>>>>>>
> >>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>> ---
> >>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>> samsung_dsim *dsi)
> >>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>       }
> >>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>> flag)
> >>>>>>>>       {
> >>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>> dsi->driver_data;
> >>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>> +        return 0;
> >>>>>>>> +
> >>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>> +
> >>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>> samsung_dsim *dsi)
> >>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>       +    dsi->state |= flag;
> >>>>>>>> +
> >>>>>>>>           return 0;
> >>>>>>>>       }
> >>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>           }
> >>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>> +
> >>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>> +    if (ret)
> >>>>>>>> +        return;
> >>>>>>>>       }
> >>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>               return -EINVAL;
> >>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>> -        if (ret)
> >>>>>>>> -            return ret;
> >>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>> -    }
> >>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>> on the first transfer in case of Exynos?
> >>>>> That's odd , it does actually break panel support for me, without this
> >>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>> a full reset be necessary at all , even on the exynos ?
> >>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>> whether a reset is required before calling it might fix the issue.  I
> >>>> agree with double initialization is odd but it seems it is required on
> >>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>> code might resolve this discrepancy.
> >>> Can someone provide further details on the exynos problem ?
> >> If I'm correct this sequence is required in order to work the existing
> >> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >> possibly fix the sequence further.
> >>
> >> Marek Szyprowski, please add if you have anything.
> >
> >
> > Well, frankly speaking the double initialization is not a correct
> > sequence, but this is the only one that actually works on Exynos based
> > boards with DSI panels after moving the initialization to bridge's
> > .prepare() callback.
>
> Somehow, I suspect this is related to the LP11 mode handling, which
> differs for different panels, right ? I think the RPi people worked on
> fixing that.
>
> +CC Dave

Yes. I've just sent out a v3 of that patch set.

Hopefully setting the pre_enable_prev_first flag on your peripheral's
drm_bridge, or prepare_prev_first if a drm_panel, will result in a
more sensible initialisation order for your panel.

Note that host_transfer should ensure that the host is initialised, as
it is valid to call it with the host in any state. If it has to
initialise, then it should deinitialise once the transfer has
completed.

Dave

> > I've already explained this and shared the results
> > of my investigation in my replies to the previous versions of this
> > patchset. The original Exynos DSI driver does the initialization on the
> > first DSI command. This however doesn't work for Jagan with I2C
> > controlled panels/bridges, so he moved the initialization to the
> > .prepare() callback, what broke the Exynos case (in-short - all tested
> > panels works fine only if the DSI host initialization is done AFTER
> > turning the panel's power on). For more information, see this thread:
> > https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/
> >
> > Now, the more I think of it, the more I'm convinced that we simply
> > should add a hack based on the HW type: do the initialization in
> > .prepare() for non-Exynos case and before the first transfer for the
> > Exynos case, as there is no way to detect the panel/next bridge type
> > (I2C or DSI controlled).
>
> Let's see what Dave has to say about this, maybe there is some further help.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Dave Stevenson]

Hi Marek

On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>
> On 12/2/22 11:52, Marek Szyprowski wrote:
> > Hi,
> >
> > Sorry for delay, I was on a sick leave last 2 weeks.
> >
> > On 28.11.2022 15:43, Jagan Teki wrote:
> >> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>> configured downstream bridges.
> >>>>>>>>
> >>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>
> >>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>> Szyprowski).
> >>>>>>>>
> >>>>>>>> v8, v7, v6, v5:
> >>>>>>>> * none
> >>>>>>>>
> >>>>>>>> v4:
> >>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>
> >>>>>>>> v3:
> >>>>>>>> * none
> >>>>>>>>
> >>>>>>>> v2:
> >>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>
> >>>>>>>> v1:
> >>>>>>>> * keep DSI init in host transfer
> >>>>>>>>
> >>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>> ---
> >>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>> samsung_dsim *dsi)
> >>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>       }
> >>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>> flag)
> >>>>>>>>       {
> >>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>> dsi->driver_data;
> >>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>> +        return 0;
> >>>>>>>> +
> >>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>> +
> >>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>> samsung_dsim *dsi)
> >>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>       +    dsi->state |= flag;
> >>>>>>>> +
> >>>>>>>>           return 0;
> >>>>>>>>       }
> >>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>           }
> >>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>> +
> >>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>> +    if (ret)
> >>>>>>>> +        return;
> >>>>>>>>       }
> >>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>               return -EINVAL;
> >>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>> -        if (ret)
> >>>>>>>> -            return ret;
> >>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>> -    }
> >>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>> on the first transfer in case of Exynos?
> >>>>> That's odd , it does actually break panel support for me, without this
> >>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>> a full reset be necessary at all , even on the exynos ?
> >>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>> whether a reset is required before calling it might fix the issue.  I
> >>>> agree with double initialization is odd but it seems it is required on
> >>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>> code might resolve this discrepancy.
> >>> Can someone provide further details on the exynos problem ?
> >> If I'm correct this sequence is required in order to work the existing
> >> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >> possibly fix the sequence further.
> >>
> >> Marek Szyprowski, please add if you have anything.
> >
> >
> > Well, frankly speaking the double initialization is not a correct
> > sequence, but this is the only one that actually works on Exynos based
> > boards with DSI panels after moving the initialization to bridge's
> > .prepare() callback.
>
> Somehow, I suspect this is related to the LP11 mode handling, which
> differs for different panels, right ? I think the RPi people worked on
> fixing that.
>
> +CC Dave

Yes. I've just sent out a v3 of that patch set.

Hopefully setting the pre_enable_prev_first flag on your peripheral's
drm_bridge, or prepare_prev_first if a drm_panel, will result in a
more sensible initialisation order for your panel.

Note that host_transfer should ensure that the host is initialised, as
it is valid to call it with the host in any state. If it has to
initialise, then it should deinitialise once the transfer has
completed.

Dave

> > I've already explained this and shared the results
> > of my investigation in my replies to the previous versions of this
> > patchset. The original Exynos DSI driver does the initialization on the
> > first DSI command. This however doesn't work for Jagan with I2C
> > controlled panels/bridges, so he moved the initialization to the
> > .prepare() callback, what broke the Exynos case (in-short - all tested
> > panels works fine only if the DSI host initialization is done AFTER
> > turning the panel's power on). For more information, see this thread:
> > https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5f5a@samsung.com/
> >
> > Now, the more I think of it, the more I'm convinced that we simply
> > should add a hack based on the HW type: do the initialization in
> > .prepare() for non-Exynos case and before the first transfer for the
> > Exynos case, as there is no way to detect the panel/next bridge type
> > (I2C or DSI controlled).
>
> Let's see what Dave has to say about this, maybe there is some further help.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

On 02.12.22 15:55, Dave Stevenson wrote:
> Hi Marek
> 
> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>> Hi,
>>>
>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>
>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>
>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>
>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>> Szyprowski).
>>>>>>>>>>
>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>> * none
>>>>>>>>>>
>>>>>>>>>> v4:
>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>
>>>>>>>>>> v3:
>>>>>>>>>> * none
>>>>>>>>>>
>>>>>>>>>> v2:
>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>
>>>>>>>>>> v1:
>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>> ---
>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>       }
>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>> flag)
>>>>>>>>>>       {
>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>> +        return 0;
>>>>>>>>>> +
>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>> +
>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>> +
>>>>>>>>>>           return 0;
>>>>>>>>>>       }
>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>           }
>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>> +
>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>> +    if (ret)
>>>>>>>>>> +        return;
>>>>>>>>>>       }
>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>> -        if (ret)
>>>>>>>>>> -            return ret;
>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>> -    }
>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>> on the first transfer in case of Exynos?
>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>> code might resolve this discrepancy.
>>>>> Can someone provide further details on the exynos problem ?
>>>> If I'm correct this sequence is required in order to work the existing
>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>> possibly fix the sequence further.
>>>>
>>>> Marek Szyprowski, please add if you have anything.
>>>
>>>
>>> Well, frankly speaking the double initialization is not a correct
>>> sequence, but this is the only one that actually works on Exynos based
>>> boards with DSI panels after moving the initialization to bridge's
>>> .prepare() callback.
>>
>> Somehow, I suspect this is related to the LP11 mode handling, which
>> differs for different panels, right ? I think the RPi people worked on
>> fixing that.
>>
>> +CC Dave
> 
> Yes. I've just sent out a v3 of that patch set.
> 
> Hopefully setting the pre_enable_prev_first flag on your peripheral's
> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> more sensible initialisation order for your panel.
> 
> Note that host_transfer should ensure that the host is initialised, as
> it is valid to call it with the host in any state. If it has to
> initialise, then it should deinitialise once the transfer has
> completed.
> 
> Dave
> 
>>> I've already explained this and shared the results
>>> of my investigation in my replies to the previous versions of this
>>> patchset. The original Exynos DSI driver does the initialization on the
>>> first DSI command. This however doesn't work for Jagan with I2C
>>> controlled panels/bridges, so he moved the initialization to the
>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>> panels works fine only if the DSI host initialization is done AFTER
>>> turning the panel's power on). For more information, see this thread:
>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cc770caab3f274d9b50d108dad4753e1f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638055897263056680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1YV551YUhXQAjE4Cg0nAtMdMksWzMtscH49O83iKHRo%3D&amp;reserved=0
>>>
>>> Now, the more I think of it, the more I'm convinced that we simply
>>> should add a hack based on the HW type: do the initialization in
>>> .prepare() for non-Exynos case and before the first transfer for the
>>> Exynos case, as there is no way to detect the panel/next bridge type
>>> (I2C or DSI controlled).
>>
>> Let's see what Dave has to say about this, maybe there is some further help.

Could we agree on adding the HW type based hack Marek S. proposed as a
quick fix?

This patchset was tested on Exynos so it's likely to not break any
existing setups. And for i.MX8, this is a new driver so there's not
really a requirement to have all setups working/supported from the
beginning.

Also having one or two hacks (marked with FIXME) in the code doesn't
hurt. As we can see there are drafts to fix them in conjunction with
changes in the DRM framework.

This has been pending for months and in my opinion if there's a chance
to get this into v6.2-rc1 we should take it.

If everyone agrees, Jagan, can you post a v9 which does the host
initialization in .prepare() for i.MX and on first transfer for Exynos?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

On 02.12.22 15:55, Dave Stevenson wrote:
> Hi Marek
> 
> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>> Hi,
>>>
>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>
>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>
>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>
>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>> Szyprowski).
>>>>>>>>>>
>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>> * none
>>>>>>>>>>
>>>>>>>>>> v4:
>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>
>>>>>>>>>> v3:
>>>>>>>>>> * none
>>>>>>>>>>
>>>>>>>>>> v2:
>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>
>>>>>>>>>> v1:
>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>> ---
>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>       }
>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>> flag)
>>>>>>>>>>       {
>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>> +        return 0;
>>>>>>>>>> +
>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>> +
>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>> +
>>>>>>>>>>           return 0;
>>>>>>>>>>       }
>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>           }
>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>> +
>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>> +    if (ret)
>>>>>>>>>> +        return;
>>>>>>>>>>       }
>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>> -        if (ret)
>>>>>>>>>> -            return ret;
>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>> -    }
>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>> on the first transfer in case of Exynos?
>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>> code might resolve this discrepancy.
>>>>> Can someone provide further details on the exynos problem ?
>>>> If I'm correct this sequence is required in order to work the existing
>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>> possibly fix the sequence further.
>>>>
>>>> Marek Szyprowski, please add if you have anything.
>>>
>>>
>>> Well, frankly speaking the double initialization is not a correct
>>> sequence, but this is the only one that actually works on Exynos based
>>> boards with DSI panels after moving the initialization to bridge's
>>> .prepare() callback.
>>
>> Somehow, I suspect this is related to the LP11 mode handling, which
>> differs for different panels, right ? I think the RPi people worked on
>> fixing that.
>>
>> +CC Dave
> 
> Yes. I've just sent out a v3 of that patch set.
> 
> Hopefully setting the pre_enable_prev_first flag on your peripheral's
> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> more sensible initialisation order for your panel.
> 
> Note that host_transfer should ensure that the host is initialised, as
> it is valid to call it with the host in any state. If it has to
> initialise, then it should deinitialise once the transfer has
> completed.
> 
> Dave
> 
>>> I've already explained this and shared the results
>>> of my investigation in my replies to the previous versions of this
>>> patchset. The original Exynos DSI driver does the initialization on the
>>> first DSI command. This however doesn't work for Jagan with I2C
>>> controlled panels/bridges, so he moved the initialization to the
>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>> panels works fine only if the DSI host initialization is done AFTER
>>> turning the panel's power on). For more information, see this thread:
>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cc770caab3f274d9b50d108dad4753e1f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638055897263056680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1YV551YUhXQAjE4Cg0nAtMdMksWzMtscH49O83iKHRo%3D&amp;reserved=0
>>>
>>> Now, the more I think of it, the more I'm convinced that we simply
>>> should add a hack based on the HW type: do the initialization in
>>> .prepare() for non-Exynos case and before the first transfer for the
>>> Exynos case, as there is no way to detect the panel/next bridge type
>>> (I2C or DSI controlled).
>>
>> Let's see what Dave has to say about this, maybe there is some further help.

Could we agree on adding the HW type based hack Marek S. proposed as a
quick fix?

This patchset was tested on Exynos so it's likely to not break any
existing setups. And for i.MX8, this is a new driver so there's not
really a requirement to have all setups working/supported from the
beginning.

Also having one or two hacks (marked with FIXME) in the code doesn't
hurt. As we can see there are drafts to fix them in conjunction with
changes in the DRM framework.

This has been pending for months and in my opinion if there's a chance
to get this into v6.2-rc1 we should take it.

If everyone agrees, Jagan, can you post a v9 which does the host
initialization in .prepare() for i.MX and on first transfer for Exynos?


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

On 02.12.22 15:55, Dave Stevenson wrote:
> Hi Marek
> 
> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>> Hi,
>>>
>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>
>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>
>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>
>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>> Szyprowski).
>>>>>>>>>>
>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>> * none
>>>>>>>>>>
>>>>>>>>>> v4:
>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>
>>>>>>>>>> v3:
>>>>>>>>>> * none
>>>>>>>>>>
>>>>>>>>>> v2:
>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>
>>>>>>>>>> v1:
>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>> ---
>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>       }
>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>> flag)
>>>>>>>>>>       {
>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>> +        return 0;
>>>>>>>>>> +
>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>> +
>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>> +
>>>>>>>>>>           return 0;
>>>>>>>>>>       }
>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>           }
>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>> +
>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>> +    if (ret)
>>>>>>>>>> +        return;
>>>>>>>>>>       }
>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>> -        if (ret)
>>>>>>>>>> -            return ret;
>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>> -    }
>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>> on the first transfer in case of Exynos?
>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>> code might resolve this discrepancy.
>>>>> Can someone provide further details on the exynos problem ?
>>>> If I'm correct this sequence is required in order to work the existing
>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>> possibly fix the sequence further.
>>>>
>>>> Marek Szyprowski, please add if you have anything.
>>>
>>>
>>> Well, frankly speaking the double initialization is not a correct
>>> sequence, but this is the only one that actually works on Exynos based
>>> boards with DSI panels after moving the initialization to bridge's
>>> .prepare() callback.
>>
>> Somehow, I suspect this is related to the LP11 mode handling, which
>> differs for different panels, right ? I think the RPi people worked on
>> fixing that.
>>
>> +CC Dave
> 
> Yes. I've just sent out a v3 of that patch set.
> 
> Hopefully setting the pre_enable_prev_first flag on your peripheral's
> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> more sensible initialisation order for your panel.
> 
> Note that host_transfer should ensure that the host is initialised, as
> it is valid to call it with the host in any state. If it has to
> initialise, then it should deinitialise once the transfer has
> completed.
> 
> Dave
> 
>>> I've already explained this and shared the results
>>> of my investigation in my replies to the previous versions of this
>>> patchset. The original Exynos DSI driver does the initialization on the
>>> first DSI command. This however doesn't work for Jagan with I2C
>>> controlled panels/bridges, so he moved the initialization to the
>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>> panels works fine only if the DSI host initialization is done AFTER
>>> turning the panel's power on). For more information, see this thread:
>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cc770caab3f274d9b50d108dad4753e1f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638055897263056680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1YV551YUhXQAjE4Cg0nAtMdMksWzMtscH49O83iKHRo%3D&amp;reserved=0
>>>
>>> Now, the more I think of it, the more I'm convinced that we simply
>>> should add a hack based on the HW type: do the initialization in
>>> .prepare() for non-Exynos case and before the first transfer for the
>>> Exynos case, as there is no way to detect the panel/next bridge type
>>> (I2C or DSI controlled).
>>
>> Let's see what Dave has to say about this, maybe there is some further help.

Could we agree on adding the HW type based hack Marek S. proposed as a
quick fix?

This patchset was tested on Exynos so it's likely to not break any
existing setups. And for i.MX8, this is a new driver so there's not
really a requirement to have all setups working/supported from the
beginning.

Also having one or two hacks (marked with FIXME) in the code doesn't
hurt. As we can see there are drafts to fix them in conjunction with
changes in the DRM framework.

This has been pending for months and in my opinion if there's a chance
to get this into v6.2-rc1 we should take it.

If everyone agrees, Jagan, can you post a v9 which does the host
initialization in .prepare() for i.MX and on first transfer for Exynos?

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Dave Stevenson]

Hi Frieder

On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 02.12.22 15:55, Dave Stevenson wrote:
> > Hi Marek
> >
> > On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>> Hi,
> >>>
> >>> Sorry for delay, I was on a sick leave last 2 weeks.
> >>>
> >>> On 28.11.2022 15:43, Jagan Teki wrote:
> >>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>>>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>>>> configured downstream bridges.
> >>>>>>>>>>
> >>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>>>
> >>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>>>> Szyprowski).
> >>>>>>>>>>
> >>>>>>>>>> v8, v7, v6, v5:
> >>>>>>>>>> * none
> >>>>>>>>>>
> >>>>>>>>>> v4:
> >>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>>>
> >>>>>>>>>> v3:
> >>>>>>>>>> * none
> >>>>>>>>>>
> >>>>>>>>>> v2:
> >>>>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>>>
> >>>>>>>>>> v1:
> >>>>>>>>>> * keep DSI init in host transfer
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>>> ---
> >>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>>>       }
> >>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>>>> flag)
> >>>>>>>>>>       {
> >>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>>>> dsi->driver_data;
> >>>>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>>>> +        return 0;
> >>>>>>>>>> +
> >>>>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>>>> +
> >>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>>>       +    dsi->state |= flag;
> >>>>>>>>>> +
> >>>>>>>>>>           return 0;
> >>>>>>>>>>       }
> >>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>           }
> >>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>>>> +
> >>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>>>> +    if (ret)
> >>>>>>>>>> +        return;
> >>>>>>>>>>       }
> >>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>>>               return -EINVAL;
> >>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>>>> -        if (ret)
> >>>>>>>>>> -            return ret;
> >>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>>>> -    }
> >>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>>>> on the first transfer in case of Exynos?
> >>>>>>> That's odd , it does actually break panel support for me, without this
> >>>>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>>>> a full reset be necessary at all , even on the exynos ?
> >>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>>>> whether a reset is required before calling it might fix the issue.  I
> >>>>>> agree with double initialization is odd but it seems it is required on
> >>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>>>> code might resolve this discrepancy.
> >>>>> Can someone provide further details on the exynos problem ?
> >>>> If I'm correct this sequence is required in order to work the existing
> >>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >>>> possibly fix the sequence further.
> >>>>
> >>>> Marek Szyprowski, please add if you have anything.
> >>>
> >>>
> >>> Well, frankly speaking the double initialization is not a correct
> >>> sequence, but this is the only one that actually works on Exynos based
> >>> boards with DSI panels after moving the initialization to bridge's
> >>> .prepare() callback.
> >>
> >> Somehow, I suspect this is related to the LP11 mode handling, which
> >> differs for different panels, right ? I think the RPi people worked on
> >> fixing that.
> >>
> >> +CC Dave
> >
> > Yes. I've just sent out a v3 of that patch set.
> >
> > Hopefully setting the pre_enable_prev_first flag on your peripheral's
> > drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> > more sensible initialisation order for your panel.
> >
> > Note that host_transfer should ensure that the host is initialised, as
> > it is valid to call it with the host in any state. If it has to
> > initialise, then it should deinitialise once the transfer has
> > completed.
> >
> > Dave
> >
> >>> I've already explained this and shared the results
> >>> of my investigation in my replies to the previous versions of this
> >>> patchset. The original Exynos DSI driver does the initialization on the
> >>> first DSI command. This however doesn't work for Jagan with I2C
> >>> controlled panels/bridges, so he moved the initialization to the
> >>> .prepare() callback, what broke the Exynos case (in-short - all tested
> >>> panels works fine only if the DSI host initialization is done AFTER
> >>> turning the panel's power on). For more information, see this thread:
> >>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cc770caab3f274d9b50d108dad4753e1f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638055897263056680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1YV551YUhXQAjE4Cg0nAtMdMksWzMtscH49O83iKHRo%3D&amp;reserved=0
> >>>
> >>> Now, the more I think of it, the more I'm convinced that we simply
> >>> should add a hack based on the HW type: do the initialization in
> >>> .prepare() for non-Exynos case and before the first transfer for the
> >>> Exynos case, as there is no way to detect the panel/next bridge type
> >>> (I2C or DSI controlled).
> >>
> >> Let's see what Dave has to say about this, maybe there is some further help.
>
> Could we agree on adding the HW type based hack Marek S. proposed as a
> quick fix?
>
> This patchset was tested on Exynos so it's likely to not break any
> existing setups. And for i.MX8, this is a new driver so there's not
> really a requirement to have all setups working/supported from the
> beginning.
>
> Also having one or two hacks (marked with FIXME) in the code doesn't
> hurt. As we can see there are drafts to fix them in conjunction with
> changes in the DRM framework.
>
> This has been pending for months and in my opinion if there's a chance
> to get this into v6.2-rc1 we should take it.

My patchset was sent in March with no one seeming to care enough to review it.

If the situation is that your devices fall into the same camp as those
for vc4 (the host needs to be initialised before the peripheral), at
least verifying that would be useful before rushing into a hack.

Your other comment references using a TI SN65DSI84. I know for certain
that falls into the category of needing the DSI bus initialised before
it is brought out of reset.

  Dave

> If everyone agrees, Jagan, can you post a v9 which does the host
> initialization in .prepare() for i.MX and on first transfer for Exynos?
>

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Dave Stevenson]

Hi Frieder

On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 02.12.22 15:55, Dave Stevenson wrote:
> > Hi Marek
> >
> > On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>> Hi,
> >>>
> >>> Sorry for delay, I was on a sick leave last 2 weeks.
> >>>
> >>> On 28.11.2022 15:43, Jagan Teki wrote:
> >>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>>>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>>>> configured downstream bridges.
> >>>>>>>>>>
> >>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>>>
> >>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>>>> Szyprowski).
> >>>>>>>>>>
> >>>>>>>>>> v8, v7, v6, v5:
> >>>>>>>>>> * none
> >>>>>>>>>>
> >>>>>>>>>> v4:
> >>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>>>
> >>>>>>>>>> v3:
> >>>>>>>>>> * none
> >>>>>>>>>>
> >>>>>>>>>> v2:
> >>>>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>>>
> >>>>>>>>>> v1:
> >>>>>>>>>> * keep DSI init in host transfer
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>>> ---
> >>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>>>       }
> >>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>>>> flag)
> >>>>>>>>>>       {
> >>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>>>> dsi->driver_data;
> >>>>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>>>> +        return 0;
> >>>>>>>>>> +
> >>>>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>>>> +
> >>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>>>       +    dsi->state |= flag;
> >>>>>>>>>> +
> >>>>>>>>>>           return 0;
> >>>>>>>>>>       }
> >>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>           }
> >>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>>>> +
> >>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>>>> +    if (ret)
> >>>>>>>>>> +        return;
> >>>>>>>>>>       }
> >>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>>>               return -EINVAL;
> >>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>>>> -        if (ret)
> >>>>>>>>>> -            return ret;
> >>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>>>> -    }
> >>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>>>> on the first transfer in case of Exynos?
> >>>>>>> That's odd , it does actually break panel support for me, without this
> >>>>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>>>> a full reset be necessary at all , even on the exynos ?
> >>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>>>> whether a reset is required before calling it might fix the issue.  I
> >>>>>> agree with double initialization is odd but it seems it is required on
> >>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>>>> code might resolve this discrepancy.
> >>>>> Can someone provide further details on the exynos problem ?
> >>>> If I'm correct this sequence is required in order to work the existing
> >>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >>>> possibly fix the sequence further.
> >>>>
> >>>> Marek Szyprowski, please add if you have anything.
> >>>
> >>>
> >>> Well, frankly speaking the double initialization is not a correct
> >>> sequence, but this is the only one that actually works on Exynos based
> >>> boards with DSI panels after moving the initialization to bridge's
> >>> .prepare() callback.
> >>
> >> Somehow, I suspect this is related to the LP11 mode handling, which
> >> differs for different panels, right ? I think the RPi people worked on
> >> fixing that.
> >>
> >> +CC Dave
> >
> > Yes. I've just sent out a v3 of that patch set.
> >
> > Hopefully setting the pre_enable_prev_first flag on your peripheral's
> > drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> > more sensible initialisation order for your panel.
> >
> > Note that host_transfer should ensure that the host is initialised, as
> > it is valid to call it with the host in any state. If it has to
> > initialise, then it should deinitialise once the transfer has
> > completed.
> >
> > Dave
> >
> >>> I've already explained this and shared the results
> >>> of my investigation in my replies to the previous versions of this
> >>> patchset. The original Exynos DSI driver does the initialization on the
> >>> first DSI command. This however doesn't work for Jagan with I2C
> >>> controlled panels/bridges, so he moved the initialization to the
> >>> .prepare() callback, what broke the Exynos case (in-short - all tested
> >>> panels works fine only if the DSI host initialization is done AFTER
> >>> turning the panel's power on). For more information, see this thread:
> >>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cc770caab3f274d9b50d108dad4753e1f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638055897263056680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1YV551YUhXQAjE4Cg0nAtMdMksWzMtscH49O83iKHRo%3D&amp;reserved=0
> >>>
> >>> Now, the more I think of it, the more I'm convinced that we simply
> >>> should add a hack based on the HW type: do the initialization in
> >>> .prepare() for non-Exynos case and before the first transfer for the
> >>> Exynos case, as there is no way to detect the panel/next bridge type
> >>> (I2C or DSI controlled).
> >>
> >> Let's see what Dave has to say about this, maybe there is some further help.
>
> Could we agree on adding the HW type based hack Marek S. proposed as a
> quick fix?
>
> This patchset was tested on Exynos so it's likely to not break any
> existing setups. And for i.MX8, this is a new driver so there's not
> really a requirement to have all setups working/supported from the
> beginning.
>
> Also having one or two hacks (marked with FIXME) in the code doesn't
> hurt. As we can see there are drafts to fix them in conjunction with
> changes in the DRM framework.
>
> This has been pending for months and in my opinion if there's a chance
> to get this into v6.2-rc1 we should take it.

My patchset was sent in March with no one seeming to care enough to review it.

If the situation is that your devices fall into the same camp as those
for vc4 (the host needs to be initialised before the peripheral), at
least verifying that would be useful before rushing into a hack.

Your other comment references using a TI SN65DSI84. I know for certain
that falls into the category of needing the DSI bus initialised before
it is brought out of reset.

  Dave

> If everyone agrees, Jagan, can you post a v9 which does the host
> initialization in .prepare() for i.MX and on first transfer for Exynos?
>

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Dave Stevenson]

Hi Frieder

On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 02.12.22 15:55, Dave Stevenson wrote:
> > Hi Marek
> >
> > On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>> Hi,
> >>>
> >>> Sorry for delay, I was on a sick leave last 2 weeks.
> >>>
> >>> On 28.11.2022 15:43, Jagan Teki wrote:
> >>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>>>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>>>> configured downstream bridges.
> >>>>>>>>>>
> >>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>>>
> >>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>>>> Szyprowski).
> >>>>>>>>>>
> >>>>>>>>>> v8, v7, v6, v5:
> >>>>>>>>>> * none
> >>>>>>>>>>
> >>>>>>>>>> v4:
> >>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>>>
> >>>>>>>>>> v3:
> >>>>>>>>>> * none
> >>>>>>>>>>
> >>>>>>>>>> v2:
> >>>>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>>>
> >>>>>>>>>> v1:
> >>>>>>>>>> * keep DSI init in host transfer
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>>> ---
> >>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>>>       }
> >>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>>>> flag)
> >>>>>>>>>>       {
> >>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>>>> dsi->driver_data;
> >>>>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>>>> +        return 0;
> >>>>>>>>>> +
> >>>>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>>>> +
> >>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>>>       +    dsi->state |= flag;
> >>>>>>>>>> +
> >>>>>>>>>>           return 0;
> >>>>>>>>>>       }
> >>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>           }
> >>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>>>> +
> >>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>>>> +    if (ret)
> >>>>>>>>>> +        return;
> >>>>>>>>>>       }
> >>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>>>               return -EINVAL;
> >>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>>>> -        if (ret)
> >>>>>>>>>> -            return ret;
> >>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>>>> -    }
> >>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>>>> on the first transfer in case of Exynos?
> >>>>>>> That's odd , it does actually break panel support for me, without this
> >>>>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>>>> a full reset be necessary at all , even on the exynos ?
> >>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>>>> whether a reset is required before calling it might fix the issue.  I
> >>>>>> agree with double initialization is odd but it seems it is required on
> >>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>>>> code might resolve this discrepancy.
> >>>>> Can someone provide further details on the exynos problem ?
> >>>> If I'm correct this sequence is required in order to work the existing
> >>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >>>> possibly fix the sequence further.
> >>>>
> >>>> Marek Szyprowski, please add if you have anything.
> >>>
> >>>
> >>> Well, frankly speaking the double initialization is not a correct
> >>> sequence, but this is the only one that actually works on Exynos based
> >>> boards with DSI panels after moving the initialization to bridge's
> >>> .prepare() callback.
> >>
> >> Somehow, I suspect this is related to the LP11 mode handling, which
> >> differs for different panels, right ? I think the RPi people worked on
> >> fixing that.
> >>
> >> +CC Dave
> >
> > Yes. I've just sent out a v3 of that patch set.
> >
> > Hopefully setting the pre_enable_prev_first flag on your peripheral's
> > drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> > more sensible initialisation order for your panel.
> >
> > Note that host_transfer should ensure that the host is initialised, as
> > it is valid to call it with the host in any state. If it has to
> > initialise, then it should deinitialise once the transfer has
> > completed.
> >
> > Dave
> >
> >>> I've already explained this and shared the results
> >>> of my investigation in my replies to the previous versions of this
> >>> patchset. The original Exynos DSI driver does the initialization on the
> >>> first DSI command. This however doesn't work for Jagan with I2C
> >>> controlled panels/bridges, so he moved the initialization to the
> >>> .prepare() callback, what broke the Exynos case (in-short - all tested
> >>> panels works fine only if the DSI host initialization is done AFTER
> >>> turning the panel's power on). For more information, see this thread:
> >>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cc770caab3f274d9b50d108dad4753e1f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638055897263056680%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=1YV551YUhXQAjE4Cg0nAtMdMksWzMtscH49O83iKHRo%3D&amp;reserved=0
> >>>
> >>> Now, the more I think of it, the more I'm convinced that we simply
> >>> should add a hack based on the HW type: do the initialization in
> >>> .prepare() for non-Exynos case and before the first transfer for the
> >>> Exynos case, as there is no way to detect the panel/next bridge type
> >>> (I2C or DSI controlled).
> >>
> >> Let's see what Dave has to say about this, maybe there is some further help.
>
> Could we agree on adding the HW type based hack Marek S. proposed as a
> quick fix?
>
> This patchset was tested on Exynos so it's likely to not break any
> existing setups. And for i.MX8, this is a new driver so there's not
> really a requirement to have all setups working/supported from the
> beginning.
>
> Also having one or two hacks (marked with FIXME) in the code doesn't
> hurt. As we can see there are drafts to fix them in conjunction with
> changes in the DRM framework.
>
> This has been pending for months and in my opinion if there's a chance
> to get this into v6.2-rc1 we should take it.

My patchset was sent in March with no one seeming to care enough to review it.

If the situation is that your devices fall into the same camp as those
for vc4 (the host needs to be initialised before the peripheral), at
least verifying that would be useful before rushing into a hack.

Your other comment references using a TI SN65DSI84. I know for certain
that falls into the category of needing the DSI bus initialised before
it is brought out of reset.

  Dave

> If everyone agrees, Jagan, can you post a v9 which does the host
> initialization in .prepare() for i.MX and on first transfer for Exynos?
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

Hi Dave,

On 05.12.22 16:20, Dave Stevenson wrote:
> Hi Frieder
> 
> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>>
>> On 02.12.22 15:55, Dave Stevenson wrote:
>>> Hi Marek
>>>
>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>> Hi,
>>>>>
>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>
>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>
>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>
>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>
>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>> * none
>>>>>>>>>>>>
>>>>>>>>>>>> v4:
>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>
>>>>>>>>>>>> v3:
>>>>>>>>>>>> * none
>>>>>>>>>>>>
>>>>>>>>>>>> v2:
>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>
>>>>>>>>>>>> v1:
>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>>>       }
>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>> flag)
>>>>>>>>>>>>       {
>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>> +
>>>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>> +
>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>>>> +
>>>>>>>>>>>>           return 0;
>>>>>>>>>>>>       }
>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>           }
>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>> +
>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>> +        return;
>>>>>>>>>>>>       }
>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>> -    }
>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>> code might resolve this discrepancy.
>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>> possibly fix the sequence further.
>>>>>>
>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>
>>>>>
>>>>> Well, frankly speaking the double initialization is not a correct
>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>> .prepare() callback.
>>>>
>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>> differs for different panels, right ? I think the RPi people worked on
>>>> fixing that.
>>>>
>>>> +CC Dave
>>>
>>> Yes. I've just sent out a v3 of that patch set.
>>>
>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>> more sensible initialisation order for your panel.
>>>
>>> Note that host_transfer should ensure that the host is initialised, as
>>> it is valid to call it with the host in any state. If it has to
>>> initialise, then it should deinitialise once the transfer has
>>> completed.
>>>
>>> Dave
>>>
>>>>> I've already explained this and shared the results
>>>>> of my investigation in my replies to the previous versions of this
>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>> turning the panel's power on). For more information, see this thread:
>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
>>>>>
>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>> should add a hack based on the HW type: do the initialization in
>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>> (I2C or DSI controlled).
>>>>
>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>
>> Could we agree on adding the HW type based hack Marek S. proposed as a
>> quick fix?
>>
>> This patchset was tested on Exynos so it's likely to not break any
>> existing setups. And for i.MX8, this is a new driver so there's not
>> really a requirement to have all setups working/supported from the
>> beginning.
>>
>> Also having one or two hacks (marked with FIXME) in the code doesn't
>> hurt. As we can see there are drafts to fix them in conjunction with
>> changes in the DRM framework.
>>
>> This has been pending for months and in my opinion if there's a chance
>> to get this into v6.2-rc1 we should take it.
> 
> My patchset was sent in March with no one seeming to care enough to review it.

I wasn't referring to your patchset but rather to the Samsung DSIM
bridge transformation patchset.

My point was simply to not try getting everything done in one big step
because this will fail. The patchset this refers to needs testing on two
separate platforms which is painful enough (thanks to Marek for covering
the Exynos side!). I think we should focus on getting the DSIM bridge
transformation merged and accept a few small hacks that will be taken
care of in the next step.

> 
> If the situation is that your devices fall into the same camp as those
> for vc4 (the host needs to be initialised before the peripheral), at
> least verifying that would be useful before rushing into a hack.
> 
> Your other comment references using a TI SN65DSI84. I know for certain
> that falls into the category of needing the DSI bus initialised before
> it is brought out of reset.

I'm actually working on this right now and when I received your message
I was about to start typing a reply to your patchset.

The SN65DSI84 works with the i.MX8MM DSIM even using the default order
of host init after peripheral init in our setup, but this configuration
doesn't seem to be stable and occasionally the bridge doesn't come up
properly.

We are still in the process of verifying if the reversed order fixes
this reliably. But regardless of the results, without the reversal the
initialization sequence is way out of spec and we need to fix this in
any case.

See here for my testing branch including some follow-up patches that
improve the initialization flow for my setup:
https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.

Thanks
Frieder

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

Hi Dave,

On 05.12.22 16:20, Dave Stevenson wrote:
> Hi Frieder
> 
> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>>
>> On 02.12.22 15:55, Dave Stevenson wrote:
>>> Hi Marek
>>>
>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>> Hi,
>>>>>
>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>
>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>
>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>
>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>
>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>> * none
>>>>>>>>>>>>
>>>>>>>>>>>> v4:
>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>
>>>>>>>>>>>> v3:
>>>>>>>>>>>> * none
>>>>>>>>>>>>
>>>>>>>>>>>> v2:
>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>
>>>>>>>>>>>> v1:
>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>>>       }
>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>> flag)
>>>>>>>>>>>>       {
>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>> +
>>>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>> +
>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>>>> +
>>>>>>>>>>>>           return 0;
>>>>>>>>>>>>       }
>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>           }
>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>> +
>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>> +        return;
>>>>>>>>>>>>       }
>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>> -    }
>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>> code might resolve this discrepancy.
>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>> possibly fix the sequence further.
>>>>>>
>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>
>>>>>
>>>>> Well, frankly speaking the double initialization is not a correct
>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>> .prepare() callback.
>>>>
>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>> differs for different panels, right ? I think the RPi people worked on
>>>> fixing that.
>>>>
>>>> +CC Dave
>>>
>>> Yes. I've just sent out a v3 of that patch set.
>>>
>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>> more sensible initialisation order for your panel.
>>>
>>> Note that host_transfer should ensure that the host is initialised, as
>>> it is valid to call it with the host in any state. If it has to
>>> initialise, then it should deinitialise once the transfer has
>>> completed.
>>>
>>> Dave
>>>
>>>>> I've already explained this and shared the results
>>>>> of my investigation in my replies to the previous versions of this
>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>> turning the panel's power on). For more information, see this thread:
>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
>>>>>
>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>> should add a hack based on the HW type: do the initialization in
>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>> (I2C or DSI controlled).
>>>>
>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>
>> Could we agree on adding the HW type based hack Marek S. proposed as a
>> quick fix?
>>
>> This patchset was tested on Exynos so it's likely to not break any
>> existing setups. And for i.MX8, this is a new driver so there's not
>> really a requirement to have all setups working/supported from the
>> beginning.
>>
>> Also having one or two hacks (marked with FIXME) in the code doesn't
>> hurt. As we can see there are drafts to fix them in conjunction with
>> changes in the DRM framework.
>>
>> This has been pending for months and in my opinion if there's a chance
>> to get this into v6.2-rc1 we should take it.
> 
> My patchset was sent in March with no one seeming to care enough to review it.

I wasn't referring to your patchset but rather to the Samsung DSIM
bridge transformation patchset.

My point was simply to not try getting everything done in one big step
because this will fail. The patchset this refers to needs testing on two
separate platforms which is painful enough (thanks to Marek for covering
the Exynos side!). I think we should focus on getting the DSIM bridge
transformation merged and accept a few small hacks that will be taken
care of in the next step.

> 
> If the situation is that your devices fall into the same camp as those
> for vc4 (the host needs to be initialised before the peripheral), at
> least verifying that would be useful before rushing into a hack.
> 
> Your other comment references using a TI SN65DSI84. I know for certain
> that falls into the category of needing the DSI bus initialised before
> it is brought out of reset.

I'm actually working on this right now and when I received your message
I was about to start typing a reply to your patchset.

The SN65DSI84 works with the i.MX8MM DSIM even using the default order
of host init after peripheral init in our setup, but this configuration
doesn't seem to be stable and occasionally the bridge doesn't come up
properly.

We are still in the process of verifying if the reversed order fixes
this reliably. But regardless of the results, without the reversal the
initialization sequence is way out of spec and we need to fix this in
any case.

See here for my testing branch including some follow-up patches that
improve the initialization flow for my setup:
https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.

Thanks
Frieder

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

Hi Dave,

On 05.12.22 16:20, Dave Stevenson wrote:
> Hi Frieder
> 
> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>>
>> On 02.12.22 15:55, Dave Stevenson wrote:
>>> Hi Marek
>>>
>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>> Hi,
>>>>>
>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>
>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>
>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>
>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>
>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>> * none
>>>>>>>>>>>>
>>>>>>>>>>>> v4:
>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>
>>>>>>>>>>>> v3:
>>>>>>>>>>>> * none
>>>>>>>>>>>>
>>>>>>>>>>>> v2:
>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>
>>>>>>>>>>>> v1:
>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>>>       }
>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>> flag)
>>>>>>>>>>>>       {
>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>> +
>>>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>> +
>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>>>> +
>>>>>>>>>>>>           return 0;
>>>>>>>>>>>>       }
>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>           }
>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>> +
>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>> +        return;
>>>>>>>>>>>>       }
>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>> -    }
>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>> code might resolve this discrepancy.
>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>> possibly fix the sequence further.
>>>>>>
>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>
>>>>>
>>>>> Well, frankly speaking the double initialization is not a correct
>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>> .prepare() callback.
>>>>
>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>> differs for different panels, right ? I think the RPi people worked on
>>>> fixing that.
>>>>
>>>> +CC Dave
>>>
>>> Yes. I've just sent out a v3 of that patch set.
>>>
>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>> more sensible initialisation order for your panel.
>>>
>>> Note that host_transfer should ensure that the host is initialised, as
>>> it is valid to call it with the host in any state. If it has to
>>> initialise, then it should deinitialise once the transfer has
>>> completed.
>>>
>>> Dave
>>>
>>>>> I've already explained this and shared the results
>>>>> of my investigation in my replies to the previous versions of this
>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>> turning the panel's power on). For more information, see this thread:
>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
>>>>>
>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>> should add a hack based on the HW type: do the initialization in
>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>> (I2C or DSI controlled).
>>>>
>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>
>> Could we agree on adding the HW type based hack Marek S. proposed as a
>> quick fix?
>>
>> This patchset was tested on Exynos so it's likely to not break any
>> existing setups. And for i.MX8, this is a new driver so there's not
>> really a requirement to have all setups working/supported from the
>> beginning.
>>
>> Also having one or two hacks (marked with FIXME) in the code doesn't
>> hurt. As we can see there are drafts to fix them in conjunction with
>> changes in the DRM framework.
>>
>> This has been pending for months and in my opinion if there's a chance
>> to get this into v6.2-rc1 we should take it.
> 
> My patchset was sent in March with no one seeming to care enough to review it.

I wasn't referring to your patchset but rather to the Samsung DSIM
bridge transformation patchset.

My point was simply to not try getting everything done in one big step
because this will fail. The patchset this refers to needs testing on two
separate platforms which is painful enough (thanks to Marek for covering
the Exynos side!). I think we should focus on getting the DSIM bridge
transformation merged and accept a few small hacks that will be taken
care of in the next step.

> 
> If the situation is that your devices fall into the same camp as those
> for vc4 (the host needs to be initialised before the peripheral), at
> least verifying that would be useful before rushing into a hack.
> 
> Your other comment references using a TI SN65DSI84. I know for certain
> that falls into the category of needing the DSI bus initialised before
> it is brought out of reset.

I'm actually working on this right now and when I received your message
I was about to start typing a reply to your patchset.

The SN65DSI84 works with the i.MX8MM DSIM even using the default order
of host init after peripheral init in our setup, but this configuration
doesn't seem to be stable and occasionally the bridge doesn't come up
properly.

We are still in the process of verifying if the reversed order fixes
this reliably. But regardless of the results, without the reversal the
initialization sequence is way out of spec and we need to fix this in
any case.

See here for my testing branch including some follow-up patches that
improve the initialization flow for my setup:
https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.

Thanks
Frieder

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

On 05.12.22 16:37, Frieder Schrempf wrote:
> Hi Dave,
> 
> On 05.12.22 16:20, Dave Stevenson wrote:
>> Hi Frieder
>>
>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>> <frieder.schrempf@kontron.de> wrote:
>>>
>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>> Hi Marek
>>>>
>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>>
>>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>>
>>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>>
>>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>>> * none
>>>>>>>>>>>>>
>>>>>>>>>>>>> v4:
>>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>>
>>>>>>>>>>>>> v3:
>>>>>>>>>>>>> * none
>>>>>>>>>>>>>
>>>>>>>>>>>>> v2:
>>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>>
>>>>>>>>>>>>> v1:
>>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>>> flag)
>>>>>>>>>>>>>       {
>>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           return 0;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>           }
>>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>>> +        return;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>>> -    }
>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>>> code might resolve this discrepancy.
>>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>>> possibly fix the sequence further.
>>>>>>>
>>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>>
>>>>>>
>>>>>> Well, frankly speaking the double initialization is not a correct
>>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>>> .prepare() callback.
>>>>>
>>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>>> differs for different panels, right ? I think the RPi people worked on
>>>>> fixing that.
>>>>>
>>>>> +CC Dave
>>>>
>>>> Yes. I've just sent out a v3 of that patch set.
>>>>
>>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>>> more sensible initialisation order for your panel.
>>>>
>>>> Note that host_transfer should ensure that the host is initialised, as
>>>> it is valid to call it with the host in any state. If it has to
>>>> initialise, then it should deinitialise once the transfer has
>>>> completed.
>>>>
>>>> Dave
>>>>
>>>>>> I've already explained this and shared the results
>>>>>> of my investigation in my replies to the previous versions of this
>>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>>> turning the panel's power on). For more information, see this thread:
>>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
>>>>>>
>>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>>> should add a hack based on the HW type: do the initialization in
>>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>>> (I2C or DSI controlled).
>>>>>
>>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>>
>>> Could we agree on adding the HW type based hack Marek S. proposed as a
>>> quick fix?
>>>
>>> This patchset was tested on Exynos so it's likely to not break any
>>> existing setups. And for i.MX8, this is a new driver so there's not
>>> really a requirement to have all setups working/supported from the
>>> beginning.
>>>
>>> Also having one or two hacks (marked with FIXME) in the code doesn't
>>> hurt. As we can see there are drafts to fix them in conjunction with
>>> changes in the DRM framework.
>>>
>>> This has been pending for months and in my opinion if there's a chance
>>> to get this into v6.2-rc1 we should take it.
>>
>> My patchset was sent in March with no one seeming to care enough to review it.
> 
> I wasn't referring to your patchset but rather to the Samsung DSIM
> bridge transformation patchset.
> 
> My point was simply to not try getting everything done in one big step
> because this will fail. The patchset this refers to needs testing on two
> separate platforms which is painful enough (thanks to Marek for covering
> the Exynos side!). I think we should focus on getting the DSIM bridge
> transformation merged and accept a few small hacks that will be taken
> care of in the next step.
> 
>>
>> If the situation is that your devices fall into the same camp as those
>> for vc4 (the host needs to be initialised before the peripheral), at
>> least verifying that would be useful before rushing into a hack.
>>
>> Your other comment references using a TI SN65DSI84. I know for certain
>> that falls into the category of needing the DSI bus initialised before
>> it is brought out of reset.
> 
> I'm actually working on this right now and when I received your message
> I was about to start typing a reply to your patchset.
> 
> The SN65DSI84 works with the i.MX8MM DSIM even using the default order
> of host init after peripheral init in our setup, but this configuration
> doesn't seem to be stable and occasionally the bridge doesn't come up
> properly.
> 
> We are still in the process of verifying if the reversed order fixes
> this reliably. But regardless of the results, without the reversal the
> initialization sequence is way out of spec and we need to fix this in
> any case.
> 
> See here for my testing branch including some follow-up patches that
> improve the initialization flow for my setup:
> https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.

To recap my thoughts on the two hacks for the DSIM bridge driver
discussed before:

(1) Passing null to previous bridge in samsung_dsim_attach()
(2) Always initialize host on first transfer (see this patch, 06/14)

My wild guess would be that both could be fixed up properly in the long
run by the following changes:

* Apply Dave's patchset [1]
* Set pre_enable_prev_first flag in the downstream bridge drivers and
  fix init flow if required ([2] for ti-sn65dsi83)
* Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
* Only call init on transfer when not already initialized and deinit
  after transfer (tbd)

As that route needs proper testing on the affected hardware setups and
includes changes to other drivers and the framework, I would suggest the
following for the v9 of this patchset:

* Keep hack (1)
* Make hack (2) dependent on the platform (Exynos)

As this is what Marek S. already suggested above, Jagan, can you send
the v9 with this change included?
Then Marek V. can test on his setup and if everything looks good we can
move on.

[1]
https://patchwork.kernel.org/project/dri-devel/cover/20221205173328.1395350-1-dave.stevenson@raspberrypi.com/
[2]
https://git.kontron-electronics.de/sw/misc/linux/-/commit/7769180e6bbdcb2e42c2b39cda5127efc21d3653
[3]
https://git.kontron-electronics.de/sw/misc/linux/-/commit/e6aba93de1189432dcaac17d969546a92541dc87

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

On 05.12.22 16:37, Frieder Schrempf wrote:
> Hi Dave,
> 
> On 05.12.22 16:20, Dave Stevenson wrote:
>> Hi Frieder
>>
>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>> <frieder.schrempf@kontron.de> wrote:
>>>
>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>> Hi Marek
>>>>
>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>>
>>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>>
>>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>>
>>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>>> * none
>>>>>>>>>>>>>
>>>>>>>>>>>>> v4:
>>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>>
>>>>>>>>>>>>> v3:
>>>>>>>>>>>>> * none
>>>>>>>>>>>>>
>>>>>>>>>>>>> v2:
>>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>>
>>>>>>>>>>>>> v1:
>>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>>> flag)
>>>>>>>>>>>>>       {
>>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           return 0;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>           }
>>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>>> +        return;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>>> -    }
>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>>> code might resolve this discrepancy.
>>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>>> possibly fix the sequence further.
>>>>>>>
>>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>>
>>>>>>
>>>>>> Well, frankly speaking the double initialization is not a correct
>>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>>> .prepare() callback.
>>>>>
>>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>>> differs for different panels, right ? I think the RPi people worked on
>>>>> fixing that.
>>>>>
>>>>> +CC Dave
>>>>
>>>> Yes. I've just sent out a v3 of that patch set.
>>>>
>>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>>> more sensible initialisation order for your panel.
>>>>
>>>> Note that host_transfer should ensure that the host is initialised, as
>>>> it is valid to call it with the host in any state. If it has to
>>>> initialise, then it should deinitialise once the transfer has
>>>> completed.
>>>>
>>>> Dave
>>>>
>>>>>> I've already explained this and shared the results
>>>>>> of my investigation in my replies to the previous versions of this
>>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>>> turning the panel's power on). For more information, see this thread:
>>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
>>>>>>
>>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>>> should add a hack based on the HW type: do the initialization in
>>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>>> (I2C or DSI controlled).
>>>>>
>>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>>
>>> Could we agree on adding the HW type based hack Marek S. proposed as a
>>> quick fix?
>>>
>>> This patchset was tested on Exynos so it's likely to not break any
>>> existing setups. And for i.MX8, this is a new driver so there's not
>>> really a requirement to have all setups working/supported from the
>>> beginning.
>>>
>>> Also having one or two hacks (marked with FIXME) in the code doesn't
>>> hurt. As we can see there are drafts to fix them in conjunction with
>>> changes in the DRM framework.
>>>
>>> This has been pending for months and in my opinion if there's a chance
>>> to get this into v6.2-rc1 we should take it.
>>
>> My patchset was sent in March with no one seeming to care enough to review it.
> 
> I wasn't referring to your patchset but rather to the Samsung DSIM
> bridge transformation patchset.
> 
> My point was simply to not try getting everything done in one big step
> because this will fail. The patchset this refers to needs testing on two
> separate platforms which is painful enough (thanks to Marek for covering
> the Exynos side!). I think we should focus on getting the DSIM bridge
> transformation merged and accept a few small hacks that will be taken
> care of in the next step.
> 
>>
>> If the situation is that your devices fall into the same camp as those
>> for vc4 (the host needs to be initialised before the peripheral), at
>> least verifying that would be useful before rushing into a hack.
>>
>> Your other comment references using a TI SN65DSI84. I know for certain
>> that falls into the category of needing the DSI bus initialised before
>> it is brought out of reset.
> 
> I'm actually working on this right now and when I received your message
> I was about to start typing a reply to your patchset.
> 
> The SN65DSI84 works with the i.MX8MM DSIM even using the default order
> of host init after peripheral init in our setup, but this configuration
> doesn't seem to be stable and occasionally the bridge doesn't come up
> properly.
> 
> We are still in the process of verifying if the reversed order fixes
> this reliably. But regardless of the results, without the reversal the
> initialization sequence is way out of spec and we need to fix this in
> any case.
> 
> See here for my testing branch including some follow-up patches that
> improve the initialization flow for my setup:
> https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.

To recap my thoughts on the two hacks for the DSIM bridge driver
discussed before:

(1) Passing null to previous bridge in samsung_dsim_attach()
(2) Always initialize host on first transfer (see this patch, 06/14)

My wild guess would be that both could be fixed up properly in the long
run by the following changes:

* Apply Dave's patchset [1]
* Set pre_enable_prev_first flag in the downstream bridge drivers and
  fix init flow if required ([2] for ti-sn65dsi83)
* Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
* Only call init on transfer when not already initialized and deinit
  after transfer (tbd)

As that route needs proper testing on the affected hardware setups and
includes changes to other drivers and the framework, I would suggest the
following for the v9 of this patchset:

* Keep hack (1)
* Make hack (2) dependent on the platform (Exynos)

As this is what Marek S. already suggested above, Jagan, can you send
the v9 with this change included?
Then Marek V. can test on his setup and if everything looks good we can
move on.

[1]
https://patchwork.kernel.org/project/dri-devel/cover/20221205173328.1395350-1-dave.stevenson@raspberrypi.com/
[2]
https://git.kontron-electronics.de/sw/misc/linux/-/commit/7769180e6bbdcb2e42c2b39cda5127efc21d3653
[3]
https://git.kontron-electronics.de/sw/misc/linux/-/commit/e6aba93de1189432dcaac17d969546a92541dc87




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Frieder Schrempf]

On 05.12.22 16:37, Frieder Schrempf wrote:
> Hi Dave,
> 
> On 05.12.22 16:20, Dave Stevenson wrote:
>> Hi Frieder
>>
>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>> <frieder.schrempf@kontron.de> wrote:
>>>
>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>> Hi Marek
>>>>
>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>>
>>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>>
>>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>>
>>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>>> * none
>>>>>>>>>>>>>
>>>>>>>>>>>>> v4:
>>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>>
>>>>>>>>>>>>> v3:
>>>>>>>>>>>>> * none
>>>>>>>>>>>>>
>>>>>>>>>>>>> v2:
>>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>>
>>>>>>>>>>>>> v1:
>>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>           disable_irq(dsi->irq);
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>>> flag)
>>>>>>>>>>>>>       {
>>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>>       +    if (dsi->state & flag)
>>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           samsung_dsim_reset(dsi);
>>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
>>>>>>>>>>>>>       +    dsi->state |= flag;
>>>>>>>>>>>>> +
>>>>>>>>>>>>>           return 0;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>           }
>>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>>> +        return;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>>               return -EINVAL;
>>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>>> -    }
>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>>> code might resolve this discrepancy.
>>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>>> possibly fix the sequence further.
>>>>>>>
>>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>>
>>>>>>
>>>>>> Well, frankly speaking the double initialization is not a correct
>>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>>> .prepare() callback.
>>>>>
>>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>>> differs for different panels, right ? I think the RPi people worked on
>>>>> fixing that.
>>>>>
>>>>> +CC Dave
>>>>
>>>> Yes. I've just sent out a v3 of that patch set.
>>>>
>>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>>> more sensible initialisation order for your panel.
>>>>
>>>> Note that host_transfer should ensure that the host is initialised, as
>>>> it is valid to call it with the host in any state. If it has to
>>>> initialise, then it should deinitialise once the transfer has
>>>> completed.
>>>>
>>>> Dave
>>>>
>>>>>> I've already explained this and shared the results
>>>>>> of my investigation in my replies to the previous versions of this
>>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>>> turning the panel's power on). For more information, see this thread:
>>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
>>>>>>
>>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>>> should add a hack based on the HW type: do the initialization in
>>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>>> (I2C or DSI controlled).
>>>>>
>>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>>
>>> Could we agree on adding the HW type based hack Marek S. proposed as a
>>> quick fix?
>>>
>>> This patchset was tested on Exynos so it's likely to not break any
>>> existing setups. And for i.MX8, this is a new driver so there's not
>>> really a requirement to have all setups working/supported from the
>>> beginning.
>>>
>>> Also having one or two hacks (marked with FIXME) in the code doesn't
>>> hurt. As we can see there are drafts to fix them in conjunction with
>>> changes in the DRM framework.
>>>
>>> This has been pending for months and in my opinion if there's a chance
>>> to get this into v6.2-rc1 we should take it.
>>
>> My patchset was sent in March with no one seeming to care enough to review it.
> 
> I wasn't referring to your patchset but rather to the Samsung DSIM
> bridge transformation patchset.
> 
> My point was simply to not try getting everything done in one big step
> because this will fail. The patchset this refers to needs testing on two
> separate platforms which is painful enough (thanks to Marek for covering
> the Exynos side!). I think we should focus on getting the DSIM bridge
> transformation merged and accept a few small hacks that will be taken
> care of in the next step.
> 
>>
>> If the situation is that your devices fall into the same camp as those
>> for vc4 (the host needs to be initialised before the peripheral), at
>> least verifying that would be useful before rushing into a hack.
>>
>> Your other comment references using a TI SN65DSI84. I know for certain
>> that falls into the category of needing the DSI bus initialised before
>> it is brought out of reset.
> 
> I'm actually working on this right now and when I received your message
> I was about to start typing a reply to your patchset.
> 
> The SN65DSI84 works with the i.MX8MM DSIM even using the default order
> of host init after peripheral init in our setup, but this configuration
> doesn't seem to be stable and occasionally the bridge doesn't come up
> properly.
> 
> We are still in the process of verifying if the reversed order fixes
> this reliably. But regardless of the results, without the reversal the
> initialization sequence is way out of spec and we need to fix this in
> any case.
> 
> See here for my testing branch including some follow-up patches that
> improve the initialization flow for my setup:
> https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.

To recap my thoughts on the two hacks for the DSIM bridge driver
discussed before:

(1) Passing null to previous bridge in samsung_dsim_attach()
(2) Always initialize host on first transfer (see this patch, 06/14)

My wild guess would be that both could be fixed up properly in the long
run by the following changes:

* Apply Dave's patchset [1]
* Set pre_enable_prev_first flag in the downstream bridge drivers and
  fix init flow if required ([2] for ti-sn65dsi83)
* Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
* Only call init on transfer when not already initialized and deinit
  after transfer (tbd)

As that route needs proper testing on the affected hardware setups and
includes changes to other drivers and the framework, I would suggest the
following for the v9 of this patchset:

* Keep hack (1)
* Make hack (2) dependent on the platform (Exynos)

As this is what Marek S. already suggested above, Jagan, can you send
the v9 with this change included?
Then Marek V. can test on his setup and if everything looks good we can
move on.

[1]
https://patchwork.kernel.org/project/dri-devel/cover/20221205173328.1395350-1-dave.stevenson@raspberrypi.com/
[2]
https://git.kontron-electronics.de/sw/misc/linux/-/commit/7769180e6bbdcb2e42c2b39cda5127efc21d3653
[3]
https://git.kontron-electronics.de/sw/misc/linux/-/commit/e6aba93de1189432dcaac17d969546a92541dc87

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 05.12.22 16:37, Frieder Schrempf wrote:
> > Hi Dave,
> >
> > On 05.12.22 16:20, Dave Stevenson wrote:
> >> Hi Frieder
> >>
> >> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> >> <frieder.schrempf@kontron.de> wrote:
> >>>
> >>> On 02.12.22 15:55, Dave Stevenson wrote:
> >>>> Hi Marek
> >>>>
> >>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
> >>>>>>
> >>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
> >>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>>>>>>> configured downstream bridges.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>>>>>>> Szyprowski).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v8, v7, v6, v5:
> >>>>>>>>>>>>> * none
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v4:
> >>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v3:
> >>>>>>>>>>>>> * none
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v2:
> >>>>>>>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v1:
> >>>>>>>>>>>>> * keep DSI init in host transfer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>>>>>>> flag)
> >>>>>>>>>>>>>       {
> >>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>>>>>>> dsi->driver_data;
> >>>>>>>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>>>>>>> +        return 0;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>>>>>>       +    dsi->state |= flag;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>           return 0;
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>           }
> >>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>>>>>>> +    if (ret)
> >>>>>>>>>>>>> +        return;
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>>>>>>               return -EINVAL;
> >>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>>>>>>> -        if (ret)
> >>>>>>>>>>>>> -            return ret;
> >>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>>>>>>> -    }
> >>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>>>>>>> on the first transfer in case of Exynos?
> >>>>>>>>>> That's odd , it does actually break panel support for me, without this
> >>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>>>>>>> a full reset be necessary at all , even on the exynos ?
> >>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>>>>>>> whether a reset is required before calling it might fix the issue.  I
> >>>>>>>>> agree with double initialization is odd but it seems it is required on
> >>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>>>>>>> code might resolve this discrepancy.
> >>>>>>>> Can someone provide further details on the exynos problem ?
> >>>>>>> If I'm correct this sequence is required in order to work the existing
> >>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >>>>>>> possibly fix the sequence further.
> >>>>>>>
> >>>>>>> Marek Szyprowski, please add if you have anything.
> >>>>>>
> >>>>>>
> >>>>>> Well, frankly speaking the double initialization is not a correct
> >>>>>> sequence, but this is the only one that actually works on Exynos based
> >>>>>> boards with DSI panels after moving the initialization to bridge's
> >>>>>> .prepare() callback.
> >>>>>
> >>>>> Somehow, I suspect this is related to the LP11 mode handling, which
> >>>>> differs for different panels, right ? I think the RPi people worked on
> >>>>> fixing that.
> >>>>>
> >>>>> +CC Dave
> >>>>
> >>>> Yes. I've just sent out a v3 of that patch set.
> >>>>
> >>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
> >>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> >>>> more sensible initialisation order for your panel.
> >>>>
> >>>> Note that host_transfer should ensure that the host is initialised, as
> >>>> it is valid to call it with the host in any state. If it has to
> >>>> initialise, then it should deinitialise once the transfer has
> >>>> completed.
> >>>>
> >>>> Dave
> >>>>
> >>>>>> I've already explained this and shared the results
> >>>>>> of my investigation in my replies to the previous versions of this
> >>>>>> patchset. The original Exynos DSI driver does the initialization on the
> >>>>>> first DSI command. This however doesn't work for Jagan with I2C
> >>>>>> controlled panels/bridges, so he moved the initialization to the
> >>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
> >>>>>> panels works fine only if the DSI host initialization is done AFTER
> >>>>>> turning the panel's power on). For more information, see this thread:
> >>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
> >>>>>>
> >>>>>> Now, the more I think of it, the more I'm convinced that we simply
> >>>>>> should add a hack based on the HW type: do the initialization in
> >>>>>> .prepare() for non-Exynos case and before the first transfer for the
> >>>>>> Exynos case, as there is no way to detect the panel/next bridge type
> >>>>>> (I2C or DSI controlled).
> >>>>>
> >>>>> Let's see what Dave has to say about this, maybe there is some further help.
> >>>
> >>> Could we agree on adding the HW type based hack Marek S. proposed as a
> >>> quick fix?
> >>>
> >>> This patchset was tested on Exynos so it's likely to not break any
> >>> existing setups. And for i.MX8, this is a new driver so there's not
> >>> really a requirement to have all setups working/supported from the
> >>> beginning.
> >>>
> >>> Also having one or two hacks (marked with FIXME) in the code doesn't
> >>> hurt. As we can see there are drafts to fix them in conjunction with
> >>> changes in the DRM framework.
> >>>
> >>> This has been pending for months and in my opinion if there's a chance
> >>> to get this into v6.2-rc1 we should take it.
> >>
> >> My patchset was sent in March with no one seeming to care enough to review it.
> >
> > I wasn't referring to your patchset but rather to the Samsung DSIM
> > bridge transformation patchset.
> >
> > My point was simply to not try getting everything done in one big step
> > because this will fail. The patchset this refers to needs testing on two
> > separate platforms which is painful enough (thanks to Marek for covering
> > the Exynos side!). I think we should focus on getting the DSIM bridge
> > transformation merged and accept a few small hacks that will be taken
> > care of in the next step.
> >
> >>
> >> If the situation is that your devices fall into the same camp as those
> >> for vc4 (the host needs to be initialised before the peripheral), at
> >> least verifying that would be useful before rushing into a hack.
> >>
> >> Your other comment references using a TI SN65DSI84. I know for certain
> >> that falls into the category of needing the DSI bus initialised before
> >> it is brought out of reset.
> >
> > I'm actually working on this right now and when I received your message
> > I was about to start typing a reply to your patchset.
> >
> > The SN65DSI84 works with the i.MX8MM DSIM even using the default order
> > of host init after peripheral init in our setup, but this configuration
> > doesn't seem to be stable and occasionally the bridge doesn't come up
> > properly.
> >
> > We are still in the process of verifying if the reversed order fixes
> > this reliably. But regardless of the results, without the reversal the
> > initialization sequence is way out of spec and we need to fix this in
> > any case.
> >
> > See here for my testing branch including some follow-up patches that
> > improve the initialization flow for my setup:
> > https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.
>
> To recap my thoughts on the two hacks for the DSIM bridge driver
> discussed before:
>
> (1) Passing null to previous bridge in samsung_dsim_attach()
> (2) Always initialize host on first transfer (see this patch, 06/14)
>
> My wild guess would be that both could be fixed up properly in the long
> run by the following changes:
>
> * Apply Dave's patchset [1]
> * Set pre_enable_prev_first flag in the downstream bridge drivers and
>   fix init flow if required ([2] for ti-sn65dsi83)
> * Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
> * Only call init on transfer when not already initialized and deinit
>   after transfer (tbd)
>
> As that route needs proper testing on the affected hardware setups and
> includes changes to other drivers and the framework, I would suggest the
> following for the v9 of this patchset:

I did it on drm-misc-next [1].

>
> * Keep hack (1)

This has gone, not needed.

> * Make hack (2) dependent on the platform (Exynos)

I think with pre_enable_prev_first flag the Exynos pipeline will start
from bridge funcs like pre_enable so initializing the host will work
for exynos to work. [2]

Marek Sz. Can you confirm this?

[1] https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v9
[2] https://gitlab.com/openedev/kernel/-/commit/95ab71b797310952284fabfbc8476a9831902c5c

Jagan.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 05.12.22 16:37, Frieder Schrempf wrote:
> > Hi Dave,
> >
> > On 05.12.22 16:20, Dave Stevenson wrote:
> >> Hi Frieder
> >>
> >> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> >> <frieder.schrempf@kontron.de> wrote:
> >>>
> >>> On 02.12.22 15:55, Dave Stevenson wrote:
> >>>> Hi Marek
> >>>>
> >>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
> >>>>>>
> >>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
> >>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>>>>>>> configured downstream bridges.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>>>>>>> Szyprowski).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v8, v7, v6, v5:
> >>>>>>>>>>>>> * none
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v4:
> >>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v3:
> >>>>>>>>>>>>> * none
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v2:
> >>>>>>>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v1:
> >>>>>>>>>>>>> * keep DSI init in host transfer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>>>>>>> flag)
> >>>>>>>>>>>>>       {
> >>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>>>>>>> dsi->driver_data;
> >>>>>>>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>>>>>>> +        return 0;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>>>>>>       +    dsi->state |= flag;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>           return 0;
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>           }
> >>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>>>>>>> +    if (ret)
> >>>>>>>>>>>>> +        return;
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>>>>>>               return -EINVAL;
> >>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>>>>>>> -        if (ret)
> >>>>>>>>>>>>> -            return ret;
> >>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>>>>>>> -    }
> >>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>>>>>>> on the first transfer in case of Exynos?
> >>>>>>>>>> That's odd , it does actually break panel support for me, without this
> >>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>>>>>>> a full reset be necessary at all , even on the exynos ?
> >>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>>>>>>> whether a reset is required before calling it might fix the issue.  I
> >>>>>>>>> agree with double initialization is odd but it seems it is required on
> >>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>>>>>>> code might resolve this discrepancy.
> >>>>>>>> Can someone provide further details on the exynos problem ?
> >>>>>>> If I'm correct this sequence is required in order to work the existing
> >>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >>>>>>> possibly fix the sequence further.
> >>>>>>>
> >>>>>>> Marek Szyprowski, please add if you have anything.
> >>>>>>
> >>>>>>
> >>>>>> Well, frankly speaking the double initialization is not a correct
> >>>>>> sequence, but this is the only one that actually works on Exynos based
> >>>>>> boards with DSI panels after moving the initialization to bridge's
> >>>>>> .prepare() callback.
> >>>>>
> >>>>> Somehow, I suspect this is related to the LP11 mode handling, which
> >>>>> differs for different panels, right ? I think the RPi people worked on
> >>>>> fixing that.
> >>>>>
> >>>>> +CC Dave
> >>>>
> >>>> Yes. I've just sent out a v3 of that patch set.
> >>>>
> >>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
> >>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> >>>> more sensible initialisation order for your panel.
> >>>>
> >>>> Note that host_transfer should ensure that the host is initialised, as
> >>>> it is valid to call it with the host in any state. If it has to
> >>>> initialise, then it should deinitialise once the transfer has
> >>>> completed.
> >>>>
> >>>> Dave
> >>>>
> >>>>>> I've already explained this and shared the results
> >>>>>> of my investigation in my replies to the previous versions of this
> >>>>>> patchset. The original Exynos DSI driver does the initialization on the
> >>>>>> first DSI command. This however doesn't work for Jagan with I2C
> >>>>>> controlled panels/bridges, so he moved the initialization to the
> >>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
> >>>>>> panels works fine only if the DSI host initialization is done AFTER
> >>>>>> turning the panel's power on). For more information, see this thread:
> >>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
> >>>>>>
> >>>>>> Now, the more I think of it, the more I'm convinced that we simply
> >>>>>> should add a hack based on the HW type: do the initialization in
> >>>>>> .prepare() for non-Exynos case and before the first transfer for the
> >>>>>> Exynos case, as there is no way to detect the panel/next bridge type
> >>>>>> (I2C or DSI controlled).
> >>>>>
> >>>>> Let's see what Dave has to say about this, maybe there is some further help.
> >>>
> >>> Could we agree on adding the HW type based hack Marek S. proposed as a
> >>> quick fix?
> >>>
> >>> This patchset was tested on Exynos so it's likely to not break any
> >>> existing setups. And for i.MX8, this is a new driver so there's not
> >>> really a requirement to have all setups working/supported from the
> >>> beginning.
> >>>
> >>> Also having one or two hacks (marked with FIXME) in the code doesn't
> >>> hurt. As we can see there are drafts to fix them in conjunction with
> >>> changes in the DRM framework.
> >>>
> >>> This has been pending for months and in my opinion if there's a chance
> >>> to get this into v6.2-rc1 we should take it.
> >>
> >> My patchset was sent in March with no one seeming to care enough to review it.
> >
> > I wasn't referring to your patchset but rather to the Samsung DSIM
> > bridge transformation patchset.
> >
> > My point was simply to not try getting everything done in one big step
> > because this will fail. The patchset this refers to needs testing on two
> > separate platforms which is painful enough (thanks to Marek for covering
> > the Exynos side!). I think we should focus on getting the DSIM bridge
> > transformation merged and accept a few small hacks that will be taken
> > care of in the next step.
> >
> >>
> >> If the situation is that your devices fall into the same camp as those
> >> for vc4 (the host needs to be initialised before the peripheral), at
> >> least verifying that would be useful before rushing into a hack.
> >>
> >> Your other comment references using a TI SN65DSI84. I know for certain
> >> that falls into the category of needing the DSI bus initialised before
> >> it is brought out of reset.
> >
> > I'm actually working on this right now and when I received your message
> > I was about to start typing a reply to your patchset.
> >
> > The SN65DSI84 works with the i.MX8MM DSIM even using the default order
> > of host init after peripheral init in our setup, but this configuration
> > doesn't seem to be stable and occasionally the bridge doesn't come up
> > properly.
> >
> > We are still in the process of verifying if the reversed order fixes
> > this reliably. But regardless of the results, without the reversal the
> > initialization sequence is way out of spec and we need to fix this in
> > any case.
> >
> > See here for my testing branch including some follow-up patches that
> > improve the initialization flow for my setup:
> > https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.
>
> To recap my thoughts on the two hacks for the DSIM bridge driver
> discussed before:
>
> (1) Passing null to previous bridge in samsung_dsim_attach()
> (2) Always initialize host on first transfer (see this patch, 06/14)
>
> My wild guess would be that both could be fixed up properly in the long
> run by the following changes:
>
> * Apply Dave's patchset [1]
> * Set pre_enable_prev_first flag in the downstream bridge drivers and
>   fix init flow if required ([2] for ti-sn65dsi83)
> * Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
> * Only call init on transfer when not already initialized and deinit
>   after transfer (tbd)
>
> As that route needs proper testing on the affected hardware setups and
> includes changes to other drivers and the framework, I would suggest the
> following for the v9 of this patchset:

I did it on drm-misc-next [1].

>
> * Keep hack (1)

This has gone, not needed.

> * Make hack (2) dependent on the platform (Exynos)

I think with pre_enable_prev_first flag the Exynos pipeline will start
from bridge funcs like pre_enable so initializing the host will work
for exynos to work. [2]

Marek Sz. Can you confirm this?

[1] https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v9
[2] https://gitlab.com/openedev/kernel/-/commit/95ab71b797310952284fabfbc8476a9831902c5c

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Jagan Teki]

On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 05.12.22 16:37, Frieder Schrempf wrote:
> > Hi Dave,
> >
> > On 05.12.22 16:20, Dave Stevenson wrote:
> >> Hi Frieder
> >>
> >> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
> >> <frieder.schrempf@kontron.de> wrote:
> >>>
> >>> On 02.12.22 15:55, Dave Stevenson wrote:
> >>>> Hi Marek
> >>>>
> >>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
> >>>>>>
> >>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
> >>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
> >>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
> >>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
> >>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
> >>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
> >>>>>>>>>>>>> configured downstream bridges.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
> >>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
> >>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
> >>>>>>>>>>>>> and enable in order to initialize or set up the host.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
> >>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
> >>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
> >>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
> >>>>>>>>>>>>> Szyprowski).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v8, v7, v6, v5:
> >>>>>>>>>>>>> * none
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v4:
> >>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v3:
> >>>>>>>>>>>>> * none
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v2:
> >>>>>>>>>>>>> * check initialized state in samsung_dsim_init
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> v1:
> >>>>>>>>>>>>> * keep DSI init in host transfer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>>       drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
> >>>>>>>>>>>>>       include/drm/bridge/samsung-dsim.h     |  5 +++--
> >>>>>>>>>>>>>       2 files changed, 20 insertions(+), 10 deletions(-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
> >>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
> >>>>>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>>>>           disable_irq(dsi->irq);
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>       -static int samsung_dsim_init(struct samsung_dsim *dsi)
> >>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
> >>>>>>>>>>>>> flag)
> >>>>>>>>>>>>>       {
> >>>>>>>>>>>>>           const struct samsung_dsim_driver_data *driver_data =
> >>>>>>>>>>>>> dsi->driver_data;
> >>>>>>>>>>>>>       +    if (dsi->state & flag)
> >>>>>>>>>>>>> +        return 0;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>           samsung_dsim_reset(dsi);
> >>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
> >>>>>>>>>>>>>             if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
> >>>>>>>>>>>>>               samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
> >>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
> >>>>>>>>>>>>> samsung_dsim *dsi)
> >>>>>>>>>>>>>           samsung_dsim_set_phy_ctrl(dsi);
> >>>>>>>>>>>>>           samsung_dsim_init_link(dsi);
> >>>>>>>>>>>>>       +    dsi->state |= flag;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>           return 0;
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>       @@ -1269,6 +1276,10 @@ static void
> >>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>           }
> >>>>>>>>>>>>>             dsi->state |= DSIM_STATE_ENABLED;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> >>>>>>>>>>>>> +    if (ret)
> >>>>>>>>>>>>> +        return;
> >>>>>>>>>>>>>       }
> >>>>>>>>>>>>>         static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
> >>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
> >>>>>>>>>>>>>           if (!(dsi->state & DSIM_STATE_ENABLED))
> >>>>>>>>>>>>>               return -EINVAL;
> >>>>>>>>>>>>>       -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> >>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
> >>>>>>>>>>>>> -        if (ret)
> >>>>>>>>>>>>> -            return ret;
> >>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
> >>>>>>>>>>>>> -    }
> >>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> >>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
> >>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
> >>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
> >>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
> >>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
> >>>>>>>>>>> on the first transfer in case of Exynos?
> >>>>>>>>>> That's odd , it does actually break panel support for me, without this
> >>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
> >>>>>>>>>> a full reset be necessary at all , even on the exynos ?
> >>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
> >>>>>>>>> whether a reset is required before calling it might fix the issue.  I
> >>>>>>>>> agree with double initialization is odd but it seems it is required on
> >>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
> >>>>>>>>> code might resolve this discrepancy.
> >>>>>>>> Can someone provide further details on the exynos problem ?
> >>>>>>> If I'm correct this sequence is required in order to work the existing
> >>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
> >>>>>>> possibly fix the sequence further.
> >>>>>>>
> >>>>>>> Marek Szyprowski, please add if you have anything.
> >>>>>>
> >>>>>>
> >>>>>> Well, frankly speaking the double initialization is not a correct
> >>>>>> sequence, but this is the only one that actually works on Exynos based
> >>>>>> boards with DSI panels after moving the initialization to bridge's
> >>>>>> .prepare() callback.
> >>>>>
> >>>>> Somehow, I suspect this is related to the LP11 mode handling, which
> >>>>> differs for different panels, right ? I think the RPi people worked on
> >>>>> fixing that.
> >>>>>
> >>>>> +CC Dave
> >>>>
> >>>> Yes. I've just sent out a v3 of that patch set.
> >>>>
> >>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
> >>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
> >>>> more sensible initialisation order for your panel.
> >>>>
> >>>> Note that host_transfer should ensure that the host is initialised, as
> >>>> it is valid to call it with the host in any state. If it has to
> >>>> initialise, then it should deinitialise once the transfer has
> >>>> completed.
> >>>>
> >>>> Dave
> >>>>
> >>>>>> I've already explained this and shared the results
> >>>>>> of my investigation in my replies to the previous versions of this
> >>>>>> patchset. The original Exynos DSI driver does the initialization on the
> >>>>>> first DSI command. This however doesn't work for Jagan with I2C
> >>>>>> controlled panels/bridges, so he moved the initialization to the
> >>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
> >>>>>> panels works fine only if the DSI host initialization is done AFTER
> >>>>>> turning the panel's power on). For more information, see this thread:
> >>>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fe96197f9-948a-997e-5453-9f9d179b5f5a%40samsung.com%2F&amp;data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cee7b57ee420e45a73b1d08dad6d45306%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638058504671330145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TQIIKNa4OVGP1dZo3tM%2FOMO3dlXrjLr04U%2FJFhd2rAs%3D&amp;reserved=0
> >>>>>>
> >>>>>> Now, the more I think of it, the more I'm convinced that we simply
> >>>>>> should add a hack based on the HW type: do the initialization in
> >>>>>> .prepare() for non-Exynos case and before the first transfer for the
> >>>>>> Exynos case, as there is no way to detect the panel/next bridge type
> >>>>>> (I2C or DSI controlled).
> >>>>>
> >>>>> Let's see what Dave has to say about this, maybe there is some further help.
> >>>
> >>> Could we agree on adding the HW type based hack Marek S. proposed as a
> >>> quick fix?
> >>>
> >>> This patchset was tested on Exynos so it's likely to not break any
> >>> existing setups. And for i.MX8, this is a new driver so there's not
> >>> really a requirement to have all setups working/supported from the
> >>> beginning.
> >>>
> >>> Also having one or two hacks (marked with FIXME) in the code doesn't
> >>> hurt. As we can see there are drafts to fix them in conjunction with
> >>> changes in the DRM framework.
> >>>
> >>> This has been pending for months and in my opinion if there's a chance
> >>> to get this into v6.2-rc1 we should take it.
> >>
> >> My patchset was sent in March with no one seeming to care enough to review it.
> >
> > I wasn't referring to your patchset but rather to the Samsung DSIM
> > bridge transformation patchset.
> >
> > My point was simply to not try getting everything done in one big step
> > because this will fail. The patchset this refers to needs testing on two
> > separate platforms which is painful enough (thanks to Marek for covering
> > the Exynos side!). I think we should focus on getting the DSIM bridge
> > transformation merged and accept a few small hacks that will be taken
> > care of in the next step.
> >
> >>
> >> If the situation is that your devices fall into the same camp as those
> >> for vc4 (the host needs to be initialised before the peripheral), at
> >> least verifying that would be useful before rushing into a hack.
> >>
> >> Your other comment references using a TI SN65DSI84. I know for certain
> >> that falls into the category of needing the DSI bus initialised before
> >> it is brought out of reset.
> >
> > I'm actually working on this right now and when I received your message
> > I was about to start typing a reply to your patchset.
> >
> > The SN65DSI84 works with the i.MX8MM DSIM even using the default order
> > of host init after peripheral init in our setup, but this configuration
> > doesn't seem to be stable and occasionally the bridge doesn't come up
> > properly.
> >
> > We are still in the process of verifying if the reversed order fixes
> > this reliably. But regardless of the results, without the reversal the
> > initialization sequence is way out of spec and we need to fix this in
> > any case.
> >
> > See here for my testing branch including some follow-up patches that
> > improve the initialization flow for my setup:
> > https://git.kontron-electronics.de/sw/misc/linux/-/commits/v6.1-dsim-mx8mm.
>
> To recap my thoughts on the two hacks for the DSIM bridge driver
> discussed before:
>
> (1) Passing null to previous bridge in samsung_dsim_attach()
> (2) Always initialize host on first transfer (see this patch, 06/14)
>
> My wild guess would be that both could be fixed up properly in the long
> run by the following changes:
>
> * Apply Dave's patchset [1]
> * Set pre_enable_prev_first flag in the downstream bridge drivers and
>   fix init flow if required ([2] for ti-sn65dsi83)
> * Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
> * Only call init on transfer when not already initialized and deinit
>   after transfer (tbd)
>
> As that route needs proper testing on the affected hardware setups and
> includes changes to other drivers and the framework, I would suggest the
> following for the v9 of this patchset:

I did it on drm-misc-next [1].

>
> * Keep hack (1)

This has gone, not needed.

> * Make hack (2) dependent on the platform (Exynos)

I think with pre_enable_prev_first flag the Exynos pipeline will start
from bridge funcs like pre_enable so initializing the host will work
for exynos to work. [2]

Marek Sz. Can you confirm this?

[1] https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v9
[2] https://gitlab.com/openedev/kernel/-/commit/95ab71b797310952284fabfbc8476a9831902c5c

Jagan.

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

On 08.12.2022 12:32, Jagan Teki wrote:
> On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>> On 05.12.22 16:37, Frieder Schrempf wrote:
>>> Hi Dave,
>>>
>>> On 05.12.22 16:20, Dave Stevenson wrote:
>>>> Hi Frieder
>>>>
>>>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>>>> <frieder.schrempf@kontron.de> wrote:
>>>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>>>> Hi Marek
>>>>>>
>>>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>>>>
>>>>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>>>>> * none
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v4:
>>>>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v3:
>>>>>>>>>>>>>>> * none
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v2:
>>>>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v1:
>>>>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>        drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>>>>        include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>>>>        2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>>>            disable_irq(dsi->irq);
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>        -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>>>>> flag)
>>>>>>>>>>>>>>>        {
>>>>>>>>>>>>>>>            const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>>>>        +    if (dsi->state & flag)
>>>>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>            samsung_dsim_reset(dsi);
>>>>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>>>              if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>>>>                samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>>>            samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>>>>            samsung_dsim_init_link(dsi);
>>>>>>>>>>>>>>>        +    dsi->state |= flag;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>            return 0;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>        @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>>>              dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>>>>> +        return;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>          static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>>>>            if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>>>>                return -EINVAL;
>>>>>>>>>>>>>>>        -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>>>>> -    }
>>>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>>>>> code might resolve this discrepancy.
>>>>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>>>>> possibly fix the sequence further.
>>>>>>>>>
>>>>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>>>>
>>>>>>>> Well, frankly speaking the double initialization is not a correct
>>>>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>>>>> .prepare() callback.
>>>>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>>>>> differs for different panels, right ? I think the RPi people worked on
>>>>>>> fixing that.
>>>>>>>
>>>>>>> +CC Dave
>>>>>> Yes. I've just sent out a v3 of that patch set.
>>>>>>
>>>>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>>>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>>>>> more sensible initialisation order for your panel.
>>>>>>
>>>>>> Note that host_transfer should ensure that the host is initialised, as
>>>>>> it is valid to call it with the host in any state. If it has to
>>>>>> initialise, then it should deinitialise once the transfer has
>>>>>> completed.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>>> I've already explained this and shared the results
>>>>>>>> of my investigation in my replies to the previous versions of this
>>>>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>>>>> turning the panel's power on). For more information, see this thread:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=b96d9a6f-d8e68f59-b96c1120-74fe485fffe0-6f8ca12c5049bf4e&q=1&e=b9def28e-897a-4edd-bfe3-86e02b64eb27&u=https%3A%2F%2Feur04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Flore.kernel.org%252Fall%252Fe96197f9-948a-997e-5453-9f9d179b5f5a%2540samsung.com%252F%26amp%3Bdata%3D05%257C01%257Cfrieder.schrempf%2540kontron.de%257Cee7b57ee420e45a73b1d08dad6d45306%257C8c9d3c973fd941c8a2b1646f3942daf1%257C0%257C0%257C638058504671330145%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DTQIIKNa4OVGP1dZo3tM%252FOMO3dlXrjLr04U%252FJFhd2rAs%253D%26amp%3Breserved%3D0
>>>>>>>>
>>>>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>>>>> should add a hack based on the HW type: do the initialization in
>>>>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>>>>> (I2C or DSI controlled).
>>>>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>>>> Could we agree on adding the HW type based hack Marek S. proposed as a
>>>>> quick fix?
>>>>>
>>>>> This patchset was tested on Exynos so it's likely to not break any
>>>>> existing setups. And for i.MX8, this is a new driver so there's not
>>>>> really a requirement to have all setups working/supported from the
>>>>> beginning.
>>>>>
>>>>> Also having one or two hacks (marked with FIXME) in the code doesn't
>>>>> hurt. As we can see there are drafts to fix them in conjunction with
>>>>> changes in the DRM framework.
>>>>>
>>>>> This has been pending for months and in my opinion if there's a chance
>>>>> to get this into v6.2-rc1 we should take it.
>>>> My patchset was sent in March with no one seeming to care enough to review it.
>>> I wasn't referring to your patchset but rather to the Samsung DSIM
>>> bridge transformation patchset.
>>>
>>> My point was simply to not try getting everything done in one big step
>>> because this will fail. The patchset this refers to needs testing on two
>>> separate platforms which is painful enough (thanks to Marek for covering
>>> the Exynos side!). I think we should focus on getting the DSIM bridge
>>> transformation merged and accept a few small hacks that will be taken
>>> care of in the next step.
>>>
>>>> If the situation is that your devices fall into the same camp as those
>>>> for vc4 (the host needs to be initialised before the peripheral), at
>>>> least verifying that would be useful before rushing into a hack.
>>>>
>>>> Your other comment references using a TI SN65DSI84. I know for certain
>>>> that falls into the category of needing the DSI bus initialised before
>>>> it is brought out of reset.
>>> I'm actually working on this right now and when I received your message
>>> I was about to start typing a reply to your patchset.
>>>
>>> The SN65DSI84 works with the i.MX8MM DSIM even using the default order
>>> of host init after peripheral init in our setup, but this configuration
>>> doesn't seem to be stable and occasionally the bridge doesn't come up
>>> properly.
>>>
>>> We are still in the process of verifying if the reversed order fixes
>>> this reliably. But regardless of the results, without the reversal the
>>> initialization sequence is way out of spec and we need to fix this in
>>> any case.
>>>
>>> See here for my testing branch including some follow-up patches that
>>> improve the initialization flow for my setup:
>>> https://protect2.fireeye.com/v1/url?k=0a67acf1-6becb9c7-0a6627be-74fe485fffe0-38ee812d7e32f480&q=1&e=b9def28e-897a-4edd-bfe3-86e02b64eb27&u=https%3A%2F%2Fgit.kontron-electronics.de%2Fsw%2Fmisc%2Flinux%2F-%2Fcommits%2Fv6.1-dsim-mx8mm.
>> To recap my thoughts on the two hacks for the DSIM bridge driver
>> discussed before:
>>
>> (1) Passing null to previous bridge in samsung_dsim_attach()
>> (2) Always initialize host on first transfer (see this patch, 06/14)
>>
>> My wild guess would be that both could be fixed up properly in the long
>> run by the following changes:
>>
>> * Apply Dave's patchset [1]
>> * Set pre_enable_prev_first flag in the downstream bridge drivers and
>>    fix init flow if required ([2] for ti-sn65dsi83)
>> * Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
>> * Only call init on transfer when not already initialized and deinit
>>    after transfer (tbd)
>>
>> As that route needs proper testing on the affected hardware setups and
>> includes changes to other drivers and the framework, I would suggest the
>> following for the v9 of this patchset:
> I did it on drm-misc-next [1].
>
>> * Keep hack (1)
> This has gone, not needed.
>
>> * Make hack (2) dependent on the platform (Exynos)
> I think with pre_enable_prev_first flag the Exynos pipeline will start
> from bridge funcs like pre_enable so initializing the host will work
> for exynos to work. [2]
>
> Marek Sz. Can you confirm this?

Host initialization is orthogonal to the hack used on the bridge list. 
Dave's patchset removes the need for that hack, but the DSI host still 
has to be initialized on the first DSI command transfer for Exynos HW, 
otherwise the tested DSI panels display nothing.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

On 08.12.2022 12:32, Jagan Teki wrote:
> On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>> On 05.12.22 16:37, Frieder Schrempf wrote:
>>> Hi Dave,
>>>
>>> On 05.12.22 16:20, Dave Stevenson wrote:
>>>> Hi Frieder
>>>>
>>>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>>>> <frieder.schrempf@kontron.de> wrote:
>>>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>>>> Hi Marek
>>>>>>
>>>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>>>>
>>>>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>>>>> * none
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v4:
>>>>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v3:
>>>>>>>>>>>>>>> * none
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v2:
>>>>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v1:
>>>>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>        drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>>>>        include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>>>>        2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>>>            disable_irq(dsi->irq);
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>        -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>>>>> flag)
>>>>>>>>>>>>>>>        {
>>>>>>>>>>>>>>>            const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>>>>        +    if (dsi->state & flag)
>>>>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>            samsung_dsim_reset(dsi);
>>>>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>>>              if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>>>>                samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>>>            samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>>>>            samsung_dsim_init_link(dsi);
>>>>>>>>>>>>>>>        +    dsi->state |= flag;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>            return 0;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>        @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>>>              dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>>>>> +        return;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>          static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>>>>            if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>>>>                return -EINVAL;
>>>>>>>>>>>>>>>        -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>>>>> -    }
>>>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>>>>> code might resolve this discrepancy.
>>>>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>>>>> possibly fix the sequence further.
>>>>>>>>>
>>>>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>>>>
>>>>>>>> Well, frankly speaking the double initialization is not a correct
>>>>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>>>>> .prepare() callback.
>>>>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>>>>> differs for different panels, right ? I think the RPi people worked on
>>>>>>> fixing that.
>>>>>>>
>>>>>>> +CC Dave
>>>>>> Yes. I've just sent out a v3 of that patch set.
>>>>>>
>>>>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>>>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>>>>> more sensible initialisation order for your panel.
>>>>>>
>>>>>> Note that host_transfer should ensure that the host is initialised, as
>>>>>> it is valid to call it with the host in any state. If it has to
>>>>>> initialise, then it should deinitialise once the transfer has
>>>>>> completed.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>>> I've already explained this and shared the results
>>>>>>>> of my investigation in my replies to the previous versions of this
>>>>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>>>>> turning the panel's power on). For more information, see this thread:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=b96d9a6f-d8e68f59-b96c1120-74fe485fffe0-6f8ca12c5049bf4e&q=1&e=b9def28e-897a-4edd-bfe3-86e02b64eb27&u=https%3A%2F%2Feur04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Flore.kernel.org%252Fall%252Fe96197f9-948a-997e-5453-9f9d179b5f5a%2540samsung.com%252F%26amp%3Bdata%3D05%257C01%257Cfrieder.schrempf%2540kontron.de%257Cee7b57ee420e45a73b1d08dad6d45306%257C8c9d3c973fd941c8a2b1646f3942daf1%257C0%257C0%257C638058504671330145%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DTQIIKNa4OVGP1dZo3tM%252FOMO3dlXrjLr04U%252FJFhd2rAs%253D%26amp%3Breserved%3D0
>>>>>>>>
>>>>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>>>>> should add a hack based on the HW type: do the initialization in
>>>>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>>>>> (I2C or DSI controlled).
>>>>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>>>> Could we agree on adding the HW type based hack Marek S. proposed as a
>>>>> quick fix?
>>>>>
>>>>> This patchset was tested on Exynos so it's likely to not break any
>>>>> existing setups. And for i.MX8, this is a new driver so there's not
>>>>> really a requirement to have all setups working/supported from the
>>>>> beginning.
>>>>>
>>>>> Also having one or two hacks (marked with FIXME) in the code doesn't
>>>>> hurt. As we can see there are drafts to fix them in conjunction with
>>>>> changes in the DRM framework.
>>>>>
>>>>> This has been pending for months and in my opinion if there's a chance
>>>>> to get this into v6.2-rc1 we should take it.
>>>> My patchset was sent in March with no one seeming to care enough to review it.
>>> I wasn't referring to your patchset but rather to the Samsung DSIM
>>> bridge transformation patchset.
>>>
>>> My point was simply to not try getting everything done in one big step
>>> because this will fail. The patchset this refers to needs testing on two
>>> separate platforms which is painful enough (thanks to Marek for covering
>>> the Exynos side!). I think we should focus on getting the DSIM bridge
>>> transformation merged and accept a few small hacks that will be taken
>>> care of in the next step.
>>>
>>>> If the situation is that your devices fall into the same camp as those
>>>> for vc4 (the host needs to be initialised before the peripheral), at
>>>> least verifying that would be useful before rushing into a hack.
>>>>
>>>> Your other comment references using a TI SN65DSI84. I know for certain
>>>> that falls into the category of needing the DSI bus initialised before
>>>> it is brought out of reset.
>>> I'm actually working on this right now and when I received your message
>>> I was about to start typing a reply to your patchset.
>>>
>>> The SN65DSI84 works with the i.MX8MM DSIM even using the default order
>>> of host init after peripheral init in our setup, but this configuration
>>> doesn't seem to be stable and occasionally the bridge doesn't come up
>>> properly.
>>>
>>> We are still in the process of verifying if the reversed order fixes
>>> this reliably. But regardless of the results, without the reversal the
>>> initialization sequence is way out of spec and we need to fix this in
>>> any case.
>>>
>>> See here for my testing branch including some follow-up patches that
>>> improve the initialization flow for my setup:
>>> https://protect2.fireeye.com/v1/url?k=0a67acf1-6becb9c7-0a6627be-74fe485fffe0-38ee812d7e32f480&q=1&e=b9def28e-897a-4edd-bfe3-86e02b64eb27&u=https%3A%2F%2Fgit.kontron-electronics.de%2Fsw%2Fmisc%2Flinux%2F-%2Fcommits%2Fv6.1-dsim-mx8mm.
>> To recap my thoughts on the two hacks for the DSIM bridge driver
>> discussed before:
>>
>> (1) Passing null to previous bridge in samsung_dsim_attach()
>> (2) Always initialize host on first transfer (see this patch, 06/14)
>>
>> My wild guess would be that both could be fixed up properly in the long
>> run by the following changes:
>>
>> * Apply Dave's patchset [1]
>> * Set pre_enable_prev_first flag in the downstream bridge drivers and
>>    fix init flow if required ([2] for ti-sn65dsi83)
>> * Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
>> * Only call init on transfer when not already initialized and deinit
>>    after transfer (tbd)
>>
>> As that route needs proper testing on the affected hardware setups and
>> includes changes to other drivers and the framework, I would suggest the
>> following for the v9 of this patchset:
> I did it on drm-misc-next [1].
>
>> * Keep hack (1)
> This has gone, not needed.
>
>> * Make hack (2) dependent on the platform (Exynos)
> I think with pre_enable_prev_first flag the Exynos pipeline will start
> from bridge funcs like pre_enable so initializing the host will work
> for exynos to work. [2]
>
> Marek Sz. Can you confirm this?

Host initialization is orthogonal to the hack used on the bridge list. 
Dave's patchset removes the need for that hack, but the DSI host still 
has to be initialized on the first DSI command transfer for Exynos HW, 
otherwise the tested DSI panels display nothing.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization

[Marek Szyprowski]

On 08.12.2022 12:32, Jagan Teki wrote:
> On Tue, Dec 6, 2022 at 2:32 PM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>> On 05.12.22 16:37, Frieder Schrempf wrote:
>>> Hi Dave,
>>>
>>> On 05.12.22 16:20, Dave Stevenson wrote:
>>>> Hi Frieder
>>>>
>>>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>>>> <frieder.schrempf@kontron.de> wrote:
>>>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>>>> Hi Marek
>>>>>>
>>>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>>>>>>
>>>>>>>> On 28.11.2022 15:43, Jagan Teki wrote:
>>>>>>>>> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>>>>> On 11/17/22 14:04, Marek Szyprowski wrote:
>>>>>>>>>>>>> On 17.11.2022 05:58, Marek Vasut wrote:
>>>>>>>>>>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>>>>>>>>>>> DSI host initialization handling in previous exynos dsi driver has
>>>>>>>>>>>>>>> some pitfalls. It initializes the host during host transfer() hook
>>>>>>>>>>>>>>> that is indeed not the desired call flow for I2C and any other DSI
>>>>>>>>>>>>>>> configured downstream bridges.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Host transfer() is usually triggered for downstream DSI panels or
>>>>>>>>>>>>>>> bridges and I2C-configured-DSI bridges miss these host initialization
>>>>>>>>>>>>>>> as these downstream bridges use bridge operations hooks like pre_enable,
>>>>>>>>>>>>>>> and enable in order to initialize or set up the host.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch is trying to handle the host init handler to satisfy all
>>>>>>>>>>>>>>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED state
>>>>>>>>>>>>>>> flag to ensure that host init is also done on first cmd transfer, this
>>>>>>>>>>>>>>> helps existing DSI panels work on exynos platform (form Marek
>>>>>>>>>>>>>>> Szyprowski).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v8, v7, v6, v5:
>>>>>>>>>>>>>>> * none
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v4:
>>>>>>>>>>>>>>> * update init handling to ensure host init done on first cmd transfer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v3:
>>>>>>>>>>>>>>> * none
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v2:
>>>>>>>>>>>>>>> * check initialized state in samsung_dsim_init
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> v1:
>>>>>>>>>>>>>>> * keep DSI init in host transfer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>        drivers/gpu/drm/bridge/samsung-dsim.c | 25 +++++++++++++++++--------
>>>>>>>>>>>>>>>        include/drm/bridge/samsung-dsim.h     |  5 +++--
>>>>>>>>>>>>>>>        2 files changed, 20 insertions(+), 10 deletions(-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> index bb1f45fd5a88..ec7e01ae02ea 100644
>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>>>>>>>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>>>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>>>            disable_irq(dsi->irq);
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>        -static int samsung_dsim_init(struct samsung_dsim *dsi)
>>>>>>>>>>>>>>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>>>>>>>>>>>>>>> flag)
>>>>>>>>>>>>>>>        {
>>>>>>>>>>>>>>>            const struct samsung_dsim_driver_data *driver_data =
>>>>>>>>>>>>>>> dsi->driver_data;
>>>>>>>>>>>>>>>        +    if (dsi->state & flag)
>>>>>>>>>>>>>>> +        return 0;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>            samsung_dsim_reset(dsi);
>>>>>>>>>>>>>>> -    samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +    if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>>>>>>>> +        samsung_dsim_enable_irq(dsi);
>>>>>>>>>>>>>>>              if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>>>>>>>>>>>>>>>                samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>>>>>>>>>>>>>>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>>>>>>>>>>>>>>> samsung_dsim *dsi)
>>>>>>>>>>>>>>>            samsung_dsim_set_phy_ctrl(dsi);
>>>>>>>>>>>>>>>            samsung_dsim_init_link(dsi);
>>>>>>>>>>>>>>>        +    dsi->state |= flag;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>            return 0;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>        @@ -1269,6 +1276,10 @@ static void
>>>>>>>>>>>>>>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>>>              dsi->state |= DSIM_STATE_ENABLED;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>>>>>>>>>>>> +    if (ret)
>>>>>>>>>>>>>>> +        return;
>>>>>>>>>>>>>>>        }
>>>>>>>>>>>>>>>          static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>> @@ -1458,12 +1469,9 @@ static ssize_t
>>>>>>>>>>>>>>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>>>>>>>>>>>>>>>            if (!(dsi->state & DSIM_STATE_ENABLED))
>>>>>>>>>>>>>>>                return -EINVAL;
>>>>>>>>>>>>>>>        -    if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>>>>>>>>>>>>>>> -        ret = samsung_dsim_init(dsi);
>>>>>>>>>>>>>>> -        if (ret)
>>>>>>>>>>>>>>> -            return ret;
>>>>>>>>>>>>>>> -        dsi->state |= DSIM_STATE_INITIALIZED;
>>>>>>>>>>>>>>> -    }
>>>>>>>>>>>>>>> +    ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>>>>>>>>>>>>>> This triggers full controller reset and reprogramming upon first
>>>>>>>>>>>>>> command transfer, is such heavy handed reload really necessary ?
>>>>>>>>>>>>> Yes it is, otherwise the proper DSI panels doesn't work with Exynos DRM
>>>>>>>>>>>>> DSI. If this is a real issue for you, then maybe the driver could do the
>>>>>>>>>>>>> initialization conditionally, in prepare() callback in case of IMX and
>>>>>>>>>>>>> on the first transfer in case of Exynos?
>>>>>>>>>>>> That's odd , it does actually break panel support for me, without this
>>>>>>>>>>>> double reset the panel works again. But I have to wonder, why would such
>>>>>>>>>>>> a full reset be necessary at all , even on the exynos ?
>>>>>>>>>>> Is it breaking samsung_dsim_reset from host_transfer? maybe checking
>>>>>>>>>>> whether a reset is required before calling it might fix the issue.  I
>>>>>>>>>>> agree with double initialization is odd but it seems it is required on
>>>>>>>>>>> some panels in Exynos, I think tweaking them and adjusting the panel
>>>>>>>>>>> code might resolve this discrepancy.
>>>>>>>>>> Can someone provide further details on the exynos problem ?
>>>>>>>>> If I'm correct this sequence is required in order to work the existing
>>>>>>>>> panel/bridges on exynos. Adjusting these panel/bridge codes can
>>>>>>>>> possibly fix the sequence further.
>>>>>>>>>
>>>>>>>>> Marek Szyprowski, please add if you have anything.
>>>>>>>>
>>>>>>>> Well, frankly speaking the double initialization is not a correct
>>>>>>>> sequence, but this is the only one that actually works on Exynos based
>>>>>>>> boards with DSI panels after moving the initialization to bridge's
>>>>>>>> .prepare() callback.
>>>>>>> Somehow, I suspect this is related to the LP11 mode handling, which
>>>>>>> differs for different panels, right ? I think the RPi people worked on
>>>>>>> fixing that.
>>>>>>>
>>>>>>> +CC Dave
>>>>>> Yes. I've just sent out a v3 of that patch set.
>>>>>>
>>>>>> Hopefully setting the pre_enable_prev_first flag on your peripheral's
>>>>>> drm_bridge, or prepare_prev_first if a drm_panel, will result in a
>>>>>> more sensible initialisation order for your panel.
>>>>>>
>>>>>> Note that host_transfer should ensure that the host is initialised, as
>>>>>> it is valid to call it with the host in any state. If it has to
>>>>>> initialise, then it should deinitialise once the transfer has
>>>>>> completed.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>>> I've already explained this and shared the results
>>>>>>>> of my investigation in my replies to the previous versions of this
>>>>>>>> patchset. The original Exynos DSI driver does the initialization on the
>>>>>>>> first DSI command. This however doesn't work for Jagan with I2C
>>>>>>>> controlled panels/bridges, so he moved the initialization to the
>>>>>>>> .prepare() callback, what broke the Exynos case (in-short - all tested
>>>>>>>> panels works fine only if the DSI host initialization is done AFTER
>>>>>>>> turning the panel's power on). For more information, see this thread:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=b96d9a6f-d8e68f59-b96c1120-74fe485fffe0-6f8ca12c5049bf4e&q=1&e=b9def28e-897a-4edd-bfe3-86e02b64eb27&u=https%3A%2F%2Feur04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Flore.kernel.org%252Fall%252Fe96197f9-948a-997e-5453-9f9d179b5f5a%2540samsung.com%252F%26amp%3Bdata%3D05%257C01%257Cfrieder.schrempf%2540kontron.de%257Cee7b57ee420e45a73b1d08dad6d45306%257C8c9d3c973fd941c8a2b1646f3942daf1%257C0%257C0%257C638058504671330145%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DTQIIKNa4OVGP1dZo3tM%252FOMO3dlXrjLr04U%252FJFhd2rAs%253D%26amp%3Breserved%3D0
>>>>>>>>
>>>>>>>> Now, the more I think of it, the more I'm convinced that we simply
>>>>>>>> should add a hack based on the HW type: do the initialization in
>>>>>>>> .prepare() for non-Exynos case and before the first transfer for the
>>>>>>>> Exynos case, as there is no way to detect the panel/next bridge type
>>>>>>>> (I2C or DSI controlled).
>>>>>>> Let's see what Dave has to say about this, maybe there is some further help.
>>>>> Could we agree on adding the HW type based hack Marek S. proposed as a
>>>>> quick fix?
>>>>>
>>>>> This patchset was tested on Exynos so it's likely to not break any
>>>>> existing setups. And for i.MX8, this is a new driver so there's not
>>>>> really a requirement to have all setups working/supported from the
>>>>> beginning.
>>>>>
>>>>> Also having one or two hacks (marked with FIXME) in the code doesn't
>>>>> hurt. As we can see there are drafts to fix them in conjunction with
>>>>> changes in the DRM framework.
>>>>>
>>>>> This has been pending for months and in my opinion if there's a chance
>>>>> to get this into v6.2-rc1 we should take it.
>>>> My patchset was sent in March with no one seeming to care enough to review it.
>>> I wasn't referring to your patchset but rather to the Samsung DSIM
>>> bridge transformation patchset.
>>>
>>> My point was simply to not try getting everything done in one big step
>>> because this will fail. The patchset this refers to needs testing on two
>>> separate platforms which is painful enough (thanks to Marek for covering
>>> the Exynos side!). I think we should focus on getting the DSIM bridge
>>> transformation merged and accept a few small hacks that will be taken
>>> care of in the next step.
>>>
>>>> If the situation is that your devices fall into the same camp as those
>>>> for vc4 (the host needs to be initialised before the peripheral), at
>>>> least verifying that would be useful before rushing into a hack.
>>>>
>>>> Your other comment references using a TI SN65DSI84. I know for certain
>>>> that falls into the category of needing the DSI bus initialised before
>>>> it is brought out of reset.
>>> I'm actually working on this right now and when I received your message
>>> I was about to start typing a reply to your patchset.
>>>
>>> The SN65DSI84 works with the i.MX8MM DSIM even using the default order
>>> of host init after peripheral init in our setup, but this configuration
>>> doesn't seem to be stable and occasionally the bridge doesn't come up
>>> properly.
>>>
>>> We are still in the process of verifying if the reversed order fixes
>>> this reliably. But regardless of the results, without the reversal the
>>> initialization sequence is way out of spec and we need to fix this in
>>> any case.
>>>
>>> See here for my testing branch including some follow-up patches that
>>> improve the initialization flow for my setup:
>>> https://protect2.fireeye.com/v1/url?k=0a67acf1-6becb9c7-0a6627be-74fe485fffe0-38ee812d7e32f480&q=1&e=b9def28e-897a-4edd-bfe3-86e02b64eb27&u=https%3A%2F%2Fgit.kontron-electronics.de%2Fsw%2Fmisc%2Flinux%2F-%2Fcommits%2Fv6.1-dsim-mx8mm.
>> To recap my thoughts on the two hacks for the DSIM bridge driver
>> discussed before:
>>
>> (1) Passing null to previous bridge in samsung_dsim_attach()
>> (2) Always initialize host on first transfer (see this patch, 06/14)
>>
>> My wild guess would be that both could be fixed up properly in the long
>> run by the following changes:
>>
>> * Apply Dave's patchset [1]
>> * Set pre_enable_prev_first flag in the downstream bridge drivers and
>>    fix init flow if required ([2] for ti-sn65dsi83)
>> * Fix DSIM init to keep data lanes in LP11 until enable() is called [3]
>> * Only call init on transfer when not already initialized and deinit
>>    after transfer (tbd)
>>
>> As that route needs proper testing on the affected hardware setups and
>> includes changes to other drivers and the framework, I would suggest the
>> following for the v9 of this patchset:
> I did it on drm-misc-next [1].
>
>> * Keep hack (1)
> This has gone, not needed.
>
>> * Make hack (2) dependent on the platform (Exynos)
> I think with pre_enable_prev_first flag the Exynos pipeline will start
> from bridge funcs like pre_enable so initializing the host will work
> for exynos to work. [2]
>
> Marek Sz. Can you confirm this?

Host initialization is orthogonal to the hack used on the bridge list. 
Dave's patchset removes the need for that hack, but the DSI host still 
has to be initialized on the first DSI command transfer for Exynos HW, 
otherwise the tested DSI panels display nothing.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH v8 07/14] drm: bridge: samsung-dsim: Add atomic_check

[Jagan Teki]

Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.

At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work properly.

On the other hand the i.MX 8M Mini Applications Processor Reference Manual,
Rev. 3, 11/2020 says.
"13.6.3.5.2 RGB interface
 Vsync, Hsync, and VDEN are active high signals."

i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
3.6.3.5.2 RGB interface
i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
13.6.2.7.2 RGB interface
both claim "Vsync, Hsync, and VDEN are active high signals.", the
LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.

No clear evidence about whether it can be documentation issues or
something, so added a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

v8:
* update the comments about sync signals polarities
* added clear commit message by including i.MX8M Nano details

v7:
* fix the hw_type checking logic

v6:
* none

v5:
* rebase based new bridge changes [mszyprow]
* remove DSIM_QUIRK_FIXUP_SYNC_POL
* add hw_type check for sync polarities change.

v4:
* none

v3:
* add DSIM_QUIRK_FIXUP_SYNC_POL to handle mode_flasg fixup

v2:
* none

v1:
* fix mode flags in atomic_check instead of mode_fixup

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index ec7e01ae02ea..3c0a8580508b 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1315,6 +1315,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
+				     struct drm_bridge_state *bridge_state,
+				     struct drm_crtc_state *crtc_state,
+				     struct drm_connector_state *conn_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+	struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+
+	/*
+	 * The i.MX8M Mini/Nano glue logic between LCDIF and DSIM
+	 * inverts HS/VS/DE sync signals polarity, therefore, while
+	 * i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
+	 * 13.6.3.5.2 RGB interface
+	 * i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
+	 * 13.6.2.7.2 RGB interface
+	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
+	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 */
+	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) {
+		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	}
+
+	return 0;
+}
+
 static void samsung_dsim_mode_set(struct drm_bridge *bridge,
 				  const struct drm_display_mode *mode,
 				  const struct drm_display_mode *adjusted_mode)
@@ -1353,6 +1379,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_check			= samsung_dsim_atomic_check,
 	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
 	.atomic_enable			= samsung_dsim_atomic_enable,
 	.atomic_disable			= samsung_dsim_atomic_disable,
-- 
2.25.1

[PATCH v8 07/14] drm: bridge: samsung-dsim: Add atomic_check

[Jagan Teki]

Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.

At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work properly.

On the other hand the i.MX 8M Mini Applications Processor Reference Manual,
Rev. 3, 11/2020 says.
"13.6.3.5.2 RGB interface
 Vsync, Hsync, and VDEN are active high signals."

i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
3.6.3.5.2 RGB interface
i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
13.6.2.7.2 RGB interface
both claim "Vsync, Hsync, and VDEN are active high signals.", the
LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.

No clear evidence about whether it can be documentation issues or
something, so added a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

v8:
* update the comments about sync signals polarities
* added clear commit message by including i.MX8M Nano details

v7:
* fix the hw_type checking logic

v6:
* none

v5:
* rebase based new bridge changes [mszyprow]
* remove DSIM_QUIRK_FIXUP_SYNC_POL
* add hw_type check for sync polarities change.

v4:
* none

v3:
* add DSIM_QUIRK_FIXUP_SYNC_POL to handle mode_flasg fixup

v2:
* none

v1:
* fix mode flags in atomic_check instead of mode_fixup

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index ec7e01ae02ea..3c0a8580508b 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1315,6 +1315,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
+				     struct drm_bridge_state *bridge_state,
+				     struct drm_crtc_state *crtc_state,
+				     struct drm_connector_state *conn_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+	struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+
+	/*
+	 * The i.MX8M Mini/Nano glue logic between LCDIF and DSIM
+	 * inverts HS/VS/DE sync signals polarity, therefore, while
+	 * i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
+	 * 13.6.3.5.2 RGB interface
+	 * i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
+	 * 13.6.2.7.2 RGB interface
+	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
+	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 */
+	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) {
+		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	}
+
+	return 0;
+}
+
 static void samsung_dsim_mode_set(struct drm_bridge *bridge,
 				  const struct drm_display_mode *mode,
 				  const struct drm_display_mode *adjusted_mode)
@@ -1353,6 +1379,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_check			= samsung_dsim_atomic_check,
 	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
 	.atomic_enable			= samsung_dsim_atomic_enable,
 	.atomic_disable			= samsung_dsim_atomic_disable,
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 07/14] drm: bridge: samsung-dsim: Add atomic_check

[Jagan Teki]

Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.

At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work properly.

On the other hand the i.MX 8M Mini Applications Processor Reference Manual,
Rev. 3, 11/2020 says.
"13.6.3.5.2 RGB interface
 Vsync, Hsync, and VDEN are active high signals."

i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
3.6.3.5.2 RGB interface
i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
13.6.2.7.2 RGB interface
both claim "Vsync, Hsync, and VDEN are active high signals.", the
LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.

No clear evidence about whether it can be documentation issues or
something, so added a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

v8:
* update the comments about sync signals polarities
* added clear commit message by including i.MX8M Nano details

v7:
* fix the hw_type checking logic

v6:
* none

v5:
* rebase based new bridge changes [mszyprow]
* remove DSIM_QUIRK_FIXUP_SYNC_POL
* add hw_type check for sync polarities change.

v4:
* none

v3:
* add DSIM_QUIRK_FIXUP_SYNC_POL to handle mode_flasg fixup

v2:
* none

v1:
* fix mode flags in atomic_check instead of mode_fixup

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index ec7e01ae02ea..3c0a8580508b 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1315,6 +1315,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
+				     struct drm_bridge_state *bridge_state,
+				     struct drm_crtc_state *crtc_state,
+				     struct drm_connector_state *conn_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+	struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+
+	/*
+	 * The i.MX8M Mini/Nano glue logic between LCDIF and DSIM
+	 * inverts HS/VS/DE sync signals polarity, therefore, while
+	 * i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
+	 * 13.6.3.5.2 RGB interface
+	 * i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
+	 * 13.6.2.7.2 RGB interface
+	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
+	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 */
+	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) {
+		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	}
+
+	return 0;
+}
+
 static void samsung_dsim_mode_set(struct drm_bridge *bridge,
 				  const struct drm_display_mode *mode,
 				  const struct drm_display_mode *adjusted_mode)
@@ -1353,6 +1379,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_check			= samsung_dsim_atomic_check,
 	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
 	.atomic_enable			= samsung_dsim_atomic_enable,
 	.atomic_disable			= samsung_dsim_atomic_disable,
-- 
2.25.1

[PATCH v8 08/14] drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset

[Jagan Teki]

Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.

However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.

The offset 13 is not working for i.MX8M Mini SoCs but the downstream
NXP sec-dsim.c driver is using offset 14 for i.MX8M Mini SoC platforms
[1] [2].

PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P()
with offset 13 and then an additional offset of one bit added in
sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS().

Not sure whether it is reference manual documentation or something else
but this patch trusts the downstream code and handle PLL_P offset via
platform driver data so-that imx8mm driver data shall use pll_p_offset
to 14.

Similar to Mini the i.MX8M Nano/Plus also has P=14, unlike Exynos.

[1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n210
[2] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211

v8:
* updated commit message for 8M Nano/Plus
* collect Marek Ack

v7, v6:
* none

v5:
* updated clear commit message

v4, v3, v2:
* none

v1:
* updated commit message
* add downstream driver link

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 10 ++++++++--
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 3c0a8580508b..0fe153b29e4f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -168,7 +168,7 @@
 /* DSIM_PLLCTRL */
 #define DSIM_FREQ_BAND(x)		((x) << 24)
 #define DSIM_PLL_EN			(1 << 23)
-#define DSIM_PLL_P(x)			((x) << 13)
+#define DSIM_PLL_P(x, offset)		((x) << (offset))
 #define DSIM_PLL_M(x)			((x) << 4)
 #define DSIM_PLL_S(x)			((x) << 1)
 
@@ -368,6 +368,7 @@ static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -380,6 +381,7 @@ static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -390,6 +392,7 @@ static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -401,6 +404,7 @@ static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 0,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5433_reg_values,
 };
 
@@ -412,6 +416,7 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 1,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5422_reg_values,
 };
 
@@ -543,7 +548,8 @@ static unsigned long samsung_dsim_set_pll(struct samsung_dsim *dsi,
 	writel(driver_data->reg_values[PLL_TIMER],
 			dsi->reg_base + driver_data->plltmr_reg);
 
-	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+	reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
+	      DSIM_PLL_M(m) | DSIM_PLL_S(s);
 
 	if (driver_data->has_freqband) {
 		static const unsigned long freq_bands[] = {
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index 0c5a905f3de7..df3d030daec6 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -53,6 +53,7 @@ struct samsung_dsim_driver_data {
 	unsigned int max_freq;
 	unsigned int wait_for_reset;
 	unsigned int num_bits_resol;
+	unsigned int pll_p_offset;
 	const unsigned int *reg_values;
 };
 
-- 
2.25.1

[PATCH v8 08/14] drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset

[Jagan Teki]

Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.

However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.

The offset 13 is not working for i.MX8M Mini SoCs but the downstream
NXP sec-dsim.c driver is using offset 14 for i.MX8M Mini SoC platforms
[1] [2].

PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P()
with offset 13 and then an additional offset of one bit added in
sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS().

Not sure whether it is reference manual documentation or something else
but this patch trusts the downstream code and handle PLL_P offset via
platform driver data so-that imx8mm driver data shall use pll_p_offset
to 14.

Similar to Mini the i.MX8M Nano/Plus also has P=14, unlike Exynos.

[1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n210
[2] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211

v8:
* updated commit message for 8M Nano/Plus
* collect Marek Ack

v7, v6:
* none

v5:
* updated clear commit message

v4, v3, v2:
* none

v1:
* updated commit message
* add downstream driver link

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 10 ++++++++--
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 3c0a8580508b..0fe153b29e4f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -168,7 +168,7 @@
 /* DSIM_PLLCTRL */
 #define DSIM_FREQ_BAND(x)		((x) << 24)
 #define DSIM_PLL_EN			(1 << 23)
-#define DSIM_PLL_P(x)			((x) << 13)
+#define DSIM_PLL_P(x, offset)		((x) << (offset))
 #define DSIM_PLL_M(x)			((x) << 4)
 #define DSIM_PLL_S(x)			((x) << 1)
 
@@ -368,6 +368,7 @@ static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -380,6 +381,7 @@ static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -390,6 +392,7 @@ static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -401,6 +404,7 @@ static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 0,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5433_reg_values,
 };
 
@@ -412,6 +416,7 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 1,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5422_reg_values,
 };
 
@@ -543,7 +548,8 @@ static unsigned long samsung_dsim_set_pll(struct samsung_dsim *dsi,
 	writel(driver_data->reg_values[PLL_TIMER],
 			dsi->reg_base + driver_data->plltmr_reg);
 
-	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+	reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
+	      DSIM_PLL_M(m) | DSIM_PLL_S(s);
 
 	if (driver_data->has_freqband) {
 		static const unsigned long freq_bands[] = {
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index 0c5a905f3de7..df3d030daec6 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -53,6 +53,7 @@ struct samsung_dsim_driver_data {
 	unsigned int max_freq;
 	unsigned int wait_for_reset;
 	unsigned int num_bits_resol;
+	unsigned int pll_p_offset;
 	const unsigned int *reg_values;
 };
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 08/14] drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset

[Jagan Teki]

Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.

However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.

The offset 13 is not working for i.MX8M Mini SoCs but the downstream
NXP sec-dsim.c driver is using offset 14 for i.MX8M Mini SoC platforms
[1] [2].

PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P()
with offset 13 and then an additional offset of one bit added in
sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS().

Not sure whether it is reference manual documentation or something else
but this patch trusts the downstream code and handle PLL_P offset via
platform driver data so-that imx8mm driver data shall use pll_p_offset
to 14.

Similar to Mini the i.MX8M Nano/Plus also has P=14, unlike Exynos.

[1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n210
[2] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211

v8:
* updated commit message for 8M Nano/Plus
* collect Marek Ack

v7, v6:
* none

v5:
* updated clear commit message

v4, v3, v2:
* none

v1:
* updated commit message
* add downstream driver link

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 10 ++++++++--
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 3c0a8580508b..0fe153b29e4f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -168,7 +168,7 @@
 /* DSIM_PLLCTRL */
 #define DSIM_FREQ_BAND(x)		((x) << 24)
 #define DSIM_PLL_EN			(1 << 23)
-#define DSIM_PLL_P(x)			((x) << 13)
+#define DSIM_PLL_P(x, offset)		((x) << (offset))
 #define DSIM_PLL_M(x)			((x) << 4)
 #define DSIM_PLL_S(x)			((x) << 1)
 
@@ -368,6 +368,7 @@ static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -380,6 +381,7 @@ static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -390,6 +392,7 @@ static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -401,6 +404,7 @@ static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 0,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5433_reg_values,
 };
 
@@ -412,6 +416,7 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 1,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5422_reg_values,
 };
 
@@ -543,7 +548,8 @@ static unsigned long samsung_dsim_set_pll(struct samsung_dsim *dsi,
 	writel(driver_data->reg_values[PLL_TIMER],
 			dsi->reg_base + driver_data->plltmr_reg);
 
-	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+	reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
+	      DSIM_PLL_M(m) | DSIM_PLL_S(s);
 
 	if (driver_data->has_freqband) {
 		static const unsigned long freq_bands[] = {
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index 0c5a905f3de7..df3d030daec6 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -53,6 +53,7 @@ struct samsung_dsim_driver_data {
 	unsigned int max_freq;
 	unsigned int wait_for_reset;
 	unsigned int num_bits_resol;
+	unsigned int pll_p_offset;
 	const unsigned int *reg_values;
 };
 
-- 
2.25.1

[PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
proper input format from list of supported output formats.

This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component closer to pipeline
components.

List of Pixel formats are taken from,
AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
3.7.4 Pixel formats
Table 14. DSI pixel packing formats

v8:
* added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2

v7, v6, v5, v4:
* none

v3:
* include media-bus-format.h

v2:
* none

v1:
* new patch

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 0fe153b29e4f..33e5ae9c865f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -15,6 +15,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
+#include <linux/media-bus-format.h>
 #include <linux/of_device.h>
 #include <linux/phy/phy.h>
 
@@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+/*
+ * This pixel output formats list referenced from,
+ * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
+ * 3.7.4 Pixel formats
+ * Table 14. DSI pixel packing formats
+ */
+static const u32 samsung_dsim_pixel_output_fmts[] = {
+	MEDIA_BUS_FMT_UYVY8_1X16,
+	MEDIA_BUS_FMT_RGB101010_1X30,
+	MEDIA_BUS_FMT_RGB121212_1X36,
+	MEDIA_BUS_FMT_RGB565_1X16,
+	MEDIA_BUS_FMT_RGB666_1X18,
+	MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
+		if (samsung_dsim_pixel_output_fmts[i] == fmt)
+			return true;
+	}
+
+	return false;
+}
+
+static u32 *
+samsung_dsim_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;
+
+	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
+		return NULL;
+
+	*num_input_fmts = 1;
+
+	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	input_fmts[0] = output_fmt;
+
+	return input_fmts;
+}
+
 static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 				     struct drm_bridge_state *bridge_state,
 				     struct drm_crtc_state *crtc_state,
@@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_get_input_bus_fmts	= samsung_dsim_atomic_get_input_bus_fmts,
 	.atomic_check			= samsung_dsim_atomic_check,
 	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
 	.atomic_enable			= samsung_dsim_atomic_enable,
-- 
2.25.1

[PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
proper input format from list of supported output formats.

This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component closer to pipeline
components.

List of Pixel formats are taken from,
AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
3.7.4 Pixel formats
Table 14. DSI pixel packing formats

v8:
* added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2

v7, v6, v5, v4:
* none

v3:
* include media-bus-format.h

v2:
* none

v1:
* new patch

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 0fe153b29e4f..33e5ae9c865f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -15,6 +15,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
+#include <linux/media-bus-format.h>
 #include <linux/of_device.h>
 #include <linux/phy/phy.h>
 
@@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+/*
+ * This pixel output formats list referenced from,
+ * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
+ * 3.7.4 Pixel formats
+ * Table 14. DSI pixel packing formats
+ */
+static const u32 samsung_dsim_pixel_output_fmts[] = {
+	MEDIA_BUS_FMT_UYVY8_1X16,
+	MEDIA_BUS_FMT_RGB101010_1X30,
+	MEDIA_BUS_FMT_RGB121212_1X36,
+	MEDIA_BUS_FMT_RGB565_1X16,
+	MEDIA_BUS_FMT_RGB666_1X18,
+	MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
+		if (samsung_dsim_pixel_output_fmts[i] == fmt)
+			return true;
+	}
+
+	return false;
+}
+
+static u32 *
+samsung_dsim_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;
+
+	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
+		return NULL;
+
+	*num_input_fmts = 1;
+
+	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	input_fmts[0] = output_fmt;
+
+	return input_fmts;
+}
+
 static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 				     struct drm_bridge_state *bridge_state,
 				     struct drm_crtc_state *crtc_state,
@@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_get_input_bus_fmts	= samsung_dsim_atomic_get_input_bus_fmts,
 	.atomic_check			= samsung_dsim_atomic_check,
 	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
 	.atomic_enable			= samsung_dsim_atomic_enable,
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
proper input format from list of supported output formats.

This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component closer to pipeline
components.

List of Pixel formats are taken from,
AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
3.7.4 Pixel formats
Table 14. DSI pixel packing formats

v8:
* added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2

v7, v6, v5, v4:
* none

v3:
* include media-bus-format.h

v2:
* none

v1:
* new patch

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 0fe153b29e4f..33e5ae9c865f 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -15,6 +15,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
+#include <linux/media-bus-format.h>
 #include <linux/of_device.h>
 #include <linux/phy/phy.h>
 
@@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+/*
+ * This pixel output formats list referenced from,
+ * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
+ * 3.7.4 Pixel formats
+ * Table 14. DSI pixel packing formats
+ */
+static const u32 samsung_dsim_pixel_output_fmts[] = {
+	MEDIA_BUS_FMT_UYVY8_1X16,
+	MEDIA_BUS_FMT_RGB101010_1X30,
+	MEDIA_BUS_FMT_RGB121212_1X36,
+	MEDIA_BUS_FMT_RGB565_1X16,
+	MEDIA_BUS_FMT_RGB666_1X18,
+	MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
+		if (samsung_dsim_pixel_output_fmts[i] == fmt)
+			return true;
+	}
+
+	return false;
+}
+
+static u32 *
+samsung_dsim_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;
+
+	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
+		return NULL;
+
+	*num_input_fmts = 1;
+
+	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	input_fmts[0] = output_fmt;
+
+	return input_fmts;
+}
+
 static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 				     struct drm_bridge_state *bridge_state,
 				     struct drm_crtc_state *crtc_state,
@@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_get_input_bus_fmts	= samsung_dsim_atomic_get_input_bus_fmts,
 	.atomic_check			= samsung_dsim_atomic_check,
 	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
 	.atomic_enable			= samsung_dsim_atomic_enable,
-- 
2.25.1

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
> 
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
> 
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
> 
> v8:
> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> 
> v7, v6, v5, v4:
> * none
> 
> v3:
> * include media-bus-format.h
> 
> v2:
> * none
> 
> v1:
> * new patch
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0fe153b29e4f..33e5ae9c865f 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -15,6 +15,7 @@
>   #include <linux/clk.h>
>   #include <linux/delay.h>
>   #include <linux/irq.h>
> +#include <linux/media-bus-format.h>
>   #include <linux/of_device.h>
>   #include <linux/phy/phy.h>
>   
> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>   	pm_runtime_put_sync(dsi->dev);
>   }
>   
> +/*
> + * This pixel output formats list referenced from,
> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> + * 3.7.4 Pixel formats
> + * Table 14. DSI pixel packing formats
> + */
> +static const u32 samsung_dsim_pixel_output_fmts[] = {

You can also add :

MEDIA_BUS_FMT_YUYV10_1X20

MEDIA_BUS_FMT_YUYV12_1X24

> +	MEDIA_BUS_FMT_UYVY8_1X16,
> +	MEDIA_BUS_FMT_RGB101010_1X30,
> +	MEDIA_BUS_FMT_RGB121212_1X36,
> +	MEDIA_BUS_FMT_RGB565_1X16,
> +	MEDIA_BUS_FMT_RGB666_1X18,
> +	MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> +		if (samsung_dsim_pixel_output_fmts[i] == fmt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static u32 *
> +samsung_dsim_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;
> +
> +	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> +		return NULL;
> +
> +	*num_input_fmts = 1;

Shouldn't this be 6 ?

> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = output_fmt;

Shouldn't this be a list of all 6 supported pixel formats ?

(replace 6 with 8 with the two new YUYV10/YUYV12 pixel formats above)

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
> 
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
> 
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
> 
> v8:
> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> 
> v7, v6, v5, v4:
> * none
> 
> v3:
> * include media-bus-format.h
> 
> v2:
> * none
> 
> v1:
> * new patch
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0fe153b29e4f..33e5ae9c865f 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -15,6 +15,7 @@
>   #include <linux/clk.h>
>   #include <linux/delay.h>
>   #include <linux/irq.h>
> +#include <linux/media-bus-format.h>
>   #include <linux/of_device.h>
>   #include <linux/phy/phy.h>
>   
> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>   	pm_runtime_put_sync(dsi->dev);
>   }
>   
> +/*
> + * This pixel output formats list referenced from,
> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> + * 3.7.4 Pixel formats
> + * Table 14. DSI pixel packing formats
> + */
> +static const u32 samsung_dsim_pixel_output_fmts[] = {

You can also add :

MEDIA_BUS_FMT_YUYV10_1X20

MEDIA_BUS_FMT_YUYV12_1X24

> +	MEDIA_BUS_FMT_UYVY8_1X16,
> +	MEDIA_BUS_FMT_RGB101010_1X30,
> +	MEDIA_BUS_FMT_RGB121212_1X36,
> +	MEDIA_BUS_FMT_RGB565_1X16,
> +	MEDIA_BUS_FMT_RGB666_1X18,
> +	MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> +		if (samsung_dsim_pixel_output_fmts[i] == fmt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static u32 *
> +samsung_dsim_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;
> +
> +	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> +		return NULL;
> +
> +	*num_input_fmts = 1;

Shouldn't this be 6 ?

> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = output_fmt;

Shouldn't this be a list of all 6 supported pixel formats ?

(replace 6 with 8 with the two new YUYV10/YUYV12 pixel formats above)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/10/22 19:38, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
> 
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
> 
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
> 
> v8:
> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> 
> v7, v6, v5, v4:
> * none
> 
> v3:
> * include media-bus-format.h
> 
> v2:
> * none
> 
> v1:
> * new patch
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0fe153b29e4f..33e5ae9c865f 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -15,6 +15,7 @@
>   #include <linux/clk.h>
>   #include <linux/delay.h>
>   #include <linux/irq.h>
> +#include <linux/media-bus-format.h>
>   #include <linux/of_device.h>
>   #include <linux/phy/phy.h>
>   
> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>   	pm_runtime_put_sync(dsi->dev);
>   }
>   
> +/*
> + * This pixel output formats list referenced from,
> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> + * 3.7.4 Pixel formats
> + * Table 14. DSI pixel packing formats
> + */
> +static const u32 samsung_dsim_pixel_output_fmts[] = {

You can also add :

MEDIA_BUS_FMT_YUYV10_1X20

MEDIA_BUS_FMT_YUYV12_1X24

> +	MEDIA_BUS_FMT_UYVY8_1X16,
> +	MEDIA_BUS_FMT_RGB101010_1X30,
> +	MEDIA_BUS_FMT_RGB121212_1X36,
> +	MEDIA_BUS_FMT_RGB565_1X16,
> +	MEDIA_BUS_FMT_RGB666_1X18,
> +	MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> +		if (samsung_dsim_pixel_output_fmts[i] == fmt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static u32 *
> +samsung_dsim_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;
> +
> +	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> +		return NULL;
> +
> +	*num_input_fmts = 1;

Shouldn't this be 6 ?

> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = output_fmt;

Shouldn't this be a list of all 6 supported pixel formats ?

(replace 6 with 8 with the two new YUYV10/YUYV12 pixel formats above)

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
> > Finding the right input bus format throughout the pipeline is hard
> > so add atomic_get_input_bus_fmts callback and initialize with the
> > proper input format from list of supported output formats.
> >
> > This format can be used in pipeline for negotiating bus format between
> > the DSI-end of this bridge and the other component closer to pipeline
> > components.
> >
> > List of Pixel formats are taken from,
> > AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> > 3.7.4 Pixel formats
> > Table 14. DSI pixel packing formats
> >
> > v8:
> > * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >
> > v7, v6, v5, v4:
> > * none
> >
> > v3:
> > * include media-bus-format.h
> >
> > v2:
> > * none
> >
> > v1:
> > * new patch
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >   1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 0fe153b29e4f..33e5ae9c865f 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -15,6 +15,7 @@
> >   #include <linux/clk.h>
> >   #include <linux/delay.h>
> >   #include <linux/irq.h>
> > +#include <linux/media-bus-format.h>
> >   #include <linux/of_device.h>
> >   #include <linux/phy/phy.h>
> >
> > @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >       pm_runtime_put_sync(dsi->dev);
> >   }
> >
> > +/*
> > + * This pixel output formats list referenced from,
> > + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> > + * 3.7.4 Pixel formats
> > + * Table 14. DSI pixel packing formats
> > + */
> > +static const u32 samsung_dsim_pixel_output_fmts[] = {
>
> You can also add :
>
> MEDIA_BUS_FMT_YUYV10_1X20
>
> MEDIA_BUS_FMT_YUYV12_1X24

Are these for the below formats?

"Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
 Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>
> > +     MEDIA_BUS_FMT_UYVY8_1X16,
> > +     MEDIA_BUS_FMT_RGB101010_1X30,
> > +     MEDIA_BUS_FMT_RGB121212_1X36,
> > +     MEDIA_BUS_FMT_RGB565_1X16,
> > +     MEDIA_BUS_FMT_RGB666_1X18,
> > +     MEDIA_BUS_FMT_RGB888_1X24,
> > +};
> > +
> > +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> > +{
> > +     int i;
> > +
> > +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> > +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
> > +                     return true;
> > +     }
> > +
> > +     return false;
> > +}
> > +
> > +static u32 *
> > +samsung_dsim_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;
> > +
> > +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> > +             return NULL;
> > +
> > +     *num_input_fmts = 1;
>
> Shouldn't this be 6 ?
>
> > +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> > +     if (!input_fmts)
> > +             return NULL;
> > +
> > +     input_fmts[0] = output_fmt;
>
> Shouldn't this be a list of all 6 supported pixel formats ?

Negotiation would settle to return one input_fmt from the list of
supporting output_fmts. so the num_input_fmts would be 1 rather than
the number of fmts in the supporting list. This is what I understood
from the atomic_get_input_bus_fmts API. let me know if I miss
something here.

Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
> > Finding the right input bus format throughout the pipeline is hard
> > so add atomic_get_input_bus_fmts callback and initialize with the
> > proper input format from list of supported output formats.
> >
> > This format can be used in pipeline for negotiating bus format between
> > the DSI-end of this bridge and the other component closer to pipeline
> > components.
> >
> > List of Pixel formats are taken from,
> > AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> > 3.7.4 Pixel formats
> > Table 14. DSI pixel packing formats
> >
> > v8:
> > * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >
> > v7, v6, v5, v4:
> > * none
> >
> > v3:
> > * include media-bus-format.h
> >
> > v2:
> > * none
> >
> > v1:
> > * new patch
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >   1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 0fe153b29e4f..33e5ae9c865f 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -15,6 +15,7 @@
> >   #include <linux/clk.h>
> >   #include <linux/delay.h>
> >   #include <linux/irq.h>
> > +#include <linux/media-bus-format.h>
> >   #include <linux/of_device.h>
> >   #include <linux/phy/phy.h>
> >
> > @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >       pm_runtime_put_sync(dsi->dev);
> >   }
> >
> > +/*
> > + * This pixel output formats list referenced from,
> > + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> > + * 3.7.4 Pixel formats
> > + * Table 14. DSI pixel packing formats
> > + */
> > +static const u32 samsung_dsim_pixel_output_fmts[] = {
>
> You can also add :
>
> MEDIA_BUS_FMT_YUYV10_1X20
>
> MEDIA_BUS_FMT_YUYV12_1X24

Are these for the below formats?

"Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
 Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>
> > +     MEDIA_BUS_FMT_UYVY8_1X16,
> > +     MEDIA_BUS_FMT_RGB101010_1X30,
> > +     MEDIA_BUS_FMT_RGB121212_1X36,
> > +     MEDIA_BUS_FMT_RGB565_1X16,
> > +     MEDIA_BUS_FMT_RGB666_1X18,
> > +     MEDIA_BUS_FMT_RGB888_1X24,
> > +};
> > +
> > +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> > +{
> > +     int i;
> > +
> > +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> > +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
> > +                     return true;
> > +     }
> > +
> > +     return false;
> > +}
> > +
> > +static u32 *
> > +samsung_dsim_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;
> > +
> > +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> > +             return NULL;
> > +
> > +     *num_input_fmts = 1;
>
> Shouldn't this be 6 ?
>
> > +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> > +     if (!input_fmts)
> > +             return NULL;
> > +
> > +     input_fmts[0] = output_fmt;
>
> Shouldn't this be a list of all 6 supported pixel formats ?

Negotiation would settle to return one input_fmt from the list of
supporting output_fmts. so the num_input_fmts would be 1 rather than
the number of fmts in the supporting list. This is what I understood
from the atomic_get_input_bus_fmts API. let me know if I miss
something here.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/10/22 19:38, Jagan Teki wrote:
> > Finding the right input bus format throughout the pipeline is hard
> > so add atomic_get_input_bus_fmts callback and initialize with the
> > proper input format from list of supported output formats.
> >
> > This format can be used in pipeline for negotiating bus format between
> > the DSI-end of this bridge and the other component closer to pipeline
> > components.
> >
> > List of Pixel formats are taken from,
> > AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> > 3.7.4 Pixel formats
> > Table 14. DSI pixel packing formats
> >
> > v8:
> > * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >
> > v7, v6, v5, v4:
> > * none
> >
> > v3:
> > * include media-bus-format.h
> >
> > v2:
> > * none
> >
> > v1:
> > * new patch
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> >   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >   1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 0fe153b29e4f..33e5ae9c865f 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -15,6 +15,7 @@
> >   #include <linux/clk.h>
> >   #include <linux/delay.h>
> >   #include <linux/irq.h>
> > +#include <linux/media-bus-format.h>
> >   #include <linux/of_device.h>
> >   #include <linux/phy/phy.h>
> >
> > @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >       pm_runtime_put_sync(dsi->dev);
> >   }
> >
> > +/*
> > + * This pixel output formats list referenced from,
> > + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> > + * 3.7.4 Pixel formats
> > + * Table 14. DSI pixel packing formats
> > + */
> > +static const u32 samsung_dsim_pixel_output_fmts[] = {
>
> You can also add :
>
> MEDIA_BUS_FMT_YUYV10_1X20
>
> MEDIA_BUS_FMT_YUYV12_1X24

Are these for the below formats?

"Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
 Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>
> > +     MEDIA_BUS_FMT_UYVY8_1X16,
> > +     MEDIA_BUS_FMT_RGB101010_1X30,
> > +     MEDIA_BUS_FMT_RGB121212_1X36,
> > +     MEDIA_BUS_FMT_RGB565_1X16,
> > +     MEDIA_BUS_FMT_RGB666_1X18,
> > +     MEDIA_BUS_FMT_RGB888_1X24,
> > +};
> > +
> > +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> > +{
> > +     int i;
> > +
> > +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> > +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
> > +                     return true;
> > +     }
> > +
> > +     return false;
> > +}
> > +
> > +static u32 *
> > +samsung_dsim_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;
> > +
> > +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> > +             return NULL;
> > +
> > +     *num_input_fmts = 1;
>
> Shouldn't this be 6 ?
>
> > +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> > +     if (!input_fmts)
> > +             return NULL;
> > +
> > +     input_fmts[0] = output_fmt;
>
> Shouldn't this be a list of all 6 supported pixel formats ?

Negotiation would settle to return one input_fmt from the list of
supporting output_fmts. so the num_input_fmts would be 1 rather than
the number of fmts in the supporting list. This is what I understood
from the atomic_get_input_bus_fmts API. let me know if I miss
something here.

Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/14/22 08:49, Jagan Teki wrote:
> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> Finding the right input bus format throughout the pipeline is hard
>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>> proper input format from list of supported output formats.
>>>
>>> This format can be used in pipeline for negotiating bus format between
>>> the DSI-end of this bridge and the other component closer to pipeline
>>> components.
>>>
>>> List of Pixel formats are taken from,
>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>> 3.7.4 Pixel formats
>>> Table 14. DSI pixel packing formats
>>>
>>> v8:
>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>
>>> v7, v6, v5, v4:
>>> * none
>>>
>>> v3:
>>> * include media-bus-format.h
>>>
>>> v2:
>>> * none
>>>
>>> v1:
>>> * new patch
>>>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>    1 file changed, 53 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -15,6 +15,7 @@
>>>    #include <linux/clk.h>
>>>    #include <linux/delay.h>
>>>    #include <linux/irq.h>
>>> +#include <linux/media-bus-format.h>
>>>    #include <linux/of_device.h>
>>>    #include <linux/phy/phy.h>
>>>
>>> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>        pm_runtime_put_sync(dsi->dev);
>>>    }
>>>
>>> +/*
>>> + * This pixel output formats list referenced from,
>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>> + * 3.7.4 Pixel formats
>>> + * Table 14. DSI pixel packing formats
>>> + */
>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>
>> You can also add :
>>
>> MEDIA_BUS_FMT_YUYV10_1X20
>>
>> MEDIA_BUS_FMT_YUYV12_1X24
> 
> Are these for the below formats?
> 
> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>   Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>
>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>> +};
>>> +
>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>> +{
>>> +     int i;
>>> +
>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>> +                     return true;
>>> +     }
>>> +
>>> +     return false;
>>> +}
>>> +
>>> +static u32 *
>>> +samsung_dsim_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;
>>> +
>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>> +             return NULL;
>>> +
>>> +     *num_input_fmts = 1;
>>
>> Shouldn't this be 6 ?
>>
>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>> +     if (!input_fmts)
>>> +             return NULL;
>>> +
>>> +     input_fmts[0] = output_fmt;
>>
>> Shouldn't this be a list of all 6 supported pixel formats ?
> 
> Negotiation would settle to return one input_fmt from the list of
> supporting output_fmts. so the num_input_fmts would be 1 rather than
> the number of fmts in the supporting list. This is what I understood
> from the atomic_get_input_bus_fmts API. let me know if I miss
> something here.

How does the negotiation work for this kind of pipeline:

LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector

where all elements (LCDIFv3, DSIM, HDMI bridge) can support either 
RGB888 or packed YUV422 ?

Who decides the format used by such pipeline ?

Why should it be the DSIM bridge and not e.g. the HDMI bridge or the 
LCDIFv3 ?

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/14/22 08:49, Jagan Teki wrote:
> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> Finding the right input bus format throughout the pipeline is hard
>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>> proper input format from list of supported output formats.
>>>
>>> This format can be used in pipeline for negotiating bus format between
>>> the DSI-end of this bridge and the other component closer to pipeline
>>> components.
>>>
>>> List of Pixel formats are taken from,
>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>> 3.7.4 Pixel formats
>>> Table 14. DSI pixel packing formats
>>>
>>> v8:
>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>
>>> v7, v6, v5, v4:
>>> * none
>>>
>>> v3:
>>> * include media-bus-format.h
>>>
>>> v2:
>>> * none
>>>
>>> v1:
>>> * new patch
>>>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>    1 file changed, 53 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -15,6 +15,7 @@
>>>    #include <linux/clk.h>
>>>    #include <linux/delay.h>
>>>    #include <linux/irq.h>
>>> +#include <linux/media-bus-format.h>
>>>    #include <linux/of_device.h>
>>>    #include <linux/phy/phy.h>
>>>
>>> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>        pm_runtime_put_sync(dsi->dev);
>>>    }
>>>
>>> +/*
>>> + * This pixel output formats list referenced from,
>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>> + * 3.7.4 Pixel formats
>>> + * Table 14. DSI pixel packing formats
>>> + */
>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>
>> You can also add :
>>
>> MEDIA_BUS_FMT_YUYV10_1X20
>>
>> MEDIA_BUS_FMT_YUYV12_1X24
> 
> Are these for the below formats?
> 
> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>   Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>
>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>> +};
>>> +
>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>> +{
>>> +     int i;
>>> +
>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>> +                     return true;
>>> +     }
>>> +
>>> +     return false;
>>> +}
>>> +
>>> +static u32 *
>>> +samsung_dsim_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;
>>> +
>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>> +             return NULL;
>>> +
>>> +     *num_input_fmts = 1;
>>
>> Shouldn't this be 6 ?
>>
>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>> +     if (!input_fmts)
>>> +             return NULL;
>>> +
>>> +     input_fmts[0] = output_fmt;
>>
>> Shouldn't this be a list of all 6 supported pixel formats ?
> 
> Negotiation would settle to return one input_fmt from the list of
> supporting output_fmts. so the num_input_fmts would be 1 rather than
> the number of fmts in the supporting list. This is what I understood
> from the atomic_get_input_bus_fmts API. let me know if I miss
> something here.

How does the negotiation work for this kind of pipeline:

LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector

where all elements (LCDIFv3, DSIM, HDMI bridge) can support either 
RGB888 or packed YUV422 ?

Who decides the format used by such pipeline ?

Why should it be the DSIM bridge and not e.g. the HDMI bridge or the 
LCDIFv3 ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/14/22 08:49, Jagan Teki wrote:
> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 11/10/22 19:38, Jagan Teki wrote:
>>> Finding the right input bus format throughout the pipeline is hard
>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>> proper input format from list of supported output formats.
>>>
>>> This format can be used in pipeline for negotiating bus format between
>>> the DSI-end of this bridge and the other component closer to pipeline
>>> components.
>>>
>>> List of Pixel formats are taken from,
>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>> 3.7.4 Pixel formats
>>> Table 14. DSI pixel packing formats
>>>
>>> v8:
>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>
>>> v7, v6, v5, v4:
>>> * none
>>>
>>> v3:
>>> * include media-bus-format.h
>>>
>>> v2:
>>> * none
>>>
>>> v1:
>>> * new patch
>>>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>    1 file changed, 53 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -15,6 +15,7 @@
>>>    #include <linux/clk.h>
>>>    #include <linux/delay.h>
>>>    #include <linux/irq.h>
>>> +#include <linux/media-bus-format.h>
>>>    #include <linux/of_device.h>
>>>    #include <linux/phy/phy.h>
>>>
>>> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>        pm_runtime_put_sync(dsi->dev);
>>>    }
>>>
>>> +/*
>>> + * This pixel output formats list referenced from,
>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>> + * 3.7.4 Pixel formats
>>> + * Table 14. DSI pixel packing formats
>>> + */
>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>
>> You can also add :
>>
>> MEDIA_BUS_FMT_YUYV10_1X20
>>
>> MEDIA_BUS_FMT_YUYV12_1X24
> 
> Are these for the below formats?
> 
> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>   Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>
>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>> +};
>>> +
>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>> +{
>>> +     int i;
>>> +
>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>> +                     return true;
>>> +     }
>>> +
>>> +     return false;
>>> +}
>>> +
>>> +static u32 *
>>> +samsung_dsim_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;
>>> +
>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>> +             return NULL;
>>> +
>>> +     *num_input_fmts = 1;
>>
>> Shouldn't this be 6 ?
>>
>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>> +     if (!input_fmts)
>>> +             return NULL;
>>> +
>>> +     input_fmts[0] = output_fmt;
>>
>> Shouldn't this be a list of all 6 supported pixel formats ?
> 
> Negotiation would settle to return one input_fmt from the list of
> supporting output_fmts. so the num_input_fmts would be 1 rather than
> the number of fmts in the supporting list. This is what I understood
> from the atomic_get_input_bus_fmts API. let me know if I miss
> something here.

How does the negotiation work for this kind of pipeline:

LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector

where all elements (LCDIFv3, DSIM, HDMI bridge) can support either 
RGB888 or packed YUV422 ?

Who decides the format used by such pipeline ?

Why should it be the DSIM bridge and not e.g. the HDMI bridge or the 
LCDIFv3 ?

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 15.11.2022 13:00, Marek Vasut wrote:
> On 11/14/22 08:49, Jagan Teki wrote:
>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout the pipeline is hard
>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>> proper input format from list of supported output formats.
>>>>
>>>> This format can be used in pipeline for negotiating bus format between
>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>> components.
>>>>
>>>> List of Pixel formats are taken from,
>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> 3.7.4 Pixel formats
>>>> Table 14. DSI pixel packing formats
>>>>
>>>> v8:
>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI 
>>>> DSI/CSI-2
>>>>
>>>> v7, v6, v5, v4:
>>>> * none
>>>>
>>>> v3:
>>>> * include media-bus-format.h
>>>>
>>>> v2:
>>>> * none
>>>>
>>>> v1:
>>>> * new patch
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 
>>>> +++++++++++++++++++++++++++
>>>>    1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/clk.h>
>>>>    #include <linux/delay.h>
>>>>    #include <linux/irq.h>
>>>> +#include <linux/media-bus-format.h>
>>>>    #include <linux/of_device.h>
>>>>    #include <linux/phy/phy.h>
>>>>
>>>> @@ -1321,6 +1322,57 @@ static void 
>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>        pm_runtime_put_sync(dsi->dev);
>>>>    }
>>>>
>>>> +/*
>>>> + * This pixel output formats list referenced from,
>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> + * 3.7.4 Pixel formats
>>>> + * Table 14. DSI pixel packing formats
>>>> + */
>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>
>>> You can also add :
>>>
>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>
>>> MEDIA_BUS_FMT_YUYV12_1X24
>>
>> Are these for the below formats?
>>
>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>   Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>
>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>> +};
>>>> +
>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>> +{
>>>> +     int i;
>>>> +
>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); 
>>>> i++) {
>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>> +                     return true;
>>>> +     }
>>>> +
>>>> +     return false;
>>>> +}
>>>> +
>>>> +static u32 *
>>>> +samsung_dsim_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;
>>>> +
>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> +             return NULL;
>>>> +
>>>> +     *num_input_fmts = 1;
>>>
>>> Shouldn't this be 6 ?
>>>
>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>> +     if (!input_fmts)
>>>> +             return NULL;
>>>> +
>>>> +     input_fmts[0] = output_fmt;
>>>
>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>
>> Negotiation would settle to return one input_fmt from the list of
>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>> the number of fmts in the supporting list. This is what I understood
>> from the atomic_get_input_bus_fmts API. let me know if I miss
>> something here.
>
> How does the negotiation work for this kind of pipeline:
>
> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>
> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either 
> RGB888 or packed YUV422 ?
>
> Who decides the format used by such pipeline ?
>
> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the 
> LCDIFv3 ?


If I got it right, the drivers reports their preference for the returned 
formats. The format that is first in the reported array is the most 
preferred one. This probably means that in your case the HDMI bridge 
decides by reporting RGB or YUV first (if all elements supports both).


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 15.11.2022 13:00, Marek Vasut wrote:
> On 11/14/22 08:49, Jagan Teki wrote:
>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout the pipeline is hard
>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>> proper input format from list of supported output formats.
>>>>
>>>> This format can be used in pipeline for negotiating bus format between
>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>> components.
>>>>
>>>> List of Pixel formats are taken from,
>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> 3.7.4 Pixel formats
>>>> Table 14. DSI pixel packing formats
>>>>
>>>> v8:
>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI 
>>>> DSI/CSI-2
>>>>
>>>> v7, v6, v5, v4:
>>>> * none
>>>>
>>>> v3:
>>>> * include media-bus-format.h
>>>>
>>>> v2:
>>>> * none
>>>>
>>>> v1:
>>>> * new patch
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 
>>>> +++++++++++++++++++++++++++
>>>>    1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/clk.h>
>>>>    #include <linux/delay.h>
>>>>    #include <linux/irq.h>
>>>> +#include <linux/media-bus-format.h>
>>>>    #include <linux/of_device.h>
>>>>    #include <linux/phy/phy.h>
>>>>
>>>> @@ -1321,6 +1322,57 @@ static void 
>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>        pm_runtime_put_sync(dsi->dev);
>>>>    }
>>>>
>>>> +/*
>>>> + * This pixel output formats list referenced from,
>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> + * 3.7.4 Pixel formats
>>>> + * Table 14. DSI pixel packing formats
>>>> + */
>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>
>>> You can also add :
>>>
>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>
>>> MEDIA_BUS_FMT_YUYV12_1X24
>>
>> Are these for the below formats?
>>
>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>   Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>
>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>> +};
>>>> +
>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>> +{
>>>> +     int i;
>>>> +
>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); 
>>>> i++) {
>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>> +                     return true;
>>>> +     }
>>>> +
>>>> +     return false;
>>>> +}
>>>> +
>>>> +static u32 *
>>>> +samsung_dsim_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;
>>>> +
>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> +             return NULL;
>>>> +
>>>> +     *num_input_fmts = 1;
>>>
>>> Shouldn't this be 6 ?
>>>
>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>> +     if (!input_fmts)
>>>> +             return NULL;
>>>> +
>>>> +     input_fmts[0] = output_fmt;
>>>
>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>
>> Negotiation would settle to return one input_fmt from the list of
>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>> the number of fmts in the supporting list. This is what I understood
>> from the atomic_get_input_bus_fmts API. let me know if I miss
>> something here.
>
> How does the negotiation work for this kind of pipeline:
>
> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>
> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either 
> RGB888 or packed YUV422 ?
>
> Who decides the format used by such pipeline ?
>
> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the 
> LCDIFv3 ?


If I got it right, the drivers reports their preference for the returned 
formats. The format that is first in the reported array is the most 
preferred one. This probably means that in your case the HDMI bridge 
decides by reporting RGB or YUV first (if all elements supports both).


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 15.11.2022 13:00, Marek Vasut wrote:
> On 11/14/22 08:49, Jagan Teki wrote:
>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>
>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout the pipeline is hard
>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>> proper input format from list of supported output formats.
>>>>
>>>> This format can be used in pipeline for negotiating bus format between
>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>> components.
>>>>
>>>> List of Pixel formats are taken from,
>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> 3.7.4 Pixel formats
>>>> Table 14. DSI pixel packing formats
>>>>
>>>> v8:
>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI 
>>>> DSI/CSI-2
>>>>
>>>> v7, v6, v5, v4:
>>>> * none
>>>>
>>>> v3:
>>>> * include media-bus-format.h
>>>>
>>>> v2:
>>>> * none
>>>>
>>>> v1:
>>>> * new patch
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 
>>>> +++++++++++++++++++++++++++
>>>>    1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/clk.h>
>>>>    #include <linux/delay.h>
>>>>    #include <linux/irq.h>
>>>> +#include <linux/media-bus-format.h>
>>>>    #include <linux/of_device.h>
>>>>    #include <linux/phy/phy.h>
>>>>
>>>> @@ -1321,6 +1322,57 @@ static void 
>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>        pm_runtime_put_sync(dsi->dev);
>>>>    }
>>>>
>>>> +/*
>>>> + * This pixel output formats list referenced from,
>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> + * 3.7.4 Pixel formats
>>>> + * Table 14. DSI pixel packing formats
>>>> + */
>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>
>>> You can also add :
>>>
>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>
>>> MEDIA_BUS_FMT_YUYV12_1X24
>>
>> Are these for the below formats?
>>
>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>   Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>
>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>> +};
>>>> +
>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>> +{
>>>> +     int i;
>>>> +
>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); 
>>>> i++) {
>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>> +                     return true;
>>>> +     }
>>>> +
>>>> +     return false;
>>>> +}
>>>> +
>>>> +static u32 *
>>>> +samsung_dsim_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;
>>>> +
>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> +             return NULL;
>>>> +
>>>> +     *num_input_fmts = 1;
>>>
>>> Shouldn't this be 6 ?
>>>
>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>> +     if (!input_fmts)
>>>> +             return NULL;
>>>> +
>>>> +     input_fmts[0] = output_fmt;
>>>
>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>
>> Negotiation would settle to return one input_fmt from the list of
>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>> the number of fmts in the supporting list. This is what I understood
>> from the atomic_get_input_bus_fmts API. let me know if I miss
>> something here.
>
> How does the negotiation work for this kind of pipeline:
>
> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>
> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either 
> RGB888 or packed YUV422 ?
>
> Who decides the format used by such pipeline ?
>
> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the 
> LCDIFv3 ?


If I got it right, the drivers reports their preference for the returned 
formats. The format that is first in the reported array is the most 
preferred one. This probably means that in your case the HDMI bridge 
decides by reporting RGB or YUV first (if all elements supports both).


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/16/22 09:07, Marek Szyprowski wrote:
> On 15.11.2022 13:00, Marek Vasut wrote:
>> On 11/14/22 08:49, Jagan Teki wrote:
>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>> proper input format from list of supported output formats.
>>>>>
>>>>> This format can be used in pipeline for negotiating bus format between
>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>> components.
>>>>>
>>>>> List of Pixel formats are taken from,
>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> 3.7.4 Pixel formats
>>>>> Table 14. DSI pixel packing formats
>>>>>
>>>>> v8:
>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
>>>>> DSI/CSI-2
>>>>>
>>>>> v7, v6, v5, v4:
>>>>> * none
>>>>>
>>>>> v3:
>>>>> * include media-bus-format.h
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * new patch
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
>>>>> +++++++++++++++++++++++++++
>>>>>     1 file changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -15,6 +15,7 @@
>>>>>     #include <linux/clk.h>
>>>>>     #include <linux/delay.h>
>>>>>     #include <linux/irq.h>
>>>>> +#include <linux/media-bus-format.h>
>>>>>     #include <linux/of_device.h>
>>>>>     #include <linux/phy/phy.h>
>>>>>
>>>>> @@ -1321,6 +1322,57 @@ static void
>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>     }
>>>>>
>>>>> +/*
>>>>> + * This pixel output formats list referenced from,
>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> + * 3.7.4 Pixel formats
>>>>> + * Table 14. DSI pixel packing formats
>>>>> + */
>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>
>>>> You can also add :
>>>>
>>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>>
>>>> MEDIA_BUS_FMT_YUYV12_1X24
>>>
>>> Are these for the below formats?
>>>
>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>>
>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>>> +};
>>>>> +
>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>> +{
>>>>> +     int i;
>>>>> +
>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
>>>>> i++) {
>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>> +                     return true;
>>>>> +     }
>>>>> +
>>>>> +     return false;
>>>>> +}
>>>>> +
>>>>> +static u32 *
>>>>> +samsung_dsim_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;
>>>>> +
>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>> +             return NULL;
>>>>> +
>>>>> +     *num_input_fmts = 1;
>>>>
>>>> Shouldn't this be 6 ?
>>>>
>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>>> +     if (!input_fmts)
>>>>> +             return NULL;
>>>>> +
>>>>> +     input_fmts[0] = output_fmt;
>>>>
>>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>>
>>> Negotiation would settle to return one input_fmt from the list of
>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>>> the number of fmts in the supporting list. This is what I understood
>>> from the atomic_get_input_bus_fmts API. let me know if I miss
>>> something here.
>>
>> How does the negotiation work for this kind of pipeline:
>>
>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>>
>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
>> RGB888 or packed YUV422 ?
>>
>> Who decides the format used by such pipeline ?
>>
>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
>> LCDIFv3 ?
> 
> 
> If I got it right, the drivers reports their preference for the returned
> formats. The format that is first in the reported array is the most
> preferred one. This probably means that in your case the HDMI bridge
> decides by reporting RGB or YUV first (if all elements supports both).

But in that case, we need to list input_fmts[0]...input_fmts[n-1] in 
samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts = 
n, correct ?

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/16/22 09:07, Marek Szyprowski wrote:
> On 15.11.2022 13:00, Marek Vasut wrote:
>> On 11/14/22 08:49, Jagan Teki wrote:
>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>> proper input format from list of supported output formats.
>>>>>
>>>>> This format can be used in pipeline for negotiating bus format between
>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>> components.
>>>>>
>>>>> List of Pixel formats are taken from,
>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> 3.7.4 Pixel formats
>>>>> Table 14. DSI pixel packing formats
>>>>>
>>>>> v8:
>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
>>>>> DSI/CSI-2
>>>>>
>>>>> v7, v6, v5, v4:
>>>>> * none
>>>>>
>>>>> v3:
>>>>> * include media-bus-format.h
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * new patch
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
>>>>> +++++++++++++++++++++++++++
>>>>>     1 file changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -15,6 +15,7 @@
>>>>>     #include <linux/clk.h>
>>>>>     #include <linux/delay.h>
>>>>>     #include <linux/irq.h>
>>>>> +#include <linux/media-bus-format.h>
>>>>>     #include <linux/of_device.h>
>>>>>     #include <linux/phy/phy.h>
>>>>>
>>>>> @@ -1321,6 +1322,57 @@ static void
>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>     }
>>>>>
>>>>> +/*
>>>>> + * This pixel output formats list referenced from,
>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> + * 3.7.4 Pixel formats
>>>>> + * Table 14. DSI pixel packing formats
>>>>> + */
>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>
>>>> You can also add :
>>>>
>>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>>
>>>> MEDIA_BUS_FMT_YUYV12_1X24
>>>
>>> Are these for the below formats?
>>>
>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>>
>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>>> +};
>>>>> +
>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>> +{
>>>>> +     int i;
>>>>> +
>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
>>>>> i++) {
>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>> +                     return true;
>>>>> +     }
>>>>> +
>>>>> +     return false;
>>>>> +}
>>>>> +
>>>>> +static u32 *
>>>>> +samsung_dsim_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;
>>>>> +
>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>> +             return NULL;
>>>>> +
>>>>> +     *num_input_fmts = 1;
>>>>
>>>> Shouldn't this be 6 ?
>>>>
>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>>> +     if (!input_fmts)
>>>>> +             return NULL;
>>>>> +
>>>>> +     input_fmts[0] = output_fmt;
>>>>
>>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>>
>>> Negotiation would settle to return one input_fmt from the list of
>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>>> the number of fmts in the supporting list. This is what I understood
>>> from the atomic_get_input_bus_fmts API. let me know if I miss
>>> something here.
>>
>> How does the negotiation work for this kind of pipeline:
>>
>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>>
>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
>> RGB888 or packed YUV422 ?
>>
>> Who decides the format used by such pipeline ?
>>
>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
>> LCDIFv3 ?
> 
> 
> If I got it right, the drivers reports their preference for the returned
> formats. The format that is first in the reported array is the most
> preferred one. This probably means that in your case the HDMI bridge
> decides by reporting RGB or YUV first (if all elements supports both).

But in that case, we need to list input_fmts[0]...input_fmts[n-1] in 
samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts = 
n, correct ?

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 11/16/22 09:07, Marek Szyprowski wrote:
> On 15.11.2022 13:00, Marek Vasut wrote:
>> On 11/14/22 08:49, Jagan Teki wrote:
>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>> proper input format from list of supported output formats.
>>>>>
>>>>> This format can be used in pipeline for negotiating bus format between
>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>> components.
>>>>>
>>>>> List of Pixel formats are taken from,
>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> 3.7.4 Pixel formats
>>>>> Table 14. DSI pixel packing formats
>>>>>
>>>>> v8:
>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
>>>>> DSI/CSI-2
>>>>>
>>>>> v7, v6, v5, v4:
>>>>> * none
>>>>>
>>>>> v3:
>>>>> * include media-bus-format.h
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * new patch
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
>>>>> +++++++++++++++++++++++++++
>>>>>     1 file changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -15,6 +15,7 @@
>>>>>     #include <linux/clk.h>
>>>>>     #include <linux/delay.h>
>>>>>     #include <linux/irq.h>
>>>>> +#include <linux/media-bus-format.h>
>>>>>     #include <linux/of_device.h>
>>>>>     #include <linux/phy/phy.h>
>>>>>
>>>>> @@ -1321,6 +1322,57 @@ static void
>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>     }
>>>>>
>>>>> +/*
>>>>> + * This pixel output formats list referenced from,
>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> + * 3.7.4 Pixel formats
>>>>> + * Table 14. DSI pixel packing formats
>>>>> + */
>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>
>>>> You can also add :
>>>>
>>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>>
>>>> MEDIA_BUS_FMT_YUYV12_1X24
>>>
>>> Are these for the below formats?
>>>
>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>>
>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>>> +};
>>>>> +
>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>> +{
>>>>> +     int i;
>>>>> +
>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
>>>>> i++) {
>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>> +                     return true;
>>>>> +     }
>>>>> +
>>>>> +     return false;
>>>>> +}
>>>>> +
>>>>> +static u32 *
>>>>> +samsung_dsim_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;
>>>>> +
>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>> +             return NULL;
>>>>> +
>>>>> +     *num_input_fmts = 1;
>>>>
>>>> Shouldn't this be 6 ?
>>>>
>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>>> +     if (!input_fmts)
>>>>> +             return NULL;
>>>>> +
>>>>> +     input_fmts[0] = output_fmt;
>>>>
>>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>>
>>> Negotiation would settle to return one input_fmt from the list of
>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>>> the number of fmts in the supporting list. This is what I understood
>>> from the atomic_get_input_bus_fmts API. let me know if I miss
>>> something here.
>>
>> How does the negotiation work for this kind of pipeline:
>>
>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>>
>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
>> RGB888 or packed YUV422 ?
>>
>> Who decides the format used by such pipeline ?
>>
>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
>> LCDIFv3 ?
> 
> 
> If I got it right, the drivers reports their preference for the returned
> formats. The format that is first in the reported array is the most
> preferred one. This probably means that in your case the HDMI bridge
> decides by reporting RGB or YUV first (if all elements supports both).

But in that case, we need to list input_fmts[0]...input_fmts[n-1] in 
samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts = 
n, correct ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 16.11.2022 11:49, Marek Vasut wrote:
> On 11/16/22 09:07, Marek Szyprowski wrote:
>> On 15.11.2022 13:00, Marek Vasut wrote:
>>> On 11/14/22 08:49, Jagan Teki wrote:
>>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>>>
>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>>> proper input format from list of supported output formats.
>>>>>>
>>>>>> This format can be used in pipeline for negotiating bus format 
>>>>>> between
>>>>>> the DSI-end of this bridge and the other component closer to 
>>>>>> pipeline
>>>>>> components.
>>>>>>
>>>>>> List of Pixel formats are taken from,
>>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>> 3.7.4 Pixel formats
>>>>>> Table 14. DSI pixel packing formats
>>>>>>
>>>>>> v8:
>>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
>>>>>> DSI/CSI-2
>>>>>>
>>>>>> v7, v6, v5, v4:
>>>>>> * none
>>>>>>
>>>>>> v3:
>>>>>> * include media-bus-format.h
>>>>>>
>>>>>> v2:
>>>>>> * none
>>>>>>
>>>>>> v1:
>>>>>> * new patch
>>>>>>
>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
>>>>>> +++++++++++++++++++++++++++
>>>>>>     1 file changed, 53 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> @@ -15,6 +15,7 @@
>>>>>>     #include <linux/clk.h>
>>>>>>     #include <linux/delay.h>
>>>>>>     #include <linux/irq.h>
>>>>>> +#include <linux/media-bus-format.h>
>>>>>>     #include <linux/of_device.h>
>>>>>>     #include <linux/phy/phy.h>
>>>>>>
>>>>>> @@ -1321,6 +1322,57 @@ static void
>>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>>     }
>>>>>>
>>>>>> +/*
>>>>>> + * This pixel output formats list referenced from,
>>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>> + * 3.7.4 Pixel formats
>>>>>> + * Table 14. DSI pixel packing formats
>>>>>> + */
>>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>>
>>>>> You can also add :
>>>>>
>>>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>>>
>>>>> MEDIA_BUS_FMT_YUYV12_1X24
>>>>
>>>> Are these for the below formats?
>>>>
>>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>>>
>>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>>>> +};
>>>>>> +
>>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>>> +{
>>>>>> +     int i;
>>>>>> +
>>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
>>>>>> i++) {
>>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>>> +                     return true;
>>>>>> +     }
>>>>>> +
>>>>>> +     return false;
>>>>>> +}
>>>>>> +
>>>>>> +static u32 *
>>>>>> +samsung_dsim_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;
>>>>>> +
>>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>>> +             return NULL;
>>>>>> +
>>>>>> +     *num_input_fmts = 1;
>>>>>
>>>>> Shouldn't this be 6 ?
>>>>>
>>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>>>> +     if (!input_fmts)
>>>>>> +             return NULL;
>>>>>> +
>>>>>> +     input_fmts[0] = output_fmt;
>>>>>
>>>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>>>
>>>> Negotiation would settle to return one input_fmt from the list of
>>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>>>> the number of fmts in the supporting list. This is what I understood
>>>> from the atomic_get_input_bus_fmts API. let me know if I miss
>>>> something here.
>>>
>>> How does the negotiation work for this kind of pipeline:
>>>
>>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>>>
>>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
>>> RGB888 or packed YUV422 ?
>>>
>>> Who decides the format used by such pipeline ?
>>>
>>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
>>> LCDIFv3 ?
>>
>>
>> If I got it right, the drivers reports their preference for the returned
>> formats. The format that is first in the reported array is the most
>> preferred one. This probably means that in your case the HDMI bridge
>> decides by reporting RGB or YUV first (if all elements supports both).
>
> But in that case, we need to list input_fmts[0]...input_fmts[n-1] in 
> samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts 
> = n, correct ?
>
Yes, if I got the bus format negotiation code right, but I didn't check 
the details.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 16.11.2022 11:49, Marek Vasut wrote:
> On 11/16/22 09:07, Marek Szyprowski wrote:
>> On 15.11.2022 13:00, Marek Vasut wrote:
>>> On 11/14/22 08:49, Jagan Teki wrote:
>>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>>>
>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>>> proper input format from list of supported output formats.
>>>>>>
>>>>>> This format can be used in pipeline for negotiating bus format 
>>>>>> between
>>>>>> the DSI-end of this bridge and the other component closer to 
>>>>>> pipeline
>>>>>> components.
>>>>>>
>>>>>> List of Pixel formats are taken from,
>>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>> 3.7.4 Pixel formats
>>>>>> Table 14. DSI pixel packing formats
>>>>>>
>>>>>> v8:
>>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
>>>>>> DSI/CSI-2
>>>>>>
>>>>>> v7, v6, v5, v4:
>>>>>> * none
>>>>>>
>>>>>> v3:
>>>>>> * include media-bus-format.h
>>>>>>
>>>>>> v2:
>>>>>> * none
>>>>>>
>>>>>> v1:
>>>>>> * new patch
>>>>>>
>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
>>>>>> +++++++++++++++++++++++++++
>>>>>>     1 file changed, 53 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> @@ -15,6 +15,7 @@
>>>>>>     #include <linux/clk.h>
>>>>>>     #include <linux/delay.h>
>>>>>>     #include <linux/irq.h>
>>>>>> +#include <linux/media-bus-format.h>
>>>>>>     #include <linux/of_device.h>
>>>>>>     #include <linux/phy/phy.h>
>>>>>>
>>>>>> @@ -1321,6 +1322,57 @@ static void
>>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>>     }
>>>>>>
>>>>>> +/*
>>>>>> + * This pixel output formats list referenced from,
>>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>> + * 3.7.4 Pixel formats
>>>>>> + * Table 14. DSI pixel packing formats
>>>>>> + */
>>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>>
>>>>> You can also add :
>>>>>
>>>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>>>
>>>>> MEDIA_BUS_FMT_YUYV12_1X24
>>>>
>>>> Are these for the below formats?
>>>>
>>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>>>
>>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>>>> +};
>>>>>> +
>>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>>> +{
>>>>>> +     int i;
>>>>>> +
>>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
>>>>>> i++) {
>>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>>> +                     return true;
>>>>>> +     }
>>>>>> +
>>>>>> +     return false;
>>>>>> +}
>>>>>> +
>>>>>> +static u32 *
>>>>>> +samsung_dsim_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;
>>>>>> +
>>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>>> +             return NULL;
>>>>>> +
>>>>>> +     *num_input_fmts = 1;
>>>>>
>>>>> Shouldn't this be 6 ?
>>>>>
>>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>>>> +     if (!input_fmts)
>>>>>> +             return NULL;
>>>>>> +
>>>>>> +     input_fmts[0] = output_fmt;
>>>>>
>>>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>>>
>>>> Negotiation would settle to return one input_fmt from the list of
>>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>>>> the number of fmts in the supporting list. This is what I understood
>>>> from the atomic_get_input_bus_fmts API. let me know if I miss
>>>> something here.
>>>
>>> How does the negotiation work for this kind of pipeline:
>>>
>>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>>>
>>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
>>> RGB888 or packed YUV422 ?
>>>
>>> Who decides the format used by such pipeline ?
>>>
>>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
>>> LCDIFv3 ?
>>
>>
>> If I got it right, the drivers reports their preference for the returned
>> formats. The format that is first in the reported array is the most
>> preferred one. This probably means that in your case the HDMI bridge
>> decides by reporting RGB or YUV first (if all elements supports both).
>
> But in that case, we need to list input_fmts[0]...input_fmts[n-1] in 
> samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts 
> = n, correct ?
>
Yes, if I got the bus format negotiation code right, but I didn't check 
the details.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 16.11.2022 11:49, Marek Vasut wrote:
> On 11/16/22 09:07, Marek Szyprowski wrote:
>> On 15.11.2022 13:00, Marek Vasut wrote:
>>> On 11/14/22 08:49, Jagan Teki wrote:
>>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
>>>>>
>>>>> On 11/10/22 19:38, Jagan Teki wrote:
>>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>>> proper input format from list of supported output formats.
>>>>>>
>>>>>> This format can be used in pipeline for negotiating bus format 
>>>>>> between
>>>>>> the DSI-end of this bridge and the other component closer to 
>>>>>> pipeline
>>>>>> components.
>>>>>>
>>>>>> List of Pixel formats are taken from,
>>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>> 3.7.4 Pixel formats
>>>>>> Table 14. DSI pixel packing formats
>>>>>>
>>>>>> v8:
>>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
>>>>>> DSI/CSI-2
>>>>>>
>>>>>> v7, v6, v5, v4:
>>>>>> * none
>>>>>>
>>>>>> v3:
>>>>>> * include media-bus-format.h
>>>>>>
>>>>>> v2:
>>>>>> * none
>>>>>>
>>>>>> v1:
>>>>>> * new patch
>>>>>>
>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>> ---
>>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
>>>>>> +++++++++++++++++++++++++++
>>>>>>     1 file changed, 53 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>> @@ -15,6 +15,7 @@
>>>>>>     #include <linux/clk.h>
>>>>>>     #include <linux/delay.h>
>>>>>>     #include <linux/irq.h>
>>>>>> +#include <linux/media-bus-format.h>
>>>>>>     #include <linux/of_device.h>
>>>>>>     #include <linux/phy/phy.h>
>>>>>>
>>>>>> @@ -1321,6 +1322,57 @@ static void
>>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>>     }
>>>>>>
>>>>>> +/*
>>>>>> + * This pixel output formats list referenced from,
>>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>> + * 3.7.4 Pixel formats
>>>>>> + * Table 14. DSI pixel packing formats
>>>>>> + */
>>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>>
>>>>> You can also add :
>>>>>
>>>>> MEDIA_BUS_FMT_YUYV10_1X20
>>>>>
>>>>> MEDIA_BUS_FMT_YUYV12_1X24
>>>>
>>>> Are these for the below formats?
>>>>
>>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
>>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
>>>>>
>>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
>>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
>>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
>>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
>>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
>>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
>>>>>> +};
>>>>>> +
>>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>>> +{
>>>>>> +     int i;
>>>>>> +
>>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
>>>>>> i++) {
>>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>>> +                     return true;
>>>>>> +     }
>>>>>> +
>>>>>> +     return false;
>>>>>> +}
>>>>>> +
>>>>>> +static u32 *
>>>>>> +samsung_dsim_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;
>>>>>> +
>>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>>> +             return NULL;
>>>>>> +
>>>>>> +     *num_input_fmts = 1;
>>>>>
>>>>> Shouldn't this be 6 ?
>>>>>
>>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>>>> +     if (!input_fmts)
>>>>>> +             return NULL;
>>>>>> +
>>>>>> +     input_fmts[0] = output_fmt;
>>>>>
>>>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>>>
>>>> Negotiation would settle to return one input_fmt from the list of
>>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>>>> the number of fmts in the supporting list. This is what I understood
>>>> from the atomic_get_input_bus_fmts API. let me know if I miss
>>>> something here.
>>>
>>> How does the negotiation work for this kind of pipeline:
>>>
>>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>>>
>>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
>>> RGB888 or packed YUV422 ?
>>>
>>> Who decides the format used by such pipeline ?
>>>
>>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
>>> LCDIFv3 ?
>>
>>
>> If I got it right, the drivers reports their preference for the returned
>> formats. The format that is first in the reported array is the most
>> preferred one. This probably means that in your case the HDMI bridge
>> decides by reporting RGB or YUV first (if all elements supports both).
>
> But in that case, we need to list input_fmts[0]...input_fmts[n-1] in 
> samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts 
> = n, correct ?
>
Yes, if I got the bus format negotiation code right, but I didn't check 
the details.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Wed, Nov 16, 2022 at 4:37 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 16.11.2022 11:49, Marek Vasut wrote:
> > On 11/16/22 09:07, Marek Szyprowski wrote:
> >> On 15.11.2022 13:00, Marek Vasut wrote:
> >>> On 11/14/22 08:49, Jagan Teki wrote:
> >>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>> Finding the right input bus format throughout the pipeline is hard
> >>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
> >>>>>> proper input format from list of supported output formats.
> >>>>>>
> >>>>>> This format can be used in pipeline for negotiating bus format
> >>>>>> between
> >>>>>> the DSI-end of this bridge and the other component closer to
> >>>>>> pipeline
> >>>>>> components.
> >>>>>>
> >>>>>> List of Pixel formats are taken from,
> >>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>>> 3.7.4 Pixel formats
> >>>>>> Table 14. DSI pixel packing formats
> >>>>>>
> >>>>>> v8:
> >>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
> >>>>>> DSI/CSI-2
> >>>>>>
> >>>>>> v7, v6, v5, v4:
> >>>>>> * none
> >>>>>>
> >>>>>> v3:
> >>>>>> * include media-bus-format.h
> >>>>>>
> >>>>>> v2:
> >>>>>> * none
> >>>>>>
> >>>>>> v1:
> >>>>>> * new patch
> >>>>>>
> >>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>> ---
> >>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
> >>>>>> +++++++++++++++++++++++++++
> >>>>>>     1 file changed, 53 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
> >>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> @@ -15,6 +15,7 @@
> >>>>>>     #include <linux/clk.h>
> >>>>>>     #include <linux/delay.h>
> >>>>>>     #include <linux/irq.h>
> >>>>>> +#include <linux/media-bus-format.h>
> >>>>>>     #include <linux/of_device.h>
> >>>>>>     #include <linux/phy/phy.h>
> >>>>>>
> >>>>>> @@ -1321,6 +1322,57 @@ static void
> >>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>>>         pm_runtime_put_sync(dsi->dev);
> >>>>>>     }
> >>>>>>
> >>>>>> +/*
> >>>>>> + * This pixel output formats list referenced from,
> >>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>>> + * 3.7.4 Pixel formats
> >>>>>> + * Table 14. DSI pixel packing formats
> >>>>>> + */
> >>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >>>>>
> >>>>> You can also add :
> >>>>>
> >>>>> MEDIA_BUS_FMT_YUYV10_1X20
> >>>>>
> >>>>> MEDIA_BUS_FMT_YUYV12_1X24
> >>>>
> >>>> Are these for the below formats?
> >>>>
> >>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
> >>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
> >>>>>
> >>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
> >>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
> >>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
> >>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
> >>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
> >>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
> >>>>>> +};
> >>>>>> +
> >>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >>>>>> +{
> >>>>>> +     int i;
> >>>>>> +
> >>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
> >>>>>> i++) {
> >>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >>>>>> +                     return true;
> >>>>>> +     }
> >>>>>> +
> >>>>>> +     return false;
> >>>>>> +}
> >>>>>> +
> >>>>>> +static u32 *
> >>>>>> +samsung_dsim_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;
> >>>>>> +
> >>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >>>>>> +             return NULL;
> >>>>>> +
> >>>>>> +     *num_input_fmts = 1;
> >>>>>
> >>>>> Shouldn't this be 6 ?
> >>>>>
> >>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> >>>>>> +     if (!input_fmts)
> >>>>>> +             return NULL;
> >>>>>> +
> >>>>>> +     input_fmts[0] = output_fmt;
> >>>>>
> >>>>> Shouldn't this be a list of all 6 supported pixel formats ?
> >>>>
> >>>> Negotiation would settle to return one input_fmt from the list of
> >>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
> >>>> the number of fmts in the supporting list. This is what I understood
> >>>> from the atomic_get_input_bus_fmts API. let me know if I miss
> >>>> something here.
> >>>
> >>> How does the negotiation work for this kind of pipeline:
> >>>
> >>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
> >>>
> >>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
> >>> RGB888 or packed YUV422 ?
> >>>
> >>> Who decides the format used by such pipeline ?
> >>>
> >>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
> >>> LCDIFv3 ?
> >>
> >>
> >> If I got it right, the drivers reports their preference for the returned
> >> formats. The format that is first in the reported array is the most
> >> preferred one. This probably means that in your case the HDMI bridge
> >> decides by reporting RGB or YUV first (if all elements supports both).
> >
> > But in that case, we need to list input_fmts[0]...input_fmts[n-1] in
> > samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts
> > = n, correct ?
> >
> Yes, if I got the bus format negotiation code right, but I didn't check
> the details.

It Looks like if the number of formats returned by the array is more
than 1, then the input_fmts array needs to return by listing formats
in decreasing preference order so that the bridge core will try all
formats until it finds one that works. But the question here is how
much is the array number, how to decide? I can see dw-hdmi return a
maximum of 3 possible input formats for an output format so the array
seems to be 3 here, but the rest of drivers like imx8qxp-pixel-link do
return 1 from the list of supported - dsim doing the same here.

If we are sure dsim can support or feature 2 then order RGB888 and
YUV422 decreasing preference and return them otherwise stick with a
single return of checking supported list and return desired one.

Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Wed, Nov 16, 2022 at 4:37 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 16.11.2022 11:49, Marek Vasut wrote:
> > On 11/16/22 09:07, Marek Szyprowski wrote:
> >> On 15.11.2022 13:00, Marek Vasut wrote:
> >>> On 11/14/22 08:49, Jagan Teki wrote:
> >>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>> Finding the right input bus format throughout the pipeline is hard
> >>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
> >>>>>> proper input format from list of supported output formats.
> >>>>>>
> >>>>>> This format can be used in pipeline for negotiating bus format
> >>>>>> between
> >>>>>> the DSI-end of this bridge and the other component closer to
> >>>>>> pipeline
> >>>>>> components.
> >>>>>>
> >>>>>> List of Pixel formats are taken from,
> >>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>>> 3.7.4 Pixel formats
> >>>>>> Table 14. DSI pixel packing formats
> >>>>>>
> >>>>>> v8:
> >>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
> >>>>>> DSI/CSI-2
> >>>>>>
> >>>>>> v7, v6, v5, v4:
> >>>>>> * none
> >>>>>>
> >>>>>> v3:
> >>>>>> * include media-bus-format.h
> >>>>>>
> >>>>>> v2:
> >>>>>> * none
> >>>>>>
> >>>>>> v1:
> >>>>>> * new patch
> >>>>>>
> >>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>> ---
> >>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
> >>>>>> +++++++++++++++++++++++++++
> >>>>>>     1 file changed, 53 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
> >>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> @@ -15,6 +15,7 @@
> >>>>>>     #include <linux/clk.h>
> >>>>>>     #include <linux/delay.h>
> >>>>>>     #include <linux/irq.h>
> >>>>>> +#include <linux/media-bus-format.h>
> >>>>>>     #include <linux/of_device.h>
> >>>>>>     #include <linux/phy/phy.h>
> >>>>>>
> >>>>>> @@ -1321,6 +1322,57 @@ static void
> >>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>>>         pm_runtime_put_sync(dsi->dev);
> >>>>>>     }
> >>>>>>
> >>>>>> +/*
> >>>>>> + * This pixel output formats list referenced from,
> >>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>>> + * 3.7.4 Pixel formats
> >>>>>> + * Table 14. DSI pixel packing formats
> >>>>>> + */
> >>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >>>>>
> >>>>> You can also add :
> >>>>>
> >>>>> MEDIA_BUS_FMT_YUYV10_1X20
> >>>>>
> >>>>> MEDIA_BUS_FMT_YUYV12_1X24
> >>>>
> >>>> Are these for the below formats?
> >>>>
> >>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
> >>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
> >>>>>
> >>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
> >>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
> >>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
> >>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
> >>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
> >>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
> >>>>>> +};
> >>>>>> +
> >>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >>>>>> +{
> >>>>>> +     int i;
> >>>>>> +
> >>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
> >>>>>> i++) {
> >>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >>>>>> +                     return true;
> >>>>>> +     }
> >>>>>> +
> >>>>>> +     return false;
> >>>>>> +}
> >>>>>> +
> >>>>>> +static u32 *
> >>>>>> +samsung_dsim_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;
> >>>>>> +
> >>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >>>>>> +             return NULL;
> >>>>>> +
> >>>>>> +     *num_input_fmts = 1;
> >>>>>
> >>>>> Shouldn't this be 6 ?
> >>>>>
> >>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> >>>>>> +     if (!input_fmts)
> >>>>>> +             return NULL;
> >>>>>> +
> >>>>>> +     input_fmts[0] = output_fmt;
> >>>>>
> >>>>> Shouldn't this be a list of all 6 supported pixel formats ?
> >>>>
> >>>> Negotiation would settle to return one input_fmt from the list of
> >>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
> >>>> the number of fmts in the supporting list. This is what I understood
> >>>> from the atomic_get_input_bus_fmts API. let me know if I miss
> >>>> something here.
> >>>
> >>> How does the negotiation work for this kind of pipeline:
> >>>
> >>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
> >>>
> >>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
> >>> RGB888 or packed YUV422 ?
> >>>
> >>> Who decides the format used by such pipeline ?
> >>>
> >>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
> >>> LCDIFv3 ?
> >>
> >>
> >> If I got it right, the drivers reports their preference for the returned
> >> formats. The format that is first in the reported array is the most
> >> preferred one. This probably means that in your case the HDMI bridge
> >> decides by reporting RGB or YUV first (if all elements supports both).
> >
> > But in that case, we need to list input_fmts[0]...input_fmts[n-1] in
> > samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts
> > = n, correct ?
> >
> Yes, if I got the bus format negotiation code right, but I didn't check
> the details.

It Looks like if the number of formats returned by the array is more
than 1, then the input_fmts array needs to return by listing formats
in decreasing preference order so that the bridge core will try all
formats until it finds one that works. But the question here is how
much is the array number, how to decide? I can see dw-hdmi return a
maximum of 3 possible input formats for an output format so the array
seems to be 3 here, but the rest of drivers like imx8qxp-pixel-link do
return 1 from the list of supported - dsim doing the same here.

If we are sure dsim can support or feature 2 then order RGB888 and
YUV422 decreasing preference and return them otherwise stick with a
single return of checking supported list and return desired one.

Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Wed, Nov 16, 2022 at 4:37 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 16.11.2022 11:49, Marek Vasut wrote:
> > On 11/16/22 09:07, Marek Szyprowski wrote:
> >> On 15.11.2022 13:00, Marek Vasut wrote:
> >>> On 11/14/22 08:49, Jagan Teki wrote:
> >>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>
> >>>>> On 11/10/22 19:38, Jagan Teki wrote:
> >>>>>> Finding the right input bus format throughout the pipeline is hard
> >>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
> >>>>>> proper input format from list of supported output formats.
> >>>>>>
> >>>>>> This format can be used in pipeline for negotiating bus format
> >>>>>> between
> >>>>>> the DSI-end of this bridge and the other component closer to
> >>>>>> pipeline
> >>>>>> components.
> >>>>>>
> >>>>>> List of Pixel formats are taken from,
> >>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>>> 3.7.4 Pixel formats
> >>>>>> Table 14. DSI pixel packing formats
> >>>>>>
> >>>>>> v8:
> >>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI
> >>>>>> DSI/CSI-2
> >>>>>>
> >>>>>> v7, v6, v5, v4:
> >>>>>> * none
> >>>>>>
> >>>>>> v3:
> >>>>>> * include media-bus-format.h
> >>>>>>
> >>>>>> v2:
> >>>>>> * none
> >>>>>>
> >>>>>> v1:
> >>>>>> * new patch
> >>>>>>
> >>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>> ---
> >>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53
> >>>>>> +++++++++++++++++++++++++++
> >>>>>>     1 file changed, 53 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
> >>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>>> @@ -15,6 +15,7 @@
> >>>>>>     #include <linux/clk.h>
> >>>>>>     #include <linux/delay.h>
> >>>>>>     #include <linux/irq.h>
> >>>>>> +#include <linux/media-bus-format.h>
> >>>>>>     #include <linux/of_device.h>
> >>>>>>     #include <linux/phy/phy.h>
> >>>>>>
> >>>>>> @@ -1321,6 +1322,57 @@ static void
> >>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>>>         pm_runtime_put_sync(dsi->dev);
> >>>>>>     }
> >>>>>>
> >>>>>> +/*
> >>>>>> + * This pixel output formats list referenced from,
> >>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>>> + * 3.7.4 Pixel formats
> >>>>>> + * Table 14. DSI pixel packing formats
> >>>>>> + */
> >>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >>>>>
> >>>>> You can also add :
> >>>>>
> >>>>> MEDIA_BUS_FMT_YUYV10_1X20
> >>>>>
> >>>>> MEDIA_BUS_FMT_YUYV12_1X24
> >>>>
> >>>> Are these for the below formats?
> >>>>
> >>>> "Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
> >>>>    Packed Pixel Stream, 24-bit YCbCr, 4:2:2"
> >>>>>
> >>>>>> +     MEDIA_BUS_FMT_UYVY8_1X16,
> >>>>>> +     MEDIA_BUS_FMT_RGB101010_1X30,
> >>>>>> +     MEDIA_BUS_FMT_RGB121212_1X36,
> >>>>>> +     MEDIA_BUS_FMT_RGB565_1X16,
> >>>>>> +     MEDIA_BUS_FMT_RGB666_1X18,
> >>>>>> +     MEDIA_BUS_FMT_RGB888_1X24,
> >>>>>> +};
> >>>>>> +
> >>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >>>>>> +{
> >>>>>> +     int i;
> >>>>>> +
> >>>>>> +     for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts);
> >>>>>> i++) {
> >>>>>> +             if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >>>>>> +                     return true;
> >>>>>> +     }
> >>>>>> +
> >>>>>> +     return false;
> >>>>>> +}
> >>>>>> +
> >>>>>> +static u32 *
> >>>>>> +samsung_dsim_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;
> >>>>>> +
> >>>>>> +     if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >>>>>> +             return NULL;
> >>>>>> +
> >>>>>> +     *num_input_fmts = 1;
> >>>>>
> >>>>> Shouldn't this be 6 ?
> >>>>>
> >>>>>> +     input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> >>>>>> +     if (!input_fmts)
> >>>>>> +             return NULL;
> >>>>>> +
> >>>>>> +     input_fmts[0] = output_fmt;
> >>>>>
> >>>>> Shouldn't this be a list of all 6 supported pixel formats ?
> >>>>
> >>>> Negotiation would settle to return one input_fmt from the list of
> >>>> supporting output_fmts. so the num_input_fmts would be 1 rather than
> >>>> the number of fmts in the supporting list. This is what I understood
> >>>> from the atomic_get_input_bus_fmts API. let me know if I miss
> >>>> something here.
> >>>
> >>> How does the negotiation work for this kind of pipeline:
> >>>
> >>> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
> >>>
> >>> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
> >>> RGB888 or packed YUV422 ?
> >>>
> >>> Who decides the format used by such pipeline ?
> >>>
> >>> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
> >>> LCDIFv3 ?
> >>
> >>
> >> If I got it right, the drivers reports their preference for the returned
> >> formats. The format that is first in the reported array is the most
> >> preferred one. This probably means that in your case the HDMI bridge
> >> decides by reporting RGB or YUV first (if all elements supports both).
> >
> > But in that case, we need to list input_fmts[0]...input_fmts[n-1] in
> > samsung_dsim_atomic_get_input_bus_fmts() and also set *num_input_fmts
> > = n, correct ?
> >
> Yes, if I got the bus format negotiation code right, but I didn't check
> the details.

It Looks like if the number of formats returned by the array is more
than 1, then the input_fmts array needs to return by listing formats
in decreasing preference order so that the bridge core will try all
formats until it finds one that works. But the question here is how
much is the array number, how to decide? I can see dw-hdmi return a
maximum of 3 possible input formats for an output format so the array
seems to be 3 here, but the rest of drivers like imx8qxp-pixel-link do
return 1 from the list of supported - dsim doing the same here.

If we are sure dsim can support or feature 2 then order RGB888 and
YUV422 decreasing preference and return them otherwise stick with a
single return of checking supported list and return desired one.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 10.11.2022 19:38, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
>
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
>
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
>
> v8:
> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>
> v7, v6, v5, v4:
> * none
>
> v3:
> * include media-bus-format.h
>
> v2:
> * none
>
> v1:
> * new patch
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0fe153b29e4f..33e5ae9c865f 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -15,6 +15,7 @@
>   #include <linux/clk.h>
>   #include <linux/delay.h>
>   #include <linux/irq.h>
> +#include <linux/media-bus-format.h>
>   #include <linux/of_device.h>
>   #include <linux/phy/phy.h>
>   
> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>   	pm_runtime_put_sync(dsi->dev);
>   }
>   
> +/*
> + * This pixel output formats list referenced from,
> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> + * 3.7.4 Pixel formats
> + * Table 14. DSI pixel packing formats
> + */
> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> +	MEDIA_BUS_FMT_UYVY8_1X16,
> +	MEDIA_BUS_FMT_RGB101010_1X30,
> +	MEDIA_BUS_FMT_RGB121212_1X36,
> +	MEDIA_BUS_FMT_RGB565_1X16,
> +	MEDIA_BUS_FMT_RGB666_1X18,
> +	MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> +		if (samsung_dsim_pixel_output_fmts[i] == fmt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static u32 *
> +samsung_dsim_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;
> +
> +	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> +		return NULL;


Please add support for MEDIA_BUS_FMT_FIXED and maybe default to 
MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.

Otherwise the above check breaks all current clients of the Samsung 
DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all 
DSI panels requests such format on my test systems...


> +
> +	*num_input_fmts = 1;
> +
> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = output_fmt;
> +
> +	return input_fmts;
> +}
> +
>   static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
>   				     struct drm_bridge_state *bridge_state,
>   				     struct drm_crtc_state *crtc_state,
> @@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
>   	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
>   	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
>   	.atomic_reset			= drm_atomic_helper_bridge_reset,
> +	.atomic_get_input_bus_fmts	= samsung_dsim_atomic_get_input_bus_fmts,
>   	.atomic_check			= samsung_dsim_atomic_check,
>   	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
>   	.atomic_enable			= samsung_dsim_atomic_enable,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 10.11.2022 19:38, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
>
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
>
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
>
> v8:
> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>
> v7, v6, v5, v4:
> * none
>
> v3:
> * include media-bus-format.h
>
> v2:
> * none
>
> v1:
> * new patch
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0fe153b29e4f..33e5ae9c865f 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -15,6 +15,7 @@
>   #include <linux/clk.h>
>   #include <linux/delay.h>
>   #include <linux/irq.h>
> +#include <linux/media-bus-format.h>
>   #include <linux/of_device.h>
>   #include <linux/phy/phy.h>
>   
> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>   	pm_runtime_put_sync(dsi->dev);
>   }
>   
> +/*
> + * This pixel output formats list referenced from,
> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> + * 3.7.4 Pixel formats
> + * Table 14. DSI pixel packing formats
> + */
> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> +	MEDIA_BUS_FMT_UYVY8_1X16,
> +	MEDIA_BUS_FMT_RGB101010_1X30,
> +	MEDIA_BUS_FMT_RGB121212_1X36,
> +	MEDIA_BUS_FMT_RGB565_1X16,
> +	MEDIA_BUS_FMT_RGB666_1X18,
> +	MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> +		if (samsung_dsim_pixel_output_fmts[i] == fmt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static u32 *
> +samsung_dsim_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;
> +
> +	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> +		return NULL;


Please add support for MEDIA_BUS_FMT_FIXED and maybe default to 
MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.

Otherwise the above check breaks all current clients of the Samsung 
DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all 
DSI panels requests such format on my test systems...


> +
> +	*num_input_fmts = 1;
> +
> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = output_fmt;
> +
> +	return input_fmts;
> +}
> +
>   static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
>   				     struct drm_bridge_state *bridge_state,
>   				     struct drm_crtc_state *crtc_state,
> @@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
>   	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
>   	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
>   	.atomic_reset			= drm_atomic_helper_bridge_reset,
> +	.atomic_get_input_bus_fmts	= samsung_dsim_atomic_get_input_bus_fmts,
>   	.atomic_check			= samsung_dsim_atomic_check,
>   	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
>   	.atomic_enable			= samsung_dsim_atomic_enable,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 10.11.2022 19:38, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
>
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
>
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
>
> v8:
> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>
> v7, v6, v5, v4:
> * none
>
> v3:
> * include media-bus-format.h
>
> v2:
> * none
>
> v1:
> * new patch
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>   1 file changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0fe153b29e4f..33e5ae9c865f 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -15,6 +15,7 @@
>   #include <linux/clk.h>
>   #include <linux/delay.h>
>   #include <linux/irq.h>
> +#include <linux/media-bus-format.h>
>   #include <linux/of_device.h>
>   #include <linux/phy/phy.h>
>   
> @@ -1321,6 +1322,57 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>   	pm_runtime_put_sync(dsi->dev);
>   }
>   
> +/*
> + * This pixel output formats list referenced from,
> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> + * 3.7.4 Pixel formats
> + * Table 14. DSI pixel packing formats
> + */
> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> +	MEDIA_BUS_FMT_UYVY8_1X16,
> +	MEDIA_BUS_FMT_RGB101010_1X30,
> +	MEDIA_BUS_FMT_RGB121212_1X36,
> +	MEDIA_BUS_FMT_RGB565_1X16,
> +	MEDIA_BUS_FMT_RGB666_1X18,
> +	MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> +		if (samsung_dsim_pixel_output_fmts[i] == fmt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static u32 *
> +samsung_dsim_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;
> +
> +	if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> +		return NULL;


Please add support for MEDIA_BUS_FMT_FIXED and maybe default to 
MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.

Otherwise the above check breaks all current clients of the Samsung 
DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all 
DSI panels requests such format on my test systems...


> +
> +	*num_input_fmts = 1;
> +
> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = output_fmt;
> +
> +	return input_fmts;
> +}
> +
>   static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
>   				     struct drm_bridge_state *bridge_state,
>   				     struct drm_crtc_state *crtc_state,
> @@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs samsung_dsim_bridge_funcs = {
>   	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
>   	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
>   	.atomic_reset			= drm_atomic_helper_bridge_reset,
> +	.atomic_get_input_bus_fmts	= samsung_dsim_atomic_get_input_bus_fmts,
>   	.atomic_check			= samsung_dsim_atomic_check,
>   	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
>   	.atomic_enable			= samsung_dsim_atomic_enable,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 14.11.2022 11:57, Marek Szyprowski wrote:
> On 10.11.2022 19:38, Jagan Teki wrote:
>> Finding the right input bus format throughout the pipeline is hard
>> so add atomic_get_input_bus_fmts callback and initialize with the
>> proper input format from list of supported output formats.
>>
>> This format can be used in pipeline for negotiating bus format between
>> the DSI-end of this bridge and the other component closer to pipeline
>> components.
>>
>> List of Pixel formats are taken from,
>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>> 3.7.4 Pixel formats
>> Table 14. DSI pixel packing formats
>>
>> v8:
>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>
>> v7, v6, v5, v4:
>> * none
>>
>> v3:
>> * include media-bus-format.h
>>
>> v2:
>> * none
>>
>> v1:
>> * new patch
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>   1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 0fe153b29e4f..33e5ae9c865f 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -15,6 +15,7 @@
>>   #include <linux/clk.h>
>>   #include <linux/delay.h>
>>   #include <linux/irq.h>
>> +#include <linux/media-bus-format.h>
>>   #include <linux/of_device.h>
>>   #include <linux/phy/phy.h>
>>   @@ -1321,6 +1322,57 @@ static void 
>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>       pm_runtime_put_sync(dsi->dev);
>>   }
>>   +/*
>> + * This pixel output formats list referenced from,
>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>> + * 3.7.4 Pixel formats
>> + * Table 14. DSI pixel packing formats
>> + */
>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>> +    MEDIA_BUS_FMT_RGB565_1X16,
>> +    MEDIA_BUS_FMT_RGB666_1X18,
>> +    MEDIA_BUS_FMT_RGB888_1X24,
>> +};
>> +
>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>> +            return true;
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> +static u32 *
>> +samsung_dsim_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;
>> +
>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>> +        return NULL;
>
>
> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to 
> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>
> Otherwise the above check breaks all current clients of the Samsung 
> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all 
> DSI panels requests such format on my test systems...

I've checked a bit more the bus format related code and it looks that 
there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_* 
formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for 
them. On Arndale board with Toshiba tc358764 bridge the 
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in 
samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel, 
but this doesn't look like a format really needed on that bridge). A bit 
more logic seems to be needed there to make it working properly.

I suggest to move all this bus format related changes into a separate 
patchset and adjust other bridges/panels/etc as needed in it.

>
>> +
>> +    *num_input_fmts = 1;
>> +
>> +    input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>> +    if (!input_fmts)
>> +        return NULL;
>> +
>> +    input_fmts[0] = output_fmt;
>> +
>> +    return input_fmts;
>> +}
>> +
>>   static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
>>                        struct drm_bridge_state *bridge_state,
>>                        struct drm_crtc_state *crtc_state,
>> @@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs 
>> samsung_dsim_bridge_funcs = {
>>       .atomic_duplicate_state        = 
>> drm_atomic_helper_bridge_duplicate_state,
>>       .atomic_destroy_state        = 
>> drm_atomic_helper_bridge_destroy_state,
>>       .atomic_reset            = drm_atomic_helper_bridge_reset,
>> +    .atomic_get_input_bus_fmts    = 
>> samsung_dsim_atomic_get_input_bus_fmts,
>>       .atomic_check            = samsung_dsim_atomic_check,
>>       .atomic_pre_enable        = samsung_dsim_atomic_pre_enable,
>>       .atomic_enable            = samsung_dsim_atomic_enable,
>
> Best regards

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 14.11.2022 11:57, Marek Szyprowski wrote:
> On 10.11.2022 19:38, Jagan Teki wrote:
>> Finding the right input bus format throughout the pipeline is hard
>> so add atomic_get_input_bus_fmts callback and initialize with the
>> proper input format from list of supported output formats.
>>
>> This format can be used in pipeline for negotiating bus format between
>> the DSI-end of this bridge and the other component closer to pipeline
>> components.
>>
>> List of Pixel formats are taken from,
>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>> 3.7.4 Pixel formats
>> Table 14. DSI pixel packing formats
>>
>> v8:
>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>
>> v7, v6, v5, v4:
>> * none
>>
>> v3:
>> * include media-bus-format.h
>>
>> v2:
>> * none
>>
>> v1:
>> * new patch
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>   1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 0fe153b29e4f..33e5ae9c865f 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -15,6 +15,7 @@
>>   #include <linux/clk.h>
>>   #include <linux/delay.h>
>>   #include <linux/irq.h>
>> +#include <linux/media-bus-format.h>
>>   #include <linux/of_device.h>
>>   #include <linux/phy/phy.h>
>>   @@ -1321,6 +1322,57 @@ static void 
>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>       pm_runtime_put_sync(dsi->dev);
>>   }
>>   +/*
>> + * This pixel output formats list referenced from,
>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>> + * 3.7.4 Pixel formats
>> + * Table 14. DSI pixel packing formats
>> + */
>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>> +    MEDIA_BUS_FMT_RGB565_1X16,
>> +    MEDIA_BUS_FMT_RGB666_1X18,
>> +    MEDIA_BUS_FMT_RGB888_1X24,
>> +};
>> +
>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>> +            return true;
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> +static u32 *
>> +samsung_dsim_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;
>> +
>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>> +        return NULL;
>
>
> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to 
> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>
> Otherwise the above check breaks all current clients of the Samsung 
> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all 
> DSI panels requests such format on my test systems...

I've checked a bit more the bus format related code and it looks that 
there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_* 
formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for 
them. On Arndale board with Toshiba tc358764 bridge the 
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in 
samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel, 
but this doesn't look like a format really needed on that bridge). A bit 
more logic seems to be needed there to make it working properly.

I suggest to move all this bus format related changes into a separate 
patchset and adjust other bridges/panels/etc as needed in it.

>
>> +
>> +    *num_input_fmts = 1;
>> +
>> +    input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>> +    if (!input_fmts)
>> +        return NULL;
>> +
>> +    input_fmts[0] = output_fmt;
>> +
>> +    return input_fmts;
>> +}
>> +
>>   static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
>>                        struct drm_bridge_state *bridge_state,
>>                        struct drm_crtc_state *crtc_state,
>> @@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs 
>> samsung_dsim_bridge_funcs = {
>>       .atomic_duplicate_state        = 
>> drm_atomic_helper_bridge_duplicate_state,
>>       .atomic_destroy_state        = 
>> drm_atomic_helper_bridge_destroy_state,
>>       .atomic_reset            = drm_atomic_helper_bridge_reset,
>> +    .atomic_get_input_bus_fmts    = 
>> samsung_dsim_atomic_get_input_bus_fmts,
>>       .atomic_check            = samsung_dsim_atomic_check,
>>       .atomic_pre_enable        = samsung_dsim_atomic_pre_enable,
>>       .atomic_enable            = samsung_dsim_atomic_enable,
>
> Best regards

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

On 14.11.2022 11:57, Marek Szyprowski wrote:
> On 10.11.2022 19:38, Jagan Teki wrote:
>> Finding the right input bus format throughout the pipeline is hard
>> so add atomic_get_input_bus_fmts callback and initialize with the
>> proper input format from list of supported output formats.
>>
>> This format can be used in pipeline for negotiating bus format between
>> the DSI-end of this bridge and the other component closer to pipeline
>> components.
>>
>> List of Pixel formats are taken from,
>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>> 3.7.4 Pixel formats
>> Table 14. DSI pixel packing formats
>>
>> v8:
>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>
>> v7, v6, v5, v4:
>> * none
>>
>> v3:
>> * include media-bus-format.h
>>
>> v2:
>> * none
>>
>> v1:
>> * new patch
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>   1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 0fe153b29e4f..33e5ae9c865f 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -15,6 +15,7 @@
>>   #include <linux/clk.h>
>>   #include <linux/delay.h>
>>   #include <linux/irq.h>
>> +#include <linux/media-bus-format.h>
>>   #include <linux/of_device.h>
>>   #include <linux/phy/phy.h>
>>   @@ -1321,6 +1322,57 @@ static void 
>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>       pm_runtime_put_sync(dsi->dev);
>>   }
>>   +/*
>> + * This pixel output formats list referenced from,
>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>> + * 3.7.4 Pixel formats
>> + * Table 14. DSI pixel packing formats
>> + */
>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>> +    MEDIA_BUS_FMT_RGB565_1X16,
>> +    MEDIA_BUS_FMT_RGB666_1X18,
>> +    MEDIA_BUS_FMT_RGB888_1X24,
>> +};
>> +
>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>> +            return true;
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> +static u32 *
>> +samsung_dsim_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;
>> +
>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>> +        return NULL;
>
>
> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to 
> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>
> Otherwise the above check breaks all current clients of the Samsung 
> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all 
> DSI panels requests such format on my test systems...

I've checked a bit more the bus format related code and it looks that 
there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_* 
formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for 
them. On Arndale board with Toshiba tc358764 bridge the 
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in 
samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel, 
but this doesn't look like a format really needed on that bridge). A bit 
more logic seems to be needed there to make it working properly.

I suggest to move all this bus format related changes into a separate 
patchset and adjust other bridges/panels/etc as needed in it.

>
>> +
>> +    *num_input_fmts = 1;
>> +
>> +    input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>> +    if (!input_fmts)
>> +        return NULL;
>> +
>> +    input_fmts[0] = output_fmt;
>> +
>> +    return input_fmts;
>> +}
>> +
>>   static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
>>                        struct drm_bridge_state *bridge_state,
>>                        struct drm_crtc_state *crtc_state,
>> @@ -1385,6 +1437,7 @@ static const struct drm_bridge_funcs 
>> samsung_dsim_bridge_funcs = {
>>       .atomic_duplicate_state        = 
>> drm_atomic_helper_bridge_duplicate_state,
>>       .atomic_destroy_state        = 
>> drm_atomic_helper_bridge_destroy_state,
>>       .atomic_reset            = drm_atomic_helper_bridge_reset,
>> +    .atomic_get_input_bus_fmts    = 
>> samsung_dsim_atomic_get_input_bus_fmts,
>>       .atomic_check            = samsung_dsim_atomic_check,
>>       .atomic_pre_enable        = samsung_dsim_atomic_pre_enable,
>>       .atomic_enable            = samsung_dsim_atomic_enable,
>
> Best regards

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 14.11.2022 11:57, Marek Szyprowski wrote:
> > On 10.11.2022 19:38, Jagan Teki wrote:
> >> Finding the right input bus format throughout the pipeline is hard
> >> so add atomic_get_input_bus_fmts callback and initialize with the
> >> proper input format from list of supported output formats.
> >>
> >> This format can be used in pipeline for negotiating bus format between
> >> the DSI-end of this bridge and the other component closer to pipeline
> >> components.
> >>
> >> List of Pixel formats are taken from,
> >> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >> 3.7.4 Pixel formats
> >> Table 14. DSI pixel packing formats
> >>
> >> v8:
> >> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >>
> >> v7, v6, v5, v4:
> >> * none
> >>
> >> v3:
> >> * include media-bus-format.h
> >>
> >> v2:
> >> * none
> >>
> >> v1:
> >> * new patch
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >> ---
> >>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >>   1 file changed, 53 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> index 0fe153b29e4f..33e5ae9c865f 100644
> >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> @@ -15,6 +15,7 @@
> >>   #include <linux/clk.h>
> >>   #include <linux/delay.h>
> >>   #include <linux/irq.h>
> >> +#include <linux/media-bus-format.h>
> >>   #include <linux/of_device.h>
> >>   #include <linux/phy/phy.h>
> >>   @@ -1321,6 +1322,57 @@ static void
> >> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>       pm_runtime_put_sync(dsi->dev);
> >>   }
> >>   +/*
> >> + * This pixel output formats list referenced from,
> >> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >> + * 3.7.4 Pixel formats
> >> + * Table 14. DSI pixel packing formats
> >> + */
> >> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >> +    MEDIA_BUS_FMT_UYVY8_1X16,
> >> +    MEDIA_BUS_FMT_RGB101010_1X30,
> >> +    MEDIA_BUS_FMT_RGB121212_1X36,
> >> +    MEDIA_BUS_FMT_RGB565_1X16,
> >> +    MEDIA_BUS_FMT_RGB666_1X18,
> >> +    MEDIA_BUS_FMT_RGB888_1X24,
> >> +};
> >> +
> >> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >> +{
> >> +    int i;
> >> +
> >> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> >> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >> +            return true;
> >> +    }
> >> +
> >> +    return false;
> >> +}
> >> +
> >> +static u32 *
> >> +samsung_dsim_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;
> >> +
> >> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >> +        return NULL;
> >
> >
> > Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
> > MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
> >
> > Otherwise the above check breaks all current clients of the Samsung
> > DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
> > DSI panels requests such format on my test systems...
>
> I've checked a bit more the bus format related code and it looks that
> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
> them. On Arndale board with Toshiba tc358764 bridge the
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,

dsim => tc358764 => panel-simple

If I understand the bridge format negotiation correctly - If
atomic_get_input_bus_fmts is not implemented in tc358764 then
MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.

from include/drm/drm_bridge.h:

         * This method is called on all elements of the bridge chain as part of
         * the bus format negotiation process that happens in
         * drm_atomic_bridge_chain_select_bus_fmts().
         * This method is optional. When not implemented, the core will bypass
         * bus format negotiation on this element of the bridge without
         * failing, and the previous element in the chain will be passed
         * MEDIA_BUS_FMT_FIXED as its output bus format.

As I can see tc358764 is not implemented either
atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
atomic_get_input_bus_fmts I can see the dsim is getting
MEDIA_BUS_FMT_FIXED.

Can you check the same from your side?

On the other side, MEDIA_BUS_FMT_RGB888_1X7X4_SPWG is 24-bit samples
transferred over an LVDS bus with four differential data pairs,
serialized into 7-time slots using SPWG which indeed a
MEDIA_BUS_FMT_RGB888_1X24 input_fmt for the bridge. so handling in the
supported list and reassigning the RGB888_1X24 would be the proper way
to handle this format.

Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 14.11.2022 11:57, Marek Szyprowski wrote:
> > On 10.11.2022 19:38, Jagan Teki wrote:
> >> Finding the right input bus format throughout the pipeline is hard
> >> so add atomic_get_input_bus_fmts callback and initialize with the
> >> proper input format from list of supported output formats.
> >>
> >> This format can be used in pipeline for negotiating bus format between
> >> the DSI-end of this bridge and the other component closer to pipeline
> >> components.
> >>
> >> List of Pixel formats are taken from,
> >> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >> 3.7.4 Pixel formats
> >> Table 14. DSI pixel packing formats
> >>
> >> v8:
> >> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >>
> >> v7, v6, v5, v4:
> >> * none
> >>
> >> v3:
> >> * include media-bus-format.h
> >>
> >> v2:
> >> * none
> >>
> >> v1:
> >> * new patch
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >> ---
> >>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >>   1 file changed, 53 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> index 0fe153b29e4f..33e5ae9c865f 100644
> >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> @@ -15,6 +15,7 @@
> >>   #include <linux/clk.h>
> >>   #include <linux/delay.h>
> >>   #include <linux/irq.h>
> >> +#include <linux/media-bus-format.h>
> >>   #include <linux/of_device.h>
> >>   #include <linux/phy/phy.h>
> >>   @@ -1321,6 +1322,57 @@ static void
> >> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>       pm_runtime_put_sync(dsi->dev);
> >>   }
> >>   +/*
> >> + * This pixel output formats list referenced from,
> >> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >> + * 3.7.4 Pixel formats
> >> + * Table 14. DSI pixel packing formats
> >> + */
> >> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >> +    MEDIA_BUS_FMT_UYVY8_1X16,
> >> +    MEDIA_BUS_FMT_RGB101010_1X30,
> >> +    MEDIA_BUS_FMT_RGB121212_1X36,
> >> +    MEDIA_BUS_FMT_RGB565_1X16,
> >> +    MEDIA_BUS_FMT_RGB666_1X18,
> >> +    MEDIA_BUS_FMT_RGB888_1X24,
> >> +};
> >> +
> >> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >> +{
> >> +    int i;
> >> +
> >> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> >> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >> +            return true;
> >> +    }
> >> +
> >> +    return false;
> >> +}
> >> +
> >> +static u32 *
> >> +samsung_dsim_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;
> >> +
> >> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >> +        return NULL;
> >
> >
> > Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
> > MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
> >
> > Otherwise the above check breaks all current clients of the Samsung
> > DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
> > DSI panels requests such format on my test systems...
>
> I've checked a bit more the bus format related code and it looks that
> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
> them. On Arndale board with Toshiba tc358764 bridge the
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,

dsim => tc358764 => panel-simple

If I understand the bridge format negotiation correctly - If
atomic_get_input_bus_fmts is not implemented in tc358764 then
MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.

from include/drm/drm_bridge.h:

         * This method is called on all elements of the bridge chain as part of
         * the bus format negotiation process that happens in
         * drm_atomic_bridge_chain_select_bus_fmts().
         * This method is optional. When not implemented, the core will bypass
         * bus format negotiation on this element of the bridge without
         * failing, and the previous element in the chain will be passed
         * MEDIA_BUS_FMT_FIXED as its output bus format.

As I can see tc358764 is not implemented either
atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
atomic_get_input_bus_fmts I can see the dsim is getting
MEDIA_BUS_FMT_FIXED.

Can you check the same from your side?

On the other side, MEDIA_BUS_FMT_RGB888_1X7X4_SPWG is 24-bit samples
transferred over an LVDS bus with four differential data pairs,
serialized into 7-time slots using SPWG which indeed a
MEDIA_BUS_FMT_RGB888_1X24 input_fmt for the bridge. so handling in the
supported list and reassigning the RGB888_1X24 would be the proper way
to handle this format.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 14.11.2022 11:57, Marek Szyprowski wrote:
> > On 10.11.2022 19:38, Jagan Teki wrote:
> >> Finding the right input bus format throughout the pipeline is hard
> >> so add atomic_get_input_bus_fmts callback and initialize with the
> >> proper input format from list of supported output formats.
> >>
> >> This format can be used in pipeline for negotiating bus format between
> >> the DSI-end of this bridge and the other component closer to pipeline
> >> components.
> >>
> >> List of Pixel formats are taken from,
> >> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >> 3.7.4 Pixel formats
> >> Table 14. DSI pixel packing formats
> >>
> >> v8:
> >> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >>
> >> v7, v6, v5, v4:
> >> * none
> >>
> >> v3:
> >> * include media-bus-format.h
> >>
> >> v2:
> >> * none
> >>
> >> v1:
> >> * new patch
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >> ---
> >>   drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >>   1 file changed, 53 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> index 0fe153b29e4f..33e5ae9c865f 100644
> >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >> @@ -15,6 +15,7 @@
> >>   #include <linux/clk.h>
> >>   #include <linux/delay.h>
> >>   #include <linux/irq.h>
> >> +#include <linux/media-bus-format.h>
> >>   #include <linux/of_device.h>
> >>   #include <linux/phy/phy.h>
> >>   @@ -1321,6 +1322,57 @@ static void
> >> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>       pm_runtime_put_sync(dsi->dev);
> >>   }
> >>   +/*
> >> + * This pixel output formats list referenced from,
> >> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >> + * 3.7.4 Pixel formats
> >> + * Table 14. DSI pixel packing formats
> >> + */
> >> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >> +    MEDIA_BUS_FMT_UYVY8_1X16,
> >> +    MEDIA_BUS_FMT_RGB101010_1X30,
> >> +    MEDIA_BUS_FMT_RGB121212_1X36,
> >> +    MEDIA_BUS_FMT_RGB565_1X16,
> >> +    MEDIA_BUS_FMT_RGB666_1X18,
> >> +    MEDIA_BUS_FMT_RGB888_1X24,
> >> +};
> >> +
> >> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >> +{
> >> +    int i;
> >> +
> >> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> >> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >> +            return true;
> >> +    }
> >> +
> >> +    return false;
> >> +}
> >> +
> >> +static u32 *
> >> +samsung_dsim_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;
> >> +
> >> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >> +        return NULL;
> >
> >
> > Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
> > MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
> >
> > Otherwise the above check breaks all current clients of the Samsung
> > DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
> > DSI panels requests such format on my test systems...
>
> I've checked a bit more the bus format related code and it looks that
> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
> them. On Arndale board with Toshiba tc358764 bridge the
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,

dsim => tc358764 => panel-simple

If I understand the bridge format negotiation correctly - If
atomic_get_input_bus_fmts is not implemented in tc358764 then
MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.

from include/drm/drm_bridge.h:

         * This method is called on all elements of the bridge chain as part of
         * the bus format negotiation process that happens in
         * drm_atomic_bridge_chain_select_bus_fmts().
         * This method is optional. When not implemented, the core will bypass
         * bus format negotiation on this element of the bridge without
         * failing, and the previous element in the chain will be passed
         * MEDIA_BUS_FMT_FIXED as its output bus format.

As I can see tc358764 is not implemented either
atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
atomic_get_input_bus_fmts I can see the dsim is getting
MEDIA_BUS_FMT_FIXED.

Can you check the same from your side?

On the other side, MEDIA_BUS_FMT_RGB888_1X7X4_SPWG is 24-bit samples
transferred over an LVDS bus with four differential data pairs,
serialized into 7-time slots using SPWG which indeed a
MEDIA_BUS_FMT_RGB888_1X24 input_fmt for the bridge. so handling in the
supported list and reassigning the RGB888_1X24 would be the proper way
to handle this format.

Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

Hi Jagan,

On 14.11.2022 18:07, Jagan Teki wrote:
> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout the pipeline is hard
>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>> proper input format from list of supported output formats.
>>>>
>>>> This format can be used in pipeline for negotiating bus format between
>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>> components.
>>>>
>>>> List of Pixel formats are taken from,
>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> 3.7.4 Pixel formats
>>>> Table 14. DSI pixel packing formats
>>>>
>>>> v8:
>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>
>>>> v7, v6, v5, v4:
>>>> * none
>>>>
>>>> v3:
>>>> * include media-bus-format.h
>>>>
>>>> v2:
>>>> * none
>>>>
>>>> v1:
>>>> * new patch
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>    1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/clk.h>
>>>>    #include <linux/delay.h>
>>>>    #include <linux/irq.h>
>>>> +#include <linux/media-bus-format.h>
>>>>    #include <linux/of_device.h>
>>>>    #include <linux/phy/phy.h>
>>>>    @@ -1321,6 +1322,57 @@ static void
>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>        pm_runtime_put_sync(dsi->dev);
>>>>    }
>>>>    +/*
>>>> + * This pixel output formats list referenced from,
>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> + * 3.7.4 Pixel formats
>>>> + * Table 14. DSI pixel packing formats
>>>> + */
>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>> +};
>>>> +
>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>> +{
>>>> +    int i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>> +            return true;
>>>> +    }
>>>> +
>>>> +    return false;
>>>> +}
>>>> +
>>>> +static u32 *
>>>> +samsung_dsim_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;
>>>> +
>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> +        return NULL;
>>>
>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>
>>> Otherwise the above check breaks all current clients of the Samsung
>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>> DSI panels requests such format on my test systems...
>> I've checked a bit more the bus format related code and it looks that
>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>> them. On Arndale board with Toshiba tc358764 bridge the
>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
> dsim => tc358764 => panel-simple
>
> If I understand the bridge format negotiation correctly - If
> atomic_get_input_bus_fmts is not implemented in tc358764 then
> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>
> from include/drm/drm_bridge.h:
>
>           * This method is called on all elements of the bridge chain as part of
>           * the bus format negotiation process that happens in
>           * drm_atomic_bridge_chain_select_bus_fmts().
>           * This method is optional. When not implemented, the core will bypass
>           * bus format negotiation on this element of the bridge without
>           * failing, and the previous element in the chain will be passed
>           * MEDIA_BUS_FMT_FIXED as its output bus format.
>
> As I can see tc358764 is not implemented either
> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
> atomic_get_input_bus_fmts I can see the dsim is getting
> MEDIA_BUS_FMT_FIXED.
>
> Can you check the same from your side?

Here in case of Arndale 5250 with the following pipeline:

dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)

the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/

Maybe if no compatible bus format is found, the driver should force 
MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is 
implemented and hacks removed?


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

Hi Jagan,

On 14.11.2022 18:07, Jagan Teki wrote:
> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout the pipeline is hard
>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>> proper input format from list of supported output formats.
>>>>
>>>> This format can be used in pipeline for negotiating bus format between
>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>> components.
>>>>
>>>> List of Pixel formats are taken from,
>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> 3.7.4 Pixel formats
>>>> Table 14. DSI pixel packing formats
>>>>
>>>> v8:
>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>
>>>> v7, v6, v5, v4:
>>>> * none
>>>>
>>>> v3:
>>>> * include media-bus-format.h
>>>>
>>>> v2:
>>>> * none
>>>>
>>>> v1:
>>>> * new patch
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>    1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/clk.h>
>>>>    #include <linux/delay.h>
>>>>    #include <linux/irq.h>
>>>> +#include <linux/media-bus-format.h>
>>>>    #include <linux/of_device.h>
>>>>    #include <linux/phy/phy.h>
>>>>    @@ -1321,6 +1322,57 @@ static void
>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>        pm_runtime_put_sync(dsi->dev);
>>>>    }
>>>>    +/*
>>>> + * This pixel output formats list referenced from,
>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> + * 3.7.4 Pixel formats
>>>> + * Table 14. DSI pixel packing formats
>>>> + */
>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>> +};
>>>> +
>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>> +{
>>>> +    int i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>> +            return true;
>>>> +    }
>>>> +
>>>> +    return false;
>>>> +}
>>>> +
>>>> +static u32 *
>>>> +samsung_dsim_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;
>>>> +
>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> +        return NULL;
>>>
>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>
>>> Otherwise the above check breaks all current clients of the Samsung
>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>> DSI panels requests such format on my test systems...
>> I've checked a bit more the bus format related code and it looks that
>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>> them. On Arndale board with Toshiba tc358764 bridge the
>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
> dsim => tc358764 => panel-simple
>
> If I understand the bridge format negotiation correctly - If
> atomic_get_input_bus_fmts is not implemented in tc358764 then
> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>
> from include/drm/drm_bridge.h:
>
>           * This method is called on all elements of the bridge chain as part of
>           * the bus format negotiation process that happens in
>           * drm_atomic_bridge_chain_select_bus_fmts().
>           * This method is optional. When not implemented, the core will bypass
>           * bus format negotiation on this element of the bridge without
>           * failing, and the previous element in the chain will be passed
>           * MEDIA_BUS_FMT_FIXED as its output bus format.
>
> As I can see tc358764 is not implemented either
> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
> atomic_get_input_bus_fmts I can see the dsim is getting
> MEDIA_BUS_FMT_FIXED.
>
> Can you check the same from your side?

Here in case of Arndale 5250 with the following pipeline:

dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)

the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/

Maybe if no compatible bus format is found, the driver should force 
MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is 
implemented and hacks removed?


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

Hi Jagan,

On 14.11.2022 18:07, Jagan Teki wrote:
> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout the pipeline is hard
>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>> proper input format from list of supported output formats.
>>>>
>>>> This format can be used in pipeline for negotiating bus format between
>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>> components.
>>>>
>>>> List of Pixel formats are taken from,
>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> 3.7.4 Pixel formats
>>>> Table 14. DSI pixel packing formats
>>>>
>>>> v8:
>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>
>>>> v7, v6, v5, v4:
>>>> * none
>>>>
>>>> v3:
>>>> * include media-bus-format.h
>>>>
>>>> v2:
>>>> * none
>>>>
>>>> v1:
>>>> * new patch
>>>>
>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>> ---
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>    1 file changed, 53 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -15,6 +15,7 @@
>>>>    #include <linux/clk.h>
>>>>    #include <linux/delay.h>
>>>>    #include <linux/irq.h>
>>>> +#include <linux/media-bus-format.h>
>>>>    #include <linux/of_device.h>
>>>>    #include <linux/phy/phy.h>
>>>>    @@ -1321,6 +1322,57 @@ static void
>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>        pm_runtime_put_sync(dsi->dev);
>>>>    }
>>>>    +/*
>>>> + * This pixel output formats list referenced from,
>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>> + * 3.7.4 Pixel formats
>>>> + * Table 14. DSI pixel packing formats
>>>> + */
>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>> +};
>>>> +
>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>> +{
>>>> +    int i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>> +            return true;
>>>> +    }
>>>> +
>>>> +    return false;
>>>> +}
>>>> +
>>>> +static u32 *
>>>> +samsung_dsim_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;
>>>> +
>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> +        return NULL;
>>>
>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>
>>> Otherwise the above check breaks all current clients of the Samsung
>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>> DSI panels requests such format on my test systems...
>> I've checked a bit more the bus format related code and it looks that
>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>> them. On Arndale board with Toshiba tc358764 bridge the
>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
> dsim => tc358764 => panel-simple
>
> If I understand the bridge format negotiation correctly - If
> atomic_get_input_bus_fmts is not implemented in tc358764 then
> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>
> from include/drm/drm_bridge.h:
>
>           * This method is called on all elements of the bridge chain as part of
>           * the bus format negotiation process that happens in
>           * drm_atomic_bridge_chain_select_bus_fmts().
>           * This method is optional. When not implemented, the core will bypass
>           * bus format negotiation on this element of the bridge without
>           * failing, and the previous element in the chain will be passed
>           * MEDIA_BUS_FMT_FIXED as its output bus format.
>
> As I can see tc358764 is not implemented either
> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
> atomic_get_input_bus_fmts I can see the dsim is getting
> MEDIA_BUS_FMT_FIXED.
>
> Can you check the same from your side?

Here in case of Arndale 5250 with the following pipeline:

dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)

the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/

Maybe if no compatible bus format is found, the driver should force 
MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is 
implemented and hacks removed?


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Frieder Schrempf]

On 15.11.22 09:09, Marek Szyprowski wrote:
> Hi Jagan,
> 
> On 14.11.2022 18:07, Jagan Teki wrote:
>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>> proper input format from list of supported output formats.
>>>>>
>>>>> This format can be used in pipeline for negotiating bus format between
>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>> components.
>>>>>
>>>>> List of Pixel formats are taken from,
>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> 3.7.4 Pixel formats
>>>>> Table 14. DSI pixel packing formats
>>>>>
>>>>> v8:
>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>>
>>>>> v7, v6, v5, v4:
>>>>> * none
>>>>>
>>>>> v3:
>>>>> * include media-bus-format.h
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * new patch
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>>    1 file changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -15,6 +15,7 @@
>>>>>    #include <linux/clk.h>
>>>>>    #include <linux/delay.h>
>>>>>    #include <linux/irq.h>
>>>>> +#include <linux/media-bus-format.h>
>>>>>    #include <linux/of_device.h>
>>>>>    #include <linux/phy/phy.h>
>>>>>    @@ -1321,6 +1322,57 @@ static void
>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>        pm_runtime_put_sync(dsi->dev);
>>>>>    }
>>>>>    +/*
>>>>> + * This pixel output formats list referenced from,
>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> + * 3.7.4 Pixel formats
>>>>> + * Table 14. DSI pixel packing formats
>>>>> + */
>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>>> +};
>>>>> +
>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>> +{
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>> +            return true;
>>>>> +    }
>>>>> +
>>>>> +    return false;
>>>>> +}
>>>>> +
>>>>> +static u32 *
>>>>> +samsung_dsim_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;
>>>>> +
>>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>> +        return NULL;
>>>>
>>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>>
>>>> Otherwise the above check breaks all current clients of the Samsung
>>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>>> DSI panels requests such format on my test systems...
>>> I've checked a bit more the bus format related code and it looks that
>>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>>> them. On Arndale board with Toshiba tc358764 bridge the
>>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
>> dsim => tc358764 => panel-simple
>>
>> If I understand the bridge format negotiation correctly - If
>> atomic_get_input_bus_fmts is not implemented in tc358764 then
>> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
>> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>>
>> from include/drm/drm_bridge.h:
>>
>>           * This method is called on all elements of the bridge chain as part of
>>           * the bus format negotiation process that happens in
>>           * drm_atomic_bridge_chain_select_bus_fmts().
>>           * This method is optional. When not implemented, the core will bypass
>>           * bus format negotiation on this element of the bridge without
>>           * failing, and the previous element in the chain will be passed
>>           * MEDIA_BUS_FMT_FIXED as its output bus format.
>>
>> As I can see tc358764 is not implemented either
>> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
>> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
>> atomic_get_input_bus_fmts I can see the dsim is getting
>> MEDIA_BUS_FMT_FIXED.
>>
>> Can you check the same from your side?
> 
> Here in case of Arndale 5250 with the following pipeline:
> 
> dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
> 
> the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
> 
> Maybe if no compatible bus format is found, the driver should force 
> MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is 
> implemented and hacks removed?

For this specific case, wouldn't it be better to just fix the format
negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
from the DSI.

Forwarding the LVDS-specific format to the input is obviously the wrong
thing for the tc358764 driver to do.

But I agree, if there are other problematic pipelines with other
bridge/display drivers that don't pass a correct format, we should
accept them for now and fall back to a sane default
(MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.

Let's not delay this series any further and better work on how to get it
merged before we miss another merge window.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Frieder Schrempf]

On 15.11.22 09:09, Marek Szyprowski wrote:
> Hi Jagan,
> 
> On 14.11.2022 18:07, Jagan Teki wrote:
>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>> proper input format from list of supported output formats.
>>>>>
>>>>> This format can be used in pipeline for negotiating bus format between
>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>> components.
>>>>>
>>>>> List of Pixel formats are taken from,
>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> 3.7.4 Pixel formats
>>>>> Table 14. DSI pixel packing formats
>>>>>
>>>>> v8:
>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>>
>>>>> v7, v6, v5, v4:
>>>>> * none
>>>>>
>>>>> v3:
>>>>> * include media-bus-format.h
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * new patch
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>>    1 file changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -15,6 +15,7 @@
>>>>>    #include <linux/clk.h>
>>>>>    #include <linux/delay.h>
>>>>>    #include <linux/irq.h>
>>>>> +#include <linux/media-bus-format.h>
>>>>>    #include <linux/of_device.h>
>>>>>    #include <linux/phy/phy.h>
>>>>>    @@ -1321,6 +1322,57 @@ static void
>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>        pm_runtime_put_sync(dsi->dev);
>>>>>    }
>>>>>    +/*
>>>>> + * This pixel output formats list referenced from,
>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> + * 3.7.4 Pixel formats
>>>>> + * Table 14. DSI pixel packing formats
>>>>> + */
>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>>> +};
>>>>> +
>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>> +{
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>> +            return true;
>>>>> +    }
>>>>> +
>>>>> +    return false;
>>>>> +}
>>>>> +
>>>>> +static u32 *
>>>>> +samsung_dsim_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;
>>>>> +
>>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>> +        return NULL;
>>>>
>>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>>
>>>> Otherwise the above check breaks all current clients of the Samsung
>>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>>> DSI panels requests such format on my test systems...
>>> I've checked a bit more the bus format related code and it looks that
>>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>>> them. On Arndale board with Toshiba tc358764 bridge the
>>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
>> dsim => tc358764 => panel-simple
>>
>> If I understand the bridge format negotiation correctly - If
>> atomic_get_input_bus_fmts is not implemented in tc358764 then
>> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
>> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>>
>> from include/drm/drm_bridge.h:
>>
>>           * This method is called on all elements of the bridge chain as part of
>>           * the bus format negotiation process that happens in
>>           * drm_atomic_bridge_chain_select_bus_fmts().
>>           * This method is optional. When not implemented, the core will bypass
>>           * bus format negotiation on this element of the bridge without
>>           * failing, and the previous element in the chain will be passed
>>           * MEDIA_BUS_FMT_FIXED as its output bus format.
>>
>> As I can see tc358764 is not implemented either
>> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
>> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
>> atomic_get_input_bus_fmts I can see the dsim is getting
>> MEDIA_BUS_FMT_FIXED.
>>
>> Can you check the same from your side?
> 
> Here in case of Arndale 5250 with the following pipeline:
> 
> dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
> 
> the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
> 
> Maybe if no compatible bus format is found, the driver should force 
> MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is 
> implemented and hacks removed?

For this specific case, wouldn't it be better to just fix the format
negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
from the DSI.

Forwarding the LVDS-specific format to the input is obviously the wrong
thing for the tc358764 driver to do.

But I agree, if there are other problematic pipelines with other
bridge/display drivers that don't pass a correct format, we should
accept them for now and fall back to a sane default
(MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.

Let's not delay this series any further and better work on how to get it
merged before we miss another merge window.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Frieder Schrempf]

On 15.11.22 09:09, Marek Szyprowski wrote:
> Hi Jagan,
> 
> On 14.11.2022 18:07, Jagan Teki wrote:
>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>> proper input format from list of supported output formats.
>>>>>
>>>>> This format can be used in pipeline for negotiating bus format between
>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>> components.
>>>>>
>>>>> List of Pixel formats are taken from,
>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> 3.7.4 Pixel formats
>>>>> Table 14. DSI pixel packing formats
>>>>>
>>>>> v8:
>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>>
>>>>> v7, v6, v5, v4:
>>>>> * none
>>>>>
>>>>> v3:
>>>>> * include media-bus-format.h
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * new patch
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>>    1 file changed, 53 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -15,6 +15,7 @@
>>>>>    #include <linux/clk.h>
>>>>>    #include <linux/delay.h>
>>>>>    #include <linux/irq.h>
>>>>> +#include <linux/media-bus-format.h>
>>>>>    #include <linux/of_device.h>
>>>>>    #include <linux/phy/phy.h>
>>>>>    @@ -1321,6 +1322,57 @@ static void
>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>        pm_runtime_put_sync(dsi->dev);
>>>>>    }
>>>>>    +/*
>>>>> + * This pixel output formats list referenced from,
>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>> + * 3.7.4 Pixel formats
>>>>> + * Table 14. DSI pixel packing formats
>>>>> + */
>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>>> +};
>>>>> +
>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>> +{
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>> +            return true;
>>>>> +    }
>>>>> +
>>>>> +    return false;
>>>>> +}
>>>>> +
>>>>> +static u32 *
>>>>> +samsung_dsim_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;
>>>>> +
>>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>> +        return NULL;
>>>>
>>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>>
>>>> Otherwise the above check breaks all current clients of the Samsung
>>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>>> DSI panels requests such format on my test systems...
>>> I've checked a bit more the bus format related code and it looks that
>>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>>> them. On Arndale board with Toshiba tc358764 bridge the
>>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
>> dsim => tc358764 => panel-simple
>>
>> If I understand the bridge format negotiation correctly - If
>> atomic_get_input_bus_fmts is not implemented in tc358764 then
>> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
>> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>>
>> from include/drm/drm_bridge.h:
>>
>>           * This method is called on all elements of the bridge chain as part of
>>           * the bus format negotiation process that happens in
>>           * drm_atomic_bridge_chain_select_bus_fmts().
>>           * This method is optional. When not implemented, the core will bypass
>>           * bus format negotiation on this element of the bridge without
>>           * failing, and the previous element in the chain will be passed
>>           * MEDIA_BUS_FMT_FIXED as its output bus format.
>>
>> As I can see tc358764 is not implemented either
>> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
>> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
>> atomic_get_input_bus_fmts I can see the dsim is getting
>> MEDIA_BUS_FMT_FIXED.
>>
>> Can you check the same from your side?
> 
> Here in case of Arndale 5250 with the following pipeline:
> 
> dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
> 
> the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
> 
> Maybe if no compatible bus format is found, the driver should force 
> MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is 
> implemented and hacks removed?

For this specific case, wouldn't it be better to just fix the format
negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
from the DSI.

Forwarding the LVDS-specific format to the input is obviously the wrong
thing for the tc358764 driver to do.

But I agree, if there are other problematic pipelines with other
bridge/display drivers that don't pass a correct format, we should
accept them for now and fall back to a sane default
(MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.

Let's not delay this series any further and better work on how to get it
merged before we miss another merge window.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 15.11.22 09:09, Marek Szyprowski wrote:
> > Hi Jagan,
> >
> > On 14.11.2022 18:07, Jagan Teki wrote:
> >> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> >> <m.szyprowski@samsung.com> wrote:
> >>> On 14.11.2022 11:57, Marek Szyprowski wrote:
> >>>> On 10.11.2022 19:38, Jagan Teki wrote:
> >>>>> Finding the right input bus format throughout the pipeline is hard
> >>>>> so add atomic_get_input_bus_fmts callback and initialize with the
> >>>>> proper input format from list of supported output formats.
> >>>>>
> >>>>> This format can be used in pipeline for negotiating bus format between
> >>>>> the DSI-end of this bridge and the other component closer to pipeline
> >>>>> components.
> >>>>>
> >>>>> List of Pixel formats are taken from,
> >>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>> 3.7.4 Pixel formats
> >>>>> Table 14. DSI pixel packing formats
> >>>>>
> >>>>> v8:
> >>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >>>>>
> >>>>> v7, v6, v5, v4:
> >>>>> * none
> >>>>>
> >>>>> v3:
> >>>>> * include media-bus-format.h
> >>>>>
> >>>>> v2:
> >>>>> * none
> >>>>>
> >>>>> v1:
> >>>>> * new patch
> >>>>>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >>>>>    1 file changed, 53 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> index 0fe153b29e4f..33e5ae9c865f 100644
> >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> @@ -15,6 +15,7 @@
> >>>>>    #include <linux/clk.h>
> >>>>>    #include <linux/delay.h>
> >>>>>    #include <linux/irq.h>
> >>>>> +#include <linux/media-bus-format.h>
> >>>>>    #include <linux/of_device.h>
> >>>>>    #include <linux/phy/phy.h>
> >>>>>    @@ -1321,6 +1322,57 @@ static void
> >>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>>        pm_runtime_put_sync(dsi->dev);
> >>>>>    }
> >>>>>    +/*
> >>>>> + * This pixel output formats list referenced from,
> >>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>> + * 3.7.4 Pixel formats
> >>>>> + * Table 14. DSI pixel packing formats
> >>>>> + */
> >>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
> >>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
> >>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
> >>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
> >>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
> >>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
> >>>>> +};
> >>>>> +
> >>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >>>>> +{
> >>>>> +    int i;
> >>>>> +
> >>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> >>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >>>>> +            return true;
> >>>>> +    }
> >>>>> +
> >>>>> +    return false;
> >>>>> +}
> >>>>> +
> >>>>> +static u32 *
> >>>>> +samsung_dsim_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;
> >>>>> +
> >>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >>>>> +        return NULL;
> >>>>
> >>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
> >>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
> >>>>
> >>>> Otherwise the above check breaks all current clients of the Samsung
> >>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
> >>>> DSI panels requests such format on my test systems...
> >>> I've checked a bit more the bus format related code and it looks that
> >>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
> >>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
> >>> them. On Arndale board with Toshiba tc358764 bridge the
> >>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
> >>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
> >> dsim => tc358764 => panel-simple
> >>
> >> If I understand the bridge format negotiation correctly - If
> >> atomic_get_input_bus_fmts is not implemented in tc358764 then
> >> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
> >> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
> >>
> >> from include/drm/drm_bridge.h:
> >>
> >>           * This method is called on all elements of the bridge chain as part of
> >>           * the bus format negotiation process that happens in
> >>           * drm_atomic_bridge_chain_select_bus_fmts().
> >>           * This method is optional. When not implemented, the core will bypass
> >>           * bus format negotiation on this element of the bridge without
> >>           * failing, and the previous element in the chain will be passed
> >>           * MEDIA_BUS_FMT_FIXED as its output bus format.
> >>
> >> As I can see tc358764 is not implemented either
> >> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
> >> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
> >> atomic_get_input_bus_fmts I can see the dsim is getting
> >> MEDIA_BUS_FMT_FIXED.
> >>
> >> Can you check the same from your side?
> >
> > Here in case of Arndale 5250 with the following pipeline:
> >
> > dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
> >
> > the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
> >
> > Maybe if no compatible bus format is found, the driver should force
> > MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is
> > implemented and hacks removed?
>
> For this specific case, wouldn't it be better to just fix the format
> negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
> probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
> from the DSI.
>
> Forwarding the LVDS-specific format to the input is obviously the wrong
> thing for the tc358764 driver to do.
>
> But I agree, if there are other problematic pipelines with other
> bridge/display drivers that don't pass a correct format, we should
> accept them for now and fall back to a sane default
> (MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.
>
> Let's not delay this series any further and better work on how to get it
> merged before we miss another merge window.

Agreed this point, here is the updated diff (on top of this patch) for
falling back to the default format for those.

+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1387,6 +1387,8 @@ static const u32 samsung_dsim_pixel_output_fmts[] = {
        MEDIA_BUS_FMT_RGB565_1X16,
        MEDIA_BUS_FMT_RGB666_1X18,
        MEDIA_BUS_FMT_RGB888_1X24,
+
+       MEDIA_BUS_FMT_FIXED,
 };

 static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
@@ -1412,7 +1414,13 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
        u32 *input_fmts;

        if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
-               return NULL;
+               /*
+                * Some bridge/display drivers are still not able to pass
+                * the correct format, so handle those pipelines by falling
+                * back to the default format till the supported format list
+                * gets finalized.
+                */
+               output_fmt = MEDIA_BUS_FMT_RGB888_1X24;

        *num_input_fmts = 1;

@@ -1420,7 +1428,14 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
        if (!input_fmts)
                return NULL;

-       input_fmts[0] = output_fmt;
+       switch (output_fmt) {
+       case MEDIA_BUS_FMT_FIXED:
+               input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+               break;
+       default:
+               input_fmts[0] = output_fmt;
+               break;
+       }

        return input_fmts;

If all is okay, I will send v9 which would probably test it for the
final version to merge.

Thanks,
Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 15.11.22 09:09, Marek Szyprowski wrote:
> > Hi Jagan,
> >
> > On 14.11.2022 18:07, Jagan Teki wrote:
> >> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> >> <m.szyprowski@samsung.com> wrote:
> >>> On 14.11.2022 11:57, Marek Szyprowski wrote:
> >>>> On 10.11.2022 19:38, Jagan Teki wrote:
> >>>>> Finding the right input bus format throughout the pipeline is hard
> >>>>> so add atomic_get_input_bus_fmts callback and initialize with the
> >>>>> proper input format from list of supported output formats.
> >>>>>
> >>>>> This format can be used in pipeline for negotiating bus format between
> >>>>> the DSI-end of this bridge and the other component closer to pipeline
> >>>>> components.
> >>>>>
> >>>>> List of Pixel formats are taken from,
> >>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>> 3.7.4 Pixel formats
> >>>>> Table 14. DSI pixel packing formats
> >>>>>
> >>>>> v8:
> >>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >>>>>
> >>>>> v7, v6, v5, v4:
> >>>>> * none
> >>>>>
> >>>>> v3:
> >>>>> * include media-bus-format.h
> >>>>>
> >>>>> v2:
> >>>>> * none
> >>>>>
> >>>>> v1:
> >>>>> * new patch
> >>>>>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >>>>>    1 file changed, 53 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> index 0fe153b29e4f..33e5ae9c865f 100644
> >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> @@ -15,6 +15,7 @@
> >>>>>    #include <linux/clk.h>
> >>>>>    #include <linux/delay.h>
> >>>>>    #include <linux/irq.h>
> >>>>> +#include <linux/media-bus-format.h>
> >>>>>    #include <linux/of_device.h>
> >>>>>    #include <linux/phy/phy.h>
> >>>>>    @@ -1321,6 +1322,57 @@ static void
> >>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>>        pm_runtime_put_sync(dsi->dev);
> >>>>>    }
> >>>>>    +/*
> >>>>> + * This pixel output formats list referenced from,
> >>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>> + * 3.7.4 Pixel formats
> >>>>> + * Table 14. DSI pixel packing formats
> >>>>> + */
> >>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
> >>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
> >>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
> >>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
> >>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
> >>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
> >>>>> +};
> >>>>> +
> >>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >>>>> +{
> >>>>> +    int i;
> >>>>> +
> >>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> >>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >>>>> +            return true;
> >>>>> +    }
> >>>>> +
> >>>>> +    return false;
> >>>>> +}
> >>>>> +
> >>>>> +static u32 *
> >>>>> +samsung_dsim_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;
> >>>>> +
> >>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >>>>> +        return NULL;
> >>>>
> >>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
> >>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
> >>>>
> >>>> Otherwise the above check breaks all current clients of the Samsung
> >>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
> >>>> DSI panels requests such format on my test systems...
> >>> I've checked a bit more the bus format related code and it looks that
> >>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
> >>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
> >>> them. On Arndale board with Toshiba tc358764 bridge the
> >>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
> >>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
> >> dsim => tc358764 => panel-simple
> >>
> >> If I understand the bridge format negotiation correctly - If
> >> atomic_get_input_bus_fmts is not implemented in tc358764 then
> >> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
> >> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
> >>
> >> from include/drm/drm_bridge.h:
> >>
> >>           * This method is called on all elements of the bridge chain as part of
> >>           * the bus format negotiation process that happens in
> >>           * drm_atomic_bridge_chain_select_bus_fmts().
> >>           * This method is optional. When not implemented, the core will bypass
> >>           * bus format negotiation on this element of the bridge without
> >>           * failing, and the previous element in the chain will be passed
> >>           * MEDIA_BUS_FMT_FIXED as its output bus format.
> >>
> >> As I can see tc358764 is not implemented either
> >> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
> >> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
> >> atomic_get_input_bus_fmts I can see the dsim is getting
> >> MEDIA_BUS_FMT_FIXED.
> >>
> >> Can you check the same from your side?
> >
> > Here in case of Arndale 5250 with the following pipeline:
> >
> > dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
> >
> > the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
> >
> > Maybe if no compatible bus format is found, the driver should force
> > MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is
> > implemented and hacks removed?
>
> For this specific case, wouldn't it be better to just fix the format
> negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
> probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
> from the DSI.
>
> Forwarding the LVDS-specific format to the input is obviously the wrong
> thing for the tc358764 driver to do.
>
> But I agree, if there are other problematic pipelines with other
> bridge/display drivers that don't pass a correct format, we should
> accept them for now and fall back to a sane default
> (MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.
>
> Let's not delay this series any further and better work on how to get it
> merged before we miss another merge window.

Agreed this point, here is the updated diff (on top of this patch) for
falling back to the default format for those.

+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1387,6 +1387,8 @@ static const u32 samsung_dsim_pixel_output_fmts[] = {
        MEDIA_BUS_FMT_RGB565_1X16,
        MEDIA_BUS_FMT_RGB666_1X18,
        MEDIA_BUS_FMT_RGB888_1X24,
+
+       MEDIA_BUS_FMT_FIXED,
 };

 static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
@@ -1412,7 +1414,13 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
        u32 *input_fmts;

        if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
-               return NULL;
+               /*
+                * Some bridge/display drivers are still not able to pass
+                * the correct format, so handle those pipelines by falling
+                * back to the default format till the supported format list
+                * gets finalized.
+                */
+               output_fmt = MEDIA_BUS_FMT_RGB888_1X24;

        *num_input_fmts = 1;

@@ -1420,7 +1428,14 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
        if (!input_fmts)
                return NULL;

-       input_fmts[0] = output_fmt;
+       switch (output_fmt) {
+       case MEDIA_BUS_FMT_FIXED:
+               input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+               break;
+       default:
+               input_fmts[0] = output_fmt;
+               break;
+       }

        return input_fmts;

If all is okay, I will send v9 which would probably test it for the
final version to merge.

Thanks,
Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Jagan Teki]

On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 15.11.22 09:09, Marek Szyprowski wrote:
> > Hi Jagan,
> >
> > On 14.11.2022 18:07, Jagan Teki wrote:
> >> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> >> <m.szyprowski@samsung.com> wrote:
> >>> On 14.11.2022 11:57, Marek Szyprowski wrote:
> >>>> On 10.11.2022 19:38, Jagan Teki wrote:
> >>>>> Finding the right input bus format throughout the pipeline is hard
> >>>>> so add atomic_get_input_bus_fmts callback and initialize with the
> >>>>> proper input format from list of supported output formats.
> >>>>>
> >>>>> This format can be used in pipeline for negotiating bus format between
> >>>>> the DSI-end of this bridge and the other component closer to pipeline
> >>>>> components.
> >>>>>
> >>>>> List of Pixel formats are taken from,
> >>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>> 3.7.4 Pixel formats
> >>>>> Table 14. DSI pixel packing formats
> >>>>>
> >>>>> v8:
> >>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
> >>>>>
> >>>>> v7, v6, v5, v4:
> >>>>> * none
> >>>>>
> >>>>> v3:
> >>>>> * include media-bus-format.h
> >>>>>
> >>>>> v2:
> >>>>> * none
> >>>>>
> >>>>> v1:
> >>>>> * new patch
> >>>>>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
> >>>>>    1 file changed, 53 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> index 0fe153b29e4f..33e5ae9c865f 100644
> >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>>>> @@ -15,6 +15,7 @@
> >>>>>    #include <linux/clk.h>
> >>>>>    #include <linux/delay.h>
> >>>>>    #include <linux/irq.h>
> >>>>> +#include <linux/media-bus-format.h>
> >>>>>    #include <linux/of_device.h>
> >>>>>    #include <linux/phy/phy.h>
> >>>>>    @@ -1321,6 +1322,57 @@ static void
> >>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>>        pm_runtime_put_sync(dsi->dev);
> >>>>>    }
> >>>>>    +/*
> >>>>> + * This pixel output formats list referenced from,
> >>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>>> + * 3.7.4 Pixel formats
> >>>>> + * Table 14. DSI pixel packing formats
> >>>>> + */
> >>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
> >>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
> >>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
> >>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
> >>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
> >>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
> >>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
> >>>>> +};
> >>>>> +
> >>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> >>>>> +{
> >>>>> +    int i;
> >>>>> +
> >>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
> >>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
> >>>>> +            return true;
> >>>>> +    }
> >>>>> +
> >>>>> +    return false;
> >>>>> +}
> >>>>> +
> >>>>> +static u32 *
> >>>>> +samsung_dsim_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;
> >>>>> +
> >>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> >>>>> +        return NULL;
> >>>>
> >>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
> >>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
> >>>>
> >>>> Otherwise the above check breaks all current clients of the Samsung
> >>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
> >>>> DSI panels requests such format on my test systems...
> >>> I've checked a bit more the bus format related code and it looks that
> >>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
> >>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
> >>> them. On Arndale board with Toshiba tc358764 bridge the
> >>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
> >>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
> >> dsim => tc358764 => panel-simple
> >>
> >> If I understand the bridge format negotiation correctly - If
> >> atomic_get_input_bus_fmts is not implemented in tc358764 then
> >> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
> >> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
> >>
> >> from include/drm/drm_bridge.h:
> >>
> >>           * This method is called on all elements of the bridge chain as part of
> >>           * the bus format negotiation process that happens in
> >>           * drm_atomic_bridge_chain_select_bus_fmts().
> >>           * This method is optional. When not implemented, the core will bypass
> >>           * bus format negotiation on this element of the bridge without
> >>           * failing, and the previous element in the chain will be passed
> >>           * MEDIA_BUS_FMT_FIXED as its output bus format.
> >>
> >> As I can see tc358764 is not implemented either
> >> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
> >> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
> >> atomic_get_input_bus_fmts I can see the dsim is getting
> >> MEDIA_BUS_FMT_FIXED.
> >>
> >> Can you check the same from your side?
> >
> > Here in case of Arndale 5250 with the following pipeline:
> >
> > dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
> >
> > the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
> >
> > Maybe if no compatible bus format is found, the driver should force
> > MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is
> > implemented and hacks removed?
>
> For this specific case, wouldn't it be better to just fix the format
> negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
> probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
> from the DSI.
>
> Forwarding the LVDS-specific format to the input is obviously the wrong
> thing for the tc358764 driver to do.
>
> But I agree, if there are other problematic pipelines with other
> bridge/display drivers that don't pass a correct format, we should
> accept them for now and fall back to a sane default
> (MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.
>
> Let's not delay this series any further and better work on how to get it
> merged before we miss another merge window.

Agreed this point, here is the updated diff (on top of this patch) for
falling back to the default format for those.

+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1387,6 +1387,8 @@ static const u32 samsung_dsim_pixel_output_fmts[] = {
        MEDIA_BUS_FMT_RGB565_1X16,
        MEDIA_BUS_FMT_RGB666_1X18,
        MEDIA_BUS_FMT_RGB888_1X24,
+
+       MEDIA_BUS_FMT_FIXED,
 };

 static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
@@ -1412,7 +1414,13 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
        u32 *input_fmts;

        if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
-               return NULL;
+               /*
+                * Some bridge/display drivers are still not able to pass
+                * the correct format, so handle those pipelines by falling
+                * back to the default format till the supported format list
+                * gets finalized.
+                */
+               output_fmt = MEDIA_BUS_FMT_RGB888_1X24;

        *num_input_fmts = 1;

@@ -1420,7 +1428,14 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
        if (!input_fmts)
                return NULL;

-       input_fmts[0] = output_fmt;
+       switch (output_fmt) {
+       case MEDIA_BUS_FMT_FIXED:
+               input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+               break;
+       default:
+               input_fmts[0] = output_fmt;
+               break;
+       }

        return input_fmts;

If all is okay, I will send v9 which would probably test it for the
final version to merge.

Thanks,
Jagan.

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

Hi Jagan,

On 15.11.2022 10:20, Jagan Teki wrote:
> On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>> On 15.11.22 09:09, Marek Szyprowski wrote:
>>> On 14.11.2022 18:07, Jagan Teki wrote:
>>>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>>>> <m.szyprowski@samsung.com> wrote:
>>>>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>>>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>>>> proper input format from list of supported output formats.
>>>>>>>
>>>>>>> This format can be used in pipeline for negotiating bus format between
>>>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>>>> components.
>>>>>>>
>>>>>>> List of Pixel formats are taken from,
>>>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>>> 3.7.4 Pixel formats
>>>>>>> Table 14. DSI pixel packing formats
>>>>>>>
>>>>>>> v8:
>>>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>>>>
>>>>>>> v7, v6, v5, v4:
>>>>>>> * none
>>>>>>>
>>>>>>> v3:
>>>>>>> * include media-bus-format.h
>>>>>>>
>>>>>>> v2:
>>>>>>> * none
>>>>>>>
>>>>>>> v1:
>>>>>>> * new patch
>>>>>>>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>>>>     1 file changed, 53 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -15,6 +15,7 @@
>>>>>>>     #include <linux/clk.h>
>>>>>>>     #include <linux/delay.h>
>>>>>>>     #include <linux/irq.h>
>>>>>>> +#include <linux/media-bus-format.h>
>>>>>>>     #include <linux/of_device.h>
>>>>>>>     #include <linux/phy/phy.h>
>>>>>>>     @@ -1321,6 +1322,57 @@ static void
>>>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>>>     }
>>>>>>>     +/*
>>>>>>> + * This pixel output formats list referenced from,
>>>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>>> + * 3.7.4 Pixel formats
>>>>>>> + * Table 14. DSI pixel packing formats
>>>>>>> + */
>>>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>>>>> +};
>>>>>>> +
>>>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>>>> +{
>>>>>>> +    int i;
>>>>>>> +
>>>>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>>>> +            return true;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    return false;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static u32 *
>>>>>>> +samsung_dsim_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;
>>>>>>> +
>>>>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>>>> +        return NULL;
>>>>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>>>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>>>>
>>>>>> Otherwise the above check breaks all current clients of the Samsung
>>>>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>>>>> DSI panels requests such format on my test systems...
>>>>> I've checked a bit more the bus format related code and it looks that
>>>>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>>>>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>>>>> them. On Arndale board with Toshiba tc358764 bridge the
>>>>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>>>>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
>>>> dsim => tc358764 => panel-simple
>>>>
>>>> If I understand the bridge format negotiation correctly - If
>>>> atomic_get_input_bus_fmts is not implemented in tc358764 then
>>>> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
>>>> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>>>>
>>>> from include/drm/drm_bridge.h:
>>>>
>>>>            * This method is called on all elements of the bridge chain as part of
>>>>            * the bus format negotiation process that happens in
>>>>            * drm_atomic_bridge_chain_select_bus_fmts().
>>>>            * This method is optional. When not implemented, the core will bypass
>>>>            * bus format negotiation on this element of the bridge without
>>>>            * failing, and the previous element in the chain will be passed
>>>>            * MEDIA_BUS_FMT_FIXED as its output bus format.
>>>>
>>>> As I can see tc358764 is not implemented either
>>>> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
>>>> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
>>>> atomic_get_input_bus_fmts I can see the dsim is getting
>>>> MEDIA_BUS_FMT_FIXED.
>>>>
>>>> Can you check the same from your side?
>>> Here in case of Arndale 5250 with the following pipeline:
>>>
>>> dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
>>>
>>> the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
>>>
>>> Maybe if no compatible bus format is found, the driver should force
>>> MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is
>>> implemented and hacks removed?
>> For this specific case, wouldn't it be better to just fix the format
>> negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
>> probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
>> from the DSI.
>>
>> Forwarding the LVDS-specific format to the input is obviously the wrong
>> thing for the tc358764 driver to do.
>>
>> But I agree, if there are other problematic pipelines with other
>> bridge/display drivers that don't pass a correct format, we should
>> accept them for now and fall back to a sane default
>> (MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.
>>
>> Let's not delay this series any further and better work on how to get it
>> merged before we miss another merge window.
> Agreed this point, here is the updated diff (on top of this patch) for
> falling back to the default format for those.
>
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1387,6 +1387,8 @@ static const u32 samsung_dsim_pixel_output_fmts[] = {
>          MEDIA_BUS_FMT_RGB565_1X16,
>          MEDIA_BUS_FMT_RGB666_1X18,
>          MEDIA_BUS_FMT_RGB888_1X24,
> +
> +       MEDIA_BUS_FMT_FIXED,
>   };
>
>   static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> @@ -1412,7 +1414,13 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
> drm_bridge *bridge,
>          u32 *input_fmts;
>
>          if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> -               return NULL;
> +               /*
> +                * Some bridge/display drivers are still not able to pass
> +                * the correct format, so handle those pipelines by falling
> +                * back to the default format till the supported format list
> +                * gets finalized.
> +                */
> +               output_fmt = MEDIA_BUS_FMT_RGB888_1X24;
>
>          *num_input_fmts = 1;
>
> @@ -1420,7 +1428,14 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
> drm_bridge *bridge,
>          if (!input_fmts)
>                  return NULL;
>
> -       input_fmts[0] = output_fmt;
> +       switch (output_fmt) {
> +       case MEDIA_BUS_FMT_FIXED:
> +               input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> +               break;
> +       default:
> +               input_fmts[0] = output_fmt;
> +               break;
> +       }
>
>          return input_fmts;
>
> If all is okay, I will send v9 which would probably test it for the
> final version to merge.

This works for me (I've manually applied the above changes, due to 
malformed diff).

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

Hi Jagan,

On 15.11.2022 10:20, Jagan Teki wrote:
> On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>> On 15.11.22 09:09, Marek Szyprowski wrote:
>>> On 14.11.2022 18:07, Jagan Teki wrote:
>>>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>>>> <m.szyprowski@samsung.com> wrote:
>>>>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>>>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>>>> proper input format from list of supported output formats.
>>>>>>>
>>>>>>> This format can be used in pipeline for negotiating bus format between
>>>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>>>> components.
>>>>>>>
>>>>>>> List of Pixel formats are taken from,
>>>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>>> 3.7.4 Pixel formats
>>>>>>> Table 14. DSI pixel packing formats
>>>>>>>
>>>>>>> v8:
>>>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>>>>
>>>>>>> v7, v6, v5, v4:
>>>>>>> * none
>>>>>>>
>>>>>>> v3:
>>>>>>> * include media-bus-format.h
>>>>>>>
>>>>>>> v2:
>>>>>>> * none
>>>>>>>
>>>>>>> v1:
>>>>>>> * new patch
>>>>>>>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>>>>     1 file changed, 53 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -15,6 +15,7 @@
>>>>>>>     #include <linux/clk.h>
>>>>>>>     #include <linux/delay.h>
>>>>>>>     #include <linux/irq.h>
>>>>>>> +#include <linux/media-bus-format.h>
>>>>>>>     #include <linux/of_device.h>
>>>>>>>     #include <linux/phy/phy.h>
>>>>>>>     @@ -1321,6 +1322,57 @@ static void
>>>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>>>     }
>>>>>>>     +/*
>>>>>>> + * This pixel output formats list referenced from,
>>>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>>> + * 3.7.4 Pixel formats
>>>>>>> + * Table 14. DSI pixel packing formats
>>>>>>> + */
>>>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>>>>> +};
>>>>>>> +
>>>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>>>> +{
>>>>>>> +    int i;
>>>>>>> +
>>>>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>>>> +            return true;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    return false;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static u32 *
>>>>>>> +samsung_dsim_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;
>>>>>>> +
>>>>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>>>> +        return NULL;
>>>>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>>>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>>>>
>>>>>> Otherwise the above check breaks all current clients of the Samsung
>>>>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>>>>> DSI panels requests such format on my test systems...
>>>>> I've checked a bit more the bus format related code and it looks that
>>>>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>>>>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>>>>> them. On Arndale board with Toshiba tc358764 bridge the
>>>>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>>>>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
>>>> dsim => tc358764 => panel-simple
>>>>
>>>> If I understand the bridge format negotiation correctly - If
>>>> atomic_get_input_bus_fmts is not implemented in tc358764 then
>>>> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
>>>> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>>>>
>>>> from include/drm/drm_bridge.h:
>>>>
>>>>            * This method is called on all elements of the bridge chain as part of
>>>>            * the bus format negotiation process that happens in
>>>>            * drm_atomic_bridge_chain_select_bus_fmts().
>>>>            * This method is optional. When not implemented, the core will bypass
>>>>            * bus format negotiation on this element of the bridge without
>>>>            * failing, and the previous element in the chain will be passed
>>>>            * MEDIA_BUS_FMT_FIXED as its output bus format.
>>>>
>>>> As I can see tc358764 is not implemented either
>>>> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
>>>> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
>>>> atomic_get_input_bus_fmts I can see the dsim is getting
>>>> MEDIA_BUS_FMT_FIXED.
>>>>
>>>> Can you check the same from your side?
>>> Here in case of Arndale 5250 with the following pipeline:
>>>
>>> dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
>>>
>>> the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
>>>
>>> Maybe if no compatible bus format is found, the driver should force
>>> MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is
>>> implemented and hacks removed?
>> For this specific case, wouldn't it be better to just fix the format
>> negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
>> probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
>> from the DSI.
>>
>> Forwarding the LVDS-specific format to the input is obviously the wrong
>> thing for the tc358764 driver to do.
>>
>> But I agree, if there are other problematic pipelines with other
>> bridge/display drivers that don't pass a correct format, we should
>> accept them for now and fall back to a sane default
>> (MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.
>>
>> Let's not delay this series any further and better work on how to get it
>> merged before we miss another merge window.
> Agreed this point, here is the updated diff (on top of this patch) for
> falling back to the default format for those.
>
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1387,6 +1387,8 @@ static const u32 samsung_dsim_pixel_output_fmts[] = {
>          MEDIA_BUS_FMT_RGB565_1X16,
>          MEDIA_BUS_FMT_RGB666_1X18,
>          MEDIA_BUS_FMT_RGB888_1X24,
> +
> +       MEDIA_BUS_FMT_FIXED,
>   };
>
>   static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> @@ -1412,7 +1414,13 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
> drm_bridge *bridge,
>          u32 *input_fmts;
>
>          if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> -               return NULL;
> +               /*
> +                * Some bridge/display drivers are still not able to pass
> +                * the correct format, so handle those pipelines by falling
> +                * back to the default format till the supported format list
> +                * gets finalized.
> +                */
> +               output_fmt = MEDIA_BUS_FMT_RGB888_1X24;
>
>          *num_input_fmts = 1;
>
> @@ -1420,7 +1428,14 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
> drm_bridge *bridge,
>          if (!input_fmts)
>                  return NULL;
>
> -       input_fmts[0] = output_fmt;
> +       switch (output_fmt) {
> +       case MEDIA_BUS_FMT_FIXED:
> +               input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> +               break;
> +       default:
> +               input_fmts[0] = output_fmt;
> +               break;
> +       }
>
>          return input_fmts;
>
> If all is okay, I will send v9 which would probably test it for the
> final version to merge.

This works for me (I've manually applied the above changes, due to 
malformed diff).

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 09/14] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts

[Marek Szyprowski]

Hi Jagan,

On 15.11.2022 10:20, Jagan Teki wrote:
> On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
>> On 15.11.22 09:09, Marek Szyprowski wrote:
>>> On 14.11.2022 18:07, Jagan Teki wrote:
>>>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>>>> <m.szyprowski@samsung.com> wrote:
>>>>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>>>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>>>>> Finding the right input bus format throughout the pipeline is hard
>>>>>>> so add atomic_get_input_bus_fmts callback and initialize with the
>>>>>>> proper input format from list of supported output formats.
>>>>>>>
>>>>>>> This format can be used in pipeline for negotiating bus format between
>>>>>>> the DSI-end of this bridge and the other component closer to pipeline
>>>>>>> components.
>>>>>>>
>>>>>>> List of Pixel formats are taken from,
>>>>>>> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>>> 3.7.4 Pixel formats
>>>>>>> Table 14. DSI pixel packing formats
>>>>>>>
>>>>>>> v8:
>>>>>>> * added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
>>>>>>>
>>>>>>> v7, v6, v5, v4:
>>>>>>> * none
>>>>>>>
>>>>>>> v3:
>>>>>>> * include media-bus-format.h
>>>>>>>
>>>>>>> v2:
>>>>>>> * none
>>>>>>>
>>>>>>> v1:
>>>>>>> * new patch
>>>>>>>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 53 +++++++++++++++++++++++++++
>>>>>>>     1 file changed, 53 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index 0fe153b29e4f..33e5ae9c865f 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -15,6 +15,7 @@
>>>>>>>     #include <linux/clk.h>
>>>>>>>     #include <linux/delay.h>
>>>>>>>     #include <linux/irq.h>
>>>>>>> +#include <linux/media-bus-format.h>
>>>>>>>     #include <linux/of_device.h>
>>>>>>>     #include <linux/phy/phy.h>
>>>>>>>     @@ -1321,6 +1322,57 @@ static void
>>>>>>> samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
>>>>>>>         pm_runtime_put_sync(dsi->dev);
>>>>>>>     }
>>>>>>>     +/*
>>>>>>> + * This pixel output formats list referenced from,
>>>>>>> + * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
>>>>>>> + * 3.7.4 Pixel formats
>>>>>>> + * Table 14. DSI pixel packing formats
>>>>>>> + */
>>>>>>> +static const u32 samsung_dsim_pixel_output_fmts[] = {
>>>>>>> +    MEDIA_BUS_FMT_UYVY8_1X16,
>>>>>>> +    MEDIA_BUS_FMT_RGB101010_1X30,
>>>>>>> +    MEDIA_BUS_FMT_RGB121212_1X36,
>>>>>>> +    MEDIA_BUS_FMT_RGB565_1X16,
>>>>>>> +    MEDIA_BUS_FMT_RGB666_1X18,
>>>>>>> +    MEDIA_BUS_FMT_RGB888_1X24,
>>>>>>> +};
>>>>>>> +
>>>>>>> +static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
>>>>>>> +{
>>>>>>> +    int i;
>>>>>>> +
>>>>>>> +    for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
>>>>>>> +        if (samsung_dsim_pixel_output_fmts[i] == fmt)
>>>>>>> +            return true;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    return false;
>>>>>>> +}
>>>>>>> +
>>>>>>> +static u32 *
>>>>>>> +samsung_dsim_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;
>>>>>>> +
>>>>>>> +    if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>>>>> +        return NULL;
>>>>>> Please add support for MEDIA_BUS_FMT_FIXED and maybe default to
>>>>>> MEDIA_BUS_FMT_RGB888_1X24 if requested format is not matched.
>>>>>>
>>>>>> Otherwise the above check breaks all current clients of the Samsung
>>>>>> DSIM/Exynos DSI. I didn't dig into the bus matching code yet, but all
>>>>>> DSI panels requests such format on my test systems...
>>>>> I've checked a bit more the bus format related code and it looks that
>>>>> there are more issues. The DSI panels don't use the MEDIA_BUS_FMT_*
>>>>> formats thus the bridge negotiation code selects MEDIA_BUS_FMT_FIXED for
>>>>> them. On Arndale board with Toshiba tc358764 bridge the
>>>>> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG output_fmt is requested in
>>>>> samsung_dsim_atomic_get_input_bus_fmts() (forwarded from the LVDS panel,
>>>> dsim => tc358764 => panel-simple
>>>>
>>>> If I understand the bridge format negotiation correctly - If
>>>> atomic_get_input_bus_fmts is not implemented in tc358764 then
>>>> MEDIA_BUS_FMT_FIXED will be the output_fmt for dsim so we can assign
>>>> MEDIA_BUS_FMT_RGB888_1X24 for FIXED formats.
>>>>
>>>> from include/drm/drm_bridge.h:
>>>>
>>>>            * This method is called on all elements of the bridge chain as part of
>>>>            * the bus format negotiation process that happens in
>>>>            * drm_atomic_bridge_chain_select_bus_fmts().
>>>>            * This method is optional. When not implemented, the core will bypass
>>>>            * bus format negotiation on this element of the bridge without
>>>>            * failing, and the previous element in the chain will be passed
>>>>            * MEDIA_BUS_FMT_FIXED as its output bus format.
>>>>
>>>> As I can see tc358764 is not implemented either
>>>> atomic_get_input_bus_fmts or atomic API, so I think dsim gets the
>>>> MEDIA_BUS_FMT_FIXED bridge pipeline. I have tested sn65dsi without
>>>> atomic_get_input_bus_fmts I can see the dsim is getting
>>>> MEDIA_BUS_FMT_FIXED.
>>>>
>>>> Can you check the same from your side?
>>> Here in case of Arndale 5250 with the following pipeline:
>>>
>>> dsim => tc358764 => panel-simple (boe,hv070wsa-100 panel)
>>>
>>> the DRM core requests MEDIA_BUS_FMT_RGB888_1X7X4_SPWG format, taken from the boe_hv070wsa panel (see from drivers/gpu/drm/panel/panel-simple.c). Please note that in case of Exynos, the reversed bridge chain order is used for dsim, so this is another nasty consequence of that hack. :/
>>>
>>> Maybe if no compatible bus format is found, the driver should force
>>> MEDIA_BUS_FMT_RGB888_1X24 until a proper format negotiation is
>>> implemented and hacks removed?
>> For this specific case, wouldn't it be better to just fix the format
>> negotiation for tc358764 using atomic_get_input_bus_fmts()? It should
>> probably do the same as sn65dsi83 and request MEDIA_BUS_FMT_RGB888_1X24
>> from the DSI.
>>
>> Forwarding the LVDS-specific format to the input is obviously the wrong
>> thing for the tc358764 driver to do.
>>
>> But I agree, if there are other problematic pipelines with other
>> bridge/display drivers that don't pass a correct format, we should
>> accept them for now and fall back to a sane default
>> (MEDIA_BUS_FMT_RGB888_1X24) and fix the other drivers afterwards.
>>
>> Let's not delay this series any further and better work on how to get it
>> merged before we miss another merge window.
> Agreed this point, here is the updated diff (on top of this patch) for
> falling back to the default format for those.
>
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1387,6 +1387,8 @@ static const u32 samsung_dsim_pixel_output_fmts[] = {
>          MEDIA_BUS_FMT_RGB565_1X16,
>          MEDIA_BUS_FMT_RGB666_1X18,
>          MEDIA_BUS_FMT_RGB888_1X24,
> +
> +       MEDIA_BUS_FMT_FIXED,
>   };
>
>   static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
> @@ -1412,7 +1414,13 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
> drm_bridge *bridge,
>          u32 *input_fmts;
>
>          if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
> -               return NULL;
> +               /*
> +                * Some bridge/display drivers are still not able to pass
> +                * the correct format, so handle those pipelines by falling
> +                * back to the default format till the supported format list
> +                * gets finalized.
> +                */
> +               output_fmt = MEDIA_BUS_FMT_RGB888_1X24;
>
>          *num_input_fmts = 1;
>
> @@ -1420,7 +1428,14 @@ samsung_dsim_atomic_get_input_bus_fmts(struct
> drm_bridge *bridge,
>          if (!input_fmts)
>                  return NULL;
>
> -       input_fmts[0] = output_fmt;
> +       switch (output_fmt) {
> +       case MEDIA_BUS_FMT_FIXED:
> +               input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> +               break;
> +       default:
> +               input_fmts[0] = output_fmt;
> +               break;
> +       }
>
>          return input_fmts;
>
> If all is okay, I will send v9 which would probably test it for the
> final version to merge.

This works for me (I've manually applied the above changes, due to 
malformed diff).

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH v8 10/14] drm: bridge: samsung-dsim: Add input_bus_flags

[Jagan Teki]

LCDIF-DSIM glue logic inverts the HS/VS/DE signals and expecting
the i.MX8M Mini/Nano DSI host to add additional Data Enable signal
active low (DE_LOW). This makes the valid data transfer on each
horizontal line.

So, add additional bus flags DE_LOW setting via input_bus_flags for
i.MX8M Mini/Nano platforms.

v8:
* add DE_LOW for i.MX8M Mini/Nano platforms.

v7, v6:
* none

v5:
* rebased based on updated bridge changes

v4, v3, v2, v1:
* none

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 33e5ae9c865f..65f7d8522bc1 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1627,6 +1627,10 @@ static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
 	.unregister_host = samsung_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
 int samsung_dsim_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1709,6 +1713,10 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	dsi->bridge.of_node = dev->of_node;
 	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
+	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
+	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM)
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
 
-- 
2.25.1

[PATCH v8 10/14] drm: bridge: samsung-dsim: Add input_bus_flags

[Jagan Teki]

LCDIF-DSIM glue logic inverts the HS/VS/DE signals and expecting
the i.MX8M Mini/Nano DSI host to add additional Data Enable signal
active low (DE_LOW). This makes the valid data transfer on each
horizontal line.

So, add additional bus flags DE_LOW setting via input_bus_flags for
i.MX8M Mini/Nano platforms.

v8:
* add DE_LOW for i.MX8M Mini/Nano platforms.

v7, v6:
* none

v5:
* rebased based on updated bridge changes

v4, v3, v2, v1:
* none

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 33e5ae9c865f..65f7d8522bc1 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1627,6 +1627,10 @@ static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
 	.unregister_host = samsung_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
 int samsung_dsim_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1709,6 +1713,10 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	dsi->bridge.of_node = dev->of_node;
 	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
+	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
+	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM)
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 10/14] drm: bridge: samsung-dsim: Add input_bus_flags

[Jagan Teki]

LCDIF-DSIM glue logic inverts the HS/VS/DE signals and expecting
the i.MX8M Mini/Nano DSI host to add additional Data Enable signal
active low (DE_LOW). This makes the valid data transfer on each
horizontal line.

So, add additional bus flags DE_LOW setting via input_bus_flags for
i.MX8M Mini/Nano platforms.

v8:
* add DE_LOW for i.MX8M Mini/Nano platforms.

v7, v6:
* none

v5:
* rebased based on updated bridge changes

v4, v3, v2, v1:
* none

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 33e5ae9c865f..65f7d8522bc1 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1627,6 +1627,10 @@ static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
 	.unregister_host = samsung_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
 int samsung_dsim_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1709,6 +1713,10 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	dsi->bridge.of_node = dev->of_node;
 	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
+	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
+	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM)
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
 
-- 
2.25.1

[PATCH v8 11/14] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Mini/Nano SoC.

Add dt-bingings for it.

v8:
* add comment to include i.MX8M Nano.

v7, v6, v5, v4:
* none

v3:
* collect Rob Acked-by

v2:
* updated comments

v1:
* new patch

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index be377786e8cd..5133d4d39190 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -7,6 +7,7 @@ Required properties:
 		"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
+		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v8 11/14] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Mini/Nano SoC.

Add dt-bingings for it.

v8:
* add comment to include i.MX8M Nano.

v7, v6, v5, v4:
* none

v3:
* collect Rob Acked-by

v2:
* updated comments

v1:
* new patch

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index be377786e8cd..5133d4d39190 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -7,6 +7,7 @@ Required properties:
 		"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
+		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 11/14] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Mini/Nano SoC.

Add dt-bingings for it.

v8:
* add comment to include i.MX8M Nano.

v7, v6, v5, v4:
* none

v3:
* collect Rob Acked-by

v2:
* updated comments

v1:
* new patch

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index be377786e8cd..5133d4d39190 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -7,6 +7,7 @@ Required properties:
 		"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
+		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v8 12/14] drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.

Add compatible and associated driver_data for it.

v8:
* fix and update the comment

v7, v6:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v5:
* [mszyprow] rebased and adjusted to the new driver initialization
* drop quirk

v4:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v2:
* collect Laurent r-b

v1:
* none

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 44 +++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 65f7d8522bc1..41aa998f5bc4 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -360,6 +360,24 @@ static const unsigned int exynos5433_reg_values[] = {
 	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
 };
 
+static const unsigned int imx8mm_dsim_reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = 0,
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
 static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.reg_ofs = exynos_reg_ofs,
 	.plltmr_reg = 0x50,
@@ -421,6 +439,22 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.reg_values = exynos5422_reg_values,
 };
 
+static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 2100,
+	.wait_for_reset = 0,
+	.num_bits_resol = 12,
+	/*
+	 * Unlike Exynos, PLL_P(PMS_P) offset 14 is used in i.MX8M Mini/Nano/Plus
+	 * downstream driver - drivers/gpu/drm/bridge/sec-dsim.c
+	 */
+	.pll_p_offset = 14,
+	.reg_values = imx8mm_dsim_reg_values,
+};
+
 static const struct samsung_dsim_driver_data *
 samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS3250] = &exynos3_dsi_driver_data,
@@ -428,6 +462,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS5410] = &exynos5_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1817,7 +1852,16 @@ const struct dev_pm_ops samsung_dsim_pm_ops = {
 };
 EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_IMX8MM,
+	.host_ops = &samsung_dsim_generic_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
+	{
+		.compatible = "fsl,imx8mm-mipi-dsim",
+		.data = &samsung_dsim_imx8mm_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
-- 
2.25.1

[PATCH v8 12/14] drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.

Add compatible and associated driver_data for it.

v8:
* fix and update the comment

v7, v6:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v5:
* [mszyprow] rebased and adjusted to the new driver initialization
* drop quirk

v4:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v2:
* collect Laurent r-b

v1:
* none

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 44 +++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 65f7d8522bc1..41aa998f5bc4 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -360,6 +360,24 @@ static const unsigned int exynos5433_reg_values[] = {
 	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
 };
 
+static const unsigned int imx8mm_dsim_reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = 0,
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
 static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.reg_ofs = exynos_reg_ofs,
 	.plltmr_reg = 0x50,
@@ -421,6 +439,22 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.reg_values = exynos5422_reg_values,
 };
 
+static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 2100,
+	.wait_for_reset = 0,
+	.num_bits_resol = 12,
+	/*
+	 * Unlike Exynos, PLL_P(PMS_P) offset 14 is used in i.MX8M Mini/Nano/Plus
+	 * downstream driver - drivers/gpu/drm/bridge/sec-dsim.c
+	 */
+	.pll_p_offset = 14,
+	.reg_values = imx8mm_dsim_reg_values,
+};
+
 static const struct samsung_dsim_driver_data *
 samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS3250] = &exynos3_dsi_driver_data,
@@ -428,6 +462,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS5410] = &exynos5_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1817,7 +1852,16 @@ const struct dev_pm_ops samsung_dsim_pm_ops = {
 };
 EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_IMX8MM,
+	.host_ops = &samsung_dsim_generic_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
+	{
+		.compatible = "fsl,imx8mm-mipi-dsim",
+		.data = &samsung_dsim_imx8mm_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 12/14] drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.

Add compatible and associated driver_data for it.

v8:
* fix and update the comment

v7, v6:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v5:
* [mszyprow] rebased and adjusted to the new driver initialization
* drop quirk

v4:
* none

v3:
* enable DSIM_QUIRK_FIXUP_SYNC_POL quirk

v2:
* collect Laurent r-b

v1:
* none

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 44 +++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 65f7d8522bc1..41aa998f5bc4 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -360,6 +360,24 @@ static const unsigned int exynos5433_reg_values[] = {
 	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
 };
 
+static const unsigned int imx8mm_dsim_reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = 0,
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
 static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.reg_ofs = exynos_reg_ofs,
 	.plltmr_reg = 0x50,
@@ -421,6 +439,22 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.reg_values = exynos5422_reg_values,
 };
 
+static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 2100,
+	.wait_for_reset = 0,
+	.num_bits_resol = 12,
+	/*
+	 * Unlike Exynos, PLL_P(PMS_P) offset 14 is used in i.MX8M Mini/Nano/Plus
+	 * downstream driver - drivers/gpu/drm/bridge/sec-dsim.c
+	 */
+	.pll_p_offset = 14,
+	.reg_values = imx8mm_dsim_reg_values,
+};
+
 static const struct samsung_dsim_driver_data *
 samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS3250] = &exynos3_dsi_driver_data,
@@ -428,6 +462,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS5410] = &exynos5_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1817,7 +1852,16 @@ const struct dev_pm_ops samsung_dsim_pm_ops = {
 };
 EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_IMX8MM,
+	.host_ops = &samsung_dsim_generic_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
+	{
+		.compatible = "fsl,imx8mm-mipi-dsim",
+		.data = &samsung_dsim_imx8mm_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
-- 
2.25.1

[PATCH v8 13/14] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.

Add dt-bingings for it.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index 5133d4d39190..2a5f0889ec32 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -8,6 +8,7 @@ Required properties:
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
 		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
+		"fsl,imx8mp-mipi-dsim" /* for i.MX8M Plus SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v8 13/14] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.

Add dt-bingings for it.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index 5133d4d39190..2a5f0889ec32 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -8,6 +8,7 @@ Required properties:
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
 		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
+		"fsl,imx8mp-mipi-dsim" /* for i.MX8M Plus SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 13/14] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.

Add dt-bingings for it.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index 5133d4d39190..2a5f0889ec32 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -8,6 +8,7 @@ Required properties:
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
 		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
+		"fsl,imx8mp-mipi-dsim" /* for i.MX8M Plus SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v8 14/14] drm: bridge: samsung-dsim: Add i.MX8M Plus support

[Jagan Teki]

From: Marek Vasut <marex@denx.de>

Add extras to support i.MX8M Plus. The main change is the removal of
HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise
the implementation of this IP in i.MX8M Plus is very much compatible
with the i.MX8M Mini/Nano one.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 26 +++++++++++++++++++++++++-
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 41aa998f5bc4..b31a344ab3bf 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -463,6 +463,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_IMX8MP] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1425,10 +1426,17 @@ static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 	 * 13.6.2.7.2 RGB interface
 	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
 	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 *
+	 * The i.MX8M Plus glue logic between LCDIFv3 and DSIM does not
+	 * implement the same behavior, therefore LCDIFv3 must generate
+	 * HS/VS/DE signals active HIGH.
 	 */
 	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) {
 		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
 		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	} else if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MP) {
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
 	}
 
 	return 0;
@@ -1461,7 +1469,8 @@ static int samsung_dsim_attach(struct drm_bridge *bridge,
 	 * Passing NULL to the previous bridge makes Exynos DSI drivers
 	 * work which is exactly done before.
 	 */
-	if (!(dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM))
+	if (dsi->plat_data->hw_type != SAMSUNG_DSIM_TYPE_IMX8MM &&
+	    dsi->plat_data->hw_type != SAMSUNG_DSIM_TYPE_IMX8MP)
 		previous = NULL;
 
 	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, previous,
@@ -1662,6 +1671,10 @@ static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
 	.unregister_host = samsung_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_high = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
 static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
 	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
 };
@@ -1751,6 +1764,8 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
 	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM)
 		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+	else
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_high;
 
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
@@ -1857,11 +1872,20 @@ static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
 	.host_ops = &samsung_dsim_generic_host_ops,
 };
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mp_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_IMX8MP,
+	.host_ops = &samsung_dsim_generic_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
 	{
 		.compatible = "fsl,imx8mm-mipi-dsim",
 		.data = &samsung_dsim_imx8mm_pdata,
 	},
+	{
+		.compatible = "fsl,imx8mp-mipi-dsim",
+		.data = &samsung_dsim_imx8mp_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index df3d030daec6..3789f9dbb238 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -28,6 +28,7 @@ enum samsung_dsim_type {
 	SAMSUNG_DSIM_TYPE_EXYNOS5422,
 	SAMSUNG_DSIM_TYPE_EXYNOS5433,
 	SAMSUNG_DSIM_TYPE_IMX8MM,
+	SAMSUNG_DSIM_TYPE_IMX8MP,
 	SAMSUNG_DSIM_TYPE_COUNT,
 };
 
-- 
2.25.1

[PATCH v8 14/14] drm: bridge: samsung-dsim: Add i.MX8M Plus support

[Jagan Teki]

From: Marek Vasut <marex@denx.de>

Add extras to support i.MX8M Plus. The main change is the removal of
HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise
the implementation of this IP in i.MX8M Plus is very much compatible
with the i.MX8M Mini/Nano one.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 26 +++++++++++++++++++++++++-
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 41aa998f5bc4..b31a344ab3bf 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -463,6 +463,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_IMX8MP] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1425,10 +1426,17 @@ static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 	 * 13.6.2.7.2 RGB interface
 	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
 	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 *
+	 * The i.MX8M Plus glue logic between LCDIFv3 and DSIM does not
+	 * implement the same behavior, therefore LCDIFv3 must generate
+	 * HS/VS/DE signals active HIGH.
 	 */
 	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) {
 		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
 		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	} else if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MP) {
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
 	}
 
 	return 0;
@@ -1461,7 +1469,8 @@ static int samsung_dsim_attach(struct drm_bridge *bridge,
 	 * Passing NULL to the previous bridge makes Exynos DSI drivers
 	 * work which is exactly done before.
 	 */
-	if (!(dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM))
+	if (dsi->plat_data->hw_type != SAMSUNG_DSIM_TYPE_IMX8MM &&
+	    dsi->plat_data->hw_type != SAMSUNG_DSIM_TYPE_IMX8MP)
 		previous = NULL;
 
 	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, previous,
@@ -1662,6 +1671,10 @@ static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
 	.unregister_host = samsung_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_high = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
 static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
 	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
 };
@@ -1751,6 +1764,8 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
 	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM)
 		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+	else
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_high;
 
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
@@ -1857,11 +1872,20 @@ static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
 	.host_ops = &samsung_dsim_generic_host_ops,
 };
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mp_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_IMX8MP,
+	.host_ops = &samsung_dsim_generic_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
 	{
 		.compatible = "fsl,imx8mm-mipi-dsim",
 		.data = &samsung_dsim_imx8mm_pdata,
 	},
+	{
+		.compatible = "fsl,imx8mp-mipi-dsim",
+		.data = &samsung_dsim_imx8mp_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index df3d030daec6..3789f9dbb238 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -28,6 +28,7 @@ enum samsung_dsim_type {
 	SAMSUNG_DSIM_TYPE_EXYNOS5422,
 	SAMSUNG_DSIM_TYPE_EXYNOS5433,
 	SAMSUNG_DSIM_TYPE_IMX8MM,
+	SAMSUNG_DSIM_TYPE_IMX8MP,
 	SAMSUNG_DSIM_TYPE_COUNT,
 };
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 14/14] drm: bridge: samsung-dsim: Add i.MX8M Plus support

[Jagan Teki]

From: Marek Vasut <marex@denx.de>

Add extras to support i.MX8M Plus. The main change is the removal of
HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise
the implementation of this IP in i.MX8M Plus is very much compatible
with the i.MX8M Mini/Nano one.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 26 +++++++++++++++++++++++++-
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 41aa998f5bc4..b31a344ab3bf 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -463,6 +463,7 @@ samsung_dsim_types[SAMSUNG_DSIM_TYPE_COUNT] = {
 	[SAMSUNG_DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
 	[SAMSUNG_DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
+	[SAMSUNG_DSIM_TYPE_IMX8MP] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1425,10 +1426,17 @@ static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 	 * 13.6.2.7.2 RGB interface
 	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
 	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 *
+	 * The i.MX8M Plus glue logic between LCDIFv3 and DSIM does not
+	 * implement the same behavior, therefore LCDIFv3 must generate
+	 * HS/VS/DE signals active HIGH.
 	 */
 	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) {
 		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
 		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	} else if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MP) {
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
 	}
 
 	return 0;
@@ -1461,7 +1469,8 @@ static int samsung_dsim_attach(struct drm_bridge *bridge,
 	 * Passing NULL to the previous bridge makes Exynos DSI drivers
 	 * work which is exactly done before.
 	 */
-	if (!(dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM))
+	if (dsi->plat_data->hw_type != SAMSUNG_DSIM_TYPE_IMX8MM &&
+	    dsi->plat_data->hw_type != SAMSUNG_DSIM_TYPE_IMX8MP)
 		previous = NULL;
 
 	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, previous,
@@ -1662,6 +1671,10 @@ static const struct samsung_dsim_host_ops samsung_dsim_generic_host_ops = {
 	.unregister_host = samsung_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_high = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
 static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
 	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
 };
@@ -1751,6 +1764,8 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
 	if (dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM)
 		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+	else
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_high;
 
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
@@ -1857,11 +1872,20 @@ static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
 	.host_ops = &samsung_dsim_generic_host_ops,
 };
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mp_pdata = {
+	.hw_type = SAMSUNG_DSIM_TYPE_IMX8MP,
+	.host_ops = &samsung_dsim_generic_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
 	{
 		.compatible = "fsl,imx8mm-mipi-dsim",
 		.data = &samsung_dsim_imx8mm_pdata,
 	},
+	{
+		.compatible = "fsl,imx8mp-mipi-dsim",
+		.data = &samsung_dsim_imx8mp_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index df3d030daec6..3789f9dbb238 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -28,6 +28,7 @@ enum samsung_dsim_type {
 	SAMSUNG_DSIM_TYPE_EXYNOS5422,
 	SAMSUNG_DSIM_TYPE_EXYNOS5433,
 	SAMSUNG_DSIM_TYPE_IMX8MM,
+	SAMSUNG_DSIM_TYPE_IMX8MP,
 	SAMSUNG_DSIM_TYPE_COUNT,
 };
 
-- 
2.25.1

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Frieder Schrempf]

Hi Jagan,

On 10.11.22 19:38, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support

Did you miss to collect all the Tested-by tags from v7, or did you drop
them deliberately?

Best regards
Frieder

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Frieder Schrempf]

Hi Jagan,

On 10.11.22 19:38, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support

Did you miss to collect all the Tested-by tags from v7, or did you drop
them deliberately?

Best regards
Frieder

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Frieder Schrempf]

Hi Jagan,

On 10.11.22 19:38, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support

Did you miss to collect all the Tested-by tags from v7, or did you drop
them deliberately?

Best regards
Frieder

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

Hi Frieder,

On Mon, Nov 14, 2022 at 2:12 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> Hi Jagan,
>
> On 10.11.22 19:38, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> >
> > Changes for v8:
> > * fixed comment lines
> > * fixed commit messages
> > * fixed video mode bits
> > * collect Marek Ack
> > * fixed video mode bit names
> > * update input formats logic
> > * added imx8mplus support
>
> Did you miss to collect all the Tested-by tags from v7, or did you drop
> them deliberately?

Few changes in v8 compared to v7, so I've not picked these tags as code changes.

Jagan.

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

Hi Frieder,

On Mon, Nov 14, 2022 at 2:12 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> Hi Jagan,
>
> On 10.11.22 19:38, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> >
> > Changes for v8:
> > * fixed comment lines
> > * fixed commit messages
> > * fixed video mode bits
> > * collect Marek Ack
> > * fixed video mode bit names
> > * update input formats logic
> > * added imx8mplus support
>
> Did you miss to collect all the Tested-by tags from v7, or did you drop
> them deliberately?

Few changes in v8 compared to v7, so I've not picked these tags as code changes.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Jagan Teki]

Hi Frieder,

On Mon, Nov 14, 2022 at 2:12 PM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> Hi Jagan,
>
> On 10.11.22 19:38, Jagan Teki wrote:
> > This series supports common bridge support for Samsung MIPI DSIM
> > which is used in Exynos and i.MX8MM SoC's.
> >
> > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> >
> > Changes for v8:
> > * fixed comment lines
> > * fixed commit messages
> > * fixed video mode bits
> > * collect Marek Ack
> > * fixed video mode bit names
> > * update input formats logic
> > * added imx8mplus support
>
> Did you miss to collect all the Tested-by tags from v7, or did you drop
> them deliberately?

Few changes in v8 compared to v7, so I've not picked these tags as code changes.

Jagan.

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Frieder Schrempf]

On 10.11.22 19:38, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support
> 
> Changes for v7:
> * fix the drm bridge attach chain for exynos drm dsi driver
> * fix the hw_type checking logic
> 
> Changes for v6:
> * handle previous bridge for exynos dsi while attaching bridge 
> 
> Changes for v5:
> * bridge changes to support multi-arch
> * updated and clear commit messages
> * add hw_type via plat data
> * removed unneeded quirk
> * rebased on linux-next
> 
> Changes for v4:
> * include Inki Dae in MAINTAINERS
> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
> * update init handling to ensure host init done on first cmd transfer
> 
> Changes for v3:
> * fix the mult-arch build
> * fix dsi host init
> * updated commit messages
> 
> Changes for v2:
> * fix bridge handling
> * fix dsi host init
> * correct the commit messages
> 
> Patch 0001:	Fix MIPI_DSI*_NO_* mode bits
> 
> Patch 0002:	Properly name HSA/HBP/HFP/HSE bits
> 
> Patch 0003: 	Samsung DSIM bridge
> 
> Patch 0004:	PHY optional
> 
> Patch 0005:	OF-graph or Child node lookup
> 
> Patch 0006: 	DSI host initialization 
> 
> Patch 0007:	atomic check
> 
> Patch 0008:	PMS_P offset via plat data
> 
> Patch 0009:	atomic_get_input_bus_fmts
> 
> Patch 0010:	input_bus_flags
> 
> Patch 0011:	document fsl,imx8mm-mipi-dsim
> 
> Patch 0012:	add i.MX8M Mini/Nano DSIM support
> 
> Patch 0013:	document fsl,imx8mp-mipi-dsim
> 
> Patch 0014:	add i.MX8M Plus DSIM support
> 
> Tested in Engicam i.Core MX8M Mini SoM.
> 
> Repo:
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v8
> 
> Any inputs?
> Jagan.

I tested this on the Kontron DL i.MX8MM which uses a TI SN65DSI84 bridge
and a Jenson 7" LVDS Display.

Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron DL
i.MX8MM

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Frieder Schrempf]

On 10.11.22 19:38, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support
> 
> Changes for v7:
> * fix the drm bridge attach chain for exynos drm dsi driver
> * fix the hw_type checking logic
> 
> Changes for v6:
> * handle previous bridge for exynos dsi while attaching bridge 
> 
> Changes for v5:
> * bridge changes to support multi-arch
> * updated and clear commit messages
> * add hw_type via plat data
> * removed unneeded quirk
> * rebased on linux-next
> 
> Changes for v4:
> * include Inki Dae in MAINTAINERS
> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
> * update init handling to ensure host init done on first cmd transfer
> 
> Changes for v3:
> * fix the mult-arch build
> * fix dsi host init
> * updated commit messages
> 
> Changes for v2:
> * fix bridge handling
> * fix dsi host init
> * correct the commit messages
> 
> Patch 0001:	Fix MIPI_DSI*_NO_* mode bits
> 
> Patch 0002:	Properly name HSA/HBP/HFP/HSE bits
> 
> Patch 0003: 	Samsung DSIM bridge
> 
> Patch 0004:	PHY optional
> 
> Patch 0005:	OF-graph or Child node lookup
> 
> Patch 0006: 	DSI host initialization 
> 
> Patch 0007:	atomic check
> 
> Patch 0008:	PMS_P offset via plat data
> 
> Patch 0009:	atomic_get_input_bus_fmts
> 
> Patch 0010:	input_bus_flags
> 
> Patch 0011:	document fsl,imx8mm-mipi-dsim
> 
> Patch 0012:	add i.MX8M Mini/Nano DSIM support
> 
> Patch 0013:	document fsl,imx8mp-mipi-dsim
> 
> Patch 0014:	add i.MX8M Plus DSIM support
> 
> Tested in Engicam i.Core MX8M Mini SoM.
> 
> Repo:
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v8
> 
> Any inputs?
> Jagan.

I tested this on the Kontron DL i.MX8MM which uses a TI SN65DSI84 bridge
and a Jenson 7" LVDS Display.

Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron DL
i.MX8MM

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 00/14] drm: bridge: Add Samsung MIPI DSIM bridge

[Frieder Schrempf]

On 10.11.22 19:38, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
> 
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
> 
> Changes for v8:
> * fixed comment lines
> * fixed commit messages
> * fixed video mode bits
> * collect Marek Ack
> * fixed video mode bit names
> * update input formats logic
> * added imx8mplus support
> 
> Changes for v7:
> * fix the drm bridge attach chain for exynos drm dsi driver
> * fix the hw_type checking logic
> 
> Changes for v6:
> * handle previous bridge for exynos dsi while attaching bridge 
> 
> Changes for v5:
> * bridge changes to support multi-arch
> * updated and clear commit messages
> * add hw_type via plat data
> * removed unneeded quirk
> * rebased on linux-next
> 
> Changes for v4:
> * include Inki Dae in MAINTAINERS
> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
> * update init handling to ensure host init done on first cmd transfer
> 
> Changes for v3:
> * fix the mult-arch build
> * fix dsi host init
> * updated commit messages
> 
> Changes for v2:
> * fix bridge handling
> * fix dsi host init
> * correct the commit messages
> 
> Patch 0001:	Fix MIPI_DSI*_NO_* mode bits
> 
> Patch 0002:	Properly name HSA/HBP/HFP/HSE bits
> 
> Patch 0003: 	Samsung DSIM bridge
> 
> Patch 0004:	PHY optional
> 
> Patch 0005:	OF-graph or Child node lookup
> 
> Patch 0006: 	DSI host initialization 
> 
> Patch 0007:	atomic check
> 
> Patch 0008:	PMS_P offset via plat data
> 
> Patch 0009:	atomic_get_input_bus_fmts
> 
> Patch 0010:	input_bus_flags
> 
> Patch 0011:	document fsl,imx8mm-mipi-dsim
> 
> Patch 0012:	add i.MX8M Mini/Nano DSIM support
> 
> Patch 0013:	document fsl,imx8mp-mipi-dsim
> 
> Patch 0014:	add i.MX8M Plus DSIM support
> 
> Tested in Engicam i.Core MX8M Mini SoM.
> 
> Repo:
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v8
> 
> Any inputs?
> Jagan.

I tested this on the Kontron DL i.MX8MM which uses a TI SN65DSI84 bridge
and a Jenson 7" LVDS Display.

Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron DL
i.MX8MM