Re: [PATCH 06/12] MIPS/octeon: use swiotlb_init instead of open coding it
On Tue, Mar 01, 2022 at 12:53:05PM +0200, Christoph Hellwig wrote: > Use the generic swiotlb initialization helper instead of open coding it. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/cavium-octeon/dma-octeon.c | 15 ++- > arch/mips/pci/pci-octeon.c | 2 +- > 2 files changed, 3 insertions(+), 14 deletions(-) Acked-by: Thomas Bogendoerfer -- 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: MIPS noncoherent DMA cleanups v2
On Wed, Feb 10, 2021 at 10:56:35AM +0100, Christoph Hellwig wrote: > Hi Thomas, > > this series cleans up some of the mips (maybe) noncoherent support. > It also remove the need for the special header only > provided by mips. > > Changes since v1: > - fix a bisection issue due to a missing brace > - simplify the parameter parsing given that it happens after >plat_mem_init series applied to mips-next. 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: MIPS noncoherent DMA cleanups v2
On Wed, Feb 10, 2021 at 10:56:35AM +0100, Christoph Hellwig wrote: > Hi Thomas, > > this series cleans up some of the mips (maybe) noncoherent support. > It also remove the need for the special header only > provided by mips. > > Changes since v1: > - fix a bisection issue due to a missing brace > - simplify the parameter parsing given that it happens after >plat_mem_init LGTM and passed all tests I did so far. I'll give it a few days for others to look at and apply it to mips-next for 5.12. 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, 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 07/18] 53c700: improve non-coherent DMA handling
On Tue, Sep 15, 2020 at 05:51:11PM +0200, Christoph Hellwig wrote: > Switch the 53c700 driver to only use non-coherent descriptor memory if it > really has to because dma_alloc_coherent fails. This doesn't matter for > any of the platforms it runs on currently, but that will change soon. > > To help with this two new helpers to transfer ownership to and from the > device are added that abstract the syncing of the non-coherent memory. > The two current bidirectional cases are mapped to transfers to the > device, as that appears to what they are used for. Note that for parisc, > which is the only architecture this driver needs to use non-coherent > memory on, the direction argument of dma_cache_sync is ignored, so this > will not change behavior in any way. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/53c700.c | 113 +++--- > drivers/scsi/53c700.h | 17 --- > 2 files changed, 72 insertions(+), 58 deletions(-) Tested-by: Thomas Bogendoerfer -- 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 12/18] sgiseeq: convert to dma_alloc_noncoherent
On Tue, Sep 15, 2020 at 05:51:16PM +0200, Christoph Hellwig wrote: > Use the new non-coherent DMA API including proper ownership transfers. > This includes adding additional calls to dma_sync_desc_dev as the > old syncing was rather ad-hoc. > > Thanks to Thomas Bogendoerfer for debugging the ownership transfer > issues. > > Signed-off-by: Christoph Hellwig > --- > drivers/net/ethernet/seeq/sgiseeq.c | 28 ++-- > 1 file changed, 18 insertions(+), 10 deletions(-) Tested-by: Thomas Bogendoerfer -- 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 10/18] hal2: convert to dma_alloc_noncoherent
On Tue, Sep 15, 2020 at 05:51:14PM +0200, Christoph Hellwig wrote: > Use the new non-coherent DMA API including proper ownership transfers. > This also means we can allocate the buffer memory with the proper > direction instead of bidirectional. > > Signed-off-by: Christoph Hellwig > --- > sound/mips/hal2.c | 58 ++- > 1 file changed, 27 insertions(+), 31 deletions(-) Tested-by: Thomas Bogendoerfer -- 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 14/18] dma-mapping: remove dma_cache_sync
On Tue, Sep 15, 2020 at 05:51:18PM +0200, Christoph Hellwig wrote: > All users are gone now, remove the API. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/Kconfig | 1 - > arch/mips/jazz/jazzdma.c| 1 - > arch/mips/mm/dma-noncoherent.c | 6 -- > arch/parisc/Kconfig | 1 - > arch/parisc/kernel/pci-dma.c| 6 -- > include/linux/dma-mapping.h | 8 > include/linux/dma-noncoherent.h | 10 -- > kernel/dma/Kconfig | 3 --- > kernel/dma/mapping.c| 14 -- > 9 files changed, 50 deletions(-) Acked-by: Thomas Bogendoerfer (MIPS part) -- 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 06/18] lib82596: move DMA allocation into the callers of i82596_probe
On Tue, Sep 15, 2020 at 05:51:10PM +0200, Christoph Hellwig wrote: > This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare > for untangling the coherent vs non-coherent DMA allocation API. > > Signed-off-by: Christoph Hellwig > --- > drivers/net/ethernet/i825xx/lasi_82596.c | 24 ++-- > drivers/net/ethernet/i825xx/lib82596.c | 36 > drivers/net/ethernet/i825xx/sni_82596.c | 19 + > 3 files changed, 40 insertions(+), 39 deletions(-) Tested-by: Thomas Bogendoerfer (SNI part) -- 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 11/18] lib82596: convert to dma_alloc_noncoherent
On Tue, Sep 15, 2020 at 05:51:15PM +0200, Christoph Hellwig wrote: > Use the new non-coherent DMA API including proper ownership transfers. > This includes moving the DMA helpers to lib82596 based of an ifdef to > avoid include order problems. > > Signed-off-by: Christoph Hellwig > --- > drivers/net/ethernet/i825xx/lasi_82596.c | 25 ++--- > drivers/net/ethernet/i825xx/lib82596.c | 114 ++- > drivers/net/ethernet/i825xx/sni_82596.c | 4 - > 3 files changed, 80 insertions(+), 63 deletions(-) Tested-by: Thomas Bogendoerfer (SNI part) -- 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 09/18] sgiwd93: convert to dma_alloc_noncoherent
On Tue, Sep 15, 2020 at 05:51:13PM +0200, Christoph Hellwig wrote: > Use the new non-coherent DMA API including proper ownership transfers. > This also means we can allocate the memory as DMA_TO_DEVICE instead > of bidirectional. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/sgiwd93.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) Tested-by: Thomas Bogendoerfer -- 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 15/18] dma-mapping: add a new dma_alloc_pages API
On Tue, Sep 15, 2020 at 05:51:19PM +0200, Christoph Hellwig wrote: > This API is the equivalent of alloc_pages, except that the returned memory > is guaranteed to be DMA addressable by the passed in device. The > implementation will also be used to provide a more sensible replacement > for DMA_ATTR_NON_CONSISTENT flag. > > Additionally dma_alloc_noncoherent is switched over to use dma_alloc_pages > as its backend. > > Signed-off-by: Christoph Hellwig > --- > Documentation/core-api/dma-attributes.rst | 8 --- > arch/alpha/kernel/pci_iommu.c | 2 + > arch/arm/mm/dma-mapping-nommu.c | 2 + > arch/arm/mm/dma-mapping.c | 4 ++ > arch/ia64/hp/common/sba_iommu.c | 2 + > arch/mips/jazz/jazzdma.c | 7 +-- > 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 | 2 + > drivers/iommu/dma-iommu.c | 2 + > drivers/iommu/intel/iommu.c | 4 ++ > drivers/parisc/ccio-dma.c | 2 + > drivers/parisc/sba_iommu.c| 2 + > drivers/xen/swiotlb-xen.c | 2 + > include/linux/dma-direct.h| 5 ++ > include/linux/dma-mapping.h | 34 ++-- > include/linux/dma-noncoherent.h | 3 -- > kernel/dma/direct.c | 52 ++- > kernel/dma/mapping.c | 63 +-- > kernel/dma/ops_helpers.c | 35 + > kernel/dma/virt.c | 2 + > 23 files changed, 206 insertions(+), 37 deletions(-) Acked-by: Thomas Bogendoerfer (MIPS part) -- 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 13/18] 53c700: convert to dma_alloc_noncoherent
On Tue, Sep 15, 2020 at 05:51:17PM +0200, Christoph Hellwig wrote: > Use the new non-coherent DMA API including proper ownership transfers. > > Signed-off-by: Christoph Hellwig > --- > drivers/scsi/53c700.c | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) Tested-by: Thomas Bogendoerfer -- 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 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device
On Tue, Sep 01, 2020 at 07:38:10PM +0200, Thomas Bogendoerfer wrote:
> On Tue, Sep 01, 2020 at 07:16:27PM +0200, Christoph Hellwig wrote:
> > Well, if IP22 doesn't speculate (which I'm pretty sure is the case),
> > dma_sync_single_for_cpu should indeeed be a no-op. But then there
> > also shouldn't be anything in the cache, as the previous
> > dma_sync_single_for_device should have invalidated it. So it seems like
> > we are missing one (or more) ownership transfers to the device. I'll
> > try to look at the the ownership management in a little more detail
> > tomorrow.
>
> this is the problem:
>
>/* Always check for received packets. */
> sgiseeq_rx(dev, sp, hregs, sregs);
>
> so the driver will look at the rx descriptor on every interrupt, so
> we cache the rx descriptor on the first interrupt and if there was
> $no rx packet, we will only see it, if cache line gets flushed for
> some other reason. kick_tx() does a busy loop checking tx descriptors,
> with just sync_desc_cpu...
the patch below fixes the problem.
Thomas.
diff --git a/drivers/net/ethernet/seeq/sgiseeq.c
b/drivers/net/ethernet/seeq/sgiseeq.c
index 8507ff242014..876e3700a0e4 100644
--- a/drivers/net/ethernet/seeq/sgiseeq.c
+++ b/drivers/net/ethernet/seeq/sgiseeq.c
@@ -112,14 +112,18 @@ struct sgiseeq_private {
static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
{
- dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
- DMA_FROM_DEVICE);
+ struct sgiseeq_private *sp = netdev_priv(dev);
+
+ dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
+ sizeof(struct sgiseeq_rx_desc), DMA_FROM_DEVICE);
}
static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
{
- dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
- DMA_TO_DEVICE);
+ struct sgiseeq_private *sp = netdev_priv(dev);
+
+ dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
+ sizeof(struct sgiseeq_rx_desc), DMA_TO_DEVICE);
}
--
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 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device
On Tue, Sep 01, 2020 at 07:16:27PM +0200, Christoph Hellwig wrote: > Well, if IP22 doesn't speculate (which I'm pretty sure is the case), > dma_sync_single_for_cpu should indeeed be a no-op. But then there > also shouldn't be anything in the cache, as the previous > dma_sync_single_for_device should have invalidated it. So it seems like > we are missing one (or more) ownership transfers to the device. I'll > try to look at the the ownership management in a little more detail > tomorrow. this is the problem: /* Always check for received packets. */ sgiseeq_rx(dev, sp, hregs, sregs); so the driver will look at the rx descriptor on every interrupt, so we cache the rx descriptor on the first interrupt and if there was $no rx packet, we will only see it, if cache line gets flushed for some other reason. kick_tx() does a busy loop checking tx descriptors, with just sync_desc_cpu... 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 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device
On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote:
> On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> > Use the proper modern API to transfer cache ownership for incoherent DMA.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> > drivers/net/ethernet/seeq/sgiseeq.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/seeq/sgiseeq.c
> > b/drivers/net/ethernet/seeq/sgiseeq.c
> > index 39599bbb5d45b6..f91dae16d69a19 100644
> > --- a/drivers/net/ethernet/seeq/sgiseeq.c
> > +++ b/drivers/net/ethernet/seeq/sgiseeq.c
> > @@ -112,14 +112,18 @@ struct sgiseeq_private {
> >
> > static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
> > {
> > - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> > - DMA_FROM_DEVICE);
> > + struct sgiseeq_private *sp = netdev_priv(dev);
> > +
> > + dma_sync_single_for_cpu(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> > + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> > }
> >
> > static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
> > {
> > - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> > - DMA_TO_DEVICE);
> > + struct sgiseeq_private *sp = netdev_priv(dev);
> > +
> > + dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> > + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> > }
>
> this breaks ethernet on IP22 completely, but I haven't figured out why, yet.
the problem is that dma_sync_single_for_cpu() doesn't flush anything
for IP22, because it only flushes for CPUs which do speculation. So
either MIPS arch_sync_dma_for_cpu() should always flush or sgiseeq
needs to use a different sync funktion, when it wants to re-read descriptors
from memory.
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 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device
On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> Use the proper modern API to transfer cache ownership for incoherent DMA.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/net/ethernet/seeq/sgiseeq.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/seeq/sgiseeq.c
> b/drivers/net/ethernet/seeq/sgiseeq.c
> index 39599bbb5d45b6..f91dae16d69a19 100644
> --- a/drivers/net/ethernet/seeq/sgiseeq.c
> +++ b/drivers/net/ethernet/seeq/sgiseeq.c
> @@ -112,14 +112,18 @@ struct sgiseeq_private {
>
> static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
> {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> -DMA_FROM_DEVICE);
> + struct sgiseeq_private *sp = netdev_priv(dev);
> +
> + dma_sync_single_for_cpu(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> }
>
> static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
> {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> -DMA_TO_DEVICE);
> + struct sgiseeq_private *sp = netdev_priv(dev);
> +
> + dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> }
this breaks ethernet on IP22 completely, but I haven't figured out why, yet.
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 09/28] MIPS/jazzdma: remove the unused vdma_remap function
On Wed, Aug 19, 2020 at 08:55:36AM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > arch/mips/include/asm/jazzdma.h | 2 - > arch/mips/jazz/jazzdma.c| 70 - > 2 files changed, 72 deletions(-) Acked-by: Thomas Bogendoerfer -- 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 10/28] MIPS/jazzdma: decouple from dma-direct
On Wed, Aug 19, 2020 at 08:55:37AM +0200, Christoph Hellwig wrote: > The jazzdma ops implement support for a very basic IOMMU. Thus we really > should not use the dma-direct code that takes physical address limits > into account. This survived through the great MIPS DMA ops cleanup mostly > because I was lazy, but now it is time to fully split the implementations. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/jazz/jazzdma.c | 32 +--- > 1 file changed, 21 insertions(+), 11 deletions(-) Acked-by: Thomas Bogendoerfer -- 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 08/28] MIPS: make dma_sync_*_for_cpu a little less overzealous
On Wed, Aug 19, 2020 at 08:55:35AM +0200, Christoph Hellwig wrote: > When transferring DMA ownership back to the CPU there should never > be any writeback from the cache, as the buffer was owned by the > device until now. Instead it should just be invalidated for the > mapping directions where the device could have written data. > Note that the changes rely on the fact that kmap_atomic is stubbed > out for the !HIGHMEM case to simplify the code a bit. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/mm/dma-noncoherent.c | 44 +- > 1 file changed, 28 insertions(+), 16 deletions(-) Acked-by: Thomas Bogendoerfer -- 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 06/28] lib82596: move DMA allocation into the callers of i82596_probe
On Wed, Aug 19, 2020 at 08:55:33AM +0200, Christoph Hellwig wrote:
> This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare
> for untangling the coherent vs non-coherent DMA allocation API.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/net/ethernet/i825xx/lasi_82596.c | 24 ++--
> drivers/net/ethernet/i825xx/lib82596.c | 36
> drivers/net/ethernet/i825xx/sni_82596.c | 19 +
> 3 files changed, 40 insertions(+), 39 deletions(-)
>
> [...]
> diff --git a/drivers/net/ethernet/i825xx/sni_82596.c
> b/drivers/net/ethernet/i825xx/sni_82596.c
> index 22f5887578b2bd..e80e790ffbd4d4 100644
> --- a/drivers/net/ethernet/i825xx/sni_82596.c
> +++ b/drivers/net/ethernet/i825xx/sni_82596.c
> @@ -24,8 +24,6 @@
>
> static const char sni_82596_string[] = "snirm_82596";
>
> -#define LIB82596_DMA_ATTR0
> -
> #define DMA_WBACK(priv, addr, len) do { } while (0)
> #define DMA_INV(priv, addr, len) do { } while (0)
> #define DMA_WBACK_INV(priv, addr, len) do { } while (0)
> @@ -134,10 +132,19 @@ static int sni_82596_probe(struct platform_device *dev)
> lp->ca = ca_addr;
> lp->mpu_port = mpu_addr;
>
> + lp->dma = dma_alloc_coherent(dev->dev.parent, sizeof(struct i596_dma),
> + >dma_addr, GFP_KERNEL);
this needs to use >dev as device argument otherwise I get a
WARNING: CPU: 0 PID: 1 at linux/kernel/dma/mapping.c:416
dma_alloc_attrs+0x64/0x98
(coherent_dma_mask is set correctly).
dev->dev.parent was correct when going from netdevice to underlying device,
but now allocation is done via platform_device probe. I wonder why this works
for parisc.
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 v2 17/17] memblock: use separate iterators for memory and reserved regions
On Sun, Aug 02, 2020 at 07:36:01PM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > for_each_memblock() is used to iterate over memblock.memory in > a few places that use data from memblock_region rather than the memory > ranges. > > Introduce separate for_each_mem_region() and for_each_reserved_mem_region() > to improve encapsulation of memblock internals from its users. > > Signed-off-by: Mike Rapoport > --- > arch/mips/netlogic/xlp/setup.c | 2 +- Acked-by: Thomas Bogendoerfer 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 v2 12/17] arch, drivers: replace for_each_membock() with for_each_mem_range()
On Sun, Aug 02, 2020 at 07:35:56PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
> end = __pfn_to_phys(memblock_region_memory_end_pfn(reg));
>
> /* do something with start and end */
> }
>
> Using for_each_mem_range() iterator is more appropriate in such cases and
> allows simpler and cleaner code.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/mips/cavium-octeon/dma-octeon.c | 12 +++---
> arch/mips/kernel/setup.c | 31 +++
Acked-by: Thomas Bogendoerfer
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
