On Wed, Dec 17, 2014 at 10:58 PM, Mike Turquette <[email protected]> wrote: > Quoting Mike Turquette (2014-12-17 07:23:22) >> Quoting Krzysztof Kozlowski (2014-12-16 00:20:15) >> > On pon, 2014-12-15 at 14:26 -0800, Kevin Hilman wrote: >> > > Kevin Hilman <[email protected]> writes: >> > > >> > > > Sylwester Nawrocki <[email protected]> writes: >> > > > >> > > >> On 09/12/14 13:59, Krzysztof Kozlowski wrote: >> > > >>> On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote: >> > > >>>> > Audio subsystem clocks are located in separate block. On Exynos >> > > >>>> > 5420 if >> > > >>>> > clock for this block (from main clock domain) 'mau_epll' is gated >> > > >>>> > then >> > > >>>> > any read or write to audss registers will block. >> > > >>>> > >> > > >>>> > This kind of boot hang was observed on Arndale Octa and Peach >> > > >>>> > Pi/Pit >> > > >>>> > after introducing runtime PM to pl330 DMA driver. After that >> > > >>>> > commit the >> > > >>>> > 'mau_epll' was gated, because the "amba" clock was disabled and >> > > >>>> > there >> > > >>>> > were no more users of mau_epll. >> > > >>>> > >> > > >>>> > The system hang on one of steps: >> > > >>>> > 1. Disabling unused clocks from audss block. >> > > >>>> > 2. During audss GPIO setup (just before probing i2s0 because >> > > >>>> > samsung_pinmux_setup() tried to access memory from audss block >> > > >>>> > which was >> > > >>>> > gated. >> > > >>>> > >> > > >>>> > Add a workaround for this by enabling the 'mau_epll' clock in >> > > >>>> > probe. >> > > >>>> > >> > > >>>> > Signed-off-by: Krzysztof Kozlowski <[email protected]> >> > > >>>> > --- >> > > >>>> > drivers/clk/samsung/clk-exynos-audss.c | 29 >> > > >>>> > ++++++++++++++++++++++++++++- >> > > >>>> > 1 file changed, 28 insertions(+), 1 deletion(-) >> > > >>> >> > > >>> Sorry for pinging so quick but merge window is open and it looks like >> > > >>> booting Exynos542x boards will be broken (because pl330 will no >> > > >>> longer >> > > >>> hold adma clock enabled so whole audss domain will be gated). >> > > >>> >> > > >>> This is a non-intrusive workaround for that issue, as wanted by >> > > >>> Sylwester: >> > > >>> https://lkml.org/lkml/2014/12/5/223 >> > > >>> >> > > >>> Any comments on this? >> > > >> >> > > >> The patch looks OK to me, it would be good though if someone else >> > > >> has confirmed it fixes the bug. I don't have any clock patches queued >> > > >> at the moment. Perhaps you could apply it directly, Mike ? >> > > > >> > > > I confirm it fixes the boot hang in linux-next (next-20141210) on my >> > > > exynos5800-peach-pi and exynos5420-arndale-octa. Tested both >> > > > exynos_defconfig and multi_v7_defconfig. >> > > > >> > > > Tested-by: Kevin Hilman <[email protected]> >> > > >> > > What's the status of this patch? linux-next is still broken for several >> > > Exynos5 platforms without this fix. >> > >> > I believe not only next is broken but also current mainline because >> > runtime PM for pl330 was merged yesterday... >> > >> > The patch received two tested-bys (Kevin's and Javier's) and Sylwester's >> > ack. >> > >> > Mike, could you pick the patch and send it to Linus after rc1? >> >> Will do. > > To be clear, I pulled this into clk-next towards -rc1, so it won't need > to go through as an -rc fix.
This hit today's linux-next, and exynos5 platforms are happily booting again. Thanks! Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
