| Message ID | 1303229239-21551-6-git-send-email-daniel@gaisler.com |
|---|---|
| State | Superseded |
| Delegated to: | David Miller |
| Headers | show |
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
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
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
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
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
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
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
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
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
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
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)
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(-)