On 01-04-16, 14:30, Mason wrote:
Hmmm... I'm using the older operating-points prop in my platform's DT. Why can't we define a new property (e.g. "enable-generic-cpufreq") which registers the "cpufreq-dt" pseudo-device?
DT is all about expressing hardware in a file. The same bindings should be usable across any operating system, not just Linux. And so we shouldn't have any OS or software-implementation specific properties here.
And platforms that manually register "cpufreq-dt" would be automatically white-listed, even if they don't have the new property, to maintain backward-compat?
Its not about just making it work, otherwise we would have done it long time back by creating a DT node for cpufreq-dt driver.
@Rob: Will that be acceptable to you? We are discussing (again) about how to probe cpufreq-dt driver automatically for platforms :)
The cpus node doesn't have any 'compatible' property today, and I will be required to add that in this case.
Why does it need a compatible prop?
That compatible property will describe how to parse/describe operating-points for a CPU. Any driver, which has the ability to parse those bindings can do things base on such a compatibility string.
I hope you got the idea.