On Tue, Dec 09, 2014 at 12:33:21PM +0200, Jani Nikula wrote: > On Tue, 09 Dec 2014, Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
