Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
Christoph Hellwig writes: > We want to use the dma_direct_ namespace for a generic implementation, > so rename powerpc to the second best choice: dma_nommu_. I'm not a fan of "nommu". Some of the users of direct ops *are* using an IOMMU, they're just setting up a 1:1 mapping once at init time, rather than mapping dynamically. Though I don't have a good idea for a better name, maybe "1to1", "linear", "premapped" ? cheers ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman wrote:
> Christoph Hellwig writes:
>
>> We want to use the dma_direct_ namespace for a generic implementation,
>> so rename powerpc to the second best choice: dma_nommu_.
>
> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
> than mapping dynamically.
>
> Though I don't have a good idea for a better name, maybe "1to1",
> "linear", "premapped" ?
"identity"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 29/67] dma-direct: use node local allocations for coherent memory
Missing patch description explaining why this change is desirable.
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -39,7 +39,7 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
> if (gfpflags_allow_blocking(gfp))
> page = dma_alloc_from_contiguous(dev, count, page_order, gfp);
> if (!page)
> - page = alloc_pages(gfp, page_order);
> + page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> if (!page)
> return NULL;
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arch: drop duplicate exports of abort()
We now have exports in both architecture code in in common code,
which causes a link failure when symbol versioning is eanbled, on
four architectures:
kernel/exit.o: In function `__crc_abort':
exit.c:(*ABS*+0xc0e2ec8b): multiple definition of `__crc_abort'
This removes the four architecture specific exports and only
leaves the export next to the __weak symbol.
Fixes: mmotm ("kernel/exit.c: export abort() to modules")
Signed-off-by: Arnd Bergmann
---
Andrew, can you apply this to -mm on top of the other patch?
---
arch/arc/kernel/traps.c | 1 -
arch/arm/kernel/traps.c | 1 -
arch/m32r/kernel/traps.c | 1 -
arch/unicore32/kernel/traps.c | 1 -
4 files changed, 4 deletions(-)
diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 51a55b06cb2a..133a4dae41fe 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -169,4 +169,3 @@ void abort(void)
{
__asm__ __volatile__("trap_s 5\n");
}
-EXPORT_SYMBOL(abort);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index e344bdd2e5ac..5e3633c24e63 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -793,7 +793,6 @@ void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
-EXPORT_SYMBOL(abort);
void __init trap_init(void)
{
diff --git a/arch/m32r/kernel/traps.c b/arch/m32r/kernel/traps.c
index cb79fba79d43..b88a8dd14933 100644
--- a/arch/m32r/kernel/traps.c
+++ b/arch/m32r/kernel/traps.c
@@ -122,7 +122,6 @@ void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
-EXPORT_SYMBOL(abort);
void __init trap_init(void)
{
diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
index 5f25b39f04d4..c4ac6043ebb0 100644
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -298,7 +298,6 @@ void abort(void)
/* if that doesn't kill us, halt */
panic("Oops failed to kill thread");
}
-EXPORT_SYMBOL(abort);
void __init trap_init(void)
{
--
2.9.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/67] alpha: mark jensen as broken
Hi Christoph,
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> ("alpha/dma: use common noop dma ops"), so mark it as broken.
unknown revision or path not in the working tree.
Ah, you dropped the leading "6":
6aca0503847f6329460b15b3ab2b0e30bb752793
is less than 2 years old, though.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/alpha/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
> index b31b974a03cb..e96adcbcab41 100644
> --- a/arch/alpha/Kconfig
> +++ b/arch/alpha/Kconfig
> @@ -209,6 +209,7 @@ config ALPHA_EIGER
>
> config ALPHA_JENSEN
> bool "Jensen"
> + depends on BROKEN
> help
> DEC PC 150 AXP (aka Jensen): This is a very old Digital system - one
> of the first-generation Alpha systems. A number of these systems
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig wrote:
> The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound
> by the dma mask in the device because it directly maps to a physical
> address range (modulo an offset in the device), or if it is virtualized
> by an iommu and can map any address (that includes virtual iommus like
> swiotlb). The problem with this scheme is that it is per-architecture and
> not per dma_ops instance, and we are growing more and more setups that
> have multiple different dma operations in use on a single system, for
> which this scheme can't provide a correct answer. Depending on the
> architecture that means we either get a false positive or false negative
> at the moment.
>
> This patch instead extents the is_phys flag in struct dma_map_ops that
> is currently only used by a few architectures to be used tree wide.
>
> Note that this means that we now need a struct device parent in the
> Scsi_Host or netdevice. Every modern driver has these, but there might
> still be a few outdated legacy drivers out there, which now won't make
> an intelligent decision.
>
> Signed-off-by: Christoph Hellwig
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arc: fix iounmap prototype
The missing 'volatile' keyword on the iounmap argument leads to lots of
harmless warnings in an allmodconfig build:
sound/pci/echoaudio/echoaudio.c:1879:10: warning: passing argument 1 of
'iounmap' discards 'volatile' qualifier f
pointer target type [-Wdiscarded-qualifiers]
Signed-off-by: Arnd Bergmann
---
arch/arc/include/asm/io.h | 4 ++--
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index c22b181e8206..2c9b98fabf82 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -30,11 +30,11 @@ static inline void __iomem *ioport_map(unsigned long port,
unsigned int nr)
return (void __iomem *)port;
}
-static inline void ioport_unmap(void __iomem *addr)
+static inline void ioport_unmap(volatile void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz)ioremap(phy, sz)
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 9881bd740ccc..94d0116063a8 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -95,7 +95,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(volatile const void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.9.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch: drop duplicate exports of abort()
On Tue, Jan 02, 2018 at 11:31:12AM +0100, Arnd Bergmann wrote:
> We now have exports in both architecture code in in common code,
> which causes a link failure when symbol versioning is eanbled, on
> four architectures:
>
> kernel/exit.o: In function `__crc_abort':
> exit.c:(*ABS*+0xc0e2ec8b): multiple definition of `__crc_abort'
>
> This removes the four architecture specific exports and only
> leaves the export next to the __weak symbol.
>
> Fixes: mmotm ("kernel/exit.c: export abort() to modules")
> Signed-off-by: Arnd Bergmann
For arm:
Acked-by: Russell King
> ---
> Andrew, can you apply this to -mm on top of the other patch?
> ---
> arch/arc/kernel/traps.c | 1 -
> arch/arm/kernel/traps.c | 1 -
> arch/m32r/kernel/traps.c | 1 -
> arch/unicore32/kernel/traps.c | 1 -
> 4 files changed, 4 deletions(-)
>
> diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
> index 51a55b06cb2a..133a4dae41fe 100644
> --- a/arch/arc/kernel/traps.c
> +++ b/arch/arc/kernel/traps.c
> @@ -169,4 +169,3 @@ void abort(void)
> {
> __asm__ __volatile__("trap_s 5\n");
> }
> -EXPORT_SYMBOL(abort);
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index e344bdd2e5ac..5e3633c24e63 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -793,7 +793,6 @@ void abort(void)
> /* if that doesn't kill us, halt */
> panic("Oops failed to kill thread");
> }
> -EXPORT_SYMBOL(abort);
>
> void __init trap_init(void)
> {
> diff --git a/arch/m32r/kernel/traps.c b/arch/m32r/kernel/traps.c
> index cb79fba79d43..b88a8dd14933 100644
> --- a/arch/m32r/kernel/traps.c
> +++ b/arch/m32r/kernel/traps.c
> @@ -122,7 +122,6 @@ void abort(void)
> /* if that doesn't kill us, halt */
> panic("Oops failed to kill thread");
> }
> -EXPORT_SYMBOL(abort);
>
> void __init trap_init(void)
> {
> diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
> index 5f25b39f04d4..c4ac6043ebb0 100644
> --- a/arch/unicore32/kernel/traps.c
> +++ b/arch/unicore32/kernel/traps.c
> @@ -298,7 +298,6 @@ void abort(void)
> /* if that doesn't kill us, halt */
> panic("Oops failed to kill thread");
> }
> -EXPORT_SYMBOL(abort);
>
> void __init trap_init(void)
> {
> --
> 2.9.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch: drop duplicate exports of abort()
Hi Arnd,
On Tue, Jan 02, 2018 at 11:31:12AM +0100, Arnd Bergmann wrote:
> We now have exports in both architecture code in in common code,
> which causes a link failure when symbol versioning is eanbled, on
> four architectures:
>
> kernel/exit.o: In function `__crc_abort':
> exit.c:(*ABS*+0xc0e2ec8b): multiple definition of `__crc_abort'
>
> This removes the four architecture specific exports and only
> leaves the export next to the __weak symbol.
Will it not be better to remove the abort() as they are exactly same
like the weak function. That was the original plan we had when this
weak function was done. Like in the attached patch..
--
Regards
Sudip
diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 51a55b0..133a4da 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -169,4 +169,3 @@ void abort(void)
{
__asm__ __volatile__("trap_s 5\n");
}
-EXPORT_SYMBOL(abort);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index e344bdd..917b425 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -786,15 +786,6 @@ asmlinkage void __div0(void)
}
EXPORT_SYMBOL(__div0);
-void abort(void)
-{
- BUG();
-
- /* if that doesn't kill us, halt */
- panic("Oops failed to kill thread");
-}
-EXPORT_SYMBOL(abort);
-
void __init trap_init(void)
{
return;
diff --git a/arch/m32r/kernel/traps.c b/arch/m32r/kernel/traps.c
index cb79fba..a6f300a 100644
--- a/arch/m32r/kernel/traps.c
+++ b/arch/m32r/kernel/traps.c
@@ -115,15 +115,6 @@ static void set_eit_vector_entries(void)
_flush_cache_copyback_all();
}
-void abort(void)
-{
- BUG();
-
- /* if that doesn't kill us, halt */
- panic("Oops failed to kill thread");
-}
-EXPORT_SYMBOL(abort);
-
void __init trap_init(void)
{
set_eit_vector_entries();
diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
index 5f25b39..30d6613 100644
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -291,15 +291,6 @@ asmlinkage void __div0(void)
}
EXPORT_SYMBOL(__div0);
-void abort(void)
-{
- BUG();
-
- /* if that doesn't kill us, halt */
- panic("Oops failed to kill thread");
-}
-EXPORT_SYMBOL(abort);
-
void __init trap_init(void)
{
return;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch: drop duplicate exports of abort()
On Tue, Jan 02, 2018 at 11:34:45AM +, Sudip Mukherjee wrote: > Hi Arnd, > > On Tue, Jan 02, 2018 at 11:31:12AM +0100, Arnd Bergmann wrote: > > We now have exports in both architecture code in in common code, > > which causes a link failure when symbol versioning is eanbled, on > > four architectures: > > > > kernel/exit.o: In function `__crc_abort': > > exit.c:(*ABS*+0xc0e2ec8b): multiple definition of `__crc_abort' > > > > This removes the four architecture specific exports and only > > leaves the export next to the __weak symbol. > > Will it not be better to remove the abort() as they are exactly same > like the weak function. That was the original plan we had when this > weak function was done. Like in the attached patch.. If that was the plan, why wasn't it done - why did we end up with a build-breaking patch merged in -mm? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch: drop duplicate exports of abort()
On Tue, Jan 02, 2018 at 11:38:29AM +, Russell King - ARM Linux wrote: > On Tue, Jan 02, 2018 at 11:34:45AM +, Sudip Mukherjee wrote: > > Hi Arnd, > > > > On Tue, Jan 02, 2018 at 11:31:12AM +0100, Arnd Bergmann wrote: > > > We now have exports in both architecture code in in common code, > > > which causes a link failure when symbol versioning is eanbled, on > > > four architectures: > > > > > > kernel/exit.o: In function `__crc_abort': > > > exit.c:(*ABS*+0xc0e2ec8b): multiple definition of `__crc_abort' > > > > > > This removes the four architecture specific exports and only > > > leaves the export next to the __weak symbol. > > > > Will it not be better to remove the abort() as they are exactly same > > like the weak function. That was the original plan we had when this > > weak function was done. Like in the attached patch.. > > If that was the plan, why wasn't it done - why did we end up with a > build-breaking patch merged in -mm? The proposed patch (which I attached in the earlier mail) was breaking the build unless weak abort() is exported. So, ideally the export of weak abort() and the proposed patch should have been part of a series. But afaik, the export has been done to fix another build failure reported by Vineet. Andrew, I think the best way now is to apply the patch sent by Arnd, and I will send a separate patch to remove abort() after proper testing. -- Regards Sudip ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: fix iounmap prototype
Hi Arnd,
On Tue, Jan 2, 2018 at 12:01 PM, Arnd Bergmann wrote:
> The missing 'volatile' keyword on the iounmap argument leads to lots of
> harmless warnings in an allmodconfig build:
>
> sound/pci/echoaudio/echoaudio.c:1879:10: warning: passing argument 1 of
> 'iounmap' discards 'volatile' qualifier f
> pointer target type [-Wdiscarded-qualifiers]
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arc/include/asm/io.h | 4 ++--
> arch/arc/mm/ioremap.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
> index c22b181e8206..2c9b98fabf82 100644
> --- a/arch/arc/include/asm/io.h
> +++ b/arch/arc/include/asm/io.h
> @@ -30,11 +30,11 @@ static inline void __iomem *ioport_map(unsigned long
> port, unsigned int nr)
> return (void __iomem *)port;
> }
>
> -static inline void ioport_unmap(void __iomem *addr)
> +static inline void ioport_unmap(volatile void __iomem *addr)
> {
> }
>
> -extern void iounmap(const void __iomem *addr);
> +extern void iounmap(const volatile void __iomem *addr);
Note that include/asm-generic/io.h also lacks the volatiles?
>
> #define ioremap_nocache(phy, sz) ioremap(phy, sz)
> #define ioremap_wc(phy, sz)ioremap(phy, sz)
> diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
> index 9881bd740ccc..94d0116063a8 100644
> --- a/arch/arc/mm/ioremap.c
> +++ b/arch/arc/mm/ioremap.c
> @@ -95,7 +95,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
> size,
> EXPORT_SYMBOL(ioremap_prot);
>
>
> -void iounmap(const void __iomem *addr)
> +void iounmap(volatile const void __iomem *addr)
const volatile?
> {
> /* weird double cast to handle phys_addr_t > 32 bits */
> if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 25/67] dma-direct: rename dma_noop to dma_direct
On 29/12/17 08:18, Christoph Hellwig wrote:
> The trivial direct mapping implementation already does a virtual to
> physical translation which isn't strictly a noop, and will soon learn
> to do non-direct but linear physical to dma translations through the
> device offset and a few small tricks. Rename it to a better fitting
> name.
>
> Signed-off-by: Christoph Hellwig
> ---
> MAINTAINERS| 2 +-
> arch/arm/Kconfig | 2 +-
> arch/arm/include/asm/dma-mapping.h | 2 +-
> arch/arm/mm/dma-mapping-nommu.c| 8
> arch/m32r/Kconfig | 2 +-
> arch/riscv/Kconfig | 2 +-
> arch/s390/Kconfig | 2 +-
> include/asm-generic/dma-mapping.h | 2 +-
> include/linux/dma-mapping.h| 2 +-
> lib/Kconfig| 2 +-
> lib/Makefile | 2 +-
> lib/{dma-noop.c => dma-direct.c} | 35 +++
> 12 files changed, 29 insertions(+), 34 deletions(-)
> rename lib/{dma-noop.c => dma-direct.c} (53%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a8b35d9f41b2..b4005fe06e4c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4336,7 +4336,7 @@ T: git
> git://git.infradead.org/users/hch/dma-mapping.git
> W: http://git.infradead.org/users/hch/dma-mapping.git
> S: Supported
> F: lib/dma-debug.c
> -F: lib/dma-noop.c
> +F: lib/dma-direct.c
> F: lib/dma-virt.c
> F: drivers/base/dma-mapping.c
> F: drivers/base/dma-coherent.c
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 00d889a37965..430a0aa710d6 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -25,7 +25,7 @@ config ARM
> select CLONE_BACKWARDS
> select CPU_PM if (SUSPEND || CPU_IDLE)
> select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> - select DMA_NOOP_OPS if !MMU
> + select DMA_DIRECT_OPS if !MMU
> select EDAC_SUPPORT
> select EDAC_ATOMIC_SCRUB
> select GENERIC_ALLOCATOR
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index e5d9020c9ee1..8436f6ade57d 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -18,7 +18,7 @@ extern const struct dma_map_ops arm_coherent_dma_ops;
>
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type
> *bus)
> {
> - return IS_ENABLED(CONFIG_MMU) ? &arm_dma_ops : &dma_noop_ops;
> + return IS_ENABLED(CONFIG_MMU) ? &arm_dma_ops : &dma_direct_ops;
> }
>
> #ifdef __arch_page_to_dma
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> index 1cced700e45a..49e9831dc0f1 100644
> --- a/arch/arm/mm/dma-mapping-nommu.c
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -22,7 +22,7 @@
> #include "dma.h"
>
> /*
> - * dma_noop_ops is used if
> + * dma_direct_ops is used if
> * - MMU/MPU is off
> * - cpu is v7m w/o cache support
> * - device is coherent
> @@ -39,7 +39,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t
> size,
>unsigned long attrs)
>
> {
> - const struct dma_map_ops *ops = &dma_noop_ops;
> + const struct dma_map_ops *ops = &dma_direct_ops;
> void *ret;
>
> /*
> @@ -70,7 +70,7 @@ static void arm_nommu_dma_free(struct device *dev, size_t
> size,
> void *cpu_addr, dma_addr_t dma_addr,
> unsigned long attrs)
> {
> - const struct dma_map_ops *ops = &dma_noop_ops;
> + const struct dma_map_ops *ops = &dma_direct_ops;
>
> if (attrs & DMA_ATTR_NON_CONSISTENT) {
> ops->free(dev, size, cpu_addr, dma_addr, attrs);
> @@ -214,7 +214,7 @@ EXPORT_SYMBOL(arm_nommu_dma_ops);
>
> static const struct dma_map_ops *arm_nommu_get_dma_map_ops(bool coherent)
> {
> - return coherent ? &dma_noop_ops : &arm_nommu_dma_ops;
> + return coherent ? &dma_direct_ops : &arm_nommu_dma_ops;
> }
>
> void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
> index 498398d915c1..dd84ee194579 100644
> --- a/arch/m32r/Kconfig
> +++ b/arch/m32r/Kconfig
> @@ -19,7 +19,7 @@ config M32R
> select MODULES_USE_ELF_RELA
> select HAVE_DEBUG_STACKOVERFLOW
> select CPU_NO_EFFICIENT_FFS
> - select DMA_NOOP_OPS
> + select DMA_DIRECT_OPS
> select ARCH_NO_COHERENT_DMA_MMAP if !MMU
>
> config SBUS
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 2c6adf12713a..865e14f50c14 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -83,7 +83,7 @@ config PGTABLE_LEVELS
> config HAVE_KPROBES
> def_bool n
>
> -config DMA_NOOP_OPS
> +config DMA_DIRECT_OPS
> def_bool y
>
> menu "Platform type"
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 829c67986db7..9376637229c9 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -140,7 +140
Re: [PATCH 26/67] dma-direct: use phys_to_dma
On 29/12/17 08:18, Christoph Hellwig wrote:
> This means it uses whatever linear remapping scheme that the architecture
> provides is used in the generic dma_direct ops.
>
> Signed-off-by: Christoph Hellwig
> ---
> lib/dma-direct.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> index 439db40854b7..0e087650e86b 100644
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -1,12 +1,11 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * lib/dma-noop.c
> - *
> - * DMA operations that map to physical addresses without flushing memory.
> + * DMA operations that map physical memory directly without using an IOMMU or
> + * flushing caches.
> */
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -17,7 +16,7 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
>
> ret = (void *)__get_free_pages(gfp, get_order(size));
> if (ret)
> - *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
> + *dma_handle = phys_to_dma(dev, virt_to_phys(ret));
>
> return ret;
> }
> @@ -32,7 +31,7 @@ static dma_addr_t dma_direct_map_page(struct device *dev,
> struct page *page,
> unsigned long offset, size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> - return page_to_phys(page) + offset - PFN_PHYS(dev->dma_pfn_offset);
> + return phys_to_dma(dev, page_to_phys(page)) + offset;
> }
>
> static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> @@ -42,12 +41,9 @@ static int dma_direct_map_sg(struct device *dev, struct
> scatterlist *sgl,
> struct scatterlist *sg;
>
> for_each_sg(sgl, sg, nents, i) {
> - dma_addr_t offset = PFN_PHYS(dev->dma_pfn_offset);
> - void *va;
> -
> BUG_ON(!sg_page(sg));
> - va = sg_virt(sg);
> - sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va) - offset;
> +
> + sg_dma_address(sg) = phys_to_dma(dev, sg_phys(sg));
> sg_dma_len(sg) = sg->length;
> }
>
>
>From ARM NOMMU perspective
Reviewed-by: Vladimir Murzin
Thanks
Vladimir
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 30/67] dma-direct: retry allocations using GFP_DMA for small masks
On 29/12/17 08:18, Christoph Hellwig wrote:
> If we got back an allocation that wasn't inside the support coherent mask,
> retry the allocation using GFP_DMA.
>
> Based on the x86 code.
>
> Signed-off-by: Christoph Hellwig
> ---
> lib/dma-direct.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> index ab81de3ac1d3..f8467cb3d89a 100644
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -28,6 +28,11 @@ check_addr(struct device *dev, dma_addr_t dma_addr, size_t
> size,
> return true;
> }
>
> +static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t
> size)
> +{
> + return phys_to_dma(dev, phys) + size <= dev->coherent_dma_mask;
Shouldn't it be: phys_to_dma(dev, phys) + size - 1 <= dev->coherent_dma_mask ?
> +}
> +
> static void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> @@ -35,11 +40,29 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
> int page_order = get_order(size);
> struct page *page = NULL;
>
> +again:
> /* CMA can be used only in the context which permits sleeping */
> - if (gfpflags_allow_blocking(gfp))
> + if (gfpflags_allow_blocking(gfp)) {
> page = dma_alloc_from_contiguous(dev, count, page_order, gfp);
> + if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> + dma_release_from_contiguous(dev, page, count);
> + page = NULL;
> + }
> + }
> if (!page)
> page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> +
> + if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> + __free_pages(page, page_order);
> + page = NULL;
> +
> + if (dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
> + !(gfp & GFP_DMA)) {
> + gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
> + goto again;
Shouldn't we limit number of attempts?
Thanks
Vladimir
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 31/67] dma-direct: make dma_direct_{alloc, free} available to other implementations
On 29/12/17 08:18, Christoph Hellwig wrote:
> So that they don't need to indirect through the operation vector.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/arm/mm/dma-mapping-nommu.c | 9 +++--
> include/linux/dma-direct.h | 5 +
> lib/dma-direct.c| 6 +++---
> 3 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> index 49e9831dc0f1..b4cf3e4e9d4a 100644
> --- a/arch/arm/mm/dma-mapping-nommu.c
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -11,7 +11,7 @@
>
> #include
> #include
> -#include
> +#include
> #include
>
> #include
> @@ -39,7 +39,6 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t
> size,
>unsigned long attrs)
>
> {
> - const struct dma_map_ops *ops = &dma_direct_ops;
> void *ret;
>
> /*
> @@ -48,7 +47,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t
> size,
>*/
>
> if (attrs & DMA_ATTR_NON_CONSISTENT)
> - return ops->alloc(dev, size, dma_handle, gfp, attrs);
> + return dma_direct_alloc(dev, size, dma_handle, gfp, attrs);
>
> ret = dma_alloc_from_global_coherent(size, dma_handle);
>
> @@ -70,10 +69,8 @@ static void arm_nommu_dma_free(struct device *dev, size_t
> size,
> void *cpu_addr, dma_addr_t dma_addr,
> unsigned long attrs)
> {
> - const struct dma_map_ops *ops = &dma_direct_ops;
> -
> if (attrs & DMA_ATTR_NON_CONSISTENT) {
> - ops->free(dev, size, cpu_addr, dma_addr, attrs);
> + dma_direct_free(dev, size, cpu_addr, dma_addr, attrs);
> } else {
> int ret = dma_release_from_global_coherent(get_order(size),
> cpu_addr);
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index 10e924b7cba7..4788bf0bf683 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -38,4 +38,9 @@ static inline void dma_mark_clean(void *addr, size_t size)
> }
> #endif /* CONFIG_ARCH_HAS_DMA_MARK_CLEAN */
>
> +void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t
> *dma_handle,
> + gfp_t gfp, unsigned long attrs);
> +void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t dma_addr, unsigned long attrs);
> +
> #endif /* _LINUX_DMA_DIRECT_H */
> diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> index f8467cb3d89a..7e913728e099 100644
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -33,8 +33,8 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
> phys, size_t size)
> return phys_to_dma(dev, phys) + size <= dev->coherent_dma_mask;
> }
>
> -static void *dma_direct_alloc(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> +void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t
> *dma_handle,
> + gfp_t gfp, unsigned long attrs)
> {
> unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> int page_order = get_order(size);
> @@ -71,7 +71,7 @@ static void *dma_direct_alloc(struct device *dev, size_t
> size,
> return page_address(page);
> }
>
> -static void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
> +void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
> dma_addr_t dma_addr, unsigned long attrs)
> {
> unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>
Reviewed-by: Vladimir Murzin
Thanks
Vladimir
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
Geert Uytterhoeven writes: > On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman wrote: >> Christoph Hellwig writes: >> >>> We want to use the dma_direct_ namespace for a generic implementation, >>> so rename powerpc to the second best choice: dma_nommu_. >> >> I'm not a fan of "nommu". Some of the users of direct ops *are* using an >> IOMMU, they're just setting up a 1:1 mapping once at init time, rather >> than mapping dynamically. >> >> Though I don't have a good idea for a better name, maybe "1to1", >> "linear", "premapped" ? > > "identity"? I think that would be wrong, but thanks for trying to help :) The address on the device side is sometimes (often?) offset from the CPU address. So eg. the device can DMA to RAM address 0x0 using address 0x800. Identity would imply 0 == 0 etc. I think "bijective" is the correct term, but that's probably a bit esoteric. cheers ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
Hi Michael,
On Wed, Jan 3, 2018 at 7:24 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>
>> On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman
>> wrote:
>>> Christoph Hellwig writes:
>>>
We want to use the dma_direct_ namespace for a generic implementation,
so rename powerpc to the second best choice: dma_nommu_.
>>>
>>> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
>>> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
>>> than mapping dynamically.
>>>
>>> Though I don't have a good idea for a better name, maybe "1to1",
>>> "linear", "premapped" ?
>>
>> "identity"?
>
> I think that would be wrong, but thanks for trying to help :)
>
> The address on the device side is sometimes (often?) offset from the CPU
> address. So eg. the device can DMA to RAM address 0x0 using address
> 0x800.
>
> Identity would imply 0 == 0 etc.
>
> I think "bijective" is the correct term, but that's probably a bit
> esoteric.
OK, didn't know about the offset.
Then "linear" is what we tend to use, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
