From: Michel Lanners <hidden> Date: 2000-03-22 10:24:31
Hi Geert,
I added code to do automatic PCI resource assignment for unassigned resources
on my CHRP LongTrail. This is experimental, of course.
Cool!
Notes:
- There are machine dependent things related to PCI resource assignment,
namely PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in include/asm-ppc/pci.h. On the
LongTrail, PCI memory space is from 0xc0000000 until 0xf7000000, so I had
to change PCIBIOS_MIN_MEM to make sure allocation starts at 0xc0000000. I
think we need
#define PCIBIOS_MIN_IO ppc_md.pcibios_min_io
#define PCIBIOS_MIN_MEM ppc_md.pcibios_min_mem
and solve this in the machine specific setup code.
Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple IO
windows, out of which IO resources need to be allocated (depends on the parent
bridge, in fact). So a single static definition doesn't do the job.
Can't we replace this with a seed to the resource tree, defined per host bridge
in arch-specific code? On PowerMacs, there's a function that scans for known
host bridges; that code could (either dynamically or based on hardcoded
knowledge) put the available IO window into some resource of the host bridge
pci_dev struct. The tree of IO resources could then be built from there.
Martin, do you think it makes sense to have PCIBIOS_MAX_IO and
PCIBIOS_MAX_MEM to pass to allocate_resource() as the upper limits?
I think so; allthough if you are clever at assigning resources, there's little chance you would ever hist the limit.... The reason to have the limit is that:
a. (on PMacs at least) IO windows are defined by the host bridges which map
a certain address range to IO accesses on the subordinate bus
b. mem windows are limited by the memory map of the arch.
Thanks
Michel
______________________________
.sig at home
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Notes:
- There are machine dependent things related to PCI resource assignment,
namely PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM in include/asm-ppc/pci.h. On the
LongTrail, PCI memory space is from 0xc0000000 until 0xf7000000, so I had
to change PCIBIOS_MIN_MEM to make sure allocation starts at 0xc0000000. I
think we need
#define PCIBIOS_MIN_IO ppc_md.pcibios_min_io
#define PCIBIOS_MIN_MEM ppc_md.pcibios_min_mem
and solve this in the machine specific setup code.
Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple IO
windows, out of which IO resources need to be allocated (depends on the parent
bridge, in fact). So a single static definition doesn't do the job.
Can't we replace this with a seed to the resource tree, defined per host bridge
in arch-specific code? On PowerMacs, there's a function that scans for known
host bridges; that code could (either dynamically or based on hardcoded
knowledge) put the available IO window into some resource of the host bridge
pci_dev struct. The tree of IO resources could then be built from there.
The PCI resource allocation code allocates from the parent of the device. So I
think it must be possible to put bus-specific resource nodes in between the
general io{port,mem}_resource that covers the whole address space and the
device itself.
My PCI bus (struct pci_bus) shows up as:
PCI bus c025f5a0
node.prev = c01578b8 node.next = c01578b8
parent = 00000000
children.prev = c025f5ac children.next = c025f5ac
devices.prev = c025c008 devices.next = c025dc08
self = 00000000
resource[] = [
0: c01412f8 [ I/O 00000000-ffffffff ]
1: c0141314 [ MEM 00000000-ffffffff ]
]
ops = c014059c sysdata = 00000000 procdir = c05b2540
number = 0 primary = 0 secondary = 0 subordinate = 0
vendor/device = 0000:0000
serial = 0 pnpver = 0 productver = 0 checksum = 0
Resource c01412f8 PCI IO
range = 00000000-ffffffff
flags = 0x00000100 [ IO ]
parent = 00000000 sibling = 00000000 child = c027dac0
Resource c0141314 PCI mem
range = 00000000-ffffffff
flags = 0x00000200 [ MEM MEM_8BIT ]
parent = 00000000 sibling = 00000000 child = c025c48c
so the parents of all resources for devices are `PCI IO' and `PCI mem', the
whole address space. If the PCI bus would have resources that contain only the
effective areas for that bus, we can live with the standard
#define PCIBIOS_MIN_IO 0x1000 (10 bit XT ISA I/O space)
#define PCIBIOS_MIN_MEM 0x10000000 (why 256 MB and not 16 MB
ISA memory space??)
as on ia32.
So the resources for my PCI bus should be
I/O 00000000-00ffffff
MEM c0000000-f6ffffff
If you have two PCI busses, you want to have separate busresources for I/O,
like
I/O 00000000-00ffffff
for bus 0 and
I/O 01000000-01ffffff
for bus 1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-22 13:15:32
On Wed, Mar 22, 2000, Geert Uytterhoeven [off-list ref] wrote:
quoted
Hmmm.. bad solution. At least on a number of PowerMacs, there are multiple
IO
quoted
windows, out of which IO resources need to be allocated (depends on the
parent
quoted
bridge, in fact). So a single static definition doesn't do the job.
Can't we replace this with a seed to the resource tree, defined per host
bridge
quoted
in arch-specific code? On PowerMacs, there's a function that scans for
known
quoted
host bridges; that code could (either dynamically or based on hardcoded
knowledge) put the available IO window into some resource of the host
bridge
quoted
pci_dev struct. The tree of IO resources could then be built from there.
The PCI resource allocation code allocates from the parent of the
device. So I
think it must be possible to put bus-specific resource nodes in between the
general io{port,mem}_resource that covers the whole address space and the
device itself.
Well, ideally, we need the resource allocation/re-allocation mecanism to
rely on the parent resource node, regardless of it beeing a real PCI bus
or something else. This way, we can handle the Uni-N case by insterting
sort of per-bus nodes: (I only report IO ranges below since mem ranges
seems to be less of a problem)
Uni-N : IO 0xf0000000 - 0xf5ffffff (fake range covering all 3 sub-busses)
|
|-- Uni-N-sub1 : IO 0xf0000000 - 0xf000ffff
| |
| --- ATI AGP
|
|-- Uni-N-sub2 : IO 0xf2000000 - 0xf200ffff
| |
| --- (external PCI, can be a DEC PCI<->PCI bridge)
|
|-- Uni-N-sub3 : IO 0xf4000000 - 0xf400ffff
|
--- GMAC
|
--- Internal FireWire
Note that I don't think we need IOs at all on the GMAC/InternalFW bus.
The pmac specific PCI code would then create the 3 Uni-N-subX nodes. The
probing code needs to be hacked so that devices are put under the proper
sub nodes. Then, the reallocation/fixup code will re-assign IO ranges
based only on the device parent node exposed range.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-22 13:18:23
On Wed, Mar 22, 2000, Michel Lanners [off-list ref] wrote:
Can't we replace this with a seed to the resource tree, defined per host
bridge
in arch-specific code? On PowerMacs, there's a function that scans for known
host bridges; that code could (either dynamically or based on hardcoded
knowledge) put the available IO window into some resource of the host bridge
pci_dev struct. The tree of IO resources could then be built from there.
Note that in the Uni-N case, all 3 sub-busses have the same bus number
(0). There's apparenty no dev_fn conflicts between the devices on the
various nodes (but each sub node does _not_ have a specific range of
dev_fn, they are somewhat mixed).
For config accesses, we can still rely on my current hack which does a
reverse lookup of the PCI device in the OF device-tree, walks up the tree
to find on which Uni-N entry it is attached, and use the proper config
access registers (all not-found devices are routed to the external PCI,
just in case).
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-23 07:41:51
Hi Ben,
On 22 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
Well, ideally, we need the resource allocation/re-allocation mecanism to
rely on the parent resource node, regardless of it beeing a real PCI bus
or something else. This way, we can handle the Uni-N case by insterting
sort of per-bus nodes: (I only report IO ranges below since mem ranges
seems to be less of a problem)
Uni-N : IO 0xf0000000 - 0xf5ffffff (fake range covering all 3 sub-busses)
|
|-- Uni-N-sub1 : IO 0xf0000000 - 0xf000ffff
| |
| --- ATI AGP
|
|-- Uni-N-sub2 : IO 0xf2000000 - 0xf200ffff
| |
| --- (external PCI, can be a DEC PCI<->PCI bridge)
|
|-- Uni-N-sub3 : IO 0xf4000000 - 0xf400ffff
|
--- GMAC
|
--- Internal FireWire
How about omitting the base Uni-N, and have each of the three
sub-entities be seen as a separate host bridge, being parent to a
separate pci bus with a separate bus number?
OK, that would mean renumbering stuff (might be quite hard, if you
think about a P2P bridge in a PCI slot...), but it might make config
acesses simpler, as you can register config access functions per bus..
The pmac specific PCI code would then create the 3 Uni-N-subX nodes. The
probing code needs to be hacked so that devices are put under the proper
sub nodes. Then, the reallocation/fixup code will re-assign IO ranges
based only on the device parent node exposed range.
Would it be possible to insert those sub-nodes at all? Would those be
PCI devices in the global chain of devs, or would you just allocate
resources and insert those in the tree of resources?
Michel
PS Interesting to see Apple still sticks to the original memory map
(from 1st generation PCI Macs)...
------------------------------------------------------------------------
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: Benjamin Herrenschmidt <hidden> Date: 2000-03-23 10:13:09
On Thu, Mar 23, 2000, Michel Lanners [off-list ref] wrote:
How about omitting the base Uni-N, and have each of the three
sub-entities be seen as a separate host bridge, being parent to a
separate pci bus with a separate bus number?
OK, that would mean renumbering stuff (might be quite hard, if you
think about a P2P bridge in a PCI slot...), but it might make config
acesses simpler, as you can register config access functions per bus..
Well, that's what I originally wanted to do. But it causes a number of
problems and I felt it could be simpler to actually use the resource trick:
- Renumbering, reconfiguring PCI<->PCI bridges (and all G4s have one), etc..
- Re-sync'ing the OF tree or else, the functions for matching PCI
devices with
OF entries will break, causing some problems here or there
- What about devices that issue config access to other devices ? I don't
know if
such device actually exist, but I beleive it's theorically possible. If for
any reason they rely on a devfn/bus_number send to them by the driver, they
will break.
Well, my main problem is with PCI<->PCI bridges and re-numbering since I
don't have the PCI bridge spec (looks like it's paying). I do have the
PCI 2.1 and 2.2 specs but they don't include the PCI<->PCI bridge section.
Would it be possible to insert those sub-nodes at all? Would those be
PCI devices in the global chain of devs, or would you just allocate
resources and insert those in the tree of resources?
Well, I was thinking about only adding them to the tree of resources. If
there a problem with that ? (I'm not too familiar with the new resource
management).
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-23 19:22:26
Hi all,
On 23 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
How about omitting the base Uni-N, and have each of the three
sub-entities be seen as a separate host bridge, being parent to a
separate pci bus with a separate bus number?
Well, that's what I originally wanted to do. But it causes a number of
problems and I felt it could be simpler to actually use the resource trick:
- Renumbering, reconfiguring PCI<->PCI bridges (and all G4s have one), etc..
You can probably avoid that by leaving the 'real' PCI bus (the one with
the slots) as bus 0 with all its subordinates, and have the other two
buses renumbered after those. Unfortunately (don't know whether it
really matters) those bus numbers might change depending on what you
put into the slots...
- Re-sync'ing the OF tree or else, the functions for matching PCI
devices with
OF entries will break, causing some problems here or there
That's obviously an issue. I think we should decide once and for all
whether the OF tree is supposed to be up-to-date once the system is
running. If so, then all fixups (also changing base address) need to be
re-sync'ed into the OF tree, which is not done now... Or we just leave
the OF tree alone and work only with the PCI_dev list.
- What about devices that issue config access to other devices ? I don't
know if
such device actually exist, but I beleive it's theorically possible. If for
any reason they rely on a devfn/bus_number send to them by the driver, they
will break.
I doubt that would be done... except maybe a DMA engine modifying it's
own config. But then again, that code is supposed to be set up by the
driver, who knows the right bus number from struct pci_dev.
Well, my main problem is with PCI<->PCI bridges and re-numbering since I
don't have the PCI bridge spec (looks like it's paying). I do have the
PCI 2.1 and 2.2 specs but they don't include the PCI<->PCI bridge section.
Yes, easiest would be to leave P2P bridges alone.
quoted
Would it be possible to insert those sub-nodes at all? Would those be
PCI devices in the global chain of devs, or would you just allocate
resources and insert those in the tree of resources?
Well, I was thinking about only adding them to the tree of resources. If
there a problem with that ? (I'm not too familiar with the new resource
management).
Neither am I... it might not be the most 'clean' way, but should work
nevertheless. You'll just have three resources with no corresponding
PCI dev...
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Timothy A. Seufert <hidden> Date: 2000-03-24 08:49:02
At 8:22 PM +0100 3/23/00, Michel Lanners wrote:
That's obviously an issue. I think we should decide once and for all
whether the OF tree is supposed to be up-to-date once the system is
running. If so, then all fixups (also changing base address) need to be
re-sync'ed into the OF tree, which is not done now... Or we just leave
the OF tree alone and work only with the PCI_dev list.
It's not up to me, because I don't understand the code well enough to
contribute directly, but I'll offer these points in favor of not
updating OF:
1. Duplication of information across multiple data structures is
evil. It should be avoided at all costs.
If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK. Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs). Is
there any such reason on ppc?
2. Most arch types obviously don't have an OF tree at all.
Presumably they just do everything with the pci_dev list. Therefore,
ppc should too -- it's a bad idea to be different in an unnecessary
way.
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
That's obviously an issue. I think we should decide once and for all
whether the OF tree is supposed to be up-to-date once the system is
running. If so, then all fixups (also changing base address) need to be
re-sync'ed into the OF tree, which is not done now... Or we just leave
the OF tree alone and work only with the PCI_dev list.
It's not up to me, because I don't understand the code well enough to
contribute directly, but I'll offer these points in favor of not
updating OF:
1. Duplication of information across multiple data structures is
evil. It should be avoided at all costs.
If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK. Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs). Is
there any such reason on ppc?
Offb is one thing that comes to my mind. But this can easily be solved by
scanning for OF displays before PCI fixup and updating the values returned from
the scanning in pcibios_update_resource() if corresponding resources are
modified.
2. Most arch types obviously don't have an OF tree at all.
Presumably they just do everything with the pci_dev list. Therefore,
ppc should too -- it's a bad idea to be different in an unnecessary
way.
I favor using PCI probing for everything as well, since it means more
integration with existing drivers and less PPC-specific code.
Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.
BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-24 09:43:34
On Fri, Mar 24, 2000, Timothy A. Seufert [off-list ref] wrote:
1. Duplication of information across multiple data structures is
evil. It should be avoided at all costs.
If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK. Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs). Is
there any such reason on ppc?
The OF tree is still used by devices inside the mac-io chip. But in this
case, the PCI bus number is not used. There are a few places where we
need to find the OF entry for a PCI device in order to read some
properties left by MacOS/OF. This is done at startup to read the
interrupt tree (but this can be done before the fixup). I don't have
other specific cases in mind, but there is at least one thing for which
we need a valid OF tree: to be able to get an OF path from a device in
order to configure the OF bootloader.
This is not used currently since we still need some more kernel support
that I didn't implement yet, but this will definitely be needed if we
want a way to configure yaboot and OF automatically from Linux without
having to type the full OF path to the boot device.
2. Most arch types obviously don't have an OF tree at all.
Presumably they just do everything with the pci_dev list. Therefore,
ppc should too -- it's a bad idea to be different in an unnecessary
way.
Well, If it was only for me, I would have craped PCI probing in favor of
a device-tree only operations ;) But that's not the point. I agree that
to be consistent with other archs and to have portable drivers, we must
rely on PCI probing alone whenever possible.
There are cases where we don't have choice:
- We need some infos from the device tree to identify machine models
- The interrupt-tree is interleaved in the device tree, so we need it to
configure the PIC.
- We need the device tree to probe ASIC cells inside the various
incarnations of
Apple ASICs. This is currently the way we probe for devices like the PMU,
Cuda, AWACS, MESH, OpenPIC, etc... Those drivers also use the tree in
order to get some
infos like the presence of an ADB bus, etc...
- We retreive the eth. HW address from the tree
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-24 09:54:31
On Fri, Mar 24, 2000, Geert Uytterhoeven [off-list ref] wrote:
Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.
BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.
If this is called _after_ we have done the bus re-numbering, updating the
OF tree will be difficult since we need the old bus number to match the
PCI device with it's OF entry.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 10:56:59
quoted
Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.
BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.
If this is called _after_ we have done the bus re-numbering, updating the
OF tree will be difficult since we need the old bus number to match the
PCI device with it's OF entry.
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
case), I get:
atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
I'd like to correct the first one to only include the big endian aperture,
and the third one to use the little endian aperture (0x817ff000). Can this
be done in atyfb_init?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.
BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.
If this is called _after_ we have done the bus re-numbering, updating the
OF tree will be difficult since we need the old bus number to match the
PCI device with it's OF entry.
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
atyfb_of_init() no longer exists. Atyfb uses PCI probing only now.
Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
case), I get:
atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
I'd like to correct the first one to only include the big endian aperture,
Why? Atyfb has no troubles finding the big endian aperture on its own.
and the third one to use the little endian aperture (0x817ff000). Can this
be done in atyfb_init?
Third one? ATI Mach64 chips have 2 PCI windows only, AFAIK.
I think chunk 0 maps to PCI BAR 0 and chunk 2 maps to PCI BAR 1. Don't know
what chunk 1 and 3 are.
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/
Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.
BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.
If this is called _after_ we have done the bus re-numbering, updating the
OF tree will be difficult since we need the old bus number to match the
PCI device with it's OF entry.
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
To be a bit more constructive: what about adapting my patches and use them on
the Lombard as well? Then the conflicting secondary aperture will be assigned a
new region, while the valid regions will stay what they are.
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: Benjamin Herrenschmidt <hidden> Date: 2000-03-24 13:12:55
On Fri, Mar 24, 2000, Timothy A. Seufert [off-list ref] wrote:
If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK. Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs). Is
there any such reason on ppc?
After thinking a bit more about this, I beleive we could simply add a
property to the nodes of cards for which we change the bus number,
indicating the new linux pci dev infos. The way, we keep the "reg"
property intact (it may be useful for rebuilding OF path).
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 13:27:27
quoted
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
To be a bit more constructive: what about adapting my patches and use them on
the Lombard as well? Then the conflicting secondary aperture will be assigned a
new region, while the valid regions will stay what they are.
Fine with me. I forgot to mention that I'm currently working on the 2.2.15
atyfb source, do your patches apply to that as well? (Frankly, I tried to
follow your argument about the PCI / OF resource handling but couldn't
make out where it would fit in with the problem I try to solve.)
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
To be a bit more constructive: what about adapting my patches and use them on
the Lombard as well? Then the conflicting secondary aperture will be assigned a
new region, while the valid regions will stay what they are.
Fine with me. I forgot to mention that I'm currently working on the 2.2.15
atyfb source, do your patches apply to that as well? (Frankly, I tried to
follow your argument about the PCI / OF resource handling but couldn't
make out where it would fit in with the problem I try to solve.)
For 2.2.15, I suggest doing it in atyfb manually. But it will be quite
difficult to find a suitable free hole in PCI memory space without the resource
management subsystem.
PCI resource assignment was added in late 2.3.x, together with hot-pluggable
PCI support.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-24 13:35:49
On Fri, 24 Mar 2000, Michael Schmitz wrote:
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
case), I get:
atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
I'd like to correct the first one to only include the big endian aperture,
and the third one to use the little endian aperture (0x817ff000). Can this
be done in atyfb_init?
Don't touch the resources which correspond to assigned PCI bus addresses
because they correspond to the address ranges to which chip decoders
respond. Lying in this area makes dynamic allocation and hotplugging
impossible by giving the resource allocator the impression that some area
is free. Rather attach asubtree to the already existing device resources.
That's for example how it looks like for the VME bridge I'm using
(I hope to build a diff soon, but it's very easy to do), the third
bridge area actually consists of 8 subareas which together occupy 64 Mb
(ther other subareas I've defined are mostly cosmetic):
e0000000-f2ffffff : Tundra Semiconductor Corp. CA91C042 [Universe]
e0000000-f2ffffff : VMEbus A32 BLT D32 [e0000000-f2ffffff]
f3000000-f3ffffff : Tundra Semiconductor Corp. CA91C042 [Universe]
f3000000-f3ffffff : VMEbus CR/CSR D32 [00000000-00ffffff]
f4000000-f7ffffff : Tundra Semiconductor Corp. CA91C042 [Universe]
f4000000-f4feffff : VMEbus A24 DATA D16 [00000000-00feffff]
f4ff0000-f4ffffff : VMEbus A16 D16 [00000000-0000ffff]
f5000000-f5feffff : VMEbus A24 DATA D32 [00000000-00feffff]
f5ff0000-f5ffffff : VMEbus A16 D32 [00000000-0000ffff]
f6000000-f6feffff : VMEbus A24 DATA PRIV D16 [00000000-00feffff]
f6ff0000-f6ffffff : VMEbus A16 PRIV D16 [00000000-0000ffff]
f7000000-f7feffff : VMEbus A24 DATA PRIV D32 [00000000-00feffff]
f7ff0000-f7ffffff : VMEbus A16 PRIV D32 [00000000-0000ffff]
fc6b0000-fc6bffff : S3 Inc. 86c764/765 [Trio32/64/64V+]
fc6c0000-fc6fffff : Digital Equipment Corporation DECchip 21140 [FasterNet]
fc700000-fc701fff : Tundra Semiconductor Corp. CA91C042 [Universe]
fc700000-fc701fff : Dynamically reprogrammed VME slave image
fc7aee80-fc7aeeff : Digital Equipment Corporation DECchip 21140 [FasterNet]
fc7aef00-fc7aefff : Symbios Logic Inc. (formerly NCR) 53c825
fc7af000-fc7affff : Symbios Logic Inc. (formerly NCR) 53c825
fc7b0000-fc7bffff : Tundra Semiconductor Corp. CA91C042 [Universe]
fc7c0000-fc7fffff : Motorola Raven
fc800000-fcffffff : S3 Inc. 86c764/765 [Trio32/64/64V+]
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 13:36:59
quoted
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
atyfb_of_init() no longer exists. Atyfb uses PCI probing only now.
Define 'now' please.
quoted
Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
case), I get:
atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
I'd like to correct the first one to only include the big endian aperture,
Why? Atyfb has no troubles finding the big endian aperture on its own.
Stupid X doesn't query atyfb on this and stomps on the PCI resources.
atyfb finds the BE aperture because someone hardcoded that it's at
base + 0x800000 :-)
quoted
and the third one to use the little endian aperture (0x817ff000). Can this
be done in atyfb_init?
Third one? ATI Mach64 chips have 2 PCI windows only, AFAIK.
1 is the I/O region, 0 is vram, 2 is MMIO. 1 conflicts with some other
device (though lspci reports it as disabled anyway), 0 and 1 overlap. X
outsmarts us and disables 0 for the benefit of 2.
lspci also reports three regions, in the same order, with the same
addresses (I sent you a lspci log when hunting down the 2.3.48 atyfb bug).
I think chunk 0 maps to PCI BAR 0 and chunk 2 maps to PCI BAR 1. Don't know
what chunk 1 and 3 are.
Here's how I read them, don't know how this translates to BAR 0 or 1:
--- drivers/video/atyfb.c.org Thu Mar 23 22:32:01 2000+++ drivers/video/atyfb.c Thu Mar 23 22:28:42 2000
@@ -3191,7 +3191,7 @@u8bus,devfn;u16cmd;structfb_info_aty*info;-inti;+inti,naddr;if(device_is_compatible(dp,"ATY,264LTPro")){/* XXX kludge for now */
@@ -3219,6 +3219,13 @@return;}+printk("atyfb_of_init: got %d OF adresses for ATY:\n",dp->n_addrs);+for(i=0;i<dp->n_addrs;i++)+printk(" %08x-%08x",dp->addrs[i].address,+dp->addrs[i].address+dp->addrs[i].size-1);+if(dp->n_addrs)+printk("\n");+info=kmalloc(sizeof(structfb_info_aty),GFP_ATOMIC);if(!info){printk("atyfb_of_init: can't alloc fb_info_aty\n");
As I said, I adapted code from elsewhere in atyfb.c. I'm just getting my
feet wet WRT PCI.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
atyfb_of_init() no longer exists. Atyfb uses PCI probing only now.
Define 'now' please.
2.4.0 :-)
quoted
quoted
I'd like to correct the first one to only include the big endian aperture,
Why? Atyfb has no troubles finding the big endian aperture on its own.
Stupid X doesn't query atyfb on this and stomps on the PCI resources.
atyfb finds the BE aperture because someone hardcoded that it's at
base + 0x800000 :-)
Bug in X: the big endian frame buffer is at base + 0x800000.
Besides, why does X need this? If it uses fbdev, all it should notice is that
the reported fix.smem_start lies within the 16 MB for this PCI device, so it
should not touch that PCI directly, only through the fbdev API (ioctl+mmap).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 13:48:59
quoted
Probing the PCI config in atyfb_of_init (code stolen from the non-OFFB
case), I get:
atyfb_of_init: got 2 adresses for ATY: 81000000-81ffffff 80881000-80881fff
atyfb: chunk 0 base 0x81000000 breg 16 io 0 pbase 0x81000000 size 0x1000000
atydb: chunk 1 base 0x80881000 breg 20 io 1 pbase 0xc01 size 0x100
atydb: chunk 2 base 0x0 breg 24 io 0 pbase 0x81fff000 size 0x1000
atydb: chunk 3 base 0x4 breg 28 io 0 pbase 0x0 size 0x0
I'd like to correct the first one to only include the big endian aperture,
and the third one to use the little endian aperture (0x817ff000). Can this
be done in atyfb_init?
Don't touch the resources which correspond to assigned PCI bus addresses
because they correspond to the address ranges to which chip decoders
respond. Lying in this area makes dynamic allocation and hotplugging
impossible by giving the resource allocator the impression that some area
is free. Rather attach asubtree to the already existing device resources.
So it's perfectly legal for resources within the same device to overlap?
WTF does X not tolerate this and disables the overlapping one?
(Side note: X also reports the mem resources in reverse order, or maybe
sorted by end address, and disables the larger of the two apertures
because it saw the smaller one first, even though the smaller one is
completely embedded in the larger).
I'm not sure adding subtrees will help - I guess X might go ahead and
disable the main resources anyway. Will the subtree resources remain
accessible in that case?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-24 14:10:12
On Fri, Mar 24, 2000, Michael Schmitz
[off-list ref] wrote:
quoted
Don't touch the resources which correspond to assigned PCI bus addresses
because they correspond to the address ranges to which chip decoders
respond. Lying in this area makes dynamic allocation and hotplugging
impossible by giving the resource allocator the impression that some area
is free. Rather attach asubtree to the already existing device resources.
So it's perfectly legal for resources within the same device to overlap?
WTF does X not tolerate this and disables the overlapping one?
(Side note: X also reports the mem resources in reverse order, or maybe
sorted by end address, and disables the larger of the two apertures
because it saw the smaller one first, even though the smaller one is
completely embedded in the larger).
I'm not sure adding subtrees will help - I guess X might go ahead and
disable the main resources anyway. Will the subtree resources remain
accessible in that case?
Two things:
- It's not legal to have overlapping BARs (well, maybe it is if they are
doing hard decoding), but it's out of spec. At least, that's my
understanding of the spec. ATI does this, so we need a workaround.
- X will always try to fix any PCI conflict it finds, with or without
fbdev drivers. That's what I understands after discussing with some X
coders. To handle various OSes and all sort of legacy crap, X has to play
weird tricks with PCI and no-one in the XFree group wants to change this.
They don't want to make this remapping optional neither for support
reasons, so we have to make sure there's no conflict detected by X so it
doesn't try to mess with assignements.
However, Egbert is working on improving the X PCI interface so that we
know in the kernel what's going on the PCI bus and can keep kernel
resources in sync. I beleive we can use this not-yet-existing mecanism to
"hide" some of those stuffs to X if really necessary.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-24 15:56:14
On Fri, 24 Mar 2000, Michael Schmitz wrote:
quoted
Don't touch the resources which correspond to assigned PCI bus addresses
because they correspond to the address ranges to which chip decoders
respond. Lying in this area makes dynamic allocation and hotplugging
impossible by giving the resource allocator the impression that some area
is free. Rather attach asubtree to the already existing device resources.
So it's perfectly legal for resources within the same device to overlap?
WTF does X not tolerate this and disables the overlapping one?
It may be legal if the internal decoders are prioritized and the priority
is the right one (which it should if the firmware has set it up this way).
I don't consider it good practice though, especially when it saves only
minute amounts of address space. X should tolerate this in any case
however, it should admit that it is not always smarter than the firmware.
I'm not sure adding subtrees will help - I guess X might go ahead and
disable the main resources anyway. Will the subtree resources remain
accessible in that case?
Yes, but then I have given up on trying to understand X :-( Oh and the
case I had was somewhat different, since base registers never overlap,
only that a single base registers defined several independant areas.
What I was suggesting is that if you need it you should add a subtree to
the vram area with for example (that's completely made-up for my S3 and
I did not even look at the reference, so the offsets night be wrong):
f8000000-fbffffff: S3 Inc. 86c764/765 [Trio32/64/64V+]
f8000000-f8ffffff: Little endian VRAM aperture
f9000000-f9ffffff: Big endian VRAM aperture
and perhaps even another line with MMIO registers if applicable. Only the
first line would appear in lspci, but you could get all the info from cat
/proc/iomem.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 16:07:23
quoted
Fine with me. I forgot to mention that I'm currently working on the 2.2.15
atyfb source, do your patches apply to that as well? (Frankly, I tried to
follow your argument about the PCI / OF resource handling but couldn't
make out where it would fit in with the problem I try to solve.)
For 2.2.15, I suggest doing it in atyfb manually. But it will be quite
difficult to find a suitable free hole in PCI memory space without the resource
management subsystem.
I just want to reduce the vram and mmio apertures to the minimum sizes and
make them non overlapping.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 17:40:37
quoted
So it's perfectly legal for resources within the same device to overlap?
WTF does X not tolerate this and disables the overlapping one?
It may be legal if the internal decoders are prioritized and the priority
is the right one (which it should if the firmware has set it up this way).
They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.
I don't consider it good practice though, especially when it saves only
minute amounts of address space. X should tolerate this in any case
however, it should admit that it is not always smarter than the firmware.
Well, arguing with X is pointless. So far I've always got the short end of
the stick :-)
quoted
I'm not sure adding subtrees will help - I guess X might go ahead and
disable the main resources anyway. Will the subtree resources remain
accessible in that case?
Yes, but then I have given up on trying to understand X :-( Oh and the
I mean: if someone disables the original resource, what happens to the
new resources?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-24 17:51:15
On Fri, 24 Mar 2000, Michael Schmitz wrote:
They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.
Ok, anyway memsetting the whole aperture may not be the smartest thing to
do since the aperture may be larger than the installed VRAM.
Well, arguing with X is pointless. So far I've always got the short end of
the stick :-)
Hmmm, then find some free space and put the MMIO registers in this area.
I mean: if someone disables the original resource, what happens to the
new resources?
I don't understand the question.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-24 18:43:06
quoted
They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.
Ok, anyway memsetting the whole aperture may not be the smartest thing to
do since the aperture may be larger than the installed VRAM.
I was hoping for OF to report the right thing.
quoted
Well, arguing with X is pointless. So far I've always got the short end of
the stick :-)
Hmmm, then find some free space and put the MMIO registers in this area.
Assuming VRAM is from 0x81800000 to 0x81ffffff (the big endian aperture),
a perfect place to put MMIO would be 0x817ff000. The same registers appear
there, and that's the very place atyfb exports for MMIO mmap. It's just
the combination of silly PCI mapping in OF and X boneheadedness that gets
us here.
quoted
I mean: if someone disables the original resource, what happens to the
new resources?
I don't understand the question.
Assume the 0x81000000->0x81ffffff mapping is left untouched and I just add
a new one for 0x81800000>0x81ffffff, and another one for 0x817ff000->
0x817fffff. X goes along and disables 0x81800000->0x81ffffff, does the
0x81800000>0x81ffffff stil work? X disables 0x81fff000->0x81ffffff, does
0x817ff000->0x817fffff still work?
But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-03-24 20:03:21
On Fri, 24 Mar 2000, Michael Schmitz wrote:
quoted
quoted
They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.
Ok, anyway memsetting the whole aperture may not be the smartest thing to
do since the aperture may be larger than the installed VRAM.
I was hoping for OF to report the right thing.
Nope, if it is the assigned addresses properties. It has to be the range
of addresses potentially decoded by this device to make sure that
allocation of other devices does not cause conflicts. I remember seeing
something about allocating subareas in OF but I don't know where to find
it right now.
Assuming VRAM is from 0x81800000 to 0x81ffffff (the big endian aperture),
a perfect place to put MMIO would be 0x817ff000. The same registers appear
there, and that's the very place atyfb exports for MMIO mmap. It's just
the combination of silly PCI mapping in OF and X boneheadedness that gets
us here.
I disagree, mapping in OF or in the resource tree is not that silly. At
one point you have to describe all address ranges potentially decoded
by a device to perform correct allocation, even if they corresopnd to
alias addresses of the same VRAM for example.
Assume the 0x81000000->0x81ffffff mapping is left untouched and I just add
a new one for 0x81800000>0x81ffffff, and another one for 0x817ff000->
0x817fffff. X goes along and disables 0x81800000->0x81ffffff, does the
0x81800000>0x81ffffff stil work? X disables 0x81fff000->0x81ffffff, does
0x817ff000->0x817fffff still work?
It depends on how it disables it. By writing 0 to the BAR ?
Anyway the resource tree in 2.3 won't let you add the 0x81800000 mapping
unless you put it as a child of the 0x81000000, which it actually is AFAIU
the intent of the resource tree code.
But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.
Then X needs to be fixed, perhaps the generic X PCI code needs special
hooks for individual drivers to check whether the configuration is
acceptable or not. OTOH I don't understand why something there (OF ?)
insists in overlapping the registers with the VRAM, the PCI code in the
kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
space is completely useless.
Gabriel.
From: Michael Schmitz <hidden> Date: 2000-03-24 21:37:07
quoted
I was hoping for OF to report the right thing.
Nope, if it is the assigned addresses properties. It has to be the range
of addresses potentially decoded by this device to make sure that
allocation of other devices does not cause conflicts. I remember seeing
OK, strictly speaking the OF mapping is right, we just never need the
full address range.
quoted
Assume the 0x81000000->0x81ffffff mapping is left untouched and I just add
a new one for 0x81800000>0x81ffffff, and another one for 0x817ff000->
0x817fffff. X goes along and disables 0x81800000->0x81ffffff, does the
0x81800000>0x81ffffff stil work? X disables 0x81fff000->0x81ffffff, does
0x817ff000->0x817fffff still work?
It depends on how it disables it. By writing 0 to the BAR ?
By writing to the register at offset 4 - I'm not familiar with PCI speak
but this seems to be the same register that pcibios_write_config* writes
to in the atyfb code. 0 to disable, different bit patterns to enable mem
or io access.
Anyway the resource tree in 2.3 won't let you add the 0x81800000 mapping
unless you put it as a child of the 0x81000000, which it actually is AFAIU
the intent of the resource tree code.
I'll look at the 2.3 code some more.
quoted
But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.
Then X needs to be fixed, perhaps the generic X PCI code needs special
hooks for individual drivers to check whether the configuration is
acceptable or not. OTOH I don't understand why something there (OF ?)
insists in overlapping the registers with the VRAM, the PCI code in the
kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
space is completely useless.
It should but last time I tried it complained about resource conflicts.
I've sent BenH a log of this on request.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-24 22:13:29
On 24 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
1. Duplication of information across multiple data structures is
evil. It should be avoided at all costs.
If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK. Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs). Is
there any such reason on ppc?
The OF tree is still used by devices inside the mac-io chip. But in this
case, the PCI bus number is not used. There are a few places where we
need to find the OF entry for a PCI device in order to read some
properties left by MacOS/OF. This is done at startup to read the
interrupt tree (but this can be done before the fixup). I don't have
other specific cases in mind, but there is at least one thing for which
we need a valid OF tree: to be able to get an OF path from a device in
order to configure the OF bootloader.
How about integrating the OF tree's data into struct pci_dev's void *sysdata?
That would provide the missing link between OF tree and pci_dev list,
that otherwise forces you to keep both in sync. I'd think about
something like 'all data must taken from PCI dev, except whenn only
available in OF', so that you can safely leave bogus stuff in the OF
device tree.
quoted
2. Most arch types obviously don't have an OF tree at all.
Presumably they just do everything with the pci_dev list. Therefore,
ppc should too -- it's a bad idea to be different in an unnecessary
way.
There are cases where we don't have choice:
- We need some infos from the device tree to identify machine models
- The interrupt-tree is interleaved in the device tree, so we need it to
configure the PIC.
- We need the device tree to probe ASIC cells inside the various
incarnations of
Apple ASICs. This is currently the way we probe for devices like the PMU,
Cuda, AWACS, MESH, OpenPIC, etc... Those drivers also use the tree in
order to get some
infos like the presence of an ADB bus, etc...
- We retreive the eth. HW address from the tree
All of the above would be left intact in the OF device refenced by
dev->sysdata.
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-24 22:16:08
On 24 Mar, this message from Michael Schmitz echoed through cyberspace:
quoted
quoted
Another advantage of no longer using the information from the OF tree is that
we can just call pci_assign_unassigned_resources() and get everything
reassigned, without worrying about inconsistencies with the OF device tree.
BTW, if you do want to keep the OF device tree consistent,
pcibios_update_resource() is the place to do this.
If this is called _after_ we have done the bus re-numbering, updating the
OF tree will be difficult since we need the old bus number to match the
PCI device with it's OF entry.
On a somewhat related issue (the PCI mapping funnies for the Lombard and
possibly other Rage Pro devices): what are the penalties if I 'correct'
the PCI mapping for the Rage Pro within atyfb_of_init?
A good advice: don't do it ;-). If OF does something wrong with the ATI
device, then fix it in arch-specific PCI fixup code, so that all other
code using that device can be left untouched.
Put the special code in the special places, so that the general code
only needs to care for the general case ;-)
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-24 22:41:32
On 24 Mar, this message from Benjamin Herrenschmidt echoed through cyberspace:
On Fri, Mar 24, 2000, Timothy A. Seufert [off-list ref] wrote:
quoted
If there was a really, really good reason to keep OF up to date
(like, say, if we could break back into the OF console like you can
on Sparcs), then it would be OK. Otherwise it is most likely
unnecessary bloat, and leads to potential confusion (and bugs). Is
there any such reason on ppc?
After thinking a bit more about this, I beleive we could simply add a
property to the nodes of cards for which we change the bus number,
indicating the new linux pci dev infos. The way, we keep the "reg"
property intact (it may be useful for rebuilding OF path).
Good idea. Fits what I said before about special code ;-)
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
So it's perfectly legal for resources within the same device to overlap?
WTF does X not tolerate this and disables the overlapping one?
It may be legal if the internal decoders are prioritized and the priority
is the right one (which it should if the firmware has set it up this way).
They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.
Aha, now I know why I had to remove the last 4K. You had overlapping regions!
Which means my patch was not really necessary, since it worked around the real
problem instead of fixing it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Then X needs to be fixed, perhaps the generic X PCI code needs special
hooks for individual drivers to check whether the configuration is
acceptable or not. OTOH I don't understand why something there (OF ?)
insists in overlapping the registers with the VRAM, the PCI code in the
kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
space is completely useless.
It should but last time I tried it complained about resource conflicts.
I've sent BenH a log of this on request.
The kernel code `should' do that, but currently it doesn't. All it does is try
to allocate the PCI resources, as they are set up by the `bootloader' (OF,
MacOS, whatever). If they conflict, you just get a warning.
The code I posted for the LongTrail does assign missing/conflicting resources.
Please adapt it for PowerMac.
And for 2.2.x: sorry, but I don't care what you do there. In theory you should
do the same thing, but then you have to `invent' all code yourself, while in
2.3.x most is already there.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-03-25 14:15:03
Gabriel Paubert wrote:
quoted
But probably X will disable both 0x81000000->0x81ffffff and 0x81800000->
0x81ffffff because they overlap the 0x81fff000->0x81ffffff range. No gain.
Then X needs to be fixed, perhaps the generic X PCI code needs special
hooks for individual drivers to check whether the configuration is
acceptable or not.
Sounds a bit drastic to correct a small, isolated problem like this.
OTOH I don't understand why something there (OF ?) insists in overlapping
the registers with the VRAM, the PCI code in the kernel (2.3) should give
the registers a separate area, saving 4kB of MMIO space is completely
useless.
Right. If it is fixed more reasonably and easily in the kernel, why should it
be worked around in X?
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-25 14:36:24
quoted
They are prioritized the right way: if you memset the whole aperture to 0
the chip freaks out instead of just painting the whole screen black. Been
there, done that.
Aha, now I know why I had to remove the last 4K. You had overlapping regions!
Which means my patch was not really necessary, since it worked around the real
problem instead of fixing it.
Indeed :-) At least that's how I see it. At that time I had no idea that
the overlap would get to be a real problem ...
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-25 15:13:13
quoted
quoted
insists in overlapping the registers with the VRAM, the PCI code in the
kernel (2.3) should give the registers a separate area, saving 4kB of MMIO
space is completely useless.
It should but last time I tried it complained about resource conflicts.
I've sent BenH a log of this on request.
The kernel code `should' do that, but currently it doesn't. All it does is try
to allocate the PCI resources, as they are set up by the `bootloader' (OF,
MacOS, whatever). If they conflict, you just get a warning.
The code I posted for the LongTrail does assign missing/conflicting resources.
Please adapt it for PowerMac.
Ok, I'll start working on this. If that gets me far enough with XFree to
show it's working, fine. I'll really need 2.2 though (USB mouse support
was broken for me in 2.3).
And for 2.2.x: sorry, but I don't care what you do there. In theory you should
do the same thing, but then you have to `invent' all code yourself, while in
2.3.x most is already there.
If the resource reassignment helps I can probably hack something like that
for 2.2.x. I wasn't asking you for a PCI resource assignment backport to
2.2 :-)
I've collected a fair share of advice on this topic, so I should get some
results now.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-27 08:57:26
The code I posted for the LongTrail does assign missing/conflicting resources.
Please adapt it for PowerMac.
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
aperture, and allows XFree86 4.0 to run on my Lombard.
Michael
--- arch/ppc/kernel/pci.c.org Sun Mar 26 14:08:53 2000+++ arch/ppc/kernel/pci.c Sun Mar 26 14:09:16 2000
@@ -231,7 +231,7 @@if(!pr||request_resource(pr,r)<0){printk(KERN_ERR"PCI: Cannot allocate resource region %d of device %s\n",idx,dev->slot_name);/* We'll assign a new address later */-r->start-=r->end;+r->end-=r->start;r->start=0;}}
From: Michel D�nzer <hidden> Date: 2000-03-27 09:43:26
Michael Schmitz wrote:
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
aperture, and allows XFree86 4.0 to run on my Lombard.
Great news! So how does it compare to 3.3.x for you?
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
The code I posted for the LongTrail does assign missing/conflicting resources.
Please adapt it for PowerMac.
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
assigned to the secondary aperture? Can you please send me the output of
`lspci -vv'? Thx!
aperture, and allows XFree86 4.0 to run on my Lombard.
Guess I have to try 4.0 as well...
quoted hunk
--- arch/ppc/kernel/pci.c.org Sun Mar 26 14:08:53 2000+++ arch/ppc/kernel/pci.c Sun Mar 26 14:09:16 2000
@@ -231,7 +231,7 @@if(!pr||request_resource(pr,r)<0){printk(KERN_ERR"PCI: Cannot allocate resource region %d of device %s\n",idx,dev->slot_name);/* We'll assign a new address later */-r->start-=r->end;+r->end-=r->start;r->start=0;}}
I copied this buglet from arch/i386/kernel/pci-i386.c.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-27 09:58:25
quoted
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
aperture, and allows XFree86 4.0 to run on my Lombard.
Great news! So how does it compare to 3.3.x for you?
It feels a lot slower (15/16 bpp as fast as 32 before), 16 bpp have messed
up color (green too bright, maybe 565 is wrong after all), 32 bpp fails to
start (no screen found, weight 000 inconsistent with depth 32).
I need to figure out what the pixel format for 16 and 32 bpp really is.
Currently the X server refuses to start up if the RGB weights don't add up
to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
it's really slower than 32 bpp before. Plus the X server refuses to
cooperate with xscreensaver and consistently kicks me out after 10
minutes.
Even with not loading the more arcane extensions the X server weighs in at
21 MB (I recall 17 or so before), that might explain the slowdown a bit.
Need to work on the accelerated Mach64 driver perhaps.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-27 10:01:12
quoted
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
assigned to the secondary aperture? Can you please send me the output of
`lspci -vv'? Thx!
00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
4c49 (rev dc)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 24
Region 0: Memory at 81000000 (32-bit, non-prefetchable)
Region 1: I/O ports at <unassigned>
Region 2: Memory at 00010000 (32-bit, non-prefetchable)
Capabilities: [5c] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
quoted
aperture, and allows XFree86 4.0 to run on my Lombard.
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
assigned to the secondary aperture? Can you please send me the output of
`lspci -vv'? Thx!
00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
4c49 (rev dc)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 24
Region 0: Memory at 81000000 (32-bit, non-prefetchable)
Region 1: I/O ports at <unassigned>
Region 2: Memory at 00010000 (32-bit, non-prefetchable)
^^^^^^^^
Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
valid address for PCI memory for your box. To me, it looks like PCIBIOS_MIN_MEM
must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
sure.
quoted
quoted
aperture, and allows XFree86 4.0 to run on my Lombard.
Guess I have to try 4.0 as well...
Does this mean you didn't compile it already? :-)
Indeed. For now, I intend to go with Jack's RPMs...
I noticed after reading linux-m68k - how did that thread move there?
That's my fault: I really should make the aliases for the Linux/m68k list and
for my personal email less similar. Or perhaps I should switch to a
GUI-based mail client, where I can just click click click click on adresses :-)
Nah, that would lower my productivity.
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/
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
aperture, and allows XFree86 4.0 to run on my Lombard.
Great news! So how does it compare to 3.3.x for you?
It feels a lot slower (15/16 bpp as fast as 32 before), 16 bpp have messed
up color (green too bright, maybe 565 is wrong after all), 32 bpp fails to
start (no screen found, weight 000 inconsistent with depth 32).
16 bpp (depth 15) is 555 on the Mach64. Feel free to add support for 565 (depth
16).
I need to figure out what the pixel format for 16 and 32 bpp really is.
Currently the X server refuses to start up if the RGB weights don't add up
to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
it's really slower than 32 bpp before. Plus the X server refuses to
cooperate with xscreensaver and consistently kicks me out after 10
minutes.
32 bpp (depth 24) is 888.
Even with not loading the more arcane extensions the X server weighs in at
21 MB (I recall 17 or so before), that might explain the slowdown a bit.
Does it use shadowfb? And extra copy of the screen image would explain some of
the memory requirements.
BTW, you don't want to know about the resource consumption of Xsun on the
Ultra-10 at work.
Need to work on the accelerated Mach64 driver perhaps.
YES! ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
aperture, and allows XFree86 4.0 to run on my Lombard.
Great news! So how does it compare to 3.3.x for you?
It feels a lot slower (15/16 bpp as fast as 32 before), 16 bpp have messed
up color (green too bright, maybe 565 is wrong after all), 32 bpp fails to
start (no screen found, weight 000 inconsistent with depth 32).
I need to figure out what the pixel format for 16 and 32 bpp really is.
Currently the X server refuses to start up if the RGB weights don't add up
to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
it's really slower than 32 bpp before. Plus the X server refuses to
cooperate with xscreensaver and consistently kicks me out after 10
minutes.
Without acceleration its logical to be *alot* slower than the old server
the shadowfb helps a little there (its used by default unless you disabled
it in the config)
16bpp isn't supported by atyfb, you should use 15bpp instead (the xserver
needs to be fixed to report that 16bpp isn't supported)
32bpp should have worked fine, the (no screen found, weight 000 inconsistent
with depth 32) message probably means that you tried a startx -- -depth 32
instead of the correct -fbbpp 32
Even with not loading the more arcane extensions the X server weighs in at
21 MB (I recall 17 or so before), that might explain the slowdown a bit.
Need to work on the accelerated Mach64 driver perhaps.
My xserver weights about 74mb (it hits 100+mb with dual head) but keep in
mind that this includes the mmaped fb/mmio areas which in my case is 64mb
so the server is using about 10mb of memory which isn't too much.
The shadowfb module might be the cause of the memory increase in your case
i don't think that all the extra 4mb are from there though, but as i said
the slowdown is because you use a non accelerated server non because of
memory.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-27 11:34:50
quoted
00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
4c49 (rev dc)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 24
Region 0: Memory at 81000000 (32-bit, non-prefetchable)
Region 1: I/O ports at <unassigned>
Region 2: Memory at 00010000 (32-bit, non-prefetchable)
^^^^^^^^
Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
valid address for PCI memory for your box. To me, it looks like PCIBIOS_MIN_MEM
must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
sure.
Well, all I know is that it works.
And this is my PCIBIOS_MIN_MEM:
include/asm/pci.h:#define PCIBIOS_MIN_MEM 0x10000000
Seems it got ignored and the resource allocator picked the next free spot.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-03-27 11:41:31
Michael Schmitz wrote:
Currently the X server refuses to start up if the RGB weights don't add up
to the screen depth, and depth 32 isn't supported at all. 24 bpp works but
it's really slower than 32 bpp before.
There's now a distinction between 'depth' and 'framebuffer bpp'. There is no
depth 32.
You can set framebuffer bpp with the -fbbpp command line option (there
certainly is an XF86Config option as well, but I don't remember it). You have
to add a Display Subsection like this:
SubSection "Display"
Depth 24
fbbpp 32
Modes "1152x864" "1024x768" "640x480"
Virtual 1152 864
EndSubSection
Plus the X server refuses to cooperate with xscreensaver and consistently
kicks me out after 10 minutes.
Hm. Can you build a static server and try to track it down in gdb?
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-27 11:46:07
On 27 Mar, this message from Geert Uytterhoeven echoed through cyberspace:
On Mon, 27 Mar 2000, Michael Schmitz wrote:
quoted
quoted
quoted
Applying Geerts patch (minus the PCIBIOS_MIN_MEM patch) plus the following
one solves my PCI address conflict for the Mach64 by reallocating the MMIO
So it works without changing PCIBIOS_MIN_MEM? I'm wondering what address is
assigned to the secondary aperture? Can you please send me the output of
`lspci -vv'? Thx!
00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
4c49 (rev dc)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 24
Region 0: Memory at 81000000 (32-bit, non-prefetchable)
Region 1: I/O ports at <unassigned>
Region 2: Memory at 00010000 (32-bit, non-prefetchable)
^^^^^^^^
Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
valid address for PCI memory for your box.
IIRC, physical RAM is mapped starting at 0x0.... with host bridges
being transparent for mem accesses that would mean your memory region is
in the midst of RAM... funny, no?
To me, it looks like PCIBIOS_MIN_MEM
must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
sure.
On my machine, yes, OF starts mapping mem resources at 0x80000000; but I
can't remember reading explicitly what the memory map is on PowerMacs.
Ben?
Cheers
Michel
PS I just checked in OF's device tree; each host bridge has an assigned
range for memory resources; for bus 0, its: 0x80000000 - 0x8fffffff.
Which means we should probably implement 'corrected' mem resources per
bus like I did with IO resources.
-------------------------------------------------------------------------
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: Michael Schmitz <hidden> Date: 2000-03-27 11:46:36
Without acceleration its logical to be *alot* slower than the old server
the shadowfb helps a little there (its used by default unless you disabled
it in the config)
So the old server was accelerating already?
16bpp isn't supported by atyfb, you should use 15bpp instead (the xserver
needs to be fixed to report that 16bpp isn't supported)
I guessed as much, and Geert said 565 weight needs to be implemented
already.
32bpp should have worked fine, the (no screen found, weight 000 inconsistent
with depth 32) message probably means that you tried a startx -- -depth 32
instead of the correct -fbbpp 32
I did no such thing. I just used the DefaultDisplayDepth option in the
config file. How do I specify fbbpp in the config?
quoted
Even with not loading the more arcane extensions the X server weighs in at
21 MB (I recall 17 or so before), that might explain the slowdown a bit.
Need to work on the accelerated Mach64 driver perhaps.
My xserver weights about 74mb (it hits 100+mb with dual head) but keep in
mind that this includes the mmaped fb/mmio areas which in my case is 64mb
so the server is using about 10mb of memory which isn't too much.
With only 64 MB RAM (yes I was cheap but the Powerbook was expensive
enough already) it's a bit heavy on the system.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
16bpp isn't supported by atyfb, you should use 15bpp instead (the xserver
needs to be fixed to report that 16bpp isn't supported)
32bpp should have worked fine, the (no screen found, weight 000 inconsistent
with depth 32) message probably means that you tried a startx -- -depth 32
instead of the correct -fbbpp 32
s/bpp/depth/
There's a difference between bpp (`bit per pixel': 8, 16, 24 or 32 are
supported by atyfb) and depth (8, 15 and 24 are supported by atyfb).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device
4c49 (rev dc)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 24
Region 0: Memory at 81000000 (32-bit, non-prefetchable)
Region 1: I/O ports at <unassigned>
Region 2: Memory at 00010000 (32-bit, non-prefetchable)
^^^^^^^^
Tadaaa, that's why you need to change PCIBIOS_MIN_MEM. I don't think this is a
valid address for PCI memory for your box. To me, it looks like PCIBIOS_MIN_MEM
must be 0x80000000 for your machine, but one of the PowerMac gurus can tell for
sure.
Well, all I know is that it works.
Ever tried writing to it? :-) For your own safety, please don't! But you can
try reading the CHIP_ID register.
And this is my PCIBIOS_MIN_MEM:
include/asm/pci.h:#define PCIBIOS_MIN_MEM 0x10000000
Seems it got ignored and the resource allocator picked the next free spot.
Weird, mine got assigned to 0xc0000000, which is what I expect.
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-27 11:58:47
s/bpp/depth/
There's a difference between bpp (`bit per pixel': 8, 16, 24 or 32 are
supported by atyfb) and depth (8, 15 and 24 are supported by atyfb).
Imagine my confusion. What bpp will X use for depth 24 by default? Would
32 help any?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Without acceleration its logical to be *alot* slower than the old server
the shadowfb helps a little there (its used by default unless you disabled
it in the config)
So the old server was accelerating already?
Yes, I had ported Ryuichi Oikawa's Mach64 acceleration for Xpmac to
XF68_FBDev. It was not that much accelerated as on ia32, but the difference
with the unaccelerated server was definitely noticable. Try `option no_accel'
in XF86Config and compare. I expect unaccelerated 4.0 to be faster than
unaccelerated 3.3.x.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-27 16:55:37
quoted
Well, all I know is that it works.
Ever tried writing to it? :-) For your own safety, please don't! But you can
try reading the CHIP_ID register.
I should still have code around to do that, in the atyfb driver. Anyway,
this is what I found in arch/ppc/kernel/pci.c:
int pci_assign_resource(struct pci_dev *dev, int i)
{
struct resource *r = &dev->resource[i];
struct resource *pr = pci_find_parent_resource(dev, r);
unsigned long size = r->end + 1;
u32 new, check;
if (!pr) {
printk(KERN_ERR "PCI: Cannot find parent resource for device %s\n", dev->slot_name);
return -EINVAL;
}
if (r->flags & IORESOURCE_IO) {
if (allocate_resource(pr, r, size, 0x100, ~0, size, NULL, NULL)) {
printk(KERN_ERR "PCI: Allocation of I/O region %s/%d (%ld bytes) failed\n", de
return -EBUSY;
}
} else {
if (allocate_resource(pr, r, size, 0x10000, ~0, size, NULL, NULL)) {
printk(KERN_ERR "PCI: Allocation of memory region %s/%d (%ld bytes) failed\n",
return -EBUSY;
}
}
See the 0x10000 above? Exactly what I get.
pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
where the correct PCIBIOS_MIN_* limits are applied. That function calls
pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
dated for your patch to apply?
quoted
And this is my PCIBIOS_MIN_MEM:
include/asm/pci.h:#define PCIBIOS_MIN_MEM 0x10000000
Seems it got ignored and the resource allocator picked the next free spot.
Weird, mine got assigned to 0xc0000000, which is what I expect.
Seems pci_assign_resource is no longer in the arch/ppc/kernel section in
your source. Or your linker picks up the other one.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-27 18:58:25
On 27 Mar, this message from Michael Schmitz echoed through cyberspace:
Anyway,
this is what I found in arch/ppc/kernel/pci.c:
int pci_assign_resource(struct pci_dev *dev, int i)
{
[snip]
}
pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
where the correct PCIBIOS_MIN_* limits are applied. That function calls
pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
dated for your patch to apply?
Yeah; you might consider moving to 2.3.99.... pci_assign_resource() is
gone from arch/ppc/kernel/pci.c.
Have fun!
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-27 20:03:01
quoted
pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
where the correct PCIBIOS_MIN_* limits are applied. That function calls
pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
dated for your patch to apply?
Yeah; you might consider moving to 2.3.99.... pci_assign_resource() is
gone from arch/ppc/kernel/pci.c.
Wasn't 2.3.99 the one with broken IDE interface as someone reported here?
I can do without that sort of fun, thank you :-) I'll move back to 2.2.15
now.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-03-27 21:03:49
On 27 Mar, this message from Michael Schmitz echoed through cyberspace:
quoted
quoted
pci_assign_resource() is duplicated (sort of) in drivers/pci/setup-res.c
where the correct PCIBIOS_MIN_* limits are applied. That function calls
pcibios_update_resource() to do the actual bit twiddling. Is 2.3.48 too
dated for your patch to apply?
Yeah; you might consider moving to 2.3.99.... pci_assign_resource() is
gone from arch/ppc/kernel/pci.c.
Wasn't 2.3.99 the one with broken IDE interface as someone reported here?
I can do without that sort of fun, thank you :-) I'll move back to 2.2.15
now.
IDE is working fine in my 2.3.99... but it's a Promise, not PowerMac
integrated IDE.
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
FYI, I played some more with PCI resources on the MIPS (to be applied to my
LongTrail in the near future :-)
You can specify from which region resources are allocated by doing this
- create a `pci mem' resource with start and end corresponding to the PCI
memory space region that is provided by your host bridge
- call request_resource(&iomem_resource, &my_pci_mem_resource);
- change bus->resource[1] = &my_pci_mem_resource in your machine specific
pcibios_fixup_bus()
After this, all resources will be allocated from the `parent' PCI mem resource,
which is my_pci_mem_resource now (by default (drivers/pci/pci.c),
bus->resource[1] points to iomem_resource).
Result for the MIPS, where _all_ resources must be assigned by calling
pci_assign_unassigned_resources() afterwards:
root # cat /proc/iomem
* 00000000-03ffffff : RAM
* 04000000-043fffff : Flash ROM
* 06000000-060fffff : Nile4 ISA I/O
* 06100000-07ffffff : Nile4 PCI I/O
* 08000000-08ffffff : Nile4 ISA mem
* 09000000-0fffffff : Nile4 PCI mem
09000000-0900007f : Digital Equipment Corporation DECchip 21140 [Fa
09001000-09001fff : Acer Laboratories Inc. [ALi] M5237 USB
09040000-0907ffff : Digital Equipment Corporation DECchip 21140 [Fa
* 1fa00000-1fbfffff : Nile4 ctrl
* 1fc00000-1fffffff : Boot ROM
root #
All resources marked with `*' were manually requested before calling
pci_scan_bus(), but only `Nile4 PCI mem' matters here.
The example considers PCI memory space only. PCI I/O space is left as an
exercise for the reader :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-30 20:59:08
The example considers PCI memory space only. PCI I/O space is left as an
exercise for the reader :-)
I played a bit with PCI resource remapping in 2.2.15pre9 and I've got a
few questions, one of them dealing with PCI I/O space:
- OF reports two base addresses for the Mach64, one of which is the I/O
region (according to the PCI BAR values) at 0xc00. OF reports its address
as 0x80881000 or some such. Does this mean the I/O registers are
accessible at 0x80881000, or did OF probing get some bogus values there?
- I can successfully remap the MMIO range of the chip to some area outside
the VRAM range. XFree86 no longer barfs on the mem resource conflict
(though it still reports the I/O resource conflict with the DVD decoder),
reports the new mapping of the MMIO range, and starts up nicely. lspci -vv,
however, still reports the old range. Where's that one stored
(assuming /proc/pci somewhere), and wouldn't it make more sense to have
the PCI bus rescanned on reading /proc/pci entries?
- I picked a range to remap MMIO to more or less at random. How can I find
out what ranges are believed to be unassigned from OF data?
Too lazy to read all of the source,
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-04-03 08:58:16
On 30 Mar, this message from Michael Schmitz echoed through cyberspace:
I played a bit with PCI resource remapping in 2.2.15pre9 and I've got a
few questions, one of them dealing with PCI I/O space:
- OF reports two base addresses for the Mach64, one of which is the I/O
region (according to the PCI BAR values) at 0xc00. OF reports its address
^^^^^
Where does that address come from? I'm missing something here..
as 0x80881000 or some such. Does this mean the I/O registers are
accessible at 0x80881000, or did OF probing get some bogus values there?
When talking PCI IO space on PowerMacs, always keep in mind that the
host bridge adds an offset to PCI IO space, i.e. IO port 0xc00 on the
bus will have processor physical address 0xf2000c00 or something like
that. The offset might be reprogrammable, but I'd suggest _not_
changing it, as it is also the base address for config space accesses on
that bus...
- I can successfully remap the MMIO range of the chip to some area outside
the VRAM range. XFree86 no longer barfs on the mem resource conflict
(though it still reports the I/O resource conflict with the DVD decoder),
reports the new mapping of the MMIO range, and starts up nicely. lspci -vv,
however, still reports the old range. Where's that one stored
(assuming /proc/pci somewhere), and wouldn't it make more sense to have
the PCI bus rescanned on reading /proc/pci entries?
If you remap the MMIO range, you need to do two things:
1. change the BAR setting, so that the device will respond to the new
address
2. change the values stored in struct pci_dev, so that the kernel at
large (that includes other drivers, and the interface used by lspci)
knows about it.
- I picked a range to remap MMIO to more or less at random. How can I find
out what ranges are believed to be unassigned from OF data?
There's no other way than to look up all assigned regions. However,
don't rely (only) on what OF tells you in the devide tree, as some
assigments may have been changed by PCI fixup code, and OF may have
forgotten some assigments.
Good luck!
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-04-03 18:42:39
quoted
- OF reports two base addresses for the Mach64, one of which is the I/O
region (according to the PCI BAR values) at 0xc00. OF reports its address
^^^^^
Where does that address come from? I'm missing something here..
Straight from the BAR for region 1, with the resource type bits masked
off. BTW lspci also reports this.
quoted
as 0x80881000 or some such. Does this mean the I/O registers are
accessible at 0x80881000, or did OF probing get some bogus values there?
When talking PCI IO space on PowerMacs, always keep in mind that the
host bridge adds an offset to PCI IO space, i.e. IO port 0xc00 on the
bus will have processor physical address 0xf2000c00 or something like
that. The offset might be reprogrammable, but I'd suggest _not_
changing it, as it is also the base address for config space accesses on
that bus...
0xfe000000 is what pmac_pci.c uses for my machine (processor physical as
well as virtual). I'm not trying to change that, I just didn't understand
the address reported by OF for that region. I still don't understand it.
quoted
- I can successfully remap the MMIO range of the chip to some area outside
the VRAM range. XFree86 no longer barfs on the mem resource conflict
(though it still reports the I/O resource conflict with the DVD decoder),
reports the new mapping of the MMIO range, and starts up nicely. lspci -vv,
however, still reports the old range. Where's that one stored
(assuming /proc/pci somewhere), and wouldn't it make more sense to have
the PCI bus rescanned on reading /proc/pci entries?
If you remap the MMIO range, you need to do two things:
1. change the BAR setting, so that the device will respond to the new
address
That's been done :-)
2. change the values stored in struct pci_dev, so that the kernel at
large (that includes other drivers, and the interface used by lspci)
knows about it.
That's what I missed. I changed the value in the OF tree but forgot the
PCI side.
quoted
- I picked a range to remap MMIO to more or less at random. How can I find
out what ranges are believed to be unassigned from OF data?
There's no other way than to look up all assigned regions. However,
don't rely (only) on what OF tells you in the devide tree, as some
assigments may have been changed by PCI fixup code, and OF may have
forgotten some assigments.
As seen for the MMIO region :-) No thanks, I'l just use the address that
appears to be unused (right beyond the framebuffer). If someone wants to
generalize this hack, be careful. On a side note: I've not changed
ati_regbase after remapping the MMIO region, it still points to the old
location at the end of the LE aperture, and does apparently still work due
to the video RAM aperture remaining unchanged.
Patch appended (use at your own risk, works for me but I don't fully
understand why, etc.).
Michael
From: Michel Lanners <hidden> Date: 2000-04-04 06:01:51
Hi there,
On 3 Apr, this message from Michael Schmitz echoed through cyberspace:
quoted
quoted
- OF reports two base addresses for the Mach64, one of which is the I/O
region (according to the PCI BAR values) at 0xc00. OF reports its address
^^^^^
Where does that address come from? I'm missing something here..
Straight from the BAR for region 1, with the resource type bits masked
off. BTW lspci also reports this.
Ahhh... ok. In that case, it's a possible value.
quoted
quoted
as 0x80881000 or some such. Does this mean the I/O registers are
accessible at 0x80881000, or did OF probing get some bogus values there?
When looking at what OF assigned, always check the BAR value in OF's
properties; they are not necessarily all in the same order all the
time. Here's for example what I have on my machine for my Matrox:
[mlan@piglet /proc/device-tree/bandit/MTRX,Millennium@F]$ hexdump reg
0000000 0000 7800 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0200 7810 0000 0000 0000 0000
0000020 0000 0000 0000 4000 4200 7814 0000 0000
0000030 0000 0000 0000 0000 0080 0000
000003c
[mlan@piglet /proc/device-tree/bandit/MTRX,Millennium@F]$ hexdump assigned-addresses
0000000 c200 7814 0000 0000 8100 0000 0000 0000
0000010 0080 0000 8200 7810 0000 0000 8080 0000
0000020 0000 0000 0000 4000
0000028
The reg property has 3 entries, where the second and third represent
BARs at 0x10 and 0x14; however, assigned-addresses has these in reverse
order...
If you look at your properties, here is their meaning:
<flags> <bus-hi> <bus-lo> <processor> <size>
All elements are 32 bits; the BAR value is in the last byte of <flags>.
You'll see that in reg, <processor> is not set; that's because reg
represents the address requests of the device before attribution.
<bus-hi> and <bus-lo> form a 64-bit PCI bus address; on 32-bit systems,
<bus-hi> is zero. assigned-addresses is what OF gave your device.
0xfe000000 is what pmac_pci.c uses for my machine (processor physical as
well as virtual). I'm not trying to change that, I just didn't understand
the address reported by OF for that region. I still don't understand it.
Can you verify your OF properties, to check whether OF _really_ assigned
a region for the IO ports at 0xc00? I doubt it...
quoted
If you remap the MMIO range, you need to do two things:
2. change the values stored in struct pci_dev, so that the kernel at
large (that includes other drivers, and the interface used by lspci)
knows about it.
That's what I missed. I changed the value in the OF tree but forgot the
PCI side.
Changing the OF device tree is nice, but probably too much hassle.
The struct pci_dev, on the other hand, is vital.
Have fun!
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. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/