Re: [PATCH v4 0/5] g_NCR5380: PDMA fixes and cleanup

[Finn Thain <fthain@telegraphics.com.au>]

On Wed, 28 Jun 2017, Ondrej Zary wrote:

> 
> Now read seems to work on non-DTC chips. Writes continue in PDMA after 
> disconnect but there's a corruption - one 128 B block missing on 
> disconnect.
> 
> On DTC, the log is spammed with errors like this:
> sd 2:0:1:0: [sdb] tag#0 generic_NCR5380_pread: End of DMA timeout (0)
> 
> They're cause by read corruption on DTC: pread() is breaking at 
> start=3968 because of an end-of-DMA IRQ (BASR=0x98) but pdma_residual is 
> set to zero (block counter is zero because the data was read into the 
> buffer but we did not read it from there). So we lose one buffer of data 
> on each 4 KB read.
>

But the algorithm in the datasheet never reads from the buffer after the 
block counter reaches zero. (Of course, the only datasheet we have is for 
a 53c400 device not a DTC436 so all bets are off.)

Anyway, the corrupted data that you describe is telling. I think you're 
right, we have to drain the buffer even when Gated IRQ has been asserted 
(or find a better way to calculate the residual).

I can see a theoretical problem with the code I sent. If the 53c80 raises 
IRQ during the outsb() or insb(), we could still end up with start == end, 
which could mess up both the residual and the handling for an incomplete 
transfer.

> The PDMA is then reset which probably means BASR_END_DMA_TRANSFER will 
> not be asserted.
> 

But the BASR_END_DMA_TRANSFER flag is latched, and resetting the 53c400 
logic should not affect 53c80 registers (assuming they are accessible). So 
the reset does not explain the log messages.

Maybe your BASR=0x98 observations do not co-incide with the log messages. 
Or maybe we need to wait for registers to become accessible after the 
reset.

I've attempted to address all these issues in v5.

Thanks.

--