On Fri, Jan 9, 2015 at 5:47 PM, Hans de Goede <[email protected]> wrote:
> Hi,
>
>
> On 09-01-15 10:37, Maxime Ripard wrote:
>>
>> On Fri, Jan 09, 2015 at 10:11:10AM +0100, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 09-01-15 09:51, Maxime Ripard wrote:
>>>>
>>>> On Fri, Jan 09, 2015 at 09:36:28AM +0100, Hans de Goede wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 09-01-15 09:30, Maxime Ripard wrote:
>>>>>>
>>>>>> On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote:
>>>>>
>>>>>
>>>>> <snip>
>>>>>
>>>>>>> For sun6i it is somewhat harder.
>>>>>>
>>>>>>
>>>>>> Yep, that version D thing is going to cause us a bit of trouble, but
>>>>>> since we don't have any hardware available, I'd say we should ignore
>>>>>> it for now.
>>>>>
>>>>>
>>>>> Version D ? I more or less completely missed that, care to explain ?
>>>>>
>>>>> I guess this is going to impact u-boot too ?
>>>>
>>>>
>>>> I don't think it will, or at least, not for this issue.
>>>>
>>>>  From what we saw in the Allwinner BSPs, the A31 rev D might need
>>>> different operating points for cpufreq.
>>>
>>>
>>> Ah, what about the max-speed operating point ? That is being set by
>>> u-boot early on, specifically for sun6i / sun8i it sets VDD-CPU to 1.2V
>>> and the CPU-clock to 1008MHz.
>>
>>
>> Based on the two samples here:
>>
>> https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/hummingbird_a31.fex#L919
>> and here:
>>
>> https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a31/mele_i7.fex#L1436
>>
>> The voltage always seem lower for each OPP. So I guess if you use the
>> voltages from the pre-rev-D OPPs, you'd be fine.
>>
>>>> It's not really an issue per-se, but supporting both pre-rev-D and
>>>> post-rev-D will need to have a bit of thoughts.
>>>
>>>
>>> Hmm, tricky. What if we add a second, soc-specific, compatible to the
>>> cpu nodes which contains the cpu-revision, and then have 2 nodes
>>> for each cpu, with either one (or both) with status = "disabled"; and
>>> then on early board init detect the revision and enable the right cpu
>>> nodes ?
>>
>>
>> I was more thinking to feed the OPPs directly from the code in
>> mach-sunxi if we detect a rev-D. I don't really know what would be the
>> side effects of playing with the CPU nodes like that.
>
>
> True (wrt side-effects), but having the OPPs defined in code, rather then
> in the dts seems wrong to me. Maybe for sun6i we need to define the OPPs
> in a separate dt-node (one per revision) and have mach-sunxi populate
> the cpu node with the OPPs for the right revision ?

That was kind of what I had in mind when I started. May need some changes
to cpufreq-dt driver. It currently loads OPPs from the default bindings
unconditionally. Not sure if changing this would break anyone else.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to