summaryrefslogtreecommitdiff
path: root/drivers/clocksource/timer-davinci.c
AgeCommit message (Collapse)Author
2021-01-18clocksource/drivers/davinci: Move pr_fmt() before the includesBartosz Golaszewski
We no longer need to undef pr_fmt if we define our own before including any headers. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210111140814.3668-1-brgl@bgdev.pl
2020-04-09clocksource: davinci: axe a pointless __GFP_NOFAILChristophe JAILLET
There is no need to specify __GFP_NOFAIL when allocating memory here, so axe it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200409101226.15432-1-christophe.jaillet@wanadoo.fr
2020-04-09clocksource/drivers/davinci: Avoid trailing '\n' hidden in pr_fmt()Christophe JAILLET
pr_xxx() functions usually have '\n' at the end of the logging message. Here, this '\n' is added via the 'pr_fmt' macro. In order to be more consistent with other files, use a more standard convention and put these '\n' back in the messages themselves and remove it from the pr_fmt macro. While at it, remove a useless message in case of 'kzalloc' failure, especially with a __GFP_NOFAIL flag. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200409092543.14727-1-christophe.jaillet@wanadoo.fr
2020-01-13clocksource: davinci: only enable clockevents once tim34 is initializedBartosz Golaszewski
The DM365 platform has a strange quirk (only present when using ancient u-boot - mainline u-boot v2013.01 and later works fine) where if we enable the second half of the timer in periodic mode before we do its initialization - the time won't start flowing and we can't boot. When using more recent u-boot, we can enable the timer, then reinitialize it and all works fine. To work around this issue only enable clockevents once tim34 is initialized i.e. move clockevents_config_and_register() below tim34 initialization. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-06-25clocksource/drivers/davinci: Add support for clocksourceBartosz Golaszewski
Extend the davinci-timer driver to also register a clock source. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2019-06-25clocksource/drivers/davinci: Add support for clockeventsBartosz Golaszewski
Currently the clocksource and clockevent support for davinci platforms lives in mach-davinci. It hard-codes many things, uses global variables, implements functionalities unused by any platform and has code fragments scattered across many (often unrelated) files. Implement a new, modern and simplified timer driver and put it into drivers/clocksource. We still need to support legacy board files so export a config structure and a function that allows machine code to register the timer. The timer we're using is 64-bit but can be programmed in dual 32-bit mode (both chained and unchained). On all davinci SoCs except for da830 we're using both halves. Lower half for clockevents and upper half for clocksource. On da830 we're using the lower half for both with the help of a compare register. This patch contains the core code and support for clockevent. The clocksource code will be included in a subsequent patch. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>