[PATCH] m32r: add simple dma

[PATCH] m32r: add simple dma

[Sudip Mukherjee]

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. 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.

Hi Fengguang,
If Andrew accepts this patch then it will open pandora's box as lots of
other drivers which were never build for m32r will be built now and you
are going to gets lots and lots of new build warnings. But nothing
breaks.

 arch/m32r/Kconfig                   |  2 +-
 arch/m32r/include/asm/device.h      |  6 +++++-
 arch/m32r/include/asm/dma-mapping.h | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 arch/m32r/include/asm/dma-mapping.h

diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 3cc8498..d227a69 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -34,7 +34,7 @@ config NO_IOPORT_MAP
 	def_bool y
 
 config NO_DMA
-	def_bool y
+	def_bool n
 
 config HZ
 	int
diff --git a/arch/m32r/include/asm/device.h b/arch/m32r/include/asm/device.h
index d8f9872..4a9f35e 100644
--- a/arch/m32r/include/asm/device.h
+++ b/arch/m32r/include/asm/device.h
@@ -3,5 +3,9 @@
  *
  * This file is released under the GPLv2
  */
-#include <asm-generic/device.h>
+struct dev_archdata {
+	struct dma_map_ops *dma_ops;
+};
 
+struct pdev_archdata {
+};
diff --git a/arch/m32r/include/asm/dma-mapping.h b/arch/m32r/include/asm/dma-mapping.h
new file mode 100644
index 0000000..1666ca6
--- /dev/null
+++ b/arch/m32r/include/asm/dma-mapping.h
@@ -0,0 +1,32 @@
+#ifndef _ASM_M32R_DMA_MAPPING_H
+#define _ASM_M32R_DMA_MAPPING_H
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/scatterlist.h>
+#include <linux/dma-debug.h>
+#include <linux/io.h>
+
+#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
+
+static inline struct dma_map_ops *get_dma_ops(struct device *dev)
+{
+	if (dev && dev->archdata.dma_ops)
+		return dev->archdata.dma_ops;
+	return &dma_noop_ops;
+}
+
+static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
+				  enum dma_data_direction direction)
+{
+}
+
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+	if (!dev->dma_mask)
+		return false;
+	return addr + size - 1 <= *dev->dma_mask;
+}
+
+#endif /* _ASM_M32R_DMA_MAPPING_H */
-- 
1.9.1

Re: [PATCH] m32r: add simple dma

[Andrew Morton]

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.

> 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.

> Hi Fengguang,
> If Andrew accepts this patch then it will open pandora's box as lots of
> other drivers which were never build for m32r will be built now and you
> are going to gets lots and lots of new build warnings. But nothing
> breaks.

Re: [PATCH] m32r: add simple dma

[Sudip Mukherjee]

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

Re: [PATCH] m32r: add simple dma

[Andrew Morton]

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?

Re: [PATCH] m32r: add simple dma

[Sudip Mukherjee]

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