On 01/12, Viresh Kumar wrote:
On 11-01-16, 18:20, Stephen Boyd wrote:
On 12/22, Viresh Kumar wrote:
OPP layer manages it now and cpufreq-dt driver doesn't need it. But, we still need to check for availability of resources for deferred probing.
Why? It seems cleaner to let OPP layer return an error indicating probe defer or failure when we try to initialize it. That way we aren't duplicating the same logic in two places to figure out if a regulator or clock is ready.
cpufreq driver's ->init() callback doesn't return the error value properly to the probe() function, and so it was done this way in the first place. The problem is in subsys framework. I tried to fix it but it was rejected and we need to fix it some other way:
Yeah I don't understand why we at least can't populate the OPP structures and get the clocks and regulators for all the CPU devices before we register the dt_cpufreq_driver structure. The CPU devices should exist at that point, and we can wait to do CPUfreq transitions until the regulators/clocks for all the CPUs are registered. Sure we'd need to find the OPPs that are being shared in the cpufreq_init callback and populate the cpu frequency tables, etc., but that's not a big deal.
Making a CPU processor driver on ARM/non-ACPI systems would be to solve the problem of all these random things like cpuidle-arm and cpufreq-dt going through the list of cpu devices and hooking up stuff to the cpuidle, cpufreq, and thermal frameworks. That's a separate but related problem to probe defering the cpufreq-dt driver.