Mason <slash.tmp@xxxxxxx> writes: > On 17/11/2016 17:10, Måns Rullgård wrote: > >> Mason writes: >> >>> On 17/11/2016 14:05, Måns Rullgård wrote: >>> >>>> I don't see why the sbox needs to be configured first. It's just a >>>> crossbar switch, and until something starts actually issuing requests, >>>> it shouldn't matter how it is connected. >>> >>> If the NAND controller starts sending to an uninitialized SBOX, >>> then (IIUC) some bits are lost forever (black-holed). >> >> That's expected. Don't do that. >> >>> So "NAND, SBOX, MBUS" cannot work. >>> >>> "SBOX, MBUS, NAND" should work, but it doesn't. >>> >>> "SBOX, NAND, MBUS" works. >>> >>> Perhaps there is a better solution than making a channel exclusive >>> to a client. Do you have a suggestion? >> >> First figure out exactly what the hardware requires. How did the >> hardware designers expect it to be used? > > That is precisely the problem :-( > > I sat down with a HW engineer, and gave him the trace of MMIO > writes issued from the NAND and DMA drivers. > > He ran that in a simulation, and reported that it should work. > The reality is that it does not. Perhaps the actual timing is > important (some kind of race condition). How does it "not work"? > I will try generating a more useful trace for the simulation, > with actual timing (I don't know if ARM has an equivalent to > the x86 RDTSC). > > In your opinion, should "SBOX, MBUS, NAND" work for both > reads AND writes? > > Or do you expect a different order for reads and writes? It depends on how dma flow control is implemented in the hardware. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
