Re: [PATCH v2 1/5] PM / OPP: extend DT binding to specify phandle of another node for OPP

[Nishanth Menon <nm@ti.com>]

On 10/17/2013 12:22 PM, Sudeep KarkadaNagesha wrote:
> On 17/10/13 14:22, Rob Herring wrote:
>> On Tue, Oct 8, 2013 at 7:55 AM, Sudeep KarkadaNagesha
>> <Sudeep.KarkadaNagesha@arm.com> wrote:
>>> On 07/10/13 17:01, Rob Herring wrote:
>>>> On 10/01/2013 08:32 AM, Sudeep KarkadaNagesha wrote:
[...]
>>> 3. As part of RFC[1][2], it was also discussed that on some SoCs we need
>>>    multiple OPP profiles/options which it provides but only one of them can
>>>    be used based on the board design. phandle to OPP will also help resolve
>>>    that issue.
>>
>> Then include the OPP required for that board design. You could have
>> dtsi files of OPPs that can be included based on the board.
>>
> 
> I will let Nishanth comment on this.

there are couple of angles to this[1] that Sudeep already pointed at:

A) SoCs like OMAP3430, 3630, 3530, 3730, omap4430, omap4460, omap4470,
omap5430, omap5432, there will at least be 2 dtsi *per* OPPset dtsi
per chip - and we have OPP sets per device inside the SoC - one for
CPU, one for GPU, one for IVA(accelerator), one for l3 (interconnect).
Further, when we go to newer variants like AM335x,AM437x,DRA7 - the
opp sets can increase to around 4/5 per domain per chip. Most of these
are deterministic based on Efused bit fields.
-> On this angle, arch/arm/mach-imx/mach-imx6q.c is a good example of
a similar challenge - here OPP enable/disable of hardcoded frequency
is kept in kernel, but data is picked up from SoC dts - not a good
story when we want to maintain old dtb compatibility - if frequency
changes in either dts/kernel, we wont function.
-> We are working internally to a potentially generic solution to
address this - not yet in a stage even for RFC -> if that is possible
to be done, then we dont need profiles to handle things, instead an
alternative constraint description is provided in dts. or we could
force folks to use specific dtsis OR allow generic handling based on
profiles.

B) now we can have a chip which can support a high frequency (efuse
will say so), however board characteristics(Power Distribution Network
requirements) may not be capable of allowing the chip to perform. We
can argue saying that "why would anyone put a higher performing chip
on a not-capable board?" - but we all know the reality of marketting
folks and cost of chip story.. but this is a real constraint when we
try to support our SoCs on as many platforms as possible and enabling
Linux on all those platforms.
-> We could use profiles to deal with this.
-> we could use dtsi override with OPP to deal with this
OR
-> we could use custom properties (something like
ti,non-optimal-board-design ;) ).

My personal preference is to state hardware capability solely in dts
and kernel is just operations on the dts data. OPP profiles did seem
to me to be the intutive way to do that job as it does describe
exactly wha the hardware capabilities were. Creating n different dtsis
is possible per device, but it essentially does describe the same
information.

[1] http://www.spinics.net/lists/cpufreq/msg06685.html
-- 
Regards,
Nishanth Menon