svn commit: r219964 - projects/altix/sys/ia64/sgisn

[Marcel Moolenaar]

On Mar 24, 2011, at 10:04 AM, John Baldwin wrote:

> On Thursday, March 24, 2011 12:56:34 pm Marcel Moolenaar wrote:
>> Author: marcel
>> Date: Thu Mar 24 16:56:33 2011
>> New Revision: 219964
>> URL: http://svn.freebsd.org/changeset/base/219964
>> 
>> Log:
>>  Add necessary address space mapping. The Altix architecture has distinct
>>  address spaces for PCI devices and CPUs. That is, the S-Hub translates
>>  addresses on the FSB and coming from CPUs to addresses valid on the PCI bus.
>>  This is abstracted and implemented in FreeBSD by having the handle contain the
>>  CPU address, while the resource itself describes the PCI bus address. Since
>>  devices are mapped when resources are activated and the bus handle is derived
>>  from that, have the SGI PCI bus driver handle the activation of resources
>>  instead of passing it up to the nexus.
>> 
>>  Note that the Altix architecture allows for IRQ values larger than 255 even
>>  though the intline register in the PCI configuration space does not. FreeBSD
>>  also doesn't support it by virtue of having an IRQ resource space that's
>>  limited. On my machines the IRQ values are within bounds so I'm not going to
>>  worry about this detail. It may very well be theoretical.
> 
> FreeBSD certainly supports any arbitrary range of unsigned long values as IRQ
> resources.  MSI on x86 uses IRQs > 255 for example.  The PCI bus code does
> assume that IRQ 255 is a cookie value that can be used for an invalid INTx
> IRQ, but that's the only assumption it makes.
> 
> The limit on the IRQ rman in the nexus is put in place by each platform.  If
> you want a larger range, just fix the initialization of your rman.

That's what I said in the commit log :-) It's not a problem, so I'm not going
to worry about it. Getting interrupts to work is a problem. Since there's no
I/O SAPIC but some other odd handshaking, I do need to abstract PICs like we
did on PowerPC.

BTW: Do you think it's feasible or worthwhile to move all of the interrupt
handling to MI if we have an MI abstraction of PICs? With multiple passes of
bus enumeration we should be able to probe and attach all PIC devices that
implement a standard PIC interface for MI code to use, right?

On PowerPC we have very good results so far and all we're lacking there is
the multi-pass support so that we can map the multiple PICs onto the flat
IRQ resource space before we need to now that mapping (which is currently
handled by a kluge, really).

-- 
Marcel Moolenaar
xcllnt at mac.com