07 Jan, 2009

2 commits


01 Jan, 2009

1 commit


20 Oct, 2008

1 commit

  • 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: Cedric Le Goater
    Signed-off-by: Matt Helsley
    Acked-by: Pavel Machek
    Acked-by: Serge E. Hallyn
    Acked-by: Rafael J. Wysocki
    Acked-by: Nigel Cunningham
    Tested-by: Matt Helsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Helsley
     

16 Oct, 2008

1 commit


14 Oct, 2008

1 commit



09 Oct, 2008

1 commit


06 Oct, 2008

3 commits

  • 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: Haavard Skinnemoen

    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: Haavard Skinnemoen

    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: Haavard Skinnemoen

    Haavard Skinnemoen
     

22 Sep, 2008

1 commit


07 Sep, 2008

1 commit


05 Aug, 2008

2 commits