trap in modprobing sun50i_cpufreq_nvmem - collective thinking needed....

Skip to first unread message

Jun 16, 2021, 5:07:00 AM6/16/21
to linux-sunxi
Guys - I need some collective thinking....

I'm working on adding cpufreq support on h616 and can't overcome kernel traps when i'm modprobing sun50i_cpufreq_nvmem module. 
Module seems correctly read nvmem cpu speed bin but later traps are like this:

Looking on trap log i see 
"WARNING: CPU: 1 PID: 4709 at drivers/opp/core.c:1908 dev_pm_opp_set_prop_name+0x94/0xa0".
This seems to correspond to
I'm reading this as maybe issue of more than 1 updators are updating DT (i.e. like maybe multiple CPU doing in parallel?)

This sun50i_cpufreq_nvmem module loads ok on h6 - but traps on h616 with error code -17 (file exists). 
I started to think maybe root cause is: input data supplied to dev_pm_opp_set_prop_name is different between h6 and h616. So I made sure h616 cpu definitions in DT are exactly the same like in working h6. Used h616 opp table also is  as close as possible to working h6 (in fact i renamed h6 opp table & update only cpu Vcc fileds). With this module still traps.... 

Next I added in module code some printks:
printk("dev_pm_opp_set_prop_name for cpu:%d name:%s\n", cpu, name) 

It prints exactly the same like in  working h6 and not working h616:

[  170.197292] speedbin from nvram:0

[  170.197321] dev_pm_opp_set_prop_name for cpu:0 name:speed0

[  170.197390] dev_pm_opp_set_prop_name for cpu:1 name:speed0

[  170.197418] dev_pm_opp_set_prop_name for cpu:2 name:speed0

[  170.197443] dev_pm_opp_set_prop_name for cpu:3 name:speed0

it looks to me like issue is dev_pm_opp_set_prop_name function is called multiple in parallel to update dt. Module loading error code -17 (file exist) might be logical here (updator1 meets already updated by updator2).  

For reference: DT with opp &  cpu defs i'm using is like this: 

maybe you have some hints here?

Jun 16, 2021, 5:26:34 AM6/16/21
to linux-sunxi
oh - i forgot to add:
another hypothesis candidate is cpu enablement: maybe psci on h616 not fully "correct" yet (i.e. some cpufreq structs are filled wrongly or only partially)?
Reply all
Reply to author
0 new messages