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 <[email protected]> >>>> Reviewed-by: Dmitry Baryshkov <[email protected]> >>>> Tested-by: Marek Szyprowski <[email protected]> >>>> >>>> --- >>>> >>>> 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 <[email protected]> -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
