Re: [alsa-devel] FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
On 08/23/2012 09:29 PM, Ola Lilja wrote:
-----Original Message----- From: Lee Jones [mailto:lee.jones@linaro.org] Sent: den 23 augusti 2012 16:59 To: Mark Brown Cc: Ola Lilja; 'Linus Walleij'; roger.xr.nilsson@stericsson.com; linux- arm-kernel@lists.infradead.org; alsa-devel@alsa-project.org Subject: Re: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
On Thu, Aug 23, 2012 at 03:37:57PM +0100, Mark Brown wrote:
On Thu, Aug 23, 2012 at 02:26:19PM +0100, Lee Jones wrote:
I think Ola is suggesting probing the DMA driver from the machine which will also work though I'm not 100% sure if I'm parsing the above correctly. The issue in DT terms is that if the DMA controller is shared with a bunch of other IPs then it should
have
one node shared between them all and not a bunch of shim nodes inserted in the middle which only exists due to the way Linux
instantiates stuff.
I haven't followed everything in this discussion, but what I meant in an earlier mail was that using the device for platform-DAI (MSP_I2S) also as platform int the DAI-link struct is not anything I can see fit (as in the patch Lee first submitted). I can see a few acceptable solutions: 1) Use it as it is! (A virtual device for PCM is created in arch/arm and the probe is invoked from the machine-driver). 2) Since the actual platform is the DMA-block, maybe there is some way of making the device "non-virtual" by having some sub-device in the DMA-driver that is instead triggered in the same way as in 1). 3) Move it to DT, but it seems that it is not possible when it is now a virtual device.
Any of these three would be fine with me.
When you say 'machine', do you mean from arch/<arch>/mach-*? If so, I'm keen for that not to happen.
No, sound/soc/ux500/snowball.c or whatever. At least that's my
guess.
Ah, I see. Maybe the mop500.c file then.
They instantiate the PCM driver dynamically from the DAI when
it's
probed which is pretty much what you're patch is doing.
So they do it in the same why I have with this patch? Do you know why Ola might think this is a bad idea?
I'm not 100% sure, I'm guessing it might be down to the fact that you end up with multiple PCM drivers. We could avoid that with refcounting but nobody's really worried about it.
I think I'll wait for Ola to get back, as he's the expert on this stuff.
I'll attempt to re-jig the patch-set, as this is a blocker atm.
-- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
On Fri, Aug 24, 2012 at 03:05:17PM +0200, Ola Lilja wrote:
I haven't followed everything in this discussion, but what I meant in an earlier mail was that using the device for platform-DAI (MSP_I2S) also as platform int the DAI-link struct is not anything I can see fit (as in the patch Lee first submitted).
I'm not sure I fully understand the above - I didn't notice anything with the dai links but I have to say that I could've looked more closely as I was waiting for ARM side reviews.
I can see a few acceptable solutions:
- Use it as it is! (A virtual device for PCM is created in arch/arm and the
probe is invoked from the machine-driver). 2) Since the actual platform is the DMA-block, maybe there is some way of making the device "non-virtual" by having some sub-device in the DMA-driver that is instead triggered in the same way as in 1).
The option we're using is essentially your option 2 but doing it from the DAI driver rather than from the DMA driver (keeping things in the audio subsystem since it's an audio specific issue).
On Mon, Aug 27, 2012 at 09:33:38AM -0700, Mark Brown wrote:
On Fri, Aug 24, 2012 at 03:05:17PM +0200, Ola Lilja wrote:
I haven't followed everything in this discussion, but what I meant in an earlier mail was that using the device for platform-DAI (MSP_I2S) also as platform int the DAI-link struct is not anything I can see fit (as in the patch Lee first submitted).
I'm not sure I fully understand the above - I didn't notice anything with the dai links but I have to say that I could've looked more closely as I was waiting for ARM side reviews.
I can see a few acceptable solutions:
- Use it as it is! (A virtual device for PCM is created in arch/arm and the
probe is invoked from the machine-driver). 2) Since the actual platform is the DMA-block, maybe there is some way of making the device "non-virtual" by having some sub-device in the DMA-driver that is instead triggered in the same way as in 1).
The option we're using is essentially your option 2 but doing it from the DAI driver rather than from the DMA driver (keeping things in the audio subsystem since it's an audio specific issue).
Ola could you please reply to this. Without your Ack this is our biggest blocker. There are other audio drivers which do it this way already. We are already doing something you suggested, just in a slightly different (more contained) way.
Please respond.
Kind regards, Lee
participants (3)
-
Lee Jones -
Mark Brown -
Ola Lilja