Re: [PATCH v8 04/18] drm/bridge: analogix_dp: Add &analogix_dp_plat_data.next_bridge

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

On Wed Jan 7, 2026 at 3:36 AM CET, Damon Ding wrote:
> Hi Luca,
>
> On 1/4/2026 10:51 AM, Damon Ding wrote:
>> Hi Luca,
>>
>> On 12/31/2025 7:11 PM, Luca Ceresoli wrote:
>>> Hello Damon,
>>>
>>> On Wed Dec 17, 2025 at 10:33 AM CET, Damon Ding wrote:
>>>> In order to move the panel/bridge parsing and attachmenet to the
>>>> Analogix side, add component struct drm_bridge *next_bridge to
>>>> platform data struct analogix_dp_plat_data.
>>>>
>>>> The movement makes sense because the panel/bridge should logically
>>>> be positioned behind the Analogix bridge in the display pipeline.
>>>>
>>>> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v4:
>>>> - Rename the &analogix_dp_plat_data.bridge to
>>>>    &analogix_dp_plat_data.next_bridge
>>>> ---
>>>>   include/drm/bridge/analogix_dp.h | 1 +
>>>>   1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/
>>>> analogix_dp.h
>>>> index cf17646c1310..582357c20640 100644
>>>> --- a/include/drm/bridge/analogix_dp.h
>>>> +++ b/include/drm/bridge/analogix_dp.h
>>>> @@ -27,6 +27,7 @@ static inline bool is_rockchip(enum
>>>> analogix_dp_devtype type)
>>>>   struct analogix_dp_plat_data {
>>>>       enum analogix_dp_devtype dev_type;
>>>>       struct drm_panel *panel;
>>>> +    struct drm_bridge *next_bridge;
>>>>       struct drm_encoder *encoder;
>>>>       struct drm_connector *connector;
>>>>       bool skip_connector;
>>>
>>> It took a while to understand why you are adding the next_bridge
>>> pointer in
>>> struct analogix_dp_plat_data instead of struct analogix_dp_device,
>>> where it
>>> would be more natural. I found an answer in patch 16: with current
>>> code you
>>> need to place next_bridge in struct analogix_dp_plat_data because it is
>>> used by user drivers to attach, and those drivers have no access to
>>> struct
>>> analogix_dp_device. However patch 16 (which looks a very good cleanup
>>> BTW)
>>> next_bridge can be moved to struct analogix_dp_device.
>>>
>>> So I'd suggest to move patch 16 before this one if it easily doable, so
>>> that you can introduce next_bridge in struct analogix_dp_device from the
>>> beginning. Should that be impossible, you can send a separate patch to
>>> move
>>> next_bridge, after patch 16.
>>>
>>>
>>
>> Thanks for your nice suggestion! After patch 16, bridge attachment is
>> unified to the Analogix side, which acts as a common bridge driver for
>> both the Rockchip and Exynos sides, so moving next_bridge there makes
>> perfect sense. I will add a separate patch to move next_bridge in v9.
>>
>>
>
> My apologies for reversing the plan to move next_bridge to the Analogix
> side in v9 -- I only considered the Rockchip side before.
>
> When I tried modifying the code based on your suggestion, I found it
> better to keep &analogix_plat_data.next_bridge as is. This is because
> the Exynos side needs to maintain compatibility with the legacy method
> of parsing panels and bridges, so the next bridge isn't always parsed by
> the common Analogix side driver.
>
> This patch series has been pending for ages, and I'm even a bit fuzzy on
> the details myself. ;-)

OK, makes sense.

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com