Quoting Douglas Anderson (2020-06-16 03:40:49) > The geni hardware has a FIFO that can hold up to 64 bytes (it has 16 > entries that can hold 4 bytes each), at least on the two SoCs I tested > (sdm845 and sc7180). We configured our RX Watermark to 0, which > basically meant we got an interrupt as soon as the first 4 bytes > showed up in the FIFO. Tracing the IRQ handler showed that we often > only read 4 or 8 bytes per IRQ handler. > > I tried setting the RX Watermark to "fifo size - 2" but that just got > me a bunch of overrun errors reported. Setting it to "fifo size - 3" > seemed to work great, though. This made me worried that we'd start > getting overruns if we had long interrupt latency, but that doesn't > appear to be the case and delays inserted in the IRQ handler while > using "fifo size - 3" didn't cause any errors. Presumably there is > some interaction with the poorly-documented RFR (ready for receive) > level means that "fifo size - 3" is the max. We are the SPI master, > so it makes sense that there would be no problems with overruns, the > master should just stop clocking. > > Despite "fifo size - 3" working, I chose "fifo size / 2" (8 entries = > 32 bytes) which gives us a little extra time to get to the interrupt > handler and should reduce dead time on the SPI wires. With this > setting, I often saw the IRQ handler handle 40 bytes but sometimes up > to 56 if we had bad interrupt latency. > > Testing by running "flashrom -p ec -r" on a Chromebook saw interrupts > from the SPI driver cut roughly in half. Time was roughly the same. > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > --- Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx> Nice improvement. Maybe it can still have a Fixes tag because it's a performance problem?
