summaryrefslogtreecommitdiffstats
path: root/drivers/clocksource (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2017-05-121-1/+1
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Ingo Molnar: "A single ARM Juno clocksource driver fix" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource/arm_arch_timer: Fix arch_timer_mem_find_best_frame()
| * clocksource/arm_arch_timer: Fix arch_timer_mem_find_best_frame()Sudeep Holla2017-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arch_timer_mem_find_best_frame() looks through ARCH_TIMER_MEM_MAX_FRAMES frames even after finding matches to ensure the best frame is chosen, which means the variable frame will point to the last valid frame but not necessarily the best frame. On Juno, we get the following error as the wrong frame is returned as the best frame from arch_timer_mem_find_best_frame(): arch_timer: Unable to map frame @ 0x0000000000000000 arch_timer: Frame missing phys irq. Failed to initialize '/timer@2a810000': -22 Fix the issue by correctly returning the best frame from arch_timer_mem_find_best_frame(). Fixes: c389d701dfb7 ("clocksource: arm_arch_timer: split MMIO timer probing.") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1494246747-17267-1-git-send-email-sudeep.holla@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | Merge tag 'hwparam-20170420' of ↵Linus Torvalds2017-05-111-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull hw lockdown support from David Howells: "Annotation of module parameters that configure hardware resources including ioports, iomem addresses, irq lines and dma channels. This allows a future patch to prohibit the use of such module parameters to prevent that hardware from being abused to gain access to the running kernel image as part of locking the kernel down under UEFI secure boot conditions. Annotations are made by changing: module_param(n, t, p) module_param_named(n, v, t, p) module_param_array(n, t, m, p) to: module_param_hw(n, t, hwtype, p) module_param_hw_named(n, v, t, hwtype, p) module_param_hw_array(n, t, hwtype, m, p) where the module parameter refers to a hardware setting hwtype specifies the type of the resource being configured. This can be one of: ioport Module parameter configures an I/O port iomem Module parameter configures an I/O mem address ioport_or_iomem Module parameter could be either (runtime set) irq Module parameter configures an I/O port dma Module parameter configures a DMA channel dma_addr Module parameter configures a DMA buffer address other Module parameter configures some other value Note that the hwtype is compile checked, but not currently stored (the lockdown code probably won't require it). It is, however, there for future use. A bonus is that the hwtype can also be used for grepping. The intention is for the kernel to ignore or reject attempts to set annotated module parameters if lockdown is enabled. This applies to options passed on the boot command line, passed to insmod/modprobe or direct twiddling in /sys/module/ parameter files. The module initialisation then needs to handle the parameter not being set, by (1) giving an error, (2) probing for a value or (3) using a reasonable default. What I can't do is just reject a module out of hand because it may take a hardware setting in the module parameters. Some important modules, some ipmi stuff for instance, both probe for hardware and allow hardware to be manually specified; if the driver is aborts with any error, you don't get any ipmi hardware. Further, trying to do this entirely in the module initialisation code doesn't protect against sysfs twiddling. [!] Note that in and of itself, this series of patches should have no effect on the the size of the kernel or code execution - that is left to a patch in the next series to effect. It does mark annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in an already existing field" * tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits) Annotate hardware config module parameters in sound/pci/ Annotate hardware config module parameters in sound/oss/ Annotate hardware config module parameters in sound/isa/ Annotate hardware config module parameters in sound/drivers/ Annotate hardware config module parameters in fs/pstore/ Annotate hardware config module parameters in drivers/watchdog/ Annotate hardware config module parameters in drivers/video/ Annotate hardware config module parameters in drivers/tty/ Annotate hardware config module parameters in drivers/staging/vme/ Annotate hardware config module parameters in drivers/staging/speakup/ Annotate hardware config module parameters in drivers/staging/media/ Annotate hardware config module parameters in drivers/scsi/ Annotate hardware config module parameters in drivers/pcmcia/ Annotate hardware config module parameters in drivers/pci/hotplug/ Annotate hardware config module parameters in drivers/parport/ Annotate hardware config module parameters in drivers/net/wireless/ Annotate hardware config module parameters in drivers/net/wan/ Annotate hardware config module parameters in drivers/net/irda/ Annotate hardware config module parameters in drivers/net/hamradio/ Annotate hardware config module parameters in drivers/net/ethernet/ ...
| * Annotate hardware config module parameters in drivers/clocksource/David Howells2017-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/clocksource/. [Note: With regard to cs5535-clockevt.c, Thomas Gleixner asked whether the timer_irq parameter is required for the driver to work on anything other than arbitrary hardware which has it mapped to 0. Jens Rottmann replied that the parameter defaults to 0, which means: 1. autodetect (=keep IRQ BIOS has set up) 2. if that fails use CONFIG_CS5535_MFGPT_DEFAULT_IRQ (see drivers/misc/cs5535-mfgpt.c: cs5535_mfgpt_set_irq()) Jens further noted that there may not be any systems that have CS5535/36 devices that support EFI and secure boot.] Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> cc: Daniel Lezcano <daniel.lezcano@linaro.org> cc: Thomas Gleixner <tglx@linutronix.de> cc: Jens Rottmann <Jens.Rottmann@ADLINKtech.com> cc: linux-kernel@vger.kernel.org
* | Merge branch 'timers-core-for-linus' of ↵Linus Torvalds2017-05-0236-637/+1180
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer updates from Thomas Gleixner: "The timer departement delivers: - more year 2038 rework - a massive rework of the arm achitected timer - preparatory patches to allow NTP correction of clock event devices to avoid early expiry - the usual pile of fixes and enhancements all over the place" * 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (91 commits) timer/sysclt: Restrict timer migration sysctl values to 0 and 1 arm64/arch_timer: Mark errata handlers as __maybe_unused Clocksource/mips-gic: Remove redundant non devicetree init MIPS/Malta: Probe gic-timer via devicetree clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver clocksource: arm_arch_timer: add GTDT support for memory-mapped timer acpi/arm64: Add memory-mapped timer support in GTDT driver clocksource: arm_arch_timer: simplify ACPI support code. acpi/arm64: Add GTDT table parse driver clocksource: arm_arch_timer: split MMIO timer probing. clocksource: arm_arch_timer: add structs to describe MMIO timer clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init call clocksource: arm_arch_timer: refactor arch_timer_needs_probing clocksource: arm_arch_timer: split dt-only rate handling x86/uv/time: Set ->min_delta_ticks and ->max_delta_ticks unicore32/time: Set ->min_delta_ticks and ->max_delta_ticks um/time: Set ->min_delta_ticks and ->max_delta_ticks tile/time: Set ->min_delta_ticks and ->max_delta_ticks score/time: Set ->min_delta_ticks and ->max_delta_ticks ...
| * | arm64/arch_timer: Mark errata handlers as __maybe_unusedArnd Bergmann2017-04-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some rare randconfig builds, we end up with two functions being entirely unused: drivers/clocksource/arm_arch_timer.c:342:12: error: 'erratum_set_next_event_tval_phys' defined but not used [-Werror=unused-function] static int erratum_set_next_event_tval_phys(unsigned long evt, drivers/clocksource/arm_arch_timer.c:335:12: error: 'erratum_set_next_event_tval_virt' defined but not used [-Werror=unused-function] static int erratum_set_next_event_tval_virt(unsigned long evt, We could add an #ifdef around them, but we would already have to check for several symbols there and there is a chance this would get more complicated over time, so marking them as __maybe_unused is the simplest way to avoid the harmless warnings. Fixes: 01d3e3ff2608 ("arm64: arch_timer: Rework the set_next_event workarounds") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Christoffer Dall <christoffer.dall@linaro.org> Link: http://lkml.kernel.org/r/20170419173737.3846098-1-arnd@arndb.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | Clocksource/mips-gic: Remove redundant non devicetree initMatt Redfearn2017-04-201-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Malta was the only platform probing this driver from platform code without using device tree. With that code removed, gic_clocksource_init is redundant so remove it. Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Ralf Baechle <ralf@linux-mips.org> Link: http://lkml.kernel.org/r/1492604806-23420-2-git-send-email-matt.redfearn@imgtec.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | Merge tag 'arch-timer-gtdt' of ↵Thomas Gleixner2017-04-201-202/+371
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux into timers/core Pull arch timer GTDT support from Mark Rutland - arch_timer cleanups and refactoring - new common GTDT parser - GTDT-based MMIO arch_timer support - GTDT-based SBSA watchdog support Fix up a trivial pr_err() conflict.
| | * | clocksource: arm_arch_timer: add GTDT support for memory-mapped timerFu Wei2017-04-191-3/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch add memory-mapped timer register support by using the information provided by the new GTDT driver of ACPI. Signed-off-by: Fu Wei <fu.wei@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> [Mark: verify CNTFRQ, only register the first frame] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: simplify ACPI support code.Fu Wei2017-04-191-30/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch update arm_arch_timer driver to use the function provided by the new GTDT driver of ACPI. By this way, arm_arch_timer.c can be simplified, and separate all the ACPI GTDT knowledge from this timer driver. Signed-off-by: Fu Wei <fu.wei@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: split MMIO timer probing.Fu Wei2017-04-191-44/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the code to probe MMIO architected timers mixes DT parsing with actual poking of hardware. This makes the code harder than necessary to understand, and makes it difficult to add support for probing via ACPI. This patch splits the DT parsing from HW probing. The DT parsing now lives in arch_timer_mem_of_init(), which fills in an arch_timer_mem structure that it hands to probing functions that can be reused for ACPI support. Since the rate detection logic will be slight different when using ACPI, the probing is performed as a number of steps. This results in more code for the moment, and some arguably redundant work, but simplifies matters considerably when ACPI support is added. Signed-off-by: Fu Wei <fu.wei@linaro.org> [Mark: refactor the probing split] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init callFu Wei2017-04-191-25/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To cleanly split code paths specific to ACPI or DT at a higher level, this patch removes arch_timer_init(), folding the relevant parts of its logic into existing callers. This pathes the way for further rework, and saves a few lines. Signed-off-by: Fu Wei <fu.wei@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: refactor arch_timer_needs_probingFu Wei2017-04-191-15/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When booting with DT, it's possible for timer nodes to be probed in any order. Some common initialisation needs to occur after all nodes have been probed, and arch_timer_common_init() has code to detect when this has happened. This logic is DT-specific, and it would be best to factor it out of the common code that will be shared with ACPI. This patch folds this into the existing arch_timer_needs_probing(), which is renamed to arch_timer_needs_of_probing(), and no longer takes any arguments. This is only called when using DT, and not when using ACPI, which will have a deterministic probe order. Signed-off-by: Fu Wei <fu.wei@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: split dt-only rate handlingFu Wei2017-04-191-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For historical reasons, rate detection when probing via DT is somewhat convoluted. We tried to package this up in arch_timer_detect_rate(), but with the addition of ACPI worse, and gets in the way of stringent rate checking when ACPI is used. This patch makes arch_timer_detect_rate() specific to DT, ripping out ACPI logic. In preparation for rework of the MMIO timer probing, the reading of the relevant CNTFRQ register is factored out to callers. The function is then renamed to arch_timer_of_configure_rate(), which better represents its new place in the world. Comments are added in the DT and ACPI probe paths to explain this. Signed-off-by: Fu Wei <fu.wei@linaro.org> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: rework PPI selectionFu Wei2017-04-101-31/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to mean the driver will use the secure PPI *and* potentially also use the non-secure PPI. This is somewhat confusing. For arm64 it never makes sense to use the secure PPI, but we do anyway, inheriting this behaviour from 32-bit arm. For ACPI, we may not even have a valid secure PPI, so we need to be able to only request the non-secure PPI. To that end, this patch reworks the timer driver so that we can request the non-secure PPI alone. The PPI selection is split out into a new function, arch_timer_select_ppi(), and verification of the selected PPI is shifted out to callers (as DT may select the PPI by other means and must handle this anyway). We now consistently use arch_timer_has_nonsecure_ppi() to determine whether we must manage a non-secure PPI *in addition* to a secure PPI. When we only have a non-secure PPI, this returns false. Signed-off-by: Fu Wei <fu.wei@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: add a new enum for spi typeFu Wei2017-04-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch add a new enum "arch_timer_spi_nr" and use it in the driver. Just for code's readability, no functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: move enums and defines to header fileFu Wei2017-04-101-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support the arm_arch_timer via ACPI we need to share defines and enums between the driver and the ACPI parser code. So we split out the relevant defines and enums into arm_arch_timer.h. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: rename the PPI enumFu Wei2017-04-101-40/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for moving the PPI enum out into a header, rename the enum and its constituent values these so they are namespaced w.r.t. the arch timer. This will aid consistency and avoid potential name clashes when this move occurs. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: rename type macrosFu Wei2017-04-101-20/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for moving the type macros out into a header, rename these so they are namespaced w.r.t. the arch timer. We'll apply the same prefix to other definitions in subsequent patches. This will aid consistency and avoid potential name clahses when this move occurs. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| | * | clocksource: arm_arch_timer: clean up printk usageFu Wei2017-04-101-24/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost all string in the arm_arch_timer driver duplicate an common prefix (though a few do not). For consistency, it would be better to use pr_fmt(), and always use this prefix. At the same time, we may as well clean up some whitespace issues in arch_timer_banner and arch_timer_init. No functional change. Signed-off-by: Fu Wei <fu.wei@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [Mark: reword commit message] Signed-off-by: Mark Rutland <mark.rutland@arm.com>
| * | | Merge branch 'clockevents/4.12' of ↵Thomas Gleixner2017-04-1729-362/+736
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.linaro.org/people/daniel.lezcano/linux into timers/core Pull clockevents updates from Daniel Lezcano - Provide a framework to handle errata gracefuly for arm_arch_timer (Mark Zyngier) - Clarify the DT properties for the rockchip timer and add the clocksource as an alternative to the bogus architected timer (Alexander Kochetkov) - Rename the Gemini timer to Faraday timer fttmr010 and provide a specific initialization for Gemini (Linus Walleij) - Add missing newlines in the error message in the timers (Rafał Miłecki) - Read the clock once and implement the delay timer on Orion (Russell King)
| | * | | Merge tag 'arch-timer-errata' of ↵Daniel Lezcano2017-04-072-159/+387
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into clockevents/4.12 arm64 arch timer workaround series, including the base patches that will also go via the arm64 tree. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| | | * | arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching dataMarc Zyngier2017-04-071-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to deal with ACPI enabled platforms suffering from the HISILICON_ERRATUM_161010101, let's add the required OEM data that allow the workaround to be enabled. Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: dann frazier <dann.frazier@canonical.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Allow erratum matching with ACPI OEM informationMarc Zyngier2017-04-071-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just as we're able to identify a broken platform using some DT information, let's enable a way to spot the offenders with ACPI. The difference is that we can only match on some OEM info instead of implementation-specific properties. So in order to avoid the insane multiplication of errata structures, we allow an array of OEM descriptions to be attached to an erratum structure. Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: dann frazier <dann.frazier@canonical.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Workaround for Cortex-A73 erratum 858921Marc Zyngier2017-04-072-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cortex-A73 (all versions) counter read can return a wrong value when the counter crosses a 32bit boundary. The workaround involves performing the read twice, and to return one or the other depending on whether a transition has taken place. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabledMarc Zyngier2017-04-071-13/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace being allowed to use read CNTVCT_EL0 anytime (and not only in the VDSO), we need to enable trapping whenever a cntvct workaround is enabled on a given CPU. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Save cntkctl_el1 as a per-cpu variableMarc Zyngier2017-04-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we're about to allow per CPU cntkctl_el1 configuration, we cannot rely on the register value to be common when performing power management. Let's turn saved_cntkctl into a per-cpu variable. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Move clocksource_counter and co aroundMarc Zyngier2017-04-071-31/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to access clocksource_counter from the errata handling code, move it (together with the related structures and functions) towards the top of the file. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUsMarc Zyngier2017-04-071-12/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of applying a CPU-specific workaround to all CPUs in the system, allow it to only affect a subset of them (typical big-little case). This is done by turning the erratum pointer into a per-CPU variable. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Rework the set_next_event workaroundsMarc Zyngier2017-04-071-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way we work around errata affecting set_next_event is not very nice, at it imposes this workaround on errata that do not need it. Add new workaround hooks and let the existing workarounds use them. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Get rid of erratum_workaround_set_sneMarc Zyngier2017-04-071-49/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's move the handling of workarounds affecting set_next_event to the affected function, instead of overriding the pointers as an afterthough. Yes, this is an extra indirection on the erratum handling path, but the HW is busted anyway. This will allow for some more flexibility later. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Move arch_timer_reg_read/write aroundMarc Zyngier2017-04-071-62/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we're about to move things around, let's start with the low level read/write functions. This allows us to use these functions in the errata handling code without having to use forward declaration of static functions. Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Add erratum handler for CPU-specific capabilityMarc Zyngier2017-04-071-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Should we ever have a workaround for an erratum that is detected using a capability and affecting a particular CPU, it'd be nice to have a way to probe them directly. Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | | * | arm64: arch_timer: Add infrastructure for multiple erratum detection methodsMarc Zyngier2017-04-071-11/+72
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're currently stuck with DT when it comes to handling errata, which is pretty restrictive. In order to make things more flexible, let's introduce an infrastructure that could support alternative discovery methods. No change in functionality. Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
| | * | clocksource/drivers/fttmr010: Refactor to handle clockLinus Walleij2017-04-071-46/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The plain Faraday FTTMR010 timer needs a clock to figure out its tick rate, and the gemini reads it directly from the system controller set-up. Split the init function and add two paths for the two compatible-strings. We only support clocking using PCLK because of lack of documentation on how EXTCLK works. The Gemini still works like before, but we can also support a generic, clock-based version. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| | * | clocksource/drivers/gemini: Rename Gemini timer to FaradayLinus Walleij2017-04-073-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After some research it turns out that the "Gemini" timer is actually a generic IP block from Faraday Technology named FTTMR010, so as to not make things too confusing we need to rename the driver and its symbols to make sense. The implementation remains the same in this patch but we fix the copy-paste error in the timer name "nomadik_mtu" as we're at it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| | * | clocksource/drivers/rockchip_timer: Implement clocksource timerAlexander Kochetkov2017-04-072-61/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clock supplying the arm-global-timer on the rk3188 is coming from the the cpu clock itself and thus changes its rate everytime cpufreq adjusts the cpu frequency making this timer unsuitable as a stable clocksource and sched clock. The rk3188, rk3288 and following socs share a separate timer block already handled by the rockchip-timer driver. Therefore adapt this driver to also be able to act as clocksource and sched clock on rk3188. In order to test clocksource you can run following commands and check how much time it take in real. On rk3188 it take about ~45 seconds. cpufreq-set -f 1.6GHZ date; sleep 60; date In order to use the patch you need to declare two timers in the dts file. The first timer will be initialized as clockevent provider and the second one as clocksource. The clockevent must be from alive subsystem as it used as backup for the local timers at sleep time. The patch does not break compatibility with older device tree files. The older device tree files contain only one timer. The timer will be initialized as clockevent, as expected. rk3288 (and probably anything newer) is irrelevant to this patch, as it has the arch timer interface. This patch may be useful for Cortex-A9/A5 based parts. Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| | * | clocksource: Add missing line break to error messagesRafał Miłecki2017-04-0725-65/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Printing with pr_* functions requires adding line break manually. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| | * | clocksource/drivers/orion: Add delay_timer implementationRussell King2017-04-071-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an implementation for the ARM delay timer, which is used for udelay(). This provides less CPU dependent and more accurate delays - the CPU loop on Marvell Dove appears to calibrate to around 6% too short. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| | * | clocksource/drivers/orion: Read clock rate onceRussell King2017-04-071-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than reading the clock rate three times, read it once - we are about to add a fourth usage. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | clockevents/drivers/atlas7: Set ->min_delta_ticks and ->max_delta_ticksNicolai Stange2017-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to stay invariant. Make the timer-atlas7 clockevent driver initialize these fields properly. This patch alone doesn't introduce any change in functionality as the clockevents core still looks exclusively at the (untouched) ->min_delta_ns and ->max_delta_ns. As soon as this has changed, a followup patch will purge the initialization of ->min_delta_ns and ->max_delta_ns from this driver. Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Barry Song <baohua@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | | clockevents/drivers/sh_cmt: Set ->min_delta_ticks and ->max_delta_ticksNicolai Stange2017-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to stay invariant. Make the sh_cmt clockevent driver initialize these fields properly. This patch alone doesn't introduce any change in functionality as the clockevents core still looks exclusively at the (untouched) ->min_delta_ns and ->max_delta_ns. As soon as this has changed, a followup patch will purge the initialization of ->min_delta_ns and ->max_delta_ns from this driver. Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | | x86/numachip timer: Set ->min_delta_ticks and ->max_delta_ticksNicolai Stange2017-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to stay invariant. Make the numachip clockevent driver initialize these fields properly. This patch alone doesn't introduce any change in functionality as the clockevents core still looks exclusively at the (untouched) ->min_delta_ns and ->max_delta_ns. As soon as this has changed, a followup patch will purge the initialization of ->min_delta_ns and ->max_delta_ns from this driver. Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | | clockevents/drivers/metag: Set ->min_delta_ticks and ->max_delta_ticksNicolai Stange2017-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to stay invariant. Make the metag_generic clockevent driver initialize these fields properly. This patch alone doesn't introduce any change in functionality as the clockevents core still looks exclusively at the (untouched) ->min_delta_ns and ->max_delta_ns. As soon as this has changed, a followup patch will purge the initialization of ->min_delta_ns and ->max_delta_ns from this driver. Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: James Hogan <james.hogan@imgtec.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | | clockevents/drivers/dw_apb: Set ->min_delta_ticks and ->max_delta_ticksNicolai Stange2017-04-141-0/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to stay invariant. Make the dw_apb clockevent driver initialize these fields properly. This patch alone doesn't introduce any change in functionality as the clockevents core still looks exclusively at the (untouched) ->min_delta_ns and ->max_delta_ns. As soon as this has changed, a followup patch will purge the initialization of ->min_delta_ns and ->max_delta_ns from this driver. Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | clocksource: h8300_timer8: Don't reset rate in ->set_state_oneshot()Nicolai Stange2017-03-231-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, h8300_timer8 violates this requirement in that it registers its clockevent device with the correct rate, but resets its ->mult and ->rate values in timer8_clock_event_start(), called from its ->set_state_oneshot() function. It seems like commit 4633f4cac85a ("clocksource/drivers/h8300: Cleanup startup and remove module code."), which introduced the rate initialization at registration, missed to remove the manual setting of ->mult and ->shift from timer8_clock_event_start(). Purge the setting of ->mult, ->shift, ->min_delta_ns and ->max_delta_ns from timer8_clock_event_start(). Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | clocksource: em_sti: Compute rate before registrationNicolai Stange2017-03-231-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, em_sti violates this requirement in that it registers its clockevent device with a dummy rate and sets its final rate through clockevents_config() called from its ->set_state_oneshot(). This patch moves the setting of the clockevent device's rate to its registration. I checked all current em_sti users in arch/arm/mach-shmobile and right now, none of them changes any rate in any clock tree relevant to em_sti after their respective time_init(). Since all em_sti instances are created after time_init(), none of them should ever observe any clock rate changes. - Determine the ->rate value in em_sti_probe() at device probing rather than at first usage. - Set the clockevent device's rate at its registration. - Although not strictly necessary for the upcoming clockevent core changes, set the clocksource's rate at its registration for consistency. Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | clocksource: em_sti: Split clock prepare and enable stepsNicolai Stange2017-03-231-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the em_sti driver prepares and enables the needed clock in em_sti_enable(), potentially called through its clockevent device's ->set_state_oneshot(). However, the clk_prepare() step may sleep whereas tick_program_event() and thus, ->set_state_oneshot(), can be called in atomic context. Split the clk_prepare_enable() in em_sti_enable() into two steps: - prepare the clock at device probing via clk_prepare() - and enable it in em_sti_enable() via clk_enable(). Slightly reorder resource initialization in em_sti_probe() in order to facilitate error handling in later patches. Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | clocksource: sh_tmu: Compute rate before registration againNicolai Stange2017-03-231-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, sh_tmu violates this requirement in that it registers its clockevent device with a dummy rate and sets its final rate through clockevents_config() called from its ->set_state_oneshot() and ->set_state_periodic() functions respectively. This patch moves the setting of the clockevent device's rate to its registration. Note that there has been some back and forth regarding this question with respect to the clocksource also provided by this driver: commit 66f49121ffa4 ("clocksource: sh_tmu: compute mult and shift before registration") moves the rate determination from the clocksource's ->enable() function to before its registration. OTOH, the later commit 0aeac458d9eb ("clocksource: sh_tmu: __clocksource_updatefreq_hz() update") basically reverts this, saying "Without this patch the old code uses clocksource_register() together with a hack that assumes a never changing clock rate." However, I checked all current sh_tmu users in arch/sh as well as in arch/arm/mach-shmobile carefully and right now, none of them changes any rate in any clock tree relevant to sh_tmu after their respective time_init(). Since all sh_tmu instances are created after time_init(), none of them should ever observe any clock rate changes. What's more, both, a clocksource as well as a clockevent device, can immediately get selected for use at their registration and thus, enabled at this point already. So it's probably safer to assume a "never changing clock rate" here. - Move the struct sh_tmu_channel's ->rate member to struct sh_tmu_device: it's a property of the underlying clock which is in turn specific to the sh_tmu_device. - Determine the ->rate value in sh_tmu_setup() at device probing rather than at first usage. - Set the clockevent device's rate at its registration. - Although not strictly necessary for the upcoming clockevent core changes, set the clocksource's rate at its registration for consistency. Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
| * | clocksource: sh_cmt: Compute rate before registration againNicolai Stange2017-03-231-20/+25
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the upcoming NTP correction related rate adjustments to be implemented in the clockevents core, the latter needs to get informed about every rate change of a clockevent device made after its registration. Currently, sh_cmt violates this requirement in that it registers its clockevent device with a dummy rate and sets its final ->mult and ->shift values from its ->set_state_oneshot() and ->set_state_periodic() functions respectively. This patch moves the setting of the clockevent device's ->mult and ->shift values to before its registration. Note that there has been some back and forth regarding this question with respect to the clocksource also provided by this driver: commit f4d7c3565c16 ("clocksource: sh_cmt: compute mult and shift before registration") moves the rate determination from the clocksource's ->enable() function to before its registration. OTOH, the later commit 3593f5fe40a1 ("clocksource: sh_cmt: __clocksource_updatefreq_hz() update") basically reverts this, saying "Without this patch the old code uses clocksource_register() together with a hack that assumes a never changing clock rate." However, I checked all current sh_cmt users in arch/sh as well as in arch/arm/mach-shmobile carefully and right now, none of them changes any rate in any clock tree relevant to sh_cmt after their respective time_init(). Since all sh_cmt instances are created after time_init(), none of them should ever observe any clock rate changes. What's more, both, a clocksource as well as a clockevent device, can immediately get selected for use at their registration and thus, enabled at this point already. So it's probably safer to assume a "never changing clock rate" here. - Move the struct sh_cmt_channel's ->rate member to struct sh_cmt_device: it's a property of the underlying clock which is in turn specific to the sh_cmt_device. - Determine the ->rate value in sh_cmt_setup() at device probing rather than at first usage. - Set the clockevent device's ->mult and ->shift values right before its registration. - Although not strictly necessary for the upcoming clockevent core changes, set the clocksource's rate at its registration for consistency. Signed-off-by: Nicolai Stange <nicstange@gmail.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 10:10:46 +0100