* About snd_dmaengine_pcm_trigger()
@ 2014-03-05 5:20 Kuninori Morimoto
2014-03-05 7:42 ` Lars-Peter Clausen
0 siblings, 1 reply; 11+ messages in thread
From: Kuninori Morimoto @ 2014-03-05 5:20 UTC (permalink / raw)
To: Mark Brown, Lars-Peter Clausen
Cc: Linux-ALSA, Simon, Liam Girdwood, Kuninori Morimoto, Kuninori Morimoto
Hi Mark, Lars and all
I need your opinion
Now, I'm working for ${LINUX}/sound/soc/sh/fsi and ${LINUX}/sound/soc/sh/rcar drirvers.
These drivers are supporting DMAEngine transfer,
but it is using original DMAEngine method,
not using snd_dmaengine_pcm_trigger() or snd_dmaengine_pcm_register().
I was requested to use it from Mark.
The reason why I couldn't use it was our DMAEngine
didn't have "cyclic" tranfer support which is used on
dmaengine_pcm_prepare_and_submit()
But now, I created cyclic support on our DMA driver (on my local PC at this point)
Then, I noticed our drivers still can't use snd_dmaengine_pcm_xxx() method.
1st, our device needs PIO tranfer support too.
Current PIO/DMA transfer are sharing many methods/functions.
Code will become difficult to read if it is separated forcibly.
(to using snd_dmaengine_pcm_xxx())
2nd, our device DMA ON/OFF timing has relation ship to other register settings.
Unfortunately, our device is picky, it needs like this
HW init setting -> DMA ON -> HW start setting
It can be solved if snd_dmaengine_pcm_xxx() has callbacks,
but many callbacks are needed...
3rd, our device needs special method on snd_pcm_ops
int the future.
>From my point of view,
our driver can replace to use "cyclic" DMA transfer
instead of current original DMAEngine method.
I guess, it is not difficult.
But, using snd_dmaengine_pcm_xxx() is difficult.
But, what do you think ?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-05 5:20 About snd_dmaengine_pcm_trigger() Kuninori Morimoto
@ 2014-03-05 7:42 ` Lars-Peter Clausen
2014-03-05 8:32 ` Kuninori Morimoto
0 siblings, 1 reply; 11+ messages in thread
From: Lars-Peter Clausen @ 2014-03-05 7:42 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Simon, Linux-ALSA, Mark Brown, Liam Girdwood, Kuninori Morimoto
On 03/05/2014 06:20 AM, Kuninori Morimoto wrote:
> Hi Mark, Lars and all
>
> I need your opinion
>
> Now, I'm working for ${LINUX}/sound/soc/sh/fsi and ${LINUX}/sound/soc/sh/rcar drirvers.
> These drivers are supporting DMAEngine transfer,
> but it is using original DMAEngine method,
> not using snd_dmaengine_pcm_trigger() or snd_dmaengine_pcm_register().
> I was requested to use it from Mark.
>
> The reason why I couldn't use it was our DMAEngine
> didn't have "cyclic" tranfer support which is used on
> dmaengine_pcm_prepare_and_submit()
> But now, I created cyclic support on our DMA driver (on my local PC at this point)
>
> Then, I noticed our drivers still can't use snd_dmaengine_pcm_xxx() method.
>
> 1st, our device needs PIO tranfer support too.
> Current PIO/DMA transfer are sharing many methods/functions.
> Code will become difficult to read if it is separated forcibly.
> (to using snd_dmaengine_pcm_xxx())
Ideally from a high level abstraction point of few PIO and DMA would be two
completely separate components that can be used interchangeably. There might
be hardware restrictions though that do not allow this.
>
> 2nd, our device DMA ON/OFF timing has relation ship to other register settings.
> Unfortunately, our device is picky, it needs like this
>
> HW init setting -> DMA ON -> HW start setting
What kind of HW init is this?
>
> It can be solved if snd_dmaengine_pcm_xxx() has callbacks,
> but many callbacks are needed...
You can wrap the snd_dmaengine_pcm functions in your pcm_ops callbacks, like
this:
int sh_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
{
init hw ...
snd_dmaengine_pcm_trigger(substream, cmd);
start hw ...
}
Each of the snd_dmaengine_pcm functions does pretty much one specific task.
There is not much room for inserting callbacks.
>
> 3rd, our device needs special method on snd_pcm_ops
> int the future.
>
What kind of special ops?
> From my point of view,
> our driver can replace to use "cyclic" DMA transfer
> instead of current original DMAEngine method.
> I guess, it is not difficult.
> But, using snd_dmaengine_pcm_xxx() is difficult.
>
I don't think using the snd_dmaengine_pcm helpers should be difficult,
since, as I said, each of them perform one very specific task. If you'd
directly call the dmaengine API you'd end up with pretty much the same code
as the dmaengine PCM helpers. What's more of a challenge would be to use the
generic dmaengine PCM driver.
I think the issue with the sound/soc/sh/ code is that there never was a
clean separation between the DMA/PIO and the DAI configuration code. And
especially with rcar you seem to be reimplementing a ASoC-like framework
on-top of ASoC. Which makes it rather hard to reused generic code, since the
generic code doesn't know about all the custom hooks and callbacks. The ASoC
framework is not set in stone, if there is something missing to properly
support your hardware you should try to extend the framework to support this
rather than working around it in your drivers.
- Lars
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-05 7:42 ` Lars-Peter Clausen
@ 2014-03-05 8:32 ` Kuninori Morimoto
2014-03-05 9:20 ` Lars-Peter Clausen
0 siblings, 1 reply; 11+ messages in thread
From: Kuninori Morimoto @ 2014-03-05 8:32 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Simon, Linux-ALSA, Mark Brown, Liam Girdwood, Kuninori Morimoto
Hi Lars
Thank you for your feedback
> > 3rd, our device needs special method on snd_pcm_ops
> > int the future.
> >
>
> What kind of special ops?
It would like to use snd_soc_dapm_widget,
but we can update snd_soc_component instead of platform ?
> I don't think using the snd_dmaengine_pcm helpers should be difficult,
> since, as I said, each of them perform one very specific task. If you'd
> directly call the dmaengine API you'd end up with pretty much the same code
> as the dmaengine PCM helpers. What's more of a challenge would be to use the
> generic dmaengine PCM driver.
>
> I think the issue with the sound/soc/sh/ code is that there never was a
> clean separation between the DMA/PIO and the DAI configuration code. And
> especially with rcar you seem to be reimplementing a ASoC-like framework
> on-top of ASoC. Which makes it rather hard to reused generic code, since the
> generic code doesn't know about all the custom hooks and callbacks. The ASoC
> framework is not set in stone, if there is something missing to properly
> support your hardware you should try to extend the framework to support this
> rather than working around it in your drivers.
I see...
I need investigate more about this,
but, before that, can I confirm ?
basically...
platform : for PIO or DMA transfer method
component : for DAI configuration = CPU side HW settings etc
Is this correct ?
And about ASoC-like framework, rcar driver needs to control many kind of devices,
and it depends on platform which device is used.
(each devices have different feature)
So, I used ASoC-like framework, but in this case, what should I do ?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-05 8:32 ` Kuninori Morimoto
@ 2014-03-05 9:20 ` Lars-Peter Clausen
2014-03-06 0:22 ` Kuninori Morimoto
2014-03-11 4:47 ` Kuninori Morimoto
0 siblings, 2 replies; 11+ messages in thread
From: Lars-Peter Clausen @ 2014-03-05 9:20 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Simon, Mark Brown, Kuninori Morimoto, Liam Girdwood
On 03/05/2014 09:32 AM, Kuninori Morimoto wrote:
>
> Hi Lars
>
> Thank you for your feedback
>
>>> 3rd, our device needs special method on snd_pcm_ops
>>> int the future.
>>>
>>
>> What kind of special ops?
>
> It would like to use snd_soc_dapm_widget,
> but we can update snd_soc_component instead of platform ?
I'm not sure I fully understand what you mean, by using snd_soc_dapm_widget
in the pcm ops.
>
>> I don't think using the snd_dmaengine_pcm helpers should be difficult,
>> since, as I said, each of them perform one very specific task. If you'd
>> directly call the dmaengine API you'd end up with pretty much the same code
>> as the dmaengine PCM helpers. What's more of a challenge would be to use the
>> generic dmaengine PCM driver.
>>
>> I think the issue with the sound/soc/sh/ code is that there never was a
>> clean separation between the DMA/PIO and the DAI configuration code. And
>> especially with rcar you seem to be reimplementing a ASoC-like framework
>> on-top of ASoC. Which makes it rather hard to reused generic code, since the
>> generic code doesn't know about all the custom hooks and callbacks. The ASoC
>> framework is not set in stone, if there is something missing to properly
>> support your hardware you should try to extend the framework to support this
>> rather than working around it in your drivers.
>
> I see...
> I need investigate more about this,
> but, before that, can I confirm ?
>
> basically...
>
> platform : for PIO or DMA transfer method
> component : for DAI configuration = CPU side HW settings etc
>
> Is this correct ?
>
Yes.
> And about ASoC-like framework, rcar driver needs to control many kind of devices,
> and it depends on platform which device is used.
> (each devices have different feature)
> So, I used ASoC-like framework, but in this case, what should I do ?
Make them ASoC components ;) I don't know the hardware, but looking at the
code it doesn't seem to be that different from other modern host side audio
processing units. But one step at a time, first maybe try and see if you can
switch over to using the dmaengine PCM helper functions. Then later thing
about how this all can be better integrated into the ASoC framework.
- Lars
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-05 9:20 ` Lars-Peter Clausen
@ 2014-03-06 0:22 ` Kuninori Morimoto
2014-03-06 4:36 ` Mark Brown
2014-03-11 4:47 ` Kuninori Morimoto
1 sibling, 1 reply; 11+ messages in thread
From: Kuninori Morimoto @ 2014-03-06 0:22 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Linux-ALSA, Simon, Mark Brown, Kuninori Morimoto, Liam Girdwood
Hi Lars, Mark
> > platform : for PIO or DMA transfer method
> > component : for DAI configuration = CPU side HW settings etc
> >
> > Is this correct ?
> >
>
> Yes.
Thank you
> > And about ASoC-like framework, rcar driver needs to control many kind of devices,
> > and it depends on platform which device is used.
> > (each devices have different feature)
> > So, I used ASoC-like framework, but in this case, what should I do ?
>
> Make them ASoC components ;) I don't know the hardware, but looking at the
> code it doesn't seem to be that different from other modern host side audio
> processing units. But one step at a time, first maybe try and see if you can
> switch over to using the dmaengine PCM helper functions. Then later thing
> about how this all can be better integrated into the ASoC framework.
OK, I see. will do.
I guess it needs many steps.
OTOH, in reality, I need to work for my business task too.
Thus, actually, I need to add new feature on current rcar driver.
So, My plain is...
- send new feature patch to ML
- work for switching to above ASoC framework
Is this acceptable ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-06 0:22 ` Kuninori Morimoto
@ 2014-03-06 4:36 ` Mark Brown
2014-03-06 4:39 ` Kuninori Morimoto
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2014-03-06 4:36 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Lars-Peter Clausen, Liam Girdwood, Simon, Kuninori Morimoto
[-- Attachment #1.1: Type: text/plain, Size: 281 bytes --]
On Wed, Mar 05, 2014 at 04:22:38PM -0800, Kuninori Morimoto wrote:
> Thus, actually, I need to add new feature on current rcar driver.
> So, My plain is...
> - send new feature patch to ML
> - work for switching to above ASoC framework
> Is this acceptable ?
Yes, it's fine.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-06 4:36 ` Mark Brown
@ 2014-03-06 4:39 ` Kuninori Morimoto
0 siblings, 0 replies; 11+ messages in thread
From: Kuninori Morimoto @ 2014-03-06 4:39 UTC (permalink / raw)
To: Mark Brown
Cc: Linux-ALSA, Lars-Peter Clausen, Liam Girdwood, Simon, Kuninori Morimoto
Hi Mark
> > Thus, actually, I need to add new feature on current rcar driver.
> > So, My plain is...
>
> > - send new feature patch to ML
> > - work for switching to above ASoC framework
>
> > Is this acceptable ?
>
> Yes, it's fine.
Thank you
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-05 9:20 ` Lars-Peter Clausen
2014-03-06 0:22 ` Kuninori Morimoto
@ 2014-03-11 4:47 ` Kuninori Morimoto
2014-03-11 9:47 ` Lars-Peter Clausen
1 sibling, 1 reply; 11+ messages in thread
From: Kuninori Morimoto @ 2014-03-11 4:47 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Linux-ALSA, Simon, Mark Brown, Kuninori Morimoto, Liam Girdwood
Hi Lars, Mark
> Make them ASoC components ;) I don't know the hardware, but looking at the
> code it doesn't seem to be that different from other modern host side audio
> processing units. But one step at a time, first maybe try and see if you can
> switch over to using the dmaengine PCM helper functions. Then later thing
> about how this all can be better integrated into the ASoC framework.
In my quick check,
I guess, my drivers (FSI/rcar) can use
${LINUX}/sound/core/pcm_dmaengine.c methods as 1st step.
OTOH, these drivers has PIO transfer too.
So, if ALSA has PIO method like pcm_pio.c (?) which has similar method,
it seems easy to switch over.
But what do you think ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-11 4:47 ` Kuninori Morimoto
@ 2014-03-11 9:47 ` Lars-Peter Clausen
2014-03-11 9:55 ` Mark Brown
0 siblings, 1 reply; 11+ messages in thread
From: Lars-Peter Clausen @ 2014-03-11 9:47 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Linux-ALSA, Simon, Mark Brown, Kuninori Morimoto, Liam Girdwood
On 03/11/2014 05:47 AM, Kuninori Morimoto wrote:
>
> Hi Lars, Mark
>
>> Make them ASoC components ;) I don't know the hardware, but looking at the
>> code it doesn't seem to be that different from other modern host side audio
>> processing units. But one step at a time, first maybe try and see if you can
>> switch over to using the dmaengine PCM helper functions. Then later thing
>> about how this all can be better integrated into the ASoC framework.
>
> In my quick check,
> I guess, my drivers (FSI/rcar) can use
> ${LINUX}/sound/core/pcm_dmaengine.c methods as 1st step.
>
> OTOH, these drivers has PIO transfer too.
> So, if ALSA has PIO method like pcm_pio.c (?) which has similar method,
> it seems easy to switch over.
> But what do you think ?
If there are other platforms that also do PIO in a very similar way it might
make sense to factor this out.
The reason why we factored out the dmaengine DMA stuff is because there is a
standard API that hides the implementation details and is supposed to behave
the same for each system. For PIO you do not have such a abstraction layer
that hides the details, so I'm not sure how similar PIO between different
platforms will actually be.
- Lars
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-11 9:47 ` Lars-Peter Clausen
@ 2014-03-11 9:55 ` Mark Brown
2014-03-12 0:28 ` Kuninori Morimoto
0 siblings, 1 reply; 11+ messages in thread
From: Mark Brown @ 2014-03-11 9:55 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Linux-ALSA, Simon, Kuninori Morimoto, Kuninori Morimoto, Liam Girdwood
[-- Attachment #1.1: Type: text/plain, Size: 832 bytes --]
On Tue, Mar 11, 2014 at 10:47:32AM +0100, Lars-Peter Clausen wrote:
> The reason why we factored out the dmaengine DMA stuff is because
> there is a standard API that hides the implementation details and is
> supposed to behave the same for each system. For PIO you do not have
> such a abstraction layer that hides the details, so I'm not sure how
> similar PIO between different platforms will actually be.
I keep thinking that there ought to be *some* commonality between the
platforms that use FIQs if only in the timer stuff at least. Part of
the reason that doesn't get factored out is that it's normally just a
temporary bodge until DMA is working of course, though Qualcomm do it
because their DMA for the DSP doesn't fit well with dmaengine and the
i.MX AC'97 needs it since the hardware doesn't fully understand AC'97.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: About snd_dmaengine_pcm_trigger()
2014-03-11 9:55 ` Mark Brown
@ 2014-03-12 0:28 ` Kuninori Morimoto
0 siblings, 0 replies; 11+ messages in thread
From: Kuninori Morimoto @ 2014-03-12 0:28 UTC (permalink / raw)
To: Mark Brown
Cc: Linux-ALSA, Lars-Peter Clausen, Kuninori Morimoto, Simon, Liam Girdwood
Hi Lars, Mark
> > The reason why we factored out the dmaengine DMA stuff is because
> > there is a standard API that hides the implementation details and is
> > supposed to behave the same for each system. For PIO you do not have
> > such a abstraction layer that hides the details, so I'm not sure how
> > similar PIO between different platforms will actually be.
>
> I keep thinking that there ought to be *some* commonality between the
> platforms that use FIQs if only in the timer stuff at least. Part of
> the reason that doesn't get factored out is that it's normally just a
> temporary bodge until DMA is working of course, though Qualcomm do it
> because their DMA for the DSP doesn't fit well with dmaengine and the
> i.MX AC'97 needs it since the hardware doesn't fully understand AC'97.
Yes, there is no pioengine (never created :)
I'm not sure detail of non-Renesas platform driver whether it is supporting PIO.
But at least my driver (= FSI/rcar) has PIO support,
and I think these can share same method/function.
So, I create pcm_pio.c under ${LINUX}/sound/soc/sh for Renesas chip
with pcm_dmaengine similar style (as much as possible).
And, use common ${LINUX}/sound/core/pcm_dmaengine.c for DMA.
How about this ?
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-03-12 0:28 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-05 5:20 About snd_dmaengine_pcm_trigger() Kuninori Morimoto
2014-03-05 7:42 ` Lars-Peter Clausen
2014-03-05 8:32 ` Kuninori Morimoto
2014-03-05 9:20 ` Lars-Peter Clausen
2014-03-06 0:22 ` Kuninori Morimoto
2014-03-06 4:36 ` Mark Brown
2014-03-06 4:39 ` Kuninori Morimoto
2014-03-11 4:47 ` Kuninori Morimoto
2014-03-11 9:47 ` Lars-Peter Clausen
2014-03-11 9:55 ` Mark Brown
2014-03-12 0:28 ` Kuninori Morimoto
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.