MPC85xx erratum I2C1 - I2C controller is unable to generate clocks when SDA is low coming out of reset
We've had some trouble with I2C not working after a soft reboot,
which we think is due to the the erratum I2C1 which is present in
at least the mpc8540 and the mpc8560. Since there is no good workaround,
the only choice seems to be to avoid resetting the CPU while the I2C bus is
busy.
The problem seems to be that the i2c-mpc driver leaves I2C in a busy state
when
it receives a signal (e.g. upon shutdown).
The code below is not meant as a patch, just me thinking aloud.
Thoughts?
/Fredrik Arnerup
fredrik.arne...@edgeware.tv
Index: drivers/i2c/busses/i2c-mpc.c
===
--- drivers/i2c/busses/i2c-mpc.c(revision 6933)
+++ drivers/i2c/busses/i2c-mpc.c(working copy)
@@ -262,12 +262,14 @@
/* Allow bus up to 1s to become not busy */
while (readb(i2c-base + MPC_I2C_SR) CSR_MBB) {
if (signal_pending(current)) {
- pr_debug(I2C: Interrupted\n);
- writeccr(i2c, 0);
+ printk(KERN_WARNING I2C: Interrupted\n);
+ if (readb(i2c-base + MPC_I2C_SR) ==
+ (CSR_MCF | CSR_MBB | CSR_RXAK))
+ mpc_i2c_fixup(i2c);
return -EINTR;
}
if (time_after(jiffies, orig_jiffies + HZ)) {
- pr_debug(I2C: timeout\n);
+ printk(KERN_WARNING I2C: mpc_xfer() timeout\n);
if (readb(i2c-base + MPC_I2C_SR) ==
(CSR_MCF | CSR_MBB | CSR_RXAK))
mpc_i2c_fixup(i2c);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Recap: Kernel oops while duming user core.
-Original Message-
From: Scott Wood [mailto:scottw...@freescale.com]
Sent: Monday, April 06, 2009 8:27 PM
To: Fredrik Arnerup
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Recap: Kernel oops while duming user core.
On Mon, Apr 06, 2009 at 05:23:12PM +0200, Fredrik Arnerup wrote:
Was the kernel oops when dumping core ever resolved?
(http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051080.html,
quoted
below)
What was the cause? Is there a patch? A bug tracker ticket?
It was fixed here:
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051350.html
Using ELDK here, so still running 2.6.24 ...
Please consider upgrading.
-Scott
Thanks! Works with the ppc arch too.
/Fredrik
--- a/arch/ppc/mm/init.c
+++ b/arch/ppc/mm/init.c
@@ -483,7 +483,12 @@ void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address,
*/
_tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
- if (!PageReserved(page)
+ /* The _PAGE_USER test should really be _PAGE_EXEC, but
+* older glibc versions execute some code from no-exec
+* pages, which for now we are supporting. If exec-only
+* pages are ever implemented, this will have to change.
+*/
+ if (!PageReserved(page) (pte_val(pte) _PAGE_USER)
!test_bit(PG_arch_1, page-flags)) {
if (vma-vm_mm == current-active_mm) {
__flush_dcache_icache((void *) address);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Recap: Kernel oops while duming user core.
Hi, Was the kernel oops when dumping core ever resolved? (http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051080.html, quoted below) What was the cause? Is there a patch? A bug tracker ticket? Using ELDK here, so still running 2.6.24 ... Thanks, /Fredrik Arnerup Kernel oops while duming user core. Rune Torgersen runet at innovsys.com Fri Feb 1 00:45:33 EST 2008 Hi I get the following kernel core while a user program I have is dumping core. Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on a 8280) When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11 and dumps core. On 2.6.24, I ghet the kernel oops, and then the program hangs sround forever and is unkillable. Unable to handle kernel paging request for data at address 0x48024000 Faulting instruction address: 0xc000ef88 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT Innovative Systems ApMax Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) NIP: c000ef88 LR: c0012180 CTR: 0080 REGS: eebc9b70 TRAP: 0300 Tainted: P (2.6.24) MSR: 9032 EE,ME,IR,DR CR: 24004442 XER: DAR: 48024000, DSISR: 2000 TASK = eebac3c0[3131] 'armd' THREAD: eebc8000 GPR00: ee9b7d00 eebc9c20 eebac3c0 48024000 0080 399a4181 48024000 GPR08: 399a4181 ee9b7d00 c200 44004422 10100f38 ee82fc00 bfff GPR16: ef377060 0030 ee9b7d00 eebc9cdc 0011 eebc9cd8 eeb96480 GPR24: ee9b7d00 399a4181 48024000 eeb9a370 eeb9a370 399a4181 48024000 c2733480 NIP [c000ef88] __flush_dcache_icache+0x14/0x40 LR [c0012180] update_mmu_cache+0x74/0x114 Call Trace: [eebc9c20] [eebc8000] 0xeebc8000 (unreliable) [eebc9c40] [c005d060] handle_mm_fault+0x630/0xbc0 [eebc9c80] [c005d9e4] get_user_pages+0x3f4/0x4fc [eebc9cd0] [c00aa7c4] elf_core_dump+0x9a4/0xc5c [eebc9d60] [c00779e4] do_coredump+0x6e0/0x748 [eebc9e50] [c002a5b0] get_signal_to_deliver+0x40c/0x45c [eebc9e80] [c0008ce8] do_signal+0x50/0x294 [eebc9f40] [c000fb98] do_user_signal+0x74/0xc4 --- Exception: 300 at 0x10044efc LR = 0x10044ec0 Instruction dump: 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 6000 54630026 38800080 7c8903a6 7c661b78 7c00186c 38630020 4200fff8 7c0004ac ---[ end trace 97db37eaf213da3c ]--- note: armd[3131] exited with preempt_count 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
