1. 03 Jul, 2014 1 commit
  2. 07 Jun, 2014 1 commit
  3. 12 Apr, 2013 1 commit
  4. 25 Mar, 2013 2 commits
  5. 20 Mar, 2013 1 commit
  6. 18 Mar, 2013 1 commit
    • Felipe Balbi's avatar
      usb: phy: make it a menuconfig · edc7cb2e
      Felipe Balbi authored
      We already have a considerable amount of USB
      PHY drivers, making it a menuconfig just
      prevents us from adding too much churn to
      USB's menuconfig.
      
      While at that, also select USB_OTG_UTILS from
      this new menuconfig just to keep backwards
      compatibility until we manage to remove
      that symbol.
      Signed-off-by: 's avatarFelipe Balbi <balbi@ti.com>
      edc7cb2e
  7. 01 Feb, 2013 1 commit
  8. 18 Jan, 2013 1 commit
    • Jon Mason's avatar
      PCI-Express Non-Transparent Bridge Support · fce8a7bb
      Jon Mason authored
      A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
      connecting 2 systems, providing electrical isolation between the two subsystems.
      A non-transparent bridge is functionally similar to a transparent bridge except
      that both sides of the bridge have their own independent address domains.  The
      host on one side of the bridge will not have the visibility of the complete
      memory or I/O space on the other side of the bridge.  To communicate across the
      non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
      the local system.  Writes to these apertures are mirrored to memory on the
      remote system.  Communications can also occur through the use of doorbell
      registers that initiate interrupts to the alternate domain, and scratch-pad
      registers accessible from both sides.
      
      The NTB device driver is needed to configure these memory windows, doorbell, and
      scratch-pad registers as well as use them in such a way as they can be turned
      into a viable communication channel to the remote system.  ntb_hw.[ch]
      determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
      the underlying hardware to provide access and a common interface to the doorbell
      registers, scratch pads, and memory windows.  These hardware interfaces are
      exported so that other, non-mainlined kernel drivers can access these.
      ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
      communication channel(s) and provide a reliable way of transferring data from
      one side to the other, which it then exports so that "client" drivers can access
      them.  These client drivers are used to provide a standard kernel interface
      (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
      system to the other in a standard way.
      Signed-off-by: 's avatarJon Mason <jon.mason@intel.com>
      Reviewed-by: 's avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fce8a7bb
  9. 03 Jan, 2013 1 commit
  10. 16 Nov, 2012 1 commit
  11. 17 Oct, 2012 1 commit
  12. 20 Sep, 2012 1 commit
    • Simon Arlott's avatar
      ARM: bcm2835: add interrupt controller driver · 89214f00
      Simon Arlott authored
      The BCM2835 contains a custom interrupt controller, which supports 72
      interrupt sources using a 2-level register scheme. The interrupt
      controller, or the HW block containing it, is referred to occasionally
      as "armctrl" in the SoC documentation, hence the symbol naming in the
      code.
      
      This patch was extracted from git://github.com/lp0/linux.git branch
      rpi-split as of 2012/09/08, and modified as follows:
      
      * s/bcm2708/bcm2835/.
      * Modified device tree vendor prefix.
      * Moved implementation to drivers/irchip/.
      * Added devicetree documentation, and hence removed list of IRQs from
        bcm2835.dtsi.
      * Changed shift in MAKE_HWIRQ() and HWIRQ_BANK() from 8 to 5 to reduce
        the size of the hwirq space, and pass the total size of the hwirq space
        to irq_domain_add_linear(), rather than just the number of valid hwirqs;
        the two are different due to the hwirq space being sparse.
      * Added the interrupt controller DT node to the top-level of the DT,
        rather than nesting it inside a /axi node. Hence, changed the reg value
        since /axi had a ranges property. This seems simpler to me, but I'm not
        sure if everyone will like this change or not.
      * Don't set struct irq_domain_ops.map = irq_domain_simple_map, hence
        removing the need to patch include/linux/irqdomain.h or
        kernel/irq/irqdomain.c.
      * Simplified armctrl_of_init() using of_iomap().
      * Removed unused IS_VALID_BANK()/IS_VALID_IRQ() macros.
      * Renamed armctrl_handle_irq() to prevent possible symbol clashes.
      * Made armctrl_of_init() static.
      * Removed comment "Each bank is registered as a separate interrupt
        controller" since this is no longer true.
      * Removed FSF address from license header.
      * Added my name to copyright header.
      Signed-off-by: 's avatarChris Boot <bootc@bootc.net>
      Signed-off-by: 's avatarSimon Arlott <simon@fire.lp0.eu>
      Signed-off-by: 's avatarDom Cobley <popcornmix@gmail.com>
      Signed-off-by: 's avatarDom Cobley <dc4@broadcom.com>
      Signed-off-by: 's avatarStephen Warren <swarren@wwwdotorg.org>
      Acked-by: 's avatarArnd Bergmann <arnd@arndb.de>
      89214f00
  13. 30 Aug, 2012 1 commit
  14. 22 Aug, 2012 1 commit
  15. 31 Jul, 2012 1 commit
    • Alex Williamson's avatar
      vfio: VFIO core · cba3345c
      Alex Williamson authored
      VFIO is a secure user level driver for use with both virtual machines
      and user level drivers.  VFIO makes use of IOMMU groups to ensure the
      isolation of devices in use, allowing unprivileged user access.  It's
      intended that VFIO will replace KVM device assignment and UIO drivers
      (in cases where the target platform includes a sufficiently capable
      IOMMU).
      
      New in this version of VFIO is support for IOMMU groups managed
      through the IOMMU core as well as a rework of the API, removing the
      group merge interface.  We now go back to a model more similar to
      original VFIO with UIOMMU support where the file descriptor obtained
      from /dev/vfio/vfio allows access to the IOMMU, but only after a
      group is added, avoiding the previous privilege issues with this type
      of model.  IOMMU support is also now fully modular as IOMMUs have
      vastly different interface requirements on different platforms.  VFIO
      users are able to query and initialize the IOMMU model of their
      choice.
      
      Please see the follow-on Documentation commit for further description
      and usage example.
      Signed-off-by: 's avatarAlex Williamson <alex.williamson@redhat.com>
      cba3345c
  16. 15 Jun, 2012 1 commit
    • Sascha Hauer's avatar
      pwm: Add PWM framework support · 0c2498f1
      Sascha Hauer authored
      This patch adds framework support for PWM (pulse width modulation) devices.
      
      The is a barebone PWM API already in the kernel under include/linux/pwm.h,
      but it does not allow for multiple drivers as each of them implements the
      pwm_*() functions.
      
      There are other PWM framework patches around from Bill Gatliff. Unlike
      his framework this one does not change the existing API for PWMs so that
      this framework can act as a drop in replacement for the existing API.
      
      Why another framework?
      
      Several people argue that there should not be another framework for PWMs
      but they should be integrated into one of the existing frameworks like led
      or hwmon. Unlike these frameworks the PWM framework is agnostic to the
      purpose of the PWM. In fact, a PWM can drive a LED, but this makes the
      LED framework a user of a PWM, like already done in leds-pwm.c. The gpio
      framework also is not suitable for PWMs. Every gpio could be turned into
      a PWM using timer based toggling, but on the other hand not every PWM hardware
      device can be turned into a gpio due to the lack of hardware capabilities.
      
      This patch does not try to improve the PWM API yet, this could be done in
      subsequent patches.
      Signed-off-by: 's avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: 's avatarKurt Van Dijck <kurt.van.dijck@eia.be>
      Reviewed-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: 's avatarMatthias Kaehlcke <matthias@kaehlcke.net>
      Reviewed-by: 's avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: 's avatarShawn Guo <shawn.guo@linaro.org>
      [thierry.reding@avionic-design.de: fixup typos, kerneldoc comments]
      Signed-off-by: 's avatarThierry Reding <thierry.reding@avionic-design.de>
      0c2498f1
  17. 17 May, 2012 1 commit
    • Paul Gortmaker's avatar
      MCA: delete all remaining traces of microchannel bus support. · bb8187d3
      Paul Gortmaker authored
      Hardware with MCA bus is limited to 386 and 486 class machines
      that are now 20+ years old and typically with less than 32MB
      of memory.  A quick search on the internet, and you see that
      even the MCA hobbyist/enthusiast community has lost interest
      in the early 2000 era and never really even moved ahead from
      the 2.4 kernels to the 2.6 series.
      
      This deletes anything remaining related to CONFIG_MCA from core
      kernel code and from the x86 architecture.  There is no point in
      carrying this any further into the future.
      
      One complication to watch for is inadvertently scooping up
      stuff relating to machine check, since there is overlap in
      the TLA name space (e.g. arch/x86/boot/mca.c).
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: x86@kernel.org
      Acked-by: 's avatarIngo Molnar <mingo@elte.hu>
      Acked-by: 's avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: 's avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      bb8187d3
  18. 08 May, 2012 1 commit
    • Hiroshi DOYU's avatar
      ARM: tegra: Add Tegra AHB driver · 87d0bab2
      Hiroshi DOYU authored
      Tegra AHB Bus conforms to the AMBA Specification (Rev 2.0) Advanced
      High-performance Bus (AHB) architecture.
      
      The AHB Arbiter controls AHB bus master arbitration. This effectively
      forms a second level of arbitration for access to the memory
      controller through the AHB Slave Memory device. The AHB pre-fetch
      logic can be configured to enhance performance for devices doing
      sequential access. Each AHB master is assigned to either the high or
      low priority bin. Both Tegra20/30 have this AHB bus.
      
      Some of configuration params could be passed from DT too if needed.
      Signed-off-by: 's avatarHiroshi DOYU <hdoyu@nvidia.com>
      Acked-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: 's avatarStephen Warren <swarren@nvidia.com>
      87d0bab2
  19. 02 May, 2012 1 commit
  20. 26 Apr, 2012 1 commit
    • Greg Kroah-Hartman's avatar
      Staging: VME: move VME drivers out of staging · db3b9e99
      Greg Kroah-Hartman authored
      This moves the VME core, VME board drivers, and VME bridge drivers out
      of the drivers/staging/vme/ area to drivers/vme/.
      
      The VME device drivers have not moved out yet due to some API questions
      they are still working through, that should happen soon, hopefully.
      
      Cc: Martyn Welch <martyn.welch@ge.com>
      Cc: Manohar Vanga <manohar.vanga@cern.ch>
      Cc: Vincent Bossier <vincent.bossier@gmail.com>
      Cc: "Emilio G. Cota" <cota@braap.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db3b9e99
  21. 25 Apr, 2012 1 commit
  22. 20 Apr, 2012 1 commit
    • MyungJoo Ham's avatar
      Extcon (external connector): import Android's switch class and modify. · de55d871
      MyungJoo Ham authored
      External connector class (extcon) is based on and an extension of
      Android kernel's switch class located at linux/drivers/switch/.
      
      This patch provides the before-extension switch class moved to the
      location where the extcon will be located (linux/drivers/extcon/) and
      updates to handle class properly.
      
      The before-extension class, switch class of Android kernel, commits
      imported are:
      
      switch: switch class and GPIO drivers. (splitted)
      Author: Mike Lockwood <lockwood@android.com>
      
      switch: Use device_create instead of device_create_drvdata.
      Author: Arve Hjønnevåg <arve@android.com>
      
      In this patch, upon the commits of Android kernel, we have added:
      - Relocated and renamed for extcon.
      - Comments, module name, and author information are updated
      - Code clean for successing patches
      - Bugfix: enabling write access without write functions
      - Class/device/sysfs create/remove handling
      - Added comments about uevents
      - Format changes for extcon_dev_register() to have a parent dev.
      Signed-off-by: 's avatarMyungJoo Ham <myungjoo.ham@samsung.com>
      Signed-off-by: 's avatarKyungmin Park <kyungmin.park@samsung.com>
      Reviewed-by: 's avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      
      --
      Changes from v7
      - Compiler error fixed when it is compiled as a module.
      - Removed out-of-date Kconfig entry
      
      Changes from v6
      - Updated comment/strings
      - Revised "Android-compatible" mode.
         * Automatically activated if CONFIG_ANDROID && !CONFIG_ANDROID_SWITCH
         * Creates /sys/class/switch/*, which is a copy of /sys/class/extcon/*
      
      Changes from v5
      - Split the patch
      - Style fixes
      - "Android-compatible" mode is enabled by Kconfig option.
      
      Changes from v2
      - Updated name_show
      - Sysfs entries are handled by class itself.
      - Updated the method to add/remove devices for the class
      - Comments on uevent send
      - Able to become a module
      - Compatible with Android platform
      
      Changes from RFC
      - Renamed to extcon (external connector) from multistate switch
      - Added a seperated directory (drivers/extcon)
      - Added kerneldoc comments
      - Removed unused variables from extcon_gpio.c
      - Added ABI Documentation.
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de55d871
  23. 09 Feb, 2012 1 commit
  24. 08 Feb, 2012 2 commits
    • Ohad Ben-Cohen's avatar
      rpmsg: add virtio-based remote processor messaging bus · bcabbcca
      Ohad Ben-Cohen authored
      Add a virtio-based inter-processor communication bus, which enables
      kernel drivers to communicate with entities, running on remote
      processors, over shared memory using a simple messaging protocol.
      
      Every pair of AMP processors share two vrings, which are used to send
      and receive the messages over shared memory.
      
      The header of every message sent on the rpmsg bus contains src and dst
      addresses, which make it possible to multiplex several rpmsg channels on
      the same vring.
      
      Every rpmsg channel is a device on this bus. When a channel is added,
      and an appropriate rpmsg driver is found and probed, it is also assigned
      a local rpmsg address, which is then bound to the driver's callback.
      
      When inbound messages carry the local address of a bound driver,
      its callback is invoked by the bus.
      
      This patch provides a kernel interface only; user space interfaces
      will be later exposed by kernel users of this rpmsg bus.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: Rusty Russell <rusty@rustcorp.com.au> (virtio_ids.h)
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      bcabbcca
    • Ohad Ben-Cohen's avatar
      remoteproc: add framework for controlling remote processors · 400e64df
      Ohad Ben-Cohen authored
      Modern SoCs typically employ a central symmetric multiprocessing (SMP)
      application processor running Linux, with several other asymmetric
      multiprocessing (AMP) heterogeneous processors running different instances
      of operating system, whether Linux or any other flavor of real-time OS.
      
      Booting a remote processor in an AMP configuration typically involves:
      - Loading a firmware which contains the OS image
      - Allocating and providing it required system resources (e.g. memory)
      - Programming an IOMMU (when relevant)
      - Powering on the device
      
      This patch introduces a generic framework that allows drivers to do
      that. In the future, this framework will also include runtime power
      management and error recovery.
      
      Based on (but now quite far from) work done by Fernando Guzman Lugo
      <fernando.lugo@ti.com>.
      
      ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on
      msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: 's avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      400e64df
  25. 12 Jan, 2012 1 commit
    • Adrian Hunter's avatar
      mmc: sdhci-pci: add platform data · 52c506f0
      Adrian Hunter authored
      Add a means of getting platform data for the SDHCI PCI
      devices.  The data is stored against the slot not the
      device in order to support multi-slot devices.
      
      The data allows platform-specific setup (such as getting
      GPIO numbers from firmware or setting up wl12xx for SDIO)
      to be done in platform support files instead of the
      sdhci-pci driver.
      Signed-off-by: 's avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: 's avatarChris Ball <cjb@laptop.org>
      52c506f0
  26. 05 Jan, 2012 1 commit
  27. 13 Oct, 2011 1 commit
    • Linus Walleij's avatar
      drivers: create a pin control subsystem · 2744e8af
      Linus Walleij authored
      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: 's avatarGrant Likely <grant.likely@secretlab.ca>
      Acked-by: 's avatarStephen Warren <swarren@nvidia.com>
      Tested-by: 's avatarBarry Song <21cnbao@gmail.com>
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      2744e8af
  28. 11 Oct, 2011 1 commit
  29. 01 Oct, 2011 1 commit
    • MyungJoo Ham's avatar
      PM: Introduce devfreq: generic DVFS framework with device-specific OPPs · a3c98b8b
      MyungJoo Ham authored
      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: 's avatarMyungJoo Ham <myungjoo.ham@samsung.com>
      Signed-off-by: 's avatarKyungmin Park <kyungmin.park@samsung.com>
      Reviewed-by: 's avatarMike Turquette <mturquette@ti.com>
      Acked-by: 's avatarKevin Hilman <khilman@ti.com>
      Signed-off-by: 's avatarRafael J. Wysocki <rjw@sisk.pl>
      a3c98b8b
  30. 08 Jul, 2011 1 commit
    • Timur Tabi's avatar
      drivers/virt: introduce Freescale hypervisor management driver · 6db71994
      Timur Tabi authored
      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: 's avatarTimur Tabi <timur@freescale.com>
      Acked-by: 's avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: 's avatarKumar Gala <galak@kernel.crashing.org>
      6db71994
  31. 07 Jul, 2011 1 commit
  32. 05 Jul, 2011 1 commit
  33. 14 Jun, 2011 1 commit
  34. 25 May, 2011 1 commit
  35. 23 May, 2011 1 commit
  36. 19 May, 2011 1 commit
  37. 10 May, 2011 1 commit
    • Rafał Miłecki's avatar
      bcma: add Broadcom specific AMBA bus driver · 8369ae33
      Rafał Miłecki authored
      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: 's avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: 's avatarJohn W. Linville <linville@tuxdriver.com>
      8369ae33
  38. 13 Apr, 2011 1 commit