On Fri, Jan 09, 2015 at 10:56:24AM +0100, Hans de Goede wrote: > 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.
Well, we would still need to define bindings for these alternate data. But that was just an idea, it's definitely open to the discussion (and we have not seen that hardware yet, soooo...) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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.
signature.asc
Description: Digital signature
