Re: [PATCH 22/23] video: omapfb: dss: Make use of the helper component_compare_dev
On 2/14/22 07:08, Yong Wu wrote:
> Use the common compare helper from component.
>
> Cc: Helge Deller
> Cc: linux-o...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Yong Wu
Applied to the fbdev for-next branch.
Thanks!
Helge
> drivers/video/fbdev/omap2/omapfb/dss/dss.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> index a6b1c1598040..45b9d3cf3860 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> @@ -1193,12 +1193,6 @@ static const struct component_master_ops
> dss_component_ops = {
> .unbind = dss_unbind,
> };
>
> -static int dss_component_compare(struct device *dev, void *data)
> -{
> - struct device *child = data;
> - return dev == child;
> -}
> -
> static int dss_add_child_component(struct device *dev, void *data)
> {
> struct component_match **match = data;
> @@ -1212,7 +1206,7 @@ static int dss_add_child_component(struct device *dev,
> void *data)
> if (strstr(dev_name(dev), "rfbi"))
> return 0;
>
> - component_match_add(dev->parent, match, dss_component_compare, dev);
> + component_match_add(dev->parent, match, component_compare_dev, dev);
>
> return 0;
> }
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 07/28] 53c700: improve non-coherent DMA handling
Hi Willy, On 01.09.20 18:53, Matthew Wilcox wrote: > On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote: >>> I still have a zoo of machines running for such testing, including a >>> 715/64 and two 730. >>> I'm going to test this git tree on the 715/64: > > The 715/64 is a 7100LC machine though. I think you need to boot on > the 730 to test the non-coherent path. Just tested the 730, and it works as well. Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 07/28] 53c700: improve non-coherent DMA handling
On 01.09.20 18:21, Helge Deller wrote: > On 01.09.20 17:22, James Bottomley wrote: >> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: >>>> I think this looks mostly OK, except for one misnamed parameter >>>> below. Unfortunately, the last non-coherent parisc was the 700 >>>> series and I no longer own a box, so I can't test that part of it >>>> (I can fire up the C360 to test it on a coherent arch). >>> >>> I have a 715/50 that probably hasn't been powered on in 15 years if >>> you need something that old to test on (I believe the 725/100 uses >>> the 7100LC and so is coherent). I'll need to set up a cross-compiler >>> ... >> >> I'm not going to say no to actual testing, but it's going to be a world >> of pain getting something so old going. I do have a box of older >> systems I keep for architectural testing that I need to rummage around >> in ... I just have a vague memory that my 715 actually caught fire a >> decade ago and had to be disposed of. > > I still have a zoo of machines running for such testing, including a > 715/64 and two 730. > I'm going to test this git tree on the 715/64: > git://git.infradead.org/users/hch/misc.git dma_alloc_pages This tree boots nicely (up to a command prompt with i82596 nic working): 53c700: Version 2.8 By james.bottom...@hansenpartnership.com scsi0: 53c710 rev 2 scsi host0: LASI SCSI 53c700 scsi 0:0:6:0: Direct-Access QUANTUM FIREBALL_TM3200S 300X PQ: 0 ANSI: 2 scsi target0:0:6: Beginning Domain Validation scsi 0:0:6:0: tag#56 Enabling Tag Command Queuing scsi target0:0:6: asynchronous scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8) scsi target0:0:6: Domain Validation skipping write tests scsi target0:0:6: Ending Domain Validation scsi 0:0:6:1: tag#63 Disabling Tag Command Queuing st: Version 20160209, fixed bufsize 32768, s/g segs 256 sd 0:0:6:0: Power-on or device reset occurred sd 0:0:6:0: Attached scsi generic sg0 type 0 LASI 82596 driver - Revision: 1.30 Found i82596 at 0xf0107000, IRQ 17 eth0: 82596 at 0xf0107000, 08:00:09:c2:9e:60 IRQ 17. sd 0:0:6:0: [sda] 6281856 512-byte logical blocks: (3.22 GB/3.00 GiB) sd 0:0:6:0: [sda] Write Protect is off Christoph, you may add a Tested-by: Helge Deller # parisc to the series. Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 07/28] 53c700: improve non-coherent DMA handling
On 01.09.20 17:22, James Bottomley wrote: > On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: >>> I think this looks mostly OK, except for one misnamed parameter >>> below. Unfortunately, the last non-coherent parisc was the 700 >>> series and I no longer own a box, so I can't test that part of it >>> (I can fire up the C360 to test it on a coherent arch). >> >> I have a 715/50 that probably hasn't been powered on in 15 years if >> you need something that old to test on (I believe the 725/100 uses >> the 7100LC and so is coherent). I'll need to set up a cross-compiler >> ... > > I'm not going to say no to actual testing, but it's going to be a world > of pain getting something so old going. I do have a box of older > systems I keep for architectural testing that I need to rummage around > in ... I just have a vague memory that my 715 actually caught fire a > decade ago and had to be disposed of. I still have a zoo of machines running for such testing, including a 715/64 and two 730. I'm going to test this git tree on the 715/64: git://git.infradead.org/users/hch/misc.git dma_alloc_pages Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: a saner API for allocating DMA addressable pages
Hi Christoph, On 19.08.20 08:55, Christoph Hellwig wrote: > this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs > with a separate new dma_alloc_pages API, which is available on all > platforms. In addition to cleaning up the convoluted code path, this > ensures that other drivers that have asked for better support for > non-coherent DMA to pages with incurring bounce buffering over can finally > be properly supported. > > A git tree is available here: > > git://git.infradead.org/users/hch/misc.git dma_alloc_pages I've tested this tree on my parisc machine which uses the 53c700 and lasi_82596 drivers. Everything worked as expected, so you may add: Tested-by: Helge Deller # parisc Thanks! Helge > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_pages > > > Diffstat: > Documentation/core-api/dma-api.rst | 92 ++ > Documentation/core-api/dma-attributes.rst|8 > Documentation/userspace-api/media/v4l/buffer.rst | 17 - > Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst |1 > arch/alpha/kernel/pci_iommu.c|2 > arch/arm/include/asm/dma-direct.h|4 > arch/arm/mm/dma-mapping-nommu.c |2 > arch/arm/mm/dma-mapping.c|4 > arch/ia64/Kconfig|3 > arch/ia64/hp/common/sba_iommu.c |2 > arch/ia64/kernel/dma-mapping.c | 14 > arch/ia64/mm/init.c |3 > arch/mips/Kconfig|1 > arch/mips/bmips/dma.c|4 > arch/mips/cavium-octeon/dma-octeon.c |4 > arch/mips/include/asm/dma-direct.h |4 > arch/mips/include/asm/jazzdma.h |2 > arch/mips/jazz/jazzdma.c | 102 +-- > arch/mips/loongson2ef/fuloong-2e/dma.c |4 > arch/mips/loongson2ef/lemote-2f/dma.c|4 > arch/mips/loongson64/dma.c |4 > arch/mips/mm/dma-noncoherent.c | 48 +-- > arch/mips/pci/pci-ar2315.c |4 > arch/mips/pci/pci-xtalk-bridge.c |4 > arch/mips/sgi-ip32/ip32-dma.c|4 > arch/parisc/Kconfig |1 > arch/parisc/kernel/pci-dma.c |6 > arch/powerpc/include/asm/dma-direct.h|4 > arch/powerpc/kernel/dma-iommu.c |2 > arch/powerpc/platforms/ps3/system-bus.c |4 > arch/powerpc/platforms/pseries/vio.c |2 > arch/s390/pci/pci_dma.c |2 > arch/x86/kernel/amd_gart_64.c|8 > drivers/gpu/drm/exynos/exynos_drm_gem.c |2 > drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c |3 > drivers/iommu/dma-iommu.c|2 > drivers/iommu/intel/iommu.c |6 > drivers/media/common/videobuf2/videobuf2-core.c | 36 -- > drivers/media/common/videobuf2/videobuf2-dma-contig.c| 19 - > drivers/media/common/videobuf2/videobuf2-dma-sg.c|3 > drivers/media/common/videobuf2/videobuf2-v4l2.c | 12 > drivers/net/ethernet/amd/au1000_eth.c| 15 - > drivers/net/ethernet/i825xx/lasi_82596.c | 36 +- > drivers/net/ethernet/i825xx/lib82596.c | 148 +- > drivers/net/ethernet/i825xx/sni_82596.c | 23 - > drivers/net/ethernet/seeq/sgiseeq.c | 24 - > drivers/nvme/host/pci.c | 79 ++--- > drivers/parisc/ccio-dma.c|2 > drivers/parisc/sba_iommu.c |2 > drivers/scsi/53c700.c| 120 > drivers/scsi/53c700.h|9 > drivers/scsi/sgiwd93.c | 14 > drivers/xen/swiotlb-xen.c|2 > include/linux/dma-direct.h | 55 ++- > include/linux/dma-mapping.h | 32 +- > include/linux/dma-noncoherent.h | 21 - > include/linux/dmapool.h | 23
Re: convert parisc to the generic dma-noncoherent code
On 22.07.2018 21:57, Christoph Hellwig wrote: > On Sun, Jul 22, 2018 at 05:45:40PM +0200, Helge Deller wrote: >> Somehow I now can't reproduce the cache issues any longer. Both, your >> original >> patch and when using flush_kernel_vmap_range(), both work. >> >> So, you can add a >> Tested-by: Helge Deller >> to your original patch series. > > I can merge this through the dma-mapping tree, but given that > it touches only arch/parisc/ it might make more sense to merge it > through the parisc tree. Sure, I will take it through the parisc tree. Thanks! Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: convert parisc to the generic dma-noncoherent code
On 17.07.2018 15:19, Christoph Hellwig wrote: > On Sun, Jul 15, 2018 at 12:29:37PM -0400, John David Anglin wrote: >> On 2018-07-13 4:14 AM, Helge Deller wrote: >>> On 11.07.2018 17:34, Christoph Hellwig wrote: >>>> ping? Any comments? >>> I applied those 3 patches on top of git head, and booted the >>> 32-bit kernel on a HP 715/64 (PCX-L) and a HP B160L (PCX-L2). >>> On both machines I had problems with those drivers which use >>> DMA (I checked specifically the lasi NIC card, which is the >>> main onboard NIC card in both machines). >>> Getting IP via DHCP was unreliable, pings on the same network >>> to both machines gave lost packets, login via ssh sometimes failed >>> and so on. >>> >>> So, there is definitively some cache-flush missing in this patchset. >> Possibly, the code should use flush_kernel_vmap_range() as it purges the >> TLB entries used >> for the cache flush. Some of the routines in pci-dma.c currently use it. > > That might be worth a try and is already discussed in my description. > > Also it might be good to check that the last patch really is the culprit, > I'm pretty certain it is, but a double check never hurts. Somehow I now can't reproduce the cache issues any longer. Both, your original patch and when using flush_kernel_vmap_range(), both work. So, you can add a Tested-by: Helge Deller to your original patch series. Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: convert parisc to the generic dma-noncoherent code
On 11.07.2018 17:34, Christoph Hellwig wrote: > ping? Any comments? I applied those 3 patches on top of git head, and booted the 32-bit kernel on a HP 715/64 (PCX-L) and a HP B160L (PCX-L2). On both machines I had problems with those drivers which use DMA (I checked specifically the lasi NIC card, which is the main onboard NIC card in both machines). Getting IP via DHCP was unreliable, pings on the same network to both machines gave lost packets, login via ssh sometimes failed and so on. So, there is definitively some cache-flush missing in this patchset. I'm happy to test any further patches, but I'l be blocked at least until end of next week. It would be good if James could do some testing on his PCX-machine too, since that machine is different than mine. Thanks for your efforts to clean that up! Helge > On Tue, Jun 19, 2018 at 09:04:52AM +0200, Christoph Hellwig wrote: >> This should address all the comments raised last time. For the record: Here is the link to the patchbundle: https://patchwork.kernel.org/bundle/helge/DMA_OP/ ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
On 18.05.2018 15:03, Alexey Brodkin wrote: > But the real fix of my problem is: > >8 > --- a/lib/dma-noncoherent.c > +++ b/lib/dma-noncoherent.c > @@ -35,7 +35,7 @@ static dma_addr_t dma_noncoherent_map_page(struct device > *dev, struct page *page > > addr = dma_direct_map_page(dev, page, offset, size, dir, attrs); > if (!dma_mapping_error(dev, addr) && !(attrs & > DMA_ATTR_SKIP_CPU_SYNC)) > - arch_sync_dma_for_device(dev, page_to_phys(page), size, dir); > + arch_sync_dma_for_device(dev, page_to_phys(page) + offset, > size, dir); > return addr; > } > >8 > > You seem to lost an offset in the page so if we happen to have a buffer not > aligned to > a page boundary then we were obviously corrupting data outside our data :) Good. This patch seems to fix the dma issues I faced on my 32bit B160L parisc box. So it leaves only one open issue on parisc: Now every 32 bit parisc system is unnecessarily non-coherent. Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: common non-cache coherent direct dma mapping ops
On 11.05.2018 09:59, Christoph Hellwig wrote: > this series continues consolidating the dma-mapping code, with a focus > on architectures that do not (always) provide cache coherence for DMA. > Three architectures (arm, mips and powerpc) are still left to be > converted later due to complexity of their dma ops selection. > > The dma-noncoherent ops calls the dma-direct ops for the actual > translation of streaming mappins and allow the architecture to provide > any cache flushing required for cpu to device and/or device to cpu > ownership transfers. The dma coherent allocator is for now still left > entirely to architecture supplied implementations due the amount of > variations. Hopefully we can do some consolidation for them later on > as well. > > A lot of architectures are currently doing very questionable things > in their dma mapping routines, which are documented in the changelogs > for each patch. Please review them very careful and correct me on > incorrect assumptions. > > Because this series sits on top of two previously submitted series > a git tree might be useful to actually test it. It is provided here: > > git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent > > Changes since RFC: > - fix a typo accidentally disabling the device to cpu transfer sync > - fixed a few compile failures I tested it again on parisc (this time again on top of git head) and it still breaks the same way as I reported in my mail on April 21st: the lasi82956 network driver works unreliable. NIC gets IP, but ping doesn't work. See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() functions. See comment in James mail from April 21st too: -> you just made every 32 bit parisc system unnecessarily use non-coherent. Helge ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 09/16] parisc: convert to dma_map_ops
On 09.11.2015 19:17, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <h...@lst.de>
Nice cleanup/consolidation patches!
I pulled your branch, built the 32- and 64bit parisc kernels
and successfully booted them on 3 different PA-RISC machines:
HP 715/64, C3000 and C8000
Everything OK.
Tested-by: Helge Deller <del...@gmx.de>
Acked-by: Helge Deller <del...@gmx.de>
Thanks!
Helge
> ---
> arch/parisc/Kconfig | 2 +
> arch/parisc/include/asm/dma-mapping.h | 189
> ++
> arch/parisc/kernel/drivers.c | 2 +-
> arch/parisc/kernel/pci-dma.c | 92 ++---
> drivers/parisc/ccio-dma.c | 57 +-
> drivers/parisc/sba_iommu.c| 52 +-
> 6 files changed, 124 insertions(+), 270 deletions(-)
>
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index c365469..bdabfcd 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -29,6 +29,8 @@ config PARISC
> select TTY # Needed for pdc_cons.c
> select HAVE_DEBUG_STACKOVERFLOW
> select HAVE_ARCH_AUDITSYSCALL
> + select ARCH_NO_COHERENT_DMA_MMAP
> + select HAVE_DMA_ATTRS
>
> help
> The PA-RISC microprocessor is designed by Hewlett-Packard and used
> diff --git a/arch/parisc/include/asm/dma-mapping.h
> b/arch/parisc/include/asm/dma-mapping.h
> index d8d60a5..4de5186 100644
> --- a/arch/parisc/include/asm/dma-mapping.h
> +++ b/arch/parisc/include/asm/dma-mapping.h
> @@ -1,30 +1,11 @@
> #ifndef _PARISC_DMA_MAPPING_H
> #define _PARISC_DMA_MAPPING_H
>
> -#include
> -#include
> #include
>
> -/* See Documentation/DMA-API-HOWTO.txt */
> -struct hppa_dma_ops {
> - int (*dma_supported)(struct device *dev, u64 mask);
> - void *(*alloc_consistent)(struct device *dev, size_t size, dma_addr_t
> *iova, gfp_t flag);
> - void *(*alloc_noncoherent)(struct device *dev, size_t size, dma_addr_t
> *iova, gfp_t flag);
> - void (*free_consistent)(struct device *dev, size_t size, void *vaddr,
> dma_addr_t iova);
> - dma_addr_t (*map_single)(struct device *dev, void *addr, size_t size,
> enum dma_data_direction direction);
> - void (*unmap_single)(struct device *dev, dma_addr_t iova, size_t size,
> enum dma_data_direction direction);
> - int (*map_sg)(struct device *dev, struct scatterlist *sg, int nents,
> enum dma_data_direction direction);
> - void (*unmap_sg)(struct device *dev, struct scatterlist *sg, int
> nhwents, enum dma_data_direction direction);
> - void (*dma_sync_single_for_cpu)(struct device *dev, dma_addr_t iova,
> unsigned long offset, size_t size, enum dma_data_direction direction);
> - void (*dma_sync_single_for_device)(struct device *dev, dma_addr_t iova,
> unsigned long offset, size_t size, enum dma_data_direction direction);
> - void (*dma_sync_sg_for_cpu)(struct device *dev, struct scatterlist *sg,
> int nelems, enum dma_data_direction direction);
> - void (*dma_sync_sg_for_device)(struct device *dev, struct scatterlist
> *sg, int nelems, enum dma_data_direction direction);
> -};
> -
> /*
> -** We could live without the hppa_dma_ops indirection if we didn't want
> -** to support 4 different coherent dma models with one binary (they will
> -** someday be loadable modules):
> +** We need to support 4 different coherent dma models with one binary:
> +**
> ** I/O MMUconsistent method dma_sync behavior
> ** = == ===
> ** a) PA-7x00LCuncachable host memory flush/purge
> @@ -40,158 +21,22 @@ struct hppa_dma_ops {
> */
>
> #ifdef CONFIG_PA11
> -extern struct hppa_dma_ops pcxl_dma_ops;
> -extern struct hppa_dma_ops pcx_dma_ops;
> +extern struct dma_map_ops pcxl_dma_ops;
> +extern struct dma_map_ops pcx_dma_ops;
> #endif
>
> -extern struct hppa_dma_ops *hppa_dma_ops;
> -
> -#define dma_alloc_attrs(d, s, h, f, a) dma_alloc_coherent(d, s, h, f)
> -#define dma_free_attrs(d, s, h, f, a) dma_free_coherent(d, s, h, f)
> -
> -static inline void *
> -dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle,
> -gfp_t flag)
> -{
> - return hppa_dma_ops->alloc_consistent(dev, size, dma_handle, flag);
> -}
> -
> -static inline void *
> -dma_alloc_noncoherent(struct device *dev, size_t size, dma_addr_t
> *dma_handle,
> - gfp_t flag)
> -{
> - return hppa_dma_ops->alloc_noncoherent(dev, size, dma_handle, flag);
> -}
> -
> -static inline void
> -dma_free_coherent(struct device *dev, size_t size,
> - void *vaddr, dma_addr_t
