On Sat, Aug 23, 2008 at 6:12 AM, Petter Urkedal <[EMAIL PROTECTED]> wrote:
>> Yeah. We need more names for things. :) I think your understanding >> is fine, and what I was incorrectly referring to as HQIO is basically >> the MEM stage and some logic in the HQ wrapper that hooks up IO ports. > > Now wounder there is confusion. It's me who uses my own terminology > incorrectly. Yes, HQIO refers to the negative addresses of the MEM > stage. I should have said "PCI IO handler". > >> Things we need names for: >> >> - VGA legacy I/O space on the PCI bus > > Is that the whole TARGET_IO or just part of it? I used PCI IO above > assuming it's not all legacy VGA. > > --> PCI IO, PCIIO, VGA IO, or VGAIO? How about these names: VGAIO - VGA legacy I/O addresses on the PCI bus PCIMEM - PCI bus access to graphics memory, also called BAR1 PCIENG - PCI bus access to config registers, also called BAR0 Those are what are caught by HQ when not in bypass mode. Side note: We need to make sure that nothing goes wrong when VGAIO is accessed when in bypass mode. Probably best to just leave it disabled at the PCI controller so that the addresses are not responded to. >> - What you get when you access a negative address in the MEM stage > > --> HQIO or HQ IO? HQIO works for me. >> - Microcode handlers that move data between PCI and bridge > > --> Bypass microcode? > > - Microcode handlers which serve various PCI IO addresses. > > --> PCI IO handlers? How about we name it after the subroutine? "poll_pci" ? >> Yeah. It could back up the write queues. In the S3, there's a write >> queue connecting the bridge to the memory arbiter; when it fills to 8 >> entries, it signals busy to the bridge, which propagates to the XP10; >> due to the delays you get roughly 12 entries there before the XP10 >> bridge registers the busy. Then you get another 16 entries on the >> XP10 command queue from HQ to the bridge. If those all fill, then you >> have to stop trying to send commands, or else they'll get lost. >> That's why there is/should be a "free command fifo entries" I/O port >> that HQ can read. > > I added in the tests for free bridge-command slots. The most critical > is the inner loop of writes. With some rearrangements it adds two > instructions, so the inner write loop is now 9 instructions. We could > do some unrolling based on MEM_CMDQ_FREE, but I'm afraid it costs much > in program size with a gain strictly bound by those two instructions. > > I'll check this in now. Awesome! Thanks again for doing all of this work! -- 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)
