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). 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? Regards. -- 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