From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 3/4] ARM: Xilinx: base header files and assembly macros
Date: Wed, 30 Mar 2011 21:43:51 +0200 [thread overview]
Message-ID: <201103302143.51409.arnd@arndb.de> (raw)
In-Reply-To: <20110330191506.GD2939@n2100.arm.linux.org.uk>
On Wednesday 30 March 2011 21:15:06 Russell King - ARM Linux wrote:
> And how do you deal with PCMCIA implementations where each socket has
> its own separate IO space, each maybe several MB large and may be spread
> across several MB of memory with the PCMCIA attribute and PCMCIA memory
> spaces interspersed. Remember that PCMCIA drivers assume PCI/ISA IO
> support.
I would assume that the majority of implementations uses regular (64KB)
I/O spaces per bus, so within 1 MB, that could fit 16 of them.
> What about platforms which have a real ISA IO space in addition to the
> PCMCIA IO spaces?
I'd do the same as on powerpc: One of them gets registered as the "primary"
bus, which gets the first 64KB. This one is typically the only
one that can support legacy ISA devices with hardcoded I/O port numbers.
Any other bus (PCI, PCMCIA, secondary ISA if needed) can go into one
of the other 15 64KB slots.
> Things aren't as simple as you'd like them to be, and sometimes changing
> this stuff changes userland too (think PCMCIA needing the IO regions
> declared to it from userspace during boot.)
Can you give an example what hardware or driver needs this?
Anyway, the idea is more to have a standard implementation that can be
used by most platforms without causing pain, getting us one step
closer to a multiplatform kernel. If one of the more obscure platforms
doesn't fit, it can still use its own variant and not be part of the
multiplatform configuration. There are a lot of other things needed
before we get there anyway.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
glikely@secretlab.ca, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org, jamie@jamieiles.com,
John Linn <John.Linn@xilinx.com>
Subject: Re: [PATCH V5 3/4] ARM: Xilinx: base header files and assembly macros
Date: Wed, 30 Mar 2011 21:43:51 +0200 [thread overview]
Message-ID: <201103302143.51409.arnd@arndb.de> (raw)
In-Reply-To: <20110330191506.GD2939@n2100.arm.linux.org.uk>
On Wednesday 30 March 2011 21:15:06 Russell King - ARM Linux wrote:
> And how do you deal with PCMCIA implementations where each socket has
> its own separate IO space, each maybe several MB large and may be spread
> across several MB of memory with the PCMCIA attribute and PCMCIA memory
> spaces interspersed. Remember that PCMCIA drivers assume PCI/ISA IO
> support.
I would assume that the majority of implementations uses regular (64KB)
I/O spaces per bus, so within 1 MB, that could fit 16 of them.
> What about platforms which have a real ISA IO space in addition to the
> PCMCIA IO spaces?
I'd do the same as on powerpc: One of them gets registered as the "primary"
bus, which gets the first 64KB. This one is typically the only
one that can support legacy ISA devices with hardcoded I/O port numbers.
Any other bus (PCI, PCMCIA, secondary ISA if needed) can go into one
of the other 15 64KB slots.
> Things aren't as simple as you'd like them to be, and sometimes changing
> this stuff changes userland too (think PCMCIA needing the IO regions
> declared to it from userspace during boot.)
Can you give an example what hardware or driver needs this?
Anyway, the idea is more to have a standard implementation that can be
used by most platforms without causing pain, getting us one step
closer to a multiplatform kernel. If one of the more obscure platforms
doesn't fit, it can still use its own variant and not be part of the
multiplatform configuration. There are a lot of other things needed
before we get there anyway.
Arnd
next prev parent reply other threads:[~2011-03-30 19:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1301444651-18008-1-git-send-email-john.linn@xilinx.com>
2011-03-30 0:24 ` [PATCH V5 1/4] ARM: Xilinx: Adding Xilinx board support John Linn
2011-03-30 0:24 ` John Linn
[not found] ` <1301444651-18008-2-git-send-email-john.linn@xilinx.com>
2011-03-30 0:24 ` [PATCH V5 2/4] ARM: Xilinx: Adding timer support to the platform John Linn
2011-03-30 0:24 ` John Linn
[not found] ` <1301444651-18008-3-git-send-email-john.linn@xilinx.com>
2011-03-30 0:24 ` [PATCH V5 3/4] ARM: Xilinx: base header files and assembly macros John Linn
2011-03-30 0:24 ` John Linn
2011-03-30 11:44 ` Arnd Bergmann
2011-03-30 11:44 ` Arnd Bergmann
2011-03-30 13:17 ` John Linn
2011-03-30 13:17 ` John Linn
2011-03-30 13:29 ` Arnd Bergmann
2011-03-30 13:29 ` Arnd Bergmann
2011-03-30 13:37 ` John Linn
2011-03-30 13:37 ` John Linn
2011-03-30 19:15 ` Russell King - ARM Linux
2011-03-30 19:15 ` Russell King - ARM Linux
2011-03-30 19:43 ` Arnd Bergmann [this message]
2011-03-30 19:43 ` Arnd Bergmann
[not found] ` <1301444651-18008-4-git-send-email-john.linn@xilinx.com>
2011-03-30 0:24 ` [PATCH V5 4/4] ARM: Xilinx: Adding Xilinx platform infrastructure support John Linn
2011-03-30 0:24 ` John Linn
[not found] <1298929919-510-1-git-send-email-john.linn@xilinx.com>
[not found] ` <1298929919-510-2-git-send-email-john.linn@xilinx.com>
[not found] ` <1298929919-510-3-git-send-email-john.linn@xilinx.com>
2011-02-28 21:51 ` [PATCH V5 3/4] ARM: Xilinx: base header files and assembly macros John Linn
2011-02-28 21:51 ` John Linn
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=201103302143.51409.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.