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:

quoted

On Sat, Feb 07, 2015 at 06:32:29AM +0800, Mark Brown wrote:

quoted

quoted

I'd really like to see some discussion as to how this is all supposed

to

quoted

quoted

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.

quoted

quoted

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

quoted

quoted

with the way that people want to use the systems.

quoted

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.

quoted

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.

-- 
Kenneth Westfield
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project