* 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: [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: [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] 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: 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
* 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
* 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
* RE: dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
From: Lee, Eric @ 2009-12-09 18:12 UTC (permalink / raw)
To: Junita Ajith; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <72d214170912090957g3743c63bq48836f6faa4b8269@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14871 bytes --]
two things; I had better luck with the mpc8349mds (? don't remember exact file name) dts as opposed to the itx. I had to remove the bcsr section or else the kernel hung during initialization . also, your u-boot is not passing the correct kernel commandline:
"Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs i0IPIC (128 IRQ sources) at fdffc700"
you're trying to run a ramdisk and with tty I expect:
"root=/dev/ram rw console=ttyS0,115200 "
check your environment variable bootargs in u-boot
From: Junita Ajith [mailto:ajijuni@gmail.com]
Sent: Wednesday, December 09, 2009 10:58 AM
To: Lee, Eric
Cc: Linuxppc-dev@lists.ozlabs.org
Subject: dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
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<mailto: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<http://hp.com>@lists.ozlabs.org<http://lists.ozlabs.org> [mailto:linuxppc-dev-bounces+eric.lee<mailto:linuxppc-dev-bounces%2Beric.lee>=hp.com<http://hp.com>@lists.ozlabs.org<http://lists.ozlabs.org>] On Behalf Of ajijuni@gmail.com<mailto:ajijuni@gmail.com>
Sent: Sunday, December 06, 2009 11:41 PM
To: Linuxppc-dev@lists.ozlabs.org<mailto: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<mailto:Linuxppc-dev@lists.ozlabs.org>
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 47549 bytes --]
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-12-09 19:13 UTC (permalink / raw)
To: Grant Likely; +Cc: avorontsov
In-Reply-To: <fa686aa40912090946m12fe293cg2efb043cb7a7f573@mail.gmail.com>
On Wed, Dec 9, 2009 at 18:46:51 Grant Likely wrote:
[...]
> > + 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;
> > + }
>
> This is a bit heavy handed in that it expects the device tree to be
> fully populated with all SPI devices which isn't always a given. For
> example a board that has some unpopulated SPI devices could have some
> gaps in the GPIO CS layout. If a node can't be found, then just
> ignore it silently and move on to the next. I'd do something like
> this:
>
> + astate = of_get_spi_cs_active_state(np, i);
What should be returned if the node can't be found, 'true' or 'false?
Maybe its better to do the following:
+ ret = of_get_spi_cs_active_state(np, i, &astate);
+ if (ret) {
+ /* Device node not found */
+ continue;
+ }
> ret = gpio_direction_output(pinfo->gpios[i],
> - pinfo->alow_flags[i]);
> + pinfo->alow_flags[i] ^ !astate);
>
> BTW, why the xor? The usage is non-obvious enough that I'd like to
> see a comment describing the use case.
If I understand it right, the alow_flags describe the wiring. If set to 0 the
wiring is non-inverted, if set to 1 its inverted respectively. To take this
into account the active state has to be xor'd with the appropriate alow_flag.
^ permalink raw reply
* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: Scott Wood @ 2009-12-09 19:59 UTC (permalink / raw)
To: 林志平; +Cc: linuxppc-dev
In-Reply-To: <8148211e0912071825t22ffa590va2fe22272f6aaf62@mail.gmail.com>
林志平 wrote:
> > Another question is that I found linux2.6.31 does not support
> > board mpc8544ds,
>
> It should. What problems do you see?
>
> => bootm 0x1000000 0x1800000 0x800000
> ## Booting kernel from Legacy Image at 01000000 ...
> Image Name: Linux-2.6.31
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2185099 Bytes = 2.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 01800000 ...
> Image Name: Simple Embedded Linux Framework
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 1859256 Bytes = 1.8 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00800000
> Booting using the fdt blob at 0x800000
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK
> booting kernel using flat tree
> It then stops and never print any more, I use mpc85xx_defconfig, I
> select mpc85xxds in the menuconfig and deselect other options like
> mpc8540ads etc.
Are you using the mpc8544ds device tree from 2.6.31, unchanged? Try
turning on CONFIG_PPC_EARLY_DEBUG.
No need to deselect the others, BTW.
> Does mpc85xx_defconfig not work?
>
> Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the
> menuconfig, but no mpc8544ds.
mpc8544ds is supported by CONFIG_MPC85xx_DS.
-Scott
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Grant Likely @ 2009-12-09 17:46 UTC (permalink / raw)
To: Torsten Fleischer; +Cc: avorontsov
In-Reply-To: <200912091649.19380.to-fleischer@t-online.de>
On Wed, Dec 9, 2009 at 8:49 AM, Torsten Fleischer
<to-fleischer@t-online.de> wrote:
> On Thu, Nov 26, 2009 at 20:17:35, =A0Grant Likely wrote:
> [...]
>> spi-cs-high is definitely not a complete solution, but it isn't
>> actively evil either. =A0Plus 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. =A0All 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. =A0The rework to the driver itself is not ugly.
>>
>
> The following patch adds a function to get the active state of the chip s=
elect
> of a SPI device by looking for the 'spi-cs-high' property in the associat=
ed device
> tree node.
> This function is used by the spi_mpc8xxx driver to set a proper initial v=
alue
> to the associated GPIOs.
>
>
> Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
I like this better. See comments below.
> ---
>
> 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 =A0 =A0 =A02009-12-03 04:51:21=
.000000000 +0100
> +++ linux-2.6.32/drivers/of/of_spi.c =A0 =A02009-12-09 12:37:01.000000000=
+0100
> @@ -10,6 +10,49 @@
> =A0#include <linux/device.h>
> =A0#include <linux/spi/spi.h>
> =A0#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: =A0 =A0 =A0 =A0parent node of the SPI device nodes
> + * @index: =A0 =A0 index/address of the SPI device (refers to the 'reg' =
property)
> + * @cs_active: pointer to return the chip select's active state
> + * =A0 =A0 =A0 =A0 =A0 =A0 (true =3D active high; false =3D 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)
> +{
> + =A0 =A0 =A0 struct device_node *child;
> + =A0 =A0 =A0 const int *prop;
> + =A0 =A0 =A0 int len;
> + =A0 =A0 =A0 bool active =3D 0;
> +
> + =A0 =A0 =A0 /* search for the matching SPI device */
> + =A0 =A0 =A0 for_each_child_of_node(np, child) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 prop =3D of_get_property(child, "reg", &len=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!prop || len < sizeof(*prop)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* property 'reg' not avail=
able (not an error) */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ( *prop =3D=3D index ) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* matching device found */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (of_find_property(child,=
"spi-cs-high", NULL))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 active =3D =
1;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (cs_active)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *cs_active =
=3D active;
A little odd. If cs_active is NULL, then this routine does nothing,
and the caller is entirely defective. Either test at the top of the
function or not at all. Then *cs_active can be assigned directly.
But even then, this function will probably need to be reworked (see
comments below).
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return -ENODEV;
> +}
> +EXPORT_SYMBOL(of_get_spi_cs_active_state);
> +
>
> =A0/**
> =A0* 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/drive=
rs/spi/spi_mpc8xxx.c
> --- linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c =A0 =A0 =A0 =A02009-12-0=
3 04:51:21.000000000 +0100
> +++ linux-2.6.32/drivers/spi/spi_mpc8xxx.c =A0 =A0 =A02009-12-09 12:50:36=
.000000000 +0100
> @@ -705,6 +705,7 @@
> =A0 =A0 =A0 =A0for (; i < ngpios; i++) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int gpio;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enum of_gpio_flags flags;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bool astate;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gpio =3D of_get_gpio_flags(np, i, &flags);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!gpio_is_valid(gpio)) {
> @@ -721,8 +722,15 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pinfo->gpios[i] =3D gpio;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pinfo->alow_flags[i] =3D flags & OF_GPIO_A=
CTIVE_LOW;
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D of_get_spi_cs_active_state(np, i, &=
astate);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "can't get cs =
active state of device "
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "#%d: %d\n"=
, i, ret);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_loop;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
This is a bit heavy handed in that it expects the device tree to be
fully populated with all SPI devices which isn't always a given. For
example a board that has some unpopulated SPI devices could have some
gaps in the GPIO CS layout. If a node can't be found, then just
ignore it silently and move on to the next. I'd do something like
this:
+ astate =3D of_get_spi_cs_active_state(np, i);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D gpio_direction_output(pinfo->gpios[i=
],
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 pinfo->alow_flags[i]);
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 pinfo->alow_flags[i] ^ !astate);
BTW, why the xor? The usage is non-obvious enough that I'd like to
see a comment describing the use case.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
From: Kumar Gala @ 2009-12-09 20:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Scott Wood, Linuxppc-dev Development, Mark Ware
In-Reply-To: <4B1EF3E9.8050005@elphinstone.net>
On Dec 8, 2009, at 6:48 PM, Mark Ware wrote:
> Port C interrupts can be either falling edge, or either edge.
> Other external interrupts are either falling edge or active low.
>=20
> Signed-Off-By: Mark Ware <mware@elphinstone.net>
> ---
> Changed in v2:
> - Disallow rising edge only on Port C=20
>=20
> arch/powerpc/sysdev/cpm2_pic.c | 30 +++++++++++++++++++++++-------
> 1 files changed, 23 insertions(+), 7 deletions(-)
Anton, mind taking a look at this for me.
- k
>=20
> diff --git a/arch/powerpc/sysdev/cpm2_pic.c =
b/arch/powerpc/sysdev/cpm2_pic.c
> index 78f1f7c..eba5f24 100644
> --- a/arch/powerpc/sysdev/cpm2_pic.c
> +++ b/arch/powerpc/sysdev/cpm2_pic.c
> @@ -141,13 +141,29 @@ static int cpm2_set_irq_type(unsigned int virq, =
unsigned int flow_type)
> struct irq_desc *desc =3D get_irq_desc(virq);
> unsigned int vold, vnew, edibit;
>=20
> - if (flow_type =3D=3D IRQ_TYPE_NONE)
> - flow_type =3D IRQ_TYPE_LEVEL_LOW;
> -
> - if (flow_type & IRQ_TYPE_EDGE_RISING) {
> - printk(KERN_ERR "CPM2 PIC: sense type 0x%x not =
supported\n",
> - flow_type);
> - return -EINVAL;
> + /* Port C interrupts are either IRQ_TYPE_EDGE_FALLING or
> + * IRQ_TYPE_EDGE_BOTH (default). All others are =
IRQ_TYPE_EDGE_FALLING
> + * or IRQ_TYPE_LEVEL_LOW (default)
> + */
> + if (src >=3D CPM2_IRQ_PORTC15 && src <=3D CPM2_IRQ_PORTC0) {
> + if (flow_type =3D=3D IRQ_TYPE_NONE)
> + flow_type =3D IRQ_TYPE_EDGE_BOTH;
> +
> + if ((flow_type !=3D IRQ_TYPE_EDGE_BOTH) &&=20
> + (flow_type !=3D IRQ_TYPE_EDGE_FALLING)) {
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not =
supported\n",
> + flow_type);
> + return -EINVAL;
> + }
> + } else {
> + if (flow_type =3D=3D IRQ_TYPE_NONE)
> + flow_type =3D IRQ_TYPE_LEVEL_LOW;
> +
> + if (flow_type & (IRQ_TYPE_EDGE_RISING | =
IRQ_TYPE_LEVEL_HIGH)) {
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not =
supported\n",
> + flow_type);
> + return -EINVAL;
> + }
> }
>=20
> desc->status &=3D ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
> --=20
> 1.5.6.5
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers
From: Kumar Gala @ 2009-12-09 20:51 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, B.J. Buchalter
In-Reply-To: <20091207225435.GA18485@oksana.dev.rtsoft.ru>
On Dec 7, 2009, at 4:54 PM, 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>
> ---
applied to next
- k
^ permalink raw reply
* Re: [RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16
From: Kumar Gala @ 2009-12-09 20:51 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: Scott Wood, linuxppc-dev, Alemao, linux-kernel
In-Reply-To: <20091206113247.GB9937@Chamillionaire.breakpoint.cc>
On Dec 6, 2009, at 5:32 AM, Sebastian Andrzej Siewior wrote:
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> ---
> Documentation/powerpc/dts-bindings/fsl/mpic.txt | 42 =
+++++++++++++++++++++++
> 1 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt
applied to next
- k=
^ permalink raw reply
* Re: [RFC PATCH 2/5] mcu_mpc8349emitx: port to new of gpio interface
From: Kumar Gala @ 2009-12-09 21:16 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Dmitry Eremin-Solenikov, Linuxppc-dev Development,
devicetree-discuss, David Brownell, Paul Mackerras
In-Reply-To: <1258472546-31343-3-git-send-email-dbaryshkov@gmail.com>
On Nov 17, 2009, at 9:42 AM, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
Minding reviewing for me.
- k
>=20
> diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c =
b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
> index 82a9bcb..4ba8b16 100644
> --- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
> +++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
> @@ -36,7 +36,7 @@ struct mcu {
> struct mutex lock;
> struct device_node *np;
> struct i2c_client *client;
> - struct of_gpio_chip of_gc;
> + struct gpio_chip gc;
> u8 reg_ctrl;
> };
>=20
> @@ -55,8 +55,7 @@ static void mcu_power_off(void)
>=20
> static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int =
val)
> {
> - struct of_gpio_chip *of_gc =3D to_of_gpio_chip(gc);
> - struct mcu *mcu =3D container_of(of_gc, struct mcu, of_gc);
> + struct mcu *mcu =3D container_of(gc, struct mcu, gc);
> u8 bit =3D 1 << (4 + gpio);
>=20
> mutex_lock(&mcu->lock);
> @@ -78,8 +77,8 @@ static int mcu_gpio_dir_out(struct gpio_chip *gc, =
unsigned int gpio, int val)
> static int mcu_gpiochip_add(struct mcu *mcu)
> {
> struct device_node *np;
> - struct of_gpio_chip *of_gc =3D &mcu->of_gc;
> - struct gpio_chip *gc =3D &of_gc->gc;
> + struct gpio_chip *gc =3D &mcu->gc;
> + struct of_gpio_chip *of_gc =3D &gc->of_gc;
> int ret;
>=20
> np =3D of_find_compatible_node(NULL, NULL, =
"fsl,mcu-mpc8349emitx");
> @@ -113,7 +112,7 @@ static int mcu_gpiochip_remove(struct mcu *mcu)
> {
> int ret;
>=20
> - ret =3D gpiochip_remove(&mcu->of_gc.gc);
> + ret =3D gpiochip_remove(&mcu->gc);
> if (ret)
> return ret;
> of_node_put(mcu->np);
> --=20
> 1.6.5
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/4] mpc8349emitx: add gpio controller declarations
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1258379934-32352-2-git-send-email-dbaryshkov@gmail.com>
On Nov 16, 2009, at 7:58 AM, Dmitry Eremin-Solenikov wrote:
> mpc8349 bears two GPIO controllers. Enable support for them.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/4] mpc8349emitx: populate I2C busses
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1258379934-32352-3-git-send-email-dbaryshkov@gmail.com>
On Nov 16, 2009, at 7:58 AM, Dmitry Eremin-Solenikov wrote:
> Add OF descriptions of EEPROM, two GPIO extenders and SPD hanging on I2C
> on this board.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: add OF descriptions of LocalBus devices
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20091116205120.GA22074@doriath.ww600.siemens.net>
On Nov 16, 2009, at 2:51 PM, Dmitry Eremin-Solenikov wrote:
> Describe all LocalBus chipselects on MPC8349E-MITX board. Also add flash
> bindings.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 21 ++++++++++++++++++++-
> 1 files changed, 20 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 4/4] mpc8349emitx: add leds-gpio binding
From: Kumar Gala @ 2009-12-09 21:17 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linuxppc-dev
In-Reply-To: <1258379934-32352-5-git-send-email-dbaryshkov@gmail.com>
On Nov 16, 2009, at 7:58 AM, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [RFC PATCH 2/5] mcu_mpc8349emitx: port to new of gpio interface
From: Anton Vorontsov @ 2009-12-09 21:32 UTC (permalink / raw)
To: Kumar Gala
Cc: Dmitry Eremin-Solenikov, Linuxppc-dev Development,
devicetree-discuss, David Brownell, Paul Mackerras
In-Reply-To: <6C061449-ACBE-4C51-9101-007DFD285F55@kernel.crashing.org>
On Wed, Dec 09, 2009 at 03:16:37PM -0600, Kumar Gala wrote:
> On Nov 17, 2009, at 9:42 AM, Dmitry Eremin-Solenikov wrote:
>
> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > ---
> > arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 11 +++++------
> > 1 files changed, 5 insertions(+), 6 deletions(-)
>
> Minding reviewing for me.
The whole approach was reviewed, and rejected.
http://lists.ozlabs.org/pipermail/devicetree-discuss/2009-November/001330.html
and
http://lists.ozlabs.org/pipermail/devicetree-discuss/2009-November/001328.html
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
From: Anton Vorontsov @ 2009-12-09 21:53 UTC (permalink / raw)
To: Mark Ware; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <4B1EF3E9.8050005@elphinstone.net>
On Wed, Dec 09, 2009 at 11:48:41AM +1100, Mark Ware wrote:
> Port C interrupts can be either falling edge, or either edge.
> Other external interrupts are either falling edge or active low.
>
> Signed-Off-By: Mark Ware <mware@elphinstone.net>
Looks correct (checked with 8272 and 8555 specs).
Reviewed-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cosmetic nitpicks below. I tend to think they don't desire
another resend, but I couldn't resist making them anyway. ;-)
[...]
> + if (src >= CPM2_IRQ_PORTC15 && src <= CPM2_IRQ_PORTC0) {
> + if (flow_type == IRQ_TYPE_NONE)
> + flow_type = IRQ_TYPE_EDGE_BOTH;
> +
> + if ((flow_type != IRQ_TYPE_EDGE_BOTH) &&
> + (flow_type != IRQ_TYPE_EDGE_FALLING)) {
I'd place one more tab here. And parenthesis aren't actually needed.
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not supported\n",
> + flow_type);
> + return -EINVAL;
> + }
> + } else {
> + if (flow_type == IRQ_TYPE_NONE)
> + flow_type = IRQ_TYPE_LEVEL_LOW;
> +
> + if (flow_type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)) {
> + printk(KERN_ERR "CPM2 PIC: sense type 0x%x not supported\n",
> + flow_type);
pr_err is shorter. Also, this message is duplicated. Would be better
to do something like:
if (somethingwrong)
goto err_sense;
...
return 0;
err_sense:
pr_err("CPM2 PIC: sense type 0x%x not supported\n", flow_type);
return -EINVAL;
}
Or we may don't print any errors at all. For internal interrupts
we don't print them anyway, i.e. the current code has just
return (flow_type & IRQ_TYPE_LEVEL_LOW) ? 0 : -EINVAL;
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Dominik Brodowski @ 2009-12-09 21:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci, linux-kernel@vger.kernel.org, Jesse Barnes, blofeldus,
Olof Johansson, linuxppc-dev
In-Reply-To: <1260341533.16132.20.camel@pasglop>
Hey Benjamin,
On Wed, Dec 09, 2009 at 05:52:13PM +1100, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> (for PCMCIA)
> Note: In the long run we might want to streamline the hooks for fixing
> up new devices vs. new busses and make some stuff common between cardbus
> and PCI hotplug which is actually a mess.
... though I'd prefer such a generic approach.
Best,
Dominik
^ permalink raw reply
* Re: [PATCH v2] cpm2_pic: Allow correct flow_types for port C interrupts
From: Scott Wood @ 2009-12-09 21:57 UTC (permalink / raw)
To: avorontsov; +Cc: Linuxppc-dev Development, Mark Ware
In-Reply-To: <20091209215334.GA536@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
>> + if ((flow_type != IRQ_TYPE_EDGE_BOTH) &&
>> + (flow_type != IRQ_TYPE_EDGE_FALLING)) {
>
> I'd place one more tab here.
Or better, align one "flow_type" with the other.
-Scott
^ permalink raw reply
* Deprecating of_platform, the path from here...
From: Grant Likely @ 2009-12-09 22:06 UTC (permalink / raw)
To: devicetree-discuss, Benjamin Herrenschmidt, Josh Boyer,
Jeremy Kerr, Segher Boessenkool, Paul Mackerras, linuxppc-dev,
David Miller
Hi all,
This is a summary of a discussion we had on #mklinux last night.
On PowerPC, SPARC and Microblaze, most system (non-discoverable)
devices are registered on the of_platform bus. In the rest of the
kernel, the same kind of devices are registered on the platform bus.
The of_platform and platform busses essentially perform the same task;
proved a method for platform code to register a device that will be
bound to a driver at a later point in time. The most significant
difference is that the of_platform bus understands how probe drivers
The OF Way using the 'compatible' property. In the OF way, more than
one driver could match the device and the OS is responsible to choose
the best one.
The platform bus only supports matching a device to a driver based on
the device's name. It has no mechanism for capturing the OF binding
model.
Maintaining of_platform comes at a cost. Many device drivers end up
with two bus bindings, both of_platform_driver and platform_driver.
In practice this means a bunch of duplicated boilerplate and some ugly
#ifdef blocks. Device driver authors don't seem thrilled to have
of_platform stuff "invade" their platform drivers. Also, the
of_platform/platform split doesn't match the pattern used for other
bus subsystems (i2c, spi, mdio, etc). On other busses, the same
driver is used regardless of whether the device was allocated
statically in platform code, obtained from the device tree, or
something else entirely.
So, the desire is to deprecate of_platform bus and use platform bus
for system devices in the device tree. However, doing this requires
two problems to be solved:
1) device to driver matching - Given an OF style compatible list, how
is the device matched to the correct platform driver?
2) data translation - how and where is the device tree data
transformed into something usable by the platform driver?
The 2nd problem is the easy one to solve. In most cases, any code to
translate device tree data into a driver platform_data structure is
driver specific. A hook can be added to the top of the driver's
.probe() routine. If no pdata pointer is set in the driver structure,
then it can call out to a helper function to create one from the
device tree data. Something along the lines of:
pdata = pdev->dev.platform_data;
if (!pdata)
pdata = pdriver_get_of_pdata(pdev);
It makes sense for this code to be called from the driver itself so
that the translation code only gets run when the device is actually
used. By running the translators at probe time (instead of device
registration time) it means the translators don't need to be built
into the kernel. On a kernel config with a lot of of-enabled drivers
this would be significant.
To solve the 1st problem the possibility was discussed is to add
compatible list parsing to both the platform bus and modutils. Doing
so would make it easy to create platform devices from nodes in the
device tree, but it would be hard to get 'right'. There is a risk
that it would break existing modutils (completely unacceptable). It
is unclear how to make sure Linux probes the correct driver. ie. If
a compatible driver is loaded, but a 'better' driver is available,
then how is the kernel prevented from binding against the 'worse'
driver before the better driver is loaded? Finally, while it may
solve the problem for the platform bus, the exact same problem needs
to also be solved for i2c, spi, mdio, etc.
In the end, the decision was to just use a simple lookup table of
compatible values to driver names. When registering devices, platform
code will use the table to choose the best name. Existing platform
devices can then bind against them as-is. The downside is that the
table must be statically compiled into the kernel. However, the
solution is simple and the table can probably be put into an initdata
section to be discarded after boot. At a later date something more
sophisticated can be designed.
So, to summarize the decisions made:
1) of_platform will be deprecated in preference of the platform bus.
2) platform code will register platform devices at boot time
- A lookup table will be used to translate 'compatible' values to
driver names used by the kernel
- If no suitable compatible values exist in the table, then choose a
name programatically (ie. of_modalias_node()). Userspace can force
bind to a driver after boot if desirable.
- helper functions to be written to make registration simple (ie.
of_platform_bus_probe())
- helper functions will fill in common resources (memory ranges and
irqs) but leave complex stuff to the driver
3) platform drivers will probe the same way they are probed now. No
changes to the platform bus.
4) If drivers needs extra platform_data, then a call will be added to
the top of the .probe() hook to go and create one.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: dts file for MPC8343EA - cuImage doesn't boot , but uImage with DTS shows serial output
From: Junita Ajith @ 2009-12-09 22:08 UTC (permalink / raw)
To: Lee, Eric; +Cc: Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <507B57E36B7C3A48BD1B90EFA80A782E5372EE795D@GVW0433EXB.americas.hpqcorp.net>
[-- Attachment #1: Type: text/plain, Size: 19528 bytes --]
Eric,
1. I did try building with MDS configuration.
2. Removed BCSR section
3. Set u-boot environment variable.
The code boots up in the MPC8349 reference platform and not in the custom
board.
Also I am wondering why the cuImage would not give out any serial output
even, whereas I do see serial out with DTB file passed from u-boot?!!
Screen-shot:
==========
Bytes transferred = 12288 (3000 hex)
SC3000> bootm 0x2000000 - 0x3000000
## Booting image at 02000000 ...
Image Name: Linux-2.6.27.18
Created: 2009-12-09 21:57:32 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1464261 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 ... 0x007FFF25
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
Skipping initrd
Booting using the fdt at 0x3000000
No initrd
## device tree at 0x03000000 ... 0x03002FFF (len=12288=0x3000)
Loading Device Tree to 007fc000, end 007fefff ... OK
Updating property '/soc8349@e0000000/ethernet@24000/mac-address' = 00 e0 0c
00 81Updating property '/soc8349@e0000000/ethernet@24000/local-mac-address'
= 00 e0 01Updating 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 MDS machine description
Linux version 2.6.27.18 (root@localhost.localdomain) (gcc version 4.1.2) #4
Wed D9Found legacy serial port 0 for /soc8349@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=266666664, speed=0
Found legacy serial port 1 for /soc8349@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=266666664, speed=0
console [udbg0] enabled
setup_arch: bootmem
mpc834x_mds_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number:
0->0
PCI host bridge /pci@e0008500 (primary) ranges:
MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
IO 0x00000000e2000000..0x00000000e20fffff -> 0x0000000000000000
Found MPC83xx PCI host bridge at 0x00000000e0008600. Firmware bus number:
0->0
PCI host bridge /pci@e0008600 ranges:
MEM 0x00000000b0000000..0x00000000bfffffff -> 0x00000000b0000000
MEM 0x00000000a0000000..0x00000000afffffff -> 0x00000000a0000000 Prefetch
IO 0x00000000e2100000..0x00000000e21fffff -> 0x0000000000000000
arch: exit
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
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
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c02ed470, node_mem_map c030f180
DMA zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram rw console=ttyS0,115200
IPIC (128 IRQ sources) at fddfa700
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 66.666666 MHz
time_init: processor frequency = 399.999996 MHz
clocksource: timebase mult[3c00001] shift[22] registered
clockevent: decrementer mult[1111] shift[16] cpu[0]
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
On 12/9/09, Lee, Eric <eric.lee@hp.com> wrote:
>
> two things; I had better luck with the mpc8349mds (? don’t remember exact
> file name) dts as opposed to the itx. I had to remove the bcsr section or
> else the kernel hung during initialization . also, your u-boot is not
> passing the correct kernel commandline:
>
>
>
> “Kernel command line: root=/dev/nfs rw nfsroot=192.168.200.230:/nfsroot/rootfs
> i0IPIC (128 IRQ sources) at fdffc700”
>
>
>
> you’re trying to run a ramdisk and with tty I expect:
>
>
>
> “root=/dev/ram rw console=ttyS0,115200 “
>
>
>
> check your environment variable bootargs in u-boot
>
>
>
>
>
>
>
> *From:* Junita Ajith [mailto:ajijuni@gmail.com]
> *Sent:* Wednesday, December 09, 2009 10:58 AM
> *To:* Lee, Eric
> *Cc:* Linuxppc-dev@lists.ozlabs.org
> *Subject:* dts file for MPC8343EA - cuImage doesn't boot , but uImage with
> DTS shows serial output
>
>
>
> 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: 24569 bytes --]
^ 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