[Intel-gfx] [PATCH v2 2/5] drm/i915: add component support

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:33:21PM +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, Daniel Vetter <daniel at 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