[PATCH 1/4] 8xx: Optimze TLB Miss handlers
This removes a couple of insn's from the TLB Miss handlers whithout changing functionality. --- arch/powerpc/kernel/head_8xx.S | 11 +++ 1 files changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 3ef743f..ecc4a02 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -343,17 +343,14 @@ InstructionTLBMiss: cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT bne-cr0, 2f - /* Clear PP lsb, 0x400 */ - rlwinm r10, r10, 0, 22, 20 - /* The Linux PTE won't go exactly into the MMU TLB. -* Software indicator bits 22 and 28 must be clear. +* Software indicator bits 21 and 28 must be clear. * Software indicator bits 24, 25, 26, and 27 must be * set. All other Linux PTE bits control the behavior * of the MMU. */ li r11, 0x00f0 - rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */ + rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */ DO_8xx_CPU6(0x2d80, r3) mtspr SPRN_MI_RPN, r10/* Update TLB entry */ @@ -444,9 +441,7 @@ DataStoreTLBMiss: /* Honour kernel RO, User NA */ /* 0x200 == Extended encoding, bit 22 */ - /* r11 = (r10 _PAGE_USER) 2 */ - rlwinm r11, r10, 32-2, 0x200 - or r10, r11, r10 + rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */ /* r11 = (r10 _PAGE_RW) 1 */ rlwinm r11, r10, 32-1, 0x200 or r10, r11, r10 -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] 8xx: Don't touch ACCESSED when no SWAP.
Only the swap function cares about the ACCESSED bit in the pte. Do not waste cycles updateting ACCESSED when swap is not compiled into the kernel. --- arch/powerpc/kernel/head_8xx.S |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 84ca1d9..6478a96 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -343,10 +343,11 @@ InstructionTLBMiss: mfspr r11, SPRN_MD_TWC/* and get the pte address */ lwz r10, 0(r11) /* Get the pte */ +#ifdef CONFIG_SWAP andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT bne-cr0, 2f - +#endif /* The Linux PTE won't go exactly into the MMU TLB. * Software indicator bits 21 and 28 must be clear. * Software indicator bits 24, 25, 26, and 27 must be @@ -439,10 +440,11 @@ DataStoreTLBMiss: * r11 = ((r10 PRESENT) ((r10 ACCESSED) 5)); * r10 = (r10 ~PRESENT) | r11; */ +#ifdef CONFIG_SWAP rlwinm r11, r10, 32-5, _PAGE_PRESENT and r11, r11, r10 rlwimi r10, r11, 0, _PAGE_PRESENT - +#endif /* Honour kernel RO, User NA */ /* 0x200 == Extended encoding, bit 22 */ rlwimi r10, r10, 32-2, 0x200 /* Copy USER to bit 22, 0x200 */ -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] 8xx: Use SPRG2 and DAR registers to stash r11 and cr.
This avoids storing these registers in memory. CPU6 errata will still use the old way. Remove some G2 leftover accesses from 2.4 --- arch/powerpc/kernel/head_8xx.S | 49 +-- 1 files changed, 36 insertions(+), 13 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 6478a96..1f1a04b 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -71,9 +71,6 @@ _ENTRY(_start); * in the first level table, but that would require many changes to the * Linux page directory/table functions that I don't want to do right now. * - * I used to use SPRG2 for a temporary register in the TLB handler, but it - * has since been put to other uses. I now use a hack to save a register - * and the CCR at memory location 0.Someday I'll fix this. * -- Dan */ .globl __start @@ -302,8 +299,13 @@ InstructionTLBMiss: DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 +#ifdef CONFIG_8xx_CPU6 stw r10, 0(r0) stw r11, 4(r0) +#else + mtspr SPRN_DAR, r10 + mtspr SPRN_SPRG2, r11 +#endif mfspr r10, SPRN_SRR0 /* Get effective address of fault */ #ifdef CONFIG_8xx_CPU15 addir11, r10, 0x1000 @@ -359,13 +361,19 @@ InstructionTLBMiss: DO_8xx_CPU6(0x2d80, r3) mtspr SPRN_MI_RPN, r10/* Update TLB entry */ - mfspr r10, SPRN_M_TW /* Restore registers */ + /* Restore registers */ +#ifndef CONFIG_8xx_CPU6 + mfspr r10, SPRN_DAR + mtcrr10 + mtspr SPRN_DAR, r11 /* Tag DAR */ + mfspr r11, SPRN_SPRG2 +#else lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif + mfspr r10, SPRN_M_TW rfi 2: mfspr r11, SPRN_SRR1 @@ -375,13 +383,20 @@ InstructionTLBMiss: rlwinm r11, r11, 0, 0x mtspr SPRN_SRR1, r11 - mfspr r10, SPRN_M_TW /* Restore registers */ + /* Restore registers */ +#ifndef CONFIG_8xx_CPU6 + mfspr r10, SPRN_DAR + mtcrr10 + li r11, 0x00f0 + mtspr SPRN_DAR, r11 /* Tag DAR */ + mfspr r11, SPRN_SPRG2 +#else lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif + mfspr r10, SPRN_M_TW b InstructionAccess . = 0x1200 @@ -392,8 +407,13 @@ DataStoreTLBMiss: DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 +#ifdef CONFIG_8xx_CPU6 stw r10, 0(r0) stw r11, 4(r0) +#else + mtspr SPRN_DAR, r10 + mtspr SPRN_SPRG2, r11 +#endif mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */ /* If we are faulting a kernel address, we have to use the @@ -461,18 +481,24 @@ DataStoreTLBMiss: * of the MMU. */ 2: li r11, 0x00f0 - mtspr SPRN_DAR,r11/* Tag DAR */ rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */ DO_8xx_CPU6(0x3d80, r3) mtspr SPRN_MD_RPN, r10/* Update TLB entry */ - mfspr r10, SPRN_M_TW /* Restore registers */ + /* Restore registers */ +#ifndef CONFIG_8xx_CPU6 + mfspr r10, SPRN_DAR + mtcrr10 + mtspr SPRN_DAR, r11 /* Tag DAR */ + mfspr r11, SPRN_SPRG2 +#else + mtspr SPRN_DAR, r11 /* Tag DAR */ lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) #endif + mfspr r10, SPRN_M_TW rfi /* This is an instruction TLB error on the MPC8xx. This could be due @@ -684,9 +710,6 @@ start_here: tophys(r4,r2) addir4,r4,THREAD/* init task's THREAD */ mtspr SPRN_SPRG_THREAD,r4 - li r3,0 - /* XXX What is that for ? SPRG2 appears otherwise unused on 8xx */ - mtspr SPRN_SPRG2,r3 /* 0 = r1 has kernel sp */ /* stack */ lis r1,init_thread_un...@ha -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] hvc_console: Fix a race between hvc_close and hvc_remove
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp-tty
unlock
lock
hp-tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty-ops will be NULL
NULL-...
This patch adds some tty krefs and also converts to using tty_vhangup()
before putting the tty kref.
Reported-by: Alan Cox a...@lxorguk.ukuu.org.uk
Signed-off-by: Amit Shah amit.s...@redhat.com
CC: Alan Cox a...@lxorguk.ukuu.org.uk
CC: linuxppc-...@ozlabs.org
CC: Rusty Russell ru...@rustcorp.com.au
---
I can't be sure if this is all that's needed. tty people, please take
a look!
drivers/char/hvc_console.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d8dac58..3983e32 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -106,6 +106,7 @@ static struct hvc_struct *hvc_get_by_index(int index)
spin_lock_irqsave(hp-lock, flags);
if (hp-index == index) {
kref_get(hp-kref);
+ tty_kref_get(hp-tty);
spin_unlock_irqrestore(hp-lock, flags);
spin_unlock(hvc_structs_lock);
return hp;
@@ -390,6 +391,7 @@ static void hvc_close(struct tty_struct *tty, struct file *
filp)
}
kref_put(hp-kref, destroy_hvc_struct);
+ tty_kref_put(tty);
}
static void hvc_hangup(struct tty_struct *tty)
@@ -806,6 +808,7 @@ int hvc_remove(struct hvc_struct *hp)
unsigned long flags;
struct tty_struct *tty;
+ tty_kref_get(hp-tty);
spin_lock_irqsave(hp-lock, flags);
tty = hp-tty;
@@ -830,7 +833,9 @@ int hvc_remove(struct hvc_struct *hp)
* cleaned up the hvc_struct.
*/
if (tty)
- tty_hangup(tty);
+ tty_vhangup(tty);
+
+ tty_kref_put(hp-tty);
return 0;
}
EXPORT_SYMBOL_GPL(hvc_remove);
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
Anton Vorontsov wrote: On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote: [...] nfs: server 192.168.0.1 not responding, still trying Further testing has shown that this isn't restricted to warm reboots, it happens from cold as well. In addition, the exact timing of the failure seems to vary, some boots have got further before failing. Unfortunately I don't have any 8641 boards near me, so I can't debug this myself. Though, I tested gianfar on MPC8568E-MDS with 2.6.33 kernel, and it seems to work just fine. I see you use SMP. Can you try to turn it off? If that will fix the issue, then it'll be a good data point. Meanwhile, I'll try SMP kernel on MPC8568 (UP), and let you know the results. Thanks I removed the second core from the dts file rather than truly disabling SMP in the kernel config. Doing this allowed the board to boot reliably. 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.we...@ge.com| M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
Anton Vorontsov wrote: On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote: [...] I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsov avoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Thanks for the bisect. I have a guess why tx hangs in SMP case. Could anyone try the patch down below? Yup, no problem. I'm afraid it doesn't resolve the problem for me. [...] ...which probably explains why you weren't seeing it on non-SMP. I'd imagine it would show up on any of the e500mc boards too. Yeah.. Pity, I don't have SMP boards anymore. I'll try to get one though. diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..3ff3bd0 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget) tx_queue = priv-tx_queue[rx_queue-qindex]; tx_cleaned += gfar_clean_tx_ring(tx_queue); + if (!tx_cleaned !tx_queue-num_txbdfree) + tx_cleaned += 1; /* don't complete napi */ rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue, budget_per_queue); rx_cleaned += rx_cleaned_per_queue; -- 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.we...@ge.com| M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] No otheros feature on new PS3 slim ?
On Fri, 2009-08-21 at 09:58 -0700, geoffrey.lev...@am.sony.com wrote: The feature of Install Other OS was removed from the new Slim PS3 model to focus on delivering games and other entertainment content. Please be assured that SCE is committed to continue the support for previously sold models that have the Install Other OS feature and that this feature will not be disabled in future firmware releases. Although it's disappointing that Sony have removed the feature from new models, It's good to have this public assurance from Sony that at least the feature won't be removed from older models which are already working. I suppose it shouldn't be too much of a surprise -- if people have bought PS3s specifically to use the advertised 'OtherOS' feature and Sony were to break that with a firmware update, then there may well be legal ramifications. But it's nice to have the promise in writing anyway. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix lwsync feature fixup vs. modules on 64-bit
Benjamin Herrenschmidt wrote: Anton's commit enabling the use of the lwsync fixup mechanism on 64-bit breaks modules. The lwsync fixup section uses .long instead of the FTR_ENTRY_OFFSET macro used by other fixups sections, and thus will generate 32-bit relocations that our module loader cannot resolve. This changes it to use the same type as other feature sections. Note however that we might want to consider using 32-bit for all the feature fixup offsets and add support for R_PPC_REL32 to module_64.c instead as that would reduce the size of the kernel image. I'll leave that as an exercise for the reader for now... Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/include/asm/feature-fixups.h |2 +- arch/powerpc/lib/feature-fixups.c |3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) Thanks for the patch Ben. I can boot -next on my power boxes with it. thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On Fri, Feb 26, 2010 at 12:06:15PM +, Martyn Welch wrote: Anton Vorontsov wrote: On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote: [...] I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsov avoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Thanks for the bisect. I have a guess why tx hangs in SMP case. Could anyone try the patch down below? Yup, no problem. I'm afraid it doesn't resolve the problem for me. Hm.. I found a p2020 board and I was able to reproduce the issue. The patch down below fixed it completely for me... hm. I'll look further, thanks! [...] ...which probably explains why you weren't seeing it on non-SMP. I'd imagine it would show up on any of the e500mc boards too. Yeah.. Pity, I don't have SMP boards anymore. I'll try to get one though. diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..3ff3bd0 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget) tx_queue = priv-tx_queue[rx_queue-qindex]; tx_cleaned += gfar_clean_tx_ring(tx_queue); + if (!tx_cleaned !tx_queue-num_txbdfree) + tx_cleaned += 1; /* don't complete napi */ rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue, budget_per_queue); rx_cleaned += rx_cleaned_per_queue; -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
Martyn Welch wrote: Paul Gortmaker wrote: On 10-02-26 09:35 AM, Anton Vorontsov wrote: On Fri, Feb 26, 2010 at 12:06:15PM +, Martyn Welch wrote: Anton Vorontsov wrote: On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote: [...] I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsovavoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Thanks for the bisect. I have a guess why tx hangs in SMP case. Could anyone try the patch down below? Yup, no problem. I'm afraid it doesn't resolve the problem for me. Hm.. I found a p2020 board and I was able to reproduce the issue. The patch down below fixed it completely for me... hm. Interesting. I just tested the patch on the sbc8641d, and it still has the issue with your patch applied. I'm using NFSroot just like Martyn was and it still appears bound up on that gianfar tx lock. I'll see if I can get a SysRq backtrace in case that will help you see how it manages to get there... I've got a p2020ds here as well, so I'll give NFSroot on that a try with your patch. Out of 10 boot attempts, 7 failed. 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.we...@ge.com| M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On Fri, Feb 26, 2010 at 03:34:07PM +, Martyn Welch wrote: [...] Out of 10 boot attempts, 7 failed. OK, I see why. With ip=on (dhcp boot) it's much harder to trigger it. With static ip config can I see the same. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On 10-02-26 09:35 AM, Anton Vorontsov wrote: On Fri, Feb 26, 2010 at 12:06:15PM +, Martyn Welch wrote: Anton Vorontsov wrote: On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote: [...] I was able to reproduce it on an 8641D and bisected it down to this: --- commit a3bc1f11e9b867a4f49505ecac486a33af248b2e Author: Anton Vorontsovavoront...@ru.mvista.com Date: Tue Nov 10 14:11:10 2009 + gianfar: Revive SKB recycling Thanks for the bisect. I have a guess why tx hangs in SMP case. Could anyone try the patch down below? Yup, no problem. I'm afraid it doesn't resolve the problem for me. Hm.. I found a p2020 board and I was able to reproduce the issue. The patch down below fixed it completely for me... hm. Interesting. I just tested the patch on the sbc8641d, and it still has the issue with your patch applied. I'm using NFSroot just like Martyn was and it still appears bound up on that gianfar tx lock. I'll see if I can get a SysRq backtrace in case that will help you see how it manages to get there... Paul. nfs: server not responding, still trying [repeated ~15 times, then...] INFO: task rc.sysinit:837 blocked for more than 120 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. rc.sysinitD 0fef73f4 0 837836 0x Call Trace: [dfb7d9b0] [c000a144] __switch_to+0x8c/0xf8 [dfb7d9d0] [c03443dc] schedule+0x380/0x954 [dfb7da50] [c0344a0c] io_schedule+0x5c/0x90 [dfb7da70] [c0074b0c] sync_page+0x4c/0x74 [dfb7da80] [c0344f44] __wait_on_bit_lock+0xb0/0x148 [dfb7dab0] [c0074a8c] __lock_page+0x94/0xa4 [dfb7dae0] [c0074d5c] find_lock_page+0x8c/0xa4 [dfb7db00] [c0075674] filemap_fault+0x1ec/0x4fc [dfb7db40] [c008d548] __do_fault+0x98/0x53c [dfb7dba0] [c0018478] do_page_fault+0x2d0/0x500 [dfb7dc50] [c00149d4] handle_page_fault+0xc/0x80 --- Exception: 301 at __clear_user+0x14/0x7c LR = load_elf_binary+0x670/0x1270 [dfb7dd10] [c00f6ca0] load_elf_binary+0x620/0x1270 (unreliable) [dfb7dd90] [c00b1f78] search_binary_handler+0x17c/0x394 [dfb7dde0] [c00f4f50] load_script+0x274/0x288 [dfb7de90] [c00b1f78] search_binary_handler+0x17c/0x394 [dfb7dee0] [c00b3580] do_execve+0x240/0x29c [dfb7df20] [c000a46c] sys_execve+0x68/0xa4 [dfb7df40] [c00145a4] ret_from_syscall+0x0/0x38 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On 10-02-26 11:10 AM, Anton Vorontsov wrote: On Fri, Feb 26, 2010 at 03:34:07PM +, Martyn Welch wrote: [...] Out of 10 boot attempts, 7 failed. OK, I see why. With ip=on (dhcp boot) it's much harder to trigger it. With static ip config can I see the same. I'd kind of expected to see us stuck in gianfar on that lock, but the SysRQ-T doesn't show us hung up anywhere in gianfar itself. [This was on a base 2.6.33, with just a small sysrq fix patch] Paul. -- SysRq : Changing Loglevel Loglevel set to 9 nfs: server not responding, still trying SysRq : Show State taskPC stack pid father init D 0ff1c380 0 1 0 0x Call Trace: [df841a30] [c0009fc4] __switch_to+0x8c/0xf8 [df841a50] [c0350160] schedule+0x354/0x92c [df841ae0] [c0331394] rpc_wait_bit_killable+0x2c/0x54 [df841af0] [c0350eb0] __wait_on_bit+0x9c/0x108 [df841b10] [c0350fc0] out_of_line_wait_on_bit+0xa4/0xb4 [df841b40] [c0331cf0] __rpc_execute+0x16c/0x398 [df841b90] [c0329abc] rpc_run_task+0x48/0x9c [df841ba0] [c0329c40] rpc_call_sync+0x54/0x88 [df841bd0] [c015e780] nfs_proc_lookup+0x94/0xe8 [df841c20] [c014eb60] nfs_lookup+0x12c/0x230 [df841d50] [c00b9680] do_lookup+0x118/0x288 [df841d80] [c00bb904] link_path_walk+0x194/0x1118 [df841df0] [c00bcb08] path_walk+0x8c/0x168 [df841e20] [c00bcd6c] do_path_lookup+0x74/0x7c [df841e40] [c00be148] do_filp_open+0x5d4/0xba4 [df841f10] [c00abe94] do_sys_open+0xac/0x190 [df841f40] [c001437c] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff1c380 LR = 0xfec6d98 kthreadd S 0 2 0 0x Call Trace: [df843e50] [c002e788] wake_up_new_task+0x128/0x16c (unreliable) [df843f10] [c0009fc4] __switch_to+0x8c/0xf8 [df843f30] [c0350160] schedule+0x354/0x92c [df843fc0] [c004d154] kthreadd+0x130/0x134 [df843ff0] [c00141a0] kernel_thread+0x4c/0x68 migration/0 S 0 3 2 0x Call Trace: [df847de0] [] 0x (unreliable) [df847ea0] [c0009fc4] __switch_to+0x8c/0xf8 [df847ec0] [c0350160] schedule+0x354/0x92c [df847f50] [c002d074] migration_thread+0x29c/0x448 [df847fb0] [c004d020] kthread+0x80/0x84 [df847ff0] [c00141a0] kernel_thread+0x4c/0x68 ksoftirqd/0 S 0 4 2 0x Call Trace: [df84be10] [0800] 0x800 (unreliable) [df84bed0] [c0009fc4] __switch_to+0x8c/0xf8 [df84bef0] [c0350160] schedule+0x354/0x92c [df84bf80] [c0038454] run_ksoftirqd+0x14c/0x1e0 [df84bfb0] [c004d020] kthread+0x80/0x84 [df84bff0] [c00141a0] kernel_thread+0x4c/0x68 watchdog/0S 0 5 2 0x Call Trace: [df84dee0] [c0009fc4] __switch_to+0x8c/0xf8 [df84df00] [c0350160] schedule+0x354/0x92c [df84df90] [c006b8e8] watchdog+0x48/0x88 [df84dfb0] [c004d020] kthread+0x80/0x84 [df84dff0] [c00141a0] kernel_thread+0x4c/0x68
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Tue, Feb 23, 2010 at 04:27:15PM +0530, K.Prasad wrote: On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote: On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote: On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote: [snipped] Also, do you think addr/len/type is enough to abstract out any ppc breakpoints? This looks enough to me to express range breakpoints and simple breakpoints. But what about value comparison? (And still, there may be other trickier implementations I don't know in ppc). The above implementation is for PPC64 architecture that supports only 'simple' breakpoints of fixed length (no range breakpoints, no value comparison). More on that below. Looks like I forgot the 'more on that below' part :-)here are some thoughts... Architectures like PPC Book-E have support for a variety of sophisticated debug features and our generic framework, in its present form, cannot easily port itself to these processors. In order to extend the framework for PPC Book-E, I intend the following to begin with: - Implement support for data breakpoints through DAC registers with all the 'bells and whistles'...support for instruction breakpoints through IAC can come in later (without precluding its use through ptrace). - Embed the flags/variables to store DVC, masked address mode, etc. in 'struct arch_hw_breakpoint', which will be populated by the user of register_breakpoint interface. Agreed. Apart from the above extensions to the framework, changes in the generic code would be required as described in an earlier LKML mail (ref: message-id: 20091127190705.gb18...@in.ibm.com)relevant contents pasted below: I think the register_ interfaces can become wrappers around functions that do the following: - arch_validate(): Validate request by invoking an arch-dependant routine. Proceed if returned valid. - arch-specific debugreg availability: Do something like if (arch_hw_breakpoint_availabile()) bp = perf_event_create_kernel_counter(); This is already what does register_hw_break(), it fails if a slot is not available: perf_event_create_kernel_counter - perf_bp_init() - reserve_bp_slot() Having a: if (arch_hw_breakpoint_availabile()) bp = perf_event_create_kernel_counter(); would be racy. perf_event_create_kernel_counter()---arch_install_hw_breakpoint(); This way, all book-keeping related work (no. of pinned/flexible/per-cpu) will be moved to arch-specific files (will be helpful for PPC Book-E implementation having two types of debug registers). Every new architecture that intends to port to the new hw-breakpoint implementation must define their arch_validate(), arch_hw_breakpoint_available() and an arch_install_hw_breakpoint(), while the hw-breakpoint code will be flexible enough to extend itself to each of these archs. Let me know what you think of the above. We certainly need the slot reservation in arch (a part of it at least). But we also need a kind of new interface for arch predefined attributes, instead of generic attributes. Probably we need a kind of perf_event_create_kernel_counter() that can accept either a perf_event_attr (for perf syscall or ftrace) and an arch structure that can be passed to the breakpoint API, so that we don't need the generic translation. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Does Linux 2.6.32 support NAND flash connect with MPC8247 through localbus with GPCM mode?
On Fri, Feb 26, 2010 at 10:08:09AM +0800, Peter Pan wrote: I'm recently porting Linux 2.6.32 to our custom board with MPC8247. We have a NAND flash connected using GPCM mode of local bus. But after I search through the Linux source, there is no compatible like fsl,gpcm-nand. And I can not find any driver that seems works for our scene. There isn't one. I was not under the impression that such a configuration was even possible (how do you control ALE/CLE, for example?). There is a NAND driver that uses UPM, though -- perhaps you could use that? How specifically is NAND connected to the SoC on your board? What about it suggests GPCM? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] No otheros feature on new PS3 slim ?
Hi All, On 02/26/2010 04:30 AM, David Woodhouse wrote: On Fri, 2009-08-21 at 09:58 -0700, geoffrey.lev...@am.sony.com wrote: The feature of Install Other OS was removed from the new Slim PS3 model to focus on delivering games and other entertainment content. Please be assured that SCE is committed to continue the support for previously sold models that have the Install Other OS feature and that this feature will not be disabled in future firmware releases. Although it's disappointing that Sony have removed the feature from new models, It's good to have this public assurance from Sony that at least the feature won't be removed from older models which are already working. Please understand that in my position as PS3-Linux maintainer I can really only provide users with technical support for Linux and the LV1 hcall interface. The text above was provided to me by SCE management. If you have any questions regarding it or any other feature of the PS3 please contact the Playstation Customer Support in your country. Using Playstation Customer Support will insure your inquiry is processed through the correct channels within SCE. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
chips seems to cause a short lived IRQ storm (/proc/interrupts
typically shows somewhere between 300 and 1500 events). Unfortunately
this renders SysRQ over the serial console completely inoperable.
Testing with obvious things like ACKing the event doesn't seem to
change anything vs. a completely dumb approach of just ignoring
it and waiting for it to stop, so that is what is implemented here.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
This is a refresh of a patch I'd done earlier -- I've tried to make
the bug support as generic as possible to minimize having board
specific ifdef crap in 8250.c -- any suggestions on how to further
improve it are welcome.
drivers/serial/8250.c |6 ++
drivers/serial/8250.h | 20
drivers/serial/Kconfig | 14 ++
include/linux/serial_reg.h |2 ++
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index e9b15c3..850b0e9 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct
uart_8250_port *up)
status = serial_inp(up, UART_LSR);
+ if ((up-bugs UART_BUG_PPC) (status == UART_LSR_RFE_ERROR_BITS)) {
+ spin_unlock_irqrestore(up-port.lock, flags);
+ return;
+ }
+
DEBUG_INTR(status = %x..., status);
if (status (UART_LSR_DR | UART_LSR_BI))
@@ -1948,6 +1953,7 @@ static int serial8250_startup(struct uart_port *port)
up-capabilities = uart_config[up-port.type].flags;
up-mcr = 0;
+ up-bugs |= UART_KNOWN_BUGS;
if (up-port.iotype != up-cur_iotype)
set_io_from_upio(port);
diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h
index 6e19ea3..2074ce1 100644
--- a/drivers/serial/8250.h
+++ b/drivers/serial/8250.h
@@ -49,6 +49,7 @@ struct serial8250_config {
#define UART_BUG_TXEN (1 1)/* UART has buggy TX IIR status */
#define UART_BUG_NOMSR(1 2)/* UART has buggy MSR status
bits (Au1x00) */
#define UART_BUG_THRE (1 3)/* UART has buggy THRE reassertion */
+#define UART_BUG_PPC (1 4)/* UART has buggy PPC break IRQ storm */
#define PROBE_RSA (1 0)
#define PROBE_ANY (~0)
@@ -78,3 +79,22 @@ struct serial8250_config {
#else
#define ALPHA_KLUDGE_MCR 0
#endif
+
+/*
+ * The following UART bugs are currently dynamically detected and not
+ * required to be contingent on any particular compile time options.
+ */
+#define HAS_BUG_QUOT 0 /* assign UART_BUG_QUOT to enable */
+#define HAS_BUG_TXEN 0 /* assign UART_BUG_TXEN to enable */
+#define HAS_BUG_NOMSR0 /* assign UART_BUG_NOMSR to enable */
+#define HAS_BUG_THRE 0 /* assign UART_BUG_THRE to enable */
+
+#ifdef CONFIG_SERIAL_8250_PPC_BUG
+#define HAS_BUG_PPC UART_BUG_PPC
+#else
+#define HAS_BUG_PPC 0
+#endif
+
+#define UART_KNOWN_BUGS (HAS_BUG_QUOT | HAS_BUG_TXEN | HAS_BUG_NOMSR | \
+ HAS_BUG_THRE | HAS_BUG_PPC)
+
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 9ff47db..e01a411 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -70,6 +70,20 @@ config SERIAL_8250_CONSOLE
If unsure, say N.
+config SERIAL_8250_PPC_BUG
+ bool Fix 8250/16550 to handle IRQ storm after receipt of a break
+ depends on SERIAL_8250 PPC32
+ ---help---
+ If you say Y here, addional checks will be added in the handling of
+ interrupts on the serial ports which will prevent ill effects of
+ an interrupt storm triggered by a break on the serial line. Without
+ this enabled, a Sysrq via the serial console can be unusable on
+ some systems.
+
+ This is commonly observed on PPC32 MPC83xx/85xx/86xx based boards.
+
+ If unsure, say N.
+
is there harm caused if we have SERIAL_8250_PPC_BUG set and dont need it?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
On Fri, Feb 26, 2010 at 09:29:40AM +0100, Joakim Tjernlund wrote: This removes a couple of insn's from the TLB Miss handlers whithout changing functionality. --- Did a quick test of the patchset, seems to work OK (without CONFIG_SWAP or CONFIG_MODULES). Didn't try with CONFIG_8xx_CPU6. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] 8xx: Optimze TLB Miss handlers
On Feb 26, 2010, at 2:29 AM, Joakim Tjernlund wrote: li r11, 0x00f0 - rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */ + rlwimi r10, r11, 0, 0x07f8 /* Set 24-27, clear 21-23,28 */ DO_8xx_CPU6(0x2d80, r3) mtspr SPRN_MI_RPN, r10/* Update TLB entry */ Cool, didn't know 'as' supported this notation. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
Hi David, On Mon, 22 Feb 2010 03:44:52 -0800 (PST) David Miller da...@davemloft.net wrote: From: Anatolij Gustschin ag...@denx.de Date: Mon, 22 Feb 2010 12:37:24 +0100 Could you please comment on this patch series. It's in the net-next-2.6 tree. If you need to make any more changes, they need to be relative to what went into my tree. I've pulled your net-next-2.6 tree again and I don't see them in net-next-2.6 tree. Could you please check it again. Thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/7] RapidIO: Add Port-Write handling for EM
Micha Nelissen wrote: Bounine, Alexandre wrote: Micha Nelissen wrote: Alexandre Bounine wrote: /** + * rio_em_set_ops- Sets Error Managment operations for a particular vendor switch + * @rdev: RIO device + * + * Searches the RIO EM ops table for known switch types. If the vid + * and did match a switch table entry, then set the em_init() and + * em_handle() ops to the table entry values. Shouldn't any RIO device be able to support error management, not just switches? Only if a device reports this capability by having Error Management Extended Features block. Ideally, we have to provide default handler for every such device (I am planning it for some future updates). It should be the same as for routing operations - if the standard feature exists, it has to be used unless something else takes over. Yes, therefore I thought that: or the EM_OPS are per driver, or they can be integrated in the switch hooks list. Or combination of both methods as I implemented it. I want to have it flexible enough to be adopted to further development of RapidIO ecosystem. For now I keep all port-write messages from end-points serviced by their individual drivers. One of reasons for this: the EM PW message format Maybe have a generic rio function that can be called by any driver that knows a particular port-write was due to error management causes? This function would read the standard defined EF block registers. Then the driver part can be quite small. I think this echoes what I mentioned above as default handler. + if (port-ops-pwenable) + port-ops-pwenable(port, enable); +} + Maybe this can be done by switch-init function? This is not per-switch function. This function enables mport to receive incoming PW messages. Per-switch PW enable is done in switch-init as for Tsi57x. Oops, I meant this comment for the em_init function call. + rio_mport_write_config_32(mport, destid, hopcount, + rdev-phys_efptr + + RIO_PORT_N_ACK_STS_CSR(portnum), + RIO_PORT_N_ACK_CLEAR); This doesn't work for the 568; but the 568 has no special handling? Tsi568 will not send EM PW message. Tsi568 PWs are disabled in its em_init(). Why? Because Tsi568 requires special handling which is not implemented (yet?). +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578, tsi57x_em_init, tsi57x_em_handler); Why not declare these along with the other ops? Because the EM extensions is a separate capability. It is not guaranteed to be in every switch. They might initialize them with NULL to indicate they don't support it? My preference is to keep unrelated capabilities separately. Otherwise, these long ops lists may become unmanageable later when new extensions will be added into RIO spec. Cheers, Alex. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
On 10-02-26 02:42 PM, Kumar Gala wrote:
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
[...]
+if ((up-bugs UART_BUG_PPC) (status == UART_LSR_RFE_ERROR_BITS)) {
+spin_unlock_irqrestore(up-port.lock, flags);
+return;
+}
+
[...]
is there harm caused if we have SERIAL_8250_PPC_BUG set and dont need it?
In theory, no -- strip away all the window dressing and we are
left with the above change. So, you'd have to have some UART
implementation that was setting those bits and still relying
on its interrupt event to be processed normally. But since
there are so many different 8250 implementations out there,
I was being cautious and taking the absolute safe approach.
P.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
On Fri, Feb 26, 2010 at 01:42:39PM -0600, Kumar Gala wrote:
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
chips seems to cause a short lived IRQ storm (/proc/interrupts
typically shows somewhere between 300 and 1500 events). Unfortunately
this renders SysRQ over the serial console completely inoperable.
Testing with obvious things like ACKing the event doesn't seem to
change anything vs. a completely dumb approach of just ignoring
it and waiting for it to stop, so that is what is implemented here.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
This is a refresh of a patch I'd done earlier -- I've tried to make
the bug support as generic as possible to minimize having board
specific ifdef crap in 8250.c -- any suggestions on how to further
improve it are welcome.
drivers/serial/8250.c |6 ++
drivers/serial/8250.h | 20
drivers/serial/Kconfig | 14 ++
include/linux/serial_reg.h |2 ++
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index e9b15c3..850b0e9 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct
uart_8250_port *up)
status = serial_inp(up, UART_LSR);
+ if ((up-bugs UART_BUG_PPC) (status == UART_LSR_RFE_ERROR_BITS)) {
+ spin_unlock_irqrestore(up-port.lock, flags);
+ return;
+ }
Will LSR always be 0xf1 when this problem hits? At least the transmit bits
shouldn't be relevant.
This has been listed as an erratum in some of the newer chips (e.g.
mpc8568).
The suggested as workaround is to, upon seeing a break condition:
- read RBR
- delay at least one character period
- read RBR again
If I'm interpreting this correctly, it could be implemented by doing the
normal break handling on the first interrupt, plus setting a flag so that the
next interrupt simply reads RBR, clears the flag, and returns, without ever
reading LSR.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
chips seems to cause a short lived IRQ storm (/proc/interrupts
typically shows somewhere between 300 and 1500 events). Unfortunately
this renders SysRQ over the serial console completely inoperable.
Testing with obvious things like ACKing the event doesn't seem to
change anything vs. a completely dumb approach of just ignoring
it and waiting for it to stop, so that is what is implemented here.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
This is a refresh of a patch I'd done earlier -- I've tried to make
the bug support as generic as possible to minimize having board
specific ifdef crap in 8250.c -- any suggestions on how to further
improve it are welcome.
drivers/serial/8250.c |6 ++
drivers/serial/8250.h | 20
drivers/serial/Kconfig | 14 ++
include/linux/serial_reg.h |2 ++
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index e9b15c3..850b0e9 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -1531,6 +1531,11 @@ static void serial8250_handle_port(struct uart_8250_port
*up)
status = serial_inp(up, UART_LSR);
+ if ((up-bugs UART_BUG_PPC) (status == UART_LSR_RFE_ERROR_BITS)) {
+ spin_unlock_irqrestore(up-port.lock, flags);
+ return;
+ }
+
DEBUG_INTR(status = %x..., status);
if (status (UART_LSR_DR | UART_LSR_BI))
@@ -1948,6 +1953,7 @@ static int serial8250_startup(struct uart_port *port)
up-capabilities = uart_config[up-port.type].flags;
up-mcr = 0;
+ up-bugs |= UART_KNOWN_BUGS;
if (up-port.iotype != up-cur_iotype)
set_io_from_upio(port);
diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h
index 6e19ea3..2074ce1 100644
--- a/drivers/serial/8250.h
+++ b/drivers/serial/8250.h
@@ -49,6 +49,7 @@ struct serial8250_config {
#define UART_BUG_TXEN (1 1)/* UART has buggy TX IIR status */
#define UART_BUG_NOMSR (1 2)/* UART has buggy MSR status bits
(Au1x00) */
#define UART_BUG_THRE (1 3)/* UART has buggy THRE reassertion */
+#define UART_BUG_PPC (1 4)/* UART has buggy PPC break IRQ storm */
#define PROBE_RSA (1 0)
#define PROBE_ANY (~0)
@@ -78,3 +79,22 @@ struct serial8250_config {
#else
#define ALPHA_KLUDGE_MCR 0
#endif
+
+/*
+ * The following UART bugs are currently dynamically detected and not
+ * required to be contingent on any particular compile time options.
+ */
+#define HAS_BUG_QUOT 0 /* assign UART_BUG_QUOT to enable */
+#define HAS_BUG_TXEN 0 /* assign UART_BUG_TXEN to enable */
+#define HAS_BUG_NOMSR 0 /* assign UART_BUG_NOMSR to enable */
+#define HAS_BUG_THRE 0 /* assign UART_BUG_THRE to enable */
+
+#ifdef CONFIG_SERIAL_8250_PPC_BUG
+#define HAS_BUG_PPCUART_BUG_PPC
+#else
+#define HAS_BUG_PPC0
+#endif
+
+#define UART_KNOWN_BUGS (HAS_BUG_QUOT | HAS_BUG_TXEN | HAS_BUG_NOMSR | \
+ HAS_BUG_THRE | HAS_BUG_PPC)
+
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 9ff47db..e01a411 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -70,6 +70,20 @@ config SERIAL_8250_CONSOLE
If unsure, say N.
+config SERIAL_8250_PPC_BUG
+ bool Fix 8250/16550 to handle IRQ storm after receipt of a break
+ depends on SERIAL_8250 PPC32
+ ---help---
+ If you say Y here, addional checks will be added in the handling of
+ interrupts on the serial ports which will prevent ill effects of
+ an interrupt storm triggered by a break on the serial line. Without
+ this enabled, a Sysrq via the serial console can be unusable on
+ some systems.
+
+ This is commonly observed on PPC32 MPC83xx/85xx/86xx based boards.
+
+ If unsure, say N.
+
config FIX_EARLYCON_MEM
bool
depends on X86
diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h
index cf9327c..010174f 100644
--- a/include/linux/serial_reg.h
+++ b/include/linux/serial_reg.h
@@ -111,6 +111,7 @@
#define UART_MCR_DTR 0x01 /* DTR complement */
#define UART_LSR 5 /* In: Line Status Register */
+#define UART_LSR_RFE 0x80 /* Rx FIFO Error (BE, FE, or PE) */
#define UART_LSR_TEMT 0x40 /* Transmitter empty */
#define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
#define UART_LSR_BI0x10 /* Break interrupt indicator */
@@ -119,6 +120,7 @@
#define UART_LSR_OE0x02 /* Overrun error indicator */
#define UART_LSR_DR0x01 /* Receiver data ready */
#define UART_LSR_BRK_ERROR_BITS0x1E /* BI, FE, PE, OE bits */
+#define UART_LSR_RFE_ERROR_BITS0xF1 /* RFE, TEMT, THRE, BI, DR bits */
#define UART_MSR 6 /* In: Modem Status Register */
#define
Re: Gianfar driver failing on MPC8641D based board
On Fri, Feb 26, 2010 at 11:27:42AM -0500, Paul Gortmaker wrote: On 10-02-26 11:10 AM, Anton Vorontsov wrote: On Fri, Feb 26, 2010 at 03:34:07PM +, Martyn Welch wrote: [...] Out of 10 boot attempts, 7 failed. OK, I see why. With ip=on (dhcp boot) it's much harder to trigger it. With static ip config can I see the same. I'd kind of expected to see us stuck in gianfar on that lock, but the SysRQ-T doesn't show us hung up anywhere in gianfar itself. [This was on a base 2.6.33, with just a small sysrq fix patch] [df841a30] [c0009fc4] __switch_to+0x8c/0xf8 [df841a50] [c0350160] schedule+0x354/0x92c [df841ae0] [c0331394] rpc_wait_bit_killable+0x2c/0x54 [df841af0] [c0350eb0] __wait_on_bit+0x9c/0x108 [df841b10] [c0350fc0] out_of_line_wait_on_bit+0xa4/0xb4 [df841b40] [c0331cf0] __rpc_execute+0x16c/0x398 [df841b90] [c0329abc] rpc_run_task+0x48/0x9c [df841ba0] [c0329c40] rpc_call_sync+0x54/0x88 [df841bd0] [c015e780] nfs_proc_lookup+0x94/0xe8 [df841c20] [c014eb60] nfs_lookup+0x12c/0x230 [df841d50] [c00b9680] do_lookup+0x118/0x288 [df841d80] [c00bb904] link_path_walk+0x194/0x1118 [df841df0] [c00bcb08] path_walk+0x8c/0x168 [df841e20] [c00bcd6c] do_path_lookup+0x74/0x7c [df841e40] [c00be148] do_filp_open+0x5d4/0xba4 [df841f10] [c00abe94] do_sys_open+0xac/0x190 Yeah, I don't think this is gianfar-related. It must be something else triggered by the fact that gianfar no longer sends stuff. OK, I think I found what's happening in gianfar. Some background... start_xmit() prepares new skb for transmitting, generally it does three things: 1. sets up all BDs (marks them ready to send), except the first one. 2. stores skb into tx_queue-tx_skbuff so that clean_tx_ring() would cleanup it later. 3. sets up the first BD, i.e. marks it ready. Here is what clean_tx_ring() does: 1. reads skbs from tx_queue-tx_skbuff 2. Checks if the *last* BD is ready. If it's still ready [to send] then it it isn't transmitted, so clean_tx_ring() returns. Otherwise it actually cleanups BDs. All is OK. Now, if there is just one BD, code flow: - start_xmit(): stores skb into tx_skbuff. Note that the first BD (which is also the last one) isn't marked as ready, yet. - clean_tx_ring(): sees that skb is not null, *and* its lstatus says that it is NOT ready (like if BD was sent), so it cleans it up (bad!) - start_xmit(): marks BD as ready [to send], but it's too late. We can fix this simply by reordering lstatus/tx_skbuff writes. It works flawlessly on my p2020, please try it. Thanks! diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..cccb409 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) } /* setup the TxBD length and buffer pointer for the first BD */ - tx_queue-tx_skbuff[tx_queue-skb_curtx] = skb; txbdp_start-bufPtr = dma_map_single(priv-ofdev-dev, skb-data, skb_headlen(skb), DMA_TO_DEVICE); @@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) txbdp_start-lstatus = lstatus; + eieio(); /* force lstatus write before tx_skbuff */ + + tx_queue-tx_skbuff[tx_queue-skb_curtx] = skb; + /* Update the current skb pointer to the next entry we will use * (wrapping if necessary) */ tx_queue-skb_curtx = (tx_queue-skb_curtx + 1) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[net-next-2.6 PATCH v3 0/3] Support for MPC512x FEC
These patches attempt to provide support for the Freescale MPC512x FEC in the fs_enet driver. The first cleanup patch replaces printk by dev_xxx. The second and third attemt to support MPC5121 FEC in the FEC driver. Changes since previous version: - don't attempt to provide runtime selection of MPC5121 FEC support in the driver since it doesn't make sense. Select MPC5121 FEC support at compile time. - fix tx buffer alignment workaround patch to align only misaligned buffers. - address Eric's comments: ratelimit warning message and use 4-byte aligned skb-len for new properly aligned skb. The patches are based on net-next-2.6 and has been tested on the: - Freescale/STX MPC5121ADS board (board rev. 4) with a MPC5121e Rev. 2. - TQM860L and TQM855 boards. Anatolij Gustschin (3): fs_enet: use dev_xxx instead of printk fs_enet: Add support for MPC512x to fs_enet driver fs_enet: add FEC TX buffer alignment workaround for MPC5121 drivers/net/fs_enet/Kconfig| 10 +++- drivers/net/fs_enet/fs_enet-main.c | 93 ++- drivers/net/fs_enet/fs_enet.h | 49 ++- drivers/net/fs_enet/mac-fcc.c |5 +- drivers/net/fs_enet/mac-fec.c | 58 ++ drivers/net/fs_enet/mac-scc.c |9 ++-- drivers/net/fs_enet/mii-fec.c |4 +- 7 files changed, 169 insertions(+), 59 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[net-next-2.6 PATCH v3 1/3] fs_enet: use dev_xxx instead of printk
Signed-off-by: Anatolij Gustschin ag...@denx.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/fs_enet/fs_enet-main.c | 39 +--
drivers/net/fs_enet/mac-fcc.c |5 ++-
drivers/net/fs_enet/mac-fec.c | 12 --
drivers/net/fs_enet/mac-scc.c |9 +++
4 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index ec2f503..c34a7e0 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -108,9 +108,7 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int
budget)
* the last indicator should be set.
*/
if ((sc BD_ENET_RX_LAST) == 0)
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s rcv is not +last\n,
- dev-name);
+ dev_warn(fep-dev, rcv is not +last\n);
/*
* Check for errors.
@@ -178,9 +176,8 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int
budget)
received++;
netif_receive_skb(skb);
} else {
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s Memory squeeze, dropping
packet.\n,
- dev-name);
+ dev_warn(fep-dev,
+Memory squeeze, dropping packet.\n);
fep-stats.rx_dropped++;
skbn = skb;
}
@@ -242,9 +239,7 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
* the last indicator should be set.
*/
if ((sc BD_ENET_RX_LAST) == 0)
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s rcv is not +last\n,
- dev-name);
+ dev_warn(fep-dev, rcv is not +last\n);
/*
* Check for errors.
@@ -313,9 +308,8 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
received++;
netif_rx(skb);
} else {
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s Memory squeeze, dropping
packet.\n,
- dev-name);
+ dev_warn(fep-dev,
+Memory squeeze, dropping packet.\n);
fep-stats.rx_dropped++;
skbn = skb;
}
@@ -388,10 +382,10 @@ static void fs_enet_tx(struct net_device *dev)
} else
fep-stats.tx_packets++;
- if (sc BD_ENET_TX_READY)
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s HEY! Enet xmit interrupt and TX_READY.\n,
- dev-name);
+ if (sc BD_ENET_TX_READY) {
+ dev_warn(fep-dev,
+HEY! Enet xmit interrupt and TX_READY.\n);
+ }
/*
* Deferred means some collisions occurred during transmit,
@@ -511,9 +505,8 @@ void fs_init_bds(struct net_device *dev)
for (i = 0, bdp = fep-rx_bd_base; i fep-rx_ring; i++, bdp++) {
skb = dev_alloc_skb(ENET_RX_FRSIZE);
if (skb == NULL) {
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s Memory squeeze, unable to allocate skb\n,
- dev-name);
+ dev_warn(fep-dev,
+Memory squeeze, unable to allocate skb\n);
break;
}
skb_align(skb, ENET_RX_ALIGN);
@@ -610,8 +603,7 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
* Ooops. All transmit buffers are full. Bail out.
* This should not happen, since the tx queue should be stopped.
*/
- printk(KERN_WARNING DRV_MODULE_NAME
- : %s tx queue full!.\n, dev-name);
+ dev_warn(fep-dev, tx queue full!.\n);
return NETDEV_TX_BUSY;
}
@@ -788,8 +780,7 @@ static int fs_enet_open(struct net_device *dev)
r = request_irq(fep-interrupt, fs_enet_interrupt, IRQF_SHARED,
fs_enet-mac, dev);
if (r != 0) {
- printk(KERN_ERR DRV_MODULE_NAME
- : %s Could not allocate FS_ENET IRQ!, dev-name);
+ dev_err(fep-dev, Could not allocate FS_ENET IRQ!);
[net-next-2.6 PATCH v3 2/3] fs_enet: Add support for MPC512x to fs_enet driver
Extend the fs_enet driver to support MPC512x FEC.
Enable it with CONFIG_FS_ENET_MPC5121_FEC option.
Signed-off-by: John Rigby jcri...@gmail.com
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by: Anatolij Gustschin ag...@denx.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/fs_enet/Kconfig| 10 +--
drivers/net/fs_enet/fs_enet-main.c |7 +
drivers/net/fs_enet/fs_enet.h | 49 +++-
drivers/net/fs_enet/mac-fec.c | 46 ++---
drivers/net/fs_enet/mii-fec.c |4 +-
5 files changed, 95 insertions(+), 21 deletions(-)
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 562ea68..fc073b5 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -1,9 +1,13 @@
config FS_ENET
tristate Freescale Ethernet Driver
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || PPC_MPC512x
select MII
select PHYLIB
+config FS_ENET_MPC5121_FEC
+ def_bool y if (FS_ENET PPC_MPC512x)
+ select FS_ENET_HAS_FEC
+
config FS_ENET_HAS_SCC
bool Chip has an SCC usable for ethernet
depends on FS_ENET (CPM1 || CPM2)
@@ -16,13 +20,13 @@ config FS_ENET_HAS_FCC
config FS_ENET_HAS_FEC
bool Chip has an FEC usable for ethernet
- depends on FS_ENET CPM1
+ depends on FS_ENET (CPM1 || FS_ENET_MPC5121_FEC)
select FS_ENET_MDIO_FEC
default y
config FS_ENET_MDIO_FEC
tristate MDIO driver for FEC
- depends on FS_ENET CPM1
+ depends on FS_ENET (CPM1 || FS_ENET_MPC5121_FEC)
config FS_ENET_MDIO_FCC
tristate MDIO driver for FCC
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index c34a7e0..4297021 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1094,11 +1094,18 @@ static struct of_device_id fs_enet_match[] = {
},
#endif
#ifdef CONFIG_FS_ENET_HAS_FEC
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ {
+ .compatible = fsl,mpc5121-fec,
+ .data = (void *)fs_fec_ops,
+ },
+#else
{
.compatible = fsl,pq1-fec-enet,
.data = (void *)fs_fec_ops,
},
#endif
+#endif
{}
};
MODULE_DEVICE_TABLE(of, fs_enet_match);
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index ef01e09..1ece4b1 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -13,9 +13,56 @@
#ifdef CONFIG_CPM1
#include asm/cpm1.h
+#endif
+
+#if defined(CONFIG_FS_ENET_HAS_FEC)
+#include asm/cpm.h
+
+#if defined(CONFIG_FS_ENET_MPC5121_FEC)
+/* MPC5121 FEC has different register layout */
+struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl;/* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl;/* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd;/* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high;/* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high;/* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound;/* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start;/* Receive descriptor ring */
+ u32 fec_x_des_start;/* Transmit descriptor ring */
+ u32 fec_r_buff_size;/* Maximum receive buff size */
+ u32 fec_reserved12[26];
+ u32 fec_dma_control;/* DMA Endian and other ctrl */
+};
+#endif
struct fec_info {
- fec_t __iomem *fecp;
+ struct fec __iomem *fecp;
u32 mii_speed;
};
#endif
[net-next-2.6 PATCH v3 3/3] fs_enet: add FEC TX buffer alignment workaround for MPC5121
MPC5121 FEC requeries 4-byte alignmnent for TX data buffers.
This patch is a work around that copies misaligned tx packets
to an aligned skb before sending.
Signed-off-by: John Rigby jcri...@gmail.com
Signed-off-by: Piotr Ziecik ko...@semihalf.com
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by: Anatolij Gustschin ag...@denx.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Changes since v2:
- ratelimit warning message
- use skb-len + 4 as size for allocation of the new skb
with aligned buffer.
drivers/net/fs_enet/fs_enet-main.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 4297021..0770e2f 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -580,6 +580,40 @@ void fs_cleanup_bds(struct net_device *dev)
/**/
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+/*
+ * MPC5121 FEC requeries 4-byte alignment for TX data buffer!
+ */
+static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ struct sk_buff *new_skb;
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ /* Alloc new skb */
+ new_skb = dev_alloc_skb(skb-len + 4);
+ if (!new_skb) {
+ if (net_ratelimit()) {
+ dev_warn(fep-dev,
+Memory squeeze, dropping tx packet.\n);
+ }
+ return NULL;
+ }
+
+ /* Make sure new skb is properly aligned */
+ skb_align(new_skb, 4);
+
+ /* Copy data to new skb ... */
+ skb_copy_from_linear_data(skb, new_skb-data, skb-len);
+ skb_put(new_skb, skb-len);
+
+ /* ... and free an old one */
+ dev_kfree_skb_any(skb);
+
+ return new_skb;
+}
+#endif
+
static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
@@ -588,6 +622,19 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
u16 sc;
unsigned long flags;
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+ if (((unsigned long)skb-data) 0x3) {
+ skb = tx_skb_align_workaround(dev, skb);
+ if (!skb) {
+ /*
+* We have lost packet due to memory allocation error
+* in tx_skb_align_workaround(). Hopefully original
+* skb is still valid, so try transmit it later.
+*/
+ return NETDEV_TX_BUSY;
+ }
+ }
+#endif
spin_lock_irqsave(fep-tx_lock, flags);
/*
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver failing on MPC8641D based board
On 10-02-26 04:38 PM, Anton Vorontsov wrote: OK, I think I found what's happening in gianfar. Some background... start_xmit() prepares new skb for transmitting, generally it does three things: 1. sets up all BDs (marks them ready to send), except the first one. 2. stores skb into tx_queue-tx_skbuff so that clean_tx_ring() would cleanup it later. 3. sets up the first BD, i.e. marks it ready. Here is what clean_tx_ring() does: 1. reads skbs from tx_queue-tx_skbuff 2. Checks if the *last* BD is ready. If it's still ready [to send] then it it isn't transmitted, so clean_tx_ring() returns. Otherwise it actually cleanups BDs. All is OK. Now, if there is just one BD, code flow: - start_xmit(): stores skb into tx_skbuff. Note that the first BD (which is also the last one) isn't marked as ready, yet. - clean_tx_ring(): sees that skb is not null, *and* its lstatus says that it is NOT ready (like if BD was sent), so it cleans it up (bad!) - start_xmit(): marks BD as ready [to send], but it's too late. We can fix this simply by reordering lstatus/tx_skbuff writes. It works flawlessly on my p2020, please try it. I've skipped right to the test part (I'll think about the description more later) and it passed 5 out of 5 boot tests on NFSroot sbc8641d. Looks like you've got a solution. Paul. Thanks! diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..cccb409 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) } /* setup the TxBD length and buffer pointer for the first BD */ - tx_queue-tx_skbuff[tx_queue-skb_curtx] = skb; txbdp_start-bufPtr = dma_map_single(priv-ofdev-dev, skb-data, skb_headlen(skb), DMA_TO_DEVICE); @@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) txbdp_start-lstatus = lstatus; + eieio(); /* force lstatus write before tx_skbuff */ + + tx_queue-tx_skbuff[tx_queue-skb_curtx] = skb; + /* Update the current skb pointer to the next entry we will use * (wrapping if necessary) */ tx_queue-skb_curtx = (tx_queue-skb_curtx + 1) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Proposal to move PCI out of arch/powerpc and into drivers/of
Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Proposal to move PCI out of arch/powerpc and into drivers/of
On Fri, 26 Feb 2010 16:07:59 -0700 John Linn john.l...@xilinx.com wrote: Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? Dave and Ben have been talking about this for awhile; seems like a good excuse to do it. IIRC they had even thought about just dumping the code directly into drivers/pci so that API updates won't get missed... -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Proposal to move PCI out of arch/powerpc and into drivers/of
On Feb 26, 2010, at 5:07 PM, John Linn wrote: Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? Thanks, John John, Does MicroBlaze firmware produce full OF style PCI device tree's or do what we do on embedded systems and just have the root and leave the probing to the kernel? I haven't looked at the OF side of what we do in PPC in a while but I know we have some major differences between PPC32 PPC64 because of assumptions about what the firmware provides (or doesnt). As well as features on the PPC64 side to not re-probe PCI and build internal kernel data structures purely from the OF tree. I think moving the code and sharing it between everyone is a good thing, just point out some issues I know we are aware of. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Proposal to move PCI out of arch/powerpc and into drivers/of
On Fri, Feb 26, 2010 at 4:50 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Feb 26, 2010, at 5:07 PM, John Linn wrote: Hi all, We are in the process of putting PCI/PCIe into the microblaze architecture. In order to not duplicate/fork the PCI code in Powerpc, we're proposing to move the PCI code from arch/powerpc into drivers/of such that it would be common code for Powerpc and MicroBlaze. This would be the 1st part of a refactoring that would occur with the PCI code. Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* to drivers/of/*)? Thanks, John John, Does MicroBlaze firmware produce full OF style PCI device tree's or do what we do on embedded systems and just have the root and leave the probing to the kernel? Mostly like we do on ppc embedded. Let the kernel do the probing. I'm also going to want to be able to do the same think on ARM, so I also would like to make the code common. I haven't looked at the OF side of what we do in PPC in a while but I know we have some major differences between PPC32 PPC64 because of assumptions about what the firmware provides (or doesnt). I'm not too worried about this. I did some work on ppc32 to allow both probing and static PCI device definition on the same bus segment (although I didn't get all of it merged). There are difference between ppc32 ppc64, but it seemed to me that the divergence was more just a matter of convenience rather than any particular technical hurdles preventing a common approach. I think the 32 and 64 bit paths can be mostly merged. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Does Linux 2.6.32 support NAND flash connect with MPC8247 through localbus with GPCM mode?
2010/2/27 Scott Wood scottw...@freescale.com: On Fri, Feb 26, 2010 at 10:08:09AM +0800, Peter Pan wrote: There isn't one. I was not under the impression that such a configuration was even possible (how do you control ALE/CLE, for example?). There is a NAND driver that uses UPM, though -- perhaps you could use that? How specifically is NAND connected to the SoC on your board? What about it suggests GPCM? -Scott Our custom board is originally running VxWorks, and there is a full solution on NAND flash connected through GPCM. Because of this, our Linux can only try to adapt to this. I'm now writing GPCM NAND driver from the UPM NAND driver. Most function can be copied from our U-Boot port. Now the NAND flash can be recognized, but there is some bug in my driver, the kernel will oops for access 0x, I will continue writing the driver next monday. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hvc_console: Fix a race between hvc_close and hvc_remove
+ tty_kref_get(hp-tty); spin_lock_irqsave(hp-lock, flags); tty = hp-tty; @@ -830,7 +833,9 @@ int hvc_remove(struct hvc_struct *hp) * cleaned up the hvc_struct. */ if (tty) - tty_hangup(tty); + tty_vhangup(tty); + + tty_kref_put(hp-tty); You need to deref hp-tty, take the kref under the lock (and indeed do all assignments to it that way too), then tty_kref_put(tty), otherwise what stops hp-tty changing during the remove ? Take a look how tty_port_tty_get() and tty_port.c does it ... Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PCI NIC for powerpc system
Hi, I should apologize ahead of time for my lack of knowledge with PCI. I'm trying to better understand if I can run a standard off the shelf PCI NIC with a powerpc kernel as the PCI with device tree is not clear to me. I don't see many Ethernet drivers having OF support in them so maybe devices on the PCI bus are discovered by the kernel such that the drivers don't need to be OF aware. Any advice is appreciated. Thanks, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Hi Linus ! Here's your batch of powerpc stuff for 2.6.34. As you can see, it's reasonably small this time around. There's a pile of scalability improvements from Anton, a batch of raw_spinlock conversion from Thomas, and a few more bits and pieces. Cheers, Ben. The following changes since commit 6ebdc661b608671e9ca572af8bb42d58108cc008: Linus Torvalds (1): Merge branch 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next Amit Shah (1): hvc_console: Remove __devinit annotation from hvc_alloc Anatolij Gustschin (10): powerpc/mpc5121: avoid using arch_initcall for clock init powerpc/mpc5121: Add machine restart support rtc: Add MPC5121 Real time clock driver powerpc/mpc5121: create and register NFC device powerpc/mpc5121: update mpc5121ads DTS powerpc/mpc5121: Add default config for MPC5121 serial: mpc52xx_uart: re-enable mpc5121 PSC UART support powerpc: doc/dts-bindings: document mpc5121 psc uart dts-bindings powerpc/mpc5121: enable support for more PSC UARTs powerpc/mpc5121: correct DIU compatible property Anton Blanchard (25): powerpc: Replace per_cpu(, smp_processor_id()) with __get_cpu_var() powerpc: Mark some variables in the page fault path __read_mostly powerpc: Increase NR_IRQS Kconfig maximum to 32768 powerpc/pseries: Quieten cede latency printk powerpc: Reduce differences between pseries and ppc64 defconfigs powerpc: Add last sysfs file and dump of ftrace buffer to oops printout powerpc: Convert mmu context allocator from idr to ida powerpc: Reformat SD_NODE_INIT to match x86 powerpc: Make powerpc_firmware_features __read_mostly powerpc: Clear MSR_RI during RTAS calls powerpc: Only print clockevent settings once powerpc: Reduce footprint of irq_stat powerpc: Reduce footprint of xics_ipi_struct powerpc: Rework /proc/interrupts powerpc: Remove whitespace in irq chip name fields powerpc: Add timer, performance monitor and machine check counts to /proc/interrupts powerpc: Convert global BAD interrupt to per cpu spurious powerpc: Use lwarx hint in spinlocks powerpc: Use lwarx/ldarx hint in bit locks powerpc: Convert open coded native hashtable bit lock powerpc: Rename LWSYNC_ON_SMP to PPC_RELEASE_BARRIER, ISYNC_ON_SMP to PPC_ACQUIRE_BARRIER powerpc: Fix lwsync patching code on 64bit powerpc: Use lwsync for acquire barrier if CPU supports it powerpc: Pair loads and stores in copy_4k_page powerpc: Improve 64bit copy_tofrom_user Anton Vorontsov (1): powerpc/85xx: Add NOR, LEDs and PIB support for MPC8568E-MDS boards Benjamin Herrenschmidt (6): powerpc/pseries: Pass more accurate number of supported cores to firmware Merge commit 'origin/master' into next Merge commit 'jwb/next' into next Merge commit 'gcl/next' into next Merge commit 'origin/master' into next powerpc: Fix lwsync feature fixup vs. modules on 64-bit Breno Leitao (1): powerpc/eeh: Fix a bug when pci structure is null Corey Minyard (1): powerpc: Add coherent_dma_mask to mv64x60 devices Dave Kleikamp (4): powerpc/booke: Introduce new CONFIG options for advanced debug registers powerpc: Extended ptrace interface powerpc/booke: Add definitions for advanced debug registers powerpc/booke: Add support for advanced debug registers Ernst Schwab (1): powerpc/of: added documentation for spi chipselects Frans Pop (1): powerpc: Remove trailing space in messages Jean Delvare (2): macintosh/therm_adt746x: Fix sysfs attributes lifetime macintosh/hwmon/ams: Fix device removal sequence Joe Perches (2): powerpc/viodasd: Remove VIOD_KERN_level macros for printks arch/powerpc: Fix continuation line formats Malcolm Crossley (3): powerpc/86xx: Fix GE SBC310 XMC site support powerpc/86xx: Add MSI section to GE SBC610 DTS powerpc/86xx: Add MSI section to GE PPC9A DTS Martyn Welch (5): powerpc/86xx: Add MSI section to GE SBC310 DTS powerpc/86xx: Basic flash support for GE SBC610 powerpc/86xx: Switch on highmem support on GE SBC610 powerpc/86xx: Enable VME driver on the GE PPC9A powerpc/86xx: Enable VME driver on the GE SBC610 Michael Ellerman (1): lmb: Add lmb_free() Peter Tyser (1): powerpc/85xx: Fix SMP when cpu-release-addr is in lowmem Robert P. J. Day (1): powerpc: Simplify param.h by including asm-generic/param.h Rusty Russell (1): hvc_console: Make the ops pointer const. Sebastian Andrzej Siewior (1): powerpc/fsl-booke: replace a hardcoded constant Stefan Roese (6): powerpc/44x: Fix L2-cache support for 460GT powerpc/44x: Add MTD support (NOR FLASH) to Katmai dts powerpc/44x: Update Arches
Re: PCI NIC for powerpc system
On Fri, Feb 26, 2010 at 6:57 PM, John Linn john.l...@xilinx.com wrote: Hi, I should apologize ahead of time for my lack of knowledge with PCI. I'm trying to better understand if I can run a standard off the shelf PCI NIC with a powerpc kernel as the PCI with device tree is not clear to me. yes. I don't see many Ethernet drivers having OF support in them so maybe devices on the PCI bus are discovered by the kernel such that the drivers don't need to be OF aware. PCI can be probed, so PCI drivers don't need to be OF aware. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Gianfar driver failing on MPC8641D based board
-Original Message- From: Anton Vorontsov [mailto:avoront...@ru.mvista.com] Sent: Saturday, February 27, 2010 3:08 AM To: Paul Gortmaker Cc: Martyn Welch; net...@vger.kernel.org; linux-ker...@vger.kernel.org; linuxppc-dev list; Kumar Gopalpet-B05799; da...@davemloft.net Subject: Re: Gianfar driver failing on MPC8641D based board On Fri, Feb 26, 2010 at 11:27:42AM -0500, Paul Gortmaker wrote: On 10-02-26 11:10 AM, Anton Vorontsov wrote: On Fri, Feb 26, 2010 at 03:34:07PM +, Martyn Welch wrote: [...] Out of 10 boot attempts, 7 failed. OK, I see why. With ip=on (dhcp boot) it's much harder to trigger it. With static ip config can I see the same. I'd kind of expected to see us stuck in gianfar on that lock, but the SysRQ-T doesn't show us hung up anywhere in gianfar itself. [This was on a base 2.6.33, with just a small sysrq fix patch] [df841a30] [c0009fc4] __switch_to+0x8c/0xf8 [df841a50] [c0350160] schedule+0x354/0x92c [df841ae0] [c0331394] rpc_wait_bit_killable+0x2c/0x54 [df841af0] [c0350eb0] __wait_on_bit+0x9c/0x108 [df841b10] [c0350fc0] out_of_line_wait_on_bit+0xa4/0xb4 [df841b40] [c0331cf0] __rpc_execute+0x16c/0x398 [df841b90] [c0329abc] rpc_run_task+0x48/0x9c [df841ba0] [c0329c40] rpc_call_sync+0x54/0x88 [df841bd0] [c015e780] nfs_proc_lookup+0x94/0xe8 [df841c20] [c014eb60] nfs_lookup+0x12c/0x230 [df841d50] [c00b9680] do_lookup+0x118/0x288 [df841d80] [c00bb904] link_path_walk+0x194/0x1118 [df841df0] [c00bcb08] path_walk+0x8c/0x168 [df841e20] [c00bcd6c] do_path_lookup+0x74/0x7c [df841e40] [c00be148] do_filp_open+0x5d4/0xba4 [df841f10] [c00abe94] do_sys_open+0xac/0x190 Yeah, I don't think this is gianfar-related. It must be something else triggered by the fact that gianfar no longer sends stuff. OK, I think I found what's happening in gianfar. Some background... start_xmit() prepares new skb for transmitting, generally it does three things: 1. sets up all BDs (marks them ready to send), except the first one. 2. stores skb into tx_queue-tx_skbuff so that clean_tx_ring() would cleanup it later. 3. sets up the first BD, i.e. marks it ready. Here is what clean_tx_ring() does: 1. reads skbs from tx_queue-tx_skbuff 2. Checks if the *last* BD is ready. If it's still ready [to send] then it it isn't transmitted, so clean_tx_ring() returns. Otherwise it actually cleanups BDs. All is OK. Now, if there is just one BD, code flow: - start_xmit(): stores skb into tx_skbuff. Note that the first BD (which is also the last one) isn't marked as ready, yet. - clean_tx_ring(): sees that skb is not null, *and* its lstatus says that it is NOT ready (like if BD was sent), so it cleans it up (bad!) - start_xmit(): marks BD as ready [to send], but it's too late. We can fix this simply by reordering lstatus/tx_skbuff writes. It works flawlessly on my p2020, please try it. Anton, Understood, and thanks for the explanation. Am I correct in saying that this is due to the out-of-order execution capability on powerpc ? I have one more question, why don't we use use atomic_t for num_txbdfree and completely do away with spin_locks in gfar_clean_tx_ring() and gfar_start_xmit(). In an non-SMP, scenario I would feel there is absolutely no requirement of spin_locks and in case of SMP atomic operation would be much more safer on powerpc rather than spin_locks. What is your suggestion ? -- Thanks Sandeep Thanks! diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 8bd3c9f..cccb409 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) } /* setup the TxBD length and buffer pointer for the first BD */ - tx_queue-tx_skbuff[tx_queue-skb_curtx] = skb; txbdp_start-bufPtr = dma_map_single(priv-ofdev-dev, skb-data, skb_headlen(skb), DMA_TO_DEVICE); @@ -2053,6 +2052,10 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) txbdp_start-lstatus = lstatus; + eieio(); /* force lstatus write before tx_skbuff */ + + tx_queue-tx_skbuff[tx_queue-skb_curtx] = skb; + /* Update the current skb pointer to the next entry we will use * (wrapping if necessary) */ tx_queue-skb_curtx = (tx_queue-skb_curtx + 1) ___ Linuxppc-dev mailing list
