* Re: Kexec support for FSL-BookE, take two
From: Sebastian Andrzej Siewior @ 2010-01-16 12:52 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7421001160435q83f5837rb931f8a16766ce91@mail.gmail.com>
* wilbur.chan | 2010-01-16 20:35:50 [+0800]:
>Is it possible to avoid setting up the 1:1 mapping but to convert
>physical address into virt before relocate , like mips do?
No.
>2010/1/16 Kumar Gala <galak@kernel.crashing.org>:
>
>>
>> What do you think we need for SMP support? I'm happy to test out on SMP HW (8572)
>>
>
>I'm happy to test it too :D
I have a 8572 myself but it is not working reliably right now. I will
try to merge the userland pieces and then I will probably look at SMP.
Sebastian
^ permalink raw reply
* DTS file reference for FSL UPM NAND for MPC832x
From: nanda @ 2010-01-16 17:02 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 239 bytes --]
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)
Thanks in advance.
Regards,
Nanda
[-- Attachment #2: Type: text/html, Size: 673 bytes --]
^ permalink raw reply
* 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
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