Re: [PATCH] restore libata build on frv

[David Howells <dhowells@redhat.com>]

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/