sparc32,leon: additional genirq patches
cover sparc32,leon: additional genirq patches
Hello Dave,
All the changes in this patch set [1..7] must be applied on top of Sam genirq patch. The are all LEON specific.
They add:
* mask/unmask spinlock protection
* Support for LEON Extended IRQ controller
* Use new genirq layer for per-cpu Timer ISR (cleanup)
* other cleanups
* add support for CPU affinity
Daniel Hellstrom
arch/sparc/include/asm/leon.h | 37 +---- arch/sparc/kernel/entry.S | 16 -- arch/sparc/kernel/leon_kernel.c | 318 ++++++++++++++++++++++++--------------- arch/sparc/kernel/leon_smp.c | 12 +- 4 files changed, 207 insertions(+), 176 deletions(-)
From: Daniel Hellstrom <[email protected]>
Date: Tue, 19 Apr 2011 18:06:12 +0200
Quoted 5 lines
Hello Dave,
All the changes in this patch set [1..7] must be applied on top of Sam genirq patch. The are all LEON specific.
Quoted 8 lines
They add:
* mask/unmask spinlock protection
* Support for LEON Extended IRQ controller
* Use new genirq layer for per-cpu Timer ISR (cleanup)
* other cleanups
* add support for CPU affinityDaniel Hellstrom
Hey Daniel, could you please address Sam's feedback on a few patches and then resubmit this? You can integrate the ACK's he gave for some of the patches when you do that.
Thanks!
Quoted 17 lines · David Miller
From: Daniel Hellstrom <[email protected]>
Date: Tue, 19 Apr 2011 18:06:12 +0200Quoted 12 lines
Hello Dave,
All the changes in this patch set [1..7] must be applied on top of Sam genirq patch. The are all LEON specific.
They add:
* mask/unmask spinlock protection
* Support for LEON Extended IRQ controller
* Use new genirq layer for per-cpu Timer ISR (cleanup)
* other cleanups
* add support for CPU affinity
Quoted 9 lines
Quoted 3 lines
Daniel Hellstrom
Hey Daniel, could you please address Sam's feedback on a few patches and then resubmit this? You can integrate the ACK's he gave for some of the patches when you do that.
It became a bit more messy than my intension... I have added Sam's boot_cpu_id patch in front of my patches, and previous patch 6 (now 7) has been swapped with previous patch 7 (now 8). I have added Sam's ACK. The previous patch 6 which I was supposed to drop have now been cleaned up using Sam's boot_cpu_id instead of a LEON specific variable leon3_boot_cpu.
Thanks,
Daniel
Quoted 28 lines · Daniel Hellstrom
Quoted 17 lines · David Miller
From: Daniel Hellstrom <[email protected]>
Date: Tue, 19 Apr 2011 18:06:12 +0200Quoted 12 lines
Hello Dave,
All the changes in this patch set [1..7] must be applied on top of Sam genirq patch. The are all LEON specific.
They add:
* mask/unmask spinlock protection
* Support for LEON Extended IRQ controller
* Use new genirq layer for per-cpu Timer ISR (cleanup)
* other cleanups
* add support for CPU affinityQuoted 9 lines
Quoted 2 lines
Daniel Hellstrom
Hey Daniel, could you please address Sam's feedback on a few patches and then resubmit this? You can integrate the ACK's he gave for some of the patches when you do that.
Quoted 6 lines
It became a bit more messy than my intension... I have added Sam's
boot_cpu_idpatch in front of my patches, and previous patch 6 (now 7) has been swapped with previous patch 7 (now 8). I have added Sam's ACK. The previous patch 6 which I was supposed to drop have now been cleaned up using Sam'sboot_cpu_idinstead of a LEON specific variableleon3_boot_cpu.
I'm sorry to mess up stuff even more, the patches 1 and 8 in my series does not compile on UP since setup.h isn't included. But even worse is that the boot_cpu_id is always 0 it seems because it is initialized before BSS is cleared, and boot_cpu_id is part of BSS.
Please apply patches [2/8]..[7/8], and drop [1/8] and [8/8]. It is better we do it the way you proposed (drop boot_cpu patch). I'm sorry that I ever brought up the boot_cpu_id stuff, as that had nothing to do with the genirq patches, and I'm sorry for taking your time like this.
Daniel
Quoted 10 lines
I'm sorry to mess up stuff even more, the patches 1 and 8 in my series does not compile on UP since
setup.hisn't included. But even worse is that theboot_cpu_idis always 0 it seems because it is initialized before BSS is cleared, andboot_cpu_idis part of BSS.Please apply patches [2/8]..[7/8], and drop [1/8] and [8/8]. It is better we do it the way you proposed (drop
boot_cpupatch). I'm sorry that I ever brought up theboot_cpu_idstuff, as that had nothing to do with the genirq patches, and I'm sorry for taking your time like this.
I agree. Lets get the genirq related stuff in and fix the boot_cpu_id stuff properly later.
Added to my TODO list.
The issue with boot_cpu_id being cleared is btw not new - but I should have caught that anyway.
Sam
From: Sam Ravnborg <[email protected]>
Date: Wed, 20 Apr 2011 14:58:53 +0200
Quoted 2 lines
The issue with
boot_cpu_idbeing cleared is btw not new - but I should have caught that anyway.
It's partially another side effect of that awful behavioral change GCC made several years ago to "auto BSS" variables explicitly initialized to zero.
You used to be able to add an explicit zero initialization to force items into the data section.
This change has broken various things in the sparc32 port over the years.
Probably the thing to do is to initialize boot_cpu_id{,4} to some "invalid" value (like 0xff) in the kernel image and just make certain the the initialization happens early enough.
On Thu, 21 Apr 2011 11:09:23 -0700 (PDT), David Miller wrote:
From: Sam Ravnborg <[email protected]>
Quoted 11 lines
Date: Wed, 20 Apr 2011 14:58:53 +0200
Quoted 2 lines
The issue with
boot_cpu_idbeing cleared is btw not new - but I should have caught that anyway.It's partially another side effect of that awful behavioral change GCC made several years ago to "auto BSS" variables explicitly initialized to zero.
You used to be able to add an explicit zero initialization to force items into the data section.
Yeah, ridiculous that change is, one could always use attribute section to force it into DATA but that is kind of complicated. I always thought I was stupid but now I know that the compiler changed its behaviour... thanks. Another problem is that "cleanup people" does not know of this and erase that only hint.
Quoted 7 lines
This change has broken various things in the sparc32 port over the years.
Probably the thing to do is to initialize boot_cpu_id{,4} to some "invalid" value (like
0xff) in the kernel image and just make certain the the initialization happens early enough.
That is basically what I've done in the next "[1..3] sparc32:boot_cpu_id patches".
Daniel
From: Daniel Hellstrom <[email protected]>
Date: Wed, 20 Apr 2011 13:23:00 +0200
Quoted 1 line
Please apply patches [2/8]..[7/8], and drop [1/8] and [8/8].
Done.