* [RFC PATCH v3 0/2] ARM: EXYNOS: Fix Suspend-to-RAM on Exynos5420 @ 2015-03-30 15:53 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 15:53 UTC (permalink / raw) To: Stephen Boyd Cc: Mike Turquette, Sylwester Nawrocki, Tomasz Figa, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 0/2] ARM: EXYNOS: Fix Suspend-to-RAM on Exynos5420 @ 2015-03-30 15:53 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 15:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-03-30 15:53 ` Javier Martinez Canillas @ 2015-03-30 15:53 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 15:53 UTC (permalink / raw) To: Stephen Boyd Cc: Mike Turquette, Sylwester Nawrocki, Tomasz Figa, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-30 15:53 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 15:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-03-30 15:53 ` Javier Martinez Canillas (?) @ 2015-03-30 16:02 ` Tomasz Figa -1 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-03-30 16:02 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-30 16:02 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-03-30 16:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-30 16:02 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-03-30 16:02 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-03-30 16:02 ` Tomasz Figa (?) @ 2015-03-30 16:08 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 16:08 UTC (permalink / raw) To: Tomasz Figa Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-30 16:08 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 16:08 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-30 16:08 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 16:08 UTC (permalink / raw) To: Tomasz Figa Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-03-30 16:08 ` Javier Martinez Canillas (?) @ 2015-03-31 1:40 ` Michael Turquette -1 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-03-31 1:40 UTC (permalink / raw) To: Javier Martinez Canillas, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-31 1:40 ` Michael Turquette 0 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-03-31 1:40 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-31 1:40 ` Michael Turquette 0 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-03-31 1:40 UTC (permalink / raw) To: Javier Martinez Canillas, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-03-31 1:40 ` Michael Turquette (?) @ 2015-03-31 8:59 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-31 8:59 UTC (permalink / raw) To: Michael Turquette, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, Tomeu Vizoso +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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-31 8:59 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-31 8:59 UTC (permalink / raw) To: linux-arm-kernel +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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-03-31 8:59 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-31 8:59 UTC (permalink / raw) To: Michael Turquette, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, Tomeu Vizoso +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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-03-31 8:59 ` Javier Martinez Canillas (?) @ 2015-04-01 1:29 ` Michael Turquette -1 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-04-01 1:29 UTC (permalink / raw) To: Javier Martinez Canillas, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, Tomeu Vizoso 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-04-01 1:29 ` Michael Turquette 0 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-04-01 1:29 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-04-01 1:29 ` Michael Turquette 0 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-04-01 1:29 UTC (permalink / raw) To: Javier Martinez Canillas, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, Tomeu Vizoso 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function 2015-04-01 1:29 ` Michael Turquette (?) @ 2015-04-01 8:26 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 8:26 UTC (permalink / raw) To: Michael Turquette, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, Tomeu Vizoso 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-04-01 8:26 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 8:26 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function @ 2015-04-01 8:26 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 8:26 UTC (permalink / raw) To: Michael Turquette, Tomasz Figa Cc: Stephen Boyd, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, Tomeu Vizoso 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-03-30 15:53 ` Javier Martinez Canillas @ 2015-03-30 15:53 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 15:53 UTC (permalink / raw) To: Stephen Boyd Cc: Mike Turquette, Sylwester Nawrocki, Tomasz Figa, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-30 15:53 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 15:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-03-30 15:53 ` Javier Martinez Canillas (?) @ 2015-03-30 16:07 ` Tomasz Figa -1 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-03-30 16:07 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-30 16:07 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-03-30 16:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-30 16:07 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-03-30 16:07 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-03-30 16:07 ` Tomasz Figa (?) @ 2015-03-30 16:16 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 16:16 UTC (permalink / raw) To: Tomasz Figa Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-30 16:16 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 16:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-30 16:16 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-30 16:16 UTC (permalink / raw) To: Tomasz Figa Cc: Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
[parent not found: <CAM4voanL3A=dS8Z-ovi_-EDi9ctyaxZkvjajp+3ZjyNAnqR1aQ@mail.gmail.com>]
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend [not found] ` <CAM4voanL3A=dS8Z-ovi_-EDi9ctyaxZkvjajp+3ZjyNAnqR1aQ@mail.gmail.com> 2015-03-31 20:00 ` Javier Martinez Canillas @ 2015-03-31 20:00 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-31 20:00 UTC (permalink / raw) To: Abhilash Kesavan Cc: Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-31 20:00 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-31 20:00 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-31 20:00 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-03-31 20:00 UTC (permalink / raw) To: Abhilash Kesavan Cc: Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-03-31 20:00 ` Javier Martinez Canillas (?) @ 2015-04-01 11:03 ` Sylwester Nawrocki -1 siblings, 0 replies; 99+ messages in thread From: Sylwester Nawrocki @ 2015-04-01 11:03 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 11:03 ` Sylwester Nawrocki 0 siblings, 0 replies; 99+ messages in thread From: Sylwester Nawrocki @ 2015-04-01 11:03 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 11:03 ` Sylwester Nawrocki 0 siblings, 0 replies; 99+ messages in thread From: Sylwester Nawrocki @ 2015-04-01 11:03 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 11:03 ` Sylwester Nawrocki (?) @ 2015-04-01 11:44 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 11:44 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 11:44 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 11:44 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 11:44 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 11:44 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 11:44 ` Javier Martinez Canillas (?) @ 2015-04-01 17:31 ` Sylwester Nawrocki -1 siblings, 0 replies; 99+ messages in thread From: Sylwester Nawrocki @ 2015-04-01 17:31 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 17:31 ` Sylwester Nawrocki 0 siblings, 0 replies; 99+ messages in thread From: Sylwester Nawrocki @ 2015-04-01 17:31 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 17:31 ` Sylwester Nawrocki 0 siblings, 0 replies; 99+ messages in thread From: Sylwester Nawrocki @ 2015-04-01 17:31 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 17:31 ` Sylwester Nawrocki (?) @ 2015-04-01 22:31 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 22:31 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 22:31 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 22:31 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 22:31 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-01 22:31 UTC (permalink / raw) To: Sylwester Nawrocki Cc: Abhilash Kesavan, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 22:31 ` Javier Martinez Canillas (?) @ 2015-04-02 12:22 ` Abhilash Kesavan -1 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-02 12:22 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-02 12:22 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-02 12:22 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-02 12:22 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-02 12:22 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-02 12:22 ` Abhilash Kesavan (?) @ 2015-04-07 10:59 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 10:59 UTC (permalink / raw) To: Abhilash Kesavan Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 10:59 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 10:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 10:59 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 10:59 UTC (permalink / raw) To: Abhilash Kesavan Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 10:59 ` Javier Martinez Canillas (?) @ 2015-04-07 11:56 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 11:56 UTC (permalink / raw) To: Abhilash Kesavan Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 11:56 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 11:56 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 11:56 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 11:56 UTC (permalink / raw) To: Abhilash Kesavan Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 11:56 ` Javier Martinez Canillas (?) @ 2015-04-07 12:46 ` Tomasz Figa -1 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-04-07 12:46 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Abhilash Kesavan, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 12:46 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-04-07 12:46 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 12:46 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-04-07 12:46 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Abhilash Kesavan, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 12:46 ` Tomasz Figa (?) @ 2015-04-07 14:11 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 14:11 UTC (permalink / raw) To: Tomasz Figa Cc: Abhilash Kesavan, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:11 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 14:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:11 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 14:11 UTC (permalink / raw) To: Tomasz Figa Cc: Abhilash Kesavan, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 14:11 ` Javier Martinez Canillas (?) @ 2015-04-07 14:38 ` Abhilash Kesavan -1 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-07 14:38 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:38 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-07 14:38 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:38 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-07 14:38 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 14:38 ` Abhilash Kesavan (?) @ 2015-04-07 15:00 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 15:00 UTC (permalink / raw) To: Abhilash Kesavan Cc: Tomasz Figa, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 15:00 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 15:00 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 15:00 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 15:00 UTC (permalink / raw) To: Abhilash Kesavan Cc: Tomasz Figa, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 15:00 ` Javier Martinez Canillas (?) @ 2015-04-08 1:50 ` Abhilash Kesavan -1 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-08 1:50 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-08 1:50 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-08 1:50 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-08 1:50 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-08 1:50 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 14:11 ` Javier Martinez Canillas (?) @ 2015-04-07 18:51 ` Kevin Hilman -1 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-04-07 18:51 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Abhilash Kesavan, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 18:51 ` Kevin Hilman 0 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-04-07 18:51 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 18:51 ` Kevin Hilman 0 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-04-07 18:51 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Abhilash Kesavan, Sylwester Nawrocki, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 14:11 ` Javier Martinez Canillas (?) @ 2015-04-07 21:28 ` Tomasz Figa -1 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-04-07 21:28 UTC (permalink / raw) To: Javier Martinez Canillas, Sylwester Nawrocki Cc: Abhilash Kesavan, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 21:28 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-04-07 21:28 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 21:28 ` Tomasz Figa 0 siblings, 0 replies; 99+ messages in thread From: Tomasz Figa @ 2015-04-07 21:28 UTC (permalink / raw) To: Javier Martinez Canillas, Sylwester Nawrocki Cc: Abhilash Kesavan, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 21:28 ` Tomasz Figa (?) @ 2015-04-08 5:36 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-08 5:36 UTC (permalink / raw) To: Tomasz Figa, Sylwester Nawrocki Cc: Abhilash Kesavan, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-08 5:36 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-08 5:36 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-08 5:36 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-08 5:36 UTC (permalink / raw) To: Tomasz Figa, Sylwester Nawrocki Cc: Abhilash Kesavan, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 10:59 ` Javier Martinez Canillas (?) @ 2015-04-07 14:11 ` Abhilash Kesavan -1 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-07 14:11 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:11 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-07 14:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:11 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-07 14:11 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-07 14:11 ` Abhilash Kesavan (?) @ 2015-04-07 14:26 ` Javier Martinez Canillas -1 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 14:26 UTC (permalink / raw) To: Abhilash Kesavan Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:26 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 14:26 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-07 14:26 ` Javier Martinez Canillas 0 siblings, 0 replies; 99+ messages in thread From: Javier Martinez Canillas @ 2015-04-07 14:26 UTC (permalink / raw) To: Abhilash Kesavan Cc: Sylwester Nawrocki, Tomasz Figa, Stephen Boyd, Mike Turquette, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Kevin Hilman, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-03-30 16:16 ` Javier Martinez Canillas (?) @ 2015-03-31 21:02 ` Kevin Hilman -1 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-03-31 21:02 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-31 21:02 ` Kevin Hilman 0 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-03-31 21:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-03-31 21:02 ` Kevin Hilman 0 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-03-31 21:02 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Abhilash Kesavan, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-03-31 21:02 ` Kevin Hilman (?) @ 2015-04-01 3:19 ` Abhilash Kesavan -1 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-01 3:19 UTC (permalink / raw) To: Kevin Hilman Cc: Javier Martinez Canillas, Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 3:19 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-01 3:19 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 3:19 ` Abhilash Kesavan 0 siblings, 0 replies; 99+ messages in thread From: Abhilash Kesavan @ 2015-04-01 3:19 UTC (permalink / raw) To: Kevin Hilman Cc: Javier Martinez Canillas, Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 3:19 ` Abhilash Kesavan (?) @ 2015-04-01 4:03 ` Kevin Hilman -1 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-04-01 4:03 UTC (permalink / raw) To: Abhilash Kesavan Cc: Javier Martinez Canillas, Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 4:03 ` Kevin Hilman 0 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-04-01 4:03 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 4:03 ` Kevin Hilman 0 siblings, 0 replies; 99+ messages in thread From: Kevin Hilman @ 2015-04-01 4:03 UTC (permalink / raw) To: Abhilash Kesavan Cc: Javier Martinez Canillas, Tomasz Figa, Stephen Boyd, Mike Turquette, Sylwester Nawrocki, Kukjin Kim, Olof Johansson, Doug Anderson, Krzysztof Kozlowski, Tyler Baker, Chanwoo Choi, linux-arm-kernel, linux-samsung-soc, linux-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 4:03 ` Kevin Hilman (?) @ 2015-04-01 9:16 ` Krzysztof Kozlowski -1 siblings, 0 replies; 99+ messages in thread From: Krzysztof Kozlowski @ 2015-04-01 9:16 UTC (permalink / raw) To: Kevin Hilman Cc: Abhilash Kesavan, Krzysztof Kozlowski, linux-samsung-soc, Mike Turquette, linux-kernel, Tyler Baker, Stephen Boyd, Tomasz Figa, Doug Anderson, Chanwoo Choi, Kukjin Kim, Sylwester Nawrocki, Olof Johansson, Javier Martinez Canillas, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 9:16 ` Krzysztof Kozlowski 0 siblings, 0 replies; 99+ messages in thread From: Krzysztof Kozlowski @ 2015-04-01 9:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 9:16 ` Krzysztof Kozlowski 0 siblings, 0 replies; 99+ messages in thread From: Krzysztof Kozlowski @ 2015-04-01 9:16 UTC (permalink / raw) To: Kevin Hilman Cc: Abhilash Kesavan, Krzysztof Kozlowski, linux-samsung-soc, Mike Turquette, linux-kernel, Tyler Baker, Stephen Boyd, Tomasz Figa, Doug Anderson, Chanwoo Choi, Kukjin Kim, Sylwester Nawrocki, Olof Johansson, Javier Martinez Canillas, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend 2015-04-01 9:16 ` Krzysztof Kozlowski (?) @ 2015-04-01 19:02 ` Michael Turquette -1 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-04-01 19:02 UTC (permalink / raw) To: Krzysztof Kozlowski, Kevin Hilman Cc: Abhilash Kesavan, Krzysztof Kozlowski, linux-samsung-soc, linux-kernel, Tyler Baker, Stephen Boyd, Tomasz Figa, Doug Anderson, Chanwoo Choi, Kukjin Kim, Sylwester Nawrocki, Olof Johansson, Javier Martinez Canillas, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 19:02 ` Michael Turquette 0 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-04-01 19:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend @ 2015-04-01 19:02 ` Michael Turquette 0 siblings, 0 replies; 99+ messages in thread From: Michael Turquette @ 2015-04-01 19:02 UTC (permalink / raw) To: Kevin Hilman Cc: Abhilash Kesavan, Krzysztof Kozlowski, linux-samsung-soc, linux-kernel, Tyler Baker, Stephen Boyd, Tomasz Figa, Doug Anderson, Chanwoo Choi, Kukjin Kim, Sylwester Nawrocki, Olof Johansson, Javier Martinez Canillas, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 99+ messages in thread
end of thread, other threads:[~2015-04-08 5:36 UTC | newest] Thread overview: 99+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-30 15:53 [RFC PATCH v3 0/2] ARM: EXYNOS: Fix Suspend-to-RAM on Exynos5420 Javier Martinez Canillas 2015-03-30 15:53 ` Javier Martinez Canillas 2015-03-30 15:53 ` [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function Javier Martinez Canillas 2015-03-30 15:53 ` Javier Martinez Canillas 2015-03-30 16:02 ` Tomasz Figa 2015-03-30 16:02 ` Tomasz Figa 2015-03-30 16:02 ` Tomasz Figa 2015-03-30 16:08 ` Javier Martinez Canillas 2015-03-30 16:08 ` Javier Martinez Canillas 2015-03-30 16:08 ` Javier Martinez Canillas 2015-03-31 1:40 ` Michael Turquette 2015-03-31 1:40 ` Michael Turquette 2015-03-31 1:40 ` Michael Turquette 2015-03-31 8:59 ` Javier Martinez Canillas 2015-03-31 8:59 ` Javier Martinez Canillas 2015-03-31 8:59 ` Javier Martinez Canillas 2015-04-01 1:29 ` Michael Turquette 2015-04-01 1:29 ` Michael Turquette 2015-04-01 1:29 ` Michael Turquette 2015-04-01 8:26 ` Javier Martinez Canillas 2015-04-01 8:26 ` Javier Martinez Canillas 2015-04-01 8:26 ` Javier Martinez Canillas 2015-03-30 15:53 ` [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend Javier Martinez Canillas 2015-03-30 15:53 ` Javier Martinez Canillas 2015-03-30 16:07 ` Tomasz Figa 2015-03-30 16:07 ` Tomasz Figa 2015-03-30 16:07 ` Tomasz Figa 2015-03-30 16:16 ` Javier Martinez Canillas 2015-03-30 16:16 ` Javier Martinez Canillas 2015-03-30 16:16 ` Javier Martinez Canillas [not found] ` <CAM4voanL3A=dS8Z-ovi_-EDi9ctyaxZkvjajp+3ZjyNAnqR1aQ@mail.gmail.com> 2015-03-31 20:00 ` Javier Martinez Canillas 2015-03-31 20:00 ` Javier Martinez Canillas 2015-03-31 20:00 ` Javier Martinez Canillas 2015-04-01 11:03 ` Sylwester Nawrocki 2015-04-01 11:03 ` Sylwester Nawrocki 2015-04-01 11:03 ` Sylwester Nawrocki 2015-04-01 11:44 ` Javier Martinez Canillas 2015-04-01 11:44 ` Javier Martinez Canillas 2015-04-01 11:44 ` Javier Martinez Canillas 2015-04-01 17:31 ` Sylwester Nawrocki 2015-04-01 17:31 ` Sylwester Nawrocki 2015-04-01 17:31 ` Sylwester Nawrocki 2015-04-01 22:31 ` Javier Martinez Canillas 2015-04-01 22:31 ` Javier Martinez Canillas 2015-04-01 22:31 ` Javier Martinez Canillas 2015-04-02 12:22 ` Abhilash Kesavan 2015-04-02 12:22 ` Abhilash Kesavan 2015-04-02 12:22 ` Abhilash Kesavan 2015-04-07 10:59 ` Javier Martinez Canillas 2015-04-07 10:59 ` Javier Martinez Canillas 2015-04-07 10:59 ` Javier Martinez Canillas 2015-04-07 11:56 ` Javier Martinez Canillas 2015-04-07 11:56 ` Javier Martinez Canillas 2015-04-07 11:56 ` Javier Martinez Canillas 2015-04-07 12:46 ` Tomasz Figa 2015-04-07 12:46 ` Tomasz Figa 2015-04-07 12:46 ` Tomasz Figa 2015-04-07 14:11 ` Javier Martinez Canillas 2015-04-07 14:11 ` Javier Martinez Canillas 2015-04-07 14:11 ` Javier Martinez Canillas 2015-04-07 14:38 ` Abhilash Kesavan 2015-04-07 14:38 ` Abhilash Kesavan 2015-04-07 14:38 ` Abhilash Kesavan 2015-04-07 15:00 ` Javier Martinez Canillas 2015-04-07 15:00 ` Javier Martinez Canillas 2015-04-07 15:00 ` Javier Martinez Canillas 2015-04-08 1:50 ` Abhilash Kesavan 2015-04-08 1:50 ` Abhilash Kesavan 2015-04-08 1:50 ` Abhilash Kesavan 2015-04-07 18:51 ` Kevin Hilman 2015-04-07 18:51 ` Kevin Hilman 2015-04-07 18:51 ` Kevin Hilman 2015-04-07 21:28 ` Tomasz Figa 2015-04-07 21:28 ` Tomasz Figa 2015-04-07 21:28 ` Tomasz Figa 2015-04-08 5:36 ` Javier Martinez Canillas 2015-04-08 5:36 ` Javier Martinez Canillas 2015-04-08 5:36 ` Javier Martinez Canillas 2015-04-07 14:11 ` Abhilash Kesavan 2015-04-07 14:11 ` Abhilash Kesavan 2015-04-07 14:11 ` Abhilash Kesavan 2015-04-07 14:26 ` Javier Martinez Canillas 2015-04-07 14:26 ` Javier Martinez Canillas 2015-04-07 14:26 ` Javier Martinez Canillas 2015-03-31 21:02 ` Kevin Hilman 2015-03-31 21:02 ` Kevin Hilman 2015-03-31 21:02 ` Kevin Hilman 2015-04-01 3:19 ` Abhilash Kesavan 2015-04-01 3:19 ` Abhilash Kesavan 2015-04-01 3:19 ` Abhilash Kesavan 2015-04-01 4:03 ` Kevin Hilman 2015-04-01 4:03 ` Kevin Hilman 2015-04-01 4:03 ` Kevin Hilman 2015-04-01 9:16 ` Krzysztof Kozlowski 2015-04-01 9:16 ` Krzysztof Kozlowski 2015-04-01 9:16 ` Krzysztof Kozlowski 2015-04-01 19:02 ` Michael Turquette 2015-04-01 19:02 ` Michael Turquette 2015-04-01 19:02 ` Michael Turquette
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.