On Sun, Sep 14, 2008 at 06:38:36PM +0200, Felix Frey wrote: > Am Samstag, 13. September 2008 20:33 meinte Matthew Wilcox: > > On Sat, Sep 13, 2008 at 12:15:34PM -0600, Grant Grundler wrote: > > > On Fri, Sep 12, 2008 at 11:29:39PM +0200, Felix Frey wrote: > > > > Dear readers > > > > > > > > I have a problem with a linux PCI driver I've written. The driver > > > > supports a kind of a data acquisition system, which is implemented in a > > > > programable logic device. It's pci interface does not have master > > > > capability, so every data exchange is initiated by the CPU. > > > > > > > > Well, the driver is fairly simple and simply handles data exchange. It > > > > has to transfer chunks of data from and to the device. To make it fast > > > > I'd like to use burst transfers, which are supported by the device. > > > > Within the driver I use the kernel functions memcpy_fromio and > > > > memcpy_toio to initiate a transfer. > > > > This works so far, however, there are no burst transfers. The bridge > > > > does a complete address cycle for every single word which is a big > > > > waste of time. > > > > > > In order to get multiple data cycles per address cycle, either the CPU > > > and/or the chipset needs to be told it's ok to coalesce the write > > > transactions (memcpy_toio). > > OK. What's the way to go? Does it mean to fiddle around with register > programming of the bridge or are there any architecture independant routines > in the kernels pci subsystem? I don't know of any PCI calls to enable/disable coalescing. I expect for outbound (to device) traffic, you can see how older graphics cards are mapping their onboard RAM since for good perf they depend on the same behavior. For x86, ISTR this required frobbing "MSR"s. I don't know if it's possible to get more than 64-bits across the bus at a time with MMIO reads. Looking at the chipset (PCI bus controller for starters) documentation would be a starting point to see if there is any way to enable a "read return" of more than 64-bits (mmio_readq() in linux kernel) or coalescing MMIO writes to the device. > > Isn't that simply a case of marking the BAR as prefetchable? > > > > Memory locations are characterized as either prefetchable or > > non-prefetchable. Prefetchable memory has the following characteristics: > > - There are no side effects of a read operation. The read operation > > cannot be destructive to either the data or any other state > > information. For example, a FIFO that advances to the next data when read > > would not be prefetchable. Similarly, a location that cleared a status bit > > when read would not be prefetchable. > > - When read, the device is required to return all bytes regardless of the > > byte enables (four or eight depending upon the width of the data > > transfer (refer to Section 3.8.1.)). > > - Bridges are permitted to merge writes into this range (refer to > > Section 3.2.6.). > > Unfortunately it isn't that simple. Marking the BAR's as prefetchable or not > didn't do any difference. (Although it makes sense to me :-| ) And marking the BAR as prefetchable carries a fair amount of baggage. I don't know of any cards that implement prefetchable BARs. ie I expect it's not nearly as well tested. The only solution I know works is to add logic so the card can do DMA itself and thus burst longer streams of data to Host RAM. This is a non-trivial change though. hth, grant > > Felix > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
