* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-07-01 7:50 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <AANLkTinYnoqfZAJWlYg633VbVyjWXhvFk2p406eP3o0c@mail.gmail.com>
Hi Scott,
> How do I find the address, reg, and range for nodes like localbus,
> soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
> relate to IMMR? So my localbus and soc should be as follows?
>
> =A0 =A0 =A0 =A0localbus@fa200100 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc885-localbus", "fsl=
,pq1-localbus",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "simple-bus";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xfa200100 0x40>;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00 0 0xfe000000 0x01000000 =
=A0 =A0// I'm not sure about this?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>;
> =A0 =A0 =A0 =A0};
I managed to proceed a little bit further.
Memory <- <0x0 0x8000000> (128MB)
ENET0: local-mac-address <- 00:09:9b:01:58:64
CPU clock-frequency <- 0x7270e00 (120MHz)
CPU timebase-frequency <- 0x393870 (4MHz)
CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07d1ccd0)
Allocating 0x186bdd bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x00591c30)...done 0x173b18 bytes
Linux/PowerPC load: root=3D/dev/ram
Finalizing device tree... flat tree at 0x59e300
The gdb showed deadbeef.
(gdb) target remote ppcbdi:2001
Remote debugging using ppcbdi:2001
0xdeadbeef in ?? ()
(gdb)
The kernel doesn't seem to start. What could go wrong here?
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: [PATCH 0/2] Faster MMU lookups for Book3s v3
From: Avi Kivity @ 2010-07-01 7:29 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1277903926-12786-1-git-send-email-agraf@suse.de>
On 06/30/2010 04:18 PM, Alexander Graf wrote:
> Book3s suffered from my really bad shadow MMU implementation so far. So
> I finally got around to implement a combined hash and list mechanism that
> allows for much faster lookup of mapped pages.
>
> To show that it really is faster, I tried to run simple process spawning
> code inside the guest with and without these patches:
>
> [without]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
>
> real 0m20.235s
> user 0m10.418s
> sys 0m9.766s
>
> [with]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
>
> real 0m14.659s
> user 0m8.967s
> sys 0m5.688s
>
> So as you can see, performance improved significantly.
>
> v2 -> v3:
>
> - use hlist
> - use global slab cache
>
>
Looks good.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: Oops while running fs_racer test on a POWER6 box against latest git
From: Michael Neuling @ 2010-07-01 5:04 UTC (permalink / raw)
To: divya
Cc: Latchesar Ionkov, npiggin, Jens Axboe, LKML, linuxppc-dev,
Ron Minnich, Christoph Hellwig
In-Reply-To: <4C2B28F3.7000006@linux.vnet.ibm.com>
> While running fs_racer test from LTP on a POWER6 box against latest git(2.6.3
5-rc3-git4 - commitid 984bc9601f64fd)
> came across the following warning followed by multiple oops.
>
> ------------[ cut here ]------------
>
> Badness at kernel/mutex-debug.c:64
> NIP: c0000000000be9e8 LR: c0000000000be9cc CTR: 0000000000000000
> REGS: c00000010be8f6f0 TRAP: 0700 Not tainted (2.6.35-rc3-git4-autotest)
> MSR: 8000000000029032<EE,ME,CE,IR,DR> CR: 24224422 XER: 00000012
> TASK = c00000010727cf00[8211] 'fs_racer_file_c' THREAD: c00000010be8bb50 CPU:
2
> GPR00: 0000000000000000 c00000010be8f970 c000000000d3d798 0000000000000001
> GPR04: c00000010be8fa70 c00000010be8c000 c00000010727d9f8 0000000000000000
> GPR08: c0000000043042f0 c0000000016534e8 000000000000017a c000000000c29a1c
> GPR12: 0000000028228424 c00000000f600500 c00000010be8fc40 0000000020000000
> GPR16: fffffffffffff000 c000000109c73000 c00000010be8fc30 0000000000010442
> GPR20: 0000000000000000 0000000000000000 00000000000001b6 c00000010dd12250
> GPR24: c00000000017c08c c00000010727cf00 c00000010dd12278 c00000010dd12210
> GPR28: 0000000000000001 c00000010be8c000 c000000000ca2008 c00000010be8fa70
> NIP [c0000000000be9e8] .mutex_remove_waiter+0xa4/0x130
> LR [c0000000000be9cc] .mutex_remove_waiter+0x88/0x130
> Call Trace:
> [c00000010be8f970] [c00000010be8fa00] 0xc00000010be8fa00 (unreliable)
> [c00000010be8fa00] [c00000000064a9f0] .mutex_lock_nested+0x384/0x430
> Instruction dump:
> e81f0010 e93d0000 7fa04800 41fe0028 482e96e5 60000000 2fa30000 419e0018
> e93e8008 80090000 2f800000 409e0008<0fe00000> e93e8000 80090000 2f800000
> Unable to handle kernel paging request for unknown fault
> Faulting instruction address: 0xc00000000008d0f4
> Oops: Kernel access of bad area, sig: 7 [#1]
> SMP NR_CPUS=1024 NUMA
> Unrecoverable FP Unavailable Exception 800 at c000000000648ed4
> pSeries
> last sysfs file: /sys/devices/system/cpu/cpu19/cache/index1/shared_cpu_map
> Modules linked in: ipv6 fuse loop dm_mod sr_mod cdrom ibmveth sg
> sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
> NIP: c00000000008d0f4 LR: c00000000008d0d0 CTR: 0000000000000000
> REGS: c00000010978f900 TRAP: 0600 Tainted: G W (2.6.35-rc3-git4-a
utotest)
> MSR: 8000000000009032
> Unrecoverable FP Unavailable Exception 800 at c000000000648ed4
> Unrecoverable FP Unavailable Exception 800 at c000000000648ed4
> Unrecoverable FP Unavailable Exception 800 at c000000000648ed4
> Unrecoverable FP Unavailable Exception 800 at c000000000648ed4
> Unrecoverable FP Unavailable Exception 800 at c000000000648ed4
> EE,ME,IR,DR> CR: 24022442 XER: 00000012
> DAR: c000000000648f54, DSISR: 0000000040010000
> TASK = c0000001096e4900[7353] 'fs_racer_file_s' THREAD: c00000010978c000 CPU:
10
> GPR00: 0000000000004000 c00000010978fb80 c000000000d3d798 0000000000000001
> GPR04: c00000000083539e c000000001610228 0000000000000000 c0000000054c6880
> GPR08: 00000000000006a5 c000000000648f54 0000000000000007 00000000049b0000
> GPR12: 0000000000000000 c00000000f601900 00000000ffffffff ffffffffffffffff
> GPR16: 000000004b7dc520 0000000000000000 0000000000000000 c00000010978fea0
> GPR20: 00000fffcca7e7a0 00000fffcca7e7a0 00000fffabf7dfd0 00000fffabf7dfd0
> GPR24: 0000000000000000 0000000001200011 c000000000e1c0a8 c000000000648ed4
> GPR28: 0000000000000000 c0000001096e4900 c000000000ca0458 c00000010725d400
> NIP [c00000000008d0f4] .copy_process+0x310/0xf40
> LR [c00000000008d0d0] .copy_process+0x2ec/0xf40
> Call Trace:
> [c00000010978fb80] [c00000000008d0d0] .copy_process+0x2ec/0xf40 (unreliable)
> [c00000010978fc80] [c00000000008deb4] .do_fork+0x190/0x3cc
> [c00000010978fdc0] [c000000000011ef4] .sys_clone+0x58/0x70
> [c00000010978fe30] [c0000000000087f0] .ppc_clone+0x8/0xc
> Instruction dump:
> 419e0010 7fe3fb78 480774cd 60000000 801f0014 e93f0008 7800b842 39290080
> 78004800 60000042 901f0014 38004000<7d6048a8> 7d6b0078 7d6049ad 40c2fff4
>
> Kernel version 2.6.34-rc3-git3 works fine.
Should this read 2.6.35-rc3-git3?
If so, there's only about 20 commits in:
5904b3b81d2516..984bc9601f64fd
The likely fs related candidates are from Christoph and Nick Piggin
(added to CC)
No commits relating to POWER6 or PPC.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Segher Boessenkool @ 2010-07-01 2:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20100701090546.0b7406ee.sfr@canb.auug.org.au>
>>> See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
>>
>> Yeah saw that right after I hit "send" :-) Either it's way more
>> complete than what I did, or way more complex because we still
>> don't link with libgcc :-P
>
> Actually, the 64bit versions of the routines are supplied by the
> linker,
> so the vmlinux links fine. But for modules, the final link is
> actually
> done by the kernel module loader, thus we need to provide those
> routines
> in this case. linking against libgcc would not have helped.
Right, so "more complete" it is :-)
I now checked that patch in detail, and it looks good to me. Thank
you for tackling this!
Segher
^ permalink raw reply
* Re: kernel init exception
From: wilbur.chan @ 2010-07-01 0:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, chen.yu10, David Gibson
In-Reply-To: <47F80BE0-6596-4A3D-B95F-72ABE2E0228C@kernel.crashing.org>
2010/7/1 Segher Boessenkool <segher@kernel.crashing.org>:
>> Maybe it was caused by floating exception.I found that,system received
>> a program check exception,the reason for it was REASON_ILLEGAL.
>>
>> I also use show_regs to print the NIP in exception,it seemed that
>> ,this exception was caused by 'vmhaddshs' instruction in user mode of
>> init process .
>>
>> Is vmhaddshs avaliable on e500mc? My cross compile tool is
>> gcc-4.1.2-glibc-2.5.0
>
> This isn't vmhaddshs (which is an AltiVec instruction), but something else
> that also uses primary opcode 4.
>
> It sounds like your toolchain isn't set up correctly for e500mc.
>
>
> Segher
>
>
I 've used cross_tool (powerpc_mc) that freescale provided, to
compile the kernel image, and
use an ordinary powerpc cross tool to compile busybox into cpio ramdisk.
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Stephen Rothwell @ 2010-06-30 23:05 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <4D7DE8D9-B226-4C6A-97FF-A63D272681C5@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Thu, 1 Jul 2010 00:50:36 +0200 Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> >> You probably also need something similar to http://git.infradead.org/
> >> users/segher/linux.git/commitdiff/
> >> 98194f54cc8e19ecd752bc10e2d19ef94074f502
> >> (note: only build-tested, not run-tested).
> >
> > See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
>
> Yeah saw that right after I hit "send" :-) Either it's way more
> complete than what I did, or way more complex because we still
> don't link with libgcc :-P
Actually, the 64bit versions of the routines are supplied by the linker,
so the vmlinux links fine. But for modules, the final link is actually
done by the kernel module loader, thus we need to provide those routines
in this case. linking against libgcc would not have helped.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Wolfgang Denk @ 2010-06-30 22:55 UTC (permalink / raw)
To: Josh Boyer
Cc: linux-ide, Rupjyoti Sarmah, linux-kernel, linuxppc-dev, sr,
Jeff Garzik
In-Reply-To: <20100630200325.GD7756@zod.rchland.ibm.com>
Dear Josh Boyer,
In message <20100630200325.GD7756@zod.rchland.ibm.com> you wrote:
>
> The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to
> require it at build time. Isn't that something that needs fixing in the
> driver?
Right. Next question is if this is really needed for this driver.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Copy from one, it's plagiarism; copy from two, it's research.
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Segher Boessenkool @ 2010-06-30 22:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20100701082756.7dced805.sfr@canb.auug.org.au>
>> You probably also need something similar to http://git.infradead.org/
>> users/segher/linux.git/commitdiff/
>> 98194f54cc8e19ecd752bc10e2d19ef94074f502
>> (note: only build-tested, not run-tested).
>
> See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
Yeah saw that right after I hit "send" :-) Either it's way more
complete than what I did, or way more complex because we still
don't link with libgcc :-P
Segher
^ permalink raw reply
* Re: kernel init exception
From: Segher Boessenkool @ 2010-06-30 22:31 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <AANLkTikyNZ5gCpuRPIZ-CJ6ClNZI_UDsmGF7xTzsv9vB@mail.gmail.com>
> Maybe it was caused by floating exception.I found that,system received
> a program check exception,the reason for it was REASON_ILLEGAL.
>
> I also use show_regs to print the NIP in exception,it seemed that
> ,this exception was caused by 'vmhaddshs' instruction in user mode of
> init process .
>
> Is vmhaddshs avaliable on e500mc? My cross compile tool is
> gcc-4.1.2-glibc-2.5.0
This isn't vmhaddshs (which is an AltiVec instruction), but something
else
that also uses primary opcode 4.
It sounds like your toolchain isn't set up correctly for e500mc.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Stephen Rothwell @ 2010-06-30 22:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <B6229BDC-F290-4A71-9F61-AAA5EC87F0F6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Hi Segher,
On Thu, 1 Jul 2010 00:16:40 +0200 Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> I've used an identical patch for almost a year now, so...
>
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Thanks.
> You probably also need something similar to http://git.infradead.org/
> users/segher/linux.git/commitdiff/
> 98194f54cc8e19ecd752bc10e2d19ef94074f502
> (note: only build-tested, not run-tested).
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
From: Segher Boessenkool @ 2010-06-30 22:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Jakub Jelinek, linuxppc-dev, Paul Mackerras
In-Reply-To: <1277878239.4200.285.camel@pasglop>
>>>> - stw%U0%X0 %L2,%1"
>>>> - : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
>>>> + stw%U1%X1 %L2,%1"
>>>> + : "=m<>" (*ptep), "=m<>" (*((unsigned char *)ptep+4))
>>>> : "r" (pte) : "memory");
>>>
>>> This still isn't correct -- the constraint says that a byte
>>> is written, but the insn changes a word. Probably should just
>>> be ptep[1] ?
>
> Oops, almost forgot about this. Are you guys shooting a new patch
> or do
> you want me to do it ?
It's really an independent fix. Just take Jakub's patch, I'll do one
on top of it?
Segher
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-30 22:25 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <4C2B6DF5.7030403@freescale.com>
Hi Scott,
> Does u-boot on your board put IMMR somewhere other than 0xff000000? =A0If=
so,
> you'll need to update the device tree to reflect this.
Thanks a lot. I think you got something here. Please bear with me.
This is the first dts file I'm creating. I have some question
regarding to dts first. BTW, My IMMR is at 0xfa200000.
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
relate to IMMR? So my localbus and soc should be as follows?
localbus@fa200100 {
compatible =3D "fsl,mpc885-localbus", "fsl,pq1-localbus",
"simple-bus";
#address-cells =3D <2>;
#size-cells =3D <1>;
reg =3D <0xfa200100 0x40>;
ranges =3D <
0 0 0xfe000000 0x01000000 // I'm not sure about =
this?
>;
};
soc@fa200000 {
compatible =3D "fsl,mpc875-immr", "fsl,pq1-soc", "simple-bu=
s";
#address-cells =3D <1>;
#size-cells =3D <1>;
ranges =3D <0 0xfa200000 0x00004000>;
// Temporary until code stops depending on it.
device_type =3D "soc";
// Temporary until get_immrbase() is fixed.
reg =3D <0xfa200000 0x4000>;
};
Thanks again,
-Shawn.
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Segher Boessenkool @ 2010-06-30 22:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20100630160422.3087bdf0.sfr@canb.auug.org.au>
> Just whitelist these extra compiler generated symbols.
> Fixes these errors:
[...]
I've used an identical patch for almost a year now, so...
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
You probably also need something similar to http://git.infradead.org/
users/segher/linux.git/commitdiff/
98194f54cc8e19ecd752bc10e2d19ef94074f502
(note: only build-tested, not run-tested).
Segher
> ---
> arch/powerpc/kernel/prom_init_check.sh | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/
> kernel/prom_init_check.sh
> index 1ac136b..9f82f49 100644
> --- a/arch/powerpc/kernel/prom_init_check.sh
> +++ b/arch/powerpc/kernel/prom_init_check.sh
> @@ -52,12 +52,18 @@ do
> if [ "${UNDEF:0:9}" = "_restgpr_" ]; then
> OK=1
> fi
> + if [ "${UNDEF:0:10}" = "_restgpr0_" ]; then
> + OK=1
> + fi
> if [ "${UNDEF:0:11}" = "_rest32gpr_" ]; then
> OK=1
> fi
> if [ "${UNDEF:0:9}" = "_savegpr_" ]; then
> OK=1
> fi
> + if [ "${UNDEF:0:10}" = "_savegpr0_" ]; then
> + OK=1
> + fi
> if [ "${UNDEF:0:11}" = "_save32gpr_" ]; then
> OK=1
> fi
> --
> 1.7.1
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-06-30 21:51 UTC (permalink / raw)
To: David Brownell
Cc: linuxppc-dev, linux-usb, Mark Miesfeld, gregkh, fushen.chen
In-Reply-To: <5569.83301.qm@web180304.mail.gq1.yahoo.com>
David,
AppliedMicro has PPC-405EX and PPC-460EX SOC using this controller.
There will be another arch/powerpc/boot/dts/canyonlands.dts for
PPC-460EX board.
Thanks,
Fushen
On Tue, 2010-06-29 at 15:41 -0700, David Brownell wrote:
> Good -- MUSB won't be the only one. ;)
>
> Could you mention a few Linux-enabled chips which
> include this controller?
>
>
> > arch/powerpc/boot/dts/kilauea.dts | 15 +
>
> Also, please provide a clean patch that only
> includes the driver, and split PPC hooks into
> a separate patch.
>
>
>
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Timur Tabi @ 2010-06-30 21:00 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev, linux-kernel, thomas.moll
In-Reply-To: <AANLkTine3pc2Ai2Woj81Y9fS_KgGs1sIMb2NMR6G74ww@mail.gmail.com>
On Wed, Jun 30, 2010 at 3:55 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> MCSR_MASK is not defined anywhere, so when I compile this code, I get this:
Never mind. I see that it's been fixed already, and that the patch
that removed MCSR_MASK was posted around the same time that this patch
was posted.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Timur Tabi @ 2010-06-30 20:55 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev, linux-kernel, thomas.moll
In-Reply-To: <20100308191005.GE4324@amak.tundra.com>
On Mon, Mar 8, 2010 at 2:10 PM, Alexandre Bounine <abounine@tundra.com> wro=
te:
>
> From: Alexandre Bounine <alexandre.bounine@idt.com>
>
> Add Machine Check exception handling into RapidIO port driver
> for Freescale SoCs (MPC85xx).
>
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> Tested-by: Thomas Moll <thomas.moll@sysgo.com>
...
> +static int fsl_rio_mcheck_exception(struct pt_regs *regs)
> +{
> + =A0 =A0 =A0 const struct exception_table_entry *entry =3D NULL;
> + =A0 =A0 =A0 unsigned long reason =3D (mfspr(SPRN_MCSR) & MCSR_MASK);
MCSR_MASK is not defined anywhere, so when I compile this code, I get this:
CC arch/powerpc/sysdev/fsl_rio.o
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared identifier
is reported only once
arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it appears in.)
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH V2] powerpc: Fix comments in fsl_booke_mmu code that mention BATS
From: Becky Bruce @ 2010-06-30 20:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1277926971-30712-1-git-send-email-beckyb@kernel.crashing.org>
There are no BATS on BookE - we have the TLBCAM instead. Also correct
the page size information to included extended sizes. We don't actually allow
a 4G page size to be used, so comment on that as well.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
Even lamer, I forgot that we don't actually allow use of a 4G page.
Update the comment to reflect this.
-Becky
arch/powerpc/mm/fsl_booke_mmu.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index cdc7526..4b66a1e 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -104,9 +104,10 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
}
/*
- * Set up one of the I/D BAT (block address translation) register pairs.
- * The parameters are not checked; in particular size must be a power
- * of 4 between 4k and 256M.
+ * Set up a variable-size TLB entry (tlbcam). The parameters are not checked;
+ * in particular size must be a power of 4 between 4k and 256M (or 1G, for cpus
+ * that support extended page sizes). Note that while some cpus support a
+ * page size of 4G, we don't allow its use here.
*/
static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned long size, unsigned long flags, unsigned int pid)
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-06-30 20:16 UTC (permalink / raw)
To: Stefan Roese
Cc: Wolfgang Denk, linux-usb, linuxppc-dev, Mark Miesfeld,
linuxppc-dev, fchen
In-Reply-To: <201006301127.21241.sr@denx.de>
Stefan,
The driver is based on Synopsys driver 2.60a.
We started to prepare open source submission based on our internal
version. We sync this version to linux-2.6-denx repository from time to
time. I'll sync the driver to the latest linux-2.6-denx as Wolfgang
pointed out, and re-submit patch to open source.
We modified the driver mostly to follow Linux kernel coding style.
Both USB host and device modes are tested.
Thanks,
Fushen
1.
On Wed, 2010-06-30 at 11:27 +0200, Stefan Roese wrote:
> Hi Fushen, Hi Mark,
>
> On Tuesday 29 June 2010 23:26:54 Fushen Chen wrote:
> > The DWC OTG driver module provides the initialization and cleanup
> > entry points for the DWC OTG USB driver.
> >
> > Signed-off-by: Fushen Chen <fchen@apm.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
>
> I tried to compare this driver with the version that's currently available in
> the linux-2.6-denx repository. But the differences are quite big. Could you
> please list the history of this DWC driver? Things like:
>
> - Which Synopsis version is it based upon?
> - What changes/enhancements/fixups where made from APM?
> - How was this driver tested (USB host and device mode)?
>
> As Wolfgang already pointed out, the driver in our git repository has
> undergone multiple changes/fixes. Did you take a look at them and try to
> integrate them?
>
> Thanks.
>
> Cheers,
> Stefan
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Josh Boyer @ 2010-06-30 20:03 UTC (permalink / raw)
To: Jeff Garzik
Cc: Wolfgang Denk, linux-ide, Rupjyoti Sarmah, linux-kernel,
linuxppc-dev, sr
In-Reply-To: <4C2B9831.9020801@pobox.com>
On Wed, Jun 30, 2010 at 03:17:05PM -0400, Jeff Garzik wrote:
> On 06/30/2010 02:47 PM, Wolfgang Denk wrote:
>> Dear Rupjyoti Sarmah,
>>
>> In message<3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>>>
>>> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
>>> download link.
>>> I created the patch on 6/24/2010 after doing a git pull.
>>
>> I don;t think that you used v2.6.35-rc3; using this version, I still
>> get this:
>>
>> drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
>> In file included from drivers/ata/sata_dwc_460ex.c:38:
>> drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
>> drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
>> drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
>> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read':
>> drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr'
>> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write':
>> drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr'
>> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr':
>> drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status'
>
> It looks like -your- build config is missing CONFIG_ATA_SFF or similar.
>
> If you actually look at include/linux/libata.h, you see that struct
> ata_port_operations most definitely has a member named sff_check_status,
> for example. Ditto ata_port and member ioaddr, etc.
The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to
require it at build time. Isn't that something that needs fixing in the
driver?
josh
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Fix comments that refer to BAT registers
From: Becky Bruce @ 2010-06-30 19:42 UTC (permalink / raw)
To: linuxppc-dev
There are no BATS on BookE - we have the TLBCAM instead. Also correct
the page size information to included extended (1G and 4G) sizes.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
Lame, I know, but this drives me batty every time I see it, and I've had
customers get confused because of it. I've finally gotten irritated enough
to send a patch.
-Becky
arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index cdc7526..681429d 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -104,9 +104,9 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
}
/*
- * Set up one of the I/D BAT (block address translation) register pairs.
- * The parameters are not checked; in particular size must be a power
- * of 4 between 4k and 256M.
+ * Set up a variable-size TLB entry (tlbcam). The parameters are not checked;
+ * in particular size must be a power of 4 between 4k and 256M (or 4G, for cpus
+ * that support extended page sizes).
*/
static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned long size, unsigned long flags, unsigned int pid)
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Jeff Garzik @ 2010-06-30 19:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-ide, sr, Rupjyoti Sarmah, linux-kernel, linuxppc-dev
In-Reply-To: <20100630184728.C02D014EBF9@gemini.denx.de>
On 06/30/2010 02:47 PM, Wolfgang Denk wrote:
> Dear Rupjyoti Sarmah,
>
> In message<3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>>
>> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
>> download link.
>> I created the patch on 6/24/2010 after doing a git pull.
>
> I don;t think that you used v2.6.35-rc3; using this version, I still
> get this:
>
> drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
> In file included from drivers/ata/sata_dwc_460ex.c:38:
> drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
> drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
> drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read':
> drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr'
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write':
> drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr'
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr':
> drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status'
It looks like -your- build config is missing CONFIG_ATA_SFF or similar.
If you actually look at include/linux/libata.h, you see that struct
ata_port_operations most definitely has a member named sff_check_status,
for example. Ditto ata_port and member ioaddr, etc.
Jeff
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Wolfgang Denk @ 2010-06-30 18:47 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com>
Dear Rupjyoti Sarmah,
In message <3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>
> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
> download link.
> I created the patch on 6/24/2010 after doing a git pull.
I don;t think that you used v2.6.35-rc3; using this version, I still
get this:
drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
In file included from drivers/ata/sata_dwc_460ex.c:38:
drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read':
drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write':
drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr':
drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_isr':
drivers/ata/sata_dwc_460ex.c:953: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c:957: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c:991: error: implicit declaration of function 'ata_sff_hsm_move'
drivers/ata/sata_dwc_460ex.c:1030: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1213: warning: 'struct ata_ioports' declared inside parameter list
drivers/ata/sata_dwc_460ex.c:1213: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_setup_port':
drivers/ata/sata_dwc_460ex.c:1215: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1216: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1218: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1219: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1221: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1223: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1224: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1225: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1227: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1228: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1229: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1231: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1232: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_port_start':
drivers/ata/sata_dwc_460ex.c:1273: error: 'struct ata_port' has no member named 'bmdma_prd'
drivers/ata/sata_dwc_460ex.c:1274: error: 'struct ata_port' has no member named 'bmdma_prd_dma'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag':
drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast
drivers/ata/sata_dwc_460ex.c:1369: error: implicit declaration of function 'ata_sff_exec_command'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue':
drivers/ata/sata_dwc_460ex.c:1512: error: 'struct ata_port_operations' has no member named 'sff_tf_load'
drivers/ata/sata_dwc_460ex.c:1516: error: implicit declaration of function 'ata_sff_qc_issue'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_handler':
drivers/ata/sata_dwc_460ex.c:1545: error: implicit declaration of function 'ata_sff_error_handler'
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1564: error: 'ata_sff_port_ops' undeclared here (not in a function)
drivers/ata/sata_dwc_460ex.c:1577: error: unknown field 'bmdma_setup' specified in initializer
drivers/ata/sata_dwc_460ex.c:1577: warning: initialization from incompatible pointer type
drivers/ata/sata_dwc_460ex.c:1578: error: unknown field 'bmdma_start' specified in initializer
drivers/ata/sata_dwc_460ex.c:1578: warning: initialization from incompatible pointer type
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_probe':
drivers/ata/sata_dwc_460ex.c:1638: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c:1639: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c:1641: error: 'struct ata_port' has no member named 'ioaddr'
make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1
make[1]: *** [drivers/ata] Error 2
make: *** [drivers] Error 2
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Often it is fatal to live too long. - Racine
^ permalink raw reply
* Re: [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163915.GC23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:15 +0400
> MPC8313ECE says:
>
> "If the controller receives a 1- or 2-byte frame (such as an illegal
> runt packet or a packet with RX_ER asserted) before GRS is asserted
> and does not receive any other frames, the controller may fail to set
> GRSC even when the receive logic is completely idle. Any subsequent
> receive frame that is larger than two bytes will reset the state so
> the graceful stop can complete. A MAC receiver (Rx) reset will also
> reset the state."
>
> This patch implements the proposed workaround:
>
> "If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
> register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
> the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
> If the register fields are not equal, wait for another timeout
> period and check again."
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163913.GB23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:13 +0400
> MPC8313ECE says:
>
> "For TOE=1 huge or jumbo frames, the data required to generate the
> checksum may exceed the 2500-byte threshold beyond which the controller
> constrains itself to one memory fetch every 256 eTSEC system clocks.
>
> This throttling threshold is supposed to trigger only when the
> controller has sufficient data to keep transmit active for the duration
> of the memory fetches. The state machine handling this threshold,
> however, fails to take large TOE frames into account. As a result,
> TOE=1 frames larger than 2500 bytes often see excess delays before start
> of transmission."
>
> This patch implements the workaround as suggested by the errata
> document, i.e.:
>
> "Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
> memory throttling.
> When using packets larger than 2700 bytes, it is recommended to turn TOE
> off."
>
> To be sure, we limit the TOE frames to 2500 bytes, and do software
> checksumming instead.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163912.GA23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:12 +0400
> MPC8313ECE says:
>
> "If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
> which are larger than MAXFRM, the controller truncates the frames to
> length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
> also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
> or MAXFRM-1, even though those frames are not truncated.
> No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
>
> There are two options to workaround the issue:
>
> "1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
> frames. Software can determine if a frame is larger than MAXFRM by
> reading RxBD[LG] or RxBD[Data Length].
>
> 2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
> normal-length frames are not marked as truncated. Software can examine
> RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
>
> This patch implements the first workaround option by setting HUGEFRAME
> bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ 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