lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <825ff59f-0a97-49a1-a210-a7ee275364bc@rock-chips.com>
Date: Thu, 4 Sep 2025 11:19:05 +0800
From: Damon Ding <damon.ding@...k-chips.com>
To: Marek Szyprowski <m.szyprowski@...sung.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

Hi Marek,

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.
>>>>>>>>
>>>>>>>> This series lacks 'select DRM_BRIDGE_CONNECTOR' in ExynosDP's
>>>>>>>> Kconfig,
>>>>>>>> so it causes build break:
>>>>>>>>
>>>>>>>> drivers/gpu/drm/exynos/exynos_dp.c:177: undefined reference to
>>>>>>>> `drm_bridge_connector_init'
>>>>>>>> make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux] Error 1
>>>>>>>>
>>>>>>>> After adding this dependency, the Exynos DP driver stops
>>>>>>>> working. On
>>>>>>>> Samsung Snow Chromebook I observed following issue:
>>>>>>>>
>>>>>>>> [    4.534220] exynos-dp 145b0000.dp-controller: failed to attach
>>>>>>>> following panel or bridge (-16)
>>>>>>>> [    4.543428] exynos-drm exynos-drm: failed to bind
>>>>>>>> 145b0000.dp-controller (ops exynos_dp_ops): -16
>>>>>>>> [    4.551775] exynos-drm exynos-drm: adev bind failed: -16
>>>>>>>> [    4.556559] exynos-dp 145b0000.dp-controller: probe with driver
>>>>>>>> exynos-dp failed with error -16
>>>>>>>>
>>>>>>>> I will investigate details later in the evening.
>>>>>>>
>>>>>>> The failure is caused by trying to add plat_data->next_bridge twice
>>>>>>> (from exynos_dp's .attach callback, and from analogix' ->bind
>>>>>>> callback).
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>
>>>>>> I see. The bridge attachment for the next bridge was not well thought
>>>>>> out. It may be better to move panel_bridge addition a little forward
>>>>>> and remove next_bridge attachment on the Analogix side. Then, the
>>>>>> Rockchip side and Exynos side can do their own next_bridge attachment
>>>>>> in &analogix_dp_plat_data.attach() as they want.
>>>>>>
>>>>>> Could you please help test the following modifications(they have been
>>>>>> tested on my RK3588S EVB1 Board) on the Samsung Snow Chromebook? ;-)
>>>>>
>>>>> Assuming that I properly applied the malformed diff, it doesn't solve
>>>>> all the issues. There are no errors reported though, but the display
>>>>> chain doesn't work and no valid mode is reported:
>>>>>
>>>>> # dmesg | grep drm
>>>>> [    3.384992] [drm] Initialized panfrost 1.4.0 for 11800000.gpu on
>>>>> minor 0
>>>>> [    4.487739] [drm] Exynos DRM: using 14400000.fimd device for DMA
>>>>> mapping operations
>>>>> [    4.494202] exynos-drm exynos-drm: bound 14400000.fimd (ops
>>>>> fimd_component_ops)
>>>>> [    4.502374] exynos-drm exynos-drm: bound 14450000.mixer (ops
>>>>> mixer_component_ops)
>>>>> [    4.511930] exynos-drm exynos-drm: bound 145b0000.dp-controller
>>>>> (ops
>>>>> exynos_dp_ops)
>>>>> [    4.518411] exynos-drm exynos-drm: bound 14530000.hdmi (ops
>>>>> hdmi_component_ops)
>>>>> [    4.529628] [drm] Initialized exynos 1.1.0 for exynos-drm on
>>>>> minor 1
>>>>> [    4.657434] exynos-drm exynos-drm: [drm] Cannot find any crtc or
>>>>> sizes
>>>>> [    4.925023] exynos-drm exynos-drm: [drm] Cannot find any crtc or
>>>>> sizes
>>>>>
>>>>> # ./modetest -c -Mexynos
>>>>> Connectors:
>>>>> id      encoder status          name            size (mm)       modes
>>>>>       encoders
>>>>> 69      0       disconnected    LVDS-1          0x0             0
>>>>>         68
>>>>>      props:
>>>>>            1 EDID:
>>>>>                    flags: immutable blob
>>>>>                    blobs:
>>>>>
>>>>>                    value:
>>>>>            2 DPMS:
>>>>>                    flags: enum
>>>>>                    enums: On=0 Standby=1 Suspend=2 Off=3
>>>>>                    value: 0
>>>>>            5 link-status:
>>>>>                    flags: enum
>>>>>                    enums: Good=0 Bad=1
>>>>>                    value: 0
>>>>>            6 non-desktop:
>>>>>                    flags: immutable range
>>>>>                    values: 0 1
>>>>>                    value: 0
>>>>>            4 TILE:
>>>>>                    flags: immutable blob
>>>>>                    blobs:
>>>>>
>>>>>                    value:
>>>>> 71      0       disconnected    HDMI-A-1        0x0             0
>>>>>         70
>>>>>      props:
>>>>>            1 EDID:
>>>>>                    flags: immutable blob
>>>>>                    blobs:
>>>>>
>>>>>                    value:
>>>>>            2 DPMS:
>>>>>                    flags: enum
>>>>>                    enums: On=0 Standby=1 Suspend=2 Off=3
>>>>>                    value: 0
>>>>>            5 link-status:
>>>>>                    flags: enum
>>>>>                    enums: Good=0 Bad=1
>>>>>                    value: 0
>>>>>            6 non-desktop:
>>>>>                    flags: immutable range
>>>>>                    values: 0 1
>>>>>                    value: 0
>>>>>            4 TILE:
>>>>>                    flags: immutable blob
>>>>>                    blobs:
>>>>>
>>>>>                    value:
>>>>>
>>>>>
>>>>> I will investigate details later this week.
>>>>>
>>>>
>>>> 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. :-)

Best regards,
Damon

View attachment "simulation_for_ptn3460_20250904.patch" of type "text/plain" (5921 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ