On 2008-08-19, Timothy Normand Miller wrote: > 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.
I intended to take advantage of the fact that if the cache is always on except for IO, then the address and count could be sent unadjusted to the bridge. > 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. Yes, except that I didn't consider caching in HQ. If we want to cache the request, could we not just as well enable the hardware cache? > >> 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. If the pipe empties during a transaction, poll_pci() would save the current address and exit. The next time it is called, it will receive the next write command. It will then issues a new write request to the bridge and continue where it left off. So, the code can handle each PCI command individually. The inner write-loop is just an optimisation. > 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. Maybe I better ask that you ignore the code and write a C version when you get the time. I have the sense that there are many details here which require knowledge of the overall architecture to get right. I think I'll be more helpful with the translation, as I know the assembler and HQ well. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
