Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding

[Marek Szyprowski]

On 25.04.2024 22:30, Adam Ford wrote:
> On Thu, Apr 25, 2024 at 4:19 AM Marek Szyprowski
>  wrote:
>> On 12.02.2024 00:09, Adam Ford wrote:
>>> When using video sync pulses, the HFP, HBP, and HSA are divided between
>>> the available lanes if there is more than one lane.  For certain
>>> timings and lane configurations, the HFP may not be evenly divisible.
>>> If the HFP is rounded down, it ends up being too small which can cause
>>> some monitors to not sync properly. In these instances, adjust htotal
>>> and hsync to round the HFP up, and recalculate the htotal.
>>>
>>> Tested-by: Frieder Schrempf  # Kontron BL 
>>> i.MX8MM with HDMI monitor
>>> Signed-off-by: Adam Ford 
>> Tested-by: Marek Szyprowski 
> Thank you very much for testing!
>
>>> ---
>>> V2:  No changes
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 8476650c477c..52939211fe93 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct 
>>> drm_bridge *bridge,
>>>adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | 
>>> DRM_MODE_FLAG_PVSYNC);
>>>}
>>>
>>> + /*
>>> +  * When using video sync pulses, the HFP, HBP, and HSA are divided 
>>> between
>>> +  * the available lanes if there is more than one lane.  For certain
>>> +  * timings and lane configurations, the HFP may not be evenly 
>>> divisible.
>>> +  * If the HFP is rounded down, it ends up being too small which can 
>>> cause
>>> +  * some monitors to not sync properly. In these instances, adjust 
>>> htotal
>>> +  * and hsync to round the HFP up, and recalculate the htotal. Through 
>>> trial
>>> +  * and error, it appears that the HBP and HSA do not appearto need 
>>> the same
>>> +  * correction that HFP does.
>>> +  */
>>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 
>>> 1) {
> Frieder  &  Marek S,
>
> Marek V is proposing we eliminate the check against the flags and do
> it unconditionally.  If I send you both a different patch, would you
> be willing to try them on your platforms?  I don't want to risk
> breaking a board.

I'm fine with testing it. I also have some additional spare boards to 
replace the broken one, but so far none was bricked by my weird testing 
activities.

> I used the check above from the NXP downstream kernel, so it felt
> safe, but I am not as familiar with the different DSI modes, so I am
> not sure what the impact would be if this read:
>
>   if (dsi->lanes > 1) {
>
> Does anyone else have an opinion on this?
>>> + int hfp = adjusted_mode->hsync_start - 
>>> adjusted_mode->hdisplay;
>>> + int remainder = hfp % dsi->lanes;
>>> +
>>> + if (remainder) {
>>> + adjusted_mode->hsync_start += remainder;
>>> + adjusted_mode->hsync_end   += remainder;
>>> + adjusted_mode->htotal  += remainder;
>>> + }
>>> + }
>>> +
>>>return 0;
>>>}

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

[PATCH] drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found

[Marek Szyprowski]

When reading EDID fails and driver reports no modes available, the DRM
core adds an artificial 1024x786 mode to the connector. Unfortunately
some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not
able to drive such mode, so report a safe 640x480 mode instead of nothing
in case of the EDID reading failure.

This fixes the following issue observed on Trats2 board since commit
13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"):

[drm] Exynos DRM: using 11c0.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops)
exynos-drm exynos-drm: bound 12c1.mixer (ops mixer_component_ops)
exynos-dsi 11c8.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device 
(lanes:4 bpp:24 mode-flags:0x10b)
exynos-drm exynos-drm: bound 11c8.dsi (ops exynos_dsi_component_ops)
exynos-drm exynos-drm: bound 12d0.hdmi (ops hdmi_component_ops)
[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
exynos-hdmi 12d0.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not 
reach steady state
panel-samsung-s6e8aa0 11c8.dsi.0: ID: 0xa2, 0x20, 0x8c
exynos-mixer 12c1.mixer: timeout waiting for VSYNC
[ cut here ]
WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 
drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
[CRTC:70:crtc-1] vblank wait timed out
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x68/0x88
 dump_stack_lvl from __warn+0x7c/0x1c4
 __warn from warn_slowpath_fmt+0x11c/0x1a8
 warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
 drm_atomic_helper_wait_for_vblanks.part.0 from 
drm_atomic_helper_commit_tail_rpm+0x7c/0x8c
 drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184
 commit_tail from drm_atomic_helper_commit+0x168/0x190
 drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0
 drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c
 drm_client_modeset_commit_atomic from 
drm_client_modeset_commit_locked+0x60/0x1cc
 drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40
 drm_client_modeset_commit from 
__drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4
 __drm_fb_helper_restore_fbdev_mode_unlocked from 
drm_fb_helper_set_par+0x2c/0x3c
 drm_fb_helper_set_par from fbcon_init+0x3d8/0x550
 fbcon_init from visual_init+0xc0/0x108
 visual_init from do_bind_con_driver+0x1b8/0x3a4
 do_bind_con_driver from do_take_over_console+0x140/0x1ec
 do_take_over_console from do_fbcon_takeover+0x70/0xd0
 do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac
 fbcon_fb_registered from register_framebuffer+0x190/0x21c
 register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574
 __drm_fb_helper_initial_config_and_unlock from 
exynos_drm_fbdev_client_hotplug+0x6c/0xb0
 exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94
 drm_client_register from exynos_drm_bind+0x160/0x190
 exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8
 try_to_bring_up_aggregate_device from __component_add+0xb0/0x170
 __component_add from mixer_probe+0x74/0xcc
 mixer_probe from platform_probe+0x5c/0xb8
 platform_probe from really_probe+0xe0/0x3d8
 really_probe from __driver_probe_device+0x9c/0x1e4
 __driver_probe_device from driver_probe_device+0x30/0xc0
 driver_probe_device from __device_attach_driver+0xa8/0x120
 __device_attach_driver from bus_for_each_drv+0x80/0xcc
 bus_for_each_drv from __device_attach+0xac/0x1fc
 __device_attach from bus_probe_device+0x8c/0x90
 bus_probe_device from deferred_probe_work_func+0x98/0xe0
 deferred_probe_work_func from process_one_work+0x240/0x6d0
 process_one_work from worker_thread+0x1a0/0x3f4
 worker_thread from kthread+0x104/0x138
 kthread from ret_from_fork+0x14/0x28
Exception stack(0xf0895fb0 to 0xf0895ff8)
...
irq event stamp: 82357
hardirqs last  enabled at (82363): [] vprintk_emit+0x308/0x33c
hardirqs last disabled at (82368): [] vprintk_emit+0x2bc/0x33c
softirqs last  enabled at (81614): [] __do_softirq+0x320/0x500
softirqs last disabled at (81609): [] __irq_exit_rcu+0x130/0x184
---[ end trace  ]---
exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
exynos-drm exynos-drm: [drm] *ERROR* [CRTC:70:crtc-1] commit wait timed out
exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
exynos-drm exynos-drm: [drm] *ERROR* [CONNECTOR:74:HDMI-A-1] commit wait timed 
out
exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
exynos-drm exynos-drm: [drm] *ERROR* [PLANE:56:plane-5] commit wait timed out
exynos-mixer 12c1.mixer: timeout waiting for VSYNC

Cc: sta...@vger.kernel.org
Fixes: 13d5b040363c ("drm/exynos: do not return negative values from 
.get_modes()")

Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding

[Marek Szyprowski]

On 12.02.2024 00:09, Adam Ford wrote:
> When using video sync pulses, the HFP, HBP, and HSA are divided between
> the available lanes if there is more than one lane.  For certain
> timings and lane configurations, the HFP may not be evenly divisible.
> If the HFP is rounded down, it ends up being too small which can cause
> some monitors to not sync properly. In these instances, adjust htotal
> and hsync to round the HFP up, and recalculate the htotal.
>
> Tested-by: Frieder Schrempf  # Kontron BL 
> i.MX8MM with HDMI monitor
> Signed-off-by: Adam Ford 

Tested-by: Marek Szyprowski 

> ---
> V2:  No changes
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 8476650c477c..52939211fe93 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge 
> *bridge,
>   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | 
> DRM_MODE_FLAG_PVSYNC);
>   }
>   
> + /*
> +  * When using video sync pulses, the HFP, HBP, and HSA are divided 
> between
> +  * the available lanes if there is more than one lane.  For certain
> +  * timings and lane configurations, the HFP may not be evenly divisible.
> +  * If the HFP is rounded down, it ends up being too small which can 
> cause
> +  * some monitors to not sync properly. In these instances, adjust htotal
> +  * and hsync to round the HFP up, and recalculate the htotal. Through 
> trial
> +  * and error, it appears that the HBP and HSA do not appearto need the 
> same
> +  * correction that HFP does.
> +  */
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1) 
> {
> + int hfp = adjusted_mode->hsync_start - adjusted_mode->hdisplay;
> + int remainder = hfp % dsi->lanes;
> +
> + if (remainder) {
> + adjusted_mode->hsync_start += remainder;
> + adjusted_mode->hsync_end   += remainder;
> + adjusted_mode->htotal  += remainder;
> + }
> + }
> +
>   return 0;
>   }
>   

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

Re: [PATCH V2 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll

[Marek Szyprowski]

On 12.02.2024 00:09, Adam Ford wrote:
> The P divider should be set based on the min and max values of
> the fin pll which may vary between different platforms.
> These ranges are defined per platform, but hard-coded values
> were used instead which resulted in a smaller range available
> on the i.MX8M[MNP] than what was possible.
>
> As noted by Frieder, there are descripencies between the reference
> manuals of the Mini, Nano and Plus, so I reached out to my NXP
> rep and got the following response regarding the varing notes
> in the documentation.
>
> "Yes it is definitely wrong, the one that is part of the NOTE in
> MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
> not correct. I will report this to Doc team, the one customer should
> be take into account is the Table 13-40 DPHY PLL Parameters and the
> Note above."
>
> With this patch, the clock rates now match the values used in NXP's
> downstream kernel.
>
> Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
> Signed-off-by: Adam Ford 
> Reviewed-by: Frieder Schrempf 
> Tested-by: Frieder Schrempf 

Feel free to add:

Tested-by: Marek Szyprowski 

although all Exynos based boards have panels with fixed timings afair.

> ---
> V2:  Only update the commit message to reflect why these values
>   were chosen.  No code change present
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 95fedc68b0ae..8476650c477c 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -574,8 +574,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct 
> samsung_dsim *dsi,
>   u16 _m, best_m;
>   u8 _s, best_s;
>   
> - p_min = DIV_ROUND_UP(fin, (12 * MHZ));
> - p_max = fin / (6 * MHZ);
> + p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
> + p_max = fin / (driver_data->pll_fin_min * MHZ);
>   
>   for (_p = p_min; _p <= p_max; ++_p) {
>   for (_s = 0; _s <= 5; ++_s) {

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

Re: [PATCH] drm/exynos: fix .get_modes return value in case of errors

[Marek Szyprowski]

On 23.04.2024 22:44, Marek Szyprowski wrote:
> Commit 7af03e688792 ("drm/probe-helper: warn about negative
> .get_modes()") clarified, that .get_modes callback must not return
> negative values on failure, so fix sub-drivers to return 0 in case of
> errors. This fixes strange Exynos DRM initialization failure on boot
> (timeout waiting for VSYNC) observed on Trats2 board.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Marek Szyprowski 

Ah, I've missed that this has been already fixed in -next by the patch 
13d5b040363c ("drm/exynos: do not return negative values from 
.get_modes()"), so ignore this one. I'm sorry for the noise.

> ---
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
>   drivers/gpu/drm/exynos/exynos_hdmi.c | 4 ++--
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index e5662bdcbbde..e3868956eb88 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -315,14 +315,14 @@ static int vidi_get_modes(struct drm_connector 
> *connector)
>*/
>   if (!ctx->raw_edid) {
>   DRM_DEV_DEBUG_KMS(ctx->dev, "raw_edid is null.\n");
> - return -EFAULT;
> + return 0;
>   }
>   
>   edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
>   edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
>   if (!edid) {
>   DRM_DEV_DEBUG_KMS(ctx->dev, "failed to allocate edid\n");
> - return -ENOMEM;
> + return 0;
>   }
>   
>   drm_connector_update_edid_property(connector, edid);
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index c5ba32fca5f3..603d8bb0b03a 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -878,11 +878,11 @@ static int hdmi_get_modes(struct drm_connector 
> *connector)
>   int ret;
>   
>   if (!hdata->ddc_adpt)
> - return -ENODEV;
> + return 0;
>   
>   edid = drm_get_edid(connector, hdata->ddc_adpt);
>   if (!edid)
> -     return -ENODEV;
> + return 0;
>   
>   hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
>   DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",

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

[PATCH] drm/exynos: fix .get_modes return value in case of errors

[Marek Szyprowski]

Commit 7af03e688792 ("drm/probe-helper: warn about negative
.get_modes()") clarified, that .get_modes callback must not return
negative values on failure, so fix sub-drivers to return 0 in case of
errors. This fixes strange Exynos DRM initialization failure on boot
(timeout waiting for VSYNC) observed on Trats2 board.

Cc: sta...@vger.kernel.org
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index e5662bdcbbde..e3868956eb88 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -315,14 +315,14 @@ static int vidi_get_modes(struct drm_connector *connector)
 */
if (!ctx->raw_edid) {
DRM_DEV_DEBUG_KMS(ctx->dev, "raw_edid is null.\n");
-   return -EFAULT;
+   return 0;
}
 
edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
if (!edid) {
DRM_DEV_DEBUG_KMS(ctx->dev, "failed to allocate edid\n");
-   return -ENOMEM;
+   return 0;
}
 
drm_connector_update_edid_property(connector, edid);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index c5ba32fca5f3..603d8bb0b03a 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -878,11 +878,11 @@ static int hdmi_get_modes(struct drm_connector *connector)
int ret;
 
if (!hdata->ddc_adpt)
-   return -ENODEV;
+   return 0;
 
edid = drm_get_edid(connector, hdata->ddc_adpt);
if (!edid)
-   return -ENODEV;
+   return 0;
 
hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
-- 
2.34.1

[no subject]

[Marek Szyprowski]

Subject: [PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE

Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH")
disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch.
This innocent change has a significant side-effect on the ARM's
multi_v7_defconfig, because FB_BACKLIGHT symbol is no longer selected,
what in turn leaves BACKLIGHT_CLASS_DEVICE symbol selected only as
a module. The latter disables some backlight related code in the DRM
core, because the DRM core is set to be compiled-in in this defconfig.
This leaves all DRM display panels without integrated backlight control,
even if the needed modules have been properly loaded and probed.

Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
multi_v7_defconfig.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 8f7445729cd0..b2955dcb5a53 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -777,6 +777,7 @@ CONFIG_FB_EFI=y
 CONFIG_FB_WM8505=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SIMPLE=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_BACKLIGHT_AS3711=y
 CONFIG_BACKLIGHT_GPIO=y
-- 
2.34.1

[PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE

[Marek Szyprowski]

Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH")
disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch.
This innocent change has a significant side-effect on the ARM's
multi_v7_defconfig, because FB_BACKLIGHT symbol is no longer selected,
what in turn leaves BACKLIGHT_CLASS_DEVICE symbol selected only as
a module. The latter disables some backlight related code in the DRM
core, because the DRM core is set to be compiled-in in this defconfig.
This leaves all DRM display panels without integrated backlight control,
even if the needed modules have been properly loaded and probed.

Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
multi_v7_defconfig.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 8f7445729cd0..b2955dcb5a53 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -777,6 +777,7 @@ CONFIG_FB_EFI=y
 CONFIG_FB_WM8505=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SIMPLE=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_BACKLIGHT_AS3711=y
 CONFIG_BACKLIGHT_GPIO=y
-- 
2.34.1

Re: [PATCH] drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume

[Marek Szyprowski]

On 20.12.2023 10:53, Fedor Pchelkin wrote:
> Do not forget to call clk_disable_unprepare() on the first element of
> ctx->clocks array.
>
> Found by Linux Verification Center (linuxtesting.org).
>
> Fixes: 8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core API")
> Signed-off-by: Fedor Pchelkin 
Reviewed-by: Marek Szyprowski 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 34cdabc30b4f..5302bebbe38c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1342,7 +1342,7 @@ static int __maybe_unused gsc_runtime_resume(struct 
> device *dev)
>   for (i = 0; i < ctx->num_clocks; i++) {
>   ret = clk_prepare_enable(ctx->clocks[i]);
>   if (ret) {
> - while (--i > 0)
> + while (--i >= 0)
>   clk_disable_unprepare(ctx->clocks[i]);
>   return ret;
>   }

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

Re: [PATCH] drm/rockchip: vop2: Avoid use regmap_reinit_cache at runtime

[Marek Szyprowski]

/0x50
> [8.898660]
> __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [8.898675]drm_fb_helper_set_par+0x30/0x48
> [8.898689]fbcon_init+0x40c/0x498
> [8.898699]visual_init+0xb0/0x108
> [8.898709]do_bind_con_driver+0x1b8/0x38c
> [8.898719]do_take_over_console+0x148/0x1d4
> [8.898730]do_fbcon_takeover+0x6c/0xe0
> [8.898740]fbcon_fb_registered+0x1f8/0x1fc
> [8.898750]register_framebuffer+0x158/0x228
> [8.898763]
> __drm_fb_helper_initial_config_and_unlock+0x304/0x4f8
> [8.898779]drm_fb_helper_initial_config+0x3c/0x48
> [8.898793]drm_fbdev_generic_client_hotplug+0xb8/0xd8
> [8.898806]drm_client_register+0x58/0xa0
> [8.898815]drm_fbdev_generic_setup+0xbc/0x144
> [8.898830]rockchip_drm_bind+0x1ec/0x1f8
> [8.898842]try_to_bring_up_aggregate_device+0x278/0x2d8
> [8.898858]__component_add+0xac/0x198
> [8.898871]component_add+0x10/0x18
> [8.898885]dw_hdmi_rockchip_probe+0x1c/0x24
> [8.898894]platform_probe+0x90/0xd8
> [8.898909]really_probe+0x114/0x3c0
> [8.898921]__driver_probe_device+0x7c/0x17c
> [8.898933]driver_probe_device+0x38/0x11c
> [8.898945]__device_attach_driver+0xb4/0x164
> [8.898958]bus_for_each_drv+0x78/0xdc
> [8.898969]__device_attach+0xfc/0x1ac
> [8.898980]device_initial_probe+0x10/0x18
> [8.898993]bus_probe_device+0xa8/0xac
> [8.899004]deferred_probe_work_func+0x98/0xe8
> [8.899015]process_scheduled_works+0x23c/0x5b8
> [8.899029]worker_thread+0x188/0x374
> [8.899042]kthread+0xe4/0x10c
> [8.899053]ret_from_fork+0x10/0x20
> [8.899064]  }
> [8.899069]  ... key  at: []_key.73979+0x0/0x10
> [8.899086]  ... acquired at:
> [8.899091]__lock_acquire+0x9d8/0x1950
> [8.899104]lock_acquire+0x238/0x354
> [8.899117]_raw_spin_lock_irqsave+0x50/0x6c
> [8.899131]regmap_lock_spinlock+0x14/0x24
> [8.899142]regmap_read+0x38/0x70
> [8.899154]vop2_isr+0x88/0x2ac
> [8.899166]__handle_irq_event_percpu+0xa4/0x2bc
> [8.899178]handle_irq_event_percpu+0x14/0x44
> [8.899188]handle_irq_event+0x44/0x90
> [8.899198]handle_fasteoi_irq+0xf8/0x1d4
> [8.899211]generic_handle_domain_irq+0x28/0x3c
> [8.899221]gic_handle_irq+0xb0/0x130
> [8.899230]call_on_irq_stack+0x24/0x34
> [8.899243]do_interrupt_handler+0xc4/0xdc
> [8.899256]el1_interrupt+0x3c/0x70
> [8.899270]el1h_64_irq_handler+0x14/0x1c
> [8.899285]el1h_64_irq+0x64/0x68
> [8.899293]default_idle_call+0xec/0x118
> [8.899304]do_idle+0x1c8/0x254
> [8.899313]cpu_startup_entry+0x30/0x38
> [8.899321]rest_init+0x13c/0x1cc
> [8.899331]arch_post_acpi_subsys_init+0x0/0x8
> [8.899342]start_kernel+0x7c0/0x968
> [8.899351]__primary_switched+0xb0/0xbc
> [8.899365]
> [8.899368]
> [8.899368] stack backtrace:
> [8.899376] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 6.7.0-rc5-next-20231215 #514
> [8.899386] Hardware name: EmbedFire LubanCat 2 (DT)
> [8.899394] Call trace:
> [8.899399]  dump_backtrace+0xe4/0x124
> [8.899410]  show_stack+0x14/0x1c
> [8.899419]  dump_stack_lvl+0x78/0xd4
> [8.899430]  dump_stack+0x14/0x1c
> [8.899438]  print_irq_inversion_bug+0x28c/0x304
> [8.899453]  mark_lock.part.43+0x2c0/0x448
> [8.899466]  __lock_acquire+0x9d8/0x1950
> [8.899479]  lock_acquire+0x238/0x354
> [8.899492]  _raw_spin_lock_irqsave+0x50/0x6c
> [8.899507]  regmap_lock_spinlock+0x14/0x24
> [8.899517]  regmap_read+0x38/0x70
> [8.899528]  vop2_isr+0x88/0x2ac
> [8.899540]  __handle_irq_event_percpu+0xa4/0x2bc
> [8.899553]  handle_irq_event_percpu+0x14/0x44
> [8.899565]  handle_irq_event+0x44/0x90
> [8.899575]  handle_fasteoi_irq+0xf8/0x1d4
> [8.899589]  generic_handle_domain_irq+0x28/0x3c
> [8.899599]  gic_handle_irq+0xb0/0x130
> [8.899608]  call_on_irq_stack+0x24/0x34
> [8.899619]  do_interrupt_handler+0xc4/0xdc
> [8.899631]  el1_interrupt+0x3c/0x70
> [8

Re: [PATCH] drm/exynos: fix accidental on-stack copy of exynos_drm_plane

[Marek Szyprowski]

On 14.12.2023 13:32, Arnd Bergmann wrote:
> From: Arnd Bergmann 
>
> gcc rightfully complains about excessive stack usage in the 
> fimd_win_set_pixfmt()
> function:
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c: In function 'fimd_win_set_pixfmt':
> drivers/gpu/drm/exynos/exynos_drm_fimd.c:750:1: error: the frame size of 1032 
> bytes is larger than 1024 byte
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 
> 'decon_win_set_pixfmt':
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:1: error: the frame size of 
> 1032 bytes is larger than 1024 bytes
>
> There is really no reason to copy the large exynos_drm_plane
> structure to the stack before using one of its members, so just
> use a pointer instead.
>
> Fixes: 6f8ee5c21722 ("drm/exynos: fimd: Make plane alpha configurable")
> Signed-off-by: Arnd Bergmann 


Reviewed-by: Marek Szyprowski 


> ---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 4 ++--
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 4d986077738b..bce027552474 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -319,9 +319,9 @@ static void decon_win_set_bldmod(struct decon_context 
> *ctx, unsigned int win,
>   static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int 
> win,
>struct drm_framebuffer *fb)
>   {
> - struct exynos_drm_plane plane = ctx->planes[win];
> + struct exynos_drm_plane *plane = >planes[win];
>   struct exynos_drm_plane_state *state =
> - to_exynos_plane_state(plane.base.state);
> + to_exynos_plane_state(plane->base.state);
>   unsigned int alpha = state->base.alpha;
>   unsigned int pixel_alpha;
>   unsigned long val;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8dde7b1e9b35..5bdc246f5fad 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -661,9 +661,9 @@ static void fimd_win_set_bldmod(struct fimd_context *ctx, 
> unsigned int win,
>   static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
>   struct drm_framebuffer *fb, int width)
>   {
> - struct exynos_drm_plane plane = ctx->planes[win];
> + struct exynos_drm_plane *plane = >planes[win];
>   struct exynos_drm_plane_state *state =
> - to_exynos_plane_state(plane.base.state);
> +     to_exynos_plane_state(plane->base.state);
>   uint32_t pixel_format = fb->format->format;
>   unsigned int alpha = state->base.alpha;
>   u32 val = WINCONx_ENWIN;

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

Re: [v5,02/16] Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume"

[Marek Szyprowski]

data->soc_id == 3566)
>   vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
> @@ -913,8 +919,6 @@ static void vop2_disable(struct vop2 *vop2)
>   
>   pm_runtime_put_sync(vop2->dev);
>   
> - regcache_mark_dirty(vop2->map);
> -
>   clk_disable_unprepare(vop2->aclk);
>   clk_disable_unprepare(vop2->hclk);
>   }

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

[PATCH] drm/debugfs: fix potential NULL pointer dereference

[Marek Szyprowski]

encoder->funcs entry might be NULL, so check it first before calling its
methods. This fixes NULL pointer dereference observed on Rasberry Pi
3b/4b boards.

Fixes: caf525ed45b4 ("drm/encoder: register per-encoder debugfs dir")
Signed-off-by: Marek Szyprowski 
---
This fixes the following issue observed on Raspberry Pi 4b:

vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 0010 
when read
[0010] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: sha256_arm raspberrypi_hwmon cfg80211(+) hci_uart btbcm 
bluetooth vc4(+) ecdh_generic ecc libaes snd_soc_hdmi_codec snd_soc_core v3d 
drm_shmem_helper ac97_bus snd_pcm_dmaengine snd_pcm genet(+) gpu_sched 
snd_timer snd bcm2711_thermal soundcore drm_dma_helper
CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 6.7.0-rc4-next-20231205 #14267
Hardware name: BCM2711
PC is at drm_debugfs_encoder_add+0x6c/0x98
LR is at 0x0
...
 drm_debugfs_encoder_add from drm_encoder_register_all+0x20/0x60
 drm_encoder_register_all from drm_modeset_register_all+0x34/0x70
 drm_modeset_register_all from drm_dev_register+0x24c/0x28c
 drm_dev_register from vc4_drm_bind+0x21c/0x2d0 [vc4]
 vc4_drm_bind [vc4] from try_to_bring_up_aggregate_device+0x160/0x1bc
 try_to_bring_up_aggregate_device from component_master_add_with_match+0xc4/0xf8
 component_master_add_with_match from vc4_platform_drm_probe+0xa0/0xc0 [vc4]
 vc4_platform_drm_probe [vc4] from platform_probe+0x5c/0xb8
 platform_probe from really_probe+0xc8/0x2dc
 really_probe from __driver_probe_device+0x88/0x19c
 __driver_probe_device from driver_probe_device+0x30/0x104
 driver_probe_device from __driver_attach+0x90/0x174
 __driver_attach from bus_for_each_dev+0x6c/0xb4
 bus_for_each_dev from bus_add_driver+0xcc/0x1cc
 bus_add_driver from driver_register+0x7c/0x118
 driver_register from vc4_drm_register+0x44/0x1000 [vc4]
 vc4_drm_register [vc4] from do_one_initcall+0x40/0x1e0
 do_one_initcall from do_init_module+0x50/0x1e4
 do_init_module from init_module_from_file+0x90/0xbc
 init_module_from_file from sys_finit_module+0x144/0x258
 sys_finit_module from ret_fast_syscall+0x0/0x54
Exception stack(0xf0cf1fa8 to 0xf0cf1ff0)
...
---[ end trace  ]---

---
 drivers/gpu/drm/drm_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 02e7481758c0..f4715a67e340 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -638,7 +638,7 @@ void drm_debugfs_encoder_add(struct drm_encoder *encoder)
debugfs_create_file("bridges", 0444, root, encoder,
_fops);
 
-   if (encoder->funcs->debugfs_init)
+   if (encoder->funcs && encoder->funcs->debugfs_init)
encoder->funcs->debugfs_init(encoder, root);
 }
 
-- 
2.34.1

Re: [PATCH v4 3/3] drm/panfrost: Synchronize and disable interrupts before powering off

[Marek Szyprowski]

On 04.12.2023 12:42, AngeloGioacchino Del Regno wrote:
> To make sure that we don't unintentionally perform any unclocked and/or
> unpowered R/W operation on GPU registers, before turning off clocks and
> regulators we must make sure that no GPU, JOB or MMU ISR execution is
> pending: doing that requires to add a mechanism to synchronize the
> interrupts on suspend.
>
> Add functions panfrost_{gpu,job,mmu}_suspend_irq() which will perform
> interrupts masking and ISR execution synchronization, and then call
> those in the panfrost_device_runtime_suspend() handler in the exact
> sequence of job (may require mmu!) -> mmu -> gpu.
>
> As a side note, JOB and MMU suspend_irq functions needed some special
> treatment: as their interrupt handlers will unmask interrupts, it was
> necessary to add an `is_suspended` bitmap which is used to address the
> possible corner case of unintentional IRQ unmasking because of ISR
> execution after a call to synchronize_irq().
>
> At resume, clear each is_suspended bit in the reset path of JOB/MMU
> to allow unmasking the interrupts.
>
> Signed-off-by: AngeloGioacchino Del Regno 
> 


Tested-by: Marek Szyprowski 


> ---
>   drivers/gpu/drm/panfrost/panfrost_device.c |  3 +++
>   drivers/gpu/drm/panfrost/panfrost_device.h |  8 +++
>   drivers/gpu/drm/panfrost/panfrost_gpu.c| 18 +--
>   drivers/gpu/drm/panfrost/panfrost_gpu.h|  1 +
>   drivers/gpu/drm/panfrost/panfrost_job.c| 26 ++
>   drivers/gpu/drm/panfrost/panfrost_job.h|  1 +
>   drivers/gpu/drm/panfrost/panfrost_mmu.c| 22 +++---
>   drivers/gpu/drm/panfrost/panfrost_mmu.h|  1 +
>   8 files changed, 71 insertions(+), 9 deletions(-)
>
> ...

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

Re: [PATCH v4 2/3] drm/panfrost: Add gpu_irq, mmu_irq to struct panfrost_device

[Marek Szyprowski]

On 04.12.2023 12:42, AngeloGioacchino Del Regno wrote:
> In preparation for adding a IRQ synchronization mechanism for PM suspend,
> add gpu_irq and mmu_irq variables to struct panfrost_device and change
> functions panfrost_gpu_init() and panfrost_mmu_init() to use those.
>
> Reviewed-by: Boris Brezillon 
> Reviewed-by: Steven Price 
> Signed-off-by: AngeloGioacchino Del Regno 
> 


Tested-by: Marek Szyprowski 


> ---
>   drivers/gpu/drm/panfrost/panfrost_device.h |  2 ++
>   drivers/gpu/drm/panfrost/panfrost_gpu.c| 10 +-
>   drivers/gpu/drm/panfrost/panfrost_mmu.c| 10 +-
>   3 files changed, 12 insertions(+), 10 deletions(-)
>
> ...

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

Re: [PATCH v4 1/3] drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq

[Marek Szyprowski]

On 04.12.2023 12:42, AngeloGioacchino Del Regno wrote:
> Some SoCs may be equipped with a GPU containing two core groups
> and this is exactly the case of Samsung's Exynos 5422 featuring
> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> is partial, as this driver currently supports using only one
> core group and that's reflected on all parts of it, including
> the power on (and power off, previously to this patch) function.
>
> The issue with this is that even though executing the soft reset
> operation should power off all cores unconditionally, on at least
> one platform we're seeing a crash that seems to be happening due
> to an interrupt firing which may be because we are calling power
> transition only on the first core group, leaving the second one
> unchanged, or because ISR execution was pending before entering
> the panfrost_gpu_power_off() function and executed after powering
> off the GPU cores, or all of the above.
>
> Finally, solve this by:
>   - Avoid to enable the power transition interrupt on reset; and
>   - Ignoring the core_mask and ask the GPU to poweroff both core groups
>
> Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in 
> panfrost_gpu_power_off()")
> Reviewed-by: Boris Brezillon 
> Reviewed-by: Steven Price 
> Signed-off-by: AngeloGioacchino Del Regno 
> 


Tested-by: Marek Szyprowski 


> ---
>   drivers/gpu/drm/panfrost/panfrost_gpu.c | 12 ++++
>   1 file changed, 8 insertions(+), 4 deletions(-)
>
> ...

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

Re: [PATCH v2 0/3] drm/panfrost: Fix poweroff and sync IRQs for suspend

[Marek Szyprowski]

On 28.11.2023 13:45, AngeloGioacchino Del Regno wrote:
> This series contains a fast fix for the basic GPU poweroff functionality
> and goes further by implementing interrupt masking and synchronization
> before suspend.
>
> For more information, please look at the conversation at [1], which
> explains the regression seen with the poweroff commit and the initial
> approaches taken to solve that.

Just to let You know, as there is still some discussion about 
beautifying the final code, I've tested this version on my test hardware 
and everything works fine again! Thanks!

Tested-by: Marek Szyprowski 


> Cheers!
>
> [1]: 
> https://lore.kernel.org/all/20231123095320.41433-1-angelogioacchino.delre...@collabora.com/
>
> AngeloGioacchino Del Regno (3):
>drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq
>drm/panfrost: Add gpu_irq, mmu_irq to struct panfrost_device
>drm/panfrost: Synchronize and disable interrupts before powering off
>
>   drivers/gpu/drm/panfrost/panfrost_device.c |  4 +++
>   drivers/gpu/drm/panfrost/panfrost_device.h |  9 +++
>   drivers/gpu/drm/panfrost/panfrost_gpu.c| 29 +++---
>   drivers/gpu/drm/panfrost/panfrost_gpu.h|  1 +
>   drivers/gpu/drm/panfrost/panfrost_job.c| 18 +++---
>   drivers/gpu/drm/panfrost/panfrost_job.h|  1 +
>   drivers/gpu/drm/panfrost/panfrost_mmu.c| 27 ++--
>   drivers/gpu/drm/panfrost/panfrost_mmu.h|  1 +
>   8 files changed, 70 insertions(+), 20 deletions(-)
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Marek Szyprowski]

On 24.11.2023 13:45, Marek Szyprowski wrote:
> On 22.11.2023 10:29, Krzysztof Kozlowski wrote:
>> On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
>>>>>> Hey Krzysztof,
>>>>>>
>>>>>> This is interesting. It might be about the cores that are missing 
>>>>>> from the partial
>>>>>> core_mask raising interrupts, but an external abort on 
>>>>>> non-linefetch is strange to
>>>>>> see here.
>>>>> I've seen such external aborts in the past, and the fault type has
>>>>> often been misleading. It's unlikely to have anything to do with a
>>>> Yeah, often accessing device with power or clocks gated.
>>>>
>>> Except my commit does *not* gate SoC power, nor SoC clocks 
>> It could be that something (like clocks or power supplies) was missing
>> on this board/SoC, which was not critical till your patch came.
>>
>>> What the "Really power off ..." commit does is to ask the GPU to 
>>> internally power
>>> off the shaders, tilers and L2, that's why I say that it is strange 
>>> to see that
>>> kind of abort.
>>>
>>> The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and 
>>> GPU_FAULT_ADDRESS_{HI/LO}
>>> registers should still be accessible even with shaders, tilers and 
>>> cache OFF.
>>>
>>> Anyway, yes, synchronizing IRQs before calling the poweroff sequence 
>>> would also
>>> work, but that'd add up quite a bit of latency on the 
>>> runtime_suspend() call, so
>>> in this case I'd be more for avoiding to execute any register r/w in 
>>> the handler
>>> by either checking if the GPU is supposed to be OFF, or clearing 
>>> interrupts, which
>>> may not work if those are generated after the execution of the 
>>> poweroff function.
>>> Or we could simply disable the irq after power_off, but that'd be 
>>> hacky (as well).
>>>
>>>
>>> Let's see if asking to poweroff *everything* works:
>> Worked.
>
> Yes, I also got into this issue some time ago, but I didn't report it 
> because I also had some power supply related problems on my test farm 
> and everything was a bit unstable. I wasn't 100% sure that the 
> $subject patch is responsible for the observed issues. Now, after 
> fixing power supply, I confirm that the issue was revealed by the 
> $subject patch and above mentioned change fixes the problem. Feel free 
> to add:
>
> Tested-by: Marek Szyprowski 


I must revoke my tested-by tag for the above fix alone. Although it 
fixed the boot issue and system stability issue, it looks that there is 
still something missing and opening the panfrost dri device causes a 
system crash:

root@target:~# ./modetest -C
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...done
root@target:~#

8<--- cut here ---
Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0c6803c
[f0c6803c] *pgd=42d87811, *pte=11800653, *ppte=11800453
Internal error: : 1008 [#1] PREEMPT SMP ARM
Modules linked in: exynos_gsc s5p_mfc s5p_jpeg v4l2_mem2mem 
videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common 
videodev mc s5p_cec
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
6.7.0-rc2-next-20231127-00055-ge14abcb527d6 #7649
Hardware name: Samsung Exynos (Flattened Device Tree)
PC is at panfrost_gpu_irq_handler+0x18/0xfc
LR is at __handle_irq_event_percpu+0xcc/0x31c
...
Process swapper/0 (pid: 0, stack limit = 0x0e2875ff)
Stack: (0xc1301e48 to 0xc1302000)
...
  panfrost_gpu_irq_handler from __handle_irq_event_percpu+0xcc/0x31c
  __handle_irq_event_percpu from handle_irq_event+0x38/0x80
  handle_irq_event from handle_fasteoi_irq+0x9c/0x250
  handle_fasteoi_irq from generic_handle_domain_irq+0x24/0x34
  generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
  generic_handle_arch_irq from __irq_svc+0x8c/0xd0
Exception stack(0xc1301f10 to 0xc1301f58)
...
  __irq_svc from default_idle_call+0x20/0x2c4
  default_idle_call from do_idle+0x244/0x2b4
  do_idle from cpu_startup_entry+0x28/0x2c
  cpu_startup_entry from rest_init+0xec/0x190
  rest_init from arch_post_acpi_subsys_init+0x0/0x8
Code: e591300c e593402c f57ff04f e591300c (e593903c)
---[ end trace  ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU2: stopping


It looks that the panfrost interrupts must be somehow synchronized with 
turning power off, what has been already discussed. Let me know if you 
want me to test any patch.


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

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Marek Szyprowski]

On 22.11.2023 10:29, Krzysztof Kozlowski wrote:
> On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
>>>>> Hey Krzysztof,
>>>>>
>>>>> This is interesting. It might be about the cores that are missing from 
>>>>> the partial
>>>>> core_mask raising interrupts, but an external abort on non-linefetch is 
>>>>> strange to
>>>>> see here.
>>>> I've seen such external aborts in the past, and the fault type has
>>>> often been misleading. It's unlikely to have anything to do with a
>>> Yeah, often accessing device with power or clocks gated.
>>>
>> Except my commit does *not* gate SoC power, nor SoC clocks 
> It could be that something (like clocks or power supplies) was missing
> on this board/SoC, which was not critical till your patch came.
>
>> What the "Really power off ..." commit does is to ask the GPU to internally 
>> power
>> off the shaders, tilers and L2, that's why I say that it is strange to see 
>> that
>> kind of abort.
>>
>> The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and 
>> GPU_FAULT_ADDRESS_{HI/LO}
>> registers should still be accessible even with shaders, tilers and cache OFF.
>>
>> Anyway, yes, synchronizing IRQs before calling the poweroff sequence would 
>> also
>> work, but that'd add up quite a bit of latency on the runtime_suspend() 
>> call, so
>> in this case I'd be more for avoiding to execute any register r/w in the 
>> handler
>> by either checking if the GPU is supposed to be OFF, or clearing interrupts, 
>> which
>> may not work if those are generated after the execution of the poweroff 
>> function.
>> Or we could simply disable the irq after power_off, but that'd be hacky (as 
>> well).
>>
>>
>> Let's see if asking to poweroff *everything* works:
> Worked.

Yes, I also got into this issue some time ago, but I didn't report it 
because I also had some power supply related problems on my test farm 
and everything was a bit unstable. I wasn't 100% sure that the $subject 
patch is responsible for the observed issues. Now, after fixing power 
supply, I confirm that the issue was revealed by the $subject patch and 
above mentioned change fixes the problem. Feel free to add:

Tested-by: Marek Szyprowski 

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

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Marek Szyprowski]

On 22.11.2023 10:29, Krzysztof Kozlowski wrote:
> On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
>>>>> Hey Krzysztof,
>>>>>
>>>>> This is interesting. It might be about the cores that are missing from 
>>>>> the partial
>>>>> core_mask raising interrupts, but an external abort on non-linefetch is 
>>>>> strange to
>>>>> see here.
>>>> I've seen such external aborts in the past, and the fault type has
>>>> often been misleading. It's unlikely to have anything to do with a
>>> Yeah, often accessing device with power or clocks gated.
>>>
>> Except my commit does *not* gate SoC power, nor SoC clocks 
> It could be that something (like clocks or power supplies) was missing
> on this board/SoC, which was not critical till your patch came.
>
>> What the "Really power off ..." commit does is to ask the GPU to internally 
>> power
>> off the shaders, tilers and L2, that's why I say that it is strange to see 
>> that
>> kind of abort.
>>
>> The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and 
>> GPU_FAULT_ADDRESS_{HI/LO}
>> registers should still be accessible even with shaders, tilers and cache OFF.
>>
>> Anyway, yes, synchronizing IRQs before calling the poweroff sequence would 
>> also
>> work, but that'd add up quite a bit of latency on the runtime_suspend() 
>> call, so
>> in this case I'd be more for avoiding to execute any register r/w in the 
>> handler
>> by either checking if the GPU is supposed to be OFF, or clearing interrupts, 
>> which
>> may not work if those are generated after the execution of the poweroff 
>> function.
>> Or we could simply disable the irq after power_off, but that'd be hacky (as 
>> well).
>>
>>
>> Let's see if asking to poweroff *everything* works:
> Worked.

Yes, I also got into this issue some time ago, but I didn't report it 
because I also had some power supply related problems on my test farm 
and everything was a bit unstable. I wasn't 100% sure that the $subject 
patch is responsible for the observed issues. Now, after fixing power 
supply, I confirm that the issue was revealed by the $subject patch and 
above mentioned change fixes the problem. Feel free to add:

Tested-by: Marek Szyprowski 

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

Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU

[Marek Szyprowski]

nd I've googled a little bit and I 
> found this web site : 
> https://lore.kernel.org/linux-arm-kernel/20220208171823.226211-8-krzysztof.kozlow...@canonical.com/
>  
> with your email address and I tried to ask for some help for fixing 
> the bug. Any ideas why booting the same Linux kernel that results in a 
> working X.org display on the bare metal instead as dom0 on Xen would 
> cause the display to remain dark, but most other basic functions would 
> work, such as network, disk, and USB ? thanks.


Thanks for the detailed description! Good to hear that those boards are 
still being used for various projects. I also have Snow Chromebook and 
use it for daily tests of linux-next branch.

Frankly speaking I have no idea what might happen wrong. There have been 
some changes recently in the Exynos IOMMU driver related to 
initialization, maybe your changes related to Xen enabling changed 
somehow the order of device initialization during boot. I assume that 
the device-tree you use for the bare metal run and Xen enabled run 
doesn't differ in the areas describing the hardware blocks.

Please check if cherry-picking the commit 
https://github.com/torvalds/linux/commit/bbc4d205d93f52ee18dfa7858d51489c0506547f
 
to your v6.1.59 based kernel helps anyhow.

If not, then as a temporary workaround please disable 
CONFIG_DRM_EXYNOS_MIXER and CONFIG_DRM_EXYNOS_HDMI in your kernel config 
and check what will happen (You will lose the HDMI output, but maybe 
this won't a big issue).


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

Re: [PATCH v2 0/5] drm/bridge: samsung-dsim: fix various modes with ADV7535 bridge

[Marek Szyprowski]

On 06.10.2023 17:07, Michael Tretter wrote:
> I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter,
> which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few
> modes were working, but in many modes my monitor stayed dark.
>
> This series fixes the Samsung DSIM bridge driver to bring up a few more
> modes:
>
> The driver read the rate of the PLL ref clock only during probe.
> However, if the clock is re-parented to the VIDEO_PLL, changes to the
> pixel clock have an effect on the PLL ref clock. Therefore, the driver
> must read and potentially update the PLL ref clock on every modeset.
>
> I also found that the rounding mode of the porches and active area has
> an effect on the working modes. If the driver rounds up instead of
> rounding down and be calculates them in Hz instead of kHz, more modes
> start to work.
>
> The following table shows the modes that were working in my test without
> this patch set and the modes that are working now:
>
> |Mode | Before | Now |
> | 1920x1080-60.00 | X  | X   |
> | 1920x1080-59.94 || X   |
> | 1920x1080-50.00 || X   |
> | 1920x1080-30.00 || X   |
> | 1920x1080-29.97 || X   |
> | 1920x1080-25.00 || X   |
> | 1920x1080-24.00 || |
> | 1920x1080-23.98 || |
> | 1680x1050-59.88 || X   |
> | 1280x1024-75.03 | X  | X   |
> | 1280x1024-60.02 | X  | X   |
> |  1200x960-59.99 || X   |
> |  1152x864-75.00 | X  | X   |
> |  1280x720-60.00 || |
> |  1280x720-59.94 || |
> |  1280x720-50.00 || X   |
> |  1024x768-75.03 || X   |
> |  1024x768-60.00 || X   |
> |   800x600-75.00 | X  | X   |
> |   800x600-60.32 | X  | X   |
> |   720x576-50.00 | X  | X   |
> |   720x480-60.00 || |
> |   720x480-59.94 | X  | |
> |   640x480-75.00 | X  | X   |
> |   640x480-60.00 || X   |
> |   640x480-59.94 || X   |
> |   720x400-70.08 || |
>
> Interestingly, the 720x480-59.94 mode stopped working. However, I am
> able to bring up the 720x480 modes by manually hacking the active area
> (hsa) to 40 and carefully adjusting the clocks, but something still
> seems to be off.
>
> Unfortunately, a few more modes are still not working at all. The NXP
> downstream kernel has some quirks to handle some of the modes especially
> wrt. to the porches, but I cannot figure out, what the driver should
> actually do in these cases. Maybe there is still an error in the
> calculation of the porches and someone at NXP can chime in.
>
> Michael
>
> Signed-off-by: Michael Tretter 

All my Exynos-based test boards with DSI display panels still work fine 
with this patchset.

Feel free to add:

Tested-by: Marek Szyprowski 


> ---
> Changes in v2:
> - Specify limits for the PLL input clock in samsung_dsim_driver_data
> - Rephrase/clarify commit messages
> - Link to v1: 
> https://lore.kernel.org/r/20230818-samsung-dsim-v1-0-b39716db6...@pengutronix.de
>
> ---
> Marco Felsch (1):
>drm/bridge: samsung-dsim: add more mipi-dsi device debug information
>
> Michael Tretter (4):
>drm/bridge: samsung-dsim: reread ref clock before configuring PLL
>drm/bridge: samsung-dsim: update PLL reference clock
>drm/bridge: samsung-dsim: adjust porches by rounding up
>drm/bridge: samsung-dsim: calculate porches in Hz
>
>   drivers/gpu/drm/bridge/samsung-dsim.c | 54 
> +++
>   include/drm/bridge/samsung-dsim.h |  3 ++
>   2 files changed, 45 insertions(+), 12 deletions(-)
> ---
> base-commit: b78b18fb8ee19f7a05f20c3abc865b3bfe182884
> change-id: 20230818-samsung-dsim-42346444bce5
>
> Best regards,

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

Re: [RFT PATCH v2 09/12] drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time

[Marek Szyprowski]

On 21.09.2023 21:26, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver unbind time. Among other things, this means that if a
> panel is in use that it won't be cleanly powered off at system
> shutdown time.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case
> of OS shutdown/restart and at driver remove (or unbind) time comes
> straight out of the kernel doc "driver instance overview" in
> drm_drv.c.
>
> A few notes about this fix:
> - When adding drm_atomic_helper_shutdown() to the unbind path, I added
>it after drm_kms_helper_poll_fini() since that's when other drivers
>seemed to have it.
> - Technically with a previous patch, ("drm/atomic-helper:
>drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
>actually need to check to see if our "drm" pointer is NULL before
>calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
>though, so that this patch can land without any dependencies. It
>could potentially be removed later.
> - This patch also makes sure to set the drvdata to NULL in the case of
>bind errors to make sure that shutdown can't access freed data.
>
> Suggested-by: Maxime Ripard 
> Reviewed-by: Maxime Ripard 
> Signed-off-by: Douglas Anderson 

Seems to be working fine on all my test Exynos-based boards with display.

Tested-by: Marek Szyprowski 

Reviewed-by: Marek Szyprowski 

> ---
> This commit is only compile-time tested.
>
> (no changes since v1)
>
>   drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++
>   1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 8399256cb5c9..5380fb6c55ae 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -300,6 +300,7 @@ static int exynos_drm_bind(struct device *dev)
>   drm_mode_config_cleanup(drm);
>   exynos_drm_cleanup_dma(drm);
>   kfree(private);
> + dev_set_drvdata(dev, NULL);
>   err_free_drm:
>   drm_dev_put(drm);
>   
> @@ -313,6 +314,7 @@ static void exynos_drm_unbind(struct device *dev)
>   drm_dev_unregister(drm);
>   
>   drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
>   
>   component_unbind_all(drm->dev, drm);
>   drm_mode_config_cleanup(drm);
> @@ -350,9 +352,18 @@ static int exynos_drm_platform_remove(struct 
> platform_device *pdev)
>   return 0;
>   }
>   
> +static void exynos_drm_platform_shutdown(struct platform_device *pdev)
> +{
> + struct drm_device *drm = platform_get_drvdata(pdev);
> +
> + if (drm)
> + drm_atomic_helper_shutdown(drm);
> +}
> +
>   static struct platform_driver exynos_drm_platform_driver = {
>   .probe  = exynos_drm_platform_probe,
>   .remove = exynos_drm_platform_remove,
> + .shutdown = exynos_drm_platform_shutdown,
>   .driver = {
>   .name   = "exynos-drm",
>   .pm = _drm_pm_ops,

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

Re: [PATCH v4] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos

[Marek Szyprowski]

On 11.08.2023 14:59, Robert Foss wrote:
> On Wed, 9 Aug 2023 16:56:41 +0200, Marek Szyprowski wrote:
>> Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
>> doesn't report empty level of packer header FIFO. In case of those SoCs,
>> use the old way of waiting for empty command tranfsfer FIFO, removed
>> recently by commit 14806c641582 ("Drain command transfer FIFO before
>> transfer").
>>
>>
>> [...]
> Fixed formatting warning related to commit message syntax.
>
> Applied, thanks!

Thanks for applying it, but yesterday I've noticed that this patch has 
been dropped from linux-next for some unknown reasons. I also cannot 
find it in today's linux-next (next-20230817):

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/gpu/drm/bridge/samsung-dsim.c?h=next-20230817

Any idea what has happened?


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

[PATCH v4] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos

[Marek Szyprowski]

Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").

Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command transfer FIFO 
before transfer")
Signed-off-by: Marek Szyprowski 
---
v4:
- made has_broken_fifoctrl_emptyhdr a bitfield

v3:
- fixed 'fixes' tag, added reviewed-by

v2:
- added additional delay when workaround is used as suggested by Marek Vasut

v1: 
https://lore.kernel.org/all/20230718131859.3114135-1-m.szyprow...@samsung.com/
---

Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").

Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
 include/drm/bridge/samsung-dsim.h |  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index c49091691ab1..35d29f6cd3e2 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -413,6 +413,7 @@ static const struct samsung_dsim_driver_data 
exynos3_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
@@ -429,6 +430,7 @@ static const struct samsung_dsim_driver_data 
exynos4_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
@@ -1010,8 +1012,20 @@ static int samsung_dsim_wait_for_hdr_fifo(struct 
samsung_dsim *dsi)
do {
u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
 
-   if (reg & DSIM_SFR_HEADER_EMPTY)
-   return 0;
+   if (!dsi->driver_data->has_broken_fifoctrl_emptyhdr) {
+   if (reg & DSIM_SFR_HEADER_EMPTY)
+   return 0;
+   } else {
+   if (!(reg & DSIM_SFR_HEADER_FULL)) {
+   /*
+* Wait a little bit, so the pending data can
+* actually leave the FIFO to avoid overflow.
+*/
+   if (!cond_resched())
+   usleep_range(950, 1050);
+   return 0;
+   }
+   }
 
if (!cond_resched())
usleep_range(950, 1050);
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 05100e91ecb9..6fc9bb2979e4 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 plltmr_reg;
unsigned int has_freqband:1;
unsigned int has_clklane_stop:1;
+   unsigned int has_broken_fifoctrl_emptyhdr:1;
unsigned int num_clks;
unsigned int min_freq;
unsigned int max_freq;
-- 
2.34.1

[PATCH v2] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos

[Marek Szyprowski]

Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").

Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command transfer FIFO 
before transfer")
Signed-off-by: Marek Szyprowski 
Reviewed-by: Marek Vasut 
---
v3:
- fixed 'fixes' tag, added reviewed-by

v2:
- added additional delay when workaround is used as suggested by Marek Vasut

v1: 
https://lore.kernel.org/all/20230718131859.3114135-1-m.szyprow...@samsung.com/
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
 include/drm/bridge/samsung-dsim.h |  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 9b7a00bafeaa..d06401de637c 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -412,6 +412,7 @@ static const struct samsung_dsim_driver_data 
exynos3_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
@@ -428,6 +429,7 @@ static const struct samsung_dsim_driver_data 
exynos4_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
@@ -1009,8 +1011,20 @@ static int samsung_dsim_wait_for_hdr_fifo(struct 
samsung_dsim *dsi)
do {
u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
 
-   if (reg & DSIM_SFR_HEADER_EMPTY)
-   return 0;
+   if (!dsi->driver_data->has_broken_fifoctrl_emptyhdr) {
+   if (reg & DSIM_SFR_HEADER_EMPTY)
+   return 0;
+   } else {
+   if (!(reg & DSIM_SFR_HEADER_FULL)) {
+   /*
+* Wait a little bit, so the pending data can
+* actually leave the FIFO to avoid overflow.
+*/
+   if (!cond_resched())
+   usleep_range(950, 1050);
+   return 0;
+   }
+   }
 
if (!cond_resched())
usleep_range(950, 1050);
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 05100e91ecb9..18017b3e5d9e 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -62,6 +62,7 @@ struct samsung_dsim_driver_data {
const unsigned int *reg_values;
u16 m_min;
u16 m_max;
+   unsigned int has_broken_fifoctrl_emptyhdr;
 };
 
 struct samsung_dsim_host_ops {
-- 
2.34.1

[PATCH v2] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos

[Marek Szyprowski]

Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").

Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Signed-off-by: Marek Szyprowski 
---
v2:
- added additional delay when workaround is used as suggested by Marek Vasut

v1: 
https://lore.kernel.org/all/20230718131859.3114135-1-m.szyprow...@samsung.com/
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
 include/drm/bridge/samsung-dsim.h |  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 9b7a00bafeaa..d06401de637c 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -412,6 +412,7 @@ static const struct samsung_dsim_driver_data 
exynos3_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
@@ -428,6 +429,7 @@ static const struct samsung_dsim_driver_data 
exynos4_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
@@ -1009,8 +1011,20 @@ static int samsung_dsim_wait_for_hdr_fifo(struct 
samsung_dsim *dsi)
do {
u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
 
-   if (reg & DSIM_SFR_HEADER_EMPTY)
-   return 0;
+   if (!dsi->driver_data->has_broken_fifoctrl_emptyhdr) {
+   if (reg & DSIM_SFR_HEADER_EMPTY)
+   return 0;
+   } else {
+   if (!(reg & DSIM_SFR_HEADER_FULL)) {
+   /*
+* Wait a little bit, so the pending data can
+* actually leave the FIFO to avoid overflow.
+*/
+   if (!cond_resched())
+   usleep_range(950, 1050);
+   return 0;
+   }
+   }
 
if (!cond_resched())
usleep_range(950, 1050);
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 05100e91ecb9..18017b3e5d9e 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -62,6 +62,7 @@ struct samsung_dsim_driver_data {
const unsigned int *reg_values;
u16 m_min;
u16 m_max;
+   unsigned int has_broken_fifoctrl_emptyhdr;
 };
 
 struct samsung_dsim_host_ops {
-- 
2.34.1

[PATCH] drm: bridge: samsung-dsim: Fix waiting for empty cmd transfer FIFO on older Exynos

[Marek Szyprowski]

Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").

Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Signed-off-by: Marek Szyprowski 
---
If I remember right, the problem with waiting for the empty command
transfer FIFO was there from the begging of the Exynos DSI driver and
Tomash Figa and Andrzej Hajda used a workaround based on waiting until
the DSIM_SFR_HEADER_FULL bit gets cleared. So far it worked well enough
on the older Exynos SoCs, but indeed there is no point using it on the
properly working hardware, like Exynos 5433 or IMX.

Marek Szyprowski
---
 drivers/gpu/drm/bridge/samsung-dsim.c | 11 +--
 include/drm/bridge/samsung-dsim.h |  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 9b7a00bafeaa..80eb268d5868 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -412,6 +412,7 @@ static const struct samsung_dsim_driver_data 
exynos3_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
@@ -428,6 +429,7 @@ static const struct samsung_dsim_driver_data 
exynos4_dsi_driver_data = {
.m_min = 41,
.m_max = 125,
.min_freq = 500,
+   .has_broken_fifoctrl_emptyhdr = 1,
 };
 
 static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
@@ -1009,8 +1011,13 @@ static int samsung_dsim_wait_for_hdr_fifo(struct 
samsung_dsim *dsi)
do {
u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
 
-   if (reg & DSIM_SFR_HEADER_EMPTY)
-   return 0;
+   if (!dsi->driver_data->has_broken_fifoctrl_emptyhdr) {
+   if (reg & DSIM_SFR_HEADER_EMPTY)
+   return 0;
+   } else {
+   if (!(reg & DSIM_SFR_HEADER_FULL))
+   return 0;
+   }
 
if (!cond_resched())
usleep_range(950, 1050);
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index 05100e91ecb9..18017b3e5d9e 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -62,6 +62,7 @@ struct samsung_dsim_driver_data {
const unsigned int *reg_values;
u16 m_min;
u16 m_max;
+   unsigned int has_broken_fifoctrl_emptyhdr;
 };
 
 struct samsung_dsim_host_ops {
-- 
2.34.1

Re: [PATCH v4 03/68] clk: Move no reparent case into a separate function

[Marek Szyprowski]

On 13.06.2023 13:15, Marek Szyprowski wrote:
> On 05.05.2023 13:25, Maxime Ripard wrote:
>> From: Stephen Boyd 
>>
>> We'll need to turn the code in clk_mux_determine_rate_flags() to deal
>> with CLK_SET_RATE_NO_REPARENT into a helper clock drivers will be able
>> to use if they don't want to allow reparenting.
>>
>> Cc: Abel Vesa 
>> Cc: Alessandro Zummo 
>> Cc: Alexandre Belloni 
>> Cc: Alexandre Torgue 
>> Cc: "Andreas Färber" 
>> Cc: AngeloGioacchino Del Regno 
>> Cc: Baolin Wang 
>> Cc: Charles Keepax 
>> Cc: Chen-Yu Tsai 
>> Cc: Chen-Yu Tsai 
>> Cc: Chunyan Zhang 
>> Cc: Claudiu Beznea 
>> Cc: Daniel Vetter 
>> Cc: David Airlie 
>> Cc: David Lechner 
>> Cc: Dinh Nguyen 
>> Cc: Fabio Estevam 
>> Cc: Geert Uytterhoeven 
>> Cc: Jaroslav Kysela 
>> Cc: Jernej Skrabec 
>> Cc: Jonathan Hunter 
>> Cc: Kishon Vijay Abraham I 
>> Cc: Liam Girdwood 
>> Cc: Linus Walleij 
>> Cc: Luca Ceresoli 
>> Cc: Manivannan Sadhasivam 
>> Cc: Mark Brown 
>> Cc: Markus Schneider-Pargmann 
>> Cc: Max Filippov 
>> Cc: Maxime Coquelin 
>> Cc: Mikko Perttunen 
>> Cc: Miles Chen 
>> Cc: Nicolas Ferre 
>> Cc: Orson Zhai 
>> Cc: Paul Cercueil 
>> Cc: Peng Fan 
>> Cc: Peter De Schrijver 
>> Cc: Prashant Gaikwad 
>> Cc: Richard Fitzgerald 
>> Cc: Samuel Holland 
>> Cc: Sascha Hauer 
>> Cc: Sekhar Nori 
>> Cc: Shawn Guo 
>> Cc: Takashi Iwai 
>> Cc: Thierry Reding 
>> Cc: Ulf Hansson 
>> Cc: Vinod Koul 
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: linux-acti...@lists.infradead.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-m...@vger.kernel.org
>> Cc: linux-...@lists.infradead.org
>> Cc: linux-renesas-...@vger.kernel.org
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-st...@st-md-mailman.stormreply.com
>> Cc: linux-su...@lists.linux.dev
>> Cc: linux-te...@vger.kernel.org
>> Cc: NXP Linux Team 
>> Cc: patc...@opensource.cirrus.com
>> Cc: Pengutronix Kernel Team 
>> Signed-off-by: Stephen Boyd 
>> Signed-off-by: Maxime Ripard 
>> ---
>
> This patch landed in today's linux-next as commit 1b4e99fda73f ("clk: 
> Move no reparent case into a separate function"). Unfortunately it 
> causes serious regression of some of my test boards. Namely Exynos3250 
> based boards are so slow after it, that my test scripts fail with a 
> timeout waiting for them to finish booting. I will try to debug this 
> later in the evening to check what has happened that some clocks got 
> very low rate.
>
I just got a few spare minutes, so I decided to take a look into this 
issue. The following change fixed my problem:

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ffc9f03840b7..7ac9f7a8cb84 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -629,6 +629,7 @@ clk_core_determine_rate_no_reparent(struct clk_hw *hw,
     best = clk_core_get_rate_nolock(core);
     }

+   req->best_parent_rate = best;
     req->rate = best;

     return 0;

best_parent_rate is still being used somewhere in the code and needs to 
be updated regardless of the CLK_SET_RATE_NO_REPARENT flag.

 > ...

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

Re: [PATCH v4 03/68] clk: Move no reparent case into a separate function

[Marek Szyprowski]

On 05.05.2023 13:25, Maxime Ripard wrote:
> From: Stephen Boyd 
>
> We'll need to turn the code in clk_mux_determine_rate_flags() to deal
> with CLK_SET_RATE_NO_REPARENT into a helper clock drivers will be able
> to use if they don't want to allow reparenting.
>
> Cc: Abel Vesa 
> Cc: Alessandro Zummo 
> Cc: Alexandre Belloni 
> Cc: Alexandre Torgue 
> Cc: "Andreas Färber" 
> Cc: AngeloGioacchino Del Regno 
> Cc: Baolin Wang 
> Cc: Charles Keepax 
> Cc: Chen-Yu Tsai 
> Cc: Chen-Yu Tsai 
> Cc: Chunyan Zhang 
> Cc: Claudiu Beznea 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: David Lechner 
> Cc: Dinh Nguyen 
> Cc: Fabio Estevam 
> Cc: Geert Uytterhoeven 
> Cc: Jaroslav Kysela 
> Cc: Jernej Skrabec 
> Cc: Jonathan Hunter 
> Cc: Kishon Vijay Abraham I 
> Cc: Liam Girdwood 
> Cc: Linus Walleij 
> Cc: Luca Ceresoli 
> Cc: Manivannan Sadhasivam 
> Cc: Mark Brown 
> Cc: Markus Schneider-Pargmann 
> Cc: Max Filippov 
> Cc: Maxime Coquelin 
> Cc: Mikko Perttunen 
> Cc: Miles Chen 
> Cc: Nicolas Ferre 
> Cc: Orson Zhai 
> Cc: Paul Cercueil 
> Cc: Peng Fan 
> Cc: Peter De Schrijver 
> Cc: Prashant Gaikwad 
> Cc: Richard Fitzgerald 
> Cc: Samuel Holland 
> Cc: Sascha Hauer 
> Cc: Sekhar Nori 
> Cc: Shawn Guo 
> Cc: Takashi Iwai 
> Cc: Thierry Reding 
> Cc: Ulf Hansson 
> Cc: Vinod Koul 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-acti...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-m...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-su...@lists.linux.dev
> Cc: linux-te...@vger.kernel.org
> Cc: NXP Linux Team 
> Cc: patc...@opensource.cirrus.com
> Cc: Pengutronix Kernel Team 
> Signed-off-by: Stephen Boyd 
> Signed-off-by: Maxime Ripard 
> ---

This patch landed in today's linux-next as commit 1b4e99fda73f ("clk: 
Move no reparent case into a separate function"). Unfortunately it 
causes serious regression of some of my test boards. Namely Exynos3250 
based boards are so slow after it, that my test scripts fail with a 
timeout waiting for them to finish booting. I will try to debug this 
later in the evening to check what has happened that some clocks got 
very low rate.


> drivers/clk/clk.c | 75 
> +++
> 1 file changed, 43 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index e495dd7a1eae..f57f821a5e5a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -594,6 +594,46 @@ clk_core_forward_rate_req(struct clk_core *core,
> req->max_rate = old_req->max_rate;
> }
> +static int
> +clk_core_determine_rate_no_reparent(struct clk_hw *hw,
> + struct clk_rate_request *req)
> +{
> + struct clk_core *core = hw->core;
> + struct clk_core *parent = core->parent;
> + unsigned long best;
> + int ret;
> +
> + if (core->flags & CLK_SET_RATE_PARENT) {
> + struct clk_rate_request parent_req;
> +
> + if (!parent) {
> + req->rate = 0;
> + return 0;
> + }
> +
> + clk_core_forward_rate_req(core, req, parent, _req,
> + req->rate);
> +
> + trace_clk_rate_request_start(_req);
> +
> + ret = clk_core_round_rate_nolock(parent, _req);
> + if (ret)
> + return ret;
> +
> + trace_clk_rate_request_done(_req);
> +
> + best = parent_req.rate;
> + } else if (parent) {
> + best = clk_core_get_rate_nolock(parent);
> + } else {
> + best = clk_core_get_rate_nolock(core);
> + }
> +
> + req->rate = best;
> +
> + return 0;
> +}
> +
> int clk_mux_determine_rate_flags(struct clk_hw *hw,
> struct clk_rate_request *req,
> unsigned long flags)
> @@ -603,35 +643,8 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
> unsigned long best = 0;
> /* if NO_REPARENT flag set, pass through to current parent */
> - if (core->flags & CLK_SET_RATE_NO_REPARENT) {
> - parent = core->parent;
> - if (core->flags & CLK_SET_RATE_PARENT) {
> - struct clk_rate_request parent_req;
> -
> - if (!parent) {
> - req->rate = 0;
> - return 0;
> - }
> -
> - clk_core_forward_rate_req(core, req, parent, _req, req->rate);
> -
> - trace_clk_rate_request_start(_req);
> -
> - ret = clk_core_round_rate_nolock(parent, _req);
> - if (ret)
> - return ret;
> -
> - trace_clk_rate_request_done(_req);
> -
> - best = parent_req.rate;
> - } else if (parent) {
> - best = clk_core_get_rate_nolock(parent);
> - } else {
> - best = clk_core_get_rate_nolock(core);
> - }
> -
> - goto out;
> - }
> + if (core->flags & CLK_SET_RATE_NO_REPARENT)
> + return clk_core_determine_rate_no_reparent(hw, req);
> /* find the parent that can provide the fastest rate <= rate */
> num_parents = core->num_parents;
> @@ -670,9 +683,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
> if (!best_parent)
> return -EINVAL;
> -out:
> - if (best_parent)
> - req->best_parent_hw = best_parent->hw;
> + req->best_parent_hw = best_parent->hw;
> req->best_parent_rate = best;
> req->rate = best;
>
Best regards

-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH V6 5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing

[Marek Szyprowski]

Hi Adam,

On 17.05.2023 04:55, Adam Ford wrote:
> On Mon, May 15, 2023 at 6:57 PM Adam Ford  wrote:
>> The DPHY timings are currently hard coded. Since the input
>> clock can be variable, the phy timings need to be variable
>> too.  To facilitate this, we need to cache the hs_clock
>> based on what is generated from the PLL.
>>
>> The phy_mipi_dphy_get_default_config_for_hsclk function
>> configures the DPHY timings in pico-seconds, and a small macro
>> converts those timings into clock cycles based on the hs_clk.
>>
>> Signed-off-by: Adam Ford 
>> Signed-off-by: Lucas Stach 
>> Tested-by: Chen-Yu Tsai 
>> Tested-by: Frieder Schrempf 
>> Reviewed-by: Frieder Schrempf 
>> Tested-by: Michael Walle 
>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 57 +++
>>   include/drm/bridge/samsung-dsim.h |  1 +
>>   2 files changed, 51 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 08266303c261..3944b7cfbbdf 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -218,6 +218,8 @@
>>
>>   #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
>>
>> +#define PS_TO_CYCLE(ps, hz) DIV64_U64_ROUND_CLOSEST(((ps) * (hz)), 
>> 1ULL)
>> +
>>   static const char *const clk_names[5] = {
>>  "bus_clk",
>>  "sclk_mipi",
>> @@ -651,6 +653,8 @@ static unsigned long samsung_dsim_set_pll(struct 
>> samsung_dsim *dsi,
>>  reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
>>  } while ((reg & DSIM_PLL_STABLE) == 0);
>>
>> +   dsi->hs_clock = fout;
>> +
>>  return fout;
>>   }
>>
>> @@ -698,13 +702,46 @@ 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;
>> +   struct phy_configure_opts_mipi_dphy cfg;
>> +   int clk_prepare, lpx, clk_zero, clk_post, clk_trail;
>> +   int hs_exit, hs_prepare, hs_zero, hs_trail;
>> +   unsigned long long byte_clock = dsi->hs_clock / 8;
>>
>>  if (driver_data->has_freqband)
>>  return;
>>
>> +   phy_mipi_dphy_get_default_config_for_hsclk(dsi->hs_clock,
>> +  dsi->lanes, );
>> +
>> +   /*
>> +* TODO:
>> +* The tech reference manual for i.MX8M Mini/Nano/Plus
>> +* doesn't state what the definition of the PHYTIMING
>> +* bits are beyond their address and bit position.
>> +* After reviewing NXP's downstream code, it appears
>> +    * that the various PHYTIMING registers take the number
>> +* of cycles and use various dividers on them.  This
>> +* calculation does not result in an exact match to the
>> +* downstream code, but it is very close, and it appears
>> +* to sync at a variety of resolutions. If someone
>> +* can get a more accurate mathematical equation needed
>> +* for these registers, this should be updated.
>> +*/
> Marek Szyprowski -
>
> I was curious to know if you have any opinion on this TODO note and/or
> if you have any stuff you can share about how the values of the
> following variables are configured?
>> +
>> +   lpx = PS_TO_CYCLE(cfg.lpx, byte_clock);
>> +   hs_exit = PS_TO_CYCLE(cfg.hs_exit, byte_clock);
>> +   clk_prepare = PS_TO_CYCLE(cfg.clk_prepare, byte_clock);
>> +   clk_zero = PS_TO_CYCLE(cfg.clk_zero, byte_clock);
>> +   clk_post = PS_TO_CYCLE(cfg.clk_post, byte_clock);
>> +   clk_trail = PS_TO_CYCLE(cfg.clk_trail, byte_clock);
>> +   hs_prepare = PS_TO_CYCLE(cfg.hs_prepare, byte_clock);
>> +   hs_zero = PS_TO_CYCLE(cfg.hs_zero, byte_clock);
>> +   hs_trail = PS_TO_CYCLE(cfg.hs_trail, byte_clock);
>> +
> These 'work' but they don't exactly match the NXP reference code, but
> they're not significantly different.  The NXP reference manual doesn't
> describe how these registers are set, they only publish the register
> and bits used.  Since you work for Samsung, I was hoping you might
> have inside information to know if this is a reasonable approach.

Unfortunately I won't be able to provide any info on that. You may check 
the reference Samsung code for various Exynos based products, but I 
suspect it will be similar to what was already in the Exynos DSI driver.

 > ...

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

Re: [PATCH V6 0/6] drm: bridge: samsung-dsim: Support variable clocking

[Marek Szyprowski]

On 16.05.2023 01:57, Adam Ford wrote:
> This series fixes the blanking pack size and the PMS calculation.  It then
> adds support to allows the DSIM to dynamically DPHY clocks, and support
> non-burst mode while allowing the removal of the hard-coded clock values
> for the PLL for imx8m mini/nano/plus, and it allows the removal of the
> burst-clock device tree entry when burst-mode isn't supported by connected
> devices like an HDMI brige.  In that event, the HS clock is set to the
> value requested by the bridge chip.
>
> This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should
> work on i.MX8M Mini as well. Marek Szyprowski has tested it on various
> Exynos boards.
>
> Adam Ford (5):
>drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
>drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
>drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY
>drm: bridge: samsung-dsim: Dynamically configure DPHY timing
>drm: bridge: samsung-dsim: Support non-burst mode
>
> Lucas Stach (1):
>drm: bridge: samsung-dsim: fix blanking packet size calculation
>
>   drivers/gpu/drm/bridge/Kconfig|   1 +
>   drivers/gpu/drm/bridge/samsung-dsim.c | 143 +-
>   include/drm/bridge/samsung-dsim.h |   4 +
>   3 files changed, 125 insertions(+), 23 deletions(-)

Feel free to add to all patches:

Tested-by: Marek Szyprowski 


> V6:  Squash-in an additional error fix from Lucas Stach regarding the
>   DPHY calcuations.  Remove the dynamic_dphy variable and let
>   everyone use the new calculations.  Move the hs_clock caching
>   from patch 6 to patch 5 to go along with the DPHY calcuations
>   since they are now based on the recorded hs_clock rate.
>   
> V5:  Update error message to dev_info and change them to indicate
>   what is happening without sounding like an error when optional
>   device tree entries are missing.
>
> V4:  Undo some accidental whitespace changes, rename PS_TO_CYCLE
>   variables to ps and hz from PS and MHz. Remove if check
>   before the samsung_dsim_set_phy_ctrl call since it's
>   unnecessary.
>   Added additional tested-by and reviewed-by comments.
>   Squash patches 6 and 7 together since the supporting
>   non-burst (patch 6) mode doesn't really work until
>   patch 7 was applied.
>
> V3:  When checking if the bust-clock is present, only check for it
>   in the device tree, and don't check the presence of the
>   MIPI_DSI_MODE_VIDEO_BURST flag as it breaks an existing Exynos
>   board.
>
>   Add a new patch to the series to select GENERIC_PHY_MIPI_DPHY in
>   Kconfig otherwise the build breaks on the 32-bit Exynos.
>
>   Change vco_min variable name to min_freq
>
>   Added tested-by from Chen-Yu Tsai
>
> V2:  Instead of using my packet blanking calculation, this integrates
>   on from Lucas Stach which gets modified later in the series to
>   cache the value of the HS-clock instead of having to do the
>   calucations again.
>
>   Instead of completely eliminating the PLL clock frequency from
>   the device tree, this makes it optional to avoid breaking some
>   Samsung devices.  When the samsung,pll-clock-frequency is not
>   found, it reads the value of the clock named "sclk_mipi"
>   This also maintains backwards compatibility with older device
>   trees.
>
>   This also changes the DPHY calcuation from a Look-up table,
>   a reverse engineered algorithm which uses
>   phy_mipi_dphy_get_default_config to determine the standard
>   nominal values and calculates the cycles necessary to update
>   the DPHY timings accordingly.
>   

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

Re: [PATCH V5 5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing

[Marek Szyprowski]

On 13.05.2023 06:25, Adam Ford wrote:
> On Fri, May 12, 2023 at 4:02 PM Marek Szyprowski
>  wrote:
>> On 12.05.2023 22:00, Adam Ford wrote:
>>> On Fri, May 12, 2023 at 2:37 PM Lucas Stach  wrote:
>>>> Am Samstag, dem 06.05.2023 um 14:24 -0500 schrieb Adam Ford:
>>>>> The DPHY timings are currently hard coded. Since the input
>>>>> clock can be variable, the phy timings need to be variable
>>>>> too.  Add an additional variable to the driver data to enable
>>>>> this feature to prevent breaking boards that don't support it.
>>>>>
>>>>> The phy_mipi_dphy_get_default_config function configures the
>>>>> DPHY timings in pico-seconds, and a small macro converts those
>>>>> timings into clock cycles based on the pixel clock rate.
>>>>>
>>>> This week I finally had some time to take a deeper look at this series
>>>> and test it on some of my systems.
>>> Thanks for testing this!
>>>> This patch causes issues when the burst clock rate is fixed by
>>>> supplying the DT entry. Instead of describing the issue below, I'm
>>>> attaching the patch that makes things work on my system.
>>> Oops, sorry about that.
>>>
>>>> I would appreciate if you could test this one on your side. Feel free
>>>> to squash it into yours if you find it working properly.
>>> I reviewed your patch, and it looks like it makes a lot of sense.
>>> If it works, I'll squash them together and add your name to the sign-off.
> That worked really well, I'll add it to my WIP directory since Marek S
> said he'd test the other proposal of dropping the dynamic phy flag and
> corresponding check in favor of pushing everyone to the same code.
>
>>>> Also I would almost bet that dynamic_dphy is working on the Exynos
>>>> boards with that fix added. So if anyone with access to those boards
>>>> would like to give it a shot, we may be able to get rid of the
>>>> hardcoded PHY parameters altogether, which would be a nice cleanup.
>>> I wondered the same thing, but I didn't want to create more work for
>>> Marek S and since there was so much churn getting the original driver
>>> ported, I thought it would be the safest thing to try to give the
>>> imx8m m/n/p the features without breaking the Exynos.
>>>
>>> Marek S - Do you want me to post this file without the extra checks to
>>> see if it still works with Exynos?
>> Feel free to send me patches to test or just point to your
>> work-in-progress git repo.
> Thanks for testing this, Marek S.  My work-in-progress branch is:
>
> https://protect2.fireeye.com/v1/url?k=2eeb1ed9-4e098384-2eea9596-000babd9f1ba-9ad5c339e5ea6e4d=1=652be603-d622-4d0e-95d3-639656ab1af1=https%3A%2F%2Fgithub.com%2Faford173%2Flinux%2Ftree%2Fdsim-updates-wip
>
> Depending on what you find will determine how I modify the next
> revision of the code I push, so I very much appreciate your feedback.
> Hopefully the suggestion from Lucas will work for your applications
> and we can reduce some of the code complexity.

The above mentioned 'dsim-updates-wip' branch works fine on all my 
Exynos based boards.


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

Re: [PATCH V5 5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing

[Marek Szyprowski]

On 12.05.2023 22:00, Adam Ford wrote:
> On Fri, May 12, 2023 at 2:37 PM Lucas Stach  wrote:
>> Am Samstag, dem 06.05.2023 um 14:24 -0500 schrieb Adam Ford:
>>> The DPHY timings are currently hard coded. Since the input
>>> clock can be variable, the phy timings need to be variable
>>> too.  Add an additional variable to the driver data to enable
>>> this feature to prevent breaking boards that don't support it.
>>>
>>> The phy_mipi_dphy_get_default_config function configures the
>>> DPHY timings in pico-seconds, and a small macro converts those
>>> timings into clock cycles based on the pixel clock rate.
>>>
>> This week I finally had some time to take a deeper look at this series
>> and test it on some of my systems.
> Thanks for testing this!
>> This patch causes issues when the burst clock rate is fixed by
>> supplying the DT entry. Instead of describing the issue below, I'm
>> attaching the patch that makes things work on my system.
> Oops, sorry about that.
>
>> I would appreciate if you could test this one on your side. Feel free
>> to squash it into yours if you find it working properly.
> I reviewed your patch, and it looks like it makes a lot of sense.
> If it works, I'll squash them together and add your name to the sign-off.
>
>> Also I would almost bet that dynamic_dphy is working on the Exynos
>> boards with that fix added. So if anyone with access to those boards
>> would like to give it a shot, we may be able to get rid of the
>> hardcoded PHY parameters altogether, which would be a nice cleanup.
> I wondered the same thing, but I didn't want to create more work for
> Marek S and since there was so much churn getting the original driver
> ported, I thought it would be the safest thing to try to give the
> imx8m m/n/p the features without breaking the Exynos.
>
> Marek S - Do you want me to post this file without the extra checks to
> see if it still works with Exynos?

Feel free to send me patches to test or just point to your 
work-in-progress git repo.


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

Re: [PATCH V3 0/7] drm: bridge: samsung-dsim: Support variable clocking

[Marek Szyprowski]

On 02.05.2023 03:07, Adam Ford wrote:
> This series fixes the blanking pack size and the PMS calculation.  It then
> adds support to allows the DSIM to dynamically DPHY clocks, and support
> non-burst mode while allowing the removal of the hard-coded clock values
> for the PLL for imx8m mini/nano/plus, and it allows the removal of the
> burst-clock device tree entry when burst-mode isn't supported by connected
> devices like an HDMI brige.  In that event, the HS clock is set to the value
> requested by the bridge chip.
>
> This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should work
> on i.MX8M Mini as well.
>
> Adam Ford (6):
>drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
>drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
>drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY
>drm: bridge: samsung-dsim: Dynamically configure DPHY timing
>drm: bridge: samsung-dsim: Support non-burst mode
>drm: bridge: samsung-dsim: Let blanking calcuation work in non-burst
>  mode
>
> Lucas Stach (1):
>drm: bridge: samsung-dsim: fix blanking packet size calculation
>
>   drivers/gpu/drm/bridge/Kconfig|   1 +
>   drivers/gpu/drm/bridge/samsung-dsim.c | 150 ++
>   include/drm/bridge/samsung-dsim.h |   5 +
>   3 files changed, 136 insertions(+), 20 deletions(-)

Works fine (= doesn't break) on Exynos.

Tested-by: Marek Szyprowski 


>
> ---
> V3:  When checking if the bust-clock is present, only check for it
>   in the device tree, and don't check the presence of the
>   MIPI_DSI_MODE_VIDEO_BURST flag as it breaks an existing Exynos
>   board.
>   
>   Add a new patch to the series to select GENERIC_PHY_MIPI_DPHY in
>   Kconfig otherwise the build breaks on the 32-bit Exynos.
>   
>   Change vco_min variable name to min_freq
>
>   Added tested-by from Chen-Yu Tsai
>
> V2:  Instead of using my packet blanking calculation, this integrates
>   on from Lucas Stach which gets modified later in the series to
>   cache the value of the HS-clock instead of having to do the
>   calucations again.
>
>   Instead of completely eliminating the PLL clock frequency from
>   the device tree, this makes it optional to avoid breaking some
>   Samsung devices.  When the samsung,pll-clock-frequency is not
>   found, it reads the value of the clock named "sclk_mipi"
>   This also maintains backwords compatibility with older device
>   trees.
>
>   This also changes the DPHY calcuation from a Look-up table,
>   a reverse engineered algorithm which uses
>   phy_mipi_dphy_get_default_config to determine the standard
>   nominal values and calculates the cycles necessary to update
>   the DPHY timings accordingly.
>   

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

Re: [PATCH V2 5/6] drm: bridge: samsung-dsim: Support non-burst mode

[Marek Szyprowski]

On 28.04.2023 15:35, Adam Ford wrote:
> On Fri, Apr 28, 2023 at 7:31 AM Marek Szyprowski
>  wrote:
>> On 24.04.2023 12:00, Adam Ford wrote:
>>> On Mon, Apr 24, 2023 at 3:25 AM Marek Szyprowski
>>>  wrote:
>>>> On 23.04.2023 14:12, Adam Ford wrote:
>>>>> The high-speed clock is hard-coded to the burst-clock
>>>>> frequency specified in the device tree.  However, when
>>>>> using devices like certain bridge chips without burst mode
>>>>> and varying resolutions and refresh rates, it may be
>>>>> necessary to set the high-speed clock dynamically based
>>>>> on the desired pixel clock for the connected device.
>>>>>
>>>>> This also removes the need to set a clock speed from
>>>>> the device tree for non-burst mode operation, since the
>>>>> pixel clock rate is the rate requested from the attached
>>>>> device like an HDMI bridge chip.  This should have no
>>>>> impact for people using burst-mode and setting the burst
>>>>> clock rate is still required for those users.
>>>>>
>>>>> Signed-off-by: Adam Ford 
>>>> This one breaks Exynos-5433 based TM2e board with a DSI panel.
>>> Marek S,
>>>
>>> Thank you for testing!  I knoiw there are several of us who appreciate
>>> your testing this since it's hard to know if something broke without
>>> hardware.  Is there any way you can tell me if the flag is set to
>>> enable MIPI_DSI_MODE_VIDEO_BURST?
>> TM2e board uses the DSI panel operated in command mode and handled by
>> panel-samsung-s6e3ha2.c driver. The MIPI_DSI_MODE_VIDEO_BURST flag is
>> not set by the driver. However, the MIPI_DSI_CLOCK_NON_CONTINUOUS flags
>> is set there. I really have no idea if setting VIDEO_BURST would make
>> sense together with CLOCK_NON_CONTINUOUS or not. Maybe the driver lacks
>> setting it?
>>
>>
>>> I was trying to be diligent about not breaking your boards, but
>>> without your boards, it's difficult.  The theory was that if
>>> MIPI_DSI_MODE_VIDEO_BURST is set and there is a burst clock set in the
>>> device tree, it would use the burst clock.
>>>
>>> As a fall-back I could just simply check for the presence of the
>>> burst_clock_rate instead of both MIPI_DSI_MODE_VIDEO_BURST and
>>> burst_clock_rate.
>> Maybe you should extend your check also for the
>> MIPI_DSI_CLOCK_NON_CONTINUOUS flag? Does it make sense?
> Looking at some of the devices that might attach in the future, It
> appears that ti-sn65dsi86.c sets this flag.  It's a display port
> bridge, so I would expect it to need a variable clock rate similar to
> how the HDMI bridge that I need works.  I am concerned that I make the
> burst clock dependent on MIPI_DSI_CLOCK_NON_CONTINUOUS, it might break
> the Display Port bridge.
>
> I think it's better to just check if the samsung,burst-clock-frequency
> is present in the device tree and use it when present.  If it's not
> present, then fall back to the pixel clock of the connected device.

Right, this sounds rational.

> I looked at a bunch of Exynos parts, and it looks like they all use
> the samsung,burst-clock-frequency device tree setting.  Is that true,
> or did I miss one?

That true. All Exynos based boards with DSI panels use constant DSI 
burst frequency defined in the device tree.


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

Re: [PATCH V2 5/6] drm: bridge: samsung-dsim: Support non-burst mode

[Marek Szyprowski]

On 24.04.2023 12:00, Adam Ford wrote:
> On Mon, Apr 24, 2023 at 3:25 AM Marek Szyprowski
>  wrote:
>> On 23.04.2023 14:12, Adam Ford wrote:
>>> The high-speed clock is hard-coded to the burst-clock
>>> frequency specified in the device tree.  However, when
>>> using devices like certain bridge chips without burst mode
>>> and varying resolutions and refresh rates, it may be
>>> necessary to set the high-speed clock dynamically based
>>> on the desired pixel clock for the connected device.
>>>
>>> This also removes the need to set a clock speed from
>>> the device tree for non-burst mode operation, since the
>>> pixel clock rate is the rate requested from the attached
>>> device like an HDMI bridge chip.  This should have no
>>> impact for people using burst-mode and setting the burst
>>> clock rate is still required for those users.
>>>
>>> Signed-off-by: Adam Ford 
>> This one breaks Exynos-5433 based TM2e board with a DSI panel.
> Marek S,
>
> Thank you for testing!  I knoiw there are several of us who appreciate
> your testing this since it's hard to know if something broke without
> hardware.  Is there any way you can tell me if the flag is set to
> enable MIPI_DSI_MODE_VIDEO_BURST?

TM2e board uses the DSI panel operated in command mode and handled by 
panel-samsung-s6e3ha2.c driver. The MIPI_DSI_MODE_VIDEO_BURST flag is 
not set by the driver. However, the MIPI_DSI_CLOCK_NON_CONTINUOUS flags 
is set there. I really have no idea if setting VIDEO_BURST would make 
sense together with CLOCK_NON_CONTINUOUS or not. Maybe the driver lacks 
setting it?


> I was trying to be diligent about not breaking your boards, but
> without your boards, it's difficult.  The theory was that if
> MIPI_DSI_MODE_VIDEO_BURST is set and there is a burst clock set in the
> device tree, it would use the burst clock.
>
> As a fall-back I could just simply check for the presence of the
> burst_clock_rate instead of both MIPI_DSI_MODE_VIDEO_BURST and
> burst_clock_rate.

Maybe you should extend your check also for the 
MIPI_DSI_CLOCK_NON_CONTINUOUS flag? Does it make sense?

 > ...

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

Re: [PATCH V2 4/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing

[Marek Szyprowski]

On 24.04.2023 11:44, Chen-Yu Tsai wrote:
> On Mon, Apr 24, 2023 at 5:31 PM Adam Ford  wrote:
>> On Mon, Apr 24, 2023 at 1:12 AM Chen-Yu Tsai  wrote:
>>> On Sun, Apr 23, 2023 at 8:13 PM Adam Ford  wrote:
>>>> The DPHY timings are currently hard coded. Since the input
>>>> clock can be variable, the phy timings need to be variable
>>>> too.  Add an additional variable to the driver data to enable
>>>> this feature to prevent breaking boards that don't support it.
>>>>
>>>> The phy_mipi_dphy_get_default_config function configures the
>>>> DPHY timings in pico-seconds, and a small macro converts those
>>>> timings into clock cycles based on the pixel clock rate.
>>>>
>>>> Signed-off-by: Adam Ford 
>>>> ---
>>>>   drivers/gpu/drm/bridge/samsung-dsim.c | 79 +++
>>>>   include/drm/bridge/samsung-dsim.h |  1 +
>>>>   2 files changed, 70 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> index 5b6e7825b92f..f165483d5044 100644
>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>> @@ -18,9 +18,7 @@
>>>>   #include 
>>>>   #include 
>>>>   #include 
>>>> -
>>>>   #include 
>>>> -
>>>>   #include 
>>>>   #include 
>>>>   #include 
>>>> @@ -218,6 +216,8 @@
>>>>
>>>>   #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
>>>>
>>>> +#define PS_TO_CYCLE(PS, MHz) DIV64_U64_ROUND_CLOSEST(((PS) * (MHz)), 
>>>> 1ULL)
>>>> +
>>>>   static const char *const clk_names[5] = {
>>>>  "bus_clk",
>>>>  "sclk_mipi",
>>>> @@ -487,6 +487,7 @@ static const struct samsung_dsim_driver_data 
>>>> imx8mm_dsi_driver_data = {
>>>>  .m_min = 64,
>>>>  .m_max = 1023,
>>>>  .vco_min = 1050,
>>>> +   .dynamic_dphy = 1,
>>>>   };
>>>>
>>>>   static const struct samsung_dsim_driver_data *
>>>> @@ -698,13 +699,50 @@ 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;
>>>> +   struct drm_display_mode *m = >mode;
>>>> +   int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>>>> +   struct phy_configure_opts_mipi_dphy cfg;
>>>> +   int clk_prepare, lpx, clk_zero, clk_post, clk_trail;
>>>> +   int hs_exit, hs_prepare, hs_zero, hs_trail;
>>>> +   unsigned long long clock_in_hz = m->clock * 1000;
>>>>
>>>>  if (driver_data->has_freqband)
>>>>  return;
>>>>
>>>> +   /* The dynamic_phy has the ability to adjust PHY Timing settings */
>>>> +   if (driver_data->dynamic_dphy) {
>>>> +   phy_mipi_dphy_get_default_config(clock_in_hz, bpp, 
>>>> dsi->lanes, );
>>> This requires adding "select GENERIC_PHY_MIPI_DPHY" to DRM_SAMSUNG_DSIM,
>>> otherwise with CONFIG_DRM_SAMSUNG_DSIM=m:
>>>
>>> ERROR: modpost: "phy_mipi_dphy_get_default_config"
>>> [drivers/gpu/drm/bridge/samsung-dsim.ko] undefined!
>>> make[5]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
>>> make[4]: *** [Makefile:1978: modpost] Error 2
>>> make[3]: *** [Makefile:357: __build_one_by_one] Error 2
>>>
>>> I'm sure there'll be a similar error if CONFIG_DRM_SAMSUNG_DSIM=y.
>> That's interesting, I didn't come across that.
>> What did you use for a starting point when you applied the patches?
>> I want to see if I can replicate it.
> next-20230421. My config is pretty much tailored to the Hummingbird Pulse.
> Device drivers for other hardware or things that I can't enable are all
> disabled. For example I don't have PHY_MIXEL_MIPI_DPHY enabled.
>
> Maybe you have some other bridge or phy that selects it enabled?


I've observed similar issue while building exynos_defconfig for arm 32bit.


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

Re: [PATCH V2 5/6] drm: bridge: samsung-dsim: Support non-burst mode

[Marek Szyprowski]

On 23.04.2023 14:12, Adam Ford wrote:
> The high-speed clock is hard-coded to the burst-clock
> frequency specified in the device tree.  However, when
> using devices like certain bridge chips without burst mode
> and varying resolutions and refresh rates, it may be
> necessary to set the high-speed clock dynamically based
> on the desired pixel clock for the connected device.
>
> This also removes the need to set a clock speed from
> the device tree for non-burst mode operation, since the
> pixel clock rate is the rate requested from the attached
> device like an HDMI bridge chip.  This should have no
> impact for people using burst-mode and setting the burst
> clock rate is still required for those users.
>
> Signed-off-by: Adam Ford 

This one breaks Exynos-5433 based TM2e board with a DSI panel.

> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 17 ++---
>   1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index f165483d5044..cea847b8e23c 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -657,11 +657,21 @@ static unsigned long samsung_dsim_set_pll(struct 
> samsung_dsim *dsi,
>   
>   static int samsung_dsim_enable_clock(struct samsung_dsim *dsi)
>   {
> - unsigned long hs_clk, byte_clk, esc_clk;
> + unsigned long hs_clk, byte_clk, esc_clk, pix_clk;
>   unsigned long esc_div;
>   u32 reg;
> + struct drm_display_mode *m = >mode;
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + /* m->clock is in KHz */
> + pix_clk = m->clock * 1000;
> +
> + /* Use burst_clk_rate for burst mode, otherwise use the pix_clk */
> + if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) && 
> dsi->burst_clk_rate)
> + hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
> + else
> + hs_clk = samsung_dsim_set_pll(dsi, DIV_ROUND_UP(pix_clk * bpp, 
> dsi->lanes));
>   
> - 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;
> @@ -1800,10 +1810,11 @@ static int samsung_dsim_parse_dt(struct samsung_dsim 
> *dsi)
>   return PTR_ERR(pll_clk);
>   }
>   
> + /* If it doesn't exist, use pixel clock instead of failing */
>   ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
>  >burst_clk_rate);
>       if (ret < 0)
> - return ret;
> + dsi->burst_clk_rate = 0;
>   
>   ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
>  >esc_clk_rate);

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

Re: [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations

[Marek Szyprowski]

f you dynamically scale the HS clock, then you would need to input the
>>>>> real used HS clock to the calculation in my patch, instead of the fixed
>>>>> burst mode rate.
>>>> I think what you're saying makes sense.
>>>>
>>>> The code I originally modeled this from was from the NXP downstream
>>>> kernel where they define the calculation as being in words [2]. I am
>>>> not saying the NXP code is perfect, but the NXP code works.  With this
>>>> series, my monitors are able to sync a bunch of different resolutions
>>>> from 1080p down to 640x480 and a bunch in between with various refresh
>>>> rates too. That was the goal of this series.
>>>>
>>>> Instead of just using your patch as-is, I will adapt yours to use the
>>>> scaled clock to see how it behaves and get back to you.
>>>>
>>> Thanks, that would be very much appreciated.
>> Lucas,
>>
>> I took your patch and added a dsi state variable named "hs_clock"  to
>> keep track of the output of samsung_dsim_set_pll which should be the
>> active high-speed clock.
>>
>> I then replaced one line in your code to reference the hs_clock
>> instead of the burst clock:
>>
>> @@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
>> samsung_dsim *dsi)
>>  u32 reg;
>>
>>  if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
>> -   int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
>> +   int byte_clk_khz = dsi->hs_clock / 1000 / 8;
>>  int hfp = (m->hsync_start - m->hdisplay) *
>> byte_clk_khz / m->clock;
>>
>> With that change, your patch works with the rest of my code, and I
>> think it's easier to read, and it doesn't involve recalculating the
>> clock speed each time since it's cached.  If you're OK with that, I'll
>> incorporate your code into V2 of my series, and I'll apply my changes
>> as a subsequent patch.  I hope to be able to send out V2 this weekend.
>>
> That's good to hear! Seems we are converging here. Feel free to pick up
> the patch, that's also easier for me as I don't have to resend with CC
> fixed.
>
>> I would be curious to know frm Marek Szyprowski what the impact is on
>> the Samsung devices, if any.
>>
> Since I messed up the list CC you also couldn't see his reply to my
> patch:
>
> | Tested-by: Marek Szyprowski 
> |
> | Works fine on the Exynos based boards I have in my test farm.

I didn't follow this discussion, I'm a bit busy with other stuff. I've 
just tested this series and patch #3 break Exynos based board. If you 
want me to test anything else (might be a work-in-progress code), just 
let me know by the separate mail.

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

Re: [PATCH 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically

[Marek Szyprowski]

On 15.04.2023 12:41, Adam Ford wrote:
> Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> having an entry in the device tree for samsung,pll-clock-frequency.
>
> Signed-off-by: Adam Ford 

This one breaks DSI panel operation on my Exynos-based Trats, Trats2 and 
TM2e boards. I've didn't check the details, but probably something is 
missing in the dts to make it working properly. Surprisingly the display 
is still working fine on Arndale board with DSI TC358764 bridge.

> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++--
>   1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9fec32b44e05..73f0c3fbbdf5 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1744,11 +1744,6 @@ static int samsung_dsim_parse_dt(struct samsung_dsim 
> *dsi)
>   struct device_node *node = dev->of_node;
>   int ret;
>   
> - ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> ->pll_clk_rate);
> - if (ret < 0)
> - return ret;
> -
>   ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
>  >burst_clk_rate);
>   if (ret < 0)
> @@ -1823,13 +1818,18 @@ int samsung_dsim_probe(struct platform_device *pdev)
>   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]))
> + if (!IS_ERR(dsi->clks[i])) {
> + dsi->pll_clk_rate = 
> clk_get_rate(dsi->clks[i]);
>   continue;
> + }
>   }
>   
>   dev_info(dev, "failed to get the clock: %s\n", 
> clk_names[i]);
>   return PTR_ERR(dsi->clks[i]);
>   }
> +
> +     if (strcmp(clk_names[i], "sclk_mipi") == 0)
> + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
>   }
>   
>   dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);

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

Re: [RFC PATCH 3/3] drm: bridge: samsung-dsim: Remove init quirk for Exynos

[Marek Szyprowski]

On 18.04.2023 12:42, Frieder Schrempf wrote:
> From: Frieder Schrempf 
>
> Assuming that with the init flow fixed to meet the documentation at
> [1] and the pre_enable_prev_first flag set in downstream bridge/panel
> drivers which require it, we can use the default flow for Exynos as
> already done for i.MX8M.
>
> [1] https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation
>
> Signed-off-by: Frieder Schrempf 
> ---
> I have no idea if my assumptions are correct and if this works at all.
> There's a very good chance it doesn't...

Unfortunately this change breaks all Exynos boards with DSI panels. I've 
check all 4 panels that are in mainline and none worked.

> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 39 ---
>   1 file changed, 11 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9775779721d9..8c68b767ae50 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1336,18 +1336,12 @@ static void samsung_dsim_atomic_pre_enable(struct 
> drm_bridge *bridge,
>   
>   dsi->state |= DSIM_STATE_ENABLED;
>   
> - /*
> -  * For Exynos-DSIM the downstream bridge, or panel are expecting
> -  * the host initialization during DSI transfer.
> -  */
> - if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
> - ret = samsung_dsim_init(dsi);
> - if (ret)
> - return;
> + ret = samsung_dsim_init(dsi);
> + if (ret)
> + return;
>   
> - samsung_dsim_set_display_mode(dsi);
> - samsung_dsim_set_display_enable(dsi, true);
> - }
> + samsung_dsim_set_display_mode(dsi);
> + samsung_dsim_set_display_enable(dsi, true);
>   }
>   
>   static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> @@ -1356,14 +1350,9 @@ static void samsung_dsim_atomic_enable(struct 
> drm_bridge *bridge,
>   struct samsung_dsim *dsi = bridge_to_dsi(bridge);
>   u32 reg;
>   
> - if (samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
> - samsung_dsim_set_display_mode(dsi);
> - samsung_dsim_set_display_enable(dsi, true);
> - } else {
> - reg = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
> - reg &= ~DSIM_FORCE_STOP_STATE;
> - samsung_dsim_write(dsi, DSIM_ESCMODE_REG, reg);
> - }
> + reg = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
> + reg &= ~DSIM_FORCE_STOP_STATE;
> + samsung_dsim_write(dsi, DSIM_ESCMODE_REG, reg);
>   
>   dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
>   }
> @@ -1377,11 +1366,9 @@ static void samsung_dsim_atomic_disable(struct 
> drm_bridge *bridge,
>   if (!(dsi->state & DSIM_STATE_ENABLED))
>   return;
>   
> - if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
> - reg = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
> - reg |= DSIM_FORCE_STOP_STATE;
> - samsung_dsim_write(dsi, DSIM_ESCMODE_REG, reg);
> - }
> + reg = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
> + reg |= DSIM_FORCE_STOP_STATE;
> + samsung_dsim_write(dsi, DSIM_ESCMODE_REG, reg);
>   
>   dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
>   }
> @@ -1680,10 +1667,6 @@ static ssize_t samsung_dsim_host_transfer(struct 
> mipi_dsi_host *host,
>   if (!(dsi->state & DSIM_STATE_ENABLED))
>   return -EINVAL;
>   
> - ret = samsung_dsim_init(dsi);
> - if (ret)
> - return ret;
> -
>   ret = mipi_dsi_create_packet(, msg);
>   if (ret < 0)
>   return ret;

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

Re: [PATCH 0/5] drm/exynos: Convert fbdev to DRM client

[Marek Szyprowski]

On 30.03.2023 09:36, Thomas Zimmermann wrote:
> Convert exynos' fbdev code to struct drm_client. Replaces the current
> ad-hoc integration. The conversion includes a number of cleanups. As
> with most other drivers' fbdev emulation, fbdev in exynos is now just
> another DRM client that runs after the DRM device has been registered.
>
> Once all drivers' fbdev emulation has been converted to struct drm_client,
> we can attempt to add additional in-kernel clients. A DRM-based dmesg
> log or a bootsplash are commonly mentioned. DRM can then switch easily
> among the existing clients if/when required.
>
> I did the conversion from similar experience with other drivers. But I
> don't have the hardware to test this. Any testing is welcome.

Seems to be working fine. Tested with default framebuffer based console 
and simple tool that writes RGB data to /dev/fb0.

Tested-by: Marek Szyprowski 


> Thomas Zimmermann (5):
>drm/exynos: Remove exynos_gem from struct exynos_drm_fbdev
>drm/exynos: Remove struct exynos_drm_fbdev
>drm/exynos: Remove fb_helper from struct exynos_drm_private
>drm/exynos: Initialize fbdev DRM client
>drm/exynos: Implement fbdev emulation as in-kernel client
>
>   drivers/gpu/drm/exynos/exynos_drm_drv.c   |  13 +-
>   drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
>   drivers/gpu/drm/exynos/exynos_drm_fb.c|   2 -
>   drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 174 +++---
>   drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  20 +--
>   5 files changed, 94 insertions(+), 117 deletions(-)
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

[PATCH] drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversion again

[Marek Szyprowski]

devm_regulator_get_enable_optional() returns -ENODEV if requested
optional regulator is not present. Adjust code for that, because in the
67d0a30128c9 I've incorrectly assumed that it also returns 0 when
regulator is not present.

Reported-by: Ricardo Cañuelo 
Fixes: 67d0a30128c9 ("drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() 
conversion")
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 534621a13a34..3d046878ce6c 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -718,7 +718,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
device *master,
dw_plat_data = _dw_hdmi->dw_plat_data;
 
ret = devm_regulator_get_enable_optional(dev, "hdmi");
-   if (ret < 0)
+   if (ret < 0 && ret != -ENODEV)
return ret;
 
meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
-- 
2.34.1

Re: [PATCH] drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversion

[Marek Szyprowski]

Hi Ricardo,

On 09.03.2023 09:55, Ricardo Cañuelo wrote:
> On lun 09-01-2023 23:00:33, Marek Szyprowski wrote:
>> devm_regulator_get_enable_optional() function returns 0 on success, so
>> use it for the check if function succeded instead of the -ENODEV value.
>>
>> Fixes: 429e87063661 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()")
>> Signed-off-by: Marek Szyprowski 
>> ---
>>   drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
>> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> index 7642f740272b..534621a13a34 100644
>> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> @@ -718,7 +718,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
>> device *master,
>>  dw_plat_data = _dw_hdmi->dw_plat_data;
>>   
>>  ret = devm_regulator_get_enable_optional(dev, "hdmi");
>> -if (ret != -ENODEV)
>> +if (ret < 0)
>>  return ret;
>>   
>>  meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
>> -- 
>> 2.39.0
> This patch seems to have caused (or uncovered) a regression in the
> bootrr.deferred-probe-empty test for meson-g12a-sei510. Apparently, this
> causes a driver to stay in the deferred probe list after boot.

Indeed my fix causes regression on the platform, which doesn't have 
"hdmi" regulator. Thanks for pointing that. I was really convinced that 
devm_regulator_get_enable_*optional*() returns 0 if requested regulator 
is not present (as "_optional" suffix suggests). Unfortunately it 
returns -ENODEV, what breaks meson_dw_hdmi driver. I will send a fix in 
a few minutes.


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

Re: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

Hello,

On 07.03.2023 10:22, Jagan Teki wrote:
> On Tue, Mar 7, 2023 at 1:25 PM Jagan Teki  wrote:
>> On Tue, Mar 7, 2023 at 4:11 AM Marek Szyprowski
>>  wrote:
>>> On 06.03.2023 18:24, Jagan Teki wrote:
>>>> On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski
>>>>  wrote:
>>>>> On 04.03.2023 19:59, Jagan Teki wrote:
>>>>>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski
>>>>>>  wrote:
>>>>>>> On 03.03.2023 15:51, 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.
>>>>>>>>
>>>>>>>> Inki Dae: please note that this series added on top of exynos-drm-next
>>>>>>>> since few exynos dsi changes are not been part of drm-misc-next.
>>>>>>>> Request you to pick these via exynos-drm-next, or let me know if you
>>>>>>>> have any comments?
>>>>>>> I gave it a try on Exynos TM2e and unfortunately it nukes again:
>>>>>>>
>>>>>>> exynos-drm exynos-drm: bound 1397.hdmi (ops hdmi_component_ops)
>>>>>>> Unable to handle kernel paging request at virtual address 
>>>>>>> 003d454d414e5675
>>>>>>> ...
>>>>>>> [003d454d414e5675] address between user and kernel address ranges
>>>>>>> Internal error: Oops: 9604 [#1] PREEMPT SMP
>>>>>>> Modules linked in:
>>>>>>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ 
>>>>>>> #13341
>>>>>>> Hardware name: Samsung TM2E board (DT)
>>>>>>> Workqueue: events_unbound deferred_probe_work_func
>>>>>>> pstate: 00c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>>>>> pc : drm_connector_list_iter_next+0x58/0x100
>>>>>>> lr : drm_connector_list_iter_next+0x2c/0x100
>>>>>>> sp : 8bbab910
>>>>>>> ...
>>>>>>> Call trace:
>>>>>>>  drm_connector_list_iter_next+0x58/0x100
>>>>>>>  drm_mode_config_reset+0xfc/0x144
>>>>>>>  exynos_drm_bind+0x160/0x1b8
>>>>>>>  try_to_bring_up_aggregate_device+0x168/0x1d4
>>>>>>>  __component_add+0xa8/0x170
>>>>>>>  component_add+0x14/0x20
>>>>>>>  hdmi_probe+0x3fc/0x6d4
>>>>>>>  platform_probe+0x68/0xd8
>>>>>>>  really_probe+0x148/0x2b4
>>>>>>>  __driver_probe_device+0x78/0xe0
>>>>>>>  driver_probe_device+0xd8/0x160
>>>>>>>  __device_attach_driver+0xb8/0x138
>>>>>>>  bus_for_each_drv+0x84/0xe0
>>>>>>>  __device_attach+0xa8/0x1b0
>>>>>>>  device_initial_probe+0x14/0x20
>>>>>>>  bus_probe_device+0xb0/0xb4
>>>>>>>  deferred_probe_work_func+0x8c/0xc8
>>>>>>>  process_one_work+0x288/0x6c8
>>>>>>>  worker_thread+0x24c/0x450
>>>>>>>  kthread+0x118/0x11c
>>>>>>>  ret_from_fork+0x10/0x20
>>>>>> This looks not related to dsi to me since there is no exynos_drm_dsi
>>>>>> call in the trace. look hdmi related. Moreover, I think the exynos dsi
>>>>>> worked well on v10 and I couldn't find any potential differences in
>>>>>> terms of call flow change.
>>>>>> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
>>>>> Well, the issue is definitely related to this patchset. On Friday, due
>>>>> to other kernel messages, I missed the most important part of the log:
>>>>>
>>>>> [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
>>>>> exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
>>>>> exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
>>>>> exynos-dsi 1390.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2
>>>>> device
>>>>> exynos-dsi 1390.dsi: request interrupt failed with -22
>>>>> panel-samsung-s6e3ha2: probe of 13

Re: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

Dear Jagan,

On 06.03.2023 18:24, Jagan Teki wrote:
> On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski
>  wrote:
>> On 04.03.2023 19:59, Jagan Teki wrote:
>>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski
>>>  wrote:
>>>> On 03.03.2023 15:51, 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.
>>>>>
>>>>> Inki Dae: please note that this series added on top of exynos-drm-next
>>>>> since few exynos dsi changes are not been part of drm-misc-next.
>>>>> Request you to pick these via exynos-drm-next, or let me know if you
>>>>> have any comments?
>>>> I gave it a try on Exynos TM2e and unfortunately it nukes again:
>>>>
>>>> exynos-drm exynos-drm: bound 1397.hdmi (ops hdmi_component_ops)
>>>> Unable to handle kernel paging request at virtual address 003d454d414e5675
>>>> ...
>>>> [003d454d414e5675] address between user and kernel address ranges
>>>> Internal error: Oops: 9604 [#1] PREEMPT SMP
>>>> Modules linked in:
>>>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341
>>>> Hardware name: Samsung TM2E board (DT)
>>>> Workqueue: events_unbound deferred_probe_work_func
>>>> pstate: 00c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>> pc : drm_connector_list_iter_next+0x58/0x100
>>>> lr : drm_connector_list_iter_next+0x2c/0x100
>>>> sp : 8bbab910
>>>> ...
>>>> Call trace:
>>>> drm_connector_list_iter_next+0x58/0x100
>>>> drm_mode_config_reset+0xfc/0x144
>>>> exynos_drm_bind+0x160/0x1b8
>>>> try_to_bring_up_aggregate_device+0x168/0x1d4
>>>> __component_add+0xa8/0x170
>>>> component_add+0x14/0x20
>>>> hdmi_probe+0x3fc/0x6d4
>>>> platform_probe+0x68/0xd8
>>>> really_probe+0x148/0x2b4
>>>> __driver_probe_device+0x78/0xe0
>>>> driver_probe_device+0xd8/0x160
>>>> __device_attach_driver+0xb8/0x138
>>>> bus_for_each_drv+0x84/0xe0
>>>> __device_attach+0xa8/0x1b0
>>>> device_initial_probe+0x14/0x20
>>>> bus_probe_device+0xb0/0xb4
>>>> deferred_probe_work_func+0x8c/0xc8
>>>> process_one_work+0x288/0x6c8
>>>> worker_thread+0x24c/0x450
>>>> kthread+0x118/0x11c
>>>> ret_from_fork+0x10/0x20
>>> This looks not related to dsi to me since there is no exynos_drm_dsi
>>> call in the trace. look hdmi related. Moreover, I think the exynos dsi
>>> worked well on v10 and I couldn't find any potential differences in
>>> terms of call flow change.
>>> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
>> Well, the issue is definitely related to this patchset. On Friday, due
>> to other kernel messages, I missed the most important part of the log:
>>
>> [drm] Exynos DRM: using 1380.decon device for DMA mapping operations
>> exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
>> exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
>> exynos-dsi 1390.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2
>> device
>> exynos-dsi 1390.dsi: request interrupt failed with -22
>> panel-samsung-s6e3ha2: probe of 1390.dsi.0 failed with error -22
>> exynos-drm exynos-drm: bound 1390.dsi (ops exynos_dsi_component_ops)
>> exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)
>>
>> It looks that the are at least 2 issues. The first one related to TE
>> interrupt registration, the second is broken error path, which should
>> free allocated resources and stop DRM from binding/initialization.
>>
>> This patch fixes the issue (TE gpio/interrupt is optional!):
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index b4a5348b763c..ed83495fe105 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct
>> samsung_dsim *dsi, struct device
>>   int ret;
>>
>>   dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN);
>> -   if (IS_ER

Re: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

Hi Jagan,

On 04.03.2023 19:59, Jagan Teki wrote:
> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski
>  wrote:
>> On 03.03.2023 15:51, 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.
>>>
>>> Inki Dae: please note that this series added on top of exynos-drm-next
>>> since few exynos dsi changes are not been part of drm-misc-next.
>>> Request you to pick these via exynos-drm-next, or let me know if you
>>> have any comments?
>> I gave it a try on Exynos TM2e and unfortunately it nukes again:
>>
>> exynos-drm exynos-drm: bound 1397.hdmi (ops hdmi_component_ops)
>> Unable to handle kernel paging request at virtual address 003d454d414e5675
>> ...
>> [003d454d414e5675] address between user and kernel address ranges
>> Internal error: Oops: 9604 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341
>> Hardware name: Samsung TM2E board (DT)
>> Workqueue: events_unbound deferred_probe_work_func
>> pstate: 00c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : drm_connector_list_iter_next+0x58/0x100
>> lr : drm_connector_list_iter_next+0x2c/0x100
>> sp : 8bbab910
>> ...
>> Call trace:
>>drm_connector_list_iter_next+0x58/0x100
>>drm_mode_config_reset+0xfc/0x144
>>exynos_drm_bind+0x160/0x1b8
>>try_to_bring_up_aggregate_device+0x168/0x1d4
>>__component_add+0xa8/0x170
>>component_add+0x14/0x20
>>hdmi_probe+0x3fc/0x6d4
>>platform_probe+0x68/0xd8
>>really_probe+0x148/0x2b4
>>__driver_probe_device+0x78/0xe0
>>driver_probe_device+0xd8/0x160
>>__device_attach_driver+0xb8/0x138
>>bus_for_each_drv+0x84/0xe0
>>__device_attach+0xa8/0x1b0
>>device_initial_probe+0x14/0x20
>>bus_probe_device+0xb0/0xb4
>>deferred_probe_work_func+0x8c/0xc8
>>process_one_work+0x288/0x6c8
>>worker_thread+0x24c/0x450
>>kthread+0x118/0x11c
>>ret_from_fork+0x10/0x20
> This looks not related to dsi to me since there is no exynos_drm_dsi
> call in the trace. look hdmi related. Moreover, I think the exynos dsi
> worked well on v10 and I couldn't find any potential differences in
> terms of call flow change.
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10

Well, the issue is definitely related to this patchset. On Friday, due 
to other kernel messages, I missed the most important part of the log:

[drm] Exynos DRM: using 1380.decon device for DMA mapping operations
exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops)
exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops)
exynos-dsi 1390.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 
device
exynos-dsi 1390.dsi: request interrupt failed with -22
panel-samsung-s6e3ha2: probe of 1390.dsi.0 failed with error -22
exynos-drm exynos-drm: bound 1390.dsi (ops exynos_dsi_component_ops)
exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops)

It looks that the are at least 2 issues. The first one related to TE 
interrupt registration, the second is broken error path, which should 
free allocated resources and stop DRM from binding/initialization.

This patch fixes the issue (TE gpio/interrupt is optional!):

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index b4a5348b763c..ed83495fe105 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct 
samsung_dsim *dsi, struct device
     int ret;

     dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN);
-   if (IS_ERR(dsi->te_gpio))
+   if (!dsi->te_gpio)
+   return 0;
+   else if (IS_ERR(dsi->te_gpio))
         return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), 
"failed to get te GPIO\n");

     te_gpio_irq = gpiod_to_irq(dsi->te_gpio);


The error path in samsung_dsim_host_attach() after 
samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up 
the allocated resources (removing the bridge, detaing the dsi device).

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

Re: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

Hi Jagan,

On 03.03.2023 15:51, 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.
>
> Inki Dae: please note that this series added on top of exynos-drm-next
> since few exynos dsi changes are not been part of drm-misc-next.
> Request you to pick these via exynos-drm-next, or let me know if you
> have any comments?

I gave it a try on Exynos TM2e and unfortunately it nukes again:

exynos-drm exynos-drm: bound 1397.hdmi (ops hdmi_component_ops)
Unable to handle kernel paging request at virtual address 003d454d414e5675
...
[003d454d414e5675] address between user and kernel address ranges
Internal error: Oops: 9604 [#1] PREEMPT SMP
Modules linked in:
CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341
Hardware name: Samsung TM2E board (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 00c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_connector_list_iter_next+0x58/0x100
lr : drm_connector_list_iter_next+0x2c/0x100
sp : 8bbab910
...
Call trace:
  drm_connector_list_iter_next+0x58/0x100
  drm_mode_config_reset+0xfc/0x144
  exynos_drm_bind+0x160/0x1b8
  try_to_bring_up_aggregate_device+0x168/0x1d4
  __component_add+0xa8/0x170
  component_add+0x14/0x20
  hdmi_probe+0x3fc/0x6d4
  platform_probe+0x68/0xd8
  really_probe+0x148/0x2b4
  __driver_probe_device+0x78/0xe0
  driver_probe_device+0xd8/0x160
  __device_attach_driver+0xb8/0x138
  bus_for_each_drv+0x84/0xe0
  __device_attach+0xa8/0x1b0
  device_initial_probe+0x14/0x20
  bus_probe_device+0xb0/0xb4
  deferred_probe_work_func+0x8c/0xc8
  process_one_work+0x288/0x6c8
  worker_thread+0x24c/0x450
  kthread+0x118/0x11c
  ret_from_fork+0x10/0x20
Code: 54000580 d1008061 f90006c1 9100c064 (b9403061)
---[ end trace  ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x460002,0e3c0400,421b
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception ]---


The debugging saga strikes again. I will try to analyze this on Monday...


> Patch 0001 - 0002: find child DSI bridge and panel
>
> Patch 0003 - 0004: optional PHY, PMS_P offset
>
> Patch 0005   : introduce hw_type
>
> Patch 0006 : fixing host init
>
> Patch 0007 : atomic_check
>
> Patch 0008 : input_bus_flags
>
> Patch 0009 : atomic_get_input_bus_fmts
>
> Patch 0010 - 0011: component vs bridge
>
> Patch 0012 : DSIM bridge
>
> Patch 0013 - 0014: i.MX8M Mini/Nano
>
> Patch 0015 - 0016: i.MX8M Plus
>
> Changes for v15:
> - drop drm_of helpers
> - re-added find DSI bridge/Panel helper in dsim
> - collect RB from Marek V
> - fixed leading underscore in function names
> - commit messages updated
> - rebased on exynos-drm-next
>
> Changes for v13:
> - remove devm call for DSI panel or bridge finding
> - rebased on drm-misc-next
>
> Changes for v12:
> - collect RB from Marek V
> - add te_irq_handler hook
> - fix comments from Marek V
> - update atomic_get_input_bus_fmts logic
>
> Changes for v11:
> - collect RB from Frieder Schrempf
> - collect ACK from Rob
> - collect ACK from Robert
> - fix BIT macro replacements
> - fix checkpatch --strict warnings
> - fix unneeded commit text
> - drop extra lines
>
> Changes for v10:
> - rebase on drm-misc-next
> - add drm_of_dsi_find_panel_or_bridge
> - add devm_drm_of_dsi_get_bridge
> - fix host initialization (Thanks to Marek Szyprowski)
> - rearrange the tiny patches for easy to review
> - update simple names for enum hw_type
> - add is_hw_exynos macro
> - rework on commit messages
>
> Changes for v9:
> - rebase on drm-misc-next
> - drop drm bridge attach fix for Exynos
> - added prepare_prev_first flag
> - added pre_enable_prev_first flag
> - fix bridge chain order for exynos
> - added fix for Exynos host init for first DSI transfer
> - added MEDIA_BUS_FMT_FIXED
> - return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt
>list is unsupported.
> - added MEDIA_BUS_FMT_YUYV10_1X20
> - added MEDIA_BUS_FMT_YUYV12_1X24
>
> 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
>

Re: [PATCH] drm/probe_helper: sort out poll_running vs poll_enabled

[Marek Szyprowski]

On 12.01.2023 16:42, Dmitry Baryshkov wrote:
> There are two flags attemting to guard connector polling:
> poll_enabled and poll_running. While poll_enabled semantics is clearly
> defined and fully adhered (mark that drm_kms_helper_poll_init() was
> called and not finalized by the _fini() call), the poll_running flag
> doesn't have such clearliness.
>
> This flag is used only in drm_helper_probe_single_connector_modes() to
> guard calling of drm_kms_helper_poll_enable, it doesn't guard the
> drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
> is actually running. Tie HPD enablement to this flag.
>
> This fix the following warning reported after merging the HPD series:
>
> Hot plug detection already enabled
> WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257 
> drm_bridge_hpd_enable+0x94/0x9c [drm]
> Modules linked in: videobuf2_memops snd_soc_simple_card 
> snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common 
> snd_soc_imx_spdif adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
> CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
> Hardware name: NXP i.MX8MQ EVK (DT)
> Workqueue: events_unbound deferred_probe_work_func
> pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
> lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
> sp : 89ef3740
> x29: 89ef3740 x28: 09331f00 x27: 1000
> x26: 0020 x25: 81148ed8 x24: 0a8fe000
> x23: fffd x22: 05086348 x21: 81133ee0
> x20: 0550d800 x19: 05086288 x18: 0006
> x17:  x16: 896ef008 x15: 972891004260
> x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
> x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
> x8 : 00250b00 x7 : 0003 x6 : 0011
> x5 :  x4 : bd986a48 x3 : 0001
> x2 :  x1 :  x0 : 0025
> Call trace:
>   drm_bridge_hpd_enable+0x94/0x9c [drm]
>   drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
>   drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
>   drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
>   drm_client_modeset_probe+0x204/0x1190 [drm]
>   __drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
>   drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
>   drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
>   drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
>   dcss_kms_attach+0x1c8/0x254 [imx_dcss]
>   dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
>   platform_probe+0x70/0xcc
>   really_probe+0xc4/0x2e0
>   __driver_probe_device+0x80/0xf0
>   driver_probe_device+0xe0/0x164
>   __device_attach_driver+0xc0/0x13c
>   bus_for_each_drv+0x84/0xe0
>   __device_attach+0xa4/0x1a0
>   device_initial_probe+0x1c/0x30
>   bus_probe_device+0xa4/0xb0
>   deferred_probe_work_func+0x90/0xd0
>   process_one_work+0x200/0x474
>   worker_thread+0x74/0x43c
>   kthread+0xfc/0x110
>   ret_from_fork+0x10/0x20
> ---[ end trace  ]---
>
> Reported-by: Laurentiu Palcu 
> Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
> Signed-off-by: Dmitry Baryshkov 

Seems to be fixing the issue I've observed recently on the Amlogic Meson 
based boards. Feel free to add:

Tested-by: Marek Szyprowski 

> ---
>   drivers/gpu/drm/drm_probe_helper.c | 110 +
>   1 file changed, 63 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 7973f2589ced..ef919d95fea6 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -222,6 +222,45 @@ drm_connector_mode_valid(struct drm_connector *connector,
>   return ret;
>   }
>   
> +static void drm_kms_helper_disable_hpd(struct drm_device *dev)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> +
> + drm_connector_list_iter_begin(dev, _iter);
> + drm_for_each_connector_iter(connector, _iter) {
> + const struct drm_connector_helper_funcs *funcs =
> + connector->helper_private;
> +
> + if (funcs && funcs->disable_hpd)
> + funcs->disable_hpd(connector);
> + }
> + drm_connector_list_iter_end(_iter);
> +}
> +
> +static bool drm_kms_helper_enable_hpd(struct drm_device *dev)
> +{
> + bool poll = false;
> + struct drm_connector *connector;
&

Re: [v3,3/7] drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement

[Marek Szyprowski]

Hi Neil,

On 12.01.2023 10:35, Neil Armstrong wrote:
> On 11/01/2023 13:41, Marek Szyprowski wrote:
>> On 02.11.2022 19:07, Dmitry Baryshkov wrote:
>>> Use drm_connector's helpers enable_hpd and disable_hpd to enable and
>>> disable HPD automatically by the means of drm_kms_helper_poll_*
>>> functions. As the drm_bridge_connector_enable_hpd() and
>>> drm_bridge_connector_disable_hpd() functions are now unused, replace
>>> them with stubs to ease driver migration.
>>>
>>> Enabling the HPD from drm_bridge_connector_init() can happen too early,
>>> before the driver is prepared to handle HPD events. As the
>>> drm_bridge_connector_enable_hpd() is empty anyway, drop this call
>>> anyway.
>>>
>>> Signed-off-by: Dmitry Baryshkov 
>>> ---
>>
>> This patch, merged to recent linux-next as commit 92d755d8f13b
>> ("drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD
>> enablement"), triggers the following warning on all my Amlogic Meson
>> based boards:
>>
>> [ cut here ]
>> Hot plug detection already enabled
>> WARNING: CPU: 2 PID: 285 at drivers/gpu/drm/drm_bridge.c:1257
>> drm_bridge_hpd_enable+0x90/0xa0
>> Modules linked in: snd_soc_meson_axg_frddr snd_soc_meson_axg_fifo
>> dwmac_generic panfrost(+) reset_meson_audio_arb(+) drm_shmem_helper
>> meson_dw_hdmi(+) dw_hdmi rc_odroid drm_display_helper meson_ir(+)
>> gpu_sched meson_rng rng_core meson_gxbb_wdt crct10dif_ce dwmac_meson8b
>> stmmac_platform snd_soc_meson_axg_sound_card snd_soc_meson_card_utils
>> mdio_mux_meson_g12a stmmac meson_drm pwm_meson pcs_xpcs meson_canvas
>> snd_soc_meson_axg_tdm_interface rtc_meson_vrtc
>> snd_soc_meson_axg_tdm_formatter nvmem_meson_efuse display_connector
>> CPU: 2 PID: 285 Comm: systemd-udevd Not tainted 6.1.0-rc6+ #13236
>> Hardware name: Hardkernel ODROID-C4 (DT)
>> pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : drm_bridge_hpd_enable+0x90/0xa0
>> lr : drm_bridge_hpd_enable+0x90/0xa0
>> ...
>> Call trace:
>>    drm_bridge_hpd_enable+0x90/0xa0
>>    _drm_bridge_connector_enable_hpd+0x24/0x34
>
> Weird because _drm_bridge_connector_enable_hpd() has been removed with
> 4c00ac500d0e ("drm/bridge_connector: drop 
> drm_bridge_connector_en/disable_hpd()")

The above log has been captured at commit 92d755d8f13b during bisecting, 
so 4c00ac500d0e is not applied yet. Maybe I should have mention that. 
The issue on top of linux-next is similar.

>
>>  drm_kms_helper_poll_enable.part.0+0x50/0xd0
>
> It seems drm_kms_helper_poll_enable is called again by
> drm_helper_probe_single_connector_modes() because poll_running isn't set.
>
> Can you try with this change:

This fixes the issue on top of linux next-20230112. Thanks! Feel free to 
add if you plan to submit it as a formal patch:

Reported-by: Marek Szyprowski 

Tested-by: Marek Szyprowski 

 > ...

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

Re: [v3,3/7] drm/bridge_connector: rely on drm_kms_helper_poll_* for HPD enablement

[Marek Szyprowski]

 typically used by display drivers in their suspend handler.
>*/
>   void drm_bridge_connector_disable_hpd(struct drm_connector *connector)
> +{
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_connector_disable_hpd);
> +
> +static void _drm_bridge_connector_disable_hpd(struct drm_connector 
> *connector)
>   {
>   struct drm_bridge_connector *bridge_connector =
>   to_drm_bridge_connector(connector);
> @@ -164,7 +173,6 @@ void drm_bridge_connector_disable_hpd(struct 
> drm_connector *connector)
>   if (hpd)
>   drm_bridge_hpd_disable(hpd);
>   }
> -EXPORT_SYMBOL_GPL(drm_bridge_connector_disable_hpd);
>   
>   /* 
> -
>* Bridge Connector Functions
> @@ -305,6 +313,8 @@ static int drm_bridge_connector_get_modes(struct 
> drm_connector *connector)
>   static const struct drm_connector_helper_funcs 
> drm_bridge_connector_helper_funcs = {
>   .get_modes = drm_bridge_connector_get_modes,
>   /* No need for .mode_valid(), the bridges are checked by the core. */
> + .enable_hpd = _drm_bridge_connector_enable_hpd,
> + .disable_hpd = _drm_bridge_connector_disable_hpd,
>   };
>   
>   /* 
> -
> @@ -387,10 +397,8 @@ struct drm_connector *drm_bridge_connector_init(struct 
> drm_device *drm,
>   connector_type, ddc);
>   drm_connector_helper_add(connector, _bridge_connector_helper_funcs);
>   
> - if (bridge_connector->bridge_hpd) {
> + if (bridge_connector->bridge_hpd)
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
> - drm_bridge_connector_enable_hpd(connector);
> - }
>   else if (bridge_connector->bridge_detect)
>   connector->polled = DRM_CONNECTOR_POLL_CONNECT
> | DRM_CONNECTOR_POLL_DISCONNECT;

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

[PATCH] drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversion

[Marek Szyprowski]

devm_regulator_get_enable_optional() function returns 0 on success, so
use it for the check if function succeded instead of the -ENODEV value.

Fixes: 429e87063661 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()")
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7642f740272b..534621a13a34 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -718,7 +718,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
device *master,
dw_plat_data = _dw_hdmi->dw_plat_data;
 
ret = devm_regulator_get_enable_optional(dev, "hdmi");
-   if (ret != -ENODEV)
+   if (ret < 0)
return ret;
 
meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
-- 
2.39.0

Re: [RESEND2,v4,2/2] drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()

[Marek Szyprowski]

Hi Matti,

On 30.11.2022 10:23, Matti Vaittinen wrote:
> Simplify using the devm_regulator_get_enable_optional(). Also drop the
> now unused struct member 'hdmi_supply'.
>
> Signed-off-by: Matti Vaittinen 
> Martin Blumenstingl 
> ---
> v4 resend 2:
> Respinning unchanged code with the commit title changed as wa suggested
> by Robert Foss and commit message changed as was suggested by Martin.
>
> I am doing a clean-up for my local git and encountered this one.
> Respinning as it seems this one fell through the cracks.
> ---
>   drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
>   1 file changed, 3 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 5cd2b2ebbbd3..7642f740272b 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -140,7 +140,6 @@ struct meson_dw_hdmi {
>   struct reset_control *hdmitx_apb;
>   struct reset_control *hdmitx_ctrl;
>   struct reset_control *hdmitx_phy;
> - struct regulator *hdmi_supply;
>   u32 irq_stat;
>   struct dw_hdmi *hdmi;
>   struct drm_bridge *bridge;
> @@ -665,11 +664,6 @@ static void meson_dw_hdmi_init(struct meson_dw_hdmi 
> *meson_dw_hdmi)
>   
>   }
>   
> -static void meson_disable_regulator(void *data)
> -{
> - regulator_disable(data);
> -}
> -
>   static void meson_disable_clk(void *data)
>   {
>   clk_disable_unprepare(data);
> @@ -723,20 +717,9 @@ static int meson_dw_hdmi_bind(struct device *dev, struct 
> device *master,
>   meson_dw_hdmi->data = match;
>   dw_plat_data = _dw_hdmi->dw_plat_data;
>   
> - meson_dw_hdmi->hdmi_supply = devm_regulator_get_optional(dev, "hdmi");
> - if (IS_ERR(meson_dw_hdmi->hdmi_supply)) {
> - if (PTR_ERR(meson_dw_hdmi->hdmi_supply) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> - meson_dw_hdmi->hdmi_supply = NULL;
> - } else {
> - ret = regulator_enable(meson_dw_hdmi->hdmi_supply);
> - if (ret)
> - return ret;
> - ret = devm_add_action_or_reset(dev, meson_disable_regulator,
> -meson_dw_hdmi->hdmi_supply);
> - if (ret)
> - return ret;
> - }
> + ret = devm_regulator_get_enable_optional(dev, "hdmi");
> + if (ret != -ENODEV)

The above line should be "if (ret < 0)", otherwise it breaks hdmi support.

I've noticed this once this change has been merged to linux-next and all 
my Amlogic Meson based boards failed to initialize HDMI. Is it possible 
to fix this in drm tree or do I need to send the incremental fixup?

> + return ret;
>   
>   meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
>   "hdmitx_apb");

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

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 14.12.2022 06:33, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 9:11 PM Marek Szyprowski
>  wrote:
>> On 13.12.2022 16:15, Jagan Teki wrote:
>>> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
>>>  wrote:
>>>> On 13.12.2022 15:18, Jagan Teki wrote:
>>>>> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
>>>>>  wrote:
>>>>>> On 13.12.2022 13:20, Marek Szyprowski wrote:
>>>>>>> On 13.12.2022 11:40, Jagan Teki wrote:
>>>>>>>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>>>>>>>>  wrote:
>>>>>>>>> On 12.12.2022 16:33, Jagan Teki wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>>>>>>>>
>>>>>>>>> On 12.12.2022 09:32, Jagan Teki wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> Hi Jagan,
>>>>>>>>>
>>>>>>>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>>>>>>>
>>>>>>>>> The existing drm panels and bridges in Exynos required host
>>>>>>>>> initialization during the first DSI command transfer even though
>>>>>>>>> the initialization was done before.
>>>>>>>>>
>>>>>>>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>>>>>>>> flag and triggers from host transfer.
>>>>>>>>>
>>>>>>>>> Do this exclusively for Exynos.
>>>>>>>>>
>>>>>>>>> Initial logic is derived from Marek Szyprowski changes.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Marek Szyprowski 
>>>>>>>>> Signed-off-by: Jagan Teki 
>>>>>>>>> ---
>>>>>>>>> Changes from v9:
>>>>>>>>> - derived from v8
>>>>>>>>> - added comments
>>>>>>>>>
>>>>>>>>>drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>>>>>>>include/drm/bridge/samsung-dsim.h |  5 +++--
>>>>>>>>>2 files changed, 17 insertions(+), 3 deletions(-)
>>>>>>>>>
>>>>>>>>> The following chunk is missing compared to v8:
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>>>>>>>> *dsi, unsigned int flag)
>>>>>>>>>   return 0;
>>>>>>>>>
>>>>>>>>>   samsung_dsim_reset(dsi);
>>>>>>>>> -   samsung_dsim_enable_irq(dsi);
>>>>>>>>> +
>>>>>>>>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>>>> +   samsung_dsim_enable_irq(dsi);
>>>>>>>>>
>>>>>>>>> Is this really required? does it make sure that the IRQ does not
>>>>>>>>> enable twice?
>>>>>>>>>
>>>>>>>>> That's what that check does. Without the 'if (!(dsi->state &
>>>>>>>>> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
>>>>>>>>> from pre_enable, then from the first transfer), what leads to a
>>>>>>>>> warning from irq core.
>>>>>>>>>
>>>>>>>>> I've just noticed that we also would need to clear the
>>>>>>>>> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 13.12.2022 16:15, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
>  wrote:
>> On 13.12.2022 15:18, Jagan Teki wrote:
>>> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
>>>  wrote:
>>>> On 13.12.2022 13:20, Marek Szyprowski wrote:
>>>>> On 13.12.2022 11:40, Jagan Teki wrote:
>>>>>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>>>>>>  wrote:
>>>>>>> On 12.12.2022 16:33, Jagan Teki wrote:
>>>>>>>
>>>>>>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>>>>>>>  wrote:
>>>>>>>
>>>>>>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>>>>>>
>>>>>>> On 12.12.2022 09:32, Jagan Teki wrote:
>>>>>>>
>>>>>>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>>>>>>  wrote:
>>>>>>>
>>>>>>> Hi Jagan,
>>>>>>>
>>>>>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>>>>>
>>>>>>> The existing drm panels and bridges in Exynos required host
>>>>>>> initialization during the first DSI command transfer even though
>>>>>>> the initialization was done before.
>>>>>>>
>>>>>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>>>>>> flag and triggers from host transfer.
>>>>>>>
>>>>>>> Do this exclusively for Exynos.
>>>>>>>
>>>>>>> Initial logic is derived from Marek Szyprowski changes.
>>>>>>>
>>>>>>> Signed-off-by: Marek Szyprowski 
>>>>>>> Signed-off-by: Jagan Teki 
>>>>>>> ---
>>>>>>> Changes from v9:
>>>>>>> - derived from v8
>>>>>>> - added comments
>>>>>>>
>>>>>>>   drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>>>>>   include/drm/bridge/samsung-dsim.h |  5 +++--
>>>>>>>   2 files changed, 17 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> The following chunk is missing compared to v8:
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>>>>>> *dsi, unsigned int flag)
>>>>>>>  return 0;
>>>>>>>
>>>>>>>  samsung_dsim_reset(dsi);
>>>>>>> -   samsung_dsim_enable_irq(dsi);
>>>>>>> +
>>>>>>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>>>> +   samsung_dsim_enable_irq(dsi);
>>>>>>>
>>>>>>> Is this really required? does it make sure that the IRQ does not
>>>>>>> enable twice?
>>>>>>>
>>>>>>> That's what that check does. Without the 'if (!(dsi->state &
>>>>>>> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
>>>>>>> from pre_enable, then from the first transfer), what leads to a
>>>>>>> warning from irq core.
>>>>>>>
>>>>>>> I've just noticed that we also would need to clear the
>>>>>>> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>>>>>>>
>>>>>>> However I've found that a bit simpler patch would keep the current code
>>>>>>> flow for Exynos instead of this reinitialization hack. This can be
>>>>>>> applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
>>>>>>> init in pre_enable" patch:
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>>> index 0b2e52585485..acc95c61ae45 100644
>>>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>>&

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 13.12.2022 15:18, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
>  wrote:
>> On 13.12.2022 13:20, Marek Szyprowski wrote:
>>> On 13.12.2022 11:40, Jagan Teki wrote:
>>>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>>>>  wrote:
>>>>> On 12.12.2022 16:33, Jagan Teki wrote:
>>>>>
>>>>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>>>>>  wrote:
>>>>>
>>>>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>>>>
>>>>> On 12.12.2022 09:32, Jagan Teki wrote:
>>>>>
>>>>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>>>>  wrote:
>>>>>
>>>>> Hi Jagan,
>>>>>
>>>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>>>
>>>>> The existing drm panels and bridges in Exynos required host
>>>>> initialization during the first DSI command transfer even though
>>>>> the initialization was done before.
>>>>>
>>>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>>>> flag and triggers from host transfer.
>>>>>
>>>>> Do this exclusively for Exynos.
>>>>>
>>>>> Initial logic is derived from Marek Szyprowski changes.
>>>>>
>>>>> Signed-off-by: Marek Szyprowski 
>>>>> Signed-off-by: Jagan Teki 
>>>>> ---
>>>>> Changes from v9:
>>>>> - derived from v8
>>>>> - added comments
>>>>>
>>>>>  drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>>>  include/drm/bridge/samsung-dsim.h |  5 +++--
>>>>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>>>>
>>>>> The following chunk is missing compared to v8:
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>>>> *dsi, unsigned int flag)
>>>>> return 0;
>>>>>
>>>>> samsung_dsim_reset(dsi);
>>>>> -   samsung_dsim_enable_irq(dsi);
>>>>> +
>>>>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>> +   samsung_dsim_enable_irq(dsi);
>>>>>
>>>>> Is this really required? does it make sure that the IRQ does not
>>>>> enable twice?
>>>>>
>>>>> That's what that check does. Without the 'if (!(dsi->state &
>>>>> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
>>>>> from pre_enable, then from the first transfer), what leads to a
>>>>> warning from irq core.
>>>>>
>>>>> I've just noticed that we also would need to clear the
>>>>> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>>>>>
>>>>> However I've found that a bit simpler patch would keep the current code
>>>>> flow for Exynos instead of this reinitialization hack. This can be
>>>>> applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
>>>>> init in pre_enable" patch:
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 0b2e52585485..acc95c61ae45 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1291,9 +1291,11 @@ 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;
>>>>> +   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
>>>>> +   ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>>>> +   if (ret)
>>>>> +   return;
>>

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 13.12.2022 13:20, Marek Szyprowski wrote:
> On 13.12.2022 11:40, Jagan Teki wrote:
>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>>  wrote:
>>> On 12.12.2022 16:33, Jagan Teki wrote:
>>>
>>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>>>  wrote:
>>>
>>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>>
>>> On 12.12.2022 09:32, Jagan Teki wrote:
>>>
>>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>>  wrote:
>>>
>>> Hi Jagan,
>>>
>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>
>>> The existing drm panels and bridges in Exynos required host
>>> initialization during the first DSI command transfer even though
>>> the initialization was done before.
>>>
>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>> flag and triggers from host transfer.
>>>
>>> Do this exclusively for Exynos.
>>>
>>> Initial logic is derived from Marek Szyprowski changes.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Changes from v9:
>>> - derived from v8
>>> - added comments
>>>
>>>     drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>     include/drm/bridge/samsung-dsim.h |  5 +++--
>>>     2 files changed, 17 insertions(+), 3 deletions(-)
>>>
>>> The following chunk is missing compared to v8:
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>> *dsi, unsigned int flag)
>>>    return 0;
>>>
>>>    samsung_dsim_reset(dsi);
>>> -   samsung_dsim_enable_irq(dsi);
>>> +
>>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> +   samsung_dsim_enable_irq(dsi);
>>>
>>> Is this really required? does it make sure that the IRQ does not
>>> enable twice?
>>>
>>> That's what that check does. Without the 'if (!(dsi->state &
>>> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
>>> from pre_enable, then from the first transfer), what leads to a
>>> warning from irq core.
>>>
>>> I've just noticed that we also would need to clear the
>>> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>>>
>>> However I've found that a bit simpler patch would keep the current code
>>> flow for Exynos instead of this reinitialization hack. This can be
>>> applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
>>> init in pre_enable" patch:
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 0b2e52585485..acc95c61ae45 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1291,9 +1291,11 @@ 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;
>>> +   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
>>> +   ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>>> +   if (ret)
>>> +   return;
>>> +   }
>>>
>>> Sorry, I don't understand this. Does it mean Exynos doesn't need to
>>> init host in pre_enable? If I remember correctly even though the host
>>> is initialized it has to reinitialize during the first transfer - This
>>> is what the Exynos requirement is. Please correct or explain here.
>>>
>>> This is a matter of enabling power regulator(s) in the right order 
>>> and doing the host initialization in the right moment. It was never 
>>> a matter of re-initialization. See the current code for the 
>>> reference (it uses the same approach as my above change). I've 
>>> already explained that here:
>>>
>>> https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5...@samsung.com/
>>>  
>>

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

Hi,

On 13.12.2022 11:40, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>  wrote:
>> On 12.12.2022 16:33, Jagan Teki wrote:
>>
>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>>  wrote:
>>
>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>
>> On 12.12.2022 09:32, Jagan Teki wrote:
>>
>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>  wrote:
>>
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>
>> The existing drm panels and bridges in Exynos required host
>> initialization during the first DSI command transfer even though
>> the initialization was done before.
>>
>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>> flag and triggers from host transfer.
>>
>> Do this exclusively for Exynos.
>>
>> Initial logic is derived from Marek Szyprowski changes.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Jagan Teki 
>> ---
>> Changes from v9:
>> - derived from v8
>> - added comments
>>
>> drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>> include/drm/bridge/samsung-dsim.h |  5 +++--
>> 2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> The following chunk is missing compared to v8:
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 6e9ad955ebd3..6a9403cb92ae 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>> *dsi, unsigned int flag)
>>return 0;
>>
>>samsung_dsim_reset(dsi);
>> -   samsung_dsim_enable_irq(dsi);
>> +
>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>> +   samsung_dsim_enable_irq(dsi);
>>
>> Is this really required? does it make sure that the IRQ does not
>> enable twice?
>>
>> That's what that check does. Without the 'if (!(dsi->state &
>> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
>> from pre_enable, then from the first transfer), what leads to a
>> warning from irq core.
>>
>> I've just noticed that we also would need to clear the
>> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>>
>> However I've found that a bit simpler patch would keep the current code
>> flow for Exynos instead of this reinitialization hack. This can be
>> applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
>> init in pre_enable" patch:
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 0b2e52585485..acc95c61ae45 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1291,9 +1291,11 @@ 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;
>> +   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
>> +   ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>> +   if (ret)
>> +   return;
>> +   }
>>
>> Sorry, I don't understand this. Does it mean Exynos doesn't need to
>> init host in pre_enable? If I remember correctly even though the host
>> is initialized it has to reinitialize during the first transfer - This
>> is what the Exynos requirement is. Please correct or explain here.
>>
>> This is a matter of enabling power regulator(s) in the right order and doing 
>> the host initialization in the right moment. It was never a matter of 
>> re-initialization. See the current code for the reference (it uses the same 
>> approach as my above change). I've already explained that here:
>>
>> https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5...@samsung.com/
>>
>> If you would like to see the exact proper moment of the dsi host 
>> initialization on the Exynos see the code here:
>>
>> https://protect2.fireeye.com/v1/url?k=5dc33900-0258001f-5dc2b24f-000babdfecba-f7c1a2a1905c83ca=1=f086bfdb-9055-48bd-b9c2-5dffb6c0d558=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv5.18-next-20220511-dsi-rework
>>  and patches adding mipi_dsi_host_init() to panel/bridge drivers.
> As I said before, the downstream bridge needs an explicit call to host
> init via mipi_dsi_host_init - this is indeed not a usual use-case
> scenario. Let's handle this with a REINIT fix and see if we can update
> this later to handle both scenarios.
>
> Would you please test this repo, I have included all.
>
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10

This doesn't work on TM2e board. Give me some time to find why...

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

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 12.12.2022 16:33, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>   wrote:
>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>> On 12.12.2022 09:32, Jagan Teki wrote:
>>>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>>>   wrote:
>>>>> Hi Jagan,
>>>>>
>>>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>>>> The existing drm panels and bridges in Exynos required host
>>>>>> initialization during the first DSI command transfer even though
>>>>>> the initialization was done before.
>>>>>>
>>>>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>>>>> flag and triggers from host transfer.
>>>>>>
>>>>>> Do this exclusively for Exynos.
>>>>>>
>>>>>> Initial logic is derived from Marek Szyprowski changes.
>>>>>>
>>>>>> Signed-off-by: Marek Szyprowski
>>>>>> Signed-off-by: Jagan Teki
>>>>>> ---
>>>>>> Changes from v9:
>>>>>> - derived from v8
>>>>>> - added comments
>>>>>>
>>>>>> drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>>>> include/drm/bridge/samsung-dsim.h |  5 +++--
>>>>>> 2 files changed, 17 insertions(+), 3 deletions(-)
>>>>> The following chunk is missing compared to v8:
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>>>> *dsi, unsigned int flag)
>>>>>return 0;
>>>>>
>>>>>samsung_dsim_reset(dsi);
>>>>> -   samsung_dsim_enable_irq(dsi);
>>>>> +
>>>>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>>>> +   samsung_dsim_enable_irq(dsi);
>>>> Is this really required? does it make sure that the IRQ does not
>>>> enable twice?
>>> That's what that check does. Without the 'if (!(dsi->state &
>>> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
>>> from pre_enable, then from the first transfer), what leads to a
>>> warning from irq core.
>> I've just noticed that we also would need to clear the
>> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>>
>> However I've found that a bit simpler patch would keep the current code
>> flow for Exynos instead of this reinitialization hack. This can be
>> applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
>> init in pre_enable" patch:
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 0b2e52585485..acc95c61ae45 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1291,9 +1291,11 @@ 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;
>> +   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
>> +   ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>> +   if (ret)
>> +   return;
>> +   }
> Sorry, I don't understand this. Does it mean Exynos doesn't need to
> init host in pre_enable? If I remember correctly even though the host
> is initialized it has to reinitialize during the first transfer - This
> is what the Exynos requirement is. Please correct or explain here.

This is a matter of enabling power regulator(s) in the right order and 
doing the host initialization in the right moment. It was never a matter 
of re-initialization. See the current code for the reference (it uses 
the same approach as my above change). I've already explained that here:

https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5...@samsung.com/

If you would like to see the exact proper moment of the dsi host 
initialization on the Exynos see the code here:

https://github.com/mszyprow/linux/tree/v5.18-next-20220511-dsi-rework  and 
patches addingmipi_dsi_host_init() to panel/bridge drivers.

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

Re: [PATCH v9 00/18] drm: bridge: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

Hi Jagan,

On 09.12.2022 16:23, 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.

Well, I think I've managed to fix the remaining bits to keep it working 
on Exynos and have all the features added in meantime between v1..v9. 
I've posted my comments in the individual patches, but to make think 
easier to test, I've also pushed my changes to the github:

https://github.com/mszyprow/linux/tree/v6.1-next-20221208-dsi-v9-fixed

With that fixes, feel free to add:

Tested-by: Marek Szyprowski 

to all common/Exynos related patches.


> Changes for v9:
> - rebase on drm-misc-next
> - drop drm bridge attach fix for Exynos
> - added prepare_prev_first flag
> - added pre_enable_prev_first flag
> - fix bridge chain order for exynos
> - added fix for Exynos host init for first DSI transfer
> - added MEDIA_BUS_FMT_FIXED
> - return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt
>list is unsupported.
> - added MEDIA_BUS_FMT_YUYV10_1X20
> - added MEDIA_BUS_FMT_YUYV12_1X24
>
> 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
> t
> 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
>
> Tested in Engicam i.Core MX8M Mini SoM.
>
> Repo:
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v9
>
> v8:
> https://lore.kernel.org/all/20221110183853.3678209-1-ja...@amarulasolutions.com/
>
> Any inputs?
> Jagan.
>
> Jagan Teki (16):
>drm: panel: Enable prepare_prev_first flag for samsung-s6e panels
>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: Add host init in pre_enable
>drm: bridge: samsung-dsim: Init exynos host for first DSI transfer
>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
>drm: bridge: samsung-dsim: Add i.MX8M Plus support
>
> Marek Szyprowski (2):
>drm/bridge: tc358764: Enable pre_enable_prev_first flag
>drm: exynos: dsi: Restore proper bridge chain order
>
>   .../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 | 1934 +
>   drivers/gpu/drm/bridge/tc358764.c |1 +
>   drivers/gpu/drm/exynos/Kconfig|1 +
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 1769 +--
>   drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c |1 +
>   .../gpu/drm/panel/panel-samsung-s6e63j0x03.c  |1 +
>   drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c |1 +
>   include/drm/bridge/samsung-dsim.h |  116 +
>   12 files changed, 2195 insertions(+), 1653 deletions(-)
>   create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>   create mode 100644 include/drm/bridge/samsung-dsim.h
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 12.12.2022 09:43, Marek Szyprowski wrote:
> On 12.12.2022 09:32, Jagan Teki wrote:
>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>  wrote:
>>> Hi Jagan,
>>>
>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>> The existing drm panels and bridges in Exynos required host
>>>> initialization during the first DSI command transfer even though
>>>> the initialization was done before.
>>>>
>>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>>> flag and triggers from host transfer.
>>>>
>>>> Do this exclusively for Exynos.
>>>>
>>>> Initial logic is derived from Marek Szyprowski changes.
>>>>
>>>> Signed-off-by: Marek Szyprowski 
>>>> Signed-off-by: Jagan Teki 
>>>> ---
>>>> Changes from v9:
>>>> - derived from v8
>>>> - added comments
>>>>
>>>>    drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>>    include/drm/bridge/samsung-dsim.h |  5 +++--
>>>>    2 files changed, 17 insertions(+), 3 deletions(-)
>>> The following chunk is missing compared to v8:
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>> *dsi, unsigned int flag)
>>>   return 0;
>>>
>>>   samsung_dsim_reset(dsi);
>>> -   samsung_dsim_enable_irq(dsi);
>>> +
>>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> +   samsung_dsim_enable_irq(dsi);
>> Is this really required? does it make sure that the IRQ does not 
>> enable twice?
>
> That's what that check does. Without the 'if (!(dsi->state & 
> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first 
> from pre_enable, then from the first transfer), what leads to a 
> warning from irq core.

I've just noticed that we also would need to clear the 
DSIM_STATE_REINITIALIZED flag in dsim_suspend.

However I've found that a bit simpler patch would keep the current code 
flow for Exynos instead of this reinitialization hack. This can be 
applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host 
init in pre_enable" patch:

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 0b2e52585485..acc95c61ae45 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1291,9 +1291,11 @@ 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;
+   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
+   ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+   if (ret)
+   return;
+   }
  }

  static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
diff --git a/include/drm/bridge/samsung-dsim.h 
b/include/drm/bridge/samsung-dsim.h
index b8132bf8e36f..b4e26de88b9e 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -30,6 +30,9 @@ enum samsung_dsim_type {
     SAMSUNG_DSIM_TYPE_COUNT,
  };

+#define samsung_dsim_hw_is_exynos(hw) ((hw) >= 
SAMSUNG_DSIM_TYPE_EXYNOS3250 && \
+   (hw) <= SAMSUNG_DSIM_TYPE_EXYNOS5433)
+
  struct samsung_dsim_transfer {
     struct list_head list;
     struct completion completed;



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

Re: [PATCH v9 03/18] drm: exynos: dsi: Restore proper bridge chain order

[Marek Szyprowski]

On 09.12.2022 16:23, Jagan Teki wrote:
> From: Marek Szyprowski 
>
> Restore the proper bridge chain by finding the previous bridge
> in the chain instead of passing NULL.
>
> This establishes a proper bridge chain while attaching downstream
> bridges.
>
> v9, v4:
> * none
>
> v3:
> * new patch
>
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Jagan Teki 
> ---

As we are resurrecting this patch, one more change is needed here:

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e5b1540c4ae4..9d10a89d28f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1713,6 +1713,7 @@ static int exynos_dsi_probe(struct platform_device 
*pdev)
     dsi->bridge.funcs = _dsi_bridge_funcs;
     dsi->bridge.of_node = dev->of_node;
     dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
+   dsi->bridge.pre_enable_prev_first = true;

     ret = component_add(dev, _dsi_component_ops);
     if (ret)


On Exynos5433 Exynos DSI is together with Exynos MIC in the bridge 
chain: Decon -> MIC -> DSI -> Panel.

To ensure proper order of initialization we need to mark our bridge 
driver also with the pre_enable_prev_first flag. This would also need to 
be added to patch "[PATCH v9 06/18] drm: bridge: Generalize Exynos-DSI 
driver into a Samsung DSIM bridge".


>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index ec673223d6b7..e5b1540c4ae4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1428,7 +1428,8 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
>   {
>   struct exynos_dsi *dsi = bridge_to_dsi(bridge);
>   
> - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
> + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
> +  flags);
>   }
>   
>   static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
> @@ -1474,7 +1475,10 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   
>   drm_bridge_add(>bridge);
>   
> - drm_bridge_attach(encoder, >bridge, NULL, 0);
> + drm_bridge_attach(encoder, >bridge,
> +   list_first_entry_or_null(>bridge_chain,
> +struct drm_bridge,
> +    chain_node), 0);
>   
>   /*
>* This is a temporary solution and should be made by more generic way.

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

Re: [PATCH v9 04/18] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Szyprowski]

On 12.12.2022 10:03, Jagan Teki wrote:
>   On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
>  wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> 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")
>>> Reviewed-by: Nicolas Boichat 
>>> Reported-by: Sébastien Szymanski 
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Changes for v9:
>>> - none
>>>
>>>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 e5b1540c4ae4..50a2a9ca88a9 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) {
>>
>> Huh, this changes the logic in the driver! I've spent another half of
>> the night trying to figure out why v8 and v9 doesn't work on all my
>> Exynos boards with DSI panels again...
>>
>> Please drop this patch from this series. If you want to get the Exynos
>> DSI -> Samsung DSIM conversion merged, please focus on the core patches
>> and don't add more random 'fixes' to each new version.
>>
>> This change has to be discussed separately. The values written by the
>> Exynos DSI driver to the registers ARE CORRECT and DSI panels work fine
>> with such configuration. So either everything is correct, or these flags
>> are reversed both in the Exynos DSI driver AND at least tested DSI
>> panels (s6e8aa0, s6e3ha2, s6e63j0x03). I would need to check this in
>> panel datasheets if I manage to get them.
> This issue was reproduced as part of the series in v7 in i.MX8m
> platform and reported by Sébastien Szymanski [1] and TRM matches the
> fix as well.
>
> [1] 
> https://lore.kernel.org/all/4c9475d0-f76f-0c59-1208-6e5395496...@armadeus.com/

Then please append the following changes to this patch to keep current 
code working:

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 1355b2c27932..2a33602372d9 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -692,7 +692,9 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)

     dsi->lanes = 4;
     dsi->format = MIPI_DSI_FMT_RGB888;
-   dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS;
+   dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS
+   | MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP
+   | MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;

     ctx->supplies[0].supply = "vdd3";
     ctx->supplies[1].supply = "vci";
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index 3223a9d06a50..bb47dbfdd7ee 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -446,7 +446,8 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)

     dsi->lanes = 1;
    

Re: [PATCH v9 04/18] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags

[Marek Szyprowski]

Hi Jagan,

On 09.12.2022 16:23, Jagan Teki wrote:
> 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")
> Reviewed-by: Nicolas Boichat 
> Reported-by: Sébastien Szymanski 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v9:
> - none
>
>   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 e5b1540c4ae4..50a2a9ca88a9 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) {


Huh, this changes the logic in the driver! I've spent another half of 
the night trying to figure out why v8 and v9 doesn't work on all my 
Exynos boards with DSI panels again...

Please drop this patch from this series. If you want to get the Exynos 
DSI -> Samsung DSIM conversion merged, please focus on the core patches 
and don't add more random 'fixes' to each new version.

This change has to be discussed separately. The values written by the 
Exynos DSI driver to the registers ARE CORRECT and DSI panels work fine 
with such configuration. So either everything is correct, or these flags 
are reversed both in the Exynos DSI driver AND at least tested DSI 
panels (s6e8aa0, s6e3ha2, s6e63j0x03). I would need to check this in 
panel datasheets if I manage to get them.

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

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

On 12.12.2022 09:32, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>  wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> The existing drm panels and bridges in Exynos required host
>>> initialization during the first DSI command transfer even though
>>> the initialization was done before.
>>>
>>> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
>>> flag and triggers from host transfer.
>>>
>>> Do this exclusively for Exynos.
>>>
>>> Initial logic is derived from Marek Szyprowski changes.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> Signed-off-by: Jagan Teki 
>>> ---
>>> Changes from v9:
>>> - derived from v8
>>> - added comments
>>>
>>>drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>>>include/drm/bridge/samsung-dsim.h |  5 +++--
>>>2 files changed, 17 insertions(+), 3 deletions(-)
>> The following chunk is missing compared to v8:
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 6e9ad955ebd3..6a9403cb92ae 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>> *dsi, unsigned int flag)
>>   return 0;
>>
>>   samsung_dsim_reset(dsi);
>> -   samsung_dsim_enable_irq(dsi);
>> +
>> +   if (!(dsi->state & DSIM_STATE_INITIALIZED))
>> +   samsung_dsim_enable_irq(dsi);
> Is this really required? does it make sure that the IRQ does not enable twice?

That's what that check does. Without the 'if (!(dsi->state & 
DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first 
from pre_enable, then from the first transfer), what leads to a warning 
from irq core.

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

Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer

[Marek Szyprowski]

Hi Jagan,

On 09.12.2022 16:23, Jagan Teki wrote:
> The existing drm panels and bridges in Exynos required host
> initialization during the first DSI command transfer even though
> the initialization was done before.
>
> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
> flag and triggers from host transfer.
>
> Do this exclusively for Exynos.
>
> Initial logic is derived from Marek Szyprowski changes.
>
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Jagan Teki 
> ---
> Changes from v9:
> - derived from v8
> - added comments
>
>   drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
>   include/drm/bridge/samsung-dsim.h |  5 +++--
>   2 files changed, 17 insertions(+), 3 deletions(-)

The following chunk is missing compared to v8:

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 6e9ad955ebd3..6a9403cb92ae 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim 
*dsi, unsigned int 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);


> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 2e15d753fdd0..ec3ab679afd9 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1254,6 +1254,19 @@ static int samsung_dsim_init(struct samsung_dsim *dsi, 
> unsigned int flag)
>   {
>   const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>   
> + /*
> +  * FIXME:
> +  * The existing drm panels and bridges in Exynos required host
> +  * initialization during the first DSI command transfer even though
> +  * the initialization was done before.
> +  *
> +  * This host reinitialization is handled via DSIM_STATE_REINITIALIZED
> +  * flag and triggers from host transfer. Do this exclusively for Exynos.
> +  */
> + if ((dsi->plat_data->hw_type == SAMSUNG_DSIM_TYPE_IMX8MM) &&
> + dsi->state & DSIM_STATE_REINITIALIZED)
> + return 0;
> +
>   if (dsi->state & flag)
>   return 0;
>   
> @@ -1467,7 +1480,7 @@ static ssize_t samsung_dsim_host_transfer(struct 
> mipi_dsi_host *host,
>   if (!(dsi->state & DSIM_STATE_ENABLED))
>   return -EINVAL;
>   
> - ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> + ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
>   if (ret)
>   return ret;
>   
> 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,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R 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
>  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
>>>>  wrote:
>>>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>>>> Hi Marek
>>>>>>
>>>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut  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  wrote:
>>>>>>>>>> On 11/23/22 21:09, Jagan Teki wrote:
>>>>>>>>>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut  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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>

Re: [v2,5/6] drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer

[Marek Szyprowski]

On 17.11.2022 18:21, Marek Szyprowski wrote:
> On 17.11.2022 17:07, Thomas Zimmermann wrote:
>> Am 17.11.22 um 13:57 schrieb Marek Szyprowski:
>>> On 15.11.2022 12:58, Thomas Zimmermann wrote:
>>>> Schedule the deferred-I/O worker instead of the damage worker after
>>>> writing to the fbdev framebuffer. The deferred-I/O worker then 
>>>> performs
>>>> the dirty-fb update. The fbdev emulation will initialize deferred I/O
>>>> for all drivers that require damage updates. It is therefore a valid
>>>> assumption that the deferred-I/O worker is present.
>>>>
>>>> It would be possible to perform the damage handling directly from 
>>>> within
>>>> the write operation. But doing this could increase the overhead of the
>>>> write or interfere with a concurrently scheduled deferred-I/O worker.
>>>> Instead, scheduling the deferred-I/O worker with its regular delay of
>>>> 50 ms removes load off the write operation and allows the deferred-I/O
>>>> worker to handle multiple write operations that arrived during the 
>>>> delay
>>>> time window.
>>>>
>>>> v2:
>>>> * keep drm_fb_helper_damage() (Daniel)
>>>> * use fb_deferred_io_schedule_flush() (Daniel)
>>>> * clarify comments (Daniel)
>>>>
>>>> Signed-off-by: Thomas Zimmermann 
>>>> Reviewed-by: Daniel Vetter 
>>>
>>> This patch, merged into today's linux-next as commit 7f5cc4a3e5e4
>>> ("drm/fb-helper: Schedule deferred-I/O worker after writing to
>>> framebuffer"), triggers a following warning on Raspberry Pi 3 & 4 as
>>> well as all Amlogic Meson G12A/B based boards:
>>>
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 220 at drivers/video/fbdev/core/fb_defio.c:340
>>
>> Thank you so much for reporting. That line should never be executed 
>> with vc4 et al.
>>
>> If you have the time, could you please try the attached patch and 
>> report the results. Thanks a lot.
>
> This fixes the issue observed on my Raspberry Pi 3/4 and Amlogic Meson 
> based boards. Feel free to add:
>
> Tested-by: Marek Szyprowski 

Gentle ping. This issue is not fixed in linux-next.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R 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  wrote:
>> On 11/23/22 21:09, Jagan Teki wrote:
>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut  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 
>>>>>>> Signed-off-by: Jagan Teki 
>>>>>>> ---
>>>>>>>  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
>

Re: [v2,5/6] drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer

[Marek Szyprowski]

On 17.11.2022 17:07, Thomas Zimmermann wrote:
> Am 17.11.22 um 13:57 schrieb Marek Szyprowski:
>> On 15.11.2022 12:58, Thomas Zimmermann wrote:
>>> Schedule the deferred-I/O worker instead of the damage worker after
>>> writing to the fbdev framebuffer. The deferred-I/O worker then performs
>>> the dirty-fb update. The fbdev emulation will initialize deferred I/O
>>> for all drivers that require damage updates. It is therefore a valid
>>> assumption that the deferred-I/O worker is present.
>>>
>>> It would be possible to perform the damage handling directly from 
>>> within
>>> the write operation. But doing this could increase the overhead of the
>>> write or interfere with a concurrently scheduled deferred-I/O worker.
>>> Instead, scheduling the deferred-I/O worker with its regular delay of
>>> 50 ms removes load off the write operation and allows the deferred-I/O
>>> worker to handle multiple write operations that arrived during the 
>>> delay
>>> time window.
>>>
>>> v2:
>>> * keep drm_fb_helper_damage() (Daniel)
>>> * use fb_deferred_io_schedule_flush() (Daniel)
>>> * clarify comments (Daniel)
>>>
>>> Signed-off-by: Thomas Zimmermann 
>>> Reviewed-by: Daniel Vetter 
>>
>> This patch, merged into today's linux-next as commit 7f5cc4a3e5e4
>> ("drm/fb-helper: Schedule deferred-I/O worker after writing to
>> framebuffer"), triggers a following warning on Raspberry Pi 3 & 4 as
>> well as all Amlogic Meson G12A/B based boards:
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID: 220 at drivers/video/fbdev/core/fb_defio.c:340
>
> Thank you so much for reporting. That line should never be executed 
> with vc4 et al.
>
> If you have the time, could you please try the attached patch and 
> report the results. Thanks a lot.

This fixes the issue observed on my Raspberry Pi 3/4 and Amlogic Meson 
based boards. Feel free to add:

Tested-by: Marek Szyprowski 

Best regards

-- 
Marek Szyprowski, PhD
Samsung R 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 
>> Signed-off-by: Jagan Teki 
>> ---
>>   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 Institute Poland

Re: [v2,5/6] drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer

[Marek Szyprowski]

lper->dev;
> + struct fb_info *info = helper->info;
> +
>   drm_fb_helper_add_damage_clip(helper, x, y, width, height);
>   
> - schedule_work(>damage_work);
> + /*
> +  * The current fbdev emulation only flushes buffers if a damage
> +  * update is necessary. And we can assume that deferred I/O has
> +  * been enabled as damage updates require deferred I/O for mmap.
> +  */
> + fb_deferred_io_schedule_flush(info);
>   }
>   
>   /*
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index c730253ab85ce..dec678f72a42f 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -332,3 +332,19 @@ void fb_deferred_io_cleanup(struct fb_info *info)
>   mutex_destroy(>lock);
>   }
>   EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> +
> +void fb_deferred_io_schedule_flush(struct fb_info *info)
> +{
> + struct fb_deferred_io *fbdefio = info->fbdefio;
> +
> + if (WARN_ON_ONCE(!fbdefio))
> + return; /* bug in driver logic */
> +
> + /*
> +  * There's no requirement from callers to schedule the
> +  * flush immediately. Rather schedule the worker with a
> +  * delay and let a few more writes pile up.
> +  */
> + schedule_delayed_work(>deferred_work, fbdefio->delay);
> +}
> +EXPORT_SYMBOL_GPL(fb_deferred_io_schedule_flush);
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index bcb8658f5b64d..172f271520c78 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -663,6 +663,7 @@ extern void fb_deferred_io_open(struct fb_info *info,
>   struct inode *inode,
>   struct file *file);
>   extern void fb_deferred_io_cleanup(struct fb_info *info);
> +extern void fb_deferred_io_schedule_flush(struct fb_info *info);
>   extern int fb_deferred_io_fsync(struct file *file, loff_t start,
>   loff_t end, int datasync);
>   

Best regards
-- 
Marek Szyprowski, PhD
Samsung R 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  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 
>>>>>> ---
>>>>>>     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 
>>>>>>     #include 
>>>>>>     #include 
>>>>>> +#include 
>>>>>>     #include 
>>>>>>     #include 
>>>>>>
>>>>>> @@ -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,
>>>>>

Re: [PATCH 1/1] drm/shmem: Dual licence the files as GPL-2 and MIT

[Marek Szyprowski]

On 12.11.2022 20:42, Robert Swindells wrote:
> Contributors to these files are:
>
> Noralf Trønnes 
> Liu Zixian 
> Dave Airlie 
> Thomas Zimmermann 
> Lucas De Marchi 
> Gerd Hoffmann 
> Rob Herring 
> Jakub Kicinski 
> Marcel Ziswiler 
> Stephen Rothwell 
> Daniel Vetter 
> Cai Huoqing 
> Neil Roberts 
> Marek Szyprowski 
> Emil Velikov 
> Sam Ravnborg 
> Boris Brezillon 
> Dan Carpenter 
>
> Signed-off-by: Robert Swindells 


Acked-by: Marek Szyprowski 


Best regards
-- 
Marek Szyprowski, PhD
Samsung R 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  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 
>>>> ---
>>>>    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 
>>>>    #include 
>>>>    #include 
>>>> +#include 
>>>>    #include 
>>>>    #include 
>>>>
>>>> @@ -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 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
>  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
>>>>  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 
>>>>>>> ---
>>>>>>> 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 
>>>>>>> #include 
>>>>>>> #include 
>>>>>>> +#include 
>>>>>>> #include 
>>>>>>> #include 
>>>>>>> @@ -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,
>>>>>>&g

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
>  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 
>>>> ---
>>>>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 
>>>>#include 
>>>>#include 
>>>> +#include 
>>>>#include 
>>>>#include 
>>>>@@ -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

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 
>> ---
>>   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 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   @@ -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 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 
> ---
>   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 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   
> @@ -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 Institute Poland

Re: [PATCH v7 01/10] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi,

On 17.10.2022 10:48, Marek Vasut wrote:
> On 10/17/22 09:43, Jagan Teki wrote:
>> On Mon, Oct 17, 2022 at 12:49 PM Marek Vasut  wrote:
>>> On 10/17/22 04:49, Jagan Teki wrote:
>>>> On Sun, Oct 16, 2022 at 3:16 AM Marek Vasut  wrote:
>>>>>
>>>>> On 10/5/22 17:13, Jagan Teki wrote:
>>>>>> 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.
>>>>>
>>>>> Maybe the Subject should say "Split ... driver" or "Move ... 
>>>>> driver" ,
>>>>> since it is not adding a new driver here ?
>>>>
>>>> Though it is not added a completely new driver, it is adding more
>>>> infrastructure platform code to be compatible with both Exynos and
>>>> i.MX8M. This is the prime reason for adding that commit head and
>>>> explaining the same in the commit body.
>>>
>>> Diffstat looks like this:
>>>
>>>    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(-)
>>>
>>> Looks to me like most of the code is just moved from existing driver in
>>> this patch.
>>
>> Yeah, as I explained (from commit) it is moved, updated, and written
>> the plat code. How about this head?
>>
>> "drm: bridge: Add Samsung DSIM bridge (Split from exynos_drm_dsi)"
>
> I disagree with the "Add" part of the Subject, but I'll wait for 
> others' opinion here.

Maybe something like a "Generalize Exynos-DSI DRM driver into a generic 
Samsung DSIM bridge"?

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

Re: [PATCH v7 00/10] drm: bridge: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

Hi Jagan,

On 05.10.2022 17:12, 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.MX8MM DSI devices.
>
> 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:   Samsung DSIM bridge
>
> Patch 0002:   PHY optional
>
> Patch 0003:   OF-graph or Child node lookup
>
> Patch 0004:   DSI host initialization
>
> Patch 0005:   atomic check
>
> Patch 0006:   PMS_P offset via plat data
>
> Patch 0007:   atomic_get_input_bus_fmts
>
> Patch 0008:   input_bus_flags
>
> Patch 0009:   document fsl,imx8mm-mipi-dsim
>
> Patch 0010:   add i.MX8MM DSIM support
>
> Tested in Engicam i.Core MX8M Mini SoM.

This finally doesn't break Exynos DSI. :) Feel free to add:

Acked-by: Marek Szyprowski

Tested-by: Marek Szyprowski

The next step would be to merge Dave's patchset and remove the hacks 
added here and there. Otherwise we will end up adding even more hacks soon.

> Repo:
> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v7
>
> Any inputs?
> Jagan.
>
> Jagan Teki (10):
>drm: bridge: Add Samsung DSIM bridge driver
>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.MX8MM support
>drm: bridge: samsung-dsim: Add i.MX8MM support
>
>   .../bindings/display/exynos/exynos_dsim.txt   |1 +
>   MAINTAINERS   |9 +
>   drivers/gpu/drm/bridge/Kconfig|   12 +
>   drivers/gpu/drm/bridge/Makefile   |1 +
>   drivers/gpu/drm/bridge/samsung-dsim.c | 1856 +
>   drivers/gpu/drm/exynos/Kconfig|1 +
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 1766 +---
>   include/drm/bridge/samsung-dsim.h |  115 +
>   8 files changed, 2108 insertions(+), 1653 deletions(-)
>   create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>   create mode 100644 include/drm/bridge/samsung-dsim.h
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v5 06/11] drm: bridge: samsung-dsim: Add atomic_check

[Marek Szyprowski]

Hi Jagan,

On 16.09.2022 20:17, Jagan Teki wrote:
> 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."
>
> 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.
>
> 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 
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 26 ++
>   include/drm/bridge/samsung-dsim.h |  1 +
>   2 files changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 6d524338d4ff..8abf89326424 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1315,6 +1315,31 @@ 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 = _state->adjusted_mode;
> +
> + if (dsi->plat_data->hw_type & SAMSUNG_DSIM_TYPE_IMX8MM) {

Again the above should be 'if (dsi->plat_data->hw_type == 
SAMSUNG_DSIM_TYPE_IMX8MM)', hw_type is not a bitmask.


> + /**
> +  * FIXME:
> +  * At least LCDIF + DSIM needs active low sync,
> +  * but 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.
> +  */
> + 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)
> @@ -1337,6 +1362,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,
> diff --git a/include/drm/bridge/samsung-dsim.h 
> b/include/drm/bridge/samsung-dsim.h
> index 57b27d75369e..0c5a905f3de7 100644
> --- a/include/drm/bridge/samsung-dsim.h
> +++ b/include/drm/bridge/samsung-dsim.h
> @@ -27,6 +27,7 @@ enum samsung_dsim_type {
>   SAMSUNG_DSIM_TYPE_EXYNOS5410,
>   SAMSUNG_DSIM_TYPE_EXYNOS5422,
>   SAMSUNG_DSIM_TYPE_EXYNOS5433,
> + SAMSUNG_DSIM_TYPE_IMX8MM,
>   SAMSUNG_DSIM_TYPE_COUNT,
>   };
>   

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

Re: [PATCH v6 01/10] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi Jagan,

On 01.10.2022 10:06, Jagan Teki wrote:
> 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.
>
> v6:
> * handle previous bridge pointer for exynos dsi

There are still issues, see my comments below.

> 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 
> Signed-off-by: Jagan Teki 
> ---
>   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 | 1769 ++-
>   include/drm/bridge/samsung-dsim.h   |  113 ++
>   7 files changed, 1955 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 
> +M:   Marek Szyprowski 
> +M:   Inki Dae  +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 
>   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_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v
>   obj-$(CONFIG_DRM_NXP_PTN346

Re: [PATCH v5 00/11] drm: bridge: Add Samsung MIPI DSIM bridge

[Marek Szyprowski]

On 16.09.2022 20:17, Jagan Teki wrote:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> Previous v4 can be available here [1], repo on linux-next [2] and
> Engicam i.Core MX8M Mini SoM boot log [3].
>
> The final bridge supports both the Exynos and i.MX8MM DSI devices.
>
> Changes for v3:
> * 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:   Restore proper bridge chain in exynos_dsi
>
> Patch 0002:   Samsung DSIM bridge
>
> Patch 0003:   PHY optional
>
> Patch 0004:   OF-graph or Child node lookup
>
> Patch 0005:   DSI host initialization
>
> Patch 0006:   atomic check
>
> Patch 0007:   PMS_P offset via plat data
>
> Patch 0008:   atomic_get_input_bus_fmts
>
> Patch 0009:   input_bus_flags
>
> Patch 0010:   document fsl,imx8mm-mipi-dsim
>
> Patch 0011:   add i.MX8MM DSIM support
>
> [3] 
> https://protect2.fireeye.com/v1/url?k=f5b98b61-94329e52-f5b8002e-000babff9bb7-1f9a3bf1da680bc2=1=efefced1-2052-43c5-834f-b50867c29e3c=https%3A%2F%2Fgist.github.com%2Fopenedev%2F22b2d63b30ade0ba55ab414a2f47aaf0
> [2] 
> https://protect2.fireeye.com/v1/url?k=02c0a3da-634bb6e9-02c12895-000babff9bb7-8ed3eab856890e56=1=efefced1-2052-43c5-834f-b50867c29e3c=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm-dsi-v5
> [1] 
> https://patchwork.kernel.org/project/dri-devel/cover/20220829184031.1863663-1-ja...@amarulasolutions.com/
>
> Any inputs?

Just to make it clear. Like I already pointed [1], this version breaks 
Exynos boards with DSI panels. Either the patch #1 has to be dropped to 
keep the current hack (the current code changes the bridge order to 
force proper pre_enable calls) or the Dave's patches have to be applied 
first [3].

[1] 
https://lore.kernel.org/all/5baf2a71-3d1e-0f25-9b0e-2af98684f...@samsung.com/

[2] 
https://lore.kernel.org/all/cover.1646406653.git.dave.steven...@raspberrypi.com/

[3] https://github.com/mszyprow/linux/tree/v6.0-dsi-v4-reworked


> Jagan.
>
> Jagan Teki (10):
>drm: bridge: Add Samsung DSIM bridge driver
>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.MX8MM support
>drm: bridge: samsung-dsim: Add i.MX8MM support
>
> Marek Szyprowski (1):
>drm: exynos: dsi: Restore proper bridge chain order
>
>   .../bindings/display/exynos/exynos_dsim.txt   |1 +
>   MAINTAINERS   |9 +
>   drivers/gpu/drm/bridge/Kconfig|   12 +
>   drivers/gpu/drm/bridge/Makefile   |1 +
>   drivers/gpu/drm/bridge/samsung-dsim.c | 1840 +
>   drivers/gpu/drm/exynos/Kconfig|1 +
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c   | 1766 +---
>   include/drm/bridge/samsung-dsim.h |  115 ++
>   8 files changed, 2092 insertions(+), 1653 deletions(-)
>   create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>   create mode 100644 include/drm/bridge/samsung-dsim.h
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi Jagan,

On 16.09.2022 12:21, Jagan Teki wrote:
> On Fri, Sep 16, 2022 at 1:58 PM Marek Szyprowski
>  wrote:
>> On 14.09.2022 11:39, Jagan Teki wrote:
>>> On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
>>>  wrote:
>>>> On 13.09.2022 19:29, Jagan Teki wrote:
>>>>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
>>>>>  wrote:
>>>>>> On 06.09.2022 21:07, Jagan Teki wrote:
>>>>>>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski
>>>>>>>  wrote:
>>>>>>>> On 02.09.2022 12:47, Marek Szyprowski wrote:
>>>>>>>>> On 29.08.2022 20:40, Jagan Teki wrote:
>>>>>>>>>> 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 and keep maintaining the exynos_drm_dsi.c code as 
>>>>>>>>>> platform-specific
>>>>>>>>>> glue code and samsung-dsim.c as a common bridge driver code.
>>>>>>>>>>
>>>>>>>>>> - Exynos specific glue code is exynos specific te_irq, host_attach, 
>>>>>>>>>> and
>>>>>>>>>>detach code along with conventional component_ops.
>>>>>>>>>>
>>>>>>>>>> - Samsung DSIM is a bridge driver which is common across all
>>>>>>>>>> platforms and
>>>>>>>>>>the respective platform-specific glue will initialize at the 
>>>>>>>>>> end
>>>>>>>>>> of the
>>>>>>>>>>probe. The platform-specific operations and other glue calls 
>>>>>>>>>> will
>>>>>>>>>> invoke
>>>>>>>>>>on associate code areas.
>>>>>>>>>>
>>>>>>>>>> v4:
>>>>>>>>>> * include Inki Dae in MAINTAINERS
>>>>>>>>>> * remove dsi_driver probe in exynos_drm_drv to support multi-arch 
>>>>>>>>>> build
>>>>>>>>> This breaks Exynos DRM completely as the Exynos DRM driver is not able
>>>>>>>>> to wait until the DSI driver is probed and registered as component.
>>>>>>>>>
>>>>>>>>> I will show how to rework this the way it is done in
>>>>>>>>> drivers/gpu/drm/exynos/exynos_dp.c and
>>>>>>>>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon...
>>>>>>>> I've finally had some time to implement such approach, see
>>>>>>>> https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked
>>>>>>>>
>>>>>>>> If you want me to send the patches against your v4 patchset, let me
>>>>>>>> know, but imho my changes are much more readable after squashing to the
>>>>>>>> original patches.
>>>>>>>>
>>>>>>>> Now the driver is fully multi-arch safe and ready for further
>>>>>>>> extensions. I've removed the weak functions, reworked the way the
>>>>>>>> plat_data is used (dropped the patch related to it) and restored
>>>>>>>> exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel
>>>>>>>> free to resend the above as v5 after testing on your hardware. At least
>>>>>>>> it properly works now on all Exynos boards I have, both compiled into
>>>>>>>> the kernel or as modules.
>>>>>>> Thanks. I've seen the repo added on top of Dave patches - does it 

Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi Jagan,

On 14.09.2022 11:39, Jagan Teki wrote:
> On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
>  wrote:
>> On 13.09.2022 19:29, Jagan Teki wrote:
>>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
>>>  wrote:
>>>> On 06.09.2022 21:07, Jagan Teki wrote:
>>>>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski
>>>>>  wrote:
>>>>>> On 02.09.2022 12:47, Marek Szyprowski wrote:
>>>>>>> On 29.08.2022 20:40, Jagan Teki wrote:
>>>>>>>> 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 and keep maintaining the exynos_drm_dsi.c code as 
>>>>>>>> platform-specific
>>>>>>>> glue code and samsung-dsim.c as a common bridge driver code.
>>>>>>>>
>>>>>>>> - Exynos specific glue code is exynos specific te_irq, host_attach, and
>>>>>>>>   detach code along with conventional component_ops.
>>>>>>>>
>>>>>>>> - Samsung DSIM is a bridge driver which is common across all
>>>>>>>> platforms and
>>>>>>>>   the respective platform-specific glue will initialize at the end
>>>>>>>> of the
>>>>>>>>   probe. The platform-specific operations and other glue calls will
>>>>>>>> invoke
>>>>>>>>   on associate code areas.
>>>>>>>>
>>>>>>>> v4:
>>>>>>>> * include Inki Dae in MAINTAINERS
>>>>>>>> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
>>>>>>> This breaks Exynos DRM completely as the Exynos DRM driver is not able
>>>>>>> to wait until the DSI driver is probed and registered as component.
>>>>>>>
>>>>>>> I will show how to rework this the way it is done in
>>>>>>> drivers/gpu/drm/exynos/exynos_dp.c and
>>>>>>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon...
>>>>>> I've finally had some time to implement such approach, see
>>>>>> https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked
>>>>>>
>>>>>> If you want me to send the patches against your v4 patchset, let me
>>>>>> know, but imho my changes are much more readable after squashing to the
>>>>>> original patches.
>>>>>>
>>>>>> Now the driver is fully multi-arch safe and ready for further
>>>>>> extensions. I've removed the weak functions, reworked the way the
>>>>>> plat_data is used (dropped the patch related to it) and restored
>>>>>> exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel
>>>>>> free to resend the above as v5 after testing on your hardware. At least
>>>>>> it properly works now on all Exynos boards I have, both compiled into
>>>>>> the kernel or as modules.
>>>>> Thanks. I've seen the repo added on top of Dave patches - does it mean
>>>>> these depends on Dave changes as well?
>>>> Yes and no. My rework doesn't change anything with this dependency. It
>>>> comes from my patch "drm: exynos: dsi: Restore proper bridge chain
>>>> order" already included in your series (patch #1). Without it exynos-dsi
>>>> driver hacks the list of bridges to ensure the order of pre_enable calls
>>>> needed for proper operation. This works somehow with DSI panels on my
>>>> test systems, but it has been reported that it doesn't work with a bit
>>>> more complex display pipelines. Only that patch depends on the Dave's
>>>> patches. If you remove it, you would need to adjust the code in the
>>>> exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be
>>>> better to keep it and merge Dave's patches together with dsi changes, as
>>>> they are the first real client of it.
>>> I think the Dave patches especially "drm/bridge: Introduce
>>> pre_enable_upstream_first to alter bridge init order" seems not 100%
>>> relevant to this series as they affect bridge chain call flow
>>> globally. Having a separate series for that makes sense to me. I'm
>>> sending v5 by excluding those parts.
>> If so then drop the "drm: exynos: dsi: Restore proper bridge chain
>> order" patch and adjust code respectively in samsung-dsim.c. Without the
>> Dave's patches, that one doesn't make sense.
> Doesn't it break Exynos?

No it won't. Lack of the "drm: exynos: dsi: Restore proper bridge chain 
order" patch doesn't change much against the current state of the driver.

Here is my rework of your v4 patchset without the mentioned patch and 
Dave's patches:

https://github.com/mszyprow/linux/tree/v6.0-dsi-v4-reworked-minimal

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

Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi Jagan,

On 13.09.2022 19:29, Jagan Teki wrote:
> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
>  wrote:
>> On 06.09.2022 21:07, Jagan Teki wrote:
>>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski
>>>  wrote:
>>>> On 02.09.2022 12:47, Marek Szyprowski wrote:
>>>>> On 29.08.2022 20:40, Jagan Teki wrote:
>>>>>> 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 and keep maintaining the exynos_drm_dsi.c code as platform-specific
>>>>>> glue code and samsung-dsim.c as a common bridge driver code.
>>>>>>
>>>>>> - Exynos specific glue code is exynos specific te_irq, host_attach, and
>>>>>>  detach code along with conventional component_ops.
>>>>>>
>>>>>> - Samsung DSIM is a bridge driver which is common across all
>>>>>> platforms and
>>>>>>  the respective platform-specific glue will initialize at the end
>>>>>> of the
>>>>>>  probe. The platform-specific operations and other glue calls will
>>>>>> invoke
>>>>>>  on associate code areas.
>>>>>>
>>>>>> v4:
>>>>>> * include Inki Dae in MAINTAINERS
>>>>>> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
>>>>> This breaks Exynos DRM completely as the Exynos DRM driver is not able
>>>>> to wait until the DSI driver is probed and registered as component.
>>>>>
>>>>> I will show how to rework this the way it is done in
>>>>> drivers/gpu/drm/exynos/exynos_dp.c and
>>>>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon...
>>>> I've finally had some time to implement such approach, see
>>>> https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked
>>>>
>>>> If you want me to send the patches against your v4 patchset, let me
>>>> know, but imho my changes are much more readable after squashing to the
>>>> original patches.
>>>>
>>>> Now the driver is fully multi-arch safe and ready for further
>>>> extensions. I've removed the weak functions, reworked the way the
>>>> plat_data is used (dropped the patch related to it) and restored
>>>> exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel
>>>> free to resend the above as v5 after testing on your hardware. At least
>>>> it properly works now on all Exynos boards I have, both compiled into
>>>> the kernel or as modules.
>>> Thanks. I've seen the repo added on top of Dave patches - does it mean
>>> these depends on Dave changes as well?
>> Yes and no. My rework doesn't change anything with this dependency. It
>> comes from my patch "drm: exynos: dsi: Restore proper bridge chain
>> order" already included in your series (patch #1). Without it exynos-dsi
>> driver hacks the list of bridges to ensure the order of pre_enable calls
>> needed for proper operation. This works somehow with DSI panels on my
>> test systems, but it has been reported that it doesn't work with a bit
>> more complex display pipelines. Only that patch depends on the Dave's
>> patches. If you remove it, you would need to adjust the code in the
>> exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be
>> better to keep it and merge Dave's patches together with dsi changes, as
>> they are the first real client of it.
> I think the Dave patches especially "drm/bridge: Introduce
> pre_enable_upstream_first to alter bridge init order" seems not 100%
> relevant to this series as they affect bridge chain call flow
> globally. Having a separate series for that makes sense to me. I'm
> sending v5 by excluding those parts.

If so then drop the "drm: exynos: dsi: Restore proper bridge chain 
order" patch and adjust code respectively in samsung-dsim.c. Without the 
Dave's patches, that one doesn't make sense.

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

Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi Jagan,

On 06.09.2022 21:07, Jagan Teki wrote:
> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski
>  wrote:
>> On 02.09.2022 12:47, Marek Szyprowski wrote:
>>> On 29.08.2022 20:40, Jagan Teki wrote:
>>>> 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 and keep maintaining the exynos_drm_dsi.c code as platform-specific
>>>> glue code and samsung-dsim.c as a common bridge driver code.
>>>>
>>>> - Exynos specific glue code is exynos specific te_irq, host_attach, and
>>>> detach code along with conventional component_ops.
>>>>
>>>> - Samsung DSIM is a bridge driver which is common across all
>>>> platforms and
>>>> the respective platform-specific glue will initialize at the end
>>>> of the
>>>> probe. The platform-specific operations and other glue calls will
>>>> invoke
>>>> on associate code areas.
>>>>
>>>> v4:
>>>> * include Inki Dae in MAINTAINERS
>>>> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
>>> This breaks Exynos DRM completely as the Exynos DRM driver is not able
>>> to wait until the DSI driver is probed and registered as component.
>>>
>>> I will show how to rework this the way it is done in
>>> drivers/gpu/drm/exynos/exynos_dp.c and
>>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon...
>> I've finally had some time to implement such approach, see
>> https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375=1=489b94d4-84fb-408e-b679-a8d27acf2930=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked
>>
>> If you want me to send the patches against your v4 patchset, let me
>> know, but imho my changes are much more readable after squashing to the
>> original patches.
>>
>> Now the driver is fully multi-arch safe and ready for further
>> extensions. I've removed the weak functions, reworked the way the
>> plat_data is used (dropped the patch related to it) and restored
>> exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel
>> free to resend the above as v5 after testing on your hardware. At least
>> it properly works now on all Exynos boards I have, both compiled into
>> the kernel or as modules.
> Thanks. I've seen the repo added on top of Dave patches - does it mean
> these depends on Dave changes as well?

Yes and no. My rework doesn't change anything with this dependency. It 
comes from my patch "drm: exynos: dsi: Restore proper bridge chain 
order" already included in your series (patch #1). Without it exynos-dsi 
driver hacks the list of bridges to ensure the order of pre_enable calls 
needed for proper operation. This works somehow with DSI panels on my 
test systems, but it has been reported that it doesn't work with a bit 
more complex display pipelines. Only that patch depends on the Dave's 
patches. If you remove it, you would need to adjust the code in the 
exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be 
better to keep it and merge Dave's patches together with dsi changes, as 
they are the first real client of it.

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

Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

Hi All,

On 02.09.2022 12:47, Marek Szyprowski wrote:
> On 29.08.2022 20:40, Jagan Teki wrote:
>> 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 and keep maintaining the exynos_drm_dsi.c code as platform-specific
>> glue code and samsung-dsim.c as a common bridge driver code.
>>
>> - Exynos specific glue code is exynos specific te_irq, host_attach, and
>>    detach code along with conventional component_ops.
>>
>> - Samsung DSIM is a bridge driver which is common across all 
>> platforms and
>>    the respective platform-specific glue will initialize at the end 
>> of the
>>    probe. The platform-specific operations and other glue calls will 
>> invoke
>>    on associate code areas.
>>
>> v4:
>> * include Inki Dae in MAINTAINERS
>> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build
>
> This breaks Exynos DRM completely as the Exynos DRM driver is not able 
> to wait until the DSI driver is probed and registered as component.
>
> I will show how to rework this the way it is done in 
> drivers/gpu/drm/exynos/exynos_dp.c and 
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon...

I've finally had some time to implement such approach, see 
https://github.com/mszyprow/linux/tree/v6.0-dsi-v4-reworked

If you want me to send the patches against your v4 patchset, let me 
know, but imho my changes are much more readable after squashing to the 
original patches.

Now the driver is fully multi-arch safe and ready for further 
extensions. I've removed the weak functions, reworked the way the 
plat_data is used (dropped the patch related to it) and restored 
exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel 
free to resend the above as v5 after testing on your hardware. At least 
it properly works now on all Exynos boards I have, both compiled into 
the kernel or as modules.

>
>> 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 
>> Signed-off-by: Jagan Teki 
>> ---
>>   MAINTAINERS |    9 +
>>   drivers/gpu/drm/bridge/Kconfig  |   12 +
>>   drivers/gpu/drm/bridge/Makefile |    1 +
>>   drivers/gpu/drm/bridge/samsung-dsim.c   | 1686 ++
>>   drivers/gpu/drm/exynos/Kconfig  |    1 +
>>   drivers/gpu/drm/exynos/exynos_drm_drv.c |    3 -
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h |    1 -
>>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1715 +--
>>   include/drm/bridge/samsung-dsim.h   |   99 ++
>>   9 files changed, 1868 insertions(+), 1659 deletions(-)
>>   create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>>   create mode 100644 include/drm/bridge/samsung-dsim.h
>>
>> ...
>
> Best regards

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

Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver

[Marek Szyprowski]

On 29.08.2022 20:40, Jagan Teki wrote:
> 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 and keep maintaining the exynos_drm_dsi.c code as platform-specific
> glue code and samsung-dsim.c as a common bridge driver code.
>
> - Exynos specific glue code is exynos specific te_irq, host_attach, and
>detach code along with conventional component_ops.
>
> - Samsung DSIM is a bridge driver which is common across all platforms and
>the respective platform-specific glue will initialize at the end of the
>probe. The platform-specific operations and other glue calls will invoke
>on associate code areas.
>
> v4:
> * include Inki Dae in MAINTAINERS
> * remove dsi_driver probe in exynos_drm_drv to support multi-arch build

This breaks Exynos DRM completely as the Exynos DRM driver is not able 
to wait until the DSI driver is probed and registered as component.

I will show how to rework this the way it is done in 
drivers/gpu/drm/exynos/exynos_dp.c and 
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon...

> 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 
> Signed-off-by: Jagan Teki 
> ---
>   MAINTAINERS |9 +
>   drivers/gpu/drm/bridge/Kconfig  |   12 +
>   drivers/gpu/drm/bridge/Makefile |1 +
>   drivers/gpu/drm/bridge/samsung-dsim.c   | 1686 ++
>   drivers/gpu/drm/exynos/Kconfig  |1 +
>   drivers/gpu/drm/exynos/exynos_drm_drv.c |3 -
>   drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1715 +--
>   include/drm/bridge/samsung-dsim.h   |   99 ++
>   9 files changed, 1868 insertions(+), 1659 deletions(-)
>   create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>   create mode 100644 include/drm/bridge/samsung-dsim.h
>
> ...

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

Re: [PATCH v3 06/13] drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable()

[Marek Szyprowski]

On 20.07.2022 17:52, Jagan Teki wrote:
> Host transfer() in DSI master will invoke only when the DSI commands
> are sent from DSI devices like DSI Panel or DSI bridges and this
> host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
>
> Handling DSI host initialization in transfer calls misses the
> controller setup for I2C configured DSI bridges.
>
> This patch adds the DSI initialization from transfer to bridge
> pre_enable as the bridge pre_enable API is invoked by core as
> it is common across all classes of DSI device drivers.

This is still problematic in case of Exynos. Without a workaround like this

https://github.com/mszyprow/linux/commit/11bbfc61272da9610dd5c574bb8ef838dc150961

the display on the all real DSI panels on my Exynos based boards is broken.


>
> v3:
> * none
>
> v2:
> * check initialized state in samsung_dsim_init
>
> v1:
> * keep DSI init in host transfer
>
> Signed-off-by: Jagan Teki 
> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
>   1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9b74a3f98a17..b07909a52f2d 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1258,6 +1258,9 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   {
>   const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>   
> + if (dsi->state & DSIM_STATE_INITIALIZED)
> + return 0;
> +
>   samsung_dsim_reset(dsi);
>   samsung_dsim_enable_irq(dsi);
>   
> @@ -1270,6 +1273,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   samsung_dsim_set_phy_ctrl(dsi);
>   samsung_dsim_init_link(dsi);
>   
> + dsi->state |= DSIM_STATE_INITIALIZED;
> +
>   return 0;
>   }
>   
> @@ -1289,6 +1294,10 @@ static void samsung_dsim_atomic_pre_enable(struct 
> drm_bridge *bridge,
>   }
>   
>   dsi->state |= DSIM_STATE_ENABLED;
> +
> + ret = samsung_dsim_init(dsi);
> + if (ret)
> + return;
>   }
>   
>   static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> @@ -1464,12 +1473,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);
> + if (ret)
> + return ret;
>   
>   ret = mipi_dsi_create_packet(, msg);
>   if (ret < 0)

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

Re: [PATCH v3 08/13] drm: bridge: samsung-dsim: Add module init, exit

[Marek Szyprowski]

Hi Jagan,

On 20.07.2022 17:52, Jagan Teki wrote:
> Add module init and exit functions for the bridge to register
> and unregister dsi_driver.
>
> Exynos drm driver stack will register the platform_driver separately
> in the common of it's exynos_drm_drv.c including dsi_driver.
>
> Register again would return -EBUSY, so return 0 for such cases as
> dsi_driver is already registered.

I've already pointed that this is a bad style solution. It will also not 
work in the following cases:

1. exynos drm and samsung-dsim compiled as modules - samsung-dsim 
module, once loaded, will register the driver and exynos_drm won't be 
able to register the exynos_dsi.

2. multi-arch case - if one compiles a kernel (disto-style) with drivers 
for both supported architectures (exynos and imx) - in such case it will 
not work on imx, because exynos_drm driver will always register 
exynos_dsi driver first (even if the kernel is booted on non-exynos board).

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

Re: [PATCH v2 08/12] drm: bridge: samsung-dsim: Add atomic_check

[Marek Szyprowski]

On 13.06.2022 13:34, Jagan Teki wrote:
> On Mon, Jun 13, 2022 at 5:02 PM Marek Szyprowski
>  wrote:
>> On 13.06.2022 13:17, Jagan Teki wrote:
>>> On Wed, May 11, 2022 at 4:01 PM Andrzej Hajda  
>>> wrote:
>>>> On 04.05.2022 13:40, Jagan Teki wrote:
>>>>> Fixing up the mode flags is required in order to correlate the
>>>>> correct sync flags of the surrounding components in the chain
>>>>> to make sure the whole pipeline can work properly.
>>>>>
>>>>> So, handle the mode flags via bridge, atomic_check.
>>>>>
>>>>> v2:
>>>>> * none
>>>>>
>>>>> v1:
>>>>> * fix mode flags in atomic_check instead of mode_fixup
>>>>>
>>>>> Signed-off-by: Jagan Teki 
>>>>> ---
>>>>> drivers/gpu/drm/bridge/samsung-dsim.c | 14 ++
>>>>> 1 file changed, 14 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> index b618e52d0ee3..bd78cef890e4 100644
>>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>>>> @@ -1340,6 +1340,19 @@ 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 drm_display_mode *adjusted_mode = _state->adjusted_mode;
>>>>> +
>>>>> + adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | 
>>>>> DRM_MODE_FLAG_NVSYNC);
>>>>> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | 
>>>>> DRM_MODE_FLAG_PVSYNC);
>>>> 1. Shouldn't this be in mode_fixup callback?
>>> Possible to do it on mode_fixup, yes. if we want to do the same stuff
>>> on atomic API then atomic_check is the proper helper.
>>>
>>>> 2. Where this requirement comes from? As Marek says it breaks Samsung
>>>> platforms and is against DSIM specification[1]:
>>> At least the bridge chain starting from LCDIF+DSIM requires active high 
>>> sync.
>> Then please make this specific to the imx variant. The current version
>> breaks DSI operation on all Exynos based boards.
> But exynos trm also says the same?
>
> "45.2.2.1.2 RGB Interface
> Vsync, Hsync, and VDEN are active high signals"

Right, but You are forcing the negative sync signals:

adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);

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

Re: [PATCH v2 08/12] drm: bridge: samsung-dsim: Add atomic_check

[Marek Szyprowski]

On 13.06.2022 13:17, Jagan Teki wrote:
> On Wed, May 11, 2022 at 4:01 PM Andrzej Hajda  wrote:
>> On 04.05.2022 13:40, Jagan Teki wrote:
>>> Fixing up the mode flags is required in order to correlate the
>>> correct sync flags of the surrounding components in the chain
>>> to make sure the whole pipeline can work properly.
>>>
>>> So, handle the mode flags via bridge, atomic_check.
>>>
>>> v2:
>>> * none
>>>
>>> v1:
>>> * fix mode flags in atomic_check instead of mode_fixup
>>>
>>> Signed-off-by: Jagan Teki 
>>> ---
>>>drivers/gpu/drm/bridge/samsung-dsim.c | 14 ++
>>>1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index b618e52d0ee3..bd78cef890e4 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1340,6 +1340,19 @@ 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 drm_display_mode *adjusted_mode = _state->adjusted_mode;
>>> +
>>> + adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
>>> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | 
>>> DRM_MODE_FLAG_PVSYNC);
>>
>> 1. Shouldn't this be in mode_fixup callback?
> Possible to do it on mode_fixup, yes. if we want to do the same stuff
> on atomic API then atomic_check is the proper helper.
>
>> 2. Where this requirement comes from? As Marek says it breaks Samsung
>> platforms and is against DSIM specification[1]:
> At least the bridge chain starting from LCDIF+DSIM requires active high sync.

Then please make this specific to the imx variant. The current version 
breaks DSI operation on all Exynos based boards.

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

Re: [PATCH v2 05/12] drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable()

[Marek Szyprowski]

On 11.05.2022 17:02, Marek Szyprowski wrote:
> On 04.05.2022 13:40, Jagan Teki wrote:
>> Host transfer() in DSI master will invoke only when the DSI commands
>> are sent from DSI devices like DSI Panel or DSI bridges and this
>> host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
>>
>> Handling DSI host initialization in transfer calls misses the
>> controller setup for I2C configured DSI bridges.
>>
>> This patch adds the DSI initialization from transfer to bridge
>> pre_enable as the bridge pre_enable API is invoked by core as
>> it is common across all classes of DSI device drivers.
>>
>> v2:
>> * check initialized state in samsung_dsim_init
>>
>> v1:
>> * keep DSI init in host transfer
>>
>> Signed-off-by: Jagan Teki 
>
> This doesn't work with Exynos DSI and DSI panels. Here is a bit more 
> detailed explanation and my solution for this:
>
> https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5...@samsung.com/ 
>


I wonder if your modification works on i.MX8MM with a pure DSI-based 
panel/bridge. In your tree I only see that you have tested it with the 
i2c-controlled DSI-to-LVDS converter.


After the comments from the above mentioned thread I've reworked the 
initialization again. It looks that the ultimate solution for both 
worlds is to call samsung_dsim_init() twice, once in pre_enable, then 
before the first host_transfer, see 
https://github.com/mszyprow/linux/tree/v5.18-next-20220511-dsi-rework-v2

This way at least it works fine on all my Exynos based test boards.

>> ---
>>   drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
>>   1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index 60dc863113a0..b9361af5ef2d 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1259,6 +1259,9 @@ static int samsung_dsim_init(struct 
>> samsung_dsim *dsi)
>>   {
>>   const struct samsung_dsim_driver_data *driver_data = 
>> dsi->driver_data;
>>   +    if (dsi->state & DSIM_STATE_INITIALIZED)
>> +    return 0;
>> +
>>   samsung_dsim_reset(dsi);
>>   samsung_dsim_enable_irq(dsi);
>>   @@ -1271,6 +1274,8 @@ static int samsung_dsim_init(struct 
>> samsung_dsim *dsi)
>>   samsung_dsim_set_phy_ctrl(dsi);
>>   samsung_dsim_init_link(dsi);
>>   +    dsi->state |= DSIM_STATE_INITIALIZED;
>> +
>>   return 0;
>>   }
>>   @@ -1290,6 +1295,10 @@ static void 
>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>>   }
>>     dsi->state |= DSIM_STATE_ENABLED;
>> +
>> +    ret = samsung_dsim_init(dsi);
>> +    if (ret)
>> +    return;
>>   }
>>     static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
>> @@ -1464,12 +1473,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);
>> +    if (ret)
>> +    return ret;
>>     ret = mipi_dsi_create_packet(, msg);
>>   if (ret < 0)
>
> Best regards

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

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Marek Szyprowski]

Hi Dave,

On 11.05.2022 17:47, Dave Stevenson wrote:
> On Wed, 11 May 2022 at 15:58, Marek Szyprowski  
> wrote:
>> On 05.04.2022 13:43, Dave Stevenson wrote:
>>> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
>>>   wrote:
>>>> On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
>>>>   wrote:
>>>>> Hi All
>>>> A gentle ping on this series. Any comments on the approach?
>>>> Thanks.
>>> I realise the merge window has just closed and therefore folks have
>>> been busy, but no responses on this after a month?
>>>
>>> Do I give up and submit a patch to document that DSI is broken and no one 
>>> cares?
>> Thanks for pointing this patchset in the 'drm: bridge: Add Samsung MIPI
>> DSIM bridge' thread, otherwise I would miss it since I'm not involved
>> much in the DRM development.
>>
>> This resolves most of the issues in the Exynos DSI and its recent
>> conversion to the drm bridge framework. I've added the needed
>> prepare_upstream_first flags to the panels and everything works fine
>> without the bridge chain order hacks.
>>
>> Feel free to add:
>>
>> Tested-by: Marek Szyprowski 
> Thanks for testing it. I was almost at the stage of abandoning the patch set.
>
>> The only remaining thing to resolve is the moment of enabling DSI host.
>> The proper sequence is:
>>
>> 1. host power on, 2. device power on, 3. host init, 4. device init, 5.
>> video enable.
>>
>> #1 is done in dsi's pre_enable, #2 is done in panel's prepare. #3 was so
>> far done in the first host transfer call, which usually happens in
>> panel's prepare, then the #4 happens. Then video enable is done in the
>> enable callbacks.
> What's your definition of host power on and host init here? What state
> are you defining the DSI interface to be in after each operation?

Well, lets start from the point that I'm not a DSI specialist nor I'm 
not the exynos-dsi author. I just played a bit with the code trying to 
restore proper driver operation on the various Exynos based boards I have.

By the host/device power on I mean enabling their power regulators. By 
host init I mean executing the samsung_dsim_init() function, which 
basically sets the lp-11 state if I understand it right.


>> Jagan wants to move it to the dsi host pre_enable() to let it work with
>> DSI bridges controlled over different interfaces
>> (https://lore.kernel.org/all/20220504114021.33265-6-ja...@amarulasolutions.com/
>> ).
> I think I'm in agreement with Jagan.
> As documented in patch 4/4:
> + * A DSI host should keep the PHY powered down until the pre_enable
> operation is
> + * called. All lanes are in an undefined idle state up to this point, and it
> + * must not be assumed that it is LP-11.
> + * pre_enable should initialise the PHY, set the data lanes to LP-11, and the
> + * clock lane to either LP-11 or HS depending on the mode_flag
> + * %MIPI_DSI_CLOCK_NON_CONTINUOUS.

Right, this theory makes sense.

However Exynos DSI for some reasons did the host initialization in the 
first call of the samsung_dsim_host_transfer(). If I moved the host 
initialization to pre_enable (before powering the panel on), executing 
DSI commands failed (timeout). This issue happens on all boards I have 
access (Trats, Trats2, Arndale, TM2e), so this must be an issue with 
Exynos DSI host itself not related to particular panel/bridge.

If I call samsung_dsim_init() once again, before issuing the first DSI 
command, then everything works fine. I've tried to check which part of 
that function is needed to be executed before transferring the commands, 
but it turned out that the complete host reset and (re)configuration is 
necessary. It looks that the initialization will need to be done twice, 
first time in the pre_enable to satisfy Jagan case, then on the first 
dsi transfer to make it work with real DSI panels.

Here is a git repo with such change: 
https://github.com/mszyprow/linux/tree/v5.18-next-20220511-dsi-rework-v2


>> This however fails on Exynos with DSI panels, because when dsi's
>> pre_enable is called, the dsi device is not yet powered.
> Sorry, I'm not following what the issue is here? DSI lanes being at
> LP-11 when the sink isn't powered, so potential for leakage through
> the device?

I also have no idea why sending DSI commands fails if host is 
initialized without device being powered up first. Maybe powering it 
later causes some glitches on the lines? However it looks doing the 
initialization again on the first transfer is enough to fix it.

> In which case the device should NOT set pre_enable_upstream first, and
> the host gets powered up and down with each host_transfer call the
> device makes in pre_enable.

Doing the in

[PATCH] drm/exynos: mic: Rework initialization

[Marek Szyprowski]

Commit dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
moved Exynos MIC attaching from DSI to MIC driver. However the method
proposed there is incomplete and cannot really work. To properly attach
it to the bridge chain, access to the respective encoder is needed. The
Exynos MIC driver always attaches to the encoder created by the Exynos
DSI driver, so grab it via available helpers for getting access to the
CRTC and encoders. This also requires to change the order of driver
component binding to let DSI to be bound before MIC.

Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
Signed-off-by: Marek Szyprowski 
---
A few words of comment. The mentioned commit has my Tested-by tag and
indeed I gave it. However that time due to remote work and incorrect
camera configuration in the office I was not able to check if the board
really produces valid display, I only checked if it boots and reports
valid DRM structures to the userspace.

If possible, please merge this to the drm-misc-next together with the
rest of Exynos DSI to drm bridge rework patches.
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  6 ++--
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 +++--
 2 files changed, 15 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 424ea23eec32..16c539657f73 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -176,15 +176,15 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] 
= {
}, {
DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
DRM_COMPONENT_DRIVER
-   }, {
-   DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
-   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(dp_driver, CONFIG_DRM_EXYNOS_DP),
DRM_COMPONENT_DRIVER
}, {
DRV_PTR(dsi_driver, CONFIG_DRM_EXYNOS_DSI),
DRM_COMPONENT_DRIVER
+   }, {
+   DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
+   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(hdmi_driver, CONFIG_DRM_EXYNOS_HDMI),
DRM_COMPONENT_DRIVER
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 9e06f8e2a863..09ce28ee08d9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "exynos_drm_drv.h"
+#include "exynos_drm_crtc.h"
 
 /* Sysreg registers for MIC */
 #define DSD_CFG_MUX0x1004
@@ -100,9 +101,7 @@ struct exynos_mic {
 
bool i80_mode;
struct videomode vm;
-   struct drm_encoder *encoder;
struct drm_bridge bridge;
-   struct drm_bridge *next_bridge;
 
bool enabled;
 };
@@ -229,8 +228,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool 
enable)
writel(reg, mic->reg + MIC_OP);
 }
 
-static void mic_disable(struct drm_bridge *bridge) { }
-
 static void mic_post_disable(struct drm_bridge *bridge)
 {
struct exynos_mic *mic = bridge->driver_private;
@@ -297,34 +294,30 @@ static void mic_pre_enable(struct drm_bridge *bridge)
mutex_unlock(_mutex);
 }
 
-static void mic_enable(struct drm_bridge *bridge) { }
-
-static int mic_attach(struct drm_bridge *bridge,
- enum drm_bridge_attach_flags flags)
-{
-   struct exynos_mic *mic = bridge->driver_private;
-
-   return drm_bridge_attach(bridge->encoder, mic->next_bridge,
->bridge, flags);
-}
-
 static const struct drm_bridge_funcs mic_bridge_funcs = {
-   .disable = mic_disable,
.post_disable = mic_post_disable,
.mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
-   .enable = mic_enable,
-   .attach = mic_attach,
 };
 
 static int exynos_mic_bind(struct device *dev, struct device *master,
   void *data)
 {
struct exynos_mic *mic = dev_get_drvdata(dev);
+   struct drm_device *drm_dev = data;
+   struct exynos_drm_crtc *crtc = exynos_drm_crtc_get_by_type(drm_dev,
+  EXYNOS_DISPLAY_TYPE_LCD);
+   struct drm_encoder *e, *encoder = NULL;
+
+   drm_for_each_encoder(e, drm_dev)
+   if (e->possible_crtcs == drm_crtc_mask(>base))
+   encoder = e;
+   if (!encoder)
+   return -ENODEV;
 
mic->bridge.driver_private = mic;
 
-   return 0;
+   return drm_bridge_attach(encoder, >bridge, NULL, 0);
 }
 
 static void exynos_mic_unbind(struct device *dev, struct device *master,
@@ -388,7 +381,6 @@ static int exynos_mic_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct exynos_mic *mic;
-   struct device_node *remote;
s

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Marek Szyprowski]

On 11.05.2022 17:47, Marek Vasut wrote:
> On 5/11/22 16:58, Marek Szyprowski wrote:
>> Hi Dave,
>>
>> On 05.04.2022 13:43, Dave Stevenson wrote:
>>> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
>>>   wrote:
>>>> On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
>>>>   wrote:
>>>>> Hi All
>>>> A gentle ping on this series. Any comments on the approach?
>>>> Thanks.
>>> I realise the merge window has just closed and therefore folks have
>>> been busy, but no responses on this after a month?
>>>
>>> Do I give up and submit a patch to document that DSI is broken and 
>>> no one cares?
>>
>> Thanks for pointing this patchset in the 'drm: bridge: Add Samsung MIPI
>> DSIM bridge' thread, otherwise I would miss it since I'm not involved
>> much in the DRM development.
>>
>> This resolves most of the issues in the Exynos DSI and its recent
>> conversion to the drm bridge framework. I've added the needed
>> prepare_upstream_first flags to the panels and everything works fine
>> without the bridge chain order hacks.
>>
>> Feel free to add:
>>
>> Tested-by: Marek Szyprowski 
>>
>>
>> The only remaining thing to resolve is the moment of enabling DSI host.
>> The proper sequence is:
>>
>> 1. host power on, 2. device power on, 3. host init, 4. device init, 5.
>> video enable.
>
> +CC Raphael, STM32MP1 has similar topic.
>
>> #1 is done in dsi's pre_enable, #2 is done in panel's prepare. #3 was so
>> far done in the first host transfer call, which usually happens in
>> panel's prepare, then the #4 happens. Then video enable is done in the
>> enable callbacks.
>>
>> Jagan wants to move it to the dsi host pre_enable() to let it work with
>> DSI bridges controlled over different interfaces
>> (https://lore.kernel.org/all/20220504114021.33265-6-ja...@amarulasolutions.com/
>>  
>>
>> ). This however fails on Exynos with DSI panels, because when dsi's
>> pre_enable is called, the dsi device is not yet powered. I've discussed
>> this with Andrzej Hajda and we came to the conclusion that this can be
>> resolved by adding the init() callback to the struct mipi_dsi_host_ops.
>> Then DSI client (next bridge or panel) would call it after powering self
>> on, but before sending any DSI commands in its pre_enable/prepare 
>> functions.
>>
>> I've prepared a prototype of such solution. This approach finally
>> resolved all the initialization issues! The bridge chain finally matches
>> the hardware, no hack are needed, and everything is controlled by the
>> DRM core. This prototype also includes the Jagan's patches, which add
>> IMX support to Samsung DSIM. If one is interested, here is my git repo
>> with all the PoC patches:
>>
>> https://protect2.fireeye.com/v1/url?k=fc60b660-9deba379-fc613d2f-74fe485cbfec-6741e6fb26af486e=1=07baacdb-540b-46fa-be0f-f534635150ec=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv5.18-next-20220511-dsi-rework
>>  
>>
>
> Can you CC me on the iMX DSIM discussion/patches ? It seems I was left 
> out of it all, even though I work with the iMX8M DRM stuff extensively.


https://lore.kernel.org/all/20220504114021.33265-1-ja...@amarulasolutions.com/

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

Re: [PATCH v2 05/12] drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable()

[Marek Szyprowski]

On 04.05.2022 13:40, Jagan Teki wrote:
> Host transfer() in DSI master will invoke only when the DSI commands
> are sent from DSI devices like DSI Panel or DSI bridges and this
> host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
>
> Handling DSI host initialization in transfer calls misses the
> controller setup for I2C configured DSI bridges.
>
> This patch adds the DSI initialization from transfer to bridge
> pre_enable as the bridge pre_enable API is invoked by core as
> it is common across all classes of DSI device drivers.
>
> v2:
> * check initialized state in samsung_dsim_init
>
> v1:
> * keep DSI init in host transfer
>
> Signed-off-by: Jagan Teki 

This doesn't work with Exynos DSI and DSI panels. Here is a bit more 
detailed explanation and my solution for this:

https://lore.kernel.org/all/e96197f9-948a-997e-5453-9f9d179b5...@samsung.com/


> ---
>   drivers/gpu/drm/bridge/samsung-dsim.c | 18 --
>   1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 60dc863113a0..b9361af5ef2d 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1259,6 +1259,9 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   {
>   const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
>   
> + if (dsi->state & DSIM_STATE_INITIALIZED)
> + return 0;
> +
>   samsung_dsim_reset(dsi);
>   samsung_dsim_enable_irq(dsi);
>   
> @@ -1271,6 +1274,8 @@ static int samsung_dsim_init(struct samsung_dsim *dsi)
>   samsung_dsim_set_phy_ctrl(dsi);
>   samsung_dsim_init_link(dsi);
>   
> + dsi->state |= DSIM_STATE_INITIALIZED;
> +
>   return 0;
>   }
>   
> @@ -1290,6 +1295,10 @@ static void samsung_dsim_atomic_pre_enable(struct 
> drm_bridge *bridge,
>   }
>   
>   dsi->state |= DSIM_STATE_ENABLED;
> +
> + ret = samsung_dsim_init(dsi);
> + if (ret)
> + return;
>   }
>   
>   static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
> @@ -1464,12 +1473,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);
> + if (ret)
> + return ret;
>   
>   ret = mipi_dsi_create_packet(, msg);
>   if (ret < 0)

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