Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] restore libata build on frv | Date | Mon, 25 Sep 2006 16:45:38 +0100 |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Fine by me. In that case we need to add > > depends on !FRV || BROKEN > > to drivers/ata/Kconfig and be done with that. BTW, empty libata-portmap.h > > is equivalent to absent one - it still won't build. > > From every public piece of info I can find and from looking at the FRV > tree your changes are correct for the ports Al. I can't find any info on > how legacy IRQ routing is done on FRV systems but if it is not then set > the IRQ values to zero and maybe Dave will stop complaining.
Sigh.
On FRV, inX() and outX() take fully qualified memory-space addresses, exactly as readX() and writeX() (in/out just wrap readX/writeX). This is because:
(1) The FRV has a limited number of static mappings, and these have to specify _all_ access windows to I/O, RAM, ROM, etc. The FRV arch uses a single mapping to handle *all* I/O (which happens to be through the region from 0xE0000000 to 0xFFFFFFFF) thus allowing it to use the remaining mappings for other purposes.
(2) inX() and outX() would have to adjust the addresses to otherwise make them appear PC compatible. Making in() and out() just pass the addresses straight through means I don't have to do any calculation on the address in order to use it.
inb(0x1F0) will, for example, oops because there's no mapping for the bottom virtual megabyte to anywhere, otherwise NULL pointer detection would not be possible.
Don't forget, also, that things like FRV systems generally _won't_ have pluggable PCI buses, and so any devices attached to it will be known in advance, and generalisations can be waived.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |