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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx