1. 07 8月, 2008 1 次提交
  2. 27 7月, 2008 1 次提交
  3. 26 7月, 2008 1 次提交
    • D
      gpio: sysfs interface · d8f388d8
      David Brownell 提交于
      This adds a simple sysfs interface for GPIOs.
      
          /sys/class/gpio
          	/export ... asks the kernel to export a GPIO to userspace
          	/unexport ... to return a GPIO to the kernel
              /gpioN ... for each exported GPIO #N
      	    /value ... always readable, writes fail for input GPIOs
      	    /direction ... r/w as: in, out (default low); write high, low
      	/gpiochipN ... for each gpiochip; #N is its first GPIO
      	    /base ... (r/o) same as N
      	    /label ... (r/o) descriptive, not necessarily unique
      	    /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
      
      GPIOs claimed by kernel code may be exported by its owner using a new
      gpio_export() call, which should be most useful for driver debugging.
      Such exports may optionally be done without a "direction" attribute.
      
      Userspace may ask to take over a GPIO by writing to a sysfs control file,
      helping to cope with incomplete board support or other "one-off"
      requirements that don't merit full kernel support:
      
        echo 23 > /sys/class/gpio/export
      	... will gpio_request(23, "sysfs") and gpio_export(23);
      	use /sys/class/gpio/gpio-23/direction to (re)configure it,
      	when that GPIO can be used as both input and output.
        echo 23 > /sys/class/gpio/unexport
      	... will gpio_free(23), when it was exported as above
      
      The extra D-space footprint is a few hundred bytes, except for the sysfs
      resources associated with each exported GPIO.  The additional I-space
      footprint is about two thirds of the current size of gpiolib (!).  Since
      no /dev node creation is involved, no "udev" support is needed.
      
      Related changes:
      
        * This adds a device pointer to "struct gpio_chip".  When GPIO
          providers initialize that, sysfs gpio class devices become children of
          that device instead of being "virtual" devices.
      
        * The (few) gpio_chip providers which have such a device node have
          been updated.
      
        * Some gpio_chip drivers also needed to update their module "owner"
          field ...  for which missing kerneldoc was added.
      
        * Some gpio_chips don't support input GPIOs.  Those GPIOs are now
          flagged appropriately when the chip is registered.
      
      Based on previous patches, and discussion both on and off LKML.
      
      A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
      merges to mainline.
      
      [akpm@linux-foundation.org: a few maintenance build fixes]
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d8f388d8
  4. 25 7月, 2008 2 次提交
  5. 22 7月, 2008 2 次提交
  6. 03 7月, 2008 12 次提交
  7. 06 6月, 2008 1 次提交
  8. 22 5月, 2008 1 次提交
    • R
      [ARM] omap: fix omap clk support build errors · b851cb28
      Russell King 提交于
      arch/arm/plat-omap/clock.c:397: warning: "struct cpufreq_frequency_table" declared inside parameter list
      arch/arm/plat-omap/clock.c:397: warning: its scope is only this definition or declaration, which is probably not what you want
      arch/arm/plat-omap/clock.c: In function `clk_init_cpufreq_table':
      arch/arm/plat-omap/clock.c:402: error: structure has no member named `clk_init_cpufreq_table'
      arch/arm/plat-omap/clock.c:403: error: structure has no member named `clk_init_cpufreq_table'
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b851cb28
  9. 10 5月, 2008 3 次提交
  10. 19 4月, 2008 1 次提交
  11. 15 4月, 2008 12 次提交
  12. 20 3月, 2008 3 次提交