Hi Sato-san,
On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
<ysato@xxxxxxxxxxxxxxxxxxxx> wrote:
> Allows initialization as CLOCKSOURCE.
>
> Signed-off-by: Yoshinori Sato <ysato@xxxxxxxxxxxxxxxxxxxx>
Thanks for your patch!
> --- a/drivers/clocksource/sh_tmu.c
> +++ b/drivers/clocksource/sh_tmu.c
> @@ -495,7 +514,12 @@ static int sh_tmu_map_memory(struct sh_tmu_device *tmu)
>
> static int sh_tmu_parse_dt(struct sh_tmu_device *tmu)
> {
> - struct device_node *np = tmu->pdev->dev.of_node;
> + struct device_node *np;
Technically, np might be used uninitialized.
> +
> + if (tmu->pdev)
> + np = tmu->pdev->dev.of_node;
If you would set up tmu->np in sh_tmu_setup_pdev()...
> + if (tmu->np)
> + np = tmu->np;
... you could just assign np = tmu->np unconditionally.
>
> tmu->model = SH_TMU;
> tmu->num_channels = 3;
> @@ -665,6 +734,7 @@ static void __exit sh_tmu_exit(void)
> platform_driver_unregister(&sh_tmu_device_driver);
> }
>
> +TIMER_OF_DECLARE(sh_tmu, "renesas,tmu", sh_tmu_of_register);
As there are now two entry points, the device is actually probed twice:
once from TIMER_OF_DECLARE/sh_tmu_of_register(), and a second
time from platform_driver/sh_tmu_probe().
E.g. on Armadillo-800-EVA with R-Mobile A1 (booting Linux on ARM
(not SH), and using TMU as the main clock source):
timer@fff80000 ch0: used for clock events
timer@fff80000 ch0: used for periodic clock events
timer@fff80000 ch1: used as clock source
clocksource: timer@fff80000: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 154445288668 ns
...
fff80000.timer ch0: used for clock events
genirq: Flags mismatch irq 16. 00015a04 (fff80000.timer) vs.
00015a04 (timer@fff80000)
fff80000.timer ch0: failed to request irq 16
fff80000.timer ch1: used as clock source
clocksource: fff80000.timer: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 154445288668 ns
After this, the timer seems to be stuck, and the boot is blocked.
On Marzen with R-Car H1 (booting Linux on ARM (not SH), and using
arm_global_timer as the main clock source), I also see the double
timer probe, but no such lock-up. I expect you to see the double
timer probe on SH775x, too?
The double probe can be fixed by adding a call to
of_node_set_flag(np, OF_POPULATED) at the end of sh_tmu_of_register()
in case of success, cfr. [1].
I haven't found the cause of the stuck timer on R-Mobile A1 yet;
both the TMU clock and the A4R power domain seem to be activated...
> #ifdef CONFIG_SUPERH
> sh_early_platform_init("earlytimer", &sh_tmu_device_driver);
> #endif
[1] "[PATCH] clocksource/drivers/renesas-ostm: Avoid reprobe after
successful early probe"
https://lore.kernel.org/all/bd027379713cbaafa21ffe9e848ebb7f475ca0e7.1710930542.git.geert+renesas@xxxxxxxxx/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
