Andy Shevchenko <andy.shevchenko@xxxxxxxxx> writes: > +Viresh > > On Mon, Dec 21, 2015 at 2:58 AM, Måns Rullgård <mans@xxxxxxxxx> wrote: >> Andy Shevchenko <andy.shevchenko@xxxxxxxxx> writes: >> >>> 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). >> >> I think they are not. The relevant part of the block diagram for the >> 460EX looks something like this: >> >> +-----+ >> | CPU | >> +-----+ >> | >> +---------------+ >> | BUS | >> +---------------+ >> | | >> +-----+ +-----+ >> | DMA | | RAM | >> +-----+ +-----+ >> | >> +------+ >> | SATA | >> +------+ >> >> The DMA-SATA link is private and ignores the address, which is the only >> reason the driver can possibly work (it's programming a CPU virtual >> address there). > > If you look at the original code the SMS and DMS are programmed > statically independent on DMA direction, so LLP is programmed always > to master 1. I don't think your scheme is reflecting this right. I > could imagine two AHB buses, one of them connects CPU, SATA and RAM, > and the other CPU and DMA. Check the code again. The original code swaps SMS and DMS depending on direction, and it sets LMS to 1. Put differently, it always sets the memory side 1 and the device side to 0. The dw_dma driver sets SMS and DMS to the src/dst_master values provided through dma_request_channel() regardless of the current direction and LMS always zero. If those values didn't matter, why would the fields exist in the first place? > In any case on all Intel SoCs and AVR32, and as far as I can tell on > Spear13xx (Viresh?) there is not a case, that's why I hardly imagine > that the problem is in master numbers by themselves. The 460EX is a PowerPC system. Expect unusual topologies. >>>> 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. >> >> From the Atmel doc: >> >> In Table 17-1 on page 185, all other combinations of LLPx.LOC = 0, >> CTLx.LLP_S_EN, CFGx.RELOAD_SR, CTLx.LLP_D_EN, and CFGx.RELOAD_DS are >> illegal, and causes indeterminate or erroneous behavior. > > I will check Synospys documentation later on. > >> Most likely nothing happens, but I think it ought to be fixed. In fact, >> I have a patch already. > > Good. Send with Fixes tag if it's upstream ready. > >> Come to think of it, I have an AVR32 dev somewhere. Maybe I should dust >> it off. > > I have ATNGW100. I have an AT32ATK1006. Can you suggest a good test to exercise the DMA engine? -- 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
