1. 11 Dec, 2009 1 commit
  2. 17 Nov, 2009 1 commit
  3. 14 Nov, 2009 1 commit
  4. 23 Sep, 2009 1 commit
  5. 21 Sep, 2009 1 commit
  6. 19 Sep, 2009 1 commit
  7. 23 Jun, 2009 2 commits
    • Trent Piepho's avatar
      leds: Add options to have GPIO LEDs start on or keep their state · ed88bae6
      Trent Piepho authored
      
      
      There already is a "default-on" trigger but there are problems with it.
      
      For one, it's a inefficient way to do it and requires led trigger support
      to be compiled in.
      
      But the real reason is that is produces a glitch on the LED.  The GPIO is
      allocate with the LED *off*, then *later* when the trigger runs it is
      turned back on.  If the LED was already on via the GPIO's reset default or
      action of the firmware, this produces a glitch where the LED goes from on
      to off to on.  While normally this is fast enough that it wouldn't be
      noticeable to a human observer, there are still serious problems.
      
      One is that there may be something else on the GPIO line, like a hardware
      alarm or watchdog, that is fast enough to notice the glitch.
      
      Another is that the kernel may panic before the LED is turned back on, thus
      hanging with the LED in the wrong state.  This is not just speculation, but
      actually happened to me with an embedded system that has an LED which
      should turn off when the kernel finishes booting, which was left in the
      incorrect state due to a bug in the OF LED binding code.
      
      We also let GPIO LEDs get their initial value from whatever the current
      state of the GPIO line is.  On some systems the LEDs are put into some
      state by the firmware or hardware before Linux boots, and it is desired to
      have them keep this state which is otherwise unknown to Linux.
      
      This requires that the underlying GPIO driver support reading the value of
      output GPIOs.  Some drivers support this and some do not.
      
      The platform device binding gains a field in the platform data
      "default_state" that controls this.  There are three constants defined to
      select from on, off, or keeping the current state.  The OpenFirmware
      binding uses a property named "default-state" that can be set to "on",
      "off", or "keep".  The default if the property isn't present is off.
      Signed-off-by: default avatarTrent Piepho <xyzzy@speakeasy.org>
      Acked-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Acked-by: default avatarWolfram Sang <w.sang@pengutronix.de>
      Acked-by: default avatarSean MacLennan <smaclennan@pikatech.com>
      Signed-off-by: default avatarRichard Purdie <rpurdie@linux.intel.com>
      ed88bae6
    • Kumar Gala's avatar
      powerpc: Refactor device tree binding · b053dc5a
      Kumar Gala authored
      
      
      Split device tree binding out of booting-without-of.txt and put them
      into their own files per binding.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      b053dc5a
  8. 21 Jun, 2009 1 commit
  9. 12 Jun, 2009 2 commits
  10. 01 Jun, 2009 1 commit
    • Wolfgang Grandegger's avatar
      can: sja1000: generic OF platform bus driver · d1a277c5
      Wolfgang Grandegger authored
      
      
      This patch adds a generic driver for SJA1000 chips on the OpenFirmware
      platform bus found on embedded PowerPC systems. You need a SJA1000 node
      definition in your flattened device tree source (DTS) file similar to:
      
        can@3,100 {
        	compatible = "nxp,sja1000";
        	reg = <3 0x100 0x80>;
        	interrupts = <2 0>;
        	interrupt-parent = <&mpic>;
        	nxp,external-clock-frequency = <16000000>;
        };
      
      See also Documentation/powerpc/dts-bindings/can/sja1000.txt.
      
      CC: devicetree-discuss@ozlabs.org
      Signed-off-by: Wolfgang Grandegger's avatarWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1a277c5
  11. 19 May, 2009 5 commits
  12. 16 Apr, 2009 2 commits
  13. 08 Apr, 2009 1 commit
  14. 06 Apr, 2009 2 commits
  15. 01 Apr, 2009 1 commit
  16. 30 Mar, 2009 1 commit
  17. 27 Mar, 2009 1 commit
  18. 09 Mar, 2009 1 commit
  19. 06 Feb, 2009 1 commit
  20. 05 Feb, 2009 1 commit
  21. 30 Jan, 2009 1 commit
  22. 29 Jan, 2009 1 commit
  23. 05 Jan, 2009 1 commit
  24. 30 Dec, 2008 1 commit
  25. 16 Dec, 2008 1 commit
  26. 21 Oct, 2008 1 commit
  27. 13 Oct, 2008 2 commits
  28. 23 Sep, 2008 1 commit
  29. 17 Sep, 2008 1 commit
  30. 28 Jul, 2008 1 commit
  31. 16 Jul, 2008 1 commit