On 3/15/16 11:21 AM, Vinod Koul wrote:
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.
My understanding is that it's an interface for external encoders that
have an I2S or S/PDIF link. Such external encoders appear as ASoC codecs
that can be bound to the SoC with DT bindings. I don't see what we could
reuse here?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
