[PATCH 2/5] t210: do not enable PLLE and UPHY PLL HW PWRSEQ
Stephen Warren
swarren at wwwdotorg.org
Thu Mar 19 00:25:36 CET 2020
On 3/17/20 7:44 PM, JC Kuo wrote:
> Please refer to "Notes" section in p1337 of Tegra_X1_TRM_DP07225001_v1.3p.pdf.
> There are some implementation considerations for boot software.
OK, I assume you mean this note:
Boot loader should not enable hardware power sequencer. Boot loader
should enable the required PLLs in software controlled state.
That's interesting, since I explicitly added the code to program PLLE in
HW controlled mode after discussing with the relevant HW engineers the
need to clean up the programming sequence in the following pages, and it
was clearly communicated that this was in the context of a bootloader,
and they pointed out that the bootloader needed to enable HW control but
didn't. Sigh. I guess I should have read the sections prior to the
programming sequence too.
So I guess this change is OK, and since we have it downstream it seems
to operate OK in practice too.
Acked-by: Stephen Warren <swarren at nvidia.com>
> Thanks,
> JC
>
> On 3/18/20 1:44 AM, Tom Warren wrote:
>> -----Original Message-----
>> From: Stephen Warren <swarren at wwwdotorg.org>
>> Sent: Tuesday, March 17, 2020 10:30 AM
>> To: Tom Warren <TWarren at nvidia.com>
>> Cc: u-boot at lists.denx.de; Jui Chang Kuo <jckuo at nvidia.com>
>> Subject: Re: [PATCH 2/5] t210: do not enable PLLE and UPHY PLL HW PWRSEQ
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 3/16/20 1:40 PM, twarren at nvidia.com wrote:
>>> From: JC Kuo <jckuo at nvidia.com>
>>>
>>> This commit removes the programming sequence that enables PLLE and
>>> UPHY PLL hardware power sequencers. Per TRM, boot software should
>>> enable PLLE and UPHY PLLs in software controlled power-on state and
>>> should power down PLL before jumping into kernel or the next stage boot software.
>>>
>>> Adds call to board_cleanup_before_linux to facilitate this.
>>
>> This directly contradicts what's in Tegra_X1_TRM_DP07225001_v1.3p.pdf,
>> pages 1340/1341, which is what the code currently implements. Was a newer internal-only TRM published that changed the recommended programming flow?
>> [Tom] JC wrote this, I'll let him answer, but I'll check my TRM to see what the most recent version is. This code is exactly what we have in downstream T210 U-Boot.
>>
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
>
More information about the U-Boot
mailing list