1. 04 Oct, 2015 2 commits
    • Alexander Shishkin's avatar
      intel_th: Add driver infrastructure for Intel(R) Trace Hub devices · 39f40346
      Alexander Shishkin authored
      Intel(R) Trace Hub (TH) is a set of hardware blocks (subdevices) that
      produce, switch and output trace data from multiple hardware and
      software sources over several types of trace output ports encoded
      in System Trace Protocol (MIPI STPv2) and is intended to perform
      full system debugging.
      
      For these subdevices, we create a bus, where they can be discovered
      and configured by userspace software.
      
      This patch creates this bus infrastructure, three types of devices
      (source, output, switch), resource allocation, some callback mechanisms
      to facilitate communication between the subdevices' drivers and some
      common sysfs attributes.
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39f40346
    • Alexander Shishkin's avatar
      stm class: Introduce an abstraction for System Trace Module devices · 7bd1d409
      Alexander Shishkin authored
      A System Trace Module (STM) is a device exporting data in System Trace
      Protocol (STP) format as defined by MIPI STP standards. Examples of such
      devices are Intel(R) Trace Hub and Coresight STM.
      
      This abstraction provides a unified interface for software trace sources
      to send their data over an STM device to a debug host. In order to do
      that, such a trace source needs to be assigned a pair of master/channel
      identifiers that all the data from this source will be tagged with. The
      STP decoder on the debug host side will use these master/channel tags to
      distinguish different trace streams from one another inside one STP
      stream.
      
      This abstraction provides a configfs-based policy management mechanism
      for dynamic allocation of these master/channel pairs based on trace
      source-supplied string identifier. It has the flexibility of being
      defined at runtime and at the same time (provided that the policy
      definition is aligned with the decoding end) consistency.
      
      For userspace trace sources, this abstraction provides write()-based and
      mmap()-based (if the underlying stm device allows this) output mechanism.
      
      For kernel-side trace sources, we provide "stm_source" device class that
      can be connected to an stm device at run time.
      
      Cc: linux-api@vger.kernel.org
      Reviewed-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bd1d409
  2. 05 Aug, 2015 1 commit
  3. 31 Jul, 2015 1 commit
    • Mark Rutland's avatar
      arm: perf: factor arm_pmu core out to drivers · fa8ad788
      Mark Rutland authored
      To enable sharing of the arm_pmu code with arm64, this patch factors it
      out to drivers/perf/. A new drivers/perf directory is added for
      performance monitor drivers to live under.
      
      MAINTAINERS is updated accordingly. Files added previously without a
      corresponsing MAINTAINERS update (perf_regs.c, perf_callchain.c, and
      perf_event.h) are also added.
      
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      [will: augmented Kconfig help slightly]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      fa8ad788
  4. 16 Jul, 2015 1 commit
  5. 25 Jun, 2015 1 commit
  6. 24 May, 2015 1 commit
  7. 03 Apr, 2015 1 commit
  8. 22 Dec, 2014 1 commit
    • Oded Gabbay's avatar
      drivers: Move iommu/ before gpu/ in Makefile · 1bacc894
      Oded Gabbay authored
      AMD GPU devices are dependent on AMD IOMMU controller functionality to allow
      the GPU to access a process's virtual memory address space, without the need
      for pinning the memory.
      
      This patch changes the order in the drivers makefile, so iommu/ subsystem is
      linked before gpu/ subsystem. That way, if the gpu and iommu drivers are
      compiled inside the kernel image (not as modules), the correct order of device
      loading is still maintained (iommu module is loaded before gpu module).
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      1bacc894
  9. 07 Nov, 2014 1 commit
    • Pratik Patel's avatar
      coresight: add CoreSight core layer framework · a06ae860
      Pratik Patel authored
      CoreSight components are compliant with the ARM CoreSight
      architecture specification and can be connected in various
      topologies to suit a particular SoC tracing needs. These trace
      components can generally be classified as sources, links and
      sinks. Trace data produced by one or more sources flows through
      the intermediate links connecting the source to the currently
      selected sink.
      
      The CoreSight framework provides an interface for the CoreSight trace
      drivers to register themselves with. It's intended to build up a
      topological view of the CoreSight components and configure the
      correct serie of components on user input via sysfs.
      
      For eg., when enabling a source, the framework builds up a path
      consisting of all the components connecting the source to the
      currently selected sink(s) and enables all of them.
      
      The framework also supports switching between available sinks
      and provides status information to user space applications
      through the debugfs interface.
      Signed-off-by: default avatarPratik Patel <pratikp@codeaurora.org>
      Signed-off-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a06ae860
  10. 20 Oct, 2014 1 commit
  11. 08 Jul, 2014 1 commit
  12. 23 Jun, 2014 1 commit
  13. 19 Jun, 2014 1 commit
    • Andreas Noever's avatar
      thunderbolt: Add initial cactus ridge NHI support · 16603153
      Andreas Noever authored
      Thunderbolt hotplug is supposed to be handled by the firmware. But Apple
      decided to implement thunderbolt at the operating system level. The
      firmare only initializes thunderbolt devices that are present at boot
      time. This driver enables hotplug of thunderbolt of non-chained
      thunderbolt devices on Apple systems with a cactus ridge controller.
      
      This first patch adds the Kconfig file as well the parts of the driver
      which talk directly to the hardware (that is pci device setup, interrupt
      handling and RX/TX ring management).
      Signed-off-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16603153
  14. 27 May, 2014 1 commit
  15. 23 May, 2014 1 commit
  16. 12 May, 2014 1 commit
    • Geert Uytterhoeven's avatar
      drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI · 3c90c55d
      Geert Uytterhoeven authored
      If the kernel is built to support multi-ARM configuration with shmobile
      support built in, then drivers/sh is not built. This contains the PM
      runtime code in drivers/sh/pm_runtime.c, which implicitly enables the
      module clocks for all devices, and thus is quite essential.
      Without this, the state of clocks depends on implicit reset state, or on
      the bootloader.
      
      If ARCH_SHMOBILE_MULTI then build the drivers/sh directory, but ensure that
      bits that may conflict (drivers/sh/clk if the common clock framework is
      enabled) or are not used (drivers/sh/intc), are not built.
      Also, only enable the PM runtime code when actually running on a shmobile
      SoCs that needs it.
      
      ARCH_SHMOBILE_MULTI was added a while ago by commit
      efacfce5 ("ARM: shmobile: Introduce
      ARCH_SHMOBILE_MULTI"), but drivers/sh was compiled for both
      ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI until commit
      bf98c1ea ("ARM: Rename ARCH_SHMOBILE to
      ARCH_SHMOBILE_LEGACY").
      
      Inspired by a patch from Ben Dooks <ben.dooks@codethink.co.uk>.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      3c90c55d
  17. 17 Apr, 2014 1 commit
  18. 28 Feb, 2014 1 commit
  19. 15 Feb, 2014 1 commit
  20. 10 Dec, 2013 1 commit
  21. 16 Oct, 2013 1 commit
  22. 28 Sep, 2013 1 commit
  23. 17 Jun, 2013 1 commit
  24. 11 Jun, 2013 1 commit
  25. 12 Apr, 2013 1 commit
  26. 25 Mar, 2013 2 commits
  27. 20 Mar, 2013 1 commit
  28. 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: default avatarFelipe Balbi <balbi@ti.com>
      edc7cb2e
  29. 01 Feb, 2013 1 commit
  30. 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: default avatarJon Mason <jon.mason@intel.com>
      Reviewed-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fce8a7bb
  31. 03 Jan, 2013 1 commit
  32. 16 Nov, 2012 1 commit
  33. 17 Oct, 2012 1 commit
  34. 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: default avatarChris Boot <bootc@bootc.net>
      Signed-off-by: default avatarSimon Arlott <simon@fire.lp0.eu>
      Signed-off-by: default avatarDom Cobley <popcornmix@gmail.com>
      Signed-off-by: default avatarDom Cobley <dc4@broadcom.com>
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@wwwdotorg.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      89214f00
  35. 30 Aug, 2012 1 commit
  36. 22 Aug, 2012 1 commit
  37. 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: default avatarAlex Williamson <alex.williamson@redhat.com>
      cba3345c
  38. 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: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: default avatarKurt Van Dijck <kurt.van.dijck@eia.be>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarMatthias Kaehlcke <matthias@kaehlcke.net>
      Reviewed-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: default avatarShawn Guo <shawn.guo@linaro.org>
      [thierry.reding@avionic-design.de: fixup typos, kerneldoc comments]
      Signed-off-by: default avatarThierry Reding <thierry.reding@avionic-design.de>
      0c2498f1