| Submitter | Wu Zhangjin |
|---|---|
| Date | 2010-02-01 09:02:55 |
| Message ID | <1265015455-32553-1-git-send-email-wuzhangjin@gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/922/ |
| State | Accepted |
| Delegated to: | Ralf Baechle |
| Headers | show |
Comments
On Mon, Feb 1, 2010 at 3:10 AM, Wu Zhangjin <wuzhangjin@gmail.com> wrote: > > From: Wu Zhangjin <wuzhangjin@gmail.com> > > As reported by Maxime Bizon, the commit "MIPS: PowerTV: Fix support for > timer interrupts with > 64 external IRQs" have broken the r4k timer > since it didn't initialize the cp0_compare_irq_shift variable used in > c0_compare_int_pending() on the architectures whose cpu_has_mips_r2 is > false. > > This patch fixes it via initializing the cp0_compare_irq_shift as the > cp0_compare_irq used in the old c0_compare_int_pending(). > > Reported-by: Maxime Bizon <mbizon@freebox.fr> > Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com> When applied to 2.6.33-rc6, this patch fixes the problem on my RM7035C-based system. Tested-by: Shane McDonald <mcdonald.shane@gmail.com>
On Mon, Feb 01, 2010 at 09:03:10PM -0600, Shane McDonald wrote: > On Mon, Feb 1, 2010 at 3:10 AM, Wu Zhangjin <wuzhangjin@gmail.com> wrote: > > > > From: Wu Zhangjin <wuzhangjin@gmail.com> > > > > As reported by Maxime Bizon, the commit "MIPS: PowerTV: Fix support for > > timer interrupts with > 64 external IRQs" have broken the r4k timer > > since it didn't initialize the cp0_compare_irq_shift variable used in > > c0_compare_int_pending() on the architectures whose cpu_has_mips_r2 is > > false. > > > > This patch fixes it via initializing the cp0_compare_irq_shift as the > > cp0_compare_irq used in the old c0_compare_int_pending(). > > > > Reported-by: Maxime Bizon <mbizon@freebox.fr> > > Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com> > > When applied to 2.6.33-rc6, this patch fixes the problem on my > RM7035C-based system. > > Tested-by: Shane McDonald <mcdonald.shane@gmail.com> Thanks folks, applied. Ralf
Hi list, I am seeing a address conflict in asm-generic/spaces.h . in spaces.h ( 64 bit)CAC_BASE has been defined as 0x9800000000000000 however see mips run says it is 0x9000000000000000 http://books.google.co.in/books?id=kk8G2gK4Tw8C&lpg=PP1&dq=see%20mips%20 run&pg=PA51#v=onepage&q=&f=false Is this intentional? Thanks Anoop
On Wed, Feb 03, 2010 at 03:34:25AM -0800, Anoop P.A. wrote: > I am seeing a address conflict in asm-generic/spaces.h . in spaces.h ( > 64 bit)CAC_BASE has been defined as 0x9800000000000000 however see mips > run says it is 0x9000000000000000 > http://books.google.co.in/books?id=kk8G2gK4Tw8C&lpg=PP1&dq=see%20mips%20 > run&pg=PA51#v=onepage&q=&f=false > > Is this intentional? <asm/mach-generic/spaces.h> defines: #ifndef CAC_BASE #ifdef CONFIG_DMA_NONCOHERENT #define CAC_BASE _AC(0x9800000000000000, UL) #else #define CAC_BASE _AC(0xa800000000000000, UL) #endif #endif No 0x9000000000000000 anywhere - and it would be wrong because it stands for uncached. Ralf
Hi Ralf, I am sorry if it is not clear from my last mail. What I want to convey is, "See MIPS Run" explains "window on physical memory (cached)" will start @ 0x9000_0000_0000_0000. You can see "See MIPS Run" page under suspect from this link http://books.google.co.in/books?id=kk8G2gK4Tw8C&lpg=PP1&dq=see%20mips%20 run&pg=PA51#v=onepage&q=&f=false How ever as you mentioned Linux source defines CAC_BASE 0x98000000_00000000 Thanks Anoop > -----Original Message----- > From: Ralf Baechle [mailto:ralf@linux-mips.org] > Sent: Wednesday, February 03, 2010 6:04 PM > To: Anoop P.A. > Cc: linux-mips@linux-mips.org > Subject: Re: Cached Base address difference. > > On Wed, Feb 03, 2010 at 03:34:25AM -0800, Anoop P.A. wrote: > > > I am seeing a address conflict in asm-generic/spaces.h . in spaces.h ( > > 64 bit)CAC_BASE has been defined as 0x9800000000000000 however see mips > > run says it is 0x9000000000000000 > > http://books.google.co.in/books?id=kk8G2gK4Tw8C&lpg=PP1&dq=see%20mips%20 > > run&pg=PA51#v=onepage&q=&f=false > > > > Is this intentional? > > <asm/mach-generic/spaces.h> defines: > > #ifndef CAC_BASE > #ifdef CONFIG_DMA_NONCOHERENT > #define CAC_BASE _AC(0x9800000000000000, UL) > #else > #define CAC_BASE _AC(0xa800000000000000, UL) > #endif > #endif > > No 0x9000000000000000 anywhere - and it would be wrong because it stands > for uncached. > > Ralf
Anoop P.A. wrote: > Hi Ralf, > > I am sorry if it is not clear from my last mail. > > What I want to convey is, > > "See MIPS Run" explains "window on physical memory (cached)" will start > @ 0x9000_0000_0000_0000. > > You can see "See MIPS Run" page under suspect from this link > http://books.google.co.in/books?id=kk8G2gK4Tw8C&lpg=PP1&dq=see%20mips%20 > run&pg=PA51#v=onepage&q=&f=false > > How ever as you mentioned Linux source defines CAC_BASE > 0x98000000_00000000 The Linux header file is correct; the cached and uncached regions are swapped in the "See MIPS Run" diagram. The full MIPS64 memory map is documented in Volume III of the architecture manual which you can download from http://www.mips.com/products/architectures/mips64/ Chris
Patch
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 338dfe8..31b204b 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -1501,6 +1501,7 @@ void __cpuinit per_cpu_trap_init(void) cp0_perfcount_irq = -1; } else { cp0_compare_irq = CP0_LEGACY_COMPARE_IRQ; + cp0_compare_irq_shift = cp0_compare_irq; cp0_perfcount_irq = -1; }