Message-Id: <DG2TG4NCMKXQ.36REPVMTQ7WWD@bootlin.com>
Date: Sat, 31 Jan 2026 14:41:21 +0100
From: "Luca Ceresoli" <luca.ceresoli@...tlin.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>, <shawnguo@...nel.org>, <s.hauer@...gutronix.de>,
 <kernel@...gutronix.de>, <festevam@...il.com>, <inki.dae@...sung.com>,
 <sw0312.kim@...sung.com>, <kyungmin.park@...sung.com>, <krzk@...nel.org>,
 <alim.akhtar@...sung.com>, <jingoohan1@...il.com>,
 <p.zabel@...gutronix.de>, <hjc@...k-chips.com>, <heiko@...ech.de>,
 <andy.yan@...k-chips.com>, <dmitry.baryshkov@....qualcomm.com>,
 <dianders@...omium.org>, <m.szyprowski@...sung.com>,
 <jani.nikula@...el.com>, <linux-kernel@...r.kernel.org>,
 <dri-devel@...ts.freedesktop.org>, <imx@...ts.linux.dev>,
 <linux-arm-kernel@...ts.infradead.org>,
 <linux-samsung-soc@...r.kernel.org>, <linux-rockchip@...ts.infradead.org>
Subject: Re: [PATCH v8 04/18] drm/bridge: analogix_dp: Add
 &analogix_dp_plat_data.next_bridge

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@...k-chips.com>
>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@...sung.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@...tlin.com>

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

Powered by blists - more mailing lists