"Porting" doesn't accurately describe how one gets a Linux driver to run on different architectures. If a driver doesn't "just work," generally it's a matter of figuring out which wrong assumptions about the HW (or OS) are embedded in the driver. The goal of this talk is to describe the HP ZX1 IO subsystem and some of the wrong assumptions I've found in 2.4.17 kernel drivers.
A Block Diagram of the ZX1 IO subsystem is quite similar to current PA-RISC systems. In contrast to Intel Itanium boxes, neither supports legacy x86 IO space. For booting, EFI drivers (ugh, DOS is back) are required and IA32 Expansion ROMs are ignored. Platform Services must be used for DMA mapping, interrupts, PCI device discovery. I'll discuss how those services are different between HP's ZX1 platform and my (weak) understanding of IA32. Fortunately, use of these services is the same between both architectures.
I was surprised by which drivers did not Just Work (e.g. tulip, acenic) and will talk about why they didn't. Primarily, the timing of CPU interaction with IO devices is different. ZX1 IO subsystem is also less tolerant of driver "quirks" - things that are wrong but other platforms don't puke on. Lastly, I'll explain what an MCA is and how it's useful for debugging IO driver problems.