1. 05 1月, 2009 5 次提交
    • A
      avr32: Hammerhead board support · dd5e1339
      Alex Raimondi 提交于
      The Hammerhead platform is built around a AVR32 32-bit microcontroller
      from Atmel.  It offers versatile peripherals, such as ethernet, usb
      device, usb host etc.
      
      The board also incooperates a power supply and is a Power over Ethernet
      (PoE) Powered Device (PD).
      
      Additonally, a Cyclone III FPGA from Altera is integrated on the board.
      The FPGA is mapped into the 32-bit AVR memory bus. The FPGA offers two
      DDR2 SDRAM interfaces, which will cover even the most exceptional need
      of memory bandwidth. Together with the onboard video decoder the board
      is ready for video processing.
      
      This patch does include the basic support for the fpga device driver,
      but not the device driver itself.
      Signed-off-by: NAlex Raimondi <mailinglist@miromico.ch>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      dd5e1339
    • A
      avr32: Allow reserving multiple pins at once · adde42b5
      Alex Raimondi 提交于
      at32_reserve_pin now takes an u32 bitmask rather than a single pin.
      This allows to reserve multiple pins at once.
      
      Remove (undocumented) SDCS (pin PE26) from reservation in board
      setup code.
      Signed-off-by: NAlex Raimondi <raimondi@miromico.ch>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      adde42b5
    • H
      favr-32: Remove deprecated call · 45f92691
      Haavard Skinnemoen 提交于
      at32_add_system_devices() is deprecated, so remove the call to it.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      45f92691
    • M
      MIMC200: Remove deprecated call · 8d3d3fb9
      Mark Jackson 提交于
      This patch removes a call to the deprecated function
      at32_add_system_devices().
      Signed-off-by: NMark Jackson <mpfj@mimc.co.uk>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      8d3d3fb9
    • K
      avr: struct device - replace bus_id with dev_name(), dev_set_name() · 5f6333bd
      Kay Sievers 提交于
      (I did not compile or test it, please let me know, or help fixing
       it, if something is wrong with the conversion)
      
      This patch is part of a larger patch series which will remove
      the "char bus_id[20]" name string from struct device. The device
      name is managed in the kobject anyway, and without any size
      limitation, and just needlessly copied into "struct device".
      
      To set and read the device name dev_name(dev) and dev_set_name(dev)
      must be used. If your code uses static kobjects, which it shouldn't
      do, "const char *init_name" can be used to statically provide the
      name the registered device should have. At registration time, the
      init_name field is cleared, to enforce the use of dev_name(dev) to
      access the device name at a later time.
      
      We need to get rid of all occurrences of bus_id in the entire tree
      to be able to enable the new interface. Please apply this patch,
      and possibly convert any remaining remaining occurrences of bus_id.
      
      We want to submit a patch to -next, which will remove bus_id from
      "struct device", to find the remaining pieces to convert, and finally
      switch over to the new api, which will remove the 20 bytes array
      and does no longer have a size limitation.
      
      Thanks,
      Kay
      
      From: Kay Sievers <kay.sievers@vrfy.org>
      Subject: avr: struct device - replace bus_id with dev_name(), dev_set_name()
      
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      5f6333bd
  2. 18 12月, 2008 2 次提交
  3. 17 12月, 2008 2 次提交
  4. 24 10月, 2008 1 次提交
  5. 23 10月, 2008 3 次提交
  6. 20 10月, 2008 2 次提交
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
    • M
      container freezer: add TIF_FREEZE flag to all architectures · 83224b08
      Matt Helsley 提交于
      This patch series introduces a cgroup subsystem that utilizes the swsusp
      freezer to freeze a group of tasks.  It's immediately useful for batch job
      management scripts.  It should also be useful in the future for
      implementing container checkpoint/restart.
      
      The freezer subsystem in the container filesystem defines a cgroup file
      named freezer.state.  Reading freezer.state will return the current state
      of the cgroup.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This patch:
      
      The first step in making the refrigerator() available to all
      architectures, even for those without power management.
      
      The purpose of such a change is to be able to use the refrigerator() in a
      new control group subsystem which will implement a control group freezer.
      
      [akpm@linux-foundation.org: fix sparc]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@tuxonice.net>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83224b08
  7. 16 10月, 2008 3 次提交
  8. 14 10月, 2008 1 次提交
  9. 13 10月, 2008 6 次提交
  10. 12 10月, 2008 2 次提交
  11. 09 10月, 2008 2 次提交
  12. 06 10月, 2008 4 次提交
    • H
      atmel-mci: Add experimental DMA support · 65e8b083
      Haavard Skinnemoen 提交于
      This adds support for DMA transfers through the generic DMA engine
      framework with the DMA slave extensions.
      
      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 7.5 MiB/s on fast cards with debugging disabled.
      
      Unfortunately, the driver has been known to lock up from time to time
      with DMA enabled, so DMA support is currently optional and marked
      EXPERIMENTAL. However, I didn't see any problems while testing 13
      different cards (MMC, SD and SDHC of different brands and sizes), so I
      suspect the "Initialize BLKR before sending data transfer command" fix
      that was posted earlier fixed this as well.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      65e8b083
    • H
      atmel-mci: support multiple mmc slots · 965ebf33
      Haavard Skinnemoen 提交于
      The Atmel MCI controller can drive multiple cards through separate sets
      of pins, but only one at a time. This patch adds support for
      multiplexing access to the controller so that multiple card slots can be
      used as if they were hooked up to separate mmc controllers.
      
      The atmel-mci driver registers each slot as a separate mmc_host. Both
      access the same common controller state, but they also have some state
      on their own for card detection/write protect handling, and separate
      shadows of the MR and SDCR registers.
      
      When one of the slots receives a request from the mmc core, the common
      controller state is checked. If it's idle, the request is submitted
      immediately. If not, the request is added to a queue. When a request is
      done, the queue is checked and if there is a queued request, it is
      submitted before the completion callback is called.
      
      This patch also includes a few cleanups and fixes, including a locking
      overhaul. I had to change the locking extensively in any case, so I
      might as well try to get it right. The driver no longer takes any
      irq-safe locks, which may or may not improve the overall system
      performance.
      
      This patch also adds a bit of documentation of the internal data
      structures.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      965ebf33
    • H
      atmel-mci: Platform code for supporting multiple mmc slots · 6b918657
      Haavard Skinnemoen 提交于
      Add the necessary platform infrastructure to support multiple mmc/sdcard
      slots all at once through a single controller. Currently, the driver
      will use the first valid slot it finds and stick with that, but later
      patches will add support for switching between several slots on the fly.
      
      Extend the platform data structure with per-slot information: MMC/SDcard
      bus width and card detect/write protect pins. This will affect the pin
      muxing as well as the capabilities announced to the mmc core.
      
      Note that board code is now required to supply a mci_platform_data
      struct to at32_add_device_mci().
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      6b918657
    • A
      avr32: Replace static clock list with dynamic linked list · 300bb762
      Alex Raimondi 提交于
      This replaces the at32_clock_list array with a linked list.
      Clocks can now be registered (added) to the list.
      Signed-off-by: NAlex Raimondi <raimondi@miromico.ch>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      300bb762
  13. 22 9月, 2008 7 次提交