1. 08 8月, 2008 6 次提交
  2. 05 8月, 2008 3 次提交
  3. 27 7月, 2008 2 次提交
  4. 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
  5. 25 7月, 2008 5 次提交
  6. 24 7月, 2008 1 次提交
  7. 22 7月, 2008 1 次提交
    • A
      sysdev: Pass the attribute to the low level sysdev show/store function · 4a0b2b4d
      Andi Kleen 提交于
      This allow to dynamically generate attributes and share show/store
      functions between attributes. Right now most attributes are generated
      by special macros and lots of duplicated code. With the attribute
      passed it's instead possible to attach some data to the attribute
      and then use that in shared low level functions to do different things.
      
      I need this for the dynamically generated bank attributes in the x86
      machine check code, but it'll allow some further cleanups.
      
      I converted all users in tree to the new show/store prototype. It's a single
      huge patch to avoid unbisectable sections.
      
      Runtime tested: x86-32, x86-64
      Compiled only: ia64, powerpc
      Not compile tested/only grep converted: sh, arm, avr32
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4a0b2b4d
  8. 19 7月, 2008 1 次提交
    • T
      nohz: prevent tick stop outside of the idle loop · b8f8c3cf
      Thomas Gleixner 提交于
      Jack Ren and Eric Miao tracked down the following long standing
      problem in the NOHZ code:
      
      	scheduler switch to idle task
      	enable interrupts
      
      Window starts here
      
      	----> interrupt happens (does not set NEED_RESCHED)
      	      	irq_exit() stops the tick
      
      	----> interrupt happens (does set NEED_RESCHED)
      
      	return from schedule()
      	
      	cpu_idle(): preempt_disable();
      
      Window ends here
      
      The interrupts can happen at any point inside the race window. The
      first interrupt stops the tick, the second one causes the scheduler to
      rerun and switch away from idle again and we end up with the tick
      disabled.
      
      The fact that it needs two interrupts where the first one does not set
      NEED_RESCHED and the second one does made the bug obscure and extremly
      hard to reproduce and analyse. Kudos to Jack and Eric.
      
      Solution: Limit the NOHZ functionality to the idle loop to make sure
      that we can not run into such a situation ever again.
      
      cpu_idle()
      {
      	preempt_disable();
      
      	while(1) {
      		 tick_nohz_stop_sched_tick(1); <- tell NOHZ code that we
      		 			          are in the idle loop
      
      		 while (!need_resched())
      		       halt();
      
      		 tick_nohz_restart_sched_tick(); <- disables NOHZ mode
      		 preempt_enable_no_resched();
      		 schedule();
      		 preempt_disable();
      	}
      }
      
      In hindsight we should have done this forever, but ... 
      
      /me grabs a large brown paperbag.
      
      Debugged-by: Jack Ren <jack.ren@marvell.com>, 
      Debugged-by: Neric miao <eric.y.miao@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b8f8c3cf
  9. 18 7月, 2008 3 次提交
    • H
      fix core/stacktrace changes on avr32, mips, sh · 8b95d917
      Heiko Carstens 提交于
      Fixes this type of problem:
      
        CC      arch/s390/kernel/stacktrace.o
      arch/s390/kernel/stacktrace.c:84: warning: data definition has no type or storage class
      arch/s390/kernel/stacktrace.c:84: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/s390/kernel/stacktrace.c:84: warning: parameter names (without types) in function declaration
      arch/s390/kernel/stacktrace.c:97: warning: data definition has no type or storage class
      arch/s390/kernel/stacktrace.c:97: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
      arch/s390/kernel/stacktrace.c:97: warning: parameter names (without types) in function declaration
      
      caused by "stacktrace: export save_stack_trace[_tsk]"
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8b95d917
    • B
      avr32: clean up mci platform code · fbfca4b8
      Ben Nizette 提交于
      This patch does a few small cleanups around the atmel mci platform code
      and in the atmel-mci driver.  The platform changes simply removes an
      unused variable, uses the fact that by the end we always have some form
      of platform data and notes that GPIO_PIN_NONE != 0.  This last point
      could cause the incorrect attempt to twice reserve pin PA0.
      
      While we've got the hood up, add linux/err.h to the atmel-mci.c include
      list.  It needs it and generally pulls it by voodoo but I did once
      stumble across a config which don't build.
      
      This is against Linus' latest git.
      Signed-off-by: NBen Nizette <bn@niasdigital.com>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      fbfca4b8
    • A
      fix avr32 build errors · 62fe8378
      Adrian Bunk 提交于
      Commit 7d2be074
      (atmel-mci: Driver for Atmel on-chip MMC controllers)
      causes build errors like:
      
      <--  snip  -->
      
      ...
        CC      arch/avr32/boards/atstk1000/atstk1003.o
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/avr32/boards/atstk1000/atstk1003.c: In function 'atstk1003_init':
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/avr32/boards/atstk1000/atstk1003.c:157: error: too few arguments to function 'at32_add_device_mci'
      make[2]: *** [arch/avr32/boards/atstk1000/atstk1003.o] Error 1
      
      <--  snip  -->
      Reported-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      62fe8378
  10. 15 7月, 2008 1 次提交
    • H
      atmel-mci: Driver for Atmel on-chip MMC controllers · 7d2be074
      Haavard Skinnemoen 提交于
      This is a driver for the MMC controller on the AP7000 chips from
      Atmel. It should in theory work on AT91 systems too with some
      tweaking, but since the DMA interface is quite different, it's not
      entirely clear if it's worth merging this with the at91_mci driver.
      
      This driver has been around for a while in BSPs and kernel sources
      provided by Atmel, but this particular version uses the generic DMA
      Engine framework (with the slave extensions) instead of an
      avr32-only DMA controller framework.
      
      This driver can also use PIO transfers when no DMA channels are
      available, and for transfers where using DMA may be difficult or
      impractical for some reason (e.g. the DMA setup overhead is usually
      not worth it for very short transfers, and badly aligned buffers or
      lengths are difficult to handle.)
      
      Currently, the driver only support PIO transfers. DMA support has been
      split out to a separate patch to hopefully make it easier to review.
      
      The driver has been tested using mmc-block and ext3fs on several SD,
      SDHC and MMC+ cards. Reads and writes work fine, with read transfer
      rates up to 3.5 MiB/s on fast cards with debugging disabled.
      
      The driver has also been tested using the mmc_test module on the same
      cards. All tests except 7, 9, 15 and 17 succeed. The first two are
      unsupported by all the cards I have, so I don't know if the driver
      handles this correctly. The last two fail because the hardware flags a
      Data CRC Error instead of a Data Timeout error. I'm not sure how to deal
      with that.
      
      Documentation for this controller can be found in many data sheets from
      Atmel, including the AT32AP7000 data sheet which can be found here:
      
      http://www.atmel.com/dyn/products/datasheets.asp?family_id=682Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      7d2be074
  11. 09 7月, 2008 1 次提交
    • H
      dmaengine: Driver for the Synopsys DesignWare DMA controller · 3bfb1d20
      Haavard Skinnemoen 提交于
      This adds a driver for the Synopsys DesignWare DMA controller (aka
      DMACA on AVR32 systems.) This DMA controller can be found integrated
      on the AT32AP7000 chip and is primarily meant for peripheral DMA
      transfer, but can also be used for memory-to-memory transfers.
      
      This patch is based on a driver from David Brownell which was based on
      an older version of the DMA Engine framework. It also implements the
      proposed extensions to the DMA Engine API for slave DMA operations.
      
      The dmatest client shows no problems, but there may still be room for
      improvement performance-wise. DMA slave transfer performance is
      definitely "good enough"; reading 100 MiB from an SD card running at ~20
      MHz yields ~7.2 MiB/s average transfer rate.
      
      Full documentation for this controller can be found in the Synopsys
      DW AHB DMAC Databook:
      
      http://www.synopsys.com/designware/docs/iip/DW_ahb_dmac/latest/doc/dw_ahb_dmac_db.pdf
      
      The controller has lots of implementation options, so it's usually a
      good idea to check the data sheet of the chip it's intergrated on as
      well. The AT32AP7000 data sheet can be found here:
      
      http://www.atmel.com/dyn/products/datasheets.asp?family_id=682
      
      
      Changes since v4:
        * Use client_count instead of dma_chan_is_in_use()
        * Add missing include
        * Unmap buffers unless client told us not to
      
      Changes since v3:
        * Update to latest DMA engine and DMA slave APIs
        * Embed the hw descriptor into the sw descriptor
        * Clean up and update MODULE_DESCRIPTION, copyright date, etc.
      
      Changes since v2:
        * Dequeue all pending transfers in terminate_all()
        * Rename dw_dmac.h -> dw_dmac_regs.h
        * Define and use controller-specific dma_slave data
        * Fix up a few outdated comments
        * Define hardware registers as structs (doesn't generate better
          code, unfortunately, but it looks nicer.)
        * Get number of channels from platform_data instead of hardcoding it
          based on CONFIG_WHATEVER_CPU.
        * Give slave clients exclusive access to the channel
      
      Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>,
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3bfb1d20
  12. 04 7月, 2008 1 次提交
  13. 03 7月, 2008 1 次提交
  14. 02 7月, 2008 9 次提交
  15. 28 6月, 2008 2 次提交
  16. 27 6月, 2008 1 次提交