Mason <slash.tmp@xxxxxxx> writes: > On 17/11/2016 23:01, Måns Rullgård wrote: > >> Mason 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"? > > Reading works as expected. Writing fails like this: > > The DMA IRQ triggers as expected, but then software is > supposed to wait for the NAND controller to signal > completion by polling the idle bit. This bit is never > set, it remains stuck at 0. > > But when I do the SBOX setup at init, and do the NAND > before the MBUS setup, the bit is set as expected. What if you do the NAND controller setup before you start the dma transaction, i.e. NAND, SBOX, MBUS, for writes and the opposite (SBOX, MBUS, NAND) for reads? Configuring the receiving end first is usually safe and makes sense. -- 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
