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

[Vaibhav Bedia]

On Wed, Nov 27, 2013 at 1:58 AM, Lokesh Vutla <lokeshvutla at ti.com> wrote:
> 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.
>

Sorry i somehow missed replying to that.

So here's the thing. Right now you are told that all the devices
support OPP NOM and hence as the U-Boot maintainer for AM437x
you go ahead and use that information. However, few days down the
line you'll have different speed grades coming out of the fab and some
of them are going to have a max OPP that's lower than what OPP_NOM
means. After a few devices blow up and some mails go around the
world your code gets blamed and you hastily come up with a patch
which tries to address the slower devices. The future you then realizes
that you need some mechanism the differentiate the old devices without
the eFuse information and the new which do. You might discover that
there's some board rev check or something like that can be used. But that's
only if you are lucky. I hope you see where this is going.

So what can you do?
A. Go ahead with OPP NOM and be prepared to debug boot failures on
random boards only to discover that the devices are not meant to operate
at OPP_NOM.

B. Find the lowest common denominator for the supported OPPs and use
that in here. This might end up making some folks unhappy but then you
need to make a choice between fast and reliable and i would personally go
for the latter. If folks really care about boot times someone needs to start
putting the right information in the eFuses at the right time.

>>
>>> 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.
>

I hope the verbiage above helps you get an idea of why i am insisting on
a change here.

I am not asking U-Boot to have the complete OPP table. That's for the kernel
+ device-tree to handle. If there's no eFuse data in the devices, hard luck.
We do the only thing we can for reliable boots and that's to use an OPP which
is reliable all the time.

If you still think OPP_NOM is the right choice please go ahead and use it.

Regards,
Vaibhav