Re: [PATCH v6 0/4] Add SCDC information to connector debugfs

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

On Monday, 15 June 2026 18:33:11 Central European Summer Time Maxime Ripard wrote:
> On Mon, Jun 15, 2026 at 10:07:02AM +0200, Nicolas Frattaroli wrote:
> > On Saturday, 13 June 2026 08:57:29 Central European Summer Time Hans Verkuil wrote:
> > > Hi Nicolas,
> > > 
> > > On 11/06/2026 14:57, Nicolas Frattaroli wrote:
> > > > HDMI uses the DDC I2C bus for communicating various bits of link status
> > > > out of band with the actual HDMI video signal. This information can be
> > > > useful for debugging issues like questionable cables sabotaged by feline
> > > > teeth, Enthusiast Grade cables made of cow fencing wire, and other such
> > > > problems that ruin one's media viewing plans.
> > > > 
> > > > Consequently, this series exposes various bits of pertinent information
> > > > from the SCDC protocol in an HDMI connector's debugfs. To continually
> > > > poll the link status, userspace can poll the debugfs file.
> > > 
> > > Something is not quite right: I've been testing this series with my i915
> > > based laptop with HDMI connector, and I never see the scdc_status file.
> > > And that's because CONFIG_DRM_BRIDGE_CONNECTOR is not set for my configuration.
> > 
> > That's to be expected. i915 does not use bridge connectors, and neither
> > does amdgpu iirc. I am working on embedded boards that do use bridge
> > connectors, along with all the rest of the HDMI state helpers.
> > 
> > Implementing something new in DRM usually involves having to triplicate
> > certain parts of the work in order to have i915 and amdgpu behave the
> > same as everyone else.
> > 
> > > So I think you are creating the debugfs entry in the wrong place.
> > 
> > I can't create it for all drm_connectors as Maxime suggested due to the
> > cyclical dependency that would create. If someone has any idea on how
> > to break that dependency cycle, I'm open to suggestions.
> 
> Back when we introduce the audio support, we floated the idea to
> de-midlayer this and turn it into a debugfs_init helper. We don't have a
> lot of users yet so it might be the best time to do so, and would solve
> your issue.

I agree and will be happy to do that. I need some more concrete info
though on what "de-midlayer" means here. From what I can tell, the
core problem is that drm_connector.c directly calls into
drm_debugfs_connector_add of drm_debugfs.c, which if it did also
do a direct call into drm_scdc_helper.c would mean drm_scdc_helper.c
needs drm_connector.c but drm_connector.c needs drm_scdc_helper.c.

So I guess the de-midlayer and turn it into helper part is that
drm_connector does an indirect call to a function pointer instead,
which is default-filled at runtime with the helper debugfs_init
function? I don't know if we can then do this by default for all
drivers in drm_connector.c or if it needs to be done per-driver
like some of the other helpers. If the latter, then we don't
really gain much over what I'm doing with bridge connector.

The other maybe less intrusive change is that
drm_scdc_debugfs_init and scdc_status_fops travels to drm_debugfs.c,
while the actual implementation of the read op remains in
drm_scdc_helper.c. I think that would solve it without a big refactor?

Kind regards,
Nicolas Frattaroli

> 
> Maxime
>