On Fri, Jun 10, 2016 at 10:47:35AM +0200, Ulf Hansson wrote: <snip> > >> > >> I don't think this will work! > >> > >> When building a multi defconfig for ARM, you might overwrite the > >> suspend_ops (there's only one set) as here you don't know that it's > >> actually the QCOM platform that is running, right!? > >> > >> Perhaps this code actually belongs closer to the cpuidle driver? > > > > Hmmmm, I might have to get creative. I originally had a DT entry for the pm, > > but that doesn't make sense as this is purely a software construct. The db410c > > uses the arm cpuidle driver so I can't really hook it in there. I'll have to > > come up with something else. > > I did a little research. > > I think you should be able to use the struct cpuidle_ops->init() > callback. This is being invoked when the arm cpuidle driver is > initialized. > > arm_idle_init() > ->arm_cpuidle_init() > ->cpuidle_ops->init() Ah I'll see if I can get that to work. Thanks for the pointer. > > In the QCOM case, it's the spm driver that registers these cpuidle_ops > (drivers/soc/qcom/spm.c). If you fold in the code from $subject patch > in qcom_cpuidle_init(), that should work I think. Only for the 32 bit processor case. The SPM is not used for the 64 bit procs. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
