[Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

Vinod Koul vinod.koul at intel.com
Tue Mar 15 16:21:07 UTC 2016

On Tue, Mar 15, 2016 at 03:35:45PM +0200, Ville Syrjälä wrote:
> > > I understand the benefits of a parent/child device/subdevice model. What I
> > > don't see is whether we need the component framework at all here?
> > > It was used in the case of HDaudio since both i915 and HDaudio controllers
> > > get probed at different times, here the HDMI interface is just a bunch of
> > > registers/DMA from the same hardware so the whole master/client interface
> > > exposed by the component framework to 'bind' independent drivers is a bit
> > > overkill?
> > 
> > I haven't read the patches, but using component.c when you instead can
> > model it with parent/child smells like abuse. Component.c is meant for
> > when you have multiple devices all over the device tree that in aggregate
> > constitute the overall logical driver. This doesn't seem to be the case
> > here.

Right I do think that might be the case.

> We still need the eld notify hooks so that i915 can inform the audio
> driver about the state of the display. Whether that's best done via
> the component stuff or something else I don't know.

There is already work ongoing by ARM folks for the interface, should we
reuse that [1]. I would certainly argue reusing rather than redfeining a
new one would be better.

Btw this interface seems to rely on display side implemting these ops.


[1]: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105526.html

More information about the Intel-gfx mailing list