Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put

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

 



Hi Tony,

On Thu, Apr 07, 2022 at 02:08:05PM +0300, Tony Lindgren wrote:
> * Tony Lindgren <tony@xxxxxxxxxxx> [220407 08:23]:
> > Hi,
> > 
> > * Maxime Ripard <maxime@xxxxxxxxxx> [220407 07:51]:
> > > I haven't been able to find an omap3 board or a qemu target that could
> > > help me debug this, but I fixed a few issues already that could fix omap
> > > as well.
> > > 
> > > Could you test today's
> > > https://github.com/mripard/linux/tree/rpi/clk-improvements-more-fixes
> > > 
> > > And let me know if it works?
> > 
> > Yes sorry I've been meaning to try your fixes but had some file system
> > issues on my build box after a power cut while updating the system. All
> > good now though, I should be able to give it a try this afternoon.
> 
> It now boots, but does a lot of checks on the clocks before the timers
> get initialized compared to v5.18-rc1.

I was about to say that this is fairly normal with the new behaviour,
but I've reworked the initial patch in that discussion to only call into
clk_set_rate_range if there was a range on that clock to begin with.

It should remove the huge majority of the checks you mentioned (and
hopefully get rid of most of the side effects as well).

It's now pushed to my branch, so it would be awesome if you could test
again.

> And then there's this:
> 
> [    2.532501] clk_core_set_rate_nolock +2293: ssi_ssr_fck_3430es2 affected!
> ...
> [    2.554443]  unwind_backtrace from show_stack+0x10/0x14
> [    2.559875]  show_stack from dump_stack_lvl+0x40/0x4c
> [    2.565093]  dump_stack_lvl from clk_core_set_rate_nolock+0x278/0x2c4
> [    2.571777]  clk_core_set_rate_nolock from clk_set_rate_range_nolock.part.0+0x154/0x384
> [    2.580047]  clk_set_rate_range_nolock.part.0 from __clk_put+0x64/0x174
> [    2.586853]  __clk_put from clk_add_alias+0x48/0x5c
> [    2.591918]  clk_add_alias from _add_clkdev.part.0+0x94/0x154
> [    2.597869]  _add_clkdev.part.0 from omap_device_alloc+0x88/0x114
> [    2.604156]  omap_device_alloc from _omap_device_notifier_call+0x25c/0x3b4
> [    2.611236]  _omap_device_notifier_call from blocking_notifier_call_chain+0x6c/0x90
> [    2.619140]  blocking_notifier_call_chain from device_add+0x360/0x894
> [    2.625823]  device_add from of_platform_device_create_pdata+0x8c/0xb8
> [    2.632568]  of_platform_device_create_pdata from of_platform_bus_create+0x194/0x22c
> [    2.640563]  of_platform_bus_create from of_platform_bus_create+0x1e0/0x22c
> [    2.647735]  of_platform_bus_create from of_platform_populate+0x60/0xb8
> [    2.654571]  of_platform_populate from pdata_quirks_init+0xb4/0xe0
> [    2.660980]  pdata_quirks_init from omap_generic_init+0xc/0x18
> [    2.666992]  omap_generic_init from customize_machine+0x1c/0x30
> [    2.673126]  customize_machine from do_one_initcall+0x44/0x24c
> [    2.679138]  do_one_initcall from kernel_init_freeable+0x1e8/0x298
> [    2.685546]  kernel_init_freeable from kernel_init+0x14/0x140
> [    2.691467]  kernel_init from ret_from_fork+0x14/0x24

It shouldn't be there anymore after that rework, but I couldn't find
wher the ssi_ssr_fck clock was defined? The only relevant driver seems
to be omap_ssi_core.c but I don't see any clock driver registered there
either.

Thanks!
Maxime

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux