Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1512166 > unrolled thread

Re: [PATCH] m32r: add simple dma

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] m32r: add simple dma Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-10-30 19:20 +0100
    Re: [PATCH] m32r: add simple dma Andrew Morton <akpm@linux-foundation.org> - 2016-11-03 20:20 +0100
      Re: [PATCH] m32r: add simple dma Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-11-08 21:10 +0100

#1512166 — Re: [PATCH] m32r: add simple dma

Hi Andrew,

On Friday 21 October 2016 08:59 AM, Andrew Morton wrote:
> On Sat,  8 Oct 2016 23:23:18 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>> Some builds of m32r were failing as it tried to build few drivers which
>> needed dma but m32r is not having dma support. Objections were raised
>> when it was tried to make those drivers depend on HAS_DMA.
>
> Huh.  What were these objections?  That sounds like the appropriate
> fix.  And I suggest that a summary of those objections be captured in
> this patch's changelog.

Sorry for the delay in reply. Got busy in dayjob and relocation.

I was asked to provide dma stubs instead of adding HAS_DMA in the Kconfig.

http://www.spinics.net/lists/kernel/msg2277152.html

And an old thread-
http://www.spinics.net/lists/alsa-devel/msg50931.html

It appeared to me that instead of adding dma stubs and returning error 
values from them it will be better to add dma_noop to m32r. Looking at 
the simplicity of dma_noop it seems that it should work.
What will you suggest? Do i send v2 after adding the "dma stub" comment 
and the link to the thread in the commit message or should I opt for dma 
stub?

>
>> So the next
>> best thing is to add dma support to m32r.
>> dma_noop is a very simple dma with 1:1 memory mapping.
>>
>> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>> ---
>>
>> Hi Andrew,
>> Just to let you know that this was not tested on any board. I think I
>> have told you earlier that inspite of all  my efforts I could not find
>>   any source of information to procure a board of m32r.
>
> It is a worry.  We're saying "m32r linux now supports these drivers",
> only we don't know if that is true.

FYI, I tried to contact Renesas for m32r boards and this is the reply I 
received (Dated- Jan 20, 2016):
"
Hi Sudip-san,
I’m afraid but I don’t know about m32r.
Also I searched our private web site, I could not find usuful 
information about m32r…
Best regards,
Yoshihiro Shimoda
"


Regards
Sudip

[toc] | [next] | [standalone]

#1514790

On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> On Friday 21 October 2016 08:59 AM, Andrew Morton wrote:
> > On Sat,  8 Oct 2016 23:23:18 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> >
> >> Some builds of m32r were failing as it tried to build few drivers which
> >> needed dma but m32r is not having dma support. Objections were raised
> >> when it was tried to make those drivers depend on HAS_DMA.
> >
> > Huh.  What were these objections?  That sounds like the appropriate
> > fix.  And I suggest that a summary of those objections be captured in
> > this patch's changelog.
> 
> Sorry for the delay in reply. Got busy in dayjob and relocation.
> 
> I was asked to provide dma stubs instead of adding HAS_DMA in the Kconfig.
> 
> http://www.spinics.net/lists/kernel/msg2277152.html
> 
> And an old thread-
> http://www.spinics.net/lists/alsa-devel/msg50931.html
> 
> It appeared to me that instead of adding dma stubs and returning error 
> values from them it will be better to add dma_noop to m32r. Looking at 
> the simplicity of dma_noop it seems that it should work.
> What will you suggest? Do i send v2 after adding the "dma stub" comment 
> and the link to the thread in the commit message or should I opt for dma 
> stub?

Disabling DMA in Kconfig is the most cautious approach.  If someone
cares then they will be able to runtime test the thing, so those people
can implement dma_noop (or something else).

On the other hand, we could just go ahead and wire up dma_noop and if
someone later has problems with it, they will report or fix those
problems.

So, umm, I guess that wiring up dma_noop gets us further forward than
simply disabling everything, so how about we do that?

[toc] | [prev] | [next] | [standalone]

#1517541

On Thursday 03 November 2016 07:13 PM, Andrew Morton wrote:
> On Sun, 30 Oct 2016 23:47:29 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>> On Friday 21 October 2016 08:59 AM, Andrew Morton wrote:
>>> On Sat,  8 Oct 2016 23:23:18 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>>>
>>>> Some builds of m32r were failing as it tried to build few drivers which
>>>> needed dma but m32r is not having dma support. Objections were raised
>>>> when it was tried to make those drivers depend on HAS_DMA.
>>>
>>> Huh.  What were these objections?  That sounds like the appropriate
>>> fix.  And I suggest that a summary of those objections be captured in
>>> this patch's changelog.
>>
>> Sorry for the delay in reply. Got busy in dayjob and relocation.
>>
>> I was asked to provide dma stubs instead of adding HAS_DMA in the Kconfig.
>>
>> http://www.spinics.net/lists/kernel/msg2277152.html
>>
>> And an old thread-
>> http://www.spinics.net/lists/alsa-devel/msg50931.html
>>
>> It appeared to me that instead of adding dma stubs and returning error
>> values from them it will be better to add dma_noop to m32r. Looking at
>> the simplicity of dma_noop it seems that it should work.
>> What will you suggest? Do i send v2 after adding the "dma stub" comment
>> and the link to the thread in the commit message or should I opt for dma
>> stub?
>
> Disabling DMA in Kconfig is the most cautious approach.  If someone
> cares then they will be able to runtime test the thing, so those people
> can implement dma_noop (or something else).
>
> On the other hand, we could just go ahead and wire up dma_noop and if
> someone later has problems with it, they will report or fix those
> problems.
>
> So, umm, I guess that wiring up dma_noop gets us further forward than
> simply disabling everything, so how about we do that?
>

Again sorry for the delayed reply. But I am all set now. Relocating from 
one country to another is a tough one.
Do I send you v2 of the patch with the links in the commit message?

Regards
Sudip

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web