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