2020-01-13 14:09:53

by Jiaxun Yang

[permalink] [raw]
Subject: [PATCH 1/2] MIPS: Define pgprot_dmacoherent according to coherentio status

For MIPS chips that support coherentio DMA, it's always safe
to make DMA requests cached.

Signed-off-by: Jiaxun Yang <[email protected]>
---
arch/mips/include/asm/dma-coherence.h | 14 ++++++++++++++
arch/mips/kernel/setup.c | 1 +
2 files changed, 15 insertions(+)

diff --git a/arch/mips/include/asm/dma-coherence.h b/arch/mips/include/asm/dma-coherence.h
index 5eaa1fcc878a..bc0df7684cae 100644
--- a/arch/mips/include/asm/dma-coherence.h
+++ b/arch/mips/include/asm/dma-coherence.h
@@ -9,6 +9,8 @@
#ifndef __ASM_DMA_COHERENCE_H
#define __ASM_DMA_COHERENCE_H

+#include <asm/pgtable.h>
+
enum coherent_io_user_state {
IO_COHERENCE_DEFAULT,
IO_COHERENCE_ENABLED,
@@ -35,4 +37,16 @@ static inline bool dev_is_dma_coherent(struct device *dev)
#define hw_coherentio 0
#endif /* CONFIG_DMA_MAYBE_COHERENT */

+#if !defined(CONFIG_DMA_PERDEV_COHERENT)
+#define pgprot_dmacoherent pgprot_dmacoherent
+static inline pgprot_t pgprot_dmacoherent(pgprot_t prot)
+{
+ if (coherentio == IO_COHERENCE_ENABLED ||
+ (coherentio == IO_COHERENCE_DEFAULT && hw_coherentio))
+ return prot;
+
+ return pgprot_noncached(prot);
+}
+#endif
+
#endif
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 701f4bc3046f..01f725819df7 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -831,6 +831,7 @@ arch_initcall(debugfs_mips);
enum coherent_io_user_state coherentio = IO_COHERENCE_DEFAULT;
EXPORT_SYMBOL_GPL(coherentio);
int hw_coherentio = 0; /* Actual hardware supported DMA coherency setting. */
+EXPORT_SYMBOL_GPL(hw_coherentio);

static int __init setcoherentio(char *str)
{
--
2.24.1


2020-01-13 14:10:54

by Jiaxun Yang

[permalink] [raw]
Subject: [PATCH 2/2] MIPS: Loongson64: Add dma iocoherency detection support

Set hw_iocoherency according to parameter passed from firmware.

Signed-off-by: Jiaxun Yang <[email protected]>
---
arch/mips/Kconfig | 1 +
arch/mips/include/asm/mach-loongson64/boot_param.h | 5 +++--
arch/mips/loongson64/env.c | 4 ++++
3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d0b727daddb3..8b0cd692a43f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -474,6 +474,7 @@ config MACH_LOONGSON64
select CSRC_R4K
select CEVT_R4K
select CPU_HAS_WB
+ select DMA_MAYBE_COHERENT
select FORCE_PCI
select ISA
select I8259
diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 8c286bedff3e..2da2be40ad81 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -115,7 +115,8 @@ struct irq_source_routing_table {
u64 pci_io_start_addr;
u64 pci_io_end_addr;
u64 pci_config_addr;
- u32 dma_mask_bits;
+ u16 dma_mask_bits;
+ u16 dma_noncoherent;
} __packed;

struct interface_info {
@@ -206,7 +207,7 @@ struct loongson_system_configuration {
u64 poweroff_addr;
u64 suspend_addr;
u64 vgabios_addr;
- u32 dma_mask_bits;
+ u16 dma_mask_bits;
char ecname[32];
u32 nr_uarts;
struct uart_device uarts[MAX_UARTS];
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 0daeb7bcf023..61e3d4874fe9 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -15,6 +15,7 @@
*/
#include <linux/export.h>
#include <asm/bootinfo.h>
+#include <asm/dma-coherence.h>
#include <loongson.h>
#include <boot_param.h>
#include <workarounds.h>
@@ -128,6 +129,9 @@ void __init prom_init_env(void)
loongson_sysconf.dma_mask_bits > 64)
loongson_sysconf.dma_mask_bits = 32;

+ hw_coherentio = !eirq_source->dma_noncoherent;
+ pr_info("Firmware I/O coherency: %s\n", hw_coherentio?"ON":"OFF");
+
loongson_sysconf.restart_addr = boot_p->reset_system.ResetWarm;
loongson_sysconf.poweroff_addr = boot_p->reset_system.Shutdown;
loongson_sysconf.suspend_addr = boot_p->reset_system.DoSuspend;
--
2.24.1

2020-01-13 14:59:32

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 1/2] MIPS: Define pgprot_dmacoherent according to coherentio status

On Mon, Jan 13, 2020 at 10:07:04PM +0800, Jiaxun Yang wrote:
> For MIPS chips that support coherentio DMA, it's always safe
> to make DMA requests cached.

For DMA coherent devices pgprot_dmacoherent isn't even used, so this
doesn't make sense.

2020-01-13 15:14:48

by Jiaxun Yang

[permalink] [raw]
Subject: Re: [PATCH 1/2] MIPS: Define pgprot_dmacoherent according to coherentio status



于 2020年1月13日 GMT+08:00 下午10:58:20, Christoph Hellwig <[email protected]> 写到:
>On Mon, Jan 13, 2020 at 10:07:04PM +0800, Jiaxun Yang wrote:
>> For MIPS chips that support coherentio DMA, it's always safe
>> to make DMA requests cached.
>
>For DMA coherent devices pgprot_dmacoherent isn't even used, so this
>doesn't make sense.

Hi,

I'm supposed to use it later in drm/ttm
ttm_bo_util to overwrite pgprot for TTM_PL_SYSTEM.
And I wish this pgropt can always represent dmacoherent pgropt.
Would it be fine?

Thanks

--
Jiaxun Yang

2020-01-13 15:15:40

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 1/2] MIPS: Define pgprot_dmacoherent according to coherentio status

On Mon, Jan 13, 2020 at 11:11:58PM +0800, Jiaxun Yang wrote:
>
>
> 于 2020年1月13日 GMT+08:00 下午10:58:20, Christoph Hellwig <[email protected]> 写到:
> >On Mon, Jan 13, 2020 at 10:07:04PM +0800, Jiaxun Yang wrote:
> >> For MIPS chips that support coherentio DMA, it's always safe
> >> to make DMA requests cached.
> >
> >For DMA coherent devices pgprot_dmacoherent isn't even used, so this
> >doesn't make sense.
>
> Hi,
>
> I'm supposed to use it later in drm/ttm
> ttm_bo_util to overwrite pgprot for TTM_PL_SYSTEM.
> And I wish this pgropt can always represent dmacoherent pgropt.
> Would it be fine?

No code outside the core DMA code has any business using
pgprot_dmacoherent.

2020-01-13 18:55:30

by Paul Burton

[permalink] [raw]
Subject: Re: [PATCH 2/2] MIPS: Loongson64: Add dma iocoherency detection support

Hi Jiaxun,

On Mon, Jan 13, 2020 at 10:07:05PM +0800, Jiaxun Yang wrote:
> diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h b/arch/mips/include/asm/mach-loongson64/boot_param.h
> index 8c286bedff3e..2da2be40ad81 100644
> --- a/arch/mips/include/asm/mach-loongson64/boot_param.h
> +++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
> @@ -115,7 +115,8 @@ struct irq_source_routing_table {
> u64 pci_io_start_addr;
> u64 pci_io_end_addr;
> u64 pci_config_addr;
> - u32 dma_mask_bits;
> + u16 dma_mask_bits;
> + u16 dma_noncoherent;
> } __packed;

This struct is generated by the firmware, right? So does this change
require that firmware be updated along with the kernel? Or was the
kernel's definition always incorrect/incomplete?

Thanks,
Paul

2020-01-14 03:48:27

by Jiaxun Yang

[permalink] [raw]
Subject: Re: [PATCH 2/2] MIPS: Loongson64: Add dma iocoherency detection support



14.01.2020, 02:52, "Paul Burton" <[email protected]>:
> Hi Jiaxun,
>
> On Mon, Jan 13, 2020 at 10:07:05PM +0800, Jiaxun Yang wrote:
>>  diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h b/arch/mips/include/asm/mach-loongson64/boot_param.h
>>  index 8c286bedff3e..2da2be40ad81 100644
>>  --- a/arch/mips/include/asm/mach-loongson64/boot_param.h
>>  +++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
>>  @@ -115,7 +115,8 @@ struct irq_source_routing_table {
>>           u64 pci_io_start_addr;
>>           u64 pci_io_end_addr;
>>           u64 pci_config_addr;
>>  - u32 dma_mask_bits;
>>  + u16 dma_mask_bits;
>>  + u16 dma_noncoherent;
>>   } __packed;
>
> This struct is generated by the firmware, right? So does this change
> require that firmware be updated along with the kernel? Or was the
> kernel's definition always incorrect/incomplete?
Hi Paul,

This define added to the firmware by 2013 but somehow never upstream.
That's what Loongson always doing.

Some versions of Loongson-3B1500 failed to maintain DMA coherent.
So they add this parameter to the firmware.
As the maximum dma_mask_bits is 64, the upper 16bit of the old u32 will always
be zero. Which means coherent DMA transformed into the new definition,
that's the expected default behavior. Thus it's safe to do so even if firmware
doesn't understand this parameter.

Thanks

>
> Thanks,
>     Paul
--
Jiaxun