Re: Altix I/O code reorganization - 6 of 21

Re: Altix I/O code reorganization - 6 of 21

[Pat Gefre]

> 002-pci-fixups:
>    you're adding tons of non-standard SAL calls for who knows what.  In
>    fact this pretty much looks like you're just moving the existing crappy
>    code into the prom so the bad Linux guys can't complain about it anymore.
>    Please switch to the standard ACPI PCI probing mechanism all other IA64
>    machines support and you can get rid of all that.
>    You're duplicating the kernel's PCI to PCI bridge support, with the normal
>    IA64 pci code it would just work..
> 

2 additional SAL calls were added.  This SAL call multiplexes 
into 10 different calls inside of Prom:

Platform Specific IO Chipset Error Handling:
        PCIIO_CALL_ERROR_INTERRUPT - Handle IO Platform Specific Error Processing.

Platform Specific Virtual Channel Reallocation:
        PCIIO_CALL_RRB_ALLOC - Allocate Read Request Buffers.

Platform Specific Hot Plug Support:
        PCIIO_CALL_SLOT_ENABLE - Hot Plug to support Slot Power Up.
        PCIIO_CALL_SLOT_DISABLE - Hot Plug to support Slot Power Down.

Platform Specific PCI Fixup at Linux Boot Time:
        PCIIO_CALL_GET_HUBDEV_INFO - Retrieve HUBIO chipset info.
        PCIIO_CALL_GET_PCIBUS_INFO - Retrieve PCI Bus Info.
        PCIIO_CALL_GET_PCIDEV_INFO,- Retrieve Platform specific PCE Device Info
        PCIIO_CALL_GET_WIDGET_DMAFLUSH_LIST - Retrieve Workaround DMA Flush Info.

Platform Specific Interrupt Allocation/Deallocation for smp_affinity() support:
	XTALK_CALL_INTR_ALLOC - Initialize IO Chipset Interrupt Registers.
	XTALK_CALL_INTR_FREE - Free IO Chipset Interrupt Registers.

As you can see these SAL calls replaces a lot of config and init code that 
we use to have in the Linux Kernel.  You can probably see that these information 
cannot be carried by ACPI Tables.

Can all these information be replaced by ACPI Tables - currently no.  In the 
future, very good possibility that we will be able to use more of the ACPI tables, 
but, looking at the information needed, the ACPI Tables, and the differences 
in our IO Chipset, we will probably still require some very Platform specific 
SAL calls.

Eventhough, we live within the arch/ia64, our IO Chipsets are definitely not 
anything close to every other arch/ia64 platforms.

The excellent news is that, now that our Prom is probing, and configuring 
every devices in the system, we will be able to send as much information as 
possible via ACPI.  That would naturally be our next step forward.

None of these SAL calls are in the performance path.

What PPB code in the Linux kernel are you commenting on?




For the new code see:

ftp://oss.sgi.com/projects/sn2/sn2-update/002-pci-fixup

Re: Altix I/O code reorganization - 6 of 21

[Christoph Hellwig]

On Wed, Aug 11, 2004 at 06:27:37PM -0500, Pat Gefre wrote:
> 2 additional SAL calls were added.  This SAL call multiplexes 
> into 10 different calls inside of Prom:

Which makes it less non-standard?

> Eventhough, we live within the arch/ia64, our IO Chipsets are definitely not 
> anything close to every other arch/ia64 platforms.

Please look a little closer at the HP zx1 :)

> What PPB code in the Linux kernel are you commenting on?

Spread drivers/pci/*.  Didn't it ever happen to you that Pci to PCI bridges
just work on any other linux plattform?