Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 2月, 2009 1 次提交
  3. 19 2月, 2009 3 次提交
  5. 18 2月, 2009 1 次提交
    • N
      [ARM] 5401/1: Orion: fix edge triggered GPIO interrupt support · fd4b9b36
      由 Nicolas Pitre 提交于 
      The GPIO interrupts can be configured as either level triggered or edge
triggered, with a default of level triggered.  When an edge triggered
interrupt is requested, the gpio_irq_set_type method is called which
currently switches the given IRQ descriptor between two struct irq_chip
instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
happens via __setup_irq() which also calls irq_chip_set_defaults() to
assign default methods to uninitialized ones.  The problem is that
irq_chip_set_defaults() is called before the irq_chip reference is
switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
case) with uninitialized methods such as chip->startup() causing a kernel
oops.

Many solutions are possible, such as making irq_chip_set_defaults() global
and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
before irq_chip_set_defaults() in __setup_irq().  But those require
modifications to the generic IRQ code which might have adverse effect on
other architectures, and that would still be a fragile arrangement.
Manually copying the missing methods from within gpio_irq_set_type()
would be really ugly and it would break again the day new methods with
automatic defaults are added.

A better solution is to have a single irq_chip instance which can deal
with both edge and level triggered interrupts.  It is also a good idea
to switch the IRQ handler instead, as the edge IRQ handler allows for
one edge IRQ event to be queued as the IRQ is actually masked only when
that second IRQ is received, at which point the hardware can queue an
additional IRQ event, making edge triggered interrupts a bit more
reliable.
Tested-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fd4b9b36
  7. 17 2月, 2009 1 次提交
  9. 15 2月, 2009 2 次提交
  11. 14 2月, 2009 2 次提交
  13. 10 2月, 2009 1 次提交
  15. 03 2月, 2009 1 次提交
  17. 31 1月, 2009 3 次提交
  19. 30 1月, 2009 8 次提交
  21. 29 1月, 2009 1 次提交
    • N
      [ARM] 5366/1: fix shared memory coherency with VIVT L1 + L2 caches · 08e445bd
      由 Nicolas Pitre 提交于 
      When there are multiple L1-aliasing userland mappings of the same physical
page, we currently remap each of them uncached, to prevent VIVT cache
aliasing issues. (E.g. writes to one of the mappings not being immediately
visible via another mapping.)  However, when we do this remapping, there
could still be stale data in the L2 cache, and an uncached mapping might
bypass L2 and go straight to RAM.  This would cause reads from such
mappings to see old data (until the dirty L2 line is eventually evicted.)

This issue is solved by forcing a L2 cache flush whenever the shared page
is made L1 uncacheable.

Ideally, we would make L1 uncacheable and L2 cacheable as L2 is PIPT. But
Feroceon does not support that combination, and the TEX=5 C=0 B=0 encoding
for XSc3 doesn't appear to work in practice.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      08e445bd
  23. 28 1月, 2009 3 次提交
  25. 27 1月, 2009 1 次提交
  27. 26 1月, 2009 2 次提交
  29. 25 1月, 2009 1 次提交
  31. 24 1月, 2009 3 次提交
  33. 22 1月, 2009 1 次提交
  35. 21 1月, 2009 1 次提交
  37. 20 1月, 2009 1 次提交
    • G
      i.MX31: Image Processing Unit DMA and IRQ drivers · 5296b56d
      由 Guennadi Liakhovetski 提交于 
      i.MX3x SoCs contain an Image Processing Unit, consisting of a Control
Module (CM), Display Interface (DI), Synchronous Display Controller (SDC),
Asynchronous Display Controller (ADC), Image Converter (IC), Post-Filter
(PF), Camera Sensor Interface (CSI), and an Image DMA Controller (IDMAC).
CM contains, among other blocks, an Interrupt Generator (IG) and a Clock
and Reset Control Unit (CRCU). This driver serves IDMAC and IG. They are
supported over dmaengine and irq-chip APIs respectively.

IDMAC is a specialised DMA controller, its DMA channels cannot be used for
general-purpose operations, even though it might be possible to configure
a memory-to-memory channel for memcpy operation. This driver will not work
with generic dmaengine clients, clients, wishing to use it must use
respective wrapper structures, they also must specify which channels they
require, as channels are hard-wired to specific IPU functions.
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      5296b56d
  39. 19 1月, 2009 3 次提交