* Hi, friends, the question about the core frequency on u-boot and device tree?
From: 郭劲 @ 2008-03-13 6:38 UTC (permalink / raw)
To: support.asia, linuxppc-embedded, u-boot-users
HI,friends,
The core frequency and bus frequency and QE frequency on MPC8360 are configed
during the loading of HRCW and the CLKIN or PCI_CLKIN, in the u-boot-1.2.0, I can
use the "clocks" command to show all kind of frequecy,at this time the core
frequency is 528MHZ. please see follow:
=> clocks
Clock configuration Guo Jing:
Core: 528 MHz
Coherent System Bus: 264 MHz
QE: 396 MHz
BRG: 198 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
SEC: 88 MHz
I2C1: 264 MHz
I2C2: 264 MHz
Then, I modified the device tree source code to make the core frequency is 660MHZ.
PowerPC,8360@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <3EF1480>; //66MHZ
bus-frequency = <FBC5200>; //264MHZ
clock-frequency = <2756CD00>; //660MHZ
32-bit;
};
The device tree will send the core frequency information to linux kernel. Then I
bootm the linux by above dtb blob. follow is the dmesg information. we can see
that:
time_init: decrementer frequency = 66.000000 MHz
time_init: processor frequency = 660.000000 MHz
I am so confused with the core frequency. I think the dmesg show the wrong core
frequency because the actual core freqyency is decided by the power on of cpu. The
device tree just only send a false frequency to the linux kernel.
My question is which frequency, 660MHZ or the 528MHZ, is the actual core
frequency?
Which one, the HRCW or the device tree, decide the actual frequency of core?
If we can use the device tree to re-assign the core frequency, how this process is
finished?
~ # dmesg
Using MPC836x MDS machine description
Linux version 2.6.22 (dpim@localhost.localdomain) (gcc version 4.0.2 20060628
(Wasabi)) #2 Mon Mar 10 01:02:46 EST 2008
Found initrd at 0xcfc39000:0xcffa4fa3
Found legacy serial port 0 for /soc8360@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=264000000, speed=0
Found legacy serial port 1 for /soc8360@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=264000000, speed=0
Entering add_active_range(0, 0, 524288) 0 entries of 256 used
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
Bad clock source for time stamp 1
Bad clock source for time stamp 2
pio-handle not available
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 196608
Normal 196608 -> 196608
HighMem 196608 -> 524288
early_node_map[1] active PFN ranges
0: 0 -> 524288
On node 0 totalpages: 524288
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
HighMem zone: 2560 pages used for memmap
HighMem zone: 325120 pages, LIFO batch:31
Built 1 zonelists. Total pages: 520192
Kernel command line: console=ttyS0,115200 root=/dev/ram rw
IPIC (128 IRQ sources) at fddf3700
QEIC (64 IRQ sources) at fddf2080
PID hash table entries: 4096 (order: 12, 16384 bytes)
time_init: decrementer frequency = 66.000000 MHz
time_init: processor frequency = 660.000000 MHz
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 1310720k
Memory: 2072044k/2097152k available (2692k kernel code, 1334664k reserved, 112k
data, 122k bss, 144k init)
Calibrating delay loop... 131.58 BogoMIPS (lpj=263168)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
fsl_sec2_of_init: start
PCI: Probing PCI hardware
Registering qe_ic with sysfs...
Registering ipic with sysfs...
Generic PHY: Registered new driver
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 3503k freed
highmem bounce pool size: 64 pages
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
cryptodev_init(c02921e8)
cryptosoft: registered as device: 0
talitos: des/3des aes md5 sha1
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (16 seconds)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
UCC Ethernet Controller MII Bus: probed
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0102000 (irq = 23)
eth0: MTU=1500 (frame size=1518,rx_buffer_size=1536,truesize=1792,sk_buff=160)
ucc_geth: UCC2 at 0xe0103000 (irq = 24)
eth1: MTU=1500 (frame size=1518,rx_buffer_size=1536,truesize=1792,sk_buff=160)
SKB Handler initialized(max=64)
Marvell 88E1101: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
MPC8360E MDS flash device: 2000000 at fe000000 Partition number 6
MPC8360E MDS Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank
MPC8360E MDS Flash Map Info: Found an alias at 0x1000000 for the chip at 0x0
Support for command set 0001 not present
gen_probe: No supported Vendor Command Set found
i2c /dev entries driver
ds1374 0-0068: rtc core: registered ds1374 as rtc0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
ds1374 0-0068: setting the system clock to 1972-02-18 11:35:36 (67260936)
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 144k init
PHY: e0102120:00 - Link is Up - 1000/Full
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 7:03 UTC (permalink / raw)
To: Sebastian Siewior, linuxppc-embedded
In-Reply-To: <20080312180421.GC7255@Chamillionaire.breakpoint.cc>
Hi, Sebastian
Could you please apply these two patches and test again?
http://lkml.org/lkml/2008/3/10/64
http://lkml.org/lkml/2008/3/13/36
Thanks!
Wei.
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
> Sent: Thursday, March 13, 2008 2:04 AM
> To: linuxppc-embedded@ozlabs.org
> Cc: Zhang Wei
> Subject: fsldma seems to be buggy, noticed in loop mode
>=20
> Hello,
>=20
> I have a little kmod where I dma data from one place to another (can
> post it if someone wants to see it). It works in general according to
> memcmp :)
>=20
> If I set the DAHE flag (DAHTS =3D 0, for one byte transfers) =
everything
> seems to work as well (I see only the last byte which has the correct
> value).
> Now if I change the destination address to my FIFO I get the requested
> transfer size plus some extra bytes. The extra bytes are looking like
> exactly the same DMA transfer once again. Then my FIFO overruns.
> Enabling some printks in the kernel gave me the following log:
>=20
> |of-fsl-dma-channel e0021100.dma-channe: new link desc alloc df32a000
> |of-fsl-dma-channel e0021100.dma-channe: --memcpy issue--
> |of-fsl-dma-channel e0021100.dma-channe: Ch 0, LD 1f32a000
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 0: 00050000
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 1: 1f0be000
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 2: 00050000
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 3: 1f36c000
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 4: 00000000
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 5: 00000001
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 6: 00000100
> |of-fsl-dma-channel e0021100.dma-channe: LD offset 7: 00000000
> |of-fsl-dma-channel e0021100.dma-channe: ----------------
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring=20
> from 0x000000001f32a000
> |of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie =3D 1
> |of-fsl-dma-channel e0021100.dma-channe: link descriptor=20
> df32a000 will be recycle.
> |of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie =3D 1
> |of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie =3D 1
>=20
> done.=20
> I have one list entry which is df32a000. According to the output that
> single request gets started a couple of times what would=20
> explain why the
> FIFO overruns.
> Is it possible that the driver does not properly recognize that the
> transfer is finished _and_ that is the last one in line? Enabling the
> dma self test Kconfig option shows no error message but the number of
> interrupts that have been generated differ from channel to channel,
> from boot to boot.
>=20
> btw: It is a MPC8544 DS with -rc5.
>=20
> thanks,
> Sebastian
>=20
^ permalink raw reply
* [PATCH] powerpc: user_regset PTRACE_SETREGS regression fix
From: Roland McGrath @ 2008-03-13 8:25 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard; +Cc: linuxppc-dev, linux-kernel
The PTRACE_SETREGS request was only recently added on powerpc,
and gdb does not use it. So it slipped through without getting
all the testing it should have had.
The user_regset changes had a simple bug in storing to all of
the 32-bit general registers block on 64-bit kernels. This bug
only comes up with PTRACE_SETREGS, not PPC_PTRACE_SETREGS.
It causes a BUG_ON to hit, so this fix needs to go in ASAP.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 7673e98..2a9fe97 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -530,15 +530,21 @@ static int gpr32_set(struct task_struct *target,
--count;
}
- if (kbuf)
+ if (kbuf) {
for (; count > 0 && pos <= PT_MAX_PUT_REG; --count)
regs[pos++] = *k++;
- else
+ for (; count > 0 && pos < PT_TRAP; --count, ++pos)
+ ++k;
+ } else {
for (; count > 0 && pos <= PT_MAX_PUT_REG; --count) {
if (__get_user(reg, u++))
return -EFAULT;
regs[pos++] = reg;
}
+ for (; count > 0 && pos < PT_TRAP; --count, ++pos)
+ if (__get_user(reg, u++))
+ return -EFAULT;
+ }
if (count > 0 && pos == PT_TRAP) {
if (kbuf)
^ permalink raw reply related
* Re: [PATCH 1/4] Ensure that pmu_sys_suspended exists in appropriate configs.
From: Guido Günther @ 2008-03-13 8:30 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080312212005.GU6887@bakeyournoodle.com>
Hi Tony,
On Thu, Mar 13, 2008 at 08:20:05AM +1100, Tony Breeds wrote:
[..snip..]
> where pmu_sys_suspended is referenced and I'm having difficulty
> understanding how CONFIG_HIBERNATION is affecting that.
I mangled the filenames and didn't notice that you fixed the header file
instead of via-pmu.c. Yes, this should work. Thanks for fixing this
and the apm-emu stuff as well.
Cheers,
-- Guido
^ permalink raw reply
* [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
From: Roland McGrath @ 2008-03-13 8:31 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard
Cc: linuxppc-dev, Ingo Molnar, Thomas Gleixner, Andrew Morton,
linux-kernel
Define the copy_siginfo_from_user32 entry point for powerpc, so
that generic CONFIG_COMPAT code can call it. We already had the
code rolled into compat_sys_rt_sigqueueinfo, this just moves it
out into the canonical function that other arch's define.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/signal_32.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index d840bc7..ad69434 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -621,6 +621,18 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *d, siginfo_t *s)
#define copy_siginfo_to_user copy_siginfo_to_user32
+int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
+{
+ memset(to, 0, sizeof *to);
+
+ if (copy_from_user(to, from, 3*sizeof(int)) ||
+ copy_from_user(to->_sifields._pad,
+ from->_sifields._pad, SI_PAD_SIZE32))
+ return -EFAULT;
+
+ return 0;
+}
+
/*
* Note: it is necessary to treat pid and sig as unsigned ints, with the
* corresponding cast to a signed int to insure that the proper conversion
@@ -634,9 +646,10 @@ long compat_sys_rt_sigqueueinfo(u32 pid, u32 sig, compat_siginfo_t __user *uinfo
int ret;
mm_segment_t old_fs = get_fs();
- if (copy_from_user (&info, uinfo, 3*sizeof(int)) ||
- copy_from_user (info._sifields._pad, uinfo->_sifields._pad, SI_PAD_SIZE32))
- return -EFAULT;
+ ret = copy_siginfo_from_user32(&info, uinfo);
+ if (unlikely(ret))
+ return ret;
+
set_fs (KERNEL_DS);
/* The __user pointer cast is valid becasuse of the set_fs() */
ret = sys_rt_sigqueueinfo((int)pid, (int)sig, (siginfo_t __user *) &info);
^ permalink raw reply related
* [PATCH -mm 2/4] ptrace: compat_ptrace_request siginfo
From: Roland McGrath @ 2008-03-13 8:32 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard
Cc: linuxppc-dev, Ingo Molnar, Thomas Gleixner, Andrew Morton,
linux-kernel
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
This adds support for PTRACE_GETSIGINFO and PTRACE_SETSIGINFO in
compat_ptrace_request. It relies on existing arch definitions for
copy_siginfo_to_user32 and copy_siginfo_from_user32.
On powerpc, this fixes a longstanding regression of 32-bit ptrace
calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
to examine e.g. siginfo_t.si_addr from a signal that sets it.
(This was broken as of 2.6.24 and, I presume, many or all prior versions.)
Signed-off-by: Roland McGrath <roland@redhat.com>
---
kernel/ptrace.c | 48 +++++++++++++++++++++++++++++++++++-------------
1 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index fdb34e8..67e392e 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -323,9 +323,8 @@ static int ptrace_setoptions(struct task_struct *child, long data)
return (data & ~PTRACE_O_MASK) ? -EINVAL : 0;
}
-static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user * data)
+static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
{
- siginfo_t lastinfo;
int error = -ESRCH;
read_lock(&tasklist_lock);
@@ -333,31 +332,25 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user * data)
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- lastinfo = *child->last_siginfo;
+ *info = *child->last_siginfo;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
}
read_unlock(&tasklist_lock);
- if (!error)
- return copy_siginfo_to_user(data, &lastinfo);
return error;
}
-static int ptrace_setsiginfo(struct task_struct *child, siginfo_t __user * data)
+static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
{
- siginfo_t newinfo;
int error = -ESRCH;
- if (copy_from_user(&newinfo, data, sizeof (siginfo_t)))
- return -EFAULT;
-
read_lock(&tasklist_lock);
if (likely(child->sighand != NULL)) {
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- *child->last_siginfo = newinfo;
+ *child->last_siginfo = *info;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
@@ -424,6 +417,7 @@ int ptrace_request(struct task_struct *child, long request,
long addr, long data)
{
int ret = -EIO;
+ siginfo_t siginfo;
switch (request) {
case PTRACE_PEEKTEXT:
@@ -442,12 +436,22 @@ int ptrace_request(struct task_struct *child, long request,
case PTRACE_GETEVENTMSG:
ret = put_user(child->ptrace_message, (unsigned long __user *) data);
break;
+
case PTRACE_GETSIGINFO:
- ret = ptrace_getsiginfo(child, (siginfo_t __user *) data);
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user((siginfo_t __user *) data,
+ &siginfo);
break;
+
case PTRACE_SETSIGINFO:
- ret = ptrace_setsiginfo(child, (siginfo_t __user *) data);
+ if (copy_from_user(&siginfo, (siginfo_t __user *) data,
+ sizeof siginfo))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
break;
+
case PTRACE_DETACH: /* detach a process that was attached. */
ret = ptrace_detach(child, data);
break;
@@ -616,6 +620,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
+ siginfo_t siginfo;
int ret;
switch (request) {
@@ -638,6 +643,23 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
ret = put_user((compat_ulong_t) child->ptrace_message, datap);
break;
+ case PTRACE_GETSIGINFO:
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user32(
+ (struct compat_siginfo __user *) datap,
+ &siginfo);
+ break;
+
+ case PTRACE_SETSIGINFO:
+ memset(&siginfo, 0, sizeof siginfo);
+ if (copy_siginfo_from_user32(
+ &siginfo, (struct compat_siginfo __user *) datap))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
+ break;
+
default:
ret = ptrace_request(child, request, addr, data);
}
^ permalink raw reply related
* RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
From: Magnus Hjorth @ 2008-03-13 8:33 UTC (permalink / raw)
To: 'Stephen Neuendorffer', 'git'; +Cc: linuxppc-embedded
In-Reply-To: <20080311173602.8E61C728093@mail209-sin.bigfish.com>
Hi,
Thanks for the feedback. I'll have a look into refining the patch in a few weeks when I get some
more time.
I have also been tinkering a little with the SPI driver, and that got me thinking. Wouldn't it be
great if SPI controllers and devices could be specified in the OF device tree and registered on boot
time? Even better if SPI worked as a true bus in EDK, with placeholder IP-cores for each slave
device, so such device entries could be autogenerated.
Cheers,
Magnus
> -----Original Message-----
> From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]
> Sent: den 11 mars 2008 18:36
> To: Magnus Hjorth; git
> Cc: linuxppc-embedded@ozlabs.org; Grant Likely
> Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
>
>
> Thanks Magnus!
>
> Generally speaking this looks reasonable. Some comments:
>
> > struct xgpio_instance {
> > struct list_head link;
> > unsigned long base_phys; /* GPIO base address - physical
> */
> > unsigned long remap_size;
> > - u32 device_id;
> > + u32 device_id; /* Dev ID for platform devices, 0 for OF
> devices */
> > + void *of_id; /* of_dev pointer for OF devices, NULL
> for plat devices */
>
> Why have separate ids? I don't think the of_dev needs to be kept around
> here. This driver seems seems awkwardly written to have a local list of
> all the devices, rather than simply attaching the xgpio_instance as the
> private data of the file.
>
> For instance, in drivers/char/xilinx_hwicap.c:
>
> static ssize_t
> hwicap_read(struct file *file, char __user *buf, size_t count, loff_t
> *ppos)
> {
> struct hwicap_drvdata *drvdata = file->private_data;
>
> and the drvdata is set in open:
>
> static int hwicap_open(struct inode *inode, struct file *file)
> {
> struct hwicap_drvdata *drvdata;
> int status;
>
> drvdata = container_of(inode->i_cdev, struct hwicap_drvdata,
> cdev);
> ...
> file->private_data = drvdata;
>
> Which would work if xgpio_instance directly contains the struct
> miscdevice.
> I think this is a much cleaner pattern (although it took me a while to
> figure out the magic that makes it work... )
>
> > +static struct of_device_id xgpio_of_match[] = {
> > + {.compatible = "xlnx,xps-gpio-1.00.a"},
>
> This should also probably contain the corresponding strings for the
> following as well:
> opb_gpio_v1_00_a
> opb_gpio_v2_00_a
> opb_gpio_v3_01_a
> opb_gpio_v3_01_b
> plb_gpio_v1_00_b
>
> This would seem to be a relatively easy driver to clean up (by pulling
> it all into one file and converting the other code to the kernel style)
> and submit to mainline, if you're interested?
>
> Steve
^ permalink raw reply
* [PATCH -mm 3/4] x86_64 ia32 ptrace: use compat_ptrace_request for siginfo
From: Roland McGrath @ 2008-03-13 8:33 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard
Cc: linuxppc-dev, Ingo Molnar, Thomas Gleixner, Andrew Morton,
linux-kernel
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
This removes the special-case handling for PTRACE_GETSIGINFO
and PTRACE_SETSIGINFO from x86_64's sys32_ptrace. The generic
compat_ptrace_request code handles these.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/x86/kernel/ptrace.c | 30 +-----------------------------
1 files changed, 1 insertions(+), 29 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 77d9ddd..42305fa 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1184,32 +1184,6 @@ static int genregs32_set(struct task_struct *target,
return ret;
}
-static long ptrace32_siginfo(unsigned request, u32 pid, u32 addr, u32 data)
-{
- siginfo_t __user *si = compat_alloc_user_space(sizeof(siginfo_t));
- compat_siginfo_t __user *si32 = compat_ptr(data);
- siginfo_t ssi;
- int ret;
-
- if (request == PTRACE_SETSIGINFO) {
- memset(&ssi, 0, sizeof(siginfo_t));
- ret = copy_siginfo_from_user32(&ssi, si32);
- if (ret)
- return ret;
- if (copy_to_user(si, &ssi, sizeof(siginfo_t)))
- return -EFAULT;
- }
- ret = sys_ptrace(request, pid, addr, (unsigned long)si);
- if (ret)
- return ret;
- if (request == PTRACE_GETSIGINFO) {
- if (copy_from_user(&ssi, si, sizeof(siginfo_t)))
- return -EFAULT;
- ret = copy_siginfo_to_user32(si32, &ssi);
- }
- return ret;
-}
-
asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
{
struct task_struct *child;
@@ -1255,11 +1229,9 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
case PTRACE_SETFPXREGS:
case PTRACE_GETFPXREGS:
case PTRACE_GETEVENTMSG:
- break;
-
case PTRACE_SETSIGINFO:
case PTRACE_GETSIGINFO:
- return ptrace32_siginfo(request, pid, addr, data);
+ break;
}
child = ptrace_get_task_struct(pid);
^ permalink raw reply related
* [PATCH -mm 4/4] x86_64 ia32 ptrace: convert to compat_arch_ptrace
From: Roland McGrath @ 2008-03-13 8:34 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard
Cc: linuxppc-dev, Ingo Molnar, Thomas Gleixner, Andrew Morton,
linux-kernel
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
Now that there are no more special cases in sys32_ptrace, we
can convert to using the generic compat_sys_ptrace entry point.
The sys32_ptrace function gets simpler and becomes compat_arch_ptrace.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/x86/ia32/ia32entry.S | 2 +-
arch/x86/kernel/ptrace.c | 65 +++++---------------------------------------
include/asm-x86/ptrace.h | 2 +
3 files changed, 11 insertions(+), 58 deletions(-)
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 8022d3c..b42d009 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -426,7 +426,7 @@ ia32_sys_call_table:
.quad sys_setuid16
.quad sys_getuid16
.quad compat_sys_stime /* stime */ /* 25 */
- .quad sys32_ptrace /* ptrace */
+ .quad compat_sys_ptrace /* ptrace */
.quad sys_alarm
.quad sys_fstat /* (old)fstat */
.quad sys_pause
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 42305fa..e36c0f3 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1184,67 +1184,16 @@ static int genregs32_set(struct task_struct *target,
return ret;
}
-asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
+long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
+ compat_ulong_t caddr, compat_ulong_t cdata)
{
- struct task_struct *child;
- struct pt_regs *childregs;
+ unsigned long addr = caddr;
+ unsigned long data = cdata;
void __user *datap = compat_ptr(data);
int ret;
__u32 val;
switch (request) {
- case PTRACE_TRACEME:
- case PTRACE_ATTACH:
- case PTRACE_KILL:
- case PTRACE_CONT:
- case PTRACE_SINGLESTEP:
- case PTRACE_SINGLEBLOCK:
- case PTRACE_DETACH:
- case PTRACE_SYSCALL:
- case PTRACE_OLDSETOPTIONS:
- case PTRACE_SETOPTIONS:
- case PTRACE_SET_THREAD_AREA:
- case PTRACE_GET_THREAD_AREA:
- case PTRACE_BTS_CONFIG:
- case PTRACE_BTS_STATUS:
- case PTRACE_BTS_SIZE:
- case PTRACE_BTS_GET:
- case PTRACE_BTS_CLEAR:
- case PTRACE_BTS_DRAIN:
- return sys_ptrace(request, pid, addr, data);
-
- default:
- return -EINVAL;
-
- case PTRACE_PEEKTEXT:
- case PTRACE_PEEKDATA:
- case PTRACE_POKEDATA:
- case PTRACE_POKETEXT:
- case PTRACE_POKEUSR:
- case PTRACE_PEEKUSR:
- case PTRACE_GETREGS:
- case PTRACE_SETREGS:
- case PTRACE_SETFPREGS:
- case PTRACE_GETFPREGS:
- case PTRACE_SETFPXREGS:
- case PTRACE_GETFPXREGS:
- case PTRACE_GETEVENTMSG:
- case PTRACE_SETSIGINFO:
- case PTRACE_GETSIGINFO:
- break;
- }
-
- child = ptrace_get_task_struct(pid);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- ret = ptrace_check_attach(child, request == PTRACE_KILL);
- if (ret < 0)
- goto out;
-
- childregs = task_pt_regs(child);
-
- switch (request) {
case PTRACE_PEEKUSR:
ret = getreg32(child, addr, &val);
if (ret == 0)
@@ -1290,12 +1239,14 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
sizeof(struct user32_fxsr_struct),
datap);
+ case PTRACE_GET_THREAD_AREA:
+ case PTRACE_SET_THREAD_AREA:
+ return arch_ptrace(child, request, addr, data);
+
default:
return compat_ptrace_request(child, request, addr, data);
}
- out:
- put_task_struct(child);
return ret;
}
diff --git a/include/asm-x86/ptrace.h b/include/asm-x86/ptrace.h
index bc44246..b57dc69 100644
--- a/include/asm-x86/ptrace.h
+++ b/include/asm-x86/ptrace.h
@@ -230,6 +230,8 @@ extern int do_get_thread_area(struct task_struct *p, int idx,
extern int do_set_thread_area(struct task_struct *p, int idx,
struct user_desc __user *info, int can_allocate);
+#define __ARCH_WANT_COMPAT_SYS_PTRACE
+
#endif /* __KERNEL__ */
#endif /* !__ASSEMBLY__ */
^ permalink raw reply related
* Re: fsldma seems to be buggy, noticed in loop mode
From: Sebastian Siewior @ 2008-03-13 9:13 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AED32DD2@zch01exm26.fsl.freescale.net>
* Zhang Wei | 2008-03-13 15:03:54 [+0800]:
>Could you please apply these two patches and test again?
>
>http://lkml.org/lkml/2008/3/10/64
>http://lkml.org/lkml/2008/3/13/36
Ui, that fast. Did you find this on your own or after me reporting that
bug?
It solves my FIFO problem, thanks.
>Thanks!
>Wei.
Sebastian
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 9:17 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080313091308.GA17132@Chamillionaire.breakpoint.cc>
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
>=20
> * Zhang Wei | 2008-03-13 15:03:54 [+0800]:
>=20
> >Could you please apply these two patches and test again?
> >
> >http://lkml.org/lkml/2008/3/10/64
> >http://lkml.org/lkml/2008/3/13/36
> Ui, that fast. Did you find this on your own or after me=20
> reporting that
> bug?
> It solves my FIFO problem, thanks.
>=20
Just after you reported. :)
Cheers!
Wei.
^ permalink raw reply
* Re: fsldma seems to be buggy, noticed in loop mode
From: Sebastian Siewior @ 2008-03-13 9:20 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AED32E67@zch01exm26.fsl.freescale.net>
* Zhang Wei | 2008-03-13 17:17:31 [+0800]:
>Just after you reported. :)
okey. Do you want me to add a tested by on lkml?
>
>Cheers!
>Wei.
Sebastian
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 9:23 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080313092008.GA17404@Chamillionaire.breakpoint.cc>
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
>=20
> * Zhang Wei | 2008-03-13 17:17:31 [+0800]:
>=20
> >Just after you reported. :)
> okey. Do you want me to add a tested by on lkml?
>=20
it's my pleasure!
Thanks!
Wei
^ permalink raw reply
* Re: [PATCH] ppc: Export empty_zero_page
From: Christoph Hellwig @ 2008-03-13 10:12 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linuxppc-dev
In-Reply-To: <E1JZGwo-0000vf-2v@closure.thunk.org>
On Tue, Mar 11, 2008 at 10:44:06PM -0400, Theodore Ts'o wrote:
> Stephen Rothwell discovered this issue in the linux-next tree:
>
> >Today's powerpc allmodconfig build of linux-next failed with:
> >
> >ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
> >
> >This is because commit dde5f2130096f8469eb1aa1ad250cd2a39fee3f5 ("ext4:
> >ENOSPC error handling for writing to an uninitialized extent") uses
> >ZERO_PAGE() which on powerpc uses empty_zero_page which is not
> >EXPORT_SYMBOLed on powerpc. I have reverted that commit and a later
> >one (1ae53f35fea49a9013353078e019469551d2ad74 "ext4: zero out
> >small extents when writing to prealloc area.") which depended on it.
>
> Any chance you could get this pushed to Linus ASAP? It would be nice if
> this could get pushed before the merge window, since it could be argued
> that rationalizing whether or not empty_zero_page is exported is a bug
> fix, and anyway this is pretty much a zero-risk patch. Thanks!!
The real fix is that ext4 shouldn't be using ZERO_PAGE(). Please use
the same zeroing helpers all the other filesystems and drivers use.
^ permalink raw reply
* Re: Driver for Freescale Display Interface Unit (A LCD controller)
From: Geert Uytterhoeven @ 2008-03-13 10:17 UTC (permalink / raw)
To: York Sun
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Linux Kernel Development
In-Reply-To: <12053582234100-git-send-email-yorksun@freescale.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1007 bytes --]
On Wed, 12 Mar 2008, York Sun wrote:
> The following patches are for Freescale DIU. The first patch is a DIU driver.
> The second patch is the platform code to support the driver. It is a frame
> buffer driver for DIU. Descriptions can be found in the patches.
>
> It is a new feature targeting 2.6.26 kernel.
Please CC linux-fbdev-devel@lists.sourceforge.net when submitting new frame
buffer device drivers. Thx!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Kamalesh Babulal @ 2008-03-13 13:02 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-kernel, linuxppc-dev, Andrew Morton, pbadari
In-Reply-To: <20080312223300.GE613@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, Mar 13, 2008 at 09:26:09AM +1100, Michael Ellerman wrote:
>> down() looks OK, but there's still a spin_lock_irq() in __down_common(),
>> although I don't know if it makes sense for us to be in __down() at that
>> stage.
>
> The spin_lock_irq in __down_common is correct. We're going to schedule(),
> so we spin_unlock_irq() to save us passing the flags into the helper
> function. If we had interrupts disabled on entry, there's an Aieee
> for that.
>
Hi All,
Sorry for all the noise made :-(, something wrong in the test setup from my end,
the kernel was 2.6.25-rc3-mm1 not 2.6.25-rc5-mm1. This bug is not seen in the
2.6.25-rc5-mm1 kernel.
--
Thanks & Regards,
Kamalesh Babulal,
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-13 13:13 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Arnd Bergmann,
Jan Kratochvil
In-Reply-To: <200803122330.36905.jens@de.ibm.com>
On Wed, 2008-03-12 at 23:30 +0100, Jens Osterkamp wrote:
> > Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
> > still fails. So this is really an open bug for PPC.
>
> On a Cell- or 970-based machine ?
>
> Gruß,
> Jens
On a 970-based machine.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: Interrupt handling documentation
From: Laurent Pinchart @ 2008-03-13 13:56 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1205283088.7544.8.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
Hi Michael,
On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > is there any documentation describing interrupt handling for the powerpc
> > architecture ? I'm writing a driver for a cascaded interrupt controller
> > and the only source of information I found was the code.
>
> I don't think there's much documentation.
I feared so :-)
> You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
> reasonably simple example of how to setup an irq_host and so on - well I
> think so :D
Thanks for the pointer.
> > I'm particularly interested in information about irq hosts (allocation
> > and initialisation, especially the map and unmap callbacks) and irq
> > chaining. Different drivers seem to implement cascaded irqs differently
> > (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
> > cascaded irq handler, while arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
> > uses set_irq_chained_handler) so I'm a bit lost here.
>
> uic.c uses set_irq_chained_handler() now, so that probably answers that
> question. I don't think it makes all that much difference if you set it
> up by hand, but set_irq_chained_handler() is the neat way to do it.
That pretty much answers my question. It's always a bit disturbing when
different drivers use different APIs to accomplish the same task, especially
when the lack of documentation doesn't clearly state which API should be used
and which API is internal/deprecated.
Thanks for your answer.
Cheers,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Help needed to describe a custom bus in the device tree
From: Laurent Pinchart @ 2008-03-13 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080311225427.GD7642@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 8406 bytes --]
Hi Dave,
On Tuesday 11 March 2008 23:54, David Gibson wrote:
> On Tue, Mar 11, 2008 at 03:27:26PM +0100, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > the migration process from ARCH=ppc to ARCH=powerpc is easier than I
> > thought in some parts, but a few devices are still giving me
> > headaches. This should hopefully be one of my last major requests
> > for help (I'm sure most of you will be happy to see traffic on this
> > list going down when I'll be done :-))
> >
> > I'm having trouble describing a custom bus named MS bus (completely
> > unrelated to a well-known software company) in the device tree. The
> > hardware is MPC8248-based and has the following hardware topology.
> >
> > MPC8248 <-- localbus --> FPGA <-- ms bus --> Custom peripherals
> >
> > The bus interrupt controller, serial access (SPI) controller and
> > status registers are accessed through memory-mapped registers in the
> > FPGA. Parallel access to the MS bus is handled transparently by the
> > FPGA which handles address mapping.
> >
> > The FPGA is mapped on the locabus at address 0xf4000000. Bus control
> > registers are at 0xf4002000 - 0xf4003000. The parallel bus memory
> > window on the localbus is located at 0xf5000000.
> >
> > My current dts draft describes that topology as follows (unrelated
> > devices on the local bus such as flash memory are removed for
> > clarity).
> >
> > localbus@f0010100 {
> > compatible = "fsl,pq2-localbus";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 40>;
> >
> > ranges = <0 0 40000000 01000000
> > 2 0 f2000000 00100000
> > 3 0 f3000000 00100000
> > 4 0 f4000000 00100000
> > 5 0 f5000000 00100000>;
> >
> > fpga@4,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <4 0 0 00010000>;
> >
> > msbus-arbitrer@2000 {
> > compatible = "tbox,cp11-msbus-arbitrer";
> > reg = <2000 4>;
> > };
> >
> > msbus_pic: interrupt-controller@2100 {
> > compatible = "tbox,cp11-msbus-pic";
> > reg = <2100 8>;
> > interrupts = <17 2>;
> > interrupt-parent = <&cpm_pic>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > };
> >
> > msbus-spi@2200 {
> > compatible = "tbox,cp11-msbus-spi";
> > reg = <2200 100>;
> > interrupts = <18 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> >
> > sdhc@5000 {
> > compatible = "tbox,sdhci";
> > reg = <5000 1000>;
> > interrupts = <16 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> > };
> >
> > msbus@5,0 {
> > compatible = "tbox,cp11-msbus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <1>;
> > reg = <5 0 0 00000400>;
> > interrupt-parent = <&msbus_pic>;
> > };
> > };
> >
> > The device tree reflects the physical topology but makes driver
> > access to the bus quite complex. An OF platform device driver
> > matching on compatible = "tbox,cp11-msbus" will not have the bus
> > FPGA registers described in its device node.
> >
> > Having a look at the various device trees included in the kernel
> > sources, it seems platforms with a PCI bus experience a similar
> > problem. To solve it the PCI bus node address and registers describe
> > the configuration registers, and the memory window to access PCI
> > devices is described by the ranges property. Applying that to my
> > custom bus would lead to the following tree.
> >
> > localbus@f0010100 {
> > compatible = "fsl,pq2-localbus";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 40>;
> >
> > ranges = <0 0 40000000 01000000
> > 2 0 f2000000 00100000
> > 3 0 f3000000 00100000
> > 4 0 f4000000 00100000
> > 4 1 f4002000 00000100
> > 5 0 f5000000 00100000>;
> >
> > fpga@4,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <4 0 0 00010000>;
> >
> > msbus_pic: interrupt-controller@2100 {
> > compatible = "tbox,cp11-msbus-pic";
> > reg = <2100 8>;
> > interrupts = <17 2>;
> > interrupt-parent = <&cpm_pic>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > };
> >
> > msbus-spi@2200 {
> > compatible = "tbox,cp11-msbus-spi";
> > reg = <2200 100>;
> > interrupts = <18 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> >
> > sdhc@5000 {
> > compatible = "tbox,sdhci";
> > reg = <5000 1000>;
> > interrupts = <16 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> > };
> >
> > msbus@4,1 {
> > compatible = "tbox,cp11-msbus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <1>;
> > reg = <4 1 4>;
> > interrupt-parent = <&msbus_pic>;
> > ranges = <5 0 0 00000400>;
> > };
> > };
> >
> > Is this correct ? Is that the best way to describe my custom bus in
> > the device tree ?
>
> Your second example looks closer to right. Certainly you should use
> 'reg' only for bus control registers, and 'ranges' for windows into
> the bus address space itself.
Ok.
> The device tree describes hardware from a functional point of view, so
> I don't know that it's relevant that all the bus control functions are
> implemented in an FPGA. Each of the subnodes are more-or-less
> independent devices, so they could just have separate nodes.
>
> Or, if this seems more sensible, you could decide that they're
> sufficiently closely related to put them all as one node, with
> multiple register blocks listed in the 'reg' property. That would
> probably get messy for your PIC at the very least though.
I suppose I could implement PIC support in the bus driver itself, but having
separate nodes with separate OF devices and separate drivers seems cleaner to
me (although it can make dependencies a bit more difficult to handle).
> > How would the relationships between the bus and
> > its PIC and SPI controller be handled in the drivers ?
>
> If the msbus driver needs to work with the associated PIC and SPI
> controllers, then you should put properties in the msbus node giving
> their phandles.
The PIC can live pretty much by itself, but the SPI controller is used to
enumerate devices on the bus (and perform some other tasks at runtime). I
plan to have the SPI device and driver be self-contained, and have the bus
node reference the SPI device through its phandle. I will just have to make
sure the bus driver is initialised after the SPI driver.
> > I also don't
> > understand how interrupt mappings are supposed to be handled. PCI
> > busses have two CPM interrupt lines, one for the PCI PIC and one for
> > the PCI bus, with the PCI bus having the CPM PIC as its interrupt
> > controller. My bus PIC uses a single interrupt line. Is there some
> > documentation explaining how PICs and interrupt mappings should be
> > described ?
>
> Are interrupts from devices on the msbus routed over the msbus, or are
> they routed independently to the mspic or the cpm PIC?
There is a single active low interrupt line on the msbus. When the mspic
detects an interrupt condition, it will read the interrupt source registers
from all devices on the bus and generate a host interrupt to the cpm PIC. The
mspic driver then process the CPM interrupt in its demux handler, reads the
interrupt sources from the mspic registers and dispatch the interrupts to the
msbus device drivers.
If I understand things correctly, the mspic node should have an 'interrupts'
attribute describing the cascaded interrupt line (mspic -> cpm PIC irq), and
the msbus node should have an 'interrupts' attribute describing the interrupt
line used to report bus-related events (hotplug events for instance). Is that
right ?
To make things a bit more complex, the msbus interrupt and the bus-related
events interrupt share the same CPM irq line. Can I use the same virq number
in both nodes, or do I have to demux the interrupts in a separate driver ? If
I have to demux the interrupts in a separate PIC driver, how do I know what
virtual irq number will be assigned to each device so that I can reference
them in the device tree ?
Thanks a lot for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH -mm 2/4] ptrace: compat_ptrace_request siginfo
From: Jeff Dike @ 2008-03-13 14:42 UTC (permalink / raw)
To: Roland McGrath
Cc: Thomas Gleixner, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Andrew Morton, Ingo Molnar
In-Reply-To: <20080313083243.E551A26F992@magilla.localdomain>
On Thu, Mar 13, 2008 at 01:32:43AM -0700, Roland McGrath wrote:
> On powerpc, this fixes a longstanding regression of 32-bit ptrace
> calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
> kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
> to examine e.g. siginfo_t.si_addr from a signal that sets it.
> (This was broken as of 2.6.24 and, I presume, many or all prior versions.)
BTW, this also fixes a long-standing bug in x86_64 ptrace32_siginfo:
ret = sys_ptrace(request, pid, addr, (unsigned long)si);
if (ret)
return ret;
if (request == PTRACE_GETSIGINFO) {
if (copy_from_user(&ssi, si, sizeof(siginfo_t)))
return -EFAULT;
ret = copy_siginfo_to_user32(si32, &ssi);
}
si comes back with the upper bits of si_code missing, courtesy of
copy_siginfo_to_user:
err |= __put_user((short)from->si_code, &to->si_code);
causing copy_siginfo_to_user32 to not copy any fields of the union
past the first word because the upper 16 bits are used to figure out
what needs copying.
Jeff
--
Work email - jdike at linux dot intel dot com
^ permalink raw reply
* Re: [PATCH] ibm_newemac: emac_tx_csum typo fix.patch
From: Stefan Roese @ 2008-03-13 15:42 UTC (permalink / raw)
To: linuxppc-dev, netdev
In-Reply-To: <20080222192139.GA26126@ru.mvista.com>
On Friday 22 February 2008, Valentine Barshak wrote:
> Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
> emac_has_feature parameters.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Stefan Roese <sr@denx.de>
I think this is 2.6.25 material. I just stumbled over this problem too while
enabling TAH on 440GX and 460EX/GT.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Hi,friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-13 15:31 UTC (permalink / raw)
To: support.asia, linuxppc-embedded, u-boot-users
Hi,friends,
I make all the frequency(timebase-frequency;bus-frequency;clock-frequency) value
on device tree file equal to zero, I think those frequency will filled by u-boot
during bootm, but in fact, the u-boot did not fill any frequency. after bootm,
crashed. Why?
Why so many document point out that the zero value will be filled by u-boot?
^ permalink raw reply
* Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx Virtex II Pro
From: Wood, Robert (GE EntSol, Intelligent Platforms) @ 2008-03-13 15:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi, sorry for what is probably previously covered subject., I am
searching the archives.
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
Robert Wood
Senior Engineer
GE Fanuc Intelligent Platforms
T +613 749 9241 x270
F +613 749 9461
E robert.wood@gefanuc.com
www.ge.com
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
General Electric Company
[-- Attachment #2: Type: text/html, Size: 5166 bytes --]
^ permalink raw reply
* [PATCH] net: NEWEMAC: Add compatible "ibm,tah" to tah matching table
From: Stefan Roese @ 2008-03-13 15:59 UTC (permalink / raw)
To: linuxppc-dev, netdev
Add "ibm,tah" to the compatible matching table of the ibm_newemac
tah driver. The type "tah" is still preserved for compatibility reasons.
New dts files should use the compatible property though.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/tah.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/tah.c b/drivers/net/ibm_newemac/tah.c
index 96417ad..b023d10 100644
--- a/drivers/net/ibm_newemac/tah.c
+++ b/drivers/net/ibm_newemac/tah.c
@@ -155,6 +155,10 @@ static int __devexit tah_remove(struct of_device *ofdev)
static struct of_device_id tah_match[] =
{
{
+ .compatible = "ibm,tah",
+ },
+ /* For backward compat with old DT */
+ {
.type = "tah",
},
{},
--
1.5.4.4
^ permalink raw reply related
* [PATCH] [POWERPC] Add TAH support to taishan dts
From: Stefan Roese @ 2008-03-13 16:00 UTC (permalink / raw)
To: linuxppc-dev
This patch adds TAH (TCP/IP Acceleration Hardware) support to the
taishan 440GX dts. It depends on the NEWEMAC/tah patch that adds the
compatible "ibm,tah" property to the matching table.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/taishan.dts | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..b5aad74 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -232,6 +232,15 @@
reg = <40000790 8>;
};
+ TAH0: emac-tah@40000b50 {
+ compatible = "ibm,tah-440gx", "ibm,tah";
+ reg = <40000b50 30>;
+ };
+
+ TAH1: emac-tah@40000d50 {
+ compatible = "ibm,tah-440gx", "ibm,tah";
+ reg = <40000d50 30>;
+ };
EMAC0: ethernet@40000800 {
unused = <1>;
@@ -297,6 +306,8 @@
rgmii-channel = <0>;
zmii-device = <&ZMII0>;
zmii-channel = <2>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
};
EMAC3: ethernet@40000e00 {
@@ -320,6 +331,8 @@
rgmii-channel = <1>;
zmii-device = <&ZMII0>;
zmii-channel = <3>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
};
--
1.5.4.4
^ 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