kernel - Hosts the 0x221E linux distro kernel.

index : kernel

Hosts the 0x221E linux distro kernel.

Ubuntu

summary refs log tree commit diff

path: root/include/linux/mbus.h

diff options

Diffstat (limited to 'include/linux/mbus.h')

0 files changed, 0 insertions, 0 deletions

the assigned hardware timers are never started before (or after) booting Linux. In this condition, any call to function get_cycles() will be returning zero, as CNTVCT_EL0 will always read zero. One common critical symptom of that is trying to use the udelay() function (calling __delay()), which executes the following loop: start = get_cycles(); while ((get_cycles() - start) < cycles) cpu_relax(); which, when CNTVCT_EL0 always reads zero, translates to: while((0 - 0) < 0) ==> while(0 < 0) ... generating an infinite loop, even though zero is never less than zero, but always equal to it (this has to be researched, but it's out of the scope of this commit). To fix this issue on the affected MediaTek platforms, the solution is to simply start the timers that are designed to be System Timer(s). These timers, downstream, are called "CPUXGPT" and there is one timer per CPU core; luckily, it is not necessary to set a start bit on each CPUX General Purpose Timer, but it's conveniently enough to: - Set the clock divider (input = 26MHz, divider = 2, output = 13MHz); - Set the ENABLE bit on a global register (starts all CPUX timers). The only small hurdle with this setup is that it's all done through the MCUSYS wrapper, where it is needed, for each read or write, to select a register address (by writing it to an index register) and then to perform any R/W on a "CON" register. For example, writing "0x1" to the CPUXGPT register offset 0x4: - Write 0x4 to mcusys INDEX register - Write 0x1 to mcusys CON register Reading from CPUXGPT register offset 0x4: - Write 0x4 to mcusys INDEX register - Read mcusys CON register. Finally, starting this timer makes platforms affected by this issue to work correctly. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220613133819.35318-3-angelogioacchino.delregno@collabora.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> 2021-08-14clocksource/drivers/mediatek: Optimize systimer irq clear flow on shutdownFengquan Chen mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow, clear any pending systimer irq when shutdown to avoid suspend aborted due to timer irq pending Also as for systimer in mediatek socs, there must be firstly enable timer before clear systimer irq Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for system timer") Signed-off-by: Fengquan Chen <fengquan.chen@mediatek.com> Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com 2021-06-15clocksource/drivers/mediatek: Ack and disable interrupts on suspendEvan Benn Interrupts are disabled during suspend before this driver disables its timers. ARM trusted firmware will abort suspend if the timer irq is pending, so ack and disable the timer interrupt during suspend. Signed-off-by: Evan Benn <evanbenn@chromium.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210512122528.v4.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid


context:
space:
mode: