Re: Change in PCI behaviour
On 11/21/2010 10:59 AM, Gary Thomas wrote: On 11/19/2010 02:46 PM, Benjamin Herrenschmidt wrote: On Fri, 2010-11-19 at 08:42 -0700, Gary Thomas wrote: In this case, note that PCI device :00:0c.0 is at 0xc000. This causes problems because it's a truly stupid device that does not work properly at PCI [relative] address 0x. It simply does not respond at that address. Pick anywhere else and it will work fine! Hrm, we used to have a trick avoid giving out the first meg of a bus to avoid that sort of thing, I suppose it got lost. The rest is related to the way you map your PCI I suppose in your dts. You can switch back to a 1:1 instead of 1:0 mapping I suppose. One way to achieve the above result would be to, in your platform code, reserve the mem region that corresponds to PCI 0...1M (c000...+1M) before the device resources are assigned/allocated. I though we had code to do that with the legacy regions somewhere... oh well, no code at hand to check right now. Thanks, I found a combo of regions in my DTS that fixed this. That went well and the system is now running, but it's not stable :-( It will crash randomly, generally leaving no trace of what went wrong. I've attached a BDI to it, but mostly all it can tell me is it's dead The one thing that seems to pop up is it looks like it's jumping into space (aka the wrong place) when doing rfi (this is a guess). I've seen things like the MSR ends up loaded with an address, or similar strangeness. Were there any system level changes during this period (I know it's some time ago) that might have introduced such an instability? It's tough to scan through the diffs and get a feeling for any little details like this. Any ideas or hints greatly appreciated, thanks I have a bit more information on this. I'm pretty sure that the failures are only happening in my SCSI (SATA actually) code. My board (8347ea) has a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28. In 2.6.32, it will run for a while (possibly quite a while), then timeout trying to do a large block write - typically 256 blocks. Once this timeout happens, the SIL controller is stuck and accesses to it will eventually cause the whole system to hang (as above). Was there any major change in how PCI or DMA was handled between 2.6.28 and 2.6.32? Given the ephemeral nature of these failures (multiple runs all eventually fail, but never the same twice), my only hope of fixing it will be to have some ideas what might have changed. Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Change in PCI behaviour
On Fri, Nov 19, 2010 at 08:42:46AM -0700, Gary Thomas wrote: In this case, note that PCI device :00:0c.0 is at 0xc000. This causes problems because it's a truly stupid device that does not work properly at PCI [relative] address 0x. It simply does not respond at that address. Pick anywhere else and it will work fine! Yes, but it was one upon a time in the PCI spec that setting the a base register to 0 should disable the corresponding decoder. I don't know whether this has changed (I actually never had the final PCI spec, only drafts). However I once had a device who actually did not disable base addresses set to zero and this was described as a bug in its (numerous) errata. This also caused a lot of mayhem since in some versions/configurations it used up to 64kB of PCI I/O space (especially fun on x86...). Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv4] Xilinx Virtex 4 FX Soft FPU support
This patch enables support for Xilinx Virtex 4 FX singe-float FPU. This patch enables support for Xilinx Virtex 4 FX singe-float FPU. Changelog v3-v4 -Added help for CONFIG_XILINX_SOFTFPU option -Made kernel math emulation dependent on !PPC_FPU. Changelog v2-v3: -Fixed whitespaces for SAVE_FPR/REST_FPR. -Changed description of MSR_AP bit. -Removed the stub for APU unavailable exception. Changelog v1-v2: -Added MSR_AP bit definition -Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to 'Platform support' and made it Virtex4-FX-only. -Changed SAVE_FPR/REST_FPR definition style. Caveats: - Hard-float binaries which rely on in-kernel math emulation will give wrong results since they expect 64-bit double-precision instead of 32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces. Signed-off-by: Sergey Temerkhanovtemerkha...@cifronik.ru diff -r df25ff2b70a4 arch/powerpc/Kconfig --- a/arch/powerpc/Kconfig Fri Aug 27 21:10:12 2010 +0400 +++ b/arch/powerpc/Kconfig Fri Sep 10 13:08:13 2010 +0400 @@ -293,7 +293,7 @@ config MATH_EMULATION bool Math emulation - depends on 4xx || 8xx || E200 || PPC_MPC832x || E500 + depends on (4xx || 8xx || E200 || PPC_MPC832x || E500) !PPC_FPU ---help--- Some PowerPC chips designed for embedded applications do not have a floating-point unit and therefore do not implement the diff -r df25ff2b70a4 arch/powerpc/include/asm/ppc_asm.h --- a/arch/powerpc/include/asm/ppc_asm.hFri Aug 27 21:10:12 2010 +0400 +++ b/arch/powerpc/include/asm/ppc_asm.hFri Sep 10 13:08:13 2010 +0400 @@ -85,13 +85,21 @@ #define REST_8GPRS(n, base)REST_4GPRS(n, base); REST_4GPRS(n+4, base) #define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base) -#define SAVE_FPR(n, base) stfdn,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) + +#ifdef CONFIG_XILINX_SOFTFPU +#define SAVE_FPR(n, base) stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) +#define REST_FPR(n, base) lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) +#else +#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) +#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) +#endif + #define SAVE_2FPRS(n, base)SAVE_FPR(n, base); SAVE_FPR(n+1, base) #define SAVE_4FPRS(n, base)SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base) #define SAVE_8FPRS(n, base)SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base) #define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base) #define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base) -#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) + #define REST_2FPRS(n, base)REST_FPR(n, base); REST_FPR(n+1, base) #define REST_4FPRS(n, base)REST_2FPRS(n, base); REST_2FPRS(n+2, base) #define REST_8FPRS(n, base)REST_4FPRS(n, base); REST_4FPRS(n+4, base) diff -r df25ff2b70a4 arch/powerpc/include/asm/reg.h --- a/arch/powerpc/include/asm/reg.hFri Aug 27 21:10:12 2010 +0400 +++ b/arch/powerpc/include/asm/reg.hFri Sep 10 13:08:13 2010 +0400 @@ -30,6 +30,7 @@ #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */ #define MSR_HV_LG 60 /* Hypervisor state */ #define MSR_VEC_LG 25 /* Enable AltiVec */ +#define MSR_AP_LG 25 /* Enable APU */ #define MSR_VSX_LG 23 /* Enable VSX */ #define MSR_POW_LG 18 /* Enable Power Management */ #define MSR_WE_LG 18 /* Wait State Enable */ @@ -71,6 +72,7 @@ #define MSR_HV 0 #endif +#define MSR_AP __MASK(MSR_AP_LG) /* Enable APU */ #define MSR_VEC__MASK(MSR_VEC_LG) /* Enable AltiVec */ #define MSR_VSX__MASK(MSR_VSX_LG) /* Enable VSX */ #define MSR_POW__MASK(MSR_POW_LG) /* Enable Power Management */ diff -r df25ff2b70a4 arch/powerpc/kernel/fpu.S --- a/arch/powerpc/kernel/fpu.S Fri Aug 27 21:10:12 2010 +0400 +++ b/arch/powerpc/kernel/fpu.S Fri Sep 10 13:08:13 2010 +0400 @@ -57,6 +57,9 @@ _GLOBAL(load_up_fpu) mfmsr r5 ori r5,r5,MSR_FP +#ifdef CONFIG_XILINX_SOFTFPU + orisr5,r5,msr...@h +#endif #ifdef CONFIG_VSX BEGIN_FTR_SECTION orisr5,r5,msr_...@h @@ -85,6 +88,9 @@ toreal(r5) PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) li r10,MSR_FP|MSR_FE0|MSR_FE1 +#ifdef CONFIG_XILINX_SOFTFPU + orisr10,r10,msr...@h +#endif andcr4,r4,r10 /* disable FP for previous task */ PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5) 1: @@ -94,6 +100,9 @@ mfspr r5,SPRN_SPRG_THREAD /* current task's THREAD (phys) */ lwz r4,THREAD_FPEXC_MODE(r5) ori r9,r9,MSR_FP/* enable FP for current */ +#ifdef CONFIG_XILINX_SOFTFPU +
Re: [git pull] Please pull powerpc.git merge branch
On Sun, Nov 21, 2010 at 6:05 PM, Michael Ellerman mich...@ellerman.id.au wrote: On Fri, 2010-11-19 at 17:02 +1100, Michael Neuling wrote: On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote: On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman mich...@ellerman.id.= au wrote: I vote for: =20 - Exception: 401 (Instruction Access) at f7937794 =20 Or: =20 =E2=98=9B Exception: 401 (Instruction Access) at f7937794 Let's get serious, it's _really_ like a phone call: =E2=98=8E Exception: 401 (Instruction Access) at f7937794 We need a dedicated NACK char! ␕! Surely it would be: ☣ josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] misc: at24: parse OF-data, too
Hi Wolfram, I seem to be mistaken. I retried compatible=linux,24c64 and it did all the right things. I was mistaken that request_module() only takes the driver name, at24 in this case, and not all device names in the table_ids. This pretty much makes my patch redundant. Thanks for helping me clear things out. Regards, Stijn On Sat, Nov 20, 2010 at 1:42 PM, Wolfram Sang w.s...@pengutronix.de wrote: Hi, As far as I could tell, using compatible = 24c64; didn't load the right module (module name is at24) and using at24 caused a device id mismatch because at24 is not a known device ID. I could be wrong here and if so, I'd very much like a source code hint as to why... Have you tried vendor, 24c64? All I can say is that it works for me. Plain at24 worked for years with pcm030.dts and pcm032.dts, so I don't know which issue you are facing. This patch is just about extending the support. My patch worked by changing drivers/of/of_i2c.c to allow a generic kind = statement that was filled in as i2c_board_info.type, to allow the module name and the device id to be different. This makes the at24 driver no longer rely on probing (which it claims is buggy anyway) and also benefits other drivers that support multiple devices, but where probing is difficult (e.g. lm90 driver). I'm in the process of getting employer approval to get these patches upstream. I hope you will get it approved, it is a lot easier to talk about code :) Best regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkznwjIACgkQD27XaX1/VRssnwCgg55UCwZFLcMI8kJI3mhCJQxL N7kAoJHpLn5BJpNjET+ngaQFrGxUBQm1 =tyTb -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Fri, 19 Nov 2010 16:44:18 +1100
Michael Ellerman mich...@ellerman.id.au wrote:
On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman
mich...@ellerman.id.au wrote:
I vote for:
- Exception: 401 (Instruction Access) at f7937794
Or:
☛ Exception: 401 (Instruction Access) at f7937794
Let's get serious, it's _really_ like a phone call:
☎ Exception: 401 (Instruction Access) at f7937794
Sparc got it right:
void die_if_kernel(char *str, struct pt_regs *regs)
{
static int die_counter;
int count = 0;
/* Amuse the user. */
printk(
\\|/ \\|/\n
\@'/ .. \...@\\n
/_| \\__/ |_\\\n
\\__U_/\n);
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Change in PCI behaviour
On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote: I have a bit more information on this. I'm pretty sure that the failures are only happening in my SCSI (SATA actually) code. My board (8347ea) has a PCI bus with a SIL SATA controller. This combo works perfectly in 2.6.28. In 2.6.32, it will run for a while (possibly quite a while), then timeout trying to do a large block write - typically 256 blocks. Once this timeout happens, the SIL controller is stuck and accesses to it will eventually cause the whole system to hang (as above). Was there any major change in how PCI or DMA was handled between 2.6.28 and 2.6.32? Given the ephemeral nature of these failures (multiple runs all eventually fail, but never the same twice), my only hope of fixing it will be to have some ideas what might have changed. Maybe the changes you did to the PCI outbound windows are now breaking DMA ? Make sure the outbound and inbound don't overlap for example and that all RAM is reachable for inbound. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] MPC5200: Eliminate duplicate include of of_device.h
Eliminate duplicate #include linux/of_device.h from sound/soc/fsl/mpc5200_dma.c Signed-off-by: Jesper Juhl j...@chaosbits.net --- mpc5200_dma.c |1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c index dce6b55..f92dca0 100644 --- a/sound/soc/fsl/mpc5200_dma.c +++ b/sound/soc/fsl/mpc5200_dma.c @@ -9,7 +9,6 @@ #include linux/module.h #include linux/of_device.h #include linux/slab.h -#include linux/of_device.h #include linux/of_platform.h #include sound/soc.h -- Jesper Juhl j...@chaosbits.nethttp://www.chaosbits.net/ Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc, time: printk time stamp init not correct
problem: I see sometimes on my mpc5200 based board such printk timing information: [0.00] NR_IRQS:512 nr_irqs:512 16 [0.00] MPC52xx PIC is up and running! [0.00] clocksource: timebase mult[79364d9] shift[22] registered [0.00] console [ttyPSC0] enabled [ 130.300633] pid_max: default: 32768 minimum: 301 [ 130.305647] Mount-cache hash table entries: 512 [ 130.315818] NET: Registered protocol family 16 reason: if the tbu not starts from 0 when linux boots, boot_tb maybe could not store the real 64 bit tbu value, because boot_tp is only a 32 bit unsigned long. solution: change boot_tb to unsigned long long Signed-off-by: Heiko Schocher h...@denx.de cc: Wolfgang Denk w...@denx.de --- arch/powerpc/kernel/time.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index fa91732..a66df7d 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -155,7 +155,7 @@ EXPORT_SYMBOL_GPL(rtc_lock); static u64 tb_to_ns_scale __read_mostly; static unsigned tb_to_ns_shift __read_mostly; -static unsigned long boot_tb __read_mostly; +static unsigned long long boot_tb __read_mostly; extern struct timezone sys_tz; static long timezone_offset; -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
