From: dillon min <[email protected]>
when do mmap on /dev/fb0, we will get -6 error on cortex-m3/m4 or armv7m
platform without cache support, this is caused by following reason:
on armv7m platform, if no cache support, we will use dma direct mapping,
but, this is not support on !MMU hardware, just return '-ENXIO' error
so, add use_reserved_mem() for these armv7m hardware but no-cache support.
eg, stm32f429/stm32f469.
verified on stm32f469-disco board, mmap frambuffer to userspace.
dillon min (2):
ARM: dts: stm32: Setup 4M bytes reserved memory for mmap
arm-nommu: Add use_reserved_mem() to check if device support reserved
memory
arch/arm/boot/dts/stm32f469-disco.dts | 14 ++++++++++++++
arch/arm/mm/dma-mapping-nommu.c | 28 +++++++++++++++++++++++++++-
2 files changed, 41 insertions(+), 1 deletion(-)
--
2.7.4
From: dillon min <[email protected]>
To mmap a framebuffer or v4l2 buffer from kernel to userspace on
no-mmu platform, we need rely on 'arm_nommu_dma_ops' from
arch/arm/mm/dma-mapping-nommu.c , so setup 4M bytes memory
reserved for this purpose.
Signed-off-by: dillon min <[email protected]>
---
arch/arm/boot/dts/stm32f469-disco.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 9397db0c43de..082b24ee81f7 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -65,6 +65,20 @@
reg = <0x00000000 0x1000000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,dma {
+ compatible = "shared-dma-pool";
+ size = <0x400000>;
+ no-map;
+ linux,dma-default;
+ };
+
+ };
+
aliases {
serial0 = &usart3;
};
--
2.7.4
From: dillon min <[email protected]>
Currently, we use dma direct to request coherent memory for driver on armv7m
platform if 'cacheid' is zero, but dma_direct_can_mmap() is return false,
dma_direct_mmap() return -ENXIO for CONFIG_MMU undefined platform.
so we have to back to use 'arm_nommu_dma_ops', add use_reserved_mem() to check
if device support global or device corherent memory. if yes, then call
set_dma_ops()
Signed-off-by: dillon min <[email protected]>
---
arch/arm/mm/dma-mapping-nommu.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index 287ef898a55e..e1c213fec152 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -14,6 +14,7 @@
#include <asm/cacheflush.h>
#include <asm/outercache.h>
#include <asm/cp15.h>
+#include <linux/of.h>
#include "dma.h"
@@ -188,6 +189,31 @@ const struct dma_map_ops arm_nommu_dma_ops = {
};
EXPORT_SYMBOL(arm_nommu_dma_ops);
+static bool use_reserved_mem(struct device *dev)
+{
+ struct device_node *np;
+
+ np = of_find_node_by_path("/reserved-memory/linux,dma");
+
+ if (np &&
+ of_device_is_compatible(np, "shared-dma-pool") &&
+ of_property_read_bool(np, "no-map") &&
+ of_property_read_bool(np, "linux,dma-default")) {
+ /* has global corherent mem support */
+ of_node_put(np);
+ return true;
+ }
+
+ np = of_parse_phandle(dev->of_node, "memory-region", 0);
+ if (np) {
+ /* has dev corherent mem support */
+ of_node_put(np);
+ return true;
+ }
+
+ return false;
+}
+
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
const struct iommu_ops *iommu, bool coherent)
{
@@ -206,6 +232,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
dev->archdata.dma_coherent = (get_cr() & CR_M) ? coherent : true;
}
- if (!dev->archdata.dma_coherent)
+ if (!dev->archdata.dma_coherent || use_reserved_mem(dev))
set_dma_ops(dev, &arm_nommu_dma_ops);
}
--
2.7.4
On 6/8/20 9:30 AM, [email protected] wrote:
> From: dillon min <[email protected]>
>
> Currently, we use dma direct to request coherent memory for driver on armv7m
> platform if 'cacheid' is zero, but dma_direct_can_mmap() is return false,
> dma_direct_mmap() return -ENXIO for CONFIG_MMU undefined platform.
>
> so we have to back to use 'arm_nommu_dma_ops', add use_reserved_mem() to check
> if device support global or device corherent memory. if yes, then call
> set_dma_ops()
>
> Signed-off-by: dillon min <[email protected]>
> ---
> arch/arm/mm/dma-mapping-nommu.c | 28 +++++++++++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> index 287ef898a55e..e1c213fec152 100644
> --- a/arch/arm/mm/dma-mapping-nommu.c
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -14,6 +14,7 @@
> #include <asm/cacheflush.h>
> #include <asm/outercache.h>
> #include <asm/cp15.h>
> +#include <linux/of.h>
>
> #include "dma.h"
>
> @@ -188,6 +189,31 @@ const struct dma_map_ops arm_nommu_dma_ops = {
> };
> EXPORT_SYMBOL(arm_nommu_dma_ops);
>
> +static bool use_reserved_mem(struct device *dev)
> +{
> + struct device_node *np;
> +
> + np = of_find_node_by_path("/reserved-memory/linux,dma");
> +
> + if (np &&
> + of_device_is_compatible(np, "shared-dma-pool") &&
> + of_property_read_bool(np, "no-map") &&
> + of_property_read_bool(np, "linux,dma-default")) {
> + /* has global corherent mem support */
> + of_node_put(np);
> + return true;
> + }
> +
> + np = of_parse_phandle(dev->of_node, "memory-region", 0);
> + if (np) {
> + /* has dev corherent mem support */
> + of_node_put(np);
> + return true;
> + }
> +
> + return false;
> +}
> +
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
> @@ -206,6 +232,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> dev->archdata.dma_coherent = (get_cr() & CR_M) ? coherent : true;
> }
>
> - if (!dev->archdata.dma_coherent)
> + if (!dev->archdata.dma_coherent || use_reserved_mem(dev))
> set_dma_ops(dev, &arm_nommu_dma_ops);
> }
>
Sorry I have to NAK this hack :(
Digging git history reveled 79964a1c2972 ("ARM: 8633/1: nommu: allow mmap when !CONFIG_MMU")
which make me wonder if diff below does the trick for you
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8f4bbda..8623b9e 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
#else /* CONFIG_MMU */
bool dma_direct_can_mmap(struct device *dev)
{
- return false;
+ return true;
}
int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- return -ENXIO;
+ return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end - vma->vm_start));;
}
#endif /* CONFIG_MMU */
Cheers
Vladimir
Hi Vladimir,
Thanks for reviewing.
Hi Christoph Hellwig,
I just want to know if kernel dma mapping/direct is focused on
platforms with MMU.
leave arch code to handle dma coherent memory management themself for
no-MMU platform.
so, you just return error code in kernel/dma/mapping.c,direct.c
without CONFIG_MMU defined ?
which means dma-direct mapping doesn't support !CONFIG_MMU is not a
bug, but design as it's.
or, just return error code currently, will add dma direct mapping
support for !CONFIG_MMU in the
future?
As Vladimir Murzin's suggestion has changes in kernel code, I need
your input to get
the design goal about dma-direct mapping, thanks.
On Tue, Jun 9, 2020 at 10:07 PM Vladimir Murzin <[email protected]> wrote:
>
> On 6/8/20 9:30 AM, [email protected] wrote:
> > From: dillon min <[email protected]>
> >
> > Currently, we use dma direct to request coherent memory for driver on armv7m
> > platform if 'cacheid' is zero, but dma_direct_can_mmap() is return false,
> > dma_direct_mmap() return -ENXIO for CONFIG_MMU undefined platform.
> >
> > so we have to back to use 'arm_nommu_dma_ops', add use_reserved_mem() to check
> > if device support global or device corherent memory. if yes, then call
> > set_dma_ops()
> >
> > Signed-off-by: dillon min <[email protected]>
> > ---
> > arch/arm/mm/dma-mapping-nommu.c | 28 +++++++++++++++++++++++++++-
> > 1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> > index 287ef898a55e..e1c213fec152 100644
> > --- a/arch/arm/mm/dma-mapping-nommu.c
> > +++ b/arch/arm/mm/dma-mapping-nommu.c
> > @@ -14,6 +14,7 @@
> > #include <asm/cacheflush.h>
> > #include <asm/outercache.h>
> > #include <asm/cp15.h>
> > +#include <linux/of.h>
> >
> > #include "dma.h"
> >
> > @@ -188,6 +189,31 @@ const struct dma_map_ops arm_nommu_dma_ops = {
> > };
> > EXPORT_SYMBOL(arm_nommu_dma_ops);
> >
> > +static bool use_reserved_mem(struct device *dev)
> > +{
> > + struct device_node *np;
> > +
> > + np = of_find_node_by_path("/reserved-memory/linux,dma");
> > +
> > + if (np &&
> > + of_device_is_compatible(np, "shared-dma-pool") &&
> > + of_property_read_bool(np, "no-map") &&
> > + of_property_read_bool(np, "linux,dma-default")) {
> > + /* has global corherent mem support */
> > + of_node_put(np);
> > + return true;
> > + }
> > +
> > + np = of_parse_phandle(dev->of_node, "memory-region", 0);
> > + if (np) {
> > + /* has dev corherent mem support */
> > + of_node_put(np);
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> > const struct iommu_ops *iommu, bool coherent)
> > {
> > @@ -206,6 +232,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> > dev->archdata.dma_coherent = (get_cr() & CR_M) ? coherent : true;
> > }
> >
> > - if (!dev->archdata.dma_coherent)
> > + if (!dev->archdata.dma_coherent || use_reserved_mem(dev))
> > set_dma_ops(dev, &arm_nommu_dma_ops);
> > }
> >
>
> Sorry I have to NAK this hack :(
>
> Digging git history reveled 79964a1c2972 ("ARM: 8633/1: nommu: allow mmap when !CONFIG_MMU")
> which make me wonder if diff below does the trick for you
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 8f4bbda..8623b9e 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> #else /* CONFIG_MMU */
> bool dma_direct_can_mmap(struct device *dev)
> {
> - return false;
> + return true;
> }
>
> int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> unsigned long attrs)
> {
> - return -ENXIO;
> + return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end - vma->vm_start));;
> }
> #endif /* CONFIG_MMU */
Yes, this is a quite nice way to support !CONFIG_MMU without cache on
platforms. I will try your suggestion.
thanks
>
> Cheers
> Vladimir
On Tue, Jun 09, 2020 at 11:22:24PM +0800, dillon min wrote:
> Hi Vladimir,
>
> Thanks for reviewing.
>
> Hi Christoph Hellwig,
>
> I just want to know if kernel dma mapping/direct is focused on
> platforms with MMU.
> leave arch code to handle dma coherent memory management themself for
> no-MMU platform.
No, I'd really like to consolidate everything that isn't overly
arch specific eventually.
>
> so, you just return error code in kernel/dma/mapping.c,direct.c
> without CONFIG_MMU defined ?
> which means dma-direct mapping doesn't support !CONFIG_MMU is not a
> bug, but design as it's.
> or, just return error code currently, will add dma direct mapping
> support for !CONFIG_MMU in the
> future?
>
> As Vladimir Murzin's suggestion has changes in kernel code, I need
> your input to get
> the design goal about dma-direct mapping, thanks.
Can someone repost the whole patch?
On 6/9/20 4:36 PM, Christoph Hellwig wrote:
> On Tue, Jun 09, 2020 at 11:22:24PM +0800, dillon min wrote:
>> Hi Vladimir,
>>
>> Thanks for reviewing.
>>
>> Hi Christoph Hellwig,
>>
>> I just want to know if kernel dma mapping/direct is focused on
>> platforms with MMU.
>> leave arch code to handle dma coherent memory management themself for
>> no-MMU platform.
>
> No, I'd really like to consolidate everything that isn't overly
> arch specific eventually.
>
>>
>> so, you just return error code in kernel/dma/mapping.c,direct.c
>> without CONFIG_MMU defined ?
>> which means dma-direct mapping doesn't support !CONFIG_MMU is not a
>> bug, but design as it's.
>> or, just return error code currently, will add dma direct mapping
>> support for !CONFIG_MMU in the
>> future?
>>
>> As Vladimir Murzin's suggestion has changes in kernel code, I need
>> your input to get
>> the design goal about dma-direct mapping, thanks.
>
> Can someone repost the whole patch?
>
Happy to repost as separate patch once dillon confirms it actually works.
Meanwhile, I'm trying to understand at which point we lost this
functionality for NOMMU... maybe it will become different patch :)
Cheers
Vladimir
Hi Christoph Hellwig,
This is the patchset. for your reference.
thanks,
On Mon, Jun 8, 2020 at 4:30 PM <[email protected]> wrote:
>
> From: dillon min <[email protected]>
>
> To mmap a framebuffer or v4l2 buffer from kernel to userspace on
> no-mmu platform, we need rely on 'arm_nommu_dma_ops' from
> arch/arm/mm/dma-mapping-nommu.c , so setup 4M bytes memory
> reserved for this purpose.
>
> Signed-off-by: dillon min <[email protected]>
> ---
> arch/arm/boot/dts/stm32f469-disco.dts | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 9397db0c43de..082b24ee81f7 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -65,6 +65,20 @@
> reg = <0x00000000 0x1000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + size = <0x400000>;
> + no-map;
> + linux,dma-default;
> + };
> +
> + };
> +
> aliases {
> serial0 = &usart3;
> };
> --
> 2.7.4
>
On 6/9/20 4:43 PM, Vladimir Murzin wrote:
> On 6/9/20 4:36 PM, Christoph Hellwig wrote:
>> On Tue, Jun 09, 2020 at 11:22:24PM +0800, dillon min wrote:
>>> Hi Vladimir,
>>>
>>> Thanks for reviewing.
>>>
>>> Hi Christoph Hellwig,
>>>
>>> I just want to know if kernel dma mapping/direct is focused on
>>> platforms with MMU.
>>> leave arch code to handle dma coherent memory management themself for
>>> no-MMU platform.
>>
>> No, I'd really like to consolidate everything that isn't overly
>> arch specific eventually.
>>
>>>
>>> so, you just return error code in kernel/dma/mapping.c,direct.c
>>> without CONFIG_MMU defined ?
>>> which means dma-direct mapping doesn't support !CONFIG_MMU is not a
>>> bug, but design as it's.
>>> or, just return error code currently, will add dma direct mapping
>>> support for !CONFIG_MMU in the
>>> future?
>>>
>>> As Vladimir Murzin's suggestion has changes in kernel code, I need
>>> your input to get
>>> the design goal about dma-direct mapping, thanks.
>>
>> Can someone repost the whole patch?
>>
>
> Happy to repost as separate patch once dillon confirms it actually works.
>
> Meanwhile, I'm trying to understand at which point we lost this
> functionality for NOMMU... maybe it will become different patch :)
>
mmap operation for dma-noop (ancestor of dma-direct) was proposed
in [1]. It was suggested to change dma_common_map() instead which
was implemented in
07c75d7a6b9e ("drivers: dma-mapping: allow dma_common_mmap() for NOMMU")
that removed CONFIG_MMU drom dma_common_mmap(). Later
62fcee9a3bd7 ("dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP")
reintroduced CONFIG_MMU in dma_common_mmap().
Even though commit mentions ARM, I do not see how mmap would continue
to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations
only in cases where caches are implemented or active, in other cases it
fully relies on dma-direct.
It looks to me that we either should provide NOMMU variant for mmap in
dma/direct or (carefully) fix dma/mapping.
Thoughts?
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/480600.html
Vladimir
> Cheers
> Vladimir
>
Hi Christoph Hellwig,
This is the patchset. for your reference.
thanks,
On Mon, Jun 8, 2020 at 4:30 PM <[email protected]> wrote:
>
> From: dillon min <[email protected]>
>
> when do mmap on /dev/fb0, we will get -6 error on cortex-m3/m4 or armv7m
> platform without cache support, this is caused by following reason:
>
> on armv7m platform, if no cache support, we will use dma direct mapping,
> but, this is not support on !MMU hardware, just return '-ENXIO' error
>
> so, add use_reserved_mem() for these armv7m hardware but no-cache support.
> eg, stm32f429/stm32f469.
>
> verified on stm32f469-disco board, mmap frambuffer to userspace.
>
> dillon min (2):
> ARM: dts: stm32: Setup 4M bytes reserved memory for mmap
> arm-nommu: Add use_reserved_mem() to check if device support reserved
> memory
>
> arch/arm/boot/dts/stm32f469-disco.dts | 14 ++++++++++++++
> arch/arm/mm/dma-mapping-nommu.c | 28 +++++++++++++++++++++++++++-
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> --
> 2.7.4
>
On Tue, Jun 09, 2020 at 05:25:04PM +0100, Vladimir Murzin wrote:
> Even though commit mentions ARM, I do not see how mmap would continue
> to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations
> only in cases where caches are implemented or active, in other cases it
> fully relies on dma-direct.
> It looks to me that we either should provide NOMMU variant for mmap in
> dma/direct or (carefully) fix dma/mapping.
I think dma-direct is the right place, the common helpers in
dma/mapping.c are basically the red headed stepchilds for misc
IOMMU drivers not covered by dma-iommu only.
Hi Vladimir,
I tested your changes, it's working fine on stm32f429-disco(armv7m,
without cache) board.
you can submit a separate patch for dma-direct support on non-mmu
platform, i will drop mine.
thanks.
best regards.
Dillon,
On Wed, Jun 10, 2020 at 1:34 AM Christoph Hellwig <[email protected]> wrote:
>
> On Tue, Jun 09, 2020 at 05:25:04PM +0100, Vladimir Murzin wrote:
> > Even though commit mentions ARM, I do not see how mmap would continue
> > to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations
> > only in cases where caches are implemented or active, in other cases it
> > fully relies on dma-direct.
>
> > It looks to me that we either should provide NOMMU variant for mmap in
> > dma/direct or (carefully) fix dma/mapping.
>
> I think dma-direct is the right place, the common helpers in
> dma/mapping.c are basically the red headed stepchilds for misc
> IOMMU drivers not covered by dma-iommu only.
Yes, thanks Christoph's input.
Ok, I finally found the original patch from Vladimir. Comments below:
> +++ b/kernel/dma/direct.c
> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> #else /* CONFIG_MMU */
> bool dma_direct_can_mmap(struct device *dev)
> {
> - return false;
> + return true;
> }
>
> int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> unsigned long attrs)
> {
> - return -ENXIO;
> + return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end - vma->vm_start));;
I think we should try to reuse the mmu dma_direct_mmap implementation,
which does about the same. This version has been compile tested on
arm-nommu only, let me know what you think: (btw, a nommu_defconfig of
some kind for arm would be nice..)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index d006668c0027d2..e0dae570a51530 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -71,6 +71,7 @@ config SWIOTLB
# in the pagetables
#
config DMA_NONCOHERENT_MMAP
+ default y if !MMU
bool
config DMA_REMAP
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 0a4881e59aa7d6..9ec6a5c3fc578c 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -459,7 +459,6 @@ int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
-#ifdef CONFIG_MMU
bool dma_direct_can_mmap(struct device *dev)
{
return dev_is_dma_coherent(dev) ||
@@ -485,19 +484,6 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
user_count << PAGE_SHIFT, vma->vm_page_prot);
}
-#else /* CONFIG_MMU */
-bool dma_direct_can_mmap(struct device *dev)
-{
- return false;
-}
-
-int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
- return -ENXIO;
-}
-#endif /* CONFIG_MMU */
int dma_direct_supported(struct device *dev, u64 mask)
{
On 6/10/20 8:24 AM, Christoph Hellwig wrote:
> Ok, I finally found the original patch from Vladimir. Comments below:
>
>> +++ b/kernel/dma/direct.c
>> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
>> #else /* CONFIG_MMU */
>> bool dma_direct_can_mmap(struct device *dev)
>> {
>> - return false;
>> + return true;
>> }
>>
>> int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
>> void *cpu_addr, dma_addr_t dma_addr, size_t size,
>> unsigned long attrs)
>> {
>> - return -ENXIO;
>> + return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end - vma->vm_start));;
>
> I think we should try to reuse the mmu dma_direct_mmap implementation,
> which does about the same. This version has been compile tested on
> arm-nommu only, let me know what you think: (btw, a nommu_defconfig of
> some kind for arm would be nice..)
Catch-all nommu_defconfig is not easy for ARM, AFAIK folk carry few hacks
for randconfig...
Meanwhile, known working NOMMU configs
$ git grep "# CONFIG_MMU is not set" arch/arm/configs/
arch/arm/configs/efm32_defconfig:# CONFIG_MMU is not set
arch/arm/configs/lpc18xx_defconfig:# CONFIG_MMU is not set
arch/arm/configs/mps2_defconfig:# CONFIG_MMU is not set
arch/arm/configs/stm32_defconfig:# CONFIG_MMU is not set
arch/arm/configs/vf610m4_defconfig:# CONFIG_MMU is not set
>
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index d006668c0027d2..e0dae570a51530 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -71,6 +71,7 @@ config SWIOTLB
> # in the pagetables
> #
> config DMA_NONCOHERENT_MMAP
> + default y if !MMU
> bool
Nit: def_bool !MMU
>
> config DMA_REMAP
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 0a4881e59aa7d6..9ec6a5c3fc578c 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -459,7 +459,6 @@ int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
> return ret;
> }
>
> -#ifdef CONFIG_MMU
> bool dma_direct_can_mmap(struct device *dev)
> {
> return dev_is_dma_coherent(dev) ||
> @@ -485,19 +484,6 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> user_count << PAGE_SHIFT, vma->vm_page_prot);
> }
> -#else /* CONFIG_MMU */
> -bool dma_direct_can_mmap(struct device *dev)
> -{
> - return false;
> -}
> -
> -int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> - void *cpu_addr, dma_addr_t dma_addr, size_t size,
> - unsigned long attrs)
> -{
> - return -ENXIO;
> -}
> -#endif /* CONFIG_MMU */
>
> int dma_direct_supported(struct device *dev, u64 mask)
> {
>
LGTM. FWIW:
Reviewed-by: Vladimir Murzin <[email protected]>
On 6/10/20 9:19 AM, Vladimir Murzin wrote:
> On 6/10/20 8:24 AM, Christoph Hellwig wrote:
>> Ok, I finally found the original patch from Vladimir. Comments below:
>>
>>> +++ b/kernel/dma/direct.c
>>> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
>>> #else /* CONFIG_MMU */
>>> bool dma_direct_can_mmap(struct device *dev)
>>> {
>>> - return false;
>>> + return true;
>>> }
>>>
>>> int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
>>> void *cpu_addr, dma_addr_t dma_addr, size_t size,
>>> unsigned long attrs)
>>> {
>>> - return -ENXIO;
>>> + return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end - vma->vm_start));;
>>
>> I think we should try to reuse the mmu dma_direct_mmap implementation,
>> which does about the same. This version has been compile tested on
>> arm-nommu only, let me know what you think: (btw, a nommu_defconfig of
>> some kind for arm would be nice..)
>
> Catch-all nommu_defconfig is not easy for ARM, AFAIK folk carry few hacks
> for randconfig...
>
> Meanwhile, known working NOMMU configs
>
> $ git grep "# CONFIG_MMU is not set" arch/arm/configs/
> arch/arm/configs/efm32_defconfig:# CONFIG_MMU is not set
> arch/arm/configs/lpc18xx_defconfig:# CONFIG_MMU is not set
> arch/arm/configs/mps2_defconfig:# CONFIG_MMU is not set
> arch/arm/configs/stm32_defconfig:# CONFIG_MMU is not set
> arch/arm/configs/vf610m4_defconfig:# CONFIG_MMU is not set
>
>>
>> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
>> index d006668c0027d2..e0dae570a51530 100644
>> --- a/kernel/dma/Kconfig
>> +++ b/kernel/dma/Kconfig
>> @@ -71,6 +71,7 @@ config SWIOTLB
>> # in the pagetables
>> #
>> config DMA_NONCOHERENT_MMAP
>> + default y if !MMU
>> bool
>
> Nit: def_bool !MMU
>
>>
>> config DMA_REMAP
>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>> index 0a4881e59aa7d6..9ec6a5c3fc578c 100644
>> --- a/kernel/dma/direct.c
>> +++ b/kernel/dma/direct.c
>> @@ -459,7 +459,6 @@ int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
>> return ret;
>> }
>>
>> -#ifdef CONFIG_MMU
>> bool dma_direct_can_mmap(struct device *dev)
>> {
>> return dev_is_dma_coherent(dev) ||
>> @@ -485,19 +484,6 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
>> return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
>> user_count << PAGE_SHIFT, vma->vm_page_prot);
>> }
>> -#else /* CONFIG_MMU */
>> -bool dma_direct_can_mmap(struct device *dev)
>> -{
>> - return false;
>> -}
>> -
>> -int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
>> - void *cpu_addr, dma_addr_t dma_addr, size_t size,
>> - unsigned long attrs)
>> -{
>> - return -ENXIO;
>> -}
>> -#endif /* CONFIG_MMU */
>>
>> int dma_direct_supported(struct device *dev, u64 mask)
>> {
>>
>
> LGTM. FWIW:
>
> Reviewed-by: Vladimir Murzin <[email protected]>
>
>
@dillon, can you give it a try?
I think Christoph would appreciate your Tested-by and that might speed up
getting fix mainline.
Cheers
Vladimir
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
On Thu, Jun 11, 2020 at 11:45 PM Vladimir Murzin
<[email protected]> wrote:
>
> On 6/10/20 9:19 AM, Vladimir Murzin wrote:
> > On 6/10/20 8:24 AM, Christoph Hellwig wrote:
> >> Ok, I finally found the original patch from Vladimir. Comments below:
> >>
> >>> +++ b/kernel/dma/direct.c
> >>> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> >>> #else /* CONFIG_MMU */
> >>> bool dma_direct_can_mmap(struct device *dev)
> >>> {
> >>> - return false;
> >>> + return true;
> >>> }
> >>>
> >>> int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> >>> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> >>> unsigned long attrs)
> >>> {
> >>> - return -ENXIO;
> >>> + return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end - vma->vm_start));;
> >>
> >> I think we should try to reuse the mmu dma_direct_mmap implementation,
> >> which does about the same. This version has been compile tested on
> >> arm-nommu only, let me know what you think: (btw, a nommu_defconfig of
> >> some kind for arm would be nice..)
> >
> > Catch-all nommu_defconfig is not easy for ARM, AFAIK folk carry few hacks
> > for randconfig...
> >
> > Meanwhile, known working NOMMU configs
> >
> > $ git grep "# CONFIG_MMU is not set" arch/arm/configs/
> > arch/arm/configs/efm32_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/lpc18xx_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/mps2_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/stm32_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/vf610m4_defconfig:# CONFIG_MMU is not set
> >
> >>
> >> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> >> index d006668c0027d2..e0dae570a51530 100644
> >> --- a/kernel/dma/Kconfig
> >> +++ b/kernel/dma/Kconfig
> >> @@ -71,6 +71,7 @@ config SWIOTLB
> >> # in the pagetables
> >> #
> >> config DMA_NONCOHERENT_MMAP
> >> + default y if !MMU
> >> bool
> >
> > Nit: def_bool !MMU
> >
> >>
> >> config DMA_REMAP
> >> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> >> index 0a4881e59aa7d6..9ec6a5c3fc578c 100644
> >> --- a/kernel/dma/direct.c
> >> +++ b/kernel/dma/direct.c
> >> @@ -459,7 +459,6 @@ int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
> >> return ret;
> >> }
> >>
> >> -#ifdef CONFIG_MMU
> >> bool dma_direct_can_mmap(struct device *dev)
> >> {
> >> return dev_is_dma_coherent(dev) ||
> >> @@ -485,19 +484,6 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> >> return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> >> user_count << PAGE_SHIFT, vma->vm_page_prot);
> >> }
> >> -#else /* CONFIG_MMU */
> >> -bool dma_direct_can_mmap(struct device *dev)
> >> -{
> >> - return false;
> >> -}
> >> -
> >> -int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> >> - void *cpu_addr, dma_addr_t dma_addr, size_t size,
> >> - unsigned long attrs)
> >> -{
> >> - return -ENXIO;
> >> -}
> >> -#endif /* CONFIG_MMU */
> >>
> >> int dma_direct_supported(struct device *dev, u64 mask)
> >> {
> >>
> >
> > LGTM. FWIW:
> >
> > Reviewed-by: Vladimir Murzin <[email protected]>
> >
> >
>
> @dillon, can you give it a try?
>
> I think Christoph would appreciate your Tested-by and that might speed up
> getting fix mainline.
>
sorry for the late response. Yes, it's working
Thanks Christoph
index 8f4bbdaf965e..3e0ecf0b5fb3 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -427,7 +427,6 @@ int dma_direct_get_sgtable(struct device *dev,
struct sg_table *sgt,
return ret;
}
-#ifdef CONFIG_MMU
bool dma_direct_can_mmap(struct device *dev)
{
return dev_is_dma_coherent(dev) ||
@@ -453,19 +452,6 @@ int dma_direct_mmap(struct device *dev, struct
vm_area_struct *vma,
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
user_count << PAGE_SHIFT, vma->vm_page_prot);
}
-#else /* CONFIG_MMU */
-bool dma_direct_can_mmap(struct device *dev)
-{
- return false;
-}
-
-int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
- return -ENXIO;
-}
-#endif /* CONFIG_MMU */
Tested-by: dillon min <[email protected]>
>
> Cheers
> Vladimir
>
> > _______________________________________________
> > linux-arm-kernel mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>