Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)

[Krzysztof Kozlowski <k.kozlowski@samsung.com>]

On pią, 2014-11-21 at 21:49 +0100, Javier Martinez Canillas wrote:
> Hello Kevin,
> 
> On 11/21/2014 05:38 PM, Kevin Hilman wrote:
> >> So, I see two different boot failures on the Peach Pi[t] Chromebooks:
> >>
> >> 1) next20141121 boot fails due snd-soc-snow
> >>
> >> Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further
> >> but still fails with the second issue:
> >>
> >> 2) next20141121 boot hangs if unused clocks are disabled.
> >>
> >> I tried to root cause these two issues but didn't see anything evident
> >> so I'll find a last known good commit and bisect. If anyone has an
> >> idea of the possible causes for these issues that would be appreciated.
> > 
> > FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot
> > failures in next-20141121 on the exynos5420-arndale-octa[1].  Adding
> > clk_ignore_unused gets things booting there as well.
> > 
> > What's interesting is that my exynos5422-odroid-xu3 is booting fine as
> > well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as
> > exynos5410-smdk5410)
> > 
> > Whatever the issue, it definietly seems like a problem that was came
> > through a driver/subsystem tree because that these boards are all
> > booting fine with Kukjin's for-next, arm-soc/for-next and
> > mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without
> > clk_ignore_unused.)  For example, just looking at peach-pi across all
> > these trees[2], you can see that it's only failing in linux-next.
> >
> 
> By bisecting I found that the commit introducing both regressions is:
> 
> ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> 
> By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y
> and *without* clk_ignore_unused.
> 
> Krzysztof,
> 
> I see you are the author of the patch, maybe you can take a look why this
> is causing regressions in some Exynos boards?
> 

OK, I got some ideas (no need to run tests mentioned in my previous
email). Apparently the mout_audss clock (or one of its parents up to
EPLL clock) must be enabled. Configuration like this works:
$ cat /sys/kernel/debug/clk/clk_summary
    fout_epll                             1            1   100000000          0 0
       mout_sclk_epll                     1            1   100000000          0 0
          mout_mau_epll_clk               1            1   100000000          0 0
             mau_epll                     1            1   100000000          0 0
                mout_audss                1            2   100000000          0 0
                   dout_srp               0            1   100000000          0 0
                      adma                0            1   100000000          0 0
                      srp_clk             0            0   100000000          0 0
                      dout_aud_bus           0            0   100000000          0 0
                         i2s_bus           0            0   100000000          0 0
                   mout_i2s               0            0   100000000          0 0
                      dout_i2s            0            0   100000000          0 0
                         sclk_i2s           0            0   100000000          0 0


Reverting my patch enables the adma clock which effectively enables mout_audss.

Now I have to find the answer which driver uses epll/audss without enabling it explicitly...

Best regards,
Krzysztof