Re: [RFC Patch v2 0/3] add temporary parent migration support
On 6 September 2013 00:02, Mike Turquette wrote: > On Wed, Sep 4, 2013 at 11:01 AM, Tomasz Figa wrote: >> On Wednesday 04 of September 2013 10:43:28 Mike Turquette wrote: >>> Quoting Tomasz Figa (2013-09-03 15:36:50) >>> >>> > Hi Chander, >>> > >>> > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: >>> > > Some platform has provision to change cpu parent clock during >>> > > cpu frequency scaling. This patch series provides a mechanism to >>> > > implement the same using CCF. >>> > > >>> > > Patch1 provides mechanism to migrate to new parent temporarily. >>> > > >>> > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which >>> > > are modified to add support for clk migration. >>> > > >>> > > Patch3 adds support to Exynos5250 to use the clock parent migration >>> > > feature implemented in CCF. >>> > >>> > I don't really like this approach. A need to change mux setting >>> > temporarily is heavily platform-specific and I don't think it should >>> > be >>> > handled by generic code. >>> >>> I agree with Tomasz. >>> >>> > First of all there are many factor that you would >>> > >>> > have to account for to make this solution generic, such as: >>> > - board specific alternative parents, >>> > - exact moment of parent change, >>> > - some other platform specific conditions, like CPU voltage that must >>> > be> >>> > changed when mux is changed, because it changes CPU frequency, >>> > >>> > - and probably a lot of more factors that only people working with >>> > all >>> > >>> > the platforms supported (and unsupported yet) by Linux. >>> > >>> > I can see at least two solutions for this problem that don't require >>> > changing core code of common clock framework: >>> > >>> > 1) Implementing a special clock type using normal mux ops, but also >>> > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE >>> > events to perform parent switching. >>> >>> Creating a custom clock type is the way to go here. It is possible to >>> wrap the mux clk_ops to re-use that code, or just write a custom clock >>> type from scratch. >>> >>> I do not like using the clock rate-change notifiers for this purpose. >>> The notifiers provide hooks to drivers that need to take care around >>> clock transitions. Using the notifiers from within the clock framework >>> indicates poor design. >> >> I was not sure how a .set_parent() from inside a .set_rate() would >> interact with rate setting, so I mentioned notifiers here, but now as I >> think of it, CCF is supposed to be re-entrant, so things should be fine. >> >>> > 2) Using normal mux clock, but registering such notifiers in clock >>> > controller or cpufreq driver. >>> >>> This depends on what the data sheet or reference manual states. If using >>> a temporary parent is a property of the clock programming sequence >>> (e.g. to have a glitch-less transition) then that logic belongs in the >>> clock provider driver (i.e. a custom clock type needs to be created >>> with this logic). >>> >>> However if using a temporary parent is not required for programming the >>> clock, but is instead a requirement of the clock consumer (e.g. a CPU, >>> or some I/O controller) then perhaps putting this logic in that driver >>> is the right way to go. In that case the logic could be explicit: >>> >>> clk_set_parent(clk, temp_parent); >>> clk_set_rate(clk, target_rate); >>> clk_set_parent(clk, target_parent); >>> >>> Or it could implicit with the use of rate-change notifiers. Again the >>> rate-change notifiers exist for clock consumer drivers to use, so this >>> is OK. >>> >>> I have a hunch that the right way to do this is for a custom clock type >>> to be created which simply calls clk_set_parent from within the clock's >>> .set_rate callback, but I'll wait on feedback from Chander on the needs >>> of his platform. >> >> I believe Chander has exactly the same use case for this as we have for >> Exynos 4210 and 4x12. >> >> On these SoCs, CPU frequency is being scaled by reconfiguring PLL, which >> needs to be masked for locking time. To let the CPU operate normally, a >> mux that allows switching CPU clock domain between two PLLs can be >> switched to the other PLL (MPLL) until the main ARM PLL (APLL) starts >> operating again. > > Right, this is the "glitchless" operation I mentioned earlier and it > is not uncommon in PLLs. > >> >> However this issue is not limited to clocks, because there must be also a >> voltage transition involved if the utility PLL has frequency higher than >> the one currently being reconfigured. > > Right, that is an altogether different issue. What I would like to see > is the temporary parent managed by calls to clk_set_parent from within > a custom .set_rate callback. > > As for the voltage scaling, it would be cool to see this working with > the voltage notifier series I posted recently. Both parents of the > PLLs can have their own operating point tables and each transition > would fire off notifiers tha
Re: [RFC Patch v2 0/3] add temporary parent migration support
On 4 September 2013 23:31, Tomasz Figa wrote: > On Wednesday 04 of September 2013 10:43:28 Mike Turquette wrote: >> Quoting Tomasz Figa (2013-09-03 15:36:50) >> >> > Hi Chander, >> > >> > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: >> > > Some platform has provision to change cpu parent clock during >> > > cpu frequency scaling. This patch series provides a mechanism to >> > > implement the same using CCF. >> > > >> > > Patch1 provides mechanism to migrate to new parent temporarily. >> > > >> > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which >> > > are modified to add support for clk migration. >> > > >> > > Patch3 adds support to Exynos5250 to use the clock parent migration >> > > feature implemented in CCF. >> > >> > I don't really like this approach. A need to change mux setting >> > temporarily is heavily platform-specific and I don't think it should >> > be >> > handled by generic code. >> >> I agree with Tomasz. >> >> > First of all there are many factor that you would >> > >> > have to account for to make this solution generic, such as: >> > - board specific alternative parents, >> > - exact moment of parent change, >> > - some other platform specific conditions, like CPU voltage that must >> > be> >> > changed when mux is changed, because it changes CPU frequency, >> > >> > - and probably a lot of more factors that only people working with >> > all >> > >> > the platforms supported (and unsupported yet) by Linux. >> > >> > I can see at least two solutions for this problem that don't require >> > changing core code of common clock framework: >> > >> > 1) Implementing a special clock type using normal mux ops, but also >> > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE >> > events to perform parent switching. >> >> Creating a custom clock type is the way to go here. It is possible to >> wrap the mux clk_ops to re-use that code, or just write a custom clock >> type from scratch. >> >> I do not like using the clock rate-change notifiers for this purpose. >> The notifiers provide hooks to drivers that need to take care around >> clock transitions. Using the notifiers from within the clock framework >> indicates poor design. > > I was not sure how a .set_parent() from inside a .set_rate() would > interact with rate setting, so I mentioned notifiers here, but now as I > think of it, CCF is supposed to be re-entrant, so things should be fine. > >> > 2) Using normal mux clock, but registering such notifiers in clock >> > controller or cpufreq driver. >> >> This depends on what the data sheet or reference manual states. If using >> a temporary parent is a property of the clock programming sequence >> (e.g. to have a glitch-less transition) then that logic belongs in the >> clock provider driver (i.e. a custom clock type needs to be created >> with this logic). >> >> However if using a temporary parent is not required for programming the >> clock, but is instead a requirement of the clock consumer (e.g. a CPU, >> or some I/O controller) then perhaps putting this logic in that driver >> is the right way to go. In that case the logic could be explicit: >> >> clk_set_parent(clk, temp_parent); >> clk_set_rate(clk, target_rate); >> clk_set_parent(clk, target_parent); >> >> Or it could implicit with the use of rate-change notifiers. Again the >> rate-change notifiers exist for clock consumer drivers to use, so this >> is OK. >> >> I have a hunch that the right way to do this is for a custom clock type >> to be created which simply calls clk_set_parent from within the clock's >> .set_rate callback, but I'll wait on feedback from Chander on the needs >> of his platform. > > I believe Chander has exactly the same use case for this as we have for > Exynos 4210 and 4x12. Yes Tomasz, I am trying to address the same issue. As this was requirement for more than one platform so thought of making it generic. > > On these SoCs, CPU frequency is being scaled by reconfiguring PLL, which > needs to be masked for locking time. To let the CPU operate normally, a > mux that allows switching CPU clock domain between two PLLs can be > switched to the other PLL (MPLL) until the main ARM PLL (APLL) starts > operating again. > > However this issue is not limited to clocks, because there must be also a > voltage transition involved if the utility PLL has frequency higher than > the one currently being reconfigured. > > Best regards, > Tomasz > -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC Patch v2 0/3] add temporary parent migration support
On Wed, Sep 4, 2013 at 11:01 AM, Tomasz Figa wrote: > On Wednesday 04 of September 2013 10:43:28 Mike Turquette wrote: >> Quoting Tomasz Figa (2013-09-03 15:36:50) >> >> > Hi Chander, >> > >> > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: >> > > Some platform has provision to change cpu parent clock during >> > > cpu frequency scaling. This patch series provides a mechanism to >> > > implement the same using CCF. >> > > >> > > Patch1 provides mechanism to migrate to new parent temporarily. >> > > >> > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which >> > > are modified to add support for clk migration. >> > > >> > > Patch3 adds support to Exynos5250 to use the clock parent migration >> > > feature implemented in CCF. >> > >> > I don't really like this approach. A need to change mux setting >> > temporarily is heavily platform-specific and I don't think it should >> > be >> > handled by generic code. >> >> I agree with Tomasz. >> >> > First of all there are many factor that you would >> > >> > have to account for to make this solution generic, such as: >> > - board specific alternative parents, >> > - exact moment of parent change, >> > - some other platform specific conditions, like CPU voltage that must >> > be> >> > changed when mux is changed, because it changes CPU frequency, >> > >> > - and probably a lot of more factors that only people working with >> > all >> > >> > the platforms supported (and unsupported yet) by Linux. >> > >> > I can see at least two solutions for this problem that don't require >> > changing core code of common clock framework: >> > >> > 1) Implementing a special clock type using normal mux ops, but also >> > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE >> > events to perform parent switching. >> >> Creating a custom clock type is the way to go here. It is possible to >> wrap the mux clk_ops to re-use that code, or just write a custom clock >> type from scratch. >> >> I do not like using the clock rate-change notifiers for this purpose. >> The notifiers provide hooks to drivers that need to take care around >> clock transitions. Using the notifiers from within the clock framework >> indicates poor design. > > I was not sure how a .set_parent() from inside a .set_rate() would > interact with rate setting, so I mentioned notifiers here, but now as I > think of it, CCF is supposed to be re-entrant, so things should be fine. > >> > 2) Using normal mux clock, but registering such notifiers in clock >> > controller or cpufreq driver. >> >> This depends on what the data sheet or reference manual states. If using >> a temporary parent is a property of the clock programming sequence >> (e.g. to have a glitch-less transition) then that logic belongs in the >> clock provider driver (i.e. a custom clock type needs to be created >> with this logic). >> >> However if using a temporary parent is not required for programming the >> clock, but is instead a requirement of the clock consumer (e.g. a CPU, >> or some I/O controller) then perhaps putting this logic in that driver >> is the right way to go. In that case the logic could be explicit: >> >> clk_set_parent(clk, temp_parent); >> clk_set_rate(clk, target_rate); >> clk_set_parent(clk, target_parent); >> >> Or it could implicit with the use of rate-change notifiers. Again the >> rate-change notifiers exist for clock consumer drivers to use, so this >> is OK. >> >> I have a hunch that the right way to do this is for a custom clock type >> to be created which simply calls clk_set_parent from within the clock's >> .set_rate callback, but I'll wait on feedback from Chander on the needs >> of his platform. > > I believe Chander has exactly the same use case for this as we have for > Exynos 4210 and 4x12. > > On these SoCs, CPU frequency is being scaled by reconfiguring PLL, which > needs to be masked for locking time. To let the CPU operate normally, a > mux that allows switching CPU clock domain between two PLLs can be > switched to the other PLL (MPLL) until the main ARM PLL (APLL) starts > operating again. Right, this is the "glitchless" operation I mentioned earlier and it is not uncommon in PLLs. > > However this issue is not limited to clocks, because there must be also a > voltage transition involved if the utility PLL has frequency higher than > the one currently being reconfigured. Right, that is an altogether different issue. What I would like to see is the temporary parent managed by calls to clk_set_parent from within a custom .set_rate callback. As for the voltage scaling, it would be cool to see this working with the voltage notifier series I posted recently. Both parents of the PLLs can have their own operating point tables and each transition would fire off notifiers that scale voltage. Something like this: clk_set_rate(pll, rate) -> enter .set_rate -> clk_set_parent(pll, temp_parent) -> temp_parent PRE_RATE_CHANGE notifier is trigg
Re: [RFC Patch v2 0/3] add temporary parent migration support
On Wednesday 04 of September 2013 10:43:28 Mike Turquette wrote: > Quoting Tomasz Figa (2013-09-03 15:36:50) > > > Hi Chander, > > > > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: > > > Some platform has provision to change cpu parent clock during > > > cpu frequency scaling. This patch series provides a mechanism to > > > implement the same using CCF. > > > > > > Patch1 provides mechanism to migrate to new parent temporarily. > > > > > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which > > > are modified to add support for clk migration. > > > > > > Patch3 adds support to Exynos5250 to use the clock parent migration > > > feature implemented in CCF. > > > > I don't really like this approach. A need to change mux setting > > temporarily is heavily platform-specific and I don't think it should > > be > > handled by generic code. > > I agree with Tomasz. > > > First of all there are many factor that you would > > > > have to account for to make this solution generic, such as: > > - board specific alternative parents, > > - exact moment of parent change, > > - some other platform specific conditions, like CPU voltage that must > > be> > > changed when mux is changed, because it changes CPU frequency, > > > > - and probably a lot of more factors that only people working with > > all > > > > the platforms supported (and unsupported yet) by Linux. > > > > I can see at least two solutions for this problem that don't require > > changing core code of common clock framework: > > > > 1) Implementing a special clock type using normal mux ops, but also > > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE > > events to perform parent switching. > > Creating a custom clock type is the way to go here. It is possible to > wrap the mux clk_ops to re-use that code, or just write a custom clock > type from scratch. > > I do not like using the clock rate-change notifiers for this purpose. > The notifiers provide hooks to drivers that need to take care around > clock transitions. Using the notifiers from within the clock framework > indicates poor design. I was not sure how a .set_parent() from inside a .set_rate() would interact with rate setting, so I mentioned notifiers here, but now as I think of it, CCF is supposed to be re-entrant, so things should be fine. > > 2) Using normal mux clock, but registering such notifiers in clock > > controller or cpufreq driver. > > This depends on what the data sheet or reference manual states. If using > a temporary parent is a property of the clock programming sequence > (e.g. to have a glitch-less transition) then that logic belongs in the > clock provider driver (i.e. a custom clock type needs to be created > with this logic). > > However if using a temporary parent is not required for programming the > clock, but is instead a requirement of the clock consumer (e.g. a CPU, > or some I/O controller) then perhaps putting this logic in that driver > is the right way to go. In that case the logic could be explicit: > > clk_set_parent(clk, temp_parent); > clk_set_rate(clk, target_rate); > clk_set_parent(clk, target_parent); > > Or it could implicit with the use of rate-change notifiers. Again the > rate-change notifiers exist for clock consumer drivers to use, so this > is OK. > > I have a hunch that the right way to do this is for a custom clock type > to be created which simply calls clk_set_parent from within the clock's > .set_rate callback, but I'll wait on feedback from Chander on the needs > of his platform. I believe Chander has exactly the same use case for this as we have for Exynos 4210 and 4x12. On these SoCs, CPU frequency is being scaled by reconfiguring PLL, which needs to be masked for locking time. To let the CPU operate normally, a mux that allows switching CPU clock domain between two PLLs can be switched to the other PLL (MPLL) until the main ARM PLL (APLL) starts operating again. However this issue is not limited to clocks, because there must be also a voltage transition involved if the utility PLL has frequency higher than the one currently being reconfigured. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC Patch v2 0/3] add temporary parent migration support
Quoting Tomasz Figa (2013-09-03 15:36:50) > Hi Chander, > > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: > > Some platform has provision to change cpu parent clock during > > cpu frequency scaling. This patch series provides a mechanism to > > implement the same using CCF. > > > > Patch1 provides mechanism to migrate to new parent temporarily. > > > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are > > modified to add support for clk migration. > > > > Patch3 adds support to Exynos5250 to use the clock parent migration > > feature implemented in CCF. > > I don't really like this approach. A need to change mux setting > temporarily is heavily platform-specific and I don't think it should be > handled by generic code. I agree with Tomasz. > First of all there are many factor that you would > have to account for to make this solution generic, such as: > - board specific alternative parents, > - exact moment of parent change, > - some other platform specific conditions, like CPU voltage that must be > changed when mux is changed, because it changes CPU frequency, > - and probably a lot of more factors that only people working with all > the platforms supported (and unsupported yet) by Linux. > > I can see at least two solutions for this problem that don't require > changing core code of common clock framework: > > 1) Implementing a special clock type using normal mux ops, but also > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events > to perform parent switching. Creating a custom clock type is the way to go here. It is possible to wrap the mux clk_ops to re-use that code, or just write a custom clock type from scratch. I do not like using the clock rate-change notifiers for this purpose. The notifiers provide hooks to drivers that need to take care around clock transitions. Using the notifiers from within the clock framework indicates poor design. > > 2) Using normal mux clock, but registering such notifiers in clock > controller or cpufreq driver. This depends on what the data sheet or reference manual states. If using a temporary parent is a property of the clock programming sequence (e.g. to have a glitch-less transition) then that logic belongs in the clock provider driver (i.e. a custom clock type needs to be created with this logic). However if using a temporary parent is not required for programming the clock, but is instead a requirement of the clock consumer (e.g. a CPU, or some I/O controller) then perhaps putting this logic in that driver is the right way to go. In that case the logic could be explicit: clk_set_parent(clk, temp_parent); clk_set_rate(clk, target_rate); clk_set_parent(clk, target_parent); Or it could implicit with the use of rate-change notifiers. Again the rate-change notifiers exist for clock consumer drivers to use, so this is OK. I have a hunch that the right way to do this is for a custom clock type to be created which simply calls clk_set_parent from within the clock's .set_rate callback, but I'll wait on feedback from Chander on the needs of his platform. Regards, Mike > > Best regards, > Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC Patch v2 0/3] add temporary parent migration support
On 4 September 2013 04:06, Tomasz Figa wrote: > Hi Chander, > > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: >> Some platform has provision to change cpu parent clock during >> cpu frequency scaling. This patch series provides a mechanism to >> implement the same using CCF. >> >> Patch1 provides mechanism to migrate to new parent temporarily. >> >> Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are >> modified to add support for clk migration. >> >> Patch3 adds support to Exynos5250 to use the clock parent migration >> feature implemented in CCF. > > I don't really like this approach. A need to change mux setting > temporarily is heavily platform-specific and I don't think it should be > handled by generic code. As of now beside samsung platforms, tegra is doing temporary parent migration. That why i opted to implement this feature in generic code. Here only set_parent operation is called on mux_clk. which is again implemented in generic framework. So i dont think any other platform specific requirements need to be taken care. >First of all there are many factor that you would > have to account for to make this solution generic, such as: > - board specific alternative parents, Yes true, that's why, that information is passed during registration time. > - exact moment of parent change, Here it is only during set rate operation. > - some other platform specific conditions, like CPU voltage that must be That will be handled separately when actual migration of cpufreq driver will be done. > changed when mux is changed, because it changes CPU frequency, > - and probably a lot of more factors that only people working with all > the platforms supported (and unsupported yet) by Linux. > > I can see at least two solutions for this problem that don't require > changing core code of common clock framework: > > 1) Implementing a special clock type using normal mux ops, but also > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events > to perform parent switching. > > 2) Using normal mux clock, but registering such notifiers in clock > controller or cpufreq driver. > I agree with you, but i am attempting through generic framework be keeping in mind the future usage of this feature by other platforms. > Best regards, > Tomasz > -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC Patch v2 0/3] add temporary parent migration support
Hi Chander, On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: > Some platform has provision to change cpu parent clock during > cpu frequency scaling. This patch series provides a mechanism to > implement the same using CCF. > > Patch1 provides mechanism to migrate to new parent temporarily. > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are > modified to add support for clk migration. > > Patch3 adds support to Exynos5250 to use the clock parent migration > feature implemented in CCF. I don't really like this approach. A need to change mux setting temporarily is heavily platform-specific and I don't think it should be handled by generic code. First of all there are many factor that you would have to account for to make this solution generic, such as: - board specific alternative parents, - exact moment of parent change, - some other platform specific conditions, like CPU voltage that must be changed when mux is changed, because it changes CPU frequency, - and probably a lot of more factors that only people working with all the platforms supported (and unsupported yet) by Linux. I can see at least two solutions for this problem that don't require changing core code of common clock framework: 1) Implementing a special clock type using normal mux ops, but also registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events to perform parent switching. 2) Using normal mux clock, but registering such notifiers in clock controller or cpufreq driver. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC Patch v2 0/3] add temporary parent migration support
Some platform has provision to change cpu parent clock during cpu frequency scaling. This patch series provides a mechanism to implement the same using CCF. Patch1 provides mechanism to migrate to new parent temporarily. Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are modified to add support for clk migration. Patch3 adds support to Exynos5250 to use the clock parent migration feature implemented in CCF. Changes in v2: - Renamed flag name from CLK_SET_RATE_ALTERNATE to CLK_SET_RATE_TEMP_PARENT - Renamed "alternate_parent_name" to "temp_parent_name" and "alternate_parent" to "temp_parent" Chander Kashyap (3): clk: add support for temporary parent clock migration clk: update users of "clk_register_mux" and "DEFINE_CLK_MUX" clk: samsung: Exynos5250: Add alternate parent name for mout_cpu arch/arm/mach-imx/clk.h|6 +-- arch/arm/mach-omap2/cclock2420_data.c |2 +- arch/arm/mach-omap2/cclock2430_data.c |4 +- arch/arm/mach-omap2/cclock33xx_data.c |7 +-- arch/arm/mach-omap2/cclock3xxx_data.c |8 ++-- arch/arm/mach-omap2/cclock44xx_data.c | 61 + drivers/clk/clk-mux.c | 13 +++--- drivers/clk/clk.c | 43 +- drivers/clk/mmp/clk-mmp2.c | 39 ++-- drivers/clk/mmp/clk-pxa910.c | 30 drivers/clk/mxs/clk.h |2 +- drivers/clk/samsung/clk-exynos-audss.c |4 +- drivers/clk/samsung/clk-exynos4.c | 10 ++-- drivers/clk/samsung/clk-exynos5250.c |4 +- drivers/clk/samsung/clk.c |3 +- drivers/clk/samsung/clk.h | 17 --- drivers/clk/spear/spear1310_clock.c| 78 ++-- drivers/clk/spear/spear1340_clock.c| 47 ++- drivers/clk/spear/spear3xx_clock.c | 36 +++ drivers/clk/spear/spear6xx_clock.c | 20 drivers/clk/sunxi/clk-sunxi.c |2 +- drivers/clk/tegra/clk-tegra114.c | 24 +- drivers/clk/tegra/clk-tegra20.c|4 +- drivers/clk/tegra/clk-tegra30.c| 22 - drivers/clk/versatile/clk-vexpress.c |2 +- drivers/clk/zynq/clkc.c| 65 +- include/linux/clk-private.h| 19 include/linux/clk-provider.h | 10 ++-- 28 files changed, 338 insertions(+), 244 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
