[alsa-devel] [PATCH 20/20] ASoC: fsl: add imx-sgtl5000 machine driver
shawn.guo at linaro.org
Mon Mar 5 14:07:09 CET 2012
On Mon, Mar 05, 2012 at 11:56:12AM +0000, Mark Brown wrote:
> On Mon, Mar 05, 2012 at 04:06:25PM +0800, Shawn Guo wrote:
> > On Sun, Mar 04, 2012 at 01:38:18PM +0000, Mark Brown wrote:
> > > This looks like there's a problem with the bindings, why are you
> > > registering the DMA device from the card?
> > There is a dma node in the device tree to instantiate the dma device
> > backed by a dmaengine driver. As a client peripheral of that dmaengine
> > device, the SSI owns just a dma request/event number. With the number
> > encoded in SSI node, there is no hardware resource to be claimed by
> > that pcm-device, so we do not have it in device tree. Then we have
> > to register this device in either fsl_ssi driver or machine driver.
> > I chose to do something that tegra is doing, registering the pcm device
> > in machine driver, to keep fsl_ssi away from imx specific bits as much
> > as possible.
> The above sounds like you have a unified DAI and PCM driver.
The pcm-dma driver is being shared across several i.MX SoCs, and we
are trying to reuse fsl_ssi driver between PowerPC and IMX.
> In that
> case they should either both be using the same device or should have
> some sort of parent/child/sibling relationship.
Sorry, I do not understand it. Can you elaborate it a little bit?
> Either way the machine
> driver really shouldn't be involved in instantiating things, perhaps
> arch/arm but not the audio machine driver.
So you are saying neither what tegra_wm8903 and tegra_alc5632 are doing
(registering pcm device in machine driver) nor what imx-ssi is doing
(registering pcm device in DAI driver) is correct? Can you please make
it clear what's the right thing to do?
More information about the Alsa-devel