* Re: FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device [not found] <014401cd8165$99960c40$ccc224c0$@se> @ 2012-08-24 13:05 ` Ola Lilja 0 siblings, 0 replies; 6+ messages in thread From: Ola Lilja @ 2012-08-24 13:05 UTC (permalink / raw) To: Mark Brown, lee.jones Cc: roger.xr.nilsson, alsa-devel@alsa-project.org, Linus Walleij, linux-arm-kernel 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 > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device @ 2012-08-24 13:05 ` Ola Lilja 0 siblings, 0 replies; 6+ messages in thread From: Ola Lilja @ 2012-08-24 13:05 UTC (permalink / raw) To: linux-arm-kernel On 08/23/2012 09:29 PM, Ola Lilja wrote: > > >> -----Original Message----- >> From: Lee Jones [mailto:lee.jones at linaro.org] >> Sent: den 23 augusti 2012 16:59 >> To: Mark Brown >> Cc: Ola Lilja; 'Linus Walleij'; roger.xr.nilsson at stericsson.com; linux- >> arm-kernel at lists.infradead.org; alsa-devel at 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device 2012-08-24 13:05 ` Ola Lilja @ 2012-08-27 16:33 ` Mark Brown -1 siblings, 0 replies; 6+ messages in thread From: Mark Brown @ 2012-08-27 16:33 UTC (permalink / raw) To: Ola Lilja Cc: roger.xr.nilsson, alsa-devel@alsa-project.org, lee.jones, Linus Walleij, linux-arm-kernel 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: > 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). 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device @ 2012-08-27 16:33 ` Mark Brown 0 siblings, 0 replies; 6+ messages in thread From: Mark Brown @ 2012-08-27 16:33 UTC (permalink / raw) To: linux-arm-kernel 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: > 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). 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device 2012-08-27 16:33 ` Mark Brown @ 2012-09-14 13:09 ` Lee Jones -1 siblings, 0 replies; 6+ messages in thread From: Lee Jones @ 2012-09-14 13:09 UTC (permalink / raw) To: Mark Brown Cc: roger.xr.nilsson, Ola Lilja, alsa-devel@alsa-project.org, Linus Walleij, linux-arm-kernel 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: > > 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). > > 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 -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device @ 2012-09-14 13:09 ` Lee Jones 0 siblings, 0 replies; 6+ messages in thread From: Lee Jones @ 2012-09-14 13:09 UTC (permalink / raw) To: linux-arm-kernel 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: > > 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). > > 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 -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-14 13:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <014401cd8165$99960c40$ccc224c0$@se>
2012-08-24 13:05 ` FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device Ola Lilja
2012-08-24 13:05 ` Ola Lilja
2012-08-27 16:33 ` Mark Brown
2012-08-27 16:33 ` Mark Brown
2012-09-14 13:09 ` Lee Jones
2012-09-14 13:09 ` Lee Jones
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.