On Tuesday, May 27, 2014 05:48:27 AM Viresh Kumar wrote:
> On 27 May 2014 05:34, Viresh Kumar wrote:
> > We are also using it for cpu->dev_id, but that's not so important. This
> > routine wouldn't have existed if you wouldn't have asked for it. It is
> > just a wrapper over of_init_opp_table, whi
On 27 May 2014 05:34, Viresh Kumar wrote:
> We are also using it for cpu->dev_id, but that's not so important. This
> routine wouldn't have existed if you wouldn't have asked for it. It is
> just a wrapper over of_init_opp_table, which also has a dummy
> implementation when its not supported.
>
>
On 27 May 2014 05:02, Rafael J. Wysocki wrote:
> Do you actually use cpu anywere in this function for anything other than
> just accessing cpu->dev? If not, why not to pass cpu->dev to it and
> move it somewhere in the OPP core?
We are also using it for cpu->dev_id, but that's not so important.
On Thursday, May 22, 2014 11:07:28 AM Viresh Kumar wrote:
> Drivers expecting CPU's OPPs from device tree initialize OPP table themselves
> by
> calling of_init_opp_table() and there is nothing driver specific in that. They
> all do it in the same redundant way.
>
> It would be better if we can g
Drivers expecting CPU's OPPs from device tree initialize OPP table themselves by
calling of_init_opp_table() and there is nothing driver specific in that. They
all do it in the same redundant way.
It would be better if we can get rid of redundancy by initializing CPU OPPs from
CPU core code for al
5 matches
Mail list logo