renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-29 15:43:59 +08:00
Code
cb2e3d461b
linux-next/Documentation/devicetree/bindings/arm/arch_timer.txt

114 lines
3.7 KiB
Plaintext
Raw Normal View History

ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
* ARM architected timer
Documentation: Add memory mapped ARM architected timer binding Add a binding for the arm architected timer hardware's memory mapped interface. The mmio timer hardware is made up of one base frame and a collection of up to 8 timer frames, where each of the 8 timer frames can have either one or two views. A frame typically maps to a privilege level (user/kernel, hypervisor, secure). The first view has full access to the registers within a frame, while the second view can be restricted to particular registers within a frame. Each frame must support a physical timer. It's optional for a frame to support a virtual timer. Cc: devicetree-discuss@lists.ozlabs.org Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robherring2@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
2013-07-19 07:59:29 +08:00
ARM cores may have a per-core architected timer, which provides per-cpu timers,
or a memory mapped architected timer, which provides up to 8 frames with a
physical and optional virtual timer per frame.
ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
Documentation: Add memory mapped ARM architected timer binding Add a binding for the arm architected timer hardware's memory mapped interface. The mmio timer hardware is made up of one base frame and a collection of up to 8 timer frames, where each of the 8 timer frames can have either one or two views. A frame typically maps to a privilege level (user/kernel, hypervisor, secure). The first view has full access to the registers within a frame, while the second view can be restricted to particular registers within a frame. Each frame must support a physical timer. It's optional for a frame to support a virtual timer. Cc: devicetree-discuss@lists.ozlabs.org Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robherring2@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
2013-07-19 07:59:29 +08:00
The per-core architected timer is attached to a GIC to deliver its
per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
to deliver its interrupts via SPIs.
ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
Documentation: Add memory mapped ARM architected timer binding Add a binding for the arm architected timer hardware's memory mapped interface. The mmio timer hardware is made up of one base frame and a collection of up to 8 timer frames, where each of the 8 timer frames can have either one or two views. A frame typically maps to a privilege level (user/kernel, hypervisor, secure). The first view has full access to the registers within a frame, while the second view can be restricted to particular registers within a frame. Each frame must support a physical timer. It's optional for a frame to support a virtual timer. Cc: devicetree-discuss@lists.ozlabs.org Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robherring2@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
2013-07-19 07:59:29 +08:00
** CP15 Timer node properties:
ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
Documentation: Add ARMv8 to arch_timer devicetree Currently the documentation for the arch_timer devicetree binding only lists "arm,armv7-timer". Add "arm,armv8-timer" to the list of compatible strings. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-11-20 19:44:15 +08:00
- compatible : Should at least contain one of
"arm,armv7-timer"
"arm,armv8-timer"
ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
- interrupts : Interrupt list for secure, non-secure, virtual and
hypervisor timers, in that order.
Doc: dt: arch_timer: discourage clock-frequency use 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: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-03-21 01:57:47 +08:00
- clock-frequency : The frequency of the main counter, in Hz. Should be present
only where necessary to work around broken firmware which does not configure
CNTFRQ on all CPUs to a uniform correct value. Use of this property is
strongly discouraged; fix your firmware unless absolutely impossible.
ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue ARM arch timers are tightly coupled with the CPU logic and lose context on platform implementing HW power management when cores are powered down at run-time. Marking the arch timers as C3STOP regardless of power management capabilities causes issues on platforms with no power management, since in that case the arch timers cannot possibly enter states where the timer loses context at runtime and therefore can always be used as a high resolution clockevent device. In order to fix the C3STOP issue in a way compliant with how real HW works, this patch adds a boolean property to the arch timer bindings to define if the arch timer is managed by an always-on power domain. This power domain is present on all ARM platforms to date, and manages HW that must not be turned off, whatever the state of other HW components (eg power controller). On platforms with no power management capabilities, it is the only power domain present, which encompasses and manages power supply for all HW components in the system. If the timer is powered by the always-on power domain, the always-on property must be present in the bindings which means that the timer cannot be shutdown at runtime, so it is not a C3STOP clockevent device. If the timer binding does not contain the always-on property, the timer is assumed to be power-gateable, hence it must be defined as a C3STOP clockevent device. Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Magnus Damm <damm@opensource.se> Cc: Marc Carino <marc.ceeeee@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2014-04-08 17:04:32 +08:00
- always-on : a boolean property. If present, the timer is powered through an
always-on power domain, therefore it never loses context.
arm64: arch_timer: Add device tree binding for A-008585 erratum This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree. Signed-off-by: Scott Wood <oss@buserror.net> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-09-22 16:35:15 +08:00
- fsl,erratum-a008585 : A boolean property. Indicates the presence of
QorIQ erratum A-008585, which says that reading the counter is
unreliable unless the same value is returned by back-to-back reads.
This also affects writes to the tval register, due to the implicit
counter read.
clocksource/drivers/arm_arch_timer: Add dt binding for hisilicon-161010101 erratum This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2017-02-07 00:47:39 +08:00
- hisilicon,erratum-161010101 : A boolean property. Indicates the
presence of Hisilicon erratum 161010101, which says that reading the
counters is unreliable in some cases, and reads may return a value 32
beyond the correct value. This also affects writes to the tval
registers, due to the implicit counter read.
clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers 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: Doug Anderson <dianders@chromium.org> Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2014-10-08 15:33:47 +08:00
** Optional properties:
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
any of the generic timer CPU registers, which contain their
architecturally-defined reset values. Only supported for 32-bit
systems which follow the ARMv7 architected reset values.
clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend The ARM specifies that the system counter "must be implemented in an always-on power domain," and so we try to use the counter as a source of timekeeping across suspend/resume. Unfortunately, some SoCs (e.g., Rockchip's RK3399) do not keep the counter ticking properly when switched from their high-power clock to the lower-power clock used in system suspend. Support this quirk by adding a new device tree property. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2016-10-05 02:12:09 +08:00
- arm,no-tick-in-suspend : The main counter does not tick when the system is in
low-power system suspend on some SoCs. This behavior does not match the
Architecture Reference Manual's specification that the system counter "must
be implemented in an always-on power domain."
clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers 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: Doug Anderson <dianders@chromium.org> Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2014-10-08 15:33:47 +08:00
ARM: architected timers: add DT support Add runtime DT support and documentation for the Cortex A7/A15 architected timers. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2012-01-19 21:53:50 +08:00
Example:
timer {
compatible = "arm,cortex-a15-timer",
"arm,armv7-timer";
interrupts = <1 13 0xf08>,
<1 14 0xf08>,
<1 11 0xf08>,
<1 10 0xf08>;
clock-frequency = <100000000>;
};
Documentation: Add memory mapped ARM architected timer binding Add a binding for the arm architected timer hardware's memory mapped interface. The mmio timer hardware is made up of one base frame and a collection of up to 8 timer frames, where each of the 8 timer frames can have either one or two views. A frame typically maps to a privilege level (user/kernel, hypervisor, secure). The first view has full access to the registers within a frame, while the second view can be restricted to particular registers within a frame. Each frame must support a physical timer. It's optional for a frame to support a virtual timer. Cc: devicetree-discuss@lists.ozlabs.org Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robherring2@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
2013-07-19 07:59:29 +08:00
** Memory mapped timer node properties:
- compatible : Should at least contain "arm,armv7-timer-mem".
Doc: dt: arch_timer: discourage clock-frequency use 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: Mark Rutland <mark.rutland@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
2015-03-21 01:57:47 +08:00
- clock-frequency : The frequency of the main counter, in Hz. Should be present
only when firmware has not configured the MMIO CNTFRQ registers.
Documentation: Add memory mapped ARM architected timer binding Add a binding for the arm architected timer hardware's memory mapped interface. The mmio timer hardware is made up of one base frame and a collection of up to 8 timer frames, where each of the 8 timer frames can have either one or two views. A frame typically maps to a privilege level (user/kernel, hypervisor, secure). The first view has full access to the registers within a frame, while the second view can be restricted to particular registers within a frame. Each frame must support a physical timer. It's optional for a frame to support a virtual timer. Cc: devicetree-discuss@lists.ozlabs.org Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robherring2@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
2013-07-19 07:59:29 +08:00
- reg : The control frame base address.
Note that #address-cells, #size-cells, and ranges shall be present to ensure
the CPU can address a frame's registers.
A timer node has up to 8 frame sub-nodes, each with the following properties:
- frame-number: 0 to 7.
- interrupts : Interrupt list for physical and virtual timers in that order.
The virtual timer interrupt is optional.
- reg : The first and second view base addresses in that order. The second view
base address is optional.
- status : "disabled" indicates the frame is not available for use. Optional.
Example:
timer@f0000000 {
compatible = "arm,armv7-timer-mem";
#address-cells = <1>;
#size-cells = <1>;
ranges;
reg = <0xf0000000 0x1000>;
clock-frequency = <50000000>;
frame@f0001000 {
frame-number = <0>
interrupts = <0 13 0x8>,
<0 14 0x8>;
reg = <0xf0001000 0x1000>,
<0xf0002000 0x1000>;
};
frame@f0003000 {
frame-number = <1>
interrupts = <0 15 0x8>;
reg = <0xf0003000 0x1000>;
status = "disabled";
};
};
Copy Permalink