* ppc: 4xx: sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
From: Stefan Roese @ 2008-01-16 10:55 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
I'm seeing this error message when booting an recent arch/ppc kernel on
4xx platforms (tested on Ocotea and other 4xx platforms). Booting NFS
rootfs still works fine, but this message kind of makes me "nervous".
This is not seen on 4xx arch/powerpc platforms. Here the bootlog:
Linux version 2.6.24-rc8 (stefan@ubuntu) (gcc version 4.2.2) #1 Wed Jan 16 11:51:57 CET 2008
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.1/ppc_4xx ip=192.168.80.2:192.168.1.1::255.255.0.0:ocotea:eth0:off panic=1 console=ttyS0,115200
PID hash table entries: 1024 (order: 10, 4096 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257536k available (1660k kernel code, 540k data, 104k init, 0k highmem)
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
Call Trace:
[cfc11df0] [c00082d0] show_stack+0x44/0x1ac (unreliable)
[cfc11e30] [c0034ffc] set_fail+0x50/0x68
[cfc11e50] [c0035428] sysctl_check_table+0x414/0x70c
[cfc11ec0] [c003543c] sysctl_check_table+0x428/0x70c
[cfc11f30] [c0021fe4] register_sysctl_table+0x64/0xb4
[cfc11f50] [c0213858] register_ppc_htab_sysctl+0x18/0x2c
[cfc11f60] [c02121f4] kernel_init+0xd0/0x2b0
[cfc11ff0] [c0003b3c] kernel_thread+0x44/0x60
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
...
Any ideas?
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Benjamin Herrenschmidt @ 2008-01-16 9:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
I need to test if it works on CAB, can't change the DT on those. I'll
let you know tomorrow.
> ---
> drivers/net/ibm_newemac/rgmii.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> index 9bc1132..5757788 100644
> --- a/drivers/net/ibm_newemac/rgmii.c
> +++ b/drivers/net/ibm_newemac/rgmii.c
> @@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
> static struct of_device_id rgmii_match[] =
> {
> {
> - .type = "rgmii-interface",
> .compatible = "ibm,rgmii",
> },
> {
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: David Gibson @ 2008-01-16 9:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200474000-5630-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:00:00AM +0100, Stefan Roese wrote:
> Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
> from the 4xx dts files.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: David Gibson @ 2008-01-16 9:39 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:37:10AM +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
In fact, this patch should go in before the one changing the dts
files.
--
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
^ permalink raw reply
* [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-01-16 9:37 UTC (permalink / raw)
To: linuxppc-dev, netdev
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/rgmii.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
static struct of_device_id rgmii_match[] =
{
{
- .type = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
--
1.5.4.rc3
^ permalink raw reply related
* PPC440SPe: generating PCIe INTx
From: kannappan @ 2008-01-16 8:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
Hello All,
I would like to know how to generate PCIe INTx interrupt from Legacy
PCIe EP in PPC440SPe.
Also, please clarify,
Page 741 of the user manual (PPC440SPe_UM2014_V1_26.pdf) write
Assert_INTx message to INT_ADDR[61:63].
Page 739, table 27-9, mentions, Assert_INTA by writing to Outbound GBIF
write channel 9, A[52:59]=0x20.
Whether the INT_ADDR is any addresses BAR3 / POM3 address?
What is the Assert_INTx value to be written to INT_ADDR[61:63]? How do
I correlate with the message code values given in PCI express system
architecture?
The message codes given in PCI express system architecture is as follows
INTx Messages
Message Code
Assert_INTA
0010 0000
Assert_INTB
0010 0001
Assert_INTC
0010 0010
Assert_INTD
0010 0011
Deassert_INTA
0010 0100
Deassert_INTB
0010 0101
Deassert_INTC
0010 0110
Deassert_INTD
0010 0111
Regards,
Kans.
[-- Attachment #2: Type: text/html, Size: 12516 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
From: Stefan Roese @ 2008-01-16 9:00 UTC (permalink / raw)
To: linuxppc-dev
Remove all "i2c" and "xxmii-interface" (rgmii etc) device_type entries
from the 4xx dts files.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/bamboo.dts | 3 ---
arch/powerpc/boot/dts/ebony.dts | 2 --
arch/powerpc/boot/dts/katmai.dts | 2 --
arch/powerpc/boot/dts/kilauea.dts | 3 ---
arch/powerpc/boot/dts/makalu.dts | 3 ---
arch/powerpc/boot/dts/rainier.dts | 4 ----
arch/powerpc/boot/dts/sequoia.dts | 4 ----
arch/powerpc/boot/dts/taishan.dts | 4 ----
8 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/boot/dts/bamboo.dts b/arch/powerpc/boot/dts/bamboo.dts
index 29f1a6f..7dc37c9 100644
--- a/arch/powerpc/boot/dts/bamboo.dts
+++ b/arch/powerpc/boot/dts/bamboo.dts
@@ -185,7 +185,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -193,7 +192,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -201,7 +199,6 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
};
diff --git a/arch/powerpc/boot/dts/ebony.dts b/arch/powerpc/boot/dts/ebony.dts
index f8790c4..106ef37 100644
--- a/arch/powerpc/boot/dts/ebony.dts
+++ b/arch/powerpc/boot/dts/ebony.dts
@@ -215,7 +215,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -223,7 +222,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 9bdfc0f..bc32ac7 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -187,7 +187,6 @@
};
IIC0: i2c@10000400 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000400 14>;
interrupt-parent = <&UIC0>;
@@ -195,7 +194,6 @@
};
IIC1: i2c@10000500 {
- device_type = "i2c";
compatible = "ibm,iic-440spe", "ibm,iic-440gp", "ibm,iic";
reg = <10000500 14>;
interrupt-parent = <&UIC0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 67c7ea1..8baef61 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index bdd70e4..710c011 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -182,7 +182,6 @@
};
IIC0: i2c@ef600400 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600400 14>;
interrupt-parent = <&UIC0>;
@@ -190,7 +189,6 @@
};
IIC1: i2c@ef600500 {
- device_type = "i2c";
compatible = "ibm,iic-405ex", "ibm,iic";
reg = <ef600500 14>;
interrupt-parent = <&UIC0>;
@@ -199,7 +197,6 @@
RGMII0: emac-rgmii@ef600b00 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef600b00 104>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index d3c2ac3..f947c75 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -229,7 +229,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -237,7 +236,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440grx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -245,13 +243,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440grx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440grx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index d9046c1..276f596 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -236,7 +236,6 @@
};
IIC0: i2c@ef600700 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
@@ -244,7 +243,6 @@
};
IIC1: i2c@ef600800 {
- device_type = "i2c";
compatible = "ibm,iic-440epx", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
@@ -252,13 +250,11 @@
};
ZMII0: emac-zmii@ef600d00 {
- device_type = "zmii-interface";
compatible = "ibm,zmii-440epx", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601000 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii-440epx", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 0706a4a..8278068 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -203,7 +203,6 @@
IIC0: i2c@40000400 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000400 14>;
interrupt-parent = <&UIC0>;
@@ -211,7 +210,6 @@
};
IIC1: i2c@40000500 {
/* FIXME */
- device_type = "i2c";
compatible = "ibm,iic-440gp", "ibm,iic";
reg = <40000500 14>;
interrupt-parent = <&UIC0>;
@@ -225,13 +223,11 @@
};
ZMII0: emac-zmii@40000780 {
- device_type = "zgmii-interface";
compatible = "ibm,zmii-440gx", "ibm,zmii";
reg = <40000780 c>;
};
RGMII0: emac-rgmii@40000790 {
- device_type = "rgmii-interface";
compatible = "ibm,rgmii";
reg = <40000790 8>;
};
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-16 7:24 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 274 +++++++++++++++++++++++++++++++++++
1 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/haleakala.dts
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
new file mode 100644
index 0000000..5dd3d15
--- /dev/null
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -0,0 +1,274 @@
+/*
+ * Device Tree Source for AMCC Haleakala (405EXr)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,haleakala";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,405EXr";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405exr", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405exr","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405exr", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405exr";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405exr", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405exr", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <80000000 80000000 10000000
+ ef600000 ef600000 a00000
+ f0000000 f0000000 10000000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405exr", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl512n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 200000>;
+ };
+ partition@200000 {
+ label = "root";
+ reg = <200000 200000>;
+ };
+ partition@400000 {
+ label = "user";
+ reg = <400000 3b60000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ compatible = "ibm,iic-405exr", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ compatible = "ibm,rgmii-405exr", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405exr", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIE0: pciex@0a0000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <a0000000 20000000 /* Config space access */
+ ef000000 00001000>; /* Registers */
+ dcr-reg = <040 020>;
+ sdr-base = <400>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 90000000 0 08000000
+ 01000000 0 00000000 e0000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 80000000>;
+
+ /* This drives busses 0x00 to 0x3f */
+ bus-range = <00 3f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC2 0 4 /* swizzled int A */
+ 0000 0 0 2 &UIC2 1 4 /* swizzled int B */
+ 0000 0 0 3 &UIC2 2 4 /* swizzled int C */
+ 0000 0 0 4 &UIC2 3 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Benjamin Herrenschmidt @ 2008-01-16 7:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200467475-1663-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 08:11 +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> GigE platforms and not only the TAH equipped ones (440GX). This enables
> an MTU of 9000 instead 4080.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Jeff, please pick up for .25.
Ben.
> drivers/net/ibm_newemac/core.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index cb06280..b24bd2d 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> return emac_xmit_finish(dev, len);
> }
>
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> static inline int emac_xmit_split(struct emac_instance *dev, int slot,
> u32 pd, int len, int last, u16 base_ctrl)
> {
> @@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
> DBG2(dev, "stopped TX queue" NL);
> return 1;
> }
> -#else
> -# define emac_start_xmit_sg emac_start_xmit
> -#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
>
> /* Tx lock BHs */
> static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
> @@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
>
> /* Fill in the driver function table */
> ndev->open = &emac_open;
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> - if (dev->tah_dev) {
> - ndev->hard_start_xmit = &emac_start_xmit_sg;
> + if (dev->tah_dev)
> ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
> - } else
> -#endif
> - ndev->hard_start_xmit = &emac_start_xmit;
> ndev->tx_timeout = &emac_tx_timeout;
> ndev->watchdog_timeo = 5 * HZ;
> ndev->stop = &emac_close;
> @@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
> ndev->set_multicast_list = &emac_set_multicast_list;
> ndev->do_ioctl = &emac_ioctl;
> if (emac_phy_supports_gige(dev->phy_mode)) {
> + ndev->hard_start_xmit = &emac_start_xmit_sg;
> ndev->change_mtu = &emac_change_mtu;
> dev->commac.ops = &emac_commac_sg_ops;
> + } else {
> + ndev->hard_start_xmit = &emac_start_xmit;
> }
> SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
>
^ permalink raw reply
* Re: [DTC PATCH] libfdt: Add ft_get_next_node(), ft_get_next_prop(), and ft_getprop_offset().
From: David Gibson @ 2008-01-16 7:15 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080116034939.GB5016@localhost.localdomain>
On Wed, Jan 16, 2008 at 02:49:39PM +1100, David Gibson wrote:
> On Tue, Jan 15, 2008 at 10:52:30AM -0600, Scott Wood wrote:
> > On Tue, Jan 15, 2008 at 11:16:57AM +1100, David Gibson wrote:
> > > On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
[snip]
> > > > + if (depth != 0)
> > > > + return -FDT_ERR_BADSTRUCTURE;
> > >
> > > I think this should be FDT_ERR_TRUNCATED.
> >
> > I'd expect TRUNCATED when we hit totalsize without an FDT_END, not when
> > we hit FDT_END in an inappropriate context.
>
> Well, TRUNCATED is valid for either situation, and fdt_next_tag() also
> returns FDT_END if it reaches totalsize.
Thought I should elaborate on this a bit - I'm not sure that the
current handling of FDT_ERR_TRUNCATED is entirely correct. The
description says only when the FDT_END tag is missing, but the way
fdt_next_tag() works means we will also (for some functions, at least)
give this error when FDT_END appears without a suitable number of
FDT_END_NODE tags preceding it.
The rationale behind FDT_ERR_TRUNCATED - why it exists as a separate
code from FDT_ERR_BADSTRUCTURE - is that the read-only functions
should work more-or-less sanely on incomplete trees created by the
sequential-write functions (fdt_sw.c). FDT_ERR_TRUNCATED is supposed
to indicate that the function couldn't complete properly because the
tree is malformed, but that suitable calls to the fdt_sw functions
could complete the tree so that it's no longer malformed.
I'm not sure that either the comment describing TRUNCATED, or the code
entirely matches that rationale...
--
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
^ permalink raw reply
* [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:11 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index cb06280..b24bd2d 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
static inline int emac_xmit_split(struct emac_instance *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2(dev, "stopped TX queue" NL);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
/* Tx lock BHs */
static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
@@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
/* Fill in the driver function table */
ndev->open = &emac_open;
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
-#endif
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_tx_timeout;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(dev->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:10 UTC (permalink / raw)
To: linuxppc-dev, netdev
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with GigE link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_emac/ibm_emac_core.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..8d1901e 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#if defined(CONFIG_IBM_EMAC_TAH)
static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
/* BHs disabled */
static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,8 @@ static int __init emac_probe(struct ocp_device *ocpdev)
/* Fill in the driver function table */
ndev->open = &emac_open;
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2175,8 +2168,11 @@ static int __init emac_probe(struct ocp_device *ocpdev)
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(emacdata->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* [libfdt] RFC: Node iterators
From: David Gibson @ 2008-01-16 6:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
Here's my counter-attempt at node iterators for libfdt. It's based on
an internal function very similar to Scott's fdt_next_node(), but the
exported interfaces are altered to be (IMO) safer and simpler.
So far, it only handles iterating across immediate children of a node,
not traversing an entire subtree. I'm still working on extending the
internals to cover that case. No property iteration as yet, either.
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2008-01-16 15:06:49.000000000 +1100
+++ dtc/libfdt/fdt_ro.c 2008-01-16 16:27:55.000000000 +1100
@@ -65,7 +65,7 @@
static int nodename_eq(const void *fdt, int offset,
const char *s, int len)
{
- const char *p = fdt_offset_ptr(fdt, offset, len+1);
+ const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
if (! p)
/* short match */
@@ -104,50 +104,16 @@ int fdt_num_mem_rsv(const void *fdt)
return i;
}
-int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
+int fdt_subnode_offset_namelen(const void *fdt, int offset,
const char *name, int namelen)
{
- int level = 0;
- uint32_t tag;
- int offset, nextoffset;
-
CHECK_HEADER(fdt);
- tag = fdt_next_tag(fdt, parentoffset, &nextoffset);
- if (tag != FDT_BEGIN_NODE)
- return -FDT_ERR_BADOFFSET;
-
- do {
- offset = nextoffset;
- tag = fdt_next_tag(fdt, offset, &nextoffset);
-
- switch (tag) {
- case FDT_END:
- return -FDT_ERR_TRUNCATED;
-
- case FDT_BEGIN_NODE:
- level++;
- if (level != 1)
- continue;
- if (nodename_eq(fdt, offset+FDT_TAGSIZE, name, namelen))
- /* Found it! */
- return offset;
- break;
-
- case FDT_END_NODE:
- level--;
- break;
-
- case FDT_PROP:
- case FDT_NOP:
- break;
-
- default:
- return -FDT_ERR_BADSTRUCTURE;
- }
- } while (level >= 0);
+ for_each_subnode(fdt, offset)
+ if (nodename_eq(fdt, offset, name, namelen))
+ return offset;
- return -FDT_ERR_NOTFOUND;
+ return offset;
}
int fdt_subnode_offset(const void *fdt, int parentoffset,
Index: dtc/libfdt/fdt.c
===================================================================
--- dtc.orig/libfdt/fdt.c 2008-01-16 16:26:48.000000000 +1100
+++ dtc/libfdt/fdt.c 2008-01-16 17:03:09.000000000 +1100
@@ -129,6 +129,58 @@ uint32_t fdt_next_tag(const void *fdt, i
return tag;
}
+static int _fdt_next_node(const void *fdt, int offset, int *depth)
+{
+ uint32_t tag;
+ int nextoffset;
+
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADOFFSET;
+
+ do {
+ offset = nextoffset;
+ tag = fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_PROP:
+ case FDT_NOP:
+ break;
+
+ case FDT_BEGIN_NODE:
+ (*depth)++;
+ if (*depth == 1)
+ return offset;
+ break;
+
+ case FDT_END_NODE:
+ (*depth)--;
+ break;
+
+ case FDT_END:
+ return -FDT_ERR_TRUNCATED;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (*depth >= 0);
+
+ return -FDT_ERR_NOTFOUND;
+}
+
+int _fdt_first_subnode(const void *fdt, int offset)
+{
+ int depth = 0;
+
+ return _fdt_next_node(fdt, offset, &depth);
+}
+
+int _fdt_next_subnode(const void *fdt, int offset)
+{
+ int depth = 1;
+ return _fdt_next_node(fdt, offset, &depth);
+}
+
const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
{
int len = strlen(s) + 1;
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2008-01-16 16:27:09.000000000 +1100
+++ dtc/libfdt/libfdt.h 2008-01-16 17:06:31.000000000 +1100
@@ -131,6 +131,18 @@ static inline void *fdt_offset_ptr_w(voi
uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
/**********************************************************************/
+/* Traversal functions */
+/**********************************************************************/
+
+int _fdt_first_subnode(const void *fdt, int offset);
+int _fdt_next_subnode(const void *fdt, int offset);
+
+#define for_each_subnode(fdt, offset) \
+ for ((offset) = _fdt_first_subnode((fdt), (offset)); \
+ (offset) >= 0; \
+ (offset) = _fdt_next_subnode((fdt), (offset)))
+
+/**********************************************************************/
/* General functions */
/**********************************************************************/
--
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
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Vitaly Bordug @ 2008-01-16 6:16 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1200439502.3618.26.camel@neuromancer.mindspace>
On Tue, 15 Jan 2008 23:25:02 +0000
Bryan O'Donoghue wrote:
> Greetings Scott.
>
> I've tried both of the procedures you've outlined on the Adder875 with
> the patches supplied against the paulus git tree to no avail.
>
> Pass #1 :
>
> Doing it safe with cuImage.8xx
>
[...]
> => bootm 0x400000
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1032266 Bytes = 1008.1 kB
> Load Address: 00400000
> Entry Point: 00400554
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
> I haven't as yet tried to single step through the bootup process -
> but, just to say that assuming the above procedure isn't _too_ far
> wrong - the stuff posted to the list agains the tree you've
> recommended doesn't seem to work..
>
yes the sequence seems correct, so I'd check cmdline params, contents of chosen node in dts, etc to make sure stuff is being written to the proper UART with proper settings.
> If you can point out a flaw in my usage of it - that'd help alot. I
> have some code I'd love to be able to use with the Adder875+powerpc
> layer - which is why I'm interested in this patchset...
>
>
> Pass #2 :
>
> Replace step 9 with.
>
> 9. make uImage
> 10 dtc -o ../adder875-uboot.dtb -O dtb
> arch/powerpc/boot/dts/adder875-uboot.dts
>
>
> cp arch/powerpc/boot/uImage /tftpboot
> cp ../adder875-uboot.dtb /tftpboot
>
> Finally in u-boot
> => tftpboot 0x400000 uImage
> Using FEC ETHERNET device
> TFTP from server 192.168.0.101; our IP address is 192.168.0.202
> Filename 'uImage'.
> Load address: 0x400000
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
> ###
> done
> Bytes transferred = 1009496 (f6758 hex)
> => tftpboot 0x500000 adder875-uboot.dtb
> Using FEC ETHERNET device
> TFTP from server 192.168.0.101; our IP address is 192.168.0.202
> Filename 'adder875-uboot.dtb'.
> Load address: 0x500000
> Loading: #
> done
> Bytes transferred = 3147 (c4b hex)
> => bootm 0x400000 - 0x500000
> ## Booting image at 00400000 ...
> Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1009432 Bytes = 985.8 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x500000
>
>
> Aside from the u-boot modification of including
>
> #define CONFIG_OF_LIBFDT 1
>
> The rest is a pristine version of Yuli Barchoen's original U-Boot
> Adder stuff.
>
> The uImage + dtb seems to get a good bit further in that it seems to
> get stuck somewhere inside of some trampoline code in time.c
>
>
> (gdb) bt
> #0 0xc000ee30 in __div64_32 ()
> #1 0xc01d71f4 in time_init () at arch/powerpc/kernel/time.c:940
>
>
> I might have a go at some proper debugging tomorrow after work.
>
> If you have any suggestions as to what's going wrong or what I've not
> done right I'd appreciate the help.
>
following the u-boot way (which is more correct imo) you'll need to add some code that fixes up frequencies and stuff inside dtb, or you may try to hardcode those values inside dts(if you know exactly what should be there). Just adding CONFIG_*LIBFDT is not going to work.
--
Sincerely, Vitaly
^ permalink raw reply
* MPIC ISU
From: vb @ 2008-01-16 6:03 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
I am trying to write a BSP for an 8245 based device. One thing which
really gets me puzzled is the 'ISU' facility in
arch/powerpc/sysdev/mpic.c, there is also a notion of ISU-less
platforms, etc. I looked through the chip's programmer's reference,
even read the original AMD/Cypress OpenPIC specification - not a clue.
What is it, at the very least - what does ISU stand for?
I would really appreciate any hints,
thank you in advance,
/vb
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: David Gibson @ 2008-01-16 5:52 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801160604.56766.sr@denx.de>
On Wed, Jan 16, 2008 at 06:04:56AM +0100, Stefan Roese wrote:
> On Wednesday 16 January 2008, David Gibson wrote:
> > On Tue, Jan 15, 2008 at 08:09:25AM +0100, Stefan Roese wrote:
[snip]
> > > + RGMII0: emac-rgmii@ef600b00 {
> > > + device_type = "rgmii-interface";
> >
> > And especially not here.
>
> Ok.
>
> Your comments are valid for some of the other 4xx dts files too. Should I
> create a patch that removes these device-types there too?
Yes please :).
[snip]
> > Oh, for crying out loud. They put dcrs on the bridge as well as MMIO
> > registers. *facepalm*
>
> Yep. PCIe on 4xx has DCR, SDR *and* MMIO registers.
Ungh.
--
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
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 5:34 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080115200019.GA2598@gate.ebshome.net>
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > OK. But how do we detect GigE support? Seems like GigE enabled devices
> > have CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another
> > version tomorrow.
>
> Look couple of lines down where I set MTU changing hook. If you cannot
> change MTU you cannot get big frames.
Ahhh, I must have been blind. Thanks for pointing out.
I'll send new patches for ibm_emac and ibm_newemac in a short while.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH v4 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2008-01-16 5:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mundt, Jeff Garzik, linux-ide
In-Reply-To: <20080115164022.GA24590@lixom.net>
On Tue, Jan 15, 2008 at 10:40:22AM -0600, Olof Johansson wrote:
> Hi,
>
> I've applied 1/3 and 2/3 together with my electra_ide move to pasemi.git
> for-2.6.25, and will ask Paul to pull that. Kumar said he'd take 3/3.
>
> I also added the const to the match table as spotted by Stephen.
Great news, thank you!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 4xx: Add AMCC Haleakala (405EXr) dts
From: Stefan Roese @ 2008-01-16 5:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080116004642.GD4283@localhost.localdomain>
On Wednesday 16 January 2008, David Gibson wrote:
> On Tue, Jan 15, 2008 at 08:09:25AM +0100, Stefan Roese wrote:
> > The patch adds the Haleakala dts. The Haleakala is a stripped down
> > version of the Kilauea (405EX) with only one EMAC and only one PCIe
> > interface.
>
> [snip]
>
> > + IIC0: i2c@ef600400 {
> > + device_type = "i2c";
>
> No device_type here.
Ok.
> > + compatible = "ibm,iic-405exr", "ibm,iic";
> > + reg = <ef600400 14>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <2 4>;
> > + };
> > +
> > + IIC1: i2c@ef600500 {
> > + device_type = "i2c";
>
> Or here.
Ok.
> > + compatible = "ibm,iic-405exr", "ibm,iic";
> > + reg = <ef600500 14>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <7 4>;
> > + };
> > +
> > +
> > + RGMII0: emac-rgmii@ef600b00 {
> > + device_type = "rgmii-interface";
>
> And especially not here.
Ok.
Your comments are valid for some of the other 4xx dts files too. Should I
create a patch that removes these device-types there too?
> > + compatible = "ibm,rgmii-405exr", "ibm,rgmii";
> > + reg = <ef600b00 104>;
> > + has-mdio;
> > + };
>
> [snip]
>
> > + PCIE0: pciex@0a0000000 {
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + compatible = "ibm,plb-pciex-405exr", "ibm,plb-pciex";
> > + primary;
> > + port = <0>; /* port number */
> > + reg = <a0000000 20000000 /* Config space access */
> > + ef000000 00001000>; /* Registers */
> > + dcr-reg = <040 020>;
> > + sdr-base = <400>;
>
> Oh, for crying out loud. They put dcrs on the bridge as well as MMIO
> registers. *facepalm*
Yep. PCIe on 4xx has DCR, SDR *and* MMIO registers.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add of_find_matching_node() helper function
From: Stephen Rothwell @ 2008-01-16 4:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18317.19252.530009.495865@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
On Wed, 16 Jan 2008 11:09:24 +1100 Paul Mackerras <paulus@samba.org> wrote:
>
> Grant Likely writes:
>
> > Any comments/concerns on this patch?
>
> I'm about to throw it into my tree.
Fine by me.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
From: Stephen Rothwell @ 2008-01-16 4:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <478D450A.8060802@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
On Tue, 15 Jan 2008 17:43:06 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> Stephen Rothwell wrote:
> >> + nr_parts = 0;
> >> + for (pp = node->child; pp; pp = pp->sibling)
> >
> > for_each_child_of_node(node, pp)
>
> "for_each_child_of_node" is only in Paul's tree, but this has to go via mtd.
>
> Plus, I'm just moving the code; it's not new.
OK, we can change it later.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mpc82xx: Embedded Planet EP8248E support
From: Stephen Rothwell @ 2008-01-16 4:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080115233047.GB21002@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
Hi Scott,
On Tue, 15 Jan 2008 17:30:47 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/82xx/ep8248e.c
> +static __initdata const struct cpm_pin ep8248e_pins[] = {
Again, const doesn't mix with __initdata so just use __initdata.
> +static __initdata const struct of_device_id of_bus_ids[] = {
Here as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] 8xx: Analogue & Micro Adder875 board support.
From: Stephen Rothwell @ 2008-01-16 4:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080115233045.GA21002@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
Hi Scott,
On Tue, 15 Jan 2008 17:30:45 -0600 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> +static __initdata const struct cpm_pin adder875_pins[] = {
Sorry, but you can't have both const and __inittdata. The section
attributes that each use conflict. So just make it __initdata.
> +static __initdata const struct of_device_id __initdata of_bus_ids[] = {
Same here.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: reserve-release proof-of-concept
From: Paul Mackerras @ 2008-01-16 4:21 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, lkessler, strosake
In-Reply-To: <4782C2FB.7020105@austin.ibm.com>
Manish Ahuja writes:
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
The main problem I see here is that if this option is turned on, the
kernel now has only 256MB of memory from early boot until
subsys_initcalls are done -- on any machine, and whether or not there
is actually a dump. That means, for instance, that a machine running
bare-metal (such as a G5) might not be able to allocate the hash table
for the MMU. Also, any allocations made during that time won't be
able to be node-local.
So it will be necessary to read the flattened device tree early on to
see whether or not there is a dump, so that we don't reserve most of
memory in the cases where there isn't a dump.
Paul.
^ permalink raw reply
* RE: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
From: Aggrwal Poonam @ 2008-01-16 4:20 UTC (permalink / raw)
To: Andrew Morton
Cc: kumar.gala, Phillips Kim, Barkowski Michael, netdev, linux-kernel,
rubini, linuxppc-dev, Kalra Ashish, Cutler Richard
In-Reply-To: <20080114131441.878979d2.akpm@linux-foundation.org>
Thanks Morton for your comments,
I shall incorporate them and reesnd the patch.
With Regards
Poonam=20
=20
=20
-----Original Message-----
From: Andrew Morton [mailto:akpm@linux-foundation.org]=20
Sent: Tuesday, January 15, 2008 2:45 AM
To: Aggrwal Poonam
Cc: rubini@vision.unipv.it; linux-kernel@vger.kernel.org;
linuxppc-dev@ozlabs.org; netdev@vger.kernel.org;
kumar.gala@freescale.co; Barkowski Michael; Phillips Kim; Kalra Ashish;
Cutler Richard
Subject: Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx
platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <b10812@freescale.com> wrote:
> From: Poonam Aggrwal <b10812@freescale.com>
>=20
> The UCC TDM driver basically multiplexes and demultiplexes data from=20
> different channels. It can interface with for example SLIC kind of=20
> devices to receive TDM data demultiplex it and send to upper=20
> applications. At the transmit end it receives data for different=20
> channels multiplexes it and sends them on the TDM channel. It=20
> internally uses TSA( Time Slot Assigner) which does multiplexing and=20
> demultiplexing, UCC to perform SDMA between host buffers and the TSA,
CMX to connect TSA to UCC.
>=20
> This driver will run on MPC8323E-RDB platforms.
>=20
> ...
>
> +#define PREV_PHASE(x) ((x =3D=3D 0) ? MAX_PHASE : (x - 1)) #define=20
> +NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info =3D {
> + .uf_info =3D {
> + .tsa =3D 1,
> + .cdp =3D 1,
> + .cds =3D 1,
> + .ctsp =3D 1,
> + .ctss =3D 1,
> + .revd =3D 1,
> + .urfs =3D 0x128,
> + .utfs =3D 0x128,
> + .utfet =3D 0,
> + .utftt =3D 0x128,
> + .ufpt =3D 256,
> + .ttx_trx =3D
UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc =3D UCC_FAST_TX_ENCODING_NRZ,
> + .renc =3D UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc =3D UCC_FAST_16_BIT_CRC,
> + .synl =3D UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy =3D 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c) { #if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts =3D tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i =3D 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i =3D 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log) {
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp =3D log ^ 0xFF;
> + sign =3D (temp & 0x80) >> 7;
> + segment =3D (temp & 0x70) >> 4;
> + quant =3D temp & 0x0F;
> + quant <<=3D 1;
> + quant +=3D 33;
> + quant <<=3D segment;
> + if (sign)
> + val =3D 33 - quant;
> + else
> + val =3D quant - 33;
> +
> + val *=3D 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear) {
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret =3D 0;
> + if (linear >=3D 0)
> + linear =3D (linear >> 2);
> + else
> + linear =3D (0xc000 | (linear >> 2));
> +
> + absol =3D abs(linear) + 33;
> + temp =3D absol;
> + sign =3D (linear >=3D 0) ? 1 : 0;
> + for (i =3D 0; i < 16; i++) {
> + output =3D temp & 0x8000;
> + if (output)
> + break;
> + temp <<=3D 1;
> + }
> + segment =3D 11 - i;
> + quant =3D (absol >> segment) & 0x0F;
> + segment--;
> + segment <<=3D 4;
> + output =3D segment + quant;
> + if (absol > 8191)
> + output =3D 0x7F;
> + if (sign)
> + ret ^=3D 0xFF;
> + else
> + ret ^=3D 0x7F;
> + return ret;
> +}
hrm, how many copies of ulaw/alaw conversion functions do we need in the
tree before someone writes a library function for it?
> + out_be16(&rx_bd->status, bd_status);
> + out_be32(&rx_bd->buf,
> + tdm_c->dma_input_addr + i * SAMPLE_DEPTH * act_num_ts);
> +
> + bd_status =3D (u16) ((T_R | T_CM | T_W) >> 16);
> + bd_len =3D SAMPLE_DEPTH * act_num_ts;
> + out_be16(&tx_bd->length, bd_len);
> + out_be16(&tx_bd->status, bd_status);
> + out_be32(&tx_bd->buf,
> + tdm_c->dma_output_addr + i * SAMPLE_DEPTH *
act_num_ts);
> +
> + config_si(tdm_c);
> +
> + setbits32(&qe_immr->ic.qimr, (0x80000000 >> ucc));
The compiler treats 0xNNN constants as unsigned so this works OK. I'd
have put a UL on the end of the constant to be sure ;)
> +static int tdm_start(struct tdm_ctrl *tdm_c) {
> + if (request_irq(tdm_c->ut_info->uf_info.irq, tdm_isr,
> + 0, "tdm", tdm_c)) {
> + printk(KERN_ERR "%s: request_irq for tdm_isr failed\n",
> + __FUNCTION__);
> + return -ENODEV;
> + }
> +
> + ucc_fast_enable(tdm_c->uf_private, COMM_DIR_RX | COMM_DIR_TX);
> +
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + pr_info("%s 8-bit u-law compressed mode active\n",
__FUNCTION__);=20
> +#else
> + pr_info("%s 16-bit linear pcm mode active with"
> + " slots 0 & 2\n", __FUNCTION__);
> +#endif
Is this the sort of thing which should be controlled at compile-time?
I'd have thought that a runtime control would be more appropriate (a
sysfs knob or a module parameter). Or just work it out automagically?
> + dump_siram(tdm_c);
> + dump_ucc(tdm_c);
> +
> + setbits8(&(qe_immr->si1.siglmr1_h), (0x1 << tdm_c->tdm_port));
> + pr_info("%s UCC based TDM enabled\n", __FUNCTION__);
> +
> + return 0;
> +}
>
> ...
>
> +static void tdm_read(u32 driver_handle, short chn_id, short
*pcm_buffer,
> + short
len)
> +{
> + int i;
> + u32 phase_rx;
> + /* point to where to start for the current phase data processing
*/
> + u32 temp_rx;
> +
> + struct tdm_ctrl *tdm_c =3D (struct tdm_ctrl *)(driver_handle);
eek. What are we doing here, casting a 32-bit quantity to a kernel
pointer?
a) Seems to rule out ever using this driver on a 64-bit system
b) It's generally suspicious and indicates that some rethinking is
needed.
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + u8 *input_tdm_buffer =3D tdm_c->tdm_input_data;
> +
> +#else
> + u16 *input_tdm_buffer =3D
> + (u16 *)tdm_c->tdm_input_data;
> +
> +#endif
> + phase_rx =3D tdm_c->phase_rx;
> + phase_rx =3D PREV_PHASE(phase_rx);
> +
> + temp_rx =3D phase_rx * SAMPLE_DEPTH * EFF_ACTIVE_CH;
> +
> +#if defined(UCC_CACHE_SNOOPING_DISABLED)
> + flush_dcache_range((size_t) &input_tdm_buffer[temp_rx],
> + (size_t) &input_tdm_buffer[temp_rx +
> + SAMPLE_DEPTH *
ACTIVE_CH]);
> +#endif
Again, is it appropriate that this behaviour be determined at
compile-time?
This is very user- and packager- and distributor-unfriendly.
> + for (i =3D 0; i < len; i++) {
> +#if !defined(CONFIG_TDM_LINEAR_PCM)
> + pcm_buffer[i] =3D
> + ulaw2int(input_tdm_buffer[i * EFF_ACTIVE_CH +
> + temp_rx + chn_id]);
> +#else
> + pcm_buffer[i] =3D
> + input_tdm_buffer[i * EFF_ACTIVE_CH + temp_rx +
chn_id]; #endif
> +
> + }
> +
> +}
> +
> +static int ucc_tdm_probe(struct of_device *ofdev,
> + const struct of_device_id *match) {
> + struct device_node *np =3D ofdev->node;
> + struct resource res;
> + const unsigned int *prop;
> + u32 ucc_num, device_num, err, ret =3D 0;
> + struct device_node *np_tmp =3D NULL;
> + dma_addr_t physaddr;
> + void *tdm_buff;
> + struct ucc_tdm_info *ut_info;
> +
> + prop =3D of_get_property(np, "device-id", NULL);
> + ucc_num =3D *prop - 1;
> + if ((ucc_num < 0) || (ucc_num > 7))
> + return -ENODEV;
> +
> + ut_info =3D &utdm_info[ucc_num];
> + if (ut_info =3D=3D NULL) {
> + printk(KERN_ERR "additional data missing\n");
> + return -ENODEV;
> + }
> + if (ut_info->ucc_busy) {
> + printk(KERN_ERR "UCC in use by another TDM driver
instance\n");
> + return -EBUSY;
> + }
> +
> + ut_info->ucc_busy =3D 1;
> + tdm_ctrl[num_tdm_devices++] =3D
> + kzalloc(sizeof(struct tdm_ctrl), GFP_KERNEL);
Shouldn't this check for (num_tdm_devices > MAX_NUM_TDM_DEVICES))?
> + if (!tdm_ctrl[num_tdm_devices - 1]) {
> + printk(KERN_ERR "%s: no memory to allocate for"
> + " tdm control structure\n", __FUNCTION__);
> + num_tdm_devices--;
> + return -ENOMEM;
> + }
> + device_num =3D num_tdm_devices - 1;
> +
> + tdm_ctrl[device_num]->device =3D &ofdev->dev;
> + tdm_ctrl[device_num]->ut_info =3D ut_info;
> +
> + tdm_ctrl[device_num]->ut_info->uf_info.ucc_num =3D ucc_num;
> +
> + prop =3D of_get_property(np, "fsl,tdm-num", NULL);
> + if (prop =3D=3D NULL) {
> + ret =3D -EINVAL;
> + goto get_property_error;
> + }
>
> ...
>
> +
> +#define SET_RX_SI_RAM(n, val) \
> + out_be16((u16 *)&qe_immr->sir.rx[(n)*2], (u16)(val))
> +
> +#define SET_TX_SI_RAM(n, val) \
> + out_be16((u16 *)&qe_immr->sir.tx[(n)*2], (u16)(val))
I don't think there's anything which requires that these be imlemented
in the preprocessor?
> +struct tdm_cfg {
> + u8 com_pin; /* Common receive and transmit pins
> + * 0 =3D separate pins
> + * 1 =3D common pins
> + */
> +
> + u8 fr_sync_level; /* SLx bit Frame Sync Polarity
> + * 0 =3D L1R/TSYNC active logic "1"
> + * 1 =3D L1R/TSYNC active logic "0"
> + */
> +
> + u8 clk_edge; /* CEx bit Tx Rx Clock Edge
> + * 0 =3D TX data on rising edge of clock
> + * RX data on falling edge
> + * 1 =3D TX data on falling edge of clock
> + * RX data on rising edge
> + */
> +
> + u8 fr_sync_edge; /* FEx bit Frame sync edge
> + * Determine when the sync pulses are
sampled
> + * 0 =3D Falling edge
> + * 1 =3D Rising edge
> + */
> +
> + u8 rx_fr_sync_delay; /* TFSDx/RFSDx bits Frame Sync Delay
> + * 00 =3D no bit delay
> + * 01 =3D 1 bit delay
> + * 10 =3D 2 bit delay
> + * 11 =3D 3 bit delay
> + */
> +
> + u8 tx_fr_sync_delay; /* TFSDx/RFSDx bits Frame Sync Delay
> + * 00 =3D no bit delay
> + * 01 =3D 1 bit delay
> + * 10 =3D 2 bit delay
> + * 11 =3D 3 bit delay
> + */
> +
> + u8 active_num_ts; /* Number of active time slots in TDM
> + * assume same active Rx/Tx time slots
> + */
> +};
Nice commenting.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox