1. 13 10月, 2011 1 次提交
    • L
      drivers: create a pin control subsystem · 2744e8af
      Linus Walleij 提交于
      This creates a subsystem for handling of pin control devices.
      These are devices that control different aspects of package
      pins.
      
      Currently it handles pinmuxing, i.e. assigning electronic
      functions to groups of pins on primarily PGA and BGA type of
      chip packages which are common in embedded systems.
      
      The plan is to also handle other I/O pin control aspects
      such as biasing, driving, input properties such as
      schmitt-triggering, load capacitance etc within this
      subsystem, to remove a lot of ARM arch code as well as
      feature-creepy GPIO drivers which are implementing the same
      thing over and over again.
      
      This is being done to depopulate the arch/arm/* directory
      of such custom drivers and try to abstract the infrastructure
      they all need. See the Documentation/pinctrl.txt file that is
      part of this patch for more details.
      
      ChangeLog v1->v2:
      
      - Various minor fixes from Joe's and Stephens review comments
      - Added a pinmux_config() that can invoke custom configuration
        with arbitrary data passed in or out to/from the pinmux driver
      
      ChangeLog v2->v3:
      
      - Renamed subsystem folder to "pinctrl" since we will likely
        want to keep other pin control such as biasing in this
        subsystem too, so let us keep to something generic even though
        we're mainly doing pinmux now.
      - As a consequence, register pins as an abstract entity separate
        from the pinmux. The muxing functions will claim pins out of the
        pin pool and make sure they do not collide. Pins can now be
        named by the pinctrl core.
      - Converted the pin lookup from a static array into a radix tree,
        I agreed with Grant Likely to try to avoid any static allocation
        (which is crap for device tree stuff) so I just rewrote this
        to be dynamic, just like irq number descriptors. The
        platform-wide definition of number of pins goes away - this is
        now just the sum total of the pins registered to the subsystem.
      - Make sure mappings with only a function name and no device
        works properly.
      
      ChangeLog v3->v4:
      
      - Define a number space per controller instead of globally,
        Stephen and Grant requested the same thing so now maps need to
        define target controller, and the radix tree of pin descriptors
        is a property on each pin controller device.
      - Add a compulsory pinctrl device entry to the pinctrl mapping
        table. This must match the pinctrl device, like "pinctrl.0"
      - Split the file core.c in two: core.c and pinmux.c where the
        latter carry all pinmux stuff, the core is for generic pin
        control, and use local headers to access functionality between
        files. It is now possible to implement a "blank" pin controller
        without pinmux capabilities. This split will make new additions
        like pindrive.c, pinbias.c etc possible for combined drivers
        and chunks of functionality which is a GoodThing(TM).
      - Rewrite the interaction with the GPIO subsystem - the pin
        controller descriptor now handles this by defining an offset
        into the GPIO numberspace for its handled pin range. This is
        used to look up the apropriate pin controller for a GPIO pin.
        Then that specific GPIO range is matched 1-1 for the target
        controller instance.
      - Fixed a number of review comments from Joe Perches.
      - Broke out a header file pinctrl.h for the core pin handling
        stuff that will be reused by other stuff than pinmux.
      - Fixed some erroneous EXPORT() stuff.
      - Remove mispatched U300 Kconfig and Makefile entries
      - Fixed a number of review comments from Stephen Warren, not all
        of them - still WIP. But I think the new mapping that will
        specify which function goes to which pin mux controller address
        50% of your concerns (else beat me up).
      
      ChangeLog v4->v5:
      
      - Defined a "position" for each function, so the pin controller now
        tracks a function in a certain position, and the pinmux maps define
        what position you want the function in. (Feedback from Stephen
        Warren and Sascha Hauer).
      - Since we now need to request a combined function+position from
        the machine mapping table that connect mux settings to drivers,
        it was extended with a position field and a name field. The
        name field is now used if you e.g. need to switch between two
        mux map settings at runtime.
      - Switched from a class device to using struct bus_type for this
        subsystem. Verified sysfs functionality: seems to work fine.
        (Feedback from Arnd Bergmann and Greg Kroah-Hartman)
      - Define a per pincontroller list of GPIO ranges from the GPIO
        pin space that can be handled by the pin controller. These can
        be added one by one at runtime. (Feedback from Barry Song)
      - Expanded documentation of regulator_[get|enable|disable|put]
        semantics.
      - Fixed a number of review comments from Barry Song. (Thanks!)
      
      ChangeLog v5->v6:
      
      - Create an abstract pin group concept that can sort pins into
        named and enumerated groups no matter what the use of these
        groups may be, one possible usecase is a group of pins being
        muxed in or so. The intention is however to also use these
        groups for other pin control activities.
      - Make it compulsory for pinmux functions to associate with
        at least one group, so the abstract pin group concept is used
        to define the groups of pins affected by a pinmux function.
        The pinmux driver interface has been altered so as to enforce
        a function to list applicable groups per function.
      - Provide an optional .group entry in the pinmux machine map
        so the map can select beteween different available groups
        to be used with a certain function.
      - Consequent changes all over the place so that e.g. debugfs
        present reasonable information about the world.
      - Drop the per-pin mux (*config) function in the pinmux_ops
        struct - I was afraid that this would start to be used for
        things totally unrelated to muxing, we can introduce that to
        the generic struct pinctrl_ops if needed. I want to keep
        muxing orthogonal to other pin control subjects and not mix
        these things up.
      
      ChangeLog v6->v7:
      
      - Make it possible to have several map entries matching the
        same device, pin controller and function, but using
        a different group, and alter the semantics so that
        pinmux_get() will pick all matching map entries, and
        store the associated groups in a list. The list will
        then be iterated over at pinmux_enable()/pinmux_disable()
        and corresponding driver functions called for each
        defined group. Notice that you're only allowed to map
        multiple *groups* to the same
        { device, pin controller, function } triplet, attempts
        to map the same device to multiple pin controllers will
        for example fail. This is hopefully the crucial feature
        requested by Stephen Warren.
      - Add a pinmux hogging field to the pinmux mapping entries,
        and enable the pinmux core to hog pinmux map entries.
        This currently only works for pinmuxes without assigned
        devices as it looks now, but with device trees we can
        look up the corresponding struct device * entries when
        we register the pinmux driver, and have it hog each
        pinmux map in turn, for a simple approach to
        non-dynamic pin muxing. This addresses an issue from
        Grant Likely that the machine should take care of as
        much of the pinmux setup as possible, not the devices.
        By supplying a list of hogs, it can now instruct the
        core to take care of any static mappings.
      - Switch pinmux group retrieveal function to grab an
        array of strings representing the groups rather than an
        array of unsigned and rewrite accordingly.
      - Alter debugfs to show the grouplist handled by each
        pinmux. Also add a list of hogs.
      - Dynamically allocate a struct pinmux at pinmux_get() and
        free it at pinmux_put(), then add these to the global
        list of pinmuxes active as we go along.
      - Go over the list of pinmux maps at pinmux_get() time
        and repeatedly apply matches.
      - Retrieve applicable groups per function from the driver
        as a string array rather than a unsigned array, then
        lookup the enumerators.
      - Make the device to pinmux map a singleton - only allow the
        mapping table to be registered once and even tag the
        registration function with __init so it surely won't be
        abused.
      - Create a separate debugfs file to view the pinmux map at
        runtime.
      - Introduce a spin lock to the pin descriptor struct, lock it
        when modifying pin status entries. Reported by Stijn Devriendt.
      - Fix up the documentation after review from Stephen Warren.
      - Let the GPIO ranges give names as const char * instead of some
        fixed-length string.
      - add a function to unregister GPIO ranges to mirror the
        registration function.
      - Privatized the struct pinctrl_device and removed it from the
        <linux/pinctrl/pinctrl.h> API, the drivers do not need to know
        the members of this struct. It is now in the local header
        "core.h".
      - Rename the concept of "anonymous" mux maps to "system" muxes
        and add convenience macros and documentation.
      
      ChangeLog v7->v8:
      
      - Delete the leftover pinmux_config() function from the
       <linux/pinctrl/pinmux.h> header.
      - Fix a race condition found by Stijn Devriendt in pin_request()
      
      ChangeLog v8->v9:
      
      - Drop the bus_type and the sysfs attributes and all, we're not on
        the clear about how this should be used for e.g. userspace
        interfaces so let us save this for the future.
      - Use the right name in MAINTAINERS, PIN CONTROL rather than
        PINMUX
      - Don't kfree() the device state holder, let the .remove() callback
        handle this.
      - Fix up numerous kerneldoc headers to have one line for the function
        description and more verbose documentation below the parameters
      
      ChangeLog v9->v10:
      - pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
        from Steven Rothwell
      - fix pinctrl_register error handling, folded in a patch from
        Axel Lin
      - Various fixes to documentation text so that it's consistent.
      - Removed pointless comment from drivers/Kconfig
      - Removed dependency on SYSFS since we removed the bus in
        v9.
      - Renamed hopelessly abbreviated pctldev_* functions to the
        more verbose pinctrl_dev_*
      - Drop mutex properly when looking up GPIO ranges
      - Return NULL instead of ERR_PTR() errors on registration of
        pin controllers, using cast pointers is fragile. We can
        live without the detailed error codes for sure.
      
      Cc: Stijn Devriendt <highguy@gmail.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NBarry Song <21cnbao@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      2744e8af
  2. 11 10月, 2011 1 次提交
  3. 02 10月, 2011 1 次提交
    • M
      PM: Introduce devfreq: generic DVFS framework with device-specific OPPs · a3c98b8b
      MyungJoo Ham 提交于
      With OPPs, a device may have multiple operable frequency and voltage
      sets. However, there can be multiple possible operable sets and a system
      will need to choose one from them. In order to reduce the power
      consumption (by reducing frequency and voltage) without affecting the
      performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
      scheme may be used.
      
      This patch introduces the DVFS capability to non-CPU devices with OPPs.
      DVFS is a techique whereby the frequency and supplied voltage of a
      device is adjusted on-the-fly. DVFS usually sets the frequency as low
      as possible with given conditions (such as QoS assurance) and adjusts
      voltage according to the chosen frequency in order to reduce power
      consumption and heat dissipation.
      
      The generic DVFS for devices, devfreq, may appear quite similar with
      /drivers/cpufreq.  However, cpufreq does not allow to have multiple
      devices registered and is not suitable to have multiple heterogenous
      devices with different (but simple) governors.
      
      Normally, DVFS mechanism controls frequency based on the demand for
      the device, and then, chooses voltage based on the chosen frequency.
      devfreq also controls the frequency based on the governor's frequency
      recommendation and let OPP pick up the pair of frequency and voltage
      based on the recommended frequency. Then, the chosen OPP is passed to
      device driver's "target" callback.
      
      When PM QoS is going to be used with the devfreq device, the device
      driver should enable OPPs that are appropriate with the current PM QoS
      requests. In order to do so, the device driver may call opp_enable and
      opp_disable at the notifier callback of PM QoS so that PM QoS's
      update_target() call enables the appropriate OPPs. Note that at least
      one of OPPs should be enabled at any time; be careful when there is a
      transition.
      Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Reviewed-by: NMike Turquette <mturquette@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      a3c98b8b
  4. 23 7月, 2011 1 次提交
    • O
      virtio: expose for non-virtualization users too · e7254219
      Ohad Ben-Cohen 提交于
      virtio has been so far used only in the context of virtualization,
      and the virtio Kconfig was sourced directly by the relevant arch
      Kconfigs when VIRTUALIZATION was selected.
      
      Now that we start using virtio for inter-processor communications,
      we need to source the virtio Kconfig outside of the virtualization
      scope too.
      
      Moreover, some architectures might use virtio for both virtualization
      and inter-processor communications, so directly sourcing virtio
      might yield unexpected results due to conflicting selections.
      
      The simple solution offered by this patch is to always source virtio's
      Kconfig in drivers/Kconfig, and remove it from the appropriate arch
      Kconfigs. Additionally, a virtio menu entry has been added so virtio
      drivers don't show up in the general drivers menu.
      
      This way anyone can use virtio, though it's arguably less accessible
      (and neat!) for virtualization users now.
      
      Note: some architectures (mips and sh) seem to have a VIRTUALIZATION
      menu merely for sourcing virtio's Kconfig, so that menu is removed too.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      e7254219
  5. 08 7月, 2011 1 次提交
    • T
      drivers/virt: introduce Freescale hypervisor management driver · 6db71994
      Timur Tabi 提交于
      Add the drivers/virt directory, which houses drivers that support
      virtualization environments, and add the Freescale hypervisor management
      driver.
      
      The Freescale hypervisor management driver provides several services to
      drivers and applications related to the Freescale hypervisor:
      
      1. An ioctl interface for querying and managing partitions
      
      2. A file interface to reading incoming doorbells
      
      3. An interrupt handler for shutting down the partition upon receiving the
         shutdown doorbell from a manager partition
      
      4. A kernel interface for receiving callbacks when a managed partition
         shuts down.
      Signed-off-by: NTimur Tabi <timur@freescale.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      6db71994
  6. 06 7月, 2011 1 次提交
  7. 14 6月, 2011 1 次提交
  8. 24 5月, 2011 1 次提交
  9. 14 5月, 2011 1 次提交
  10. 11 5月, 2011 1 次提交
    • R
      bcma: add Broadcom specific AMBA bus driver · 8369ae33
      Rafał Miłecki 提交于
      Broadcom has released cards based on a new AMBA-based bus type. From a
      programming point of view, this new bus type differs from AMBA and does
      not use AMBA common registers. It also differs enough from SSB. We
      decided that a new bus driver is needed to keep the code clean.
      
      In its current form, the driver detects devices present on the bus and
      registers them in the system. It allows registering BCMA drivers for
      specified bus devices and provides them basic operations. The bus driver
      itself includes two important bus managing drivers: ChipCommon core
      driver and PCI(c) core driver. They are early used to allow correct
      initialization.
      
      Currently code is limited to supporting buses on PCI(e) devices, however
      the driver is designed to be used also on other hosts. The host
      abstraction layer is implemented and already used for PCI(e).
      
      Support for PCI(e) hosts is working and seems to be stable (access to
      80211 core was tested successfully on a few devices). We can still
      optimize it by using some fixed windows, but this can be done later
      without affecting any external code. Windows are just ranges in MMIO
      used for accessing cores on the bus.
      
      Cc: Greg KH <greg@kroah.com>
      Cc: Michael Büsch <mb@bu3sch.de>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: George Kashperko <george@znau.edu.ua>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andy Botting <andy@andybotting.com>
      Cc: linuxdriverproject <devel@linuxdriverproject.org>
      Cc: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8369ae33
  11. 18 2月, 2011 1 次提交
    • O
      drivers: hwspinlock: add framework · bd9a4c7d
      Ohad Ben-Cohen 提交于
      Add a platform-independent hwspinlock framework.
      
      Hardware spinlock devices are needed, e.g., in order to access data
      that is shared between remote processors, that otherwise have no
      alternative mechanism to accomplish synchronization and mutual exclusion
      operations.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Hari Kanigeri <h-kanigeri2@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bd9a4c7d
  12. 15 1月, 2011 1 次提交
    • N
      [SCSI] target: Add LIO target core v4.0.0-rc6 · c66ac9db
      Nicholas Bellinger 提交于
      LIO target is a full featured in-kernel target framework with the
      following feature set:
      
      High-performance, non-blocking, multithreaded architecture with SIMD
      support.
      
      Advanced SCSI feature set:
      
          * Persistent Reservations (PRs)
          * Asymmetric Logical Unit Assignment (ALUA)
          * Protocol and intra-nexus multiplexing, load-balancing and failover (MC/S)
          * Full Error Recovery (ERL=0,1,2)
          * Active/active task migration and session continuation (ERL=2)
          * Thin LUN provisioning (UNMAP and WRITE_SAMExx)
      
      Multiprotocol target plugins
      
      Storage media independence:
      
          * Virtualization of all storage media; transparent mapping of IO to LUNs
          * No hard limits on number of LUNs per Target; maximum LUN size ~750 TB
          * Backstores: SATA, SAS, SCSI, BluRay, DVD, FLASH, USB, ramdisk, etc.
      
      Standards compliance:
      
          * Full compliance with IETF (RFC 3720)
          * Full implementation of SPC-4 PRs and ALUA
      
      Significant code cleanups done by Christoph Hellwig.
      
      [jejb: fix up for new block bdev exclusive interface. Minor fixes from
       Randy Dunlap and Dan Carpenter.]
      Signed-off-by: NNicholas A. Bellinger <nab@linux-iscsi.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      c66ac9db
  13. 14 1月, 2011 1 次提交
  14. 26 11月, 2010 1 次提交
  15. 07 3月, 2010 1 次提交
  16. 30 12月, 2009 1 次提交
    • S
      firewire, ieee1394: update Kconfig help · 5d7db049
      Stefan Richter 提交于
      Update the Kconfig help texts of both stacks to encourage a general move
      from the older to the newer drivers.  However, do not label ieee1394 as
      "Obsolete" yet, as the newer drivers have not been deployed as default
      stack in the majority of Linux distributions yet, and those who start
      doing so now may still want to install the old drivers as fallback for
      unforeseen issues.
      
      Since Linux 2.6.32, FireWire audio devices can be driven by the newer
      firewire driver stack too, hence remove an outdated comment about audio
      devices.  Also remove comments about library versions since the 2nd
      generation of libraw1394 and libdc1394 is now in common use; details on
      library versions can be read at the wiki link from the help texts.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      5d7db049
  17. 16 12月, 2009 1 次提交
  18. 09 11月, 2009 1 次提交
  19. 19 6月, 2009 1 次提交
    • R
      LinuxPPS: core support · eae9d2ba
      Rodolfo Giometti 提交于
      This patch adds the kernel side of the PPS support currently named
      "LinuxPPS".
      
      PPS means "pulse per second" and a PPS source is just a device which
      provides a high precision signal each second so that an application can
      use it to adjust system clock time.
      
      Common use is the combination of the NTPD as userland program with a GPS
      receiver as PPS source to obtain a wallclock-time with sub-millisecond
      synchronisation to UTC.
      
      To obtain this goal the userland programs shoud use the PPS API
      specification (RFC 2783 - Pulse-Per-Second API for UNIX-like Operating
      Systems, Version 1.0) which in part is implemented by this patch.  It
      provides a set of chars devices, one per PPS source, which can be used to
      get the time signal.  The RFC's functions can be implemented by accessing
      to these char devices.
      Signed-off-by: NRodolfo Giometti <giometti@linux.it>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eae9d2ba
  20. 17 6月, 2009 1 次提交
  21. 19 12月, 2008 1 次提交
    • L
      create drivers/platform/x86/ from drivers/misc/ · 41b16dce
      Len Brown 提交于
      Move x86 platform specific drivers from drivers/misc/
      to a new home under drivers/platform/x86/.
      
      The community has been maintaining x86 vendor-specific
      platform specific drivers under /drivers/misc/ for a few years.
      The oldest ones started life under drivers/acpi.
      They moved out of drivers/acpi/ because they don't actually
      implement the ACPI specification, but either simply
      use ACPI, or implement vendor-specific ACPI extensions.
      
      In the future we anticipate...
      drivers/misc/ will go away.
      other architectures will create drivers/platform/<arch>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      41b16dce
  22. 29 10月, 2008 1 次提交
  23. 11 10月, 2008 1 次提交
  24. 17 9月, 2008 1 次提交
  25. 30 4月, 2008 1 次提交
  26. 25 4月, 2008 1 次提交
  27. 10 2月, 2008 1 次提交
  28. 06 2月, 2008 1 次提交
    • D
      gpiolib: add drivers/gpio directory · a9c5fff5
      David Brownell 提交于
      Add an empty drivers/gpio directory for gpiolib infrastructure and GPIO
      expanders.  It will be populated by later patches.
      
      This won't be the only place to hold such gpio_chip code.  Many external chips
      add a few GPIOs as secondary functionality (such as MFD drivers) and platform
      code frequently needs to closely integrate GPIO and IRQ support.
      
      This is placed *early* in the build/link sequence since it's common for other
      drivers to depend on GPIOs to do their work, so they must be initialized early
      in the device_initcall() sequence.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NJean Delvare <khali@linux-fr.org>
      Cc: Eric Miao <eric.miao@marvell.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Philipp Zabel <philipp.zabel@gmail.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ben Gardner <bgardner@wabtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9c5fff5
  29. 04 2月, 2008 1 次提交
  30. 02 2月, 2008 1 次提交
  31. 31 1月, 2008 1 次提交
  32. 23 10月, 2007 2 次提交
    • R
      Virtio interface · ec3d41c4
      Rusty Russell 提交于
      This attempts to implement a "virtual I/O" layer which should allow
      common drivers to be efficiently used across most virtual I/O
      mechanisms.  It will no-doubt need further enhancement.
      
      The virtio drivers add buffers to virtio queues; as the buffers are consumed
      the driver "interrupt" callbacks are invoked.
      
      There is also a generic implementation of config space which drivers can query
      to get setup information from the host.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Dor Laor <dor.laor@qumranet.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      ec3d41c4
    • R
      Consolidate host virtualization support under Virtualization menu · 9525ca02
      Rusty Russell 提交于
      Move lguest under the virtualization menu.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Avi Kivity <avi@qumranet.com>
      9525ca02
  33. 18 10月, 2007 1 次提交
  34. 17 10月, 2007 1 次提交
    • S
      DCA: Add Direct Cache Access driver · 7589670f
      Shannon Nelson 提交于
      Direct Cache Access (DCA) is a method for warming the CPU cache before data
      is used, with the intent of lessening the impact of cache misses.  This
      patch adds a manager and interface for matching up client requests for DCA
      services with devices that offer DCA services.
      
      In order to use DCA, a module must do bus writes with the appropriate tag
      bits set to trigger a cache read for a specific CPU.  However, different
      CPUs and chipsets can require different sets of tag bits, and the methods
      for determining the correct bits may be simple hardcoding or may be a
      hardware specific magic incantation.  This interface is a way for DCA
      clients to find the correct tag bits for the targeted CPU without needing
      to know the specifics.
      
          [Dave Miller] use DEFINE_SPINLOCK()
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7589670f
  35. 11 10月, 2007 1 次提交
  36. 20 7月, 2007 2 次提交
  37. 19 7月, 2007 1 次提交
    • H
      UIO: Add the User IO core code · beafc54c
      Hans J. Koch 提交于
      This interface allows the ability to write the majority of a driver in
      userspace with only a very small shell of a driver in the kernel itself.
      It uses a char device and sysfs to interact with a userspace process to
      process interrupts and control memory accesses.
      
      See the docbook documentation for more details on how to use this
      interface.
      
      From: Hans J. Koch <hjk@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benedikt Spranger <b.spranger@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      beafc54c
  38. 10 7月, 2007 1 次提交
    • A
      [BATTERY] Universal power supply class (was: battery class) · 4a11b59d
      Anton Vorontsov 提交于
      This class is result of "external power" and "battery" classes merge,
      as suggested by David Woodhouse. He also implemented uevent support.
      
      Here how userspace seeing it now:
      
          	# ls /sys/class/power\ supply/
          	ac  main-battery  usb
      
          	# cat /sys/class/power\ supply/ac/type
          	AC
      
          	# cat /sys/class/power\ supply/usb/type
          	USB
      
          	# cat /sys/class/power\ supply/main-battery/type
          	Battery
      
          	# cat /sys/class/power\ supply/ac/online
          	1
      
          	# cat /sys/class/power\ supply/usb/online
          	0
      
          	# cat /sys/class/power\ supply/main-battery/status
          	Charging
      
          	# cat /sys/class/leds/h5400\:red-left/trigger
          	none h5400-radio timer hwtimer ac-online usb-online
          	main-battery-charging-or-full [main-battery-charging]
          	main-battery-full
      Signed-off-by: NAnton Vorontsov <cbou@mail.ru>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      4a11b59d