On Dec 10, 2007 3:46 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2007-12-10, Timothy Normand Miller wrote: > > Here are some things we need to figure out. PCI and the SPI > > controller (iirc) both run in the PCI clock domain, so I am making the > > address decoder do the same. > > By address decoder I assume you mean a 32 bit register which keeps track > of the current address being processed by PCI, and which can > self-increment within the size of a burst, but otherwise is updated > either from PCI or HQ?
No. I mean the logic that detects which internal resource is being accessed through PCI and directs reads and writes to the correct place. I'll post part of what I'm working on for that shortly. > > > However, HQ and the bridge will be in > > another (100MHz or whatever we can manage). Without HQ, we would put > > fifos between the decode (I called this 'glue' elsewhere) and the > > bridge. With HQ, those same fifos would be read by HQ, and HQ would > > therefore read and write the bridge protocol. > > So, the idea is to do this in oga1hq_io? As discussed before, we don't > want to pass data words though HQ, so what I'm imagining is that HQ can > put oga1hq_io in a state where data words are passed though in either > direction. It will need to know when to leave the pass-through mode, > and since PCI transactions can be aborted, I guess that information must > come from the PCI controller. There'll be some register that defines which accesses go to HQ and which ones don't. These will be mem, engine, and vgaio. Vgaio will go nowhere (discard writes and return 0 for reads) when not connected to HQ. Also, for DMA, you're right that data will not pass through. But in VGA mode, we have to filter everything since HQ will be hogging the bridge. > > > So, this is helping me with the bridge. I'll do some clean up on that > > and write a module with a fifo interface. We'll have the decode talk > > to the fifos and then fit HQ in there next. > > Okay. Now that the PCI fifo is tightly coupled with the HQ I/O, it > should probably be worked out before HQ I/O. Agreed. -- 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)
