Re: [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA allocations

2019-06-14 Thread Eugeniy Paltsev
Hi Christoph,

Regular question - do you have any public git repository with all this dma 
changes?
I want to test it for ARC.

Pretty sure the
 [PATCH 2/7] arc: remove the partial DMA_ATTR_NON_CONSISTENT support
is fine.

Not so sure about
 [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA 
allocations
:)

On Fri, 2019-06-14 at 16:44 +0200, Christoph Hellwig wrote:
> Replace the code that sets up uncached PTEs with the generic vmap based
> remapping code.  It also provides an atomic pool for allocations from
> non-blocking context, which we not properly supported by the existing
> arc code.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arc/Kconfig  |  2 ++
>  arch/arc/mm/dma.c | 62 ---
>  2 files changed, 12 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 23e063df5d2c..cdad7d30ff1d 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -10,6 +10,7 @@ config ARC
>   def_bool y
>   select ARC_TIMERS
>   select ARCH_HAS_DMA_COHERENT_TO_PFN
> + select ARCH_HAS_DMA_PREP_COHERENT
>   select ARCH_HAS_PTE_SPECIAL
>   select ARCH_HAS_SETUP_DMA_OPS
>   select ARCH_HAS_SYNC_DMA_FOR_CPU
> @@ -19,6 +20,7 @@ config ARC
>   select BUILDTIME_EXTABLE_SORT
>   select CLONE_BACKWARDS
>   select COMMON_CLK
> + select DMA_DIRECT_REMAP
>   select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
>   select GENERIC_CLOCKEVENTS
>   select GENERIC_FIND_FIRST_BIT
> diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
> index 9832928f896d..0fa850709fac 100644
> --- a/arch/arc/mm/dma.c
> +++ b/arch/arc/mm/dma.c
> @@ -11,46 +11,15 @@
>  #include 
>  
>  /*
> - * ARCH specific callbacks for generic noncoherent DMA ops 
> (dma/noncoherent.c)
> + * ARCH specific callbacks for generic noncoherent DMA ops
>   *  - hardware IOC not available (or "dma-coherent" not set for device in DT)
>   *  - But still handle both coherent and non-coherent requests from caller
>   *
>   * For DMA coherent hardware (IOC) generic code suffices
>   */
> -void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> - gfp_t gfp, unsigned long attrs)
> -{
> - unsigned long order = get_order(size);
> - struct page *page;
> - phys_addr_t paddr;
> - void *kvaddr;
> -
> - /*
> -  * __GFP_HIGHMEM flag is cleared by upper layer functions
> -  * (in include/linux/dma-mapping.h) so we should never get a
> -  * __GFP_HIGHMEM here.
> -  */
> - BUG_ON(gfp & __GFP_HIGHMEM);
> -
> - page = alloc_pages(gfp | __GFP_ZERO, order);
> - if (!page)
> - return NULL;
> -
> - /* This is linear addr (0x8000_ based) */
> - paddr = page_to_phys(page);
> -
> - *dma_handle = paddr;
> -
> - /*
> -  * A coherent buffer needs MMU mapping to enforce non-cachability.
> -  * kvaddr is kernel Virtual address (0x7000_ based).
> -  */
> - kvaddr = ioremap_nocache(paddr, size);
> - if (kvaddr == NULL) {
> - __free_pages(page, order);
> - return NULL;
> - }
>  
> +void arch_dma_prep_coherent(struct page *page, size_t size)
> +{
>   /*
>* Evict any existing L1 and/or L2 lines for the backing page
>* in case it was used earlier as a normal "cached" page.
> @@ -61,24 +30,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, 
> dma_addr_t *dma_handle,
>* Currently flush_cache_vmap nukes the L1 cache completely which
>* will be optimized as a separate commit
>*/
> - dma_cache_wback_inv(paddr, size);
> - return kvaddr;
> -}
> -
> -void arch_dma_free(struct device *dev, size_t size, void *vaddr,
> - dma_addr_t dma_handle, unsigned long attrs)
> -{
> - phys_addr_t paddr = dma_handle;
> - struct page *page = virt_to_page(paddr);
> -
> - iounmap((void __force __iomem *)vaddr);
> - __free_pages(page, get_order(size));
> -}
> -
> -long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
> - dma_addr_t dma_addr)
> -{
> - return __phys_to_pfn(dma_addr);
> + dma_cache_wback_inv(page_to_phys(page), size);
>  }
>  
>  /*
> @@ -155,3 +107,9 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
> u64 size,
>   dev_info(dev, "use %sncoherent DMA ops\n",
>dev->dma_coherent ? "" : "non");
>  }
> +
> +static int __init atomic_pool_init(void)
> +{
> + return dma_atomic_pool_init(GFP_KERNEL, pgprot_noncached(PAGE_KERNEL));
> +}
> +postcore_initcall(atomic_pool_init);
-- 
 Eugeniy Paltsev
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: ensure dma_alloc_coherent always returns zeroed memory

2018-12-20 Thread Eugeniy Paltsev
Hi Christoph,

I test kernel from your 'dma-alloc-always-zero' branch, and as
I can see we have DMA peripherals (like USB) broken.

There are the errors example I got during USB initializing:
-->8
usb 1-1: device descriptor read/64, error -110
usb usb1-port1: attempt power cycle
usb 1-1: new high-speed USB device number 4 using ehci-platform
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new high-speed USB device number 5 using ehci-platform
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb usb1-port1: unable to enumerate USB device
usb 2-1: new full-speed USB device number 2 using ohci-platform
usb 2-1: device descriptor read/all, error -84
usb 2-1: new full-speed USB device number 3 using ohci-platform
usb 2-1: device descriptor read/all, error -84
usb usb2-port1: attempt power cycle
usb 2-1: new full-speed USB device number 4 using ohci-platform
usb 2-1: device descriptor read/8, error -62
usb 2-1: device descriptor read/8, error -62
usb 2-1: new full-speed USB device number 5 using ohci-platform
usb 2-1: device descriptor read/8, error -84
usb 2-1: device descriptor read/8, error -84
usb usb2-port1: unable to enumerate USB device
 [snip]
--8<


On Wed, 2018-12-19 at 17:59 +0100, Christoph Hellwig wrote:
> FYI, I've picked this up for dma-mapping for-next now.
> 
> ___
> linux-snps-arc mailing list
> linux-snps-...@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=ZlJN
> 1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=naBCT96A4RSQJLzBWzuCcmptFGiQDfFTOWJpprqDIVk=cHF84va89ofP6VlrV683ewENUXdaLW7opamLZSkZBgk=
-- 
 Eugeniy Paltsev
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: ensure dma_alloc_coherent always returns zeroed memory

2018-12-20 Thread Eugeniy Paltsev
On Thu, 2018-12-20 at 15:34 +0100, h...@lst.de wrote:
> On Thu, Dec 20, 2018 at 02:32:52PM +0000, Eugeniy Paltsev wrote:
> > Hi Christoph,
> > 
> > I test kernel from your 'dma-alloc-always-zero' branch, and as
> > I can see we have DMA peripherals (like USB) broken.
> 
> I would be really surprised if that is caused by the patch to add
> the zeroing. 
Me too :)

>  Can you check which commit caused the issue by bisecting
> from a known good baseline?

Yep. At least kernel build from v4.20-rc4 (which is base for your branch)
seems to work fine.

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


Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*

2018-12-14 Thread Eugeniy Paltsev
Hi Christoph,

do you have any public git repository with all your dma changes?

I want to test them for ARC.

Thanks.

On Fri, 2018-12-14 at 09:25 +0100, Christoph Hellwig wrote:
> If we want to map memory from the DMA allocator to userspace it must be
> zeroed at allocation time to prevent stale data leaks.   We already do
> this on most common architectures, but some architectures don't do this
> yet, fix them up, either by passing GFP_ZERO when we use the normal page
> allocator or doing a manual memset otherwise.
> 
> Signed-off-by: Christoph Hellwig 
> ---
-- 
 Eugeniy Paltsev
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu