Re: [PATCH v2 2/5] drm/i915: add component support

Daniel Vetter
2014-12-10T09:24:03Z

On Tue, Dec 09, 2014 at 12:33:21PM +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Dec 09, 2014 at 11:41:17AM +0200, Imre Deak wrote:
> >> Register a component to be used to interface with the snd_hda_intel
> >> driver. This is meant to replace the same interface that is currently
> >> based on module symbol lookup.
> >>
> >> v2:
> >> - change roles between the hda and i915 components (Daniel)
> >> - add the implementation to a new file (Jani)
> >
> > I disagree with the name here - intel_component.c is not really
> > descriptive since it's not really. Imo it makes much more sense to put
> > this into intel_audio.c. After all it's all about how we interact with the
> > audio side, which will be even more obvious once we have a dedicated
> > subdevice for this.
>
> If we keep this component audio specific, then I guess I agree
> intel_audio.c is the better place for it. But that means anything else
> (like possibly pmic driver interaction) will need to have a component of
> its own.

I guess it depends upon how we'll structure it, but if i915 needs to
access pmic then pmic needs to expose a new platform dev/component and
i915 is a master. This won't interfere I think since it's something from
the i915 device that we expose for the audio driver.

So high-level summary of component:
- master: the main part which owns the userspace/logical device (e.g.
drm_device, snd_dev, ...)
- component: various bits&pieces all over needed for a master, but not
part of the main device. In DT-land that's everything since the main
device is just a fake DT node to bundle everything up with no realation
to real hw. In acpi we'll likely always have some real acpi or pci
device as master.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch