1. 15 2月, 2009 1 次提交
    • A
      [ARM] 5390/1: AT91: Watchdog fixes · 2af29b78
      Andrew Victor 提交于
      The recently merged AT91SAM9 watchdog driver uses the
      AT91SAM9X_WATCHDOG config variable, whereas the original version of
      the driver (and the platform support code) used AT91SAM9_WATCHDOG.
      This causes the watchdog platform_device to never be registered, and
      therefore the driver not to be initialized.
      
      This patch:
      - updates the platform support code to use AT91SAM9X_WATCHDOG.
      - includes <linux/io.h> to fix compile error (same fix as was applied
      to at91rm9200_wdt.c)
      - fixes comment regarding watchdog clock-rates in at91rm9200.
      Signed-off-by: NAndrew Victor <linux@maxim.org.za>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2af29b78
  2. 14 2月, 2009 2 次提交
  3. 10 2月, 2009 1 次提交
  4. 03 2月, 2009 1 次提交
  5. 31 1月, 2009 3 次提交
  6. 30 1月, 2009 8 次提交
  7. 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
  8. 28 1月, 2009 3 次提交
  9. 27 1月, 2009 1 次提交
  10. 26 1月, 2009 2 次提交
  11. 25 1月, 2009 1 次提交
  12. 24 1月, 2009 3 次提交
  13. 22 1月, 2009 1 次提交
  14. 21 1月, 2009 1 次提交
  15. 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
  16. 19 1月, 2009 3 次提交
  17. 15 1月, 2009 7 次提交