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

[Ondrej Zary <linux@rainbow-software.org>]

On Wednesday 28 June 2017 06:04:36 Finn Thain wrote:
> Ondrej, would you please test this new series?
>
> Changed since v1:
> - PDMA transfer residual is calculated earlier.
> - End of DMA flag check is now polled (if there is any residual).
>
> Changed since v2:
> - Bail out of transfer loops when Gated IRQ gets asserted.
> - Make udelay conditional on board type.
> - Drop sg_tablesize patch due to performance regression.
>
> Changed since v3:
> - Add Ondrej's workaround for corrupt WRITE commands on DTC boards.
> - Reset the 53c400 logic after any short PDMA transfer.
> - Don't fail the transfer if the 53c400 logic got a reset.
>
>
> Finn Thain (1):
>   g_NCR5380: Cleanup comments and whitespace
>
> Ondrej Zary (4):
>   g_NCR5380: Fix PDMA transfer size
>   g_NCR5380: End PDMA transfer correctly on target disconnection
>   g_NCR5380: Limit PDMA send to 512 B to avoid random corruption on
>     DTC3181E
>   g_NCR5380: Re-work PDMA loops
>
>  drivers/scsi/g_NCR5380.c | 239
> ++++++++++++++++++++++++----------------------- 1 file changed, 120
> insertions(+), 119 deletions(-)

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.
The PDMA is then reset which probably means BASR_END_DMA_TRANSFER will not be 
asserted.


-- 
Ondrej Zary