From: David Gibson <hidden> Date: 2007-09-03 01:34:31
On Fri, Aug 31, 2007 at 07:50:06PM +0200, Gerhard Pircher wrote:
Hi,
I updated the AmigaOne device tree based on the comments in this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038069.html
All the ISA devices are now subnodes of the PCI2ISA bridge, which marks
the first 64k (of PCI address space) as I/O space. The pci node doesn't
contain any interrupt routing information, because interrupt routing
differs between the three AmigaOne models. Thus I would like to omit it,
if it is not really necessary.
Interrupt routing information is really necessary. If it differs
between the models then either you will need different device tree
source for each of them, or you will need to fill in the correct
interrupt routing information from the bootwrapper, whichever approach
is easier.
The PCI host for bus 0 is a subnode of
the pci node, but I'm not sure if this is correct.
Please take a look at the reg and ranges properties of the PCI devices.
The PCI OF spec defined "zero" reg properties (like
reg = <00xxxx00 00000000 00000000 00000000 00000000>, where xxxx is
the device number), even if all the other BARs are defined. What are
they good for?
The BARs of the VIA IDE controller are assumed to be relocateable,
even if the address is fixed in compatibility mode.
BTW: Is there a way to specify the addresses for PCI config with
indirect addressing?
I believe that's handled by the bridge's compatible and reg
properties. The platform or bridge code will have to know that this
type of bridge (as encoded in compatible) uses indirect addressing,
and which resource (from the reg property) has the indirect access
registers.
I don't know enough about PCI to answer most of the above questions,
but I spotted a bunch of problems with the device tree anyway...
/*
* AmigaOne Device Tree Source
*
* Copyright 2007 Gerhard Pircher (gerhard_pircher@gmx.net)
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "Eyetech,AmigaOne";
compatible = "Eyetech,AmigaOne" "MAI,Teron";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33.3 MHz, from U-boot
clock-frequency = <0>; // From U-boot
bus-frequency = <0>; // From U-boot
32-bit;
};
};
memory {
device_type = "memory";
reg = <0 0>; // From U-boot
};
pci@80000000 {
device_type = "pci";
bus-frequency = <01fca055>; // 33.3MHz
bus-range = <0 1>;
reg = <80000000 7f000000>; // Whole PCI space.
'reg' and 'ranges' should not typically overlap. 'reg' should only
encode control registers for the bridge, not the whole PCI space (not
that I'm even entirely sure what you mean by that).
The unit address (after the @) should be derived from the first range
listed in the 'reg' property. It's a bus address, not a slot number.
vendor-id = 0x000010cc;
Um.. evidentally you have never even tried compiling this device tree,
since this is invalid syntax. That would need to be:
vendor-id = <000010cc>;
and likewise all the others below.
// Is there a device_type defined for IDE controllers?
vendor-id = 0x00001106;
device-id = 0x00000571;
revision-id = 0x00000006;
// Class code with PCI IDE programming interface indicator.
class-code = 0x0001018f;
subsystem-id = 0;
subsystem-vendor-id = 0;
devsel-speed = 0x00000001;
min-grant = 0;
max-latency = 0;
fast-back-to-back;
// Assume base addresses are relocateable, even if
// controller operates in compatibility mode. Right?
reg = <21003910 0 00000000 0 00000000
21003914 0 00000000 0 00000000
21003918 0 00000000 0 00000000
2100391c 0 00000000 0 00000000
21003920 0 00000000 0 00000000>;
assigned-addresses = <01003910 0 000001f0 0 00000008
01003914 0 000003f4 0 00000004
01003918 0 00000170 0 00000008
0100391c 0 00000374 0 00000004
01003920 0 0000cc00 0 00000010>;
};
chosen {
linux,stdout-path = "/pci@80000000/isa@7/serial@2f8";
};
};
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-09-03 08:41:20
'reg' and 'ranges' should not typically overlap. 'reg' should only
encode control registers for the bridge, not the whole PCI space (not
that I'm even entirely sure what you mean by that).
The unit address (after the @) should be derived from the first range
listed in the 'reg' property. It's a bus address, not a slot number.
Actually... on PCI, the unit address is often the slot number, or
rather, "slot,function" with the second part ommited for non
multifunction devices.
All these devices should have unit addresses.
... which for ISA are generally in the form iPORT (8242@i60 for
example) though I've seen the "i" ommited. Not terribly important I
would say but better to follow the spec.
quoted
ide@7,1 {
This will need a compatible property, at least.
Actually, it's a PCI device, it can have a compatible property based on
the generic PCI device compatible property generation as defined in the
OF PCI binding. Since that's just derived from other fields, I suppose
it can be omitted in a flat DT. It would be -nice- to have a more
explicit cpmpatible property but in that case, not absolutely necessary
since that device will be probed as PCI anyway.
Ben.
The unit address (after the @) should be derived from the first range
listed in the 'reg' property. It's a bus address, not a slot number.
Actually... on PCI, the unit address is often the slot number, or
rather, "slot,function" with the second part ommited for non
multifunction devices.
Not slot number, but "device-id". Like, if you have actual
PCI plugin slots on your board, they likely have device ids
16,17,...; but slot numbers 1, 2, 3 (little labels on the box).
David's point is that unit addresses are not random numbers.
quoted
All these devices should have unit addresses.
... which for ISA are generally in the form iPORT (8242@i60 for
example) though I've seen the "i" ommited. Not terribly important I
would say but better to follow the spec.
Omitting the "i" is perfectly in line with the spec :-)
quoted
quoted
ide@7,1 {
This will need a compatible property, at least.
Actually, it's a PCI device, it can have a compatible property based on
the generic PCI device compatible property generation as defined in the
OF PCI binding. Since that's just derived from other fields, I suppose
it can be omitted in a flat DT. It would be -nice- to have a more
explicit cpmpatible property but in that case, not absolutely necessary
since that device will be probed as PCI anyway.
Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
compatible property though, for good measure. Anything else isn't
all that useful I think.
Segher
From: David Gibson <hidden> Date: 2007-09-03 10:12:34
On Mon, Sep 03, 2007 at 12:02:58PM +0200, Segher Boessenkool wrote:
quoted
quoted
quoted
host@0 {
The unit address (after the @) should be derived from the first range
listed in the 'reg' property. It's a bus address, not a slot number.
Actually... on PCI, the unit address is often the slot number, or
rather, "slot,function" with the second part ommited for non
multifunction devices.
Not slot number, but "device-id". Like, if you have actual
PCI plugin slots on your board, they likely have device ids
16,17,...; but slot numbers 1, 2, 3 (little labels on the box).
David's point is that unit addresses are not random numbers.
You flatter me. But i'll happily make that point, now that my
ignorance is slightly alleviated ;-).
quoted
quoted
All these devices should have unit addresses.
... which for ISA are generally in the form iPORT (8242@i60 for
example) though I've seen the "i" ommited. Not terribly important I
would say but better to follow the spec.
Omitting the "i" is perfectly in line with the spec :-)
quoted
quoted
quoted
ide@7,1 {
This will need a compatible property, at least.
Actually, it's a PCI device, it can have a compatible property based on
the generic PCI device compatible property generation as defined in the
OF PCI binding. Since that's just derived from other fields, I suppose
it can be omitted in a flat DT. It would be -nice- to have a more
explicit cpmpatible property but in that case, not absolutely necessary
since that device will be probed as PCI anyway.
Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
compatible property though, for good measure. Anything else isn't
all that useful I think.
Indeed, since PCI is probable, it's unclear whether these device nodes
are even necessary at all. Depends on whether there's anything
interesting in the omitted interrupt routing information.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Mon, Sep 03, 2007 at 12:02:58PM +0200, Segher Boessenkool wrote:
quoted
Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
compatible property though, for good measure. Anything else isn't
all that useful I think.
Wouldn't that be the same as the class-code property?
Indeed, since PCI is probable, it's unclear whether these device nodes
are even necessary at all. Depends on whether there's anything
interesting in the omitted interrupt routing information.
Well, I mainly specified the device node for the IDE controller, because
it works in compatible mode and thus the IDE driver needs to know about
the I/O ports. I guess the driver doesn't probe the BARs, if the
controller is configured for compatible mode (and AFAIK a VIA IDE
controller cannot be made work in fully native mode). Also the ppc_ide_md
function hooks are considered obsolete.
The interrupts for the IDE controller are another story. Judging from
what some developers wrote on this mailing list, there doesn't seem to
be a way to define legacy IDE interrupts (14 & 15) for a PCI device node.
Therefore I'll reuse the IDE interrupt quirk for the Pegasos.
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
compatible property though, for good measure. Anything else isn't
all that useful I think.
Wouldn't that be the same as the class-code property?
Sure, except it is a different property. If you use the "class-code"
thing, you really should implement _all_ of the PCI binding's required
properties. If you don't (since Linux doesn't use it anyway), it might
still be nice to have a "compatible" property at least (since that is
what is used for figuring out what device driver to use for this device
node). Linux doesn't currently use that either, so you don't have to,
but you could put it there and it would make sense, that's all.
quoted
Indeed, since PCI is probable, it's unclear whether these device nodes
are even necessary at all. Depends on whether there's anything
interesting in the omitted interrupt routing information.
Well, I mainly specified the device node for the IDE controller,
because
it works in compatible mode and thus the IDE driver needs to know about
the I/O ports. I guess the driver doesn't probe the BARs, if the
controller is configured for compatible mode (and AFAIK a VIA IDE
controller cannot be made work in fully native mode).
Yeah most of those are nasty.
If the driver grabs some hardcoded legacy I/O ranges if the controller
is in legacy mode, the only thing that showing those ranges in the
"reg" property helps are _other_ parts of the kernel that might care,
not that driver since it hardcodes the address; and those other parts
of the kernel shouldn't care anyway, since _they_ shouldn't use any
hardcoded ranges either!
If those addresses really show up in the PCI BARs (most controllers
don't do that in legacy mode), the kernel's own PCI probing will
see it already; if they aren't in BARs, it is a bit tricky to encode
that correctly in the "reg" (it's perfectly well-defined, just a bit
hard to get it right).
The interrupts for the IDE controller are another story. Judging from
what some developers wrote on this mailing list, there doesn't seem to
be a way to define legacy IDE interrupts (14 & 15) for a PCI device
node.
There is no such thing as "interrupt 14 and 15" on PCI. You can use
the interrupt mapping recommended practice to show two interrupts
(and their polarity, and how they are routed to the relevant interrupt
controller) in the IDE node.
Segher
From: David Gibson <hidden> Date: 2007-09-04 00:27:45
On Tue, Sep 04, 2007 at 12:52:02AM +0200, Segher Boessenkool wrote:
quoted
quoted
quoted
Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
compatible property though, for good measure. Anything else isn't
all that useful I think.
Wouldn't that be the same as the class-code property?
Sure, except it is a different property. If you use the "class-code"
thing, you really should implement _all_ of the PCI binding's required
properties. If you don't (since Linux doesn't use it anyway), it might
still be nice to have a "compatible" property at least (since that is
what is used for figuring out what device driver to use for this device
node). Linux doesn't currently use that either, so you don't have to,
but you could put it there and it would make sense, that's all.
quoted
quoted
Indeed, since PCI is probable, it's unclear whether these device nodes
are even necessary at all. Depends on whether there's anything
interesting in the omitted interrupt routing information.
Well, I mainly specified the device node for the IDE controller,
because
it works in compatible mode and thus the IDE driver needs to know about
the I/O ports. I guess the driver doesn't probe the BARs, if the
controller is configured for compatible mode (and AFAIK a VIA IDE
controller cannot be made work in fully native mode).
Hrm.. IIRC, it is permissible under Linux to only include device nodes
for those PCI devices where something must be specified which can't be
proved via PCI.
Yeah most of those are nasty.
If the driver grabs some hardcoded legacy I/O ranges if the controller
is in legacy mode, the only thing that showing those ranges in the
"reg" property helps are _other_ parts of the kernel that might care,
not that driver since it hardcodes the address; and those other parts
of the kernel shouldn't care anyway, since _they_ shouldn't use any
hardcoded ranges either!
If those addresses really show up in the PCI BARs (most controllers
don't do that in legacy mode), the kernel's own PCI probing will
see it already; if they aren't in BARs, it is a bit tricky to encode
that correctly in the "reg" (it's perfectly well-defined, just a bit
hard to get it right).
quoted
The interrupts for the IDE controller are another story. Judging from
what some developers wrote on this mailing list, there doesn't seem to
be a way to define legacy IDE interrupts (14 & 15) for a PCI device
node.
There is no such thing as "interrupt 14 and 15" on PCI. You can use
the interrupt mapping recommended practice to show two interrupts
(and their polarity, and how they are routed to the relevant interrupt
controller) in the IDE node.
What he said. More specifically, your IDE device node could specify
interrupts which are routed to the ISA i8259 (and are therefore
equivalent to the legacy interrupts) rather than to the main system
interrupt controller, or via the normal pci interrupt map.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Hrm.. IIRC, it is permissible under Linux to only include device nodes
for those PCI devices where something must be specified which can't be
proved via PCI.
It is. It isn't clear (to me, at least) which properties are
required in a PCI node that exists for e.g. interrupt reasons
only; or how the kernel decides if a PCI node is a "real" PCI
node (i.e., using the PCI binding), or an "empty" PCI node.
Segher
Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
compatible property though, for good measure. Anything else isn't
all that useful I think.
Wouldn't that be the same as the class-code property?
Sure, except it is a different property. If you use the "class-code"
thing, you really should implement _all_ of the PCI binding's required
properties. If you don't (since Linux doesn't use it anyway), it might
still be nice to have a "compatible" property at least (since that is
what is used for figuring out what device driver to use for this device
node). Linux doesn't currently use that either, so you don't have to,
but you could put it there and it would make sense, that's all.
Okay, I'll add a compatible = "pciclass,0101"; property to the node.
BTW: It looks like the Pegasos II device tree defines device_type = "spi"
for the IDE controller. Is that correct?
If those addresses really show up in the PCI BARs (most controllers
don't do that in legacy mode), the kernel's own PCI probing will
see it already; if they aren't in BARs, it is a bit tricky to encode
that correctly in the "reg" (it's perfectly well-defined, just a bit
hard to get it right).
These addresses show up in the PCI BARs of the VIA 686B IDE controller,
even if it is configured for compatible mode.
There is no such thing as "interrupt 14 and 15" on PCI. You can use
the interrupt mapping recommended practice to show two interrupts
(and their polarity, and how they are routed to the relevant interrupt
controller) in the IDE node.
But I'll still need a quirk in the IDE driver, because it doesn't make
use of any interrupt routing information in the device tree. If so, I
can omit the whole IDE controller device node and simply rely on the
IDE driver's probe functions and the Pegasos IDE IRQ quirk.
I wonder how this issue will be handled for libata and the via-pata
driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.
Thanks,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
BTW: It looks like the Pegasos II device tree defines device_type =
"spi"
for the IDE controller. Is that correct?
There is no standard binding for an "spi" device type. I have no
idea which of various "SPI" kind of devices is meant here; and none
of the ones I know of have anything to do with ATA anyway.
In short, it probably is incorrect.
Also, in general, you shouldn't use "device_type" in flat device
trees (the main exceptions are: some/most bus nodes, cpu nodes,
some other "standard" nodes).
quoted
There is no such thing as "interrupt 14 and 15" on PCI. You can use
the interrupt mapping recommended practice to show two interrupts
(and their polarity, and how they are routed to the relevant interrupt
controller) in the IDE node.
But I'll still need a quirk in the IDE driver, because it doesn't make
use of any interrupt routing information in the device tree. If so, I
can omit the whole IDE controller device node and simply rely on the
IDE driver's probe functions and the Pegasos IDE IRQ quirk.
I wonder how this issue will be handled for libata and the via-pata
driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.
I imagine the ata quirk would ask the arch or platform code about
the interrupts used; it in turn can query the device tree.
Segher
From: Gerhard Pircher <hidden> Date: 2007-09-03 14:58:17
Hi,
-------- Original-Nachricht --------
Datum: Mon, 3 Sep 2007 11:34:31 +1000
Von: David Gibson [off-list ref]
An: Gerhard Pircher [off-list ref]
CC: linuxppc-dev@ozlabs.org
Betreff: Re: [RFC] AmigaOne device tree source v2
Interrupt routing information is really necessary. If it differs
between the models then either you will need different device tree
source for each of them, or you will need to fill in the correct
interrupt routing information from the bootwrapper, whichever approach
is easier.
Okay, I could probe the southbridge's PCI interrupt registers to fill in
some of the interrupt routing information from the bootwrapper.
I believe that's handled by the bridge's compatible and reg
properties. The platform or bridge code will have to know that this
type of bridge (as encoded in compatible) uses indirect addressing,
and which resource (from the reg property) has the indirect access
registers.
Well, then I'll copy and paste from the CHRP/Pegasos PCI setup code,
which should exactly do that. :-)
I don't know enough about PCI to answer most of the above questions,
but I spotted a bunch of problems with the device tree anyway...
'reg' and 'ranges' should not typically overlap. 'reg' should only
encode control registers for the bridge, not the whole PCI space (not
that I'm even entirely sure what you mean by that).
Hmm, strange. I'm sure I found this in another device tree. I define
"whole PCI space" as PCI (prefetchable) memory and PCI I/O space.
quoted
host@0 {
The unit address (after the @) should be derived from the first range
listed in the 'reg' property. It's a bus address, not a slot number.
AFAIK it's the device number, which is 0 for this host/PCI bridge.
quoted
vendor-id = 0x000010cc;
Um.. evidentally you have never even tried compiling this device tree,
since this is invalid syntax. That would need to be:
vendor-id = <000010cc>;
and likewise all the others below.
Uh, yeah! I thought I fixed all these typos. You're right, I didn't try
to compile the device tree yet.
Okay, that would be dma-controller@0, interrupt-controller@20 and so.
Will be fixed!
quoted
ide@7,1 {
This will need a compatible property, at least.
I hoped the class-code property is enough for a PCI device, as it
clearly identifies this device as a PCI IDE conroller with primary and
secondary master functionality.
Thanks!
regards,
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
'reg' and 'ranges' should not typically overlap. 'reg' should only
encode control registers for the bridge, not the whole PCI space (not
that I'm even entirely sure what you mean by that).
Hmm, strange. I'm sure I found this in another device tree. I define
"whole PCI space" as PCI (prefetchable) memory and PCI I/O space.
PCI memory space sits on the PCI bus, not on the PCI host bridge,
so is not part of "reg" but is part of "ranges" here, since it is
direct mapped into the host's address space.
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.
The order of the "reg" entries depends on the exact model of PCI
bridge, so a device binding for it has to be written.
quoted
quoted
host@0 {
The unit address (after the @) should be derived from the first range
listed in the 'reg' property. It's a bus address, not a slot number.
AFAIK it's the device number, which is 0 for this host/PCI bridge.
The unit address is relative to the parent bus. The PCI host bridge
is not its own parent ;-)
Segher
PCI memory space sits on the PCI bus, not on the PCI host bridge,
so is not part of "reg" but is part of "ranges" here, since it is
direct mapped into the host's address space.
That's right, but what about this example here (from a Pegasos II):
/proc/device-tree/pci@80000000:
name "pci"
linux,phandle 0fc59260 (264606304)
bus-range 00000000 00000000
pci-bridge-number 00000000
reg 80000000 40000000
8259-interrupt-acknowledge f1000cb4
ranges 01000000 00000000 00000000 fe000000 00000000 00010000
02000000 00000000 80000000 80000000 00000000 40000000
clock-frequency 01fca055 (33333333)
#size-cells 00000002
#address-cells 00000003
device_type "pci"
AFAIU the reg property overlaps the ranges property for the PCI memory
space from 0x80000000 to 0xC0000000 or the CPU address space at the
same location!? Would be good to know, why it was defined like this.
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.
Yes, it is a simple linear address window. I'll remove its address range
from the reg property.
The order of the "reg" entries depends on the exact model of PCI
bridge, so a device binding for it has to be written.
Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it should
be enough to check for the board type, but a compatible property doesn't
hurt.
Thanks,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
PCI memory space sits on the PCI bus, not on the PCI host bridge,
so is not part of "reg" but is part of "ranges" here, since it is
direct mapped into the host's address space.
That's right, but what about this example here (from a Pegasos II):
/proc/device-tree/pci@80000000:
name "pci"
linux,phandle 0fc59260 (264606304)
bus-range 00000000 00000000
pci-bridge-number 00000000
reg 80000000 40000000
8259-interrupt-acknowledge f1000cb4
ranges 01000000 00000000 00000000 fe000000 00000000 00010000
02000000 00000000 80000000 80000000 00000000 40000000
clock-frequency 01fca055 (33333333)
#size-cells 00000002
#address-cells 00000003
device_type "pci"
AFAIU the reg property overlaps the ranges property for the PCI memory
space from 0x80000000 to 0xC0000000 or the CPU address space at the
same location!? Would be good to know, why it was defined like this.
That looks totally bogus. Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense (PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example). But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.
quoted
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
Yes, it is a simple linear address window. I'll remove its address range
from the reg property.
quoted
The order of the "reg" entries depends on the exact model of PCI
bridge, so a device binding for it has to be written.
Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it should
be enough to check for the board type, but a compatible property doesn't
hurt.
The whole damn point of the device tree is to avoid using this kind of
non-local information "I know what the board type is over there, so it
must be this PCI bridge over here". The node should have a compatible
property which is sufficient to select the right bridge driver.
I think this is typically badly done at the moment, simply because PCI
has historically been set up by the platform code, rather than by a
"host bridge driver" in the mould of other drivers. I don't see that
changing real soon, but that doesn't mean we shouldn't at least put
enough information in the device tree to make it possible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Gerhard Pircher <hidden> Date: 2007-09-05 11:54:22
-------- Original-Nachricht --------
Datum: Wed, 5 Sep 2007 12:48:05 +1000
Von: David Gibson [off-list ref]
An: Gerhard Pircher [off-list ref]
CC: Segher Boessenkool <redacted>, linuxppc-dev@ozlabs.org
Betreff: Re: [RFC] AmigaOne device tree source v2
That looks totally bogus. Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense (PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example). But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.
AmigaOne's PCI bridge implements PCI config with indirect addressing, but
not within the ISA I/O space. I just wanted to clear up the meaning of
this reg entry, because it looks like everyone interprets the OF spec a
little bit differently.
quoted
quoted
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be
implemented via an address/data register pair.
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
I defined the legacy I/O space together with the PCI I/O space in the
ranges property of the PCI node:
ranges = <01000000 0 00000000 fe000000 0 00c00000
The first 64k of this address space are mapped to ISA I/O in the PCI2ISA
bridge node.
The whole damn point of the device tree is to avoid using this kind of
non-local information "I know what the board type is over there, so it
must be this PCI bridge over here". The node should have a compatible
property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci node.
Are there any naming conventions (maybe lower case only)?
I think this is typically badly done at the moment, simply because PCI
has historically been set up by the platform code, rather than by a
"host bridge driver" in the mould of other drivers. I don't see that
changing real soon, but that doesn't mean we shouldn't at least put
enough information in the device tree to make it possible.
I agree (even if it means more work for me :-)
I'll post a revised version of the device tree.
Thanks!
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
The node should have a compatible
property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci
node.
Are there any naming conventions (maybe lower case only)?
It's conventional for the part behind the comma to be lower-case
only, yes. There are more stringent rules for the part before
the comma (the manufacturer part). What is "mai"?
Segher
From: Sven Luther <hidden> Date: 2007-09-06 14:40:39
On Thu, Sep 06, 2007 at 04:00:45PM +0200, Segher Boessenkool wrote:
quoted
quoted
The node should have a compatible
property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci
node.
Are there any naming conventions (maybe lower case only)?
It's conventional for the part behind the comma to be lower-case
only, yes. There are more stringent rules for the part before
the comma (the manufacturer part). What is "mai"?
mai logic (some mentor arc derivative i think, ma stands for mentor arc)
was the firm who produced the articia northbridge. The Articia S
northbridge was known to be defective, and i am unsure if mai survived
it or something.
Friendly,
Sven Luther
The node should have a compatible
property which is sufficient to select the right bridge driver.
Yeah, I defined a compatible = "mai,articias"; property in the pci
node.
Are there any naming conventions (maybe lower case only)?
It's conventional for the part behind the comma to be lower-case
only, yes. There are more stringent rules for the part before
the comma (the manufacturer part). What is "mai"?
mai logic (some mentor arc derivative i think, ma stands for mentor
arc)
was the firm who produced the articia northbridge.
It should either be "00009D2,articia-s" (using the OUI) or
"mai-logic,articia-s", then.
The Articia S
northbridge was known to be defective, and i am unsure if mai survived
it or something.
That looks totally bogus. Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense
That's not unlike me -- I may have lower tolerance for it though :-)
(PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example).
That's a good example yes.
But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.
Indeed.
quoted
quoted
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be
implemented
via an address/data register pair.
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
On an arch like x86, where "I/O addresses" exist on the system
bus as well, it would make sense, since you can translate I/O
addresses to I/O addresses that way (except on x86 even it cannot
be done either, since I/O addresses cannot be encoded on the root
bus -- at least not in existing device trees. There is no official
x86 binding yet though).
Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.
But yes, you _can_ use "ranges" for this purpose on PHBs where
legacy I/O is linearly mapped. It just doesn't make much sense.
The binding for your specific PHB should tell you what to do.
quoted
Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
should
be enough to check for the board type, but a compatible property
doesn't
hurt.
The whole damn point of the device tree is to avoid using this kind of
non-local information "I know what the board type is over there, so it
must be this PCI bridge over here". The node should have a compatible
property which is sufficient to select the right bridge driver.
Yeah. _Even if_ the kernel decides to cheat by hardcoding certain
board information, that doesn't mean the device tree shouldn't
encode that info, too.
I think this is typically badly done at the moment, simply because PCI
has historically been set up by the platform code, rather than by a
"host bridge driver" in the mould of other drivers. I don't see that
changing real soon, but that doesn't mean we shouldn't at least put
enough information in the device tree to make it possible.
From: Scott Wood <hidden> Date: 2007-09-06 14:15:16
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
quoted
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
Why does it not make sense? I'm not sure what you mean by using it as
"normal memory space", but if the PCI bridge does a straightforward
linear mapping of I/O into memory space (like most non-x86 bridges do),
it seems to make sense to me to reuse the existing ranges mechanism
rather than require each driver to have extra glue code.
And given the substantial impact of such a change on many existing device
trees and the kernel, it should probably be brought up in a thread with a
subject that will clue people in to what is being discussed, rather than
buried in "AmigaOne device tree source v2".
BTW, memory space could be non-linear as well, so should we stop using
ranges for that? For an example, see the old Alphas which lacked
byte/word I/O, and thus used a weird sparse mapping to control the size
of the access that went out over the bus.
Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.
All it currently needs to do is a), provided it's a normal linear mapping
and the I/O space is in ranges.
-Scott
From: Gerhard Pircher <hidden> Date: 2007-09-06 20:51:39
-------- Original-Nachricht --------
Datum: Thu, 6 Sep 2007 09:15:01 -0500
Von: Scott Wood [off-list ref]
An: Segher Boessenkool [off-list ref]
CC: linuxppc-dev@ozlabs.org, David Gibson <redacted>
Betreff: PCI I/O space -- reg or ranges?
quoted
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
Why does it not make sense? I'm not sure what you mean by using it as
"normal memory space", but if the PCI bridge does a straightforward
linear mapping of I/O into memory space (like most non-x86 bridges do),
it seems to make sense to me to reuse the existing ranges mechanism
rather than require each driver to have extra glue code.
Well, pci_process_bridge_OF_ranges() only looks at the ranges property to
ioremap() I/O space.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
Why does it not make sense? I'm not sure what you mean by using it as
"normal memory space", but if the PCI bridge does a straightforward
linear mapping of I/O into memory space (like most non-x86 bridges
do),
it seems to make sense to me to reuse the existing ranges mechanism
rather than require each driver to have extra glue code.
Well, pci_process_bridge_OF_ranges() only looks at the ranges property
to
ioremap() I/O space.
That's because it is the function that process the "ranges"
property, like its name shows ;-)
Segher
From: David Gibson <hidden> Date: 2007-09-07 00:20:49
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
quoted
That looks totally bogus. Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense
That's not unlike me -- I may have lower tolerance for it though :-)
I see. Can't imagine how I got another impression... :-p
: Date: Thu, 19 Jul 2007 17:51:17 +0200
: From: Segher Boessenkool [off-list ref]
: Subject: Re: [PATCH] Add 8548CDS with Arcadia 3.0 support
...
: "reg" and "ranges" overlap, that can't be right.
: Date: Tue, 7 Aug 2007 18:51:04 +0200
: From: Segher Boessenkool [off-list ref]
: Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
...
: > To be honest this looks rather to me like another case where having
: > overlapping 'reg' and 'ranges' would actually make sense.
:
: It never makes sense. You should give the "master" device
: the full "reg" range it covers, and have it define its own
...
quoted
(PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example).
That's a good example yes.
quoted
But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.
Indeed.
quoted
quoted
quoted
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be
implemented
via an address/data register pair.
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
Sure, it can be encoded like that. But does it make sense?
You cannot use legacy I/O space as normal memory space.
Well, no, but you can't use *any* MMIO space as normal memory space,
and that's handled routinely by 'ranges'.
On an arch like x86, where "I/O addresses" exist on the system
bus as well, it would make sense, since you can translate I/O
addresses to I/O addresses that way (except on x86 even it cannot
be done either, since I/O addresses cannot be encoded on the root
bus -- at least not in existing device trees. There is no official
x86 binding yet though).
What!? This is nuts, Segher. Why should the binding have to define
some bridge-specific way of encoding the legacy I/O information, when
the PCI-binding's address encoding plus 'ranges' provides a perfectly
unambiguous way of doing so. *And* it makes the normal semantics of
ranges do just the right thing for a subordinate PCI<->ISA bridge.
Also, from a driver standpoint, a PHB driver needs to find out
two main things about the bridge: a) how and where to generate
config cycles; b) how and where to generate legacy I/O cycles.
It is told "how" by the "compatible" property, and "where" by
the "reg" property, normally.
But yes, you _can_ use "ranges" for this purpose on PHBs where
legacy I/O is linearly mapped. It just doesn't make much sense.
The binding for your specific PHB should tell you what to do.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
PCI memory space sits on the PCI bus, not on the PCI host bridge,
so is not part of "reg" but is part of "ranges" here, since it is
direct mapped into the host's address space.
That's right, but what about this example here (from a Pegasos II):
/proc/device-tree/pci@80000000:
AFAIU the reg property overlaps the ranges property for the PCI memory
space from 0x80000000 to 0xC0000000 or the CPU address space at the
same location!?
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.
Yes, it is a simple linear address window. I'll remove its address
range
from the reg property.
No, please remove it from the "ranges" property, instead.
quoted
The order of the "reg" entries depends on the exact model of PCI
bridge, so a device binding for it has to be written.
Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
should
be enough to check for the board type, but a compatible property
doesn't
hurt.
Please always use "compatible" to probe any devices.
Segher
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.
Yes, it is a simple linear address window. I'll remove its address
range from the reg property.
No, please remove it from the "ranges" property, instead.
What about the PCI2ISA bridge? I map the first 64k PCI I/O address space
as ISA I/O space by using a ranges property. Would that be incorrect,
too?
Gerhard
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
From: David Gibson <hidden> Date: 2007-09-07 00:21:36
On Thu, Sep 06, 2007 at 03:36:30PM +0200, Segher Boessenkool wrote:
[snip]
quoted
quoted
PCI legacy I/O is not direct mapped: there is no legacy I/O on a
PowerPC system bus. So, it can not be mentioned in the "ranges"
property, but the PHB registers used to access it should be shown
in the "reg" property. It could be a simple linear window (it
sounds like it is here?), but it could for example also be implemented
via an address/data register pair.
Yes, it is a simple linear address window. I'll remove its address
range
from the reg property.
No, please remove it from the "ranges" property, instead.
No, don't. Removing it from reg is just fine.
quoted
quoted
The order of the "reg" entries depends on the exact model of PCI
bridge, so a device binding for it has to be written.
Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
should
be enough to check for the board type, but a compatible property
doesn't
hurt.
Please always use "compatible" to probe any devices.
Do do that, though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson