Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, 22 Feb 2021, Maciej W. Rozycki wrote: > > > I haven't booted Linux on my Malta for a while now, but it turns out to > > > work just fine, and your patch set does not regress it booting multi-user > > > NFS-rooted over FDDI. > > > > > > I note however that the system does not reboot properly: > > > > > > sd 0:0:0:0: [sda] Synchronizing SCSI cache > > > reboot: Restarting system > > > Reboot failed -- System halted > > > > > > which is a regression, and also the MMIO-mapped discrete CBUS UART > > > (ttyS2) > > > does not sign in anymore either: > > > > Do you mean a regression with this series, or just compared to when you > > last tested? > > When last tested. Years ago, so nothing for you to be concerned. I'll > look into it sometime unless someone beats me to. Don't hold your breath > though. Sorry to be unclear. For the record, Malta reboot requires: CONFIG_POWER_RESET=y CONFIG_POWER_RESET_SYSCON=y to work these days, which wasn't picked automatically on an older config regeneration for me. Sorry for the noise then, although ISTM that these would better be picked up automatically by reverse dependencies. What's the point of omitting reboot support? Still looking into the CBUS UART issue. Maciej ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, 22 Feb 2021, Christoph Hellwig wrote: > > I haven't booted Linux on my Malta for a while now, but it turns out to > > work just fine, and your patch set does not regress it booting multi-user > > NFS-rooted over FDDI. > > > > I note however that the system does not reboot properly: > > > > sd 0:0:0:0: [sda] Synchronizing SCSI cache > > reboot: Restarting system > > Reboot failed -- System halted > > > > which is a regression, and also the MMIO-mapped discrete CBUS UART (ttyS2) > > does not sign in anymore either: > > Do you mean a regression with this series, or just compared to when you > last tested? When last tested. Years ago, so nothing for you to be concerned. I'll look into it sometime unless someone beats me to. Don't hold your breath though. Sorry to be unclear. Maciej ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Sun, Feb 21, 2021 at 04:32:38AM +0100, Maciej W. Rozycki wrote: > I haven't booted Linux on my Malta for a while now, but it turns out to > work just fine, and your patch set does not regress it booting multi-user > NFS-rooted over FDDI. > > I note however that the system does not reboot properly: > > sd 0:0:0:0: [sda] Synchronizing SCSI cache > reboot: Restarting system > Reboot failed -- System halted > > which is a regression, and also the MMIO-mapped discrete CBUS UART (ttyS2) > does not sign in anymore either: Do you mean a regression with this series, or just compared to when you last tested? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, 15 Feb 2021, Maciej W. Rozycki wrote: > I hope to have the adapter properly fixed soon and I'll look at the Malta > side now, possibly using the old server whose DEFPA has worked flawlessly > for some 20 years now. I have planned to use the interface to supply NFS > root, which I think should be enough of a stress test. Card reworked now and network wired, so using the new server actually. I haven't booted Linux on my Malta for a while now, but it turns out to work just fine, and your patch set does not regress it booting multi-user NFS-rooted over FDDI. I note however that the system does not reboot properly: sd 0:0:0:0: [sda] Synchronizing SCSI cache reboot: Restarting system Reboot failed -- System halted which is a regression, and also the MMIO-mapped discrete CBUS UART (ttyS2) does not sign in anymore either: Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled printk: console [ttyS0] disabled serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A printk: console [ttyS0] enabled printk: console [ttyS0] enabled printk: bootconsole [uart8250] disabled printk: bootconsole [uart8250] disabled serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A while long ago: Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS28 at 0x03f8 (irq = 4) is a 16550A ttyS29 at 0x02f8 (irq = 3) is a 16550A ttyS30 at 0x (irq = 20) is a 16550 (I don't know why the line numbers reported were so odd back then, but the standard character device major:minor numbers for ttyS0-2 just worked), so there's probably something wrong with platform device registration. ISTR using the CBUS UART as a console device at one point too. Maciej ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Tue, 9 Feb 2021, Maciej W. Rozycki wrote: > > > Do you need to have this verified anyhow? I only have a non-coherent > > > 5Kc > > > Malta though. > > > > If you get a chance to test this logic, that would be great. > > I'll try to give it a hit in the next few days then. Installed in my > Malta I have a DEFPA, which is about as serious a DMA user as a piece of > classic PCI hardware could be. I need to debug the issue of another DEFPA > not working with my POWER9 system, possibly due to an IOMMU handling bug > (hopefully not broken host hardware), so I'll take the opportunity and do > it all at once. FYI still working on it. The POWER9 issue turned out to be a combination of a driver configuration issue with the distribution caused by a chain of historical events leading to the use of PCI I/O bus commands not supported by the PHB PCIe host bridge and a bad solder joint with the adapter's main PDQ IC on a 20+ years old brand new card. I hope to have the adapter properly fixed soon and I'll look at the Malta side now, possibly using the old server whose DEFPA has worked flawlessly for some 20 years now. I have planned to use the interface to supply NFS root, which I think should be enough of a stress test. Patches will follow sometime too for the driver's configuration issue, a nonsense in 2021 I should have long addressed, and for resource handling which I think should explicitly fail port I/O claims on a system that does not support port I/O at all and should not allow this: # cat /proc/ioports - : 0031:02:04.0 # to happen. Maciej ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, Feb 08, 2021 at 03:50:23PM +0100, Christoph Hellwig wrote:
> Lift the dma_default_coherent variable from the mips architecture code
> to the driver core. This allows an architecture to sdefault all device
> to be DMA coherent at run time, even if the kernel is build with support
> for DMA noncoherent device. By allowing device_initialize to ѕet the
> ->dma_coherent field to this default the amount of arch hooks required
> for this behavior can be greatly reduced.
>
> Signed-off-by: Christoph Hellwig
> ---
> [..]
> @@ -143,7 +143,7 @@ static void __init plat_setup_iocoherency(void)
> pr_crit("IOCU OPERATION DISABLED BY SWITCH - DEFAULTING
> TO SW IO COHERENCY\n");
> }
>
> - if (supported)
> + if (supported) {
> if (dma_force_noncoherent) {
> pr_info("Hardware DMA cache coherency disabled\n");
> return;
this hunk needs to be in patch 1, otherwise it's not compilable
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, 8 Feb 2021, Christoph Hellwig wrote: > > Do you need to have this verified anyhow? I only have a non-coherent 5Kc > > Malta though. > > If you get a chance to test this logic, that would be great. I'll try to give it a hit in the next few days then. Installed in my Malta I have a DEFPA, which is about as serious a DMA user as a piece of classic PCI hardware could be. I need to debug the issue of another DEFPA not working with my POWER9 system, possibly due to an IOMMU handling bug (hopefully not broken host hardware), so I'll take the opportunity and do it all at once. Maciej ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, 8 Feb 2021, Christoph Hellwig wrote:
> diff --git a/arch/mips/mti-malta/malta-setup.c
> b/arch/mips/mti-malta/malta-setup.c
> index e98cc977a735b2..f8c9663e7faa10 100644
> --- a/arch/mips/mti-malta/malta-setup.c
> +++ b/arch/mips/mti-malta/malta-setup.c
> @@ -143,7 +143,7 @@ static void __init plat_setup_iocoherency(void)
> pr_crit("IOCU OPERATION DISABLED BY SWITCH - DEFAULTING
> TO SW IO COHERENCY\n");
> }
>
> - if (supported)
> + if (supported) {
> if (dma_force_noncoherent) {
> pr_info("Hardware DMA cache coherency disabled\n");
> return;
I think this has to go with 1/6; otherwise compilation breaks between
then and now AFAICT.
Do you need to have this verified anyhow? I only have a non-coherent 5Kc
Malta though.
Maciej
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, Feb 08, 2021 at 04:57:33PM +0100, Maciej W. Rozycki wrote:
> > diff --git a/arch/mips/mti-malta/malta-setup.c
> > b/arch/mips/mti-malta/malta-setup.c
> > index e98cc977a735b2..f8c9663e7faa10 100644
> > --- a/arch/mips/mti-malta/malta-setup.c
> > +++ b/arch/mips/mti-malta/malta-setup.c
> > @@ -143,7 +143,7 @@ static void __init plat_setup_iocoherency(void)
> > pr_crit("IOCU OPERATION DISABLED BY SWITCH - DEFAULTING
> > TO SW IO COHERENCY\n");
> > }
> >
> > - if (supported)
> > + if (supported) {
> > if (dma_force_noncoherent) {
> > pr_info("Hardware DMA cache coherency disabled\n");
> > return;
>
> I think this has to go with 1/6; otherwise compilation breaks between
> then and now AFAICT.
Indeed.
> Do you need to have this verified anyhow? I only have a non-coherent 5Kc
> Malta though.
If you get a chance to test this logic, that would be great.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] driver core: lift dma_default_coherent into common code
On Mon, Feb 08, 2021 at 03:50:23PM +0100, Christoph Hellwig wrote: > Lift the dma_default_coherent variable from the mips architecture code > to the driver core. This allows an architecture to sdefault all device > to be DMA coherent at run time, even if the kernel is build with support > for DMA noncoherent device. By allowing device_initialize to ѕet the > ->dma_coherent field to this default the amount of arch hooks required > for this behavior can be greatly reduced. > > Signed-off-by: Christoph Hellwig Acked-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 5/6] driver core: lift dma_default_coherent into common code
Lift the dma_default_coherent variable from the mips architecture code
to the driver core. This allows an architecture to sdefault all device
to be DMA coherent at run time, even if the kernel is build with support
for DMA noncoherent device. By allowing device_initialize to ѕet the
->dma_coherent field to this default the amount of arch hooks required
for this behavior can be greatly reduced.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig | 9 ++---
arch/mips/alchemy/common/setup.c | 2 +-
arch/mips/include/asm/dma-coherence.h | 22 --
arch/mips/kernel/setup.c | 6 --
arch/mips/mm/c-r4k.c | 2 +-
arch/mips/mm/dma-noncoherent.c| 1 -
arch/mips/mti-malta/malta-setup.c | 4 ++--
arch/mips/pci/pci-alchemy.c | 2 +-
arch/mips/pistachio/init.c| 1 -
drivers/base/core.c | 6 ++
include/linux/dma-map-ops.h | 5 ++---
kernel/dma/Kconfig| 3 ---
kernel/dma/mapping.c | 2 ++
13 files changed, 17 insertions(+), 48 deletions(-)
delete mode 100644 arch/mips/include/asm/dma-coherence.h
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0a17bedf4f0dba..1f1603a08a6d2d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -181,7 +181,7 @@ config MIPS_ALCHEMY
select CEVT_R4K
select CSRC_R4K
select IRQ_MIPS_CPU
- select DMA_MAYBE_COHERENT # Au1000,1500,1100 aren't, rest is
+ select DMA_NONCOHERENT # Au1000,1500,1100 aren't, rest is
select MIPS_FIXUP_BIGPHYS_ADDR if PCI
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_32BIT_KERNEL
@@ -546,7 +546,7 @@ config MIPS_MALTA
select CLKSRC_MIPS_GIC
select COMMON_CLK
select CSRC_R4K
- select DMA_MAYBE_COHERENT
+ select DMA_NONCOHERENT
select GENERIC_ISA_DMA
select HAVE_PCSPKR_PLATFORM
select HAVE_PCI
@@ -1127,11 +1127,6 @@ config FW_CFE
config ARCH_SUPPORTS_UPROBES
bool
-config DMA_MAYBE_COHERENT
- select ARCH_HAS_DMA_COHERENCE_H
- select DMA_NONCOHERENT
- bool
-
config DMA_PERDEV_COHERENT
bool
select ARCH_HAS_SETUP_DMA_OPS
diff --git a/arch/mips/alchemy/common/setup.c b/arch/mips/alchemy/common/setup.c
index 39e5b9cd882b10..2388d68786f4a7 100644
--- a/arch/mips/alchemy/common/setup.c
+++ b/arch/mips/alchemy/common/setup.c
@@ -28,8 +28,8 @@
#include
#include
#include
+#include /* for dma_default_coherent */
-#include
#include
#include
diff --git a/arch/mips/include/asm/dma-coherence.h
b/arch/mips/include/asm/dma-coherence.h
deleted file mode 100644
index 846c5ade30d12d..00
--- a/arch/mips/include/asm/dma-coherence.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2006 Ralf Baechle
- *
- */
-#ifndef __ASM_DMA_COHERENCE_H
-#define __ASM_DMA_COHERENCE_H
-
-#ifdef CONFIG_DMA_MAYBE_COHERENT
-extern bool dma_default_coherent;
-static inline bool dev_is_dma_coherent(struct device *dev)
-{
- return dma_default_coherent;
-}
-#else
-#define dma_default_coherent (!IS_ENABLED(CONFIG_DMA_NONCOHERENT))
-#endif
-
-#endif
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 85690957525ac9..d95f195dddcb36 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -805,8 +804,3 @@ static int __init debugfs_mips(void)
}
arch_initcall(debugfs_mips);
#endif
-
-#ifdef CONFIG_DMA_NONCOHERENT
-bool dma_default_coherent;
-EXPORT_SYMBOL_GPL(dma_default_coherent);
-#endif
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 58afbc3e4ada03..3c4a50e12cebd4 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include /* for dma_default_coherent */
#include
#include
@@ -35,7 +36,6 @@
#include
#include /* for run_uncached() */
#include
-#include
#include
/*
diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
index 38d3d9143b47fb..90b562753eb892 100644
--- a/arch/mips/mm/dma-noncoherent.c
+++ b/arch/mips/mm/dma-noncoherent.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include
/*
diff --git a/arch/mips/mti-malta/malta-setup.c
b/arch/mips/mti-malta/malta-setup.c
index e98cc977a735b2..f8c9663e7faa10 100644
--- a/arch/mips/mti-malta/malta-setup.c
+++ b/arch/mips/mti-malta/malta-setup.c
@@ -13,8 +13,8 @@
#include
#include
#include
+#include /* for dma_default_coherent */
-#include
#include
#include
#include
@@ -143,7 +143,7 @@ static void __init plat_setup_iocoherency(void)
pr_crit("IOCU OPERATION DISABLED BY
