On 1/17/25 13:41, Mark Brown wrote: > On Fri, Jan 17, 2025 at 07:31:08PM +0100, Miquel Raynal wrote: >> On 17/01/2025 at 13:21:58 GMT, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > If you're hitting a timeout that tends to indicate there's already a >> > serious stability problem... > >> Yes, unless the timeout is reached for "good reasons", ie. you request >> substantial amounts of data (typically from a memory device) and the >> timeout is too short compared to the theoretical time spent in the >> transfer. A loaded machine can also increase the number of false >> positives I guess. > > I'd argue that all of those are bad reasons, I'd only expect us to time > out when there's a bug - choosing too low a timeout or doing things in a > way that generates timeouts under load is a problem. There's no transmit DMA for this device. So if you are under high load and make a long transfer, it's possible to time out. I don't know if it's possible to fix that very easily. The timeout calculation assumes that data is being transferred at the SPI bus rate. That said, in the common case (NOR flash) writes don't work like that. To write a flash, we make a short transfer (such as an eraseblock) and then poll the status register before making another transfer. With short transfers there is less probability of timing out because the extra time makes up more of the duration. --Sean
