On Tue, Aug 19, 2008 at 5:25 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2008-08-19, Timothy Normand Miller wrote: >> The cache is only available to the PCI target. HQ is behind the >> cache. You can take advantage of the cache in order to reduce the >> amount of PCI read traffic that HQ has to service. If the memory >> space is cachable (reads have no side-effects), then enabling the >> cache is a good idea. If reads have side-effects, then disable it. >> The cache is never used for engine access. Engine registers can be >> volatile, so we don't want to return stale data. > > Okay, then we'll need to deal with unaligned PCI reads. I simplified it > by truncating read requests to a single granule. I attach a preliminary > poll_pci implementation. I assumed everything to be word-addressed, so > that has to be fixed, at least. The compiled code is 115 instruction > words.
Sortof. If the cache is off, then the address you get is the address PCI wants. If the cache is on, then the address is the first address of the cache line. Either way, you can just take the address and count at face value. Now (and this is what I think you may be talking about), if you're going to turn the cache off and then do caching in HQ, then you have to mask the address in software. >> If writes occur then nothing, you'll never see a non-write. The only >> solution is to bring some PCI state info into where HQ can get at it. >> For instance, we could add a null command to the fifo. Whenever the >> target terminates a transaction, we send this null command down the >> command pipe. The bridge should be designed to ignore it, but HQ can >> use it as a hint that writes are done. > > We have already defined an "idle" command type to be zero, though I > guess it's currently unused. Rather than pushing this onto the pipe, I > think it would be more convenient from the code point of view if the > PCI_T_CMD_INFO port returns 0 (idle) when the pipe is empty. That saves > us two instructions to check PCI_T_CMD_COUNT in the inner write-loop > (see CHECKME in the code). The pipe being empty doesn't tell you enough. You could have a bunch of wait states inserted on the PCI bus, so the queue empties, but the transaction isn't finished. At the same time, the null command has to be inserted into the pipe so that it synchronizes with everything else. I've looked over the code you wrote, but reading assembly is hard, so I'm going to have to come back to it again before I can comment intelligently. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
