Simon Burge wrote:
> On Mon, Jan 30, 2006 at 02:49:26PM -0800, Garrett D'Amore wrote:
>
>   
>> Good.  What I will do is go ahead and commit *that* change seperately,
>> and then commit the PCI code which depends on it after I have changed
>> it. :-)
>>
>> Any objections (Simon?)  Speak up now, please!
>>     
>
> My first broad comment on the PCI-specific parts was the name of the
> device (aupb) - I would have preferred aupci, or at a stretch aupcib
> to keep in line with the current naming conventions.  There was a stub
> entry already in the aubus attachment code for aupci.
>   
I think I forgot to respond to this one earlier.  Sorry 'bout that.  I
actually prefer the name aupci myself, but I decided to use aupb in a
(perhaps foolish) attempt to follow the standards set by other ports. 
There were two choices to follow: XXpb (where "pb" presumably means "pci
bridge"), or some name that doesn't reflect PCI at all (e.g. galileo or
bonito), and then a "device node" (not sure about NetBSD terminology
here) that is "pci".  (E.g. a lot of platforms have a "pci" device that
is not backed by a "pci.c" file, and which is totally different from
platform to platform.)

I'm more than happy to change aupb to aupci if that is preferable. 
After all, its just a name, and "pci" is more descriptive.  I would like
to avoid having to rename all the internal symbols for now, if possible,
but that's just because I'm lazy and there are a bunch of them.  (I
don't trust a global search/replace not to bodge something else.)

Anyway, let me know which you want, and whether it is a blocker for
commit, and I'll do whatever.


> I'm still not conviced about wiring down gobs of memory for PCI vs
> normal allocation and faulting in the pages to the TLB when needed, but
> I'm still open to being convinced this is a win for large areas of PCI
> memory space like frame buffers.
>
> Just to check my memory, we wire down a TLB per 32MB of wired space we
> reserve?  So your PCI patch will wire down 288MB (256MB of PCI mem, 16MB
> of PCI IO and 16MB of PCI config) or 9 TLB entries regardless of how
> much space is needed?  This is close to a third of our total TLB count
> and I'm worried about the performance hit that might cause.  Perhaps
> we could do the wiring after calling pci_configure_bus() (or otherwise
> in the non-PCI_NETBSD_CONFIGURE case) when we know how much space we
> actually need, and then wire only what we do need.
>
> PCI config space access pretty much only occur during system startup,
> and otherwise if you run "pcictl dump" or similar.  It seems a waste to
> burn a wired TLB entry for the life of the system for this use.  I think
> we can get away with just using uvm_km_alloc/pmap_kenter_pa when needed,
> or perhaps just reserve a single 4kB page with uvm_km_alloc once and
> enter a different PA each time we need to do a config cycle.
>
> I'm really trying to get away from using as many wired TLB entries as we
> can - the more often we need to recycle non-wired TLB entries the more
> performance in general is going to get hurt.
>
>
> With the existing wired entries you have now, I wonder if something like:
>
> #define        AU_PCI_MEM_VA           0xf0000000
> #define        AU_PCI_MEM_SZ           0x0e000000    /* 224 MB */
>
> #define        AU_PCI_IO_VA            0xfe000000
> #define        AU_PCI_IO_SZ            0x01000000    /* 16 MB */
>
> #define        AU_PCI_CFG_VA           0xff000000
> #define        AU_PCI_CFG_SZ           0x01000000    /* 16 MB, overkill */
>
> would work better, with all the entries being contiguous?  This
> gives KSEG2 more room for growth if the kernel needs VA for other
> purposes.  Or if we don't need to wire down an entry for PCI config,
> then 240MB/16MB for PCI mem/IO.
>
> Simon.
> --
> Simon Burge                                   <simonb@wasabisystems.com>
> NetBSD Development, Support and Service:   http://www.wasabisystems.com/
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191