Re: DMA_ATTR_WRITE_COMBINE on mips

[Maciej W. Rozycki]

Hi Christoph,

> [I hope the imgtec address still works, but maybe the mips folks know
> if it moved to mips]

 Alex left Imagination long before the transition to the interim MIPS 
company.

> you added DMA_ATTR_WRITE_COMBINE support in dma_mmap_attrs to mips
> in commit 8c172467be36f7c9591e59b647e4cd342ce2ef41
> ("MIPS: Add implementation of dma_map_ops.mmap()"), but that commit
> only added the support in mmap, not in dma_alloc_attrs.  This means
> the memory is now used in kernel space through KSEG1, and thus uncached,
> while for userspace mappings through dma_mmap_* pgprot_writebombine
> is used, which creates a write combine mapping, which on some MIPS CPUs
> sets the _CACHE_UNCACHED_ACCELERATED pte bit instead of the
> _CACHE_UNCACHED one.  I know at least on arm, powerpc and x86 such
> mixed page cachability attributes can cause pretty severe problems.
> Are they ok on mips?

 The uncached accelerated mode is implementation-specific, so you won't 
find its definition in the architecture, however the original R1 
implementation explicitly documents[1] interactions between bus accesses 
using the two modes (essentially a _CACHE_UNCACHED store acts as a barrier 
for any outstanding _CACHE_UNCACHED_ACCELERATED stores; for loads the 
modes are equivalent), so that's clearly supported.

 I've glanced over the interAptiv manual[2] too and it seems to define the 
caching modes similarly.

>  Or was the DMA_ATTR_WRITE_COMBINE supported
> unintended and not correct and we should remove it?

 I don't know, so regrettably I can't comment on this.

References:

[1] "MIPS R1 Microprocessor", Version 2.0, MIPS Technologies, Inc., 
January 29, 1997



[2] "MIPS32 interAptiv Multiprocessing System Software User's Manual", 
Imagination Technologies Ltd., Document Number: MD00904, Revision 
02.01, June 15, 2016

  Maciej

Re: [PATCH 2/2] MIPS: remove support for DMA_ATTR_WRITE_COMBINE

[Maciej W. Rozycki]

On Wed, 7 Aug 2019, Christoph Hellwig wrote:

> Mips uses the KSEG1 kernel memory segment to map dma coherent
> allocations for non-coherent devices as uncacheable, and does not have
> any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
> path.  Thus supporting DMA_ATTR_WRITE_COMBINE in dma_mmap_attrs will
> lead to multiple mappings with different caching attributes.

 FYI, AFAIK _CACHE_UNCACHED_ACCELERATED (where supported) is effectively 
write-combine.  Though IIUC someone would have to wire it in first.

  Maciej

Re: [PATCH 12/25] MIPS: loongson: untangle dma implementations

[Maciej W. Rozycki]

On Fri, 25 May 2018, Christoph Hellwig wrote:

> Only loongson-3 is DMA coherent and uses swiotlb.  So move the dma
> address translations stubs directly to the loongson-3 code, and remove
> a few Kconfig indirections.

 SiByte should too though, at least for those boards, such as the SWARM 
and the BigSur, that can have DRAM over 4GiB (and 32-bit PCI devices 
plugged).

 I never got to have the wiring of swiotlb completed for these boards as 
I got distracted with getting set up to debug a DRAM controller issue 
observed in the form of memory data corruption with the banks fully 
populated (which might have to do something with the parameters of bank 
interleaving enabled in such a configuration, as replacing a single 
module with a smaller-sized one and therefore disabling interleaving, 
which can only work with all modules being the same size, makes the 
problem go away).

 FWIW,

  Maciej
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 12/25] MIPS: loongson: untangle dma implementations

[Maciej W. Rozycki]

On Wed, 11 Jul 2018, Christoph Hellwig wrote:

> >  SiByte should too though, at least for those boards, such as the SWARM 
> > and the BigSur, that can have DRAM over 4GiB (and 32-bit PCI devices 
> > plugged).
> 
> Only in this case refers to loonson boards.

 Right!

> >  I never got to have the wiring of swiotlb completed for these boards as 
> > I got distracted with getting set up to debug a DRAM controller issue 
> > observed in the form of memory data corruption with the banks fully 
> > populated (which might have to do something with the parameters of bank 
> > interleaving enabled in such a configuration, as replacing a single 
> > module with a smaller-sized one and therefore disabling interleaving, 
> > which can only work with all modules being the same size, makes the 
> > problem go away).
> 
> After this series enabling swiotlb for another board is trivial as all
> the code has been consolidated.  Just select SWIOTLB and add a call to
> swiotlb_init to the board setup code.

 I had that feeling too, thanks for confirming.  And for doing this work 
in the first place!

  Maciej
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/6] dma-mapping: merge direct and noncoherent ops

[Maciej W. Rozycki]

Hi Christoph,

On Fri, 14 Sep 2018, Christoph Hellwig wrote:

> All the cache maintainance is already stubbed out when not enabled,
> but merging the two allows us to nicely handle the case where
> cache maintainance is required for some devices, but not others.

 FYI, you commit bc3ec75de545 ("dma-mapping: merge direct and noncoherent 
ops") has caused:

fddi0: DMA command request failed!
fddi0: Adapter open failed!

with the `defxx' driver on my R4400SC TURBOchannel DECstation (but not the 
R3400 one) and consequently the interface does not work anymore.  Both are 
non-coherent cache systems, however the R3400 implements the write-through 
policy while the policy of the R4400SC is write-back (it also has 1MiB of 
secondary cache), which I suspect is the reason of the difference.

 I'll be experimenting with this commit to figure out what the real cause 
is, but it'll take a while as my resources are limited, so I'm sending 
this early heads-up in case you or someone else has an idea what might be 
going wrong here.

  Maciej
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/6] dma-mapping: merge direct and noncoherent ops

[Maciej W. Rozycki]

On Wed, 31 Oct 2018, Maciej W. Rozycki wrote:

> > All the cache maintainance is already stubbed out when not enabled,
> > but merging the two allows us to nicely handle the case where
> > cache maintainance is required for some devices, but not others.
> 
>  FYI, you commit bc3ec75de545 ("dma-mapping: merge direct and noncoherent 
> ops") has caused:
> 
> fddi0: DMA command request failed!
> fddi0: Adapter open failed!
> 
> with the `defxx' driver on my R4400SC TURBOchannel DECstation (but not the 
> R3400 one) and consequently the interface does not work anymore.  Both are 
> non-coherent cache systems, however the R3400 implements the write-through 
> policy while the policy of the R4400SC is write-back (it also has 1MiB of 
> secondary cache), which I suspect is the reason of the difference.

 Doh!  It would have helped if I actually had the right adapter installed 
in the R3400 box.  I've got a spare one, which I have now plugged in there 
and the R3400 actually shows the same issue as the R4400SC does.  So this 
has nothing to do WRT write-through vs write-back.

 Hmm, in `dfx_hw_dma_cmd_req' the driver polls the consumer block (which 
is write-only by the adapter and read-only by the host, except for the 
initialisation time before adapter's DMA engines have been started, and 
write-through vs write-back indeed does not matter for this kind of use) 
and there's no DMA synchronisation whatsoever in that.

 However the block has been allocated with `dma_zalloc_coherent', which 
means no synchronisation is supposed to be required.  For non-coherent 
cache systems that essentially means an uncached memory allocation.

  Maciej
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 4/6] dma-mapping: merge direct and noncoherent ops

[Maciej W. Rozycki]

On Wed, 31 Oct 2018, Christoph Hellwig wrote:

> Can you send me your .config?

 Sure, attached.

 This is an updated 4.19 defconfig I was going to submit as I tripped over 
this problem, so just rename it to .config and use `make olddefconfig' to 
regenerate a full version.

 Thanks,

  MaciejCONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_EXPERT=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_BPF_SYSCALL=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
CONFIG_MACH_DECSTATION=y
CONFIG_CPU_R3000=y
CONFIG_TC=y
# CONFIG_SUSPEND is not set
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_LBDAF is not set
CONFIG_PARTITION_ADVANCED=y
CONFIG_OSF_PARTITION=y
# CONFIG_EFI_PARTITION is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_NETWORK_SECMARK=y
CONFIG_IP_SCTP=m
CONFIG_VLAN_8021Q=m
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
# CONFIG_WIRELESS is not set
# CONFIG_UEVENT_HELPER is not set
# CONFIG_FW_LOADER is not set
# CONFIG_ALLOW_DEV_COREDUMP is not set
CONFIG_MTD=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_MTD_MS02NV=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_ISCSI_TCP=m
CONFIG_NETDEVICES=y
# CONFIG_NET_VENDOR_ALACRITECH is not set
# CONFIG_NET_VENDOR_AMAZON is not set
CONFIG_DECLANCE=y
# CONFIG_NET_VENDOR_AQUANTIA is not set
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_VENDOR_AURORA is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_CADENCE is not set
# CONFIG_NET_VENDOR_CAVIUM is not set
# CONFIG_NET_VENDOR_CORTINA is not set
# CONFIG_NET_VENDOR_EZCHIP is not set
# CONFIG_NET_VENDOR_HUAWEI is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROSEMI is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_NETRONOME is not set
# CONFIG_NET_VENDOR_NI is not set
# CONFIG_NET_VENDOR_QUALCOMM is not set
# CONFIG_NET_VENDOR_RENESAS is not set
# CONFIG_NET_VENDOR_ROCKER is not set
# CONFIG_NET_VENDOR_SAMSUNG is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SOLARFLARE is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_SOCIONEXT is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SYNOPSYS is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_NET_VENDOR_XILINX is not set
CONFIG_FDDI=y
CONFIG_DEFZA=y
CONFIG_DEFXX=y
# CONFIG_WLAN is not set
# CONFIG_KEYBOARD_ATKBD is not set
CONFIG_KEYBOARD_LKKBD=y
# CONFIG_MOUSE_PS2 is not set
CONFIG_MOUSE_VSXXXAA=y
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
CONFIG_FB=y
CONFIG_FB_TGA=y
CONFIG_FB_PMAG_AA=y
CONFIG_FB_PMAG_BA=y
CONFIG_FB_PMAGB_B=y
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE_COLUMNS=160
CONFIG_DUMMY_CONSOLE_ROWS=64
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_VGA16 is not set
# CONFIG_LOGO_LINUX_CLUT224 is not set
# CONFIG_HID is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_RTC_CLASS=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_CMOS=y
# CONFIG_MIPS_PLATFORM_DEVICES is not set
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_MANDATORY_FILE_LOCKING is not set
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_CHILDREN=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_CONFIGFS_FS=y
CONFIG_UFS_FS=y
CONFIG_UFS_FS_WRITE=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_SWAP=y
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_UTF8=m
CONFIG_CRYPTO_RSA=m
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_CHACHA20POLY1305=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m

[PATCH] MIPS: Fix `dma_alloc_coherent' returning a non-coherent allocation

[Maciej W. Rozycki]

Fix a MIPS `dma_alloc_coherent' regression from commit bc3ec75de545 
("dma-mapping: merge direct and noncoherent ops") that causes a cached 
allocation to be returned on noncoherent cache systems.

This is due to an inverted check now used in the MIPS implementation of 
`arch_dma_alloc' on the result from `dma_direct_alloc_pages' before 
doing the cached-to-uncached mapping of the allocation address obtained.  
The mapping has to be done for a non-NULL rather than NULL result, 
because a NULL result means the allocation has failed.

Invert the check for correct operation then.

Signed-off-by: Maciej W. Rozycki 
Fixes: bc3ec75de545 ("dma-mapping: merge direct and noncoherent ops")
Cc: sta...@vger.kernel.org # 4.19+
---
On Thu, 1 Nov 2018, Christoph Hellwig wrote:

> Fails to compile for me with:
> 
> cc1: error: ‘-march=r3000’ requires ‘-mfp32’
> 
> using the x86_64 corss gcc 8 from Debian testing.

 Hmm, that seems related to the FPXX ABI, which the R3000 does not support 
and which they may have configured as the default for GCC (`-mfpxx').  
That's not relevant to the kernel, so we probably just ought to force 
`-mfp32' and `-mfp64' for 32-bit and 64-bit builds respectively these 
days.

> Either way the config looks like we have all the required bits for
> non-coherent dma support.  The only guess is that somehow
> dma_cache_wback_inv aren't hooked up to the right functions for some
> reason, but I can't really think off why.

 Well, `dma_cache_wback_inv' isn't actually called and with the 64-bit 
configuration I switched to the address returned is in the XKPHYS cached 
noncoherent space, as proved with a simple diagnostic patch applied to 
`dma_direct_alloc' showing the results of `dev_is_dma_coherent' and the 
actual allocation:

tc1: DEFTA at MMIO addr = 0x1e90, IRQ = 20, Hardware addr = 
08-00-2b-a3-a3-29
defxx tc1: dma_direct_alloc: coherent: 0
defxx tc1: dma_direct_alloc: returned: 980003db8000
tc1: registered as fddi0

(the value of 3 in bits 61:59 of the virtual address denotes the cached 
noncoherent attribute).

 The cause is commit bc3ec75de545 ("dma-mapping: merge direct and 
noncoherent ops") reversed the interpretation of the `dma_direct_alloc*' 
result in `arch_dma_alloc'.  I guess this change was unlucky not to have 
this part of the API actually verified at run-time by anyone anywhere.

 Fixed thus, with debug output now as expected:

defxx tc1: dma_direct_alloc: coherent: 0
defxx tc1: dma_direct_alloc: returned: 93db8000

showing the address returned in the XKPHYS uncached space (the value of 2 
in bits 61:59 of the virtual address denotes the uncached attribute), and 
the network interface working properly.

 Please apply, and backport as required.

  Maciej
---
 arch/mips/mm/dma-noncoherent.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

linux-mips-arch-dma-alloc-err.patch
Index: linux-20181028-4maxp64-defconfig/arch/mips/mm/dma-noncoherent.c
===
--- linux-20181028-4maxp64-defconfig.orig/arch/mips/mm/dma-noncoherent.c
+++ linux-20181028-4maxp64-defconfig/arch/mips/mm/dma-noncoherent.c
@@ -50,7 +50,7 @@ void *arch_dma_alloc(struct device *dev,
void *ret;
 
ret = dma_direct_alloc_pages(dev, size, dma_handle, gfp, attrs);
-   if (!ret && !(attrs & DMA_ATTR_NON_CONSISTENT)) {
+   if (ret && !(attrs & DMA_ATTR_NON_CONSISTENT)) {
dma_cache_wback_inv((unsigned long) ret, size);
ret = (void *)UNCAC_ADDR(ret);
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] MIPS: Fix `dma_alloc_coherent' returning a non-coherent allocation

[Maciej W. Rozycki]

On Thu, 1 Nov 2018, Christoph Hellwig wrote:

> Oops, yes this looks good:

 BTW, for anyone missing hardware suitable for serious DMA testing I can 
recommend getting a pair of DEFPA cards, the ubiquitous PCI version of 
this board, cheaply available, which is the same except for a different 
host bus bridge ASIC, developed later.  They can be wired back to back 
similarly to Ethernet adapters (or in a loop if you have 2 or more dual 
attachment versions), no other hardware is required save for patch cords.
Version 3 (DEFPA-xC) boards support universal PCI signalling, older ones 
are 5V-only.

 These devices are a stellar example of fine engineering[1].  Our `defxx' 
driver, which I believe has been adapted from the DEC OSF/1 one referred 
in the said document, has some latency and other issues that I plan to 
address sometime, once I have sorted higher-priority issues, however 
hardware itself is excellent.

References:

[1] Chran-Ham Chang et al., "High-performance TCP/IP and UDP/IP Networking 
in DEC OSF/1 for Alpha AXP", Digital Technical Journal, vol. 5, no. 1 
(Winter 1993), "Network Adapter Characteristics", p. 7



  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

[Maciej W. Rozycki]

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

[Maciej W. Rozycki]

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

[Maciej W. Rozycki]

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 1/6] MIPS/malta: simplify plat_setup_iocoherency

[Maciej W. Rozycki]

On Wed, 10 Feb 2021, Christoph Hellwig wrote:

> Given that plat_mem_setup runs before earlyparams are handled and malta
> selects CONFIG_DMA_MAYBE_COHERENT, coherentio can only be set to
> IO_COHERENCE_DEFAULT at this point.  So remove the checking for other
> options and merge plat_enable_iocoherency into plat_setup_iocoherency
> to simplify the code a bit.

Tested-by: Maciej W. Rozycki 

 FWIW,

  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

[Maciej W. Rozycki]

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

[Maciej W. Rozycki]

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

[Maciej W. Rozycki]

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] scsi: remove stale BusLogic driver

[Maciej W. Rozycki]

On Mon, 6 Jun 2022, Arnd Bergmann wrote:

> This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
> 64-bit system enumeration error for Buslogic"), 8 years later.
> 
> The fact that this was found at all is an indication that there are
> users, and it seems that Maciej, Matt and Khalid all have access to
> this hardware, but if it took eight years to find the problem,
> it's likely that nobody actually relies on it.

 Umm, I use it with a 32-bit system, so it would be quite an issue for me 
to discover a problem with 64-bit configurations.  And I quite rely on 
this system for various stuff too!

> Remove it as part of the global virt_to_bus()/bus_to_virt() removal.
> If anyone is still interested in keeping this driver, the alternative
> is to stop it from using bus_to_virt(), possibly along the lines of
> how dpt_i2o gets around the same issue.

 Thanks for the pointer and for cc-ing me.  Please refrain from removing 
the driver at least for this release cycle and let me fix it.  It should 
be easy to mimic what I did for the defza driver: all bus addresses in the 
DMA API come associated with virtual addresses, so it is just a matter of 
recording those somewhere for later use rather than trying to mess up with 
bus addresses to figure out a reverse mapping.

  Maciej
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu