On Tue, Mar 27, 2012 at 12:40 AM, Mark Brown
<[email protected]> wrote:
> So, I just said to the SPEAr guys that I really want to see support for
> non-cyclic dmaengine added to the helper library rather than open
> coding. ?We're seeing lots of platforms moving to dmaengine (as well as
What is going on this ?
Let me know this status.
--
ROHM Co., Ltd.
tomoya
On Wed, May 23, 2012 at 01:17:15PM +0900, Tomoya MORINAGA wrote:
> On Tue, Mar 27, 2012 at 12:40 AM, Mark Brown
> > So, I just said to the SPEAr guys that I really want to see support for
> > non-cyclic dmaengine added to the helper library rather than open
> > coding. ?We're seeing lots of platforms moving to dmaengine (as well as
> What is going on this ?
> Let me know this status.
Nobody seems to be working on it as far as I can tell, I've certainly
not seen any patches.
On Wed, May 23, 2012 at 6:41 PM, Mark Brown
<[email protected]> wrote:
>> > So, I just said to the SPEAr guys that I really want to see support for
>> > non-cyclic dmaengine added to the helper library rather than open
>> > coding. ?We're seeing lots of platforms moving to dmaengine (as well as
>
>> What is going on this ?
>> Let me know this status.
>
> Nobody seems to be working on it as far as I can tell, I've certainly
> not seen any patches.
If so, could you accept current platform/machine driver ?
thanks in advance.
--
ROHM Co., Ltd.
tomoya
On Thu, May 24, 2012 at 08:46:03AM +0900, Tomoya MORINAGA wrote:
> On Wed, May 23, 2012 at 6:41 PM, Mark Brown
> > Nobody seems to be working on it as far as I can tell, I've certainly
> > not seen any patches.
> If so, could you accept current platform/machine driver ?
Ideally what would be happening here is that you or other people who
have such systems would be working to add the required support to the
core code, there's clearly a need for common code here as there are a
number of different systems that don't have cyclic DMA and it wouldn't
be great to end up with duplicated code.
Is there some great difficulty in factoring out the support for
non-cyclic audio DMA on dmaengine - it seems like if there is we must
have a serious problem in dmaengine which we should fix? If there is a
substantial difficulty then that's different but it doesn't feel like
we've tried doing common code yet, if there's problems doing that I'd
like to understand what they are before we jump ahead of ourselves.
On Thu, May 24, 2012 at 7:07 PM, Mark Brown
<[email protected]> wrote:
>> > Nobody seems to be working on it as far as I can tell, I've certainly
>> > not seen any patches.
>
>> If so, could you accept current platform/machine driver ?
>
> Ideally what would be happening here is that you or other people who
> have such systems would be working to add the required support to the
> core code, there's clearly a need for common code here as there are a
> number of different systems that don't have cyclic DMA and it wouldn't
> be great to end up with duplicated code.
>
> Is there some great difficulty in factoring out the support for
> non-cyclic audio DMA on dmaengine - it seems like if there is we must
> have a serious problem in dmaengine which we should fix? ?If there is a
> substantial difficulty then that's different but it doesn't feel like
> we've tried doing common code yet, if there's problems doing that I'd
> like to understand what they are before we jump ahead of ourselves.
I'm not so familiar with Linux's DMA idea.
So we don't know whether non-cyclic dmaengine has problem or not.
Until now, we've developed device drivers use DMA driver like UART, SPI.
These drivers are implemented using the same way, you called
"non-cyclic", and already applied.
As you said, common code for DMA code can be best solution.
However, currently, the code is nothing.
So, I want you to accept our driver as first step.
Because I think supporting new device is more important for linux than
dmaengine common.
thanks
--
ROHM Co., Ltd.
tomoya
On Fri, 2012-05-25 at 18:30 +0900, Tomoya MORINAGA wrote:
> On Thu, May 24, 2012 at 7:07 PM, Mark Brown
> <[email protected]> wrote:
> >> > Nobody seems to be working on it as far as I can tell, I've certainly
> >> > not seen any patches.
> >
> >> If so, could you accept current platform/machine driver ?
> >
> > Ideally what would be happening here is that you or other people who
> > have such systems would be working to add the required support to the
> > core code, there's clearly a need for common code here as there are a
> > number of different systems that don't have cyclic DMA and it wouldn't
> > be great to end up with duplicated code.
> >
> > Is there some great difficulty in factoring out the support for
> > non-cyclic audio DMA on dmaengine - it seems like if there is we must
> > have a serious problem in dmaengine which we should fix? If there is a
> > substantial difficulty then that's different but it doesn't feel like
> > we've tried doing common code yet, if there's problems doing that I'd
> > like to understand what they are before we jump ahead of ourselves.
>
> I'm not so familiar with Linux's DMA idea.
> So we don't know whether non-cyclic dmaengine has problem or not.
First you should not be writing your own dma driver, it *needs* to use
dmaenegine. We already have bunch of driver supported, so there may be a
case that existing driver works straight or with little modifications.
Using your own dma driver is a dead road, so sooner you move over better
it is.
One you move then it would be easy for you to use soc-dmaengine. If your
driver doesn't support cyclic; nothing stops from you emulating that in
S/W. And given that you have already contributed to dmaengine subsystem,
it should be easy for you :)
>
> Until now, we've developed device drivers use DMA driver like UART, SPI.
> These drivers are implemented using the same way, you called
> "non-cyclic", and already applied.
>
> As you said, common code for DMA code can be best solution.
> However, currently, the code is nothing.
> So, I want you to accept our driver as first step.
> Because I think supporting new device is more important for linux than
> dmaengine common.
>
> thanks
--
~Vinod
On Fri, May 25, 2012 at 03:50:31PM +0530, Vinod Koul wrote:
> On Fri, 2012-05-25 at 18:30 +0900, Tomoya MORINAGA wrote:
> > On Thu, May 24, 2012 at 7:07 PM, Mark Brown
> > I'm not so familiar with Linux's DMA idea.
> > So we don't know whether non-cyclic dmaengine has problem or not.
Nobody has written the code, this is the problem! If the code is not
there, you should try to write it. If there is some great problem
writing the code then you should t
> First you should not be writing your own dma driver, it *needs* to use
> dmaenegine. We already have bunch of driver supported, so there may be a
He's already done that, their current code is all open coded dmaengine
stuff.
> > As you said, common code for DMA code can be best solution.
> > However, currently, the code is nothing.
> > So, I want you to accept our driver as first step.
> > Because I think supporting new device is more important for linux than
> > dmaengine common.
The existing code is far from nothing, there is a fairly substantial
dmaengine library there already which should share a big chunk of code
with any cyclic support. If you were saying "this is too hard for
$REASON" that'd be one thing but that's not what you're saying here.
It's possible that there is actually some substantial difficult but
my first instinct would be that it should be relatively straightforward.
On Fri, May 25, 2012 at 7:20 PM, Vinod Koul <[email protected]> wrote:
>> >> > Nobody seems to be working on it as far as I can tell, I've certainly
>> >> > not seen any patches.
>> >
>> >> If so, could you accept current platform/machine driver ?
>> >
>> > Ideally what would be happening here is that you or other people who
>> > have such systems would be working to add the required support to the
>> > core code, there's clearly a need for common code here as there are a
>> > number of different systems that don't have cyclic DMA and it wouldn't
>> > be great to end up with duplicated code.
>> >
>> > Is there some great difficulty in factoring out the support for
>> > non-cyclic audio DMA on dmaengine - it seems like if there is we must
>> > have a serious problem in dmaengine which we should fix? ?If there is a
>> > substantial difficulty then that's different but it doesn't feel like
>> > we've tried doing common code yet, if there's problems doing that I'd
>> > like to understand what they are before we jump ahead of ourselves.
>>
>> I'm not so familiar with Linux's DMA idea.
>> So we don't know whether non-cyclic dmaengine has problem or not.
> First you should not be writing your own dma driver, it *needs* to use
> dmaenegine. We already have bunch of driver supported, so there may be a
> case that existing driver works straight or with little modifications.
> Using your own dma driver is a dead road, so sooner you move over better
> it is.
I've never developed our own dma driver.
I've developed our ASoC driver using linux standard DMA framework.
--
ROHM Co., Ltd.
tomoya
On Mon, May 28, 2012 at 7:19 AM, Mark Brown
<[email protected]> wrote:
>> > I'm not so familiar with Linux's DMA idea.
>> > So we don't know whether non-cyclic dmaengine has problem or not.
>
> Nobody has written the code, this is the problem! ?If the code is not
> there, you should try to write it. ?If there is some great problem
> writing the code then you should t
The latter of the above seems dropped...
>> First you should not be writing your own dma driver, it *needs* to use
>> dmaenegine. We already have bunch of driver supported, so there may be a
>
> He's already done that, their current code is all open coded dmaengine
> stuff.
I don't understand why you say so ?
I don't use any own dma driver, right ? I use only dmaengine's.
If there is own, let me show.
>> > As you said, common code for DMA code can be best solution.
>> > However, currently, the code is nothing.
>> > So, I want you to accept our driver as first step.
>> > Because I think supporting new device is more important for linux than
>> > dmaengine common.
>
> The existing code is far from nothing, there is a fairly substantial
> dmaengine library there already which should share a big chunk of code
> with any cyclic support. ?If you were saying "this is too hard for
> $REASON" that'd be one thing but that's not what you're saying here.
If our ASoC supports cyclic dma mode, we must modify both pch_dma
driver and our ASoC driver.
I don't want to do this.
Because I can't understand the merit. In plain words, to me, this
looks insignificant things.
In fact, current all applied ASoC drivers use dmaengine don't use
cyclic mode, right ?
> It's possible that there is actually some substantial difficult but
> my first instinct would be that it should be relatively straightforward.
Let me clarify your saying again.
Which do you want ?
1) pch_dma must support cyclic dma mode and our ASoC driver must use
the cyclic dma function.
2) Non-cyclic dma engine should be added to alsa-dmaengine by myself.
3) Other
Thanks
--
ROHM Co., Ltd.
tomoya
On Wed, May 30, 2012 at 07:50:28PM +0900, Tomoya MORINAGA wrote:
> On Mon, May 28, 2012 at 7:19 AM, Mark Brown
> <[email protected]> wrote:
> > Nobody has written the code, this is the problem! ?If the code is not
> > there, you should try to write it. ?If there is some great problem
> > writing the code then you should t
> The latter of the above seems dropped...
...tell us.
> >> First you should not be writing your own dma driver, it *needs* to use
> >> dmaenegine. We already have bunch of driver supported, so there may be a
> > He's already done that, their current code is all open coded dmaengine
> > stuff.
> I don't understand why you say so ?
> I don't use any own dma driver, right ? I use only dmaengine's.
> If there is own, let me show.
Please re-read what I wrote.
> > The existing code is far from nothing, there is a fairly substantial
> > dmaengine library there already which should share a big chunk of code
> > with any cyclic support. ?If you were saying "this is too hard for
> > $REASON" that'd be one thing but that's not what you're saying here.
> If our ASoC supports cyclic dma mode, we must modify both pch_dma
> driver and our ASoC driver.
No, all current mainline drivers using the library use cyclic DMA.
> I don't want to do this.
> Because I can't understand the merit. In plain words, to me, this
> looks insignificant things.
The purpose of this change is to factor code out of individual drivers
into generic code rather than having lots of people writing exactly the
same code. Code duplication at this level is pointless and makes more
work for everyone who will have to maintain the code going forward.
Having looked at Russell's out of tree code I'm even more convinced that
the amount of new code needed for non-cyclic DMA should be pretty
trivial.
> > It's possible that there is actually some substantial difficult but
> > my first instinct would be that it should be relatively straightforward.
> Let me clarify your saying again.
> Which do you want ?
> 1) pch_dma must support cyclic dma mode and our ASoC driver must use
> the cyclic dma function.
> 2) Non-cyclic dma engine should be added to alsa-dmaengine by myself.
Either of these options are fine.
> 3) Other
This would be someone else doing one of the above things.
On Wed, May 30, 2012 at 9:14 PM, Mark Brown
<[email protected]> wrote:
>> >> First you should not be writing your own dma driver, it *needs* to use
>> >> dmaenegine. We already have bunch of driver supported, so there may be a
>> > He's already done that, their current code is all open coded dmaengine
>> > stuff.
>> I don't understand why you say so ?
>> I don't use any own dma driver, right ? I use only dmaengine's.
>> If there is own, let me show.
> Please re-read what I wrote.
Let me clarify.
Do you say native DMA driver API like dmaengine_prep_slave_sg(),
dmaengine_submit() shouldn't be used from ASoC driver, right ?
>> > The existing code is far from nothing, there is a fairly substantial
>> > dmaengine library there already which should share a big chunk of code
>> > with any cyclic support. ?If you were saying "this is too hard for
>> > $REASON" that'd be one thing but that's not what you're saying here.
>
>> If our ASoC supports cyclic dma mode, we must modify both pch_dma
>> driver and our ASoC driver.
>
> No, all current mainline drivers using the library use cyclic DMA.
I can't see any driver uses cyclic DMA. (I saw linux-next's tree from
kernel.org.)
Where is your saying "current mainline" ?
>> I don't want to do this.
>> Because I can't understand the merit. In plain words, to me, this
>> looks insignificant things.
> The purpose of this change is to factor code out of individual drivers
> into generic code rather than having lots of people writing exactly the
> same code. ?Code duplication at this level is pointless and makes more
> work for everyone who will have to maintain the code going forward.
I understand your saying "merit".
However I think it seems difficult for supporting all devices.
Because hardware dependency control code can't be added.
For example, for ML7213, needs interrupt control both before/after DMA transfer.
However, in case of using soc-dmaengine, the control can't be done.
Because the processing is in soc-dmaengine.
> Having looked at Russell's out of tree code I'm even more convinced that
> the amount of new code needed for non-cyclic DMA should be pretty
> trivial.
I don't know what you are talking about.
thanks.
--
ROHM Co., Ltd.
tomoya
On Thu, May 31, 2012 at 02:38:30PM +0900, Tomoya MORINAGA wrote:
> On Wed, May 30, 2012 at 9:14 PM, Mark Brown
> > Please re-read what I wrote.
> Let me clarify.
> Do you say native DMA driver API like dmaengine_prep_slave_sg(),
> dmaengine_submit() shouldn't be used from ASoC driver, right ?
Your driver should be written in terms of the ASoC DMA framework.
> > No, all current mainline drivers using the library use cyclic DMA.
> I can't see any driver uses cyclic DMA. (I saw linux-next's tree from
> kernel.org.)
> Where is your saying "current mainline" ?
Linus' tree, or mine. Have you even looked at the soc-dmaengine-pcm
code? It uncondtionally requests a cyclic channel.
> However I think it seems difficult for supporting all devices.
> Because hardware dependency control code can't be added.
> For example, for ML7213, needs interrupt control both before/after DMA transfer.
> However, in case of using soc-dmaengine, the control can't be done.
> Because the processing is in soc-dmaengine.
Please be more specific. What are the concrete problems that you see?
Why is it not possible to address them within the framework?
On Thu, May 31, 2012 at 7:45 PM, Mark Brown
<[email protected]> wrote:
>> > Please re-read what I wrote.
>
>> Let me clarify.
>> Do you say native DMA driver API like dmaengine_prep_slave_sg(),
>> dmaengine_submit() shouldn't be used from ASoC driver, right ?
>
> Your driver should be written in terms of the ASoC DMA framework.
I understand your order.
But isn't it only me ?
You mean all ASoC driver uses dmaengine should be written in terms of
the ASoC DMA framework.
Right ?
>> > No, all current mainline drivers using the library use cyclic DMA.
>> I can't see any driver uses cyclic DMA. (I saw linux-next's tree from
>> kernel.org.)
>> Where is your saying "current mainline" ?
> Linus' tree, or mine.
Sorry, I couldn't find.
Is your saying Linus's tree this ?
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
However, any ASoC driver doesn't use cyclic DMA's.
> Have you even looked at the soc-dmaengine-pcm
> code? ?It uncondtionally requests a cyclic channel.
I already saw soc-dmaengine-pcm.c
>> However I think it seems difficult for supporting all devices.
>> Because hardware dependency control code can't be added.
>> For example, for ML7213, needs interrupt control both before/after DMA transfer.
>> However, ?in case of using soc-dmaengine, the control can't be done.
>> Because the processing is in soc-dmaengine.
> Please be more specific. ?What are the concrete problems that you see?
> Why is it not possible to address them within the framework?
I show the code.
+static void i2s_dma_tx_complete(void *arg)
+{
...
+
+ ioh_i2s_irq_ctrl(ioh->number, SNDRV_PCM_STREAM_PLAYBACK,
IOH_EN_IRQ); ##<<Interrupt control
+}
Our device needs interrupt control both before/after DMA transfer like above.
In your soc-dma-engine, DMA transfer complete code is in soc-dma-engine, right ?
So, the vendor specific code like the above can't be written.
thanks.
--
ROHM Co., Ltd.
tomoya
On Fri, Jun 01, 2012 at 05:13:45PM +0900, Tomoya MORINAGA wrote:
> > Linus' tree, or mine.
> Sorry, I couldn't find.
> Is your saying Linus's tree this ?
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> However, any ASoC driver doesn't use cyclic DMA's.
$ grep CYCLIC sound/soc/soc-dmaengine-pcm.c
dma_cap_set(DMA_CYCLIC, mask);
On Fri, Jun 1, 2012 at 5:30 PM, Mark Brown
<[email protected]> wrote:
> > Sorry, I couldn't find.
> > Is your saying Linus's tree this ?
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > However, any ASoC driver doesn't use cyclic DMA's.
>
> $ grep CYCLIC sound/soc/soc-dmaengine-pcm.c
> ? ? ? ?dma_cap_set(DMA_CYCLIC, mask);
I already saw this.
You said "all current mainline drivers using the library use cyclic DMA."
Does this mean the following drivers use "snd_dmaengine_pcm_open" ?
ep93xx-pcm
imx-pcm-dma-mx2
mxs-pcm
However, the following drivers don't use any ASoC DMA framework, right ?.
E.g. these drivers call dma_request_channel directly.
siu_pcm
fsi
txx9aclc
That is to say, some drivers ASoC DMA framework. However some drivers
don't use any ASoC DMA framework.
Why didn't you do porting to your saying "ASoC DMA framework"?
thanks.
--
ROHM Co., Ltd.
tomoya
On Mon, Jun 11, 2012 at 04:05:56PM +0900, Tomoya MORINAGA wrote:
> That is to say, some drivers ASoC DMA framework. However some drivers
> don't use any ASoC DMA framework.
There are some drivers that predate the availibility of the dmaengine
framework.
> Why didn't you do porting to your saying "ASoC DMA framework"?
This, and the fact that the PCH driver uses dmaengine without using any
shared code, is the topic of the discussion. It is entirely natural
that there are no open coded drivers using cyclic DMA via dmaengine,
they have all had that code factored out.
Please stop this and at least look at factoring this code out. If it
turns out that there's some reason why it's a lot of work that's one
thing but it seems clear that you've not even looked yet. It's like the
previous issues where you were sending patches which would clearly not
run successfully, it's not a very positive approach.
On Mon, Jun 11, 2012 at 5:54 PM, Mark Brown
<[email protected]> wrote:
> There are some drivers that predate the availibility of the dmaengine
> framework.
In case, you develop a new ASoC framework, all previous ASoC drivers
should be adopted to the framework by yourself, don't you ?
Because a new developer must be confused by this.
> This, and the fact that the PCH driver uses dmaengine without using any
> shared code, is the topic of the discussion. ?It is entirely natural
> that there are no open coded drivers using cyclic DMA via dmaengine,
> they have all had that code factored out.
>
> Please stop this and at least look at factoring this code out. ?If it
> turns out that there's some reason why it's a lot of work that's one
> thing but it seems clear that you've not even looked yet. ?It's like the
> previous issues where you were sending patches which would clearly not
> run successfully, it's not a very positive approach.
OK, I'll stop this.
I wanted to finish adding these patch series to upstream because we
spent much resource on this.
But I'm involved in other work, so I can't start now.
Until now thank you for your support.
Regards.
--
ROHM Co., Ltd.
tomoya
On Wed, Jun 13, 2012 at 07:41:57PM +0900, Tomoya MORINAGA wrote:
> On Mon, Jun 11, 2012 at 5:54 PM, Mark Brown
> > There are some drivers that predate the availibility of the dmaengine
> > framework.
> In case, you develop a new ASoC framework, all previous ASoC drivers
> should be adopted to the framework by yourself, don't you ?
> Because a new developer must be confused by this.
This is exactly what Lars-Peter did, he updated all the drivers that
used cyclic mode to use the framework. Drivers using non-cyclic mode
weren't updated as there is some additional work needed in the
framework.
That said, you don't always want to do this - depending on the change
involved it's sometimes simpler and easier to move things over piecemeal
unless there's an actual issue being created by the lack of the new
firmware.