From: Benjamin Herrenschmidt <hidden> Date: 2000-03-14 10:03:14
On Tue, Mar 14, 2000, Geert Uytterhoeven [off-list ref]
wrote:
... which they can easily find out by combining /proc/bus/pci with
fix.{smem,mmio}_{start,len}.
Since XFree86 4.0 already has resource handling, it should be a piece of cake
to remove all devices corresponding to any fix.{smem,mmio}_{start,len} from
their list.
Well, while we are at it, we could also work on fixing the PCI problems:
Instead of relying on XFree knowing the host bridge and deducing the
iobase, I beleive we should export from the kernel either one iobase per
PCI device (there can be different busses with different iobases, that's
the case on the new macs and they have the same bus number), or we can
have /proc/bus/pci export "fixed'up" IO addresses (already including the
iobase).
I can code those fixes, but I'm not sure what solution has most chances
of beeing accepted (especially changing /poc/bus/pci semantics). The
problem is that exporting an IO address alone (without the iobase) has
really no meaning on arch that don't have a x86-like separate IO space at
the CPU level.
Back to the subject of fbdev vs. XFree, it would be easy to add an
optional ioctl returning the PCI bus:dev:fn from the fbdev (would be
PCI-specific however). Eventually, it could be a generic ioctl that returns
- A constant indicating the bus type
- A string containing a bus-specific identification
I beleive it's cleaner that relying on resource removal, and may be
useful for other things too (like board-specific userland setup tools
that would want to issue some config space accesses to the card, etc...).
Note that I'd love to see this mecanism of a bus-type/id-string extended
to all devices in the kernel (using /proc/ instead of ioctls) since it
would help solving our problem of configuring OF boot path too. But
that's another story...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 14 Mar 2000, Benjamin Herrenschmidt wrote:
On Tue, Mar 14, 2000, Geert Uytterhoeven [off-list ref]
wrote:
Well, while we are at it, we could also work on fixing the PCI problems:
Instead of relying on XFree knowing the host bridge and deducing the
iobase, I beleive we should export from the kernel either one iobase per
PCI device (there can be different busses with different iobases, that's
the case on the new macs and they have the same bus number), or we can
have /proc/bus/pci export "fixed'up" IO addresses (already including the
iobase).
I can code those fixes, but I'm not sure what solution has most chances
of beeing accepted (especially changing /poc/bus/pci semantics). The
problem is that exporting an IO address alone (without the iobase) has
really no meaning on arch that don't have a x86-like separate IO space at
the CPU level.
Have you talked to Martin Mares about this?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-14 21:22:48
quoted
... which they can easily find out by combining /proc/bus/pci with
fix.{smem,mmio}_{start,len}.
Since XFree86 4.0 already has resource handling, it should be a piece of cake
to remove all devices corresponding to any fix.{smem,mmio}_{start,len} from
their list.
Well, while we are at it, we could also work on fixing the PCI problems:
Instead of relying on XFree knowing the host bridge and deducing the
iobase, I beleive we should export from the kernel either one iobase per
PCI device (there can be different busses with different iobases, that's
the case on the new macs and they have the same bus number), or we can
have /proc/bus/pci export "fixed'up" IO addresses (already including the
iobase).
I'd like to see something like this for instance atyfb knows about the
structure of the devices' mem region (wich memory aperture to use for vram
or mmio) but the X server messes up because it only knows the full
aperture, and detects a conflict between MMIO and vram.
If the X server uses /proc/bus/pci to work it's magic, this would be the
place to fix it.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-14 22:11:35
Hi all,
On 14 Mar, this message from Geert Uytterhoeven echoed through cyberspace:
quoted
Well, while we are at it, we could also work on fixing the PCI problems:
Instead of relying on XFree knowing the host bridge and deducing the
iobase, I beleive we should export from the kernel either one iobase per
PCI device (there can be different busses with different iobases, that's
the case on the new macs and they have the same bus number), or we can
have /proc/bus/pci export "fixed'up" IO addresses (already including the
iobase).
I'd clearly vote for this approach. Something along those lines is
neede as well if you want to use more than one IDE controller at the
same time (or anything other than Apple's integrated controller, for
that matter).
quoted
I can code those fixes, but I'm not sure what solution has most chances
of beeing accepted (especially changing /poc/bus/pci semantics). The
problem is that exporting an IO address alone (without the iobase) has
really no meaning on arch that don't have a x86-like separate IO space at
the CPU level.
I have just yesterday completed my patch doing exactly that (ported
over from 2.2.x); it is, however, PowerMac-only. It's attached below,
and also fixes the missing scan of PCI buses other than bus 0 on
PowerMacs.
Have you talked to Martin Mares about this?
Martin, what is your feeling about this? I think the IO-port-fixup
scheme could be generalized on PPC (or any PCI platform lacking true IO
space); however, it would be best if there were a generic way to find
out the processor base address of the IO space of a specific bus. On
PowerMacs, we get that from OF.
I'm thinking about something along the lines of a resource of the
parent bridge's PCI dev; much like it is available for P2P bridges. So
even though the information is not given directly by host bridges, the
platform fixup code would need to provide those through other means
(typically something firmware-derived).
This would be a step in the direction of a complete resource tree
starting at the host bridges, which, at least on PMacs, is not there
right now. That is needed, however, if dynamic resource allocation is
to produce working results ;-)
Please try this patch if you expierence PCI trouble, and also if you
have IDE in your machine; I'd like to verify I didn't break built-in
PowerMac IDE. Be warned, however....
Flames, comments, cookies, ideas? Beer?
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
From: Gabriel Paubert <hidden> Date: 2000-03-14 22:59:23
On Tue, 14 Mar 2000, Geert Uytterhoeven wrote:
quoted
I can code those fixes, but I'm not sure what solution has most chances
of beeing accepted (especially changing /poc/bus/pci semantics). The
problem is that exporting an IO address alone (without the iobase) has
really no meaning on arch that don't have a x86-like separate IO space at
the CPU level.
Indeed, there is one and only one CPU address space on _all_ architectures
except x86 (even HP's IA64 has does not have the silly I/O space). This
makes /proc/ioports an heresy while /proc/iomem is reasonable. How do you
handle I/O accesses in a machine with several bridges which have
independant PCI I/O spaces which a) appear at discontiguous physical
addresses b) map to the same or overlapping range of I/O addresses c)
support drivers which access hardwired I/O addresses ?
That's simple, there is no solution ;-)(especially if, god forbid, several
buses have an ISA bridge) So you have to select your goals:
- support non-transparent bridges, which is what PPC bridges are,
as "transparently" as possible, this will give support for non transparent
bridges (DEC21554) used in clusters almost for free
- get rid of iobase since the number of instructions which load iobase
into a register in an average kernel is far from negligible and this will
save a few pages: in some sequences it's about 30% of the instructions
- maintain maximum compatibility with existing code (don't need to modify
most drivers),
I think this is possible provided you accept to kill condition c) above,
forcing to modify many ISA drivers. This probably makes it a 2.5 task...
I might even give it a try because it would make inserting my VME driver
and devices inside the resource tree feasible, while it's currently a
mess.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
#define _IO_BASE 0
breaks CHRP and PReP boxes that use plain ISA drivers (inb() and friends).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-15 09:57:15
On Wed, 15 Mar 2000, Geert Uytterhoeven wrote:
On Tue, 14 Mar 2000, Michel Lanners wrote:
quoted
Flames, comments, cookies, ideas? Beer?
#define _IO_BASE 0
breaks CHRP and PReP boxes that use plain ISA drivers (inb() and friends).
Indeed, but that's unavoidable. Except that the breakage has to wait for
2.5 to be acceptable. Given the choice I prefer to break this and properly
use resources even for drivers which believe that they have to use fixed
addresses assigned by God, or rather the devil given the mess that the PC
`architecture' is.
Then all ISA drivers would have to ask with some function (a substitute
for request_region) for a resource and take te I/O address from the
resource.start field. This avoids useless code bloat in so many other
drivers which right now add 3 elements for most I/O accesses: _IO_BASE,
their own port base address, and a register offset.
out[wl] instructions are defined as inline assembly modifying volatile
memory and the compiler has to assume that this could modify any variable,
among them _IO_BASE, which means that it is reloaded between two succesive
outs for example and the address for the next out[wl] is recomputed from
scratch. This is one load + 2 adds at least since we force the address to
be in a register for st[hw]brx instructions. That's bloat and that's IMHO
the most important reason for which _IO_BASE should be killed.
This said if anybody knows a trick to avoid this kind of stupid code
generation from the compiler (I suspect a __builtin_byteswap will have to
be implemented sooner or later as well with compiler constraints to use
indexed addressing mode only which is needed anyway for Altivec).
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-15 11:31:50
On Wed, Mar 15, 2000, Gabriel Paubert [off-list ref] wrote:
quoted
#define _IO_BASE 0
breaks CHRP and PReP boxes that use plain ISA drivers (inb() and friends).
Indeed, but that's unavoidable. Except that the breakage has to wait for
2.5 to be acceptable. Given the choice I prefer to break this and properly
use resources even for drivers which believe that they have to use fixed
addresses assigned by God, or rather the devil given the mess that the PC
`architecture' is.
Well, we need a fix _now_ (that I will backport to 2.2.x as soon as
possible too), at least for PowerMacs. The problem of ISA drivers with
legacy hard-coded addresses is indeed a real one, but it can be
temporarily worked around by having the kernel maintaing a separate
mapping of the "old" IO base to the legacy ISA bus if one exist.
We have, I think, no legacy code using /proc/bus/pci, do we ? If I'm
right, then we can chance it to return physical addresses without
breaking anyone so at least we have a temporary fix for XFree. We must
get the kernel<->userland interface right asap so that we don't need to
change XFree again and again.
I'll play a bit with Michel patches next week-end. Unfortunately, I can't
test much on 2.3.x until the OHCI driver is fixed.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-15 20:38:39
On 15 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
quoted
#define _IO_BASE 0
breaks CHRP and PReP boxes that use plain ISA drivers (inb() and friends).
Indeed, but that's unavoidable. Except that the breakage has to wait for
2.5 to be acceptable. Given the choice I prefer to break this and properly
use resources even for drivers which believe that they have to use fixed
addresses assigned by God, or rather the devil given the mess that the PC
`architecture' is.
Well, we need a fix _now_ (that I will backport to 2.2.x as soon as
possible too), at least for PowerMacs.
Hmmm, I do vote for a solution like mine _right now_ for PMac, given
that PRep and CHRP do use real ISA. That means the above #define can't
be used, but we need to get back to a working ppc_md.something aproach.
This leaves time to implement a unified solution for 2.5, but that
solution needs to be coordinated with other platforms.
The problem of ISA drivers with
legacy hard-coded addresses is indeed a real one, but it can be
temporarily worked around by having the kernel maintaing a separate
mapping of the "old" IO base to the legacy ISA bus if one exist.
That would be difficult to implement... as all inb() and friends
include the _IO_BASE offset. Either you remove that, and you need to
map the ISA bus at kernel address 0x0, or you leave it in, but then
inb() are unusable from drivers using 'corrected' IO ports.
We have, I think, no legacy code using /proc/bus/pci, do we ? If I'm
right, then we can change it to return physical addresses without
breaking anyone so at least we have a temporary fix for XFree. We must
get the kernel<->userland interface right asap so that we don't need to
change XFree again and again.
Agreed. But, now that I think about it: what address space should the
'translated' port be in? Processor physical or kernel virtual? They are
the same for the addresses I've come across on my PMac, but they need
not be... PMac bridge init code ioremap()'s the IO region; is that the
same on other platforms/architectures?
I'll play a bit with Michel patches next week-end. Unfortunately, I can't
test much on 2.3.x until the OHCI driver is fixed.
Good luck!
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-15 21:06:59
On Wed, 15 Mar 2000, Benjamin Herrenschmidt wrote:
Well, we need a fix _now_ (that I will backport to 2.2.x as soon as
possible too), at least for PowerMacs. The problem of ISA drivers with
legacy hard-coded addresses is indeed a real one, but it can be
temporarily worked around by having the kernel maintaing a separate
mapping of the "old" IO base to the legacy ISA bus if one exist.
- Mapping address 0 does not help in catching null pointer accesses and
has the slight defect of overlapping user space :-),
- conditionally adding _IO_BASE if address is too low will bloat code
- systematically oring with _IO_BASE instead of adding it might prove
reasonable (oring with 0 has little side effects for PMacs, and on all
other boards I know it should work properly given that the alignement
of I/O space is larger than its size), although it does not solve the code
bloat issue.
But you have to consider that, AFAIK, on all architectures, the I/O space
is accessed using the start field in the resource struct. So these have to
be kernel virtual addresses, which are hard to distinguish from physical
addresses with 1:1 mappings as we have now. But that's exactly this
confusion of physical addresses with kernel virtual addresses which
prohibits increasing user space to 3Gb since on PreP I/O is mapped at 2
Gb...
MMIO is not a problem since what is in the resource field is first
translated by ioremap() so that you can put physical addresses. But for
I/O space some form of cookie is used which can be used as a parameter
for in and out instructions and is wildly varying depending on
architectures:
- on PPC, add _IO_BASE and use the result as kernel _virtual_ address.
- on SPARC64, I don't know what the address space identifiers exactly are,
but it seems to use only physical addresses. SPARC32 on the other hand
uses kernel virtual addresses but they don't have any ISA legacy it seems.
- on ALPHA, seems a mess (just spotted in core_tsunami.h):
/* ??? I wish I could get rid of this. But there's no ioremap
equivalent for I/O space. PCI I/O can be forced into the
correct hose's I/O region, but that doesn't take care of
legacy ISA crap. */
addr += TSUNAMI_IO_BIAS;
return __kernel_ldbu(*(vucp)addr);
and it's much worse with generic kernels or older machines which did not
support byte and 16 bit transfers. Ok, they acknowledge that something has
to be done for legacy I/O, perhaps functions prefixed with isa_ IIRC what
Richard Henderson said at some point.
- on ix86: fairly straightforward for obvious reasons, after all it's the
machine that we inherit the marvellously broken concept of separate spaces
from, and it's inherited from the 8008...
- on IA64, extremely baroque, using 4kB of virtual address space for every
4 bytes of I/O space and still limited to 64kB. Some things never
change...
I can't think of any simple solution right now, using physical addresses
does not seem to be an option because it forces 1:1 mappings and it's
definitely not what we want. How does cat /proc/ioports (which now
actually lists the contents of pci devices resource fields) look like on
architectures other than x86 and PPC with a recent 2.3 ?
We have, I think, no legacy code using /proc/bus/pci, do we ? If I'm
right, then we can chance it to return physical addresses without
breaking anyone so at least we have a temporary fix for XFree. We must
get the kernel<->userland interface right asap so that we don't need to
change XFree again and again.
I suspect you mean /proc/bus/pci/devices not /proc/bus/pci/xx/xx.x which
directly access configuration space and can't be fixed up.
I agree to put physical addresses for MMIO (actually I do it by fixing up
addresses in resource srtuctures when the bridge is in PreP mode), but it
requires more thought for I/O space, we want a definitive solution not one
which will break in another 6 months.
BTW: is it possible to add specific ioctls to /proc code, this might be a
solution, ugly but given the current state it might be the only solution.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/