1. 08 Dec, 2014 1 commit
  2. 05 Dec, 2014 3 commits
    • Olof Johansson's avatar
      Merge branch 'clocksource/physical-timers' into next/drivers · 6b34df9e
      Olof Johansson authored
      * clocksource/physical-timers:
        clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers
        clocksource: arch_timer: Fix code to use physical timers when requested
      6b34df9e
    • Doug Anderson's avatar
      clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers · 65b5732d
      Doug Anderson authored
      Some 32-bit (ARMv7) systems are architected like this:
      
      * The firmware doesn't know and doesn't care about hypervisor mode and
        we don't want to add the complexity of hypervisor there.
      
      * The firmware isn't involved in SMP bringup or resume.
      
      * The ARCH timer come up with an uninitialized offset (CNTVOFF)
        between the virtual and physical counters.  Each core gets a
        different random offset.
      
      * The device boots in "Secure SVC" mode.
      
      * Nothing has touched the reset value of CNTHCTL.PL1PCEN or
        CNTHCTL.PL1PCTEN (both default to 1 at reset)
      
      On systems like the above, it doesn't make sense to use the virtual
      counter.  There's nobody managing the offset and each time a core goes
      down and comes back up it will get reinitialized to some other random
      value.
      
      This adds an optional property which can inform the kernel of this
      situation, and firmware is free to remove the property if it is going
      to initialize the CNTVOFF registers when each CPU comes out of reset.
      
      Currently, the best course of action in this case is to use the
      physical timer, which is why it is important that CNTHCTL hasn't been
      changed from its reset value and it's a reasonable assumption given
      that the firmware has never entered HYP mode.
      
      Note that it's been said that on ARMv8 systems the firmware and
      kernel really can't be architected as described above.  That means
      using the physical timer like this really only makes sense for ARMv7
      systems.
      Signed-off-by: default avatarDoug Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSonny Rao <sonnyrao@chromium.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      65b5732d
    • Sonny Rao's avatar
      clocksource: arch_timer: Fix code to use physical timers when requested · 0b46b8a7
      Sonny Rao authored
      This is a bug fix for using physical arch timers when
      the arch_timer_use_virtual boolean is false.  It restores the
      arch_counter_get_cntpct() function after removal in
      
      0d651e4e "clocksource: arch_timer: use virtual counters"
      
      We need this on certain ARMv7 systems which are architected like this:
      
      * The firmware doesn't know and doesn't care about hypervisor mode and
        we don't want to add the complexity of hypervisor there.
      
      * The firmware isn't involved in SMP bringup or resume.
      
      * The ARCH timer come up with an uninitialized offset between the
        virtual and physical counters.  Each core gets a different random
        offset.
      
      * The device boots in "Secure SVC" mode.
      
      * Nothing has touched the reset value of CNTHCTL.PL1PCEN or
        CNTHCTL.PL1PCTEN (both default to 1 at reset)
      
      One example of such as system is RK3288 where it is much simpler to
      use the physical counter since there's nobody managing the offset and
      each time a core goes down and comes back up it will get reinitialized
      to some other random value.
      
      Fixes: 0d651e4e ("clocksource: arch_timer: use virtual counters")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSonny Rao <sonnyrao@chromium.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      0b46b8a7
  3. 04 Dec, 2014 4 commits
    • Arnd Bergmann's avatar
      Merge tag 'tegra-for-3.19-iommu' of... · e58e501a
      Arnd Bergmann authored
      Merge tag 'tegra-for-3.19-iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
      
      Pull "ARM: tegra: IOMMU support for v3.19" from Thierry Reding:
      
      This adds the driver pieces required for IOMMU support on Tegra30,
      Tegra114 and Tegra124.
      
      * tag 'tegra-for-3.19-iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
        memory: Add NVIDIA Tegra memory controller support
        of: Add NVIDIA Tegra memory controller binding
        ARM: tegra: Move AHB Kconfig to drivers/amba
        amba: Add Kconfig file
        clk: tegra: Implement memory-controller clock
        powerpc/iommu: Rename iommu_[un]map_sg functions
        iommu: Improve error handling when setting bus iommu
        iommu: Do more input validation in iommu_map_sg()
        iommu: Add iommu_map_sg() function
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      e58e501a
    • Arnd Bergmann's avatar
      Merge tag 'reset-for-3.19-2' of git://git.pengutronix.de/git/pza/linux into next/drivers · a8afa264
      Arnd Bergmann authored
      Pull "Reset controller changes for v3.19" from Philipp Zabel:
      
      This adds a new driver for the sti soc family, and creates
      a reset_control_status interface, which is added to the existing
      drivers.
      
      * tag 'reset-for-3.19-2' of git://git.pengutronix.de/git/pza/linux:
        reset: add socfpga_reset_status
        reset: sti: Document sti-picophyreset controllers bindings.
        reset: stih407: Add softreset, powerdown and picophy controllers
        reset: stih407: Add reset controllers DT bindings
        reset: add reset_control_status helper function
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a8afa264
    • Arnd Bergmann's avatar
      Merge tag 'arm-soc/for-3.19/brcmstb-drivers' of https://github.com/brcm/linux into next/drivers · 136a713d
      Arnd Bergmann authored
      This pull request contains the following changes to the Broadcom GISB bus
      arbiter from Kevin Cernekee:
      
      - Extend brcmstb GISB bus driver to work on MIPS (currently ARM-only) and support
        65nm and 40nm MIPS-based chips such as: BCM7038, BCM7400 and BCM7435
      
      * tag 'arm-soc/for-3.19/brcmstb-drivers' of https://github.com/brcm/linux:
        bus: brcmstb_gisb: Add register offset tables for older chips
        bus: brcmstb_gisb: Look up register offsets in a table
        bus: brcmstb_gisb: Introduce wrapper functions for MMIO accesses
        bus: brcmstb_gisb: Make the driver buildable on MIPS
      
      Conflicts:
      	drivers/bus/brcmstb_gisb.c
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      136a713d
    • Thierry Reding's avatar
      memory: Add NVIDIA Tegra memory controller support · 89184651
      Thierry Reding authored
      The memory controller on NVIDIA Tegra exposes various knobs that can be
      used to tune the behaviour of the clients attached to it.
      
      Currently this driver sets up the latency allowance registers to the HW
      defaults. Eventually an API should be exported by this driver (via a
      custom API or a generic subsystem) to allow clients to register latency
      requirements.
      
      This driver also registers an IOMMU (SMMU) that's implemented by the
      memory controller. It is supported on Tegra30, Tegra114 and Tegra124
      currently. Tegra20 has a GART instead.
      
      The Tegra SMMU operates on memory clients and SWGROUPs. A memory client
      is a unidirectional, special-purpose DMA master. A SWGROUP represents a
      set of memory clients that form a logical functional unit corresponding
      to a single device. Typically a device has two clients: one client for
      read transactions and one client for write transactions, but there are
      also devices that have only read clients, but many of them (such as the
      display controllers).
      
      Because there is no 1:1 relationship between memory clients and devices
      the driver keeps a table of memory clients and the SWGROUPs that they
      belong to per SoC. Note that this is an exception and due to the fact
      that the SMMU is tightly integrated with the rest of the Tegra SoC. The
      use of these tables is discouraged in drivers for generic IOMMU devices
      such as the ARM SMMU because the same IOMMU could be used in any number
      of SoCs and keeping such tables for each SoC would not scale.
      Acked-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      89184651
  4. 28 Nov, 2014 5 commits
  5. 26 Nov, 2014 5 commits
  6. 21 Nov, 2014 3 commits
  7. 20 Nov, 2014 6 commits
  8. 18 Nov, 2014 2 commits
  9. 13 Nov, 2014 9 commits
  10. 12 Nov, 2014 2 commits