From: t-kristo@ti•com (Tero Kristo)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 0/2] clk: improve handling of orphan clocks
Date: Thu, 7 May 2015 11:22:12 +0300 [thread overview]
Message-ID: <554B20B4.3040003@ti.com> (raw)
In-Reply-To: <55440EDA.4030905@codeaurora.org>
On 05/02/2015 02:40 AM, Stephen Boyd wrote:
> On 05/01/15 15:07, Heiko St?bner wrote:
>> Am Freitag, 1. Mai 2015, 13:52:47 schrieb Stephen Boyd:
>>
>>>> Instead I guess we could hook it less deep into clk_get_sys, like in the
>>>> following patch?
>>> It looks like it will work at least, but still I'd prefer to keep the
>>> orphan check contained to clk.c. How about this compile tested only patch?
>> I gave this a spin on my rk3288-firefly board. It still boots, the clock tree
>> looks the same and it also still defers nicely in the scenario I needed it
>> for. The implementation also looks nice - and of course much more compact than
>> my check in two places :-) . I don't know if you want to put this as follow-up
>> on top or fold it into the original orphan-check, so in any case
>>
>> Tested-by: Heiko Stuebner <heiko@sntech•de>
>> Reviewed-by: Heiko Stuebner <heiko@sntech•de>
>
> Thanks. I'm leaning towards tossing your patch 2/2 and replacing it with
> my patch and a note that it's based on an earlier patch from you.
FWIW, just gave a try for these two patches on all TI boards I have
access to.
Tested-by: Tero Kristo <t-kristo@ti•com>
I didn't try your evolved patch though, as you don't seem to have made
your mind yet.
-Tero
>
>>
>>
>>> This also brings up an existing problem with clk_unregister() where
>>> orphaned clocks are sitting out there useable by drivers when their
>>> parent is unregistered. That code could use some work to atomically
>>> switch all the orphaned clocks over to use the nodrv_ops.
>> Not sure I understand this correctly yet, but when these children get
>> orphaned, switched to the clk_nodrv_ops, they won't get their original ops
>> back if the parent reappears.
>>
>> So I guess we would need to store the original ops in secondary property of
>> struct clk_core and I guess simply bind the ops-switch to the orphan state
>> update?
>
> Yep. We'll need to store away the original ops in case we need to put
> them back. Don't feel obligated to fix this either. It would certainly
> be nice if someone tried to fix this case at some point, but it's not
> like things are any worse off right now.
>
next prev parent reply other threads:[~2015-05-07 8:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 20:53 [PATCH v3 0/2] clk: improve handling of orphan clocks Heiko Stuebner
2015-04-22 20:53 ` [PATCH v3 1/2] clk: track the orphan status of clocks and their children Heiko Stuebner
2015-04-30 23:20 ` Stephen Boyd
2015-04-22 20:53 ` [PATCH v3 2/2] clk: prevent orphan clocks from being used Heiko Stuebner
2015-04-30 23:20 ` Stephen Boyd
2015-04-25 12:23 ` [PATCH v3 0/2] clk: improve handling of orphan clocks Stefan Wahren
2015-04-25 13:44 ` Heiko Stübner
2015-04-26 19:58 ` Robert Jarzmik
2015-05-01 0:19 ` Stephen Boyd
2015-05-01 19:59 ` Heiko Stübner
2015-05-01 20:52 ` Stephen Boyd
2015-05-01 22:07 ` Heiko Stübner
2015-05-01 23:40 ` Stephen Boyd
2015-05-07 8:22 ` Tero Kristo [this message]
2015-05-07 18:18 ` Stephen Boyd
2015-05-08 11:41 ` Tero Kristo
2015-05-07 15:17 ` Kevin Hilman
2015-05-07 21:03 ` Stephen Boyd
2015-05-08 0:27 ` Kevin Hilman
2015-05-08 6:53 ` Stephen Boyd
2015-05-08 8:13 ` Sascha Hauer
2015-05-08 9:30 ` Heiko Stübner
2015-05-08 9:53 ` Sascha Hauer
2015-05-08 10:02 ` Maxime Ripard
2015-05-12 22:35 ` Stephen Boyd
2015-05-13 13:03 ` Maxime Ripard
2015-05-13 14:33 ` Kevin Hilman
2015-05-13 20:14 ` Maxime Ripard
2015-05-13 20:44 ` Kevin Hilman
2015-05-13 20:51 ` Maxime Ripard
2015-07-27 8:57 ` Heiko Stübner
2015-07-30 10:09 ` Maxime Ripard
2015-08-11 22:34 ` Stephen Boyd
2015-08-12 8:26 ` Heiko Stübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=554B20B4.3040003@ti.com \
--to=t-kristo@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox