[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87mse851um.fsf@intel.com>
Date: Wed, 26 Feb 2025 14:26:09 +0200
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong
<neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, Laurent
Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman
<jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, Maarten
Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David
Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Dmitry
Baryshkov <dmitry.baryshkov@...aro.org>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/2] drm/bridge: move bridges_show logic from
drm_debugfs.c
On Wed, 26 Feb 2025, Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
> Hello Jani,
>
> On Tue, 25 Feb 2025 20:21:50 +0200
> Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>
>> On Tue, 25 Feb 2025, Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
>> > Hello Jani,
>> >
>> > On Tue, 25 Feb 2025 18:36:41 +0200
>> > Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>> >
>> >> On Tue, 25 Feb 2025, Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
>> >> > In preparation to expose more info about bridges in debugfs, which will
>> >> > require more insight into drm_bridge data structures, move the bridges_show
>> >> > code to drm_bridge.c.
>> >> >
>> >> > Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>> >> > Signed-off-by: Luca Ceresoli <luca.ceresoli@...tlin.com>
>> >>
>> >> I hate myself for doing this on a patch that's at v7... but here goes.
>> >
>> > Please don't! :-) This patch is new in v7, and a different (and
>> > definitely worse) approach was present in v6, but there was nothing
>> > before.
>> >
>> >> Perhaps consider moving the bridges debugfs creation and fops to
>> >> drm_bridge.c instead of just adding
>> >> drm_bridge_debugfs_show_encoder_bridges().
>> >>
>> >> For example, add drm_bridge_debugfs_add(struct drm_encoder *encoder),
>> >> which then contains the debugfs_create_file() call.
>> >
>> > I think it should go in drm_encoder.c, not drm_bridge.c, right? Here we
>> > are showing the bridges attached to an encoder, so the entry point is
>> > each encoder.
>>
>> I'm still thinking drm_bridge.c, because it's about bridges and their
>> details. The encoder shouldn't care about bridge implementation details.
>
> Ah, I think I now get what you mean.
>
> Current code is:
>
> drm_encoder_register_all() [drm_encoder.c]
> -> drm_debugfs_encoder_add [drm_debugfs.c]
> -> debugfs_create_file("bridges"... &bridges_fops) [drm_debugfs.c]
> [bridges_fops is in drm_debugfs.c]
>
> Moving the last 2 lines to drm_bridge.c and into a new function we'd
> have:
>
> drm_encoder_register_all() [drm_encoder.c]
> -> drm_debugfs_encoder_add [*] [drm_debugfs.c]
> -> drm_bridge_debugfs_add_encoder_bridges_file (NEW) [drm_bridge.c]
> -> debugfs_create_file("bridges"... &bridges_fops) [drm_bridge.c]
> [bridges_fops is in drm_bridge.c]
>
> Potentially [*] could be moved to drm_encoder.c, but that is not bridge
> related and can be done as a future step.
>
> Is this what you had in mind?
Yes!
(Though I'd give drm_bridge_debugfs_add_encoder_bridges_file() a shorter
and more generic name.)
BR,
Jani.
>
>> > On the other hand in patch 2 we should move the
>> > drm_debugfs_global_add() code to drm_bridge.c, as it's showing bridges
>> > ina encoder-independent way.
>>
>> Agreed on that.
>>
>> > And finally drm_bridge should export the common
>> > drm_bridge_debugfs_show_bridge() function to drm_encoder.c.
>>
>> Disagree. That will still require the EXPORT and #ifdefs around
>> CONFIG_DEBUG_FS.
>
> With the above-sketched idea I agree we wouldn't need to export
> drm_bridge_debugfs_show_bridge().
>
> Luca
--
Jani Nikula, Intel
Powered by blists - more mailing lists