On 2008-08-22, Timothy Normand Miller wrote: > On Fri, Aug 22, 2008 at 4:14 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > > >> For the moment, let's just do the easy thing, which is to hook the > >> unused port of the scratch memory up to the same top-level HQ module > >> ports that let us load the program file. Just one extra address bit > >> and an extra gate on each write-enable. > >> > >> If space gets tight, we can look into program access to the program > >> file, via the HQIO handler. > > > > I think we're still speaking different languages, but I'm not sure where > > the misunderstanding lies. When I refer the HQIO handler I mean a > > fragment of HQ-code which handles a PCI target commands addressed to > > TARGET_IO (as defined in pci_address_decode.v). It has been my > > assumption that TARGET_IO is the mechanism by which the host > > communicates and controls HQ. Maybe that's my misunderstanding. I have > > not at all considered accessing the program file at from HQ code, and I > > don't see how a HQIO handler, which is a host-to-HQ channel, could do > > that. > > 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? > - What you get when you access a negative address in the MEM stage --> HQIO or HQ IO? > - Microcode handlers that move data between PCI and bridge --> Bypass microcode? - Microcode handlers which serve various PCI IO addresses. --> PCI IO handlers? > >> It's always all or nothing. HQ becomes a gatekeeper for the bridge > >> over to the S3. It's only safe to switch when there's absolutely > >> nothing pending on the bridge. So we'll need some way, via PCI, to > >> tell the microcode to go into a safe state, then we wait until it's in > >> that state before changing modes. > > > > Sorry, I misread your original comment. But in any case, if the video > > controller is doing a long read, does it affect HQ in any other way that > > delaying the eventual MEM_READQ_AVAIL becoming non-zero? > > 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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
