Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 3月, 2014 1 次提交
  3. 05 3月, 2014 1 次提交
    • T
      irqchip: xtensa: Select only an online cpu · 5c331c86
      由 Thomas Gleixner 提交于 
      The user space interface does not filter out offline cpus. It merily
verifies that the mask contains at least one online cpu. So the
selector in the irq chip implementation needs to make sure to pick
only an online cpu because otherwise:

     Offline Core 1
     Set affinity to 0xe
     Selector will pick first set bit, i.e. core 1
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Chris Zankel <chris@zankel.net>
Cc: xtensa <linux-xtensa@linux-xtensa.org>
      5c331c86
  5. 04 3月, 2014 1 次提交
  7. 22 2月, 2014 2 次提交
  9. 23 1月, 2014 3 次提交
  11. 21 1月, 2014 1 次提交
  13. 15 1月, 2014 2 次提交
  15. 09 1月, 2014 1 次提交
    • B
      irqchip: sirf: set IRQ_LEVEL status_flags · a87010ef
      由 Barry Song 提交于 
      SiRF internal interrupts are using level trigger. we need to tell the irq
core this information. otherwise, we might get some problems as below
1. disable_irq(n)
here irq core will mark the disabled flag but still keep the irq enabled
due to involved lazy-disable
2. doing someting after disable_irq(n)
in step 2, if one interrupt n comes, irq core will mark it as pending and
mask the HW interrupt really. we name the coming interrupt as "X".
3. enable_irq(n)
this will unmask the interrupt, so the level-trigger HW interrupt will come
again, irq_handler will enter as "E1". after that, irq core will also check
whether irq n is pending, if yes, and pending interrupt is not level-trigger,
irq core will execute the pending irq_handler.
so if we don't set the IRQ_LEVEL flag here, irq core will execute pending
X again as "E2", but actually the pending interrupt has been handled by "E1".
that makes a level-trigger HW interrupt is executed twice.

here we fix the issue to avoid redundant interrupt overload.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NHuayi Li <Huayi.Li@csr.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      a87010ef
  17. 04 1月, 2014 1 次提交
  19. 23 12月, 2013 1 次提交
  21. 14 12月, 2013 2 次提交
    • L
      irqchip: armada-370-xp: fix MSI race condition · c7f7bd4a
      由 Lior Amsalem 提交于 
      In the Armada 370/XP driver, when we receive an IRQ 1, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of MSIs that
were generated. However, instead of acknowledging only the MSIs that
were generated, we acknowledge *all* the MSIs, by writing
~MSI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new MSI that isn't part of the
ones read into the temporary "msimask" variable is fired before we
acknowledge all MSIs, then we will simply loose it.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~msimask to acknoledge the handled MSIs.

Notice that the same problem is present in the IPI implementation, but
it is fixed as a separate patch, so that this IPI fix can be pushed to
older stable versions as appropriate (all the way to 3.8), while the
MSI code only appeared in 3.13.
Signed-off-by: NLior Amsalem <alior@marvell.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      c7f7bd4a
    • L
      irqchip: armada-370-xp: fix IPI race condition · a6f089e9
      由 Lior Amsalem 提交于 
      In the Armada 370/XP driver, when we receive an IRQ 0, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of IPIs that
were generated. However, instead of acknowledging only the IPIs that
were generated, we acknowledge *all* the IPIs, by writing
~IPI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new IPI that isn't part of the
ones read into the temporary "ipimask" variable is fired before we
acknowledge all IPIs, then we will simply loose it. This is causing
scheduling hangs on SMP intensive workloads.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~ipimask to acknoledge the handled IPIs.

Notice that the same problem is present in the MSI implementation, but
it will be fixed as a separate patch, so that this IPI fix can be
pushed to older stable versions as appropriate (all the way to 3.8),
while the MSI code only appeared in 3.13.
Signed-off-by: NLior Amsalem <alior@marvell.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: stable@vger.kernel.org # v3.8+
Fixes: 344e873e 'arm: mvebu: Add IPI support via doorbells'
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      a6f089e9
  23. 13 12月, 2013 1 次提交
  25. 12 12月, 2013 2 次提交
  27. 02 12月, 2013 1 次提交
  29. 28 11月, 2013 1 次提交
  31. 26 11月, 2013 1 次提交
  33. 24 11月, 2013 1 次提交
  35. 07 11月, 2013 1 次提交
  37. 30 9月, 2013 2 次提交
  39. 24 9月, 2013 2 次提交
  41. 17 9月, 2013 1 次提交
  43. 30 8月, 2013 1 次提交
    • B
      irqchip: sirf: move from legacy mode to linear irqdomain · 29eb51a7
      由 Barry Song 提交于 
      the series of patches for irqdomain core in 3.11 has broken sirf
irq which uses legacy mapping. all users fail in the new kernel
while setupping irq.

this patch moves to linear irqdomain and drop old legacy irqdomain
codes since we don't need it any more, and at the same time, it
also fixes the broken interrupts of sirfsoc in 3.11.

on the other hand, we actually only have 64 interrupt sources for
prima2 and atlas6, but there are 128 interrupt souces for marco
which uses GIC. in the legacy codes, sirf gpio also uses legacy
irqdomain, so to make gpio interrupt mapping not depend on the
prima2/atlas6/marco an use unified marco,we enlarge prima2/atlas6
interrupt number to 128. here we don't need this workaround any
more as sirf gpio also moved to linear mode before. so we move
SIRFSOC_NUM_IRQS back to 64 too.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      29eb51a7
  45. 29 8月, 2013 1 次提交
    • N
      drivers: irq-chip: irq-gic: introduce gic_cpu_if_down() · 10d9eb8a
      由 Nicolas Pitre 提交于 
      When processors are about to hit low power states, the assertion of
standbywfi signal, triggered by the wfi instruction, is essential to
entering low power modes. If an IRQ is pending on the processor at the
time wfi is issued, the wfi instruction completes and the processor
restarts execution without asserting the standbywfi signal. Depending
on the platform power controller HW this behaviour can be acceptable or
not; if this behaviour must be prevented software should be provided
with a way to disable the routing of interrupts to the core IRQ pins.

On systems where raw GIC distributor interrupts are connected to the power
controller as wake-up events (hence the power controller still senses
IRQs and can wake up cores upon IRQ pending), the GIC CPU interface can
be disabled on power down, so that the GIC CPU IF output is gated and wfi
cannot complete, thereby preventing the standbywfi issue.

This patch adds a simple function to the GIC driver that allows to
disable the GIC CPU IF from power down procedures.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
[rewrote commit log]
Signed-off-by: NOlof Johansson <olof@lixom.net>
      10d9eb8a
  47. 24 8月, 2013 4 次提交
  49. 21 8月, 2013 1 次提交
    • J
      irq-imgpdc: add ImgTec PDC irqchip driver · b6ef9161
      由 James Hogan 提交于 
      Add irqchip driver for the ImgTec PowerDown Controller (PDC) as found in
the TZ1090. The PDC has a number of general system wakeup (SysWake)
interrupts (which would for example be connected to a power button or an
external peripheral), and a number of peripheral interrupts which can
also wake the system but are connected straight to specific low-power
peripherals (such as RTC or Infrared). It has a single interrupt output
for SysWakes, and individual interrupt outputs for each peripheral.

The driver demuxes the SysWake interrupt line, and passes the peripheral
interrupts straight through. It also handles the set_wake interrupt
operation to enable/disable the appropriate wake event bits.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Rob Landley <rob@landley.net>
Cc: linux-metag@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
      b6ef9161
  51. 30 7月, 2013 2 次提交
    • N
      ARM: bL_switcher: do not hardcode GIC IDs in the code · ed96762e
      由 Nicolas Pitre 提交于 
      Currently, GIC IDs are hardcoded making the code dependent on the 4+4 b.L
configuration.  Let's allow for GIC IDs to be discovered upon switcher
initialization to support other b.L configurations such as the 1+1 one,
or 2+3 as on the VExpress TC2.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
      ed96762e
    • N
      ARM: gic: add CPU migration support · 1a6b69b6
      由 Nicolas Pitre 提交于 
      This is required by the big.LITTLE switcher code.

The gic_migrate_target() changes the CPU interface mapping for the
current CPU to redirect SGIs to the specified interface, and it also
updates the target CPU for each interrupts to that CPU interface
if they were targeting the current interface.  Finally, pending
SGIs for the current CPU are forwarded to the new interface.

Because Linux does not use it, the SGI source information for the
forwarded SGIs is not preserved.  Neither is the source information
for the SGIs sent by the current CPU to other CPUs adjusted to match
the new CPU interface mapping.  The required registers are banked so
only the target CPU could do it.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
      1a6b69b6
  53. 16 7月, 2013 1 次提交
  55. 15 7月, 2013 1 次提交
    • P
      clocksource+irqchip: delete __cpuinit usage from all related files · 8c37bb3a
      由 Paul Gortmaker 提交于 
      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 5e427ec2 ("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.

This removes all the drivers/clocksource and drivers/irqchip uses of
the __cpuinit macros from all C files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8c37bb3a