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)?
środa, 16 czerwca 2021 o 11:07:00 UTC+2 [email protected] napisał(a): > 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: https://pastebin.com/hrTrRvY5 > > 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 > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/opp/core.c?h=v5.12.10#n1878 > 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) > before > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/cpufreq/sun50i-cpufreq-nvmem.c?h=v5.12.10#n114 > ; > > 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: > https://pastebin.com/vqE9UFZu > > maybe you have some hints here? > > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/44caee00-a4d5-4f12-b68e-69491b5ad7a7n%40googlegroups.com.
