[alsa-devel] [Patch V4 00/10] ASoC: QCOM: Add support for ipq806x SOC

Mark Brown broonie at kernel.org
Wed Feb 11 03:26:34 CET 2015


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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150211/184aec80/attachment.sig>


More information about the Alsa-devel mailing list