Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2018-04-21 at 19:43 +0200, Helge Deller wrote:
> On 20.04.2018 10:03, Christoph Hellwig wrote:
> > Switch to the generic noncoherent direct mapping implementation.
> > 
> > Parisc previously had two different non-coherent dma ops
> > implementation that just different in the way coherent allocations
> > were handled or not handled.  The different behavior is not
> > selected at runtime in the arch_dma_alloc and arch_dma_free
> > routines.  The non-coherent allocation in the pcx cases now uses
> > the dma_direct helpers that are a little more sophisticated and
> > used by a lot of other architectures.
> > 
> > Fix sync_single_for_cpu to do skip the cache flush unless the
> > transfer is to the device to match the more tested unmap_single
> > path which should have the same cache coherency implications.
> > 
> > This also now consistenly uses flush_kernel_dcache_range for cache
> > flushing while previously some of the SG based operations used
> > flush_kernel_vmap_range instead.
> 
> 
> This patch breaks a 32bit kernel on a B160L machine (PA7300LC CPU,
> "pcxl2"). After applying this patch series 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.

That's actually a weird result.  The 32 bit machines have two cases:
those that can make uncached memory by setting the U bit (and thus
don't need the sync operations in the lasi and D700 drivers) and those
that can't.  The latter is basically only the old 700 series.  The B180
is in the class of can set pages to uncached, so it sounds like
something in our uncached memory allocation for dma areas is failing
after this patch set.

I still have an old 700 in my box of curiosities, so I can try to dust
it off and plug it back in when I get home to see what it makes of the
series when it gets fixed.

James

James