On 19/03/2020 14.23, Vignesh Raghavendra wrote:
For the read side, it seems that just replacing the UINT_MAX in the two copies of spi_nor_read_data with some smaller constant should suffice. But I don't know if I should make that smaller constant a CONFIG_* option or just pick something like 256K. Thoughts?
Breaking reads into smaller units unconditionally will cause performance regressions. But I would like to avoid adding new CONFIG option as well.
Hm, but how much are we talking about? I can't imagine WATCHDOG_RESET() taking much more than 10us - especially the rate-limited one that has an early return just based on reading the current time will be practically free to call. For me, reading 256K takes about 200ms, which I assume is a rather typical value. Even if I'm off by an order of magnitude on both numbers, we're talking about adding an extra 100us for every 20ms, i.e. 0.5%. And that's extremely pessimistic.
How about resetting the watchdog in the SPI driver's read implementation?
I'd prefer something done in the generic layer, not something specific to this SOC (because next month I'll have another customer with another board based on some ARM SOC that also decided to put on an aggressive gpio watchdog, and next month yet another...).
Or setting max_read_size (in struct spi_slave) to
smaller value in the SPI controller driver to force fragmentation of reads?
Even if one forces fragmentation in that way, the generic layer would still need to grow a WATCHDOG_RESET() call in the read loop, no? It also seems to be an abuse of max_read_size.
Rasmus