1. 14 10月, 2008 3 次提交
  2. 08 10月, 2008 1 次提交
  3. 03 10月, 2008 1 次提交
  4. 24 9月, 2008 2 次提交
  5. 09 9月, 2008 3 次提交
  6. 05 9月, 2008 1 次提交
    • M
      i2c: fix i2c-sh_mobile timing issues · 4eb00c9f
      Magnus Damm 提交于
      This patch teaches the i2c-sh_mobile driver to make use of wait irqs.
      Without this patch only dte irqs are used which may lead to overruns
      and cases of missing stop and extra bytes being read on the i2c bus.
      
      Use of wait irqs forces the hardware to pause and wait until the cpu
      is ready. Polling is also reworked in this patch to fix ms delay issues.
      
      Verified with bus analyzer and tested on MigoR and AP325RXA boards.
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      4eb00c9f
  7. 28 8月, 2008 2 次提交
  8. 24 8月, 2008 1 次提交
  9. 14 8月, 2008 1 次提交
  10. 11 8月, 2008 5 次提交
  11. 07 8月, 2008 3 次提交
  12. 28 7月, 2008 4 次提交
  13. 26 7月, 2008 2 次提交
    • M
      gpiolib: allow user-selection · 7444a72e
      Michael Buesch 提交于
      This patch adds functionality to the gpio-lib subsystem to make it
      possible to enable the gpio-lib code even if the architecture code didn't
      request to get it built in.
      
      The archtitecture code does still need to implement the gpiolib accessor
      functions in its asm/gpio.h file.  This patch adds the implementations for
      x86 and PPC.
      
      With these changes it is possible to run generic GPIO expansion cards on
      every architecture that implements the trivial wrapper functions.  Support
      for more architectures can easily be added.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Samuel Ortiz <sameo@openedhand.com>
      Cc: Kumar Gala <galak@gate.crashing.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7444a72e
    • 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
  14. 22 7月, 2008 2 次提交
  15. 17 7月, 2008 7 次提交
  16. 15 7月, 2008 2 次提交
    • J
      i2c: Add detection capability to new-style drivers · 4735c98f
      Jean Delvare 提交于
      Add a mechanism to let new-style i2c drivers optionally autodetect
      devices they would support on selected buses and ask i2c-core to
      instantiate them. This is a replacement for legacy i2c drivers, much
      cleaner.
      
      Where drivers had to implement both a legacy i2c_driver and a
      new-style i2c_driver so far, this mechanism makes it possible to get
      rid of the legacy i2c_driver and implement both enumerated and
      detected device support with just one (new-style) i2c_driver.
      
      Here is a quick conversion guide for these drivers, step by step:
      
      * Delete the legacy driver definition, registration and removal.
        Delete the attach_adapter and detach_client methods of the legacy
        driver.
      
      * Change the prototype of the legacy detect function from
          static int foo_detect(struct i2c_adapter *adapter, int address, int kind);
        to
          static int foo_detect(struct i2c_client *client, int kind,
          			  struct i2c_board_info *info);
      
      * Set the new-style driver detect callback to this new function, and
        set its address_data to &addr_data (addr_data is generally provided
        by I2C_CLIENT_INSMOD.)
      
      * Add the appropriate class to the new-style driver. This is
        typically the class the legacy attach_adapter method was checking
        for. Class checking is now mandatory (done by i2c-core.) See
        <linux/i2c.h> for the list of available classes.
      
      * Remove the i2c_client allocation and freeing from the detect
        function. A pre-allocated client is now handed to you by i2c-core,
        and is freed automatically.
      
      * Make the detect function fill the type field of the i2c_board_info
        structure it was passed as a parameter, and return 0, on success. If
        the detection fails, return -ENODEV.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      4735c98f
    • J
      i2c: Call client_unregister for new-style devices too · 8508159e
      Jean Delvare 提交于
      We call adapter->client_register for both legacy and new-style i2c
      devices, however we only call adapter->client_unregister for legacy
      drivers. This doesn't make much sense. Usually, drivers will undo
      in client_unregister what they did in client_register, so we should
      call neither or both for every given i2c device.
      
      In order to ease the transition from legacy to new-style devices, it
      seems preferable to actually call both.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: David Brownell <david-b@pacbell.net>
      8508159e