On Thu, Oct 8, 2015 at 8:40 PM, Jean-Francois Dagenais <jeff.dagen...@gmail.com> wrote: > >> On Jun 4, 2013, at 1:32 PM, Mark Brown <broo...@kernel.org> wrote: >> >> Applied but this is a bit sad, having to defer the refill to process >> context means that we're adding extra latency which takes us further >> away from being able to saturate the bus. There ought to be a way to >> avoid the issue though I can't think of a non-racy one - I guess level >> triggered interrupts aren't an option? > > Hi all, > > We've been using an improved version of this driver in production for years > here > in the 3.4 tree. I had to intervene in order to improve performance. I managed > to double it (not bad). Thats cool.
> > Like the other threads I've seen about this, my strategy involved limiting the > reads to the registers, which, through a pci-e link were kind of long. Here's > the yet un-submitted commit header I carry in my clone: Why not send the patches. > > ============= > spi: xilinx - minimize iomem reads > > If this IP core is accessed through bridges like PCI-e, reads are rather > costly. Doing many reads or read-modify-writes is thus long and strenuous > on the CPU (active waiting). > > The transfer workflow of this driver allows some assumptions to be made > and > exploited to minimize reads as much as possible. > > These two assumptions are made: > - since we are in control of the CR register, cache it so we don't have to > read it all the time to modify it. Makes sense. > - FIFO (either depth of 1 or 16) are always maxed out, unless the > remaining > bytes are less than the FIFO depth. For this reason, we can predict the > state of the FIFOs without checking with the status register to check if > they are empty or full. Can you explain more details. > > Reading 32Mb flash at 32MHz on a core with 8bits/word and FIFO enabled > (16), > has dropped from ~60s to ~30s. Still high, but better. Most of the delay > still > comes from emptying the RX FIFO one "word" at a time. > =============== > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/