From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lokesh Vutla Date: Fri, 5 May 2017 12:58:24 +0530 Subject: [U-Boot] [PATCH 1/3] arm: am33xx: Fix MPU opp selection In-Reply-To: <20170503154939.GX12511@bill-the-cat> References: <20170502141026.27093-1-lokeshvutla@ti.com> <20170502141026.27093-2-lokeshvutla@ti.com> <20170503123312.GP12511@bill-the-cat> <809ad4dd-e1e1-0af0-373f-899a35ed1c18@ti.com> <20170503152310.GW12511@bill-the-cat> <579644ee-c8b1-b451-a414-630144e04ef6@ti.com> <20170503154939.GX12511@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wednesday 03 May 2017 09:19 PM, Tom Rini wrote: > On Wed, May 03, 2017 at 09:10:35PM +0530, Lokesh Vutla wrote: >> >> >> On Wednesday 03 May 2017 08:53 PM, Tom Rini wrote: >>> On Wed, May 03, 2017 at 07:36:32PM +0530, Lokesh Vutla wrote: >>>> >>>> >>>> On Wednesday 03 May 2017 06:03 PM, Tom Rini wrote: >>>>> On Tue, May 02, 2017 at 07:40:24PM +0530, Lokesh Vutla wrote: >>>>>> Update MPU frequencies and voltages as per the latest >>>>>> DM[1] dated: OCT 2011 Revised APRIL 2016, Section 5.4. >>>>>> Below is the consolidated data: >>>>>> >>>>>> MPU values for PG 2.0 and later(Package ZCZ and ZCE): >>>>>> >>>>>> ------------------------------------------------------- >>>>>> | | ZCZ | ZCE | >>>>>> |-------------------------------------------------------| >>>>>> | | VDD[V] | ARM [MHz] | VDD[V] | ARM [MHz] | >>>>>> |-------|----------|------------|----------|------------| >>>>>> | NITRO | 1.325 | 1000 | NA | NA | >>>>>> |-------|----------|------------|----------|------------| >>>>>> | TURBO | 1.26 | 800 | NA | NA | >>>>>> |-------|----------|------------|----------|------------| >>>>>> |OPP120 | 1.20 | 720 | NA | NA | >>>>>> |-------|----------|------------|----------|------------| >>>>>> |OPP100 | 1.10 | 600 | 1.10 | 600 | >>>>>> |-------|----------|------------|----------|------------| >>>>>> | OPP50 | 0.95 | 300 | 0.95 | 300 | >>>>>> ------------------------------------------------------- >>>>>> >>>>>> There is no eFuse blown on PG1.0 Silicons due to which there is >>>>>> no way to detect the maximum frequencies supported. So default >>>>>> to OPP100 for which both frequency and voltages are common on both >>>>>> the packages. >>>>> >>>>> You say OPP100 here, but the code (and table) is for OPP50. Which means >>>>> a good bit of a speed cut. >>>> >>>> The above table is for PG2.0 and later versions. For PG1.0 ARM runs at >>>> 500MHz in OPP100. Refer Table 5.3 and Table 5.5 in >>>> DM(http://www.ti.com/lit/ds/symlink/am3356.pdf) >>>> >>>>> >>>>> [snip] >>>>>> /* MAIN PLL Fdll = 550 MHz, by default */ >>>>>> #ifndef CONFIG_SYS_MPUCLK >>>>>> -#define CONFIG_SYS_MPUCLK MPUPLL_M_550 >>>>>> +#define CONFIG_SYS_MPUCLK MPUPLL_M_500 >>>>>> #endif >>>>> >>>>> Update the comment please. Better yet, Kconfig migration (as this is >>>>> only an am33xx thing). >>>> >>>> Hmm.. The above value is used only for PG1.0 silicons and the value is >>>> fixed per SoC. Do we need a Kconfig symbol for that? >>> >>> If you can get rid of it, do so, but please make sure to check on how >>> the other am335x boards are making use of it (ie the Siemens stuff). >> >> okay Ill check it. As you said, looks like lot of other users are using it. Ill convert to Kconfig symbol. >> >>> >>>>> [snip] >>>>>> @@ -132,13 +132,21 @@ int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev) >>>>>> >>>>>> sil_rev = readl(&cdev->deviceid) >> 28; >>>>>> >>>>>> - if (sil_rev == 1) >>>>>> - /* PG 2.0, efuse may not be set. */ >>>>>> - return MPUPLL_M_800; >>>>>> - else if (sil_rev >= 2) { >>>>>> + if (sil_rev == 0) { >>>>>> + /* No efuse in PG 1.0. So use OPP100 */ >>>>>> + return MPUPLL_M_500; >>>>> >>>>> Isn't that OPP50? >>>>> >>>>>> + } else if (sil_rev >= 1) { >>>>>> /* Check what the efuse says our max speed is. */ >>>>>> - int efuse_arm_mpu_max_freq; >>>>>> + int efuse_arm_mpu_max_freq, package_type; >>>>>> efuse_arm_mpu_max_freq = readl(&cdev->efuse_sma); >>>>>> + package_type = (efuse_arm_mpu_max_freq & PACKAGE_TYPE_MASK) >> >>>>>> + PACKAGE_TYPE_SHIFT; >>>>>> + >>>>>> + /* PG 2.0, efuse may not be set. */ >>>>>> + if (package_type == PACKAGE_TYPE_UNDEFINED || package_type == >>>>>> + PACKAGE_TYPE_RESERVED) >>>>>> + return MPUPLL_M_800; >>>>>> + >>>>>> switch ((efuse_arm_mpu_max_freq & DEVICE_ID_MASK)) { >>>>>> case AM335X_ZCZ_1000: >>>>>> return MPUPLL_M_1000; >>>>>> @@ -155,14 +163,14 @@ int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev) >>>>>> } >>>>>> } >>>>>> >>>>>> - /* PG 1.0 or otherwise unknown, use the PG1.0 max */ >>>>>> - return MPUPLL_M_720; >>>>>> + /* PG 1.0 or otherwise unknown, use the PG1.0 safe */ >>>>>> + return MPUPLL_M_500; >>>>> >>>>> Is the problem here new PG values getting unsafe values? I'm concerned >>>>> about slowing down PG1.0 stuff which is also in the wild, in numbers. >>>> >>>> No, I just wanted to return a value as it is a non-void function, may be >>>> I should update the comment properly. >>> >>> My concern is that PG1.0 stuff was previously being clocked at 720MHz, >>> but now will be down to 500MHz. I'm not sure if in these cases anything >>> else (ie Linux) touches this and would be kicking it back up. It'll >>> also slow down boot there a bit. Thanks! >> >> Till now for PG 1.0 we are clocking at 720MHz(OPP_NITRO for ZCZ package) >> and configuring voltages at 1.13V(OPP_100) which is wrong(Especially for >> ZCE package 500MHz is the maximum supported value.) I tried to make a >> common value for everything. >> >> Do you want me to run at 720MHz then increase the voltage accordingly >> and handle ZCE package separately? > > Well, part of the big open question here I have is, what does and > doesn't exist (and was shipped) for PG 1.0? My recollection at the time > was that we didn't care about ZCZ vs ZCE packages as it basically came > down to Beaglebone White (and some lead customers) that got ZCZ PG 1.0 > and everything else got PG2.x (with PG2.0 also being selective and PG2.1 > being the general release). I really don't want to start handicapping Okay. Then Ill use 720MHz for PG1.0 and repost the series. Thanks and regards, Lokesh