* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Paul Jackson @ 2008-02-08 18:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linuxppc-dev, paulus, akpm, tglx
In-Reply-To: <alpine.LFD.1.00.0802071449240.2896@woody.linux-foundation.org>
Linus wrote:
> Please, when mentioning hex numbers, also do the one-liner shortlog.
> ...
> without _requiring_ people to be git users to get the gist of the
> matter, ok?
Thanks for sticking up for us git-challenged contributors.
Can anyone point me at instructions providing the shortest
path for getting from one of those git hex numbers to the
log or change it represents, for non-git users?
Or do those instructions begin with a first step of:
1. become a git user
2. ...
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
^ permalink raw reply
* Re: [PATCH 02/18] ide: fix ide_find_port()
From: Sergei Shtylyov @ 2008-02-08 17:23 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004434.17746.33986.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> * Instead of checking for '->io_ports[IDE_DATA_OFFSET] == 0' check for
> '->chipset == ide_unknown' when looking for an empty ide_hwifs[] slot.
> * Do ide-pnp initialization after ide-generic when IDE is built-in
> (ide-pnp is the only user of ide_find_port() which needs such fixup).
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 08/18] ide: move ide_port_setup_devices() call to ide_device_add_all()
From: Sergei Shtylyov @ 2008-02-08 17:20 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004516.17746.18498.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> Add ide_cfg_mtx lock/unlock to ide_port_setup_devices() and then move
> ide_port_setup_devices() call from init_irq() to ide_device_add_all().
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 05/18] ide: factor out cable detection from ide_init_port()
From: Sergei Shtylyov @ 2008-02-08 17:18 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004455.17746.44570.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> * Factor out cable detection from ide_init_port() to ide_port_cable_detect().
> * Move ide_port_cable_detect() call to ide_device_add_all().
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] MTD support for the AMCC Taishan
From: Stefan Roese @ 2008-02-08 14:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200802081527.28771.sr@denx.de>
On Friday 08 February 2008, Stefan Roese wrote:
> > + partition@380000 {
> > + label = "user";
> > + reg = <380000 3a80000>;
> > + };
> > + partition@3e00000 {
> > + label = "kozio";
> > + reg = <3e00000 140000>;
> > + };
>
> Please remove the kozio partition from this list. It's not used/supported
> anymore.
And please extend the "user" partition accordingly.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] MTD support for the AMCC Taishan
From: Stefan Roese @ 2008-02-08 14:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <120203530465-git-send-email-kaloz@openwrt.org>
On Sunday 03 February 2008, Imre Kaloz wrote:
> Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
> ---
> arch/powerpc/boot/dts/taishan.dts | 33 +++++++++++-
> arch/powerpc/configs/taishan_defconfig | 89
> ++++++++++++++++++++++++++++++-- 2 files changed, 116 insertions(+), 6
> deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/taishan.dts
> b/arch/powerpc/boot/dts/taishan.dts index 0706a4a..28c14dd 100644
> --- a/arch/powerpc/boot/dts/taishan.dts
> +++ b/arch/powerpc/boot/dts/taishan.dts
> @@ -174,7 +174,38 @@
> interrupts = <5 4>;
> interrupt-parent = <&UIC1>;
>
> - /* TODO: Add other EBC devices */
> + nor_flash@0,0 {
> + compatible = "cfi-flash";
> + bank-width = <4>;
> + device-width = <2>;
> + reg = <0 000000 4000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "kernel";
> + reg = <0 180000>;
> + };
> + partition@180000 {
> + label = "root";
> + reg = <180000 200000>;
> + };
> + partition@380000 {
> + label = "user";
> + reg = <380000 3a80000>;
> + };
> + partition@3e00000 {
> + label = "kozio";
> + reg = <3e00000 140000>;
> + };
Please remove the kozio partition from this list. It's not used/supported
anymore.
Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* [Virtex 4 PPC] Problem mountin rootfs via NFS
From: IngoM @ 2008-02-08 14:11 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
in the meantime, I get up my toolchain and an linux-kernel from xilinx
git-repository.
Hardware is an FX12 Mini-Module form AVNET, standard design with LL-TEMAC,
EDK 9.2.
Kernel boots fine till he try to mount his rootfs via NFS. NFS is working
correctly, probed with some other maschines. Some times kernel can mount
NFS, somtimes kernel panics trying this.
I already try some additional parameters found here on the list like
"tcp,no_lock" but didn't help. Also probed direct connection, connection via
a 100 MBit switch. No success.
Another thing I tried is set ip=dhcp, the device find our DHCP-Server and
gets an address. So I think network should ok, but where comes the NFS
trouble from?
Best Regards,
Ingo Maindorfer
The boot messages from console:
loaded at: 00400000 0052E19C
board data at: 0052C120 0052C19C
relocated to: 0040409C 00404118
zimage at: 00404F13 0052BDE3
avail ram: 0052F000 02000000
Linux/PPC load: console=ttyUL0,19200
ip=10.82.2.234:10.82.2.103:10.82.2.4:255.255.255.0
nfsroot=10.82.2.103:/tftpboot
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.24-rc8-xlnx-g8a6d0b1a-dirty (ingo@messstrecke) (gcc
version 3.4.5) #24 PREEMPT Fri Feb 8 14:21:06 CET 2008
Xilinx Generic PowerPC board support package (Xilinx ML40
Zone PFN ranges:ilinx_lltemac.0:
DMA 0 -> 8192
Normal 8192 -> 8192lTemac: Dma base address: phy:
HighMem 8192 -> 81927c
Movable zone start PFN for each node
et
XLlTemac: buffer descriptor s
early_node_map[1] active PFN ranges_table+0x64/0xe44 (order: 0, 40
0: 0 -> 8192
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
with kmalloc<6>XLlTemac: (buffer_descriptor
Kernel command line: console=ttyUL0,19200
ip=10.82.2.234:10.82.2.103:10.82.2.4:255.255.255.0
nfsroot=10.82.2.103:/tftpboot
_init) phy: 0x1c98000, virt: 0xc1c98000, size: 0x8000
TCP estab
Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
XTemac: PHY detected at address 4.
PID hash table entries: 128 (order: 7, 512 bytes)
eth0: Dropping NETIF_F_SG sin
Memory: 29820k available (1940k kernel code, 600k data, 104k init, 0k
highmem)
eth0: XLlTemac: allocating interrupt 1 f
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1,
Nodes=1LlTemac:
eth0: XLlTemac: Not able to set the speed to 1000 (st
Mount-cache hash table entries: 512
net_namespace: 64 bytesLlTemac: We renegotiate
NET: Registered protocol family 16
Registering device uartlite:0ltemac.0: eth0:
Registering device xilinx_lltemac:0mac: speed set to 100Mb/s 0xC3Send
NET: Registered protocol family 2
TCP reno registeredmac: allocating int
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy4k init
eth0: XLlTemac:
Call Trace:o
[c1c0fe60] [c0008e68] show_stack+0x40/0x194 (unreliable)sole.
IP-Con
[c1c0fe90] [c0036414] set_fail+0x68/0x80nk carrier restored.
[c1c0feb0] [c0036a2c] sysctl_check_table+0x600/0x77c
-- Entering main() --ask=255.255.255.0, gw
[c1c0fef0] [c0036a14] sysctl_c
[c1c0fff0] [c0004e78] kernel_thread+0x44/0x60ver=1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).rnel memory: 104k i
io scheduler noop registeredLinux/PPC load: console=ttyU
io scheduler cfq registered (default).82.2.4:255.25e to open an initial co
uartlite.0: ttyUL0 at MMIO 0x84000003 (irq = 3) is a uartlite
Lookin
console [ttyUL0] enabled82.2.75:/tftpboot82.
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
DMA 0 -> 819210.82.2
Built 1
XLlTemac: Allocating DMA descriptors with kmalloc<6>XLlTemac:
(buffer_descriptor_init) phy: 0x1c90000, virt: 0xc1c90000, size: 0x800
55.255.255.0 nfsroot=10.82.2.75:/tftpboot######################
0
XTemac: PHY detected at address 4. #0 at 0x81800000 mapped to 0xFDFF
eth0: Dropping NETIF_F_SG since no checksum feature.
PID
xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC a
RPC: Registered udp transport module.AC
RPC: Registered tcp transport module.s: 2048 (order: 1, 8192 bytes)8192
eth0: XLlTemac: allocating interrupt 0 for dma mode tx.
eth0: XLlTemac: allocating interrupt 1 for dma mode rx.
eth0: XLlTemac: We renegotiated the speed to: 1000
eth0: XLlTemac: speed set to 1000Mb/s
eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
IP-Config: Complete:
device=eth0, addr=10.82.2.234, mask=255.255.255.0, gw=10.82.2.4,
host=10.82.2.234, domain=, nis-domain=(none),
bootserver=10.82.2.103, rootserver=10.82.2.103, rootpath=
Looking up port of RPC 100003/2 on 10.82.2.103
Looking up port of RPC 100005/1 on 10.82.2.103
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 104k init
Warning: unable to open an initial console.
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 OK
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 OK
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 OK
nfs: server 10.82.2.103 OK
wireshark spite out this (.103 NFS-Server, .234 Xilinx):
"22","7.482314000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
25), FH:0xb29d0d7b Offset:16384 Count:4096 TotalCount:4096"
"23","7.482411000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #25]"
"24","7.482416000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #25]"
"25","7.482418000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
22)"
"26","8.581527000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
29), FH:0xb29d0d7b Offset:8192 Count:4096 TotalCount:4096"
"27","8.581608000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #29]"
"28","8.581612000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #29]"
"29","8.581615000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
26)"
"30","8.585120000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
33), FH:0xb29d0d7b Offset:12288 Count:4096 TotalCount:4096"
"31","8.585160000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #33]"
"32","8.585164000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #33]"
"33","8.585166000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
30)"
"34","8.593065000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission of
#22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"35","8.593109000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #37]"
"36","8.593113000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #37]"
"37","8.593115000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"38","8.607327000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
39), FH:0xb29d0d7b Offset:20480 Count:896 TotalCount:896"
"39","8.607363000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
38)"
"54","10.807186000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #38]V2 READ Call (Reply In 39), FH:0xb29d0d7b Offset:20480 Count:896
TotalCount:896"
"55","10.807248000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#39]V2 READ Reply (Call In 38)"
"60","13.012339000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"61","13.012483000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #63]"
"62","13.012489000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #63]"
"63","13.012492000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"65","14.111614000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"66","14.111699000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #68]"
"67","14.111705000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #68]"
"68","14.111707000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"71","16.311259000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"72","16.311360000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #74]"
"73","16.311366000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #74]"
"74","16.311368000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"75","16.322672000","10.82.2.234","10.82.2.103","NFS","V2 GETATTR Call
(Reply In 76), FH:0x00bdec42"
"76","16.322705000","10.82.2.103","10.82.2.234","NFS","V2 GETATTR Reply
(Call In 75)"
"77","16.326131000","10.82.2.234","10.82.2.103","NFS","V2 LOOKUP Call (Reply
In 78), DH:0x529ded7b/libc.so.6"
"78","16.326167000","10.82.2.103","10.82.2.234","NFS","V2 LOOKUP Reply (Call
In 77), FH:0x569de97b"
"79","16.329608000","10.82.2.234","10.82.2.103","NFS","V2 READLINK Call
(Reply In 80), FH:0x569de97b"
"80","16.329654000","10.82.2.103","10.82.2.234","NFS","V2 READLINK Reply
(Call In 79) Path:libc-2.3.6.so"
"81","16.332969000","10.82.2.234","10.82.2.103","NFS","V2 LOOKUP Call (Reply
In 82), DH:0x529ded7b/libc-2.3.6.so"
"82","16.332993000","10.82.2.103","10.82.2.234","NFS","V2 LOOKUP Reply (Call
In 81), FH:0x529ded7b"
"83","16.336586000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply
In 86), FH:0x529ded7b Offset:0 Count:4096 TotalCount:4096"
"84","16.336620000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #86]"
"85","16.336625000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #86]"
"86","16.336627000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call
In 83)"
"87","16.336815000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply
In 90), FH:0x529ded7b Offset:4096 Count:4096 TotalCount:4096"
"88","16.336845000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #90]"
"89","16.336850000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #90]"
"90","16.336852000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call
In 87)"
"168","31.034419000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #83]V2 READ Call (Reply In 86), FH:0x529ded7b Offset:0 Count:4096
TotalCount:4096"
"169","31.034530000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=0) [Reassembled in #171]"
"170","31.034535000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=1480) [Reassembled in #171]"
"171","31.034537000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#86]V2 READ Reply (Call In 83)"
"193","32.133681000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #87]V2 READ Call (Reply In 90), FH:0x529ded7b Offset:4096 Count:4096
TotalCount:4096"
"194","32.133823000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=0) [Reassembled in #196]"
"195","32.133828000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=1480) [Reassembled in #196]"
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Problem-mountin-rootfs-via-NFS-tp15355858p15355858.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely @ 2008-02-08 14:07 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, jwboyer, scottwood,
stephen.neuendorffer
In-Reply-To: <20080208110219.GC27955@localhost.localdomain>
On Feb 8, 2008 4:02 AM, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> > + /* Make sure FDT blob is sane */
> > + if (fdt_check_header(_dtb_start) != 0)
> > + fatal("Invalid device tree blob\n");
>
> I think most of these fatal()s are pretty pointless. This is
> platform_init(), so the console won't even have been initialized to
> actually print any of the messages. Precisely because this is
> simpleboot, in which every bit of information the wrapper has comes
> from teh device tree, if the provided blob is so bad as to fail these
> basic tests, we're totally stuffed anyway. It'll take a hardware
> debugger to track down, and I don't think the fatal()s will actually
> help much at that point.
heh; very true. I'll kill them.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Leds
From: Simon Kagstrom @ 2008-02-08 11:26 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47AC324D.1050503@coritel.it>
On Fri, 08 Feb 2008 11:43:25 +0100
Marco Stornelli <marco.stornelli@coritel.it> wrote:
> > Although I'm not sure if it's the "standard" way, we just added a
> > "home-made" node like this:
> >
> > resetLED@c0018000 {
> > device_type = "leds";
> > compatible = "reset-leds";
> > reg = <c0018000 00008000>;
> > };
> >
> Thanks. In this case where have you added the device registration? In
> the probe function? Have you registered the driver with
> of_register_platform_driver()?
We put it in the module init function and registered it as a platform
device:
static int __init led_init(void)
{
int ret;
ret = platform_driver_register(&led_driver);
if (ret < 0)
return -ENODEV;
pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0);
if (IS_ERR(pdev)) {
ret = PTR_ERR(pdev);
platform_driver_unregister(&led_driver);
}
return ret;
}
And just use the device tree stuff to read out the device address. The
driver itself is quite similar to other led drivers found in the same
directory, so you can probably base your work on those.
This was for kernel 2.6.21, I'm not sure if these things have changed
for newer kernels (although I would guess most of it is the same).
// Simon
^ permalink raw reply
* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: David Gibson @ 2008-02-08 11:02 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20080202065517.12920.20235.stgit@trillian.secretlab.ca>
On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
[snip]
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> + unsigned long r6, unsigned long r7)
> +{
> + const u32 *na, *ns, *reg, *timebase;
> + u64 memsize64;
> + int node, size, i;
> +
> + /* Allocate initial heap for probing the tree */
> + simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
> +
> + /* Make sure FDT blob is sane */
> + if (fdt_check_header(_dtb_start) != 0)
> + fatal("Invalid device tree blob\n");
I think most of these fatal()s are pretty pointless. This is
platform_init(), so the console won't even have been initialized to
actually print any of the messages. Precisely because this is
simpleboot, in which every bit of information the wrapper has comes
from teh device tree, if the provided blob is so bad as to fail these
basic tests, we're totally stuffed anyway. It'll take a hardware
debugger to track down, and I don't think the fatal()s will actually
help much at that point.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Leds
From: Simon Kagstrom @ 2008-02-08 10:20 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47AC28A8.5030609@coritel.it>
Hi Marco,
On Fri, 08 Feb 2008 11:02:16 +0100
Marco Stornelli <marco.stornelli@coritel.it> wrote:
> how can specify a led device in a dts file? These leds are connected
> with gpio to the microprocessor. I can't find anything like a led node
> in the dts files of the other boards. Have you got any suggestions?
Although I'm not sure if it's the "standard" way, we just added a
"home-made" node like this:
resetLED@c0018000 {
device_type = "leds";
compatible = "reset-leds";
reg = <c0018000 00008000>;
};
and then just get the info in the probe function for the led driver
we placed in drivers/leds/:
/* Get device info from OF tree */
np = of_find_compatible_node(NULL, "leds", "reset-leds");
if (!np) {
dev_err(&pdev->dev, "Could not find device tree node for reset-leds\n");
goto error_classdev;
}
if (of_address_to_resource(np, 0, &res)) {
dev_err(&pdev->dev, "Could not convert reset-leds device tree address\n");
of_node_put(np);
goto error_classdev;
}
...
At least this was all the information we needed from the device tree.
// Simon
^ permalink raw reply
* Re: Leds
From: Marco Stornelli @ 2008-02-08 10:43 UTC (permalink / raw)
To: LinuxPPC-Embedded
In-Reply-To: <20080208112002.42a15c0d@seasc0532.dyn.rnd.as.sw.ericsson.se>
Simon Kagstrom ha scritto:
> Hi Marco,
>
> On Fri, 08 Feb 2008 11:02:16 +0100
> Marco Stornelli <marco.stornelli@coritel.it> wrote:
>
>> how can specify a led device in a dts file? These leds are connected
>> with gpio to the microprocessor. I can't find anything like a led node
>> in the dts files of the other boards. Have you got any suggestions?
>
> Although I'm not sure if it's the "standard" way, we just added a
> "home-made" node like this:
>
> resetLED@c0018000 {
> device_type = "leds";
> compatible = "reset-leds";
> reg = <c0018000 00008000>;
> };
>
> and then just get the info in the probe function for the led driver
> we placed in drivers/leds/:
>
> /* Get device info from OF tree */
> np = of_find_compatible_node(NULL, "leds", "reset-leds");
> if (!np) {
> dev_err(&pdev->dev, "Could not find device tree node for reset-leds\n");
> goto error_classdev;
> }
>
> if (of_address_to_resource(np, 0, &res)) {
> dev_err(&pdev->dev, "Could not convert reset-leds device tree address\n");
> of_node_put(np);
> goto error_classdev;
> }
> ...
>
> At least this was all the information we needed from the device tree.
>
> // Simon
>
Thanks. In this case where have you added the device registration? In
the probe function? Have you registered the driver with
of_register_platform_driver()?
^ permalink raw reply
* Leds
From: Marco Stornelli @ 2008-02-08 10:02 UTC (permalink / raw)
To: LinuxPPC-Embedded
Hi all,
how can specify a led device in a dts file? These leds are connected
with gpio to the microprocessor. I can't find anything like a led node
in the dts files of the other boards. Have you got any suggestions?
Regards,
Marco
^ permalink raw reply
* Please pull powerpc.git for-2.6.25 branch
From: Paul Mackerras @ 2008-02-08 9:56 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git for-2.6.25
to get some bug-fixes for powerpc (1 for powermac and 8 for Cell),
plus 3 commits from Badari Pulavarty that implement memory hot-remove
for 64-bit powerpc. These 3 commits have been signed-off by Andrew
Morton. One of them touches generic code (kernel/resource.c), and it
has been acked by KAMEZAWA Hiroyuki.
Thanks,
Paul.
arch/powerpc/Kconfig | 6 +++
arch/powerpc/mm/mem.c | 33 +++++++++++++++
arch/powerpc/platforms/cell/iommu.c | 48 +++++++++++++----------
arch/powerpc/platforms/cell/spufs/backing_ops.c | 6 +++
arch/powerpc/platforms/cell/spufs/fault.c | 12 ++----
arch/powerpc/platforms/cell/spufs/file.c | 49 ++++++++++++++---------
arch/powerpc/platforms/cell/spufs/run.c | 21 ++++++----
arch/powerpc/platforms/cell/spufs/spufs.h | 5 ++
arch/powerpc/platforms/powermac/feature.c | 11 +++++
drivers/macintosh/smu.c | 25 +++++++++++-
include/asm-powerpc/pmac_feature.h | 8 ++++
kernel/resource.c | 2 -
12 files changed, 166 insertions(+), 60 deletions(-)
Badari Pulavarty (3):
[POWERPC] Add remove_memory() for 64-bit powerpc
[POWERPC] Enable hotplug memory remove for 64-bit powerpc
[POWERPC] Add arch-specific walk_memory_remove() for 64-bit powerpc
Benjamin Herrenschmidt (1):
[POWERPC] Disable G5 NAP mode during SMU commands on U3
Christoph Hellwig (1):
[POWERPC] spufs: Fix state_mutex leaks
Luke Browning (2):
[POWERPC] spufs: No need to have a runnable SPU for libassist update
[POWERPC] spufs: Fix timing dependent false return from spufs_run_spu
Masato Noguchi (1):
[POWERPC] spufs: Update SPU_Status[CISHP] in backing runcntl write
Michael Ellerman (4):
[POWERPC] Fix cell IOMMU null pointer explosion on old firmwares
[POWERPC] Don't enable cell IOMMU fixed mapping if there are no dma-ranges
[POWERPC] Fix potential cell IOMMU bug when switching back to default DMA ops
[POWERPC] Make cell IOMMU fixed mapping printk more useful
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Jiri Slaby @ 2008-02-08 9:10 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080208021747.92253161805C@mail10-sin.bigfish.com>
On 02/08/2008 03:17 AM, Stephen Neuendorffer wrote:
> This includes code for new fifo-based xps_hwicap in addition to the
> older opb_hwicap, which has a significantly different interface. The
> common code between the two drivers is largely shared.
>
> Significant differences exists between this driver and what is
> supported in the EDK drivers. In particular, most of the
> architecture-specific code for reconfiguring individual FPGA resources
> has been removed. This functionality is likely better provided in a
> user-space support library. In addition, read and write access is
> supported. In addition, although the xps_hwicap cores support
> interrupt-driver mode, this driver only supports polled operation, in
> order to make the code simpler, and since the interrupt processing
> overhead is likely to slow down the throughput under Linux.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> Fixed to add mutexes, and a few style issues.
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> The final update to xilinx_hwicap.h was missing.
>
> fix some missing __user tags and incorrect section tags.
> convert semaphores to mutexes.
> make probed_devices re-entrancy and error condition safe.
> fix some backwards memcpys.
> some other minor cleanups.
Looks good to me.
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> ---
[...]
> diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> new file mode 100644
> index 0000000..2caac31
> --- /dev/null
> +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> @@ -0,0 +1,923 @@
[...]
> +module_param(xhwicap_major, int, S_IRUGO);
> +module_param(xhwicap_minor, int, S_IRUGO);
> +
> +/* An array, which is set to true when the device is registered. */
> +static bool probed_devices[HWICAP_DEVICES];
> +static struct mutex icap_sem;
Just a sideway note, static DEFINE_MUTEX(icap_sem); and you don't need to
runtime init it then.
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Benjamin Herrenschmidt @ 2008-02-08 8:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004421.17746.32557.sendpatchset@localhost.localdomain>
On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> - couple of fixes and preparatory patches
>
> - rework of PowerMac media-bay support ([un]register IDE devices instead of
> [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
Interesting... I was thinking about doing a full remove of the device at
a higher level instead but I suppose what you propose is easier.
I'll have a look & test next week hopefully.
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] get rid of `model = "UCC"' in the ucc nodes
From: David Gibson @ 2008-02-08 6:14 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, Jon Loeliger
In-Reply-To: <fa686aa40802050839k652aeb4ga0e6b304d91ee9dd@mail.gmail.com>
On Tue, Feb 05, 2008 at 09:39:02AM -0700, Grant Likely wrote:
> On 2/5/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Fri, Feb 01, 2008 at 09:23:47AM -0700, Grant Likely wrote:
> > > cell-index has been useful for things like clock controllers to know
> > > what offset into a shared clock control register or something like
> > > that and a driver would pass the cell-index value to the shared reg
> > > driver when requesting service.
> >
> > Right. Except that if the shared resource is just a single register,
> > calling the routines to access it a "shared reg driver" gives a
> > misleading impression. Depending on how the shared reg is used, even
> > a lock may not be necessary, so potentially the drivers for the
> > individual device instances using the shared resource can (safely)
> > directly access it.
>
> Fair enough. In the case of a single shared, or a homogeneous set of
> shared registers (all of them use the same index) I can see the
> argument for cell index.
Yes, that's the situation it was created for.
> However, there are places where cell-index is being used where the
> value of cell-index has no relation to the offset into a register.
> But what about the case where the device uses multiple shared
> registers, each one using a *different* offset. cell-index doesn't
> describe this situation well (or at least no better than just using
> the value of reg instead, a translation is still required)
Absolutely. This is not a suitable situation in which to use
cell-index.
[snip]
> >From booting-without-of (in the EMAC description):
> - cell-index : 1 cell, hardware index of the EMAC cell on a
> given ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on each Axon
> chip.
>
> So, even if the intent was for cell-index to specify offsets into
> shared regs, the description does not reflect that purpose. And
> reading thorough the rest of the document, cell-index is described
> purely in terms of enumerating ip blocks, so that is clearly the
> assumption that people are making when using it.
>
> In other words, my point is this: *If* cell-index is just a way to
> encode the manufacturing assigned ip-block number (EMAC0, EMAC1, etc)
> then there is probably little or no value in it. The two arguments I
> see for using cell-index in that mode are:
>
> 1) to offset into shared registers (but this doesn't hold because ip
> block numbers often don't match register offsets and the reg property
> would be just as suitable)
>
> 2) to logically identify ip blocks to the user (but cell-index was
> never intended for this and /aliases is a better solution anyway)
Right. The confusion arises because cell-index was invented on 4xx,
where it's common practice to index global registers by the ip block
number.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 4/4] Make cell IOMMU fixed mapping printk more useful
From: Michael Ellerman @ 2008-02-08 5:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <3aa63ba024ba35ff3bf5b5f1d6aec2efa9782ba5.1202449018.git.michael@ellerman.id.au>
Currently the cell IOMMU fixed mapping just printks that it's been setup,
which is not particularly useful. Much more interesting is the address
ranges for the different windows. This adds one line to dmesg on a blade.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 5cdcd36..edab631 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -991,8 +991,8 @@ static int __init cell_iommu_fixed_mapping_init(void)
dsize = htab_size_bytes;
}
- pr_debug("iommu: setting up %d, dynamic window %lx-%lx " \
- "fixed window %lx-%lx\n", iommu->nid, dbase,
+ printk(KERN_DEBUG "iommu: node %d, dynamic window 0x%lx-0x%lx "
+ "fixed window 0x%lx-0x%lx\n", iommu->nid, dbase,
dbase + dsize, fbase, fbase + fsize);
cell_iommu_setup_page_tables(iommu, dbase, dsize, fbase, fsize);
@@ -1008,8 +1008,6 @@ static int __init cell_iommu_fixed_mapping_init(void)
dma_iommu_ops.set_dma_mask = dma_set_mask_and_switch;
set_pci_dma_ops(&dma_iommu_ops);
- printk(KERN_DEBUG "IOMMU fixed mapping established.\n");
-
return 0;
}
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 3/4] Fix potential cell IOMMU bug when switching back to default DMA ops
From: Michael Ellerman @ 2008-02-08 5:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <3aa63ba024ba35ff3bf5b5f1d6aec2efa9782ba5.1202449018.git.michael@ellerman.id.au>
If we get a 64-bit dma mask we switch to the fixed ops and call
cell_dma_dev_setup(). If the driver then switches back to a 32-bit dma
mask for any reason we don't call cell_dma_dev_setup() again, which
has the potential to leave bogus data in dev->archdata.dma_data.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 1f7b254..5cdcd36 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -841,19 +841,18 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
- if (dma_mask == DMA_BIT_MASK(64)) {
- if (cell_iommu_get_fixed_address(dev) == OF_BAD_ADDR)
- dev_dbg(dev, "iommu: 64-bit OK, but bad addr\n");
- else {
- dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
- set_dma_ops(dev, &dma_iommu_fixed_ops);
- cell_dma_dev_setup(dev);
- }
+ if (dma_mask == DMA_BIT_MASK(64) &&
+ cell_iommu_get_fixed_address(dev) != OF_BAD_ADDR)
+ {
+ dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
+ set_dma_ops(dev, &dma_iommu_fixed_ops);
} else {
dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
set_dma_ops(dev, get_pci_dma_ops());
}
+ cell_dma_dev_setup(dev);
+
*dev->dma_mask = dma_mask;
return 0;
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/4] Don't enable cell IOMMU fixed mapping if there are no dma-ranges
From: Michael Ellerman @ 2008-02-08 5:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <3aa63ba024ba35ff3bf5b5f1d6aec2efa9782ba5.1202449018.git.michael@ellerman.id.au>
In order for the cell IOMMU fixed mapping to work we need "dma-ranges"
properties in the device tree. If there are none then there's no point
enabling the fixed mapping support.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index a276064..1f7b254 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -917,6 +917,18 @@ static int __init cell_iommu_fixed_mapping_init(void)
return -1;
}
+ /* We must have dma-ranges properties for fixed mapping to work */
+ for (np = NULL; (np = of_find_all_nodes(np));) {
+ if (of_find_property(np, "dma-ranges", NULL))
+ break;
+ }
+ of_node_put(np);
+
+ if (!np) {
+ pr_debug("iommu: no dma-ranges found, no fixed mapping\n");
+ return -1;
+ }
+
/* The default setup is to have the fixed mapping sit after the
* dynamic region, so find the top of the largest IOMMU window
* on any axon, then add the size of RAM and that's our max value.
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 1/4] Fix cell IOMMU null pointer explosion on old firmwares
From: Michael Ellerman @ 2008-02-08 5:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
The cell IOMMU fixed mapping support has a null pointer bug if you run
it on older firmwares that don't contain the "dma-ranges" properties.
Fix it and convert to using of_get_next_parent() while we're there.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/iommu.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index df33066..a276064 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -26,6 +26,7 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/notifier.h>
+#include <linux/of.h>
#include <linux/of_platform.h>
#include <asm/prom.h>
@@ -789,18 +790,16 @@ static int __init cell_iommu_init_disabled(void)
static u64 cell_iommu_get_fixed_address(struct device *dev)
{
u64 cpu_addr, size, best_size, pci_addr = OF_BAD_ADDR;
- struct device_node *tmp, *np;
+ struct device_node *np;
const u32 *ranges = NULL;
int i, len, best;
- np = dev->archdata.of_node;
- of_node_get(np);
- ranges = of_get_property(np, "dma-ranges", &len);
- while (!ranges && np) {
- tmp = of_get_parent(np);
- of_node_put(np);
- np = tmp;
+ np = of_node_get(dev->archdata.of_node);
+ while (np) {
ranges = of_get_property(np, "dma-ranges", &len);
+ if (ranges)
+ break;
+ np = of_get_next_parent(np);
}
if (!ranges) {
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [PATCH 2/4] spufs: update SPU_Status[CISHP] in backing runcntl write
From: Jeremy Kerr @ 2008-02-08 4:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1202446241.799868.442184577655.0.gpush@pokey>
From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Currently, the kernel may fail to restart a SPE context which
has stopped and been swapped out.
This patch changes spu_backing_runcntl_write to emulate the real
SPU_Status register exactly. When the SPU Run Control register
is written with SPU_RunCntl[Run] set to '1', the physical SPU
automatically sets SPU_Status[R] and clears SPU_Status[CISHP].
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spufs/backing_ops.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/cell/spufs/backing_ops.c b/arch/powerpc/platforms/cell/spufs/backing_ops.c
index 50d98a1..64eb15b 100644
--- a/arch/powerpc/platforms/cell/spufs/backing_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/backing_ops.c
@@ -288,6 +288,12 @@ static void spu_backing_runcntl_write(struct spu_context *ctx, u32 val)
spin_lock(&ctx->csa.register_lock);
ctx->csa.prob.spu_runcntl_RW = val;
if (val & SPU_RUNCNTL_RUNNABLE) {
+ ctx->csa.prob.spu_status_R &=
+ ~SPU_STATUS_STOPPED_BY_STOP &
+ ~SPU_STATUS_STOPPED_BY_HALT &
+ ~SPU_STATUS_SINGLE_STEP &
+ ~SPU_STATUS_INVALID_INSTR &
+ ~SPU_STATUS_INVALID_CH;
ctx->csa.prob.spu_status_R |= SPU_STATUS_RUNNING;
} else {
ctx->csa.prob.spu_status_R &= ~SPU_STATUS_RUNNING;
^ permalink raw reply related
* [PATCH 3/4] spufs: no need to have a runnable SPU for libassist update
From: Jeremy Kerr @ 2008-02-08 4:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1202446241.799868.442184577655.0.gpush@pokey>
From: Luke Browning <lukebr@linux.vnet.ibm.com>
We don't need to update the libassist statistic with the context in a
runnable state, so do it after spu_disable_spu().
Signed-off-by: Luke Browning <lukebrowning@us.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Christoph Hellwig <hch@lst.de>
---
arch/powerpc/platforms/cell/spufs/run.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/run.c b/arch/powerpc/platforms/cell/spufs/run.c
index e9c61a1..f401e51 100644
--- a/arch/powerpc/platforms/cell/spufs/run.c
+++ b/arch/powerpc/platforms/cell/spufs/run.c
@@ -395,16 +395,14 @@ long spufs_run_spu(struct spu_context *ctx, u32 *npc, u32 *event)
SPU_STATUS_STOPPED_BY_HALT |
SPU_STATUS_SINGLE_STEP)));
- if ((status & SPU_STATUS_STOPPED_BY_STOP) &&
- (((status >> SPU_STOP_STATUS_SHIFT) & 0x3f00) == 0x2100) &&
- (ctx->state == SPU_STATE_RUNNABLE))
- ctx->stats.libassist++;
-
-
spu_disable_spu(ctx);
ret = spu_run_fini(ctx, npc, &status);
spu_yield(ctx);
+ if ((status & SPU_STATUS_STOPPED_BY_STOP) &&
+ (((status >> SPU_STOP_STATUS_SHIFT) & 0x3f00) == 0x2100))
+ ctx->stats.libassist++;
+
if ((ret == 0) ||
((ret == -ERESTARTSYS) &&
((status & SPU_STATUS_STOPPED_BY_HALT) ||
^ permalink raw reply related
* [PATCH 0/4] A few spufs fixes for .25
From: Jeremy Kerr @ 2008-02-08 4:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
Hi Paul,
Here are a few spufs fixes & updates for 2.6.25. Let me know if these
are all OK.
Cheers,
Jeremy
---
Christoph Hellwig (1):
spufs: fix state_mutex leaks
Luke Browning (2):
spufs: no need to have a runnable SPU for libassist update
spufs: fix timing dependent false return from spufs_run_spu
Masato Noguchi (1):
spufs: update SPU_Status[CISHP] in backing runcntl write
^ permalink raw reply
* [PATCH 1/4] spufs: fix state_mutex leaks
From: Jeremy Kerr @ 2008-02-08 4:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1202446241.799868.442184577655.0.gpush@pokey>
From: Christoph Hellwig <hch@lst.de>
Fix various state_mutex leaks. The worst one was introduced by the
interrutible state_mutex conversion but there've been a few before
too. Notably spufs_wait now returns without the state_mutex held
when returning an error, which actually cleans up some code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Luke Browning <lukebrowning@us.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spufs/fault.c | 12 ++-----
arch/powerpc/platforms/cell/spufs/file.c | 49 +++++++++++++++++-------------
arch/powerpc/platforms/cell/spufs/run.c | 9 ++++-
arch/powerpc/platforms/cell/spufs/spufs.h | 5 ++-
4 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/fault.c b/arch/powerpc/platforms/cell/spufs/fault.c
index eff4d29..e46d300 100644
--- a/arch/powerpc/platforms/cell/spufs/fault.c
+++ b/arch/powerpc/platforms/cell/spufs/fault.c
@@ -108,7 +108,7 @@ int spufs_handle_class1(struct spu_context *ctx)
u64 ea, dsisr, access;
unsigned long flags;
unsigned flt = 0;
- int ret, ret2;
+ int ret;
/*
* dar and dsisr get passed from the registers
@@ -148,13 +148,10 @@ int spufs_handle_class1(struct spu_context *ctx)
ret = spu_handle_mm_fault(current->mm, ea, dsisr, &flt);
/*
- * If spu_acquire fails due to a pending signal we just want to return
- * EINTR to userspace even if that means missing the dma restart or
- * updating the page fault statistics.
+ * This is nasty: we need the state_mutex for all the bookkeeping even
+ * if the syscall was interrupted by a signal. ewww.
*/
- ret2 = spu_acquire(ctx);
- if (ret2)
- goto out;
+ mutex_lock(&ctx->state_mutex);
/*
* Clear dsisr under ctxt lock after handling the fault, so that
@@ -185,7 +182,6 @@ int spufs_handle_class1(struct spu_context *ctx)
} else
spufs_handle_event(ctx, ea, SPE_EVENT_SPE_DATA_STORAGE);
- out:
spuctx_switch_state(ctx, SPU_UTIL_SYSTEM);
return ret;
}
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 1018acd..e4ab9d5 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -358,6 +358,7 @@ static unsigned long spufs_ps_nopfn(struct vm_area_struct *vma,
{
struct spu_context *ctx = vma->vm_file->private_data;
unsigned long area, offset = address - vma->vm_start;
+ int ret = 0;
spu_context_nospu_trace(spufs_ps_nopfn__enter, ctx);
@@ -379,7 +380,7 @@ static unsigned long spufs_ps_nopfn(struct vm_area_struct *vma,
if (ctx->state == SPU_STATE_SAVED) {
up_read(¤t->mm->mmap_sem);
spu_context_nospu_trace(spufs_ps_nopfn__sleep, ctx);
- spufs_wait(ctx->run_wq, ctx->state == SPU_STATE_RUNNABLE);
+ ret = spufs_wait(ctx->run_wq, ctx->state == SPU_STATE_RUNNABLE);
spu_context_trace(spufs_ps_nopfn__wake, ctx, ctx->spu);
down_read(¤t->mm->mmap_sem);
} else {
@@ -388,7 +389,8 @@ static unsigned long spufs_ps_nopfn(struct vm_area_struct *vma,
spu_context_trace(spufs_ps_nopfn__insert, ctx, ctx->spu);
}
- spu_release(ctx);
+ if (!ret)
+ spu_release(ctx);
return NOPFN_REFAULT;
}
@@ -755,23 +757,25 @@ static ssize_t spufs_ibox_read(struct file *file, char __user *buf,
count = spu_acquire(ctx);
if (count)
- return count;
+ goto out;
/* wait only for the first element */
count = 0;
if (file->f_flags & O_NONBLOCK) {
- if (!spu_ibox_read(ctx, &ibox_data))
+ if (!spu_ibox_read(ctx, &ibox_data)) {
count = -EAGAIN;
+ goto out_unlock;
+ }
} else {
count = spufs_wait(ctx->ibox_wq, spu_ibox_read(ctx, &ibox_data));
+ if (count)
+ goto out;
}
- if (count)
- goto out;
/* if we can't write at all, return -EFAULT */
count = __put_user(ibox_data, udata);
if (count)
- goto out;
+ goto out_unlock;
for (count = 4, udata++; (count + 4) <= len; count += 4, udata++) {
int ret;
@@ -788,9 +792,9 @@ static ssize_t spufs_ibox_read(struct file *file, char __user *buf,
break;
}
-out:
+out_unlock:
spu_release(ctx);
-
+out:
return count;
}
@@ -905,7 +909,7 @@ static ssize_t spufs_wbox_write(struct file *file, const char __user *buf,
count = spu_acquire(ctx);
if (count)
- return count;
+ goto out;
/*
* make sure we can at least write one element, by waiting
@@ -913,14 +917,16 @@ static ssize_t spufs_wbox_write(struct file *file, const char __user *buf,
*/
count = 0;
if (file->f_flags & O_NONBLOCK) {
- if (!spu_wbox_write(ctx, wbox_data))
+ if (!spu_wbox_write(ctx, wbox_data)) {
count = -EAGAIN;
+ goto out_unlock;
+ }
} else {
count = spufs_wait(ctx->wbox_wq, spu_wbox_write(ctx, wbox_data));
+ if (count)
+ goto out;
}
- if (count)
- goto out;
/* write as much as possible */
for (count = 4, udata++; (count + 4) <= len; count += 4, udata++) {
@@ -934,8 +940,9 @@ static ssize_t spufs_wbox_write(struct file *file, const char __user *buf,
break;
}
-out:
+out_unlock:
spu_release(ctx);
+out:
return count;
}
@@ -1598,12 +1605,11 @@ static ssize_t spufs_mfc_read(struct file *file, char __user *buffer,
} else {
ret = spufs_wait(ctx->mfc_wq,
spufs_read_mfc_tagstatus(ctx, &status));
+ if (ret)
+ goto out;
}
spu_release(ctx);
- if (ret)
- goto out;
-
ret = 4;
if (copy_to_user(buffer, &status, 4))
ret = -EFAULT;
@@ -1732,6 +1738,8 @@ static ssize_t spufs_mfc_write(struct file *file, const char __user *buffer,
int status;
ret = spufs_wait(ctx->mfc_wq,
spu_send_mfc_command(ctx, cmd, &status));
+ if (ret)
+ goto out;
if (status)
ret = status;
}
@@ -1785,7 +1793,7 @@ static int spufs_mfc_flush(struct file *file, fl_owner_t id)
ret = spu_acquire(ctx);
if (ret)
- return ret;
+ goto out;
#if 0
/* this currently hangs */
ret = spufs_wait(ctx->mfc_wq,
@@ -1794,12 +1802,13 @@ static int spufs_mfc_flush(struct file *file, fl_owner_t id)
goto out;
ret = spufs_wait(ctx->mfc_wq,
ctx->ops->read_mfc_tagstatus(ctx) == ctx->tagwait);
-out:
+ if (ret)
+ goto out;
#else
ret = 0;
#endif
spu_release(ctx);
-
+out:
return ret;
}
diff --git a/arch/powerpc/platforms/cell/spufs/run.c b/arch/powerpc/platforms/cell/spufs/run.c
index b4814c7..e9c61a1 100644
--- a/arch/powerpc/platforms/cell/spufs/run.c
+++ b/arch/powerpc/platforms/cell/spufs/run.c
@@ -354,8 +354,15 @@ long spufs_run_spu(struct spu_context *ctx, u32 *npc, u32 *event)
do {
ret = spufs_wait(ctx->stop_wq, spu_stopped(ctx, &status));
- if (unlikely(ret))
+ if (unlikely(ret)) {
+ /*
+ * This is nasty: we need the state_mutex for all the
+ * bookkeeping even if the syscall was interrupted by
+ * a signal. ewww.
+ */
+ mutex_lock(&ctx->state_mutex);
break;
+ }
spu = ctx->spu;
if (unlikely(test_and_clear_bit(SPU_SCHED_NOTIFY_ACTIVE,
&ctx->sched_flags))) {
diff --git a/arch/powerpc/platforms/cell/spufs/spufs.h b/arch/powerpc/platforms/cell/spufs/spufs.h
index 795a1b5..2c2fe3c 100644
--- a/arch/powerpc/platforms/cell/spufs/spufs.h
+++ b/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -268,6 +268,9 @@ extern char *isolated_loader;
* Same as wait_event_interruptible(), except that here
* we need to call spu_release(ctx) before sleeping, and
* then spu_acquire(ctx) when awoken.
+ *
+ * Returns with state_mutex re-acquired when successfull or
+ * with -ERESTARTSYS and the state_mutex dropped when interrupted.
*/
#define spufs_wait(wq, condition) \
@@ -278,11 +281,11 @@ extern char *isolated_loader;
prepare_to_wait(&(wq), &__wait, TASK_INTERRUPTIBLE); \
if (condition) \
break; \
+ spu_release(ctx); \
if (signal_pending(current)) { \
__ret = -ERESTARTSYS; \
break; \
} \
- spu_release(ctx); \
schedule(); \
__ret = spu_acquire(ctx); \
if (__ret) \
^ permalink raw reply related
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