| Message ID | 20170805024209.3703-3-nm@ti.com |
|---|---|
| State | Accepted |
| Commit | 0459bc30b601434abc27b75e7319ac790e6d5c80 |
| Headers | show |
| Series | ARM: OMAP5: Add AVS support for ES2.0 | expand |
On 8/5/2017 8:12 AM, Nishanth Menon wrote: > OMAP5432 did go into production with AVS class0 registers which were > mutually exclusive from AVS Class 1.5 registers. > > Most OMAP5-uEVM boards use the pre-production Class1.5 which has > production efuse registers set to 0. However on production devices, > these are set to valid data. > > scale_vcore logic is already smart enough to detect this and use the > "Nominal voltage" on devices that do not have efuse registers populated. > > On a test production device populated as follows: > MPU OPP_NOM: > => md.l 0x04A0021C4 1 > 4a0021c4: 03a003e9 .... > (0x3e9 = 1.01v) vs nom voltage of 1.06v > MPU OPP_HIGH: > => md.l 0x04A0021C8 1 > 4a0021c8: 03400485 ..@. > > MM OPP_NOM: > => md.l 0x04A0021A4 1 > 4a0021a4: 038003d4 .... > (0x3d4 = 980mV) vs nom voltage of 1.025v > MM OPP_OD: > => md.l 0x04A0021A8 1 > 4a0021a8: 03600403 ..`. > > CORE OPP_NOM: > => md.l 0x04A0021D8 1 > 4a0021d8: 000003cf .... > (0x3cf = 975mV) vs nom voltage of 1.040v > > Since the efuse values are'nt currently used, we do not regress on > existing pre-production samples (they continue to use nominal voltage). > > But on boards that do have production samples populated, we can leverage > the optimal voltages necessary for proper operation. > > Tested on: > a) 720-2644-001 OMAP5UEVM with production sample. > b) 750-2628-222(A) UEVM5432G-02 with pre-production sample. > > Data based on OMAP5432 Technical reference Manual SWPU282AF (May > 2012-Revised Aug 2016) > > NOTE: All collaterals on OMAP5432 silicon itself seems to have been > removed from ti.com, though EVM details are still available: > http://www.ti.com/tool/OMAP5432-EVM > Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Thanks and regards, Lokesh > Signed-off-by: Nishanth Menon <nm@ti.com>
On Fri, Aug 04, 2017 at 09:42:09PM -0500, Nishanth Menon wrote: > OMAP5432 did go into production with AVS class0 registers which were > mutually exclusive from AVS Class 1.5 registers. > > Most OMAP5-uEVM boards use the pre-production Class1.5 which has > production efuse registers set to 0. However on production devices, > these are set to valid data. > > scale_vcore logic is already smart enough to detect this and use the > "Nominal voltage" on devices that do not have efuse registers populated. > > On a test production device populated as follows: > MPU OPP_NOM: > => md.l 0x04A0021C4 1 > 4a0021c4: 03a003e9 .... > (0x3e9 = 1.01v) vs nom voltage of 1.06v > MPU OPP_HIGH: > => md.l 0x04A0021C8 1 > 4a0021c8: 03400485 ..@. > > MM OPP_NOM: > => md.l 0x04A0021A4 1 > 4a0021a4: 038003d4 .... > (0x3d4 = 980mV) vs nom voltage of 1.025v > MM OPP_OD: > => md.l 0x04A0021A8 1 > 4a0021a8: 03600403 ..`. > > CORE OPP_NOM: > => md.l 0x04A0021D8 1 > 4a0021d8: 000003cf .... > (0x3cf = 975mV) vs nom voltage of 1.040v > > Since the efuse values are'nt currently used, we do not regress on > existing pre-production samples (they continue to use nominal voltage). > > But on boards that do have production samples populated, we can leverage > the optimal voltages necessary for proper operation. > > Tested on: > a) 720-2644-001 OMAP5UEVM with production sample. > b) 750-2628-222(A) UEVM5432G-02 with pre-production sample. > > Data based on OMAP5432 Technical reference Manual SWPU282AF (May > 2012-Revised Aug 2016) > > NOTE: All collaterals on OMAP5432 silicon itself seems to have been > removed from ti.com, though EVM details are still available: > http://www.ti.com/tool/OMAP5432-EVM > > Signed-off-by: Nishanth Menon <nm@ti.com> > Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Applied to u-boot/master, thanks! -- Tom
diff --git a/arch/arm/include/asm/arch-omap5/clock.h b/arch/arm/include/asm/arch-omap5/clock.h index dd05e8ba8317..dbe340d23e4f 100644 --- a/arch/arm/include/asm/arch-omap5/clock.h +++ b/arch/arm/include/asm/arch-omap5/clock.h @@ -236,6 +236,22 @@ #define VDD_MPU_ES2_HIGH 1250 #define VDD_MM_ES2_OD 1120 +/* Efuse register offsets for OMAP5 platform */ +#define OMAP5_ES2_EFUSE_BASE 0x4A002000 +#define OMAP5_ES2_PROD_REGBITS 16 + +/* CONTROL_STD_FUSE_OPP_VDD_CORE_3 */ +#define OMAP5_ES2_PROD_CORE_OPNO_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1D8) + +/* CONTROL_STD_FUSE_OPP_VDD_MM_4 */ +#define OMAP5_ES2_PROD_MM_OPNO_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1A4) +/* CONTROL_STD_FUSE_OPP_VDD_MM_5 */ +#define OMAP5_ES2_PROD_MM_OPOD_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1A8) +/* CONTROL_STD_FUSE_OPP_VDD_MPU_6 */ +#define OMAP5_ES2_PROD_MPU_OPNO_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1C4) +/* CONTROL_STD_FUSE_OPP_VDD_MPU_7 */ +#define OMAP5_ES2_PROD_MPU_OPHI_VMIN (OMAP5_ES2_EFUSE_BASE + 0x1C8) + /* DRA74x/75x/72x voltage settings in mv for OPP_NOM per DM */ #define VDD_MPU_DRA7_NOM 1150 #define VDD_CORE_DRA7_NOM 1150 diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index 2f005dd3ad92..b047f0d65081 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -224,8 +224,8 @@ struct s32ktimer { #define OMAP_ABB_GPU_TXDONE_MASK (0x1 << 28) /* ABB efuse masks */ -#define OMAP5_ABB_FUSE_VSET_MASK (0x1F << 24) -#define OMAP5_ABB_FUSE_ENABLE_MASK (0x1 << 29) +#define OMAP5_PROD_ABB_FUSE_VSET_MASK (0x1F << 20) +#define OMAP5_PROD_ABB_FUSE_ENABLE_MASK (0x1 << 25) #define DRA7_ABB_FUSE_VSET_MASK (0x1F << 20) #define DRA7_ABB_FUSE_ENABLE_MASK (0x1 << 25) #define OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK (0x1 << 10) diff --git a/arch/arm/mach-omap2/omap5/abb.c b/arch/arm/mach-omap2/omap5/abb.c index 3bf88979e5d6..1882c49e7df6 100644 --- a/arch/arm/mach-omap2/omap5/abb.c +++ b/arch/arm/mach-omap2/omap5/abb.c @@ -28,8 +28,8 @@ s8 abb_setup_ldovbb(u32 fuse, u32 ldovbb) { u32 vset; - u32 fuse_enable_mask = OMAP5_ABB_FUSE_ENABLE_MASK; - u32 fuse_vset_mask = OMAP5_ABB_FUSE_VSET_MASK; + u32 fuse_enable_mask = OMAP5_PROD_ABB_FUSE_ENABLE_MASK; + u32 fuse_vset_mask = OMAP5_PROD_ABB_FUSE_VSET_MASK; if (!is_omap54xx()) { /* DRA7 */ diff --git a/arch/arm/mach-omap2/omap5/hw_data.c b/arch/arm/mach-omap2/omap5/hw_data.c index a8a6b8a869e5..4ad6b530d29c 100644 --- a/arch/arm/mach-omap2/omap5/hw_data.c +++ b/arch/arm/mach-omap2/omap5/hw_data.c @@ -329,6 +329,15 @@ struct vcores_data omap5430_volts_es2 = { .mm.addr = SMPS_REG_ADDR_45_IVA, .mm.pmic = &palmas, .mm.abb_tx_done_mask = OMAP_ABB_MM_TXDONE_MASK, + + .mpu.efuse.reg[OPP_NOM] = OMAP5_ES2_PROD_MPU_OPNO_VMIN, + .mpu.efuse.reg_bits = OMAP5_ES2_PROD_REGBITS, + + .core.efuse.reg[OPP_NOM] = OMAP5_ES2_PROD_CORE_OPNO_VMIN, + .core.efuse.reg_bits = OMAP5_ES2_PROD_REGBITS, + + .mm.efuse.reg[OPP_NOM] = OMAP5_ES2_PROD_MM_OPNO_VMIN, + .mm.efuse.reg_bits = OMAP5_ES2_PROD_REGBITS, }; /*
OMAP5432 did go into production with AVS class0 registers which were mutually exclusive from AVS Class 1.5 registers. Most OMAP5-uEVM boards use the pre-production Class1.5 which has production efuse registers set to 0. However on production devices, these are set to valid data. scale_vcore logic is already smart enough to detect this and use the "Nominal voltage" on devices that do not have efuse registers populated. On a test production device populated as follows: MPU OPP_NOM: => md.l 0x04A0021C4 1 4a0021c4: 03a003e9 .... (0x3e9 = 1.01v) vs nom voltage of 1.06v MPU OPP_HIGH: => md.l 0x04A0021C8 1 4a0021c8: 03400485 ..@. MM OPP_NOM: => md.l 0x04A0021A4 1 4a0021a4: 038003d4 .... (0x3d4 = 980mV) vs nom voltage of 1.025v MM OPP_OD: => md.l 0x04A0021A8 1 4a0021a8: 03600403 ..`. CORE OPP_NOM: => md.l 0x04A0021D8 1 4a0021d8: 000003cf .... (0x3cf = 975mV) vs nom voltage of 1.040v Since the efuse values are'nt currently used, we do not regress on existing pre-production samples (they continue to use nominal voltage). But on boards that do have production samples populated, we can leverage the optimal voltages necessary for proper operation. Tested on: a) 720-2644-001 OMAP5UEVM with production sample. b) 750-2628-222(A) UEVM5432G-02 with pre-production sample. Data based on OMAP5432 Technical reference Manual SWPU282AF (May 2012-Revised Aug 2016) NOTE: All collaterals on OMAP5432 silicon itself seems to have been removed from ti.com, though EVM details are still available: http://www.ti.com/tool/OMAP5432-EVM Signed-off-by: Nishanth Menon <nm@ti.com> --- arch/arm/include/asm/arch-omap5/clock.h | 16 ++++++++++++++++ arch/arm/include/asm/arch-omap5/omap.h | 4 ++-- arch/arm/mach-omap2/omap5/abb.c | 4 ++-- arch/arm/mach-omap2/omap5/hw_data.c | 9 +++++++++ 4 files changed, 29 insertions(+), 4 deletions(-)