* Re: [PATCH] m8xx_setup.c and PCMCIA
[not found] <3E30F363.1020501@imc-berlin.de>
@ 2003-01-24 15:11 ` Dan Malek
2003-01-24 15:42 ` Steven Scholz
2003-01-26 22:21 ` Paul Mackerras
0 siblings, 2 replies; 4+ messages in thread
From: Dan Malek @ 2003-01-24 15:11 UTC (permalink / raw)
To: Steven Scholz; +Cc: Linuxppc-Embedded
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] m8xx_setup.c and PCMCIA
2003-01-24 15:11 ` [PATCH] m8xx_setup.c and PCMCIA Dan Malek
@ 2003-01-24 15:42 ` Steven Scholz
2003-01-26 22:21 ` Paul Mackerras
1 sibling, 0 replies; 4+ messages in thread
From: Steven Scholz @ 2003-01-24 15:42 UTC (permalink / raw)
To: Linuxppc-Embedded
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] m8xx_setup.c and PCMCIA
2003-01-24 15:11 ` [PATCH] m8xx_setup.c and PCMCIA Dan Malek
2003-01-24 15:42 ` Steven Scholz
@ 2003-01-26 22:21 ` Paul Mackerras
2003-01-27 4:09 ` Dan Malek
1 sibling, 1 reply; 4+ messages in thread
From: Paul Mackerras @ 2003-01-26 22:21 UTC (permalink / raw)
To: Steven Scholz, Dan Malek; +Cc: Linuxppc-Embedded
Dan Malek writes:
> > 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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] m8xx_setup.c and PCMCIA
2003-01-26 22:21 ` Paul Mackerras
@ 2003-01-27 4:09 ` Dan Malek
0 siblings, 0 replies; 4+ messages in thread
From: Dan Malek @ 2003-01-27 4:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Steven Scholz, Linuxppc-Embedded
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-01-27 4:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <3E30F363.1020501@imc-berlin.de>
2003-01-24 15:11 ` [PATCH] m8xx_setup.c and PCMCIA Dan Malek
2003-01-24 15:42 ` Steven Scholz
2003-01-26 22:21 ` Paul Mackerras
2003-01-27 4:09 ` Dan Malek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).