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
--
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
