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. Thanks -- ~Vinod [1]: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105526.html _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
