1. 20 6月, 2006 3 次提交
  2. 18 6月, 2006 1 次提交
  3. 09 6月, 2006 1 次提交
  4. 06 6月, 2006 1 次提交
  5. 18 5月, 2006 1 次提交
  6. 06 5月, 2006 1 次提交
  7. 19 4月, 2006 1 次提交
  8. 03 4月, 2006 1 次提交
  9. 01 4月, 2006 3 次提交
  10. 29 3月, 2006 1 次提交
  11. 28 3月, 2006 1 次提交
  12. 27 3月, 2006 1 次提交
  13. 24 3月, 2006 1 次提交
  14. 22 3月, 2006 3 次提交
  15. 02 2月, 2006 1 次提交
  16. 14 1月, 2006 1 次提交
  17. 13 1月, 2006 1 次提交
  18. 09 1月, 2006 1 次提交
    • R
      [PATCH] IRQ type flags · 9ded96f2
      Russell King 提交于
      Some ARM platforms have the ability to program the interrupt controller to
      detect various interrupt edges and/or levels.  For some platforms, this is
      critical to setup correctly, particularly those which the setting is dependent
      on the device.
      
      Currently, ARM drivers do (eg) the following:
      
      	err = request_irq(irq, ...);
      
      	set_irq_type(irq, IRQT_RISING);
      
      However, if the interrupt has previously been programmed to be level sensitive
      (for whatever reason) then this will cause an interrupt storm.
      
      Hence, if we combine set_irq_type() with request_irq(), we can then safely set
      the type prior to unmasking the interrupt.  The unfortunate problem is that in
      order to support this, these flags need to be visible outside of the ARM
      architecture - drivers such as smc91x need these flags and they're
      cross-architecture.
      
      Finally, the SA_TRIGGER_* flag passed to request_irq() should reflect the
      property that the device would like.  The IRQ controller code should do its
      best to select the most appropriate supported mode.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9ded96f2
  19. 07 1月, 2006 1 次提交
  20. 06 1月, 2006 8 次提交
  21. 05 1月, 2006 1 次提交
  22. 13 12月, 2005 1 次提交
    • L
      [ARM] 3201/1: PXA27x: Prevent hangup during resume due to inadvertedly... · 1ee9530a
      Lothar Wassmann 提交于
      [ARM] 3201/1: PXA27x: Prevent hangup during resume due to inadvertedly enabling MBREQ (replaces: 3198/1)
      
      Patch from Lothar Wassmann
      
      The patch makes sure, that the ouptut functions of pins are restored
      before restoring the Alternat Function settings, preventing pins from
      being intermediately configured for undefined or unwanted alternate
      functions.
      
      Here is the original comment:
      I've got a PXA270 system that uses GPIO80 as nCS4. This system did
      hang on resume. Digging into the problem I found that the processor
      stalled immediately when restoring the GAFR2_U register which restored
      the alternate function for GPIO80. Since the GPDR registers were
      restored after the GAFR registers, the offending GPIO was configured
      as input at this point.
      Thus the alternate function that was in effect after restoring the
      GAFR was in fact the input function "MBREQ" instead of the output
      function "nCS4". The "PXA27x Processor Family Developer's Manual"
      (Footnote in Table 6-1 on page 6-3) states that:
      "The MBREQ alternate function must not be enabled until the PSSR[RDH]
      bit field is cleared. For more details, see Table 3-15, "PSSR Bit
      Definitions" on page 3-71."
      
      There is another note in the Developer's Manual (chapter 24.4.2
      "GPIO operation as Alternate Function" on page 24-4)
      stating that:
      "Configuring a GPIO for an alternate function that is not defined for
      it causes unpredictable results."
      
      Since some GPIOs have no input function defined, and to prevent
      inadvertedly programming the MBREQ function on some pin, the GAFR
      registers should be restored after the GPDR registers have been
      restored.
      
      Additional provisions have to be made when the MBREQ function is
      actually required. The corresponding GAFR bits should not be restored
      with the regular GAFR restore, but must be set only after the PSSR
      bits have been cleared.
      Signed-off-by: NLothar Wassmann <LW@KARO-electronics.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ee9530a
  23. 01 12月, 2005 1 次提交
  24. 29 11月, 2005 1 次提交
  25. 21 11月, 2005 1 次提交
  26. 16 11月, 2005 1 次提交
  27. 13 11月, 2005 1 次提交
    • R
      [ARM] 3160/1: SharpSL: Add driver for Akita specific GPIOs · bd5d080a
      Richard Purdie 提交于
      Patch from Richard Purdie
      
      Add a driver for the extra GPIOs found on the Sharp SL-C1000 (Akita).
      These GPIOs are found on a Maxim MAX7310 I2C i/o expander chip. A
      generic GPIO driver for the MAX7310 was attempted but this mini
      driver is a much simpler and much more effective solution avoiding
      several issues and complexity the generic driver had (as discussed
      on LKML).
      
      The platform device is required so the device parent can be set
      correctly which ensures the device is one of the last to suspend
      and first to resume. Whilst the i2c suspend/resume calls can be
      influenced, nothing guarantees this is easlier/later than the
      subsystems the gpios are used on which are all independent of i2c
      (sound, irda, video/backlight etc.).
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bd5d080a