[U-Boot] [PATCH V2 10/14] ARM: AM43xx: clocks: Update DPLL details for EPOS EVM

[Lokesh Vutla]

On Wednesday 27 November 2013 05:36 AM, Vaibhav Bedia wrote:
> On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla <lokeshvutla at ti.com> wrote:
>> On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote:
>>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla <lokeshvutla at ti.com> wrote:
>>>> Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
>>>> Following are the DPLL locking frequencies at OPP NOM:
>>>> MPU locks at 600MHz
>>>> Core locks at 1000MHz
>>>> Per locks at 960MHz
>>>> DDR locks at 266MHz
>>>>
>>>
>>> As mentioned earlier, this hardcoded frequency approach is really not
>>> scalable when you have
>>> more device variants coming in. Just look at the AM335x changes on how
>>> this gets complicated.
>> We already had a discussion on this during V1 of this series.
>> Sekhar and Tom replied to you comments. What is the point in asking the same question again?
>>
> 
> Because i don't recall any conclusion being reached on that thread? Because the
> objective of a patch review is to come up with a solution which learns
> from the past
> and doesn't try to brush the past issues under the carpet under the
> assumption that
> the shiny new device will never have bugs?
Yes I agree with you point.
But I have replied to this thread saying that 
"Currently these values are not blown in eFuse. Both EPOS and GP evms support 
OPP NOM. So there is no harm in booting at OPP NOM here."
You haven't come back on that. 

> 
>> Since you are very concerned here. Why are you feeling it so complicated when new variants come?
>> We can always differentiate the new variant from the old ones and can pass dpll structure accordingly. It is just a matter a one if condition.
>> It ll be better to look at the current code and see how cleanly it is done.
>>
> 
> As the OPP decoder table in the AM335x datasheet will tell you it's
> not that simple.
I guess your previous comment was about the code complexity when a new variant of the board comes.
Coming to OPP tables:
Frankly, I don't know what happened during AM33xx times. I am just trying to make things simpler and cleaner.
Do you mean here, we need to support  all OPPs in U-Boot?
Are you expecting complete OPP table to get from e-fuse values for AM43xx?

As per my understanding from working on OMAP, U-Boot supports only OPP_NOM( or the safe OPP to boot).

Please correct me if I am wrong.

Thanks and regards,
Lokesh 
> Frankly, i could care less about this change...
>