[U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table

[Nishanth Menon]

Steve Sakoman wrote, on 11/05/2010 11:05 PM:
> On Fri, Nov 5, 2010 at 10:54 AM, Nishanth Menon
> <menon.nishanth at gmail.com>  wrote:
>> Jason Kridner wrote, on 11/05/2010 01:46 AM:
>>> From: Koen Kooi<koen at dominion.thruhere.net>
>>>
>>> Patch was updated by Jason Kridner<jkridner at beagleboard.org>:
>>> * Use tabs to match style of other board revisions
>>> * Only include board revisions that exist
>>> * Default to the same configuration as the latest revision, but
>>>     without setting 'beaglerev'
>>>
>>> Signed-off-by: Jason Kridner<jkridner at beagleboard.org>
>> not signed-off-by: Koen?
>>
>>> ---
>>>    board/ti/beagle/beagle.c |   20 +++++++++++++++++++-
>>>    board/ti/beagle/beagle.h |    3 ++-
>>>    2 files changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
>>> index 520e57d..93c452e 100644
>>> --- a/board/ti/beagle/beagle.c
>>> +++ b/board/ti/beagle/beagle.c
>>> @@ -176,7 +176,7 @@ int misc_init_r(void)
>>>                                        TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>>>                                        TWL4030_PM_RECEIVER_DEV_GRP_P1);
>>>                break;
>>> -     case REVISION_XM:
>>> +     case REVISION_XM_A:
>>>                printf("Beagle xM Rev A\n");
>>>                setenv("beaglerev", "xMA");
>>>                setenv("mpurate", "1000");
>>> @@ -187,8 +187,26 @@ int misc_init_r(void)
>>>                                        TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>>>                                        TWL4030_PM_RECEIVER_DEV_GRP_P1);
>>>                break;
>>> +     case REVISION_XM_B:
>>> +             printf("Beagle xM Rev B\n");
>>> +             setenv("beaglerev", "xMB");
>>> +             setenv("mpurate", "1000");
>>> +             MUX_BEAGLE_XM();
>>> +             /* Set VAUX2 to 1.8V for EHCI PHY */
>>> +             twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
>>> +                                     TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
>>> +                                     TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>>> +                                     TWL4030_PM_RECEIVER_DEV_GRP_P1);
>>> +             break;
>>>        default:
>>>                printf("Beagle unknown 0x%02x\n", get_board_revision());
>>> +             setenv("mpurate", "1000");
>>
>> It looks to me looking at the file that mpurate usage is CPU based and
>> NOT board based.. maybe you should use the cpu idendity to decide on
>> mpurate instead?
>
> I noticed this too.  I just submitted a patch for Overo that sets the
> mpurate to the cpu maximum (based on cpu type and version) if the
> mpurate environment variable is set to "auto"
just for the record, saw this and I liked it :) thanks.

>
> This solves an additional issue: with things as they are now, it is
> not possible for a user to set the mpurate to a specific value -- it
> will always be overwritten.  The scheme above allows the user to set a
> specific value or to allow u-boot to set the maximum automatically.
>
> Note that for 36xx my patch sets the max to 720 -- this is because
> mainline/linux-omap currently does not support 1000.  We can adjust
> that when kernel support for 1000 appears.

Errr.. that is not completely true[1](ignoring the lack of upstream DVFS 
for OMAP3+) - Here is the explanation for it:

36xx family of silicon comes in 4 variants - the ones that support upto 
600MHz, ones that do 800MHz, ones that do 1GHz and the ones that do 
1.2GHz. the defaults posted upstream enables the least common 
denominator - 300,600MHz and it leaves it to board files to mention if 
they have silicon of additional capability- unfortunately, there is no 
bits that tell the s/w that(for those wondering - yeah s/w folks did try 
to convince h/w folks for those additional bits.. but after a long 
debate never succeeded) :(

Anyway, to put a long story short - if your board file supports 1GHz, 
with upstream OPP layer, you do have the flexibility to enable 1GHz OPP 
- just look at opp_enable[2] usage documentation [3]. I used thermal 
management as an example here, but no reason why we cant use it as 
well.. this way, you can infact support cpufreq if you would like to as 
well.


Ref:
[1] https://patchwork.kernel.org/patch/266911/ (search for 
omap36xx_opp_def_list)
[2] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/opp.h;h=5449945d589f994ed5ac25f018ced4a5dc81db30;hb=HEAD#l39
[3] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/power/opp.txt;h=44d87ad3cea9fd345a774e196578a0cc8bf4d779;hb=HEAD#l193

-- 
Regards,
Nishanth Menon