Re: [RESEND v7 08/37] clocksource: sh_tmu: CLOCKSOURCE support.

Geert Uytterhoeven <[email protected]>
Newsgroups gmane.linux.ide,gmane.linux.ports.sh.devel,gmane.linux.drivers.devicetree,gmane.linux.kernel,gmane.linux.kernel.renesas-soc,gmane.linux.kernel.clk,gmane.comp.video.dri.devel,gmane.linux.kernel.pci,gmane.linux.serial
Message-ID <CAMuHMdUVEj-TEV5iYjknTKOJ0_MBO8sMzc6-7NSAL-XoxLGn9g@mail.gmail.com>
Hi Sato-san,

On Thu, Apr 4, 2024 at 7:15 AM Yoshinori Sato
<[email protected]> wrote:
> Allows initialization as CLOCKSOURCE.
>
> Signed-off-by: Yoshinori Sato <[email protected]>

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@glider.be/

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.