From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: [RFC] cpufreq: Add bindings for CPU clock sharing topology Date: Thu, 24 Jul 2014 16:09:31 +0530 Message-ID: References: <7e097b71342c9f5f63b07ff2e135eb7beb626aab.1405661369.git.viresh.kumar@linaro.org> <53CA8D95.8010108@ti.com> <20140724003314.6419.51564@quantum> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Rob Herring Cc: Mike Turquette , Santosh Shilimkar , Olof Johansson , "Rafael J. Wysocki" , Grant Likely , "linaro-kernel@lists.linaro.org" , Nishanth Menon , Sudeep Holla , Stephen Boyd , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "devicetree@vger.kernel.org" , Lorenzo Pieralisi , Arvind Chauhan , Arnd Bergmann List-Id: devicetree@vger.kernel.org On 24 July 2014 07:54, Rob Herring wrote: >> A previous approach tried to compare struct clk pointers, which is a bad >> idea since those are just cookies and should not be deref'd by drivers. >> However a similar approach would be to compare the phandle, right? Yeah. So what's the right way then? > I think there needs to be a way to query whether a rate change for a > clock affects other children. As pointed out previously, the clock to > a core may not be shared, but it's parent that can change rates could > be shared. This could be done with functions > clk_get_parent_rate_change to return the clock in heirarchy which can > change rates, and clk_is_parent_clk which tells if one clock is a > child of another clock. It's been a while since I've looked at the > clock api. It could also be done by experiment. Change the rate for > core 0 and see if core 1's rate is changed and still equal. There's > probably some ordering issue with doing that though. But Mike sort of Nak'd that as well earlier :) From mboxrd@z Thu Jan 1 00:00:00 1970 From: viresh.kumar@linaro.org (Viresh Kumar) Date: Thu, 24 Jul 2014 16:09:31 +0530 Subject: [RFC] cpufreq: Add bindings for CPU clock sharing topology In-Reply-To: References: <7e097b71342c9f5f63b07ff2e135eb7beb626aab.1405661369.git.viresh.kumar@linaro.org> <53CA8D95.8010108@ti.com> <20140724003314.6419.51564@quantum> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 24 July 2014 07:54, Rob Herring wrote: >> A previous approach tried to compare struct clk pointers, which is a bad >> idea since those are just cookies and should not be deref'd by drivers. >> However a similar approach would be to compare the phandle, right? Yeah. So what's the right way then? > I think there needs to be a way to query whether a rate change for a > clock affects other children. As pointed out previously, the clock to > a core may not be shared, but it's parent that can change rates could > be shared. This could be done with functions > clk_get_parent_rate_change to return the clock in heirarchy which can > change rates, and clk_is_parent_clk which tells if one clock is a > child of another clock. It's been a while since I've looked at the > clock api. It could also be done by experiment. Change the rate for > core 0 and see if core 1's rate is changed and still equal. There's > probably some ordering issue with doing that though. But Mike sort of Nak'd that as well earlier :)