Hi Kevin, On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: > HI Thomas, > > Thomas Abraham <ta.omasab@xxxxxxxxx> writes: > >> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>> Hi Thomas, >>> >>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@xxxxxxxxx> wrote: >>>> Hi Kevin, >>>> >>>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@xxxxxxxxxxx> wrote: >>>>> >>>>> [...] >>>>> >>>>>>>> >>>>>>>> Can you clarify how you're setting the voltages to ensure stability? >>>>>>> >>>>>>> below is the diff : wip/exynos/integ >>>>>> >>>>>> Thanks. >>>>>> >>>>>> I've applied your patch, and bootup shows vdd_arm and vdd_kfc at >>>>>> 1500mV, but still when booting with cpuidle enabled (bL switcher >>>>>> disabled), I'm seeing lockups with no kernel output. With CPUidle >>>>>> disabled, things are pretty stable. >>>>>> >>>>>> What tree are you using to test this out on 5420? I'm using mainline >>>>>> v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my >>>>>> wip/exynos/integ branch at >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. >>>>> >>>>> I mis-stated this. Actually my tree is based on the v3.17-rc1 branch >>>>> of the exynos-reference tree[1] + the above mentioned patches for >>>>> cpuidle and cpufreq. >>>>> >>>>> Also, I've narrowed down the instability a bit, and it's not related >>>>> to CPUidle. I can now trigger a boot hang even without CPUidle >>>>> enabled. Here's a quick way to cause a boot lockup. With the switcher >>>>> disabled, I enable CPUfreq and set the default governor to >>>>> performance. As soon as cpufreq driver loads, it tries to use the top >>>>> frequences for both clusters, and it hangs. >>>>> >>>>> Selectively disabling frequencies, I narrowed it down to the 1.3GHz >>>>> and 1.2GHz frequencies of the little cluster. With these commented >>>>> out in the DT, it will fully boot with the performance governor >>>>> enabled. >>>>> >>>>> So that leads to the question. Are all of the operating points in >>>>> exynos5420.dtsi valid for exynos5800, and have they been validated? >>>> >>>> I tried to recreate the boot lockup issue using the same steps you >>>> listed above for the Exynos5800 peach-pi platform (Chromebook2), but I >>>> do not see any issues. I can see both clusters with max clock speed >>>> after boot (1.8GHz and 1.3GHz). >>>> >>>> I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support >>>> patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 >>>> voltage to 1.3V. >>> >>> Can you share your branch and temp hack(s) as well as your defconfig? >>> >>> I'm using the v3.17-rc1 branch from the exynos tree (which includes >>> the max77802 series) but also has a bunch of other stuff which may be >>> causing the issue. >>> >>> It would be good if I can reproduce your exact tree/branch and see if >>> I still have the same problem. >> >> The branch with the patches that have been used to test cpufreq on >> Exynos5800 is available at >> >> https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq >> >> Please let me know if this works or if there are any issues. > > Yes, your branch works fine, but it's because of the last (unposted) > patch on your branch[1]: > ARM: dts: remove all supplies sourced from tps65090 PMIC I must have explicitly stated that I am using local changes to get vdd_arm and vdd_kfc to required levels. I apologize for that. These are local temporary changes which I did not want to post. I am working on adding voltage scaling support in arm bL cpufreq driver with which these local hacks would not be necessary. > > That patch had not been posted, so I hadn't seen it before, but based on > the changelog, it's pretty clear you had the same problems that I had > without it, so I'm not sure why it wasn't mentioned earlier in this > thread. At the time of posting, this patch series was only tested on Exynos5420 based smdk5420 board. There was no regulator support for peach-pit and peach-pi at that time and so I had not tested this series on Exynos5800 Chromebook2. But the code was written to be fully compatible for Exynos5800 as well. It was when you reported a problem with Exynos5800 that I tested this series on Exynos5800 with the regulator patches from Javier. > > I also noticed that the "force vdd_arm and vdd_kfc to max voltage" patch > is not actually using the max voltage, which appears to be 1.5V from the > DT, but actually using 1.35 V, however the changelog has no explanation > for this. This also is a temporary patch and by "max voltage" I actually meant max voltage required to operate the cpus and not the max voltage that the buck can supply. > > One other thing, your temp-cpufreq branch has conflicts with max77802 > stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm > using for CPUidle dependencies, on the PMU series IIRC.) I haven't checked but probably there is an older version of Javier's regulator patches in the v3.17-rc1 branch. > > Are there any plans to update the main referece branch and include > cpufreq? Yes, a new branch with all the latest patches (cpufreq + regulator + temp fixes) will be created. I will let you when that is ready. Thanks, Thomas. > > Kevin > > [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |