Re: [PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday, April 24, 2015 12:02:11 AM Anand Moon wrote:
> Hi Bartlomiej/Kevin,
> 
> I have being testing github branch on OdroidXU3 board,
> 
> Would you consider testing by applying patch.
> 
> https://lkml.org/lkml/2015/1/30/423
> 
> On my board it stuck after booting. Below is the console log.

The kernel with the above patch works just fine for me
(with both DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP enabled).

Could you please share your kernel config?

Also, is the user-space image that you're using available somewhere?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

>  * CPUFreq Utilities: Setting ondemand CPUFreq governor...
>   [ OK ]  * CPU7...
> [   14.245169] wait_until_divider_stable: timeout in divider stablization
>  * Starting CPU Frequency daemon cpufreqd                                [ OK ]
> [   14.385179] wait_until_divider_stable: timeout in divider stablization
> [   14.400162] wait_until_divider_stable: timeout in divider stablization
> [   14.470180] wait_until_divider_stable: timeout in divider stablization
> [   14.525157] wait_until_divider_stable: timeout in divider stablization
> [   14.665200] wait_until_divider_stable: timeout in divider stablization
>  * Starting NTP server ntpd                                              [ OK ]
> saned disabled; edit /etc/default/saned
> root@odroidxu3:~# [   14.945183] wait_until_divider_stable: timeout in
> divider stablization
> [   14.960159] wait_until_divider_stable: timeout in divider stablization
> [   15.085154] wait_until_divider_stable: timeout in divider stablization
> [   15.105170] wait_until_divider_stable: timeout in divider stablization
> [   15.125180] wait_until_divider_stable: timeout in divider stablization
> [   15.365147] wait_until_divider_stable: timeout in divider stablization
> [   15.505163] wait_until_divider_stable: timeout in divider stablization
> [   15.520167] wait_until_divider_stable: timeout in divider stablization
> [   15.930146] wait_until_divider_stable: timeout in divider stablization
> [   17.765953] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
> 
> root@odroidxu3:~#
> root@odroidxu3:~# [   23.625134] wait_until_divider_stable: timeout in
> divider stablization
> [   23.640137] wait_until_divider_stable: timeout in divider stablization
> 
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~# [   26.215135] wait_until_divider_stable: timeout in
> divider stablization
> [   26.230135] wait_until_divider_stable: timeout in divider stablization
> [   26.237850] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
> [   26.243196] Preemption disabled at:[<  (null)>]   (null)
> 
> root@odroidxu3:~#
> root@odroidxu3:~# [   26.282330] BUG: scheduling while atomic:
> kswitcher_7/1456/0x00000002
> [   26.287501] Preemption disabled at:[<  (null)>]   (null)
> [   26.293244] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
> [   26.299170] Preemption disabled at:[<  (null)>]   (null)
> 
> root@odroidxu3:~# [   27.660264] Unable to handle kernel paging
> request at virtual address ac22254f
> [   27.660633] Unable to handle kernel paging request at virtual
> address 76688788
> 
> -Anand Moon
> 
> 
> On 22 April 2015 at 23:07, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@xxxxxxxxxxx> wrote:
> >
> > On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote:
> >> Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx> writes:
> >>
> >> > On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
> >> >> Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx> writes:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > This patch series removes the use of Exynos5250 specific support
> >> >> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
> >> >> > for this platform.  The exynos-cpufreq driver itself is also removed
> >> >> > as it is no longer used/needed after Exynos5250 support removal.
> >> >> >
> >> >> > This patch series has been tested on Exynos5250 based Arndale board.
> >> >> >
> >> >> > Depends on:
> >> >> > - next-20150330 branch of linux-next kernel tree
> >> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
> >> >> >   platform" [1]
> >> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> >> >> >   platform" [2]
> >> >> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
> >> >>
> >> >> Any chance you could prepare a branch with all the dependencies for easy
> >> >> testing?
> >> >
> >> > All cpufreq changes with needed dependencies are now availble in
> >> >
> >> >     https://github.com/bzolnier/linux.git
> >> >
> >> > repository and the branch is
> >> >
> >> >     next-20150330-generic-cpufreq-exynos5420-5800-v2
> >>
> >> Great, thanks.
> >>
> >> >> Also, The previous version from Thomas was v12, and this one is neither
> >> >> versioned nor has any reference to what may have changed since that
> >> >
> >> > Please note that Thomas' patchset was split on separate parts (this is
> >> > part #3) and heavily modified so the previous versioning was dropped.
> >> >
> >> > The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
> >> > drivers for Exynos4210 platform") contains detailed changelog on what has
> >> > been changed since Thomas' original v12 patch series.  Individual Thomas'
> >> > patches which were modified by me also contain such information.
> >> >
> >> > Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> >> > platform") was entirely new code when compared to Thomas' v12 patchset so
> >> > its cover letter doesn't contain such detailed changelog as part #1.
> >> >
> >> > The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
> >> > support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
> >> > also contains the detailed changelog.
> >> >
> >> > However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
> >> > drivers for Exynos5250 platform") such summary changelog got missed for
> >> > some reason.  Here it is:
> >> > - split Exynos5250 support from the original patch
> >> > - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
> >> > - added CPU regulator supply property for Google Spring board
> >> > - removed exynos-cpufreq driver entirely as it is no longer used/needed
> >>
> >> Great, thanks for clarifying.
> >>
> >> >> version.  Also, on v12, I had several comments[1] and wonder if they've
> >> >> been addressed.
> >> >
> >> > All issues previously reported should have been fixed.  If you still see
> >> > some problems please let me know.
> >> >
> >> > [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
> >> >   exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
> >> >   been updated to contain CPU cluster regulator supply properties or else
> >> >   if the default vdd_arm/vdd_kfc regulator state is set to too low value
> >> >   there may be problems with stability when switching to higher than
> >> >   default frequencies.  I have posted v2 version of patch #2/8 of part #4
> >> >   and pushed v2 combined branch on github.  Sorry for the inconvenience. ]
> >>
> >> I've now tested your v2 branch with the bL switcher disabled, CPUidle
> >> enabled and CPUfreq enabled.
> >>
> >> With the default governor set to performance, it fails to boot.  The last
> >> kernel messages on the console are:
> >
> > [ Small explanation for people not following the discussion from
> >   the start:
> >
> >   This testing is relevant to part #4 of the rework: "[PATCH 0/8]
> >   cpufreq: add generic cpufreq driver support for Exynos5250/5800
> >   platforms" (https://lkml.org/lkml/2015/4/21/314";), not this one
> >   which is part #3 and has no known issues. ]
> >
> >> [...]
> >> [    3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
> >> [    3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
> >>
> >> However, with the default governor set to userspace it boots fine until
> >> my userspace (ubuntu) tries to enable the ondemand governor, and then it
> >> hangs.
> >>
> >> For it to boot, I have to disable the ondemand governor, and set the
> >> default governor to userspace.
> >
> > I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
> > that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
> > fails to boot.  This happens even with cpufreq support disabled (hard
> > lockup happens during mmc initialization which is done just after cpufreq
> > initialization).
> >
> > Could you please check if disabling cpuidle support helps?
> >
> >> As I reported earlier on Thomas' series, I suspect this is related to
> >> the fact that the higher OPPs aren't really functional without voltage
> >> scaling also supported.
> >
> > Part #4 contains voltage scaling support for arm_big_little[_dt] driver
> > so this should not be a problem any longer.
> >
> > You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
> > branch from my github (with cpufreq debugging printks enabled) to check
> > whether the voltage scaling is indeed done on your board.
> >
> >> I'm also seeing the wait_until_divider_stable errors when switching
> >> between the available A7 OPPs.  I'd reported this one earlier as well,
> >> along with the script to reproduce it.
> >
> > I've tried your script and it works fine for me (I only needed to change
> > cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/