1. 01 8月, 2016 1 次提交
    • M
      clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered · f005bd7e
      Marc Zyngier 提交于
      The ARM architected timer produces level-triggered interrupts (this
      is mandated by the architecture). Unfortunately, a number of
      device-trees get this wrong, and expose an edge-triggered interrupt.
      
      Until now, this wasn't too much an issue, as the programming of the
      trigger would fail (the corresponding PPI cannot be reconfigured),
      and the kernel would be happy with this. But we're about to change
      this, and trust DT a lot if the driver doesn't provide its own
      trigger information. In that context, the timer breaks badly.
      
      While we do need to fix the DTs, there is also some userspace out
      there (kvmtool) that generates the same kind of broken DT on the
      fly, and that will completely break with newer kernels.
      
      As a safety measure, and to keep buggy software alive as well as
      buying us some time to fix DTs all over the place, let's check
      what trigger configuration has been given us by the firmware.
      If this is not a level configuration, then we know that the
      DT/ACPI configuration is bust, and we pick some defaults which
      won't be worse than the existing setup.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Liu Gang <Gang.Liu@nxp.com>
      Cc: Mark Rutland <marc.rutland@arm.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Wenbin Song <Wenbin.Song@freescale.com>
      Cc: Mingkai Hu <Mingkai.Hu@freescale.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Cc: arm@kernel.org
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Ray Jui <rjui@broadcom.com>
      Cc: "Hou Zhiqiang" <B48286@freescale.com>
      Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: Yuan Yao <yao.yuan@nxp.com>
      Cc: Jan Glauber <jglauber@cavium.com>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: linux-amlogic@lists.infradead.org
      Cc: soren.brinkmann@xilinx.com
      Cc: Rajesh Bhagat <rajesh.bhagat@freescale.com>
      Cc: Scott Branden <sbranden@broadcom.com>
      Cc: Duc Dang <dhdang@apm.com>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
      Link: http://lkml.kernel.org/r/1470045256-9032-2-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      f005bd7e
  2. 15 7月, 2016 1 次提交
  3. 28 6月, 2016 3 次提交
  4. 03 5月, 2016 3 次提交
  5. 01 3月, 2016 1 次提交
  6. 25 2月, 2016 2 次提交
  7. 01 10月, 2015 1 次提交
  8. 06 8月, 2015 1 次提交
  9. 31 3月, 2015 1 次提交
  10. 26 3月, 2015 1 次提交
  11. 07 1月, 2015 1 次提交
  12. 17 12月, 2014 1 次提交
  13. 05 12月, 2014 2 次提交
    • D
      clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers · 65b5732d
      Doug Anderson 提交于
      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: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NSonny Rao <sonnyrao@chromium.org>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      65b5732d
    • S
      clocksource: arch_timer: Fix code to use physical timers when requested · 0b46b8a7
      Sonny Rao 提交于
      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: NSonny Rao <sonnyrao@chromium.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      0b46b8a7
  14. 27 10月, 2014 1 次提交
  15. 29 9月, 2014 4 次提交
  16. 29 4月, 2014 1 次提交
    • L
      clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue · 82a56194
      Lorenzo Pieralisi 提交于
      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: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      82a56194
  17. 12 3月, 2014 1 次提交
  18. 16 10月, 2013 1 次提交
  19. 10 10月, 2013 1 次提交
    • S
      arch_timer: Move to generic sched_clock framework · 65cd4f6c
      Stephen Boyd 提交于
      Register with the generic sched_clock framework now that it
      supports 64 bits. This fixes two problems with the current
      sched_clock support for machines using the architected timers.
      First off, we don't subtract the start value from subsequent
      sched_clock calls so we can potentially start off with
      sched_clock returning gigantic numbers. Second, there is no
      support for suspend/resume handling so problems such as discussed
      in 6a4dae5e (ARM: 7565/1: sched: stop sched_clock() during
      suspend, 2012-10-23) can happen without this patch. Finally, it
      allows us to move the sched_clock setup into drivers clocksource
      out of the arch ports.
      
      Cc: Christopher Covington <cov@codeaurora.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      65cd4f6c
  20. 02 10月, 2013 1 次提交
  21. 26 9月, 2013 2 次提交
  22. 01 8月, 2013 4 次提交
  23. 15 7月, 2013 1 次提交
    • P
      clocksource+irqchip: delete __cpuinit usage from all related files · 8c37bb3a
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      This removes all the drivers/clocksource and drivers/irqchip uses of
      the __cpuinit macros from all C files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8c37bb3a
  24. 07 6月, 2013 1 次提交
    • M
      clocksource: arch_timer: use virtual counters · 0d651e4e
      Mark Rutland 提交于
      Switching between reading the virtual or physical counters is
      problematic, as some core code wants a view of time before we're fully
      set up. Using a function pointer and switching the source after the
      first read can make time appear to go backwards, and having a check in
      the read function is an unfortunate block on what we want to be a fast
      path.
      
      Instead, this patch makes us always use the virtual counters. If we're a
      guest, or don't have hyp mode, we'll use the virtual timers, and as such
      don't care about CNTVOFF as long as it doesn't change in such a way as
      to make time appear to travel backwards. As the guest will use the
      virtual timers, a (potential) KVM host must use the physical timers
      (which can wake up the host even if they fire while a guest is
      executing), and hence a host must have CNTVOFF set to zero so as to have
      a consistent view of time between the physical timers and virtual
      counters.
      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: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Rob Herring <rob.herring@calxeda.com>
      0d651e4e
  25. 27 4月, 2013 1 次提交
    • S
      ARM: arch_timer: Silence debug preempt warnings · f31c2f1c
      Stephen Boyd 提交于
      Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
      architected timers causes a slew of "using smp_processor_id() in
      preemptible" warnings:
      
        BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
        caller is arch_timer_cpu_notify+0x14/0xc8
      
      This happens because sometimes the cpu notifier,
      arch_timer_cpu_notify(), is called in preemptible context and
      other times in non-preemptible context but we use this_cpu_ptr()
      to retrieve the clockevent in all cases. We're only going to
      actually use the pointer in non-preemptible context though, so
      push the this_cpu_ptr() access down into the cases to force the
      checks to occur only in non-preemptible contexts.
      
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: NMarc Zyngier <Marc.Zyngier@arm.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      f31c2f1c
  26. 12 4月, 2013 1 次提交
    • R
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init · 0583fe47
      Rob Herring 提交于
      This converts arm and arm64 to use CLKSRC_OF DT based initialization for
      the arch timer. A new function arch_timer_arch_init is added to allow for
      arch specific setup.
      
      This has a side effect of enabling sched_clock on omap5 and exynos5. There
      should not be any reason not to use the arch timers for sched_clock.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      0583fe47
  27. 31 1月, 2013 1 次提交