[RFC] cpufreq-cpu0: allow OPP table supplied by platform

[RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Jisheng Zhang]

Hi all,

cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue to address.
The opp is different between chips even on the same step SoC, BG2Q for example.
we can calculate the OPP table from the value of one OTP register. We have two
solutions:

1. bootloader reads OTP register and calculate the OPP table then change dtb
danamically

2. supply one driver in mach-berlin to initialize the OPP table; and modify
cpufreq-cpu0 to allow platform supply OPP table, fall back to of_init_opp_table()
if there's no OPP table.

Which solution is better?

Thanks in advance,
Jisheng

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Viresh Kumar]

On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
> Hi all,
>
> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue to address.
> The opp is different between chips even on the same step SoC, BG2Q for example.
> we can calculate the OPP table from the value of one OTP register. We have two
> solutions:
>
> 1. bootloader reads OTP register and calculate the OPP table then change dtb
> danamically
>
> 2. supply one driver in mach-berlin to initialize the OPP table; and modify
> cpufreq-cpu0 to allow platform supply OPP table, fall back to of_init_opp_table()
> if there's no OPP table.
>
> Which solution is better?

I think we can go ahead with second option here. We can just check if opp tables
are already initialized or not. In case they are, don't probe from dt..

But lets see with others have to say here..

--
viresh

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Viresh Kumar]

Fixing Rafael's id.

On 13 March 2014 16:25, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
>> Hi all,
>>
>> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue to address.
>> The opp is different between chips even on the same step SoC, BG2Q for example.
>> we can calculate the OPP table from the value of one OTP register. We have two
>> solutions:
>>
>> 1. bootloader reads OTP register and calculate the OPP table then change dtb
>> danamically
>>
>> 2. supply one driver in mach-berlin to initialize the OPP table; and modify
>> cpufreq-cpu0 to allow platform supply OPP table, fall back to of_init_opp_table()
>> if there's no OPP table.
>>
>> Which solution is better?
>
> I think we can go ahead with second option here. We can just check if opp tables
> are already initialized or not. In case they are, don't probe from dt..
>
> But lets see with others have to say here..
>
> --
> viresh

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Jisheng Zhang]

Fixing lakml :)

sorry

On Thu, 13 Mar 2014 03:56:46 -0700
Viresh Kumar <viresh.kumar@linaro.org> wrote:

> Fixing Rafael's id.
> 
> On 13 March 2014 16:25, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
> >> Hi all,
> >>
> >> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue
> >> to address. The opp is different between chips even on the same step
> >> SoC, BG2Q for example. we can calculate the OPP table from the value of
> >> one OTP register. We have two solutions:
> >>
> >> 1. bootloader reads OTP register and calculate the OPP table then change
> >> dtb danamically
> >>
> >> 2. supply one driver in mach-berlin to initialize the OPP table; and
> >> modify cpufreq-cpu0 to allow platform supply OPP table, fall back to
> >> of_init_opp_table() if there's no OPP table.
> >>
> >> Which solution is better?
> >
> > I think we can go ahead with second option here. We can just check if opp
> > tables are already initialized or not. In case they are, don't probe from
> > dt..
> >
> > But lets see with others have to say here..
> >
> > --
> > viresh

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Sören Brinkmann]

On Thu, 2014-03-13 at 07:44PM +0800, Jisheng Zhang wrote:
> Fixing lakml :)
> 
> sorry
> 
> On Thu, 13 Mar 2014 03:56:46 -0700
> Viresh Kumar <viresh.kumar@linaro.org> wrote:
> 
> > Fixing Rafael's id.
> > 
> > On 13 March 2014 16:25, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
> > >> Hi all,
> > >>
> > >> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue
> > >> to address. The opp is different between chips even on the same step
> > >> SoC, BG2Q for example. we can calculate the OPP table from the value of
> > >> one OTP register. We have two solutions:
> > >>
> > >> 1. bootloader reads OTP register and calculate the OPP table then change
> > >> dtb danamically
> > >>
> > >> 2. supply one driver in mach-berlin to initialize the OPP table; and
> > >> modify cpufreq-cpu0 to allow platform supply OPP table, fall back to
> > >> of_init_opp_table() if there's no OPP table.
> > >>
> > >> Which solution is better?
> > >
> > > I think we can go ahead with second option here. We can just check if opp
> > > tables are already initialized or not. In case they are, don't probe from
> > > dt..
> > >
> > > But lets see with others have to say here..

This might become useful for Zynq as well. We essentially allow to boot
with all kind of different frequencies and depending on how the PLL, and clock
registers get setup by the bootloader, certain frequencies may or may
not become possible. Having a way to dynamically build an OPP table
would probably be a nicer way than having to tell everybody to adjust
the DT according to how the bootloader sets up the clocks.

	Sören

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Shawn Guo]

On Thu, Mar 13, 2014 at 07:44:24PM +0800, Jisheng Zhang wrote:
> > On 13 March 2014 16:25, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
> > >> Hi all,
> > >>
> > >> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue
> > >> to address. The opp is different between chips even on the same step
> > >> SoC, BG2Q for example. we can calculate the OPP table from the value of
> > >> one OTP register. We have two solutions:
> > >>
> > >> 1. bootloader reads OTP register and calculate the OPP table then change
> > >> dtb danamically
> > >>
> > >> 2. supply one driver in mach-berlin to initialize the OPP table; and
> > >> modify cpufreq-cpu0 to allow platform supply OPP table, fall back to
> > >> of_init_opp_table() if there's no OPP table.
> > >>
> > >> Which solution is better?
> > >
> > > I think we can go ahead with second option here. We can just check if opp
> > > tables are already initialized or not. In case they are, don't probe from
> > > dt..
> > >
> > > But lets see with others have to say here..

Yea, we had gone for the second option on imx6q-cpufreq driver with
commit 20b7cbe (cpufreq: imx6q: add of_init_opp_table).

Shawn

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Nishanth Menon]

On 03/14/2014 07:32 AM, Shawn Guo wrote:
> On Thu, Mar 13, 2014 at 07:44:24PM +0800, Jisheng Zhang wrote:
>>> On 13 March 2014 16:25, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>>> On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue
>>>>> to address. The opp is different between chips even on the same step
>>>>> SoC, BG2Q for example. we can calculate the OPP table from the value of
>>>>> one OTP register. We have two solutions:
>>>>>
>>>>> 1. bootloader reads OTP register and calculate the OPP table then change
>>>>> dtb danamically
>>>>>
>>>>> 2. supply one driver in mach-berlin to initialize the OPP table; and
>>>>> modify cpufreq-cpu0 to allow platform supply OPP table, fall back to
>>>>> of_init_opp_table() if there's no OPP table.
>>>>>
>>>>> Which solution is better?
>>>>
>>>> I think we can go ahead with second option here. We can just check if opp
>>>> tables are already initialized or not. In case they are, don't probe from
>>>> dt..
>>>>
>>>> But lets see with others have to say here..
> 
> Yea, we had gone for the second option on imx6q-cpufreq driver with
> commit 20b7cbe (cpufreq: imx6q: add of_init_opp_table).

There might be a better alternative here given the scope of potential
reuse cross SoCs - a generic opp modifier logic which'd work for all
of us. I will let Dave Gerlach post his series to give an idea.

-- 
Regards,
Nishanth Menon

Re: [RFC] cpufreq-cpu0: allow OPP table supplied by platform

[Dave Gerlach]

On 03/14/2014 10:36 AM, Nishanth Menon wrote:
> On 03/14/2014 07:32 AM, Shawn Guo wrote:
>> On Thu, Mar 13, 2014 at 07:44:24PM +0800, Jisheng Zhang wrote:
>>>> On 13 March 2014 16:25, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>>>> On 13 March 2014 16:18, Jisheng Zhang <jszhang@marvell.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> cpufreq-cpu0 is suitable for Marvell Berlin SoC. But there's one issue
>>>>>> to address. The opp is different between chips even on the same step
>>>>>> SoC, BG2Q for example. we can calculate the OPP table from the value of
>>>>>> one OTP register. We have two solutions:
>>>>>>
>>>>>> 1. bootloader reads OTP register and calculate the OPP table then change
>>>>>> dtb danamically
>>>>>>
>>>>>> 2. supply one driver in mach-berlin to initialize the OPP table; and
>>>>>> modify cpufreq-cpu0 to allow platform supply OPP table, fall back to
>>>>>> of_init_opp_table() if there's no OPP table.
>>>>>>
>>>>>> Which solution is better?
>>>>>
>>>>> I think we can go ahead with second option here. We can just check if opp
>>>>> tables are already initialized or not. In case they are, don't probe from
>>>>> dt..
>>>>>
>>>>> But lets see with others have to say here..
>>
>> Yea, we had gone for the second option on imx6q-cpufreq driver with
>> commit 20b7cbe (cpufreq: imx6q: add of_init_opp_table).
>
> There might be a better alternative here given the scope of potential
> reuse cross SoCs - a generic opp modifier logic which'd work for all
> of us. I will let Dave Gerlach post his series to give an idea.

I have posted an RFC for a small opp-modifier framework along with a 
driver that uses it to enable or disable OPPs based on a register value. 
I copied everyone from this thread but in case I forgot anyone the 
series is here http://marc.info/?l=linux-pm&m=139482524506817&w=2.

Regards,
Dave

>