On Thursday 07 April 2016 14:00:36 Viresh Kumar wrote:
> On 01-04-16, 09:15, Rob Herring wrote:
> > On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar
> > wrote:
> > >
> > >
> > > And the cpufreq-dt driver can match /cpus node's compatible string against
> > > "operating-points-v2" and create a device
On 01-04-16, 09:15, Rob Herring wrote:
> On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar wrote:
> > So you mean for future DT files we can have something like this:
> >
> > cpus {
> > compatible = "operation-points-v2";
> > #address-cells = <1>;
> >
On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar wrote:
> Cc'ing Rob and Mason.
>
> On 30-03-16, 09:53, Arnd Bergmann wrote:
>> I think it should be something in the /cpus or the /opp_table hierarchy,
>> not the root of the device tree, but other than that I don't care much
>> whether it's a variation
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 b
On 01/04/2016 12:23, Viresh Kumar wrote:
> Cc'ing Rob and Mason.
>
> On 30-03-16, 09:53, Arnd Bergmann wrote:
>
>> I think it should be something in the /cpus or the /opp_table hierarchy,
>> not the root of the device tree, but other than that I don't care much
>> whether it's a variation of the
Cc'ing Rob and Mason.
On 30-03-16, 09:53, Arnd Bergmann wrote:
> I think it should be something in the /cpus or the /opp_table hierarchy,
> not the root of the device tree, but other than that I don't care much
> whether it's a variation of the oppv2 compatible string or an additional
> property i
On Wednesday 30 March 2016 08:52:40 Viresh Kumar wrote:
> On 29-03-16, 21:45, Arnd Bergmann wrote:
> > Regarding new platforms, I'd hope that we could manage to define an
> > extension
> > to the oppv2 binding that marks a machine as compatible with opp, so we can
>
> The extension of oppv2 bindi
On 29-03-16, 21:45, Arnd Bergmann wrote:
> Regarding new platforms, I'd hope that we could manage to define an extension
> to the oppv2 binding that marks a machine as compatible with opp, so we can
The extension of oppv2 binding or compatible string is for platforms that really
need extend oppv2
On Tuesday 29 March 2016 22:12:09 you wrote:
> On 29-03-16, 17:14, Arnd Bergmann wrote:
> > if (of_device_match(of_root, compat))
>
> You meant of_match_node() here, right?
>
Yes, sorry for the confusion.
Arnd
On Tuesday 29 March 2016 22:06:49 Viresh Kumar wrote:
> On 29-03-16, 17:14, Arnd Bergmann wrote:
> > On Tuesday 29 March 2016 12:09:48 Viresh Kumar wrote:
> > > +config CPUFREQ_DT_PLATDEV
> > > + bool
> > > + depends on CPUFREQ_DT
> >
> > The 'depends on' line is redundant as you always 'select' t
On 29-03-16, 17:14, Arnd Bergmann wrote:
> if (of_device_match(of_root, compat))
You meant of_match_node() here, right?
> platform_device_register_simple(NULL, "cpufreq-dt", 0, NULL, 0);
--
viresh
On 29-03-16, 17:14, Arnd Bergmann wrote:
> On Tuesday 29 March 2016 12:09:48 Viresh Kumar wrote:
> > +config CPUFREQ_DT_PLATDEV
> > + bool
> > + depends on CPUFREQ_DT
>
> The 'depends on' line is redundant as you always 'select' the code
> from CPUFREQ_DT. Since they are always set together, y
On Tuesday 29 March 2016 12:09:48 Viresh Kumar wrote:
> Multiple platforms are using the generic cpufreq-dt driver now, and all
> of them are required to create a platform device with name "cpufreq-dt",
> in order to get the cpufreq-dt probed.
>
> Many of them do it from platform code, others have
Multiple platforms are using the generic cpufreq-dt driver now, and all
of them are required to create a platform device with name "cpufreq-dt",
in order to get the cpufreq-dt probed.
Many of them do it from platform code, others have special drivers just
to do that.
It would be more sensible to
14 matches
Mail list logo
