Re: [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/01/2013 06:15 AM, Nishanth Menon wrote:
> On 15:51-20130731, Stephen Warren wrote:
>> On 07/31/2013 08:46 AM, Nishanth Menon wrote:
>> ...
>>> Let me try to explain since SoCs such as OMAP/AM family dont make life
>>> trivial :)..
>>>
>>> An legacy example[1][2]
>>>
>>> SoC DM explains that the chip is capable of X opps:
>>> opp1, 2 - for all devices
>>> opp1,2, 3 - if efuse bit X@y is set
>>> opp1,2,3,4 - if efuse bit X@y is set AND Board design meets SoC vendors
>>> requirements (including additional features A, B is enabled).
>>
>> Hopefully the text "board design meets SoC vendors requirements" means
>> something like "the board has a big fan capable of dissipating a lot of
>> heat" and not "the board manufacturer paid us a lot of money to license
>> the 'go faster' feature". The former could well be suitable to represent
>> in DT, the latter not.
> 
> Nope, these are technical requirements. In my company, these
> guidelines are called Power Distribution Network guideline - which
> control the IRDrop within reasonable limit, running DPLLs are varied
> frequencies have different current draw characteristics, such that noise
> limits, cleanup capacitors etc. For boards that dont care too much about
> higher frequencies, they tend to skimp a little on caps and board
> routing constraints to save on BOM (Bill Of Materials) cost.
> 
> I am sure similar constraints do exist in other SoC vendors as well.

Great, sounds good then.