On pon, 2014-11-24 at 14:16 +0100, Javier Martinez Canillas wrote: > [adding Tushar Behera and Doug Anderson to cc list] > > Hello, > > On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: > > On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: > >> Hello Krzysztof, > >> > >> > It seems that mau_epll has to be enabled... or something is wrong with > >> > clock hierarchy. > >> > > >> > >> Another strange thing is that the problem does not happen for some people > >> using the same board, kernel and config options. For example Vivek and Ajay > >> report that they can't reproduce the issue on a Peach Pi using next-20141121 > >> and exynos_defconfig without using clk_ignore_unused. > > > > Maybe they have different bootloader which messes here by enabling some > > clock? > > > > Anyway it is reproducible on at least some Arndale Octa (Kevin's and > > mine) and Peach Pi boards (yours). > > > > This issue started to look extremely familiar to me so I searched in > my mail inbox and found that the same problem was previously reported > by Kevin a couple of months ago [0] and Tushar provided a fix [1]. > > I tested linux-next + [1] and that indeed fixes the hang on Peach. > > To save you a click, the problem as explained by Tushar is that the > AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when > the output of AUDSS mux is gated, no operations can be made on the > clocks provided by MAU block. For some reason the kernel just oops > so it seems to be a H/W errata? > > Mike was not fond about the solution proposed in [1] but something > along those lines would be needed maybe Tushar can comment on that. > > Vivek and Ajay, > > As explained in [0], you are not facing this issue because your RW > U-Boot seems to predate when audio support was enabled by default. > > Can you try executing "sound init" in the U-Boot prompt and see if > that triggers the hang for you? > > Best regards, > Javier > > [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html > [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html Thank you for digging this out. It looks like mau_epll is needed to keep audio powered on... Disabling the adma device (from DT) helps. But then $ cat /sys/kernel/debug/clk/clk_summary stops working. Just like ISP clocks (need to keep ISP domain on to read clk_summary). When mau_epll is disabled all of reads and writes to Audio registers fail. When system tries to disable unused adma clock it stucks because Audio domain is off... Still this is strange. 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
 |