All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
@ 2014-04-22  5:39 Tushar Behera
  2014-04-22  7:38 ` Alim Akhtar
  2014-04-22 16:34 ` Doug Anderson
  0 siblings, 2 replies; 15+ messages in thread
From: Tushar Behera @ 2014-04-22  5:39 UTC (permalink / raw)
  To: linux-samsung-soc; +Cc: kgene.kim

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.

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
---
 arch/arm/boot/dts/exynos5420.dtsi |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..68e0f24 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -219,11 +219,6 @@
 		reg = <0x100440C0 0x20>;
 	};
 
-	mau_pd: power-domain@100440E0 {
-		compatible = "samsung,exynos4210-pd";
-		reg = <0x100440E0 0x20>;
-	};
-
 	g2d_pd: power-domain@10044100 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044100 0x20>;
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  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-22 16:34 ` Doug Anderson
  1 sibling, 1 reply; 15+ messages in thread
From: Alim Akhtar @ 2014-04-22  7:38 UTC (permalink / raw)
  To: Tushar Behera; +Cc: linux-samsung-soc, Kukjin Kim

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.
?? which abort?? Can you please mention it here?
>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index c3a9a66..68e0f24 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -219,11 +219,6 @@
>                 reg = <0x100440C0 0x20>;
>         };
>
> -       mau_pd: power-domain@100440E0 {
> -               compatible = "samsung,exynos4210-pd";
> -               reg = <0x100440E0 0x20>;
> -       };
> -
>         g2d_pd: power-domain@10044100 {
>                 compatible = "samsung,exynos4210-pd";
>                 reg = <0x10044100 0x20>;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Alim

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-22  7:38 ` Alim Akhtar
@ 2014-04-22  8:21   ` Tushar Behera
  2014-04-23 10:13     ` Kukjin Kim
  0 siblings, 1 reply; 15+ messages in thread
From: Tushar Behera @ 2014-04-22  8:21 UTC (permalink / raw)
  To: Alim Akhtar; +Cc: linux-samsung-soc, Kukjin Kim

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.
> ?? which abort?? Can you please mention it here?
>>

Thanks Alim for spotting this ... I somehow missed adding this.

<<<<
Unhandled fault: imprecise external abort (0x1406) at 0x00000000
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
>>>>

Kukjin,

Let me know if I need to resend the patch.

-- 
Tushar Behera

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: ARM: dts: Remove mau_pd node for Exynos5420
  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 16:34 ` Doug Anderson
  1 sibling, 0 replies; 15+ messages in thread
From: Doug Anderson @ 2014-04-22 16:34 UTC (permalink / raw)
  To: Tushar Behera; +Cc: linux-samsung-soc, Kukjin Kim

Tushar,

On Mon, Apr 21, 2014 at 10:39 PM, 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.
>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
>
> ---
> arch/arm/boot/dts/exynos5420.dtsi |    5 -----
>  1 file changed, 5 deletions(-)

Tested-by: Doug Anderson <dianders@chromium.org>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-22  8:21   ` Tushar Behera
@ 2014-04-23 10:13     ` Kukjin Kim
  2014-04-24  9:07       ` Tushar Behera
  0 siblings, 1 reply; 15+ messages in thread
From: Kukjin Kim @ 2014-04-23 10:13 UTC (permalink / raw)
  To: 'Tushar Behera', 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi

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?

> > ?? which abort?? Can you please mention it here?
> >>
> 
> Thanks Alim for spotting this ... I somehow missed adding this.
> 
> <<<<
> Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
> >>>>
> 
> Kukjin,
> 
> Let me know if I need to resend the patch.

- Kukjin

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-23 10:13     ` Kukjin Kim
@ 2014-04-24  9:07       ` Tushar Behera
  2014-04-24 10:06         ` Tomasz Figa
  0 siblings, 1 reply; 15+ messages in thread
From: Tushar Behera @ 2014-04-24  9:07 UTC (permalink / raw)
  To: Kukjin Kim, 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi, Tomasz Figa

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.

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.

[1] http://www.spinics.net/lists/kernel/msg1728566.html

>>> ?? which abort?? Can you please mention it here?
>>>>
>>
>> Thanks Alim for spotting this ... I somehow missed adding this.
>>
>> <<<<
>> Unhandled fault: imprecise external abort (0x1406) at 0x00000000
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
>>>>>>
>>
>> Kukjin,
>>
>> Let me know if I need to resend the patch.
> 
> - Kukjin
> 


-- 
Tushar Behera

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-24  9:07       ` Tushar Behera
@ 2014-04-24 10:06         ` Tomasz Figa
  2014-04-24 11:03           ` Tushar Behera
  0 siblings, 1 reply; 15+ messages in thread
From: Tomasz Figa @ 2014-04-24 10:06 UTC (permalink / raw)
  To: Tushar Behera, Kukjin Kim, 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi

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.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-24 10:06         ` Tomasz Figa
@ 2014-04-24 11:03           ` Tushar Behera
  2014-04-25 23:30             ` Tomasz Figa
  0 siblings, 1 reply; 15+ messages in thread
From: Tushar Behera @ 2014-04-24 11:03 UTC (permalink / raw)
  To: Tomasz Figa, Kukjin Kim, 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi

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.

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


> Best regards,
> Tomasz


-- 
Tushar Behera

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-24 11:03           ` Tushar Behera
@ 2014-04-25 23:30             ` Tomasz Figa
  2014-04-26 11:57               ` Vikas Sajjan
  2014-04-28  3:41               ` Tushar Behera
  0 siblings, 2 replies; 15+ messages in thread
From: Tomasz Figa @ 2014-04-25 23:30 UTC (permalink / raw)
  To: Tushar Behera, Tomasz Figa, Kukjin Kim, 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi



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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-25 23:30             ` Tomasz Figa
@ 2014-04-26 11:57               ` Vikas Sajjan
  2014-04-26 15:18                 ` Tomasz Figa
  2014-04-28  3:41               ` Tushar Behera
  1 sibling, 1 reply; 15+ messages in thread
From: Vikas Sajjan @ 2014-04-26 11:57 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: Tushar Behera, Tomasz Figa, Kukjin Kim, Alim Akhtar,
	linux-samsung-soc, jhbird.choi

Hi,


On Sat, Apr 26, 2014 at 5:00 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>
>
> 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.
>

According to UM of 5420, MAU has to be power gated is specific order
the SYS_PWR_CFG field of EXYNOS5_PAD_RETENTION_MAU_SYS_PWR_REG should
be set to 0, before actually power gating the MAU block.
I am NOT sure whether this is taken care in the mainline.
As per the current implementation in pm_domain.c, the
exynos_pd_power() just writes  __raw_writel(pwr, base);
based on bool power_on passed.
We dont have the provision in the generic power domain framework to
have something like pre_power_off() or post_power_on(). Correct me if
am wrong.

Even for power gating of ISP block a certain specific order needs to
be followed.

So I think there is a need ops like pre_power_off(), post_power_on()
in generic power domain framework.

let me know your opinion.

> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-26 11:57               ` Vikas Sajjan
@ 2014-04-26 15:18                 ` Tomasz Figa
  2014-04-26 15:42                   ` Vikas Sajjan
  0 siblings, 1 reply; 15+ messages in thread
From: Tomasz Figa @ 2014-04-26 15:18 UTC (permalink / raw)
  To: Vikas Sajjan
  Cc: Tushar Behera, Tomasz Figa, Kukjin Kim, Alim Akhtar,
	linux-samsung-soc, jhbird.choi

Hi Vikas,

On 26.04.2014 13:57, Vikas Sajjan wrote:
> Hi,
>
>
> On Sat, Apr 26, 2014 at 5:00 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>
>>
>> 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.
>>
>
> According to UM of 5420, MAU has to be power gated is specific order
> the SYS_PWR_CFG field of EXYNOS5_PAD_RETENTION_MAU_SYS_PWR_REG should
> be set to 0, before actually power gating the MAU block.
> I am NOT sure whether this is taken care in the mainline.
> As per the current implementation in pm_domain.c, the
> exynos_pd_power() just writes  __raw_writel(pwr, base);
> based on bool power_on passed.
> We dont have the provision in the generic power domain framework to
> have something like pre_power_off() or post_power_on(). Correct me if
> am wrong.
>
> Even for power gating of ISP block a certain specific order needs to
> be followed.
>
> So I think there is a need ops like pre_power_off(), post_power_on()
> in generic power domain framework.
>
> let me know your opinion.

I don't think there is any need to handle this in high level code. IMHO 
just extending Exynos power domain initialization code and 
exynos_pd_power() should be enough.

Best regards,
Tomasz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-26 15:18                 ` Tomasz Figa
@ 2014-04-26 15:42                   ` Vikas Sajjan
  2014-04-26 15:46                     ` Tomasz Figa
  0 siblings, 1 reply; 15+ messages in thread
From: Vikas Sajjan @ 2014-04-26 15:42 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: Tushar Behera, Tomasz Figa, Kukjin Kim, Alim Akhtar,
	linux-samsung-soc, jhbird.choi

Hi Tomasz,

On Sat, Apr 26, 2014 at 8:48 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Vikas,
>
>
> On 26.04.2014 13:57, Vikas Sajjan wrote:
>>
>> Hi,
>>
>>
>> On Sat, Apr 26, 2014 at 5:00 AM, Tomasz Figa <tomasz.figa@gmail.com>
>> wrote:
>>>
>>>
>>>
>>> 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.
>>>
>>
>> According to UM of 5420, MAU has to be power gated is specific order
>> the SYS_PWR_CFG field of EXYNOS5_PAD_RETENTION_MAU_SYS_PWR_REG should
>> be set to 0, before actually power gating the MAU block.
>> I am NOT sure whether this is taken care in the mainline.
>> As per the current implementation in pm_domain.c, the
>> exynos_pd_power() just writes  __raw_writel(pwr, base);
>> based on bool power_on passed.
>> We dont have the provision in the generic power domain framework to
>> have something like pre_power_off() or post_power_on(). Correct me if
>> am wrong.
>>
>> Even for power gating of ISP block a certain specific order needs to
>> be followed.
>>
>> So I think there is a need ops like pre_power_off(), post_power_on()
>> in generic power domain framework.
>>
>> let me know your opinion.
>
>
> I don't think there is any need to handle this in high level code. IMHO just
> extending Exynos power domain initialization code and exynos_pd_power()
> should be enough.

Fair enough. Yes, I think we can extend the existing exynos power
domain Initialization code and exynos_pd_power() to have such support.


>
> Best regards,
> Tomasz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-26 15:42                   ` Vikas Sajjan
@ 2014-04-26 15:46                     ` Tomasz Figa
  0 siblings, 0 replies; 15+ messages in thread
From: Tomasz Figa @ 2014-04-26 15:46 UTC (permalink / raw)
  To: Vikas Sajjan
  Cc: Tushar Behera, Tomasz Figa, Kukjin Kim, Alim Akhtar,
	linux-samsung-soc, jhbird.choi

On 26.04.2014 17:42, Vikas Sajjan wrote:
> Hi Tomasz,
>
> On Sat, Apr 26, 2014 at 8:48 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>> Hi Vikas,
>>
>>
>> On 26.04.2014 13:57, Vikas Sajjan wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Sat, Apr 26, 2014 at 5:00 AM, Tomasz Figa <tomasz.figa@gmail.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> According to UM of 5420, MAU has to be power gated is specific order
>>> the SYS_PWR_CFG field of EXYNOS5_PAD_RETENTION_MAU_SYS_PWR_REG should
>>> be set to 0, before actually power gating the MAU block.
>>> I am NOT sure whether this is taken care in the mainline.
>>> As per the current implementation in pm_domain.c, the
>>> exynos_pd_power() just writes  __raw_writel(pwr, base);
>>> based on bool power_on passed.
>>> We dont have the provision in the generic power domain framework to
>>> have something like pre_power_off() or post_power_on(). Correct me if
>>> am wrong.
>>>
>>> Even for power gating of ISP block a certain specific order needs to
>>> be followed.
>>>
>>> So I think there is a need ops like pre_power_off(), post_power_on()
>>> in generic power domain framework.
>>>
>>> let me know your opinion.
>>
>>
>> I don't think there is any need to handle this in high level code. IMHO just
>> extending Exynos power domain initialization code and exynos_pd_power()
>> should be enough.
>
> Fair enough. Yes, I think we can extend the existing exynos power
> domain Initialization code and exynos_pd_power() to have such support.

OK. I still need to take a look at the manuals myself to see what kind 
of requirements can different power domains on all our supported Exynos 
SoCs have, but from what you described this seems quite do-able.

Best regards,
Tomasz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-25 23:30             ` Tomasz Figa
  2014-04-26 11:57               ` Vikas Sajjan
@ 2014-04-28  3:41               ` Tushar Behera
  2014-05-13  4:11                 ` Kukjin Kim
  1 sibling, 1 reply; 15+ messages in thread
From: Tushar Behera @ 2014-04-28  3:41 UTC (permalink / raw)
  To: Tomasz Figa, Tomasz Figa, Kukjin Kim, 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi

On 04/26/2014 05:00 AM, Tomasz Figa wrote:
> 
> 
> 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.
> 

Right, AMDA is handled by pl330 driver which gets registered during
device_initcall. But the clk_get for 'abp_clk' for devices on an AMBA
bus gets called during amba_device_add() which gets called during
arch_initcall. So if clk-exynos-audss driver is registered later, ADMA
node doesn't get added to amba device list and hence doesn't get probed.

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

Right, I was missing those calls in clk-exynos-audss driver. Adding
pm_runtime_get_sync(), the kernel crash is gone. But the issue regarding
ADMA node not getting probed still persists.

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

I had that in internal patch while testing.

> 
> Best regards,
> Tomasz

Having tried all these options, I still feel removing mau_pd node from
device tree is the only option.

-- 
Tushar Behera

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [PATCH] ARM: dts: Remove mau_pd node for Exynos5420
  2014-04-28  3:41               ` Tushar Behera
@ 2014-05-13  4:11                 ` Kukjin Kim
  0 siblings, 0 replies; 15+ messages in thread
From: Kukjin Kim @ 2014-05-13  4:11 UTC (permalink / raw)
  To: 'Tushar Behera', 'Tomasz Figa',
	'Tomasz Figa', 'Alim Akhtar'
  Cc: linux-samsung-soc, jhbird.choi

Tushar Behera wrote:

[...]

> 
> Having tried all these options, I still feel removing mau_pd node from
> device tree is the only option.

Agreed. I will apply this fix if nobody has any idea about that at this
moment.

Thanks,
Kukjin

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2014-05-13  4:11 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.