On 24.04.2014 11:07, Tushar Behera wrote:
On 04/23/2014 03:43 PM, Kukjin Kim wrote:
Tushar Behera wrote:
On 22 April 2014 13:08, Alim Akhtar <alim.akh...@gmail.com> wrote:
Hi Tushar
On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
<tushar.beh...@linaro.org> wrote:
MAU powerdomain provides clocks for Audio sub-system block. This block
comprises of the I2S audio controller, audio DMA blocks and Audio
sub-system clock registers.
Right now, there is no way to hook up power-domains with clock
providers.
During late boot when this power-domain gets disabled, we get following
external abort.
+ Jonghwan Choi
Well, this is not a perfect solution to support MAU power domain, it's true it
is a problem right now though.
In other words, this is just temporal fix for the problem.
How about accessing clock stuff for audio sub-system with handling MAU power
domain via generic IO power domain?
+ Tomasz Figa
Existing power domain driver exynos4_pm_init_power_domain is registered
with an arch_initcall whereas the clk-exynos-audss driver is registered
with core_initcall. Hence even if add mau_pd node to clk-exynos-audss
node, the binding with power-domain doesn't happen.
I'd say core_initcall is way too early for clk-exynos-audss driver. It
should be at most subsys_initcall. As far as I can see, all users of
clocks provided by this driver (i.e. i2s) are probed at device_initcall
level anyway.
Alternately, if Tomasz's patches are applied [1], power-domain binding
is successful. But because of the init order, clk-exynos-audss defers
probe resulting in a kernel crash. Forcing clk-exynos-audss to register
through arch_initcall() fixes this issue, but I am not sure if that is okay.
If the driver crashes on deferred probe, then it's a bug and it should
be fixed.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
