* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Marc Leeman @ 2007-06-11 16:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <d3c57096eec4553de180adab085d0145@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]
> > Poor guy trying to figure out the right way to do
> > his stuff will run away screaming and go back hard coding his number in
> > his platform code before we are finished :-)
>
> Heh I hope not.
Hm, I guess I took the dirty way suggested by Benjamin and having a look
at the CDS Freescale platform by copying the following in my platform
file:
static void __init mpc83xx_svc2_pcibios_fixup(void)
{
struct pci_dev *dev;
if ((dev = pci_get_device(VENDOR_ID_ALTERA,
DEVICE_ID_FPGA834XG1, NULL))) {
dev->irq = 23;
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 23);
pci_dev_put(dev);
}
/* Now map all the PCI irqs */
dev = NULL;
for_each_pci_dev(dev)
pci_read_irq_line(dev);
}
I am planning to have another look at the proper (tm) way to fix it, by
experimenting with my dts file; but since I need to get a number of
boards released, it's a bit pushed backwards.
What is more disturbing though, is that a number of operations on the
powerpc arch seems significantly slower wrt the ppc arch.
ioremap and iounmap being the most important one: we are using a small
driver that uses one of the UPMs in combination with GPIOs for HPI (Host
Port Interface) for TI DSPs.
Where the loading of a DSP took only 3 seconds, it went up to over a
minute on powerpc (same driver code).
Changing the driver to ioremap and unmap 0xe2400000 only once at driver
initialisation and unloading (not really relevant on this embedded
system, shame on me) instead twice for every word greatly improves the
time (around one second). However, this optimisation has the same effect
on ppc too :-/
Running the same application with the same modules on ppc and powerpc
(transferring data from the network to an FPGA) has a 50% higher load on
powerpc. The transfer is done with mapping user pages into the kernel
and DMA'ing them over PCI. What all driver have in common is that there
are quite some writes/reads to the IMMR configuration.
Decreasing the read and writes to the LBC for HPI (0xe2400000) seems to
improve the overall load.
So my question would be if I need to specify a special section in the
dts file for some reason; next to the U-Boot configuration that sends
writes to this address through the UPMB?
If not, is there any other reason that might account for these
significant performance drops?
--
greetz, marc
Aeryn, did I say or do anything to piss you off? I mean other than
caving in the side of your head?
Crichton - Die Me, Dichotomy
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux 2.6.x, MTD drivers and NAND flashes
From: Bill Gatliff @ 2007-06-11 15:59 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c7ac3c$15e7da80$5201a8c0@GEG2400>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Laurent Lagrange wrote:
> Hello,
>
> I use a Linux 2.6.9 on a 85xx custom board with a NAND flash.
>
> This flash has some bad blocks.
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB
> 3,3V 8-bit)
> Scanning device for bad blocks
> Bad eraseblock 8 at 0x00100000
> Bad eraseblock 430 at 0x035c0000
> ...
> Creating 1 MTD partitions on "NAND 128MiB 3,3V 8-bit":
> 0x00000000-0x08000000 : "flash partition 1".
>
> I have selected in the kernel :
> 1) the MTD character and block supports for NAND,
> 2) the CRAMFS and JFFS2 supports for NAND.
>
> I can erase the flash but receive IO errors for each bad blocks (that
> seems right).
> I can mount an empty JFFS2 partition on the NAND and untar some
> directories and files in it.
>
> I would like to generate some JFFS2 images and program them in the
> flash with a character
> command like "cat img > /dev/mtd/0". If I dont encounter a bad block,
> it runs right else the
> command fails.
>
> This is a little bit annoying. So my question is simple :
> Is there a MTD character driver which can detect and ignore the bad
> blocks in a NAND flash ?
Wrong question. :)
With NAND, working directly with the media is indeed a pain because of
bad blocks. What's done instead is to leave that to the filesystem.
Pick a NAND-aware one like YAFFS.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
[-- Attachment #2: Type: text/html, Size: 2835 bytes --]
^ permalink raw reply
* Re: a question for linux framebuffer driver
From: Grant Likely @ 2007-06-11 16:06 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20070611160313.B1A36DA8056@mail207-sin.bigfish.com>
On 6/11/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> The kernel has to be informed of the device itself using platform_device_register.
> I believe in the kernel you have you'll have to add code to do this, and
> /arch/ppc/platforms/4xx/virtex.c is a reasonable place.
In more recent kernels, look at arch/ppc/syslib/virtex_devices.c
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: a question for linux framebuffer driver
From: Stephen Neuendorffer @ 2007-06-11 16:03 UTC (permalink / raw)
To: silicom, linuxppc-embedded
In-Reply-To: <1316548361.5052161181391690811.JavaMail.coremail@bj163app129.163.com>
The kernel has to be informed of the device itself using =
platform_device_register.
I believe in the kernel you have you'll have to add code to do this, and =
/arch/ppc/platforms/4xx/virtex.c is a reasonable place.=20
Steve
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
> labs.org] On Behalf Of silicom
> Sent: Saturday, June 09, 2007 5:22 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: a question for linux framebuffer driver
>=20
> Hello,
> Now I'm porting framebuffer driver for ml403 in linux=20
> 2.6.171, but I find after registering the driver using=20
> driver_register function in xilinxfb_int, the=20
> xilinxfb_drv_probe function has not been called, so=20
> framebuffer not registered yet, no devices founded(but I have=20
> connected the monitor). I want to know when will=20
> xilinxfb_drv_probe be called?
>=20
> =20
> =20
> =20
>=20
>=20
> ________________________________
>=20
> 150 =CD=F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 =
=D3=CE=A3=AC=C4=E3 =B2=BB =CA=D4 =CA=D4 =C2=F0 =A3=BF=20
> <http://event.mail.163.com/chanel/xyq.htm?from=3D163_NO1>=20
>=20
^ permalink raw reply
* ioctl on 870 FEC causes "badness in local_bh_enable at kernel/softirq.c"
From: N. van Bolhuis @ 2007-06-11 15:44 UTC (permalink / raw)
To: linuxppc-embedded
I found a minor problem for the linux PPC PowerQuic_II FEC driver.
When doing an:
ioctl(.. SIOCGMIIREG ..) or
ioctl(.. SIOCSMIIREG ..)
the following kernel message pops up:
Badness in local_bh_enable at kernel/softirq.c:137
Call Trace:
[C102FC80] [C0008E04] (unreliable)
[C102FCA0] [C0003608]
[C102FCB0] [C0003EB0]
[C102FCD0] [C000310C]
[C102FD90] [C102FE40]
[C102FDA0] [C010794C]
[C102FDC0] [C01079C0]
[C102FDE0] [C010E7DC]
[C102FE00] [C01316C0]
[C102FE20] [C0132A08]
[C102FEA0] [C0126408]
[C102FEC0] [C0064B10]
[C102FEE0] [C0064F1C]
[C102FF10] [C0064F98]
[C102FF40] [C0002AC4]
This is because drivers/net/fs_enet/fs_enet-main.c:fs_ioctl
disables the interrupts with spin_lock_irqsave after which it calls
phy_mii_ioctl. This leads to drivers/net/phy/phy.c:phy_read
being called which does spin_lock_bh/spin_unlock_bh.
Obviously the spin_unlock_bh enables softirqs and it is correctly
complaining irqs are disabled.
fs_ioctl and phy_read are used by many others so I'm not sure
how to solve this. Therefore I ask this list.
Maybe fs_ioctl can use spin_(un)lock but I'm not sure.
Anybody has a fix or ideas about this ?
---
N. van Bolhuis.
--
This message has been scanned for viruses and is believed to be clean
^ permalink raw reply
* Linux 2.6.x, MTD drivers and NAND flashes
From: Laurent Lagrange @ 2007-06-11 15:20 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
Hello,
I use a Linux 2.6.9 on a 85xx custom board with a NAND flash.
This flash has some bad blocks.
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V
8-bit)
Scanning device for bad blocks
Bad eraseblock 8 at 0x00100000
Bad eraseblock 430 at 0x035c0000
...
Creating 1 MTD partitions on "NAND 128MiB 3,3V 8-bit":
0x00000000-0x08000000 : "flash partition 1".
I have selected in the kernel :
1) the MTD character and block supports for NAND,
2) the CRAMFS and JFFS2 supports for NAND.
I can erase the flash but receive IO errors for each bad blocks (that seems
right).
I can mount an empty JFFS2 partition on the NAND and untar some directories
and files in it.
I would like to generate some JFFS2 images and program them in the flash
with a character
command like "cat img > /dev/mtd/0". If I dont encounter a bad block, it
runs right else the
command fails.
This is a little bit annoying. So my question is simple :
Is there a MTD character driver which can detect and ignore the bad blocks
in a NAND flash ?
Thanks for any tips.
Bye
Laurent
[-- Attachment #2: Type: text/html, Size: 2693 bytes --]
^ permalink raw reply
* Re: [patch 09/18] PS3: System-bus rework
From: Geert Uytterhoeven @ 2007-06-11 15:45 UTC (permalink / raw)
To: Geoff Levand; +Cc: ppcdev, Milton Miller
In-Reply-To: <466D6CA7.3020709@am.sony.com>
On Mon, 11 Jun 2007, Geoff Levand wrote:
> Milton Miller wrote:
> >> --- a/arch/powerpc/platforms/ps3/mm.c
> >> +++ b/arch/powerpc/platforms/ps3/mm.c
> >> -#define DBG(fmt...) do{if(0)printk(fmt);}while(0)
> >> +#define DBG(fmt...) do { if (0) printk(fmt);} while (0)
> >
> > While there isn't a style guide for one line defines, while you're
> > adding spaces add one more after the ; before the } where a new line
> > would normally appear.
>
>
> I don't even like the original. I planned to replace it with the
> following, and will do so now.
>
> static inline int __attribute__ ((format (printf, 1, 2))) DBG(
> const char *fmt, ...) {return 0;}
We have the exact same definition (albeit with a different name, `pr_debug'),
in include/linux/kernel.h...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [patch 09/18] PS3: System-bus rework
From: Geoff Levand @ 2007-06-11 15:39 UTC (permalink / raw)
To: Milton Miller; +Cc: Geert Uytterhoeven, ppcdev
In-Reply-To: <c52d99b0071ef223a51612ce7d0cddea@bga.com>
Milton Miller wrote:
>> --- a/arch/powerpc/platforms/ps3/mm.c
>> +++ b/arch/powerpc/platforms/ps3/mm.c
>> -#define DBG(fmt...) do{if(0)printk(fmt);}while(0)
>> +#define DBG(fmt...) do { if (0) printk(fmt);} while (0)
>
> While there isn't a style guide for one line defines, while you're
> adding spaces add one more after the ; before the } where a new line
> would normally appear.
I don't even like the original. I planned to replace it with the
following, and will do so now.
static inline int __attribute__ ((format (printf, 1, 2))) DBG(
const char *fmt, ...) {return 0;}
>> + BUG_ON(!dev->bus_id);
>> + mutex_lock(&usage_hack.mutex);
>> +
>> + if(dev->bus_id == 1 && dev->dev_id == 1) {
>> + usage_hack.sb_11++;
>
> If you expect to leave this hack in for a while, how about adding a
> DEVICE_IS(dev, bus, device) macro?
A good idea!
-Geoff
^ permalink raw reply
* racy calls to platform_device_add_data after platform_device_register_simple
From: Milton Miller @ 2007-06-11 15:27 UTC (permalink / raw)
To: Mark Zhan; +Cc: ppcdev
On Fri Jun 8 18:54:38 EST 2007, Mark Zhan wrote:
> @@ -775,38 +774,42 @@ static int __init cpm_uart_of_init(void)
> + if (strstr(model, "SMC")) {
> + cpm_uart_dev =
> platform_device_register_simple("fsl-cpm-smc:uart",
> + i, &r[0], 3);
> + } else if (strstr(model, "SCC")) {
> + cpm_uart_dev =
> platform_device_register_simple("fsl-cpm-scc:uart",
> + i, &r[0], 3);
> + }
> +
> + if (IS_ERR(cpm_uart_dev)) {
> + ret = PTR_ERR(cpm_uart_dev);
> + goto err;
> + }
>
> + cpm_uart_data.uart_clk = ppc_proc_freq;
> cpm_uart_data.tx_num_fifo = 4;
> cpm_uart_data.tx_buf_size = 32;
> cpm_uart_data.rx_num_fifo = 4;
> @@ -816,10 +819,8 @@ static int __init cpm_uart_of_init(void)
> cpm_uart_data.clk_tx = *((u32 *)of_get_property(np,
> "tx-clock", NULL));
>
> - ret =
> - platform_device_add_data(cpm_uart_dev,
> &cpm_uart_data,
> - sizeof(struct
> -
> fs_uart_platform_info));
> + ret = platform_device_add_data(cpm_uart_dev,
> &cpm_uart_data,
> + sizeof(struct
> fs_uart_platform_info));
This code (and others like the ethernet code above it) is racy in that
the device is visible to the device layer without all of the data
needed by the driver. Since its being run as an arch_initcall, the
driver is not yet registered so its not quite a bug yet.
Since this seems to be appearing frequently as we add wrappers from the
device tree to the subsystem layer drivers, we should create an
extended function that takes a data pointer and size (NULL/zero would
mean none), and define platform_device_register_simple in terms of it.
milton
^ permalink raw reply
* Re: [PATCH] Add the support of ST M48T59 RTC chip in rtc-class driver subsystem
From: Milton Miller @ 2007-06-11 14:35 UTC (permalink / raw)
To: Mark Zhan; +Cc: ppcdev
In-Reply-To: <1181548600.5217.16.camel@mark>
On Mon Jun 11 17:56:40 EST 2007, Mark Zhan wrote:
> Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
> Wind River SBC PowerQUICCII 82xx board
...
> +#define M48T59_CNTL 0x1ff8
> +#define M48T59_WATCHDOG 0x1ff7
> +#define M48T59_INTR 0x1ff6
> +#define M48T59_ALARM_DATE 0x1ff5
> +#define M48T59_ALARM_HOUR 0x1ff4
> +#define M48T59_ALARM_MIN 0x1ff3
> +#define M48T59_ALARM_SEC 0x1ff2
> +#define M48T59_UNUSED 0x1ff1
> +#define M48T59_FLAGS 0x1ff0
> +
> +#define M48T59_WDAY_CB 0x20 /* Century Bit */
> +#define M48T59_WDAY_CEB 0x10 /* Century Enable Bit
> */
> +
> +#define M48T59_CNTL_READ 0x40;
> +#define M48T59_CNTL_WRITE 0x80;
> +
> +#define M48T59_FLAGS_WDT 0x80 /* watchdog timer expired */
> +#define M48T59_FLAGS_AF 0x40 /* alarm */
> +#define M48T59_FLAGS_BF 0x10 /* low battery */
> +
> +#define M48T59_INTR_AFE 0x80 /* Alarm Interrupt
> Enable */
> +#define M48T59_INTR_ABE 0x20
>
Another style is to put the flag and control register values
immediately after the register, indenting the values an additional tab
to distinguish them from the list of registers. Either way is ok with
me.
> +/**
> + * NOTE: M48T59 only uses BCD mode
> + */
> +static int m48t59_rtc_read_time(struct device *dev, struct rtc_time
> *tm)
> +{
> + unsigned char val;
> +
> + /* Issue the READ command */
> + M48T59_WRITE((M48T59_READ(M48T59_CNTL) | 0x40), M48T59_CNTL);
> +
...
> + /* Clear the READ bit to restore the update */
> + M48T59_WRITE((M48T59_READ(M48T59_CNTL) & ~0x40), M48T59_CNTL);
Should you clear READ and WRITE when your driver starts in case the
previous driver got interrupted (say the system crashed)? Or is it ok
for READ and WRITE to be set?
You aren't using the READ and WRITE flag bits you defined above. If
the line gets too long, you might create a SET_BITS / CLEAR_BITS macro.
milton
^ permalink raw reply
* RE: [PATCH 5/6]: 82xx: Add the support of Wind River SBC PowerQUICCII 82xx
From: Li Yang-r58472 @ 2007-06-11 13:51 UTC (permalink / raw)
To: Mark Zhan, paulus; +Cc: linuxppc-dev
In-Reply-To: <1181293043.11341.19.camel@mark>
{snip}
> diff --git a/arch/powerpc/platforms/82xx/sbcpq2.c
> b/arch/powerpc/platforms/82xx/sbcpq2.c
> new file mode 100644
> index 0000000..c459be4
> --- /dev/null
> +++ b/arch/powerpc/platforms/82xx/sbcpq2.c
> @@ -0,0 +1,306 @@
> +/*
> + * sbcpq2.c: The platform support for Wind River SBC PowerQUICCII
82xx
> + *
> + * Copyright 2007, Wind River Systems, Inc.
> + *
> + * Author: Mark Zhan <rongkai.zhan@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as published
by
> the
> + * Free Software Foundation; either version 2 of the License, or
(at
> your
> + * option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/pci.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/rtc.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/fsl_devices.h>
> +#include <linux/fs_uart_pd.h>
> +#include <linux/fs_enet_pd.h>
> +
> +#include <asm/prom.h>
> +#include <asm/machdep.h>
> +#include <asm/io.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/mpc8260.h>
> +#include <asm/cpm2.h>
> +#include <sysdev/cpm2_pic.h>
> +#include <asm/udbg.h>
> +#include <asm/i8259.h>
> +#include <asm/fs_pd.h>
> +
> +static struct resource m48t59_resources[] =3D {
> + {
> + .start =3D SBCPQ2_RTC_BASE,
> + .end =3D SBCPQ2_RTC_BASE + SBCPQ2_RTC_SIZE - 1,
> + .flags =3D IORESOURCE_MEM,
> + }, {
> + .start =3D SBCPQ2_M48T59_IRQ,
> + .end =3D SBCPQ2_M48T59_IRQ,
> + .flags =3D IORESOURCE_IRQ,
> + },
> + { },
> +};
> +
Shouldn't these come from device tree too?
Moreover, you can no longer use the hard coded IRQ numbers. They need
to be mapped to virtual irq, and the driver needs to use the virtual irq
number.
> +static struct platform_device m48t59_rtc =3D {
> + .name =3D "rtc-m48t59",
> + .id =3D 0,
> + .num_resources =3D 2,
> + .resource =3D m48t59_resources,
> +};
> +
> +static struct platform_device *sbcpq2_devices[] __initdata =3D {
> + &m48t59_rtc,
> +};
> +
> +/**
> + * sbcpq2_pdev_init - Register the platform device for sbcpq2 board
> + */
> +static int __init sbcpq2_platdev_init(void)
> +{
> + struct irq_desc *desc =3D irq_desc + SBCPQ2_M48T59_IRQ;
> +
> + /* Install a dummy irq chip for M48T59 RTC irq */
> + if (desc->chip =3D=3D &no_irq_chip)
> + set_irq_handler(SBCPQ2_M48T59_IRQ, desc->handle_irq);
> +
> + /* Register all platform devices for sbcpq2 */
> + platform_add_devices(sbcpq2_devices,
ARRAY_SIZE(sbcpq2_devices));
> + return 0;
> +}
> +arch_initcall(sbcpq2_platdev_init);
> +
{snip}
> diff --git a/arch/powerpc/platforms/82xx/sbcpq2.h
> b/arch/powerpc/platforms/82xx/sbcpq2.h
> new file mode 100644
> index 0000000..77b7ca6
> --- /dev/null
> +++ b/arch/powerpc/platforms/82xx/sbcpq2.h
> @@ -0,0 +1,118 @@
> +/*
> + * sbcpq2.h: the header file for Wind River SBC PowerQUICCII 82xx
> + *
> + * Copyright (C) 2007, Wind River Systems, Inc.
> + * Mark Zhan, <rongkai.zhan@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as published
by
> the
> + * Free Software Foundation; either version 2 of the License, or
(at
> your
> + * option) any later version.
> + */
> +
> +#ifndef __MACH_SBCPQ2_H
> +#define __MACH_SBCPQ2_H
> +
> +#include <asm/ppcboot.h>
> +
> +/* For our show_cpuinfo hooks. */
> +#define CPUINFO_VENDOR "Wind River"
> +#define CPUINFO_MACHINE "SBC PowerQUICCII 82xx"
> +
I don't believe the following are necessary. New MTD mapping should be
defined in device tree.
> +/*
> + * Wind River SBC PowerQUICCII 82xx Physical Memory Map (CS0 for
> OnBoard Flash)
> + *
> + * 0x00000000 - 0x07FFFFFF CS2, 128 MB DIMM SDRAM
> + * 0x08000000 - 0x0FFFFFFF CS3, 128 MB DIMM SDRAM
> + * 0x12000000 - 0x12100000 CS8, ATM
> + * 0x20000000 - 0x20FFFFFF CS4, 16 MB Local Bus SDRAM
> + * 0x21000000 - 0x21001FFF CS7, Control EPLD
> + * 0x22000000 - 0x22001FFF CS5, 8KB EEPROM
> + * 0x22002000 - 0x22003FFF CS5, visionPORT
> + * 0x22004000 - 0x22005FFF CS5, User Switches
> + * 0x22006000 - 0x22007FFF CS5, STATUS
> + * 0x22008000 - 0x22009FFF CS5, i8259 interrupt controller
> + * 0x2200A000 - 0x2200BFFF CS5, LED (Seven Segment Display)
> + * 0x80000000 - 0x80001FFF CS11, RTC
> + * 0xE0000000 - 0xE3FFFFFF CS6, 64 MB DIMM Flash
> + * 0xE4000000 - 0xE7FFFFFF CS1, 64 MB DIMM Flash
> + * 0xFE000000 - 0xFFFFFFFF CS0, 2 MB Boot Flash
> + * 0xF0000000 - 0xF0020000 MPC82xx Internal Registers Space
> + */
> +#define SBCPQ2_SDRAM_BASE 0x00000000
> +#define SBCPQ2_SDRAM_SIZE 0x10000000
> +
> +#define SBCPQ2_LOCAL_SDRAM_BASE 0x20000000
> +#define SBCPQ2_LOCAL_SDRAM_SIZE 0x1000000
> +
> +#define SBCPQ2_EPLD_BASE 0x21000000
> +#define SBCPQ2_EPLD_SIZE 0x2000
> +
> +#define SBCPQ2_EEPROM_BASE 0x22000000
> +#define SBCPQ2_EEPROM_SIZE 0x2000
> +
> +/* User Switches SW5 */
> +#define SBCPQ2_USER_SW_BASE 0x22004000
> +#define SBCPQ2_USER_SW_SIZE 0x2000
> +
> +#define SBCPQ2_STATUS_BASE 0x22006000
> +#define SBCPQ2_STATUS_SIZE 0x2000
> +
> +#define SBCPQ2_I8259_BASE 0x22008000
> +#define SBCPQ2_I8259_SIZE 0x2000
> +
> +/* Seven Segment Display LED D46 */
> +#define SBCPQ2_LED_BASE 0x2200A000
> +#define SBCPQ2_LED_SIZE 0x2000
> +
> +#define SBCPQ2_RTC_BASE 0x80000000
> +#define SBCPQ2_RTC_SIZE 0x2000
> +
> +#define SBCPQ2_BOOT_FLASH_BASE 0xFE000000
> +#define SBCPQ2_BOOT_FLASH_SIZE 0x00200000
> +
> +#define SBCPQ2_DIMM_FLASH_BASE 0xE0000000
> +#define SBCPQ2_DIMM_FLASH_SIZE 0x04000000
> +
> +#define CPM_MAP_ADDR 0xF0000000
> +#define CPM_IRQ_OFFSET 0
> +
> +/*
> + * The offset of ethernet MAC addr within EEPROM
> + */
> +#define SBCPQ2_FCC1_MACADDR_OFS 0x60
> +#define SBCPQ2_FCC2_MACADDR_OFS 0x66
> +#define SBCPQ2_FCC3_MACADDR_OFS 0x72
> +#define SBCPQ2_SCC1_MACADDR_OFS 0x78
> +
> +/*
> + * The interrupt of M48T59 RTC chip will generate
> + * a machine check exception. We use a fake irq
> + * to get the platform machine_check_exception() hook
> + * have a chance to call the driver ISR.
> + */
> +#define SBCPQ2_M48T59_IRQ (NR_IRQS-1)
> +
> +/*
> + * The following IRQs are routed to i8259 PIC.
> + *
> + * NOTE: i8259 PIC is cascaded to SIU_INT_IRQ6 of CPM2 interrupt
> controller
> + */
> +#define SBCPQ2_PC_IRQA (NR_SIU_INTS+0)
> +#define SBCPQ2_PC_IRQB (NR_SIU_INTS+1)
> +#define SBCPQ2_MPC185_IRQ (NR_SIU_INTS+2)
> +#define SBCPQ2_ATM_IRQ (NR_SIU_INTS+3)
> +#define SBCPQ2_PIRQA (NR_SIU_INTS+4)
> +#define SBCPQ2_PIRQB (NR_SIU_INTS+5)
> +#define SBCPQ2_PIRQC (NR_SIU_INTS+6)
> +#define SBCPQ2_PIRQD (NR_SIU_INTS+7)
> +
> +/* cpm serial driver works with constants below */
> +#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
> +#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
> +#define SIU_INT_SCC1 ((uint)0x28+CPM_IRQ_OFFSET)
> +#define SIU_INT_SCC2 ((uint)0x29+CPM_IRQ_OFFSET)
> +#define SIU_INT_SCC3 ((uint)0x2a+CPM_IRQ_OFFSET)
> +#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
> +
> +#endif /* __MACH_SBCPQ2_H */
> diff --git a/arch/powerpc/boot/dts/sbcpq2.dts
> b/arch/powerpc/boot/dts/sbcpq2.dts
> new file mode 100644
> index 0000000..cdcf780
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/sbcpq2.dts
> @@ -0,0 +1,191 @@
> +/*
> + * Wind River SBC PowerQUICCII 82xx Device Tree Source
> + *
> + * Copyright 2007, Wind River Systems, Inc.
> + * Mark Zhan <rongkai.zhan@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as published
by
> the
> + * Free Software Foundation; either version 2 of the License, or
(at
> your
> + * option) any later version.
> + *
> + * Build with: dtc -f -I dts -O dtb -o sbcpq2.dtb -V 16 sbcpq2.dts
> + */
> +
> +/ {
> + model =3D "SBCPQ2";
> + compatible =3D "mpc82xx";
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + linux,phandle =3D <100>;
> +
> + cpus {
> + #cpus =3D <1>;
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + linux,phandle =3D <200>;
> +
> + PowerPC,8260@0 {
> + device_type =3D "cpu";
> + reg =3D <0>;
> + d-cache-line-size =3D <20>; // 32 bytes
> + i-cache-line-size =3D <20>; // 32 bytes
> + d-cache-size =3D <4000>; // L1, 16K
> + i-cache-size =3D <4000>; // L1, 16K
> + timebase-frequency =3D <0>; /* =3D
(bus-frequency / 4) */
> + bus-frequency =3D <0>; /* =3D
bd->bi_busfreq */
> + clock-frequency =3D <0>; /* =3D
bd->bi_intfreq =3D gd->cpu_clk */
> + 32-bit;
> + linux,phandle =3D <201>;
> + };
> + };
> +
> + memory {
> + device_type =3D "memory";
> + linux,phandle =3D <300>;
> + /* 256MB DIMM SDRAM & 16MB Local Bus SDRAM */
> + reg =3D <00000000 10000000 20000000 01000000>;
> + };
> +
> + soc8260@f0000000 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + #interrupt-cells =3D <2>;
> + device_type =3D "soc";
> + ranges =3D <00000000 f0000000 00020000>;
> + reg =3D <f0000000 00020000>;
> + bus-frequency =3D <0>; /* from u-boot */
> +
> + cpm@f0000000 {
> + linux,phandle =3D <f0000000>;
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + #interrupt-cells =3D <2>;
> + device_type =3D "cpm";
> + model =3D "CPM2";
> + ranges =3D <00000000 00000000 00020000>;
> + reg =3D <0 00020000>;
> + command-proc =3D <0>; /* from u-boot */
> + brg-frequency =3D <0>; /* from u-boot */
> + cpm_clk =3D <0>; /* from u-boot */
> +
> + smc@11a80 {
> + device_type =3D "serial";
> + compatible =3D "cpm_uart";
> + model =3D "SMC";
> + device-id =3D <1>;
> + reg =3D <11a80 10 0 40>;
> + rx-clock =3D <1>;
> + tx-clock =3D <1>;
> + interrupts =3D <4 2>;
> + interrupt-parent =3D <10c00>;
Use < &interrupt-controller > as interrupt-parent instead.
- Leo
^ permalink raw reply
* Re: [PATCH] dtc: parse NOP in dtb input
From: Jon Loeliger @ 2007-06-11 13:41 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, david
In-Reply-To: <311814492916b8b45674.846930886.miltonm@bga.com>
So, like, the other day Milton Miller mumbled:
> Version 16 and later of the flat device tree format allow NOPs
> to be placed in the tree. When processing dtb input, dtc must
> recognise them.
>
> Previously it would produce the error message
> FATAL ERROR: Invalid opcode word 00000004 in device tree blob
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Add the support of ST M48T59 RTC chip in rtc-class driver subsystem
From: Gabriel Paubert @ 2007-06-11 12:11 UTC (permalink / raw)
To: Mark Zhan; +Cc: a.zummo, rtc-linux, linuxppc-dev@ozlabs.org
In-Reply-To: <1181548600.5217.16.camel@mark>
On Mon, Jun 11, 2007 at 03:56:40PM +0800, Mark Zhan wrote:
> Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
> Wind River SBC PowerQUICCII 82xx board
>
There are other boards which have exactly the same chip, but use
a very different (uglier) access method: using ISA 2 I/O ports
(0x74 and 0x75) to write the address and another port (0x77) to
read/write the data.
Besides that, these boards also use the NVRAM part which means that
a spinlock must be used to serialize between RTC and NVRAM access.
I have no idea whether the drivers should be shared or two
different drivers should be written... But if there are two
different drivers, there should be a way to distinguish them
(different config name, different module names, and some
explanation in the config help text).
> Signed-off-by: Mark Zhan <rongkai.zhan@windriver.com>
> ---
> b/drivers/rtc/Kconfig | 10 +
> b/drivers/rtc/Makefile | 1
> b/drivers/rtc/rtc-m48t59.c | 360
> +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 371 insertions(+)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 4e4c10a..ca6a064 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -329,6 +329,16 @@ config RTC_DRV_S3C
> This driver can also be build as a module. If so, the module
> will be called rtc-s3c.
>
> +config RTC_DRV_M48T59
> + tristate "ST M48T59"
> + depends on RTC_CLASS
> + help
> + If you say Y here you will get support for the
> + ST M48T59 RTC chip.
> +
> + This driver can also be built as a module, if so, the module
> + will be called "rtc-m48t59".
> +
> config RTC_DRV_EP93XX
> tristate "Cirrus Logic EP93XX"
> depends on RTC_CLASS && ARCH_EP93XX
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index a1afbc2..70ba581 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -41,3 +41,4 @@ obj-$(CONFIG_RTC_DRV_V3020) += rtc-v3020
> obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
> obj-$(CONFIG_RTC_DRV_SH) += rtc-sh.o
> obj-$(CONFIG_RTC_DRV_BFIN) += rtc-bfin.o
> +obj-$(CONFIG_RTC_DRV_M48T59) += rtc-m48t59.o
> diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> new file mode 100644
> index 0000000..0737827
> --- /dev/null
> +++ b/drivers/rtc/rtc-m48t59.c
> @@ -0,0 +1,360 @@
> +/*
> + * ST M48T59 RTC driver
> + *
> + * Copyright (c) 2007 Wind River Systems, Inc.
> + *
> + * Author: Mark Zhan <rongkai.zhan@windriver.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/rtc.h>
> +#include <linux/platform_device.h>
> +#include <linux/bcd.h>
> +
> +#define DEBUG_M48T59 1
> +
> +#ifdef DEBUG_M48T59
> +#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: "fmt,
> __FUNCTION__, ##args)
> +#else
> +#define DPRINTK(fmt, args...)
> +#endif
> +
> +#define M48T59_YEAR 0x1fff
> +#define M48T59_MONTH 0x1ffe
> +#define M48T59_MDAY 0x1ffd /* Day of Month */
> +#define M48T59_WDAY 0x1ffc /* Day of Week */
> +#define M48T59_HOUR 0x1ffb
> +#define M48T59_MIN 0x1ffa
> +#define M48T59_SEC 0x1ff9
> +#define M48T59_CNTL 0x1ff8
> +#define M48T59_WATCHDOG 0x1ff7
> +#define M48T59_INTR 0x1ff6
> +#define M48T59_ALARM_DATE 0x1ff5
> +#define M48T59_ALARM_HOUR 0x1ff4
> +#define M48T59_ALARM_MIN 0x1ff3
> +#define M48T59_ALARM_SEC 0x1ff2
> +#define M48T59_UNUSED 0x1ff1
> +#define M48T59_FLAGS 0x1ff0
> +
> +#define M48T59_WDAY_CB 0x20 /* Century Bit */
> +#define M48T59_WDAY_CEB 0x10 /* Century Enable Bit */
> +
> +#define M48T59_CNTL_READ 0x40;
> +#define M48T59_CNTL_WRITE 0x80;
> +
> +#define M48T59_FLAGS_WDT 0x80 /* watchdog timer expired */
> +#define M48T59_FLAGS_AF 0x40 /* alarm */
> +#define M48T59_FLAGS_BF 0x10 /* low battery */
> +
> +#define M48T59_INTR_AFE 0x80 /* Alarm Interrupt Enable */
> +#define M48T59_INTR_ABE 0x20
> +
> +static unsigned char * m48t59_vbase = NULL;
> +static unsigned int m48t59_irq = -1;
Shouldn't it be NO_IRQ (here and in several other places) ?
Regards,
Gabriel
^ permalink raw reply
* [PATCH] Add the support of ST M48T59 RTC chip in rtc-class driver subsystem
From: Mark Zhan @ 2007-06-11 7:56 UTC (permalink / raw)
To: a.zummo; +Cc: linuxppc-dev@ozlabs.org, rtc-linux
Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
Wind River SBC PowerQUICCII 82xx board
Signed-off-by: Mark Zhan <rongkai.zhan@windriver.com>
---
b/drivers/rtc/Kconfig | 10 +
b/drivers/rtc/Makefile | 1
b/drivers/rtc/rtc-m48t59.c | 360
+++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 371 insertions(+)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 4e4c10a..ca6a064 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -329,6 +329,16 @@ config RTC_DRV_S3C
This driver can also be build as a module. If so, the module
will be called rtc-s3c.
+config RTC_DRV_M48T59
+ tristate "ST M48T59"
+ depends on RTC_CLASS
+ help
+ If you say Y here you will get support for the
+ ST M48T59 RTC chip.
+
+ This driver can also be built as a module, if so, the module
+ will be called "rtc-m48t59".
+
config RTC_DRV_EP93XX
tristate "Cirrus Logic EP93XX"
depends on RTC_CLASS && ARCH_EP93XX
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index a1afbc2..70ba581 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -41,3 +41,4 @@ obj-$(CONFIG_RTC_DRV_V3020) += rtc-v3020
obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
obj-$(CONFIG_RTC_DRV_SH) += rtc-sh.o
obj-$(CONFIG_RTC_DRV_BFIN) += rtc-bfin.o
+obj-$(CONFIG_RTC_DRV_M48T59) += rtc-m48t59.o
diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
new file mode 100644
index 0000000..0737827
--- /dev/null
+++ b/drivers/rtc/rtc-m48t59.c
@@ -0,0 +1,360 @@
+/*
+ * ST M48T59 RTC driver
+ *
+ * Copyright (c) 2007 Wind River Systems, Inc.
+ *
+ * Author: Mark Zhan <rongkai.zhan@windriver.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/rtc.h>
+#include <linux/platform_device.h>
+#include <linux/bcd.h>
+
+#define DEBUG_M48T59 1
+
+#ifdef DEBUG_M48T59
+#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: "fmt,
__FUNCTION__, ##args)
+#else
+#define DPRINTK(fmt, args...)
+#endif
+
+#define M48T59_YEAR 0x1fff
+#define M48T59_MONTH 0x1ffe
+#define M48T59_MDAY 0x1ffd /* Day of Month */
+#define M48T59_WDAY 0x1ffc /* Day of Week */
+#define M48T59_HOUR 0x1ffb
+#define M48T59_MIN 0x1ffa
+#define M48T59_SEC 0x1ff9
+#define M48T59_CNTL 0x1ff8
+#define M48T59_WATCHDOG 0x1ff7
+#define M48T59_INTR 0x1ff6
+#define M48T59_ALARM_DATE 0x1ff5
+#define M48T59_ALARM_HOUR 0x1ff4
+#define M48T59_ALARM_MIN 0x1ff3
+#define M48T59_ALARM_SEC 0x1ff2
+#define M48T59_UNUSED 0x1ff1
+#define M48T59_FLAGS 0x1ff0
+
+#define M48T59_WDAY_CB 0x20 /* Century Bit */
+#define M48T59_WDAY_CEB 0x10 /* Century Enable Bit */
+
+#define M48T59_CNTL_READ 0x40;
+#define M48T59_CNTL_WRITE 0x80;
+
+#define M48T59_FLAGS_WDT 0x80 /* watchdog timer expired */
+#define M48T59_FLAGS_AF 0x40 /* alarm */
+#define M48T59_FLAGS_BF 0x10 /* low battery */
+
+#define M48T59_INTR_AFE 0x80 /* Alarm Interrupt Enable */
+#define M48T59_INTR_ABE 0x20
+
+static unsigned char * m48t59_vbase = NULL;
+static unsigned int m48t59_irq = -1;
+
+#define M48T59_READ(reg) readb(m48t59_vbase+reg)
+#define M48T59_WRITE(val, reg) writeb((val), (m48t59_vbase+reg))
+
+/**
+ * NOTE: M48T59 only uses BCD mode
+ */
+static int m48t59_rtc_read_time(struct device *dev, struct rtc_time
*tm)
+{
+ unsigned char val;
+
+ /* Issue the READ command */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) | 0x40), M48T59_CNTL);
+
+ tm->tm_year = BCD2BIN(M48T59_READ(M48T59_YEAR));
+ /* tm_mon is 0-11 */
+ tm->tm_mon = BCD2BIN(M48T59_READ(M48T59_MONTH)) - 1;
+ tm->tm_mday = BCD2BIN(M48T59_READ(M48T59_MDAY));
+
+ val = M48T59_READ(M48T59_WDAY);
+ if ((val & M48T59_WDAY_CEB) && (val & M48T59_WDAY_CB)) {
+ DPRINTK("Century bit is enabled\n");
+ tm->tm_year += 100; /* one century */
+ }
+
+ tm->tm_wday = BCD2BIN(val & 0x07);
+ tm->tm_hour = BCD2BIN(M48T59_READ(M48T59_HOUR) & 0x3F);
+ tm->tm_min = BCD2BIN(M48T59_READ(M48T59_MIN) & 0x7F);
+ tm->tm_sec = BCD2BIN(M48T59_READ(M48T59_SEC) & 0x7F);
+
+ /* Clear the READ bit to restore the update */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) & ~0x40), M48T59_CNTL);
+
+ DPRINTK("RTC read time %04d-%02d-%02d %02d/%02d/%02d\n",
+ tm->tm_year + 1900, tm->tm_mon, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+ return 0;
+}
+
+static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ unsigned char val = 0;
+
+ DPRINTK("RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
+ tm->tm_year + 1900, tm->tm_mon, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+ /* Issue the WRITE command */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) | 0x80), M48T59_CNTL);
+
+ M48T59_WRITE((BIN2BCD(tm->tm_sec) & 0x7F), M48T59_SEC);
+ M48T59_WRITE((BIN2BCD(tm->tm_min) & 0x7F), M48T59_MIN);
+ M48T59_WRITE((BIN2BCD(tm->tm_hour) & 0x3F), M48T59_HOUR);
+ M48T59_WRITE((BIN2BCD(tm->tm_mday) & 0x3F), M48T59_MDAY);
+ /* tm_mon is 0-11 */
+ M48T59_WRITE((BIN2BCD(tm->tm_mon + 1) & 0x1F), M48T59_MONTH);
+ M48T59_WRITE(BIN2BCD(tm->tm_year % 100), M48T59_YEAR);
+
+ if (tm->tm_year/100)
+ val = (M48T59_WDAY_CEB | M48T59_WDAY_CB);
+ val |= (BIN2BCD(tm->tm_wday) & 0x07);
+ M48T59_WRITE(val, M48T59_WDAY);
+
+ /* update ended */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) & ~0x80), M48T59_CNTL);
+
+ return 0;
+}
+
+/*
+ * Read alarm time and date in RTC
+ */
+static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm
*alrm)
+{
+ unsigned char val;
+ struct rtc_time *tm = &alrm->time;
+
+ /* If no irq, we don't support ALARM */
+ if (m48t59_irq == -1)
+ return -EIO;
+
+ /* Issue the READ command */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) | 0x40), M48T59_CNTL);
+
+ tm->tm_year = BCD2BIN(M48T59_READ(M48T59_YEAR));
+ /* tm_mon is 0-11 */
+ tm->tm_mon = BCD2BIN(M48T59_READ(M48T59_MONTH)) - 1;
+
+ val = M48T59_READ(M48T59_WDAY);
+ if ((val & M48T59_WDAY_CEB) && (val & M48T59_WDAY_CB))
+ tm->tm_year += 100; /* one century */
+
+ tm->tm_mday = BCD2BIN(M48T59_READ(M48T59_ALARM_DATE));
+ tm->tm_hour = BCD2BIN(M48T59_READ(M48T59_ALARM_HOUR));
+ tm->tm_min = BCD2BIN(M48T59_READ(M48T59_ALARM_MIN));
+ tm->tm_sec = BCD2BIN(M48T59_READ(M48T59_ALARM_SEC));
+
+ /* Clear the READ bit to restore the update */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) & ~0x40), M48T59_CNTL);
+
+ DPRINTK("RTC read alarm time %04d-%02d-%02d %02d/%02d/%02d\n",
+ tm->tm_year + 1900, tm->tm_mon, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+ return 0;
+}
+
+/*
+ * Set alarm time and date in RTC
+ */
+static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm
*alrm)
+{
+ struct rtc_time *tm = &alrm->time;
+ unsigned char mday, hour, min, sec;
+
+ if (m48t59_irq == -1)
+ return -EIO;
+
+ /*
+ * 0xff means "always match"
+ */
+ mday = tm->tm_mday;
+ mday = (mday >= 1 && mday <= 31) ? BIN2BCD(mday) : 0xff;
+ if (mday == 0xff)
+ mday = M48T59_READ(M48T59_MDAY);
+
+ hour = tm->tm_hour;
+ hour = (hour < 24) ? BIN2BCD(hour) : 0x00;
+
+ min = tm->tm_min;
+ min = (min < 60) ? BIN2BCD(min) : 0x00;
+
+ sec = tm->tm_sec;
+ sec = (sec < 60) ? BIN2BCD(sec) : 0x00;
+
+ /* Issue the WRITE command */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) | 0x80), M48T59_CNTL);
+
+ M48T59_WRITE(mday, M48T59_ALARM_DATE);
+ M48T59_WRITE(hour, M48T59_ALARM_HOUR);
+ M48T59_WRITE(min, M48T59_ALARM_MIN);
+ M48T59_WRITE(sec, M48T59_ALARM_SEC);
+
+ /* update ended */
+ M48T59_WRITE((M48T59_READ(M48T59_CNTL) & ~0x80), M48T59_CNTL);
+
+ DPRINTK("RTC set alarm time %04d-%02d-%02d %02d/%02d/%02d\n",
+ tm->tm_year + 1900, tm->tm_mon, tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec);
+ return 0;
+}
+
+/*
+ * Handle commands from user-space
+ */
+static int m48t59_rtc_ioctl(struct device *dev, unsigned int cmd,
+ unsigned long arg)
+{
+ int ret = 0;
+
+ switch (cmd) {
+ case RTC_AIE_OFF: /* alarm interrupt off */
+ M48T59_WRITE(0x00, M48T59_INTR);
+ break;
+ case RTC_AIE_ON: /* alarm interrupt on */
+ M48T59_WRITE(M48T59_INTR_AFE, M48T59_INTR);
+ break;
+ default:
+ ret = -ENOIOCTLCMD;
+ break;
+ }
+
+ return ret;
+}
+
+static int m48t59_rtc_proc(struct device *dev, struct seq_file *seq)
+{
+ unsigned char val;
+
+ val = M48T59_READ(M48T59_FLAGS);
+ seq_printf(seq, "battery\t\t: %s\n",
+ (val & M48T59_FLAGS_BF) ? "low" : "normal");
+
+ return 0;
+}
+
+/*
+ * IRQ handler for the RTC
+ */
+static irqreturn_t m48t59_rtc_interrupt(int irq, void *dev_id)
+{
+ unsigned char flags;
+ struct platform_device *pdev = (struct platform_device *)dev_id;
+ struct rtc_device *rdev;
+
+ flags = M48T59_READ(M48T59_FLAGS);
+ if (flags & M48T59_FLAGS_AF) {
+ rdev = (struct rtc_device *)platform_get_drvdata(pdev);
+ rtc_update_irq(rdev, 1, (RTC_AF | RTC_IRQF));
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
+static const struct rtc_class_ops m48t59_rtc_ops = {
+ .ioctl = m48t59_rtc_ioctl,
+ .read_time = m48t59_rtc_read_time,
+ .set_time = m48t59_rtc_set_time,
+ .read_alarm = m48t59_rtc_readalarm,
+ .set_alarm = m48t59_rtc_setalarm,
+ .proc = m48t59_rtc_proc,
+};
+
+static int __devinit m48t59_rtc_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct rtc_device *rtc_dev;
+ int ret = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ m48t59_vbase = ioremap(res->start, (res->end - res->start + 1));
+ if (!m48t59_vbase)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res)
+ m48t59_irq = res->start;
+
+ if (m48t59_irq != -1) {
+ ret = request_irq(m48t59_irq, m48t59_rtc_interrupt,
+ IRQF_SHARED, "rtc-m48t59", pdev);
+ if (ret)
+ goto err_unmap;
+ }
+
+ rtc_dev = rtc_device_register("m48t59", &pdev->dev,
+ &m48t59_rtc_ops, THIS_MODULE);
+ if (IS_ERR(rtc_dev)) {
+ ret = PTR_ERR(rtc_dev);
+ goto err_freeirq;
+ }
+
+ platform_set_drvdata(pdev, rtc_dev);
+ return 0;
+
+err_freeirq:
+ if (m48t59_irq != -1)
+ free_irq(m48t59_irq, pdev);
+err_unmap:
+ iounmap(m48t59_vbase);
+ return ret;
+}
+
+static int __devexit m48t59_rtc_remove(struct platform_device *pdev)
+{
+ struct rtc_device *rtc = platform_get_drvdata(pdev);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ platform_set_drvdata(pdev, NULL);
+
+ if (m48t59_vbase)
+ iounmap(m48t59_vbase);
+ m48t59_vbase = NULL;
+
+ if (m48t59_irq != -1)
+ free_irq(m48t59_irq, pdev);
+ m48t59_irq = -1;
+ return 0;
+}
+
+static struct platform_driver m48t59_rtc_platform_driver = {
+ .driver = {
+ .name = "rtc-m48t59",
+ .owner = THIS_MODULE,
+ },
+ .probe = m48t59_rtc_probe,
+ .remove = __devexit_p(m48t59_rtc_remove),
+};
+
+static int __init m48t59_rtc_init(void)
+{
+ return platform_driver_register(&m48t59_rtc_platform_driver);
+}
+
+static void __exit m48t59_rtc_exit(void)
+{
+ platform_driver_unregister(&m48t59_rtc_platform_driver);
+}
+
+module_init(m48t59_rtc_init);
+module_exit(m48t59_rtc_exit);
+
+MODULE_AUTHOR("Mark Zhan <rongkai.zhan@windriver.com>");
+MODULE_DESCRIPTION("M48T59 RTC driver");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* [PATCH] MII bitbang driver should generate MII bus phy_mask dynamically
From: Mark Zhan @ 2007-06-11 7:53 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev@ozlabs.org, Vitaly Bordug
Current MII bitbang bus driver hard-codes the phy mask of mii_bus to
~0x09, which is actually specific to the FSL boards. This patch will
make the bitbang driver to generate MII bus phy_mask dynamically, by the
PHY irq info provided by the platform.
Signed-off-by: Mark Zhan <rongkai.zhan@windriver.com>
---
b/drivers/net/fs_enet/mii-bitbang.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fs_enet/mii-bitbang.c
b/drivers/net/fs_enet/mii-bitbang.c
index d384010..3732d69 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -315,7 +315,7 @@ static int __devinit fs_enet_mdio_probe(
struct fs_mii_bb_platform_info *pdata;
struct mii_bus *new_bus;
struct bb_info *bitbang;
- int err = 0;
+ int i, err = 0;
if (NULL == dev)
return -EINVAL;
@@ -336,14 +336,17 @@ static int __devinit fs_enet_mdio_probe(
new_bus->reset = &fs_enet_mii_bb_reset,
new_bus->id = pdev->id;
- new_bus->phy_mask = ~0x9;
pdata = (struct fs_mii_bb_platform_info *)pdev->dev.platform_data;
-
if (NULL == pdata) {
printk(KERN_ERR "gfar mdio %d: Missing platform data!\n", pdev->id);
return -ENODEV;
}
+ new_bus->phy_mask = 0xFFFFFFFF;
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ if (pdata->irq[i] != -1)
+ new_bus->phy_mask &= ~(1 << i);
+
/*set up workspace*/
fs_mii_bitbang_init(bitbang, pdata);
^ permalink raw reply related
* Re: [rtc-linux] [PATCH] Add the support of ST M48T59 RTC chip in rtc-class driver subsystem
From: Alessandro Zummo @ 2007-06-11 11:25 UTC (permalink / raw)
To: rtc-linux; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1181548600.5217.16.camel@mark>
On Mon, 11 Jun 2007 15:56:40 +0800
Mark Zhan <rongkai.zhan@windriver.com> wrote:
>
> Add the support of ST M48T59 RTC chip driver in RTC class subsystem for
> Wind River SBC PowerQUICCII 82xx board
Hello Mark, thanks for you contribution. Code looks
good, I only have some minor comments:
>
> +config RTC_DRV_M48T59
> + tristate "ST M48T59"
> + depends on RTC_CLASS
> + help
> + If you say Y here you will get support for the
> + ST M48T59 RTC chip.
> +
> + This driver can also be built as a module, if so, the module
> + will be called "rtc-m48t59".
Please add some infos about the Wind River board in the help.
> +
> +#ifdef DEBUG_M48T59
> +#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: "fmt,
> __FUNCTION__, ##args)
> +#else
> +#define DPRINTK(fmt, args...)
> +#endif
please use standard device debugging/reporting functions
> +
> +static unsigned char * m48t59_vbase = NULL;
> +static unsigned int m48t59_irq = -1;
those shouldn't be globals. please see other drivers for suggestions
on encapsulation.
> +static int m48t59_rtc_proc(struct device *dev, struct seq_file *seq)
> +{
> + unsigned char val;
> +
> + val = M48T59_READ(M48T59_FLAGS);
> + seq_printf(seq, "battery\t\t: %s\n",
> + (val & M48T59_FLAGS_BF) ? "low" : "normal");
> +
> + return 0;
> +}
this is going to be deprecated, you can use it but it will fade away
sooner or later. you might want to add a sysfs attribute
with the battery info.
thanks.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Making fs_enet phy unaware
From: DI BACCO ANTONIO - technolabs @ 2007-06-11 10:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
how can I avoid that fs_enet driver uses its associated phy? My problem
is that my FEC is attached to a switch and three other ports of the
switch are connected to three physical connectors. I don't want that the
driver bothers about the PHYs.=20
^ permalink raw reply
* Re: Question on nfsroot shared by multiple targets
From: Ajit Singh @ 2007-06-11 10:26 UTC (permalink / raw)
To: Johan Borkhuis
Cc: linuxppc-embedded-bounces+ajit.singh=vihaannetworks.com,
linuxppc-embedded
In-Reply-To: <466D0C56.3080804@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]
Johan,
The way i had done it was creating a read only partition for the / (root)
filesystem. The /var partition was the only one created seperately for the
different mounted systems. The additional work done was to have a /var/etc
with the links made from the /etc directory for the files that need change
across the system. The entries softlink and if any file ctreation was done
in the rcS scripts. It would take a bit of time, but it works.
regards
Ajit
Vihaan Networks Limited | 246, Phase - IV, Udyog Vihar, Gurgoan , PIN
122015, Haryana, India, Phone: +91-124-4311712, Fax: +91-124-4104766 |
www.vihaannetworks.com
DISCLAIMER This message and any attachment therewith is privileged,
confidential and proprietary in nature and the property of the originator.
It is intended solely and exclusively for use by the individual to whom it
is addressed. It should not be circulated or used for any purpose other
than for what is stated. If you have received this message erroneously,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message and are
called upon to delete the same from your system. Any contradictory action
by you may invite penal consequences. Vihaan Networks Ltd. accepts no
responsibility for loss or damage arising from the use of the information
transmitted by this email including but not limited to damage from virus."
Johan Borkhuis <j.borkhuis@dutchspace.nl>
Sent by:
linuxppc-embedded-bounces+ajit.singh=vihaannetworks.com@ozlabs.org
06/11/07 02:18 PM
To
linuxppc-embedded@ozlabs.org
cc
Subject
Question on nfsroot shared by multiple targets
Hello,
I have the following setup: one server, with DHCP server and NFS-root
for an embedded target. With one target this works OK, but now I want to
add another target. The problem I see is that both targets are going to
write into the same logfiles and lockfiles.
I did setup the DHCP server in such a way that the NFS-root of the
target points to /nfsroot/<last octet of IP address>. But for this to
work I need a copy of the complete tree for each target board. I would
prefer to have only one tree for all targets, as this saves the effort
of keeping all trees in sync.
I could create a smaller NFS-root per target, with only /etc, /var and
some other directories and mount-points and mount all directories from a
central nfsroot using the local fstab in /etc. This could work for /var,
but I would still need to keep /etc in sync.
Is there another way to do this, or is this the correct way to setup a
multi-target system?
Kind regards,
Johan Borkhuis
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3908 bytes --]
^ permalink raw reply
* Question on nfsroot shared by multiple targets
From: Johan Borkhuis @ 2007-06-11 8:48 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have the following setup: one server, with DHCP server and NFS-root
for an embedded target. With one target this works OK, but now I want to
add another target. The problem I see is that both targets are going to
write into the same logfiles and lockfiles.
I did setup the DHCP server in such a way that the NFS-root of the
target points to /nfsroot/<last octet of IP address>. But for this to
work I need a copy of the complete tree for each target board. I would
prefer to have only one tree for all targets, as this saves the effort
of keeping all trees in sync.
I could create a smaller NFS-root per target, with only /etc, /var and
some other directories and mount-points and mount all directories from a
central nfsroot using the local fstab in /etc. This could work for /var,
but I would still need to keep /etc in sync.
Is there another way to do this, or is this the correct way to setup a
multi-target system?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Using xgpio
From: Thomas Johnson @ 2007-06-11 8:49 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
Hi,
Can anyone give me an example of using the xgpio on an ML403 using
Montavista Linux.
I can see the driver uses ioctl but this only seems to be able to set
the io direction, and I am not clear how to use this, for instance how
do I turn one of the led's on/off or read the GPIO_SW's.
Many thanks.
Tom Johnson
[-- Attachment #2: Type: text/html, Size: 1307 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] 82xx: Add the support of Wind River SBC PowerQUICCII 82xx
From: Mark Zhan @ 2007-06-11 7:59 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev@ozlabs.org, paulus@samba.org
In-Reply-To: <20070609192516.092ff1b6@vitb.ru.mvista.com>
Hi Vitaly,
Since you will cover this issue, so I will remove this chunk from my
patch, and re-submit my patches.
Thanks
Mark Zhan
On Sat, 2007-06-09 at 19:25 +0400, Vitaly Bordug wrote:
> On Fri, 08 Jun 2007 16:54:38 +0800
> Mark Zhan <rongkai.zhan@windriver.com> wrote:
>
> > snprintf((char*)&bus_id[(*id)], BUS_ID_SIZE, "%x:%02x",
> > - (u32)res.start, fs_enet_data.phy_addr);
> > + fs_enet_dev->id, fs_enet_data.phy_addr);
> > +
> > fs_enet_data.bus_id = (char*)&bus_id[(*id)];
>
> Have to admit this is not correct. The issue is in fs_enet code (which should take mdio bus id, not device id), and I'll cover it.
>
^ permalink raw reply
* Re: [patch 00/18] PS3 patches for 2.6.23
From: Milton Miller @ 2007-06-11 7:08 UTC (permalink / raw)
To: Geoff Levand; +Cc: Geert Uytterhoeven, ppcdev
In-Reply-To: <466622FA.7030200@am.sony.com>
On Wed Jun 6 12:59:06 EST 2007, Geoff Levand wrote:
> Here is a series I have for 2.6.23.
>
> Patches 1-8 are more or less independent of each other.
> Patches 9-18 are a dependent series of my system bus
> rework patches.
I'm repling to the summary but will pull a few points from the series.
The dependent series is currently split per file. While this makes it
easier to see what a given area looks like after all the patches, it
means that the kernel compile will break during the series. Breaking
git bisect is frowned upon, so it will need to be re-split for merge.
(Or disable the ps3 system bus during the merge of the series).
> [09/18] PS3: System-bus rework
> [10/18] PS3: System-bus uevent
> [11/18] PS3: System-bus modinfo attribute
If you define a module device table and add it to
scripts/bin/file2alias.c you would not need to create the MOD_ALIAS_xxx
driver defines.
Should your module alias and matching include the device_type?
Rather than setting core.owner = THIS_MODULE, take the
pci_driver_register approach where __pci_driver_register takes the
module name and owner id as arguments that are automatically passed by
a macro.
> [12/18] PS3: Repository probe cleanups
> [13/18] PS3: USB system-bus rework
> [14/18] PS3: vuart rework
This changes vuart_device->core from struct_device to ps3 system
device, but doesn't update the drivers.
> [15/18] PS3: sys-manager re-work
> [16/18] PS3: Rework AV settings driver
There are several dev_debug() that still use vuart_device.core not
.core.core.
Maybe vuart_device.core should be renamed?
The probe routine assigns to the global ps3av without checking if its
already set. If a second device caused probe to be called the
references to the first one would be lost.
> [17/18] PS3: frame buffer system-bus rework
> [18/18] PS3: Device registration routines.
ps3_start_probe_thread should add at least the bus_type to the thread
name (the thread name is a sprintf va_list format arg; you don't need
to create a temporary string buffer).
milton
^ permalink raw reply
* Re: [patch 09/18] PS3: System-bus rework
From: Milton Miller @ 2007-06-11 7:07 UTC (permalink / raw)
To: Geoff Levand; +Cc: Geert Uytterhoeven, ppcdev
In-Reply-To: <4666234B.2020208@am.sony.com>
On Wed Jun 6 13:00:27 EST 2007, Geoff Levand wrote:
> Rework the PS3 system bus to unify device support.
> - DMA region sizes must be a power of two
> - storage bus DMA updates:
> - Small fixes for the PS3 DMA core:
> o fix alignment bug
> o kill superfluous test
> o indentation
> o spelling
> o export ps3_dma_region_{create,free}()
> - ps3_dma_region_init():
> o Add `addr' and `len' parameters, so you can create a DMA
> region that
> does not cover all memory (use `NULL' and `0' to cover all
> memory).
> This is needed because there are not sufficient IOMMU
> resources to have
> all DMA regions cover all memory.
> o Uninline
> - Added remove and shutdown routines to all to all drivers.
That'd be all y'all .
Oh, wait, changelogs are not ususally in Texan. :-)
> - Added loadable module support to all drivers.
> - Added HV calls for iopte management (needed by sound driver).
>
Just a quick scan through :
> --- a/arch/powerpc/platforms/ps3/mm.c
> +++ b/arch/powerpc/platforms/ps3/mm.c
> -#define DBG(fmt...) do{if(0)printk(fmt);}while(0)
> +#define DBG(fmt...) do { if (0) printk(fmt);} while (0)
While there isn't a style guide for one line defines, while you're
adding spaces add one more after the ; before the } where a new line
would normally appear.
> + BUG_ON(!dev->bus_id);
> + mutex_lock(&usage_hack.mutex);
> +
> + if(dev->bus_id == 1 && dev->dev_id == 1) {
> + usage_hack.sb_11++;
If you expect to leave this hack in for a while, how about adding a
DEVICE_IS(dev, bus, device) macro?
milton
^ permalink raw reply
* Re: [PATCH] Create add_rtc() function to enable the RTC CMOS driver
From: Milton Miller @ 2007-06-11 7:06 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: ppcdev
In-Reply-To: <1181147873.5674.116.camel@rhino>
On Thu Jun 7 02:37:53 EST 2007, Wade Farnsworth wrote:
No changelog, just the subject?
> ---
>
> arch/powerpc/kernel/setup-common.c | 31 +++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> Index: linux-2.6-powerpc-8641/arch/powerpc/kernel/setup-common.c
> ===================================================================
> --- linux-2.6-powerpc-8641.orig/arch/powerpc/kernel/setup-common.c
> +++ linux-2.6-powerpc-8641/arch/powerpc/kernel/setup-common.c
A driver specific ifdef in setup-common?
Please put this in a file in sysdev. Possibly linked on the config
with the existing ifdef, if you can't find a related file.
> @@ -32,6 +32,7 @@
> #include <linux/unistd.h>
> #include <linux/serial.h>
> #include <linux/serial_8250.h>
> +#include <linux/mc146818rtc.h>
> #include <asm/io.h>
> #include <asm/prom.h>
> #include <asm/processor.h>
> @@ -447,6 +448,36 @@ static __init int add_pcspkr(void)
> }
> device_initcall(add_pcspkr);
Oh, we already did this with the pc speaker?
I stand by my first impression. Although one could argue its similar
in scope to check_legacy_io_port, probe_machine is totally unrelated
and between pc speaker and check legacy io port. At least the grouping
of these functions in the file should be cleaned up.
> +#ifdef CONFIG_RTC_DRV_CMOS
> +static int __init add_rtc(void)
> +{
> + struct device_node *np;
> + struct platform_device *pd;
> + struct resource res;
> +
> + np = of_find_compatible_node(NULL, NULL, "pnpPNP,b00");
> + if (!np)
> + return -ENODEV;
> +
> + if (of_address_to_resource(np, 0, &res)) {
> + of_node_put(np);
> + return -ENODEV;
> + }
> +
Ok you have found a resource, but not mapped it.
> + pd = platform_device_register_simple("rtc_cmos", -1,
> + &res, 1);
> + of_node_put(np);
> + if (IS_ERR(pd))
> + return PTR_ERR(pd);
> +
> + /* rtc-cmos only supports 24-hr mode */
> + CMOS_WRITE(CMOS_READ(RTC_CONTROL) | RTC_24H, RTC_CONTROL);
> +
But now you invoke a macro from somewhere, which would appear to write
to the device. Probably with some hard-coded isa port, as it doesn't
take any obvious device or resource argument.
Is this writing to the legacy io port? What mapped that resource?
If the driver only works with the standard port, then should you check
the resource is that standard port? Or does the compatibility also
dictate the resource, in which case assigning the resource is
redundant.
This is after the device register, so the platform driver might think
it owns the device. Or it my be off doing its own initialization. Or
the driver subsystem may have requested the platform device be loaded,
and it has not run at all (assuming it can be a module for the moment).
> + return 0;
> +}
> +device_initcall(add_rtc);
> +#endif /* CONFIG_RTC_DRV_CMOS */
> +
> void probe_machine(void)
> {
> extern struct machdep_calls __machine_desc_start;
>
milton
^ permalink raw reply
* linux kernel BUG REPORT "/usr/src/linux-2.6.11.7/drivers/ide/ppc/pmac.c"
From: stewart midgley @ 2007-06-11 4:23 UTC (permalink / raw)
To: linuxppc-dev
(1) One line summary: Occasional problem with hard disk access, that
kills an iBookG4, but is fixed by rebooting
(2) Full description: Occasional error with the following kernel message
> EXT3-fs error device hda17 in start_transaction : Journal has aborted
The /var partition is mounted on /dev/hda17
The machine will not respond, acknowledging key board commands but cant
execute code (e.g., /sbin/sync or /sbin/shutdown -r now), with
complaints that I forgot to write down. Problem fixed by rebooting, but
all unsaved data is lost. We speculated about hard disk failure and
consulted the web. A link suggested looking at
/usr/src/linux-2.6.11.7/drivers/ide/ppc/pmac.c, and I find the following
clues in /var/log/messages (at the time of the last failure).
> Jun 7 04:02:11 l-cl27-g41-a logrotate: ALERT exited abnormally with [1]
> Jun 8 04:02:11 l-cl27-g41-a logrotate: ALERT exited abnormally with [1]
> Jun 8 15:49:39 l-cl27-g41-a kernel: ide-pmac lost interrupt, dma
status: 8480
> Jun 8 15:49:39 l-cl27-g41-a kernel: hda: lost interrupt
> Jun 8 15:49:39 l-cl27-g41-a kernel: hda: dma_intr: status=0xd0 { Busy }
> Jun 8 15:49:39 l-cl27-g41-a kernel:
> Jun 8 15:49:39 l-cl27-g41-a kernel: ide: failed opcode was: unknown
> Jun 8 15:49:39 l-cl27-g41-a kernel: hda: DMA disabled
> Jun 8 15:49:55 l-cl27-g41-a kernel: ide0: reset: success
> Jun 8 17:24:48 localhost syslogd 1.4.1: restart.
> Jun 8 17:24:48 localhost syslog: syslogd startup succeeded
(3) Key words: drivers, ide, ppc pmac.c
(4) cat /proc/version
Linux version 2.6.11.7 (root@w-cl27-g41-aa.spme.monash.edu.au) (gcc
version 3.3.3 (Yellow Dog Linux 3.3.3-16.ydl.4)) #1 Wed Apr 27 10:16:03
EST 2005
rnel version
(5) Not an Oops problem
(6) Problem creation script: N/A, an infrequent problem
(7) Environment information
(7.1) Software is Yellow Dog linux 4.0
script ver_linux finds
Linux l-cl27-g41-a.physics.monash.edu.au 2.6.11.7 #1 Wed Apr 27
10:16:03 EST 2005 ppc ppc ppc GNU/Linux
Gnu C 3.3.3
Gnu make 3.80
binutils 2.15.90
util-linux 2.12pre
mount 2.12pre
module-init-tools 2.4.26
e2fsprogs 1.35
reiserfsprogs line
reiser4progs line
pcmcia-cs 3.2.7
quota-tools 3.10.
PPP 2.4.2
isdn4k-utils 3.3
nfs-utils 1.0.6
Linux C Library 2.3.3
Dynamic linker (ldd) 2.3.3
Procps 3.2.0
Net-tools 1.60
Kbd 1.12
Sh-utils 5.2.1
./ver_linux: line 90: udevinfo: command not found
Modules Loaded ipx p8022 psnap llc sg ohci1394 ieee1394 sd_mod
scsi_mod vfat fat
(7.2) cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 1066MHz
revision : 1.1 (pvr 8003 0101)
bogomips : 1060.86
machine : PowerBook6,5
motherboard : PowerBook6,5 MacRISC3 Power Macintosh
detected as : 287 (iBook G4)
pmac flags : 0000001b
L2 cache : 512K unified
memory : 768MB
pmac-generation : NewWorld
(7.3) cat /proc/modules
ipx 28188 0 - Live 0xf21ee000
p8022 1792 1 ipx, Live 0xf21df000
psnap 3460 1 ipx, Live 0xf1032000
llc 6460 2 p8022,psnap, Live 0xf21e1000
sg 34916 0 - Live 0xf20f6000
ohci1394 35716 0 - Live 0xf1075000
ieee1394 106984 1 ohci1394, Live 0xf21c1000
sd_mod 15120 0 - Live 0xf1028000
scsi_mod 137404 2 sg,sd_mod, Live 0xf2401000
vfat 12736 0 - Live 0xf102d000
fat 41468 1 vfat, Live 0xf1061000
(7.4) cat /proc/modules
ipx 28188 0 - Live 0xf21ee000
p8022 1792 1 ipx, Live 0xf21df000
psnap 3460 1 ipx, Live 0xf1032000
llc 6460 2 p8022,psnap, Live 0xf21e1000
sg 34916 0 - Live 0xf20f6000
ohci1394 35716 0 - Live 0xf1075000
ieee1394 106984 1 ohci1394, Live 0xf21c1000
sd_mod 15120 0 - Live 0xf1028000
scsi_mod 137404 2 sg,sd_mod, Live 0xf2401000
vfat 12736 0 - Live 0xf102d000
fat 41468 1 vfat, Live 0xf1061000
[root@l-cl27-g41-a scripts]# cat /proc/ioports
00000000-007fffff : /pci@f2000000
00802000-01001fff : /pci@f0000000
00802400-008024ff : 0000:00:10.0
00802400-008024ff : radeonfb
ff7fe000-ffffdfff : /pci@f4000000
cat /proc/iomem
80000000-8fffffff : /pci@f2000000
80000000-8007ffff : 0001:10:17.0
80000000-8007ffff : 0.80000000:mac-io
80000050-8000007f : 0.00000050:gpio
80008000-800080ff : 0.00010000:i2s
80008000-800080ff : i2s-a (tx dma)
80008100-800081ff : 0.00010000:i2s
80008100-800081ff : i2s-a (rx dma)
80008200-800082ff : 0.00010000:i2s
80008300-800083ff : 0.00010000:i2s
80008800-800088ff : 0.00020000:ata-3
80008800-800088ff : ide-pmac (dma)
80010000-80010fff : 0.00010000:i2s
80010000-80010fff : i2s-a
80013000-80013000 : 0.00013000:ch-b
80013010-80013010 : 0.00013000:ch-b
80013020-80013020 : 0.00013020:ch-a
80013030-80013030 : 0.00013020:ch-a
80013040-80013040 : 0.00013000:ch-b
80013050-80013050 : 0.00013020:ch-a
80015000-80015fff : 0.00015000:timer
80016000-80017fff : 0.00016000:via-pmu
80016000-80017fff : via-pmu
80018000-80018fff : 0.00018000:i2c
80020000-80020fff : 0.00020000:ata-3
80020000-80020fff : ide-pmac (ports)
80040000-8007ffff : interrupt-controller
80040000-8007ffff : 0.00040000:interrup
80080000-800800ff : 0001:10:1b.2
80080000-800800ff : ehci_hcd
80081000-80081fff : 0001:10:1b.1
80081000-80081fff : ohci_hcd
80082000-80082fff : 0001:10:1b.0
80082000-80082fff : ohci_hcd
80083000-80083fff : 0001:10:1a.0
80083000-80083fff : ohci_hcd
90000000-9fffffff : /pci@f0000000
90000000-9000ffff : 0000:00:10.0
90000000-9000ffff : radeonfb
98000000-9fffffff : 0000:00:10.0
98000000-9fffffff : radeonfb
f1000000-f1ffffff : /pci@f0000000
f1000000-f101ffff : 0000:00:10.0
f3000000-f3ffffff : /pci@f2000000
f5000000-f5ffffff : /pci@f4000000
f5000000-f5000fff : 0002:20:0e.0
f5000000-f50007ff : ohci1394
f5004000-f5007fff : 0002:20:0d.0
f5004000-f5007fff : Kauai ATA
f5200000-f53fffff : 0002:20:0f.0
f5200000-f53fffff : sungem
f8000000-f8ffffff : uni-n
(7.5) /sbin/lspci -vvv
00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 16, Cache Line Size 08
Capabilities: [80] AGP version 1.0
Status: RQ=8 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x1
00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV280
[Radeon Mobility 9200 M9+] (rev 01) (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Radeon RV280 [Radeon Mobility
9200 M9+]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 255 (2000ns min), Cache Line Size 08
Interrupt: pin A routed to IRQ 48
Region 0: Memory at 0000000098000000 (32-bit, prefetchable)
[size=00000000f1000000]
Region 1: I/O ports at 802400 [size=256]
Region 2: Memory at 0000000090000000 (32-bit, non-prefetchable)
[size=64K]
Expansion ROM at 0000000000020000 [disabled]
Capabilities: [58] AGP version 2.0
Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=8 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW-
Rate=x1
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 16, Cache Line Size 08
0001:10:17.0 Class ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16, Cache Line Size 08
Region 0: Memory at 0000000080000000 (32-bit, non-prefetchable)
0001:10:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
(prog-if 10 [OHCI])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
(prog-if 10 [OHCI])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
(prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (750ns min, 21500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 29
Region 0: Memory at 0000000080083000 (32-bit, non-prefetchable)
0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10
[OHCI])
Subsystem: NEC Corporation USB
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (250ns min, 10500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 63
Region 0: Memory at 0000000080082000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10
[OHCI])
Subsystem: NEC Corporation USB
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (250ns min, 10500ns max), Cache Line Size 08
Interrupt: pin B routed to IRQ 63
Region 0: Memory at 0000000080081000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if
20 [EHCI])
Subsystem: NEC Corporation USB 2.0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16 (4000ns min, 8500ns max), Cache Line Size 08
Interrupt: pin C routed to IRQ 63
Region 0: Memory at 0000000080080000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0002:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 16, Cache Line Size 08
0002:20:0d.0 Class ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 32, Cache Line Size 08
Interrupt: pin ? routed to IRQ 39
Region 0: Memory at 00000000f5004000 (32-bit, non-prefetchable)
0002:20:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2
FireWire (rev 81) (prog-if 10 [OHCI])
Subsystem: Apple Computer Inc.: Unknown device 5811
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (3000ns min, 6000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 40
Region 0: Memory at 00000000f5000000 (32-bit, non-prefetchable)
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC
(Sun GEM) (rev 80)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 16 (16000ns min, 16000ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 41
Region 0: Memory at 00000000f5200000 (32-bit, non-prefetchable)
[size=00000000f5100000]
Expansion ROM at 0000000000100000 [disabled]
(7.6) cat /proc/scsi/scsi
Attached devices:
(7.7) Other relevant information:
Hi Paul, Benjamin and helpers,
I found your names in the code and among list of maintainers.
Perhaps you already fixed this and I need to upgrade my 2 year old kernel?
regards
Stewart
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr Stewart Midgley
Instrumentation Group,
Monash Centre for Synchrotron Science,
Monash University, Clayton, VIC 3800
Room 111, Building 26
ph: +61 3 9905 9350 fax: +61 3 9905 3637
email: stewart.midgley@sync.monash.ed.au
http://www.sync.monash.edu.au/instgroup/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox