Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
get_online_cpus and put_online_cpus instead as it highlights the
refcount semantics in these operations.
The new API guarantees protection against the cpu-hotplug operation, but
it doesn't guarantee serialized access to any of the local data
structures. Hence the changes needs to be reviewed.
In case of pseries_add_processor/pseries_remove_processor, use
cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
cpu_present_map there.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
All kobjects require a dynamically allocated name now. We no longer
need to keep track if the name is statically assigned, we can just
unconditionally free() all kobject names on cleanup.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This seems as reasonable assumption and gets some SNI machines to work
which currently must rely on the cp0 counter as clocksource.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Frank Rowand <frank.rowand@am.sony.com> reports:
> In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot.
>
> The cause is that plat_time_init() from arch/mips/tx4927/common/
> tx4927_setup.c does not override the __weak plat_time_init() from
> arch/mips/kernel/time.c. This is due to a compiler bug in gcc 4.1.1. The
> bug is reported to not exist in earlier versions of gcc, and to be fixed in
> 4.1.2. The problem is that the __weak plat_time_init() is empty and thus
> gets optimized out of existence (thus the linker is never given the option
> to replace the __weak function).
[ He meant the call to plat_time_init() from time_init() gets optimized away ]
> For more info on the gcc bug see
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
>
> The attached patch is one workaround. Another possible workaround
[ His patch adds -fno-unit-at-a-time for time.c ]
> would be to change the __weak plat_time_init() to be a non-empty
> function.
The __weak definition of plat_time_init was only ever meant to be a
migration helper to keep platforms that don't have a plat_time_init
compiling. A few greps says that all platforms now supply their own
plat_time_init() so the weak definition is no longer needed. So I
instead delete it.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Sibyte SOCs only have 32-bit PCI. Due to the sparse use of the address
space only the first 1GB of memory is mapped at physical addresses
below 1GB. If a system has more than 1GB of memory 32-bit DMA will
not be able to reach all of it.
For now this patch is good enough to keep Sibyte users happy but it seems
eventually something like swiotlb will be needed for Sibyte.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In particular as-is it's not suited for multicore and mutiprocessors
systems where there is on guarantee that the counter are synchronized
or running from the same clock at all. This broke Sibyte and probably
others since the "[MIPS] Handle R4000/R4400 mfc0 from count register."
commit.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The R4000 and R4400 have an errata where if the cp0 count register is read
in the exact moment when it matches the compare register no interrupt will
be generated.
This bug may be triggered if the cp0 count register is being used as
clocksource and the compare interrupt as clockevent. So a simple
workaround is to avoid using the compare for both facilities on the
affected CPUs.
This is different from the workaround suggested in the old errata documents;
at some opportunity probably the official version should be implemented
and tested. Another thing to find out is which processor versions
exactly are affected. I only have errata documents upto R4400 V3.0
available so for the moment the code treats all R4000 and R4400 as broken.
This is potencially a problem for some machines that have no other decent
clocksource available; this workaround will cause them to fall back to
another clocksource, worst case the "jiffies" source.
This matters to any sort of device that is wired to one of the CPU
interrupt pins on an SMP system. Typically the scenario is most easily
triggered with the count/compare timer interrupt where the same interrupt
number and thus irq_desc is used on each processor.
CPU A CPU B
do_IRQ()
generic_handle_irq()
handle_level_irq()
spin_lock(desc_lock)
set IRQ_INPROGRESS
spin_unlock(desc_lock)
do_IRQ()
generic_handle_irq()
handle_level_irq()
spin_lock(desc_lock)
IRQ_INPROGRESS set => bail out
spin_lock(desc_lock)
clear IRQ_INPROGRESS
spin_unlock(desc_lock)
In case of the cp0 compare interrupt this means the interrupt will be
acked and not handled or re-armed on CPU b, so there won't be any timer
interrupt until the count register wraps around.
With kernels 2.6.20 ... 2.6.23 we usually were lucky that things were just
working right on VSMP because the count registers are synchronized on
bootup so it takes something that disables interrupts for a long time on
one processor to trigger this one.
For scenarios where an interrupt is multicasted or broadcasted over several
CPUs the existing code was safe and the fix will break it. There is no
way to know in the interrupt controller code because it is abstracted from
the platform code. I think we do not have such a setup currently, so this
should be ok.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Adds a JR.HB after halting a TC, to ensure that the TC has really halted.
only modifies the TCSTATUS register when the TC is safely halted.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
We have no guarantee by the generic time code that the timer is stopped
when the ->next_event method is called. Modifying the Timer Initial Count
register while the timer is enabled has UNPREDICTABLE effect according to
the BCM1250/BCM1125/BCM1125H User Manual. So stop the timer before
reprogramming.
This is a paranoia fix; no ill effects have been observed previously.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
For the old minimum of a single tick a value of zero would be programmed
into the init value register which in the BCM1250/BCM1125/BCM1125H User
Manual in the Timer Special Cases section is documented to have
UNPREDICTABLE effect.
Observable sympthoms of this bug were hangs of several seconds on the
console during bootup and later if both dyntick and highres timer options
were activated.
In theory contiguous mode of the timers is also affected but in an act of
hopeless lack of realism I'll assume nobody will ever configure a KERNEL
for HZ > 500kHz but if so I leave that to evolution to sort out.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Shadow register support would not possibly have worked on multicore
systems. The support code for it was also depending not on MIPS R2 but
VSMP or SMTC kernels even though it makes perfect sense with UP kernels.
SR sets are a scarce resource and the expected usage pattern is that
users actually hardcode the register set numbers in their code. So fix
the allocator by ditching it. Move the remaining CPU probe bits into
the generic CPU probe.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The Jazz machines have to use the PIT timer for dyntick and highresolution
kernels. This may break because currently just like i386 used to do MIPS
uses two separate spinlocks in the actual PIT code and the PC speaker
code. So switch to do it the same that x86 currently does PIT locking.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
