1. 07 4月, 2017 8 次提交
  2. 02 3月, 2017 1 次提交
  3. 12 2月, 2017 1 次提交
  4. 08 2月, 2017 3 次提交
  5. 25 12月, 2016 2 次提交
  6. 21 11月, 2016 2 次提交
  7. 24 9月, 2016 2 次提交
  8. 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
  9. 15 7月, 2016 1 次提交
  10. 28 6月, 2016 3 次提交
  11. 03 5月, 2016 3 次提交
  12. 01 3月, 2016 1 次提交
  13. 25 2月, 2016 2 次提交
  14. 01 10月, 2015 1 次提交
  15. 06 8月, 2015 1 次提交
  16. 31 3月, 2015 1 次提交
  17. 26 3月, 2015 1 次提交
  18. 07 1月, 2015 1 次提交
  19. 17 12月, 2014 1 次提交
  20. 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
  21. 27 10月, 2014 1 次提交
  22. 29 9月, 2014 1 次提交