[RFC PATCH v3 0/2] ARM: EXYNOS: Fix Suspend-to-RAM on Exynos5420

[RFC PATCH v3 0/2] ARM: EXYNOS: Fix Suspend-to-RAM on Exynos5420

[Javier Martinez Canillas]

Hello,

This series is a 3rd version of a RFC to fix Suspend-to-RAM on Exynos5420.
Abhilash Kesavan traced down to the MDMA0 DMA controller clock needed to
be enabled during suspend in order to make the system resume correctly.

I posted a RFC that grabbed the clock in the Exynos5420 specific suspend
and resume callbacks [0] and a re-spin [1] but was asked by Abhilash and
Chanwoo to do it in the clock driver instead.

So this series is an attempt to fix the issue and is composed of patches:

Javier Martinez Canillas (2):
  clk: samsung: Add a clock lookup function
  clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

 drivers/clk/samsung/clk-exynos5420.c | 26 ++++++++++++++++++++++++--
 drivers/clk/samsung/clk.c            |  6 ++++++
 drivers/clk/samsung/clk.h            |  3 +++
 3 files changed, 33 insertions(+), 2 deletions(-)

Patch #1 just adds a function to lookup the provider clock instances.

Patch #2 enables the MDMA0 clock before entering into a suspend state and
disables it again once the system has been resumed.

The patches are again an RFC because I'm not sure if this is the best
approach to solve the issue. So feedback will be highly appreciated.

Best regards,
Javier

[0]: https://lkml.org/lkml/2015/3/27/397
[1]: https://lkml.org/lkml/2015/3/27/770

[RFC PATCH v3 0/2] ARM: EXYNOS: Fix Suspend-to-RAM on Exynos5420

[Javier Martinez Canillas]

Hello,

This series is a 3rd version of a RFC to fix Suspend-to-RAM on Exynos5420.
Abhilash Kesavan traced down to the MDMA0 DMA controller clock needed to
be enabled during suspend in order to make the system resume correctly.

I posted a RFC that grabbed the clock in the Exynos5420 specific suspend
and resume callbacks [0] and a re-spin [1] but was asked by Abhilash and
Chanwoo to do it in the clock driver instead.

So this series is an attempt to fix the issue and is composed of patches:

Javier Martinez Canillas (2):
  clk: samsung: Add a clock lookup function
  clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

 drivers/clk/samsung/clk-exynos5420.c | 26 ++++++++++++++++++++++++--
 drivers/clk/samsung/clk.c            |  6 ++++++
 drivers/clk/samsung/clk.h            |  3 +++
 3 files changed, 33 insertions(+), 2 deletions(-)

Patch #1 just adds a function to lookup the provider clock instances.

Patch #2 enables the MDMA0 clock before entering into a suspend state and
disables it again once the system has been resumed.

The patches are again an RFC because I'm not sure if this is the best
approach to solve the issue. So feedback will be highly appreciated.

Best regards,
Javier

[0]: https://lkml.org/lkml/2015/3/27/397
[1]: https://lkml.org/lkml/2015/3/27/770

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

The Samsung helpers functions to register clocks, add the clock instance
returned by the common clock framework to a lookup table that is used by
OF to lookup the clocks.

But this table could also be useful to clock drivers if they need to get
a clock instance since the helper functions don't return them.

The common clock framework __clk_lookup() function from the clk provider
API could be used by drivers as well. But it's more efficient to use the
Samsung specific lookup table that returns the clock instance in constant
time, than using the __clk_lookup() function that uses the clock name as
an index so it has a linear search time.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk.c | 6 ++++++
 drivers/clk/samsung/clk.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 9e1f88c04fd4..3b2868a70774 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -96,6 +96,12 @@ void samsung_clk_add_lookup(struct samsung_clk_provider *ctx, struct clk *clk,
 		ctx->clk_data.clks[id] = clk;
 }
 
+struct clk *samsung_clk_lookup(struct samsung_clk_provider *ctx,
+				unsigned int id)
+{
+	return ctx->clk_data.clks ? ctx->clk_data.clks[id] : NULL;
+}
+
 /* register a list of aliases */
 void __init samsung_clk_register_alias(struct samsung_clk_provider *ctx,
 				struct samsung_clock_alias *list,
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index e4c75383cea7..ad04220bd733 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -368,6 +368,9 @@ extern void __init samsung_clk_of_register_fixed_ext(
 extern void samsung_clk_add_lookup(struct samsung_clk_provider *ctx,
 			struct clk *clk, unsigned int id);
 
+extern struct clk *samsung_clk_lookup(struct samsung_clk_provider *ctx,
+			unsigned int id);
+
 extern void samsung_clk_register_alias(struct samsung_clk_provider *ctx,
 			struct samsung_clock_alias *list,
 			unsigned int nr_clk);
-- 
2.1.4

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

The Samsung helpers functions to register clocks, add the clock instance
returned by the common clock framework to a lookup table that is used by
OF to lookup the clocks.

But this table could also be useful to clock drivers if they need to get
a clock instance since the helper functions don't return them.

The common clock framework __clk_lookup() function from the clk provider
API could be used by drivers as well. But it's more efficient to use the
Samsung specific lookup table that returns the clock instance in constant
time, than using the __clk_lookup() function that uses the clock name as
an index so it has a linear search time.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk.c | 6 ++++++
 drivers/clk/samsung/clk.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 9e1f88c04fd4..3b2868a70774 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -96,6 +96,12 @@ void samsung_clk_add_lookup(struct samsung_clk_provider *ctx, struct clk *clk,
 		ctx->clk_data.clks[id] = clk;
 }
 
+struct clk *samsung_clk_lookup(struct samsung_clk_provider *ctx,
+				unsigned int id)
+{
+	return ctx->clk_data.clks ? ctx->clk_data.clks[id] : NULL;
+}
+
 /* register a list of aliases */
 void __init samsung_clk_register_alias(struct samsung_clk_provider *ctx,
 				struct samsung_clock_alias *list,
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index e4c75383cea7..ad04220bd733 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -368,6 +368,9 @@ extern void __init samsung_clk_of_register_fixed_ext(
 extern void samsung_clk_add_lookup(struct samsung_clk_provider *ctx,
 			struct clk *clk, unsigned int id);
 
+extern struct clk *samsung_clk_lookup(struct samsung_clk_provider *ctx,
+			unsigned int id);
+
 extern void samsung_clk_register_alias(struct samsung_clk_provider *ctx,
 			struct samsung_clock_alias *list,
 			unsigned int nr_clk);
-- 
2.1.4

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Tomasz Figa]

Hi Javier,

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> The Samsung helpers functions to register clocks, add the clock instance
> returned by the common clock framework to a lookup table that is used by
> OF to lookup the clocks.
>
> But this table could also be useful to clock drivers if they need to get
> a clock instance since the helper functions don't return them.
>
> The common clock framework __clk_lookup() function from the clk provider
> API could be used by drivers as well. But it's more efficient to use the
> Samsung specific lookup table that returns the clock instance in constant
> time, than using the __clk_lookup() function that uses the clock name as
> an index so it has a linear search time.

Is this really something we should be concerned about? If so, maybe
the generic look-up function should be rewritten to use something
faster, such as tree or hash table?

Best regards,
Tomasz

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Tomasz Figa]

Hi Javier,

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> The Samsung helpers functions to register clocks, add the clock instance
> returned by the common clock framework to a lookup table that is used by
> OF to lookup the clocks.
>
> But this table could also be useful to clock drivers if they need to get
> a clock instance since the helper functions don't return them.
>
> The common clock framework __clk_lookup() function from the clk provider
> API could be used by drivers as well. But it's more efficient to use the
> Samsung specific lookup table that returns the clock instance in constant
> time, than using the __clk_lookup() function that uses the clock name as
> an index so it has a linear search time.

Is this really something we should be concerned about? If so, maybe
the generic look-up function should be rewritten to use something
faster, such as tree or hash table?

Best regards,
Tomasz

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Tomasz Figa]

Hi Javier,

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> The Samsung helpers functions to register clocks, add the clock instance
> returned by the common clock framework to a lookup table that is used by
> OF to lookup the clocks.
>
> But this table could also be useful to clock drivers if they need to get
> a clock instance since the helper functions don't return them.
>
> The common clock framework __clk_lookup() function from the clk provider
> API could be used by drivers as well. But it's more efficient to use the
> Samsung specific lookup table that returns the clock instance in constant
> time, than using the __clk_lookup() function that uses the clock name as
> an index so it has a linear search time.

Is this really something we should be concerned about? If so, maybe
the generic look-up function should be rewritten to use something
faster, such as tree or hash table?

Best regards,
Tomasz

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

Hello Tomasz,

On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> Hi Javier,
> 
> 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> The Samsung helpers functions to register clocks, add the clock instance
>> returned by the common clock framework to a lookup table that is used by
>> OF to lookup the clocks.
>>
>> But this table could also be useful to clock drivers if they need to get
>> a clock instance since the helper functions don't return them.
>>
>> The common clock framework __clk_lookup() function from the clk provider
>> API could be used by drivers as well. But it's more efficient to use the
>> Samsung specific lookup table that returns the clock instance in constant
>> time, than using the __clk_lookup() function that uses the clock name as
>> an index so it has a linear search time.
> 
> Is this really something we should be concerned about? If so, maybe
> the generic look-up function should be rewritten to use something
> faster, such as tree or hash table?
>

I don't performance is a big issue here. I just thought that since the
lookup table is already filled by the driver and the lookup function
is one line, we could use that instead to get the performance benefit.

But I don't mind to drop this patch and use the generic lookup function
from the CCF API if that is preferred.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

Hello Tomasz,

On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> Hi Javier,
> 
> 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> The Samsung helpers functions to register clocks, add the clock instance
>> returned by the common clock framework to a lookup table that is used by
>> OF to lookup the clocks.
>>
>> But this table could also be useful to clock drivers if they need to get
>> a clock instance since the helper functions don't return them.
>>
>> The common clock framework __clk_lookup() function from the clk provider
>> API could be used by drivers as well. But it's more efficient to use the
>> Samsung specific lookup table that returns the clock instance in constant
>> time, than using the __clk_lookup() function that uses the clock name as
>> an index so it has a linear search time.
> 
> Is this really something we should be concerned about? If so, maybe
> the generic look-up function should be rewritten to use something
> faster, such as tree or hash table?
>

I don't performance is a big issue here. I just thought that since the
lookup table is already filled by the driver and the lookup function
is one line, we could use that instead to get the performance benefit.

But I don't mind to drop this patch and use the generic lookup function
from the CCF API if that is preferred.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

Hello Tomasz,

On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> Hi Javier,
> 
> 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> The Samsung helpers functions to register clocks, add the clock instance
>> returned by the common clock framework to a lookup table that is used by
>> OF to lookup the clocks.
>>
>> But this table could also be useful to clock drivers if they need to get
>> a clock instance since the helper functions don't return them.
>>
>> The common clock framework __clk_lookup() function from the clk provider
>> API could be used by drivers as well. But it's more efficient to use the
>> Samsung specific lookup table that returns the clock instance in constant
>> time, than using the __clk_lookup() function that uses the clock name as
>> an index so it has a linear search time.
> 
> Is this really something we should be concerned about? If so, maybe
> the generic look-up function should be rewritten to use something
> faster, such as tree or hash table?
>

I don't performance is a big issue here. I just thought that since the
lookup table is already filled by the driver and the lookup function
is one line, we could use that instead to get the performance benefit.

But I don't mind to drop this patch and use the generic lookup function
from the CCF API if that is preferred.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Michael Turquette]

Quoting Javier Martinez Canillas (2015-03-30 09:08:40)
> Hello Tomasz,
> 
> On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> > Hi Javier,
> > 
> > 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> > <javier.martinez@collabora.co.uk>:
> >> The Samsung helpers functions to register clocks, add the clock instance
> >> returned by the common clock framework to a lookup table that is used by
> >> OF to lookup the clocks.
> >>
> >> But this table could also be useful to clock drivers if they need to get
> >> a clock instance since the helper functions don't return them.
> >>
> >> The common clock framework __clk_lookup() function from the clk provider
> >> API could be used by drivers as well. But it's more efficient to use the
> >> Samsung specific lookup table that returns the clock instance in constant
> >> time, than using the __clk_lookup() function that uses the clock name as
> >> an index so it has a linear search time.
> > 
> > Is this really something we should be concerned about? If so, maybe
> > the generic look-up function should be rewritten to use something
> > faster, such as tree or hash table?
> >
> 
> I don't performance is a big issue here. I just thought that since the
> lookup table is already filled by the driver and the lookup function
> is one line, we could use that instead to get the performance benefit.
> 
> But I don't mind to drop this patch and use the generic lookup function
> from the CCF API if that is preferred.

Hello,

I am not a fan of __clk_lookup and I don't like to see it used more and
more outside of drivers/clk/clk.c. You mentioned that performance wasn't
really the problem here.  The real method for a driver to get a clock is
with clk_get(). Any reason to not use that?

Regards,
Mike

>  
> > Best regards,
> > Tomasz
> >
> 
> Best regards,
> Javier

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Michael Turquette]

Quoting Javier Martinez Canillas (2015-03-30 09:08:40)
> Hello Tomasz,
> 
> On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> > Hi Javier,
> > 
> > 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> > <javier.martinez@collabora.co.uk>:
> >> The Samsung helpers functions to register clocks, add the clock instance
> >> returned by the common clock framework to a lookup table that is used by
> >> OF to lookup the clocks.
> >>
> >> But this table could also be useful to clock drivers if they need to get
> >> a clock instance since the helper functions don't return them.
> >>
> >> The common clock framework __clk_lookup() function from the clk provider
> >> API could be used by drivers as well. But it's more efficient to use the
> >> Samsung specific lookup table that returns the clock instance in constant
> >> time, than using the __clk_lookup() function that uses the clock name as
> >> an index so it has a linear search time.
> > 
> > Is this really something we should be concerned about? If so, maybe
> > the generic look-up function should be rewritten to use something
> > faster, such as tree or hash table?
> >
> 
> I don't performance is a big issue here. I just thought that since the
> lookup table is already filled by the driver and the lookup function
> is one line, we could use that instead to get the performance benefit.
> 
> But I don't mind to drop this patch and use the generic lookup function
> from the CCF API if that is preferred.

Hello,

I am not a fan of __clk_lookup and I don't like to see it used more and
more outside of drivers/clk/clk.c. You mentioned that performance wasn't
really the problem here.  The real method for a driver to get a clock is
with clk_get(). Any reason to not use that?

Regards,
Mike

>  
> > Best regards,
> > Tomasz
> >
> 
> Best regards,
> Javier

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Michael Turquette]

Quoting Javier Martinez Canillas (2015-03-30 09:08:40)
> Hello Tomasz,
> 
> On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> > Hi Javier,
> > 
> > 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> > <javier.martinez@collabora.co.uk>:
> >> The Samsung helpers functions to register clocks, add the clock instance
> >> returned by the common clock framework to a lookup table that is used by
> >> OF to lookup the clocks.
> >>
> >> But this table could also be useful to clock drivers if they need to get
> >> a clock instance since the helper functions don't return them.
> >>
> >> The common clock framework __clk_lookup() function from the clk provider
> >> API could be used by drivers as well. But it's more efficient to use the
> >> Samsung specific lookup table that returns the clock instance in constant
> >> time, than using the __clk_lookup() function that uses the clock name as
> >> an index so it has a linear search time.
> > 
> > Is this really something we should be concerned about? If so, maybe
> > the generic look-up function should be rewritten to use something
> > faster, such as tree or hash table?
> >
> 
> I don't performance is a big issue here. I just thought that since the
> lookup table is already filled by the driver and the lookup function
> is one line, we could use that instead to get the performance benefit.
> 
> But I don't mind to drop this patch and use the generic lookup function
> from the CCF API if that is preferred.

Hello,

I am not a fan of __clk_lookup and I don't like to see it used more and
more outside of drivers/clk/clk.c. You mentioned that performance wasn't
really the problem here.  The real method for a driver to get a clock is
with clk_get(). Any reason to not use that?

Regards,
Mike

>  
> > Best regards,
> > Tomasz
> >
> 
> Best regards,
> Javier

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

+Tomeu who I forgot to add to the cc list.

Hello Mike,

Thanks a lot for your feedback.

On 03/31/2015 03:40 AM, Michael Turquette wrote:
>> 
>> I don't performance is a big issue here. I just thought that since the
>> lookup table is already filled by the driver and the lookup function
>> is one line, we could use that instead to get the performance benefit.
>> 
>> But I don't mind to drop this patch and use the generic lookup function
>> from the CCF API if that is preferred.
> 
> Hello,
> 
> I am not a fan of __clk_lookup and I don't like to see it used more and
> more outside of drivers/clk/clk.c. You mentioned that performance wasn't
> really the problem here.  The real method for a driver to get a clock is
> with clk_get(). Any reason to not use that?
>

I can certainly use clk_get() but I thought that the clk consumer API was
not supposed to be used from within clock drivers. That's why I mentioned
__clk_lookup() as a possibility since that is part of the provider API.

Below is a RFC patch that uses clk_get() [0]. That needs another patch
which was part of a previous RFC and adds an alias for the mdma0 clock:

https://lkml.org/lkml/2015/3/27/769

If you think that is the correct approach then I can post it as a patch.

It would be great if you can also provide some feedback about the other
patch in the first RFC that instead of enabling and disabling the mdma0
clock in driver, does it in the exynos5420 platform PM callbacks:

https://lkml.org/lkml/2015/3/27/770

I was asked to do it in the exynos5420 clk driver instead but maybe you
have a different opinion on that.

Best regards,
Javier

[0]:
>From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Mon, 30 Mar 2015 17:11:40 +0200
Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
 suspend

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this clock needs to remain enabled in order to make
the system resume from a system suspend state.

To make sure that the clock is enabled during suspend, enable it prior
to entering a suspend state and disable it once the system has resumed.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 8b49e8b3b548..02029cf9fcb8 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -155,6 +155,7 @@ static enum exynos5x_soc exynos5x_soc;
 #ifdef CONFIG_PM_SLEEP
 static struct samsung_clk_reg_dump *exynos5x_save;
 static struct samsung_clk_reg_dump *exynos5800_save;
+static struct clk **exynos5x_clks;
 
 /*
  * list of controller registers to be saved and restored during a
@@ -275,8 +276,17 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
 
+/*
+ * list of clocks that have to be kept enabled during suspend/resume cycle.
+ */
+static const char *exynos5x_clk_pm[] __initdata = {
+	"mdma0",
+};
+
 static int exynos5420_clk_suspend(void)
 {
+	int i;
+
 	samsung_clk_save(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -287,11 +297,19 @@ static int exynos5420_clk_suspend(void)
 	samsung_clk_restore(reg_base, exynos5420_set_clksrc,
 				ARRAY_SIZE(exynos5420_set_clksrc));
 
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
+		clk_prepare_enable(exynos5x_clks[i]);
+
 	return 0;
 }
 
 static void exynos5420_clk_resume(void)
 {
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
+		clk_disable_unprepare(exynos5x_clks[i]);
+
 	samsung_clk_restore(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -307,6 +325,9 @@ static struct syscore_ops exynos5420_clk_syscore_ops = {
 
 static void exynos5420_clk_sleep_init(void)
 {
+	int i;
+	int clk_len = ARRAY_SIZE(exynos5x_clk_pm);
+
 	exynos5x_save = samsung_clk_alloc_reg_dump(exynos5x_clk_regs,
 					ARRAY_SIZE(exynos5x_clk_regs));
 	if (!exynos5x_save) {
@@ -323,8 +344,31 @@ static void exynos5420_clk_sleep_init(void)
 			goto err_soc;
 	}
 
+	exynos5x_clks = kzalloc(sizeof(struct clk *) * clk_len, GFP_KERNEL);
+	if (!exynos5x_clks)
+		goto err_clks;
+
+	for (i = 0; i < clk_len; i++) {
+		exynos5x_clks[i] = clk_get(NULL, exynos5x_clk_pm[i]);
+		if (IS_ERR(exynos5x_clks[i])) {
+			pr_warn("Failed to get %s clk (%ld)\n",
+				exynos5x_clk_pm[i], PTR_ERR(exynos5x_clks[i]));
+
+			while (i--)
+				clk_put(exynos5x_clks[i]);
+
+			goto err_clkget;
+		}
+	}
+
 	register_syscore_ops(&exynos5420_clk_syscore_ops);
 	return;
+err_clkget:
+	kfree(exynos5x_clks);
+err_clks:
+	kfree(exynos5800_save);
+	pr_warn("%s: failed to allocate suspend clocks, no sleep support!\n",
+		__func__);
 err_soc:
 	kfree(exynos5x_save);
 	pr_warn("%s: failed to allocate sleep save data, no sleep support!\n",
-- 
2.1.4

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

+Tomeu who I forgot to add to the cc list.

Hello Mike,

Thanks a lot for your feedback.

On 03/31/2015 03:40 AM, Michael Turquette wrote:
>> 
>> I don't performance is a big issue here. I just thought that since the
>> lookup table is already filled by the driver and the lookup function
>> is one line, we could use that instead to get the performance benefit.
>> 
>> But I don't mind to drop this patch and use the generic lookup function
>> from the CCF API if that is preferred.
> 
> Hello,
> 
> I am not a fan of __clk_lookup and I don't like to see it used more and
> more outside of drivers/clk/clk.c. You mentioned that performance wasn't
> really the problem here.  The real method for a driver to get a clock is
> with clk_get(). Any reason to not use that?
>

I can certainly use clk_get() but I thought that the clk consumer API was
not supposed to be used from within clock drivers. That's why I mentioned
__clk_lookup() as a possibility since that is part of the provider API.

Below is a RFC patch that uses clk_get() [0]. That needs another patch
which was part of a previous RFC and adds an alias for the mdma0 clock:

https://lkml.org/lkml/2015/3/27/769

If you think that is the correct approach then I can post it as a patch.

It would be great if you can also provide some feedback about the other
patch in the first RFC that instead of enabling and disabling the mdma0
clock in driver, does it in the exynos5420 platform PM callbacks:

https://lkml.org/lkml/2015/3/27/770

I was asked to do it in the exynos5420 clk driver instead but maybe you
have a different opinion on that.

Best regards,
Javier

[0]:
>From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Mon, 30 Mar 2015 17:11:40 +0200
Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
 suspend

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this clock needs to remain enabled in order to make
the system resume from a system suspend state.

To make sure that the clock is enabled during suspend, enable it prior
to entering a suspend state and disable it once the system has resumed.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 8b49e8b3b548..02029cf9fcb8 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -155,6 +155,7 @@ static enum exynos5x_soc exynos5x_soc;
 #ifdef CONFIG_PM_SLEEP
 static struct samsung_clk_reg_dump *exynos5x_save;
 static struct samsung_clk_reg_dump *exynos5800_save;
+static struct clk **exynos5x_clks;
 
 /*
  * list of controller registers to be saved and restored during a
@@ -275,8 +276,17 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
 
+/*
+ * list of clocks that have to be kept enabled during suspend/resume cycle.
+ */
+static const char *exynos5x_clk_pm[] __initdata = {
+	"mdma0",
+};
+
 static int exynos5420_clk_suspend(void)
 {
+	int i;
+
 	samsung_clk_save(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -287,11 +297,19 @@ static int exynos5420_clk_suspend(void)
 	samsung_clk_restore(reg_base, exynos5420_set_clksrc,
 				ARRAY_SIZE(exynos5420_set_clksrc));
 
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
+		clk_prepare_enable(exynos5x_clks[i]);
+
 	return 0;
 }
 
 static void exynos5420_clk_resume(void)
 {
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
+		clk_disable_unprepare(exynos5x_clks[i]);
+
 	samsung_clk_restore(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -307,6 +325,9 @@ static struct syscore_ops exynos5420_clk_syscore_ops = {
 
 static void exynos5420_clk_sleep_init(void)
 {
+	int i;
+	int clk_len = ARRAY_SIZE(exynos5x_clk_pm);
+
 	exynos5x_save = samsung_clk_alloc_reg_dump(exynos5x_clk_regs,
 					ARRAY_SIZE(exynos5x_clk_regs));
 	if (!exynos5x_save) {
@@ -323,8 +344,31 @@ static void exynos5420_clk_sleep_init(void)
 			goto err_soc;
 	}
 
+	exynos5x_clks = kzalloc(sizeof(struct clk *) * clk_len, GFP_KERNEL);
+	if (!exynos5x_clks)
+		goto err_clks;
+
+	for (i = 0; i < clk_len; i++) {
+		exynos5x_clks[i] = clk_get(NULL, exynos5x_clk_pm[i]);
+		if (IS_ERR(exynos5x_clks[i])) {
+			pr_warn("Failed to get %s clk (%ld)\n",
+				exynos5x_clk_pm[i], PTR_ERR(exynos5x_clks[i]));
+
+			while (i--)
+				clk_put(exynos5x_clks[i]);
+
+			goto err_clkget;
+		}
+	}
+
 	register_syscore_ops(&exynos5420_clk_syscore_ops);
 	return;
+err_clkget:
+	kfree(exynos5x_clks);
+err_clks:
+	kfree(exynos5800_save);
+	pr_warn("%s: failed to allocate suspend clocks, no sleep support!\n",
+		__func__);
 err_soc:
 	kfree(exynos5x_save);
 	pr_warn("%s: failed to allocate sleep save data, no sleep support!\n",
-- 
2.1.4

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

+Tomeu who I forgot to add to the cc list.

Hello Mike,

Thanks a lot for your feedback.

On 03/31/2015 03:40 AM, Michael Turquette wrote:
>> 
>> I don't performance is a big issue here. I just thought that since the
>> lookup table is already filled by the driver and the lookup function
>> is one line, we could use that instead to get the performance benefit.
>> 
>> But I don't mind to drop this patch and use the generic lookup function
>> from the CCF API if that is preferred.
> 
> Hello,
> 
> I am not a fan of __clk_lookup and I don't like to see it used more and
> more outside of drivers/clk/clk.c. You mentioned that performance wasn't
> really the problem here.  The real method for a driver to get a clock is
> with clk_get(). Any reason to not use that?
>

I can certainly use clk_get() but I thought that the clk consumer API was
not supposed to be used from within clock drivers. That's why I mentioned
__clk_lookup() as a possibility since that is part of the provider API.

Below is a RFC patch that uses clk_get() [0]. That needs another patch
which was part of a previous RFC and adds an alias for the mdma0 clock:

https://lkml.org/lkml/2015/3/27/769

If you think that is the correct approach then I can post it as a patch.

It would be great if you can also provide some feedback about the other
patch in the first RFC that instead of enabling and disabling the mdma0
clock in driver, does it in the exynos5420 platform PM callbacks:

https://lkml.org/lkml/2015/3/27/770

I was asked to do it in the exynos5420 clk driver instead but maybe you
have a different opinion on that.

Best regards,
Javier

[0]:
>From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Mon, 30 Mar 2015 17:11:40 +0200
Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
 suspend

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this clock needs to remain enabled in order to make
the system resume from a system suspend state.

To make sure that the clock is enabled during suspend, enable it prior
to entering a suspend state and disable it once the system has resumed.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 44 ++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 8b49e8b3b548..02029cf9fcb8 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -155,6 +155,7 @@ static enum exynos5x_soc exynos5x_soc;
 #ifdef CONFIG_PM_SLEEP
 static struct samsung_clk_reg_dump *exynos5x_save;
 static struct samsung_clk_reg_dump *exynos5800_save;
+static struct clk **exynos5x_clks;
 
 /*
  * list of controller registers to be saved and restored during a
@@ -275,8 +276,17 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
 
+/*
+ * list of clocks that have to be kept enabled during suspend/resume cycle.
+ */
+static const char *exynos5x_clk_pm[] __initdata = {
+	"mdma0",
+};
+
 static int exynos5420_clk_suspend(void)
 {
+	int i;
+
 	samsung_clk_save(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -287,11 +297,19 @@ static int exynos5420_clk_suspend(void)
 	samsung_clk_restore(reg_base, exynos5420_set_clksrc,
 				ARRAY_SIZE(exynos5420_set_clksrc));
 
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
+		clk_prepare_enable(exynos5x_clks[i]);
+
 	return 0;
 }
 
 static void exynos5420_clk_resume(void)
 {
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
+		clk_disable_unprepare(exynos5x_clks[i]);
+
 	samsung_clk_restore(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -307,6 +325,9 @@ static struct syscore_ops exynos5420_clk_syscore_ops = {
 
 static void exynos5420_clk_sleep_init(void)
 {
+	int i;
+	int clk_len = ARRAY_SIZE(exynos5x_clk_pm);
+
 	exynos5x_save = samsung_clk_alloc_reg_dump(exynos5x_clk_regs,
 					ARRAY_SIZE(exynos5x_clk_regs));
 	if (!exynos5x_save) {
@@ -323,8 +344,31 @@ static void exynos5420_clk_sleep_init(void)
 			goto err_soc;
 	}
 
+	exynos5x_clks = kzalloc(sizeof(struct clk *) * clk_len, GFP_KERNEL);
+	if (!exynos5x_clks)
+		goto err_clks;
+
+	for (i = 0; i < clk_len; i++) {
+		exynos5x_clks[i] = clk_get(NULL, exynos5x_clk_pm[i]);
+		if (IS_ERR(exynos5x_clks[i])) {
+			pr_warn("Failed to get %s clk (%ld)\n",
+				exynos5x_clk_pm[i], PTR_ERR(exynos5x_clks[i]));
+
+			while (i--)
+				clk_put(exynos5x_clks[i]);
+
+			goto err_clkget;
+		}
+	}
+
 	register_syscore_ops(&exynos5420_clk_syscore_ops);
 	return;
+err_clkget:
+	kfree(exynos5x_clks);
+err_clks:
+	kfree(exynos5800_save);
+	pr_warn("%s: failed to allocate suspend clocks, no sleep support!\n",
+		__func__);
 err_soc:
 	kfree(exynos5x_save);
 	pr_warn("%s: failed to allocate sleep save data, no sleep support!\n",
-- 
2.1.4

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Michael Turquette]

Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
> +Tomeu who I forgot to add to the cc list.
> 
> Hello Mike,
> 
> Thanks a lot for your feedback.
> 
> On 03/31/2015 03:40 AM, Michael Turquette wrote:
> >> 
> >> I don't performance is a big issue here. I just thought that since the
> >> lookup table is already filled by the driver and the lookup function
> >> is one line, we could use that instead to get the performance benefit.
> >> 
> >> But I don't mind to drop this patch and use the generic lookup function
> >> from the CCF API if that is preferred.
> > 
> > Hello,
> > 
> > I am not a fan of __clk_lookup and I don't like to see it used more and
> > more outside of drivers/clk/clk.c. You mentioned that performance wasn't
> > really the problem here.  The real method for a driver to get a clock is
> > with clk_get(). Any reason to not use that?
> >
> 
> I can certainly use clk_get() but I thought that the clk consumer API was
> not supposed to be used from within clock drivers. That's why I mentioned
> __clk_lookup() as a possibility since that is part of the provider API.

I would like to remove __clk_lookup some day, so the fewer users now the
better. Additionally, now that we have unique struct clk pointers from
clk_get it makes a lot of sense for clk_register to stop returning
pointers to a struct clk. Hopefully we can get around to that soon.

These two points above are enough reason for the clock provider to use
clk_get.

> 
> Below is a RFC patch that uses clk_get() [0]. That needs another patch
> which was part of a previous RFC and adds an alias for the mdma0 clock:
> 
> https://lkml.org/lkml/2015/3/27/769
> 
> If you think that is the correct approach then I can post it as a patch.
> 
> It would be great if you can also provide some feedback about the other
> patch in the first RFC that instead of enabling and disabling the mdma0
> clock in driver, does it in the exynos5420 platform PM callbacks:
> 
> https://lkml.org/lkml/2015/3/27/770

This seems like a big hack to me.

> 
> I was asked to do it in the exynos5420 clk driver instead but maybe you
> have a different opinion on that.
> 
> Best regards,
> Javier
> 
> [0]:
> From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Mon, 30 Mar 2015 17:11:40 +0200
> Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
>  suspend
> 
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this clock needs to remain enabled in order to make
> the system resume from a system suspend state.
> 
> To make sure that the clock is enabled during suspend, enable it prior
> to entering a suspend state and disable it once the system has resumed.

I'd like to understand the issue a bit further. Isn't the correct
solution that the clk's prepare/unprepare and enable/disable callbacks
should support the CG_STATUS requirement?

Regards,
Mike

> 
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
> 
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 44 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 8b49e8b3b548..02029cf9fcb8 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -155,6 +155,7 @@ static enum exynos5x_soc exynos5x_soc;
>  #ifdef CONFIG_PM_SLEEP
>  static struct samsung_clk_reg_dump *exynos5x_save;
>  static struct samsung_clk_reg_dump *exynos5800_save;
> +static struct clk **exynos5x_clks;
>  
>  /*
>   * list of controller registers to be saved and restored during a
> @@ -275,8 +276,17 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
>  
> +/*
> + * list of clocks that have to be kept enabled during suspend/resume cycle.
> + */
> +static const char *exynos5x_clk_pm[] __initdata = {
> +       "mdma0",
> +};
> +
>  static int exynos5420_clk_suspend(void)
>  {
> +       int i;
> +
>         samsung_clk_save(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>  
> @@ -287,11 +297,19 @@ static int exynos5420_clk_suspend(void)
>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>  
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
> +               clk_prepare_enable(exynos5x_clks[i]);
> +
>         return 0;
>  }
>  
>  static void exynos5420_clk_resume(void)
>  {
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
> +               clk_disable_unprepare(exynos5x_clks[i]);
> +
>         samsung_clk_restore(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>  
> @@ -307,6 +325,9 @@ static struct syscore_ops exynos5420_clk_syscore_ops = {
>  
>  static void exynos5420_clk_sleep_init(void)
>  {
> +       int i;
> +       int clk_len = ARRAY_SIZE(exynos5x_clk_pm);
> +
>         exynos5x_save = samsung_clk_alloc_reg_dump(exynos5x_clk_regs,
>                                         ARRAY_SIZE(exynos5x_clk_regs));
>         if (!exynos5x_save) {
> @@ -323,8 +344,31 @@ static void exynos5420_clk_sleep_init(void)
>                         goto err_soc;
>         }
>  
> +       exynos5x_clks = kzalloc(sizeof(struct clk *) * clk_len, GFP_KERNEL);
> +       if (!exynos5x_clks)
> +               goto err_clks;
> +
> +       for (i = 0; i < clk_len; i++) {
> +               exynos5x_clks[i] = clk_get(NULL, exynos5x_clk_pm[i]);
> +               if (IS_ERR(exynos5x_clks[i])) {
> +                       pr_warn("Failed to get %s clk (%ld)\n",
> +                               exynos5x_clk_pm[i], PTR_ERR(exynos5x_clks[i]));
> +
> +                       while (i--)
> +                               clk_put(exynos5x_clks[i]);
> +
> +                       goto err_clkget;
> +               }
> +       }
> +
>         register_syscore_ops(&exynos5420_clk_syscore_ops);
>         return;
> +err_clkget:
> +       kfree(exynos5x_clks);
> +err_clks:
> +       kfree(exynos5800_save);
> +       pr_warn("%s: failed to allocate suspend clocks, no sleep support!\n",
> +               __func__);
>  err_soc:
>         kfree(exynos5x_save);
>         pr_warn("%s: failed to allocate sleep save data, no sleep support!\n",
> -- 
> 2.1.4

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Michael Turquette]

Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
> +Tomeu who I forgot to add to the cc list.
> 
> Hello Mike,
> 
> Thanks a lot for your feedback.
> 
> On 03/31/2015 03:40 AM, Michael Turquette wrote:
> >> 
> >> I don't performance is a big issue here. I just thought that since the
> >> lookup table is already filled by the driver and the lookup function
> >> is one line, we could use that instead to get the performance benefit.
> >> 
> >> But I don't mind to drop this patch and use the generic lookup function
> >> from the CCF API if that is preferred.
> > 
> > Hello,
> > 
> > I am not a fan of __clk_lookup and I don't like to see it used more and
> > more outside of drivers/clk/clk.c. You mentioned that performance wasn't
> > really the problem here.  The real method for a driver to get a clock is
> > with clk_get(). Any reason to not use that?
> >
> 
> I can certainly use clk_get() but I thought that the clk consumer API was
> not supposed to be used from within clock drivers. That's why I mentioned
> __clk_lookup() as a possibility since that is part of the provider API.

I would like to remove __clk_lookup some day, so the fewer users now the
better. Additionally, now that we have unique struct clk pointers from
clk_get it makes a lot of sense for clk_register to stop returning
pointers to a struct clk. Hopefully we can get around to that soon.

These two points above are enough reason for the clock provider to use
clk_get.

> 
> Below is a RFC patch that uses clk_get() [0]. That needs another patch
> which was part of a previous RFC and adds an alias for the mdma0 clock:
> 
> https://lkml.org/lkml/2015/3/27/769
> 
> If you think that is the correct approach then I can post it as a patch.
> 
> It would be great if you can also provide some feedback about the other
> patch in the first RFC that instead of enabling and disabling the mdma0
> clock in driver, does it in the exynos5420 platform PM callbacks:
> 
> https://lkml.org/lkml/2015/3/27/770

This seems like a big hack to me.

> 
> I was asked to do it in the exynos5420 clk driver instead but maybe you
> have a different opinion on that.
> 
> Best regards,
> Javier
> 
> [0]:
> From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Mon, 30 Mar 2015 17:11:40 +0200
> Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
>  suspend
> 
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this clock needs to remain enabled in order to make
> the system resume from a system suspend state.
> 
> To make sure that the clock is enabled during suspend, enable it prior
> to entering a suspend state and disable it once the system has resumed.

I'd like to understand the issue a bit further. Isn't the correct
solution that the clk's prepare/unprepare and enable/disable callbacks
should support the CG_STATUS requirement?

Regards,
Mike

> 
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
> 
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 44 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 8b49e8b3b548..02029cf9fcb8 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -155,6 +155,7 @@ static enum exynos5x_soc exynos5x_soc;
>  #ifdef CONFIG_PM_SLEEP
>  static struct samsung_clk_reg_dump *exynos5x_save;
>  static struct samsung_clk_reg_dump *exynos5800_save;
> +static struct clk **exynos5x_clks;
>  
>  /*
>   * list of controller registers to be saved and restored during a
> @@ -275,8 +276,17 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
>  
> +/*
> + * list of clocks that have to be kept enabled during suspend/resume cycle.
> + */
> +static const char *exynos5x_clk_pm[] __initdata = {
> +       "mdma0",
> +};
> +
>  static int exynos5420_clk_suspend(void)
>  {
> +       int i;
> +
>         samsung_clk_save(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>  
> @@ -287,11 +297,19 @@ static int exynos5420_clk_suspend(void)
>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>  
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
> +               clk_prepare_enable(exynos5x_clks[i]);
> +
>         return 0;
>  }
>  
>  static void exynos5420_clk_resume(void)
>  {
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
> +               clk_disable_unprepare(exynos5x_clks[i]);
> +
>         samsung_clk_restore(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>  
> @@ -307,6 +325,9 @@ static struct syscore_ops exynos5420_clk_syscore_ops = {
>  
>  static void exynos5420_clk_sleep_init(void)
>  {
> +       int i;
> +       int clk_len = ARRAY_SIZE(exynos5x_clk_pm);
> +
>         exynos5x_save = samsung_clk_alloc_reg_dump(exynos5x_clk_regs,
>                                         ARRAY_SIZE(exynos5x_clk_regs));
>         if (!exynos5x_save) {
> @@ -323,8 +344,31 @@ static void exynos5420_clk_sleep_init(void)
>                         goto err_soc;
>         }
>  
> +       exynos5x_clks = kzalloc(sizeof(struct clk *) * clk_len, GFP_KERNEL);
> +       if (!exynos5x_clks)
> +               goto err_clks;
> +
> +       for (i = 0; i < clk_len; i++) {
> +               exynos5x_clks[i] = clk_get(NULL, exynos5x_clk_pm[i]);
> +               if (IS_ERR(exynos5x_clks[i])) {
> +                       pr_warn("Failed to get %s clk (%ld)\n",
> +                               exynos5x_clk_pm[i], PTR_ERR(exynos5x_clks[i]));
> +
> +                       while (i--)
> +                               clk_put(exynos5x_clks[i]);
> +
> +                       goto err_clkget;
> +               }
> +       }
> +
>         register_syscore_ops(&exynos5420_clk_syscore_ops);
>         return;
> +err_clkget:
> +       kfree(exynos5x_clks);
> +err_clks:
> +       kfree(exynos5800_save);
> +       pr_warn("%s: failed to allocate suspend clocks, no sleep support!\n",
> +               __func__);
>  err_soc:
>         kfree(exynos5x_save);
>         pr_warn("%s: failed to allocate sleep save data, no sleep support!\n",
> -- 
> 2.1.4

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Michael Turquette]

Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
> +Tomeu who I forgot to add to the cc list.
> 
> Hello Mike,
> 
> Thanks a lot for your feedback.
> 
> On 03/31/2015 03:40 AM, Michael Turquette wrote:
> >> 
> >> I don't performance is a big issue here. I just thought that since the
> >> lookup table is already filled by the driver and the lookup function
> >> is one line, we could use that instead to get the performance benefit.
> >> 
> >> But I don't mind to drop this patch and use the generic lookup function
> >> from the CCF API if that is preferred.
> > 
> > Hello,
> > 
> > I am not a fan of __clk_lookup and I don't like to see it used more and
> > more outside of drivers/clk/clk.c. You mentioned that performance wasn't
> > really the problem here.  The real method for a driver to get a clock is
> > with clk_get(). Any reason to not use that?
> >
> 
> I can certainly use clk_get() but I thought that the clk consumer API was
> not supposed to be used from within clock drivers. That's why I mentioned
> __clk_lookup() as a possibility since that is part of the provider API.

I would like to remove __clk_lookup some day, so the fewer users now the
better. Additionally, now that we have unique struct clk pointers from
clk_get it makes a lot of sense for clk_register to stop returning
pointers to a struct clk. Hopefully we can get around to that soon.

These two points above are enough reason for the clock provider to use
clk_get.

> 
> Below is a RFC patch that uses clk_get() [0]. That needs another patch
> which was part of a previous RFC and adds an alias for the mdma0 clock:
> 
> https://lkml.org/lkml/2015/3/27/769
> 
> If you think that is the correct approach then I can post it as a patch.
> 
> It would be great if you can also provide some feedback about the other
> patch in the first RFC that instead of enabling and disabling the mdma0
> clock in driver, does it in the exynos5420 platform PM callbacks:
> 
> https://lkml.org/lkml/2015/3/27/770

This seems like a big hack to me.

> 
> I was asked to do it in the exynos5420 clk driver instead but maybe you
> have a different opinion on that.
> 
> Best regards,
> Javier
> 
> [0]:
> From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Mon, 30 Mar 2015 17:11:40 +0200
> Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
>  suspend
> 
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this clock needs to remain enabled in order to make
> the system resume from a system suspend state.
> 
> To make sure that the clock is enabled during suspend, enable it prior
> to entering a suspend state and disable it once the system has resumed.

I'd like to understand the issue a bit further. Isn't the correct
solution that the clk's prepare/unprepare and enable/disable callbacks
should support the CG_STATUS requirement?

Regards,
Mike

> 
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
> 
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 44 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 8b49e8b3b548..02029cf9fcb8 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -155,6 +155,7 @@ static enum exynos5x_soc exynos5x_soc;
>  #ifdef CONFIG_PM_SLEEP
>  static struct samsung_clk_reg_dump *exynos5x_save;
>  static struct samsung_clk_reg_dump *exynos5800_save;
> +static struct clk **exynos5x_clks;
>  
>  /*
>   * list of controller registers to be saved and restored during a
> @@ -275,8 +276,17 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
>  
> +/*
> + * list of clocks that have to be kept enabled during suspend/resume cycle.
> + */
> +static const char *exynos5x_clk_pm[] __initdata = {
> +       "mdma0",
> +};
> +
>  static int exynos5420_clk_suspend(void)
>  {
> +       int i;
> +
>         samsung_clk_save(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>  
> @@ -287,11 +297,19 @@ static int exynos5420_clk_suspend(void)
>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>  
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
> +               clk_prepare_enable(exynos5x_clks[i]);
> +
>         return 0;
>  }
>  
>  static void exynos5420_clk_resume(void)
>  {
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_pm); i++)
> +               clk_disable_unprepare(exynos5x_clks[i]);
> +
>         samsung_clk_restore(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>  
> @@ -307,6 +325,9 @@ static struct syscore_ops exynos5420_clk_syscore_ops = {
>  
>  static void exynos5420_clk_sleep_init(void)
>  {
> +       int i;
> +       int clk_len = ARRAY_SIZE(exynos5x_clk_pm);
> +
>         exynos5x_save = samsung_clk_alloc_reg_dump(exynos5x_clk_regs,
>                                         ARRAY_SIZE(exynos5x_clk_regs));
>         if (!exynos5x_save) {
> @@ -323,8 +344,31 @@ static void exynos5420_clk_sleep_init(void)
>                         goto err_soc;
>         }
>  
> +       exynos5x_clks = kzalloc(sizeof(struct clk *) * clk_len, GFP_KERNEL);
> +       if (!exynos5x_clks)
> +               goto err_clks;
> +
> +       for (i = 0; i < clk_len; i++) {
> +               exynos5x_clks[i] = clk_get(NULL, exynos5x_clk_pm[i]);
> +               if (IS_ERR(exynos5x_clks[i])) {
> +                       pr_warn("Failed to get %s clk (%ld)\n",
> +                               exynos5x_clk_pm[i], PTR_ERR(exynos5x_clks[i]));
> +
> +                       while (i--)
> +                               clk_put(exynos5x_clks[i]);
> +
> +                       goto err_clkget;
> +               }
> +       }
> +
>         register_syscore_ops(&exynos5420_clk_syscore_ops);
>         return;
> +err_clkget:
> +       kfree(exynos5x_clks);
> +err_clks:
> +       kfree(exynos5800_save);
> +       pr_warn("%s: failed to allocate suspend clocks, no sleep support!\n",
> +               __func__);
>  err_soc:
>         kfree(exynos5x_save);
>         pr_warn("%s: failed to allocate sleep save data, no sleep support!\n",
> -- 
> 2.1.4

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

Hello Mike,

On 04/01/2015 03:29 AM, Michael Turquette wrote:
> Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
>> +Tomeu who I forgot to add to the cc list.
>> 
>> Hello Mike,
>> 
>> Thanks a lot for your feedback.
>> 
>> On 03/31/2015 03:40 AM, Michael Turquette wrote:
>> >> 
>> >> I don't performance is a big issue here. I just thought that since the
>> >> lookup table is already filled by the driver and the lookup function
>> >> is one line, we could use that instead to get the performance benefit.
>> >> 
>> >> But I don't mind to drop this patch and use the generic lookup function
>> >> from the CCF API if that is preferred.
>> > 
>> > Hello,
>> > 
>> > I am not a fan of __clk_lookup and I don't like to see it used more and
>> > more outside of drivers/clk/clk.c. You mentioned that performance wasn't
>> > really the problem here.  The real method for a driver to get a clock is
>> > with clk_get(). Any reason to not use that?
>> >
>> 
>> I can certainly use clk_get() but I thought that the clk consumer API was
>> not supposed to be used from within clock drivers. That's why I mentioned
>> __clk_lookup() as a possibility since that is part of the provider API.
> 
> I would like to remove __clk_lookup some day, so the fewer users now the
> better. Additionally, now that we have unique struct clk pointers from
> clk_get it makes a lot of sense for clk_register to stop returning
> pointers to a struct clk. Hopefully we can get around to that soon.
> 
> These two points above are enough reason for the clock provider to use
> clk_get.
>

Got it.
 
>> 
>> Below is a RFC patch that uses clk_get() [0]. That needs another patch
>> which was part of a previous RFC and adds an alias for the mdma0 clock:
>> 
>> https://lkml.org/lkml/2015/3/27/769
>> 
>> If you think that is the correct approach then I can post it as a patch.
>> 
>> It would be great if you can also provide some feedback about the other
>> patch in the first RFC that instead of enabling and disabling the mdma0
>> clock in driver, does it in the exynos5420 platform PM callbacks:
>> 
>> https://lkml.org/lkml/2015/3/27/770
> 
> This seems like a big hack to me.
> 

Ok, good to know. I just did because initially I thought that the clock
consumer API was not allowed to be used from within clock drivers.

>> 
>> I was asked to do it in the exynos5420 clk driver instead but maybe you
>> have a different opinion on that.
>> 
>> Best regards,
>> Javier
>> 
>> [0]:
>> From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Mon, 30 Mar 2015 17:11:40 +0200
>> Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
>>  suspend
>> 
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this clock needs to remain enabled in order to make
>> the system resume from a system suspend state.
>> 
>> To make sure that the clock is enabled during suspend, enable it prior
>> to entering a suspend state and disable it once the system has resumed.
> 
> I'd like to understand the issue a bit further. Isn't the correct
> solution that the clk's prepare/unprepare and enable/disable callbacks
> should support the CG_STATUS requirement?
> 

Agreed, I'll take a look to that.

> Regards,
> Mike
> 

Best regards,
Javier

[RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

Hello Mike,

On 04/01/2015 03:29 AM, Michael Turquette wrote:
> Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
>> +Tomeu who I forgot to add to the cc list.
>> 
>> Hello Mike,
>> 
>> Thanks a lot for your feedback.
>> 
>> On 03/31/2015 03:40 AM, Michael Turquette wrote:
>> >> 
>> >> I don't performance is a big issue here. I just thought that since the
>> >> lookup table is already filled by the driver and the lookup function
>> >> is one line, we could use that instead to get the performance benefit.
>> >> 
>> >> But I don't mind to drop this patch and use the generic lookup function
>> >> from the CCF API if that is preferred.
>> > 
>> > Hello,
>> > 
>> > I am not a fan of __clk_lookup and I don't like to see it used more and
>> > more outside of drivers/clk/clk.c. You mentioned that performance wasn't
>> > really the problem here.  The real method for a driver to get a clock is
>> > with clk_get(). Any reason to not use that?
>> >
>> 
>> I can certainly use clk_get() but I thought that the clk consumer API was
>> not supposed to be used from within clock drivers. That's why I mentioned
>> __clk_lookup() as a possibility since that is part of the provider API.
> 
> I would like to remove __clk_lookup some day, so the fewer users now the
> better. Additionally, now that we have unique struct clk pointers from
> clk_get it makes a lot of sense for clk_register to stop returning
> pointers to a struct clk. Hopefully we can get around to that soon.
> 
> These two points above are enough reason for the clock provider to use
> clk_get.
>

Got it.
 
>> 
>> Below is a RFC patch that uses clk_get() [0]. That needs another patch
>> which was part of a previous RFC and adds an alias for the mdma0 clock:
>> 
>> https://lkml.org/lkml/2015/3/27/769
>> 
>> If you think that is the correct approach then I can post it as a patch.
>> 
>> It would be great if you can also provide some feedback about the other
>> patch in the first RFC that instead of enabling and disabling the mdma0
>> clock in driver, does it in the exynos5420 platform PM callbacks:
>> 
>> https://lkml.org/lkml/2015/3/27/770
> 
> This seems like a big hack to me.
> 

Ok, good to know. I just did because initially I thought that the clock
consumer API was not allowed to be used from within clock drivers.

>> 
>> I was asked to do it in the exynos5420 clk driver instead but maybe you
>> have a different opinion on that.
>> 
>> Best regards,
>> Javier
>> 
>> [0]:
>> From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Mon, 30 Mar 2015 17:11:40 +0200
>> Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
>>  suspend
>> 
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this clock needs to remain enabled in order to make
>> the system resume from a system suspend state.
>> 
>> To make sure that the clock is enabled during suspend, enable it prior
>> to entering a suspend state and disable it once the system has resumed.
> 
> I'd like to understand the issue a bit further. Isn't the correct
> solution that the clk's prepare/unprepare and enable/disable callbacks
> should support the CG_STATUS requirement?
> 

Agreed, I'll take a look to that.

> Regards,
> Mike
> 

Best regards,
Javier

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

[Javier Martinez Canillas]

Hello Mike,

On 04/01/2015 03:29 AM, Michael Turquette wrote:
> Quoting Javier Martinez Canillas (2015-03-31 01:59:39)
>> +Tomeu who I forgot to add to the cc list.
>> 
>> Hello Mike,
>> 
>> Thanks a lot for your feedback.
>> 
>> On 03/31/2015 03:40 AM, Michael Turquette wrote:
>> >> 
>> >> I don't performance is a big issue here. I just thought that since the
>> >> lookup table is already filled by the driver and the lookup function
>> >> is one line, we could use that instead to get the performance benefit.
>> >> 
>> >> But I don't mind to drop this patch and use the generic lookup function
>> >> from the CCF API if that is preferred.
>> > 
>> > Hello,
>> > 
>> > I am not a fan of __clk_lookup and I don't like to see it used more and
>> > more outside of drivers/clk/clk.c. You mentioned that performance wasn't
>> > really the problem here.  The real method for a driver to get a clock is
>> > with clk_get(). Any reason to not use that?
>> >
>> 
>> I can certainly use clk_get() but I thought that the clk consumer API was
>> not supposed to be used from within clock drivers. That's why I mentioned
>> __clk_lookup() as a possibility since that is part of the provider API.
> 
> I would like to remove __clk_lookup some day, so the fewer users now the
> better. Additionally, now that we have unique struct clk pointers from
> clk_get it makes a lot of sense for clk_register to stop returning
> pointers to a struct clk. Hopefully we can get around to that soon.
> 
> These two points above are enough reason for the clock provider to use
> clk_get.
>

Got it.
 
>> 
>> Below is a RFC patch that uses clk_get() [0]. That needs another patch
>> which was part of a previous RFC and adds an alias for the mdma0 clock:
>> 
>> https://lkml.org/lkml/2015/3/27/769
>> 
>> If you think that is the correct approach then I can post it as a patch.
>> 
>> It would be great if you can also provide some feedback about the other
>> patch in the first RFC that instead of enabling and disabling the mdma0
>> clock in driver, does it in the exynos5420 platform PM callbacks:
>> 
>> https://lkml.org/lkml/2015/3/27/770
> 
> This seems like a big hack to me.
> 

Ok, good to know. I just did because initially I thought that the clock
consumer API was not allowed to be used from within clock drivers.

>> 
>> I was asked to do it in the exynos5420 clk driver instead but maybe you
>> have a different opinion on that.
>> 
>> Best regards,
>> Javier
>> 
>> [0]:
>> From c118df83da8cac65cc218ae9443622592222f5d0 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Mon, 30 Mar 2015 17:11:40 +0200
>> Subject: [RFC] clk: exynos5420: Make sure MDMA0 clock is enabled during
>>  suspend
>> 
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this clock needs to remain enabled in order to make
>> the system resume from a system suspend state.
>> 
>> To make sure that the clock is enabled during suspend, enable it prior
>> to entering a suspend state and disable it once the system has resumed.
> 
> I'd like to understand the issue a bit further. Isn't the correct
> solution that the clk's prepare/unprepare and enable/disable callbacks
> should support the CG_STATUS requirement?
> 

Agreed, I'll take a look to that.

> Regards,
> Mike
> 

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this clock needs to remain enabled in order to make
the system resume from a system suspend state.

To make sure that the clock is enabled during suspend, enable it prior
to entering a suspend state and disable it once the system has resumed.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..2d39b629144a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -151,6 +151,7 @@ enum exynos5x_plls {
 
 static void __iomem *reg_base;
 static enum exynos5x_soc exynos5x_soc;
+struct samsung_clk_provider *ctx;
 
 #ifdef CONFIG_PM_SLEEP
 static struct samsung_clk_reg_dump *exynos5x_save;
@@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
 
+/*
+ * list of clocks that have to be kept enabled during suspend/resume cycle.
+ */
+static unsigned int exynos5x_clk_suspend[] = {
+	CLK_MDMA0,
+};
+
 static int exynos5420_clk_suspend(void)
 {
+	int i;
+	struct clk *clk;
+
 	samsung_clk_save(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
 	samsung_clk_restore(reg_base, exynos5420_set_clksrc,
 				ARRAY_SIZE(exynos5420_set_clksrc));
 
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
+		clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
+		clk_prepare_enable(clk);
+	}
+
 	return 0;
 }
 
 static void exynos5420_clk_resume(void)
 {
+	int i;
+	struct clk *clk;
+
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
+		clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
+		clk_disable_unprepare(clk);
+	}
+
 	samsung_clk_restore(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -1255,8 +1279,6 @@ static const struct of_device_id ext_clk_match[] __initconst = {
 static void __init exynos5x_clk_init(struct device_node *np,
 		enum exynos5x_soc soc)
 {
-	struct samsung_clk_provider *ctx;
-
 	if (np) {
 		reg_base = of_iomap(np, 0);
 		if (!reg_base)
-- 
2.1.4

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this clock needs to remain enabled in order to make
the system resume from a system suspend state.

To make sure that the clock is enabled during suspend, enable it prior
to entering a suspend state and disable it once the system has resumed.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..2d39b629144a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -151,6 +151,7 @@ enum exynos5x_plls {
 
 static void __iomem *reg_base;
 static enum exynos5x_soc exynos5x_soc;
+struct samsung_clk_provider *ctx;
 
 #ifdef CONFIG_PM_SLEEP
 static struct samsung_clk_reg_dump *exynos5x_save;
@@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
 
+/*
+ * list of clocks that have to be kept enabled during suspend/resume cycle.
+ */
+static unsigned int exynos5x_clk_suspend[] = {
+	CLK_MDMA0,
+};
+
 static int exynos5420_clk_suspend(void)
 {
+	int i;
+	struct clk *clk;
+
 	samsung_clk_save(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
 	samsung_clk_restore(reg_base, exynos5420_set_clksrc,
 				ARRAY_SIZE(exynos5420_set_clksrc));
 
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
+		clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
+		clk_prepare_enable(clk);
+	}
+
 	return 0;
 }
 
 static void exynos5420_clk_resume(void)
 {
+	int i;
+	struct clk *clk;
+
+	for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
+		clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
+		clk_disable_unprepare(clk);
+	}
+
 	samsung_clk_restore(reg_base, exynos5x_save,
 				ARRAY_SIZE(exynos5x_clk_regs));
 
@@ -1255,8 +1279,6 @@ static const struct of_device_id ext_clk_match[] __initconst = {
 static void __init exynos5x_clk_init(struct device_node *np,
 		enum exynos5x_soc soc)
 {
-	struct samsung_clk_provider *ctx;
-
 	if (np) {
 		reg_base = of_iomap(np, 0);
 		if (!reg_base)
-- 
2.1.4

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

Hi Javier,

Please see my comments inline.

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
[snip]
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..2d39b629144a 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -151,6 +151,7 @@ enum exynos5x_plls {
>
>  static void __iomem *reg_base;
>  static enum exynos5x_soc exynos5x_soc;
> +struct samsung_clk_provider *ctx;

static

>
>  #ifdef CONFIG_PM_SLEEP
>  static struct samsung_clk_reg_dump *exynos5x_save;
> @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
>
> +/*
> + * list of clocks that have to be kept enabled during suspend/resume cycle.
> + */
> +static unsigned int exynos5x_clk_suspend[] = {

static const

> +       CLK_MDMA0,
> +};
> +
>  static int exynos5420_clk_suspend(void)
>  {
> +       int i;
> +       struct clk *clk;
> +
>         samsung_clk_save(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>
> @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
> +               clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);

If look-up speed is important here, maybe all the relevant clocks
could be looked up once at initialization time and just prepared and
enabled here?

Best regards,
Tomasz

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

Hi Javier,

Please see my comments inline.

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
[snip]
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..2d39b629144a 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -151,6 +151,7 @@ enum exynos5x_plls {
>
>  static void __iomem *reg_base;
>  static enum exynos5x_soc exynos5x_soc;
> +struct samsung_clk_provider *ctx;

static

>
>  #ifdef CONFIG_PM_SLEEP
>  static struct samsung_clk_reg_dump *exynos5x_save;
> @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
>
> +/*
> + * list of clocks that have to be kept enabled during suspend/resume cycle.
> + */
> +static unsigned int exynos5x_clk_suspend[] = {

static const

> +       CLK_MDMA0,
> +};
> +
>  static int exynos5420_clk_suspend(void)
>  {
> +       int i;
> +       struct clk *clk;
> +
>         samsung_clk_save(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>
> @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
> +               clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);

If look-up speed is important here, maybe all the relevant clocks
could be looked up once at initialization time and just prepared and
enabled here?

Best regards,
Tomasz

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

Hi Javier,

Please see my comments inline.

2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
[snip]
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..2d39b629144a 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -151,6 +151,7 @@ enum exynos5x_plls {
>
>  static void __iomem *reg_base;
>  static enum exynos5x_soc exynos5x_soc;
> +struct samsung_clk_provider *ctx;

static

>
>  #ifdef CONFIG_PM_SLEEP
>  static struct samsung_clk_reg_dump *exynos5x_save;
> @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
>
> +/*
> + * list of clocks that have to be kept enabled during suspend/resume cycle.
> + */
> +static unsigned int exynos5x_clk_suspend[] = {

static const

> +       CLK_MDMA0,
> +};
> +
>  static int exynos5420_clk_suspend(void)
>  {
> +       int i;
> +       struct clk *clk;
> +
>         samsung_clk_save(reg_base, exynos5x_save,
>                                 ARRAY_SIZE(exynos5x_clk_regs));
>
> @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>
> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
> +               clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);

If look-up speed is important here, maybe all the relevant clocks
could be looked up once at initialization time and just prepared and
enabled here?

Best regards,
Tomasz

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

Thanks a lot for your feedback.

On 03/30/2015 06:07 PM, Tomasz Figa wrote:
> Hi Javier,
> 
> Please see my comments inline.
> 
> 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
> [snip]
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..2d39b629144a 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -151,6 +151,7 @@ enum exynos5x_plls {
>>
>>  static void __iomem *reg_base;
>>  static enum exynos5x_soc exynos5x_soc;
>> +struct samsung_clk_provider *ctx;
> 
> static
>

Ok.
 
>>
>>  #ifdef CONFIG_PM_SLEEP
>>  static struct samsung_clk_reg_dump *exynos5x_save;
>> @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>  };
>>
>> +/*
>> + * list of clocks that have to be kept enabled during suspend/resume cycle.
>> + */
>> +static unsigned int exynos5x_clk_suspend[] = {
> 
> static const
>

Ok.
 
>> +       CLK_MDMA0,
>> +};
>> +
>>  static int exynos5420_clk_suspend(void)
>>  {
>> +       int i;
>> +       struct clk *clk;
>> +
>>         samsung_clk_save(reg_base, exynos5x_save,
>>                                 ARRAY_SIZE(exynos5x_clk_regs));
>>
>> @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
>>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>>
>> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
>> +               clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
> 
> If look-up speed is important here, maybe all the relevant clocks
> could be looked up once at initialization time and just prepared and
> enabled here?
>

Yes, I'll do that indeed.

In fact, I was wondering if we should let this clock be disabled at
all. I noticed that the rockchip clk drivers do something similar
and prepare / enable a list of clocks at init time [0,1].

Unfortunately I don't fully understand why this clock needs to be
enabled. It would be good if someone at Samsung can explain in
more detail what the real problem really is.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/drivers/clk/rockchip/clk.c#L320
[1]: http://lxr.free-electrons.com/source/drivers/clk/rockchip/clk-rk3288.c#L874

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

Thanks a lot for your feedback.

On 03/30/2015 06:07 PM, Tomasz Figa wrote:
> Hi Javier,
> 
> Please see my comments inline.
> 
> 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
> [snip]
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..2d39b629144a 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -151,6 +151,7 @@ enum exynos5x_plls {
>>
>>  static void __iomem *reg_base;
>>  static enum exynos5x_soc exynos5x_soc;
>> +struct samsung_clk_provider *ctx;
> 
> static
>

Ok.
 
>>
>>  #ifdef CONFIG_PM_SLEEP
>>  static struct samsung_clk_reg_dump *exynos5x_save;
>> @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>  };
>>
>> +/*
>> + * list of clocks that have to be kept enabled during suspend/resume cycle.
>> + */
>> +static unsigned int exynos5x_clk_suspend[] = {
> 
> static const
>

Ok.
 
>> +       CLK_MDMA0,
>> +};
>> +
>>  static int exynos5420_clk_suspend(void)
>>  {
>> +       int i;
>> +       struct clk *clk;
>> +
>>         samsung_clk_save(reg_base, exynos5x_save,
>>                                 ARRAY_SIZE(exynos5x_clk_regs));
>>
>> @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
>>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>>
>> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
>> +               clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
> 
> If look-up speed is important here, maybe all the relevant clocks
> could be looked up once at initialization time and just prepared and
> enabled here?
>

Yes, I'll do that indeed.

In fact, I was wondering if we should let this clock be disabled at
all. I noticed that the rockchip clk drivers do something similar
and prepare / enable a list of clocks at init time [0,1].

Unfortunately I don't fully understand why this clock needs to be
enabled. It would be good if someone at Samsung can explain in
more detail what the real problem really is.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/drivers/clk/rockchip/clk.c#L320
[1]: http://lxr.free-electrons.com/source/drivers/clk/rockchip/clk-rk3288.c#L874

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

Thanks a lot for your feedback.

On 03/30/2015 06:07 PM, Tomasz Figa wrote:
> Hi Javier,
> 
> Please see my comments inline.
> 
> 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
> [snip]
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..2d39b629144a 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -151,6 +151,7 @@ enum exynos5x_plls {
>>
>>  static void __iomem *reg_base;
>>  static enum exynos5x_soc exynos5x_soc;
>> +struct samsung_clk_provider *ctx;
> 
> static
>

Ok.
 
>>
>>  #ifdef CONFIG_PM_SLEEP
>>  static struct samsung_clk_reg_dump *exynos5x_save;
>> @@ -275,8 +276,18 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>  };
>>
>> +/*
>> + * list of clocks that have to be kept enabled during suspend/resume cycle.
>> + */
>> +static unsigned int exynos5x_clk_suspend[] = {
> 
> static const
>

Ok.
 
>> +       CLK_MDMA0,
>> +};
>> +
>>  static int exynos5420_clk_suspend(void)
>>  {
>> +       int i;
>> +       struct clk *clk;
>> +
>>         samsung_clk_save(reg_base, exynos5x_save,
>>                                 ARRAY_SIZE(exynos5x_clk_regs));
>>
>> @@ -287,11 +298,24 @@ static int exynos5420_clk_suspend(void)
>>         samsung_clk_restore(reg_base, exynos5420_set_clksrc,
>>                                 ARRAY_SIZE(exynos5420_set_clksrc));
>>
>> +       for (i = 0; i < ARRAY_SIZE(exynos5x_clk_suspend); i++) {
>> +               clk = samsung_clk_lookup(ctx, exynos5x_clk_suspend[i]);
> 
> If look-up speed is important here, maybe all the relevant clocks
> could be looked up once at initialization time and just prepared and
> enabled here?
>

Yes, I'll do that indeed.

In fact, I was wondering if we should let this clock be disabled at
all. I noticed that the rockchip clk drivers do something similar
and prepare / enable a list of clocks at init time [0,1].

Unfortunately I don't fully understand why this clock needs to be
enabled. It would be good if someone at Samsung can explain in
more detail what the real problem really is.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

[0]: http://lxr.free-electrons.com/source/drivers/clk/rockchip/clk.c#L320
[1]: http://lxr.free-electrons.com/source/drivers/clk/rockchip/clk-rk3288.c#L874

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
> javier.martinez@collabora.co.uk> wrote:
>> On 03/30/2015 06:07 PM, Tomasz Figa wrote:
>> >
>> > If look-up speed is important here, maybe all the relevant clocks
>> > could be looked up once at initialization time and just prepared and
>> > enabled here?
>> >
>>
>> Yes, I'll do that indeed.
>>
>> In fact, I was wondering if we should let this clock be disabled at
>> all. I noticed that the rockchip clk drivers do something similar
>> and prepare / enable a list of clocks at init time [0,1].
>>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in
>> more detail what the real problem really is.
>>
> 
> I had a look at this some more today. The problem actually occurs when the
> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
> issue.
> From the User Manual, it appears that aclk266_g2d should be gated only when
> certain bits in the clock gating status register are 0. I cannot say for
> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
> being 0 could be a cause of the suspend failure.
> 

Thanks a lot for the explanation. I see the NOTE at the bottom of section
7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
to the commit message when posting as a proper patch instead of a RFC.

I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
instead of "mdm0" also makes the system to resume correctly from suspend
so I'll change that on the patch as well.

I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
to disable the clocks on init but doesn't prevent the clocks to be disabled
if all the clock childs are gated so the parent is gated as well.

> As the CG_STATUS bits are not being checked anywhere in the kernel I think
> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with

For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
clocks (and others) that should only be gated when CG_STATUS is 0 can be
added. My patch iterates over a list of clocks to be kept during suspend even
when there is only one for now so adding more later if needed will be trivial.

Or do you think that I should add all the GATE_BUS_TOP clocks now?

> the suspend specific approach you have posted.
>

Great, I'll wait a couple of days to see if others have more comments about
the last RFC I shared [0] and I'll post it as a proper patch.

> Regards,
> Abhilash
> 

Thanks a lot for all your help and best regards,
Javier

[0]: https://lkml.org/lkml/2015/3/31/152

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
> javier.martinez at collabora.co.uk> wrote:
>> On 03/30/2015 06:07 PM, Tomasz Figa wrote:
>> >
>> > If look-up speed is important here, maybe all the relevant clocks
>> > could be looked up once at initialization time and just prepared and
>> > enabled here?
>> >
>>
>> Yes, I'll do that indeed.
>>
>> In fact, I was wondering if we should let this clock be disabled at
>> all. I noticed that the rockchip clk drivers do something similar
>> and prepare / enable a list of clocks at init time [0,1].
>>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in
>> more detail what the real problem really is.
>>
> 
> I had a look at this some more today. The problem actually occurs when the
> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
> issue.
> From the User Manual, it appears that aclk266_g2d should be gated only when
> certain bits in the clock gating status register are 0. I cannot say for
> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
> being 0 could be a cause of the suspend failure.
> 

Thanks a lot for the explanation. I see the NOTE at the bottom of section
7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
to the commit message when posting as a proper patch instead of a RFC.

I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
instead of "mdm0" also makes the system to resume correctly from suspend
so I'll change that on the patch as well.

I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
to disable the clocks on init but doesn't prevent the clocks to be disabled
if all the clock childs are gated so the parent is gated as well.

> As the CG_STATUS bits are not being checked anywhere in the kernel I think
> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with

For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
clocks (and others) that should only be gated when CG_STATUS is 0 can be
added. My patch iterates over a list of clocks to be kept during suspend even
when there is only one for now so adding more later if needed will be trivial.

Or do you think that I should add all the GATE_BUS_TOP clocks now?

> the suspend specific approach you have posted.
>

Great, I'll wait a couple of days to see if others have more comments about
the last RFC I shared [0] and I'll post it as a proper patch.

> Regards,
> Abhilash
> 

Thanks a lot for all your help and best regards,
Javier

[0]: https://lkml.org/lkml/2015/3/31/152

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
> javier.martinez@collabora.co.uk> wrote:
>> On 03/30/2015 06:07 PM, Tomasz Figa wrote:
>> >
>> > If look-up speed is important here, maybe all the relevant clocks
>> > could be looked up once at initialization time and just prepared and
>> > enabled here?
>> >
>>
>> Yes, I'll do that indeed.
>>
>> In fact, I was wondering if we should let this clock be disabled at
>> all. I noticed that the rockchip clk drivers do something similar
>> and prepare / enable a list of clocks at init time [0,1].
>>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in
>> more detail what the real problem really is.
>>
> 
> I had a look at this some more today. The problem actually occurs when the
> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
> issue.
> From the User Manual, it appears that aclk266_g2d should be gated only when
> certain bits in the clock gating status register are 0. I cannot say for
> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
> being 0 could be a cause of the suspend failure.
> 

Thanks a lot for the explanation. I see the NOTE at the bottom of section
7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
to the commit message when posting as a proper patch instead of a RFC.

I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
instead of "mdm0" also makes the system to resume correctly from suspend
so I'll change that on the patch as well.

I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
to disable the clocks on init but doesn't prevent the clocks to be disabled
if all the clock childs are gated so the parent is gated as well.

> As the CG_STATUS bits are not being checked anywhere in the kernel I think
> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with

For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
clocks (and others) that should only be gated when CG_STATUS is 0 can be
added. My patch iterates over a list of clocks to be kept during suspend even
when there is only one for now so adding more later if needed will be trivial.

Or do you think that I should add all the GATE_BUS_TOP clocks now?

> the suspend specific approach you have posted.
>

Great, I'll wait a couple of days to see if others have more comments about
the last RFC I shared [0] and I'll post it as a proper patch.

> Regards,
> Abhilash
> 

Thanks a lot for all your help and best regards,
Javier

[0]: https://lkml.org/lkml/2015/3/31/152

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Sylwester Nawrocki]

Hello,

On 31/03/15 22:00, Javier Martinez Canillas wrote:
> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>> javier.martinez@collabora.co.uk> wrote:

>>> Unfortunately I don't fully understand why this clock needs to be
>>> enabled. It would be good if someone at Samsung can explain in
>>> more detail what the real problem really is.
>>>
>>
>> I had a look at this some more today. The problem actually occurs when the
>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>> issue.
>> From the User Manual, it appears that aclk266_g2d should be gated only when
>> certain bits in the clock gating status register are 0. I cannot say for
>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>> being 0 could be a cause of the suspend failure.
>>
> 
> Thanks a lot for the explanation. I see the NOTE at the bottom of section
> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
> to the commit message when posting as a proper patch instead of a RFC.
> 
> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
> instead of "mdm0" also makes the system to resume correctly from suspend
> so I'll change that on the patch as well.
> 
> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
> to disable the clocks on init but doesn't prevent the clocks to be disabled
> if all the clock childs are gated so the parent is gated as well.
> 
>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
> 
> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
> clocks (and others) that should only be gated when CG_STATUS is 0 can be
> added. My patch iterates over a list of clocks to be kept during suspend even
> when there is only one for now so adding more later if needed will be trivial.

It's not clear what subsystems affect state of the CG_STATUSx registers, it
would be good if we could get more information on that. They are in the PMU
block and are related to LPI (Low Power Interface handshaking), but what
subsystems/peripheral blocks exactly are associated with them it's not clear
from the documentation.

I think it's essential to understand what triggers changes in CG_STATUSx
registers, before we start checking their value in the clock driver.

Also it might be that there are indeed some clocks which must stay enabled
over suspend/resume cycle, then the approach with enabling/disabling clocks
in the clock driver might not be such a hack as it looks at first sight.

> Or do you think that I should add all the GATE_BUS_TOP clocks now?

No, please don't do that. That includes many important clocks and we should
be certain what we are doing. I don't think it is expected to touch those
clocks in that way, it would likely cause more issues.


-- 
Thanks
Sylwester

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Sylwester Nawrocki]

Hello,

On 31/03/15 22:00, Javier Martinez Canillas wrote:
> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>> javier.martinez at collabora.co.uk> wrote:

>>> Unfortunately I don't fully understand why this clock needs to be
>>> enabled. It would be good if someone at Samsung can explain in
>>> more detail what the real problem really is.
>>>
>>
>> I had a look at this some more today. The problem actually occurs when the
>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>> issue.
>> From the User Manual, it appears that aclk266_g2d should be gated only when
>> certain bits in the clock gating status register are 0. I cannot say for
>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>> being 0 could be a cause of the suspend failure.
>>
> 
> Thanks a lot for the explanation. I see the NOTE at the bottom of section
> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
> to the commit message when posting as a proper patch instead of a RFC.
> 
> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
> instead of "mdm0" also makes the system to resume correctly from suspend
> so I'll change that on the patch as well.
> 
> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
> to disable the clocks on init but doesn't prevent the clocks to be disabled
> if all the clock childs are gated so the parent is gated as well.
> 
>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
> 
> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
> clocks (and others) that should only be gated when CG_STATUS is 0 can be
> added. My patch iterates over a list of clocks to be kept during suspend even
> when there is only one for now so adding more later if needed will be trivial.

It's not clear what subsystems affect state of the CG_STATUSx registers, it
would be good if we could get more information on that. They are in the PMU
block and are related to LPI (Low Power Interface handshaking), but what
subsystems/peripheral blocks exactly are associated with them it's not clear
from the documentation.

I think it's essential to understand what triggers changes in CG_STATUSx
registers, before we start checking their value in the clock driver.

Also it might be that there are indeed some clocks which must stay enabled
over suspend/resume cycle, then the approach with enabling/disabling clocks
in the clock driver might not be such a hack as it looks at first sight.

> Or do you think that I should add all the GATE_BUS_TOP clocks now?

No, please don't do that. That includes many important clocks and we should
be certain what we are doing. I don't think it is expected to touch those
clocks in that way, it would likely cause more issues.


-- 
Thanks
Sylwester

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Sylwester Nawrocki]

Hello,

On 31/03/15 22:00, Javier Martinez Canillas wrote:
> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>> javier.martinez@collabora.co.uk> wrote:

>>> Unfortunately I don't fully understand why this clock needs to be
>>> enabled. It would be good if someone at Samsung can explain in
>>> more detail what the real problem really is.
>>>
>>
>> I had a look at this some more today. The problem actually occurs when the
>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>> issue.
>> From the User Manual, it appears that aclk266_g2d should be gated only when
>> certain bits in the clock gating status register are 0. I cannot say for
>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>> being 0 could be a cause of the suspend failure.
>>
> 
> Thanks a lot for the explanation. I see the NOTE at the bottom of section
> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
> to the commit message when posting as a proper patch instead of a RFC.
> 
> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
> instead of "mdm0" also makes the system to resume correctly from suspend
> so I'll change that on the patch as well.
> 
> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
> to disable the clocks on init but doesn't prevent the clocks to be disabled
> if all the clock childs are gated so the parent is gated as well.
> 
>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
> 
> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
> clocks (and others) that should only be gated when CG_STATUS is 0 can be
> added. My patch iterates over a list of clocks to be kept during suspend even
> when there is only one for now so adding more later if needed will be trivial.

It's not clear what subsystems affect state of the CG_STATUSx registers, it
would be good if we could get more information on that. They are in the PMU
block and are related to LPI (Low Power Interface handshaking), but what
subsystems/peripheral blocks exactly are associated with them it's not clear
from the documentation.

I think it's essential to understand what triggers changes in CG_STATUSx
registers, before we start checking their value in the clock driver.

Also it might be that there are indeed some clocks which must stay enabled
over suspend/resume cycle, then the approach with enabling/disabling clocks
in the clock driver might not be such a hack as it looks at first sight.

> Or do you think that I should add all the GATE_BUS_TOP clocks now?

No, please don't do that. That includes many important clocks and we should
be certain what we are doing. I don't think it is expected to touch those
clocks in that way, it would likely cause more issues.


-- 
Thanks
Sylwester

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
> 
> On 31/03/15 22:00, Javier Martinez Canillas wrote:
>> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>>> javier.martinez@collabora.co.uk> wrote:
> 
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in
>>>> more detail what the real problem really is.
>>>>
>>>
>>> I had a look at this some more today. The problem actually occurs when the
>>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>>> issue.
>>> From the User Manual, it appears that aclk266_g2d should be gated only when
>>> certain bits in the clock gating status register are 0. I cannot say for
>>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>>> being 0 could be a cause of the suspend failure.
>>>
>> 
>> Thanks a lot for the explanation. I see the NOTE at the bottom of section
>> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
>> to the commit message when posting as a proper patch instead of a RFC.
>> 
>> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
>> instead of "mdm0" also makes the system to resume correctly from suspend
>> so I'll change that on the patch as well.
>> 
>> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
>> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
>> to disable the clocks on init but doesn't prevent the clocks to be disabled
>> if all the clock childs are gated so the parent is gated as well.
>> 
>>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
>> 
>> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
>> clocks (and others) that should only be gated when CG_STATUS is 0 can be
>> added. My patch iterates over a list of clocks to be kept during suspend even
>> when there is only one for now so adding more later if needed will be trivial.
> 
> It's not clear what subsystems affect state of the CG_STATUSx registers, it
> would be good if we could get more information on that. They are in the PMU
> block and are related to LPI (Low Power Interface handshaking), but what
> subsystems/peripheral blocks exactly are associated with them it's not clear
> from the documentation.
> 

Yes, I've been looking at the docs again and found out a couple of things:

* Each GC_STATUSx register bit is associated with an IP hw block
* Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
  and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
part of the PMU register address space.

In the particular case of aclk266_g2d, the doc says that the clock can only
be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

> I think it's essential to understand what triggers changes in CG_STATUSx
> registers, before we start checking their value in the clock driver.
>

Indeed, we should really understand what the status on these registers
means. Also is not clear from the docs how much time should be waited,
how long until giving up, etc.

> Also it might be that there are indeed some clocks which must stay enabled
> over suspend/resume cycle, then the approach with enabling/disabling clocks
> in the clock driver might not be such a hack as it looks at first sight.
>

Having a clock driver to both a provider and consumer feels hacky to me as
well but I didn't find a better way to solve this issue... another option
is to have this workaround to solve the S2R issue while we figure out what
the the state in the CG_STATUSx really mean.

>> Or do you think that I should add all the GATE_BUS_TOP clocks now?
> 
> No, please don't do that. That includes many important clocks and we should
> be certain what we are doing. I don't think it is expected to touch those
> clocks in that way, it would likely cause more issues.
> 
> 

Perfect, I just asked since it was not clear to me from Abhilash comment.
But I also agree to only focus on the clock that is causing issues now.

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
> 
> On 31/03/15 22:00, Javier Martinez Canillas wrote:
>> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>>> javier.martinez at collabora.co.uk> wrote:
> 
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in
>>>> more detail what the real problem really is.
>>>>
>>>
>>> I had a look at this some more today. The problem actually occurs when the
>>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>>> issue.
>>> From the User Manual, it appears that aclk266_g2d should be gated only when
>>> certain bits in the clock gating status register are 0. I cannot say for
>>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>>> being 0 could be a cause of the suspend failure.
>>>
>> 
>> Thanks a lot for the explanation. I see the NOTE at the bottom of section
>> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
>> to the commit message when posting as a proper patch instead of a RFC.
>> 
>> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
>> instead of "mdm0" also makes the system to resume correctly from suspend
>> so I'll change that on the patch as well.
>> 
>> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
>> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
>> to disable the clocks on init but doesn't prevent the clocks to be disabled
>> if all the clock childs are gated so the parent is gated as well.
>> 
>>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
>> 
>> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
>> clocks (and others) that should only be gated when CG_STATUS is 0 can be
>> added. My patch iterates over a list of clocks to be kept during suspend even
>> when there is only one for now so adding more later if needed will be trivial.
> 
> It's not clear what subsystems affect state of the CG_STATUSx registers, it
> would be good if we could get more information on that. They are in the PMU
> block and are related to LPI (Low Power Interface handshaking), but what
> subsystems/peripheral blocks exactly are associated with them it's not clear
> from the documentation.
> 

Yes, I've been looking at the docs again and found out a couple of things:

* Each GC_STATUSx register bit is associated with an IP hw block
* Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
  and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
part of the PMU register address space.

In the particular case of aclk266_g2d, the doc says that the clock can only
be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

> I think it's essential to understand what triggers changes in CG_STATUSx
> registers, before we start checking their value in the clock driver.
>

Indeed, we should really understand what the status on these registers
means. Also is not clear from the docs how much time should be waited,
how long until giving up, etc.

> Also it might be that there are indeed some clocks which must stay enabled
> over suspend/resume cycle, then the approach with enabling/disabling clocks
> in the clock driver might not be such a hack as it looks at first sight.
>

Having a clock driver to both a provider and consumer feels hacky to me as
well but I didn't find a better way to solve this issue... another option
is to have this workaround to solve the S2R issue while we figure out what
the the state in the CG_STATUSx really mean.

>> Or do you think that I should add all the GATE_BUS_TOP clocks now?
> 
> No, please don't do that. That includes many important clocks and we should
> be certain what we are doing. I don't think it is expected to touch those
> clocks in that way, it would likely cause more issues.
> 
> 

Perfect, I just asked since it was not clear to me from Abhilash comment.
But I also agree to only focus on the clock that is causing issues now.

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
> 
> On 31/03/15 22:00, Javier Martinez Canillas wrote:
>> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>>> javier.martinez@collabora.co.uk> wrote:
> 
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in
>>>> more detail what the real problem really is.
>>>>
>>>
>>> I had a look at this some more today. The problem actually occurs when the
>>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>>> issue.
>>> From the User Manual, it appears that aclk266_g2d should be gated only when
>>> certain bits in the clock gating status register are 0. I cannot say for
>>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>>> being 0 could be a cause of the suspend failure.
>>>
>> 
>> Thanks a lot for the explanation. I see the NOTE at the bottom of section
>> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
>> to the commit message when posting as a proper patch instead of a RFC.
>> 
>> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
>> instead of "mdm0" also makes the system to resume correctly from suspend
>> so I'll change that on the patch as well.
>> 
>> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
>> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
>> to disable the clocks on init but doesn't prevent the clocks to be disabled
>> if all the clock childs are gated so the parent is gated as well.
>> 
>>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
>> 
>> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
>> clocks (and others) that should only be gated when CG_STATUS is 0 can be
>> added. My patch iterates over a list of clocks to be kept during suspend even
>> when there is only one for now so adding more later if needed will be trivial.
> 
> It's not clear what subsystems affect state of the CG_STATUSx registers, it
> would be good if we could get more information on that. They are in the PMU
> block and are related to LPI (Low Power Interface handshaking), but what
> subsystems/peripheral blocks exactly are associated with them it's not clear
> from the documentation.
> 

Yes, I've been looking at the docs again and found out a couple of things:

* Each GC_STATUSx register bit is associated with an IP hw block
* Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
  and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
part of the PMU register address space.

In the particular case of aclk266_g2d, the doc says that the clock can only
be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

> I think it's essential to understand what triggers changes in CG_STATUSx
> registers, before we start checking their value in the clock driver.
>

Indeed, we should really understand what the status on these registers
means. Also is not clear from the docs how much time should be waited,
how long until giving up, etc.

> Also it might be that there are indeed some clocks which must stay enabled
> over suspend/resume cycle, then the approach with enabling/disabling clocks
> in the clock driver might not be such a hack as it looks at first sight.
>

Having a clock driver to both a provider and consumer feels hacky to me as
well but I didn't find a better way to solve this issue... another option
is to have this workaround to solve the S2R issue while we figure out what
the the state in the CG_STATUSx really mean.

>> Or do you think that I should add all the GATE_BUS_TOP clocks now?
> 
> No, please don't do that. That includes many important clocks and we should
> be certain what we are doing. I don't think it is expected to touch those
> clocks in that way, it would likely cause more issues.
> 
> 

Perfect, I just asked since it was not clear to me from Abhilash comment.
But I also agree to only focus on the clock that is causing issues now.

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Sylwester Nawrocki]

Hello Javier,

On 01/04/15 13:44, Javier Martinez Canillas wrote:
> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>> On 31/03/15 22:00, Javier Martinez Canillas wrote:
>>> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>>>> javier.martinez@collabora.co.uk> wrote:
>>>> I had a look at this some more today. The problem actually occurs when the
>>>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>>>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>>>> issue.
>>>> From the User Manual, it appears that aclk266_g2d should be gated only when
>>>> certain bits in the clock gating status register are 0. I cannot say for
>>>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>>>> being 0 could be a cause of the suspend failure.
>>>>
>>>
>>> Thanks a lot for the explanation. I see the NOTE at the bottom of section
>>> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
>>> to the commit message when posting as a proper patch instead of a RFC.
>>>
>>> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
>>> instead of "mdm0" also makes the system to resume correctly from suspend
>>> so I'll change that on the patch as well.
>>>
>>> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
>>> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
>>> to disable the clocks on init but doesn't prevent the clocks to be disabled
>>> if all the clock childs are gated so the parent is gated as well.
>>>
>>>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>>>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
>>>
>>> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
>>> clocks (and others) that should only be gated when CG_STATUS is 0 can be
>>> added. My patch iterates over a list of clocks to be kept during suspend even
>>> when there is only one for now so adding more later if needed will be trivial.
>>
>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>> would be good if we could get more information on that. They are in the PMU
>> block and are related to LPI (Low Power Interface handshaking), but what
>> subsystems/peripheral blocks exactly are associated with them it's not clear
>> from the documentation.
> 
> Yes, I've been looking at the docs again and found out a couple of things:
> 
> * Each GC_STATUSx register bit is associated with an IP hw block
> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
documentation I have. I guess you've got something newer than REV0.00?

> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
> part of the PMU register address space.
> 
> In the particular case of aclk266_g2d, the doc says that the clock can only
> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
the camera subsystem. Such a dependency would be rather surprising.

>> I think it's essential to understand what triggers changes in CG_STATUSx
>> registers, before we start checking their value in the clock driver.
>>
> 
> Indeed, we should really understand what the status on these registers
> means. Also is not clear from the docs how much time should be waited,
> how long until giving up, etc.

Exactly, I checked some kernels from http://opensource.samsung.com
(e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
related to these registers yet, except the address macro definitions
and debug traces in the power domains driver.

>> Also it might be that there are indeed some clocks which must stay enabled
>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>> in the clock driver might not be such a hack as it looks at first sight.
>>
> 
> Having a clock driver to both a provider and consumer feels hacky to me as
> well but I didn't find a better way to solve this issue... another option
> is to have this workaround to solve the S2R issue while we figure out what
> the the state in the CG_STATUSx really mean.

Let's try to diagnose the issue best we can, then we would choose the most
accurate bug fix.

-- 
Regards,
Sylwester

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Sylwester Nawrocki]

Hello Javier,

On 01/04/15 13:44, Javier Martinez Canillas wrote:
> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>> On 31/03/15 22:00, Javier Martinez Canillas wrote:
>>> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>>>> javier.martinez at collabora.co.uk> wrote:
>>>> I had a look at this some more today. The problem actually occurs when the
>>>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>>>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>>>> issue.
>>>> From the User Manual, it appears that aclk266_g2d should be gated only when
>>>> certain bits in the clock gating status register are 0. I cannot say for
>>>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>>>> being 0 could be a cause of the suspend failure.
>>>>
>>>
>>> Thanks a lot for the explanation. I see the NOTE at the bottom of section
>>> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
>>> to the commit message when posting as a proper patch instead of a RFC.
>>>
>>> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
>>> instead of "mdm0" also makes the system to resume correctly from suspend
>>> so I'll change that on the patch as well.
>>>
>>> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
>>> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
>>> to disable the clocks on init but doesn't prevent the clocks to be disabled
>>> if all the clock childs are gated so the parent is gated as well.
>>>
>>>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>>>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
>>>
>>> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
>>> clocks (and others) that should only be gated when CG_STATUS is 0 can be
>>> added. My patch iterates over a list of clocks to be kept during suspend even
>>> when there is only one for now so adding more later if needed will be trivial.
>>
>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>> would be good if we could get more information on that. They are in the PMU
>> block and are related to LPI (Low Power Interface handshaking), but what
>> subsystems/peripheral blocks exactly are associated with them it's not clear
>> from the documentation.
> 
> Yes, I've been looking at the docs again and found out a couple of things:
> 
> * Each GC_STATUSx register bit is associated with an IP hw block
> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
documentation I have. I guess you've got something newer than REV0.00?

> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
> part of the PMU register address space.
> 
> In the particular case of aclk266_g2d, the doc says that the clock can only
> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
the camera subsystem. Such a dependency would be rather surprising.

>> I think it's essential to understand what triggers changes in CG_STATUSx
>> registers, before we start checking their value in the clock driver.
>>
> 
> Indeed, we should really understand what the status on these registers
> means. Also is not clear from the docs how much time should be waited,
> how long until giving up, etc.

Exactly, I checked some kernels from http://opensource.samsung.com
(e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
related to these registers yet, except the address macro definitions
and debug traces in the power domains driver.

>> Also it might be that there are indeed some clocks which must stay enabled
>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>> in the clock driver might not be such a hack as it looks at first sight.
>>
> 
> Having a clock driver to both a provider and consumer feels hacky to me as
> well but I didn't find a better way to solve this issue... another option
> is to have this workaround to solve the S2R issue while we figure out what
> the the state in the CG_STATUSx really mean.

Let's try to diagnose the issue best we can, then we would choose the most
accurate bug fix.

-- 
Regards,
Sylwester

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Sylwester Nawrocki]

Hello Javier,

On 01/04/15 13:44, Javier Martinez Canillas wrote:
> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>> On 31/03/15 22:00, Javier Martinez Canillas wrote:
>>> On 03/31/2015 04:38 PM, Abhilash Kesavan wrote:
>>>> javier.martinez@collabora.co.uk> wrote:
>>>> I had a look at this some more today. The problem actually occurs when the
>>>> mdma0 clock's parent - aclk266_g2d gets disabled. The run-time pm support
>>>> in the dma driver disables mdma0 and in turn aclk266_g2d which causes the
>>>> issue.
>>>> From the User Manual, it appears that aclk266_g2d should be gated only when
>>>> certain bits in the clock gating status register are 0. I cannot say for
>>>> certain, but our gating the aclk266_g2d clock without the CG_STATUS bits
>>>> being 0 could be a cause of the suspend failure.
>>>>
>>>
>>> Thanks a lot for the explanation. I see the NOTE at the bottom of section
>>> 7.9.1.159 CLK_GATE_BUS_TOP that mentions that. I'll add this information
>>> to the commit message when posting as a proper patch instead of a RFC.
>>>
>>> I confirmed that changing the patch to prevent "aclk266_g2d" to be gated
>>> instead of "mdm0" also makes the system to resume correctly from suspend
>>> so I'll change that on the patch as well.
>>>
>>> I see that many of the Exynos5420 clocks (including "aclk266_g2d") use the
>>> CLK_IGNORE_UNUSED flag but AFAIU it only prevents the common clock framework
>>> to disable the clocks on init but doesn't prevent the clocks to be disabled
>>> if all the clock childs are gated so the parent is gated as well.
>>>
>>>> As the CG_STATUS bits are not being checked anywhere in the kernel I think
>>>> aclk266_g2d (and others in GATE_BUS_TOP) should not be gated. I am OK with
>>>
>>> For now I'll just add "aclk266_g2d" but later if needed all the GATE_BUS_TOP
>>> clocks (and others) that should only be gated when CG_STATUS is 0 can be
>>> added. My patch iterates over a list of clocks to be kept during suspend even
>>> when there is only one for now so adding more later if needed will be trivial.
>>
>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>> would be good if we could get more information on that. They are in the PMU
>> block and are related to LPI (Low Power Interface handshaking), but what
>> subsystems/peripheral blocks exactly are associated with them it's not clear
>> from the documentation.
> 
> Yes, I've been looking at the docs again and found out a couple of things:
> 
> * Each GC_STATUSx register bit is associated with an IP hw block
> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)

The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
documentation I have. I guess you've got something newer than REV0.00?

> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
> part of the PMU register address space.
> 
> In the particular case of aclk266_g2d, the doc says that the clock can only
> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.

In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
the camera subsystem. Such a dependency would be rather surprising.

>> I think it's essential to understand what triggers changes in CG_STATUSx
>> registers, before we start checking their value in the clock driver.
>>
> 
> Indeed, we should really understand what the status on these registers
> means. Also is not clear from the docs how much time should be waited,
> how long until giving up, etc.

Exactly, I checked some kernels from http://opensource.samsung.com
(e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
related to these registers yet, except the address macro definitions
and debug traces in the power domains driver.

>> Also it might be that there are indeed some clocks which must stay enabled
>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>> in the clock driver might not be such a hack as it looks at first sight.
>>
> 
> Having a clock driver to both a provider and consumer feels hacky to me as
> well but I didn't find a better way to solve this issue... another option
> is to have this workaround to solve the S2R issue while we figure out what
> the the state in the CG_STATUSx really mean.

Let's try to diagnose the issue best we can, then we would choose the most
accurate bug fix.

-- 
Regards,
Sylwester

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>> would be good if we could get more information on that. They are in the PMU
>>> block and are related to LPI (Low Power Interface handshaking), but what
>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>> from the documentation.
>> 
>> Yes, I've been looking at the docs again and found out a couple of things:
>> 
>> * Each GC_STATUSx register bit is associated with an IP hw block
>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
> 
> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
> documentation I have. I guess you've got something newer than REV0.00?
>

My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).

GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
the same bits from 0 to 5 and then differ from there.
 
>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>> part of the PMU register address space.
>> 
>> In the particular case of aclk266_g2d, the doc says that the clock can only
>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
> 
> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
> the camera subsystem. Such a dependency would be rather surprising.
> 

Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).

As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
have a corresponding bit in CG_STATUS0. But I don't know if that is an
error in the doc I've since is suspicious that is the only difference
between LPI_MASK0 and CG_STATUS0.

>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>> registers, before we start checking their value in the clock driver.
>>>
>> 
>> Indeed, we should really understand what the status on these registers
>> means. Also is not clear from the docs how much time should be waited,
>> how long until giving up, etc.
> 
> Exactly, I checked some kernels from http://opensource.samsung.com
> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
> related to these registers yet, except the address macro definitions
> and debug traces in the power domains driver.
>

Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
 
>>> Also it might be that there are indeed some clocks which must stay enabled
>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>> in the clock driver might not be such a hack as it looks at first sight.
>>>
>> 
>> Having a clock driver to both a provider and consumer feels hacky to me as
>> well but I didn't find a better way to solve this issue... another option
>> is to have this workaround to solve the S2R issue while we figure out what
>> the the state in the CG_STATUSx really mean.
> 
> Let's try to diagnose the issue best we can, then we would choose the most
> accurate bug fix.
> 

Sounds good to me.

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>> would be good if we could get more information on that. They are in the PMU
>>> block and are related to LPI (Low Power Interface handshaking), but what
>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>> from the documentation.
>> 
>> Yes, I've been looking at the docs again and found out a couple of things:
>> 
>> * Each GC_STATUSx register bit is associated with an IP hw block
>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
> 
> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
> documentation I have. I guess you've got something newer than REV0.00?
>

My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).

GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
the same bits from 0 to 5 and then differ from there.
 
>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>> part of the PMU register address space.
>> 
>> In the particular case of aclk266_g2d, the doc says that the clock can only
>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
> 
> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
> the camera subsystem. Such a dependency would be rather surprising.
> 

Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).

As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
have a corresponding bit in CG_STATUS0. But I don't know if that is an
error in the doc I've since is suspicious that is the only difference
between LPI_MASK0 and CG_STATUS0.

>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>> registers, before we start checking their value in the clock driver.
>>>
>> 
>> Indeed, we should really understand what the status on these registers
>> means. Also is not clear from the docs how much time should be waited,
>> how long until giving up, etc.
> 
> Exactly, I checked some kernels from http://opensource.samsung.com
> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
> related to these registers yet, except the address macro definitions
> and debug traces in the power domains driver.
>

Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
 
>>> Also it might be that there are indeed some clocks which must stay enabled
>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>> in the clock driver might not be such a hack as it looks at first sight.
>>>
>> 
>> Having a clock driver to both a provider and consumer feels hacky to me as
>> well but I didn't find a better way to solve this issue... another option
>> is to have this workaround to solve the S2R issue while we figure out what
>> the the state in the CG_STATUSx really mean.
> 
> Let's try to diagnose the issue best we can, then we would choose the most
> accurate bug fix.
> 

Sounds good to me.

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Sylwester,

On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>> would be good if we could get more information on that. They are in the PMU
>>> block and are related to LPI (Low Power Interface handshaking), but what
>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>> from the documentation.
>> 
>> Yes, I've been looking at the docs again and found out a couple of things:
>> 
>> * Each GC_STATUSx register bit is associated with an IP hw block
>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
> 
> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
> documentation I have. I guess you've got something newer than REV0.00?
>

My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).

GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
the same bits from 0 to 5 and then differ from there.
 
>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>> part of the PMU register address space.
>> 
>> In the particular case of aclk266_g2d, the doc says that the clock can only
>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
> 
> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
> the camera subsystem. Such a dependency would be rather surprising.
> 

Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).

As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
have a corresponding bit in CG_STATUS0. But I don't know if that is an
error in the doc I've since is suspicious that is the only difference
between LPI_MASK0 and CG_STATUS0.

>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>> registers, before we start checking their value in the clock driver.
>>>
>> 
>> Indeed, we should really understand what the status on these registers
>> means. Also is not clear from the docs how much time should be waited,
>> how long until giving up, etc.
> 
> Exactly, I checked some kernels from http://opensource.samsung.com
> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
> related to these registers yet, except the address macro definitions
> and debug traces in the power domains driver.
>

Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
 
>>> Also it might be that there are indeed some clocks which must stay enabled
>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>> in the clock driver might not be such a hack as it looks at first sight.
>>>
>> 
>> Having a clock driver to both a provider and consumer feels hacky to me as
>> well but I didn't find a better way to solve this issue... another option
>> is to have this workaround to solve the S2R issue while we figure out what
>> the the state in the CG_STATUSx really mean.
> 
> Let's try to diagnose the issue best we can, then we would choose the most
> accurate bug fix.
> 

Sounds good to me.

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi,

On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Sylwester,
>
> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>> would be good if we could get more information on that. They are in the PMU
>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>> from the documentation.
>>>
>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>
>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>
>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>> documentation I have. I guess you've got something newer than REV0.00?
>>
>
> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>
> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
> the same bits from 0 to 5 and then differ from there.
>
>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>> part of the PMU register address space.
>>>
>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>
>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>> the camera subsystem. Such a dependency would be rather surprising.
>>
>
> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>
> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
> have a corresponding bit in CG_STATUS0. But I don't know if that is an
> error in the doc I've since is suspicious that is the only difference
> between LPI_MASK0 and CG_STATUS0.
>
>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>> registers, before we start checking their value in the clock driver.
>>>>
>>>
>>> Indeed, we should really understand what the status on these registers
>>> means. Also is not clear from the docs how much time should be waited,
>>> how long until giving up, etc.
>>
>> Exactly, I checked some kernels from http://opensource.samsung.com
>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>> related to these registers yet, except the address macro definitions
>> and debug traces in the power domains driver.
>>
>
> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>
>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>
>>>
>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>> well but I didn't find a better way to solve this issue... another option
>>> is to have this workaround to solve the S2R issue while we figure out what
>>> the the state in the CG_STATUSx really mean.
>>
>> Let's try to diagnose the issue best we can, then we would choose the most
>> accurate bug fix.
>>
>
> Sounds good to me.

Based on the earlier comments I was trying to isolate if:
1) s2r fails because we gate aclk266_g2d (but it is one of those
clocks that needs to be always on prior to suspend).
2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
are not 0 (thus not following the spec).

As I did not have access to the hardware guys who could possibly
confirm 1), I decided to
a) find a configuration where CG_STATUS0 allows gating of the
aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
b) disable the aclk266_g2d clock using such a configuration.
c) check s2r.

I found a configuration [1] which gave the following after boot-up:
# devmem 0x10040914
0xFD800014 (CG_STATUS0[22:21] is 0)
# devmem 0x10020700
0xC6F8DE9F (aclk266_g2d is enabled)

At this point s2r works.

I rebooted the board with the same config as above and then disabled
aclk266_g2d.

# devmem 0x10020700 32 0xC6F8DE9D
# devmem 0x10020700
0xC6F8DE9D (aclk266_g2d is disabled)
# devmem 0x10040914
0xFD800014

and tried s2r - It fails.

>From the results, disabling the clock seems to cause the issue rather
than the CG_STATUS violation. This is all a little confusing, so
please let me know if I have missed something.

Regards,
Abhilash

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi,

On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Sylwester,
>
> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>> would be good if we could get more information on that. They are in the PMU
>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>> from the documentation.
>>>
>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>
>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>
>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>> documentation I have. I guess you've got something newer than REV0.00?
>>
>
> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>
> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
> the same bits from 0 to 5 and then differ from there.
>
>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>> part of the PMU register address space.
>>>
>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>
>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>> the camera subsystem. Such a dependency would be rather surprising.
>>
>
> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>
> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
> have a corresponding bit in CG_STATUS0. But I don't know if that is an
> error in the doc I've since is suspicious that is the only difference
> between LPI_MASK0 and CG_STATUS0.
>
>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>> registers, before we start checking their value in the clock driver.
>>>>
>>>
>>> Indeed, we should really understand what the status on these registers
>>> means. Also is not clear from the docs how much time should be waited,
>>> how long until giving up, etc.
>>
>> Exactly, I checked some kernels from http://opensource.samsung.com
>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>> related to these registers yet, except the address macro definitions
>> and debug traces in the power domains driver.
>>
>
> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>
>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>
>>>
>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>> well but I didn't find a better way to solve this issue... another option
>>> is to have this workaround to solve the S2R issue while we figure out what
>>> the the state in the CG_STATUSx really mean.
>>
>> Let's try to diagnose the issue best we can, then we would choose the most
>> accurate bug fix.
>>
>
> Sounds good to me.

Based on the earlier comments I was trying to isolate if:
1) s2r fails because we gate aclk266_g2d (but it is one of those
clocks that needs to be always on prior to suspend).
2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
are not 0 (thus not following the spec).

As I did not have access to the hardware guys who could possibly
confirm 1), I decided to
a) find a configuration where CG_STATUS0 allows gating of the
aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
b) disable the aclk266_g2d clock using such a configuration.
c) check s2r.

I found a configuration [1] which gave the following after boot-up:
# devmem 0x10040914
0xFD800014 (CG_STATUS0[22:21] is 0)
# devmem 0x10020700
0xC6F8DE9F (aclk266_g2d is enabled)

At this point s2r works.

I rebooted the board with the same config as above and then disabled
aclk266_g2d.

# devmem 0x10020700 32 0xC6F8DE9D
# devmem 0x10020700
0xC6F8DE9D (aclk266_g2d is disabled)
# devmem 0x10040914
0xFD800014

and tried s2r - It fails.

>From the results, disabling the clock seems to cause the issue rather
than the CG_STATUS violation. This is all a little confusing, so
please let me know if I have missed something.

Regards,
Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi,

On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Sylwester,
>
> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>> would be good if we could get more information on that. They are in the PMU
>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>> from the documentation.
>>>
>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>
>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>
>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>> documentation I have. I guess you've got something newer than REV0.00?
>>
>
> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>
> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
> the same bits from 0 to 5 and then differ from there.
>
>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>> part of the PMU register address space.
>>>
>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>
>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>> the camera subsystem. Such a dependency would be rather surprising.
>>
>
> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>
> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
> have a corresponding bit in CG_STATUS0. But I don't know if that is an
> error in the doc I've since is suspicious that is the only difference
> between LPI_MASK0 and CG_STATUS0.
>
>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>> registers, before we start checking their value in the clock driver.
>>>>
>>>
>>> Indeed, we should really understand what the status on these registers
>>> means. Also is not clear from the docs how much time should be waited,
>>> how long until giving up, etc.
>>
>> Exactly, I checked some kernels from http://opensource.samsung.com
>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>> related to these registers yet, except the address macro definitions
>> and debug traces in the power domains driver.
>>
>
> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>
>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>
>>>
>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>> well but I didn't find a better way to solve this issue... another option
>>> is to have this workaround to solve the S2R issue while we figure out what
>>> the the state in the CG_STATUSx really mean.
>>
>> Let's try to diagnose the issue best we can, then we would choose the most
>> accurate bug fix.
>>
>
> Sounds good to me.

Based on the earlier comments I was trying to isolate if:
1) s2r fails because we gate aclk266_g2d (but it is one of those
clocks that needs to be always on prior to suspend).
2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
are not 0 (thus not following the spec).

As I did not have access to the hardware guys who could possibly
confirm 1), I decided to
a) find a configuration where CG_STATUS0 allows gating of the
aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
b) disable the aclk266_g2d clock using such a configuration.
c) check s2r.

I found a configuration [1] which gave the following after boot-up:
# devmem 0x10040914
0xFD800014 (CG_STATUS0[22:21] is 0)
# devmem 0x10020700
0xC6F8DE9F (aclk266_g2d is enabled)

At this point s2r works.

I rebooted the board with the same config as above and then disabled
aclk266_g2d.

# devmem 0x10020700 32 0xC6F8DE9D
# devmem 0x10020700
0xC6F8DE9D (aclk266_g2d is disabled)
# devmem 0x10040914
0xFD800014

and tried s2r - It fails.

>From the results, disabling the clock seems to cause the issue rather
than the CG_STATUS violation. This is all a little confusing, so
please let me know if I have missed something.

Regards,
Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
> Hi,
> 
> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Hello Sylwester,
>>
>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>>> would be good if we could get more information on that. They are in the PMU
>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>>> from the documentation.
>>>>
>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>
>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>
>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>> documentation I have. I guess you've got something newer than REV0.00?
>>>
>>
>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>
>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>> the same bits from 0 to 5 and then differ from there.
>>
>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>> part of the PMU register address space.
>>>>
>>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>
>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>> the camera subsystem. Such a dependency would be rather surprising.
>>>
>>
>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>
>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>> error in the doc I've since is suspicious that is the only difference
>> between LPI_MASK0 and CG_STATUS0.
>>
>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>> registers, before we start checking their value in the clock driver.
>>>>>
>>>>
>>>> Indeed, we should really understand what the status on these registers
>>>> means. Also is not clear from the docs how much time should be waited,
>>>> how long until giving up, etc.
>>>
>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>> related to these registers yet, except the address macro definitions
>>> and debug traces in the power domains driver.
>>>
>>
>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>
>>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>
>>>>
>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>> well but I didn't find a better way to solve this issue... another option
>>>> is to have this workaround to solve the S2R issue while we figure out what
>>>> the the state in the CG_STATUSx really mean.
>>>
>>> Let's try to diagnose the issue best we can, then we would choose the most
>>> accurate bug fix.
>>>
>>
>> Sounds good to me.
> 
> Based on the earlier comments I was trying to isolate if:
> 1) s2r fails because we gate aclk266_g2d (but it is one of those
> clocks that needs to be always on prior to suspend).
> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
> are not 0 (thus not following the spec).
> 

Thanks a lot for continue looking at this. I didn't have time to dig
deeper on this since last week.

> As I did not have access to the hardware guys who could possibly
> confirm 1), I decided to
> a) find a configuration where CG_STATUS0 allows gating of the
> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
> b) disable the aclk266_g2d clock using such a configuration.
> c) check s2r.
> 
> I found a configuration [1] which gave the following after boot-up:

I think you forgot the reference for [1] right? Since with latest
linux-next (20150402) I got:

> # devmem 0x10040914
> 0xFD800014 (CG_STATUS0[22:21] is 0)

# devmem 0x10040914
0xFFE00000 (CG_STATUS0[22:21] is 1)

> # devmem 0x10020700
> 0xC6F8DE9F (aclk266_g2d is enabled)
>
> At this point s2r works.
> 
> I rebooted the board with the same config as above and then disabled
> aclk266_g2d.
> 
> # devmem 0x10020700 32 0xC6F8DE9D
> # devmem 0x10020700
> 0xC6F8DE9D (aclk266_g2d is disabled)
> # devmem 0x10040914
> 0xFD800014
> 
> and tried s2r - It fails.
>
> From the results, disabling the clock seems to cause the issue rather
> than the CG_STATUS violation. This is all a little confusing, so
> please let me know if I have missed something.
>

So IIUC the CG_STATUS0 bits were a red herring and the real problem
is that the aclk266_g2d needs to be enabled during suspend (although
we still don't know why).

It seems were are at a dead end now. Without being able to ask the HW
Samsung folks we would never know what's going on here...

I can re-post my patches to keep aclk266_g2d enabled during suspend
in the clk driver if that is the least bad option. But it would be
great to solve this issue otherwise S2R will remain to be broken for
Exynos5420 which will be really sad.

> Regards,
> Abhilash
> 

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
> Hi,
> 
> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Hello Sylwester,
>>
>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>>> would be good if we could get more information on that. They are in the PMU
>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>>> from the documentation.
>>>>
>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>
>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>
>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>> documentation I have. I guess you've got something newer than REV0.00?
>>>
>>
>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>
>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>> the same bits from 0 to 5 and then differ from there.
>>
>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>> part of the PMU register address space.
>>>>
>>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>
>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>> the camera subsystem. Such a dependency would be rather surprising.
>>>
>>
>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>
>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>> error in the doc I've since is suspicious that is the only difference
>> between LPI_MASK0 and CG_STATUS0.
>>
>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>> registers, before we start checking their value in the clock driver.
>>>>>
>>>>
>>>> Indeed, we should really understand what the status on these registers
>>>> means. Also is not clear from the docs how much time should be waited,
>>>> how long until giving up, etc.
>>>
>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>> related to these registers yet, except the address macro definitions
>>> and debug traces in the power domains driver.
>>>
>>
>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>
>>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>
>>>>
>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>> well but I didn't find a better way to solve this issue... another option
>>>> is to have this workaround to solve the S2R issue while we figure out what
>>>> the the state in the CG_STATUSx really mean.
>>>
>>> Let's try to diagnose the issue best we can, then we would choose the most
>>> accurate bug fix.
>>>
>>
>> Sounds good to me.
> 
> Based on the earlier comments I was trying to isolate if:
> 1) s2r fails because we gate aclk266_g2d (but it is one of those
> clocks that needs to be always on prior to suspend).
> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
> are not 0 (thus not following the spec).
> 

Thanks a lot for continue looking at this. I didn't have time to dig
deeper on this since last week.

> As I did not have access to the hardware guys who could possibly
> confirm 1), I decided to
> a) find a configuration where CG_STATUS0 allows gating of the
> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
> b) disable the aclk266_g2d clock using such a configuration.
> c) check s2r.
> 
> I found a configuration [1] which gave the following after boot-up:

I think you forgot the reference for [1] right? Since with latest
linux-next (20150402) I got:

> # devmem 0x10040914
> 0xFD800014 (CG_STATUS0[22:21] is 0)

# devmem 0x10040914
0xFFE00000 (CG_STATUS0[22:21] is 1)

> # devmem 0x10020700
> 0xC6F8DE9F (aclk266_g2d is enabled)
>
> At this point s2r works.
> 
> I rebooted the board with the same config as above and then disabled
> aclk266_g2d.
> 
> # devmem 0x10020700 32 0xC6F8DE9D
> # devmem 0x10020700
> 0xC6F8DE9D (aclk266_g2d is disabled)
> # devmem 0x10040914
> 0xFD800014
> 
> and tried s2r - It fails.
>
> From the results, disabling the clock seems to cause the issue rather
> than the CG_STATUS violation. This is all a little confusing, so
> please let me know if I have missed something.
>

So IIUC the CG_STATUS0 bits were a red herring and the real problem
is that the aclk266_g2d needs to be enabled during suspend (although
we still don't know why).

It seems were are at a dead end now. Without being able to ask the HW
Samsung folks we would never know what's going on here...

I can re-post my patches to keep aclk266_g2d enabled during suspend
in the clk driver if that is the least bad option. But it would be
great to solve this issue otherwise S2R will remain to be broken for
Exynos5420 which will be really sad.

> Regards,
> Abhilash
> 

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
> Hi,
> 
> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Hello Sylwester,
>>
>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>>> would be good if we could get more information on that. They are in the PMU
>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>>> from the documentation.
>>>>
>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>
>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>
>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>> documentation I have. I guess you've got something newer than REV0.00?
>>>
>>
>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>
>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>> the same bits from 0 to 5 and then differ from there.
>>
>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>> part of the PMU register address space.
>>>>
>>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>
>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>> the camera subsystem. Such a dependency would be rather surprising.
>>>
>>
>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>
>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>> error in the doc I've since is suspicious that is the only difference
>> between LPI_MASK0 and CG_STATUS0.
>>
>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>> registers, before we start checking their value in the clock driver.
>>>>>
>>>>
>>>> Indeed, we should really understand what the status on these registers
>>>> means. Also is not clear from the docs how much time should be waited,
>>>> how long until giving up, etc.
>>>
>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>> related to these registers yet, except the address macro definitions
>>> and debug traces in the power domains driver.
>>>
>>
>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>
>>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>
>>>>
>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>> well but I didn't find a better way to solve this issue... another option
>>>> is to have this workaround to solve the S2R issue while we figure out what
>>>> the the state in the CG_STATUSx really mean.
>>>
>>> Let's try to diagnose the issue best we can, then we would choose the most
>>> accurate bug fix.
>>>
>>
>> Sounds good to me.
> 
> Based on the earlier comments I was trying to isolate if:
> 1) s2r fails because we gate aclk266_g2d (but it is one of those
> clocks that needs to be always on prior to suspend).
> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
> are not 0 (thus not following the spec).
> 

Thanks a lot for continue looking at this. I didn't have time to dig
deeper on this since last week.

> As I did not have access to the hardware guys who could possibly
> confirm 1), I decided to
> a) find a configuration where CG_STATUS0 allows gating of the
> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
> b) disable the aclk266_g2d clock using such a configuration.
> c) check s2r.
> 
> I found a configuration [1] which gave the following after boot-up:

I think you forgot the reference for [1] right? Since with latest
linux-next (20150402) I got:

> # devmem 0x10040914
> 0xFD800014 (CG_STATUS0[22:21] is 0)

# devmem 0x10040914
0xFFE00000 (CG_STATUS0[22:21] is 1)

> # devmem 0x10020700
> 0xC6F8DE9F (aclk266_g2d is enabled)
>
> At this point s2r works.
> 
> I rebooted the board with the same config as above and then disabled
> aclk266_g2d.
> 
> # devmem 0x10020700 32 0xC6F8DE9D
> # devmem 0x10020700
> 0xC6F8DE9D (aclk266_g2d is disabled)
> # devmem 0x10040914
> 0xFD800014
> 
> and tried s2r - It fails.
>
> From the results, disabling the clock seems to cause the issue rather
> than the CG_STATUS violation. This is all a little confusing, so
> please let me know if I have missed something.
>

So IIUC the CG_STATUS0 bits were a red herring and the real problem
is that the aclk266_g2d needs to be enabled during suspend (although
we still don't know why).

It seems were are at a dead end now. Without being able to ask the HW
Samsung folks we would never know what's going on here...

I can re-post my patches to keep aclk266_g2d enabled during suspend
in the clk driver if that is the least bad option. But it would be
great to solve this issue otherwise S2R will remain to be broken for
Exynos5420 which will be really sad.

> Regards,
> Abhilash
> 

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

On 04/07/2015 12:59 PM, Javier Martinez Canillas wrote:
> 
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
> 
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...
> 

Ok, I found another interesting data point. ACLK_266_G2D has as
constraints that CG_STATUS0[21:22] needs to be 0 before gating
the clock and as I mentioned before those are associated with
the SSS and SSS_SLIM HW crypto modules according the docs I've.

So I looked at the clock used by the SSS module and found that
CLK_SSS parent is ACLK_266_G2D but CLK_SSS is never requested
since drivers/crypto/s5p-sss.c isn't built for exynos_defconfig.

Enabling CONFIG_CRYPTO_DEV_S5P makes the system to resume without
any patches since the sss clock prevents aclk266_g2d to be gated.

But I wanted to know if it was really aclk266_g2d that was needed
or the actual sss clock since the kernel didn't manage that clock
without the driver enabled.

So I disabled the sss clock before trying a S2R:

# devmem 0x10018800 32 0xFFFFFFFB
(CLK_SSS in CLK_GATE_IP_G2D is gated)

and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
its default value on S2R so maybe that is why it works anyways?

# devmem 0x10018800
0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)

Does this shed any more light? Could the problem be that the sss
clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
required for S2R or is just that CLK_SSS prevents the parent to
be gated and so it is another red herring?

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

On 04/07/2015 12:59 PM, Javier Martinez Canillas wrote:
> 
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
> 
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...
> 

Ok, I found another interesting data point. ACLK_266_G2D has as
constraints that CG_STATUS0[21:22] needs to be 0 before gating
the clock and as I mentioned before those are associated with
the SSS and SSS_SLIM HW crypto modules according the docs I've.

So I looked at the clock used by the SSS module and found that
CLK_SSS parent is ACLK_266_G2D but CLK_SSS is never requested
since drivers/crypto/s5p-sss.c isn't built for exynos_defconfig.

Enabling CONFIG_CRYPTO_DEV_S5P makes the system to resume without
any patches since the sss clock prevents aclk266_g2d to be gated.

But I wanted to know if it was really aclk266_g2d that was needed
or the actual sss clock since the kernel didn't manage that clock
without the driver enabled.

So I disabled the sss clock before trying a S2R:

# devmem 0x10018800 32 0xFFFFFFFB
(CLK_SSS in CLK_GATE_IP_G2D is gated)

and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
its default value on S2R so maybe that is why it works anyways?

# devmem 0x10018800
0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)

Does this shed any more light? Could the problem be that the sss
clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
required for S2R or is just that CLK_SSS prevents the parent to
be gated and so it is another red herring?

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

On 04/07/2015 12:59 PM, Javier Martinez Canillas wrote:
> 
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
> 
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...
> 

Ok, I found another interesting data point. ACLK_266_G2D has as
constraints that CG_STATUS0[21:22] needs to be 0 before gating
the clock and as I mentioned before those are associated with
the SSS and SSS_SLIM HW crypto modules according the docs I've.

So I looked at the clock used by the SSS module and found that
CLK_SSS parent is ACLK_266_G2D but CLK_SSS is never requested
since drivers/crypto/s5p-sss.c isn't built for exynos_defconfig.

Enabling CONFIG_CRYPTO_DEV_S5P makes the system to resume without
any patches since the sss clock prevents aclk266_g2d to be gated.

But I wanted to know if it was really aclk266_g2d that was needed
or the actual sss clock since the kernel didn't manage that clock
without the driver enabled.

So I disabled the sss clock before trying a S2R:

# devmem 0x10018800 32 0xFFFFFFFB
(CLK_SSS in CLK_GATE_IP_G2D is gated)

and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
its default value on S2R so maybe that is why it works anyways?

# devmem 0x10018800
0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)

Does this shed any more light? Could the problem be that the sss
clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
required for S2R or is just that CLK_SSS prevents the parent to
be gated and so it is another red herring?

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> So I disabled the sss clock before trying a S2R:
>
> # devmem 0x10018800 32 0xFFFFFFFB
> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>
> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
> its default value on S2R so maybe that is why it works anyways?

Does the driver restore its value on resume (i.e. has it in the
save/restore array)? Remember that suspend causes all clock registers
to be reset. Then some of them will be configured by the lowest
bootloader stage after wake-up reset, but the kernel needs to restore
all of them.

>
> # devmem 0x10018800
> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>
> Does this shed any more light? Could the problem be that the sss
> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
> required for S2R or is just that CLK_SSS prevents the parent to
> be gated and so it is another red herring?

Does the board use secure firmware? If yes, it might require to do
some encryption on suspend, so if the firmware is broken and doesn't
control the clock itself, it might need the SSS clock to be running,
when the SLEEP SMC operation is called.

Anyway, I just realized that Exynos4 also need several clocks to be
ungated on suspend and this is handled by code [1] based on arrays
[2].

[1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
[2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276

Could this method work for your case as well? There would be no need
to call any clock API at all, just low level register writes, which is
okay, since this is a low level driver anyway.

Best regards,
Tomasz

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> So I disabled the sss clock before trying a S2R:
>
> # devmem 0x10018800 32 0xFFFFFFFB
> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>
> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
> its default value on S2R so maybe that is why it works anyways?

Does the driver restore its value on resume (i.e. has it in the
save/restore array)? Remember that suspend causes all clock registers
to be reset. Then some of them will be configured by the lowest
bootloader stage after wake-up reset, but the kernel needs to restore
all of them.

>
> # devmem 0x10018800
> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>
> Does this shed any more light? Could the problem be that the sss
> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
> required for S2R or is just that CLK_SSS prevents the parent to
> be gated and so it is another red herring?

Does the board use secure firmware? If yes, it might require to do
some encryption on suspend, so if the firmware is broken and doesn't
control the clock itself, it might need the SSS clock to be running,
when the SLEEP SMC operation is called.

Anyway, I just realized that Exynos4 also need several clocks to be
ungated on suspend and this is handled by code [1] based on arrays
[2].

[1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
[2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276

Could this method work for your case as well? There would be no need
to call any clock API at all, just low level register writes, which is
okay, since this is a low level driver anyway.

Best regards,
Tomasz

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> So I disabled the sss clock before trying a S2R:
>
> # devmem 0x10018800 32 0xFFFFFFFB
> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>
> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
> its default value on S2R so maybe that is why it works anyways?

Does the driver restore its value on resume (i.e. has it in the
save/restore array)? Remember that suspend causes all clock registers
to be reset. Then some of them will be configured by the lowest
bootloader stage after wake-up reset, but the kernel needs to restore
all of them.

>
> # devmem 0x10018800
> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>
> Does this shed any more light? Could the problem be that the sss
> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
> required for S2R or is just that CLK_SSS prevents the parent to
> be gated and so it is another red herring?

Does the board use secure firmware? If yes, it might require to do
some encryption on suspend, so if the firmware is broken and doesn't
control the clock itself, it might need the SSS clock to be running,
when the SLEEP SMC operation is called.

Anyway, I just realized that Exynos4 also need several clocks to be
ungated on suspend and this is handled by code [1] based on arrays
[2].

[1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
[2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276

Could this method work for your case as well? There would be no need
to call any clock API at all, just low level register writes, which is
okay, since this is a low level driver anyway.

Best regards,
Tomasz

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

On 04/07/2015 02:46 PM, Tomasz Figa wrote:
> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> So I disabled the sss clock before trying a S2R:
>>
>> # devmem 0x10018800 32 0xFFFFFFFB
>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>
>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>> its default value on S2R so maybe that is why it works anyways?
> 
> Does the driver restore its value on resume (i.e. has it in the
> save/restore array)? Remember that suspend causes all clock registers
> to be reset. Then some of them will be configured by the lowest

No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
the kernel after a suspend/resume cycle.

> bootloader stage after wake-up reset, but the kernel needs to restore
> all of them.
> 

I see, thanks for the clarification. Then I think that is a bug and
GATE_IP_G2D needs to be added to the list of clocks to be saved and
restored right? That's a separate issue from our current S2R problem
though so it can be done later as a separate patch.

>>
>> # devmem 0x10018800
>> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>
>> Does this shed any more light? Could the problem be that the sss
>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>> required for S2R or is just that CLK_SSS prevents the parent to
>> be gated and so it is another red herring?
> 
> Does the board use secure firmware? If yes, it might require to do
> some encryption on suspend, so if the firmware is broken and doesn't
> control the clock itself, it might need the SSS clock to be running,
> when the SLEEP SMC operation is called.
> 

No, the Chromebooks don't use secure firmware AFAIK.

> Anyway, I just realized that Exynos4 also need several clocks to be
> ungated on suspend and this is handled by code [1] based on arrays
> [2].
> 
> [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
> [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>

Yes I noticed that the Exynos5420 driver also does the same but did not
want to do it there because I didn't know what value should had been used
for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
your explanation right, it is safe to do so since the register is going to
be reset to its default values anyways.

> Could this method work for your case as well? There would be no need
> to call any clock API at all, just low level register writes, which is
> okay, since this is a low level driver anyway.
>

Yes, the following patch [0] is enough to make S2R working. If you think
that is correct then I'll post it as a proper patch then.

> Best regards,
> Tomasz
> 

Best regards,
Javier

[0]
>From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Tue, 7 Apr 2015 15:53:27 +0200
Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this in turn makes its parent clock aclk266_g2d to
be gated. But the clock needs to be ungated prior suspend to allow the
system to be suspend and resumed correctly.

Add GATE_BUS_TOP register to the list of registers to be restored when
the system enters into a suspend state so aclk266_g2d will be ungated.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..bea4a173eef5 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = SRC_MASK_PERIC0,		.value = 0x11111110, },
 	{ .offset = SRC_MASK_PERIC1,		.value = 0x11111100, },
 	{ .offset = SRC_MASK_ISP,		.value = 0x11111000, },
+	{ .offset = GATE_BUS_TOP,		.value = 0xffffffff, },
 	{ .offset = GATE_BUS_DISP1,		.value = 0xffffffff, },
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
-- 
2.1.4

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

On 04/07/2015 02:46 PM, Tomasz Figa wrote:
> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> So I disabled the sss clock before trying a S2R:
>>
>> # devmem 0x10018800 32 0xFFFFFFFB
>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>
>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>> its default value on S2R so maybe that is why it works anyways?
> 
> Does the driver restore its value on resume (i.e. has it in the
> save/restore array)? Remember that suspend causes all clock registers
> to be reset. Then some of them will be configured by the lowest

No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
the kernel after a suspend/resume cycle.

> bootloader stage after wake-up reset, but the kernel needs to restore
> all of them.
> 

I see, thanks for the clarification. Then I think that is a bug and
GATE_IP_G2D needs to be added to the list of clocks to be saved and
restored right? That's a separate issue from our current S2R problem
though so it can be done later as a separate patch.

>>
>> # devmem 0x10018800
>> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>
>> Does this shed any more light? Could the problem be that the sss
>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>> required for S2R or is just that CLK_SSS prevents the parent to
>> be gated and so it is another red herring?
> 
> Does the board use secure firmware? If yes, it might require to do
> some encryption on suspend, so if the firmware is broken and doesn't
> control the clock itself, it might need the SSS clock to be running,
> when the SLEEP SMC operation is called.
> 

No, the Chromebooks don't use secure firmware AFAIK.

> Anyway, I just realized that Exynos4 also need several clocks to be
> ungated on suspend and this is handled by code [1] based on arrays
> [2].
> 
> [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
> [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>

Yes I noticed that the Exynos5420 driver also does the same but did not
want to do it there because I didn't know what value should had been used
for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
your explanation right, it is safe to do so since the register is going to
be reset to its default values anyways.

> Could this method work for your case as well? There would be no need
> to call any clock API at all, just low level register writes, which is
> okay, since this is a low level driver anyway.
>

Yes, the following patch [0] is enough to make S2R working. If you think
that is correct then I'll post it as a proper patch then.

> Best regards,
> Tomasz
> 

Best regards,
Javier

[0]
>From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Tue, 7 Apr 2015 15:53:27 +0200
Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this in turn makes its parent clock aclk266_g2d to
be gated. But the clock needs to be ungated prior suspend to allow the
system to be suspend and resumed correctly.

Add GATE_BUS_TOP register to the list of registers to be restored when
the system enters into a suspend state so aclk266_g2d will be ungated.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..bea4a173eef5 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = SRC_MASK_PERIC0,		.value = 0x11111110, },
 	{ .offset = SRC_MASK_PERIC1,		.value = 0x11111100, },
 	{ .offset = SRC_MASK_ISP,		.value = 0x11111000, },
+	{ .offset = GATE_BUS_TOP,		.value = 0xffffffff, },
 	{ .offset = GATE_BUS_DISP1,		.value = 0xffffffff, },
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
-- 
2.1.4

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

On 04/07/2015 02:46 PM, Tomasz Figa wrote:
> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> So I disabled the sss clock before trying a S2R:
>>
>> # devmem 0x10018800 32 0xFFFFFFFB
>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>
>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>> its default value on S2R so maybe that is why it works anyways?
> 
> Does the driver restore its value on resume (i.e. has it in the
> save/restore array)? Remember that suspend causes all clock registers
> to be reset. Then some of them will be configured by the lowest

No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
the kernel after a suspend/resume cycle.

> bootloader stage after wake-up reset, but the kernel needs to restore
> all of them.
> 

I see, thanks for the clarification. Then I think that is a bug and
GATE_IP_G2D needs to be added to the list of clocks to be saved and
restored right? That's a separate issue from our current S2R problem
though so it can be done later as a separate patch.

>>
>> # devmem 0x10018800
>> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>
>> Does this shed any more light? Could the problem be that the sss
>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>> required for S2R or is just that CLK_SSS prevents the parent to
>> be gated and so it is another red herring?
> 
> Does the board use secure firmware? If yes, it might require to do
> some encryption on suspend, so if the firmware is broken and doesn't
> control the clock itself, it might need the SSS clock to be running,
> when the SLEEP SMC operation is called.
> 

No, the Chromebooks don't use secure firmware AFAIK.

> Anyway, I just realized that Exynos4 also need several clocks to be
> ungated on suspend and this is handled by code [1] based on arrays
> [2].
> 
> [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
> [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>

Yes I noticed that the Exynos5420 driver also does the same but did not
want to do it there because I didn't know what value should had been used
for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
your explanation right, it is safe to do so since the register is going to
be reset to its default values anyways.

> Could this method work for your case as well? There would be no need
> to call any clock API at all, just low level register writes, which is
> okay, since this is a low level driver anyway.
>

Yes, the following patch [0] is enough to make S2R working. If you think
that is correct then I'll post it as a proper patch then.

> Best regards,
> Tomasz
> 

Best regards,
Javier

[0]
>From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Tue, 7 Apr 2015 15:53:27 +0200
Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend

Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this in turn makes its parent clock aclk266_g2d to
be gated. But the clock needs to be ungated prior suspend to allow the
system to be suspend and resumed correctly.

Add GATE_BUS_TOP register to the list of registers to be restored when
the system enters into a suspend state so aclk266_g2d will be ungated.

Thanks to Abhilash Kesavan for figuring out that this was the issue.

Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 drivers/clk/samsung/clk-exynos5420.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..bea4a173eef5 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
 	{ .offset = SRC_MASK_PERIC0,		.value = 0x11111110, },
 	{ .offset = SRC_MASK_PERIC1,		.value = 0x11111100, },
 	{ .offset = SRC_MASK_ISP,		.value = 0x11111000, },
+	{ .offset = GATE_BUS_TOP,		.value = 0xffffffff, },
 	{ .offset = GATE_BUS_DISP1,		.value = 0xffffffff, },
 	{ .offset = GATE_IP_PERIC,		.value = 0xffffffff, },
 };
-- 
2.1.4

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 7:41 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Tomasz,
>
> On 04/07/2015 02:46 PM, Tomasz Figa wrote:
>> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk>:
>>> So I disabled the sss clock before trying a S2R:
>>>
>>> # devmem 0x10018800 32 0xFFFFFFFB
>>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>>
>>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>>> its default value on S2R so maybe that is why it works anyways?
>>
>> Does the driver restore its value on resume (i.e. has it in the
>> save/restore array)? Remember that suspend causes all clock registers
>> to be reset. Then some of them will be configured by the lowest
>
> No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
> the kernel after a suspend/resume cycle.
>
>> bootloader stage after wake-up reset, but the kernel needs to restore
>> all of them.
>>
>
> I see, thanks for the clarification. Then I think that is a bug and
> GATE_IP_G2D needs to be added to the list of clocks to be saved and
> restored right? That's a separate issue from our current S2R problem
> though so it can be done later as a separate patch.
>
>>>
>>> # devmem 0x10018800
>>> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>>
>>> Does this shed any more light? Could the problem be that the sss
>>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>>> required for S2R or is just that CLK_SSS prevents the parent to
>>> be gated and so it is another red herring?
>>
>> Does the board use secure firmware? If yes, it might require to do
>> some encryption on suspend, so if the firmware is broken and doesn't
>> control the clock itself, it might need the SSS clock to be running,
>> when the SLEEP SMC operation is called.
>>
>
> No, the Chromebooks don't use secure firmware AFAIK.
>
>> Anyway, I just realized that Exynos4 also need several clocks to be
>> ungated on suspend and this is handled by code [1] based on arrays
>> [2].
>>
>> [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
>> [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>>
>
> Yes I noticed that the Exynos5420 driver also does the same but did not
> want to do it there because I didn't know what value should had been used
> for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
> your explanation right, it is safe to do so since the register is going to
> be reset to its default values anyways.
>
>> Could this method work for your case as well? There would be no need
>> to call any clock API at all, just low level register writes, which is
>> okay, since this is a low level driver anyway.
>>
>
> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.
>
>> Best regards,
>> Tomasz
>>
>
> Best regards,
> Javier
>
> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };

While there could be a concern that we are ungating all the clocks in
BUS_TOP, this looks like the least intrusive fix for the issue. Tested
this on Peach Pi, S2R works fine.

Thanks,
Abhilash

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 7:41 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Tomasz,
>
> On 04/07/2015 02:46 PM, Tomasz Figa wrote:
>> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk>:
>>> So I disabled the sss clock before trying a S2R:
>>>
>>> # devmem 0x10018800 32 0xFFFFFFFB
>>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>>
>>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>>> its default value on S2R so maybe that is why it works anyways?
>>
>> Does the driver restore its value on resume (i.e. has it in the
>> save/restore array)? Remember that suspend causes all clock registers
>> to be reset. Then some of them will be configured by the lowest
>
> No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
> the kernel after a suspend/resume cycle.
>
>> bootloader stage after wake-up reset, but the kernel needs to restore
>> all of them.
>>
>
> I see, thanks for the clarification. Then I think that is a bug and
> GATE_IP_G2D needs to be added to the list of clocks to be saved and
> restored right? That's a separate issue from our current S2R problem
> though so it can be done later as a separate patch.
>
>>>
>>> # devmem 0x10018800
>>> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>>
>>> Does this shed any more light? Could the problem be that the sss
>>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>>> required for S2R or is just that CLK_SSS prevents the parent to
>>> be gated and so it is another red herring?
>>
>> Does the board use secure firmware? If yes, it might require to do
>> some encryption on suspend, so if the firmware is broken and doesn't
>> control the clock itself, it might need the SSS clock to be running,
>> when the SLEEP SMC operation is called.
>>
>
> No, the Chromebooks don't use secure firmware AFAIK.
>
>> Anyway, I just realized that Exynos4 also need several clocks to be
>> ungated on suspend and this is handled by code [1] based on arrays
>> [2].
>>
>> [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
>> [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>>
>
> Yes I noticed that the Exynos5420 driver also does the same but did not
> want to do it there because I didn't know what value should had been used
> for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
> your explanation right, it is safe to do so since the register is going to
> be reset to its default values anyways.
>
>> Could this method work for your case as well? There would be no need
>> to call any clock API at all, just low level register writes, which is
>> okay, since this is a low level driver anyway.
>>
>
> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.
>
>> Best regards,
>> Tomasz
>>
>
> Best regards,
> Javier
>
> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };

While there could be a concern that we are ungating all the clocks in
BUS_TOP, this looks like the least intrusive fix for the issue. Tested
this on Peach Pi, S2R works fine.

Thanks,
Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 7:41 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Tomasz,
>
> On 04/07/2015 02:46 PM, Tomasz Figa wrote:
>> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk>:
>>> So I disabled the sss clock before trying a S2R:
>>>
>>> # devmem 0x10018800 32 0xFFFFFFFB
>>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>>
>>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>>> its default value on S2R so maybe that is why it works anyways?
>>
>> Does the driver restore its value on resume (i.e. has it in the
>> save/restore array)? Remember that suspend causes all clock registers
>> to be reset. Then some of them will be configured by the lowest
>
> No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
> the kernel after a suspend/resume cycle.
>
>> bootloader stage after wake-up reset, but the kernel needs to restore
>> all of them.
>>
>
> I see, thanks for the clarification. Then I think that is a bug and
> GATE_IP_G2D needs to be added to the list of clocks to be saved and
> restored right? That's a separate issue from our current S2R problem
> though so it can be done later as a separate patch.
>
>>>
>>> # devmem 0x10018800
>>> 0xFFFFFFFF (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>>
>>> Does this shed any more light? Could the problem be that the sss
>>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>>> required for S2R or is just that CLK_SSS prevents the parent to
>>> be gated and so it is another red herring?
>>
>> Does the board use secure firmware? If yes, it might require to do
>> some encryption on suspend, so if the firmware is broken and doesn't
>> control the clock itself, it might need the SSS clock to be running,
>> when the SLEEP SMC operation is called.
>>
>
> No, the Chromebooks don't use secure firmware AFAIK.
>
>> Anyway, I just realized that Exynos4 also need several clocks to be
>> ungated on suspend and this is handled by code [1] based on arrays
>> [2].
>>
>> [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
>> [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>>
>
> Yes I noticed that the Exynos5420 driver also does the same but did not
> want to do it there because I didn't know what value should had been used
> for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
> your explanation right, it is safe to do so since the register is going to
> be reset to its default values anyways.
>
>> Could this method work for your case as well? There would be no need
>> to call any clock API at all, just low level register writes, which is
>> okay, since this is a low level driver anyway.
>>
>
> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.
>
>> Best regards,
>> Tomasz
>>
>
> Best regards,
> Javier
>
> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };

While there could be a concern that we are ungating all the clocks in
BUS_TOP, this looks like the least intrusive fix for the issue. Tested
this on Peach Pi, S2R works fine.

Thanks,
Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>
>> [0]
>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this in turn makes its parent clock aclk266_g2d to
>> be gated. But the clock needs to be ungated prior suspend to allow the
>> system to be suspend and resumed correctly.
>>
>> Add GATE_BUS_TOP register to the list of registers to be restored when
>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>
>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>
>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..bea4a173eef5 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
>> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>  };
> 
> While there could be a concern that we are ungating all the clocks in

Yes, I mentioned that but OTOH it will be even more dangerous to gate
clocks that should remain enabled so I used the register default values.

> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
> this on Peach Pi, S2R works fine.
>

Thanks a lot for testing, does it mean I can add your Tested-by then when
posting it as a proper patch? I'll wait for Tomasz to comment before though.
 
> Thanks,
> Abhilash
> 

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>
>> [0]
>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this in turn makes its parent clock aclk266_g2d to
>> be gated. But the clock needs to be ungated prior suspend to allow the
>> system to be suspend and resumed correctly.
>>
>> Add GATE_BUS_TOP register to the list of registers to be restored when
>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>
>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>
>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..bea4a173eef5 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
>> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>  };
> 
> While there could be a concern that we are ungating all the clocks in

Yes, I mentioned that but OTOH it will be even more dangerous to gate
clocks that should remain enabled so I used the register default values.

> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
> this on Peach Pi, S2R works fine.
>

Thanks a lot for testing, does it mean I can add your Tested-by then when
posting it as a proper patch? I'll wait for Tomasz to comment before though.
 
> Thanks,
> Abhilash
> 

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>
>> [0]
>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this in turn makes its parent clock aclk266_g2d to
>> be gated. But the clock needs to be ungated prior suspend to allow the
>> system to be suspend and resumed correctly.
>>
>> Add GATE_BUS_TOP register to the list of registers to be restored when
>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>
>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>
>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..bea4a173eef5 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
>> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>  };
> 
> While there could be a concern that we are ungating all the clocks in

Yes, I mentioned that but OTOH it will be even more dangerous to gate
clocks that should remain enabled so I used the register default values.

> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
> this on Peach Pi, S2R works fine.
>

Thanks a lot for testing, does it mean I can add your Tested-by then when
posting it as a proper patch? I'll wait for Tomasz to comment before though.
 
> Thanks,
> Abhilash
> 

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Abhilash,
>
> On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>>
>>> [0]
>>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>>
>>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12") added pm support for the pl330 dma driver but
>>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>>> during suspend and this in turn makes its parent clock aclk266_g2d to
>>> be gated. But the clock needs to be ungated prior suspend to allow the
>>> system to be suspend and resumed correctly.
>>>
>>> Add GATE_BUS_TOP register to the list of registers to be restored when
>>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>>
>>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>>
>>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>>> index 07d666cc6a29..bea4a173eef5 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>>>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>>>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
>>> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>>>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>>  };
>>
>> While there could be a concern that we are ungating all the clocks in
>
> Yes, I mentioned that but OTOH it will be even more dangerous to gate
> clocks that should remain enabled so I used the register default values.
>
>> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
>> this on Peach Pi, S2R works fine.
>>
>
> Thanks a lot for testing, does it mean I can add your Tested-by then when
> posting it as a proper patch? I'll wait for Tomasz to comment before though.

Tested-by: Abhilash Kesavan <a.kesavan@samsung.com>.

Abhilash

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Abhilash,
>
> On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>>
>>> [0]
>>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>>
>>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12") added pm support for the pl330 dma driver but
>>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>>> during suspend and this in turn makes its parent clock aclk266_g2d to
>>> be gated. But the clock needs to be ungated prior suspend to allow the
>>> system to be suspend and resumed correctly.
>>>
>>> Add GATE_BUS_TOP register to the list of registers to be restored when
>>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>>
>>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>>
>>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>>> index 07d666cc6a29..bea4a173eef5 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>>>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>>>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
>>> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>>>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>>  };
>>
>> While there could be a concern that we are ungating all the clocks in
>
> Yes, I mentioned that but OTOH it will be even more dangerous to gate
> clocks that should remain enabled so I used the register default values.
>
>> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
>> this on Peach Pi, S2R works fine.
>>
>
> Thanks a lot for testing, does it mean I can add your Tested-by then when
> posting it as a proper patch? I'll wait for Tomasz to comment before though.

Tested-by: Abhilash Kesavan <a.kesavan@samsung.com>.

Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Abhilash,
>
> On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>>
>>> [0]
>>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>>
>>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12") added pm support for the pl330 dma driver but
>>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>>> during suspend and this in turn makes its parent clock aclk266_g2d to
>>> be gated. But the clock needs to be ungated prior suspend to allow the
>>> system to be suspend and resumed correctly.
>>>
>>> Add GATE_BUS_TOP register to the list of registers to be restored when
>>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>>
>>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>>
>>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
>>> index 07d666cc6a29..bea4a173eef5 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>>>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>>>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>>>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
>>> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>>>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>>>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>>>  };
>>
>> While there could be a concern that we are ungating all the clocks in
>
> Yes, I mentioned that but OTOH it will be even more dangerous to gate
> clocks that should remain enabled so I used the register default values.
>
>> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
>> this on Peach Pi, S2R works fine.
>>
>
> Thanks a lot for testing, does it mean I can add your Tested-by then when
> posting it as a proper patch? I'll wait for Tomasz to comment before though.

Tested-by: Abhilash Kesavan <a.kesavan@samsung.com>.

Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:

[...]

> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.

[...]

> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Tested-by: Kevin Hilman <khilman@linaro.org>

on exynos5800-peach-pi

Kevin

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:

[...]

> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.

[...]

> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Tested-by: Kevin Hilman <khilman@linaro.org>

on exynos5800-peach-pi

Kevin

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:

[...]

> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.

[...]

> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Tested-by: Kevin Hilman <khilman@linaro.org>

on exynos5800-peach-pi

Kevin

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

2015-04-07 16:11 GMT+02:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
> --
> 2.1.4

Looks good to me. You can consider this Acked-by, as long as Sylwester
is not opposed to this approach.

Best regards,
Tomasz

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

2015-04-07 16:11 GMT+02:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
> --
> 2.1.4

Looks good to me. You can consider this Acked-by, as long as Sylwester
is not opposed to this approach.

Best regards,
Tomasz

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Tomasz Figa]

2015-04-07 16:11 GMT+02:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump exynos5420_set_clksrc[] = {
>         { .offset = SRC_MASK_PERIC0,            .value = 0x11111110, },
>         { .offset = SRC_MASK_PERIC1,            .value = 0x11111100, },
>         { .offset = SRC_MASK_ISP,               .value = 0x11111000, },
> +       { .offset = GATE_BUS_TOP,               .value = 0xffffffff, },
>         { .offset = GATE_BUS_DISP1,             .value = 0xffffffff, },
>         { .offset = GATE_IP_PERIC,              .value = 0xffffffff, },
>  };
> --
> 2.1.4

Looks good to me. You can consider this Acked-by, as long as Sylwester
is not opposed to this approach.

Best regards,
Tomasz

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

On 04/07/2015 11:28 PM, Tomasz Figa wrote:
> 
> Looks good to me. You can consider this Acked-by, as long as Sylwester
> is not opposed to this approach.
>

Thanks a lot, I've posted it as a proper patch now.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

On 04/07/2015 11:28 PM, Tomasz Figa wrote:
> 
> Looks good to me. You can consider this Acked-by, as long as Sylwester
> is not opposed to this approach.
>

Thanks a lot, I've posted it as a proper patch now.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Tomasz,

On 04/07/2015 11:28 PM, Tomasz Figa wrote:
> 
> Looks good to me. You can consider this Acked-by, as long as Sylwester
> is not opposed to this approach.
>

Thanks a lot, I've posted it as a proper patch now.
 
> Best regards,
> Tomasz
>

Best regards,
Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 4:29 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Abhilash,
>
> On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
>> Hi,
>>
>> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> Hello Sylwester,
>>>
>>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>>>> would be good if we could get more information on that. They are in the PMU
>>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>>>> from the documentation.
>>>>>
>>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>>
>>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>>
>>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>>> documentation I have. I guess you've got something newer than REV0.00?
>>>>
>>>
>>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>>
>>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>>> the same bits from 0 to 5 and then differ from there.
>>>
>>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>>> part of the PMU register address space.
>>>>>
>>>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>>
>>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>>> the camera subsystem. Such a dependency would be rather surprising.
>>>>
>>>
>>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>>
>>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>>> error in the doc I've since is suspicious that is the only difference
>>> between LPI_MASK0 and CG_STATUS0.
>>>
>>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>>> registers, before we start checking their value in the clock driver.
>>>>>>
>>>>>
>>>>> Indeed, we should really understand what the status on these registers
>>>>> means. Also is not clear from the docs how much time should be waited,
>>>>> how long until giving up, etc.
>>>>
>>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>>> related to these registers yet, except the address macro definitions
>>>> and debug traces in the power domains driver.
>>>>
>>>
>>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>>
>>>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>>
>>>>>
>>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>>> well but I didn't find a better way to solve this issue... another option
>>>>> is to have this workaround to solve the S2R issue while we figure out what
>>>>> the the state in the CG_STATUSx really mean.
>>>>
>>>> Let's try to diagnose the issue best we can, then we would choose the most
>>>> accurate bug fix.
>>>>
>>>
>>> Sounds good to me.
>>
>> Based on the earlier comments I was trying to isolate if:
>> 1) s2r fails because we gate aclk266_g2d (but it is one of those
>> clocks that needs to be always on prior to suspend).
>> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
>> are not 0 (thus not following the spec).
>>
>
> Thanks a lot for continue looking at this. I didn't have time to dig
> deeper on this since last week.
>
>> As I did not have access to the hardware guys who could possibly
>> confirm 1), I decided to
>> a) find a configuration where CG_STATUS0 allows gating of the
>> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
>> b) disable the aclk266_g2d clock using such a configuration.
>> c) check s2r.
>>
>> I found a configuration [1] which gave the following after boot-up:
>
> I think you forgot the reference for [1] right? Since with latest

Yes, looks like I missed that. There are the changes I had:

diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..3a9e21a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -379,6 +379,7 @@
                        #dma-cells = <1>;
                        #dma-channels = <8>;
                        #dma-requests = <1>;
+                       status = "disabled";
                };

                mdma1: mdma@11C10000 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 07d666c..38cb896 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -898,6 +898,7 @@ static struct samsung_gate_clock
exynos5x_gate_clks[] __initdata = {
        GATE(CLK_G2D, "g2d", "aclk333_g2d", GATE_IP_G2D, 3, 0, 0),
        GATE(CLK_SMMU_MDMA0, "smmu_mdma0", "aclk266_g2d", GATE_IP_G2D, 5, 0, 0),
        GATE(CLK_SMMU_G2D, "smmu_g2d", "aclk333_g2d", GATE_IP_G2D, 7, 0, 0),
+       GATE(CLK_SLIMSSS, "slimsss", "aclk266_g2d", GATE_IP_G2D, 12, 0, 0),

        GATE(0, "aclk200_fsys", "mout_user_aclk200_fsys",
                        GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 99da0d1..9459911 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -196,6 +196,7 @@
 #define CLK_ACLK432_CAM                518
 #define CLK_ACLK_FL1550_CAM    519
 #define CLK_ACLK550_CAM                520
+#define CLK_SLIMSSS            521

 /* mux clocks */
 #define CLK_MOUT_HDMI          640

These changes gave me CG_STATUS0[22:21] as 0. I noticed that of the 2
CG_STATUS0 bits one did not turn 0 even when the mdma0 clock was kept
on. I decided to add the clock slimsss as it was the other clock
sourced from aclk266_g2d and noticed that the other bits turned 0.

> linux-next (20150402) I got:
>
>> # devmem 0x10040914
>> 0xFD800014 (CG_STATUS0[22:21] is 0)
>
> # devmem 0x10040914
> 0xFFE00000 (CG_STATUS0[22:21] is 1)
>
>> # devmem 0x10020700
>> 0xC6F8DE9F (aclk266_g2d is enabled)
>>
>> At this point s2r works.
>>
>> I rebooted the board with the same config as above and then disabled
>> aclk266_g2d.
>>
>> # devmem 0x10020700 32 0xC6F8DE9D
>> # devmem 0x10020700
>> 0xC6F8DE9D (aclk266_g2d is disabled)
>> # devmem 0x10040914
>> 0xFD800014
>>
>> and tried s2r - It fails.
>>
>> From the results, disabling the clock seems to cause the issue rather
>> than the CG_STATUS violation. This is all a little confusing, so
>> please let me know if I have missed something.
>>
>
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
>
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...

Yes, though it increasingly looks like aclk266_g2d needs to stay ON
and we should use your patch that keeps it enabled prior to suspend.

Regards,
Abhilash
>
> I can re-post my patches to keep aclk266_g2d enabled during suspend
> in the clk driver if that is the least bad option. But it would be
> great to solve this issue otherwise S2R will remain to be broken for
> Exynos5420 which will be really sad.
>
>> Regards,
>> Abhilash
>>
>
> Best regards,
> Javier

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 4:29 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Abhilash,
>
> On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
>> Hi,
>>
>> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> Hello Sylwester,
>>>
>>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>>>> would be good if we could get more information on that. They are in the PMU
>>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>>>> from the documentation.
>>>>>
>>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>>
>>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>>
>>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>>> documentation I have. I guess you've got something newer than REV0.00?
>>>>
>>>
>>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>>
>>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>>> the same bits from 0 to 5 and then differ from there.
>>>
>>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>>> part of the PMU register address space.
>>>>>
>>>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>>
>>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>>> the camera subsystem. Such a dependency would be rather surprising.
>>>>
>>>
>>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>>
>>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>>> error in the doc I've since is suspicious that is the only difference
>>> between LPI_MASK0 and CG_STATUS0.
>>>
>>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>>> registers, before we start checking their value in the clock driver.
>>>>>>
>>>>>
>>>>> Indeed, we should really understand what the status on these registers
>>>>> means. Also is not clear from the docs how much time should be waited,
>>>>> how long until giving up, etc.
>>>>
>>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>>> related to these registers yet, except the address macro definitions
>>>> and debug traces in the power domains driver.
>>>>
>>>
>>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>>
>>>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>>
>>>>>
>>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>>> well but I didn't find a better way to solve this issue... another option
>>>>> is to have this workaround to solve the S2R issue while we figure out what
>>>>> the the state in the CG_STATUSx really mean.
>>>>
>>>> Let's try to diagnose the issue best we can, then we would choose the most
>>>> accurate bug fix.
>>>>
>>>
>>> Sounds good to me.
>>
>> Based on the earlier comments I was trying to isolate if:
>> 1) s2r fails because we gate aclk266_g2d (but it is one of those
>> clocks that needs to be always on prior to suspend).
>> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
>> are not 0 (thus not following the spec).
>>
>
> Thanks a lot for continue looking at this. I didn't have time to dig
> deeper on this since last week.
>
>> As I did not have access to the hardware guys who could possibly
>> confirm 1), I decided to
>> a) find a configuration where CG_STATUS0 allows gating of the
>> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
>> b) disable the aclk266_g2d clock using such a configuration.
>> c) check s2r.
>>
>> I found a configuration [1] which gave the following after boot-up:
>
> I think you forgot the reference for [1] right? Since with latest

Yes, looks like I missed that. There are the changes I had:

diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..3a9e21a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -379,6 +379,7 @@
                        #dma-cells = <1>;
                        #dma-channels = <8>;
                        #dma-requests = <1>;
+                       status = "disabled";
                };

                mdma1: mdma at 11C10000 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 07d666c..38cb896 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -898,6 +898,7 @@ static struct samsung_gate_clock
exynos5x_gate_clks[] __initdata = {
        GATE(CLK_G2D, "g2d", "aclk333_g2d", GATE_IP_G2D, 3, 0, 0),
        GATE(CLK_SMMU_MDMA0, "smmu_mdma0", "aclk266_g2d", GATE_IP_G2D, 5, 0, 0),
        GATE(CLK_SMMU_G2D, "smmu_g2d", "aclk333_g2d", GATE_IP_G2D, 7, 0, 0),
+       GATE(CLK_SLIMSSS, "slimsss", "aclk266_g2d", GATE_IP_G2D, 12, 0, 0),

        GATE(0, "aclk200_fsys", "mout_user_aclk200_fsys",
                        GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 99da0d1..9459911 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -196,6 +196,7 @@
 #define CLK_ACLK432_CAM                518
 #define CLK_ACLK_FL1550_CAM    519
 #define CLK_ACLK550_CAM                520
+#define CLK_SLIMSSS            521

 /* mux clocks */
 #define CLK_MOUT_HDMI          640

These changes gave me CG_STATUS0[22:21] as 0. I noticed that of the 2
CG_STATUS0 bits one did not turn 0 even when the mdma0 clock was kept
on. I decided to add the clock slimsss as it was the other clock
sourced from aclk266_g2d and noticed that the other bits turned 0.

> linux-next (20150402) I got:
>
>> # devmem 0x10040914
>> 0xFD800014 (CG_STATUS0[22:21] is 0)
>
> # devmem 0x10040914
> 0xFFE00000 (CG_STATUS0[22:21] is 1)
>
>> # devmem 0x10020700
>> 0xC6F8DE9F (aclk266_g2d is enabled)
>>
>> At this point s2r works.
>>
>> I rebooted the board with the same config as above and then disabled
>> aclk266_g2d.
>>
>> # devmem 0x10020700 32 0xC6F8DE9D
>> # devmem 0x10020700
>> 0xC6F8DE9D (aclk266_g2d is disabled)
>> # devmem 0x10040914
>> 0xFD800014
>>
>> and tried s2r - It fails.
>>
>> From the results, disabling the clock seems to cause the issue rather
>> than the CG_STATUS violation. This is all a little confusing, so
>> please let me know if I have missed something.
>>
>
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
>
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...

Yes, though it increasingly looks like aclk266_g2d needs to stay ON
and we should use your patch that keeps it enabled prior to suspend.

Regards,
Abhilash
>
> I can re-post my patches to keep aclk266_g2d enabled during suspend
> in the clk driver if that is the least bad option. But it would be
> great to solve this issue otherwise S2R will remain to be broken for
> Exynos5420 which will be really sad.
>
>> Regards,
>> Abhilash
>>
>
> Best regards,
> Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Javier,

On Tue, Apr 7, 2015 at 4:29 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> Hello Abhilash,
>
> On 04/02/2015 02:22 PM, Abhilash Kesavan wrote:
>> Hi,
>>
>> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> Hello Sylwester,
>>>
>>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote:
>>>> On 01/04/15 13:44, Javier Martinez Canillas wrote:
>>>>> On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote:
>>>>>> It's not clear what subsystems affect state of the CG_STATUSx registers, it
>>>>>> would be good if we could get more information on that. They are in the PMU
>>>>>> block and are related to LPI (Low Power Interface handshaking), but what
>>>>>> subsystems/peripheral blocks exactly are associated with them it's not clear
>>>>>> from the documentation.
>>>>>
>>>>> Yes, I've been looking at the docs again and found out a couple of things:
>>>>>
>>>>> * Each GC_STATUSx register bit is associated with an IP hw block
>>>>> * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1)
>>>>>   and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2)
>>>>
>>>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to
>>>> documentation I have. I guess you've got something newer than REV0.00?
>>>>
>>>
>>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits
>>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned
>>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP).
>>>
>>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have
>>> the same bits from 0 to 5 and then differ from there.
>>>
>>>>> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are
>>>>> part of the PMU register address space.
>>>>>
>>>>> In the particular case of aclk266_g2d, the doc says that the clock can only
>>>>> be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated
>>>>> with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules.
>>>>
>>>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register
>>>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e.
>>>> the camera subsystem. Such a dependency would be rather surprising.
>>>>
>>>
>>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but
>>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM).
>>>
>>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't
>>> have a corresponding bit in CG_STATUS0. But I don't know if that is an
>>> error in the doc I've since is suspicious that is the only difference
>>> between LPI_MASK0 and CG_STATUS0.
>>>
>>>>>> I think it's essential to understand what triggers changes in CG_STATUSx
>>>>>> registers, before we start checking their value in the clock driver.
>>>>>>
>>>>>
>>>>> Indeed, we should really understand what the status on these registers
>>>>> means. Also is not clear from the docs how much time should be waited,
>>>>> how long until giving up, etc.
>>>>
>>>> Exactly, I checked some kernels from http://opensource.samsung.com
>>>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything
>>>> related to these registers yet, except the address macro definitions
>>>> and debug traces in the power domains driver.
>>>>
>>>
>>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything.
>>>
>>>>>> Also it might be that there are indeed some clocks which must stay enabled
>>>>>> over suspend/resume cycle, then the approach with enabling/disabling clocks
>>>>>> in the clock driver might not be such a hack as it looks at first sight.
>>>>>>
>>>>>
>>>>> Having a clock driver to both a provider and consumer feels hacky to me as
>>>>> well but I didn't find a better way to solve this issue... another option
>>>>> is to have this workaround to solve the S2R issue while we figure out what
>>>>> the the state in the CG_STATUSx really mean.
>>>>
>>>> Let's try to diagnose the issue best we can, then we would choose the most
>>>> accurate bug fix.
>>>>
>>>
>>> Sounds good to me.
>>
>> Based on the earlier comments I was trying to isolate if:
>> 1) s2r fails because we gate aclk266_g2d (but it is one of those
>> clocks that needs to be always on prior to suspend).
>> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits
>> are not 0 (thus not following the spec).
>>
>
> Thanks a lot for continue looking at this. I didn't have time to dig
> deeper on this since last week.
>
>> As I did not have access to the hardware guys who could possibly
>> confirm 1), I decided to
>> a) find a configuration where CG_STATUS0 allows gating of the
>> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0).
>> b) disable the aclk266_g2d clock using such a configuration.
>> c) check s2r.
>>
>> I found a configuration [1] which gave the following after boot-up:
>
> I think you forgot the reference for [1] right? Since with latest

Yes, looks like I missed that. There are the changes I had:

diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..3a9e21a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -379,6 +379,7 @@
                        #dma-cells = <1>;
                        #dma-channels = <8>;
                        #dma-requests = <1>;
+                       status = "disabled";
                };

                mdma1: mdma@11C10000 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 07d666c..38cb896 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -898,6 +898,7 @@ static struct samsung_gate_clock
exynos5x_gate_clks[] __initdata = {
        GATE(CLK_G2D, "g2d", "aclk333_g2d", GATE_IP_G2D, 3, 0, 0),
        GATE(CLK_SMMU_MDMA0, "smmu_mdma0", "aclk266_g2d", GATE_IP_G2D, 5, 0, 0),
        GATE(CLK_SMMU_G2D, "smmu_g2d", "aclk333_g2d", GATE_IP_G2D, 7, 0, 0),
+       GATE(CLK_SLIMSSS, "slimsss", "aclk266_g2d", GATE_IP_G2D, 12, 0, 0),

        GATE(0, "aclk200_fsys", "mout_user_aclk200_fsys",
                        GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 99da0d1..9459911 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -196,6 +196,7 @@
 #define CLK_ACLK432_CAM                518
 #define CLK_ACLK_FL1550_CAM    519
 #define CLK_ACLK550_CAM                520
+#define CLK_SLIMSSS            521

 /* mux clocks */
 #define CLK_MOUT_HDMI          640

These changes gave me CG_STATUS0[22:21] as 0. I noticed that of the 2
CG_STATUS0 bits one did not turn 0 even when the mdma0 clock was kept
on. I decided to add the clock slimsss as it was the other clock
sourced from aclk266_g2d and noticed that the other bits turned 0.

> linux-next (20150402) I got:
>
>> # devmem 0x10040914
>> 0xFD800014 (CG_STATUS0[22:21] is 0)
>
> # devmem 0x10040914
> 0xFFE00000 (CG_STATUS0[22:21] is 1)
>
>> # devmem 0x10020700
>> 0xC6F8DE9F (aclk266_g2d is enabled)
>>
>> At this point s2r works.
>>
>> I rebooted the board with the same config as above and then disabled
>> aclk266_g2d.
>>
>> # devmem 0x10020700 32 0xC6F8DE9D
>> # devmem 0x10020700
>> 0xC6F8DE9D (aclk266_g2d is disabled)
>> # devmem 0x10040914
>> 0xFD800014
>>
>> and tried s2r - It fails.
>>
>> From the results, disabling the clock seems to cause the issue rather
>> than the CG_STATUS violation. This is all a little confusing, so
>> please let me know if I have missed something.
>>
>
> So IIUC the CG_STATUS0 bits were a red herring and the real problem
> is that the aclk266_g2d needs to be enabled during suspend (although
> we still don't know why).
>
> It seems were are at a dead end now. Without being able to ask the HW
> Samsung folks we would never know what's going on here...

Yes, though it increasingly looks like aclk266_g2d needs to stay ON
and we should use your patch that keeps it enabled prior to suspend.

Regards,
Abhilash
>
> I can re-post my patches to keep aclk266_g2d enabled during suspend
> in the clk driver if that is the least bad option. But it would be
> great to solve this issue otherwise S2R will remain to be broken for
> Exynos5420 which will be really sad.
>
>> Regards,
>> Abhilash
>>
>
> Best regards,
> Javier

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/07/2015 04:11 PM, Abhilash Kesavan wrote:
> 
> Yes, though it increasingly looks like aclk266_g2d needs to stay ON
> and we should use your patch that keeps it enabled prior to suspend.
>

Indeed, could you please give me some feedback on the latest RFC patch
I shared [0] on this thread according to Tomasz comments?
 
> Regards,
> Abhilash
>>

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2015/4/7/537

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/07/2015 04:11 PM, Abhilash Kesavan wrote:
> 
> Yes, though it increasingly looks like aclk266_g2d needs to stay ON
> and we should use your patch that keeps it enabled prior to suspend.
>

Indeed, could you please give me some feedback on the latest RFC patch
I shared [0] on this thread according to Tomasz comments?
 
> Regards,
> Abhilash
>>

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2015/4/7/537

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Javier Martinez Canillas]

Hello Abhilash,

On 04/07/2015 04:11 PM, Abhilash Kesavan wrote:
> 
> Yes, though it increasingly looks like aclk266_g2d needs to stay ON
> and we should use your patch that keeps it enabled prior to suspend.
>

Indeed, could you please give me some feedback on the latest RFC patch
I shared [0] on this thread according to Tomasz comments?
 
> Regards,
> Abhilash
>>

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2015/4/7/537

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:

[...]

> Unfortunately I don't fully understand why this clock needs to be
> enabled. It would be good if someone at Samsung can explain in more
> detail what the real problem really is.

+1

Maybe Abhilash can shed some light here?

We really should know *why* this is needed because having the fix in the
clock driver just doesn't seem right.  It seems like the DMA driver
should be managing this clock.

Kevin

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:

[...]

> Unfortunately I don't fully understand why this clock needs to be
> enabled. It would be good if someone at Samsung can explain in more
> detail what the real problem really is.

+1

Maybe Abhilash can shed some light here?

We really should know *why* this is needed because having the fix in the
clock driver just doesn't seem right.  It seems like the DMA driver
should be managing this clock.

Kevin

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:

[...]

> Unfortunately I don't fully understand why this clock needs to be
> enabled. It would be good if someone at Samsung can explain in more
> detail what the real problem really is.

+1

Maybe Abhilash can shed some light here?

We really should know *why* this is needed because having the fix in the
clock driver just doesn't seem right.  It seems like the DMA driver
should be managing this clock.

Kevin

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Kevin,

On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>
> [...]
>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in more
>> detail what the real problem really is.
>
> +1
>
> Maybe Abhilash can shed some light here?
>
> We really should know *why* this is needed because having the fix in the
> clock driver just doesn't seem right.  It seems like the DMA driver
> should be managing this clock.

I think my last mail might not have reached you (was accidentally sent
as html). We are gating the aclk266_g2d clock without checking the
CG_STATUS0 register bits as specified in the UM. It looks like we need
to keep several clocks alive or gate them only after checking the
CG_STATUSx register bits.

Regards,
Abhilash

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Kevin,

On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>
> [...]
>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in more
>> detail what the real problem really is.
>
> +1
>
> Maybe Abhilash can shed some light here?
>
> We really should know *why* this is needed because having the fix in the
> clock driver just doesn't seem right.  It seems like the DMA driver
> should be managing this clock.

I think my last mail might not have reached you (was accidentally sent
as html). We are gating the aclk266_g2d clock without checking the
CG_STATUS0 register bits as specified in the UM. It looks like we need
to keep several clocks alive or gate them only after checking the
CG_STATUSx register bits.

Regards,
Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Abhilash Kesavan]

Hi Kevin,

On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>
> [...]
>
>> Unfortunately I don't fully understand why this clock needs to be
>> enabled. It would be good if someone at Samsung can explain in more
>> detail what the real problem really is.
>
> +1
>
> Maybe Abhilash can shed some light here?
>
> We really should know *why* this is needed because having the fix in the
> clock driver just doesn't seem right.  It seems like the DMA driver
> should be managing this clock.

I think my last mail might not have reached you (was accidentally sent
as html). We are gating the aclk266_g2d clock without checking the
CG_STATUS0 register bits as specified in the UM. It looks like we need
to keep several clocks alive or gate them only after checking the
CG_STATUSx register bits.

Regards,
Abhilash

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:

> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>>
>> [...]
>>
>>> Unfortunately I don't fully understand why this clock needs to be
>>> enabled. It would be good if someone at Samsung can explain in more
>>> detail what the real problem really is.
>>
>> +1
>>
>> Maybe Abhilash can shed some light here?
>>
>> We really should know *why* this is needed because having the fix in the
>> clock driver just doesn't seem right.  It seems like the DMA driver
>> should be managing this clock.
>
> I think my last mail might not have reached you (was accidentally sent
> as html). 

Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
research and reporting back.

> We are gating the aclk266_g2d clock without checking the
> CG_STATUS0 register bits as specified in the UM. It looks like we need
> to keep several clocks alive or gate them only after checking the
> CG_STATUSx register bits.

I dont' know much about this clock hardware, but to me it sounds like a
clock driver bug.  The suspend fix Javier is proposing would fix it, but
to me it sounds like the clock driver needs to actually start checking
these CG_STATUSx bits before gating clocks.

Otherwise, we might fix this current bug but a similar one will come and
bite us another day.

Kevin

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:

> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>>
>> [...]
>>
>>> Unfortunately I don't fully understand why this clock needs to be
>>> enabled. It would be good if someone at Samsung can explain in more
>>> detail what the real problem really is.
>>
>> +1
>>
>> Maybe Abhilash can shed some light here?
>>
>> We really should know *why* this is needed because having the fix in the
>> clock driver just doesn't seem right.  It seems like the DMA driver
>> should be managing this clock.
>
> I think my last mail might not have reached you (was accidentally sent
> as html). 

Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
research and reporting back.

> We are gating the aclk266_g2d clock without checking the
> CG_STATUS0 register bits as specified in the UM. It looks like we need
> to keep several clocks alive or gate them only after checking the
> CG_STATUSx register bits.

I dont' know much about this clock hardware, but to me it sounds like a
clock driver bug.  The suspend fix Javier is proposing would fix it, but
to me it sounds like the clock driver needs to actually start checking
these CG_STATUSx bits before gating clocks.

Otherwise, we might fix this current bug but a similar one will come and
bite us another day.

Kevin

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Kevin Hilman]

Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:

> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>>
>> [...]
>>
>>> Unfortunately I don't fully understand why this clock needs to be
>>> enabled. It would be good if someone at Samsung can explain in more
>>> detail what the real problem really is.
>>
>> +1
>>
>> Maybe Abhilash can shed some light here?
>>
>> We really should know *why* this is needed because having the fix in the
>> clock driver just doesn't seem right.  It seems like the DMA driver
>> should be managing this clock.
>
> I think my last mail might not have reached you (was accidentally sent
> as html). 

Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
research and reporting back.

> We are gating the aclk266_g2d clock without checking the
> CG_STATUS0 register bits as specified in the UM. It looks like we need
> to keep several clocks alive or gate them only after checking the
> CG_STATUSx register bits.

I dont' know much about this clock hardware, but to me it sounds like a
clock driver bug.  The suspend fix Javier is proposing would fix it, but
to me it sounds like the clock driver needs to actually start checking
these CG_STATUSx bits before gating clocks.

Otherwise, we might fix this current bug but a similar one will come and
bite us another day.

Kevin

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Krzysztof Kozlowski]

2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@kernel.org>:
> Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
>
>> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>>>
>>> [...]
>>>
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in more
>>>> detail what the real problem really is.
>>>
>>> +1
>>>
>>> Maybe Abhilash can shed some light here?
>>>
>>> We really should know *why* this is needed because having the fix in the
>>> clock driver just doesn't seem right.  It seems like the DMA driver
>>> should be managing this clock.
>>
>> I think my last mail might not have reached you (was accidentally sent
>> as html).
>
> Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> research and reporting back.
>
>> We are gating the aclk266_g2d clock without checking the
>> CG_STATUS0 register bits as specified in the UM. It looks like we need
>> to keep several clocks alive or gate them only after checking the
>> CG_STATUSx register bits.
>
> I dont' know much about this clock hardware, but to me it sounds like a
> clock driver bug.  The suspend fix Javier is proposing would fix it, but
> to me it sounds like the clock driver needs to actually start checking
> these CG_STATUSx bits before gating clocks.
>
> Otherwise, we might fix this current bug but a similar one will come and
> bite us another day.

Actually it looks kind a similar to issue with adma/mau_epll clocks:
https://lkml.org/lkml/2014/12/5/291

In that case runtime PM for pl330 caused adma clock to be gated. This
lead to gating its parent clock - mau_epll. The clock hierarchy is
strange for maudio domain. Basically mau_epll is needed to access
maudio clocks however these clocks are not children of mau_epll.

I think we should not enable the mdma0 but instead we should find the
proper parent which needs to be enabled.

Anyway it is kind of annoying (or funny if one has sense of black
humour) that two issues are exposed by runtime PM for pl330 driver.

Best regards,
Krzysztof

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Krzysztof Kozlowski]

2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@kernel.org>:
> Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
>
>> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>>>
>>> [...]
>>>
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in more
>>>> detail what the real problem really is.
>>>
>>> +1
>>>
>>> Maybe Abhilash can shed some light here?
>>>
>>> We really should know *why* this is needed because having the fix in the
>>> clock driver just doesn't seem right.  It seems like the DMA driver
>>> should be managing this clock.
>>
>> I think my last mail might not have reached you (was accidentally sent
>> as html).
>
> Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> research and reporting back.
>
>> We are gating the aclk266_g2d clock without checking the
>> CG_STATUS0 register bits as specified in the UM. It looks like we need
>> to keep several clocks alive or gate them only after checking the
>> CG_STATUSx register bits.
>
> I dont' know much about this clock hardware, but to me it sounds like a
> clock driver bug.  The suspend fix Javier is proposing would fix it, but
> to me it sounds like the clock driver needs to actually start checking
> these CG_STATUSx bits before gating clocks.
>
> Otherwise, we might fix this current bug but a similar one will come and
> bite us another day.

Actually it looks kind a similar to issue with adma/mau_epll clocks:
https://lkml.org/lkml/2014/12/5/291

In that case runtime PM for pl330 caused adma clock to be gated. This
lead to gating its parent clock - mau_epll. The clock hierarchy is
strange for maudio domain. Basically mau_epll is needed to access
maudio clocks however these clocks are not children of mau_epll.

I think we should not enable the mdma0 but instead we should find the
proper parent which needs to be enabled.

Anyway it is kind of annoying (or funny if one has sense of black
humour) that two issues are exposed by runtime PM for pl330 driver.

Best regards,
Krzysztof

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Krzysztof Kozlowski]

2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@kernel.org>:
> Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
>
>> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
>>>
>>> [...]
>>>
>>>> Unfortunately I don't fully understand why this clock needs to be
>>>> enabled. It would be good if someone at Samsung can explain in more
>>>> detail what the real problem really is.
>>>
>>> +1
>>>
>>> Maybe Abhilash can shed some light here?
>>>
>>> We really should know *why* this is needed because having the fix in the
>>> clock driver just doesn't seem right.  It seems like the DMA driver
>>> should be managing this clock.
>>
>> I think my last mail might not have reached you (was accidentally sent
>> as html).
>
> Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> research and reporting back.
>
>> We are gating the aclk266_g2d clock without checking the
>> CG_STATUS0 register bits as specified in the UM. It looks like we need
>> to keep several clocks alive or gate them only after checking the
>> CG_STATUSx register bits.
>
> I dont' know much about this clock hardware, but to me it sounds like a
> clock driver bug.  The suspend fix Javier is proposing would fix it, but
> to me it sounds like the clock driver needs to actually start checking
> these CG_STATUSx bits before gating clocks.
>
> Otherwise, we might fix this current bug but a similar one will come and
> bite us another day.

Actually it looks kind a similar to issue with adma/mau_epll clocks:
https://lkml.org/lkml/2014/12/5/291

In that case runtime PM for pl330 caused adma clock to be gated. This
lead to gating its parent clock - mau_epll. The clock hierarchy is
strange for maudio domain. Basically mau_epll is needed to access
maudio clocks however these clocks are not children of mau_epll.

I think we should not enable the mdma0 but instead we should find the
proper parent which needs to be enabled.

Anyway it is kind of annoying (or funny if one has sense of black
humour) that two issues are exposed by runtime PM for pl330 driver.

Best regards,
Krzysztof

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Michael Turquette]

Quoting Krzysztof Kozlowski (2015-04-01 02:16:08)
> 2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@kernel.org>:
> > Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
> >
> >> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
> >>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
> >>>
> >>> [...]
> >>>
> >>>> Unfortunately I don't fully understand why this clock needs to be
> >>>> enabled. It would be good if someone at Samsung can explain in more
> >>>> detail what the real problem really is.
> >>>
> >>> +1
> >>>
> >>> Maybe Abhilash can shed some light here?
> >>>
> >>> We really should know *why* this is needed because having the fix in the
> >>> clock driver just doesn't seem right.  It seems like the DMA driver
> >>> should be managing this clock.
> >>
> >> I think my last mail might not have reached you (was accidentally sent
> >> as html).
> >
> > Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> > research and reporting back.
> >
> >> We are gating the aclk266_g2d clock without checking the
> >> CG_STATUS0 register bits as specified in the UM. It looks like we need
> >> to keep several clocks alive or gate them only after checking the
> >> CG_STATUSx register bits.
> >
> > I dont' know much about this clock hardware, but to me it sounds like a
> > clock driver bug.  The suspend fix Javier is proposing would fix it, but
> > to me it sounds like the clock driver needs to actually start checking
> > these CG_STATUSx bits before gating clocks.
> >
> > Otherwise, we might fix this current bug but a similar one will come and
> > bite us another day.
> 
> Actually it looks kind a similar to issue with adma/mau_epll clocks:
> https://lkml.org/lkml/2014/12/5/291
> 
> In that case runtime PM for pl330 caused adma clock to be gated. This
> lead to gating its parent clock - mau_epll. The clock hierarchy is
> strange for maudio domain. Basically mau_epll is needed to access
> maudio clocks however these clocks are not children of mau_epll.

This sounds like an interface clock. It must be enabled for you touch
registers across a bus/interconnect.

For this type of clock is perfectly correct for the driver to enable it
in addition to any functional clocks (e.g. maudio clocks).

There are many instances where a driver must enable an interface clock
(iclk) and a functional clock (fclk) and this isn't an issue of the
driver knowing the clock topology, but instead knowing it's operational
requirements.

Just to make life more confusing, it might also be appropriate for the
clock driver to manage turning on the interface clocks if this is
required to touching the functional clocks. In general the register
address space is used to determine which IP "owns" such behavior.

Regards,
Mike

> 
> I think we should not enable the mdma0 but instead we should find the
> proper parent which needs to be enabled.
> 
> Anyway it is kind of annoying (or funny if one has sense of black
> humour) that two issues are exposed by runtime PM for pl330 driver.
> 
> Best regards,
> Krzysztof

[RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Michael Turquette]

Quoting Krzysztof Kozlowski (2015-04-01 02:16:08)
> 2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@kernel.org>:
> > Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
> >
> >> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
> >>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
> >>>
> >>> [...]
> >>>
> >>>> Unfortunately I don't fully understand why this clock needs to be
> >>>> enabled. It would be good if someone at Samsung can explain in more
> >>>> detail what the real problem really is.
> >>>
> >>> +1
> >>>
> >>> Maybe Abhilash can shed some light here?
> >>>
> >>> We really should know *why* this is needed because having the fix in the
> >>> clock driver just doesn't seem right.  It seems like the DMA driver
> >>> should be managing this clock.
> >>
> >> I think my last mail might not have reached you (was accidentally sent
> >> as html).
> >
> > Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> > research and reporting back.
> >
> >> We are gating the aclk266_g2d clock without checking the
> >> CG_STATUS0 register bits as specified in the UM. It looks like we need
> >> to keep several clocks alive or gate them only after checking the
> >> CG_STATUSx register bits.
> >
> > I dont' know much about this clock hardware, but to me it sounds like a
> > clock driver bug.  The suspend fix Javier is proposing would fix it, but
> > to me it sounds like the clock driver needs to actually start checking
> > these CG_STATUSx bits before gating clocks.
> >
> > Otherwise, we might fix this current bug but a similar one will come and
> > bite us another day.
> 
> Actually it looks kind a similar to issue with adma/mau_epll clocks:
> https://lkml.org/lkml/2014/12/5/291
> 
> In that case runtime PM for pl330 caused adma clock to be gated. This
> lead to gating its parent clock - mau_epll. The clock hierarchy is
> strange for maudio domain. Basically mau_epll is needed to access
> maudio clocks however these clocks are not children of mau_epll.

This sounds like an interface clock. It must be enabled for you touch
registers across a bus/interconnect.

For this type of clock is perfectly correct for the driver to enable it
in addition to any functional clocks (e.g. maudio clocks).

There are many instances where a driver must enable an interface clock
(iclk) and a functional clock (fclk) and this isn't an issue of the
driver knowing the clock topology, but instead knowing it's operational
requirements.

Just to make life more confusing, it might also be appropriate for the
clock driver to manage turning on the interface clocks if this is
required to touching the functional clocks. In general the register
address space is used to determine which IP "owns" such behavior.

Regards,
Mike

> 
> I think we should not enable the mdma0 but instead we should find the
> proper parent which needs to be enabled.
> 
> Anyway it is kind of annoying (or funny if one has sense of black
> humour) that two issues are exposed by runtime PM for pl330 driver.
> 
> Best regards,
> Krzysztof

Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend

[Michael Turquette]

Quoting Krzysztof Kozlowski (2015-04-01 02:16:08)
> 2015-04-01 6:03 GMT+02:00 Kevin Hilman <khilman@kernel.org>:
> > Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
> >
> >> On Wed, Apr 1, 2015 at 2:32 AM, Kevin Hilman <khilman@kernel.org> wrote:
> >>> Javier Martinez Canillas <javier.martinez@collabora.co.uk> writes:
> >>>
> >>> [...]
> >>>
> >>>> Unfortunately I don't fully understand why this clock needs to be
> >>>> enabled. It would be good if someone at Samsung can explain in more
> >>>> detail what the real problem really is.
> >>>
> >>> +1
> >>>
> >>> Maybe Abhilash can shed some light here?
> >>>
> >>> We really should know *why* this is needed because having the fix in the
> >>> clock driver just doesn't seem right.  It seems like the DMA driver
> >>> should be managing this clock.
> >>
> >> I think my last mail might not have reached you (was accidentally sent
> >> as html).
> >
> > Yeah, I saw it a bit later in Javier's reply.  Thanks for doing the
> > research and reporting back.
> >
> >> We are gating the aclk266_g2d clock without checking the
> >> CG_STATUS0 register bits as specified in the UM. It looks like we need
> >> to keep several clocks alive or gate them only after checking the
> >> CG_STATUSx register bits.
> >
> > I dont' know much about this clock hardware, but to me it sounds like a
> > clock driver bug.  The suspend fix Javier is proposing would fix it, but
> > to me it sounds like the clock driver needs to actually start checking
> > these CG_STATUSx bits before gating clocks.
> >
> > Otherwise, we might fix this current bug but a similar one will come and
> > bite us another day.
> 
> Actually it looks kind a similar to issue with adma/mau_epll clocks:
> https://lkml.org/lkml/2014/12/5/291
> 
> In that case runtime PM for pl330 caused adma clock to be gated. This
> lead to gating its parent clock - mau_epll. The clock hierarchy is
> strange for maudio domain. Basically mau_epll is needed to access
> maudio clocks however these clocks are not children of mau_epll.

This sounds like an interface clock. It must be enabled for you touch
registers across a bus/interconnect.

For this type of clock is perfectly correct for the driver to enable it
in addition to any functional clocks (e.g. maudio clocks).

There are many instances where a driver must enable an interface clock
(iclk) and a functional clock (fclk) and this isn't an issue of the
driver knowing the clock topology, but instead knowing it's operational
requirements.

Just to make life more confusing, it might also be appropriate for the
clock driver to manage turning on the interface clocks if this is
required to touching the functional clocks. In general the register
address space is used to determine which IP "owns" such behavior.

Regards,
Mike

> 
> I think we should not enable the mdma0 but instead we should find the
> proper parent which needs to be enabled.
> 
> Anyway it is kind of annoying (or funny if one has sense of black
> humour) that two issues are exposed by runtime PM for pl330 driver.
> 
> Best regards,
> Krzysztof