Message-ID: <4939d55e-b560-4235-8295-adf8e48d9b74@samsung.com>
Date: Thu, 4 Sep 2025 15:27:24 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Damon Ding <damon.ding@...k-chips.com>, andrzej.hajda@...el.com,
	neil.armstrong@...aro.org, rfoss@...nel.org
Cc: Laurent.pinchart@...asonboard.com, jonas@...boo.se,
	jernej.skrabec@...il.com, maarten.lankhorst@...ux.intel.com,
	mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com, simona@...ll.ch,
	jingoohan1@...il.com, inki.dae@...sung.com, sw0312.kim@...sung.com,
	kyungmin.park@...sung.com, krzk@...nel.org, alim.akhtar@...sung.com,
	hjc@...k-chips.com, heiko@...ech.de, andy.yan@...k-chips.com,
	dmitry.baryshkov@....qualcomm.com, l.stach@...gutronix.de,
	dianders@...omium.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v4 00/13] Apply drm_bridge_connector and panel_bridge
 helper for the Analogix DP driver

On 04.09.2025 05:19, Damon Ding wrote:
> On 9/1/2025 6:25 PM, Marek Szyprowski wrote:
>> On 01.09.2025 05:41, Damon Ding wrote:
>>> On 8/29/2025 4:23 PM, Marek Szyprowski wrote:
>>>> On 29.08.2025 10:08, Damon Ding wrote:
>>>>> On 8/20/2025 5:20 AM, Marek Szyprowski wrote:
>>>>>> On 15.08.2025 04:59, Damon Ding wrote:
>>>>>>> On 2025/8/15 5:16, Marek Szyprowski wrote:
>>>>>>>> On 14.08.2025 16:33, Marek Szyprowski wrote:
>>>>>>>>> On 14.08.2025 12:47, Damon Ding wrote:
>>>>>>>>>> PATCH 1 is a small format optimization for struct
>>>>>>>>>> analogid_dp_device.
>>>>>>>>>> PATCH 2 is to perform mode setting in
>>>>>>>>>> &drm_bridge_funcs.atomic_enable.
>>>>>>>>>> PATCH 3-6 are preparations for apply drm_bridge_connector 
>>>>>>>>>> helper.
>>>>>>>>>> PATCH 7 is to apply the drm_bridge_connector helper.
>>>>>>>>>> PATCH 8-10 are to move the panel/bridge parsing to the Analogix
>>>>>>>>>> side.
>>>>>>>>>> PATCH 11-12 are preparations for apply panel_bridge helper.
>>>>>>>>>> PATCH 13 is to apply the panel_bridge helper.
>>>>>>>>> ...
>>>>>>
>>>>>
>>>>> Could you please provide the related DTS file for the test? I will
>>>>> also try to find out the reason for this unexpected issue. ;-)
>>>>
>>>> Unfortunately I didn't find enough time to debug this further. The 
>>>> above
>>>> log is from Samsung Snow Chromebook,
>>>> arch/arm/boot/dts/samsung/exynos5250-snow.dts
>>>>
>>>>
>>>
>>> I compare the differences in the following display path before and
>>> after this patch series:
>>>
>>> exynos_dp -> nxp-ptn3460 -> panel "auo,b116xw03"
>>>
>>> The issue is likely caused by the &drm_connector_funcs.detect()
>>> related logic. Before this patch series, the nxp-ptn3460 connector is
>>> always connector_status_connected because there is not available
>>> &drm_connector_funcs.detect(). After it, the DRM_BRIDGE_OP_DETECT flag
>>> make the connection status depend on analogix_dp_bridge_detect().
>>>
>>> Could you please add the following patches additionally and try again?
>>> (Not the final solution, just validation)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index a93ff8f0a468..355911c47354 100644
>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -1491,9 +1491,11 @@ int analogix_dp_bind(struct analogix_dp_device
>>> *dp, struct drm_device *drm_dev)
>>>                  }
>>>          }
>>>
>>> -       bridge->ops = DRM_BRIDGE_OP_DETECT |
>>> -                     DRM_BRIDGE_OP_EDID |
>>> +       bridge->ops = DRM_BRIDGE_OP_EDID |
>>>                        DRM_BRIDGE_OP_MODES;
>>> +       if (drm_bridge_is_panel(dp->plat_data->next_bridge))
>>> +               bridge->ops |= DRM_BRIDGE_OP_DETECT;
>>> +
>>>          bridge->of_node = dp->dev->of_node;
>>>          bridge->type = DRM_MODE_CONNECTOR_eDP;
>>>          ret = devm_drm_bridge_add(dp->dev, &dp->bridge);
>>
>> It is better. Now the display panel is detected and reported to
>> userspace, but it looks that something is not properly initialized,
>> because there is garbage instead of the proper picture.
>>
>
> I simulated the display path mentioned above on my RK3588S EVB1 Board.
> To my slight surprise, it displayed normally with the reported 
> connector type DRM_MODE_CONNECTOR_LVDS. ;-)
>
> The modifications included:
> 1.Synchronized the Analogix DP ralated DT configurations with Samsung 
> Snow Chromebook.
> 2.Skipped the I2C transfers and GPIO operations in nxp-ptn3460 driver.
> 3.Set the EDID to that of eDP Panel LP079QX1-SP0V forcibly.
>
> Additionally, I added debug logs to verify whether the functions in 
> ptn3460_bridge_funcs were actually called.
>
> Did you encounter any unexpected logs during your investigation? I'd 
> like to perform additional tests on this issue. :-)


Okay, I've finally went to the office and tested manually all 3 
Chromebook boards witch use exynos-dp based display hardware. Previously 
I only did the remote tests and observed result on a webcam, which was 
not directed directly at the tested displays, so I only saw the glare 
from the display panel.

The results are as follows:

1. Snow (arch/arm/boot/dts/samsung/exynos5250-snow.dts) - exynos-dp -> 
nxp-ptn3460 1366x768 lvds panel - works fine with the above mentioned 
change.

2. Peach-Pit (arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts) - 
exynos-dp -> parade,ps8625 -> auo,b116xw03 1366x768 lvds panel - 
displays garbage, this was the only board I previously was able to see 
partially on the webcam.

3. Peach-Pi (arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts) - 
exynos-dp -> auo,b133htn01 1920x1080 edp panel - also displays garbage.

Then I found why both Peach boards displays garbage on boot - the 
framebuffer emulation is initialized for 1024x786 resolution, which is 
not handled by those panels. This is a bit strange, because the 
connector implemented by the panel reports proper native mode to drm and 
userspace. 'modetest -c' shows the right resolution. Also when I run 
'modetest -s' with the panel's native resolution then the test pattern 
is correctly displayed on all three boards.


Then I've played a bit with the analogix code and it looks that this 
1024x768 mode is some kind default mode which comes from 
analogix_dp_bridge_edid_read() function, which has been introduced by 
this patchset. When I removed DRM_BRIDGE_OP_EDID flag from bridge->ops, 
then I got it finally working again properly on all three boards. I hope 
this helps fixing this issue.



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

Powered by blists - more mailing lists