Linux Samsung SOC development
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Tushar Behera <tushar.behera@linaro.org>,
	Tomasz Figa <t.figa@samsung.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	'Alim Akhtar' <alim.akhtar@gmail.com>
Cc: linux-samsung-soc@vger.kernel.org, jhbird.choi@samsung.com
Subject: Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
Date: Sat, 26 Apr 2014 01:30:06 +0200	[thread overview]
Message-ID: <535AEFFE.7020900@gmail.com> (raw)
In-Reply-To: <5358EF70.7070809@linaro.org>



On 24.04.2014 13:03, Tushar Behera wrote:
> On 04/24/2014 03:36 PM, Tomasz Figa wrote:
>> 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.akhtar@gmail.com> wrote:
>>>>>> Hi Tushar
>>>>>>
>>>>>> On Tue, Apr 22, 2014 at 11:09 AM, Tushar Behera
>>>>>> <tushar.behera@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.
>>
>
> It is also used by ADMA node, which gets probed.

If I'm looking correctly, ADMA is handled by pl330 driver which is 
registered at device_initcall level and so it shouldn't make problems 
with clk-exynos-audss driver being probed at subsys_initcall level.

>
>>>
>>> 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.
>>
>
> By the time clk-exynos-audss is getting called, mau_pd is already
> disabled by power-domain driver. That is not getting enabled during
> clk-exynos-audss probe. Am I missing something?

Probably. The driver should enable runtime PM and call 
pm_runtime_get_sync() to make sure that power is supplied to the device 
it accesses.

By the way, if defining MAU power domain in DT, then also all the 
devices inside of this domain should be bound to it, including ADMA and 
I2S, but I don't see neither of them having the "samsung,power-domain" 
property.

Best regards,
Tomasz

  reply	other threads:[~2014-04-25 23:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22  5:39 [PATCH] ARM: dts: Remove mau_pd node for Exynos5420 Tushar Behera
2014-04-22  7:38 ` Alim Akhtar
2014-04-22  8:21   ` Tushar Behera
2014-04-23 10:13     ` Kukjin Kim
2014-04-24  9:07       ` Tushar Behera
2014-04-24 10:06         ` Tomasz Figa
2014-04-24 11:03           ` Tushar Behera
2014-04-25 23:30             ` Tomasz Figa [this message]
2014-04-26 11:57               ` Vikas Sajjan
2014-04-26 15:18                 ` Tomasz Figa
2014-04-26 15:42                   ` Vikas Sajjan
2014-04-26 15:46                     ` Tomasz Figa
2014-04-28  3:41               ` Tushar Behera
2014-05-13  4:11                 ` Kukjin Kim
2014-04-22 16:34 ` Doug Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=535AEFFE.7020900@gmail.com \
    --to=tomasz.figa@gmail.com \
    --cc=alim.akhtar@gmail.com \
    --cc=jhbird.choi@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=t.figa@samsung.com \
    --cc=tushar.behera@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox