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

[Lokesh Vutla]

On Thursday 28 November 2013 04:18 AM, Vaibhav Bedia wrote:
> 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.
Thanks for the clear explanation. Now I get the point.
> 
> 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.
I agree with you, we need to have EEPROM to have the safe OPP.
Unfortunately we don't have this information.
I am sure people will not accept to boot at lowest OPP.

I read more about it and got inputs from Sekhar. I came to know that there is a DEV_ATTRIBUTE register
which tells about the safest OPP to boot with. Looks like this should be sufficient to get the values.
Ill add this code and update the patch.

Thanks and regards,
Lokesh



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