Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 18 7月, 2015 1 次提交
  3. 25 6月, 2015 1 次提交
  5. 12 6月, 2015 1 次提交
  7. 11 6月, 2015 1 次提交
  9. 06 6月, 2015 1 次提交
  11. 05 6月, 2015 1 次提交
  13. 03 6月, 2015 1 次提交
  15. 02 6月, 2015 1 次提交
  17. 29 5月, 2015 1 次提交
    • S
      arm-cci: Add CCI-500 PMU support · a95791ef
      由 Suzuki K. Poulose 提交于 
      CCI-500 provides 8 event counters which can count any of the
supported events independently. The PMU event id is a 9-bit
value made of two parts.
	bits [8:5] - Source port
			0x0-0x6 Slave Ports
			0x8-0xD Master Ports
			0xf     Global Events to CCI
			0x7,0xe Reserved
	bits [0:4] - Event code (specific to each type of port)

The generic CCI-500 controlling interface remains the same with CCI-400.
However there are some differences in the PMU event counters.
 - No cycle counter
 - Upto 8 counters(4 in CCI-400)
 - Each counter area is 64K(4K in CCI400)
 - The counter0 starts at offset 0x10000 from the base of CCI

Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: NSuzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: NPunit Agrawal <punit.agrawal@arm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      a95791ef
  19. 25 5月, 2015 2 次提交
  21. 22 5月, 2015 1 次提交
  23. 21 5月, 2015 1 次提交
    • S
      ARM: vf610: enable Cortex-M4 configuration on Vybrid SoC · 8064887e
      由 Stefan Agner 提交于 
      This patch allows to build the Kernel for Vybrid (VF6xx) SoC
when ARMv7-M CPU is selected. The resulting image runs on the
secondary Cortex-M4 core. This core has equally access to all
peripherals as the main Cortex-A5 core. However, there is no
resource control mechanism, hence when both cores are used
simultaneously, orthogonal device tree's are required.

The boot CPU is dependent on the SoC variant. The available
boards use mostly variants where the Cortex-A5 is the primary
and hence the boot CPU. Booting the secondary Cortex-M4 CPU
needs SoC specific registers written. There is no in kernel
support for this right now, a external userspace utility
called "m4boot" can be used to boot the kernel:

m4boot xipImage initramfs.cpio.lzo vf610m4-colibri.dtb
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      8064887e
  25. 20 5月, 2015 1 次提交
  27. 18 5月, 2015 2 次提交
  29. 16 5月, 2015 6 次提交
  31. 14 5月, 2015 3 次提交
  33. 08 5月, 2015 1 次提交
  35. 06 5月, 2015 1 次提交
  37. 05 5月, 2015 1 次提交
    • S
      bus: omap_l3_noc: Fix master id address decoding for OMAP5 · e7309c26
      由 Suman Anna 提交于 
      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:

  1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
     11 bits on OMAP5 as against 8 bits on OMAP4, with the master
     NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
     field.
  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: NSuman Anna <s-anna@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      e7309c26
  39. 27 4月, 2015 1 次提交
  41. 23 4月, 2015 1 次提交
  43. 22 4月, 2015 1 次提交
  45. 16 4月, 2015 1 次提交
    • M
      Doc: dt: arch_timer: discourage clock-frequency use · 4155fc07
      由 Mark Rutland 提交于 
      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: NMark Rutland <mark.rutland@arm.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
      4155fc07
  47. 04 4月, 2015 3 次提交
  49. 03 4月, 2015 1 次提交
  51. 02 4月, 2015 1 次提交
    • P
      ARM: 8335/1: Documentation: DT bindings: Tegra AHB: document the legacy base address · 38e42f12
      由 Paul Walmsley 提交于 
      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: NPaul 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: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      38e42f12
  53. 01 4月, 2015 3 次提交