[PATCH urgent] MIPS: Fixup of the r4k timer

[PATCH urgent] MIPS: Fixup of the r4k timer

[Wu Zhangjin]

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>
---
 arch/mips/kernel/traps.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

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;
 	}
 
-- 
1.6.6

Re: [PATCH urgent] MIPS: Fixup of the r4k timer

[Shane McDonald]

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>

Re: [PATCH urgent] MIPS: Fixup of the r4k timer

[Ralf Baechle]

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

Cached Base address difference.

[Anoop P.A.]

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

Cached Base address difference.

[Anoop P.A.]

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

Re: Cached Base address difference.

[Ralf Baechle]

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

RE: Cached Base address difference.

[Anoop P.A.]

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

RE: Cached Base address difference.

[Anoop P.A.]

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

Re: Cached Base address difference.

[Chris Dearman]

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

-- 
Chris Dearman               Desk: +1 408 530 5092  Cell: +1 408 398 5531
MIPS Technologies Inc            955 East Arques Ave, Sunnyvale CA 94085