* dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
From: Junita Ajith @ 2009-12-09 17:57 UTC (permalink / raw)
To: Lee, Eric; +Cc: Linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 14046 bytes --]
Hi Eric,
I am building the linux kernel V-2.6.27 based on MPC8349miTXGP dts file.
I am still not able to boot the cuImage.
But, I see serial outuput from kernel when I try to boot with <kernel>
<ramdisk> <dtb file>
Still the kernel hangs after "Dentry cache hash table entries: 32768 (order:
5, 131072 bytes)".
Any clues ..?? We have DDR2 in this board and we are initializing it in
U-Boot.
Please find the screen dump below:
Thanks,
Junita
Screen shot:
===========
u-boot> bootm 0x2000000 0x3000000 0x4000000
## Booting image at 02000000 ...
Image Name: Linux-2.6.27.18-svn52-dirty8
Created: 2009-12-08 23:49:28 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1416039 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FF9BD48 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFFA6
bd address = 0x0FF9BFC4
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x00080000
flashoffset = 0x00034000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 399.999 MHz
busfreq = 266.666 MHz
ethaddr = 00:E0:0C:00:8C:01
IP addr = 192.168.201.199
baudrate = 115200 bps
Not skipping initrd
## Loading RAMDisk Image at 03000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2009-10-30 20:15:22 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3889103 Bytes = 3.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using the fdt at 0x4000000
## initrd at 0x03000040 ... 0x033B580E (len=3889103=0x3B57CF)
Loading Ramdisk to 0fbe5000, end 0ff9a7cf ... OK
## device tree at 0x04000000 ... 0x04002FFF (len=12288=0x3000)
Loading Device Tree to 007fc000, end 007fefff ... OK
Updating property '/soc8349@e0000000/ethernet@24000/mac-address' = 00 e0 0c
001Updating property '/soc8349@e0000000/ethernet@24000/local-mac-address' =
00 e01Updating property 'timebase-frequency' = 03 f9 40 aa
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 17 d7 83 fc
Updating property 'bus-frequency' = 0f e5 02 a8
Updating property 'clock-frequency' = 0f e5 02 a8
## Transferring control to Linux (at address 00000000) ...
Using MPC834x ITX machine description
Linux version 2.6.27.18-svn52-dirty8 (root@localhost.localdomain) (gcc
version 9Found initrd at 0xcfbe5000:0xcff9a7cf
console [udbg0] enabled
setup_arch: bootmem
mpc834x_itx_setup_arch()
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs
i0IPIC (128 IRQ sources) at fdffc700
PID hash table entries: 1024 (order: 10, 4096 bytes)
clocksource: timebase mult[3c00001] shift[22] registered
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
On 12/9/09, Lee, Eric <eric.lee@hp.com> wrote:
>
> I would probably remove the bcsr region. this was some cpld I believe on a
> reference board. with this dts it'll try to write to some hardware
> registers that do not exist or are not mapped to the same area.
>
>
>
>
> -----Original Message-----
> From: linuxppc-dev-bounces+eric.lee=hp.com@lists.ozlabs.org [mailto:
> linuxppc-dev-bounces+eric.lee <linuxppc-dev-bounces%2Beric.lee>=hp.com@
> lists.ozlabs.org] On Behalf Of ajijuni@gmail.com
> Sent: Sunday, December 06, 2009 11:41 PM
> To: Linuxppc-dev@lists.ozlabs.org
> Subject: dts file for MPC8343EA
>
> Hi
>
> We have an MPC8343EA based custom board.
>
> I am not able to get Linux up and running in this. No serial output to
> debug further.
> U-boot shows correct 'bdinfo' & 'clocks' output.
> inux hangs at machine_probe.
>
>
> I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
>
> u-boot version - 1.3.2
> linux-2.6.27
> The board base files are drived from MPC8349Imtx-GP since we have the
> reference board in which we tested the linux image.
>
> My current DTS file
> /dts-v1/;
>
> / {
> model = "MPC8343";
> compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
> linux,phandle = <0x100>;
> #size-cells = <0x1>;
> #address-cells = <0x1>;
>
> aliases {
> ethernet0 = &enet0;
> ethernet1 = &enet1;
> serial0 = &serial0;
> serial1 = &serial1;
> pci0 = &pci0;
> pci1 = &pci1;
> };
> cpus {
> linux,phandle = <0x200>;
> #cpus = <0x1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> PowerPC,8343EA@0 {
> device_type = "cpu";
> reg = <0x0>;
> d-cache-line-size = <20>;
> i-cache-line-size = <20>;
> d-cache-size = <8000>;
> i-cache-size = <8000>;
> timebase-frequency = <0>; // from bootloader
> bus-frequency = <0>; // from bootloader
> clock-frequency = <0>; // from bootloader
> 32-bit;
> };
> };
>
>
> memory {
> device_type = "memory";
> reg = <0x00000000 0x10000000>; // 256MB at 0
> };
>
> bcsr@e2400000 {
> device_type = "board-control";
> reg = <0xe2400000 0x8000>;
> };
> soc8343@e0000000 {
> bus-frequency = <0x1>;
> reg = <0xe0000000 0x200>;
> ranges = <0x0 0xe0000000 0x100000>;
> device_type = "soc";
> #interrupt-cells = <0x2>;
> #size-cells = <0x1>;
> #address-cells = <0x1>;
>
> wdt@200 {
> device_type = "watchdog";
> compatible = "mpc83xx_wdt";
> reg = <0x200 0x100>;
> };
>
> i2c@3000 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> compatible = "fsl-i2c";
> reg = <0x3000 0x100>;
> interrupts = <14 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
>
> rtc@68 {
> compatible = "dallas,ds1374";
> reg = <0x68>;
> };
> };
>
> i2c@3100 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <1>;
> compatible = "fsl-i2c";
> reg = <0x3100 0x100>;
> interrupts = <15 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
> };
>
> spi@7000 {
> cell-index = <0>;
> compatible = "fsl,spi";
> reg = <0x7000 0x1000>;
> interrupts = <16 0x8>;
> interrupt-parent = <&ipic>;
> mode = "cpu";
> };
>
> dma@82a8 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
> reg = <0x82a8 4>;
> ranges = <0 0x8100 0x1a8>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> cell-index = <0>;
> dma-channel@0 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@80 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x80 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@100 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x100 0x80>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> dma-channel@180 {
> compatible = "fsl,mpc8349-dma-channel",
> "fsl,elo-dma-channel";
> reg = <0x180 0x28>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
> };
> /* phy type (ULPI or SERIAL) are only types supported for MPH */
> /* port = 0 or 1 */
> usb@22000 {
> compatible = "fsl-usb2-mph";
> reg = <0x22000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <39 0x8>;
> phy_type = "ulpi";
> port1;
> };
> /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
> usb@23000 {
> compatible = "fsl-usb2-dr";
> reg = <0x23000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <38 0x8>;
> dr_mode = "otg";
> phy_type = "ulpi";
> };
>
> mdio@24520 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,gianfar-mdio";
> reg = <0x24520 0x20>;
>
> phy0: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <17 0x8>;
> reg = <0x0>;
> device_type = "ethernet-phy";
> };
> phy1: ethernet-phy@1 {
> interrupt-parent = <&ipic>;
> interrupts = <18 0x8>;
> reg = <0x1>;
> device_type = "ethernet-phy";
> };
> enet0: ethernet@24000 {
> cell-index = <0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x24000 0x1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <32 0x8 33 0x8 34 0x8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy0>;
> linux,network-index = <0>;
> };
>
> enet1: ethernet@25000 {
> cell-index = <1>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <0x25000 0x1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <35 0x8 36 0x8 37 0x8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy1>;
> linux,network-index = <1>;
> };
>
> serial0: serial@4500 {
> cell-index = <0>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4500 0x100>;
> clock-frequency = <0>;
> interrupts = <9 0x8>;
> interrupt-parent = <&ipic>;
> };
>
> serial1: serial@4600 {
> cell-index = <1>;
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x4600 0x100>;
> clock-frequency = <0>;
> interrupts = <10 0x8>;
> interrupt-parent = <&ipic>;
> };
>
> crypto@30000 {
> compatible = "fsl,sec2.0";
> reg = <0x30000 0x10000>;
> interrupts = <11 0x8>;
> interrupt-parent = <&ipic>;
> fsl,num-channels = <4>;
> fsl,channel-fifo-len = <24>;
> fsl,exec-units-mask = <0x7e>;
> fsl,descriptor-types-mask = <0x01010ebf>;
> };
>
> Thanks,
> agnel
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 16657 bytes --]
^ permalink raw reply
* Q: how to access the MPC5200B's timer gipo's?
From: Albrecht Dreß @ 2009-12-09 16:28 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I have a (probably dumb) question regarding the access to the MPC5200B's timer gpio's. I added e.g.
timer@640 { // General Purpose Timer 4
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg = <0x640 0x10>;
interrupts = <1 13 0>;
interrupt-parent = <&mpc5200_pic>;
gpio-controller;
#gpio-cells = <2>;
};
in the DTS file to several timers. Several gpiochipxxx folders are now present in /sys/class/gpio/.
In my code, I grab the node by calling of_find_node_by_path("/soc5200@f0000000/timer@640"), which returns the proper node. Then I try to get the gpio number (for a call to gpio_set_value()) by calling of_get_gpio(node, 0) with the node found above. However, this call always dumps
of_get_gpio_flags: can't parse gpios property
of_get_gpio_flags exited with status -2
What would be the proper way to determine the gpio number for a timer's gpio pin from the node name or path?
Thanks for any help,
Albrecht.
Es weihnachtet sehr! Vom leckerem Backrezept bis zum leckeren Schneehasen finden Sie alles im Weihnachtsspecial von Arcor.de:
http://www.arcor.de/rd/footer.weihnachten
Feliz Navidad, God Yul, Merry X-Mas und ein frohes Fest!
^ permalink raw reply
* RE: dts file for MPC8343EA
From: Lee, Eric @ 2009-12-09 16:22 UTC (permalink / raw)
To: ajijuni@gmail.com, Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <7675847.584551260168085277.JavaMail.nabble@isper.nabble.com>
I would probably remove the bcsr region. this was some cpld I believe on a=
reference board. with this dts it'll try to write to some hardware regist=
ers that do not exist or are not mapped to the same area.
-----Original Message-----
From: linuxppc-dev-bounces+eric.lee=3Dhp.com@lists.ozlabs.org [mailto:linux=
ppc-dev-bounces+eric.lee=3Dhp.com@lists.ozlabs.org] On Behalf Of ajijuni@gm=
ail.com
Sent: Sunday, December 06, 2009 11:41 PM
To: Linuxppc-dev@lists.ozlabs.org
Subject: dts file for MPC8343EA
Hi=20
We have an MPC8343EA based custom board.=20
I am not able to get Linux up and running in this. No serial output to debu=
g further.=20
U-boot shows correct 'bdinfo' & 'clocks' output.=20
inux hangs at machine_probe.
I doubt the DTS file in Linux. anyone has DTS file for MPC8343??=20
u-boot version - 1.3.2
linux-2.6.27
The board base files are drived from MPC8349Imtx-GP since we have the refer=
ence board in which we tested the linux image.
My current DTS file=20
/dts-v1/;=20
/ {=20
model =3D "MPC8343";=20
compatible =3D "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";=20
linux,phandle =3D <0x100>;=20
#size-cells =3D <0x1>;=20
#address-cells =3D <0x1>;=20
aliases {=20
ethernet0 =3D &enet0;=20
ethernet1 =3D &enet1;=20
serial0 =3D &serial0;=20
serial1 =3D &serial1;=20
pci0 =3D &pci0;=20
pci1 =3D &pci1;=20
};=20
cpus {=20
linux,phandle =3D <0x200>;=20
#cpus =3D <0x1>;=20
#address-cells =3D <1>;=20
#size-cells =3D <0>;=20
PowerPC,8343EA@0 {=20
device_type =3D "cpu";=20
reg =3D <0x0>;=20
d-cache-line-size =3D <20>;=20
i-cache-line-size =3D <20>;=20
d-cache-size =3D <8000>;=20
i-cache-size =3D <8000>;=20
timebase-frequency =3D <0>; // from bootloade=
r=20
bus-frequency =3D <0>; // from bootloade=
r=20
clock-frequency =3D <0>; // from bootloade=
r=20
32-bit;=20
};=20
};=20
memory {=20
device_type =3D "memory";=20
reg =3D <0x00000000 0x10000000>; // 256MB at 0=20
};=20
bcsr@e2400000 {=20
device_type =3D "board-control";=20
reg =3D <0xe2400000 0x8000>;=20
};=20
soc8343@e0000000 {=20
bus-frequency =3D <0x1>;=20
reg =3D <0xe0000000 0x200>;=20
ranges =3D <0x0 0xe0000000 0x100000>;=20
device_type =3D "soc";=20
#interrupt-cells =3D <0x2>;=20
#size-cells =3D <0x1>;=20
#address-cells =3D <0x1>;=20
wdt@200 {=20
device_type =3D "watchdog";=20
compatible =3D "mpc83xx_wdt";=20
reg =3D <0x200 0x100>;=20
};=20
i2c@3000 {=20
#address-cells =3D <1>;=20
#size-cells =3D <0>;=20
cell-index =3D <0>;=20
compatible =3D "fsl-i2c";=20
reg =3D <0x3000 0x100>;=20
interrupts =3D <14 0x8>;=20
interrupt-parent =3D <&ipic>;=20
dfsrr;=20
rtc@68 {=20
compatible =3D "dallas,ds1374";=20
reg =3D <0x68>;=20
};=20
};=20
i2c@3100 {=20
#address-cells =3D <1>;=20
#size-cells =3D <0>;=20
cell-index =3D <1>;=20
compatible =3D "fsl-i2c";=20
reg =3D <0x3100 0x100>;=20
interrupts =3D <15 0x8>;=20
interrupt-parent =3D <&ipic>;=20
dfsrr;=20
};=20
spi@7000 {=20
cell-index =3D <0>;=20
compatible =3D "fsl,spi";=20
reg =3D <0x7000 0x1000>;=20
interrupts =3D <16 0x8>;=20
interrupt-parent =3D <&ipic>;=20
mode =3D "cpu";=20
};=20
dma@82a8 {=20
#address-cells =3D <1>;=20
#size-cells =3D <1>;=20
compatible =3D "fsl,mpc8349-dma", "fsl,elo-dma";=20
reg =3D <0x82a8 4>;=20
ranges =3D <0 0x8100 0x1a8>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <71 8>;=20
cell-index =3D <0>;=20
dma-channel@0 {=20
compatible =3D "fsl,mpc8349-dma-channel", "=
fsl,elo-dma-channel";=20
reg =3D <0 0x80>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <71 8>;=20
};=20
dma-channel@80 {=20
compatible =3D "fsl,mpc8349-dma-channel", "=
fsl,elo-dma-channel";=20
reg =3D <0x80 0x80>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <71 8>;=20
};=20
dma-channel@100 {=20
compatible =3D "fsl,mpc8349-dma-channel", "=
fsl,elo-dma-channel";=20
reg =3D <0x100 0x80>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <71 8>;=20
};=20
dma-channel@180 {=20
compatible =3D "fsl,mpc8349-dma-channel", "=
fsl,elo-dma-channel";=20
reg =3D <0x180 0x28>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <71 8>;=20
};=20
};=20
/* phy type (ULPI or SERIAL) are only types supported for MPH */=20
/* port =3D 0 or 1 */=20
usb@22000 {=20
compatible =3D "fsl-usb2-mph";=20
reg =3D <0x22000 0x1000>;=20
#address-cells =3D <1>;=20
#size-cells =3D <0>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <39 0x8>;=20
phy_type =3D "ulpi";=20
port1;=20
};=20
/* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */=20
usb@23000 {=20
compatible =3D "fsl-usb2-dr";=20
reg =3D <0x23000 0x1000>;=20
#address-cells =3D <1>;=20
#size-cells =3D <0>;=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <38 0x8>;=20
dr_mode =3D "otg";=20
phy_type =3D "ulpi";=20
};=20
mdio@24520 {=20
#address-cells =3D <1>;=20
#size-cells =3D <0>;=20
compatible =3D "fsl,gianfar-mdio";=20
reg =3D <0x24520 0x20>;=20
phy0: ethernet-phy@0 {=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <17 0x8>;=20
reg =3D <0x0>;=20
device_type =3D "ethernet-phy";=20
};=20
phy1: ethernet-phy@1 {=20
interrupt-parent =3D <&ipic>;=20
interrupts =3D <18 0x8>;=20
reg =3D <0x1>;=20
device_type =3D "ethernet-phy";=20
};=20
enet0: ethernet@24000 {=20
cell-index =3D <0>;=20
device_type =3D "network";=20
model =3D "TSEC";=20
compatible =3D "gianfar";=20
reg =3D <0x24000 0x1000>;=20
local-mac-address =3D [ 00 00 00 00 00 00 ];=20
interrupts =3D <32 0x8 33 0x8 34 0x8>;=20
interrupt-parent =3D <&ipic>;=20
phy-handle =3D <&phy0>;=20
linux,network-index =3D <0>;=20
};=20
enet1: ethernet@25000 {=20
cell-index =3D <1>;=20
device_type =3D "network";=20
model =3D "TSEC";=20
compatible =3D "gianfar";=20
reg =3D <0x25000 0x1000>;=20
local-mac-address =3D [ 00 00 00 00 00 00 ];=20
interrupts =3D <35 0x8 36 0x8 37 0x8>;=20
interrupt-parent =3D <&ipic>;=20
phy-handle =3D <&phy1>;=20
linux,network-index =3D <1>;=20
};=20
serial0: serial@4500 {=20
cell-index =3D <0>;=20
device_type =3D "serial";=20
compatible =3D "ns16550";=20
reg =3D <0x4500 0x100>;=20
clock-frequency =3D <0>;=20
interrupts =3D <9 0x8>;=20
interrupt-parent =3D <&ipic>;=20
};=20
serial1: serial@4600 {=20
cell-index =3D <1>;=20
device_type =3D "serial";=20
compatible =3D "ns16550";=20
reg =3D <0x4600 0x100>;=20
clock-frequency =3D <0>;=20
interrupts =3D <10 0x8>;=20
interrupt-parent =3D <&ipic>;=20
};=20
crypto@30000 {=20
compatible =3D "fsl,sec2.0";=20
reg =3D <0x30000 0x10000>;=20
interrupts =3D <11 0x8>;=20
interrupt-parent =3D <&ipic>;=20
fsl,num-channels =3D <4>;=20
fsl,channel-fifo-len =3D <24>;=20
fsl,exec-units-mask =3D <0x7e>;=20
fsl,descriptor-types-mask =3D <0x01010ebf>;=20
};=20
Thanks,=20
agnel=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers
From: Anton Vorontsov @ 2009-12-09 16:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, B.J. Buchalter
In-Reply-To: <20091207225435.GA18485@oksana.dev.rtsoft.ru>
On Tue, Dec 08, 2009 at 01:54:35AM +0300, Anton Vorontsov wrote:
> It appears that we wrongly calculate dev_base for type1 config cycles.
> The thing is: we shouldn't subtract hose->first_busno because PCI core
> sets PCI primary, secondary and subordinate bus numbers, and PCIe
> controller actually takes the registers into account. So we should use
> just bus->number.
>
> Also, according to MPC8315 reference manual, primary bus number should
> always remain 0. We have PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS quirk
> in indirect_pci.c, but since 83xx is somewhat special, it doesn't use
> indirect_pci.c routines, so we have to implement the quirk specifically
> for 83xx PCIe controllers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> This fixes the issue similar to http://www.pubbs.net/linuxppc/200908/22024/
> i.e. lspci reports:
>
> 0000:00:00.0 Power PC: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:02:00.0 PCI bridge: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:01.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:02.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> ...
>
> While it should be:
>
> 0000:00:00.0 Power PC: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:02:00.0 PCI bridge: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01)
Just for the reference... I found and tested a PLX bridge, and
it works OK as well:
0002:03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
0002:04:00.0 USB Controller: NEC Corporation USB (rev 43)
0002:04:00.1 USB Controller: NEC Corporation USB (rev 43)
0002:04:00.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
0002:04:01.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC PATCH v2 2/6] powerpc: wii: bootwrapper bits
From: Segher Boessenkool @ 2009-12-09 16:23 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1259880447-5008-3-git-send-email-albert_herranz@yahoo.es>
> Add support for the Nintendo Wii video game console to the powerpc
> bootwrapper.
>
> dtbImage.wii is a wrapped image that contains a flat device tree,
> an entry point compatible with the Homebrew Channel and BootMii,
> and an optional initrd.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH 6/8] Use proper types for do_div
From: Anton Vorontsov @ 2009-12-09 16:09 UTC (permalink / raw)
To: Mark Wielaard; +Cc: linuxppc-dev, systemtap
In-Reply-To: <1260374194.31018.11.camel@springer.wildebeest.org>
On Wed, Dec 09, 2009 at 04:56:34PM +0100, Mark Wielaard wrote:
> On Sat, 2009-11-28 at 01:33 +0300, Anton Vorontsov wrote:
> > do_div accepts unsigned 64-bit integer type for dividend, signed types
> > would cause do_div's typecheck fail:
> >
> > stat-common.c: In function 'needed_space':
> > stat-common.c:50: error: comparison of distinct pointer types lacks a cast
> > ...same errors in time.c and tapset-timers.cxx's generated code...
> >
> I don't immediately see anything wrong with the code. But on x86_64 this
> does cause some regression test failures in testsuite/systemtap.maps. In
> particular the following tests now fail (they all pass with this one
> patch reverted):
>
> Running /home/mark/src/systemtap/testsuite/systemtap.maps/elision.exp ...
> FAIL: elision-1
[...]
> Running /home/mark/src/systemtap/testsuite/systemtap.maps/log_edge.exp ...
> FAIL: systemtap.maps/log_edge.stp
>
> Could you have a look?
I think this should be fixed by this patch:
http://sourceware.org/ml/systemtap/2009-q4/msg00800.html
Can you try it? With this patch I see no new regressions on x86_64.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/8] Use proper types for do_div
From: Mark Wielaard @ 2009-12-09 15:56 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, systemtap
In-Reply-To: <20091127223347.GF21805@oksana.dev.rtsoft.ru>
Hi Anton,
On Sat, 2009-11-28 at 01:33 +0300, Anton Vorontsov wrote:
> do_div accepts unsigned 64-bit integer type for dividend, signed types
> would cause do_div's typecheck fail:
>
> stat-common.c: In function 'needed_space':
> stat-common.c:50: error: comparison of distinct pointer types lacks a cast
> ...same errors in time.c and tapset-timers.cxx's generated code...
>
> A fix for time.c is special, on ppc32 cycles_t is 32-bit, so technically
> we don't need do_div, but since the whole _stp_gettimeofday_ns() operates
> on 64-bit types we'd better be safe and use uint64_t for the math.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> runtime/stat-common.c | 8 ++++----
> runtime/time.c | 3 ++-
> tapset-timers.cxx | 2 +-
> 3 files changed, 7 insertions(+), 6 deletions(-)
I don't immediately see anything wrong with the code. But on x86_64 this
does cause some regression test failures in testsuite/systemtap.maps. In
particular the following tests now fail (they all pass with this one
patch reverted):
Running /home/mark/src/systemtap/testsuite/systemtap.maps/elision.exp ...
FAIL: elision-1
FAIL: elision0
FAIL: elision1
FAIL: elision2
FAIL: elision3
Running /home/mark/src/systemtap/testsuite/systemtap.maps/ix.exp ...
FAIL: systemtap.maps/ix.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_large_neg.exp ...
FAIL: systemtap.maps/linear_large_neg.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_overunder.exp ...
FAIL: systemtap.maps/linear_overunder.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_under.exp ...
FAIL: systemtap.maps/linear_under.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/log.exp ...
FAIL: systemtap.maps/log.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/log_edge.exp ...
FAIL: systemtap.maps/log_edge.stp
Could you have a look?
Thanks,
Mark
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-12-09 15:49 UTC (permalink / raw)
To: Grant Likely; +Cc: avorontsov
In-Reply-To: <fa686aa40911261117y4744e56bmf4d1d8260c7a51d0@mail.gmail.com>
On Thu, Nov 26, 2009 at 20:17:35, Grant Likely wrote:
[...]
> spi-cs-high is definitely not a complete solution, but it isn't
> actively evil either. Plus it is documented and (presumably) in
> active use. so support for it should not be dropped.
>
> Regardless, there needs to be a library function for parsing all the
> SPI child nodes and returning the active state for each GPIO chip
> select. All the code for parsing the old spi-cs-high properties can
> be contained in the same place as a new yet-to-be-defined bus node cs
> polarity property. The rework to the driver itself is not ugly.
>
The following patch adds a function to get the active state of the chip select
of a SPI device by looking for the 'spi-cs-high' property in the associated device
tree node.
This function is used by the spi_mpc8xxx driver to set a proper initial value
to the associated GPIOs.
Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
---
diff -ruN linux-2.6.32_orig//drivers/of/of_spi.c linux-2.6.32/drivers/of/of_spi.c
--- linux-2.6.32_orig//drivers/of/of_spi.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/of/of_spi.c 2009-12-09 12:37:01.000000000 +0100
@@ -10,6 +10,49 @@
#include <linux/device.h>
#include <linux/spi/spi.h>
#include <linux/of_spi.h>
+#include <linux/errno.h>
+
+/**
+ * of_get_spi_cs_active_state - Gets the chip select's active state of a SPI
+ * child devices.
+ * @np: parent node of the SPI device nodes
+ * @index: index/address of the SPI device (refers to the 'reg' property)
+ * @cs_active: pointer to return the chip select's active state
+ * (true = active high; false = active low)
+ *
+ * Returns 0 on success; negative errno on failure
+ */
+int of_get_spi_cs_active_state(struct device_node *np, int index, bool *cs_active)
+{
+ struct device_node *child;
+ const int *prop;
+ int len;
+ bool active = 0;
+
+ /* search for the matching SPI device */
+ for_each_child_of_node(np, child) {
+ prop = of_get_property(child, "reg", &len);
+ if (!prop || len < sizeof(*prop)) {
+ /* property 'reg' not available (not an error) */
+ continue;
+ }
+
+ if ( *prop == index ) {
+ /* matching device found */
+ if (of_find_property(child, "spi-cs-high", NULL))
+ active = 1;
+
+ if (cs_active)
+ *cs_active = active;
+
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL(of_get_spi_cs_active_state);
+
/**
* of_register_spi_devices - Register child devices onto the SPI bus
diff -ruN linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.32/drivers/spi/spi_mpc8xxx.c
--- linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/spi/spi_mpc8xxx.c 2009-12-09 12:50:36.000000000 +0100
@@ -705,6 +705,7 @@
for (; i < ngpios; i++) {
int gpio;
enum of_gpio_flags flags;
+ bool astate;
gpio = of_get_gpio_flags(np, i, &flags);
if (!gpio_is_valid(gpio)) {
@@ -721,8 +722,15 @@
pinfo->gpios[i] = gpio;
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+ ret = of_get_spi_cs_active_state(np, i, &astate);
+ if (ret) {
+ dev_err(dev, "can't get cs active state of device "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+
ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
+ pinfo->alow_flags[i] ^ !astate);
if (ret) {
dev_err(dev, "can't set output direction for gpio "
"#%d: %d\n", i, ret);
diff -ruN linux-2.6.32_orig//include/linux/of_spi.h linux-2.6.32/include/linux/of_spi.h
--- linux-2.6.32_orig//include/linux/of_spi.h 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/include/linux/of_spi.h 2009-12-09 12:36:48.000000000 +0100
@@ -15,4 +15,7 @@
extern void of_register_spi_devices(struct spi_master *master,
struct device_node *np);
+extern int of_get_spi_cs_active_state(struct device_node *np,
+ int index, bool *cs_active);
+
#endif /* __LINUX_OF_SPI */
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Josh Boyer @ 2009-12-09 15:47 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091209103645.01058e79@opus.seanm.ca>
On Wed, Dec 09, 2009 at 10:36:45AM -0500, Sean MacLennan wrote:
>On Wed, 9 Dec 2009 09:40:55 -0500
>Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
>> How does that impact the older revisions? You're using a cuImage
>> with Warp, so the device tree is bundled with that. If you boot a
>> new kernel with this change to the DTS on a older board revision,
>> will it do bad things?
>
>The new SD driver takes care of that. If you use the new kernel with an
>old FPGA you reserve more space than you need, but the driver will not
>touch it.
>
>And if you somehow end up with the new DTS on an older kernel, the old
>SD driver will not use the space anyway since the buffer is limited to
>one block.
>
>The SD driver is not in the kernel proper because it was implemented in
>the FPGA and has a non-standard interface. It requires a change to the
>SD core to run. But it is GPLed, so if anybody wants to see it, just
>ask.
OK thanks. I figured something like that would be the case, but wanted to
verify first.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Sean MacLennan @ 2009-12-09 15:36 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <20091209144055.GS2937@zod.rchland.ibm.com>
On Wed, 9 Dec 2009 09:40:55 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> How does that impact the older revisions? You're using a cuImage
> with Warp, so the device tree is bundled with that. If you boot a
> new kernel with this change to the DTS on a older board revision,
> will it do bad things?
The new SD driver takes care of that. If you use the new kernel with an
old FPGA you reserve more space than you need, but the driver will not
touch it.
And if you somehow end up with the new DTS on an older kernel, the old
SD driver will not use the space anyway since the buffer is limited to
one block.
The SD driver is not in the kernel proper because it was implemented in
the FPGA and has a non-standard interface. It requires a change to the
SD core to run. But it is GPLed, so if anybody wants to see it, just
ask.
Cheers,
Sean
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Wolfram Sang @ 2009-12-09 14:57 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200912091529.13913.roman.fietze@telemotive.de>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hello Roman,
> I would be interested in your opinion, maybe Wolfgang could make some
> comments, because he is involved in the U-Boot a lot as well.
Do you have a way to measure performance penalties? I know that stability comes
before performance, still I am wondering as it looks to me that the most
interesting features are simply switched off.
Regrads,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Josh Boyer @ 2009-12-09 14:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091209000437.78794a8f@opus.seanm.ca>
On Wed, Dec 09, 2009 at 12:04:37AM -0500, Sean MacLennan wrote:
>Newer revs of the FPGA have a larger SD buffer.
How does that impact the older revisions? You're using a cuImage with Warp,
so the device tree is bundled with that. If you boot a new kernel with this
change to the DTS on a older board revision, will it do bad things?
josh
^ permalink raw reply
* MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2009-12-09 14:29 UTC (permalink / raw)
To: linuxppc-dev
Hallo,
I had a discussion with some Freescale support people about the
constant RFIFO Event errors or PATA hard disk crashes when stressing a
board with (very) high loads, in my case even with some additional
traffic from an FPGA (or just the FLASH) via the SCLPC FIFO using the
BestComm.
The latest recommendation from Freescale was to set BSDIS and PLDIS
and to clear SE, resulting in a XLB config register value of
0x80012006, at least for my MPC5200B PVR/SVR of
0x80822014/0x80110022. If I am correct, the current XLB config setting
using the current U-Boot and kernel is 0x0000a006.
In order to get cache coherency I had to set
CONFIG_NOT_COHERENT_CACHE=3Dy for the MPC5200B boards. Please correct me
if I am wrong with this assumption.
With this setup, XLB config and kernel config, I do no longer have any
PATA crashes, I do no longer have any FEC RFIFO errors, and my SCLPC
driver runs w/o problems, too.
I would be interested in your opinion, maybe Wolfgang could make some
comments, because he is involved in the U-Boot a lot as well.
Here is the original text from the Freescale support person:
=2D- snippety snip --
Dear Roman Fietze,=20
In reply to your message regarding Service Request SR 1-597437219:
Disable pipelining also. Test your software using the following
setting of the XLB arbiter: 0x80012006.
We have request from a customer with similar problem. Problem
disappeared if XLB pipelining and BestComm snooping were disabled.
Should you need to contact us with regard to this message, please see
the notes below.
Best Regards,=20
Pavel=20
Technical Support
=46reescale Semiconductor
=2D- snappety snap --
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* RE: [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: Kumar Gopalpet-B05799 @ 2009-12-09 13:55 UTC (permalink / raw)
To: avorontsov; +Cc: David Miller, linuxppc-dev, netdev
In-Reply-To: <20091209.025245.152622485.davem@davemloft.net>
=20
>From: Anton Vorontsov <avorontsov@ru.mvista.com>
>Date: Wed, 9 Dec 2009 13:44:27 +0300
>
>> commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add=20
>> Multiple group Support") introduced the following build error with=20
>> CONFIG_NET_POLL_CONTROLLER=3Dy:
> ...
>> This patch fixes the issue.
>>=20
>> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
Thanks Anton !
^ permalink raw reply
* Re: 2.6.33 -next tree
From: Grant Likely @ 2009-12-09 13:40 UTC (permalink / raw)
To: Luotao Fu; +Cc: linuxppc-dev
In-Reply-To: <4B1F6D3A.3030500@pengutronix.de>
On Wed, Dec 9, 2009 at 2:26 AM, Luotao Fu <l.fu@pengutronix.de> wrote:
> Hi Grant,
>
> Grant Likely wrote:
>> Hi Ben, Stephen.
>>
>> I just prepared my next branch for 2.6.33:
>> git://git.secretlab.ca/git/linux-2.6 next
>>
>
> Just for curiosity: I noticed that you keep so far the further patches for the
> dedicated spi controller on mpc5200 in the next-spi tree. Any plan when they
> will be merged to the -next tree? Like mentioned before, some of them are
> essential, without which the driver doesn't work (at least on my board)
I based the next-spi tree on my regular next tree (which was
convenient, but lead to it looking like I had inappropriate stuff in
my spi tree). Once Ben asks Linus to pull his tree it will all look
correct. I'll ask Linux to pull my next-spi tree directly after Ben's
tree is in.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: David Miller @ 2009-12-09 10:52 UTC (permalink / raw)
To: avorontsov; +Cc: Sandeep.Kumar, linuxppc-dev, netdev
In-Reply-To: <20091209104427.GA25526@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 9 Dec 2009 13:44:27 +0300
> commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add
> Multiple group Support") introduced the following build error
> with CONFIG_NET_POLL_CONTROLLER=y:
...
> This patch fixes the issue.
>
> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, but this shows that netconsole needs some serious
testing with this drive now :-/
Thanks.
^ permalink raw reply
* [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: Anton Vorontsov @ 2009-12-09 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Sandeep Gopalpet, netdev, linuxppc-dev, David Miller
In-Reply-To: <1260341804.16132.22.camel@pasglop>
commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add
Multiple group Support") introduced the following build error
with CONFIG_NET_POLL_CONTROLLER=y:
CC ggianfar.o
ggianfar.c: In function 'gfar_netpoll':
ggianfar.c:2653: error: invalid storage class for function 'gfar_interrupt'
ggianfar.c:2652: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:2681: error: invalid storage class for function 'adjust_link'
ggianfar.c:2764: error: invalid storage class for function 'gfar_set_multi'
ggianfar.c:2855: error: invalid storage class for function 'gfar_clear_exact_match'
ggianfar.c:2877: error: invalid storage class for function 'gfar_set_hash_for_addr'
ggianfar.c:2898: error: invalid storage class for function 'gfar_set_mac_for_addr'
ggianfar.c:2922: error: invalid storage class for function 'gfar_error'
ggianfar.c:3020: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:3032: error: invalid storage class for function 'gfar_init'
ggianfar.c:3037: error: invalid storage class for function 'gfar_exit'
ggianfar.c:3041: error: initializer element is not constant
ggianfar.c:3042: error: initializer element is not constant
ggianfar.c:3042: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:3042: error: expected declaration or statement at end of input
make[1]: *** [ggianfar.o] Error 1
This patch fixes the issue.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Wed, Dec 09, 2009 at 05:56:44PM +1100, Benjamin Herrenschmidt wrote:
> In my next (not pushed out yet as I'm writing this but will be by the
> time you read it hopefully), I get a build failure:
>
> /home/benh/linux-powerpc-test/drivers/net/gianfar.c: In function ‘gfar_netpoll’:
> /home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653: error: invalid storage class for function ‘gfar_interrupt’
[...]
> make[3]: *** [drivers/net/gianfar.o] Error 1
>
> Stephen says that breakage has been in -next for some time...
>
> Can you guys sort it out ?
drivers/net/gianfar.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 16def13..6850dc0 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2644,6 +2644,7 @@ static void gfar_netpoll(struct net_device *dev)
gfar_interrupt(priv->gfargrp[i].interruptTransmit,
&priv->gfargrp[i]);
enable_irq(priv->gfargrp[i].interruptTransmit);
+ }
}
}
#endif
--
1.6.3.3
^ permalink raw reply related
* Problem in setting timeout from user space for MPC 83x watchdog timer
From: Aswathi C @ 2009-12-09 9:41 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
I am using MPC 8323E processor and linux-2.6.24 kernel.
I tried to set watchdog timer from user space using ioctl with the case
WDIOC_SETTIMEOUT.
I am getting timeout value as seconds and calculating corresponding modulus
for the WDT.
After that I am setting SWTC of SWCRR and writing service sequence to SWSRR.
But SWCNR is setting back to 0xffff after service sequence written into
SWSRR, means it is not setting with configured SWTC.
Can anyone tell what is the problem?
Please suggest solution..
Regards,
Aswathi
[-- Attachment #2: Type: text/html, Size: 561 bytes --]
^ permalink raw reply
* RE: gianfar breaking builds
From: Benjamin Herrenschmidt @ 2009-12-09 9:34 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: linuxppc-dev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA08A6F@zin33exm22.fsl.freescale.net>
On Wed, 2009-12-09 at 15:02 +0530, Kumar Gopalpet-B05799 wrote:
>
> I din't notice that netpoll wa enabled in your compilation.
> This is also not wotking on net-next tree.
>
> Will send out a patch today in some time.
Ah yes, this is something close to a 6xx_defconfig. Thanks.
Cheers,
Ben.
^ permalink raw reply
* RE: gianfar breaking builds
From: Kumar Gopalpet-B05799 @ 2009-12-09 9:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260350780.16132.40.camel@pasglop>
=20
>
>This is powerpc-next which contains the current Linus stuff=20
>plus the pending powerpc stuff. If that's fixed in net-next=20
>then we shall wait for Dave to merge it I suppose.
>
I din't notice that netpoll wa enabled in your compilation.
This is also not wotking on net-next tree.
Will send out a patch today in some time.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2009-12-09 9:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1260348995.16132.37.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 09/12/2009 09:56:35:
>
> On Wed, 2009-12-09 at 08:39 +0100, Joakim Tjernlund wrote:
> > The later isn't as simple :) I believe the bulk of such code in
> > entry_32.S.
>
> Yeah but it would be useful for hash I suppose if one really wants to
> boot with nobats. Though at least on hash most of the time we have ways
> to recover by mean of MSR:RI being cleared, which your TLB miss code
> doesn't check...
Never looked at this so I cannot comment.
>
> > Anyhow, the config option is still valid as if enabled
> > it will pin several DTLB's too. Scott had some concerns about removing
> > the config option completely so this was the next best thing.
>
> Well, if you want to pin at least one entry, then just remove the #if
> completely but don't leave a #if 1 :-)
I could, but I wanted to have an easy way back to the old way if
the need arises.
Anyway, I am rather busy ATM with more pressing matters so I would
appreciate if you could take the patch as is.
Jocke
^ permalink raw reply
* RE: gianfar breaking builds
From: Benjamin Herrenschmidt @ 2009-12-09 9:26 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: linuxppc-dev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA08A66@zin33exm22.fsl.freescale.net>
On Wed, 2009-12-09 at 14:20 +0530, Kumar Gopalpet-B05799 wrote:
> Hi Ben,
>
> Can you point to me from where you cloned the tree.
>
> Also, net-next-2.6 tree was building for me.
This is powerpc-next which contains the current Linus stuff plus the
pending powerpc stuff. If that's fixed in net-next then we shall wait
for Dave to merge it I suppose.
Cheers,
Ben.
> --
> Thanks
> Sandeep
>
> >-----Original Message-----
> >From:
> >linuxppc-dev-bounces+sandeep.kumar=freescale.com@lists.ozlabs.o
> >rg
> >[mailto:linuxppc-dev-bounces+sandeep.kumar=freescale.com@lists.
> >ozlabs.org] On Behalf Of Benjamin Herrenschmidt
> >Sent: Wednesday, December 09, 2009 12:27 PM
> >To: Kumar Gala
> >Cc: linuxppc-dev
> >Subject: gianfar breaking builds
> >
> >In my next (not pushed out yet as I'm writing this but will be
> >by the time you read it hopefully), I get a build failure:
> >
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c: In
> >function 'gfar_netpoll':
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653:
> >error: invalid storage class for function 'gfar_interrupt'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2652:
> >warning: ISO C90 forbids mixed declarations and code
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2681:
> >error: invalid storage class for function 'adjust_link'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2764:
> >error: invalid storage class for function 'gfar_set_multi'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2855:
> >error: invalid storage class for function 'gfar_clear_exact_match'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2877:
> >error: invalid storage class for function 'gfar_set_hash_for_addr'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2898:
> >error: invalid storage class for function 'gfar_set_mac_for_addr'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2922:
> >error: invalid storage class for function 'gfar_error'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3017:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3032:
> >error: invalid storage class for function 'gfar_init'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3037:
> >error: invalid storage class for function 'gfar_exit'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:
> >error: invalid storage class for function '__inittest'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >error: invalid storage class for function '__exittest'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >warning: ISO C90 forbids mixed declarations and code
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >error: expected declaration or statement at end of input
> >make[3]: *** [drivers/net/gianfar.o] Error 1
> >
> >Stephen says that breakage has been in -next for some time...
> >
> >Can you guys sort it out ?
> >
> >Cheers,
> >Ben.
> >
> >
> >_______________________________________________
> >Linuxppc-dev mailing list
> >Linuxppc-dev@lists.ozlabs.org
> >https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
^ permalink raw reply
* Re: 2.6.33 -next tree
From: Luotao Fu @ 2009-12-09 9:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911042210q5bbbca2fi82911b7245d17588@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> Hi Ben, Stephen.
>
> I just prepared my next branch for 2.6.33:
> git://git.secretlab.ca/git/linux-2.6 next
>
Just for curiosity: I noticed that you keep so far the further patches for the
dedicated spi controller on mpc5200 in the next-spi tree. Any plan when they
will be merged to the -next tree? Like mentioned before, some of them are
essential, without which the driver doesn't work (at least on my board)
sorry for nagging. ;-)
thanks
cheers
Luotao Fu
--
Pengutronix e.K. | Dipl.-Ing. Luotao Fu |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Peter Korsgaard @ 2009-12-09 9:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260349142.16132.39.camel@pasglop>
>>>>> "Benjamin" == Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
Benjamin> On Wed, 2009-12-09 at 08:32 +0100, Peter Korsgaard wrote:
>> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>>
Peter> struct irq_chip::typename is going away (replaced by name). Use name if
Peter> set instead of typename in show_interrupt to make ease transition.
>>
>> Comments?
Benjamin> Hi Peter !
Benjamin> There's already a patch in my -next tree from Thomas Gleixner
Benjamin> that fixes that up along with a few others in arch/powerpc.
Ahh, ok - Hadn't noticed - Sorry.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Benjamin Herrenschmidt @ 2009-12-09 8:59 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87y6lcmwkk.fsf@macbook.be.48ers.dk>
On Wed, 2009-12-09 at 08:32 +0100, Peter Korsgaard wrote:
> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>
> Peter> struct irq_chip::typename is going away (replaced by name). Use name if
> Peter> set instead of typename in show_interrupt to make ease transition.
>
> Comments?
Hi Peter !
There's already a patch in my -next tree from Thomas Gleixner that fixes
that up along with a few others in arch/powerpc.
Cheers,
Ben.
> Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> Peter> ---
> Peter> arch/powerpc/kernel/irq.c | 3 ++-
> Peter> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> Peter> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> Peter> index e5d1211..33e1130 100644
> Peter> --- a/arch/powerpc/kernel/irq.c
> Peter> +++ b/arch/powerpc/kernel/irq.c
> Peter> @@ -203,7 +203,8 @@ int show_interrupts(struct seq_file *p, void *v)
> Peter> seq_printf(p, "%10u ", kstat_irqs(i));
> Peter> #endif /* CONFIG_SMP */
> Peter> if (desc->chip)
> Peter> - seq_printf(p, " %s ", desc->chip->typename);
> Peter> + seq_printf(p, " %s ", desc->chip->name ?
> Peter> + desc->chip->name : desc->chip->typename);
> Peter> else
> Peter> seq_puts(p, " None ");
> Peter> seq_printf(p, "%s", (desc->status & IRQ_LEVEL) ? "Level " : "Edge ");
> Peter> --
> Peter> 1.6.5
>
>
^ 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