From: David Gibson <hidden> Date: 2007-05-14 04:54:04
This patch corrects a number of minor errors in the Ebony device tree:
- Missing (given as 0) cache sizes are added to the CPU node
- device_type properties are removed from nodes which don't
have a reasonably well defined device_type binding. This does require
a very small code change to locate the busses to be probed for
of_platform devices by 'compatible' instead of 'device_type'.
- A node is added for the SRAM controller
- The unit address of the small-flash node is adjusted to
correctly reflect the reg property.
- device_type values for the MAL and ZMII are updated to
reflected more up-to-date versions of the binding.
- An incorrect offset in the partition map for the large-flash
node is corrected.
- Some redundant values, already commented out are removed
entirely.
Signed-off-by: David Gibson <redacted>
---
The flash partition offset correction, at least, should go into
2.6.22. I think the rest while only borderline "bugfixes" is also
reasonable for inclusion in 2.6.22.
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
@@ -133,7 +131,6 @@clock-frequency=<0>;// Filled in by zImageEBC0:ebc{-device_type="ibm,ebc";compatible="ibm,ebc-440gp";dcr-reg=<0122>;#address-cells=<2>;
--
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, 2007-05-14 at 14:54 +1000, David Gibson wrote:
This patch corrects a number of minor errors in the Ebony device tree:
- Missing (given as 0) cache sizes are added to the CPU node
- device_type properties are removed from nodes which don't
have a reasonably well defined device_type binding. This does require
a very small code change to locate the busses to be probed for
of_platform devices by 'compatible' instead of 'device_type'.
- A node is added for the SRAM controller
- The unit address of the small-flash node is adjusted to
correctly reflect the reg property.
- device_type values for the MAL and ZMII are updated to
reflected more up-to-date versions of the binding.
- An incorrect offset in the partition map for the large-flash
node is corrected.
- Some redundant values, already commented out are removed
entirely.
Signed-off-by: David Gibson <redacted>
Is this thing _only_ addressable over DCRs? Weird.
Well... the control registers are certainly DCR only. I guess there's
the actual SRAM itself, though whether this belongs in this node, or
elsewhere isn't immediately clear. I haven't yet investigated how the
SRAM is mapped (it depends on DIP switch settings) so I'm certainly
not considering this node complete yet.
Remove "device_type", change name to "dma-controller"?
Don't really want to remove the device_type, because the MAL driver
looks for it at present. Don't really want to change the name, since
that might encourage confusion with the other (more conventional) DMA
controller.
Hmm.. yeah, I guess.
Revised patch coming shortly.
--
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
Is this thing _only_ addressable over DCRs? Weird.
Well... the control registers are certainly DCR only. I guess there's
the actual SRAM itself, though whether this belongs in this node, or
elsewhere isn't immediately clear. I haven't yet investigated how the
SRAM is mapped (it depends on DIP switch settings) so I'm certainly
not considering this node complete yet.
If it is supposed to have a "reg" property, and it doesn't
yet, it might be a good idea to comment it out in the DTS
for now, so later kernels can work with the older device
tree correctly.
Remove "device_type", change name to "dma-controller"?
Don't really want to remove the device_type, because the MAL driver
looks for it at present.
Fair enough. But you change the "device_type" in
this patch, so presumably you change it in the kernel
driver as well -- can't you just *fix* the kernel driver,
instead?
Don't really want to change the name, since
that might encourage confusion with the other (more conventional) DMA
controller.
Nah, just look at the other properties in the node and
you know what is what. It is quite common to have nodes
with the same name representing different devices (for
example, "ethernet" devices -- "dma-controller" would be
a bit more unusual, sure).
I have no strong feelings about the name, "mcmal" is
generic enough a name as far as I'm concerned.
Is this thing _only_ addressable over DCRs? Weird.
Well... the control registers are certainly DCR only. I guess there's
the actual SRAM itself, though whether this belongs in this node, or
elsewhere isn't immediately clear. I haven't yet investigated how the
SRAM is mapped (it depends on DIP switch settings) so I'm certainly
not considering this node complete yet.
If it is supposed to have a "reg" property, and it doesn't
yet, it might be a good idea to comment it out in the DTS
for now, so later kernels can work with the older device
tree correctly.
Given that I'm not aware of any Ebony firmwares that actually supply a
device tree, so in practice the kernel's tree will always come from an
attached zImage, I don't think this is really a big consideration.
Remove "device_type", change name to "dma-controller"?
Don't really want to remove the device_type, because the MAL driver
looks for it at present.
Fair enough. But you change the "device_type" in
this patch, so presumably you change it in the kernel
The kernel driver recognizes both variants, but the one I had
previously is marked deprecated.
driver as well -- can't you just *fix* the kernel driver,
instead?
Well.. I guess, but I'd prefer to leave that to BenH, who wrote the
driver.
quoted
Don't really want to change the name, since
that might encourage confusion with the other (more conventional) DMA
controller.
Nah, just look at the other properties in the node and
you know what is what. It is quite common to have nodes
with the same name representing different devices (for
example, "ethernet" devices -- "dma-controller" would be
a bit more unusual, sure).
I have no strong feelings about the name, "mcmal" is
generic enough a name as far as I'm concerned.
Um.. yes. I wonder how it was working before...
--
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: David Gibson <hidden> Date: 2007-05-16 03:47:01
On Tue, May 15, 2007 at 03:46:26PM +1000, David Gibson wrote:
On Tue, May 15, 2007 at 06:59:49AM +0200, Segher Boessenkool wrote:
[snip]
quoted
driver as well -- can't you just *fix* the kernel driver,
instead?
Well.. I guess, but I'd prefer to leave that to BenH, who wrote the
driver.
On second thoughts I will alter the driver, the new version I sent out
today has the fix to only look at 'compatible'.
quoted
quoted
Don't really want to change the name, since
that might encourage confusion with the other (more conventional) DMA
controller.
Nah, just look at the other properties in the node and
you know what is what. It is quite common to have nodes
with the same name representing different devices (for
example, "ethernet" devices -- "dma-controller" would be
a bit more unusual, sure).
I have no strong feelings about the name, "mcmal" is
generic enough a name as far as I'm concerned.
I'll leave it then.
--
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