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

[Vinod Koul]

On Tue, Mar 15, 2016 at 04:14:19PM -0500, Pierre-Louis Bossart wrote:
> 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?

That is one of the intended usages. Right now three folks are developing
on that, TI which seems to be encoder case, then sti (don't know if that
off chip or not) and mediatek.

The point here is that we can use the same interface here too if we are
not going i915 way. Possibly we might want to modify or add to this and
not make it ASoC dependent as this driver won't be an ASoC one. But yes
I haven't looked closely enough to say that if this should be the way or
not. I wanted to pint our an alternate interface being developed which
can be possible reused in non i915 case

Thanks
-- 
~Vinod