From: David Howells <dhowells@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Al Viro <viro@ftp.linux.org.uk>,
David Howells <dhowells@redhat.com>,
Linus Torvalds <torvalds@osdl.org>,
Jeff Garzik <jgarzik@pobox.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] restore libata build on frv
Date: Mon, 25 Sep 2006 16:45:38 +0100 [thread overview]
Message-ID: <22061.1159199138@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <1159198774.11049.87.camel@localhost.localdomain>
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
prev parent reply other threads:[~2006-09-25 15:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 22:39 [PATCH] restore libata build on frv Al Viro
2006-09-25 10:44 ` David Howells
2006-09-25 11:26 ` Alan Cox
2006-09-25 11:04 ` Russell King
2006-09-25 11:28 ` David Howells
2006-09-25 11:27 ` David Howells
2006-09-25 12:19 ` Alan Cox
2006-09-25 12:18 ` David Howells
2006-09-25 14:20 ` Al Viro
2006-09-25 14:39 ` David Howells
2006-09-25 15:46 ` Alan Cox
2006-09-25 16:04 ` David Howells
2006-09-25 16:21 ` Al Viro
2006-09-26 8:06 ` David Woodhouse
2006-09-26 8:52 ` Jeff Garzik
2006-09-26 8:56 ` David Woodhouse
2006-09-26 11:25 ` Alan Cox
2006-09-26 11:30 ` Alan Cox
2006-09-26 16:15 ` Linus Torvalds
2006-09-26 17:25 ` David Howells
2006-09-26 20:21 ` David Woodhouse
2006-09-27 7:05 ` David Woodhouse
2006-09-25 15:39 ` Alan Cox
2006-09-25 15:45 ` David Howells [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22061.1159199138@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox