diff mbox

[U-Boot,v2,1/2] imx: mx6: add get_cpu_speed_grade_hz func to return MHz speed grade from OTP

Message ID 1431580121-24726-2-git-send-email-tharvey@gateworks.com
State Changes Requested
Delegated to: Stefano Babic
Headers show

Commit Message

Tim Harvey May 14, 2015, 5:08 a.m. UTC 
The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
Table. Return this frequency so that it can be used elsewhere.

Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
their Fusemap Description Table however Freescale has confirmed that these
eFUSE bits match the description within the IMX6DQRM and that they will
be added to the next revision of the respective reference manuals.

These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
 arch/arm/cpu/armv7/mx6/soc.c              | 41 +++++++++++++++++++++++++++++++
 arch/arm/include/asm/arch-mx6/sys_proto.h |  1 +
 2 files changed, 42 insertions(+)

Comments

Christian Gmeiner May 15, 2015, 7:53 a.m. UTC | #1 
Hi

2015-05-14 7:08 GMT+02:00 Tim Harvey <tharvey@gateworks.com>:
> The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
> indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
> Table. Return this frequency so that it can be used elsewhere.
>
> Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
> their Fusemap Description Table however Freescale has confirmed that these
> eFUSE bits match the description within the IMX6DQRM and that they will
> be added to the next revision of the respective reference manuals.
>
> These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.
>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
>  arch/arm/cpu/armv7/mx6/soc.c              | 41 +++++++++++++++++++++++++++++++
>  arch/arm/include/asm/arch-mx6/sys_proto.h |  1 +
>  2 files changed, 42 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index dd34138..71fa1fb 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -83,6 +83,47 @@ u32 get_cpu_rev(void)
>         return (type << 12) | (reg + 0x10);
>  }
>
> +/*
> + * OCOTP_CFG3[17:16] (see Fusemap Description Table offset 0x440)
> + * defines a 2-bit SPEED_GRADING
> + */
> +#define OCOTP_CFG3_SPEED_SHIFT 16
> +#define OCOTP_CFG3_SPEED_800MHZ        0
> +#define OCOTP_CFG3_SPEED_850MHZ        1
> +#define OCOTP_CFG3_SPEED_1GHZ  2
> +#define OCOTP_CFG3_SPEED_1P2GHZ        3

Note: 0x3 is defined as reserved (IMX6DQRM Rev 2, 06/2014).

> +
> +u32 get_cpu_speed_grade_hz(void)
> +{
> +       struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
> +       struct fuse_bank *bank = &ocotp->bank[0];
> +       struct fuse_bank0_regs *fuse =
> +               (struct fuse_bank0_regs *)bank->fuse_regs;
> +       uint32_t val;
> +
> +       val = readl(&fuse->cfg3);
> +       val >>= OCOTP_CFG3_SPEED_SHIFT;
> +       val &= 0x3;
> +
> +       switch (val) {
> +       /* Valid for IMX6DQ */
> +       case OCOTP_CFG3_SPEED_1P2GHZ:
> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> +                       return 1200000000;
> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
> +       case OCOTP_CFG3_SPEED_1GHZ:
> +               return 996000000;
> +       /* Valid for IMX6DQ */
> +       case OCOTP_CFG3_SPEED_850MHZ:
> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> +                       return 852000000;
> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
> +       case OCOTP_CFG3_SPEED_800MHZ:
> +               return 792000000;
> +       }
> +       return 0;

Do we really need the ifs inside the cases? The speed grading fuse
value is read only and
we must simply life with the value we read back. So I would drop the
is_cpu_type(..) thing.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
Stefano Babic May 15, 2015, 1:20 p.m. UTC | #2 
Hi Christian,

On 15/05/2015 09:53, Christian Gmeiner wrote:
> Hi
> 
> 2015-05-14 7:08 GMT+02:00 Tim Harvey <tharvey@gateworks.com>:
>> The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
>> indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
>> Table. Return this frequency so that it can be used elsewhere.
>>
>> Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
>> their Fusemap Description Table however Freescale has confirmed that these
>> eFUSE bits match the description within the IMX6DQRM and that they will
>> be added to the next revision of the respective reference manuals.
>>
>> These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.
>>
>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>> ---
>>  arch/arm/cpu/armv7/mx6/soc.c              | 41 +++++++++++++++++++++++++++++++
>>  arch/arm/include/asm/arch-mx6/sys_proto.h |  1 +
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>> index dd34138..71fa1fb 100644
>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>> @@ -83,6 +83,47 @@ u32 get_cpu_rev(void)
>>         return (type << 12) | (reg + 0x10);
>>  }
>>
>> +/*
>> + * OCOTP_CFG3[17:16] (see Fusemap Description Table offset 0x440)
>> + * defines a 2-bit SPEED_GRADING
>> + */
>> +#define OCOTP_CFG3_SPEED_SHIFT 16
>> +#define OCOTP_CFG3_SPEED_800MHZ        0
>> +#define OCOTP_CFG3_SPEED_850MHZ        1
>> +#define OCOTP_CFG3_SPEED_1GHZ  2
>> +#define OCOTP_CFG3_SPEED_1P2GHZ        3
> 
> Note: 0x3 is defined as reserved (IMX6DQRM Rev 2, 06/2014).
> 

That means that the manual is buggy, if the SOC returns exactly this
value ;-)

>> +
>> +u32 get_cpu_speed_grade_hz(void)
>> +{
>> +       struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
>> +       struct fuse_bank *bank = &ocotp->bank[0];
>> +       struct fuse_bank0_regs *fuse =
>> +               (struct fuse_bank0_regs *)bank->fuse_regs;
>> +       uint32_t val;
>> +
>> +       val = readl(&fuse->cfg3);
>> +       val >>= OCOTP_CFG3_SPEED_SHIFT;
>> +       val &= 0x3;
>> +
>> +       switch (val) {
>> +       /* Valid for IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_1P2GHZ:
>> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>> +                       return 1200000000;
>> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_1GHZ:
>> +               return 996000000;
>> +       /* Valid for IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_850MHZ:
>> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>> +                       return 852000000;
>> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_800MHZ:
>> +               return 792000000;
>> +       }
>> +       return 0;
> 
> Do we really need the ifs inside the cases? The speed grading fuse
> value is read only and
> we must simply life with the value we read back. So I would drop the
> is_cpu_type(..) thing.

Function does not returns the value of the fuse, else it should returns
val. The value is parsed for consistency, and if it is not, 0 means a
failure. IMHO this interpretation is correct - I would agree with you
only if the return value would be the read value, but it is not.

Best regards,
Stefano Babic

> 
> greets
> --
> Christian Gmeiner, MSc
> 
> https://soundcloud.com/christian-gmeiner
>
Tim Harvey May 15, 2015, 1:42 p.m. UTC | #3 
On Fri, May 15, 2015 at 12:53 AM, Christian Gmeiner
<christian.gmeiner@gmail.com> wrote:
> Hi
>
> 2015-05-14 7:08 GMT+02:00 Tim Harvey <tharvey@gateworks.com>:
>> The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
>> indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
>> Table. Return this frequency so that it can be used elsewhere.
>>
>> Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
>> their Fusemap Description Table however Freescale has confirmed that these
>> eFUSE bits match the description within the IMX6DQRM and that they will
>> be added to the next revision of the respective reference manuals.
>>
>> These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.
>>
>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>> ---
>>  arch/arm/cpu/armv7/mx6/soc.c              | 41 +++++++++++++++++++++++++++++++
>>  arch/arm/include/asm/arch-mx6/sys_proto.h |  1 +
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>> index dd34138..71fa1fb 100644
>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>> @@ -83,6 +83,47 @@ u32 get_cpu_rev(void)
>>         return (type << 12) | (reg + 0x10);
>>  }
>>
>> +/*
>> + * OCOTP_CFG3[17:16] (see Fusemap Description Table offset 0x440)
>> + * defines a 2-bit SPEED_GRADING
>> + */
>> +#define OCOTP_CFG3_SPEED_SHIFT 16
>> +#define OCOTP_CFG3_SPEED_800MHZ        0
>> +#define OCOTP_CFG3_SPEED_850MHZ        1
>> +#define OCOTP_CFG3_SPEED_1GHZ  2
>> +#define OCOTP_CFG3_SPEED_1P2GHZ        3
>
> Note: 0x3 is defined as reserved (IMX6DQRM Rev 2, 06/2014).

Right - this goes back to the fact that the RM's are full of omissions
in this area. I've gotten confirmation of sorts from Freescale that
the above is what is used. Still, I would love to see some testing and
I only have 800MHz/1GHz ranges, so if anyone out there with a IMX6DUAL
or IMX6QUAD at 1.2GHz could verify this works please do.

>
>> +
>> +u32 get_cpu_speed_grade_hz(void)
>> +{
>> +       struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
>> +       struct fuse_bank *bank = &ocotp->bank[0];
>> +       struct fuse_bank0_regs *fuse =
>> +               (struct fuse_bank0_regs *)bank->fuse_regs;
>> +       uint32_t val;
>> +
>> +       val = readl(&fuse->cfg3);
>> +       val >>= OCOTP_CFG3_SPEED_SHIFT;
>> +       val &= 0x3;
>> +
>> +       switch (val) {
>> +       /* Valid for IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_1P2GHZ:
>> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>> +                       return 1200000000;
>> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_1GHZ:
>> +               return 996000000;
>> +       /* Valid for IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_850MHZ:
>> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>> +                       return 852000000;
>> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
>> +       case OCOTP_CFG3_SPEED_800MHZ:
>> +               return 792000000;
>> +       }
>> +       return 0;
>
> Do we really need the ifs inside the cases? The speed grading fuse
> value is read only and
> we must simply life with the value we read back. So I would drop the
> is_cpu_type(..) thing.

I've had a bit of a difficult time getting verification from Freescale
that all IMX6 CPU's use the exact same OTP register and setting for
this which is why I'm asking for testing. I haven't gotten a simple
'yes' to that question but instead of been giving small snippets of
information. Not a single one of the RM's agree's with the other in
this area (most marked as reserved or omit the register or omit the
values altogether)

My personal feeling is that the speed grades (and temp grades for that
matter) are the same for all IMX6 and even though the datasheets for
the IMX6SDL/IMX6SX state they don't 'sell' a 850MHz or 1.2GHz speed
grade we should honor the setting (meaning I agree with you that we
should remove the if's).

Tim
Christian Gmeiner May 15, 2015, 2:26 p.m. UTC | #4 
2015-05-15 15:20 GMT+02:00 Stefano Babic <sbabic@denx.de>:
> Hi Christian,
>
> On 15/05/2015 09:53, Christian Gmeiner wrote:
>> Hi
>>
>> 2015-05-14 7:08 GMT+02:00 Tim Harvey <tharvey@gateworks.com>:
>>> The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
>>> indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
>>> Table. Return this frequency so that it can be used elsewhere.
>>>
>>> Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
>>> their Fusemap Description Table however Freescale has confirmed that these
>>> eFUSE bits match the description within the IMX6DQRM and that they will
>>> be added to the next revision of the respective reference manuals.
>>>
>>> These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.
>>>
>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>>> ---
>>>  arch/arm/cpu/armv7/mx6/soc.c              | 41 +++++++++++++++++++++++++++++++
>>>  arch/arm/include/asm/arch-mx6/sys_proto.h |  1 +
>>>  2 files changed, 42 insertions(+)
>>>
>>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>>> index dd34138..71fa1fb 100644
>>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>>> @@ -83,6 +83,47 @@ u32 get_cpu_rev(void)
>>>         return (type << 12) | (reg + 0x10);
>>>  }
>>>
>>> +/*
>>> + * OCOTP_CFG3[17:16] (see Fusemap Description Table offset 0x440)
>>> + * defines a 2-bit SPEED_GRADING
>>> + */
>>> +#define OCOTP_CFG3_SPEED_SHIFT 16
>>> +#define OCOTP_CFG3_SPEED_800MHZ        0
>>> +#define OCOTP_CFG3_SPEED_850MHZ        1
>>> +#define OCOTP_CFG3_SPEED_1GHZ  2
>>> +#define OCOTP_CFG3_SPEED_1P2GHZ        3
>>
>> Note: 0x3 is defined as reserved (IMX6DQRM Rev 2, 06/2014).
>>
>
> That means that the manual is buggy, if the SOC returns exactly this
> value ;-)

yep :)

>
>>> +
>>> +u32 get_cpu_speed_grade_hz(void)
>>> +{
>>> +       struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
>>> +       struct fuse_bank *bank = &ocotp->bank[0];
>>> +       struct fuse_bank0_regs *fuse =
>>> +               (struct fuse_bank0_regs *)bank->fuse_regs;
>>> +       uint32_t val;
>>> +
>>> +       val = readl(&fuse->cfg3);
>>> +       val >>= OCOTP_CFG3_SPEED_SHIFT;
>>> +       val &= 0x3;
>>> +
>>> +       switch (val) {
>>> +       /* Valid for IMX6DQ */
>>> +       case OCOTP_CFG3_SPEED_1P2GHZ:
>>> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>>> +                       return 1200000000;
>>> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
>>> +       case OCOTP_CFG3_SPEED_1GHZ:
>>> +               return 996000000;
>>> +       /* Valid for IMX6DQ */
>>> +       case OCOTP_CFG3_SPEED_850MHZ:
>>> +               if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
>>> +                       return 852000000;
>>> +       /* Valid for IMX6SX/IMX6SDL/IMX6DQ */
>>> +       case OCOTP_CFG3_SPEED_800MHZ:
>>> +               return 792000000;
>>> +       }
>>> +       return 0;
>>
>> Do we really need the ifs inside the cases? The speed grading fuse
>> value is read only and
>> we must simply life with the value we read back. So I would drop the
>> is_cpu_type(..) thing.
>
> Function does not returns the value of the fuse, else it should returns
> val. The value is parsed for consistency, and if it is not, 0 means a
> failure. IMHO this interpretation is correct - I would agree with you
> only if the return value would be the read value, but it is not.
>

If all mx6 variants use the same otp register/values, then the
ifs are _NOT_ needed. I hope that later testings/doc updates/etc
proofs it and we can get rid of the superfluous ifs.

If they are different then I can life with it.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
Stefano Babic May 15, 2015, 2:32 p.m. UTC | #5 
Hi Christian,

On 15/05/2015 16:26, Christian Gmeiner wrote:

>> Function does not returns the value of the fuse, else it should returns
>> val. The value is parsed for consistency, and if it is not, 0 means a
>> failure. IMHO this interpretation is correct - I would agree with you
>> only if the return value would be the read value, but it is not.
>>
> 
> If all mx6 variants use the same otp register/values, then the
> ifs are _NOT_ needed. I hope that later testings/doc updates/etc
> proofs it and we can get rid of the superfluous ifs.
> 

Ok - let's see if this can be proofed. It looks like we have to test and
ask the hardware for that instead of relying on the documentation.

Best regards,
Stefano Babic
Troy Kisky May 15, 2015, 7:54 p.m. UTC | #6 
On 5/15/2015 7:32 AM, Stefano Babic wrote:
> Hi Christian,
> 
> On 15/05/2015 16:26, Christian Gmeiner wrote:
> 
>>> Function does not returns the value of the fuse, else it should returns
>>> val. The value is parsed for consistency, and if it is not, 0 means a
>>> failure. IMHO this interpretation is correct - I would agree with you
>>> only if the return value would be the read value, but it is not.
>>>
>>
>> If all mx6 variants use the same otp register/values, then the
>> ifs are _NOT_ needed. I hope that later testings/doc updates/etc
>> proofs it and we can get rid of the superfluous ifs.
>>
> 
> Ok - let's see if this can be proofed. It looks like we have to test and
> ask the hardware for that instead of relying on the documentation.
> 
> Best regards,
> Stefano Babic
> 

On our imx6sx board the patch outputs

U-Boot 2015.04-00074-g1bd6819 (May 15 2015 - 12:44:22)

CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
Reset cause: WDOG
Board: Nitrogen6sx
Tim Harvey May 15, 2015, 8:38 p.m. UTC | #7 
On Fri, May 15, 2015 at 12:54 PM, Troy Kisky
<troy.kisky@boundarydevices.com> wrote:
> On 5/15/2015 7:32 AM, Stefano Babic wrote:
>> Hi Christian,
>>
>> On 15/05/2015 16:26, Christian Gmeiner wrote:
>>
>>>> Function does not returns the value of the fuse, else it should returns
>>>> val. The value is parsed for consistency, and if it is not, 0 means a
>>>> failure. IMHO this interpretation is correct - I would agree with you
>>>> only if the return value would be the read value, but it is not.
>>>>
>>>
>>> If all mx6 variants use the same otp register/values, then the
>>> ifs are _NOT_ needed. I hope that later testings/doc updates/etc
>>> proofs it and we can get rid of the superfluous ifs.
>>>
>>
>> Ok - let's see if this can be proofed. It looks like we have to test and
>> ask the hardware for that instead of relying on the documentation.
>>
>> Best regards,
>> Stefano Babic
>>
>
> On our imx6sx board the patch outputs
>
> U-Boot 2015.04-00074-g1bd6819 (May 15 2015 - 12:44:22)
>
> CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
> Reset cause: WDOG
> Board: Nitrogen6sx
> ______________
>
>
> Did you want me to test some variation of this?
>
> Thanks
> Troy

Troy,

As far as the frequency grade goes if you know the actual part number
is a 1GHz part then that looks good - thanks for the test!

Could you provide similar results for the thermal grade patch series
as well? (you will need to enable imx6 thermal sensor and remove the
if (!imx6sx) around the print).

Thanks!

Tim
Troy Kisky May 15, 2015, 8:43 p.m. UTC | #8 
On 5/15/2015 1:38 PM, Tim Harvey wrote:
> On Fri, May 15, 2015 at 12:54 PM, Troy Kisky
> <troy.kisky@boundarydevices.com> wrote:
>> On 5/15/2015 7:32 AM, Stefano Babic wrote:
>>> Hi Christian,
>>>
>>> On 15/05/2015 16:26, Christian Gmeiner wrote:
>>>
>>>>> Function does not returns the value of the fuse, else it should returns
>>>>> val. The value is parsed for consistency, and if it is not, 0 means a
>>>>> failure. IMHO this interpretation is correct - I would agree with you
>>>>> only if the return value would be the read value, but it is not.
>>>>>
>>>>
>>>> If all mx6 variants use the same otp register/values, then the
>>>> ifs are _NOT_ needed. I hope that later testings/doc updates/etc
>>>> proofs it and we can get rid of the superfluous ifs.
>>>>
>>>
>>> Ok - let's see if this can be proofed. It looks like we have to test and
>>> ask the hardware for that instead of relying on the documentation.
>>>
>>> Best regards,
>>> Stefano Babic
>>>
>>
>> On our imx6sx board the patch outputs
>>
>> U-Boot 2015.04-00074-g1bd6819 (May 15 2015 - 12:44:22)
>>
>> CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
>> Reset cause: WDOG
>> Board: Nitrogen6sx
>> ______________
>>
>>
>> Did you want me to test some variation of this?
>>
>> Thanks
>> Troy
> 
> Troy,
> 
> As far as the frequency grade goes if you know the actual part number
> is a 1GHz part then that looks good - thanks for the test!

Right, it is a 1GHz part.

> 
> Could you provide similar results for the thermal grade patch series
> as well? (you will need to enable imx6 thermal sensor and remove the
> if (!imx6sx) around the print).

Will do.

> 
> Thanks!
> 
> Tim
>
Troy Kisky May 15, 2015, 10:34 p.m. UTC | #9 
On 5/15/2015 1:43 PM, Troy Kisky wrote:
> On 5/15/2015 1:38 PM, Tim Harvey wrote:
>> On Fri, May 15, 2015 at 12:54 PM, Troy Kisky
>> <troy.kisky@boundarydevices.com> wrote:
>>> On 5/15/2015 7:32 AM, Stefano Babic wrote:
>>>> Hi Christian,
>>>>
>>>> On 15/05/2015 16:26, Christian Gmeiner wrote:
>>>>
>>>>>> Function does not returns the value of the fuse, else it should returns
>>>>>> val. The value is parsed for consistency, and if it is not, 0 means a
>>>>>> failure. IMHO this interpretation is correct - I would agree with you
>>>>>> only if the return value would be the read value, but it is not.
>>>>>>
>>>>>
>>>>> If all mx6 variants use the same otp register/values, then the
>>>>> ifs are _NOT_ needed. I hope that later testings/doc updates/etc
>>>>> proofs it and we can get rid of the superfluous ifs.
>>>>>
>>>>
>>>> Ok - let's see if this can be proofed. It looks like we have to test and
>>>> ask the hardware for that instead of relying on the documentation.
>>>>
>>>> Best regards,
>>>> Stefano Babic
>>>>
>>>
>>> On our imx6sx board the patch outputs
>>>
>>> U-Boot 2015.04-00074-g1bd6819 (May 15 2015 - 12:44:22)
>>>
>>> CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
>>> Reset cause: WDOG
>>> Board: Nitrogen6sx
>>> ______________
>>>
>>>
>>> Did you want me to test some variation of this?
>>>
>>> Thanks
>>> Troy
>>
>> Troy,
>>
>> As far as the frequency grade goes if you know the actual part number
>> is a 1GHz part then that looks good - thanks for the test!
> 
> Right, it is a 1GHz part.
> 
>>
>> Could you provide similar results for the thermal grade patch series
>> as well? (you will need to enable imx6 thermal sensor and remove the
>> if (!imx6sx) around the print).
> 
> Will do.
> 
>>
>> Thanks!
>>
>> Tim
>>


Ok. I think I gave bad info

The part number is PCIMX6X4AVM08AA, which should be -40 to 125 C, 800 MHz

and u-boot prints

U-Boot 2015.07-rc1-01048-gc4f95cb-dirty (May 15 2015 - 14:46:05)

CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C)
Otavio Salvador May 15, 2015, 10:57 p.m. UTC | #10 
On Fri, May 15, 2015 at 7:34 PM, Troy Kisky
<troy.kisky@boundarydevices.com> wrote:
...
>>>> CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
...

TO1.0 is the first one and had some issues. We need testing with
current production TO not alpha customers one.
Troy Kisky May 15, 2015, 11:24 p.m. UTC | #11 
On 5/15/2015 3:57 PM, Otavio Salvador wrote:
> On Fri, May 15, 2015 at 7:34 PM, Troy Kisky
> <troy.kisky@boundarydevices.com> wrote:
> ...
>>>>> CPU:   Freescale i.MX6SX rev1.0 996 MHz (running at 792 MHz)
> ...
> 
> TO1.0 is the first one and had some issues. We need testing with
> current production TO not alpha customers one.
> 

Thanks for pointing that out, Otavio.

Troy
Nikolay Dimitrov May 17, 2015, 9:37 p.m. UTC | #12 
Hi Tim,

On 05/14/2015 08:08 AM, Tim Harvey wrote:
> The IMX6 has four different speed grades determined by eFUSE SPEED_GRADING
> indicated by OCOTP_CFG3[17:16] which is at 0x440 in the Fusemap Description
> Table. Return this frequency so that it can be used elsewhere.
>
> Note that the IMX6SDLRM and the IMX6SXRM do not indicate this in the
> their Fusemap Description Table however Freescale has confirmed that these
> eFUSE bits match the description within the IMX6DQRM and that they will
> be added to the next revision of the respective reference manuals.
>
> These have been tested with IMX6 Quad/Solo/Dual-light 800Mhz and 1GHz grades.
>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
>   arch/arm/cpu/armv7/mx6/soc.c              | 41 +++++++++++++++++++++++++++++++
>   arch/arm/include/asm/arch-mx6/sys_proto.h |  1 +
>   2 files changed, 42 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index dd34138..71fa1fb 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -83,6 +83,47 @@ u32 get_cpu_rev(void)
>   	return (type << 12) | (reg + 0x10);
>   }
>
> +/*
> + * OCOTP_CFG3[17:16] (see Fusemap Description Table offset 0x440)
> + * defines a 2-bit SPEED_GRADING
> + */
> +#define OCOTP_CFG3_SPEED_SHIFT	16
> +#define OCOTP_CFG3_SPEED_800MHZ	0
> +#define OCOTP_CFG3_SPEED_850MHZ	1
> +#define OCOTP_CFG3_SPEED_1GHZ	2
> +#define OCOTP_CFG3_SPEED_1P2GHZ	3
> +
> +u32 get_cpu_speed_grade_hz(void)
> +{
> +	struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
> +	struct fuse_bank *bank = &ocotp->bank[0];
> +	struct fuse_bank0_regs *fuse =
> +		(struct fuse_bank0_regs *)bank->fuse_regs;
> +	uint32_t val;
> +
> +	val = readl(&fuse->cfg3);
> +	val >>= OCOTP_CFG3_SPEED_SHIFT;
> +	val &= 0x3;
> +
> +	switch (val) {
> +	/* Valid for IMX6DQ */
> +	case OCOTP_CFG3_SPEED_1P2GHZ:
> +		if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> +			return 1200000000;
> +	/* Valid for IMX6SX/IMX6SDL/IMX6DQ */
> +	case OCOTP_CFG3_SPEED_1GHZ:
> +		return 996000000;
> +	/* Valid for IMX6DQ */
> +	case OCOTP_CFG3_SPEED_850MHZ:
> +		if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> +			return 852000000;
> +	/* Valid for IMX6SX/IMX6SDL/IMX6DQ */
> +	case OCOTP_CFG3_SPEED_800MHZ:
> +		return 792000000;
> +	}
> +	return 0;
> +}
> +
>   #ifdef CONFIG_REVISION_TAG
>   u32 __weak get_board_rev(void)
>   {
> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h b/arch/arm/include/asm/arch-mx6/sys_proto.h
> index 28ba844..a2cd0a9 100644
> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h
> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
> @@ -16,6 +16,7 @@
>
>   u32 get_nr_cpus(void);
>   u32 get_cpu_rev(void);
> +u32 get_cpu_speed_grade_hz(void);
>
>   /* returns MXC_CPU_ value */
>   #define cpu_type(rev) (((rev) >> 12)&0xff)
>


U-Boot 2015.07-rc1-21804-gaf1db4a-dirty (May 18 2015 - 00:31:26)

CPU:   Freescale i.MX6SOLO rev1.1 996 MHz (running at 792 MHz)
Reset cause: WDOG
Board: RIoTboard


Tested-by: Nikolay Dimitrov <picmaster@mail.bg>

Regards,
Nikolay
diff mbox

Patch

diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index dd34138..71fa1fb 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -83,6 +83,47 @@  u32 get_cpu_rev(void)
 	return (type << 12) | (reg + 0x10);
 }
 
+/*
+ * OCOTP_CFG3[17:16] (see Fusemap Description Table offset 0x440)
+ * defines a 2-bit SPEED_GRADING
+ */
+#define OCOTP_CFG3_SPEED_SHIFT	16
+#define OCOTP_CFG3_SPEED_800MHZ	0
+#define OCOTP_CFG3_SPEED_850MHZ	1
+#define OCOTP_CFG3_SPEED_1GHZ	2
+#define OCOTP_CFG3_SPEED_1P2GHZ	3
+
+u32 get_cpu_speed_grade_hz(void)
+{
+	struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+	struct fuse_bank *bank = &ocotp->bank[0];
+	struct fuse_bank0_regs *fuse =
+		(struct fuse_bank0_regs *)bank->fuse_regs;
+	uint32_t val;
+
+	val = readl(&fuse->cfg3);
+	val >>= OCOTP_CFG3_SPEED_SHIFT;
+	val &= 0x3;
+
+	switch (val) {
+	/* Valid for IMX6DQ */
+	case OCOTP_CFG3_SPEED_1P2GHZ:
+		if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
+			return 1200000000;
+	/* Valid for IMX6SX/IMX6SDL/IMX6DQ */
+	case OCOTP_CFG3_SPEED_1GHZ:
+		return 996000000;
+	/* Valid for IMX6DQ */
+	case OCOTP_CFG3_SPEED_850MHZ:
+		if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
+			return 852000000;
+	/* Valid for IMX6SX/IMX6SDL/IMX6DQ */
+	case OCOTP_CFG3_SPEED_800MHZ:
+		return 792000000;
+	}
+	return 0;
+}
+
 #ifdef CONFIG_REVISION_TAG
 u32 __weak get_board_rev(void)
 {
diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 28ba844..a2cd0a9 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -16,6 +16,7 @@ 
 
 u32 get_nr_cpus(void);
 u32 get_cpu_rev(void);
+u32 get_cpu_speed_grade_hz(void);
 
 /* returns MXC_CPU_ value */
 #define cpu_type(rev) (((rev) >> 12)&0xff)