Hi,
On 09-01-15 10:53, wens Tsai wrote:
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.
If we move/copy the right OPPs over to the cpu dt node (so we do runtime
devicetree mangling) before the cpufreq driver loads there should be no need
for changes to the cpufreq-dt driver.
Regards,
Hans
--
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.
