Some configs of mips like xway_defconffig are failing with the error:
arch/mips/lantiq/irq.c:209:2: error: initialization from incompatible
pointer type [-Werror]
"icu",
^
arch/mips/lantiq/irq.c:209:2: error: (near initialization for
'ltq_irq_type.parent_device') [-Werror]
arch/mips/lantiq/irq.c:219:2: error: initialization from incompatible
pointer type [-Werror]
"eiu",
^
arch/mips/lantiq/irq.c:219:2: error: (near initialization for
'ltq_eiu_type.parent_device') [-Werror]
The first member of the "struct irq" is no longer a pointer for the
name.
Fixes: be45beb2df ("genirq: Add runtime power management support for IRQ chips")
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Acked-by: John Crispin <john@phrozen.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13684/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
We used the hardware IRQ number to register the IRQ handler and not the
virtual one. This probably caused some problems because the hardware
IRQ numbers are only unique for each IRQ controller and not in the
system. The virtual IRQ number is managed by Linux and unique in the
system. This was probably the reason there was a gab of 8 IRQ numbers added
before the numbers used for the lantiq IRQ controller. With the current
setup the hardware and the virtual IRQ numbers are the same.
Reported-by: Thomas Langer <thomas.langer@intel.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: John Crispin <john@phrozen.org>
Cc: thomas.langer@intel.com
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13539/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
We runtime load the available external interrupts into an array and store
the number inside exin_avail. Some of the code however uses MAX_EIU for
looping over the array which may partially be 0. This is a cosmetic fix as
the existing code works as is. It is just nicer to only loop over the array
elements that were actually populated during probe.
Signed-off-by: John Crispin <john@phrozen.org>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/13602/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Using of_irq_count to load the irq index from the devicetree is incorrect.
This will cause the kernel to map them regardless, even if they dont
actually get used. Change the code to use of_property_count_u32_elems()
instead which is the correct API to use in this case.
Signed-off-by: John Crispin <john@phrozen.org>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/13601/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Using of_irq_count to load the irq index from the devicetree is incorrect.
This will cause the kernel to map them regardless, even if they dont
actually get used. Change the code to use of_property_count_u32_elems()
instead which is the correct API to use in this case.
Signed-off-by: John Crispin <john@phrozen.org>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/13601/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The majority of SMP platforms handle their IPIs through do_IRQ()
which calls irq_{enter/exit}(). When a call function IPI is received,
smp_call_function_interrupt() is called which also calls
irq_{enter,exit}(), meaning irq_count is raised twice.
When tick broadcasting is used (which is implemented via a call
function IPI), this incorrectly causes all CPU idle time on the core
receiving broadcast ticks to be accounted as time spent servicing
IRQs, as account_process_tick() will account as such if irq_count is
greater than 1. This results in 100% CPU usage being reported on a
core which receives its ticks via broadcast.
This patch removes the SMP smp_call_function_interrupt() wrapper which
calls irq_{enter,exit}(). Platforms which handle their IPIs through
do_IRQ() now call generic_smp_call_function_interrupt() directly to
avoid incrementing irq_count a second time. Platforms which don't
(loongson, sgi-ip27, sibyte) call generic_smp_call_function_interrupt()
wrapped in irq_{enter,exit}().
Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10770/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Nobody is maintaining SMTC anymore and there also seems to be no userbase.
Which is a pity - the SMTC technology primarily developed by Kevin D.
Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
ASE's power and elegance.
Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
https://patchwork.linux-mips.org/patch/6719/ which while very similar did
no longer apply cleanly when I tried to merge it plus some additional
post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
merge once upon a time.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Panic() is going to add a \n itself and it's annoying if a panic message rolls
of the screen on a device with no scrollback.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 3747069b25e419f6b51395f48127e9812abc3596 upstream.
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
and are flagged as __cpuinit -- so if we remove the __cpuinit from
the arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
related content into no-ops as early as possible, since that will get
rid of these warnings. In any case, they are temporary and harmless.
Here, we remove all the MIPS __cpuinit from C code and __CPUINIT
from asm files. MIPS is interesting in this respect, because there
are also uasm users hiding behind their own renamed versions of the
__cpuinit macros.
[1] https://lkml.org/lkml/2013/5/20/589
[ralf@linux-mips.org: Folded in Paul's followup fix.]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5494/
Patchwork: https://patchwork.linux-mips.org/patch/5495/
Patchwork: https://patchwork.linux-mips.org/patch/5509/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This code makes the irqs used by the EIU loadable from the DT. Additionally we
add a helper that allows the pinctrl layer to map external irqs to real irq
numbers.
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/4818/
Up to now all our SoCs had the 5 IM ranges in a consecutive order. To accomodate
the SVIP we need to support IM ranges that are scattered inside the register range.
Signed-off-by: John Crispin <blogic@openwrt.org>
Patchwork: http://patchwork.linux-mips.org/patch/4237/
Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled and we even check
and yell when an interrupt handler returns with interrupts enabled (see
commit [b738a50a: genirq: Warn when handler enables interrupts]).
So now this flag is a NOOP and can be removed.
[ralf@linux-mips.org: Fixed up conflicts in
arch/mips/alchemy/common/dbdma.c, arch/mips/cavium-octeon/smp.c and
arch/mips/kernel/perf_event.c.]
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de
linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/2835/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Panic() invokes printk() to add a \n internally, so panic arguments should
not themselves end in \n. Panic invocations in arch/mips and elsewhere
are inconsistently sometimes terminating in \n, sometimes not.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
