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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux