On Tue, Feb 10, 2015 at 06:26:34PM -0800, Mark Brown wrote:
On Sun, Feb 08, 2015 at 10:45:11PM -0800, Kenneth Westfield wrote:
On Sat, Feb 07, 2015 at 06:32:29AM +0800, Mark Brown wrote:
I'd really like to see some discussion as to how this is all supposed
to
be handled - how will these direct hardware access drivers and device trees work when someone does want to use the DSP (without causing problems), and how will we transition from one to the other. This is particularly pressing if there are use cases where people will want to switch between the two modes at runtime.
What I'm trying to avoid here is being in a situation where we have existing stable DT bindings which we have to support but which
conflict
with the way that people want to use the systems.
The ipq806x SOC has no LPASS DSP. On SOCs with a DSP, these drivers would not be enabled.
OK, but I'm guessing that they're using the same IP that is in other SoCs which do have the DSP so even if you don't care for this device it might still be an issue.
These drivers are prefixed with "lpass" to differentiate themselves from other drivers that would interact with a DSP, rather than the LPASS hardware directly.
Right, it may be that all that's needed here is some indication as to how to describe a system which *does* have a DSP. Perhaps require that the devices be children of the DSP, that way if people want to access the hardware directly they can load a dummy driver for the DSP that just passes things through if they don't want to use the DSP?
Replacing DSP-based drivers with LPASS-based drivers would be something that should be handled by Kconfig selections. For the DT, the DSP-related nodes and the LPASS-related nodes shouldn't overlap. There should be a DSP-based DT binding and a separate LPASS-based DT binding. Tying one or the other to the sound node (but not both), should work.