* Re: DTS file reference for FSL UPM NAND for MPC832x
From: Wolfgang Grandegger @ 2010-01-17 7:21 UTC (permalink / raw)
To: nanda; +Cc: linuxppc-dev
In-Reply-To: <20100116170224.29250.qmail@f5mail-236-241.rediffmail.com>
nanda wrote:
> Hi,
> Iam looking for any references for the dts (device tree source) file which implements freescale's UPM based NAND driver connected to NAND flash. (it uses the individual gpio connected to R/B pin)
The following links might be useful:
http://lxr.linux.no/#linux+v2.6.32/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
http://lxr.linux.no/#linux+v2.6.32/arch/powerpc/boot/dts/mpc836x_rdk.dts#L407
Wolfgang.
^ permalink raw reply
* RE: openpic specification
From: SHAN Gavin @ 2010-01-17 7:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <451D99C3-3C43-450E-A1F5-C828A5EA4BFA@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
> I ever searched openpic specification on google for several times, but unfortunately nothing found.
> Could anybody point me where I can get the openpic specification?
>
> The source code seems being from IBM: arch/powerpc/sysdev/mpic.c
While not the openpic spec if you grab any of the Freescale RM for MPC85xx chips there will be a chapter on the PIC that is an "openPIC" based interrupt controller.
Thanks, Kumar. Actually, I'm facing a wired issue on my system: some times, the interrupt
from external devices can't be seen from CPU. That means the CPU was never disturbed by
extern interrupts at some point. I don't know why, it seems the PIC just ignored the
external interrupts.
We're using Pasemi 1682M part, which integrated a openpic compatible PIC. But the CPU part has 2
cores. There're 3 kinds of interrupts:
several internal interrupts - priority 8
one external interrupt - priority 8
IPI - priority 10
Thanks,
Gavin
[-- Attachment #2: Type: text/html, Size: 1625 bytes --]
^ permalink raw reply
* [PATCH] trivial: fix typo s/leve/level/ in powerpc arch
From: Thadeu Lima de Souza Cascardo @ 2010-01-17 21:23 UTC (permalink / raw)
To: trivial
Cc: linuxppc-dev, Thadeu Lima de Souza Cascardo, Paul Mackerras,
linux-kernel
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
---
arch/powerpc/mm/tlb_low_64e.S | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index f288279..8b04c54 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -1,5 +1,5 @@
/*
- * Low leve TLB miss handlers for Book3E
+ * Low level TLB miss handlers for Book3E
*
* Copyright (C) 2008-2009
* Ben. Herrenschmidt (benh@kernel.crashing.org), IBM Corp.
--
1.6.6
^ permalink raw reply related
* Re: [PATCH] trivial: fix typo s/leve/level/ in powerpc arch
From: Jiri Kosina @ 2010-01-17 21:43 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo; +Cc: Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <1263763394-9572-1-git-send-email-cascardo@holoscopio.com>
On Sun, 17 Jan 2010, Thadeu Lima de Souza Cascardo wrote:
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> ---
> arch/powerpc/mm/tlb_low_64e.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
> index f288279..8b04c54 100644
> --- a/arch/powerpc/mm/tlb_low_64e.S
> +++ b/arch/powerpc/mm/tlb_low_64e.S
> @@ -1,5 +1,5 @@
> /*
> - * Low leve TLB miss handlers for Book3E
> + * Low level TLB miss handlers for Book3E
> *
> * Copyright (C) 2008-2009
> * Ben. Herrenschmidt (benh@kernel.crashing.org), IBM Corp.
Applied to trivial queue, thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-01-18 6:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
Hi Linus !
A tad late due to me slacking and leaving the patches take dust in
patchwork for a bit too long, but here are a few bug fixes for powerpc
and a bunch of defconfig freshen ups for some of our embedded platforms.
Cheers,
Ben.
The following changes since commit 004b35063296b6772fa72404a35b498f1e71e87e:
Linus Torvalds (1):
Merge branch 'drm-linus' of git://git.kernel.org/.../airlied/drm-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (2):
powerpc/pseries: Fix xics interrupt affinity
powerpc: cpumask_of_node() should handle -1 as a node
Anton Vorontsov (1):
powerpc/swsusp_32: Fix TLB invalidation
Benjamin Herrenschmidt (3):
serial/pmac_zilog: Workaround problem due to interrupt on closed port
Merge commit 'kumar/merge' into merge
Merge commit 'gcl/merge' into merge
FUJITA Tomonori (1):
powerpc/pseries: Fix dlpar compile warning without CONFIG_PROC_DEVICETREE
Grant Likely (1):
powerpc/5200: update defconfigs
Jiri Slaby (1):
powerpc: Use helpers for rlimits
Joakim Tjernlund (2):
powerpc/8xx: Always pin kernel instruction TLB
powerpc/8xx: Fix user space TLB walk in dcbX fixup
Kamalesh Babulal (1):
powerpc/hvc: Driver build breaks with !HVC_CONSOLE
Kumar Gala (1):
powerpc: 2.6.33 update of defconfigs for embedded 6xx/7xxx, 8xx, 8xxx
Michael Ellerman (1):
powerpc/iseries: Initialise on-stack completion
Márton Németh (1):
powerpc/macintosh: Make Open Firmware device id constant
Nathan Fontenot (2):
powerpc: Move /proc/ppc64 to /proc/powerpc update
powerpc: Move cpu hotplug driver lock from pseries to powerpc
Peter Tyser (1):
powerpc: Use scripts/mkuboot.sh instead of 'mkimage'
Stefan Roese (1):
powerpc: Fix decrementer setup on 1GHz boards
arch/powerpc/boot/wrapper | 7 +-
arch/powerpc/configs/52xx/cm5200_defconfig | 75 ++++++++++++---
arch/powerpc/configs/52xx/lite5200b_defconfig | 90 ++++++++++++++----
arch/powerpc/configs/52xx/motionpro_defconfig | 79 +++++++++++++---
arch/powerpc/configs/52xx/pcm030_defconfig | 83 +++++++++++++----
arch/powerpc/configs/52xx/tqm5200_defconfig | 79 +++++++++++++---
arch/powerpc/configs/83xx/asp8347_defconfig | 88 +++++++++++++-----
arch/powerpc/configs/83xx/kmeter1_defconfig | 68 +++++++++++---
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 97 +++++++++++++++-----
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 100 +++++++++++++++-----
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 89 +++++++++++++-----
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 93 ++++++++++++++-----
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 95 ++++++++++++++-----
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 92 ++++++++++++++-----
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 86 +++++++++++++-----
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 89 +++++++++++++-----
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 87 +++++++++++++-----
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 89 +++++++++++++-----
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 91 +++++++++++++-----
arch/powerpc/configs/83xx/sbc834x_defconfig | 85 ++++++++++++-----
arch/powerpc/configs/85xx/ksi8560_defconfig | 69 ++++++++++---
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 69 ++++++++++---
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 76 ++++++++++++----
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 75 +++++++++++----
arch/powerpc/configs/85xx/sbc8548_defconfig | 77 ++++++++++++----
arch/powerpc/configs/85xx/sbc8560_defconfig | 72 +++++++++++---
arch/powerpc/configs/85xx/socrates_defconfig | 99 +++++++++++++++-----
arch/powerpc/configs/85xx/stx_gp3_defconfig | 87 +++++++++++++-----
arch/powerpc/configs/85xx/tqm8540_defconfig | 89 +++++++++++++-----
arch/powerpc/configs/85xx/tqm8541_defconfig | 90 +++++++++++++-----
arch/powerpc/configs/85xx/tqm8548_defconfig | 95 ++++++++++++++----
arch/powerpc/configs/85xx/tqm8555_defconfig | 90 +++++++++++++-----
arch/powerpc/configs/85xx/tqm8560_defconfig | 90 +++++++++++++-----
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 103 ++++++++++++++++----
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 102 ++++++++++++++++----
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 99 ++++++++++++++++----
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 92 ++++++++++++++----
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 88 +++++++++++++----
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 90 ++++++++++++++----
arch/powerpc/configs/86xx/sbc8641d_defconfig | 81 ++++++++++++----
arch/powerpc/configs/adder875_defconfig | 57 +++++++++---
arch/powerpc/configs/c2k_defconfig | 90 +++++++++++++-----
arch/powerpc/configs/ep8248e_defconfig | 64 ++++++++++---
arch/powerpc/configs/ep88xc_defconfig | 55 +++++++++---
arch/powerpc/configs/linkstation_defconfig | 96 ++++++++++++++-----
arch/powerpc/configs/mgcoge_defconfig | 74 +++++++++++----
arch/powerpc/configs/mgsuvd_defconfig | 63 ++++++++++---
arch/powerpc/configs/mpc5200_defconfig | 106 +++++++++++++++++----
arch/powerpc/configs/mpc7448_hpc2_defconfig | 79 ++++++++++++----
arch/powerpc/configs/mpc8272_ads_defconfig | 70 +++++++++++---
arch/powerpc/configs/mpc83xx_defconfig | 92 +++++++++++++-----
arch/powerpc/configs/mpc85xx_defconfig | 97 ++++++++++++++-----
arch/powerpc/configs/mpc85xx_smp_defconfig | 97 ++++++++++++++-----
arch/powerpc/configs/mpc866_ads_defconfig | 65 ++++++++++---
arch/powerpc/configs/mpc86xx_defconfig | 93 ++++++++++++++----
arch/powerpc/configs/mpc885_ads_defconfig | 55 +++++++++---
arch/powerpc/configs/pq2fads_defconfig | 72 +++++++++++---
arch/powerpc/configs/prpmc2800_defconfig | 94 ++++++++++++++-----
arch/powerpc/configs/storcenter_defconfig | 86 +++++++++++++----
arch/powerpc/include/asm/topology.h | 4 +-
arch/powerpc/kernel/head_8xx.S | 12 +-
arch/powerpc/kernel/rtas-proc.c | 14 ++--
arch/powerpc/kernel/smp.c | 12 +++
arch/powerpc/kernel/swsusp_32.S | 2 +-
arch/powerpc/kernel/time.c | 11 ++-
arch/powerpc/mm/mmap_64.c | 4 +-
arch/powerpc/platforms/cell/spufs/coredump.c | 2 +-
arch/powerpc/platforms/iseries/vio.c | 2 +
arch/powerpc/platforms/pseries/dlpar.c | 18 +---
arch/powerpc/platforms/pseries/xics.c | 12 +-
drivers/char/Kconfig | 2 +-
drivers/macintosh/smu.c | 2 +-
drivers/macintosh/therm_pm72.c | 2 +-
drivers/macintosh/therm_windtunnel.c | 2 +-
drivers/serial/pmac_zilog.c | 11 ++
75 files changed, 3837 insertions(+), 1175 deletions(-)
^ permalink raw reply
* jffs2_gcd_mtdx thread and umount problem.
From: Johnny Hung @ 2010-01-18 7:04 UTC (permalink / raw)
To: linux-embedded, linuxppc-dev, linux-mtd
Hi All,
I have a customized MPC8313 (ppc arch) board with SPANSION 64MB NOR
flash, everything works fine but I found a abnormal about JFFS2 flahs
filesystem.
The system will mount JFFS2 to /mnt/mtd when system boot up. I try to
execute umount /mnt/mtd or sync or reboot right away after login then
these commands hangs. Use ps command to check process status and is D
(Uninterruptible sleep, usually IO). I try to kill jffs2_gcd_mtd4 and
umount/reboot/syc commands execute successfully. I think
jffs2_gcd_mtd4 (mount /dev/mtd4) do something in the background so I
wait for 10 minutes after login and execute the same commands and it
doesn't hangs.
The following procedure is I to make jffs2 file system and write to
flash then mount to /mnt/mtd.
1. mkfs.jffs2 -d mtd -e 0x20000 --pad 0x3080000 -o mtd.jffs2 (erase
block size is 128KB and jffs2 partition size is 48.5MB)
2. write jffs2 file system to flash in uboot.
tftpboot 200000 mtd.jffs2; (load mtd.jffs2 to memory)
protect off f8f80000 fbffffff;
erase f8f80000 fbffffff; (erase all 48.5MB)
cp.b 200000 f8f80000 $filesize; (program mtd.jffs2 to flash)
protect on f8f80000 fbffffff;
cmp.b 200000 f8f80000 $filesize
3. Add below in /etc/fstab file to mount to /mnt/mtd
/dev/mtdblock4 /mnt/mtd jffs2 defaults 1 1
Does anyone knows what purpose for jffs2_gcd_mtdx thread and why it
cause umount/sync/reboot commands hangs it is reasonable or something
I did wrong?
BRs, H. Johnny
^ permalink raw reply
* Re: jffs2_gcd_mtdx thread and umount problem.
From: Joakim Tjernlund @ 2010-01-18 7:57 UTC (permalink / raw)
To: Johnny Hung; +Cc: linuxppc-dev, linux-mtd, linux-embedded
In-Reply-To: <cb9ecdfa1001172304q132d5324qa963d0d5cdfb7806@mail.gmail.com>
>
> Hi All,
>
> I have a customized MPC8313 (ppc arch) board with SPANSION 64MB NOR
> flash, everything works fine but I found a abnormal about JFFS2 flahs
> filesystem.
>
> The system will mount JFFS2 to /mnt/mtd when system boot up. I try to
> execute umount /mnt/mtd or sync or reboot right away after login then
> these commands hangs. Use ps command to check process status and is D
> (Uninterruptible sleep, usually IO). I try to kill jffs2_gcd_mtd4 and
> umount/reboot/syc commands execute successfully. I think
> jffs2_gcd_mtd4 (mount /dev/mtd4) do something in the background so I
> wait for 10 minutes after login and execute the same commands and it
> doesn't hangs.
>
> The following procedure is I to make jffs2 file system and write to
> flash then mount to /mnt/mtd.
>
> 1. mkfs.jffs2 -d mtd -e 0x20000 --pad 0x3080000 -o mtd.jffs2 (erase
> block size is 128KB and jffs2 partition size is 48.5MB)
>
> 2. write jffs2 file system to flash in uboot.
> tftpboot 200000 mtd.jffs2; (load mtd.jffs2 to memory)
> protect off f8f80000 fbffffff;
> erase f8f80000 fbffffff; (erase all 48.5MB)
> cp.b 200000 f8f80000 $filesize; (program mtd.jffs2 to flash)
> protect on f8f80000 fbffffff;
> cmp.b 200000 f8f80000 $filesize
>
> 3. Add below in /etc/fstab file to mount to /mnt/mtd
> /dev/mtdblock4 /mnt/mtd jffs2 defaults 1 1
>
> Does anyone knows what purpose for jffs2_gcd_mtdx thread and why it
> cause umount/sync/reboot commands hangs it is reasonable or something
> I did wrong?
I guess this is the first reboot after mounting a new JFFS2 FS?
Then JFFS2 is reerasing empty blocks and you will have to wait
until it is done.
I posted a patch long ago for this, but it was racy w.r.t JFSS2 module unload so
it didn't make it into the repo. Search the list for
"[JFFS2] Stop erasing blocks when rebooting." to find my old patch
Jocke
^ permalink raw reply
* Weird crash of kernel during module loading on mpc8548 based board
From: Alex Dubov @ 2010-01-18 8:14 UTC (permalink / raw)
To: linuxppc-dev
Greetings.=0A=0AI've got a rather weird problem and hope that somebody may =
have encountered=0Ait before.=0A=0AI've got an MPC8548 based board which wa=
s not supported by the=0Au-boot/kernel, but was quite similar to other AMC =
boards of this sort. I=0Apatched up the kernel and stress-tested the board =
quite extensively=0A(essentially, by compiling a whole gentoo distro native=
ly on it, which=0Atook me a couple of weeks :-). Board has a single SODIMM =
with 512 MB=0Amemory installed.=0A=0ANow, I enabled a loadable module suppo=
rt and want to load a small module=0AI'm working on. However, all my attemp=
ts to load the module lead to=0Aimmediate kernel segfault, at precisely the=
first command of the=0Amodule_init function.=0A=0AI'm working with a git h=
ead version of the kernel (2.6.33-rc4-xx).=0AAll user space functionality w=
orks fine - I'm running a fully featured=0Aworkstation setup on it over nfs=
root.=0A=0AHere is the debug dump:=0A-bash: HISTORY: PID=3D1731 UID=3D0 mo=
dprobe rio_core=0A[ 34.149070] load_module: umod=3D4802f008, len=3D141251=
, uargs=3D1001d160=0A[ 34.150198] Core section allocation order:=0A[ 34=
.150212] .text=0A[ 34.150217] .exit.text=0A[ 34.150221]=
.plt=0A[ 34.150226] .note.gnu.build-id=0A[ 34.150231] =
__ksymtab_strings=0A[ 34.150236] .rodata.str1.4=0A[ 34.=
150241] __ksymtab=0A[ 34.150246] __kcrctab=0A[ 34.15025=
1] .data=0A[ 34.150256] .gnu.linkonce.this_module=0A[ 3=
4.150261] .bss=0A[ 34.150266] Init section allocation order:=0A[ =
34.150273] .init.text=0A[ 34.150277] .init.plt=0A[ 34=
.150285] .symtab=0A[ 34.150339] .strtab=0A[ 34.150410] =
final section addresses:=0A[ 34.150418] 0xe10ac2f8 .note.gnu.buil=
d-id=0A[ 34.150434] 0xe10ab000 .text=0A[ 34.150440] 0xe=
10ac1a4 .exit.text=0A[ 34.150446] 0xe10b0000 .init.text=0A[ 34.=
150453] 0xe10ac31c __ksymtab_strings=0A[ 34.150460] 0xe10=
ac37c .rodata.str1.4=0A[ 34.150466] 0xe10ac5bc __ksymtab=0A[ 34=
.150472] 0xe10ac5ec __kcrctab=0A[ 34.150479] 0xe10ac604 .=
data=0A[ 34.150486] 0xe10ac728 .gnu.linkonce.this_module=0A[ 34=
.150492] 0xe10ac870 .bss=0A[ 34.150497] 0xe10ac1a8 .plt=
=0A[ 34.150503] 0xe10b0058 .init.plt=0A[ 34.150514] 0xe=
10b0068 .symtab=0A[ 34.150524] 0xe10b0f08 .strtab=0A[ 34.150545=
] kobject: 'rio_core' (e10ac770): kobject_add_internal:=0Aparent: 'module',=
set: 'module'=0A[ 34.150580] Absolute symbol: 0x00000000=0A[ 34.150586=
] Absolute symbol: 0x00000000=0A[ 34.150593] Absolute symbol: 0x00000000=
=0A[ 34.151961] Absolute symbol: 0xb77d8702=0A[ 34.152726] Absolute sym=
bol: 0x137e9f0d=0A[ 34.152869] Absolute symbol: 0x86125fdb=0A[ 34.15342=
8] Absolute symbol: 0xc4a5e8df=0A[ 34.153728] Absolute symbol: 0x74e7f0ed=
=0A[ 34.153866] Absolute symbol: 0xb45adf12=0A[ 34.154328] Failed to fi=
nd symbol rio_free_iface=0A[ 34.154676] Failed to find symbol rio_remove_=
iface=0A[ 34.155024] Failed to find symbol rio_add_iface=0A[ 34.155372]=
Failed to find symbol rio_alloc_iface=0A[ 34.155720] Failed to find symb=
ol copy_toio_be32=0A[ 34.156080] Failed to find symbol copy_fromio_be32=
=0A[ 34.162175] kobject: 'holders' (df19a700): kobject_add_internal: pare=
nt:=0A'rio_core', set: '<NULL>'=0A[ 34.162201] kobject: 'rio_core' (e10ac=
770): kobject_uevent_env=0A[ 34.162220] kobject: 'rio_core' (e10ac770): f=
ill_kobj_path: path =3D=0A'/module/rio_core'=0A[ 34.163393] kobject: 'not=
es' (df19a540): kobject_add_internal: parent:=0A'rio_core', set: '<NULL>'=
=0A[ 34.163457] Unable to handle kernel paging request for instruction fe=
tch=0A[ 34.163465] Faulting instruction address: 0xe10b0000=0A[ 34.1634=
76] Oops: Kernel access of bad area, sig: 11 [#1]=0A[ 34.168864] STX AMC8=
548=0A[ 34.171299] Modules linked in: rio_core(+)=0A[ 34.175395] NIP: e=
10b0000 LR: c0001dc0 CTR: e10b0000=0A[ 34.180349] REGS: df1b1e50 TRAP: 04=
00 Not tainted (2.6.33-rc4-00193-=0Agd1e4922-dirty)=0A[ 34.188248] MSR=
: 00029000 <EE,ME,CE> CR: 24022482 XER: 00000000=0A[ 34.194360] TASK =
=3D dfa4d2c0[1736] 'modprobe' THREAD: df1b0000=0A[ 34.199918] GPR00: 0000=
0000 df1b1f00 dfa4d2c0 e10b0000 00000001 e10ac728=0Affffffff 00000000=0A[ =
34.208295] GPR08: 0000002c df1b0000 c0bfd000 0000006c 00000005 10024204=0A=
1ffebe00 1001c598=0A[ 34.216672] GPR16: 00000000 00000000 00000003 1001d5=
74 00000000 10005b10=0A00000000 00000000=0A[ 34.225049] GPR24: 1001d428 0=
0000000 000227c3 1001d160 c04a6c80 c04a6c8c=0A000000000 e10b0000=0A[ 34.2=
33636] NIP [e10b0000] rio_init+0x0/0x68 [rio_core]=0A[ 34.238856] LR [c00=
01dc0] do_one_initcall+0x74/0x220=0A[ 34.243807] Call Trace:=0A[ 34.246=
253] [df1b1f20] [c00617ec] sys_init_module+0xf4/0x250=0A[ 34.251912] [df1=
b1f40] [c000fa18] ret_from_syscall+0x0/0x3c=0A[ 34.257473] Instruction du=
mp:=0A[ 34.260434] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX=
=0AXXXXXXXX XXXXXXXX=0A[ 34.268197] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX <=
9421fff0> 3c60e10b=0A7c0802a6 3863c37c=0A[ 34.276187] ---[ end trace 72ab=
109d9f179c15 ]---=0A=0A=0A=0A=0A _____________________________________=
_____________________________________________=0ASee what's on at the movies=
in your area. Find out now: http://au.movies.yahoo.com/session-times/
^ permalink raw reply
* Re: jffs2_gcd_mtdx thread and umount problem.
From: Johnny Hung @ 2010-01-18 8:26 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, linux-mtd, linux-embedded
In-Reply-To: <OF593A1F75.3C3C7D18-ONC12576AF.002B1239-C12576AF.002BB30A@transmode.se>
Yes, umount / reboot command doesn't hang after first boot + wait for
20 minutes. The jffs2_gcd_mtdx will re-erase empty blocks but how do I
know it is finished?
BTW, why jffs2_gcd_mtd need to re-erase empty blocks and it will cause
some command cannot work if erase block is necessary. I mean many
pepple could meet this problem if it is need to erase empty block and
how do they overcome or workaround it.
Thank you so much, Jocke
BRs, H. Johnny
> I guess this is the first reboot after mounting a new JFFS2 FS?
> Then JFFS2 is reerasing empty blocks and you will have to wait
> until it is done.
>
> I posted a patch long ago for this, but it was racy w.r.t JFSS2 module un=
load so
> it didn't make it into the repo. Search the list for
> "[JFFS2] Stop erasing blocks when rebooting." to find my old patch
>
> =A0Jocke
>
>
^ permalink raw reply
* Re: jffs2_gcd_mtdx thread and umount problem.
From: Joakim Tjernlund @ 2010-01-18 9:13 UTC (permalink / raw)
To: Johnny Hung; +Cc: linuxppc-dev, linux-mtd, linux-embedded
In-Reply-To: <cb9ecdfa1001180026q5856b170t3f4c71191a7b99d8@mail.gmail.com>
Johnny Hung <johnny.hacking@gmail.com> wrote on 18/01/2010 09:26:26:
>
Please don't top post.
> Yes, umount / reboot command doesn't hang after first boot + wait for=
> 20 minutes. The jffs2_gcd_mtdx will re-erase empty blocks but how do =
I
> know it is finished?
You don't or just monitor jffs2_gcd_mtdx until it is finished.
>
> BTW, why jffs2_gcd_mtd need to re-erase empty blocks and it will caus=
e
> some command cannot work if erase block is necessary. I mean many
> pepple could meet this problem if it is need to erase empty block and=
> how do they overcome or workaround it.
Because it might not be completely erased due to power failure in the
middle of an erase. You get random bit flips if that happens.
You can avoid this by writing clean markers in every empty block when y=
ou
install it, a bit messy though and it won't solve the general problem: =
Try
removing a few big files and then reboot, you will have to wait then to=
o.
If you don't use JFFS2 as a module and unload it, you can my old patch =
which will
solve both problems.
Jocke
>
> Thank you so much, Jocke
> BRs, H. Johnny
>
> > I guess this is the first reboot after mounting a new JFFS2 FS?
> > Then JFFS2 is reerasing empty blocks and you will have to wait
> > until it is done.
> >
> > I posted a patch long ago for this, but it was racy w.r.t JFSS2 mod=
ule unload so
> > it didn't make it into the repo. Search the list for
> > "[JFFS2] Stop erasing blocks when rebooting." to find my old patch
> >
> > =A0Jocke
> >
> >
>=
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Josh Boyer @ 2010-01-18 12:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <1263797148.724.484.camel@pasglop>
On Mon, Jan 18, 2010 at 05:45:48PM +1100, Benjamin Herrenschmidt wrote:
>Hi Linus !
>
>A tad late due to me slacking and leaving the patches take dust in
>patchwork for a bit too long, but here are a few bug fixes for powerpc
>and a bunch of defconfig freshen ups for some of our embedded platforms.
You missed my defconfig updates. I sent you a pull request 2 weeks ago.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079309.html
Those are still sitting in that tree on that branch if someone wanted to pull
them directly.
josh
^ permalink raw reply
* [PATCH 03/32] hvc_console: make the ops pointer const.
From: Amit Shah @ 2010-01-18 13:44 UTC (permalink / raw)
To: rusty; +Cc: Amit Shah, linuxppc-dev, virtualization
In-Reply-To: <1263822326-24208-3-git-send-email-amit.shah@redhat.com>
From: Rusty Russell <rusty@rustcorp.com.au>
This is nicer for modern R/O protection. And noone needs it non-const, so
constify the callers as well.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linuxppc-dev@ozlabs.org
---
drivers/char/hvc_beat.c | 2 +-
drivers/char/hvc_console.c | 7 ++++---
drivers/char/hvc_console.h | 7 ++++---
drivers/char/hvc_iseries.c | 2 +-
drivers/char/hvc_iucv.c | 2 +-
drivers/char/hvc_rtas.c | 2 +-
drivers/char/hvc_udbg.c | 2 +-
drivers/char/hvc_vio.c | 2 +-
drivers/char/hvc_xen.c | 2 +-
drivers/char/virtio_console.c | 2 +-
10 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/char/hvc_beat.c b/drivers/char/hvc_beat.c
index 0afc8b8..6913fc3 100644
--- a/drivers/char/hvc_beat.c
+++ b/drivers/char/hvc_beat.c
@@ -84,7 +84,7 @@ static int hvc_beat_put_chars(uint32_t vtermno, const char *buf, int cnt)
return cnt;
}
-static struct hv_ops hvc_beat_get_put_ops = {
+static const struct hv_ops hvc_beat_get_put_ops = {
.get_chars = hvc_beat_get_chars,
.put_chars = hvc_beat_put_chars,
};
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 416d342..d8dac58 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -125,7 +125,7 @@ static struct hvc_struct *hvc_get_by_index(int index)
* console interfaces but can still be used as a tty device. This has to be
* static because kmalloc will not work during early console init.
*/
-static struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
+static const struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
{[0 ... MAX_NR_HVC_CONSOLES - 1] = -1};
@@ -247,7 +247,7 @@ static void destroy_hvc_struct(struct kref *kref)
* vty adapters do NOT get an hvc_instantiate() callback since they
* appear after early console init.
*/
-int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops)
+int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops)
{
struct hvc_struct *hp;
@@ -749,7 +749,8 @@ static const struct tty_operations hvc_ops = {
};
struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
- struct hv_ops *ops, int outbuf_size)
+ const struct hv_ops *ops,
+ int outbuf_size)
{
struct hvc_struct *hp;
int i;
diff --git a/drivers/char/hvc_console.h b/drivers/char/hvc_console.h
index 10950ca..52ddf4d 100644
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -55,7 +55,7 @@ struct hvc_struct {
int outbuf_size;
int n_outbuf;
uint32_t vtermno;
- struct hv_ops *ops;
+ const struct hv_ops *ops;
int irq_requested;
int data;
struct winsize ws;
@@ -76,11 +76,12 @@ struct hv_ops {
};
/* Register a vterm and a slot index for use as a console (console_init) */
-extern int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops);
+extern int hvc_instantiate(uint32_t vtermno, int index,
+ const struct hv_ops *ops);
/* register a vterm for hvc tty operation (module_init or hotplug add) */
extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int data,
- struct hv_ops *ops, int outbuf_size);
+ const struct hv_ops *ops, int outbuf_size);
/* remove a vterm from hvc tty operation (module_exit or hotplug remove) */
extern int hvc_remove(struct hvc_struct *hp);
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 936d05b..fd02426 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -197,7 +197,7 @@ done:
return sent;
}
-static struct hv_ops hvc_get_put_ops = {
+static const struct hv_ops hvc_get_put_ops = {
.get_chars = get_chars,
.put_chars = put_chars,
.notifier_add = notifier_add_irq,
diff --git a/drivers/char/hvc_iucv.c b/drivers/char/hvc_iucv.c
index fe62bd0..21681a8 100644
--- a/drivers/char/hvc_iucv.c
+++ b/drivers/char/hvc_iucv.c
@@ -922,7 +922,7 @@ static int hvc_iucv_pm_restore_thaw(struct device *dev)
/* HVC operations */
-static struct hv_ops hvc_iucv_ops = {
+static const struct hv_ops hvc_iucv_ops = {
.get_chars = hvc_iucv_get_chars,
.put_chars = hvc_iucv_put_chars,
.notifier_add = hvc_iucv_notifier_add,
diff --git a/drivers/char/hvc_rtas.c b/drivers/char/hvc_rtas.c
index 88590d0..61c4a61 100644
--- a/drivers/char/hvc_rtas.c
+++ b/drivers/char/hvc_rtas.c
@@ -71,7 +71,7 @@ static int hvc_rtas_read_console(uint32_t vtermno, char *buf, int count)
return i;
}
-static struct hv_ops hvc_rtas_get_put_ops = {
+static const struct hv_ops hvc_rtas_get_put_ops = {
.get_chars = hvc_rtas_read_console,
.put_chars = hvc_rtas_write_console,
};
diff --git a/drivers/char/hvc_udbg.c b/drivers/char/hvc_udbg.c
index bd63ba8..b0957e6 100644
--- a/drivers/char/hvc_udbg.c
+++ b/drivers/char/hvc_udbg.c
@@ -58,7 +58,7 @@ static int hvc_udbg_get(uint32_t vtermno, char *buf, int count)
return i;
}
-static struct hv_ops hvc_udbg_ops = {
+static const struct hv_ops hvc_udbg_ops = {
.get_chars = hvc_udbg_get,
.put_chars = hvc_udbg_put,
};
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index 10be343..27370e9 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -77,7 +77,7 @@ static int filtered_get_chars(uint32_t vtermno, char *buf, int count)
return got;
}
-static struct hv_ops hvc_get_put_ops = {
+static const struct hv_ops hvc_get_put_ops = {
.get_chars = filtered_get_chars,
.put_chars = hvc_put_chars,
.notifier_add = notifier_add_irq,
diff --git a/drivers/char/hvc_xen.c b/drivers/char/hvc_xen.c
index b1a7163..60446f8 100644
--- a/drivers/char/hvc_xen.c
+++ b/drivers/char/hvc_xen.c
@@ -122,7 +122,7 @@ static int read_console(uint32_t vtermno, char *buf, int len)
return recv;
}
-static struct hv_ops hvc_ops = {
+static const struct hv_ops hvc_ops = {
.get_chars = read_console,
.put_chars = write_console,
.notifier_add = notifier_add_irq,
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 1d844a4..791be4e 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -163,7 +163,7 @@ static void hvc_handle_input(struct virtqueue *vq)
}
/* The operations for the console. */
-static struct hv_ops hv_ops = {
+static const struct hv_ops hv_ops = {
.get_chars = get_chars,
.put_chars = put_chars,
.notifier_add = notifier_add_vio,
--
1.6.2.5
^ permalink raw reply related
* [PATCH 04/32] hvc_console: Remove __devinit annotation from hvc_alloc
From: Amit Shah @ 2010-01-18 13:44 UTC (permalink / raw)
To: rusty; +Cc: Amit Shah, linuxppc-dev, virtualization
In-Reply-To: <1263822326-24208-4-git-send-email-amit.shah@redhat.com>
Virtio consoles can be hotplugged, so hvc_alloc gets called from
multiple sites: from the initial probe() routine as well as later on
from workqueue handlers which aren't __devinit code.
So, drop the __devinit annotation for hvc_alloc.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Cc: linuxppc-dev@ozlabs.org
---
drivers/char/hvc_console.c | 6 +++---
drivers/char/hvc_console.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d8dac58..4c3b59b 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -748,9 +748,9 @@ static const struct tty_operations hvc_ops = {
.chars_in_buffer = hvc_chars_in_buffer,
};
-struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
- const struct hv_ops *ops,
- int outbuf_size)
+struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
+ const struct hv_ops *ops,
+ int outbuf_size)
{
struct hvc_struct *hp;
int i;
diff --git a/drivers/char/hvc_console.h b/drivers/char/hvc_console.h
index 52ddf4d..54381eb 100644
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -80,8 +80,8 @@ extern int hvc_instantiate(uint32_t vtermno, int index,
const struct hv_ops *ops);
/* register a vterm for hvc tty operation (module_init or hotplug add) */
-extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int data,
- const struct hv_ops *ops, int outbuf_size);
+extern struct hvc_struct * hvc_alloc(uint32_t vtermno, int data,
+ const struct hv_ops *ops, int outbuf_size);
/* remove a vterm from hvc tty operation (module_exit or hotplug remove) */
extern int hvc_remove(struct hvc_struct *hp);
--
1.6.2.5
^ permalink raw reply related
* got problem with timer interrupt
From: wilbur.chan @ 2010-01-18 15:28 UTC (permalink / raw)
To: linuxppc-dev
A timer has been added into my system, and it is used to generate
continuous interrupt every 1 ms.
This hw is register by request_irq(19, handler_1ms)
Howeve I found that , it is longer than 1 ms between two interrupts,
for I used get_cycles everytime we entered
do_irq :
if(irq==19)
{
delta = get_cycle()-old;
}
but to find that delta is always larger than cpu cycles between 1ms.
Does anyone know why this happened?
regards,
^ permalink raw reply
* [PATCH] ucc_geth: Fix full TX queue processing
From: Anton Vorontsov @ 2010-01-18 15:47 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev, Wu Jiajun-B06378, lsorense
From: Jiajun Wu <b06378@freescale.com>
commit 7583605b6d29f1f7f6fc505b883328089f3485ad ("ucc_geth: Fix empty
TX queue processing") fixed empty TX queue mishandling, but didn't
account another corner case: when TX queue becomes full.
Without this patch the driver will stop transmiting when TX queue
becomes full since 'bd == ugeth->txBd[txQ]' actually checks for
two things: queue empty or full.
Let's better check for NULL skb, which unambiguously signals an empty
queue.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Stable <stable@vger.kernel.org> [2.6.32]
---
On Mon, Jan 11, 2010 at 07:52:26PM +0800, Wu Jiajun-B06378 wrote:
> Yes,'if (!skb)' is enough.
> You can reproduce transmitting stopping if you use
> 'if ((bd == ugeth->txBd[txQ])' and run ipforwarding with MTU=64
> 1Gbps 100%linerate.
OK, let's resend the patch with just !skb check?
drivers/net/ucc_geth.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 96bdc0b..eb8fe7e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3279,13 +3279,12 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
- if (bd == ugeth->txBd[txQ]) /* queue empty? */
+ skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
+ if (!skb)
break;
dev->stats.tx_packets++;
- skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
-
if (skb_queue_len(&ugeth->rx_recycle) < RX_BD_RING_LEN &&
skb_recycle_check(skb,
ugeth->ug_info->uf_info.max_rx_buf_length +
--
1.6.5.7
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: Fix oops during MSI driver probe on MPC85xxMDS boards
From: Anton Vorontsov @ 2010-01-18 15:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20091215225809.GA32140@oksana.dev.rtsoft.ru>
On Wed, Dec 16, 2009 at 01:58:09AM +0300, Anton Vorontsov wrote:
> MPC85xx chips report the wrong value in feature reporting register,
> and that causes the following oops:
>
> Unable to handle kernel paging request for data at address 0x00000c00
> Faulting instruction address: 0xc0019294
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC8569 MDS
> Modules linked in:
> [...]
> NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
> LR [c0019124] mpic_set_irq_type+0x180/0x368
> Call Trace:
> [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
> [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
> [ef851db0] [c007b550] set_irq_type+0x40/0x7c
> [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
> [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
> [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
> [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
> [...]
>
> This is because mpic_alloc() assigns wrong values to
> mpic->isu_{size,shift,mask}, and things eventually break when
> _mpic_irq_read() is trying to use them.
>
> This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Kumar,
Did you miss this patch or it's just in a queue for review?
Thanks!
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> index c5028a2..6491f7c 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> @@ -338,7 +338,8 @@ static void __init mpc85xx_mds_pic_init(void)
> }
>
> mpic = mpic_alloc(np, r.start,
> - MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN |
> + MPIC_BROKEN_FRR_NIRQS,
> 0, 256, " OpenPIC ");
> BUG_ON(mpic == NULL);
> of_node_put(np);
> --
> 1.6.3.3
^ permalink raw reply
* GE GPIO and PIC support.
From: Martyn Welch @ 2010-01-18 16:20 UTC (permalink / raw)
To: linuxppc-dev list
Hi,
I'm currently adding support for a GE board based on the Freescale
P2020. This board has a cascaded interrupt controller and GPIO which
should be compatible with drivers currently provided for the MPC8641D
based boards that are already in the kernel.
At the moment the drivers (in gef_gpio.c and gef_pic.c) are in the
"arch/powerpc/platforms/86xx" folder. As the p2020 is not 86xx, I guess
I should move these drivers to a more central location. I'm currently
not sure where would be best to move them to, I see
"arch/powerpc/sysdev" and "arch/powerpc/platforms" as potential
locations, where would be the most suitable?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: xilinx-pci driver and pci in general
From: Grant Likely @ 2010-01-18 17:36 UTC (permalink / raw)
To: michal.simek
Cc: Arnd Bergmann, thunderbird2k, LKML, linuxppc-dev, John Williams
In-Reply-To: <4B4DE58D.10008@petalogix.com>
On Wed, Jan 13, 2010 at 8:23 AM, Michal Simek
<michal.simek@petalogix.com> wrote:
> Hi guys,
>
> We (John and partially I) did initial support for pci on Microblaze.
> It is based on powerpc files and almost everything is the same.
> There are some small differences which could be easily removed that's why I
> think that will be good to move that file to any generic location.
> That's why I would like to know your opinion about this step.
> If you don't like or prefer we will add that modified versions to
> arch/microblaze and in future we can merge them and move to any other
> location.
>
> Affected files: xilinx-pci.c, pci_32.c pci-common.c, indirect_pci.c and some
> headers.
My preference is to move the common bits to a common location first,
and then modify to make it suitable for Microblaze also. I've just
finished doing a bunch of fdt merge work where PowerPC and Microblaze
diverged in subtle ways. It isn't a whole lot of fun.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: xilinx-pci driver and pci in general
From: Grant Likely @ 2010-01-18 17:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, linuxppc-dev, thunderbird2k, LKML, michal.simek,
John Williams
In-Reply-To: <1263434836.724.317.camel@pasglop>
On Wed, Jan 13, 2010 at 7:07 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:
>
>> The main problems are:
>> ppc use ppc_md struct which we don't have it on Microblaze.
>> xilinx-pci driver uses exclude_device function. This function is used in
>> indirect_pci.c too. There could be a way to move that function directly
>> to pci_controller structure which could be useful for other controllers
>> too. What do you think?
>>
>> Then there are some other ppc_md. calling like pcibios_after_init which
>> if I see correctly not used for ppc too.
>
> We may not be using after_init() anymore in which case you are welcome
> to send a patch to remove it :-)
>
> As for the others, well ... maybe you can do wrappers for these that
> call into ppc_md. on powerpc and into some kind of arch_pci_ops. that
> the platform provides on microblaze ?
I agree. Replace the direct ppc_md. references with arch-provided wrappers.
>> Files contains CONFIG_PPC_OF and we would like to use only CONFIG_OF.
>> I remember any discuss around but not sure what was the conclusion on
>> powerpc.
>
> I think that should be allright, Grant, any objection there ?
None whatsoever.
>> Part of headers are the same that's why there will be a space to move
>> them to asm-generic.
>
> If you can convince other archs that it makes sense to do so ? :-)
Arnd can give you good advice here I think.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: xilinx-pci driver and pci in general
From: Grant Likely @ 2010-01-18 17:39 UTC (permalink / raw)
To: monstr
Cc: Arnd Bergmann, michal.simek, thunderbird2k, LKML, linuxppc-dev,
John Williams
In-Reply-To: <4B503422.60209@monstr.eu>
On Fri, Jan 15, 2010 at 2:23 AM, Michal Simek <monstr@monstr.eu> wrote:
> Benjamin Herrenschmidt wrote:
>> On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:
>>> Thanks for this early discuss. I would like to hear your opinion and then
>>> I will choose solution how to add our pci support to mainline.
>
> I will keep you informed but I see that I will add that part of code to
> mainline and then we look at consolidation work.
As mentioned in previous email, please do it the other way around. It
may seem like more work to do so, but it is less work in the long
term.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Need advice on changing MPC5200B UART prescaler
From: Grant Likely @ 2010-01-18 18:36 UTC (permalink / raw)
To: Sylvain Lamontagne; +Cc: linuxppc-dev
In-Reply-To: <3e45db430912170757v20209609y61498e287928d47b@mail.gmail.com>
On Thu, Dec 17, 2009 at 8:57 AM, Sylvain Lamontagne
<sylvain.lamontagne@gmail.com> wrote:
> Hi all,
> I would like to be able to set a baud rate of 460800 for modem that we ar=
e
> testing. With the actual prescaler of 32 and a IPB frequency of 84MHz
> I got a 5.1% error (437500) vs a 0.9% error (456522) if I could use the
> prescaler of 4. See MPC5200B user manual page 15-46 for the calculation
> formula and page 15-12 for the CSR description.
> Currently the code for the kernel we are using here, (2.6.29.2) seams not=
to
> take a prescaler of 4 into account.
> Line 249 of
> mpc52xx_uart.c=A0http://lxr.linux.no/linux+v2.6.29.2/drivers/serial/mpc52=
xx_uart.c#L249
> /* Search for bus-frequency property in this node or a parent */
> static unsigned long mpc52xx_getuartclk(void *p)
> {
> =A0=A0 =A0 =A0 =A0/*
> =A0=A0 =A0 =A0 =A0 * 5200 UARTs have a / 32 prescaler
> =A0=A0 =A0 =A0 =A0 * but the generic serial code assumes 16
> =A0=A0 =A0 =A0 =A0 * so return ipb freq / 2
> =A0=A0 =A0 =A0 =A0 */
> =A0=A0 =A0 =A0 =A0return mpc52xx_find_ipb_freq(p) / 2;
> }
> How could I make it use the prescaler of 4 without breaking anything that=
we
> currently have working ?
> I doubt that simply doing=A0=A0return mpc52xx_find_ipb_freq(p) / 4 would =
do the
> trick ...
since 32 prescale is scaled to 16 by dividing by 2, then 4 would be
scaled to 16 by multiplying by 4. Have you tried
mpc52xx_find_ipb_freq(p) * 4? You'll need to add some method for the
uart driver to either set the prescaler at boot time or to figure out
on its own which prescaler would be best.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: GE GPIO and PIC support.
From: Kumar Gala @ 2010-01-18 19:41 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev list
In-Reply-To: <4B548A6A.5010708@ge.com>
On Jan 18, 2010, at 10:20 AM, Martyn Welch wrote:
> Hi,
>=20
> I'm currently adding support for a GE board based on the Freescale
> P2020. This board has a cascaded interrupt controller and GPIO which
> should be compatible with drivers currently provided for the MPC8641D
> based boards that are already in the kernel.
>=20
> At the moment the drivers (in gef_gpio.c and gef_pic.c) are in the
> "arch/powerpc/platforms/86xx" folder. As the p2020 is not 86xx, I =
guess
> I should move these drivers to a more central location. I'm currently
> not sure where would be best to move them to, I see
> "arch/powerpc/sysdev" and "arch/powerpc/platforms" as potential
> locations, where would be the most suitable?
I would suggest arch/powerpc/platforms as its board specific code and =
not chip specific. However others gripe at me about that from time to =
time.
- k=
^ permalink raw reply
* Re: Problem dtb file booting Kernel 2.6.32
From: Andres F Marquez @ 2010-01-18 20:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Hunter Cobbs
In-Reply-To: <1263614364.2806.20.camel@ccs-laptop>
Hello,
I finally got the dtb working for the Kernel 2.6.32.2. I went to an
old folder backup that I had in which I found some files used by LTIB
for the Kernel configuration and restore them (including .config file).
Then, I removed the /localbus and /pci references from my dtb file
because I am not using them at this point. I did it using the fdt
utility under uboot.
Thank you everyone for your help.
--
Andres F Marquez
EdgeAccess
Development
amarquez@edgeaccess.net
On Fri, 2010-01-15 at 21:59 -0600, Hunter Cobbs wrote:
> Hi,
>
> If you're going to attempt to use v1 dts, you might want to try to add
>
>
> * option) any later version.
> */
>
> /dts-v1/;
>
> / {
>
> to your DTS file. Also, you'll want to prefix all of your hex addresses
> with "0x" so, 200000 = 0x200000
>
> Hope that helps,
> Hunter
>
>
> On Fri, 2010-01-15 at 09:30 -0500, Andres F Marquez wrote:
> > Hello,
> >
> > I was able to boot Kernel 2.6.26.8 (using our old dts file from
> > Kernel 2.6.25). However, I need to upgrade to a newer Kernel because
> > I am having serious problems with the ethernet interface under heavy
> > load. I am not sure if it could be a scheduling problem or the network
> > driver. CPU usage is low but load average is high (more than 4).
> >
> > The main difference that I could find is that for newer Kernels the
> > /arch/ppc was removed. I also read online that dts version changed
> > from 0 to 1 somewhere around Kernel 2.6.27 or so.
> >
> > Following your instruction, I executed in the LTIB command shell:
> >
> > LTIB> dtc -I dtb -O dts ../mpc8272ads.dtb
> >
> > I executed that command passing as argument the old working dtb file.
> > I got a dts file which I placed in the new Kernel and compiled.
> > Unfortunately, I am still getting the same error.
> >
> > Attached you can find both dts files.
> >
> > Thank you.
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface
From: Dave Kleikamp @ 2010-01-18 21:57 UTC (permalink / raw)
To: linuxppc-dev list
Cc: Sergio Durigan Junior, David Gibson, Torez Smith,
Thiago Jung Bauermann
These patches implement an extention to the ptrace interface proposed by
Thiago Bauermann and the the PowerPC gdb team.
This is a resubmission of the patches I first sent on December 9th.
Sorry for the delay. I have addressed most of the comments, and I'll
follow up on the others.
These patches are based on 2.6.33-rc3. (Nothing really changed in powerpc
between rc3 & rc4.) These patches still need some testing, but I want
to get the ball rolling again.
The following has been added as Documentation/powerpc/ptrace.txt:
GDB intends to support the following hardware debug features of BookE
processors:
4 hardware breakpoints (IAC)
2 hardware watchpoints (read, write and read-write) (DAC)
2 value conditions for the hardware watchpoints (DVC)
For that, we need to extend ptrace so that GDB can query and set these
resources. Since we're extending, we're trying to create an interface
that's extendable and that covers both BookE and server processors, so
that GDB doesn't need to special-case each of them. We added the
following 3 new ptrace requests.
1. PTRACE_PPC_GETHWDEBUGINFO
Query for GDB to discover the hardware debug features. The main info to
be returned here is the minimum alignment for the hardware watchpoints.
BookE processors don't have restrictions here, but server processors have
an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
adding special cases to GDB based on what it sees in AUXV.
Since we're at it, we added other useful info that the kernel can return to
GDB: this query will return the number of hardware breakpoints, hardware
watchpoints and whether it supports a range of addresses and a condition.
The query will fill the following structure provided by the requesting process:
struct ppc_debug_info {
unit32_t version;
unit32_t num_instruction_bps;
unit32_t num_data_bps;
unit32_t num_condition_regs;
unit32_t data_bp_alignment;
unit32_t sizeof_condition; /* size of the DVC register */
uint64_t features; /* bitmask of the individual flags */
};
features will have bits indicating whether there is support for:
#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
2. PTRACE_SETHWDEBUG
Sets a hardware breakpoint or watchpoint, according to the provided structure:
struct ppc_hw_breakpoint {
uint32_t version;
#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
#define PPC_BREAKPOINT_TRIGGER_READ 0x2
#define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
uint32_t trigger_type; /* only some combinations allowed */
#define PPC_BREAKPOINT_MODE_EXACT 0x0
#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
#define PPC_BREAKPOINT_MODE_MASK 0x3
uint32_t addr_mode; /* address match mode */
#define PPC_BREAKPOINT_CONDITION_MODE 0x3
#define PPC_BREAKPOINT_CONDITION_NONE 0x0
#define PPC_BREAKPOINT_CONDITION_AND 0x1
#define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same thing as above */
#define PPC_BREAKPOINT_CONDITION_OR 0x2
#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000 /* byte enable bits */
#define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
uint32_t condition_mode; /* break/watchpoint condition flags */
uint64_t addr;
uint64_t addr2;
uint64_t condition_value;
};
A request specifies one event, not necessarily just one register to be set.
For instance, if the request is for a watchpoint with a condition, both the
DAC and DVC registers will be set in the same request.
With this GDB can ask for all kinds of hardware breakpoints and watchpoints
that the BookE supports. COMEFROM breakpoints available in server processors
are not contemplated, but that is out of the scope of this work.
ptrace will return an integer (handle) uniquely identifying the breakpoint or
watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
request to ask for its removal. Return -ENOSPC if the requested breakpoint
can't be allocated on the registers.
Some examples of using the structure to:
- set a breakpoint in the first breakpoint register
p.version = PPC_DEBUG_CURRENT_VERSION;
p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
p.addr = (uint64_t) address;
p.addr2 = 0;
p.condition_value = 0;
- set a watchpoint which triggers on reads in the second watchpoint register
p.version = PPC_DEBUG_CURRENT_VERSION;
p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
p.addr = (uint64_t) address;
p.addr2 = 0;
p.condition_value = 0;
- set a watchpoint which triggers only with a specific value
p.version = PPC_DEBUG_CURRENT_VERSION;
p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
p.condition_mode = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
p.addr = (uint64_t) address;
p.addr2 = 0;
p.condition_value = (uint64_t) condition;
- set a ranged hardware breakpoint
p.version = PPC_DEBUG_CURRENT_VERSION;
p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
p.addr = (uint64_t) begin_range;
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
3. PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
corresponding breakpoint or watchpoint..
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [RFC:PATCH 01/03] powerpc: Extended ptrace interface
From: Dave Kleikamp @ 2010-01-18 21:57 UTC (permalink / raw)
To: linuxppc-dev list
Cc: Sergio Durigan Junior, David Gibson, Torez Smith,
Thiago Jung Bauermann
In-Reply-To: <20100118215704.15684.60646.sendpatchset@norville.austin.ibm.com>
powerpc: Extended ptrace interface
From: Torez Smith <lnxtorez@linux.vnet.ibm.com>
Add a new extended ptrace interface so that user-space has a single
interface for powerpc, without having to know the specific layout
of the debug registers.
Implement:
PPC_PTRACE_GETHWDEBUGINFO
PPC_PTRACE_SETHWDEBUG
PPC_PTRACE_DELHWDEBUG
Signed-off-by: Torez Smith <lnxtorez@linux.vnet.ibm.com>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Acked-by: David Gibson <dwg@au1.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Sergio Durigan Junior <sergiodj@br.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: linuxppc-dev list <Linuxppc-dev@ozlabs.org>
---
Documentation/powerpc/ptrace.txt | 134 +++++++++++++++++++++++++++++++++++++
arch/powerpc/include/asm/ptrace.h | 77 +++++++++++++++++++++
arch/powerpc/kernel/ptrace.c | 90 +++++++++++++++++++++++++
3 files changed, 301 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/ptrace.txt
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
new file mode 100644
index 0000000..f4a5499
--- /dev/null
+++ b/Documentation/powerpc/ptrace.txt
@@ -0,0 +1,134 @@
+GDB intends to support the following hardware debug features of BookE
+processors:
+
+4 hardware breakpoints (IAC)
+2 hardware watchpoints (read, write and read-write) (DAC)
+2 value conditions for the hardware watchpoints (DVC)
+
+For that, we need to extend ptrace so that GDB can query and set these
+resources. Since we're extending, we're trying to create an interface
+that's extendable and that covers both BookE and server processors, so
+that GDB doesn't need to special-case each of them. We added the
+following 3 new ptrace requests.
+
+1. PTRACE_PPC_GETHWDEBUGINFO
+
+Query for GDB to discover the hardware debug features. The main info to
+be returned here is the minimum alignment for the hardware watchpoints.
+BookE processors don't have restrictions here, but server processors have
+an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
+adding special cases to GDB based on what it sees in AUXV.
+
+Since we're at it, we added other useful info that the kernel can return to
+GDB: this query will return the number of hardware breakpoints, hardware
+watchpoints and whether it supports a range of addresses and a condition.
+The query will fill the following structure provided by the requesting process:
+
+struct ppc_debug_info {
+ unit32_t version;
+ unit32_t num_instruction_bps;
+ unit32_t num_data_bps;
+ unit32_t num_condition_regs;
+ unit32_t data_bp_alignment;
+ unit32_t sizeof_condition; /* size of the DVC register */
+ uint64_t features; /* bitmask of the individual flags */
+};
+
+features will have bits indicating whether there is support for:
+
+#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
+#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
+#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
+#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
+
+2. PTRACE_SETHWDEBUG
+
+Sets a hardware breakpoint or watchpoint, according to the provided structure:
+
+struct ppc_hw_breakpoint {
+ uint32_t version;
+#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
+#define PPC_BREAKPOINT_TRIGGER_READ 0x2
+#define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
+ uint32_t trigger_type; /* only some combinations allowed */
+#define PPC_BREAKPOINT_MODE_EXACT 0x0
+#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
+#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
+#define PPC_BREAKPOINT_MODE_MASK 0x3
+ uint32_t addr_mode; /* address match mode */
+
+#define PPC_BREAKPOINT_CONDITION_MODE 0x3
+#define PPC_BREAKPOINT_CONDITION_NONE 0x0
+#define PPC_BREAKPOINT_CONDITION_AND 0x1
+#define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same thing as above */
+#define PPC_BREAKPOINT_CONDITION_OR 0x2
+#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
+#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000 /* byte enable bits */
+#define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
+ uint32_t condition_mode; /* break/watchpoint condition flags */
+
+ uint64_t addr;
+ uint64_t addr2;
+ uint64_t condition_value;
+};
+
+A request specifies one event, not necessarily just one register to be set.
+For instance, if the request is for a watchpoint with a condition, both the
+DAC and DVC registers will be set in the same request.
+
+With this GDB can ask for all kinds of hardware breakpoints and watchpoints
+that the BookE supports. COMEFROM breakpoints available in server processors
+are not contemplated, but that is out of the scope of this work.
+
+ptrace will return an integer (handle) uniquely identifying the breakpoint or
+watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
+request to ask for its removal. Return -ENOSPC if the requested breakpoint
+can't be allocated on the registers.
+
+Some examples of using the structure to:
+
+- set a breakpoint in the first breakpoint register
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) address;
+ p.addr2 = 0;
+ p.condition_value = 0;
+
+- set a watchpoint which triggers on reads in the second watchpoint register
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) address;
+ p.addr2 = 0;
+ p.condition_value = 0;
+
+- set a watchpoint which triggers only with a specific value
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
+ p.addr = (uint64_t) address;
+ p.addr2 = 0;
+ p.condition_value = (uint64_t) condition;
+
+- set a ranged hardware breakpoint
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
+3. PTRACE_DELHWDEBUG
+
+Takes an integer which identifies an existing breakpoint or watchpoint
+(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
+corresponding breakpoint or watchpoint..
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index cbd759e..b451081 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -24,6 +24,12 @@
* 2 of the License, or (at your option) any later version.
*/
+#ifdef __KERNEL__
+#include <linux/types.h>
+#else
+#include <stdint.h>
+#endif
+
#ifndef __ASSEMBLY__
struct pt_regs {
@@ -294,4 +300,75 @@ extern void user_disable_single_step(struct task_struct *);
#define PTRACE_SINGLEBLOCK 0x100 /* resume execution until next branch */
+#define PPC_PTRACE_GETHWDBGINFO 0x89
+#define PPC_PTRACE_SETHWDEBUG 0x88
+#define PPC_PTRACE_DELHWDEBUG 0x87
+
+#ifndef __ASSEMBLY__
+
+struct ppc_debug_info {
+ uint32_t version; /* Only version 1 exists to date */
+ uint32_t num_instruction_bps;
+ uint32_t num_data_bps;
+ uint32_t num_condition_regs;
+ uint32_t data_bp_alignment;
+ uint32_t sizeof_condition; /* size of the DVC register */
+ uint64_t features;
+};
+
+#endif /* __ASSEMBLY__ */
+
+/*
+ * features will have bits indication whether there is support for:
+ */
+#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x0000000000000001
+#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x0000000000000002
+#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x0000000000000004
+#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x0000000000000008
+
+#ifndef __ASSEMBLY__
+
+struct ppc_hw_breakpoint {
+ uint32_t version; /* currently, version must be 1 */
+ uint32_t trigger_type; /* only some combinations allowed */
+ uint32_t addr_mode; /* address match mode */
+ uint32_t condition_mode; /* break/watchpoint condition flags */
+ uint64_t addr; /* break/watchpoint address */
+ uint64_t addr2; /* range end or mask */
+ uint64_t condition_value; /* contents of the DVC register */
+};
+
+#endif /* __ASSEMBLY__ */
+
+/*
+ * Trigger Type
+ */
+#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x00000001
+#define PPC_BREAKPOINT_TRIGGER_READ 0x00000002
+#define PPC_BREAKPOINT_TRIGGER_WRITE 0x00000004
+#define PPC_BREAKPOINT_TRIGGER_RW \
+ (PPC_BREAKPOINT_TRIGGER_READ | PPC_BREAKPOINT_TRIGGER_WRITE)
+
+/*
+ * Address Mode
+ */
+#define PPC_BREAKPOINT_MODE_EXACT 0x00000000
+#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x00000001
+#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x00000002
+#define PPC_BREAKPOINT_MODE_MASK 0x00000003
+
+/*
+ * Condition Mode
+ */
+#define PPC_BREAKPOINT_CONDITION_MODE 0x00000003
+#define PPC_BREAKPOINT_CONDITION_NONE 0x00000000
+#define PPC_BREAKPOINT_CONDITION_AND 0x00000001
+#define PPC_BREAKPOINT_CONDITION_EXACT PPC_BREAKPOINT_CONDITION_AND
+#define PPC_BREAKPOINT_CONDITION_OR 0x00000002
+#define PPC_BREAKPOINT_CONDITION_AND_OR 0x00000003
+#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000
+#define PPC_BREAKPOINT_CONDITION_BE_SHIFT 16
+#define PPC_BREAKPOINT_CONDITION_BE(n) \
+ (1<<((n)+PPC_BREAKPOINT_CONDITION_BE_SHIFT))
+
#endif /* _ASM_POWERPC_PTRACE_H */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index ef14988..33ab496 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -839,6 +839,52 @@ void ptrace_disable(struct task_struct *child)
user_disable_single_step(child);
}
+static long ppc_set_hwdebug(struct task_struct *child,
+ struct ppc_hw_breakpoint *bp_info)
+{
+ /*
+ * We currently support one data breakpoint
+ */
+ if (((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0) ||
+ ((bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0) ||
+ (bp_info->trigger_type != PPC_BREAKPOINT_TRIGGER_WRITE) ||
+ (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) ||
+ (bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE))
+ return -EINVAL;
+
+ if (child->thread.dabr)
+ return -ENOSPC;
+
+ if ((unsigned long)bp_info->addr >= TASK_SIZE)
+ return -EIO;
+
+ child->thread.dabr = (unsigned long)bp_info->addr;
+#ifdef CONFIG_BOOKE
+ child->thread.dbcr0 = DBCR0_IDM;
+ if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
+ child->thread.dbcr0 |= DBSR_DAC1R;
+ if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
+ child->thread.dbcr0 |= DBSR_DAC1W;
+ child->thread.regs->msr |= MSR_DE;
+#endif
+ return 1;
+}
+
+static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
+{
+ if (data != 1)
+ return -EINVAL;
+ if (child->thread.dabr == 0)
+ return -ENOENT;
+
+ child->thread.dabr = 0;
+#ifdef CONFIG_BOOKE
+ child->thread.dbcr0 &= ~(DBSR_DAC1R | DBSR_DAC1W | DBCR0_IDM);
+ child->thread.regs->msr &= ~MSR_DE;
+#endif
+ return 0;
+}
+
/*
* Here are the old "legacy" powerpc specific getregs/setregs ptrace calls,
* we mark them as obsolete now, they will be removed in a future version
@@ -932,6 +978,50 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
}
+ case PPC_PTRACE_GETHWDBGINFO: {
+ struct ppc_debug_info dbginfo;
+
+ dbginfo.version = 1;
+ dbginfo.num_instruction_bps = 0;
+ dbginfo.num_data_bps = 1;
+ dbginfo.num_condition_regs = 0;
+#ifdef CONFIG_PPC64
+ dbginfo.data_bp_alignment = 8;
+#else
+ dbginfo.data_bp_alignment = 4;
+#endif
+ dbginfo.sizeof_condition = 0;
+ dbginfo.features = 0;
+
+ if (!access_ok(VERIFY_WRITE, data,
+ sizeof(struct ppc_debug_info)))
+ return -EFAULT;
+ ret = __copy_to_user((struct ppc_debug_info __user *)data,
+ &dbginfo, sizeof(struct ppc_debug_info)) ?
+ -EFAULT : 0;
+ break;
+ }
+
+ case PPC_PTRACE_SETHWDEBUG: {
+ struct ppc_hw_breakpoint bp_info;
+
+ if (!access_ok(VERIFY_READ, data,
+ sizeof(struct ppc_hw_breakpoint)))
+ return -EFAULT;
+ ret = __copy_from_user(&bp_info,
+ (struct ppc_hw_breakpoint __user *)data,
+ sizeof(struct ppc_hw_breakpoint)) ?
+ -EFAULT : 0;
+ if (!ret)
+ ret = ppc_set_hwdebug(child, &bp_info);
+ break;
+ }
+
+ case PPC_PTRACE_DELHWDEBUG: {
+ ret = ppc_del_hwdebug(child, addr, data);
+ break;
+ }
+
case PTRACE_GET_DEBUGREG: {
ret = -EINVAL;
/* We only support one DABR and no IABRS at the moment */
--
Dave Kleikamp
IBM Linux Technology Center
^ 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