2019-05-19 13:07:45 +01:00
|
|
|
|
2014-06-16 11:48:45 +02:00
|
|
|
|
clocksource: Improve GENERIC_CLOCKEVENTS dependency
We regularly run into build errors when a clocksource driver selects
CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:
In file included from drivers/clocksource/timer-of.c:25:0:
drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
many times, but I have looked a little bit more at what architectures
are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
is a better solution.
On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
and we also don't use ARCH_USES_GETTIMEOFFSET, which would
block the clocksource Kconfig menu. On m68k, some platforms use
CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
use neither of them. The good news is that there is no configuration that
does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
the Kconfig symbols in the menu, so we can simply replace the dependency
with the stricter one. While in theory one could have a clocksource
driver without the clockevent infrastructure, this seems unlikely
to be relevant in the future any more.
We can probably drop some of the other dependencies as well now,
e.g. there should generally be no reason to depend on CONFIG_ARM
unless the driver uses architecture specific assembly.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2017-09-05 17:04:56 +02:00
|
|
|
|
2014-06-16 11:48:45 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2012-11-19 16:41:20 -07:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-09-28 15:49:16 +01:00
|
|
|
|
2017-05-26 19:40:24 +02:00
|
|
|
|
2015-09-28 15:49:16 +01:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-09-28 15:49:16 +01:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-09-28 15:49:16 +01:00
|
|
|
|
2012-11-19 16:41:20 -07:00
|
|
|
|
2011-05-08 18:47:58 +01:00
|
|
|
|
|
|
|
|
|
2011-05-08 14:06:52 +01:00
|
|
|
|
2011-06-09 13:08:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-01 19:04:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-08 13:17:14 +03:00
|
|
|
|
2018-02-15 11:31:46 +05:30
|
|
|
|
2021-08-28 10:57:47 -07:00
|
|
|
|
2018-02-15 11:31:46 +05:30
|
|
|
|
2011-06-01 19:04:59 +01:00
|
|
|
|
2011-06-09 13:08:25 +00:00
|
|
|
|
2011-06-01 19:04:59 +01:00
|
|
|
|
2011-05-08 14:06:52 +01:00
|
|
|
|
|
|
|
|
|
2011-06-06 12:43:07 +01:00
|
|
|
|
2016-06-02 18:35:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-02 19:20:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-24 11:50:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-26 20:35:18 +02:00
|
|
|
|
2015-10-30 22:32:10 +01:00
|
|
|
|
2016-01-25 17:02:49 +01:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2015-10-30 22:32:10 +01:00
|
|
|
|
|
|
|
|
|
2015-01-26 20:35:18 +02:00
|
|
|
|
2022-04-08 13:17:14 +03:00
|
|
|
|
2022-05-23 18:14:48 +03:00
|
|
|
|
|
|
|
|
|
2022-04-08 13:17:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-06 12:43:07 +01:00
|
|
|
|
2015-10-30 22:35:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-27 10:30:12 +02:00
|
|
|
|
2012-07-11 15:13:16 -05:00
|
|
|
|
|
|
|
|
|
2013-06-04 11:38:11 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2012-07-11 15:13:16 -05:00
|
|
|
|
2017-03-24 22:32:34 +01:00
|
|
|
|
|
|
|
|
|
2017-01-22 13:17:17 +01:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2017-01-22 13:17:17 +01:00
|
|
|
|
|
|
|
|
|
2017-03-24 22:32:34 +01:00
|
|
|
|
|
|
|
|
|
2017-01-22 13:17:17 +01:00
|
|
|
|
2019-01-26 00:49:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-06 22:55:05 +02:00
|
|
|
|
2019-01-26 00:49:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-25 22:06:02 +01:00
|
|
|
|
2015-10-30 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2017-01-31 15:43:14 +03:00
|
|
|
|
2015-10-30 17:58:47 +01:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2015-01-25 22:06:02 +01:00
|
|
|
|
2012-06-13 18:58:09 +02:00
|
|
|
|
2015-10-30 20:30:34 +01:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-01-25 17:02:49 +01:00
|
|
|
|
2015-10-30 20:30:34 +01:00
|
|
|
|
|
|
|
|
|
2012-06-13 18:58:09 +02:00
|
|
|
|
2014-09-29 01:50:05 +02:00
|
|
|
|
2015-10-30 22:07:39 +01:00
|
|
|
|
2014-11-18 16:41:20 +01:00
|
|
|
|
2015-10-30 22:07:39 +01:00
|
|
|
|
|
|
|
|
|
2014-09-29 01:50:05 +02:00
|
|
|
|
2013-06-11 08:38:50 +02:00
|
|
|
|
2015-10-30 22:28:31 +01:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2013-06-11 08:38:50 +02:00
|
|
|
|
2015-10-30 22:28:31 +01:00
|
|
|
|
|
|
|
|
|
2013-06-11 08:38:50 +02:00
|
|
|
|
2017-02-23 19:27:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-10 23:05:46 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-24 11:49:25 +01:00
|
|
|
|
2015-10-30 22:39:00 +01:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2013-10-14 21:07:46 +02:00
|
|
|
|
2017-06-06 23:07:51 +02:00
|
|
|
|
2015-10-30 22:39:00 +01:00
|
|
|
|
|
|
|
|
|
2012-11-12 15:07:50 +01:00
|
|
|
|
2013-11-07 12:01:48 +01:00
|
|
|
|
2015-10-31 17:01:46 +01:00
|
|
|
|
2013-11-07 12:01:48 +01:00
|
|
|
|
2015-10-31 17:01:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-07 12:01:48 +01:00
|
|
|
|
2014-07-07 15:26:30 +02:00
|
|
|
|
2015-10-31 20:13:09 +01:00
|
|
|
|
2016-01-25 17:02:49 +01:00
|
|
|
|
2019-02-21 15:21:44 +08:00
|
|
|
|
2019-06-03 21:59:46 +03:00
|
|
|
|
2015-10-31 20:13:09 +01:00
|
|
|
|
|
|
|
|
|
2014-07-07 15:26:30 +02:00
|
|
|
|
2022-07-04 13:43:38 +05:30
|
|
|
|
2022-07-18 23:36:57 +02:00
|
|
|
|
2022-07-04 13:43:38 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-14 17:58:21 +13:00
|
|
|
|
2015-10-31 20:23:54 +01:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2015-10-31 20:23:54 +01:00
|
|
|
|
|
|
|
|
|
2013-01-14 17:58:21 +13:00
|
|
|
|
2018-03-08 17:24:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-05 14:24:48 +01:00
|
|
|
|
2018-03-08 17:24:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2018-03-08 17:24:58 +02:00
|
|
|
|
2013-03-20 10:46:01 +01:00
|
|
|
|
2015-10-31 21:39:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2013-03-20 10:46:01 +01:00
|
|
|
|
2015-02-23 19:54:16 +01:00
|
|
|
|
2015-10-31 21:41:23 +01:00
|
|
|
|
2015-02-23 19:54:16 +01:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-10-31 21:41:23 +01:00
|
|
|
|
|
|
|
|
|
2015-02-23 19:54:16 +01:00
|
|
|
|
2012-10-18 14:01:25 +02:00
|
|
|
|
2015-11-01 21:11:28 +01:00
|
|
|
|
|
|
|
|
|
2012-10-18 14:01:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-27 10:30:12 +02:00
|
|
|
|
2015-11-01 21:16:01 +01:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2011-05-27 10:30:12 +02:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2011-05-27 10:30:12 +02:00
|
|
|
|
2016-06-02 20:06:54 +02:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-06-02 20:06:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-03 13:36:18 +02:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-06-03 13:36:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-06-03 13:36:18 +02:00
|
|
|
|
2016-06-03 15:03:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-03 15:05:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-03 15:11:21 +02:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-06-03 15:11:21 +02:00
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-06-03 15:11:21 +02:00
|
|
|
|
2015-05-12 00:00:48 +02:00
|
|
|
|
2015-10-31 21:44:52 +01:00
|
|
|
|
clocksource: Improve GENERIC_CLOCKEVENTS dependency
We regularly run into build errors when a clocksource driver selects
CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:
In file included from drivers/clocksource/timer-of.c:25:0:
drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
many times, but I have looked a little bit more at what architectures
are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
is a better solution.
On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
and we also don't use ARCH_USES_GETTIMEOFFSET, which would
block the clocksource Kconfig menu. On m68k, some platforms use
CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
use neither of them. The good news is that there is no configuration that
does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
the Kconfig symbols in the menu, so we can simply replace the dependency
with the stricter one. While in theory one could have a clocksource
driver without the clockevent infrastructure, this seems unlikely
to be relevant in the future any more.
We can probably drop some of the other dependencies as well now,
e.g. there should generally be no reason to depend on CONFIG_ARM
unless the driver uses architecture specific assembly.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2017-09-05 17:04:56 +02:00
|
|
|
|
2016-02-09 22:54:27 -03:00
|
|
|
|
2015-05-12 00:00:48 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-10-31 21:44:52 +01:00
|
|
|
|
|
|
|
|
|
2015-05-12 00:00:48 +02:00
|
|
|
|
2015-08-07 16:39:31 +01:00
|
|
|
|
2021-07-23 10:25:38 +08:00
|
|
|
|
clocksource: Improve GENERIC_CLOCKEVENTS dependency
We regularly run into build errors when a clocksource driver selects
CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:
In file included from drivers/clocksource/timer-of.c:25:0:
drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
many times, but I have looked a little bit more at what architectures
are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
is a better solution.
On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
and we also don't use ARCH_USES_GETTIMEOFFSET, which would
block the clocksource Kconfig menu. On m68k, some platforms use
CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
use neither of them. The good news is that there is no configuration that
does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
the Kconfig symbols in the menu, so we can simply replace the dependency
with the stricter one. While in theory one could have a clocksource
driver without the clockevent infrastructure, this seems unlikely
to be relevant in the future any more.
We can probably drop some of the other dependencies as well now,
e.g. there should generally be no reason to depend on CONFIG_ARM
unless the driver uses architecture specific assembly.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2017-09-05 17:04:56 +02:00
|
|
|
|
2021-07-23 10:25:38 +08:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-10-30 17:28:13 +01:00
|
|
|
|
|
|
|
|
|
2015-08-07 16:39:31 +01:00
|
|
|
|
2015-09-29 13:55:33 -05:00
|
|
|
|
|
|
|
|
|
2015-10-16 16:10:05 -05:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-09-29 13:55:33 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 23:03:33 +02:00
|
|
|
|
2015-06-20 19:02:32 -04:00
|
|
|
|
|
|
|
|
|
2015-05-22 23:03:33 +02:00
|
|
|
|
2018-01-08 14:28:51 +01:00
|
|
|
|
2015-05-22 23:03:33 +02:00
|
|
|
|
2020-06-03 14:54:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-25 09:45:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-04-25 09:45:44 +01:00
|
|
|
|
2016-10-31 13:46:38 -07:00
|
|
|
|
|
|
|
|
|
2018-11-19 14:29:17 +03:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-10-31 13:46:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-10-31 13:46:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-10-31 13:46:38 -07:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2016-10-31 13:46:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-12 14:33:44 +00:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2017-05-26 19:40:24 +02:00
|
|
|
|
2012-10-09 10:54:39 +01:00
|
|
|
|
2013-08-23 15:32:29 +01:00
|
|
|
|
2016-06-27 17:30:13 +01:00
|
|
|
|
2013-08-23 15:32:29 +01:00
|
|
|
|
2013-11-20 12:02:03 -08:00
|
|
|
|
2013-08-23 15:32:29 +01:00
|
|
|
|
2016-06-27 17:30:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-23 15:32:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-06 16:47:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 03:35:17 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-06 16:47:41 +00:00
|
|
|
|
2016-09-22 03:35:17 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-06 16:47:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-27 12:52:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability
The Allwinner A64 SoC is known[1] to have an unstable architectural
timer, which manifests itself most obviously in the time jumping forward
a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
timer frequency of 24 MHz, implying that the time went slightly backward
(and this was interpreted by the kernel as it jumping forward and
wrapping around past the epoch).
Investigation revealed instability in the low bits of CNTVCT at the
point a high bit rolls over. This leads to power-of-two cycle forward
and backward jumps. (Testing shows that forward jumps are about twice as
likely as backward jumps.) Since the counter value returns to normal
after an indeterminate read, each "jump" really consists of both a
forward and backward jump from the software perspective.
Unless the kernel is trapping CNTVCT reads, a userspace program is able
to read the register in a loop faster than it changes. A test program
running on all 4 CPU cores that reported jumps larger than 100 ms was
run for 13.6 hours and reported the following:
Count | Event
-------+---------------------------
9940 | jumped backward 699ms
268 | jumped backward 1398ms
1 | jumped backward 2097ms
16020 | jumped forward 175ms
6443 | jumped forward 699ms
2976 | jumped forward 1398ms
9 | jumped forward 356516ms
9 | jumped forward 357215ms
4 | jumped forward 714430ms
1 | jumped forward 3578440ms
This works out to a jump larger than 100 ms about every 5.5 seconds on
each CPU core.
The largest jump (almost an hour!) was the following sequence of reads:
0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
Note that the middle bits don't necessarily all read as all zeroes or
all ones during the anomalous behavior; however the low 10 bits checked
by the function in this patch have never been observed with any other
value.
Also note that smaller jumps are much more common, with backward jumps
of 2048 (2^11) cycles observed over 400 times per second on each core.
(Of course, this is partially explained by lower bits rolling over more
frequently.) Any one of these could have caused the 95 year time skip.
Similar anomalies were observed while reading CNTPCT (after patching the
kernel to allow reads from userspace). However, the CNTPCT jumps are
much less frequent, and only small jumps were observed. The same program
as before (except now reading CNTPCT) observed after 72 hours:
Count | Event
-------+---------------------------
17 | jumped backward 699ms
52 | jumped forward 175ms
2831 | jumped forward 699ms
5 | jumped forward 1398ms
Further investigation showed that the instability in CNTPCT/CNTVCT also
affected the respective timer's TVAL register. The following values were
observed immediately after writing CNVT_TVAL to 0x10000000:
CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
The pattern of errors in CNTV_TVAL seemed to depend on exactly which
value was written to it. For example, after writing 0x10101010:
CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error
--------------------+------------+--------------------+-----------------
0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
I was also twice able to reproduce the issue covered by Allwinner's
workaround[4], that writing to TVAL sometimes fails, and both CVAL and
TVAL are left with entirely bogus values. One was the following values:
CNTVCT | CNTV_TVAL | CNTV_CVAL
--------------------+------------+--------------------------------------
0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
========================================================================
Because the CPU can read the CNTPCT/CNTVCT registers faster than they
change, performing two reads of the register and comparing the high bits
(like other workarounds) is not a workable solution. And because the
timer can jump both forward and backward, no pair of reads can
distinguish a good value from a bad one. The only way to guarantee a
good value from consecutive reads would be to read _three_ times, and
take the middle value only if the three values are 1) each unique and
2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
if an anomaly is detected.
However, since there is a distinct pattern to the bad values, we can
optimize the common case (1022/1024 of the time) to a single read by
simply ignoring values that match the error pattern. This still takes no
more than 3 cycles in the worst case, and requires much less code. As an
additional safety check, we still limit the loop iteration to the number
of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
For the TVAL registers, the simple solution is to not use them. Instead,
read or write the CVAL and calculate the TVAL value in software.
Although the manufacturer is aware of at least part of the erratum[4],
there is no official name for it. For now, use the kernel-internal name
"UNKNOWN1".
[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2019-01-12 20:17:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-26 12:48:38 +01:00
|
|
|
|
2016-06-06 14:34:28 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-06-06 14:34:28 +02:00
|
|
|
|
2013-06-26 12:48:38 +01:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2013-06-26 12:48:38 +01:00
|
|
|
|
clocksource/drivers/arm_global_timer: Implement rate compensation whenever source clock changes
This patch adds rate change notification support for the parent clock;
should that clock change, then we try to adjust the our prescaler in order
to compensate (i.e. we adjust to still get the same timer frequency).
This is loosely based on what it's done in timer-cadence-ttc. timer-sun51,
mips-gic-timer and smp_twd.c also seem to look at their parent clock rate
and to perform some kind of adjustment whenever needed.
In this particular case we have only one single counter and prescaler for
all clocksource, clockevent and timer_delay, and we just update it for all
(i.e. we don't let it go and call clockevents_update_freq() to notify to
the kernel that our rate has changed).
Note that, there is apparently no other way to fixup things, because once
we call register_current_timer_delay(), specifying the timer rate, it seems
that that rate is not supposed to change ever.
In order for this mechanism to work, we have to make assumptions about how
much the initial clock is supposed to eventually decrease from the initial
one, and set our initial prescaler to a value that we can eventually
decrease enough to compensate. We provide an option in KConfig for this.
In case we end up in a situation in which we are not able to compensate the
parent clock change, we fail returning NOTIFY_BAD.
This fixes a real-world problem with Zynq arch not being able to use this
driver and CPU_FREQ at the same time (because ARM global timer is fed by
the CPU clock, which may keep changing when CPU_FREQ is enabled).
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210406130045.15491-2-andrea.merello@gmail.com
2021-04-06 15:00:44 +02:00
|
|
|
|
|
|
|
|
|
2021-04-06 15:00:45 +02:00
|
|
|
|
clocksource/drivers/arm_global_timer: Implement rate compensation whenever source clock changes
This patch adds rate change notification support for the parent clock;
should that clock change, then we try to adjust the our prescaler in order
to compensate (i.e. we adjust to still get the same timer frequency).
This is loosely based on what it's done in timer-cadence-ttc. timer-sun51,
mips-gic-timer and smp_twd.c also seem to look at their parent clock rate
and to perform some kind of adjustment whenever needed.
In this particular case we have only one single counter and prescaler for
all clocksource, clockevent and timer_delay, and we just update it for all
(i.e. we don't let it go and call clockevents_update_freq() to notify to
the kernel that our rate has changed).
Note that, there is apparently no other way to fixup things, because once
we call register_current_timer_delay(), specifying the timer rate, it seems
that that rate is not supposed to change ever.
In order for this mechanism to work, we have to make assumptions about how
much the initial clock is supposed to eventually decrease from the initial
one, and set our initial prescaler to a value that we can eventually
decrease enough to compensate. We provide an option in KConfig for this.
In case we end up in a situation in which we are not able to compensate the
parent clock change, we fail returning NOTIFY_BAD.
This fixes a real-world problem with Zynq arch not being able to use this
driver and CPU_FREQ at the same time (because ARM global timer is fed by
the CPU clock, which may keep changing when CPU_FREQ is enabled).
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210406130045.15491-2-andrea.merello@gmail.com
2021-04-06 15:00:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-14 18:58:52 -07:00
|
|
|
|
clocksource/drivers/arm_global_timer: Implement rate compensation whenever source clock changes
This patch adds rate change notification support for the parent clock;
should that clock change, then we try to adjust the our prescaler in order
to compensate (i.e. we adjust to still get the same timer frequency).
This is loosely based on what it's done in timer-cadence-ttc. timer-sun51,
mips-gic-timer and smp_twd.c also seem to look at their parent clock rate
and to perform some kind of adjustment whenever needed.
In this particular case we have only one single counter and prescaler for
all clocksource, clockevent and timer_delay, and we just update it for all
(i.e. we don't let it go and call clockevents_update_freq() to notify to
the kernel that our rate has changed).
Note that, there is apparently no other way to fixup things, because once
we call register_current_timer_delay(), specifying the timer rate, it seems
that that rate is not supposed to change ever.
In order for this mechanism to work, we have to make assumptions about how
much the initial clock is supposed to eventually decrease from the initial
one, and set our initial prescaler to a value that we can eventually
decrease enough to compensate. We provide an option in KConfig for this.
In case we end up in a situation in which we are not able to compensate the
parent clock change, we fail returning NOTIFY_BAD.
This fixes a real-world problem with Zynq arch not being able to use this
driver and CPU_FREQ at the same time (because ARM global timer is fed by
the CPU clock, which may keep changing when CPU_FREQ is enabled).
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210406130045.15491-2-andrea.merello@gmail.com
2021-04-06 15:00:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-18 16:29:40 +01:00
|
|
|
|
2019-04-08 10:07:45 +02:00
|
|
|
|
2021-05-31 11:48:49 +02:00
|
|
|
|
2015-05-18 16:29:40 +01:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-05-18 16:29:40 +01:00
|
|
|
|
2013-06-26 12:48:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2013-06-26 12:48:38 +01:00
|
|
|
|
2015-05-09 09:53:46 +02:00
|
|
|
|
2016-06-02 18:41:52 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-05-09 09:53:46 +02:00
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2015-05-09 09:53:46 +02:00
|
|
|
|
2014-09-02 18:12:35 +02:00
|
|
|
|
2019-04-26 23:47:15 +02:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2019-04-26 23:47:15 +02:00
|
|
|
|
|
|
|
|
|
2014-09-02 18:12:35 +02:00
|
|
|
|
2015-03-12 13:07:31 +01:00
|
|
|
|
2016-06-06 19:08:39 +02:00
|
|
|
|
2018-03-06 20:20:33 +09:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-03-19 14:17:48 +01:00
|
|
|
|
2016-06-06 19:08:39 +02:00
|
|
|
|
|
|
|
|
|
2015-03-12 13:07:31 +01:00
|
|
|
|
2019-04-26 23:47:14 +02:00
|
|
|
|
|
|
|
|
|
2019-08-13 15:30:50 +02:00
|
|
|
|
2019-04-26 23:47:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-09 16:16:13 +09:00
|
|
|
|
2015-11-01 21:51:30 +01:00
|
|
|
|
2016-08-24 22:49:05 +09:00
|
|
|
|
2022-06-09 13:27:38 +02:00
|
|
|
|
2013-03-09 16:16:13 +09:00
|
|
|
|
|
|
|
|
|
2013-05-06 23:49:09 +02:00
|
|
|
|
2013-04-20 23:22:13 +02:00
|
|
|
|
2016-06-16 15:53:18 +02:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2021-10-21 08:35:00 +02:00
|
|
|
|
2013-04-20 23:22:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-29 10:12:17 +02:00
|
|
|
|
2014-05-23 10:12:04 +02:00
|
|
|
|
2015-11-02 09:51:02 +01:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2016-01-08 14:21:31 +01:00
|
|
|
|
2014-05-23 10:12:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-29 10:12:17 +02:00
|
|
|
|
|
|
|
|
|
2016-01-25 17:02:49 +01:00
|
|
|
|
2013-05-29 10:12:17 +02:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
2016-06-15 12:13:26 +02:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-06-15 12:13:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
2019-11-20 21:42:36 +08:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
2014-07-18 11:36:43 +02:00
|
|
|
|
2015-10-30 17:53:27 +01:00
|
|
|
|
clocksource: Improve GENERIC_CLOCKEVENTS dependency
We regularly run into build errors when a clocksource driver selects
CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:
In file included from drivers/clocksource/timer-of.c:25:0:
drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
many times, but I have looked a little bit more at what architectures
are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
is a better solution.
On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
and we also don't use ARCH_USES_GETTIMEOFFSET, which would
block the clocksource Kconfig menu. On m68k, some platforms use
CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
use neither of them. The good news is that there is no configuration that
does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
the Kconfig symbols in the menu, so we can simply replace the dependency
with the stricter one. While in theory one could have a clocksource
driver without the clockevent infrastructure, this seems unlikely
to be relevant in the future any more.
We can probably drop some of the other dependencies as well now,
e.g. there should generally be no reason to depend on CONFIG_ARM
unless the driver uses architecture specific assembly.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2017-09-05 17:04:56 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2014-07-18 11:36:43 +02:00
|
|
|
|
2015-10-30 17:53:27 +01:00
|
|
|
|
|
|
|
|
|
2014-07-18 11:36:43 +02:00
|
|
|
|
2018-01-08 14:28:47 +01:00
|
|
|
|
2018-05-07 17:04:47 +08:00
|
|
|
|
2018-01-08 14:28:47 +01:00
|
|
|
|
2018-05-07 17:04:47 +08:00
|
|
|
|
|
|
|
|
|
2018-01-08 14:28:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
2019-11-20 21:42:36 +08:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
2019-11-20 21:42:36 +08:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
2019-11-20 21:42:36 +08:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
2016-10-13 21:51:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
2015-03-26 10:27:06 +01:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-26 10:27:06 +01:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-18 11:36:36 +02:00
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
2017-01-27 15:02:15 -05:00
|
|
|
|
2021-11-12 18:44:13 +00:00
|
|
|
|
|
|
|
|
|
2017-01-27 15:02:15 -05:00
|
|
|
|
2019-10-16 16:47:46 +02:00
|
|
|
|
2017-01-27 15:02:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
2015-03-26 10:27:06 +01:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
clocksource: Improve GENERIC_CLOCKEVENTS dependency
We regularly run into build errors when a clocksource driver selects
CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled:
In file included from drivers/clocksource/timer-of.c:25:0:
drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete type
At the moment, three drivers can show this behavior: ARMV7M_SYSTICK,
CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did
many times, but I have looked a little bit more at what architectures
are left that don't use GENERIC_CLOCKEVENTS, and this shows that there
is a better solution.
On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS
and we also don't use ARCH_USES_GETTIMEOFFSET, which would
block the clocksource Kconfig menu. On m68k, some platforms use
CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some
use neither of them. The good news is that there is no configuration that
does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of
the Kconfig symbols in the menu, so we can simply replace the dependency
with the stricter one. While in theory one could have a clocksource
driver without the clockevent infrastructure, this seems unlikely
to be relevant in the future any more.
We can probably drop some of the other dependencies as well now,
e.g. there should generally be no reason to depend on CONFIG_ARM
unless the driver uses architecture specific assembly.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2017-09-05 17:04:56 +02:00
|
|
|
|
2014-02-20 12:54:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-05 13:51:19 -07:00
|
|
|
|
2014-01-29 16:17:30 -06:00
|
|
|
|
2015-10-09 11:10:43 +02:00
|
|
|
|
|
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2015-10-09 11:10:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-16 18:22:59 +01:00
|
|
|
|
|
|
|
|
|
2016-06-07 11:05:01 +02:00
|
|
|
|
2020-09-24 12:30:50 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2020-04-17 16:20:45 -05:00
|
|
|
|
2014-04-16 18:22:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-17 16:20:45 -05:00
|
|
|
|
2014-06-16 11:48:45 +02:00
|
|
|
|
2014-10-20 12:03:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-21 23:48:17 +03:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2014-10-20 12:03:58 -07:00
|
|
|
|
2014-12-21 16:07:09 +01:00
|
|
|
|
2015-10-09 17:47:32 +02:00
|
|
|
|
2016-01-25 23:24:19 +01:00
|
|
|
|
2015-10-09 17:47:32 +02:00
|
|
|
|
2014-12-21 16:07:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-28 02:52:42 +09:00
|
|
|
|
2015-05-15 15:41:00 +08:00
|
|
|
|
|
|
|
|
|
2021-05-31 11:48:49 +02:00
|
|
|
|
2015-05-15 15:41:00 +08:00
|
|
|
|
|
|
|
|
|
2017-08-01 16:40:17 +08:00
|
|
|
|
|
|
|
|
|
2021-05-31 11:48:49 +02:00
|
|
|
|
2017-08-01 16:40:17 +08:00
|
|
|
|
2020-07-08 11:16:07 +08:00
|
|
|
|
2017-08-01 16:40:17 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-05 06:40:52 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-26 13:39:43 +01:00
|
|
|
|
2015-10-09 15:36:28 +02:00
|
|
|
|
2017-05-26 19:34:11 +02:00
|
|
|
|
2016-01-02 23:06:36 +01:00
|
|
|
|
2016-01-25 17:02:49 +01:00
|
|
|
|
2015-05-26 13:39:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 11:33:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-04 10:23:19 +02:00
|
|
|
|
2020-08-17 18:12:50 +05:30
|
|
|
|
2020-10-28 21:12:30 +08:00
|
|
|
|
2018-08-04 10:23:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-17 18:12:49 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-03 00:51:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-27 21:10:22 -08:00
|
|
|
|
|
|
|
|
|
2018-11-03 00:51:28 +08:00
|
|
|
|
2018-11-03 00:51:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-27 13:53:20 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-17 20:57:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-24 13:16:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 01:18:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-12 15:04:08 -03:00
|
|
|
|
2020-07-23 01:18:04 +08:00
|
|
|
|
2020-02-12 15:04:08 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-13 13:19:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-26 22:43:56 +10:00
|
|
|
|
2019-12-13 13:19:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-06 22:15:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-16 11:48:45 +02:00
|
|
|
|
