Andy Shevchenko <andy.shevchenko@xxxxxxxxx> writes: > On Sun, Dec 20, 2015 at 10:17 PM, Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: >> On Sun, Dec 20, 2015 at 8:49 PM, Måns Rullgård <mans@xxxxxxxxx> wrote: >>> Julian Margetson <runaway@xxxxxxxx> writes: >>>> On 12/20/2015 1:11 PM, Måns Rullgård wrote: >>>>> Julian Margetson <runaway@xxxxxxxx> writes: >> >>>> [ 48.769671] ata3.00: failed command: READ FPDMA QUEUED >>> >>> Well, that didn't help. I still think it's part of the problem, but >>> something else must be wrong as well. The various Master Select fields >>> look like a good place to start. >> >> Master number (which is here would be either 1 or 0) should not affect >> as long as they are connected to the same AHB bus (I would be >> surprised if they are not). >> >>> Also, the manual says the LLP_SRC_EN >>> and LLP_DST_EN flags should be cleared on the last in a chain of blocks. >>> The old sata_dwc driver does this whereas dw_dma does not. >> >> Easy to fix, however I can't get how it might affect. >> >>> It might be worthwhile to try reverting drivers/ata/sata_dwc_460ex.c to >>> v4.0 (leaving the rest at 4.4-rc5) just to make sure that's a good >>> reference. I've verified that this builds. >> >> It would be nice. >> >> I noticed thanks to DWC_PARAMS that burst size is hardcoded to 32 >> items on this board, however registers for SATA program it to 64. I >> remember that I got no interrupt when I programmed transfer width >> wrongly (64 bits against 32 bits) when I ported dw_dmac to be used on >> Intel SoCs. > > One more thing, I have a patch to monitor DMA IO, we may check what > exactly the values are written / read in DMA. I can share it > tomorrow. > > P.S. I also noticed that original driver enables interrupt per each > block And then ignores all but the transfer complete interrupt. > and sets protection control bits. With no indication what the value it sets is supposed to mean. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
