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. --
