* Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-27 16:47 UTC (permalink / raw)
To: i2c, linuxppc-dev, linux-kernel
In-Reply-To: <20071220044136.20091.70984.stgit@terra.home>
On 12/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in.
Are there any further objections to this patch? Can it all go in
through the powerpc trees or do the i2c people want to send it on?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-27 18:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <20071227101404.2C05F2405E@gemini.denx.de>
On Thursday 27 December 2007 11:14:04 Wolfgang Denk wrote:
> In message <200712261708.51432.mb@bu3sch.de> you wrote:
> > On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
> > > Michael Buesch <mb@bu3sch.de> writes:
> > >
> > > > + set +e
> > > > mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
> > > > $uboot_version -d "$vmz" "$ofile"
> > > > + [ $? -eq 0 ] || exit 0
> > > > + set -e
> > >
> > > mkimage ... || exit 0
> >
> > Could you PLEASE increase your verbosity?
> > Why is mkimage || exit 0 any better than my test?
>
> Because it works, while your's doesn't.
>
> Make runs each command in a new shell. Your "set +e" is in vain, and
> so is your test of the return code.
>
> Um... doesn't make throw an error anyway when the execution of
> mkimage fails?
I'm not sure what you are talking about at all, sorry.
set +e simply disables the abortion of the shell script if
the mkimage command fails. The test after that checks whether it failed
and returns success in that event, so the calling makefile does
_not_ interrupt. It only gives you a mkimage not found message.
I did test this patch on my machine where there is no mkimage
and it correctly aborts the shell script and throws an error,
while it does not abort the makefile process. And that is what we want.
--
Greetings Michael.
^ permalink raw reply
* Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-27 22:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stefan Roese
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
If this should go in linuxppc-embedded please let me know. It seems that
the board supports are getting posted here.
PIKA has an embedded PPC440EP board based on the AMCC Yosemite board. I
got the Linux 2.6.19.2 kernel working by basically copying the Yosemite
configuration. Now I am trying to move from the ppc to the powerpc
architecture using Josh Boyer's for-2.6.25 kernel. And there is no
Yosemite config :( We are using u-boot 1.3.0.
I have the kernel booting, but the OS runs very strange. I cannot run
the ash shell, it fails on the first setjmp. But I can run the hush
shell (we are using busybox). So it goes, many things work, others don't.
I am mounting the root filesystem over NFS, so the ethernet seem to work
well.
But cat /proc/interrupts shows:
CPU0
16: 126 UIC Level serial
17: 520 UIC Level MAL TX EOB
18: 804 UIC Level MAL RX EOB
19: 0 UIC Level MAL SERR
20: 0 UIC Level MAL TX DE
21: 0 UIC Level MAL RX DE
28: 0 UIC Level EMAC
BAD: 0
Which is quite different from the older kernel:
CPU0
0: 3075 UIC0 Level serial
2: 1526 UIC0 Level IBM IIC
7: 0 UIC0 Level IBM IIC
10: 1388 UIC0 Level MAL TX EOB
11: 1839 UIC0 Level MAL RX EOB
32: 0 UIC1 Level MAL SERR
33: 0 UIC1 Level MAL TX DE
34: 0 UIC1 Level MAL RX DE
40: 1 UIC1 Level ohci_hcd:usb1
60: 0 UIC1 Level EMAC
BAD: 0
I have attached the dts file. It is based on the bamboo. I can provide
any other config, the only thing I can't provide is the hardware ;)
Since the new kernel doesn't show UIC0 or UIC1, just UIC I am wondering
if something is wrong with the dts.
I have to admit the dts file confuses me a bit. So I suspect that is
where the problem is. If anybody has any other ideas, don't hesitate to
suggest!
Cheers,
Sean
[-- Attachment #2: taco.dts --]
[-- Type: text/plain, Size: 4665 bytes --]
/*
* Device Tree Source for PIKA Taco
*
* Copyright 2007 PIKA Technologies
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without
* any warranty of any kind, whether express or implied.
*/
/ {
#address-cells = <2>;
#size-cells = <1>;
model = "pika,taco";
compatible = "pika,taco";
dcr-parent = <&/cpus/cpu@0>;
aliases {
ethernet0 = &EMAC0;
serial0 = &UART0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
model = "PowerPC,440EP";
reg = <0>;
clock-frequency = <0>; /* Filled in by zImage */
timebase-frequency = <0>; /* Filled in by zImage */
i-cache-line-size = <20>;
d-cache-line-size = <20>;
i-cache-size = <8000>;
d-cache-size = <8000>;
dcr-controller;
dcr-access-method = "native";
};
};
memory {
device_type = "memory";
reg = <0 0 0>; /* Filled in by zImage */
};
UIC0: interrupt-controller0 {
compatible = "ibm,uic-440ep","ibm,uic";
interrupt-controller;
cell-index = <0>;
dcr-reg = <0c0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
};
UIC1: interrupt-controller1 {
compatible = "ibm,uic-440ep","ibm,uic";
interrupt-controller;
cell-index = <1>;
dcr-reg = <0d0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <1e 4 1f 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
SDR0: sdr {
compatible = "ibm,sdr-440ep";
dcr-reg = <00e 002>;
};
CPR0: cpr {
compatible = "ibm,cpr-440ep";
dcr-reg = <00c 002>;
};
plb {
compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
#address-cells = <2>;
#size-cells = <1>;
ranges;
clock-frequency = <0>; /* Filled in by zImage */
SDRAM0: sdram {
compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
dcr-reg = <010 2>;
};
DMA0: dma {
compatible = "ibm,dma-440ep", "ibm,dma-440gp";
dcr-reg = <100 027>;
};
MAL0: mcmal {
compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp", "ibm,mcmal";
dcr-reg = <180 62>;
num-tx-chans = <4>;
num-rx-chans = <2>;
interrupt-parent = <&MAL0>;
interrupts = <0 1 2 3 4>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
/*RXEOB*/ 1 &UIC0 b 4
/*SERR*/ 2 &UIC1 0 4
/*TXDE*/ 3 &UIC1 1 4
/*RXDE*/ 4 &UIC1 2 4>;
};
POB0: opb {
compatible = "ibm,opb-440ep", "ibm,opb-440gp", "ibm,opb";
#address-cells = <1>;
#size-cells = <1>;
ranges = <00000000 0 00000000 80000000
80000000 0 80000000 80000000>;
interrupt-parent = <&UIC1>;
interrupts = <7 4>;
clock-frequency = <0>; /* Filled in by zImage */
EBC0: ebc {
compatible = "ibm,ebc-440ep", "ibm,ebc-440gp", "ibm,ebc";
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
clock-frequency = <0>; /* Filled in by zImage */
interrupts = <5 1>;
interrupt-parent = <&UIC1>;
};
UART0: serial@ef600300 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600300 8>;
virtual-reg = <ef600300>;
clock-frequency = <0>; /* Filled in by zImage */
current-speed = <1c200>;
interrupt-parent = <&UIC0>;
interrupts = <0 4>;
};
IIC0: i2c@ef600700 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
};
IIC1: i2c@ef600800 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <7 4>;
};
ZMII0: emac-zmii@ef600d00 {
device_type = "zmii-interface";
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
};
EMAC0: ethernet@ef600e00 {
linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
reg = <ef600e00 70>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0 1>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rmii";
phy-map = <00000000>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
};
usb@ef601000 {
compatible = "ohci-be";
reg = <ef601000 80>;
interrupts = <8 1 9 1>;
interrupt-parent = < &UIC1 >;
};
};
};
chosen {
linux,stdout-path = "/plb/opb/serial@ef600300";
};
};
^ permalink raw reply
* update: RE: nap/dfs on 7448
From: Leisner, Martin @ 2007-12-27 22:37 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191304917.6310.99.camel@pasglop>
Turns out the Tundra TSI109 has various "problems" trying
to nap -- its not a 7448 issue...
We're working with tundra to get a workaround (in software, they=20
won't respin the part). It seems DMA while napping is an issue, we
have to turn off the tsi109 ethernet queues before entering nap mode...
If anyone needs this work, let me know (it will be covered under GPL).
marty
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Tuesday, October 02, 2007 2:02 AM
> To: Leisner, Martin
> Cc: linuxppc-dev
> Subject: Re: nap/dfs on 7448
> =20
> =20
> On Mon, 2007-10-01 at 17:32 -0400, Leisner, Martin wrote:
> > I asked this on linuxppc-embedded a week ago (I didn't even know
this
> > list existed until last week -- another reason to get rid of
> > linuxpcc-embedded).
> >
> > Has anyone gotten NAP/DFS to reliably work on a 7448?
> >
> > I'm seeing strange problems with peripherals...(using a ram disk
> > works fine).
> =20
> Could it be that your host bridge isn't properly waking up the CPU
to
> DOZE state for snooping DMA ? (It might require some delays on QACK
in
> some cases, I know Apple had workarounds in those areas, maybe
something
> along those lines need to be configured in the chipset).
> =20
> Ben.
> =20
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Josh Boyer @ 2007-12-28 1:47 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <47742519.8060502@pikatech.com>
On Thu, 27 Dec 2007 17:20:09 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> If this should go in linuxppc-embedded please let me know. It seems that
> the board supports are getting posted here.
>
> PIKA has an embedded PPC440EP board based on the AMCC Yosemite board. I
> got the Linux 2.6.19.2 kernel working by basically copying the Yosemite
> configuration. Now I am trying to move from the ppc to the powerpc
> architecture using Josh Boyer's for-2.6.25 kernel. And there is no
> Yosemite config :( We are using u-boot 1.3.0.
Yeah, I've no Yosemite board so no port for it yet.
> I have the kernel booting, but the OS runs very strange. I cannot run
> the ash shell, it fails on the first setjmp. But I can run the hush
> shell (we are using busybox). So it goes, many things work, others don't.
>
> I am mounting the root filesystem over NFS, so the ethernet seem to work
> well.
>
> But cat /proc/interrupts shows:
>
> CPU0
> 16: 126 UIC Level serial
> 17: 520 UIC Level MAL TX EOB
> 18: 804 UIC Level MAL RX EOB
> 19: 0 UIC Level MAL SERR
> 20: 0 UIC Level MAL TX DE
> 21: 0 UIC Level MAL RX DE
> 28: 0 UIC Level EMAC
> BAD: 0
Looks fairly normal to me.
>
> Which is quite different from the older kernel:
>
> CPU0
> 0: 3075 UIC0 Level serial
> 2: 1526 UIC0 Level IBM IIC
> 7: 0 UIC0 Level IBM IIC
> 10: 1388 UIC0 Level MAL TX EOB
> 11: 1839 UIC0 Level MAL RX EOB
> 32: 0 UIC1 Level MAL SERR
> 33: 0 UIC1 Level MAL TX DE
> 34: 0 UIC1 Level MAL RX DE
> 40: 1 UIC1 Level ohci_hcd:usb1
> 60: 0 UIC1 Level EMAC
> BAD: 0
>
There's no support for the i2c devices on 440 in arch/powerpc yet,
which is why those don't show up. As for the USB interrupt, you might
be missing the device-tree enabled USB driver in your config. The
interrupt numbers will differ based on various things, so I wouldn't
worry about that.
> I have attached the dts file. It is based on the bamboo. I can provide
> any other config, the only thing I can't provide is the hardware ;)
> Since the new kernel doesn't show UIC0 or UIC1, just UIC I am wondering
> if something is wrong with the dts.
I didn't see anything wrong in my cursory glance. But I need to look
at it a bit closer to be sure.
Can you post the full boot messages (send privately if you'd like). One
thing to make sure of is if all the properties in the DTS file that say
"Filled in by zImage wrapper" are actually getting filled in.
josh
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-28 3:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071227194753.56bc92f8@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Josh Boyer wrote:
> Can you post the full boot messages (send privately if you'd like). One
> thing to make sure of is if all the properties in the DTS file that say
> "Filled in by zImage wrapper" are actually getting filled in.
>
I have attached a boot log. The ethernet and IP addresses have been
modified, but everything else is correct.
I checked all the dts entries marked by /* Filled in by zImage */ by
checking /proc/device-tree and they all match what is printed after the
log message "Uncompressing Kernel Image ... OK".
FYI: It is a 533MHz PPC but the HW guys read the spec wrong and are
running the system clock at 66.0MHz rather than 66.6MHz, so the 528MHz
value is correct.
Cheers,
Sean
[-- Attachment #2: boot --]
[-- Type: text/plain, Size: 6593 bytes --]
U-Boot 1.3.0-gf92edbd8-dirty (Dec 7 2007 - 11:06:34)
CPU: AMCC PowerPC 440EP Rev. C at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
I2C boot EEPROM enabled
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
, PCI async ext clock used 32 kB I-Cache 32 kB D-Cache
Board: PIKA Embedded Appliance
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
NAND: 64 MiB
In: serial
Out: serial
Err: serial
Protected 2 sectors
FPGA download...complete.
FPGA code revision 1.2.2.0
Starting board diagnostics:
1. RAM walking bit test, first bank... test complete.
2. RAM walking bit test, second bank... test complete.
3. FPGA walking bit test... test complete.
4. Skipping user test - start_test_addr or end_test_addr env. vars not set.
Board diagnostics complete.
Net: ppc_4xx_eth0
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
Waiting for PHY auto negotiation to complete. done
ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server 192.168.0.164; our IP address is 192.168.0.99
Filename 'uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#############################################################
done
Bytes transferred = 1308159 (13f5ff hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.24-rc6-pika
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1308095 Bytes = 1.2 MB
Load Address: 00400000
Entry Point: 004003c8
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
CPU clock-frequency <- 0x1f78a400 (528MHz)
CPU timebase-frequency <- 0x1f78a400 (528MHz)
/plb: clock-frequency <- 7de2900 (132MHz)
/plb/opb: clock-frequency <- 3ef1480 (66MHz)
/plb/opb/ebc: clock-frequency <- 3ef1480 (66MHz)
/plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
Memory <- <0x0 0x0 0x10000000> (256MB)
ENET0: local-mac-address <- <mac address>
zImage starting: loaded at 0x00400000 (sp: 0x0ff2a558)
Allocating 0x2b84a0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x006ba364)...done 0x297408 bytes
Linux/PowerPC load: root=/dev/nfs rw nfsroot=192.168.x.x:/usr/src/eldk/taco ip=192.168.x.x:192.168.x.x:192.168.x.x:255.255.252.0:tigger:eth0:off panic=1 console=ttyS0,1150
Finalizing device tree... flat tree at 0x6c7300
Using Taco machine description
Linux version 2.6.24-rc6-pika (seanm@lappy) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #14 Thu Dec 27 16:33:16 EST 2007
console [udbg0] enabled
setup_arch: bootmem
arch: exit
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.x.x:/usr/src/eldk/taco ip=192.168.x.x:192.168.x.x:192.168.x.x:255.255.252.0:tigger:eth0:off panic=1 console=ttyS0,110
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
PID hash table entries: 1024 (order: 10, 4096 bytes)
clocksource: timebase mult[79364e] shift[22] registered
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256768k/262144k available (2516k kernel code, 5056k reserved, 116k data, 129k bss, 140k init)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
SCSI subsystem initialized
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.54
MAL v1 /plb/mcmal, 4 TX channels, 2 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
/plb/opb/emac-zmii@ef600d00: bridge in RMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:1e:84:ff:n.n
eth0: found Generic MII PHY (0x01)
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
eth0: link is down
IP-Config: Complete:
device=eth0, addr=192.168.x.x, mask=255.255.252.0, gw=192.168.x.x,
host=tigger, domain=, nis-domain=(none),
bootserver=192.168.x.x, rootserver=192.168.x.x, rootpath=
Looking up port of RPC 100003/2 on 192.168.x.x
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.x.x
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 140k init
init started: BusyBox v1.6.1 (2007-09-17 15:31:56 EDT) multi-call binary
starting pid 16, tty '': '/sbin/syslogd'
starting pid 19, tty '': '/etc/rc.S'
starting pid 28, tty '': '/sbin/getty'
tigger login:
^ permalink raw reply
* RE: Device node - How does kernel know about it
From: Siva Prasad @ 2007-12-28 3:27 UTC (permalink / raw)
To: Nicholas Mc Guire, Jon Smirl; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0712280936420.1827@rtl14.hofr.at>
Thank you Jon and Nicholas.
I already have "console=3DttyS0" in the kernel command line. That is not
helping me.
I looked at the major/minor numbers with a good working system and it
looks correct for the nodes created in ramdisk.
What is the kernel routine that is first called when there is, for
example a read() function call from user program?=20
I would like to start debugging from there and see if any thing at all
happens when there is a call. Appreciate your help with this question.
Thanks
Siva
-----Original Message-----
From: Nicholas Mc Guire [mailto:der.herr@hofr.at]=20
Sent: Friday, December 28, 2007 12:39 AM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: Device node - How does kernel know about it
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> * Ramdisk is also executing fine, just that prints are not coming out
of
> serial. I can see the execution of various user programs with a printk
> in sys_execve() routine. Ramdisk has all the required files like
> /dev/console, /dev/ttyS0, etc.
> * Looking further into tty driver, I noticed that call to tty_write()
or
> do_tty_write() is not happening at all. So, somewhere the interface
> between kernel and user program is lost.
> * Just to check it out, I tried to write a small kernel module and a
> test program.
> - Attached memtest.c module (not really testing memory there. :-))
> - Attached testmemtest.c user program, that just open's it and reads
> the information
> - Created a device node using "mknod /dev/memtest c 168 0"
> - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I
> could see all the printk's on the console
> - When I execute "testmemtest" next in the same script, it does not
> display the printk inside of memtest.c module. This only indicates
that
> read call did not really go to the kernel side.
> - Just to check my program's validity, I checked on a similar machine
> and all the code works fine.
> - "uname -r" also matches with what I built. So, chances of exiting
> from open call because of mismatch is remote. Since userland cannot
> print, I have no idea what exactly is happening there.
>
The kernel will simply look at the major:minor numbers - so maybe you
simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
see nothing but other than that most things will go on working.
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
hrfpn2RMn5l23ZqCOXV5rd8=3D
=3DGfsF
-----END PGP SIGNATURE-----
^ permalink raw reply
* 2.6.10 kernel hangs after timer_init
From: goog long @ 2007-12-28 3:49 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
2.6.10 kernel hangs on my board with PPC64 processors. The log is below. There must be a fix for this somewhere because it boots just fine on 2.6.14 kernel. Could someone please point me to the fix for this?
time_init: decrementer frequency = 112.500000 MHz
time_init: processor frequency = 1800.000000 MHz
-> set_preferred_console()
stdout is /ht@0/isa@8,2/serial@a0
Found serial console at ttyS0
smp_prepare_cpus
smp_mpic_probe()...
nr_cpus: 2
smp: kicking cpu 1
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 790 bytes --]
^ permalink raw reply
* [PATCH 1/2] [POWERPC] smp_call_function_map should be static
From: Olof Johansson @ 2007-12-28 4:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
smp_call_function_map should be static, and for consistency prepend it
with __ like other local helper functions in the same file.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 338950a..cefeee8 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -181,12 +181,13 @@ static struct call_data_struct {
* <wait> If true, wait (atomically) until function has completed on other CPUs.
* [RETURNS] 0 on success, else a negative status code. Does not return until
* remote CPUs are nearly ready to execute <<func>> or are or have executed.
+ * <map> is a cpu map of the cpus to send IPI to.
*
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
- int wait, cpumask_t map)
+static int __smp_call_function_map(void (*func) (void *info), void *info,
+ int nonatomic, int wait, cpumask_t map)
{
struct call_data_struct data;
int ret = -1, num_cpus;
@@ -265,7 +266,8 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
static int __smp_call_function(void (*func)(void *info), void *info,
int nonatomic, int wait)
{
- return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
+ return __smp_call_function_map(func, info, nonatomic, wait,
+ cpu_online_map);
}
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
@@ -278,8 +280,8 @@ int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
}
EXPORT_SYMBOL(smp_call_function);
-int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int nonatomic,
- int wait)
+int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
{
cpumask_t map = CPU_MASK_NONE;
int ret = 0;
@@ -292,7 +294,7 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
cpu_set(cpu, map);
if (cpu != get_cpu())
- ret = smp_call_function_map(func,info,nonatomic,wait,map);
+ ret = __smp_call_function_map(func, info, nonatomic, wait, map);
else {
local_irq_disable();
func(info);
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] Make smp_send_stop() handle panic and xmon reboot
From: Olof Johansson @ 2007-12-28 4:11 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071228040836.GA23635@lixom.net>
smp_send_stop() will send an IPI to all other cpus to shut them down.
However, for the case of xmon-based reboots (as well as potentially some
panics), the other cpus are (or might be) spinning with interrupts off,
and won't take the IPI.
Current code will drop us into the debugger when the IPI fails, which
means we're in an infinite loop that we can't get out of without an
external reset of some sort.
Instead, make the smp_send_stop() IPI call path just print the warning
about being unable to send IPIs, but make it return so the rest of the
shutdown sequence can continue. It's not perfect, but the lesser of
two evils.
Also move the call_lock handling outside of smp_call_function_map so we
can avoid deadlocks in smp_send_stop().
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index cefeee8..8730687 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -76,6 +76,8 @@ void smp_call_function_interrupt(void);
int smt_enabled_at_boot = 1;
+static int ipi_fail_ok;
+
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
#ifdef CONFIG_PPC64
@@ -204,8 +206,6 @@ static int __smp_call_function_map(void (*func) (void *info), void *info,
if (wait)
atomic_set(&data.finished, 0);
- spin_lock(&call_lock);
-
/* remove 'self' from the map */
if (cpu_isset(smp_processor_id(), map))
cpu_clear(smp_processor_id(), map);
@@ -232,7 +232,8 @@ static int __smp_call_function_map(void (*func) (void *info), void *info,
printk("smp_call_function on cpu %d: other cpus not "
"responding (%d)\n", smp_processor_id(),
atomic_read(&data.started));
- debugger(NULL);
+ if (!ipi_fail_ok)
+ debugger(NULL);
goto out;
}
}
@@ -259,15 +260,18 @@ static int __smp_call_function_map(void (*func) (void *info), void *info,
out:
call_data = NULL;
HMT_medium();
- spin_unlock(&call_lock);
return ret;
}
static int __smp_call_function(void (*func)(void *info), void *info,
int nonatomic, int wait)
{
- return __smp_call_function_map(func, info, nonatomic, wait,
+ int ret;
+ spin_lock(&call_lock);
+ ret =__smp_call_function_map(func, info, nonatomic, wait,
cpu_online_map);
+ spin_unlock(&call_lock);
+ return ret;
}
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
@@ -293,9 +297,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
return -EINVAL;
cpu_set(cpu, map);
- if (cpu != get_cpu())
+ if (cpu != get_cpu()) {
+ spin_lock(&call_lock);
ret = __smp_call_function_map(func, info, nonatomic, wait, map);
- else {
+ spin_unlock(&call_lock);
+ } else {
local_irq_disable();
func(info);
local_irq_enable();
@@ -307,7 +313,22 @@ EXPORT_SYMBOL(smp_call_function_single);
void smp_send_stop(void)
{
- __smp_call_function(stop_this_cpu, NULL, 1, 0);
+ int nolock;
+
+ /* It's OK to fail sending the IPI, since the alternative is to
+ * be stuck forever waiting on the other CPU to take the interrupt.
+ *
+ * It's better to at least continue and go through reboot, since this
+ * function is usually called at panic or reboot time in the first
+ * place.
+ */
+ ipi_fail_ok = 1;
+
+ /* Don't deadlock in case we got called through panic */
+ nolock = !spin_trylock(&call_lock);
+ __smp_call_function_map(stop_this_cpu, NULL, 1, 0, cpu_online_map);
+ if (!nolock)
+ spin_unlock(&call_lock);
}
void smp_call_function_interrupt(void)
^ permalink raw reply related
* Re: Device node - How does kernel know about it
From: Jon Smirl @ 2007-12-28 4:15 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, Nicholas Mc Guire, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7012AFA2D@corpexc01.corp.networkrobots.com>
On 12/27/07, Siva Prasad <sprasad@bivio.net> wrote:
> Thank you Jon and Nicholas.
>
> I already have "console=ttyS0" in the kernel command line. That is not
> helping me.
Do you have
CONFIG_EARLY_PRINTK=y
in .config?
>
> I looked at the major/minor numbers with a good working system and it
> looks correct for the nodes created in ramdisk.
>
> What is the kernel routine that is first called when there is, for
> example a read() function call from user program?
> I would like to start debugging from there and see if any thing at all
> happens when there is a call. Appreciate your help with this question.
>
> Thanks
> Siva
>
>
> -----Original Message-----
> From: Nicholas Mc Guire [mailto:der.herr@hofr.at]
> Sent: Friday, December 28, 2007 12:39 AM
> To: Siva Prasad
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: Device node - How does kernel know about it
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > * Ramdisk is also executing fine, just that prints are not coming out
> of
> > serial. I can see the execution of various user programs with a printk
> > in sys_execve() routine. Ramdisk has all the required files like
> > /dev/console, /dev/ttyS0, etc.
> > * Looking further into tty driver, I noticed that call to tty_write()
> or
> > do_tty_write() is not happening at all. So, somewhere the interface
> > between kernel and user program is lost.
> > * Just to check it out, I tried to write a small kernel module and a
> > test program.
> > - Attached memtest.c module (not really testing memory there. :-))
> > - Attached testmemtest.c user program, that just open's it and reads
> > the information
> > - Created a device node using "mknod /dev/memtest c 168 0"
> > - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I
> > could see all the printk's on the console
> > - When I execute "testmemtest" next in the same script, it does not
> > display the printk inside of memtest.c module. This only indicates
> that
> > read call did not really go to the kernel side.
> > - Just to check my program's validity, I checked on a similar machine
> > and all the code works fine.
> > - "uname -r" also matches with what I built. So, chances of exiting
> > from open call because of mismatch is remote. Since userland cannot
> > print, I have no idea what exactly is happening there.
> >
> The kernel will simply look at the major:minor numbers - so maybe you
> simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
> see nothing but other than that most things will go on working.
>
> hofrat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
> hrfpn2RMn5l23ZqCOXV5rd8=
> =GfsF
> -----END PGP SIGNATURE-----
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RE: Device node - How does kernel know about it
From: Siva Prasad @ 2007-12-28 4:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, Nicholas Mc Guire, linuxppc-embedded
In-Reply-To: <9e4733910712272015m30ffc13cu6022ee9d29f9bddc@mail.gmail.com>
Jon,
Yes!... I have CONFIG_EARLY_PRINTK=3Dy, and I could see early prints
during booting the kernel. Afterwards, printk's also work as expected.
Only printf's from user space has problem.
- Siva
-----Original Message-----
From: Jon Smirl [mailto:jonsmirl@gmail.com]=20
Sent: Thursday, December 27, 2007 8:16 PM
To: Siva Prasad
Cc: Nicholas Mc Guire; linuxppc-dev@ozlabs.org;
linuxppc-embedded@ozlabs.org
Subject: Re: Device node - How does kernel know about it
On 12/27/07, Siva Prasad <sprasad@bivio.net> wrote:
> Thank you Jon and Nicholas.
>
> I already have "console=3DttyS0" in the kernel command line. That is =
not
> helping me.
Do you have
CONFIG_EARLY_PRINTK=3Dy
in .config?
>
> I looked at the major/minor numbers with a good working system and it
> looks correct for the nodes created in ramdisk.
>
> What is the kernel routine that is first called when there is, for
> example a read() function call from user program?
> I would like to start debugging from there and see if any thing at all
> happens when there is a call. Appreciate your help with this question.
>
> Thanks
> Siva
>
>
> -----Original Message-----
> From: Nicholas Mc Guire [mailto:der.herr@hofr.at]
> Sent: Friday, December 28, 2007 12:39 AM
> To: Siva Prasad
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: Device node - How does kernel know about it
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > * Ramdisk is also executing fine, just that prints are not coming
out
> of
> > serial. I can see the execution of various user programs with a
printk
> > in sys_execve() routine. Ramdisk has all the required files like
> > /dev/console, /dev/ttyS0, etc.
> > * Looking further into tty driver, I noticed that call to
tty_write()
> or
> > do_tty_write() is not happening at all. So, somewhere the interface
> > between kernel and user program is lost.
> > * Just to check it out, I tried to write a small kernel module and a
> > test program.
> > - Attached memtest.c module (not really testing memory there. :-))
> > - Attached testmemtest.c user program, that just open's it and
reads
> > the information
> > - Created a device node using "mknod /dev/memtest c 168 0"
> > - When I do "insmod memtest.ko" inside the ramdisk bootup scripts,
I
> > could see all the printk's on the console
> > - When I execute "testmemtest" next in the same script, it does not
> > display the printk inside of memtest.c module. This only indicates
> that
> > read call did not really go to the kernel side.
> > - Just to check my program's validity, I checked on a similar
machine
> > and all the code works fine.
> > - "uname -r" also matches with what I built. So, chances of exiting
> > from open call because of mismatch is remote. Since userland cannot
> > print, I have no idea what exactly is happening there.
> >
> The kernel will simply look at the major:minor numbers - so maybe you
> simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
> see nothing but other than that most things will go on working.
>
> hofrat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
> hrfpn2RMn5l23ZqCOXV5rd8=3D
> =3DGfsF
> -----END PGP SIGNATURE-----
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-28 5:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi all...
I am writing a driver in which device port is mapped to CPLD and 8 bit data
bus is directly connected from processor to CPLD. Read write on CPLD memory
mapped (buffer/register) is required to control the device. This is now IO
mapped to processor.
I need to know whether i am right if i impliment like this :-
addr=ioremap(base_addr); // Remap to Mem mapped address
outb(addr) and inb(addr);
Please suggest me if i am wrong or there could be better solution to this .
-----Misbah <><
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14522349.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: update: RE: nap/dfs on 7448
From: Benjamin Herrenschmidt @ 2007-12-28 5:19 UTC (permalink / raw)
To: Leisner, Martin; +Cc: linuxppc-dev
In-Reply-To: <556445368AFA1C438794ABDA8901891C07C113CC@USA0300MS03.na.xerox.net>
On Thu, 2007-12-27 at 17:37 -0500, Leisner, Martin wrote:
> Turns out the Tundra TSI109 has various "problems" trying
> to nap -- its not a 7448 issue...
>
> We're working with tundra to get a workaround (in software, they
> won't respin the part). It seems DMA while napping is an issue, we
> have to turn off the tsi109 ethernet queues before entering nap mode...
>
> If anyone needs this work, let me know (it will be covered under GPL).
This looks like yet another f*cked up bridge ... I wonder if we'll ever
get a half decent working northbridge for those processors...
Unfortunately, it looks like the market for those is limited to junk
from vendor A and shit from vendor B...
Is the problem limited to the TSI internal ethernet or it happens with
any DMA ?
Looks to me like turning off DMA in NAP mode basically makes NAP mode
unuseable, perdiod. You can't start loosing packets because your
processor is idle. So no power saving, and let's eat the watts since
they won't respin the part. Great !
Ben.
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2007-12-28 5:30 UTC (permalink / raw)
To: balbir; +Cc: fujita.tomonori, linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <47733C01.1080002@linux.vnet.ibm.com>
On Thu, 27 Dec 2007 11:15:37 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> FUJITA Tomonori wrote:
> > On Thu, 27 Dec 2007 10:08:25 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> >
> >> FUJITA Tomonori wrote:
> >>> On Mon, 24 Dec 2007 10:18:50 +0530
> >>> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> >>>
> >> [snip]
> >>
> >>> I might break the IOMMU code. Can you reproduce it easily? If so,
> >>> reverting my IOMMU patches (I've attached a patch to revert them) fix
> >>> the problem?
> >> [snip]
> >>
> >>
> >> Yes, this patch fixes the problem for me.
> >
> > Thanks, so you can reproduce it easily, right?
> >
>
> Yes, quite easily
>
> > The problem is that I don't want to revert these changes. I'll see
> > how these changes cause the problem shortly.
>
> I'll try and find some bandwidth to review/test the patches and help you
> figure out the right solution.
Thanks,
Can you try this?
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index e7d8544..495575a 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -8,15 +8,20 @@
static unsigned long find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
- unsigned int nr)
+ unsigned int nr,
+ unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) & ~align_mask;
+
end = index + nr;
- if (end > size)
+ if (end >= size)
return -1;
- for (i = index + 1; i < end; i++) {
+ for (i = index; i < end; i++) {
if (test_bit(i, map)) {
start = i+1;
goto again;
@@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
{
unsigned long index;
again:
- index = find_next_zero_area(map, size, start, nr);
+ index = find_next_zero_area(map, size, start, nr, align_mask);
if (index != -1) {
- index = (index + align_mask) & ~align_mask;
if (is_span_boundary(index, nr, shift, boundary_size)) {
/* we could do more effectively */
start = index + 1;
^ permalink raw reply related
* Re: Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-28 6:12 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071227194753.56bc92f8@vader.jdub.homelinux.org>
Josh Boyer wrote:
> As for the USB interrupt, you might
> be missing the device-tree enabled USB driver in your config. The
> interrupt numbers will differ based on various things, so I wouldn't
> worry about that.
>
Just so I am not all bad news, I got the usb going. I borrowed the usb
config from bamboo.dts. I then had to patch the top level usb Kconfig.
It basically relies on PCI, and the taco has no PCI, so I added the
taco as a special case.
Cheers,
Sean
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-28 6:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <477493D9.7070700@pikatech.com>
And one more thought, could uClibc be causing problems with the new
kernel? It just seems strange that kernel "stuff" seems to work (e.g. no
problems mounting a usbkey) yet a simple setjmp in a user mode app reeks
havoc.
We are going to be moving away from uClibc in the short term (I am the
only one left using it). So if this could be an issue I might have to
bite the bullet and switch now.
Cheers,
Sean
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: Balbir Singh @ 2007-12-28 7:35 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <20071228143043U.fujita.tomonori@lab.ntt.co.jp>
FUJITA Tomonori wrote:
[snip]
> Thanks,
>
> Can you try this?
>
>
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> index e7d8544..495575a 100644
> --- a/lib/iommu-helper.c
> +++ b/lib/iommu-helper.c
> @@ -8,15 +8,20 @@
> static unsigned long find_next_zero_area(unsigned long *map,
> unsigned long size,
> unsigned long start,
> - unsigned int nr)
> + unsigned int nr,
> + unsigned long align_mask)
> {
> unsigned long index, end, i;
> again:
> index = find_next_zero_bit(map, size, start);
> +
> + /* Align allocation */
> + index = (index + align_mask) & ~align_mask;
> +
> end = index + nr;
> - if (end > size)
> + if (end >= size)
> return -1;
> - for (i = index + 1; i < end; i++) {
> + for (i = index; i < end; i++) {
> if (test_bit(i, map)) {
> start = i+1;
> goto again;
> @@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
> {
> unsigned long index;
> again:
> - index = find_next_zero_area(map, size, start, nr);
> + index = find_next_zero_area(map, size, start, nr, align_mask);
> if (index != -1) {
> - index = (index + align_mask) & ~align_mask;
> if (is_span_boundary(index, nr, shift, boundary_size)) {
> /* we could do more effectively */
> start = index + 1;
This on top of -mm? Or on top of the reverted iommu patch.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2007-12-28 7:48 UTC (permalink / raw)
To: balbir; +Cc: fujita.tomonori, linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <4774A74B.3000105@linux.vnet.ibm.com>
On Fri, 28 Dec 2007 13:05:39 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> FUJITA Tomonori wrote:
> [snip]
> > Thanks,
> >
> > Can you try this?
> >
> >
> > diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> > index e7d8544..495575a 100644
> > --- a/lib/iommu-helper.c
> > +++ b/lib/iommu-helper.c
> > @@ -8,15 +8,20 @@
> > static unsigned long find_next_zero_area(unsigned long *map,
> > unsigned long size,
> > unsigned long start,
> > - unsigned int nr)
> > + unsigned int nr,
> > + unsigned long align_mask)
> > {
> > unsigned long index, end, i;
> > again:
> > index = find_next_zero_bit(map, size, start);
> > +
> > + /* Align allocation */
> > + index = (index + align_mask) & ~align_mask;
> > +
> > end = index + nr;
> > - if (end > size)
> > + if (end >= size)
> > return -1;
> > - for (i = index + 1; i < end; i++) {
> > + for (i = index; i < end; i++) {
> > if (test_bit(i, map)) {
> > start = i+1;
> > goto again;
> > @@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
> > {
> > unsigned long index;
> > again:
> > - index = find_next_zero_area(map, size, start, nr);
> > + index = find_next_zero_area(map, size, start, nr, align_mask);
> > if (index != -1) {
> > - index = (index + align_mask) & ~align_mask;
> > if (is_span_boundary(index, nr, shift, boundary_size)) {
> > /* we could do more effectively */
> > start = index + 1;
>
> This on top of -mm? Or on top of the reverted iommu patch.
Oops, it's for -mm.
Thanks,
^ permalink raw reply
* Re: Device node - How does kernel know about it
From: Nicholas Mc Guire @ 2007-12-28 8:39 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7012AF958@corpexc01.corp.networkrobots.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> * Ramdisk is also executing fine, just that prints are not coming out of
> serial. I can see the execution of various user programs with a printk
> in sys_execve() routine. Ramdisk has all the required files like
> /dev/console, /dev/ttyS0, etc.
> * Looking further into tty driver, I noticed that call to tty_write() or
> do_tty_write() is not happening at all. So, somewhere the interface
> between kernel and user program is lost.
> * Just to check it out, I tried to write a small kernel module and a
> test program.
> - Attached memtest.c module (not really testing memory there. :-))
> - Attached testmemtest.c user program, that just open's it and reads
> the information
> - Created a device node using "mknod /dev/memtest c 168 0"
> - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I
> could see all the printk's on the console
> - When I execute "testmemtest" next in the same script, it does not
> display the printk inside of memtest.c module. This only indicates that
> read call did not really go to the kernel side.
> - Just to check my program's validity, I checked on a similar machine
> and all the code works fine.
> - "uname -r" also matches with what I built. So, chances of exiting
> from open call because of mismatch is remote. Since userland cannot
> print, I have no idea what exactly is happening there.
>
The kernel will simply look at the major:minor numbers - so maybe you
simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
see nothing but other than that most things will go on working.
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
hrfpn2RMn5l23ZqCOXV5rd8=
=GfsF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-12-28 9:28 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get two more bug-fixes that the Cell guys would like to see in
2.6.24 (and which only affect Cell). The changes are less than the
diffstat might indicate since a couple of functions got moved from one
file to another by the second commit listed below.
Thanks,
Paul.
arch/powerpc/platforms/cell/Kconfig | 5 ++
arch/powerpc/platforms/cell/Makefile | 1
arch/powerpc/platforms/cell/spu_notify.c | 67 ++++++++++++++++++++++++++
arch/powerpc/platforms/cell/spu_syscalls.c | 14 +++++
arch/powerpc/platforms/cell/spufs/context.c | 16 ------
arch/powerpc/platforms/cell/spufs/sched.c | 29 +++--------
arch/powerpc/platforms/cell/spufs/syscalls.c | 1
arch/powerpc/platforms/ps3/os-area.c | 40 ++++++++++++----
include/asm-powerpc/spu.h | 4 ++
9 files changed, 129 insertions(+), 48 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/spu_notify.c
commit ec5d2dfe72cf4808ae4ecee03454a4d91dfcbe0c
Author: Geoff Levand <geoffrey.levand@am.sony.com>
Date: Mon Dec 24 04:41:01 2007 +1100
[POWERPC] PS3: Fix printing of os-area magic numbers
Fix a bug in the printing of the os-area magic numbers which assumed
that magic numbers were zero terminated strings. The magic numbers
are represented in memory as integers. If the os-area sections are
not initialized correctly they could contained random data that would
be printed to the display. Also unify the handling of header and db
magic numbers and make both of type array of u8.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit aed3a8c9bb1a8623a618232087c5ff62718e3b9a
Author: Bob Nelson <rrnelson@linux.vnet.ibm.com>
Date: Sat Dec 15 01:27:30 2007 +1100
[POWERPC] Oprofile: Remove dependency on spufs module
This removes an OProfile dependency on the spufs module. This
dependency was causing a problem for multiplatform systems that are
built with support for Oprofile on Cell but try to load the oprofile
module on a non-Cell system.
Signed-off-by: Bob Nelson <rrnelson@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jean Delvare @ 2007-12-28 12:14 UTC (permalink / raw)
To: jonsmirl; +Cc: linuxppc-dev, i2c, linux-kernel
In-Reply-To: <9e4733910712270847j35778e43i66fda3eca9dc125@mail.gmail.com>
Hi John,
Le 27/12/2007, Jon Smirl =E9crit:
>On 12/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> Another rework of the i2c for powerpc device tree patch. This version impl=
ements standard alias naming only on the powerpc platform and only for the de=
vice tree names. The old naming mechanism of i2c_client.name,driver_name is l=
eft in place and not changed for non-powerpc platforms. This patch is fully c=
apable of dynamically loading the i2c modules. You can modprobe in the i2c-mp=
c driver and the i2c modules described in the device tree will be automatical=
ly loaded. Modules also work if compiled in.
>
>Are there any further objections to this patch? Can it all go in
>through the powerpc trees or do the i2c people want to send it on?
I am on vacation until January 4th. I will review your patchset the week
following my return.
Thanks for your patience,
--
Jean Delvare
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Josh Boyer @ 2007-12-28 13:25 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <47749548.8020908@pikatech.com>
On Fri, 28 Dec 2007 01:18:48 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> And one more thought, could uClibc be causing problems with the new
> kernel? It just seems strange that kernel "stuff" seems to work (e.g. no
> problems mounting a usbkey) yet a simple setjmp in a user mode app reeks
> havoc.
>
> We are going to be moving away from uClibc in the short term (I am the
> only one left using it). So if this could be an issue I might have to
> bite the bullet and switch now.
Does the setjmp call use floating point instructions? I'm wondering if
the APU isn't enabled for the FPU on the Yosemite board for some
reason. If that wasn't enabled, weird things would happen.
josh
^ permalink raw reply
* How can I support 2GB of memory in Linux kernel on 440SPe
From: Vincitore @ 2007-12-28 13:59 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I need to support 2GB of memory on a custom 440SPe board.
I see to support 1GB of memory on the 440SPe yucca board the following
configuration changes were done.
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
# CONFIG_CONSISTENT_START_BOOL is not set CONFIG_CONSISTENT_START=0xff100000
# CONFIG_CONSISTENT_SIZE_BOOL is not set
CONFIG_CONSISTENT_SIZE=0x00200000 # CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x01000000
It looks like the only thing I would need to do is modify the
following for 2GB support.
CONFIG_LOWMEM_SIZE=0x80000000
and
CONFIG_KERNEL_START=0x60000000
But this does not work. It almost does, but right after I get to the
Linux prompt, this system panics. If I scale back to one 1GB
everything works great.
Any ideas?
Thank You,
Vincitore
^ permalink raw reply
* [PATCH/RFC] Add support for PowerQUICC watchdog
From: Jochen Friedrich @ 2007-12-28 15:13 UTC (permalink / raw)
To: wim; +Cc: Scott Wood, linuxppc-dev, linux-kernel
The PowerQUICC series has a watchdog which can be activated by the boot
loader and then needs to be reset in regular intervals. Once the
watchdog is enabled, it can't be disabled anymore. This patch adds
support for this kind of watchdog. An early init function is provided to
manually reset the watchdog in early board setup. Later, a kernel timer
is used to reset the watchdog until the watchdog driver is opened from
user space. This replaces mpc8xx_wdt.c (only usable for ARCH=ppc) and
mpc83xx_wdt.c (untested on this platform).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 5 +
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 +
arch/powerpc/sysdev/Makefile | 3 +
arch/powerpc/sysdev/pq_wdt.c | 204 +++++++++++++++++++++++
arch/powerpc/sysdev/pq_wdt.h | 28 ++++
drivers/watchdog/Kconfig | 13 ++-
drivers/watchdog/Makefile | 1 +
drivers/watchdog/pq_wdt.c | 222 ++++++++++++++++++++++++++
8 files changed, 480 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/pq_wdt.c
create mode 100644 arch/powerpc/sysdev/pq_wdt.h
create mode 100644 drivers/watchdog/pq_wdt.c
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index 4901283..c468ec2 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -38,6 +38,7 @@
#include <asm/prom.h>
#include <sysdev/commproc.h>
+#include <sysdev/pq_wdt.h>
static void init_smc1_uart_ioports(struct fs_uart_platform_info* fpi);
static void init_smc2_uart_ioports(struct fs_uart_platform_info* fpi);
@@ -251,6 +252,10 @@ static void __init mpc86xads_setup_arch(void)
mpc86xads_board_setup();
ROOT_DEV = Root_NFS;
+
+#if defined(CONFIG_PQ_WDT) || defined(CONFIG_PQ_WDT_MODULE)
+ pq_wdt_early_init();
+#endif
}
static int __init mpc86xads_probe(void)
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..f076b67 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -41,6 +41,7 @@
#include <asm/udbg.h>
#include <sysdev/commproc.h>
+#include <sysdev/pq_wdt.h>
static u32 __iomem *bcsr, *bcsr5;
@@ -246,6 +247,10 @@ static void __init mpc885ads_setup_arch(void)
m8xx_pcmcia_ops.hw_ctrl = pcmcia_hw_setup;
m8xx_pcmcia_ops.voltage_set = pcmcia_set_voltage;
#endif
+
+#if defined(CONFIG_PQ_WDT) || defined(CONFIG_PQ_WDT_MODULE)
+ pq_wdt_early_init();
+#endif
}
static int __init mpc885ads_probe(void)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 99a77d7..84f190e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -35,5 +35,8 @@ obj-$(CONFIG_CPM) += cpm_common.o
obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
+ifneq ($(CONFIG_PQ_WDT),)
+obj-y += pq_wdt.o
+endif
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
endif
diff --git a/arch/powerpc/sysdev/pq_wdt.c b/arch/powerpc/sysdev/pq_wdt.c
new file mode 100644
index 0000000..0adbe42
--- /dev/null
+++ b/arch/powerpc/sysdev/pq_wdt.c
@@ -0,0 +1,204 @@
+/*
+ * pq_wdt.c - Freescale PowerQUICC watchdog driver
+ *
+ * Author: Florian Schirmer <jolt@tuxbox.org>
+ *
+ * 2002 (c) Florian Schirmer <jolt@tuxbox.org> This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * 2007 (c) Jochen Friedrich <jochen@scram.de> ported to ARCH=powerpc and
+ * extended to be useful on any Power QUICC 1/2/2pro which have the same
+ * style of watchdog.
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/sched.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <asm/irq.h>
+#include <asm/io.h>
+#include <asm/prom.h>
+
+#include "pq_wdt.h"
+
+struct pq_wdt {
+ __be32 res0;
+ __be32 swcrr; /* System watchdog control register */
+ __be32 swcnr; /* System watchdog count register */
+ u8 res1[2];
+ __be16 swsrr; /* System watchdog service register */
+};
+
+static int wdt_timeout;
+static int wdt_freq;
+static struct pq_wdt __iomem *wdt_reg;
+static int wdt_scale;
+
+void pq_wdt_reset(void)
+{
+ if (!wdt_reg)
+ return;
+
+ out_be16(&wdt_reg->swsrr, 0x556c); /* write magic1 */
+ out_be16(&wdt_reg->swsrr, 0xaa39); /* write magic2 */
+}
+EXPORT_SYMBOL(pq_wdt_reset);
+
+static void wdt_timer_func(unsigned long data);
+
+static struct timer_list wdt_timer =
+ TIMER_INITIALIZER(wdt_timer_func, 0, 0);
+
+void pq_wdt_stop_timer(void)
+{
+ del_timer(&wdt_timer);
+}
+EXPORT_SYMBOL_GPL(pq_wdt_stop_timer);
+
+void pq_wdt_install_timer(void)
+{
+ pq_wdt_reset();
+ mod_timer(&wdt_timer, jiffies + (HZ/2));
+}
+EXPORT_SYMBOL_GPL(pq_wdt_install_timer);
+
+static void wdt_timer_func(unsigned long data)
+{
+ pq_wdt_install_timer();
+}
+
+int pq_wdt_present(void)
+{
+ if (!wdt_reg)
+ return -ENODEV;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pq_wdt_present);
+
+int pq_wdt_get_timeout(void)
+{
+ return wdt_timeout / wdt_freq;
+}
+EXPORT_SYMBOL_GPL(pq_wdt_get_timeout);
+
+static int wdt_readparam(void)
+{
+ u32 swcrr;
+
+ if (!wdt_reg)
+ return -ENODEV;
+
+ wdt_timeout = 0;
+
+ swcrr = in_be32(&wdt_reg->swcrr);
+
+ if (!(swcrr & SWCRR_SWEN)) {
+ printk(KERN_NOTICE "pq_wdt: wdt disabled (SWCRR: 0x%08X)\n",
+ swcrr);
+ return -ENODEV;
+ }
+
+ pq_wdt_reset();
+
+ printk(KERN_NOTICE
+ "pq_wdt: active wdt found (SWTC: 0x%04X, SWP: 0x%01X)\n",
+ (swcrr >> 16), swcrr & 0x07);
+
+ wdt_timeout = (swcrr >> 16) & 0xFFFF;
+
+ if (!wdt_timeout)
+ wdt_timeout = 0xFFFF;
+
+ if (swcrr & SWCRR_SWPR)
+ wdt_timeout *= wdt_scale;
+
+ return 0;
+}
+
+int pq_wdt_setup(int value)
+{
+ if (!wdt_reg)
+ return -ENODEV;
+
+ out_be32(&wdt_reg->swcrr, value);
+ return wdt_readparam();
+}
+EXPORT_SYMBOL_GPL(pq_wdt_setup);
+
+int __init pq_wdt_init_timer(void)
+{
+ int ret;
+
+ if (!wdt_reg) {
+ ret = pq_wdt_early_init();
+ if (ret)
+ return ret;
+ }
+
+ if (!wdt_reg)
+ return -ENODEV;
+
+ pq_wdt_install_timer();
+ return 0;
+}
+arch_initcall(pq_wdt_init_timer);
+
+int __init pq_wdt_early_init(void)
+{
+ struct device_node *np, *soc;
+ int ret;
+ const u32 *data;
+
+ if (wdt_reg)
+ return 0;
+
+ wdt_scale = 2048;
+ np = of_find_compatible_node(NULL, NULL, "fsl,pq1-wdt");
+ if (np == NULL)
+ np = of_find_compatible_node(NULL, NULL, "fsl,pq2-wdt");
+ if (np == NULL) {
+ np = of_find_compatible_node(NULL, NULL, "fsl,pq2pro-wdt");
+ wdt_scale = 65536;
+ }
+ if (np == NULL) {
+ printk(KERN_ERR "Could not find fsl,pq1/2/2pro-wdt node\n");
+ return -ENODEV;
+ }
+
+ soc = of_find_node_by_type(NULL, "soc");
+ if (!soc) {
+ printk(KERN_ERR "Could not find soc node\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ data = of_get_property(soc, "bus-frequency", NULL);
+ if (!data) {
+ of_node_put(soc);
+ printk(KERN_ERR "Could not find bus-frequency in soc node\n");
+ ret = -ENODEV;
+ goto out;
+ }
+ of_node_put(soc);
+ wdt_freq = *data;
+
+ wdt_reg = of_iomap(np, 0);
+ if (wdt_reg == NULL) {
+ printk(KERN_ERR "Could not iomap wdt\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = wdt_readparam();
+ if (ret) {
+ iounmap(wdt_reg);
+ wdt_reg = NULL;
+ }
+out:
+ of_node_put(np);
+ return ret;
+}
diff --git a/arch/powerpc/sysdev/pq_wdt.h b/arch/powerpc/sysdev/pq_wdt.h
new file mode 100644
index 0000000..c5ca7bc
--- /dev/null
+++ b/arch/powerpc/sysdev/pq_wdt.h
@@ -0,0 +1,28 @@
+/*
+ * Author: Florian Schirmer <jolt@tuxbox.org>
+ *
+ * 2002 (c) Florian Schirmer <jolt@tuxbox.org> This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * 2007 (c) Jochen Friedrich <jochen@scram.de> ported to ARCH=powerpc and
+ * extended to be useful on any Power QUICC 1/2/2pro which have the same
+ * style of watchdog.
+ */
+#ifndef _POWERPC_SYSDEV_PQ_WDT_H
+#define _POWERPC_SYSDEV_PQ_WDT_H
+
+#define SWCRR_SWEN 0x00000004 /* Watchdog Enable bit. */
+#define SWCRR_SWRI 0x00000002 /* Software Watchdog Reset/Interrupt Select bit.*/
+#define SWCRR_SWPR 0x00000001 /* Software Watchdog Counter Prescale bit. */
+
+extern int pq_wdt_get_timeout(void);
+extern void pq_wdt_reset(void);
+extern void pq_wdt_install_timer(void);
+extern void pq_wdt_stop_timer(void);
+extern int pq_wdt_setup(int);
+extern int pq_wdt_present(void);
+extern int pq_wdt_early_init(void);
+
+#endif /* _POWERPC_SYSDEV_PQ_WDT_H */
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 52dff40..bc1c513 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -649,7 +649,18 @@ config MPC5200_WDT
config 8xx_WDT
tristate "MPC8xx Watchdog Timer"
- depends on 8xx
+ depends on 8xx && ! OF
+
+config PQ_WDT
+ tristate "Power QUICC Watchdog Timer"
+ depends on (8xx || PPC_82xx || PPC_83xx) && OF
+ default y
+ help
+ Watchdog driver for Power QUICC 1/2/2pro style watchdog drivers.
+ You should really select this unless your boot loader turns
+ off the watchdog. As the watchdog is turned on by default and
+ can be turned on/off only once after reboot, your board won't
+ run otherwise. Say 'M' if unsure.
config 83xx_WDT
tristate "MPC83xx Watchdog Timer"
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 87483cc..8005cc8 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_AR7_WDT) += ar7_wdt.o
# POWERPC Architecture
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
+obj-$(CONFIG_PQ_WDT) += pq_wdt.o
obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
diff --git a/drivers/watchdog/pq_wdt.c b/drivers/watchdog/pq_wdt.c
new file mode 100644
index 0000000..bb597e7
--- /dev/null
+++ b/drivers/watchdog/pq_wdt.c
@@ -0,0 +1,222 @@
+/*
+ * pq_wdt.c - Power QUICC watchdog userspace interface
+ *
+ * Author: Florian Schirmer <jolt@tuxbox.org>
+ *
+ * 2002 (c) Florian Schirmer <jolt@tuxbox.org> This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * 2007 (c) Jochen Friedrich <jochen@scram.de> renamed to pq_wdt.c and
+ * extended to be useful on any Power QUICC 1/2/2pro which have the same
+ * style of watchdog.
+ */
+
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/watchdog.h>
+#include <linux/of_platform.h>
+#include <asm/uaccess.h>
+#include <asm/io.h>
+#include <sysdev/pq_wdt.h>
+
+static unsigned long wdt_opened;
+static int wdt_status;
+
+static u16 timeout = 0xffff;
+module_param(timeout, ushort, 0);
+MODULE_PARM_DESC(timeout,
+ "Watchdog timeout in ticks. (0<timeout<65536, default=65535");
+
+static int reset = 1;
+module_param(reset, bool, 0);
+MODULE_PARM_DESC(reset,
+ "Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 = reset (default)");
+
+static int prescale = 1;
+
+static void pq_wdt_handler_disable(void)
+{
+ pq_wdt_stop_timer();
+
+ pr_debug("pq_wdt: keep-alive handler deactivated\n");
+}
+
+static void pq_wdt_handler_enable(void)
+{
+ pq_wdt_install_timer();
+
+ pr_debug("pq_wdt: keep-alive handler activated\n");
+}
+
+static int pq_wdt_open(struct inode *inode, struct file *file)
+{
+ u32 tmp = SWCRR_SWEN;
+
+ if (test_and_set_bit(0, &wdt_opened))
+ return -EBUSY;
+
+ pq_wdt_reset();
+
+ if (prescale)
+ tmp |= SWCRR_SWPR;
+ if (reset)
+ tmp |= SWCRR_SWRI;
+
+ tmp |= timeout << 16;
+
+ if (pq_wdt_setup(tmp))
+ return -EBUSY;
+
+#if defined(CONFIG_WATCHDOG_NOWAYOUT)
+ /* Once we start the watchdog we can't stop it */
+ __module_get(THIS_MODULE);
+#endif
+
+ pq_wdt_handler_disable();
+
+ return nonseekable_open(inode, file);
+}
+
+static int pq_wdt_release(struct inode *inode, struct file *file)
+{
+ pq_wdt_reset();
+
+#if !defined(CONFIG_WATCHDOG_NOWAYOUT)
+ pq_wdt_handler_enable();
+#endif
+
+ clear_bit(0, &wdt_opened);
+
+ return 0;
+}
+
+static ssize_t pq_wdt_write(struct file *file, const char *data, size_t len,
+ loff_t *ppos)
+{
+ if (len)
+ pq_wdt_reset();
+
+ return len;
+}
+
+static int pq_wdt_ioctl(struct inode *inode, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ int timeout;
+ static struct watchdog_info info = {
+ .options = WDIOF_KEEPALIVEPING,
+ .firmware_version = 0,
+ .identity = "PQ watchdog",
+ };
+
+ switch (cmd) {
+ case WDIOC_GETSUPPORT:
+ if (copy_to_user((void *)arg, &info, sizeof(info)))
+ return -EFAULT;
+ break;
+
+ case WDIOC_GETSTATUS:
+ case WDIOC_GETBOOTSTATUS:
+ if (put_user(wdt_status, (int *)arg))
+ return -EFAULT;
+ wdt_status &= ~WDIOF_KEEPALIVEPING;
+ break;
+
+ case WDIOC_GETTEMP:
+ return -EOPNOTSUPP;
+
+ case WDIOC_SETOPTIONS:
+ return -EOPNOTSUPP;
+
+ case WDIOC_KEEPALIVE:
+ pq_wdt_reset();
+ wdt_status |= WDIOF_KEEPALIVEPING;
+ break;
+
+ case WDIOC_SETTIMEOUT:
+ return -EOPNOTSUPP;
+
+ case WDIOC_GETTIMEOUT:
+ timeout = pq_wdt_get_timeout();
+ if (put_user(timeout, (int *)arg))
+ return -EFAULT;
+ break;
+
+ default:
+ return -ENOTTY;
+ }
+
+ return 0;
+}
+
+static const struct file_operations pq_wdt_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .write = pq_wdt_write,
+ .ioctl = pq_wdt_ioctl,
+ .open = pq_wdt_open,
+ .release = pq_wdt_release,
+};
+
+static struct miscdevice pq_wdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &pq_wdt_fops,
+};
+
+static int __devinit pq_wdt_probe(struct of_device *op, const struct of_device_id *match)
+{
+ int ret;
+
+ ret = pq_wdt_present();
+ if (ret)
+ return ret;
+
+ pq_wdt_handler_enable();
+
+ return misc_register(&pq_wdt_miscdev);
+}
+
+static int __devexit pq_wdt_remove(struct of_device *op)
+{
+ misc_deregister(&pq_wdt_miscdev);
+ return 0;
+}
+
+static struct of_device_id pq_wdt_match[] = {
+ { .compatible = "fsl,pq1-wdt", },
+ { .compatible = "fsl,pq2-wdt", },
+ { .compatible = "fsl,pq2pro-wdt", },
+ {},
+};
+
+static struct of_platform_driver pq_wdt_driver = {
+ .owner = THIS_MODULE,
+ .name = "pq-wdt",
+ .match_table = pq_wdt_match,
+ .probe = pq_wdt_probe,
+ .remove = pq_wdt_remove,
+};
+
+static int __init pq_wdt_moduleinit(void)
+{
+ return of_register_platform_driver(&pq_wdt_driver);
+}
+
+static void __exit pq_wdt_moduleexit(void)
+{
+ of_unregister_platform_driver(&pq_wdt_driver);
+}
+
+module_init(pq_wdt_moduleinit);
+module_exit(pq_wdt_moduleexit);
+
+MODULE_AUTHOR("Florian Schirmer <jolt@tuxbox.org>");
+MODULE_DESCRIPTION("PQ watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
--
1.5.3.7
^ 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