1. 02 Jun, 2015 1 commit
  2. 04 May, 2015 1 commit
    • Suman Anna's avatar
      bus: omap_l3_noc: Fix master id address decoding for OMAP5 · e7309c26
      Suman Anna authored
      The L3 Error handling on OMAP5 for the most part is very similar
      to that of OMAP4, and had leveraged common data structures and
      register layout definitions so far. Upon closer inspection, there
      are a few minor differences causing an incorrect decoding and
      reporting of the master NIU upon an error:
           11 bits on OMAP5 as against 8 bits on OMAP4, with the master
           NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
        2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
           input sources on OMAP5. The common DEBUGSS source is at a
           different input on each SoC.
      Fix the above issues by using a OMAP5-specific compatible property
      and using SoC-specific data where there are differences.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Acked-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  3. 22 Apr, 2015 2 commits
  4. 16 Apr, 2015 1 commit
    • Mark Rutland's avatar
      Doc: dt: arch_timer: discourage clock-frequency use · 4155fc07
      Mark Rutland authored
      The ARM Generic Timer (AKA the architected timer, arm_arch_timer)
      features a CPU register (CNTFRQ) which firmware is intended to
      initialize, and non-secure software can read to determine the frequency
      of the timer. On CPUs with secure state, this register cannot be written
      from non-secure states.
      The firmware of early SoCs featuring the timer did not correctly
      initialize CNTFRQ correctly on all CPUs, requiring the frequency to be
      described in DT as a workaround. This workaround is not complete however
      as it is exposed to all software in a privileged non-secure mode
      (including guests running under a hypervisor). The firmware and DTs for
      recent SoCs have followed the example set by these early SoCs.
      This patch updates the arch timer binding documentation to make it
      clearer that the use of the clock-frequency property is a poor
      work-around. The MMIO generic timer binding is similarly updated, though
      this is less of a concern as there is generally no need to expose the
      MMIO timers to guest OSs.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
  5. 03 Apr, 2015 4 commits
  6. 02 Apr, 2015 1 commit
    • Paul Walmsley's avatar
      ARM: 8335/1: Documentation: DT bindings: Tegra AHB: document the legacy base address · 38e42f12
      Paul Walmsley authored
      Documentation: DT bindings: Tegra AHB: require the legacy base address for existing chips
      Per Stephen Warren, note in the Tegra AHB DT binding documentation
      that we specifically deprecate any attempt to use the IP block's
      actual hardware base address, and advocate the use of the legacy
      "off-by-four" address in the 'regs' property, for Tegra chips with
      existing upstream Linux DT files that include a Tegra AHB node.  This
      patch updates the documentation accordingly.
      Changing the existing kernel DT data isn't under consideration because
      Linux kernel DT data policy is to preserve compatibility between newer
      DT data files and older kernels.  However, this additional step of
      changing the documentation should discourage others from sending
      kernel patches to try to change the legacy kernel DT data.
      Furthermore, for out-of-tree software (such as bootloaders or other
      operating systems) that may rely on Linux kernel DT binding
      documentation as an ABI (but not the Linux kernel DT data itself),
      such a change may allow future convergence with the Linux kernel DT
      data without additional code changes.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Paul Walmsley <pwalmsley@nvidia.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Eduardo Valentin <edubezval@gmail.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  7. 31 Mar, 2015 7 commits
  8. 30 Mar, 2015 1 commit
  9. 27 Mar, 2015 1 commit
    • Suzuki K. Poulose's avatar
      arm-cci: Get rid of secure transactions for PMU driver · 772742a6
      Suzuki K. Poulose authored
      Avoid secure transactions while probing the CCI PMU. The
      existing code makes use of the Peripheral ID2 (PID2) register
      to determine the revision of the CCI400, which requires a
      secure transaction. This puts a limitation on the usage of the
      driver on systems running non-secure Linux(e.g, ARM64).
      Updated the device-tree binding for cci pmu node to add the explicit
      revision number for the compatible field.
      The supported strings are :
      	arm,cci-400-pmu - DEPRECATED. See NOTE below
      NOTE: If the revision is not mentioned, we need to probe the cci revision,
      which could be fatal on a platform running non-secure. We need a reliable way
      to know if we can poke the CCI registers at runtime on ARM32. We depend on
      'mcpm_is_available()' when it is available. mcpm_is_available() returns true
      only when there is a registered driver for mcpm. Otherwise, we assume that we
      don't have secure access, and skips probing the revision number(ARM64 case).
      The MCPM should figure out if it is safe to access the CCI. Unfortunately
      there isn't a reliable way to indicate the same via dtb. This patch doesn't
      address/change the current situation. It only deals with the CCI-PMU, leaving
      the assumptions about the secure access as it has been, prior to this patch.
      Cc: devicetree@vger.kernel.org
      Cc: Punit Agrawal <punit.agrawal@arm.com>
      Tested-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  10. 26 Mar, 2015 1 commit
  11. 25 Mar, 2015 1 commit
  12. 24 Mar, 2015 1 commit
  13. 18 Mar, 2015 1 commit
  14. 17 Mar, 2015 2 commits
  15. 16 Mar, 2015 2 commits
  16. 14 Mar, 2015 2 commits
  17. 11 Mar, 2015 2 commits
  18. 07 Mar, 2015 1 commit
  19. 04 Mar, 2015 3 commits
  20. 02 Mar, 2015 1 commit
  21. 26 Feb, 2015 1 commit
  22. 23 Feb, 2015 3 commits