Patchwork [6/7] sparc32,leon: operate on boot-cpu IRQ controller registers

login
register
mail settings
Submitter Daniel Hellstrom
Date April 19, 2011, 4:07 p.m.
Message ID <1303229239-21551-6-git-send-email-daniel@gaisler.com>
Download mbox | patch
Permalink /patch/92015/
State Superseded
Delegated to: David Miller
Headers show

Comments

Daniel Hellstrom - April 19, 2011, 4:07 p.m.
Each CPU has a separate set of IRQ controller registers, this
patch makes sure that the boot-cpu registers are used instead
of CPU0's. Note that there are other parts of the SPARC32/LEON
port which does not support booting on other than CPU0 anyway,
however this this cleans up the IRQ controller layer in that
regard.

Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
---
 arch/sparc/include/asm/leon.h   |    1 +
 arch/sparc/kernel/leon_kernel.c |   14 ++++++++------
 2 files changed, 9 insertions(+), 6 deletions(-)
Sam Ravnborg - April 19, 2011, 6:47 p.m.
On Tue, Apr 19, 2011 at 06:07:18PM +0200, Daniel Hellstrom wrote:
> Each CPU has a separate set of IRQ controller registers, this
> patch makes sure that the boot-cpu registers are used instead
> of CPU0's. Note that there are other parts of the SPARC32/LEON
> port which does not support booting on other than CPU0 anyway,
> however this this cleans up the IRQ controller layer in that
> regard.
> 
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
> ---
>  arch/sparc/include/asm/leon.h   |    1 +
>  arch/sparc/kernel/leon_kernel.c |   14 ++++++++------
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/sparc/include/asm/leon.h b/arch/sparc/include/asm/leon.h
> index 31fb2ac..1776f71 100644
> --- a/arch/sparc/include/asm/leon.h
> +++ b/arch/sparc/include/asm/leon.h
> @@ -335,6 +335,7 @@ extern int leon_flush_needed(void);
>  extern void leon_switch_mm(void);
>  extern int srmmu_swprobe_trace;
>  extern int leon3_ticker_irq;
> +extern int leon3_boot_cpu;

We already have boot_cpu_id - defiend in smp_32.c.
Could it be used rather than a leon specific variable?

We would need to define boot_cpu_id also in the non-SMP case
to do so - but this could also clean up code
in sun4d_irq.

Note: leon actually set this variable in head_32.S already.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Hellstrom - April 20, 2011, 7:02 a.m.
Sam Ravnborg wrote:

>On Tue, Apr 19, 2011 at 06:07:18PM +0200, Daniel Hellstrom wrote:
>  
>
>>Each CPU has a separate set of IRQ controller registers, this
>>patch makes sure that the boot-cpu registers are used instead
>>of CPU0's. Note that there are other parts of the SPARC32/LEON
>>port which does not support booting on other than CPU0 anyway,
>>however this this cleans up the IRQ controller layer in that
>>regard.
>>
>>Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
>>---
>> arch/sparc/include/asm/leon.h   |    1 +
>> arch/sparc/kernel/leon_kernel.c |   14 ++++++++------
>> 2 files changed, 9 insertions(+), 6 deletions(-)
>>
>>diff --git a/arch/sparc/include/asm/leon.h b/arch/sparc/include/asm/leon.h
>>index 31fb2ac..1776f71 100644
>>--- a/arch/sparc/include/asm/leon.h
>>+++ b/arch/sparc/include/asm/leon.h
>>@@ -335,6 +335,7 @@ extern int leon_flush_needed(void);
>> extern void leon_switch_mm(void);
>> extern int srmmu_swprobe_trace;
>> extern int leon3_ticker_irq;
>>+extern int leon3_boot_cpu;
>>    
>>
>
>We already have boot_cpu_id - defiend in smp_32.c.
>Could it be used rather than a leon specific variable?
>
>We would need to define boot_cpu_id also in the non-SMP case
>to do so - but this could also clean up code
>in sun4d_irq.
>  
>
Yes, it might remove a ifdef to the expence of a bigger footprint.

>Note: leon actually set this variable in head_32.S already.
>  
>
I agree that it would be nicer, however I think the SUNs will never be 
booted on CPU1 anyway? Anyways, I think this should go into another 
patch series. I'm very interested in supporting booting on CPU1 for 
LEON, that is really nice in AMP systems where for example RTEMS is 
running on CPU0 and Linux on CPU1. Today RTEMS supports running on 
CPU!=0, so it is not a big issue right now but is not very flexible.

As I state in the comment this patch does not aim to fix everything just 
parts of the IRQ Controller code, there are a lot of other stuff that 
needs to be done in order to support this, not only in Linux the PROM as 
well. I plan to come back later with a patch set for this.

Sam, is that acceptable for now?

Daniel

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
crn@post.netunix.com - April 20, 2011, 7:39 a.m.
On Wed, 20 Apr 2011, Daniel Hellstrom wrote:

>> 
> I agree that it would be nicer, however I think the SUNs will never be booted 
> on CPU1 anyway? Anyways, I think this should go into another patch series.

You cannot assume this, sun4d and AFAIK all 64bit systems will boot on
the first non-blacklisted CPU found.
For example, it is perfectly OK to have no CPU present on board0 slot0
in which case the SS1000 will boot using CPU1.

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Hellstrom - April 20, 2011, 8:12 a.m.
crn@post.netunix.com wrote:

>
>
> On Wed, 20 Apr 2011, Daniel Hellstrom wrote:
>
>>>
>> I agree that it would be nicer, however I think the SUNs will never 
>> be booted on CPU1 anyway? Anyways, I think this should go into 
>> another patch series.
>
>
> You cannot assume this, sun4d and AFAIK all 64bit systems will boot on
> the first non-blacklisted CPU found.
> For example, it is perfectly OK to have no CPU present on board0 slot0
> in which case the SS1000 will boot using CPU1.

Sorry I meant the UP 32-bit SUNs, some if not all SMP 32-bit SUNs 
apparently use the boot_cpu_id Sam is talking about. Have you tried 
booting on CPU1 with a UP Linux kernel on the SS1000 machine?

I still believe that the changes should go into a separate patch series 
though.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - April 20, 2011, 8:15 a.m.
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Wed, 20 Apr 2011 10:12:25 +0200

> Sorry I meant the UP 32-bit SUNs, some if not all SMP 32-bit SUNs
> apparently use the boot_cpu_id Sam is talking about. Have you tried
> booting on CPU1 with a UP Linux kernel on the SS1000 machine?

Regardless, we should make it work.

It was terrible when I had to fix this on sparc64.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Hellstrom - April 20, 2011, 8:35 a.m.
David Miller wrote:

>From: Daniel Hellstrom <daniel@gaisler.com>
>Date: Wed, 20 Apr 2011 10:12:25 +0200
>
>  
>
>>Sorry I meant the UP 32-bit SUNs, some if not all SMP 32-bit SUNs
>>apparently use the boot_cpu_id Sam is talking about. Have you tried
>>booting on CPU1 with a UP Linux kernel on the SS1000 machine?
>>    
>>
>
>Regardless, we should make it work.
>  
>
I totally agree with you. And it is important for the LEON family as 
well. New quad-core LEONs are designed to be able to run different 
operating systems on different CPUs, or two linux instances in parallel. 
So the hardware supports it, and I believe the SUNs do too.

>It was terrible when I had to fix this on sparc64.
>  
>
I think it is a quite big job, and not really related. I can drop this 
cleanup patch now and make a proper implementation later this year. What 
I want is get more important stuff working with genirq first.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - April 20, 2011, 8:39 a.m.
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Wed, 20 Apr 2011 10:35:55 +0200

> David Miller wrote:
> 
>>It was terrible when I had to fix this on sparc64.
>>  
> I think it is a quite big job, and not really related. I can drop this
> cleanup patch now and make a proper implementation later this
> year. What I want is get more important stuff working with genirq
> first.

So like you said, leave this cleanup for later.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Daniel Hellstrom - April 20, 2011, 8:44 a.m.
David Miller wrote:

>From: Daniel Hellstrom <daniel@gaisler.com>
>Date: Wed, 20 Apr 2011 10:35:55 +0200
>
>  
>
>>David Miller wrote:
>>
>>    
>>
>>>It was terrible when I had to fix this on sparc64.
>>> 
>>>      
>>>
>>I think it is a quite big job, and not really related. I can drop this
>>cleanup patch now and make a proper implementation later this
>>year. What I want is get more important stuff working with genirq
>>first.
>>    
>>
>
>So like you said, leave this cleanup for later.
>  
>
Ok, since the affinity patch depends on it, I will update according to 
Sams comments and resend it. The affinity patch will be patch 7/7 and 
6/7 should be dropped.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - April 20, 2011, 8:45 a.m.
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Wed, 20 Apr 2011 10:44:26 +0200

> Ok, since the affinity patch depends on it, I will update according to
> Sams comments and resend it. The affinity patch will be patch 7/7 and
> 6/7 should be dropped.

Ok.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
crn@post.netunix.com - April 20, 2011, 8:46 a.m.
On Wed, 20 Apr 2011, Daniel Hellstrom wrote:
> crn@post.netunix.com wrote:
>> On Wed, 20 Apr 2011, Daniel Hellstrom wrote:
>>>> 
>>> I agree that it would be nicer, however I think the SUNs will never be 
>>> booted on CPU1 anyway? Anyways, I think this should go into another patch 
>>> series.
>> 
>> You cannot assume this, sun4d and AFAIK all 64bit systems will boot on
>> the first non-blacklisted CPU found.
>> For example, it is perfectly OK to have no CPU present on board0 slot0
>> in which case the SS1000 will boot using CPU1.
>
> Sorry I meant the UP 32-bit SUNs, some if not all SMP 32-bit SUNs apparently 
> use the boot_cpu_id Sam is talking about. Have you tried booting on CPU1 with 
> a UP Linux kernel on the SS1000 machine?
>
> I still believe that the changes should go into a separate patch series 
> though.

It is legal hardware and OBP wise to have only one CPU fitted in any
random slot and the OBP will report this.
We should support this (slightly unusual but valid) configuration.
In the case of the ss1000 the kernel has a bad case of bit rot and
it would be a very good idea to get a UP kernel working before
trying to fix SMP.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/sparc/include/asm/leon.h b/arch/sparc/include/asm/leon.h
index 31fb2ac..1776f71 100644
--- a/arch/sparc/include/asm/leon.h
+++ b/arch/sparc/include/asm/leon.h
@@ -335,6 +335,7 @@  extern int leon_flush_needed(void);
 extern void leon_switch_mm(void);
 extern int srmmu_swprobe_trace;
 extern int leon3_ticker_irq;
+extern int leon3_boot_cpu;
 
 #ifdef CONFIG_SMP
 extern int leon_smp_nrcpus(void);
diff --git a/arch/sparc/kernel/leon_kernel.c b/arch/sparc/kernel/leon_kernel.c
index 80ab271..26acc75 100644
--- a/arch/sparc/kernel/leon_kernel.c
+++ b/arch/sparc/kernel/leon_kernel.c
@@ -31,6 +31,7 @@  int leondebug_irq_disable;
 int leon_debug_irqout;
 static int dummy_master_l10_counter;
 unsigned long amba_system_id;
+int leon3_boot_cpu;
 static DEFINE_SPINLOCK(leon_irq_lock);
 
 unsigned long leon3_gptimer_irq; /* interrupt controller irq number */
@@ -79,8 +80,8 @@  void leon_eirq_setup(unsigned int eirq)
 	 */
 	irq_link(veirq);
 	mask = 1 << eirq;
-	oldmask = LEON3_BYPASS_LOAD_PA(LEON_IMASK(0));
-	LEON3_BYPASS_STORE_PA(LEON_IMASK(0), (oldmask | mask));
+	oldmask = LEON3_BYPASS_LOAD_PA(LEON_IMASK(leon3_boot_cpu));
+	LEON3_BYPASS_STORE_PA(LEON_IMASK(leon3_boot_cpu), (oldmask | mask));
 	sparc_leon_eirq = eirq;
 }
 
@@ -105,8 +106,8 @@  static void leon_unmask_irq(struct irq_data *data)
 
 	mask = (unsigned long)data->chip_data;
 	spin_lock_irqsave(&leon_irq_lock, flags);
-	oldmask = LEON3_BYPASS_LOAD_PA(LEON_IMASK(0));
-	LEON3_BYPASS_STORE_PA(LEON_IMASK(0), (oldmask | mask));
+	oldmask = LEON3_BYPASS_LOAD_PA(LEON_IMASK(leon3_boot_cpu));
+	LEON3_BYPASS_STORE_PA(LEON_IMASK(leon3_boot_cpu), (oldmask | mask));
 	spin_unlock_irqrestore(&leon_irq_lock, flags);
 }
 
@@ -116,8 +117,8 @@  static void leon_mask_irq(struct irq_data *data)
 
 	mask = (unsigned long)data->chip_data;
 	spin_lock_irqsave(&leon_irq_lock, flags);
-	oldmask = LEON3_BYPASS_LOAD_PA(LEON_IMASK(0));
-	LEON3_BYPASS_STORE_PA(LEON_IMASK(0), (oldmask & ~mask));
+	oldmask = LEON3_BYPASS_LOAD_PA(LEON_IMASK(leon3_boot_cpu));
+	LEON3_BYPASS_STORE_PA(LEON_IMASK(leon3_boot_cpu), (oldmask & ~mask));
 	spin_unlock_irqrestore(&leon_irq_lock, flags);
 }
 
@@ -205,6 +206,7 @@  void __init leon_init_timers(irq_handler_t counter_fn)
 	leon_debug_irqout = 0;
 	master_l10_counter = (unsigned int *)&dummy_master_l10_counter;
 	dummy_master_l10_counter = 0;
+	leon3_boot_cpu = hard_smp_processor_id();
 
 	rootnp = of_find_node_by_path("/ambapp0");
 	if (!rootnp)