Steven Scholz wrote:
Hi there,
I reckon that (almost) all MPC8xx boards that use PCMCIA CS have to call
io_block_mapping() with _IO_BASE anyway....
Well, _almost_ isn't good enough :-)
I hope some of the more PCMCIA literate folks speak up here, because I
think placing IO_BASE into the mix, and certainly io_block_mapping it
is quite wrong. It may be necessary for your board, but it certainly
isn't something that is going to work on many others. All you need is
an 860 with a Tundra PCI bridge and all of these patches will fail to work.
The pcmcia register mapping for you board should take these things
into consideration when that mapping and register configuration is
done, it's not something that should be part of global set up.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dan Malek wrote:
Well, _almost_ isn't good enough :-)
Fair enough!
I hope some of the more PCMCIA literate folks speak up here, because I
think placing IO_BASE into the mix, and certainly io_block_mapping it
is quite wrong. It may be necessary for your board, but it certainly
isn't something that is going to work on many others. All you need is
an 860 with a Tundra PCI bridge and all of these patches will fail to work.
Well, that's why "&& !defined(CONFIG_PCI)"... Or?
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dan Malek writes:
quoted
I reckon that (almost) all MPC8xx boards that use PCMCIA CS have to call
io_block_mapping() with _IO_BASE anyway....
Well, _almost_ isn't good enough :-)
I hope some of the more PCMCIA literate folks speak up here, because I
think placing IO_BASE into the mix, and certainly io_block_mapping it
is quite wrong. It may be necessary for your board, but it certainly
isn't something that is going to work on many others. All you need is
an 860 with a Tundra PCI bridge and all of these patches will fail to work.
The pcmcia register mapping for you board should take these things
into consideration when that mapping and register configuration is
done, it's not something that should be part of global set up.
I'm not really here, I'm on vacation, but anyway...
The PCMCIA layer is one of those places where we can't easily get in
and change its assumptions about how I/O is mapped. The reason is
that it will assign some range of I/O addresses to a card and then
expect to be able to access the card using those addresses.
In more detail, when a card is plugged in, the PCMCIA layer will read
its attribute memory to find out what it is and what memory and I/O
resources it has. For example, suppose it is a modem card that
presents a serial port (16550-style) interface. Its attribute memory
will say that it needs 8 bytes of I/O. The PCMCIA layer will look for
8 bytes of unused I/O space. Suppose it finds 8 bytes free at 0x400.
It will then write that value (0x400) into the appropriate spot in the
card's attribute memory, and expect to be able to do inb(0x400) to
access the card.
Which is, on the face of it, perfectly reasonable. It put the card at
I/O address 0x400 and it expects to be able to access the card at I/O
address 0x400. It creates difficulties for us, of course, because it
is assuming a single space of I/O port addresses with no translations.
What it boils down to is that we have little choice (unless you want
to rewrite the pcmcia layer :) but to make inb/outb etc. do what the
pcmcia layer is expecting. That's the reason for the _IO_BASE mapping
hacks.
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Paul Mackerras wrote:
I'm not really here, I'm on vacation, but anyway...
Me, too :-)
What it boils down to is that we have little choice (unless you want
to rewrite the pcmcia layer :) but to make inb/outb etc. do what the
pcmcia layer is expecting. That's the reason for the _IO_BASE mapping
hacks.
I understand that, I was just concerned about why it was needed and the
way it was done in this patch. The PCMCIA has been working quite well
for many people on the 8xx, so I'm hoping someone that has experience with
that can take a look at these changes and discuss them.
On processors like the 8xx where you have multiple, separate address
spaces that can be the targets of inb/outb, you have to be very careful
how you use the IO_BASE addresses and map those spaces. Anyone making a
change that uses this raises a big red flag, because it usually "fixes"
one configuration and breaks everything else.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/