On Mon, 17 Apr 2023 11:01:15 +0100, AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx> wrote: > > Il 17/04/23 11:06, walter.chang@xxxxxxxxxxxx ha scritto: > > From: Walter Chang <walter.chang@xxxxxxxxxxxx> > > > > The MT69XX series SoCs have the incomplete implementation issue in the > > mmio timer. Specifically, the hardware only implements the TVAL > > functionality, but not the CVAL functionality. This hardware limitation > > will cause set_next_event_mem() fail to set the actual expiration time > > when writing a value to the CVAL. On these platforms, the mmio timer's > > internal expiration time will still be judged as 0 (the value of TVAL), > > resulting in the mmio timer not functioning as intended. > > > > The workaround is to use TVAL in addition to CVAL for these affected > > platforms. > > > > Signed-off-by: Walter Chang <walter.chang@xxxxxxxxxxxx> > > --- > > Documentation/arm64/silicon-errata.rst | 4 ++++ > > drivers/clocksource/Kconfig | 9 ++++++++ > > drivers/clocksource/arm_arch_timer.c | 29 ++++++++++++++++++++++++++ > > 3 files changed, 42 insertions(+) > > > > diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst > > index ec5f889d7681..ca1893713a4c 100644 > > --- a/Documentation/arm64/silicon-errata.rst > > +++ b/Documentation/arm64/silicon-errata.rst > > @@ -209,3 +209,7 @@ stable kernels. > > +----------------+-----------------+-----------------+-----------------------------+ > > | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | > > +----------------+-----------------+-----------------+-----------------------------+ > > + > > ++----------------+-----------------+-----------------+-----------------------------+ > > +| MediaTek | MT69XX series | #690001 | MEDIATEK_ERRATUM_690001 | > > ++----------------+-----------------+-----------------+-----------------------------+ > > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > > index 5fc8f0e7fb38..475356b8dbdc 100644 > > --- a/drivers/clocksource/Kconfig > > +++ b/drivers/clocksource/Kconfig > > @@ -368,6 +368,15 @@ config SUN50I_ERRATUM_UNKNOWN1 > > the Allwinner A64 SoC. The workaround will only be active if the > > allwinner,erratum-unknown1 property is found in the timer node. > > +config MEDIATEK_ERRATUM_690001 > > + bool "Workaround for MediaTek MT69XX erratum 690001" > > + depends on ARM_ARCH_TIMER && ARM64 > > + help > > + This option enables a workaround for incomplete implementation > > + in the MMIO timer on the MediaTek MT69XX SoCs. The workaround > > + will only be active if mediatek,erratum-690001 property is > > + found in the timer node. > > + > > config ARM_GLOBAL_TIMER > > bool "Support for the ARM global timer" if COMPILE_TEST > > select TIMER_OF if OF > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c > > index e09d4427f604..920570d57fc0 100644 > > --- a/drivers/clocksource/arm_arch_timer.c > > +++ b/drivers/clocksource/arm_arch_timer.c > > @@ -389,6 +389,10 @@ static u64 notrace sun50i_a64_read_cntvct_el0(void) > > } > > #endif > > +#ifdef CONFIG_MEDIATEK_ERRATUM_690001 > > +static bool arch_timer_mem_sne_use_tval __ro_after_init; > > What about reusing part of the CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND logic and > adding something like CONFIG_ARM_ARCH_TIMER_MEM_WORKAROUND? I don't think there is *any* need for the out-of-line stuff on any of the memory-mapped accesses, if only because they are not inlined the first place, and that there is no performance requirements around this timer (it should hardly ever be used as the sched clock, for example). Despite being part of the same driver, the sysreg and MMIO timers are vastly different and keeping them together has only been a nuisance. Someone should throw an axe at this stuff. M. -- Without deviation from the norm, progress is not possible.
