Prepare for OMAP2+ movement to Common Clk
Subsystems (20)
cover Prepare for OMAP2+ movement to Common Clk
Hi,
This is a preparatory series for the OMAP Common Clk conversion. They mostly add clk_prepare/clk_unprepare in OMAP drivers and platform code. Also gets rid of omap_clk_get_by_name() and uses clk_get(), and removes all direct 'struct clk' dereferrencing and uses helpers similar to what is provided by Common Clk.
Patches are boot tested on OMAP2430sdp, 3630 Beagle-Xm and 4460 Panda.
Some of these patches were earlier posted as part of OMAP2+ Common Clk conversion series [1] which is now split into a preparatory series and actual CCF conversion series.
Patches from this series can be found heregit://github.com/rrnayak/linux.git prepare-common-clk-3.5-rc3
regards,
Rajendra
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg70299.html
Rajendra Nayak (11):
ARM: omap: clk: add clk_prepare and clk_unprepare
mmc: omap: add clk_prepare and clk_unprepare
hwrng: omap: add clk_prepare and clk_unprepare
mfd: omap-usb: add clk_prepare and clk_unprepare
OMAPDSS: add clk_prepare and clk_unprepare gpio/omap: add clk_prepare and clk_unprepare
w1: omap_hdq: add clk_prepare and clk_unprepare
crypto: omap: add clk_prepare and clk_unprepare
iommu: omap: add clk_prepare and clk_unprepare
ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
ARM: omap: clk: Remove all direct dereferencing of struct clk
arch/arm/mach-omap2/board-apollon.c | 4 +- arch/arm/mach-omap2/board-h4.c | 6 +- arch/arm/mach-omap2/board-omap4panda.c | 2 +- arch/arm/mach-omap2/clkt2xxx_apll.c | 2 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 4 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 18 +++--- arch/arm/mach-omap2/clkt_clksel.c | 84 ++++++++++++++++++-------- arch/arm/mach-omap2/clkt_dpll.c | 24 ++++--- arch/arm/mach-omap2/clock.c | 9 ++- arch/arm/mach-omap2/clock2420_data.c | 17 +++++ arch/arm/mach-omap2/clock2430_data.c | 21 +++++++ arch/arm/mach-omap2/clock3xxx.c | 8 +- arch/arm/mach-omap2/clock3xxx_data.c | 24 +++++++ arch/arm/mach-omap2/clock44xx_data.c | 17 +++++ arch/arm/mach-omap2/display.c | 4 +- arch/arm/mach-omap2/dpll3xxx.c | 45 ++++++++------ arch/arm/mach-omap2/gpmc.c | 2 +- arch/arm/mach-omap2/omap_hwmod.c | 21 ++++--- arch/arm/mach-omap2/omap_phy_internal.c | 3 + arch/arm/mach-omap2/pm.c | 2 +- arch/arm/mach-omap2/pm24xx.c | 2 + arch/arm/mach-omap2/usb-fs.c | 4 +- arch/arm/plat-omap/include/plat/clock.h | 4 + arch/arm/plat-omap/omap_device.c | 6 +- drivers/char/hw_random/omap-rng.c | 6 +- drivers/crypto/omap-aes.c | 2 + drivers/crypto/omap-sham.c | 2 + drivers/gpio/gpio-omap.c | 2 + drivers/iommu/omap-iommu.c | 2 + drivers/mfd/omap-usb-host.c | 20 ++++++ drivers/mmc/host/omap.c | 9 ++- drivers/mmc/host/omap_hsmmc.c | 6 +- drivers/video/omap2/dss/dsi.c | 5 +- drivers/video/omap2/dss/hdmi.c | 5 +- drivers/video/omap2/dss/venc.c | 5 +- drivers/w1/masters/omap_hdq.c | 8 +- 36 files changed, 292 insertions(+), 113 deletions(-)
PATCH 1/11 ARM: omap: clk: add clk_prepare and clk_unprepare
As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes.
Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare().
For a few others where there is a possibility they get called from an interrupt or atomic context, there is an additonal clk_prepare() done immediately following a clk_get() and a clk_unprepare() immediately preceding the clk_put().
This is in preparation of OMAP moving to CCF.
Based on initial changes from Mike turquette.
--- arch/arm/mach-omap2/board-apollon.c | 4 ++-- arch/arm/mach-omap2/board-h4.c | 6 +++--- arch/arm/mach-omap2/board-omap4panda.c | 2 +- arch/arm/mach-omap2/clock3xxx.c | 8 ++++---- arch/arm/mach-omap2/display.c | 4 ++-- arch/arm/mach-omap2/gpmc.c | 2 +- arch/arm/mach-omap2/omap_hwmod.c | 3 +++ arch/arm/mach-omap2/omap_phy_internal.c | 3 +++ arch/arm/mach-omap2/pm24xx.c | 2 ++ arch/arm/mach-omap2/usb-fs.c | 4 ++-- 10 files changed, 23 insertions(+), 15 deletions(-)
arch/arm/mach-omap2/board-apollon.c +2 -2
@@ -205,7 +205,7 @@ static inline void __init apollon_init_smc91x(void)return ; } -clk_enable (gpmc_fck); +clk_prepare_enable (gpmc_fck); rate =clk_get_rate (gpmc_fck); eth_cs =APOLLON_ETH_CS ;
@@ -249,7 +249,7 @@ static inline void __init apollon_init_smc91x(void)gpmc_cs_free (APOLLON_ETH_CS ); } out: -clk_disable (gpmc_fck); +clk_disable_unprepare (gpmc_fck);clk_put (gpmc_fck); }
arch/arm/mach-omap2/board-h4.c +3 -3
@@ -267,9 +267,9 @@ static inline void __init h4_init_debug(void)return ; } -clk_enable (gpmc_fck); +clk_prepare_enable (gpmc_fck); rate =clk_get_rate (gpmc_fck); -clk_disable (gpmc_fck); +clk_disable_unprepare (gpmc_fck);clk_put (gpmc_fck);if (is_gpmc_muxed ())
@@ -313,7 +313,7 @@ static inline void __init h4_init_debug(void)gpmc_cs_free (eth_cs); out: -clk_disable (gpmc_fck); +clk_disable_unprepare (gpmc_fck);clk_put (gpmc_fck); }
arch/arm/mach-omap2/board-omap4panda.c +1 -1
@@ -172,7 +172,7 @@ static void __init omap4_ehci_init(void)return ; }clk_set_rate (phy_ref_clk,19200000 ); -clk_enable (phy_ref_clk); +clk_prepare_enable (phy_ref_clk);/* disable the power to the usb hub prior to init and reset phy+hub */ ret = gpio_request_array(panda_ehci_gpios,
arch/arm/mach-omap2/clock3xxx.c +4 -4
@@ -64,15 +64,15 @@ void __init omap3_clk_lock_dpll5(void) dpll5_clk =clk_get (NULL ,"dpll5_ck" );clk_set_rate (dpll5_clk,DPLL5_FREQ_FOR_USBHOST ); -clk_enable (dpll5_clk); +clk_prepare_enable (dpll5_clk);/* Program dpll5_m2_clk divider for no division */ dpll5_m2_clk =clk_get (NULL ,"dpll5_m2_ck" ); -clk_enable (dpll5_m2_clk); +clk_prepare_enable (dpll5_m2_clk);clk_set_rate (dpll5_m2_clk,DPLL5_FREQ_FOR_USBHOST ); -clk_disable (dpll5_m2_clk); -clk_disable (dpll5_clk); +clk_disable_unprepare (dpll5_m2_clk); +clk_disable_unprepare (dpll5_clk);return ; }
arch/arm/mach-omap2/display.c +2 -2
@@ -471,7 +471,7 @@ int omap_dss_reset(struct omap_hwmod *oh)for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i >0 ; i--, oc++)if (oc->_clk) -clk_enable (oc->_clk); +clk_prepare_enable (oc->_clk);dispc_disable_outputs ();
@@ -498,7 +498,7 @@ int omap_dss_reset(struct omap_hwmod *oh)for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i >0 ; i--, oc++)if (oc->_clk) -clk_disable (oc->_clk); +clk_disable_unprepare (oc->_clk); r = (c ==MAX_MODULE_SOFTRESET_WAIT ) ? -ETIMEDOUT :0 ;
arch/arm/mach-omap2/gpmc.c +1 -1
@@ -749,7 +749,7 @@ static int __init gpmc_init(void)BUG (); } -clk_enable (gpmc_l3_clk); +clk_prepare_enable (gpmc_l3_clk); l =gpmc_read_reg (GPMC_REVISION );printk (KERN_INFO "GPMC revision %d.%d\n" , (l >>4 ) &0x0f , l &0x0f );
arch/arm/mach-omap2/omap_hwmod.c +3 -0
@@ -608,6 +608,7 @@ static int _init_main_clk(struct omap_hwmod *oh) oh->name, oh->main_clk);return -EINVAL ; } +clk_prepare (oh->_clk);if (!oh->_clk->clkdm) pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
@@ -644,6 +645,7 @@ static int _init_interface_clks(struct omap_hwmod *oh) oh->name, os->clk); ret = -EINVAL ; } +clk_prepare (os->_clk); os->_clk = c; }
@@ -671,6 +673,7 @@ static int _init_opt_clks(struct omap_hwmod *oh) oh->name, oc->clk); ret = -EINVAL ; } +clk_prepare (oc->_clk); oc->_clk = c; }
arch/arm/mach-omap2/omap_phy_internal.c +3 -0
@@ -84,6 +84,9 @@ int omap4430_phy_init(struct device *dev)iounmap (ctrl_base);return PTR_ERR (clk32k); } +clk_prepare (phyclk); +clk_prepare (clk48m); +clk_prepare (clk32k);return 0 ; }
arch/arm/mach-omap2/pm24xx.c +2 -0
@@ -340,11 +340,13 @@ int __init omap2_pm_init(void)printk (KERN_ERR "could not get osc_ck\n" );return -ENODEV ; } +clk_prepare (osc_ck);if (cpu_is_omap242x ()) { emul_ck =clk_get (NULL ,"emul_ck" );if (IS_ERR (emul_ck)) {printk (KERN_ERR "could not get emul_ck\n" ); +clk_unprepare (osc_ck);clk_put (osc_ck);return -ENODEV ; }
arch/arm/mach-omap2/usb-fs.c +2 -2
@@ -344,7 +344,7 @@ void __init omap2_usbfs_init(struct omap_usb_config *pdata)if (IS_ERR (ick))return ; -clk_enable (ick); +clk_prepare_enable (ick); pdata->usb0_init = omap2_usb0_init; pdata->usb1_init = omap2_usb1_init; pdata->usb2_init = omap2_usb2_init;
@@ -352,7 +352,7 @@ void __init omap2_usbfs_init(struct omap_usb_config *pdata)ohci_device_init (pdata);otg_device_init (pdata);omap_otg_init (pdata); -clk_disable (ick); +clk_disable_unprepare (ick);clk_put (ick); }
Signature · 1 line
1.7.1
PATCH 1/11 ARM: omap: clk: add clk_prepare and clk_unprepare
Hi,
Quoted 52 lines · Rajendra Nayak
As part of Common Clk Framework (CCF) the
clk_enable()operation was split into aclk_prepare()which could sleep, and aclk_enable()which should never sleep. Similarly theclk_disable()was split intoclk_disable()andclk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes.
Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using aclk_enable()toclk_prepare_enable()andclk_disable()toclk_disable_unprepare().
For a few others where there is a possibility they get called from an interrupt or atomic context, there is an additonalclk_prepare()done immediately following aclk_get()and aclk_unprepare()immediately preceding theclk_put().
This is in preparation of OMAP moving to CCF.Based on initial changes from Mike turquette.
Signed-off-by Rajendra Nayak <[email protected]>---
?arch/arm/mach-omap2/board-apollon.c ? ? | ? ?4 ++-- ?arch/arm/mach-omap2/board-h4.c ? ? ? ? ?| ? ?6 +++--- ?arch/arm/mach-omap2/board-omap4panda.c ?| ? ?2 +- ?arch/arm/mach-omap2/clock3xxx.c ? ? ? ? | ? ?8 ++++---- ?arch/arm/mach-omap2/display.c ? ? ? ? ? | ? ?4 ++-- ?arch/arm/mach-omap2/gpmc.c ? ? ? ? ? ? ?| ? ?2 +- ?arch/arm/mach-omap2/omap_hwmod.c ? ? ? ?| ? ?3 +++ ?arch/arm/mach-omap2/omap_phy_internal.c | ? ?3 +++ ?arch/arm/mach-omap2/pm24xx.c ? ? ? ? ? ?| ? ?2 ++ ?arch/arm/mach-omap2/usb-fs.c ? ? ? ? ? ?| ? ?4 ++--?10 files changed, 23 insertions(+), 15 deletions(-)
?}
arch/arm/mach-omap2/display.c +1
-1@@ -471,7 +471,7 @@ int omap_dss_reset(struct omap_hwmod *oh) ? ? ? ?for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) ? ? ? ? ? ? ? ?if (oc->_clk) - ? ? ? ? ? ? ? ? ? ? ? clk_enable(oc->_clk); + ? ? ? ? ? ? ? ? ? ? ? clk_prepare_enable(oc->_clk); ? ? ? ?dispc_disable_outputs();
arch/arm/mach-omap2/display.c int omap_dss_reset(struct omap_hwmod *oh) · line 502
Quoted 6 lines
arch/arm/mach-omap2/display.c +1
-1@@ -498,7 +498,7 @@ int omap_dss_reset(struct omap_hwmod *oh) ? ? ? ?for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) ? ? ? ? ? ? ? ?if (oc->_clk) - ? ? ? ? ? ? ? ? ? ? ? clk_disable(oc->_clk); + ? ? ? ? ? ? ? ? ? ? ? clk_disable_unprepare(oc->_clk);
Just a doubt. Isn't it the same clocks you are preparing in omap_hwmod.c ?
arch/arm/mach-omap2/display.c int omap_dss_reset(struct omap_hwmod *oh) · line 504
Quoted 2 lines
arch/arm/mach-omap2/display.c +0
-0? ? ? ?r = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
d> diff --git a/arch/arm/mach-omap2/omap_hwmod.cb/arch/arm/mach-omap2/omap_hwmod.c
Quoted 12 lines
index bf86f7e..2746bce 100644
arch/arm/mach-omap2/omap_hwmod.c +1
-0@@ -608,6 +608,7 @@ static int _init_main_clk(struct omap_hwmod *oh) ? ? ? ? ? ? ? ? ? ? ? ? ? oh->name, oh->main_clk); ? ? ? ? ? ? ? ?return -EINVAL; ? ? ? ?} + ? ? ? clk_prepare(oh->_clk); ? ? ? ?if (!oh->_clk->clkdm) ? ? ? ? ? ? ? ?pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
arch/arm/mach-omap2/omap_hwmod.c static int _init_interface_clks(struct omap_hwmod *oh) · line 649
Quoted 5 lines
arch/arm/mach-omap2/omap_hwmod.c +1
-0@@ -644,6 +645,7 @@ static int _init_interface_clks(struct omap_hwmod *oh) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? oh->name, os->clk); ? ? ? ? ? ? ? ? ? ? ? ?ret = -EINVAL; ? ? ? ? ? ? ? ?} + ? ? ? ? ? ? ? clk_prepare(os->_clk); ? ? ? ? ? ? ? ?os->_clk = c;
You should do clk_prepare() after os->_clk = c statement. Otherwise you are operating on a uninitialized structure pointer.
arch/arm/mach-omap2/omap_hwmod.c static int _init_opt_clks(struct omap_hwmod *oh) · line 676
Quoted 7 lines
arch/arm/mach-omap2/omap_hwmod.c +1
-0? ? ? ?}@@ -671,6 +673,7 @@ static int _init_opt_clks(struct omap_hwmod *oh) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? oh->name, oc->clk); ? ? ? ? ? ? ? ? ? ? ? ?ret = -EINVAL; ? ? ? ? ? ? ? ?} + ? ? ? ? ? ? ? clk_prepare(oc->_clk);
Same here. You are preparing the uninitialized clk structure.
arch/arm/mach-omap2/omap_hwmod.c static int _init_opt_clks(struct omap_hwmod *oh) · line 679
Quoted 3 lines
arch/arm/mach-omap2/omap_hwmod.c +0
-0? ? ? ? ? ? ? ?oc->_clk = c; ? ? ? ?}
d
PATCH 1/11 ARM: omap: clk: add clk_prepare and clk_unprepare
Quoted 13 lines · Pankaj Jangra
Quoted 13 lines
arch/arm/mach-omap2/display.c +0
-0Quoted 12 lines
index 5fb47a1..e5f8e48 100644
---a/arch/arm/mach-omap2/display.c
+++b/arch/arm/mach-omap2/display.c
@@ -471,7 +471,7 @@ intomap_dss_reset(struct omap_hwmod *oh)for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i> 0; i--, oc++) if (oc->_clk)-
clk_enable(oc->_clk);
+clk_prepare_enable(oc->_clk);dispc_disable_outputs();
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
@@ -498,7 +498,7 @@ int
omap_dss_reset(struct omap_hwmod *oh)for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i> 0; i--, oc++) if (oc->_clk)-
clk_disable(oc->_clk);
+clk_disable_unprepare(oc->_clk);Just a doubt. Isn't it the same clocks you are preparing in
omap_hwmod.c?
Yes, but different users can and should prepare and enable clocks independently, and hence the framework does usecounting to keep track.
Quoted 22 lines
Quoted 3 lines
Quoted 3 lines
r = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;d> diff --git
a/arch/arm/mach-omap2/omap_hwmod.cb/arch/arm/mach-omap2/omap_hwmod.cQuoted 9 lines
Quoted 9 lines
index bf86f7e..2746bce 100644
---a/arch/arm/mach-omap2/omap_hwmod.c
+++b/arch/arm/mach-omap2/omap_hwmod.c
@@ -608,6 +608,7 @@ static int_init_main_clk(struct omap_hwmod *oh)oh->name, oh->main_clk); return -EINVAL; }+
clk_prepare(oh->_clk);Quoted 8 lines
Quoted 8 lines
if (!oh->_clk->clkdm)
pr_warning("omap_hwmod: %s: missing clockdomain for %s.\n",
@@ -644,6 +645,7 @@ static int_init_interface_clks(struct omap_hwmod *oh)oh->name, os->clk); ret = -EINVAL; } + clk_prepare(os->_clk); os->_clk = c;
Quoted 2 lines
You should do
clk_prepare()afteros->_clk= c statement. Otherwise you are operating on a uninitialized structure pointer.
yes, that was really stupid of me :(. Thanks for catching this.
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
}@@ -671,6 +673,7 @@ static int
_init_opt_clks(struct omap_hwmod *oh)oh->name, oc->clk); ret = -EINVAL; }+
clk_prepare(oc->_clk);Same here. You are preparing the uninitialized clk structure.
Thanks, will fix.
Quoted 1 line
PATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the mmc and hsmmc clocks as part of the drivers probe() and remove() routines.
--- drivers/mmc/host/omap.c | 9 ++++++--- drivers/mmc/host/omap_hsmmc.c | 6 +++--- 2 files changed, 9 insertions(+), 6 deletions(-)
drivers/mmc/host/omap.c +6 -3
@@ -1466,13 +1466,14 @@ static int __devinit mmc_omap_probe(struct platform_device *pdev) ret =PTR_ERR (host->iclk); goto err_free_mmc_host; } -clk_enable (host->iclk); +clk_prepare_enable (host->iclk); host->fclk =clk_get (&pdev->dev,"fck" );if (IS_ERR (host->fclk)) { ret =PTR_ERR (host->fclk); goto err_free_iclk; } +clk_prepare (host->fclk); ret =request_irq (host->irq, mmc_omap_irq,0 ,DRIVER_NAME , host);if (ret)
@@ -1509,9 +1510,10 @@ err_plat_cleanup: err_free_irq:free_irq (host->irq, host); err_free_fclk: +clk_unprepare (host->fclk);clk_put (host->fclk); err_free_iclk: -clk_disable (host->iclk); +clk_disable_unprepare (host->iclk);clk_put (host->iclk); err_free_mmc_host:iounmap (host->virt_base);
@@ -1539,8 +1541,9 @@ static int __devexit mmc_omap_remove(struct platform_device *pdev)mmc_omap_fclk_enable (host,0 );free_irq (host->irq, host); +clk_unprepare (host->fclk);clk_put (host->fclk); -clk_disable (host->iclk); +clk_disable_unprepare (host->iclk);clk_put (host->iclk);iounmap (host->virt_base);
drivers/mmc/host/omap_hsmmc.c +3 -3
@@ -1908,7 +1908,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev)if (IS_ERR (host->dbclk)) {dev_warn (mmc_dev (host->mmc),"Failed to get debounce clk\n" ); host->dbclk =NULL ; - }else if (clk_enable (host->dbclk) !=0 ) { + }else if (clk_prepare_enable (host->dbclk) !=0 ) {dev_warn (mmc_dev (host->mmc),"Failed to enable debounce clk\n" );clk_put (host->dbclk); host->dbclk =NULL ;
@@ -2032,7 +2032,7 @@ err_irq:pm_runtime_disable (host->dev);clk_put (host->fclk);if (host->dbclk) { -clk_disable (host->dbclk); +clk_disable_unprepare (host->dbclk);clk_put (host->dbclk); } err1:
@@ -2067,7 +2067,7 @@ static int __devexit omap_hsmmc_remove(struct platform_device *pdev)pm_runtime_disable (host->dev);clk_put (host->fclk);if (host->dbclk) { -clk_disable (host->dbclk); +clk_disable_unprepare (host->dbclk);clk_put (host->dbclk); }
Signature · 1 line
1.7.1
PATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
Quoted 8 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the mmc and hsmmc clocks as part of the driversprobe()andremove()routines.Signed-off-by Rajendra Nayak <[email protected]>Cc Chris Ball <[email protected]>Cc Balaji T K <[email protected]>Cc <[email protected]>
Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
Paul Walmsley
maintainerPATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
Quoted 5 lines · Venkatraman
Quoted 4 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the mmc and hsmmc clocks as part of the driversprobe()andremove()routines.
Quoted 8 lines
Quoted 4 lines
Signed-off-by Rajendra Nayak <[email protected]>Cc Chris Ball <[email protected]>Cc Balaji T K <[email protected]>Cc <[email protected]>Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
A better way to handle this one would be to convert the driver to runtime PM. That needs to be done anyway.
- Paul
PATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
Quoted 12 lines · Paul Walmsley
Quoted 10 lines · Venkatraman
Quoted 8 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the mmc and hsmmc clocks as part of the driversprobe()andremove()routines.Signed-off-by Rajendra Nayak<[email protected]>Cc Chris Ball<[email protected]>Cc Balaji T K<[email protected]>Cc <[email protected]>
Quoted 6 lines
Quoted 3 lines
Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?A better way to handle this one would be to convert the driver to runtime PM. That needs to be done anyway.
Well, mmc driver is already using runtime PM. But it still using clock apis' to deal with some optional debounce clock needed only on 2430.
Quoted 3 lines
- Paul
Paul Walmsley
maintainerPATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
Quoted 18 lines · Rajendra Nayak
Quoted 17 lines · Paul Walmsley
Quoted 14 lines · Venkatraman
Quoted 9 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()
andclk_unprepare()for the mmc and hsmmc clocks as part of the driversprobe()andremove()routines.Signed-off-by Rajendra Nayak<[email protected]>Cc Chris Ball<[email protected]>Cc Balaji T K<[email protected]>Cc <[email protected]>Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
Quoted 5 lines
Quoted 2 lines
A better way to handle this one would be to convert the driver to runtime PM. That needs to be done anyway.
Well, mmc driver is already using runtime PM. But it still using clock apis' to deal with some optional debounce clock needed only on 2430.
drivers/mmc/host/omap.c, which is what this patch changes, has not yet been converted to use runtime PM in mainline.
This is a driver for the MSDI IP block which is not available on 2430.
- Paul
PATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
Quoted 20 lines · Paul Walmsley
Quoted 18 lines · Rajendra Nayak
Quoted 17 lines · Paul Walmsley
Quoted 14 lines · Venkatraman
Quoted 9 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()
andclk_unprepare()for the mmc and hsmmc clocks as part of the driversprobe()andremove()routines.Signed-off-by Rajendra Nayak<[email protected]>Cc Chris Ball<[email protected]>Cc Balaji T K<[email protected]>Cc <[email protected]>Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
A better way to handle this one would be to convert the driver to runtime PM. That needs to be done anyway.
Well, mmc driver is already using runtime PM. But it still using clock apis' to deal with some optional debounce clock needed only on 2430.
drivers/mmc/host/omap.c, which is what this patch changes, has not yet been converted to use runtime PM in mainline.
Venkat/Balaji,
Any plans of converting this driver to use runtime pm?
Quoted 2 lines
This is a driver for the MSDI IP block which is not available on 2430.
Sorry, I meant to say the debounce clock in omap_hsmmc.c was used only on 2430. I seemed to have overlooked the fclk/iclk in drivers/mmc /host/omap.c completely. That one seems to be for the controller in 2420 (atlest, and maybe some other older OMAPs).
Quoted 2 lines
- Paul
PATCH 2/11 mmc: omap: add clk_prepare and clk_unprepare
In reply to S, VenkatramanQuoted 5 lines · Venkatraman
Quoted 4 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the mmc and hsmmc clocks as part of the driversprobe()andremove()routines.
Quoted 8 lines
Quoted 4 lines
Signed-off-by Rajendra Nayak<[email protected]>Cc Chris Ball<[email protected]>Cc Balaji T K<[email protected]>Cc <[email protected]>Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
Yes, this can be applied independently. There is no other dependency.
PATCH 3/11 hwrng: omap: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the rng interface clock as part of the drivers probe() and remove() routines.
--- drivers/char/hw_random/omap-rng.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/char/hw_random/omap-rng.c +3 -3
@@ -110,7 +110,7 @@ static int __devinit omap_rng_probe(struct platform_device *pdev) ret =PTR_ERR (rng_ick);return ret; }else -clk_enable (rng_ick); +clk_prepare_enable (rng_ick); } res =platform_get_resource (pdev,IORESOURCE_MEM ,0 );
@@ -138,7 +138,7 @@ err_register: rng_base =NULL ; err_ioremap:if (cpu_is_omap24xx ()) { -clk_disable (rng_ick); +clk_disable_unprepare (rng_ick);clk_put (rng_ick); }return ret;
@@ -151,7 +151,7 @@ static int __exit omap_rng_remove(struct platform_device *pdev)omap_rng_write_reg (RNG_MASK_REG ,0x0 );if (cpu_is_omap24xx ()) { -clk_disable (rng_ick); +clk_disable_unprepare (rng_ick);clk_put (rng_ick); }
Signature · 1 line
1.7.1
PATCH 4/11 mfd: omap-usb: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare() and clk_unprepare() for the various usb host clocks.
--- drivers/mfd/omap-usb-host.c | 20 ++++++++++++++++++++ 1 files changed, 20 insertions(+), 0 deletions(-)
drivers/mfd/omap-usb-host.c +20 -0
@@ -632,6 +632,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_warn (dev,"ehci_logic_fck failed:%d\n" , ret); } +clk_prepare (omap->ehci_logic_fck);break ; }
@@ -641,6 +642,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"utmi_p1_gfclk failed error:%d\n" , ret); goto err_end; } +clk_prepare (omap->utmi_p1_fck); omap->xclk60mhsp1_ck =clk_get (dev,"xclk60mhsp1_ck" );if (IS_ERR (omap->xclk60mhsp1_ck)) {
@@ -648,6 +650,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"xclk60mhsp1_ck failed error:%d\n" , ret); goto err_utmi_p1_fck; } +clk_prepare (omap->xclk60mhsp1_ck); omap->utmi_p2_fck =clk_get (dev,"utmi_p2_gfclk" );if (IS_ERR (omap->utmi_p2_fck)) {
@@ -655,6 +658,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"utmi_p2_gfclk failed error:%d\n" , ret); goto err_xclk60mhsp1_ck; } +clk_prepare (omap->utmi_p2_fck); omap->xclk60mhsp2_ck =clk_get (dev,"xclk60mhsp2_ck" );if (IS_ERR (omap->xclk60mhsp2_ck)) {
@@ -662,6 +666,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"xclk60mhsp2_ck failed error:%d\n" , ret); goto err_utmi_p2_fck; } +clk_prepare (omap->xclk60mhsp2_ck); omap->usbhost_p1_fck =clk_get (dev,"usb_host_hs_utmi_p1_clk" );if (IS_ERR (omap->usbhost_p1_fck)) {
@@ -669,6 +674,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"usbhost_p1_fck failed error:%d\n" , ret); goto err_xclk60mhsp2_ck; } +clk_prepare (omap->usbhost_p1_fck); omap->usbtll_p1_fck =clk_get (dev,"usb_tll_hs_usb_ch0_clk" );if (IS_ERR (omap->usbtll_p1_fck)) {
@@ -676,6 +682,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"usbtll_p1_fck failed error:%d\n" , ret); goto err_usbhost_p1_fck; } +clk_prepare (omap->usbtll_p1_fck); omap->usbhost_p2_fck =clk_get (dev,"usb_host_hs_utmi_p2_clk" );if (IS_ERR (omap->usbhost_p2_fck)) {
@@ -683,6 +690,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"usbhost_p2_fck failed error:%d\n" , ret); goto err_usbtll_p1_fck; } +clk_prepare (omap->usbhost_p2_fck); omap->usbtll_p2_fck =clk_get (dev,"usb_tll_hs_usb_ch1_clk" );if (IS_ERR (omap->usbtll_p2_fck)) {
@@ -690,6 +698,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"usbtll_p2_fck failed error:%d\n" , ret); goto err_usbhost_p2_fck; } +clk_prepare (omap->usbtll_p2_fck); omap->init_60m_fclk =clk_get (dev,"init_60m_fclk" );if (IS_ERR (omap->init_60m_fclk)) {
@@ -697,6 +706,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)dev_err (dev,"init_60m_fclk failed error:%d\n" , ret); goto err_usbtll_p2_fck; } +clk_prepare (omap->init_60m_fclk);if (is_ehci_phy_mode (pdata->port_mode[0 ])) {/* for OMAP3 , the clk set paretn fails */
@@ -773,33 +783,43 @@ err_tll:iounmap (omap->uhh_base); err_init_60m_fclk: +clk_unprepare (omap->init_60m_fclk);clk_put (omap->init_60m_fclk); err_usbtll_p2_fck: +clk_unprepare (omap->usbtll_p2_fck);clk_put (omap->usbtll_p2_fck); err_usbhost_p2_fck: +clk_unprepare (omap->usbhost_p2_fck);clk_put (omap->usbhost_p2_fck); err_usbtll_p1_fck: +clk_unprepare (omap->usbtll_p1_fck);clk_put (omap->usbtll_p1_fck); err_usbhost_p1_fck: +clk_unprepare (omap->usbhost_p1_fck);clk_put (omap->usbhost_p1_fck); err_xclk60mhsp2_ck: +clk_unprepare (omap->xclk60mhsp2_ck);clk_put (omap->xclk60mhsp2_ck); err_utmi_p2_fck: +clk_unprepare (omap->utmi_p2_fck);clk_put (omap->utmi_p2_fck); err_xclk60mhsp1_ck: +clk_unprepare (omap->xclk60mhsp1_ck);clk_put (omap->xclk60mhsp1_ck); err_utmi_p1_fck: +clk_unprepare (omap->utmi_p1_fck);clk_put (omap->utmi_p1_fck); err_end: +clk_unprepare (omap->ehci_logic_fck);clk_put (omap->ehci_logic_fck);pm_runtime_disable (dev);kfree (omap);
Signature · 1 line
1.7.1
Paul Walmsley
maintainerPATCH 4/11 mfd: omap-usb: add clk_prepare and clk_unprepare
Quoted 5 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework (CCF) add
clk_prepare()andclk_unprepare()for the various usb host clocks.Signed-off-by Rajendra Nayak <[email protected]>Cc Samuel Ortiz <[email protected]>
Looks like this one will be at least partially obsoleted by this series:
ARM: OMAP: TLL driver implementation for USB host driver
http://marc.info/?l=linux-omap&m=134019432606399&w=2
and the runtime PM conversion in that series needs to be done anyway.
- Paul
PATCH 4/11 mfd: omap-usb: add clk_prepare and clk_unprepare
Quoted 10 lines · Paul Walmsley
Quoted 5 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework (CCF) add
clk_prepare()andclk_unprepare()for the various usb host clocks.Signed-off-by Rajendra Nayak <[email protected]>Cc Samuel Ortiz <[email protected]>Looks like this one will be at least partially obsoleted by this series:
Thanks paul
Hi Rajendra
please re-base this patch to below series:
Quoted 7 lines
ARM: OMAP: TLL driver implementation for USB host driver
http://marc.info/?l=linux-omap&m=134019432606399&w=2and the runtime PM conversion in that series needs to be done anyway.
- Paul
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omapdss clocks.
--- drivers/video/omap2/dss/dsi.c | 5 ++++- drivers/video/omap2/dss/hdmi.c | 5 ++++- drivers/video/omap2/dss/venc.c | 5 ++++- 3 files changed, 12 insertions(+), 3 deletions(-)
drivers/video/omap2/dss/dsi.c +4 -1
@@ -4776,6 +4776,7 @@ static int dsi_get_clocks(struct platform_device *dsidev) } dsi->sys_clk = clk; +clk_prepare (dsi->sys_clk);return 0 ; }
@@ -4786,8 +4787,10 @@ static void dsi_put_clocks(struct platform_device *dsidev)if (dsi->dss_clk)clk_put (dsi->dss_clk); -if (dsi->sys_clk) +if (dsi->sys_clk) { +clk_unprepare (dsi->sys_clk);clk_put (dsi->sys_clk); + } }static void __init dsi_probe_pdata (struct platform_device *dsidev)
drivers/video/omap2/dss/hdmi.c +4 -1
@@ -544,14 +544,17 @@ static int hdmi_get_clocks(struct platform_device *pdev) } hdmi.sys_clk = clk; +clk_prepare (hdmi.sys_clk);return 0 ; }static void hdmi_put_clocks (void ) { -if (hdmi.sys_clk) +if (hdmi.sys_clk) { +clk_unprepare (hdmi.sys_clk);clk_put (hdmi.sys_clk); + } }#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO )
drivers/video/omap2/dss/venc.c +4 -1
@@ -818,14 +818,17 @@ static int venc_get_clocks(struct platform_device *pdev) } venc.tv_dac_clk = clk; +clk_prepare (venc.tv_dac_clk);return 0 ; }static void venc_put_clocks (void ) { -if (venc.tv_dac_clk) +if (venc.tv_dac_clk) { +clk_unprepare (venc.tv_dac_clk);clk_put (venc.tv_dac_clk); + } }static void __init venc_probe_pdata (struct platform_device *pdev)
Signature · 1 line
1.7.1
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Hi,
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omapdss clocks.
You used clk_prepare and clk_unprepare instead of clk_prepare_enable and clk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context.
What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after clk_get, or prepare right before clk_enable? (And similarly for unprepare)
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120625/fb172c0f/attachment.sig>
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 11 lines · Tomi Valkeinen
Hi,
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omapdss clocks.You used
clk_prepareandclk_unprepareinstead ofclk_prepare_enableandclk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context.
Quoted 4 lines
What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after
clk_get, or prepare right beforeclk_enable? (And similarly for unprepare)
clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook.
The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after clk_get() and before clk_put() in this particular case.
Quoted 3 lines
Tom
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 23 lines · Rajendra Nayak
Quoted 11 lines · Tomi Valkeinen
Hi,
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omapdss clocks.You used
clk_prepareandclk_unprepareinstead ofclk_prepare_enableandclk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context.Quoted 4 lines
What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after
clk_get, or prepare right beforeclk_enable? (And similarly for unprepare)clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook.
Quoted 6 lines
The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after
clk_get()and beforeclk_put()in this particular case.
But the driver should not presume anything special about the clocks. In this case the dss driver would presume that the clocks it uses do not have prepare and unprepare hooks.
If the generally proper way to use prepare/unprepare is in combination of enable/disable, then I think we should try to do that.
I'll check if any of the dss clocks are enabled or disabled in atomic context.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120625/85453955/attachment.sig>
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 31 lines · Tomi Valkeinen
Quoted 23 lines · Rajendra Nayak
Quoted 11 lines · Tomi Valkeinen
Hi,
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omapdss clocks.You used
clk_prepareandclk_unprepareinstead ofclk_prepare_enableandclk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context.Quoted 4 lines
What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after
clk_get, or prepare right beforeclk_enable? (And similarly for unprepare)clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook.
Quoted 6 lines
The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after
clk_get()and beforeclk_put()in this particular case.
Quoted 6 lines
But the driver should not presume anything special about the clocks. In this case the dss driver would presume that the clocks it uses do not have prepare and unprepare hooks.
If the generally proper way to use prepare/unprepare is in combination of enable/disable, then I think we should try to do that.
makes sense. Lets see if any of the clk_enable/disable happen in atomic context, if not it would be just a matter of replacing all with a clk_prepare_enable/disable_unprepare. Else we might have to find a safe place sometime before clk_enable to prepare the clk and after clk_disable to unprepare it.
Quoted 6 lines
I'll check if any of the dss clocks are enabled or disabled in atomic context.
Tomi
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 36 lines · Rajendra Nayak
Quoted 35 lines · Tomi Valkeinen
Quoted 23 lines · Rajendra Nayak
Quoted 11 lines · Tomi Valkeinen
Hi,
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omapdss clocks.You used
clk_prepareandclk_unprepareinstead ofclk_prepare_enableandclk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context.Quoted 4 lines
What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after
clk_get, or prepare right beforeclk_enable? (And similarly for unprepare)clk_prepare/unprepare are useful for clocks which need the 'enable' logic to be implemented as a slow part (which can sleep) and a fast part (which does not sleep). For all the dss clocks in question we don't need a slow part and hence they do not have a .clk_prepare/unprepare platform hook.
Quoted 6 lines
The framework however still does prepare usecounting (it has a prepare count and an enable count, and prepare count is expected to be non-zero while the clock is being enabled) and uses a mutex around to guard it. So while the dss driver would do multiple clk_enable/disable while its active, it seems fair to just prepare/unprepare the clocks once just after
clk_get()and beforeclk_put()in this particular case.But the driver should not presume anything special about the clocks. In this case the dss driver would presume that the clocks it uses do not have prepare and unprepare hooks.
Quoted 12 lines
Quoted 2 lines
If the generally proper way to use prepare/unprepare is in combination of enable/disable, then I think we should try to do that.
makes sense. Lets see if any of the clk_enable/disable happen in atomic context, if not it would be just a matter of replacing all with a clk_prepare_enable/disable_unprepare. Else we might have to find a safe place sometime before
clk_enableto prepare the clk and afterclk_disableto unprepare it.Quoted 3 lines
I'll check if any of the dss clocks are enabled or disabled in atomic context.
venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend & resume). If I understand correctly, the callbacks are not called in atomic context if pm_runtime_irq_safe() has not been used. And it is not used in omapdss.
dsi uses clk_enable/disable in a different manner, but not in atomic context.
So as far as I see, clocks are never handled in atomic context. Is everything related to the base clk stuff already in mainline? Can I take the clk_prepare/unprepare patch into my omapdss tree?
A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets pm_runtime_irq_safe().
Now, the driver can call pm_runtime_get_sync() in an atomic context, and this would lead to the underlying framework (hwmod, omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't use clk_prepare.
How does the underlying framework handle that case? (sorry if that's a stupid question =).
Tomi
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 11 lines · Tomi Valkeinen
venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend& resume). If I understand correctly, the callbacks are not called in atomic context if
pm_runtime_irq_safe()has not been used. And it is not used in omapdss.dsi uses clk_enable/disable in a different manner, but not in atomic context.
So as far as I see, clocks are never handled in atomic context. Is everything related to the base clk stuff already in mainline? Can I take the clk_prepare/unprepare patch into my omapdss tree?
Well the Common Clk framework is already in mainline, but we still don;t have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so, clk_prepare/unprepare will just be stubs which do nothing.
I will repost the patch getting rid of the clk_prepare/unprepare and adding clk_prepare_enable/disable_unprepare instead.
Quoted 6 lines
A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets
pm_runtime_irq_safe().
Quoted 7 lines
Now, the driver can call
pm_runtime_get_sync()in an atomic context, and this would lead to the underlying framework (hwmod,omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't useclk_prepare.How does the underlying framework handle that case? (sorry if that's a stupid question =).
No, its not a stupid question at all. I have been thinking about this too to figure out whats the best way to handle this. For now, the patches I posted, do an early clk_prepare (like I did for dss) for all hwmod clocks as I have no way to know which ones will have their _enable, _idle etc called in atomic context. Maybe I should see if there is a way I can do so only for those devices which end up calling a pm_runtime_irq_safe() and not do it early for all.
Quoted 1 line
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 7 lines · Rajendra Nayak
Quoted 3 lines
So as far as I see, clocks are never handled in atomic context. Is everything related to the base clk stuff already in mainline? Can I take the clk_prepare/unprepare patch into my omapdss tree?
Well the Common Clk framework is already in mainline, but we still don;t have
CONFIG_COMMON_CLKenabled for our builds yet. So until we do so, clk_prepare/unprepare will just be stubs which do nothing.
But if I understood correctly, clk_prepare and clk_unprepare are anyway no-ops with dss clocks, even when CONFIG_COMMON_CLK is enabled?
My point was only to understand if I can safely take the patch into omapdss tree, instead of it going through l-o, to avoid any possible conflicts.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120626/ab95f1a0/attachment.sig>
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 6 lines · Tomi Valkeinen
Quoted 4 lines · Rajendra Nayak
Quoted 3 lines
So as far as I see, clocks are never handled in atomic context. Is everything related to the base clk stuff already in mainline? Can I take the clk_prepare/unprepare patch into my omapdss tree?
Quoted 6 lines
Quoted 3 lines
Well the Common Clk framework is already in mainline, but we still don;t have
CONFIG_COMMON_CLKenabled for our builds yet. So until we do so, clk_prepare/unprepare will just be stubs which do nothing.But if I understood correctly,
clk_prepareandclk_unprepareare anyway no-ops with dss clocks, even whenCONFIG_COMMON_CLKis enabled?
With CONFIG_COMMON_CLK enabled, they will do prepare use-counting with a mutex lock/unlock around it.
Quoted 4 lines
My point was only to understand if I can safely take the patch into omapdss tree, instead of it going through l-o, to avoid any possible conflicts.
yes, I don't see any issues with it going through dss tree.
Quoted 3 lines
Tomi
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
In reply to Tomi ValkeinenQuoted 4 lines · Tomi Valkeinen
A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets
pm_runtime_irq_safe().
Quoted 8 lines
Now, the driver can call
pm_runtime_get_sync()in an atomic context, and this would lead to the underlying framework (hwmod,omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't useclk_prepare.How does the underlying framework handle that case? (sorry if that's a stupid question =).
I think it's a good question!
If we're going to call clk_prepare_enable from within a runtime pm callback then I think we'll need to check if _irq_safe() is set and conditionally call only clk_enable in such a case.
I'm not a runtime pm expert, but if the driver owns the responsibility of calling pm_runtime_irq_safe then the driver has the proper context to know that it should call clk_prepare BEFORE calling pm_runtime_get_sync.
However if some other framework (outside of the driver) calls pm_runtime_irq_safe then it will be difficult for the driver to know what to do...
Regards,
Mike
Quoted 2 lines
Tomi
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 16 lines · Mike Turquette
Quoted 4 lines · Tomi Valkeinen
A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets
pm_runtime_irq_safe().Quoted 8 lines
Now, the driver can call
pm_runtime_get_sync()in an atomic context, and this would lead to the underlying framework (hwmod,omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't useclk_prepare.How does the underlying framework handle that case? (sorry if that's a stupid question =).
I think it's a good question!
Quoted 8 lines
If we're going to call
clk_prepare_enablefrom within a runtime pm callback then I think we'll need to check if_irq_safe()is set and conditionally call onlyclk_enablein such a case.I'm not a runtime pm expert, but if the driver owns the responsibility of calling
pm_runtime_irq_safethen the driver has the proper context to know that it should callclk_prepareBEFORE callingpm_runtime_get_sync.
That's not quite what I meant. If it's the driver that does clk_enable, be it in runtime PM callback or not, it's driver's responsibility.
But some clocks are not handled by the driver, but the hwmod/omap_device framework. Mainly I think this is for the functional and interface clocks. The driver has no visibility to those, they are implicitly enabled via pm_runtime_get.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120627/3f730154/attachment.sig>
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
Quoted 26 lines · Tomi Valkeinen
Quoted 16 lines · Mike Turquette
Quoted 4 lines · Tomi Valkeinen
A question about clk_prepare/unprepare, not directly related: let's say I have a driver for some HW block. The driver doesn't use clk functions, but uses runtime PM. The driver also sets
pm_runtime_irq_safe().Quoted 8 lines
Now, the driver can call
pm_runtime_get_sync()in an atomic context, and this would lead to the underlying framework (hwmod,omap_device, I don't know who =) enabling the func clock for that HW. But this would happen in atomic context, so the underlying framework can't useclk_prepare.How does the underlying framework handle that case? (sorry if that's a stupid question =).
I think it's a good question!
Quoted 8 lines
If we're going to call
clk_prepare_enablefrom within a runtime pm callback then I think we'll need to check if_irq_safe()is set and conditionally call onlyclk_enablein such a case.I'm not a runtime pm expert, but if the driver owns the responsibility of calling
pm_runtime_irq_safethen the driver has the proper context to know that it should callclk_prepareBEFORE callingpm_runtime_get_sync.
Quoted 7 lines
That's not quite what I meant. If it's the driver that does
clk_enable, be it in runtime PM callback or not, it's driver's responsibility.But some clocks are not handled by the driver, but the hwmod/omap_device framework. Mainly I think this is for the functional and interface clocks. The driver has no visibility to those, they are implicitly enabled via
pm_runtime_get.
yes, thats the tricky part on how would hwmod/omap_device know if the driver would use runtime pm within atomic context or non-atomic context. The driver does inform the runtime pm framework about this by calling a pm_runtime_irq_safe(), which is then used to set the .irq_safe flag telling it to leave the interrupts disabled during callbacks. This information however does not flow down to hwmod/omap_device in any way. So the way its currently handled is to do an early prepare of all hwmod controlled clocks.
I have copied Kevin in case he has any better ideas on how this should be handled.
Quoted 3 lines
Tomi
PATCH 5/11 OMAPDSS: add clk_prepare and clk_unprepare
In reply to Tomi ValkeinenQuoted 9 lines · Tomi Valkeinen
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omapdss clocks.You used
clk_prepareandclk_unprepareinstead ofclk_prepare_enableandclk_disable_unprepare. I didn't check the dss driver yet, but my hunch is that the clocks are normally not enabled/disabled from atomic context.
Quoted 4 lines
What does the prepare/unprepare actually do? Is there any benefit in delaying preparing, i.e. is there a difference between prepare right after
clk_get, or prepare right beforeclk_enable? (And similarly for unprepare)
I think you're looking at this the wrong way.
Think of clk_prepare() as the _sleepable_ part of clk_enable(). So, think of clk_prepare() as ideally being placed just before clk_enable() with the exception that if that's not possible (because you're in a non-atomic context) it should be placed in a position as close to clk_enable() as possible which is atomic.
Don't think of it as an extra step to be done after clk_get() but as an extra step needing to be done before clk_enable().
PATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() for omap gpio debounce clock.
--- drivers/gpio/gpio-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/gpio/gpio-omap.c +2 -0
@@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset, bank->dbck =clk_get (bank->dev,"dbclk" );if (IS_ERR (bank->dbck))dev_err (bank->dev,"Could not get gpio dbck\n" ); +else +clk_prepare (bank->dbck); }spin_lock_irqsave (&bank->lock, flags);
Signature · 1 line
1.7.1
PATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
HI,
Quoted 8 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()for omap gpio debounce clock.Signed-off-by Rajendra Nayak <[email protected]>Cc Grant Likely <[email protected]>---
?drivers/gpio/gpio-omap.c | ? ?2 ++
?1 files changed, 2 insertions(+), 0 deletions(-)
Regards,
Pankaj Jangra
Paul Walmsley
maintainerPATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
In reply to Rajendra NayakHi
Quoted 14 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()for omap gpio debounce clock.Signed-off-by Rajendra Nayak <[email protected]>Cc Grant Likely <[email protected]>--- drivers/gpio/gpio-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)drivers/gpio/gpio-omap.c +0
-0
drivers/gpio/gpio-omap.c static int gpio_debounce(struct gpio_chip *chip, unsigned offset, · line 900
Quoted 8 lines
drivers/gpio/gpio-omap.c +2
-0@@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset, bank->dbck =clk_get (bank->dev,"dbclk" );if (IS_ERR (bank->dbck))dev_err (bank->dev,"Could not get gpio dbck\n" ); +else +clk_prepare (bank->dbck); }spin_lock_irqsave (&bank->lock, flags);
What code unprepares this clock?
Put differently, doesn't this driver need at least a platform_driver .remove function pointer, that would call clk_unprepare() and clk_put()?
Also, it looks to me that the bank->dbck init should be in omap_gpio_chip_init(), not gpio_debounce()?
- Paul
PATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
Quoted 25 lines · Paul Walmsley
Hi
Quoted 21 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()for omap gpio debounce clock.Signed-off-by Rajendra Nayak<[email protected]>Cc Grant Likely<[email protected]>--- drivers/gpio/gpio-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)drivers/gpio/gpio-omap.c +2
-0@@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip, unsigned offset, bank->dbck =clk_get (bank->dev,"dbclk" );if (IS_ERR (bank->dbck))dev_err (bank->dev,"Could not get gpio dbck\n" ); +else +clk_prepare (bank->dbck); }
Quoted 6 lines
drivers/gpio/gpio-omap.c static int gpio_debounce(struct gpio_chip *chip, unsigned offset, · line 900
Quoted 1 line
drivers/gpio/gpio-omap.c +0
-0spin_lock_irqsave (&bank->lock, flags);What code unprepares this clock?
Put differently, doesn't this driver need at least a
platform_driver.remove function pointer, that would callclk_unprepare()andclk_put()?
Maybe because this driver can never be built as a module. It gets complied in with CONFIG_ARCH_OMAP=y.
Adding Tarun and Santosh who can comment further.
Quoted 3 lines
Also, it looks to me that the
bank->dbckinit should be inomap_gpio_chip_init(), notgpio_debounce()?
Tarun, can you comment on why the dbck init is in gpio_debounce and not in omap_gpio_chip_init()?
Quoted 3 lines
- Paul
PATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
Quoted 45 lines · Rajendra Nayak
Quoted 28 lines · Paul Walmsley
Hi
Quoted 23 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()
for omap gpio debounce clock.Signed-off-by Rajendra Nayak<[email protected]>Cc Grant Likely<[email protected]>---
?drivers/gpio/gpio-omap.c | ? ?2 ++
?1 files changed, 2 insertions(+), 0 deletions(-)drivers/gpio/gpio-omap.c +2
-0@@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip,unsigned offset, ? ? ? ? ? ? ? ?bank->dbck = clk_get(bank->dev, "dbclk"); ? ? ? ? ? ? ? ?if (IS_ERR(bank->dbck)) ? ? ? ? ? ? ? ? ? ? ? ?dev_err(bank->dev, "Could not get gpio dbck\n"); + ? ? ? ? ? ? ? else + ? ? ? ? ? ? ? ? ? ? ? clk_prepare(bank->dbck); ? ? ? ?}Quoted 7 lines
Quoted 1 line
? ? ? ?spin_lock_irqsave(&bank->lock, flags);
What code unprepares this clock?
Put differently, doesn't this driver need at least a
platform_driver.remove function pointer, that would callclk_unprepare()andclk_put()?Maybe because this driver can never be built as a module. It gets complied in with
CONFIG_ARCH_OMAP=y.Adding Tarun and Santosh who can comment further.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
Also, it looks to me that the
bank->dbckinit should be inomap_gpio_chip_init(), notgpio_debounce()?Tarun, can you comment on why the dbck init is in
gpio_debounceand not inomap_gpio_chip_init()?
BTW, bank->dbck is initialized in gpio_debounce() even before the cleanup and fixes series. I am not quite sure if there was specific intent for keeping it here. Personally I do not see issues in doing clk_get of bank->dbck in omap_gpio_chip_init().
Quoted 6 lines
Quoted 4 lines
- Paul
PATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
Quoted 50 lines · Tarun Kanti
Quoted 49 lines · Rajendra Nayak
Quoted 28 lines · Paul Walmsley
Hi
Quoted 23 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()
for omap gpio debounce clock.Signed-off-by Rajendra Nayak<[email protected]>Cc Grant Likely<[email protected]>--- drivers/gpio/gpio-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)drivers/gpio/gpio-omap.c +2
-0@@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip,unsigned offset, bank->dbck = clk_get(bank->dev, "dbclk");if (IS_ERR (bank->dbck))dev_err (bank->dev,"Could not get gpio dbck\n" ); +else +clk_prepare (bank->dbck); }Quoted 7 lines
Quoted 1 line
spin_lock_irqsave(&bank->lock, flags);What code unprepares this clock?
Put differently, doesn't this driver need at least a
platform_driver.remove function pointer, that would callclk_unprepare()andclk_put()?Maybe because this driver can never be built as a module. It gets complied in with
CONFIG_ARCH_OMAP=y.Adding Tarun and Santosh who can comment further.
Quoted 3 lines
Also, it looks to me that the
bank->dbckinit should be inomap_gpio_chip_init(), notgpio_debounce()?
Quoted 6 lines
Quoted 2 lines
Tarun, can you comment on why the dbck init is in
gpio_debounceand not inomap_gpio_chip_init()?BTW,
bank->dbckis initialized ingpio_debounce()even before the cleanup and fixes series. I am not quite sure if there was specific intent for keeping it here. Personally I do not see issues in doingclk_getofbank->dbckinomap_gpio_chip_init().
Care to send a patch to move it into omap_gpio_chip_init() then? Also can you comment on the above point that Paul made, as to why this driver has a .remove missing? If adding that is a non-issue, would be great if you can drop in a patch for that too.
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
- Paul
PATCH 6/11 gpio/omap: add clk_prepare and clk_unprepare
Quoted 67 lines · Rajendra Nayak
Quoted 56 lines · Tarun Kanti
Quoted 54 lines · On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak<[email protected]> ?wrote:
Quoted 29 lines · Paul Walmsley
Hi
Quoted 23 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()
for omap gpio debounce clock.Signed-off-by Rajendra Nayak<[email protected]>Cc Grant Likely<[email protected]>---
?drivers/gpio/gpio-omap.c | ? ?2 ++
?1 files changed, 2 insertions(+), 0 deletions(-)drivers/gpio/gpio-omap.c +2
-0@@ -893,6 +893,8 @@ static int gpio_debounce(struct gpio_chip *chip,unsigned offset, ? ? ? ? ? ? ? ?bank->dbck = clk_get(bank->dev, "dbclk"); ? ? ? ? ? ? ? ?if (IS_ERR(bank->dbck)) ? ? ? ? ? ? ? ? ? ? ? ?dev_err(bank->dev, "Could not get gpio dbck\n"); + ? ? ? ? ? ? ? else + ? ? ? ? ? ? ? ? ? ? ? clk_prepare(bank->dbck); ? ? ? ?}Quoted 8 lines
Quoted 1 line
? ? ? ?spin_lock_irqsave(&bank->lock, flags);
What code unprepares this clock?
Put differently, doesn't this driver need at least a
platform_driver.remove function pointer, that would callclk_unprepare()andclk_put()?Maybe because this driver can never be built as a module. It gets complied in with
CONFIG_ARCH_OMAP=y.Adding Tarun and Santosh who can comment further.
Quoted 3 lines
Also, it looks to me that the
bank->dbckinit should be inomap_gpio_chip_init(), notgpio_debounce()?Quoted 8 lines
Quoted 2 lines
Tarun, can you comment on why the dbck init is in
gpio_debounceand not inomap_gpio_chip_init()?BTW,
bank->dbckis initialized ingpio_debounce()even before the cleanup and fixes series. I am not quite sure if there was specific intent for keeping
it here. Personally I do not see issues in doingclk_getofbank->dbckinomap_gpio_chip_init().
Quoted 4 lines
Care to send a patch to move it into
omap_gpio_chip_init()then? Also can you comment on the above point that Paul made, as to why this driver has a .remove missing? If adding that is a non-issue, would be great if you can drop in a patch for that too.
Yes, I will have a re-look before generating the patches. --
Tarun
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
- Paul
PATCH 7/11 w1: omap_hdq: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the hdq clocks.
--- drivers/w1/masters/omap_hdq.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
drivers/w1/masters/omap_hdq.c +4 -4
@@ -609,13 +609,13 @@ static int __devinit omap_hdq_probe(struct platform_device *pdev) hdq_data->hdq_usecount =0 ;mutex_init (&hdq_data->hdq_mutex); -if (clk_enable (hdq_data->hdq_ick)) { +if (clk_prepare_enable (hdq_data->hdq_ick)) {dev_dbg (&pdev->dev,"Can not enable ick\n" ); ret = -ENODEV ; goto err_intfclk; } -if (clk_enable (hdq_data->hdq_fck)) { +if (clk_prepare_enable (hdq_data->hdq_fck)) {dev_dbg (&pdev->dev,"Can not enable fck\n" ); ret = -ENODEV ; goto err_fnclk;
@@ -657,10 +657,10 @@ static int __devinit omap_hdq_probe(struct platform_device *pdev) err_w1: err_irq: -clk_disable (hdq_data->hdq_fck); +clk_disable_unprepare (hdq_data->hdq_fck); err_fnclk: -clk_disable (hdq_data->hdq_ick); +clk_disable_unprepare (hdq_data->hdq_ick); err_intfclk:clk_put (hdq_data->hdq_fck);
Signature · 1 line
1.7.1
Paul Walmsley
maintainerPATCH 7/11 w1: omap_hdq: add clk_prepare and clk_unprepare
Quoted 5 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the hdq clocks.Signed-off-by Rajendra Nayak <[email protected]>Cc Evgeniy Polyakov <[email protected]>
This one should not be needed soon:
http://marc.info/?l=linux-omap&m=134037453807275&w=2
- Paul
PATCH 7/11 w1: omap_hdq: add clk_prepare and clk_unprepare
Quoted 11 lines · Paul Walmsley
Quoted 5 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the hdq clocks.Signed-off-by Rajendra Nayak<[email protected]>Cc Evgeniy Polyakov<[email protected]>This one should not be needed soon:
Ok, thanks, will drop this one then.
Quoted 2 lines
- Paul
PATCH 8/11 crypto: omap: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the omap crypto clocks.
--- drivers/crypto/omap-aes.c | 2 ++ drivers/crypto/omap-sham.c | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-)
drivers/crypto/omap-aes.c +2 -0
@@ -848,6 +848,7 @@ static int omap_aes_probe(struct platform_device *pdev) err =PTR_ERR (dd->iclk); goto err_res; } +clk_prepare (dd->iclk); dd->io_base =ioremap (dd->phys_base,SZ_4K );if (!dd->io_base) {
@@ -894,6 +895,7 @@ err_dma:tasklet_kill (&dd->queue_task);iounmap (dd->io_base); err_io: +clk_unprepare (dd->iclk);clk_put (dd->iclk); err_res:kfree (dd);
drivers/crypto/omap-sham.c +2 -0
@@ -1205,6 +1205,7 @@ static int __devinit omap_sham_probe(struct platform_device *pdev) err =PTR_ERR (dd->iclk); goto clk_err; } +clk_prepare (dd->iclk); dd->io_base =ioremap (dd->phys_base,SZ_4K );if (!dd->io_base) {
@@ -1236,6 +1237,7 @@ err_algs:crypto_unregister_ahash (&algs[j]);iounmap (dd->io_base); io_err: +clk_unprepare (dd->iclk);clk_put (dd->iclk); clk_err:omap_sham_dma_cleanup (dd);
Signature · 1 line
1.7.1
Paul Walmsley
maintainerPATCH 8/11 crypto: omap: add clk_prepare and clk_unprepare
Hi
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omap crypto clocks.
These drivers should be converted to use runtime PM instead, since that needs to be done anyway.
- Paul
PATCH 8/11 crypto: omap: add clk_prepare and clk_unprepare
Quoted 9 lines · Paul Walmsley
Hi
Quoted 2 lines · Rajendra Nayak
In preparation of OMAP moving to Common Clk Framework(CCF) add
clk_prepare()andclk_unprepare()for the omap crypto clocks.These drivers should be converted to use runtime PM instead, since that needs to be done anyway.
So if CCF conversion patches get in before these get converted to runtime PM, do we break them? or should CCF conversion for OMAP wait till all remaining drivers get converted to runtime PM?
Quoted 3 lines
- Paul
Paul Walmsley
maintainerPATCH 8/11 crypto: omap: add clk_prepare and clk_unprepare
Quoted 3 lines · Rajendra Nayak
So if CCF conversion patches get in before these get converted to runtime PM, do we break them? or should CCF conversion for OMAP wait till all remaining drivers get converted to runtime PM?
I'd suggest getting patches 1, 10, and 11 from your series in shape and PM-tested. Those shouldn't have any driver dependencies, so once those are in good condition, they can be merged through the OMAP tree.
Then at the same time, maybe get the rest of the drivers runtime-PM converted and acked through their respective maintainers. Looks like you have a couple of driver patches that don't involve runtime-PM conversions; those can presumably get merged through their respective maintainers?
...
I did notice that some other driver conversions weren't present in this series, e.g., omap3isp. If someone doesn't convert those drivers, then those seem likely to break.
- Paul
PATCH 8/11 crypto: omap: add clk_prepare and clk_unprepare
Quoted 2 lines · Paul Walmsley
Then at the same time, maybe get the rest of the drivers runtime-PM converted and acked through their respective maintainers.
So if I read your response correctly, you are saying all OMAP drivers being converted to use runtime PM is a pre-requisite for OMAP moving over to use Common Clk framework?
PATCH 9/11 iommu: omap: add clk_prepare and clk_unprepare
In reply to Rajendra NayakIn preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare() and clk_unprepare() for the iommu clocks.
--- drivers/iommu/omap-iommu.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/iommu/omap-iommu.c +2 -0
@@ -923,6 +923,7 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj->clk =clk_get (&pdev->dev, pdata->clk_name);if (IS_ERR (obj->clk)) goto err_clk; +clk_prepare (obj->clk); obj->nr_tlb_entries = pdata->nr_tlb_entries; obj->name = pdata->name;
@@ -974,6 +975,7 @@ err_irq: err_ioremap:release_mem_region (res->start,resource_size (res)); err_mem: +clk_unprepare (obj->clk);clk_put (obj->clk); err_clk:kfree (obj);
Signature · 1 line
1.7.1
PATCH 10/11 ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
In reply to Rajendra NayakMoving to Common clk framework for OMAP would mean we no longer use internal lookup mechanism like omap_clk_get_by_name(). get rid of all its usage mostly from hwmod and omap_device code.
Also use IS_ERR_OR_NULL() for error checking.
Moving to clk_get() also means the respective platforms need the clkdev tables updated with an entry for all clocks used by hwmod to have clock name same as the alias.
Based on original changes from Mike Turquette.
--- arch/arm/mach-omap2/clock2420_data.c | 17 +++++++++++++++++ arch/arm/mach-omap2/clock2430_data.c | 21 +++++++++++++++++++++ arch/arm/mach-omap2/clock3xxx_data.c | 24 ++++++++++++++++++++++++ arch/arm/mach-omap2/clock44xx_data.c | 17 +++++++++++++++++ arch/arm/mach-omap2/omap_hwmod.c | 12 ++++++------ arch/arm/plat-omap/omap_device.c | 6 +++--- 6 files changed, 88 insertions(+), 9 deletions(-)
arch/arm/mach-omap2/clock2420_data.c +17 -0
@@ -1808,6 +1808,7 @@ static struct omap_clk omap2420_clks[] = {CLK (NULL ,"gfx_ick" , &gfx_ick,CK_242X ),/* DSS domain clocks */ CLK ("omapdss_dss" ,"ick" , &dss_ick,CK_242X ), +CLK (NULL ,"dss_ick" , &dss_ick,CK_242X ),CLK (NULL ,"dss1_fck" , &dss1_fck,CK_242X ),CLK (NULL ,"dss2_fck" , &dss2_fck,CK_242X ), CLK(NULL, "dss_54m_fck", &dss_54m_fck, CK_242X),
@@ -1847,12 +1848,16 @@ static struct omap_clk omap2420_clks[] = {CLK (NULL ,"gpt12_ick" , &gpt12_ick,CK_242X ),CLK (NULL ,"gpt12_fck" , &gpt12_fck,CK_242X ),CLK ("omap-mcbsp.1" ,"ick" , &mcbsp1_ick,CK_242X ), +CLK (NULL ,"mcbsp1_ick" , &mcbsp1_ick,CK_242X ),CLK (NULL ,"mcbsp1_fck" , &mcbsp1_fck,CK_242X ),CLK ("omap-mcbsp.2" ,"ick" , &mcbsp2_ick,CK_242X ), +CLK (NULL ,"mcbsp2_ick" , &mcbsp2_ick,CK_242X ),CLK (NULL ,"mcbsp2_fck" , &mcbsp2_fck,CK_242X ),CLK ("omap2_mcspi.1" ,"ick" , &mcspi1_ick,CK_242X ), +CLK (NULL ,"mcspi1_ick" , &mcspi1_ick,CK_242X ),CLK (NULL ,"mcspi1_fck" , &mcspi1_fck,CK_242X ),CLK ("omap2_mcspi.2" ,"ick" , &mcspi2_ick,CK_242X ), +CLK (NULL ,"mcspi2_ick" , &mcspi2_ick,CK_242X ),CLK (NULL ,"mcspi2_fck" , &mcspi2_fck,CK_242X ),CLK (NULL ,"uart1_ick" , &uart1_ick,CK_242X ), CLK(NULL, "uart1_fck", &uart1_fck, CK_242X),
@@ -1863,12 +1868,15 @@ static struct omap_clk omap2420_clks[] = {CLK (NULL ,"gpios_ick" , &gpios_ick,CK_242X ),CLK (NULL ,"gpios_fck" , &gpios_fck,CK_242X ),CLK ("omap_wdt" ,"ick" , &mpu_wdt_ick,CK_242X ), +CLK (NULL ,"mpu_wdt_ick" , &mpu_wdt_ick,CK_242X ),CLK (NULL ,"mpu_wdt_fck" , &mpu_wdt_fck,CK_242X ),CLK (NULL ,"sync_32k_ick" , &sync_32k_ick,CK_242X ),CLK (NULL ,"wdt1_ick" , &wdt1_ick,CK_242X ),CLK (NULL ,"omapctrl_ick" , &omapctrl_ick,CK_242X ),CLK ("omap24xxcam" ,"fck" , &cam_fck,CK_242X ), +CLK (NULL ,"cam_fck" , &cam_fck,CK_242X ),CLK ("omap24xxcam" ,"ick" , &cam_ick,CK_242X ), +CLK (NULL ,"cam_ick" , &cam_ick,CK_242X ),CLK (NULL ,"mailboxes_ick" , &mailboxes_ick,CK_242X ),CLK (NULL ,"wdt4_ick" , &wdt4_ick,CK_242X ), CLK(NULL, "wdt4_fck", &wdt4_fck, CK_242X),
@@ -1877,16 +1885,22 @@ static struct omap_clk omap2420_clks[] = {CLK (NULL ,"mspro_ick" , &mspro_ick,CK_242X ),CLK (NULL ,"mspro_fck" , &mspro_fck,CK_242X ),CLK ("mmci-omap.0" ,"ick" , &mmc_ick,CK_242X ), +CLK (NULL ,"mmc_ick" , &mmc_ick,CK_242X ),CLK ("mmci-omap.0" ,"fck" , &mmc_fck,CK_242X ), +CLK (NULL ,"mmc_fck" , &mmc_fck,CK_242X ),CLK (NULL ,"fac_ick" , &fac_ick,CK_242X ),CLK (NULL ,"fac_fck" , &fac_fck,CK_242X ),CLK (NULL ,"eac_ick" , &eac_ick,CK_242X ),CLK (NULL ,"eac_fck" , &eac_fck,CK_242X ),CLK ("omap_hdq.0" ,"ick" , &hdq_ick,CK_242X ), +CLK (NULL ,"hdq_ick" , &hdq_ick,CK_242X ),CLK ("omap_hdq.0" ,"fck" , &hdq_fck,CK_242X ), +CLK (NULL ,"hdq_fck" , &hdq_fck,CK_242X ),CLK ("omap_i2c.1" ,"ick" , &i2c1_ick,CK_242X ), +CLK (NULL ,"i2c1_ick" , &i2c1_ick,CK_242X ),CLK (NULL ,"i2c1_fck" , &i2c1_fck,CK_242X ),CLK ("omap_i2c.2" ,"ick" , &i2c2_ick,CK_242X ), +CLK (NULL ,"i2c2_ick" , &i2c2_ick,CK_242X ),CLK (NULL ,"i2c2_fck" , &i2c2_fck,CK_242X ),CLK (NULL ,"gpmc_fck" , &gpmc_fck,CK_242X ), CLK(NULL, "sdma_fck", &sdma_fck, CK_242X),
@@ -1896,8 +1910,11 @@ static struct omap_clk omap2420_clks[] = {CLK (NULL ,"vlynq_fck" , &vlynq_fck,CK_242X ),CLK (NULL ,"des_ick" , &des_ick,CK_242X ),CLK ("omap-sham" ,"ick" , &sha_ick,CK_242X ), +CLK (NULL ,"sha_ick" , &sha_ick,CK_242X ),CLK ("omap_rng" ,"ick" , &rng_ick,CK_242X ), +CLK (NULL ,"rng_ick" , &rng_ick,CK_242X ),CLK ("omap-aes" ,"ick" , &aes_ick,CK_242X ), +CLK (NULL ,"aes_ick" , &aes_ick,CK_242X ),CLK (NULL ,"pka_ick" , &pka_ick,CK_242X ),CLK (NULL ,"usb_fck" , &usb_fck,CK_242X ), CLK("musb-hdrc", "fck", &osc_ck, CK_242X),
arch/arm/mach-omap2/clock2430_data.c +21 -0
@@ -1897,6 +1897,7 @@ static struct omap_clk omap2430_clks[] = {CLK (NULL ,"mdm_osc_ck" , &mdm_osc_ck,CK_243X ),/* DSS domain clocks */ CLK ("omapdss_dss" ,"ick" , &dss_ick,CK_243X ), +CLK (NULL ,"dss_ick" , &dss_ick,CK_243X ),CLK (NULL ,"dss1_fck" , &dss1_fck,CK_243X ),CLK (NULL ,"dss2_fck" , &dss2_fck,CK_243X ), CLK(NULL, "dss_54m_fck", &dss_54m_fck, CK_243X),
@@ -1936,20 +1937,28 @@ static struct omap_clk omap2430_clks[] = {CLK (NULL ,"gpt12_ick" , &gpt12_ick,CK_243X ),CLK (NULL ,"gpt12_fck" , &gpt12_fck,CK_243X ),CLK ("omap-mcbsp.1" ,"ick" , &mcbsp1_ick,CK_243X ), +CLK (NULL ,"mcbsp1_ick" , &mcbsp1_ick,CK_243X ),CLK (NULL ,"mcbsp1_fck" , &mcbsp1_fck,CK_243X ),CLK ("omap-mcbsp.2" ,"ick" , &mcbsp2_ick,CK_243X ), +CLK (NULL ,"mcbsp2_ick" , &mcbsp2_ick,CK_243X ),CLK (NULL ,"mcbsp2_fck" , &mcbsp2_fck,CK_243X ),CLK ("omap-mcbsp.3" ,"ick" , &mcbsp3_ick,CK_243X ), +CLK (NULL ,"mcbsp3_ick" , &mcbsp3_ick,CK_243X ),CLK (NULL ,"mcbsp3_fck" , &mcbsp3_fck,CK_243X ),CLK ("omap-mcbsp.4" ,"ick" , &mcbsp4_ick,CK_243X ), +CLK (NULL ,"mcbsp4_ick" , &mcbsp4_ick,CK_243X ),CLK (NULL ,"mcbsp4_fck" , &mcbsp4_fck,CK_243X ),CLK ("omap-mcbsp.5" ,"ick" , &mcbsp5_ick,CK_243X ), +CLK (NULL ,"mcbsp5_ick" , &mcbsp5_ick,CK_243X ),CLK (NULL ,"mcbsp5_fck" , &mcbsp5_fck,CK_243X ),CLK ("omap2_mcspi.1" ,"ick" , &mcspi1_ick,CK_243X ), +CLK (NULL ,"mcspi1_ick" , &mcspi1_ick,CK_243X ),CLK (NULL ,"mcspi1_fck" , &mcspi1_fck,CK_243X ),CLK ("omap2_mcspi.2" ,"ick" , &mcspi2_ick,CK_243X ), +CLK (NULL ,"mcspi2_ick" , &mcspi2_ick,CK_243X ),CLK (NULL ,"mcspi2_fck" , &mcspi2_fck,CK_243X ),CLK ("omap2_mcspi.3" ,"ick" , &mcspi3_ick,CK_243X ), +CLK (NULL ,"mcspi3_ick" , &mcspi3_ick,CK_243X ),CLK (NULL ,"mcspi3_fck" , &mcspi3_fck,CK_243X ),CLK (NULL ,"uart1_ick" , &uart1_ick,CK_243X ), CLK(NULL, "uart1_fck", &uart1_fck, CK_243X),
@@ -1960,13 +1969,16 @@ static struct omap_clk omap2430_clks[] = {CLK (NULL ,"gpios_ick" , &gpios_ick,CK_243X ),CLK (NULL ,"gpios_fck" , &gpios_fck,CK_243X ),CLK ("omap_wdt" ,"ick" , &mpu_wdt_ick,CK_243X ), +CLK (NULL ,"mpu_wdt_ick" , &mpu_wdt_ick,CK_243X ),CLK (NULL ,"mpu_wdt_fck" , &mpu_wdt_fck,CK_243X ),CLK (NULL ,"sync_32k_ick" , &sync_32k_ick,CK_243X ),CLK (NULL ,"wdt1_ick" , &wdt1_ick,CK_243X ),CLK (NULL ,"omapctrl_ick" , &omapctrl_ick,CK_243X ),CLK (NULL ,"icr_ick" , &icr_ick,CK_243X ),CLK ("omap24xxcam" ,"fck" , &cam_fck,CK_243X ), +CLK (NULL ,"cam_fck" , &cam_fck,CK_243X ),CLK ("omap24xxcam" ,"ick" , &cam_ick,CK_243X ), +CLK (NULL ,"cam_ick" , &cam_ick,CK_243X ),CLK (NULL ,"mailboxes_ick" , &mailboxes_ick,CK_243X ),CLK (NULL ,"wdt4_ick" , &wdt4_ick,CK_243X ), CLK(NULL, "wdt4_fck", &wdt4_fck, CK_243X),
@@ -1975,10 +1987,14 @@ static struct omap_clk omap2430_clks[] = {CLK (NULL ,"fac_ick" , &fac_ick,CK_243X ),CLK (NULL ,"fac_fck" , &fac_fck,CK_243X ),CLK ("omap_hdq.0" ,"ick" , &hdq_ick,CK_243X ), +CLK (NULL ,"hdq_ick" , &hdq_ick,CK_243X ),CLK ("omap_hdq.1" ,"fck" , &hdq_fck,CK_243X ), +CLK (NULL ,"hdq_fck" , &hdq_fck,CK_243X ),CLK ("omap_i2c.1" ,"ick" , &i2c1_ick,CK_243X ), +CLK (NULL ,"i2c1_ick" , &i2c1_ick,CK_243X ),CLK (NULL ,"i2chs1_fck" , &i2chs1_fck,CK_243X ),CLK ("omap_i2c.2" ,"ick" , &i2c2_ick,CK_243X ), +CLK (NULL ,"i2c2_ick" , &i2c2_ick,CK_243X ),CLK (NULL ,"i2chs2_fck" , &i2chs2_fck,CK_243X ),CLK (NULL ,"gpmc_fck" , &gpmc_fck,CK_243X ), CLK(NULL, "sdma_fck", &sdma_fck, CK_243X),
@@ -1991,15 +2007,20 @@ static struct omap_clk omap2430_clks[] = {CLK (NULL ,"pka_ick" , &pka_ick,CK_243X ),CLK (NULL ,"usb_fck" , &usb_fck,CK_243X ),CLK ("musb-omap2430" ,"ick" , &usbhs_ick,CK_243X ), +CLK (NULL ,"usbhs_ick" , &usbhs_ick,CK_243X ),CLK ("omap_hsmmc.0" ,"ick" , &mmchs1_ick,CK_243X ), +CLK (NULL ,"mmchs1_ick" , &mmchs1_ick,CK_243X ),CLK (NULL ,"mmchs1_fck" , &mmchs1_fck,CK_243X ),CLK ("omap_hsmmc.1" ,"ick" , &mmchs2_ick,CK_243X ), +CLK (NULL ,"mmchs2_ick" , &mmchs2_ick,CK_243X ),CLK (NULL ,"mmchs2_fck" , &mmchs2_fck,CK_243X ),CLK (NULL ,"gpio5_ick" , &gpio5_ick,CK_243X ),CLK (NULL ,"gpio5_fck" , &gpio5_fck,CK_243X ),CLK (NULL ,"mdm_intc_ick" , &mdm_intc_ick,CK_243X ),CLK ("omap_hsmmc.0" ,"mmchsdb_fck" , &mmchsdb1_fck,CK_243X ), +CLK (NULL ,"mmchsdb1_fck" , &mmchsdb1_fck,CK_243X ),CLK ("omap_hsmmc.1" ,"mmchsdb_fck" , &mmchsdb2_fck,CK_243X ), +CLK (NULL ,"mmchsdb2_fck" , &mmchsdb2_fck,CK_243X ),CLK ("omap_timer.1" ,"32k_ck" , &func_32k_ck,CK_243X ),CLK ("omap_timer.2" ,"32k_ck" , &func_32k_ck,CK_243X ), CLK("omap_timer.3", "32k_ck", &func_32k_ck, CK_243X),
arch/arm/mach-omap2/clock3xxx_data.c +24 -0
@@ -3260,6 +3260,7 @@ static struct omap_clk omap3xxx_clks[] = {CLK (NULL ,"dpll4_x2_ck" , &dpll4_x2_ck,CK_3XXX ),CLK (NULL ,"omap_192m_alwon_fck" , &omap_192m_alwon_fck,CK_36XX ),CLK (NULL ,"omap_96m_alwon_fck" , &omap_96m_alwon_fck,CK_3XXX ), +CLK (NULL ,"omap_96m_alwon_fck_3630" , &omap_96m_alwon_fck_3630,CK_3XXX ),CLK (NULL ,"omap_96m_fck" , &omap_96m_fck,CK_3XXX ),CLK (NULL ,"cm_96m_fck" , &cm_96m_fck,CK_3XXX ), CLK(NULL, "omap_54m_fck", &omap_54m_fck, CK_3XXX),
@@ -3329,6 +3330,7 @@ static struct omap_clk omap3xxx_clks[] = {CLK (NULL ,"fshostusb_fck" , &fshostusb_fck,CK_3430ES1 ),CLK (NULL ,"core_12m_fck" , &core_12m_fck,CK_3XXX ),CLK ("omap_hdq.0" ,"fck" , &hdq_fck,CK_3XXX ), +CLK (NULL ,"hdq_fck" , &hdq_fck,CK_3XXX ),CLK (NULL ,"ssi_ssr_fck" , &ssi_ssr_fck_3430es1,CK_3430ES1 ),CLK (NULL ,"ssi_ssr_fck" , &ssi_ssr_fck_3430es2,CK_3430ES2PLUS |CK_36XX ), CLK(NULL, "ssi_sst_fck", &ssi_sst_fck_3430es1, CK_3430ES1),
@@ -3336,6 +3338,8 @@ static struct omap_clk omap3xxx_clks[] = {CLK (NULL ,"core_l3_ick" , &core_l3_ick,CK_3XXX ),CLK ("musb-omap2430" ,"ick" , &hsotgusb_ick_3430es1,CK_3430ES1 ),CLK ("musb-omap2430" ,"ick" , &hsotgusb_ick_3430es2,CK_3430ES2PLUS |CK_36XX ), +CLK (NULL ,"hsotgusb_ick" , &hsotgusb_ick_3430es1,CK_3430ES1 ), +CLK (NULL ,"hsotgusb_ick" , &hsotgusb_ick_3430es2,CK_3430ES2PLUS |CK_36XX ),CLK (NULL ,"sdrc_ick" , &sdrc_ick,CK_3XXX ),CLK (NULL ,"gpmc_fck" , &gpmc_fck,CK_3XXX ), CLK(NULL, "security_l3_ick", &security_l3_ick, CK_34XX | CK_36XX),
@@ -3344,27 +3348,40 @@ static struct omap_clk omap3xxx_clks[] = {CLK (NULL ,"usbtll_ick" , &usbtll_ick,CK_3430ES2PLUS |CK_AM35XX |CK_36XX ),CLK ("usbhs_omap" ,"usbtll_ick" , &usbtll_ick,CK_3430ES2PLUS |CK_AM35XX |CK_36XX ),CLK ("omap_hsmmc.2" ,"ick" , &mmchs3_ick,CK_3430ES2PLUS |CK_AM35XX |CK_36XX ), +CLK (NULL ,"mmchs3_ick" , &mmchs3_ick,CK_3430ES2PLUS |CK_AM35XX |CK_36XX ),CLK (NULL ,"icr_ick" , &icr_ick,CK_34XX |CK_36XX ),CLK ("omap-aes" ,"ick" , &aes2_ick,CK_34XX |CK_36XX ),CLK ("omap-sham" ,"ick" , &sha12_ick,CK_34XX |CK_36XX ),CLK (NULL ,"des2_ick" , &des2_ick,CK_34XX |CK_36XX ),CLK ("omap_hsmmc.1" ,"ick" , &mmchs2_ick,CK_3XXX ),CLK ("omap_hsmmc.0" ,"ick" , &mmchs1_ick,CK_3XXX ), +CLK (NULL ,"mmchs2_ick" , &mmchs2_ick,CK_3XXX ), +CLK (NULL ,"mmchs1_ick" , &mmchs1_ick,CK_3XXX ),CLK (NULL ,"mspro_ick" , &mspro_ick,CK_34XX |CK_36XX ),CLK ("omap_hdq.0" ,"ick" , &hdq_ick,CK_3XXX ), +CLK (NULL ,"hdq_ick" , &hdq_ick,CK_3XXX ),CLK ("omap2_mcspi.4" ,"ick" , &mcspi4_ick,CK_3XXX ),CLK ("omap2_mcspi.3" ,"ick" , &mcspi3_ick,CK_3XXX ),CLK ("omap2_mcspi.2" ,"ick" , &mcspi2_ick,CK_3XXX ),CLK ("omap2_mcspi.1" ,"ick" , &mcspi1_ick,CK_3XXX ), +CLK (NULL ,"mcspi4_ick" , &mcspi4_ick,CK_3XXX ), +CLK (NULL ,"mcspi3_ick" , &mcspi3_ick,CK_3XXX ), +CLK (NULL ,"mcspi2_ick" , &mcspi2_ick,CK_3XXX ), +CLK (NULL ,"mcspi1_ick" , &mcspi1_ick,CK_3XXX ),CLK ("omap_i2c.3" ,"ick" , &i2c3_ick,CK_3XXX ),CLK ("omap_i2c.2" ,"ick" , &i2c2_ick,CK_3XXX ),CLK ("omap_i2c.1" ,"ick" , &i2c1_ick,CK_3XXX ), +CLK (NULL ,"i2c3_ick" , &i2c3_ick,CK_3XXX ), +CLK (NULL ,"i2c2_ick" , &i2c2_ick,CK_3XXX ), +CLK (NULL ,"i2c1_ick" , &i2c1_ick,CK_3XXX ),CLK (NULL ,"uart2_ick" , &uart2_ick,CK_3XXX ),CLK (NULL ,"uart1_ick" , &uart1_ick,CK_3XXX ),CLK (NULL ,"gpt11_ick" , &gpt11_ick,CK_3XXX ),CLK (NULL ,"gpt10_ick" , &gpt10_ick,CK_3XXX ),CLK ("omap-mcbsp.5" ,"ick" , &mcbsp5_ick,CK_3XXX ),CLK ("omap-mcbsp.1" ,"ick" , &mcbsp1_ick,CK_3XXX ), +CLK (NULL ,"mcbsp5_ick" , &mcbsp5_ick,CK_3XXX ), +CLK (NULL ,"mcbsp1_ick" , &mcbsp1_ick,CK_3XXX ),CLK (NULL ,"fac_ick" , &fac_ick,CK_3430ES1 ),CLK (NULL ,"mailboxes_ick" , &mailboxes_ick,CK_34XX |CK_36XX ), CLK(NULL, "omapctrl_ick", &omapctrl_ick, CK_3XXX),
@@ -3383,7 +3400,9 @@ static struct omap_clk omap3xxx_clks[] = {CLK (NULL ,"dss_96m_fck" , &dss_96m_fck,CK_3XXX ),CLK (NULL ,"dss2_alwon_fck" , &dss2_alwon_fck,CK_3XXX ),CLK ("omapdss_dss" ,"ick" , &dss_ick_3430es1,CK_3430ES1 ), +CLK (NULL ,"dss_ick" , &dss_ick_3430es1,CK_3430ES1 ),CLK ("omapdss_dss" ,"ick" , &dss_ick_3430es2,CK_3430ES2PLUS |CK_AM35XX |CK_36XX ), +CLK (NULL ,"dss_ick" , &dss_ick_3430es2,CK_3430ES2PLUS |CK_AM35XX |CK_36XX ),CLK (NULL ,"cam_mclk" , &cam_mclk,CK_34XX |CK_36XX ),CLK (NULL ,"cam_ick" , &cam_ick,CK_34XX |CK_36XX ), CLK(NULL, "csi2_96m_fck", &csi2_96m_fck, CK_34XX | CK_36XX),
@@ -3408,6 +3427,7 @@ static struct omap_clk omap3xxx_clks[] = {CLK (NULL ,"wkup_l4_ick" , &wkup_l4_ick,CK_34XX |CK_36XX ),CLK (NULL ,"usim_ick" , &usim_ick,CK_3430ES2PLUS |CK_36XX ),CLK ("omap_wdt" ,"ick" , &wdt2_ick,CK_3XXX ), +CLK (NULL ,"wdt2_ick" , &wdt2_ick,CK_3XXX ),CLK (NULL ,"wdt1_ick" , &wdt1_ick,CK_3XXX ),CLK (NULL ,"gpio1_ick" , &gpio1_ick,CK_3XXX ), CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_3XXX),
@@ -3456,6 +3476,9 @@ static struct omap_clk omap3xxx_clks[] = {CLK ("omap-mcbsp.2" ,"ick" , &mcbsp2_ick,CK_3XXX ),CLK ("omap-mcbsp.3" ,"ick" , &mcbsp3_ick,CK_3XXX ),CLK ("omap-mcbsp.4" ,"ick" , &mcbsp4_ick,CK_3XXX ), +CLK (NULL ,"mcbsp4_ick" , &mcbsp2_ick,CK_3XXX ), +CLK (NULL ,"mcbsp3_ick" , &mcbsp3_ick,CK_3XXX ), +CLK (NULL ,"mcbsp2_ick" , &mcbsp4_ick,CK_3XXX ),CLK (NULL ,"mcbsp2_fck" , &mcbsp2_fck,CK_3XXX ),CLK (NULL ,"mcbsp3_fck" , &mcbsp3_fck,CK_3XXX ), CLK(NULL, "mcbsp4_fck", &mcbsp4_fck, CK_3XXX),
@@ -3479,6 +3502,7 @@ static struct omap_clk omap3xxx_clks[] = {CLK ("vpfe-capture" ,"master" , &vpfe_ick,CK_AM35XX ),CLK ("vpfe-capture" ,"slave" , &vpfe_fck,CK_AM35XX ),CLK ("musb-am35x" ,"ick" , &hsotgusb_ick_am35xx,CK_AM35XX ), +CLK (NULL ,"hsotgusb_ick" , &hsotgusb_ick_am35xx,CK_AM35XX ),CLK ("musb-am35x" ,"fck" , &hsotgusb_fck_am35xx,CK_AM35XX ),CLK (NULL ,"hecc_ck" , &hecc_ck,CK_AM35XX ), CLK(NULL, "uart4_ick", &uart4_ick_am35xx, CK_AM35XX),
arch/arm/mach-omap2/clock44xx_data.c +17 -0
@@ -3223,6 +3223,7 @@ static struct omap_clk omap44xx_clks[] = {CLK (NULL ,"dss_tv_clk" , &dss_tv_clk,CK_443X ),CLK (NULL ,"dss_48mhz_clk" , &dss_48mhz_clk,CK_443X ),CLK (NULL ,"dss_dss_clk" , &dss_dss_clk,CK_443X ), +CLK (NULL ,"dss_fck" , &dss_fck,CK_443X ),CLK ("omapdss_dss" ,"ick" , &dss_fck,CK_443X ),CLK (NULL ,"efuse_ctrl_cust_fck" , &efuse_ctrl_cust_fck,CK_443X ), CLK(NULL, "emif1_fck", &emif1_fck, CK_443X),
@@ -3279,6 +3280,7 @@ static struct omap_clk omap44xx_clks[] = {CLK (NULL ,"ocp2scp_usb_phy_phy_48m" , &ocp2scp_usb_phy_phy_48m,CK_443X ),CLK (NULL ,"ocp2scp_usb_phy_ick" , &ocp2scp_usb_phy_ick,CK_443X ),CLK (NULL ,"ocp_wp_noc_ick" , &ocp_wp_noc_ick,CK_443X ), +CLK (NULL ,"rng_ick" , &rng_ick,CK_443X ),CLK ("omap_rng" ,"ick" , &rng_ick,CK_443X ),CLK (NULL ,"sha2md5_fck" , &sha2md5_fck,CK_443X ), CLK(NULL, "sl2if_ick", &sl2if_ick, CK_443X),
@@ -3295,20 +3297,32 @@ static struct omap_clk omap44xx_clks[] = {CLK (NULL ,"smartreflex_iva_fck" , &smartreflex_iva_fck,CK_443X ),CLK (NULL ,"smartreflex_mpu_fck" , &smartreflex_mpu_fck,CK_443X ),CLK (NULL ,"gpt1_fck" , &timer1_fck,CK_443X ), +CLK (NULL ,"timer1_fck" , &timer1_fck,CK_443X ),CLK (NULL ,"gpt10_fck" , &timer10_fck,CK_443X ), +CLK (NULL ,"timer10_fck" , &timer10_fck,CK_443X ),CLK (NULL ,"gpt11_fck" , &timer11_fck,CK_443X ), +CLK (NULL ,"timer11_fck" , &timer11_fck,CK_443X ),CLK (NULL ,"gpt2_fck" , &timer2_fck,CK_443X ), +CLK (NULL ,"timer2_fck" , &timer2_fck,CK_443X ),CLK (NULL ,"gpt3_fck" , &timer3_fck,CK_443X ), +CLK (NULL ,"timer3_fck" , &timer3_fck,CK_443X ),CLK (NULL ,"gpt4_fck" , &timer4_fck,CK_443X ), +CLK (NULL ,"timer4_fck" , &timer4_fck,CK_443X ),CLK (NULL ,"gpt5_fck" , &timer5_fck,CK_443X ), +CLK (NULL ,"timer5_fck" , &timer5_fck,CK_443X ),CLK (NULL ,"gpt6_fck" , &timer6_fck,CK_443X ), +CLK (NULL ,"timer6_fck" , &timer6_fck,CK_443X ),CLK (NULL ,"gpt7_fck" , &timer7_fck,CK_443X ), +CLK (NULL ,"timer7_fck" , &timer7_fck,CK_443X ),CLK (NULL ,"gpt8_fck" , &timer8_fck,CK_443X ), +CLK (NULL ,"timer8_fck" , &timer8_fck,CK_443X ),CLK (NULL ,"gpt9_fck" , &timer9_fck,CK_443X ), +CLK (NULL ,"timer9_fck" , &timer9_fck,CK_443X ),CLK (NULL ,"uart1_fck" , &uart1_fck,CK_443X ),CLK (NULL ,"uart2_fck" , &uart2_fck,CK_443X ),CLK (NULL ,"uart3_fck" , &uart3_fck,CK_443X ),CLK (NULL ,"uart4_fck" , &uart4_fck,CK_443X ), +CLK (NULL ,"usb_host_fs_fck" , &usb_host_fs_fck,CK_443X ),CLK ("usbhs_omap" ,"fs_fck" , &usb_host_fs_fck,CK_443X ),CLK (NULL ,"utmi_p1_gfclk" , &utmi_p1_gfclk,CK_443X ), CLK(NULL, "usb_host_hs_utmi_p1_clk", &usb_host_hs_utmi_p1_clk, CK_443X),
@@ -3320,14 +3334,17 @@ static struct omap_clk omap44xx_clks[] = {CLK (NULL ,"usb_host_hs_hsic60m_p2_clk" , &usb_host_hs_hsic60m_p2_clk,CK_443X ),CLK (NULL ,"usb_host_hs_hsic480m_p2_clk" , &usb_host_hs_hsic480m_p2_clk,CK_443X ),CLK (NULL ,"usb_host_hs_func48mclk" , &usb_host_hs_func48mclk,CK_443X ), +CLK (NULL ,"usb_host_hs_fck" , &usb_host_hs_fck,CK_443X ),CLK ("usbhs_omap" ,"hs_fck" , &usb_host_hs_fck,CK_443X ),CLK (NULL ,"otg_60m_gfclk" , &otg_60m_gfclk,CK_443X ),CLK (NULL ,"usb_otg_hs_xclk" , &usb_otg_hs_xclk,CK_443X ), +CLK (NULL ,"usb_otg_hs_ick" , &usb_otg_hs_ick,CK_443X ),CLK ("musb-omap2430" ,"ick" , &usb_otg_hs_ick,CK_443X ),CLK (NULL ,"usb_phy_cm_clk32k" , &usb_phy_cm_clk32k,CK_443X ),CLK (NULL ,"usb_tll_hs_usb_ch2_clk" , &usb_tll_hs_usb_ch2_clk,CK_443X ),CLK (NULL ,"usb_tll_hs_usb_ch0_clk" , &usb_tll_hs_usb_ch0_clk,CK_443X ),CLK (NULL ,"usb_tll_hs_usb_ch1_clk" , &usb_tll_hs_usb_ch1_clk,CK_443X ), +CLK (NULL ,"usb_tll_hs_ick" , &usb_tll_hs_ick,CK_443X ),CLK ("usbhs_omap" ,"usbtll_ick" , &usb_tll_hs_ick,CK_443X ),CLK (NULL ,"usim_ck" , &usim_ck,CK_443X ), CLK(NULL, "usim_fclk", &usim_fclk, CK_443X),
arch/arm/mach-omap2/omap_hwmod.c +6 -6
@@ -602,8 +602,8 @@ static int _init_main_clk(struct omap_hwmod *oh)if (!oh->main_clk)return 0 ; - oh->_clk =omap_clk_get_by_name (oh->main_clk); -if (!oh->_clk) { + oh->_clk =clk_get (NULL , oh->main_clk); +if (IS_ERR_OR_NULL (oh->_clk)) {pr_warning ("omap_hwmod: %s: cannot clk_get main_clk %s\n" , oh->name, oh->main_clk);return -EINVAL ;
@@ -639,8 +639,8 @@ static int _init_interface_clks(struct omap_hwmod *oh)if (!os->clk)continue ; - c =omap_clk_get_by_name (os->clk); -if (!c) { + c =clk_get (NULL , os->clk); +if (IS_ERR_OR_NULL (c)) {pr_warning ("omap_hwmod: %s: cannot clk_get interface_clk %s\n" , oh->name, os->clk); ret = -EINVAL ;
@@ -667,8 +667,8 @@ static int _init_opt_clks(struct omap_hwmod *oh)int ret =0 ;for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i >0 ; i--, oc++) { - c =omap_clk_get_by_name (oc->clk); -if (!c) { + c =clk_get (NULL , oc->clk); +if (IS_ERR_OR_NULL (c)) {pr_warning ("omap_hwmod: %s: cannot clk_get opt_clk %s\n" , oh->name, oc->clk); ret = -EINVAL ;
arch/arm/plat-omap/omap_device.c +3 -3
@@ -266,10 +266,10 @@ static void _add_clkdev(struct omap_device *od, const char *clk_alias,return ; } - r =omap_clk_get_by_name (clk_name); -if (IS_ERR (r)) { + r =clk_get (NULL , clk_name); +if (IS_ERR_OR_NULL (r)) {dev_err (&od->pdev->dev, -"omap_clk_get_by_name for %s failed\n" , clk_name); +"clk_get for %s failed\n" , clk_name);return ; }
Signature · 1 line
1.7.1
PATCH 11/11 ARM: omap: clk: Remove all direct dereferencing of struct clk
In reply to Rajendra NayakWhile we move to Common Clk Framework (CCF), direct deferencing of struct clk wouldn't be possible anymore. Hence get rid of all such instances in the current clock code and use macros/helpers similar to the ones that are provided by CCF.
--- arch/arm/mach-omap2/clkt2xxx_apll.c | 2 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 4 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 18 +++--- arch/arm/mach-omap2/clkt_clksel.c | 84 ++++++++++++++++++-------- arch/arm/mach-omap2/clkt_dpll.c | 24 ++++--- arch/arm/mach-omap2/clock.c | 9 ++- arch/arm/mach-omap2/dpll3xxx.c | 45 ++++++++------ arch/arm/mach-omap2/omap_hwmod.c | 6 +- arch/arm/mach-omap2/pm.c | 2 +- arch/arm/plat-omap/include/plat/clock.h | 4 + 10 files changed, 125 insertions(+), 73 deletions(-)
arch/arm/mach-omap2/clkt2xxx_apll.c +1 -1
@@ -59,7 +59,7 @@ static int omap2_clk_apll_enable(struct clk *clk, u32 status_mask)omap2_cm_write_mod_reg (cval,PLL_MOD ,CM_CLKEN );omap2_cm_wait_idlest (cm_idlest_pll, status_mask, -OMAP24XX_CM_IDLEST_VAL , clk->name); +OMAP24XX_CM_IDLEST_VAL ,__clk_get_name (clk));/* * REVISIT: Should we return an error code if omap2_wait_clock_ready()
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c +2 -2
@@ -75,7 +75,7 @@ long omap2_round_to_table_rate(struct clk *clk, unsigned long rate)for (ptr = rate_table; ptr->mpu_speed; ptr++) {if (!(ptr->flags & cpu_mask))continue ; -if (ptr->xtal_speed != sclk->rate) +if (ptr->xtal_speed !=__clk_get_rate (sclk))continue ; highest_rate = ptr->mpu_speed;
@@ -99,7 +99,7 @@ int omap2_select_table_rate(struct clk *clk, unsigned long rate)if (!(prcm->flags & cpu_mask))continue ; -if (prcm->xtal_speed != sclk->rate) +if (prcm->xtal_speed !=__clk_get_rate (sclk))continue ;if (prcm->mpu_speed <= rate) {
arch/arm/mach-omap2/clkt34xx_dpll3m2.c +10 -8
@@ -56,6 +56,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)struct omap_sdrc_params *sdrc_cs0;struct omap_sdrc_params *sdrc_cs1;int ret; +unsigned long clkrate;if (!clk || !rate)return -EINVAL ;
@@ -64,11 +65,12 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)if (validrate != rate)return -EINVAL ; - sdrcrate = sdrc_ick_p->rate; -if (rate > clk->rate) - sdrcrate <<= ((rate / clk->rate) >>1 ); + sdrcrate =__clk_get_rate (sdrc_ick_p); + clkrate =__clk_get_rate (clk); +if (rate > clkrate) + sdrcrate <<= ((rate / clkrate) >>1 );else - sdrcrate >>= ((clk->rate / rate) >>1 ); + sdrcrate >>= ((clkrate / rate) >>1 ); ret =omap2_sdrc_get_params (sdrcrate, &sdrc_cs0, &sdrc_cs1);if (ret)
@@ -82,7 +84,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)/* * XXX This only needs to be done when the CPU frequency changes */ - _mpurate = arm_fck_p->rate /CYCLES_PER_MHZ ; + _mpurate =__clk_get_rate (arm_fck_p) /CYCLES_PER_MHZ ; c = (_mpurate <<SDRC_MPURATE_SCALE ) >>SDRC_MPURATE_BASE_SHIFT ; c +=1 ;/* for safety */ c *=SDRC_MPURATE_LOOPS ;
@@ -90,7 +92,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)if (c ==0 ) c =1 ; -pr_debug ("clock: changing CORE DPLL rate from %lu to %lu\n" , clk->rate, +pr_debug ("clock: changing CORE DPLL rate from %lu to %lu\n" , clkrate, validrate); pr_debug("clock: SDRC CS0 timing params used:" " RFR %08x CTRLA %08x CTRLB %08x MR %08x\n",
@@ -104,14 +106,14 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)if (sdrc_cs1)omap3_configure_core_dpll ( - new_div, unlock_dll, c, rate > clk->rate, + new_div, unlock_dll, c, rate > clkrate, sdrc_cs0->rfr_ctrl, sdrc_cs0->actim_ctrla, sdrc_cs0->actim_ctrlb, sdrc_cs0->mr, sdrc_cs1->rfr_ctrl, sdrc_cs1->actim_ctrla, sdrc_cs1->actim_ctrlb, sdrc_cs1->mr);else omap3_configure_core_dpll ( - new_div, unlock_dll, c, rate > clk->rate, + new_div, unlock_dll, c, rate > clkrate, sdrc_cs0->rfr_ctrl, sdrc_cs0->actim_ctrla, sdrc_cs0->actim_ctrlb, sdrc_cs0->mr,0 ,0 ,0 ,0 );
arch/arm/mach-omap2/clkt_clksel.c +58 -26
213 lines not on this page · raw message
arch/arm/mach-omap2/clkt_dpll.c +14 -10
@@ -87,7 +87,7 @@ static int _dpll_test_fint(struct clk *clk, u8 n) dd = clk->dpll_data;/* DPLL divider must result in a valid jitter correction val */ - fint = clk->parent->rate / n; + fint =__clk_get_rate (__clk_get_parent (clk)) / n;if (cpu_is_omap24xx ()) {/* Should not be called for OMAP2, so warn if it is called */
@@ -252,16 +252,16 @@ u32 omap2_get_dpll_rate(struct clk *clk)if (cpu_is_omap24xx ()) {if (v ==OMAP2XXX_EN_DPLL_LPBYPASS || v ==OMAP2XXX_EN_DPLL_FRBYPASS ) -return dd->clk_bypass->rate; +return __clk_get_rate (dd->clk_bypass); }else if (cpu_is_omap34xx ()) {if (v ==OMAP3XXX_EN_DPLL_LPBYPASS || v ==OMAP3XXX_EN_DPLL_FRBYPASS ) -return dd->clk_bypass->rate; +return __clk_get_rate (dd->clk_bypass); }else if (cpu_is_omap44xx ()) {if (v ==OMAP4XXX_EN_DPLL_LPBYPASS || v ==OMAP4XXX_EN_DPLL_FRBYPASS || v ==OMAP4XXX_EN_DPLL_MNBYPASS ) -return dd->clk_bypass->rate; +return __clk_get_rate (dd->clk_bypass); } v =__raw_readl (dd->mult_div1_reg);
@@ -270,7 +270,7 @@ u32 omap2_get_dpll_rate(struct clk *clk) dpll_div = v & dd->div1_mask; dpll_div >>=__ffs (dd->div1_mask); - dpll_clk = (long long )dd->clk_ref->rate * dpll_mult; + dpll_clk = (long long )__clk_get_rate (dd->clk_ref) * dpll_mult;do_div (dpll_clk, dpll_div +1 );return dpll_clk;
@@ -296,16 +296,20 @@ long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate)unsigned long scaled_rt_rp;unsigned long new_rate =0 ;struct dpll_data *dd; +unsigned long ref_rate; +const char *clk_name;if (!clk || !clk->dpll_data)return ~0 ; dd = clk->dpll_data; + ref_rate =__clk_get_rate (dd->clk_ref); + clk_name =__clk_get_name (clk);pr_debug ("clock: %s: starting DPLL round_rate, target rate %ld\n" , - clk->name, target_rate); + clk_name, target_rate); - scaled_rt_rp = target_rate / (dd->clk_ref->rate /DPLL_SCALE_FACTOR ); + scaled_rt_rp = target_rate / (ref_rate /DPLL_SCALE_FACTOR ); scaled_max_m = dd->max_multiplier *DPLL_SCALE_FACTOR ; dd->last_rounded_rate =0 ;
@@ -332,14 +336,14 @@ long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate)break ; r =_dpll_test_mult (&m, n, &new_rate, target_rate, - dd->clk_ref->rate); + ref_rate);/* m can't be set low enough for this n - try with a larger n */ if (r ==DPLL_MULT_UNDERFLOW )continue ;pr_debug ("clock: %s: m = %d: n = %d: new_rate = %ld\n" , - clk->name, m, n, new_rate); + clk_name, m, n, new_rate);if (target_rate == new_rate) { dd->last_rounded_m = m;
@@ -350,7 +354,7 @@ long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate) }if (target_rate != new_rate) { -pr_debug ("clock: %s: cannot round to rate %ld\n" , clk->name, +pr_debug ("clock: %s: cannot round to rate %ld\n" , clk_name, target_rate);return ~0 ; }
arch/arm/mach-omap2/clock.c +6 -3
@@ -76,7 +76,7 @@ static void _omap2_module_wait_ready(struct clk *clk) clk->ops->find_idlest (clk, &idlest_reg, &idlest_bit, &idlest_val);omap2_cm_wait_idlest (idlest_reg, (1 << idlest_bit), idlest_val, - clk->name); +__clk_get_name (clk)); }/* Public functions */
@@ -92,18 +92,21 @@ static void _omap2_module_wait_ready(struct clk *clk)void omap2_init_clk_clkdm (struct clk *clk) {struct clockdomain *clkdm; +const char *clk_name;if (!clk->clkdm_name)return ; + clk_name =__clk_get_name (clk); + clkdm =clkdm_lookup (clk->clkdm_name);if (clkdm) {pr_debug ("clock: associated clk %s to clkdm %s\n" , - clk->name, clk->clkdm_name); + clk_name, clk->clkdm_name); clk->clkdm = clkdm; }else {pr_debug ("clock: could not associate clk %s to " -"clkdm %s\n" , clk->name, clk->clkdm_name); +"clkdm %s\n" , clk_name, clk->clkdm_name); } }
arch/arm/mach-omap2/dpll3xxx.c +26 -19
152 lines not on this page · raw message
arch/arm/mach-omap2/omap_hwmod.c +3 -3
@@ -612,7 +612,7 @@ static int _init_main_clk(struct omap_hwmod *oh)if (!oh->_clk->clkdm)pr_warning ("omap_hwmod: %s: missing clockdomain for %s.\n" , - oh->main_clk, oh->_clk->name); + oh->name, oh->main_clk);return ret; }
@@ -753,7 +753,7 @@ static void _enable_optional_clocks(struct omap_hwmod *oh)for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i >0 ; i--, oc++)if (oc->_clk) {pr_debug ("omap_hwmod: enable %s:%s\n" , oc->role, - oc->_clk->name); +__clk_get_name (oc->_clk));clk_enable (oc->_clk); } }
@@ -768,7 +768,7 @@ static void _disable_optional_clocks(struct omap_hwmod *oh)for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i >0 ; i--, oc++)if (oc->_clk) {pr_debug ("omap_hwmod: disable %s:%s\n" , oc->role, - oc->_clk->name); +__clk_get_name (oc->_clk));clk_disable (oc->_clk); } }
arch/arm/mach-omap2/pm.c +1 -1
@@ -188,7 +188,7 @@ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, goto exit; } - freq = clk->rate; + freq =clk_get_rate (clk);clk_put (clk);rcu_read_lock ();
arch/arm/plat-omap/include/plat/clock.h +4 -0
@@ -19,6 +19,10 @@ struct module;struct clk ;struct clockdomain ; +#define __clk_get_name (clk) clk->name +#define __clk_get_parent (clk) clk->parent +#define __clk_get_rate (clk) clk->rate +/** * struct clkops - some clock function pointers * @enable: fn ptr that enables the current clock in hardware
Signature · 1 line
1.7.1
cover Prepare for OMAP2+ movement to Common Clk
In reply to Rajendra NayakHi Rajendra,
Quoted 9 lines · On Friday 22 June 2012 19:17:59 Rajendra Nayak wrote:
Hi,
This is a preparatory series for the OMAP Common Clk conversion. They mostly add clk_prepare/clk_unprepare in OMAP drivers and platform code. Also gets rid of
omap_clk_get_by_name()and usesclk_get(), and removes all direct 'struct clk' dereferrencing and uses helpers similar to what is provided by Common Clk.
I think you've missed drivers/media/video/omap3isp/isp.c. Should I send a patch for that ? Do these changes depend on anything not yet in mainline that I should apply to my tree for testing ?
Quoted 66 lines
Patches are boot tested on OMAP2430sdp, 3630 Beagle-Xm and 4460 Panda.
Some of these patches were earlier posted as part of OMAP2+ Common Clk conversion series [1] which is now split into a preparatory series and actual CCF conversion series.
Patches from this series can be found here
git://github.com/rrnayak/linux.gitprepare-common-clk-3.5-rc3regards,
Rajendra[1] http://www.mail-archive.com/[email protected]/msg70299.html
Rajendra Nayak (11):
ARM: omap: clk: addclk_prepareandclk_unprepare
mmc: omap: addclk_prepareandclk_unprepare
hwrng: omap: addclk_prepareandclk_unprepare
mfd: omap-usb: addclk_prepareandclk_unprepare
OMAPDSS: addclk_prepareandclk_unpreparegpio/omap: addclk_prepareandclk_unprepare
w1:omap_hdq: addclk_prepareandclk_unprepare
crypto: omap: addclk_prepareandclk_unprepare
iommu: omap: addclk_prepareandclk_unprepare
ARM: omap: hwmod: get rid of allomap_clk_get_by_nameusage
ARM: omap: clk: Remove all direct dereferencing of struct clkarch/arm/mach-omap2/board-apollon.c | 4 +- arch/arm/mach-omap2/board-h4.c | 6 +- arch/arm/mach-omap2/board-omap4panda.c | 2 +- arch/arm/mach-omap2/clkt2xxx_apll.c | 2 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 4 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 18 +++--- arch/arm/mach-omap2/clkt_clksel.c | 84 ++++++++++++++++------- arch/arm/mach-omap2/clkt_dpll.c | 24 ++++--- arch/arm/mach-omap2/clock.c | 9 ++- arch/arm/mach-omap2/clock2420_data.c | 17 +++++ arch/arm/mach-omap2/clock2430_data.c | 21 +++++++ arch/arm/mach-omap2/clock3xxx.c | 8 +- arch/arm/mach-omap2/clock3xxx_data.c | 24 +++++++ arch/arm/mach-omap2/clock44xx_data.c | 17 +++++ arch/arm/mach-omap2/display.c | 4 +- arch/arm/mach-omap2/dpll3xxx.c | 45 ++++++++------ arch/arm/mach-omap2/gpmc.c | 2 +- arch/arm/mach-omap2/omap_hwmod.c | 21 ++++--- arch/arm/mach-omap2/omap_phy_internal.c | 3 + arch/arm/mach-omap2/pm.c | 2 +- arch/arm/mach-omap2/pm24xx.c | 2 + arch/arm/mach-omap2/usb-fs.c | 4 +- arch/arm/plat-omap/include/plat/clock.h | 4 + arch/arm/plat-omap/omap_device.c | 6 +- drivers/char/hw_random/omap-rng.c | 6 +- drivers/crypto/omap-aes.c | 2 + drivers/crypto/omap-sham.c | 2 + drivers/gpio/gpio-omap.c | 2 + drivers/iommu/omap-iommu.c | 2 + drivers/mfd/omap-usb-host.c | 20 ++++++ drivers/mmc/host/omap.c | 9 ++- drivers/mmc/host/omap_hsmmc.c | 6 +- drivers/video/omap2/dss/dsi.c | 5 +- drivers/video/omap2/dss/hdmi.c | 5 +- drivers/video/omap2/dss/venc.c | 5 +- drivers/w1/masters/omap_hdq.c | 8 +- 36 files changed, 292 insertions(+), 113 deletions(-)
Signature · 3 lines
Regards, Laurent Pinchart
Paul Walmsley
maintainercover Prepare for OMAP2+ movement to Common Clk
Hi Laurent
Quoted 3 lines · Laurent Pinchart
I think you've missed
drivers/media/video/omap3isp/isp.c. Should I send a patch for that ? Do these changes depend on anything not yet in mainline that I should apply to my tree for testing ?
What would be ideal is if omap3isp could be converted to runtime PM for its internal IP block control. Almost all of the other OMAP on-chip oC drivers have been converted. Please let us know if more information or assistance is needed with this.
- Paul
cover Prepare for OMAP2+ movement to Common Clk
Hi Paul,
Quoted 9 lines · On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
Quoted 3 lines · Laurent Pinchart
I think you've missed
drivers/media/video/omap3isp/isp.c. Should I send a patch for that ? Do these changes depend on anything not yet in mainline that I should apply to my tree for testing ?What would be ideal is if omap3isp could be converted to runtime PM for its internal IP block control. Almost all of the other OMAP on-chip oC drivers have been converted. Please let us know if more information or assistance is needed with this.
How does that integrate with the clock framework ?
Signature · 3 lines
Regards, Laurent Pinchart
cover Prepare for OMAP2+ movement to Common Clk
Quoted 7 lines · On Wednesday 27 June 2012 20:05:27 Laurent Pinchart wrote:
Quoted 6 lines · On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
Quoted 4 lines · Laurent Pinchart
I think you've missed
drivers/media/video/omap3isp/isp.c. Should I send a
patch for that ? Do these changes depend on anything not yet in mainline that I should apply to my tree for testing ?
Quoted 6 lines
Quoted 4 lines
What would be ideal is if omap3isp could be converted to runtime PM for its internal IP block control. Almost all of the other OMAP on-chip oC drivers have been converted. Please let us know if more information or assistance is needed with this.
How does that integrate with the clock framework ?
OK, I think I've found the information. I'll give this a try.
What is still not clear to me is how runtime PM and system PM interact. For instance the OMAP3 ISP driver disables its clocks in the system PM suspend handler, and restarts them in the system PM resume handler. How do I port that to runtime PM, can I just call pm_runtime_put() and pm_runtime_get_sync() in the system PM handlers ?
Signature · 3 lines
Regards, Laurent Pinchart
cover Prepare for OMAP2+ movement to Common Clk
Quoted 10 lines · On Wednesday 27 June 2012 20:45:00 Laurent Pinchart wrote:
Quoted 9 lines · On Wednesday 27 June 2012 20:05:27 Laurent Pinchart wrote:
Quoted 8 lines · On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
Quoted 6 lines · Laurent Pinchart
I think you've missed
drivers/media/video/omap3isp/isp.c. Should I send
a
patch for that ? Do these changes depend on anything not yet in mainline
that I should apply to my tree for testing ?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
What would be ideal is if omap3isp could be converted to runtime PM for its internal IP block control. Almost all of the other OMAP on-chip oC drivers have been converted. Please let us know if more information or assistance is needed with this.
How does that integrate with the clock framework ?
OK, I think I've found the information. I'll give this a try.
Not much luck, pm_runtime_get_sync() doesn't seem to enable the ISP clocks.
I'm not familiar with runtime PM internals, what's the call stack from pm_runtime_get_sync() to the arch code that's supposed to enable clocks ?
Quoted 5 lines
What is still not clear to me is how runtime PM and system PM interact. For instance the OMAP3 ISP driver disables its clocks in the system PM suspend handler, and restarts them in the system PM resume handler. How do I port that to runtime PM, can I just call
pm_runtime_put()andpm_runtime_get_sync()in the system PM handlers ?
Signature · 3 lines
Regards, Laurent Pinchart
Paul Walmsley
maintainercover Prepare for OMAP2+ movement to Common Clk
In reply to Laurent Pinchart+ Kevin
Quoted 1 line · Laurent Pinchart
OK, I think I've found the information. I'll give this a try.
That sounds great.
Quoted 5 lines
What is still not clear to me is how runtime PM and system PM interact. For instance the OMAP3 ISP driver disables its clocks in the system PM suspend handler, and restarts them in the system PM resume handler. How do I port that to runtime PM, can I just call
pm_runtime_put()andpm_runtime_get_sync()in the system PM handlers ?
I've lost track of what the official guidance on this is. But we have plenty of drivers that do this. A few examples are drivers/mmc/host/omap_hsmmc.c, drivers/spi/spi-omap2-mcspi.c, and the DSS drivers.
IMHO, if possible, for the driver's system suspend call, the best thing to do is to check to see if the driver is currently doing something. If it is, then ask it to stop. Then wait until it does. When it stops, that other part of the driver is ideally what should do the pm_runtime_put*().
It's been a long time since I've looked, but I'd be surprised if we had many drivers that operated like that...
- Paul
cover Prepare for OMAP2+ movement to Common Clk
Hi Paul,
Quoted 6 lines · On Wednesday 27 June 2012 13:59:21 Paul Walmsley wrote:
+ Kevin
Quoted 1 line · Laurent Pinchart
OK, I think I've found the information. I'll give this a try.
That sounds great.
I'll repeat here what I've stated in my other mail, as Kevin is CC'ed.
I haven't had much luck, pm_runtime_get_sync() doesn't seem to enable the ISP clocks. I'd like to trace what happens (or rather doesn't happen), but I'm not familiar with runtime PM internals. What's the call stack from pm_runtime_get_sync() to the arch code that's supposed to enable clocks ?
Quoted 7 lines
Quoted 5 lines
What is still not clear to me is how runtime PM and system PM interact. For instance the OMAP3 ISP driver disables its clocks in the system PM suspend handler, and restarts them in the system PM resume handler. How do I port that to runtime PM, can I just call
pm_runtime_put()andpm_runtime_get_sync()in the system PM handlers ?I've lost track of what the official guidance on this is.
That's what has always bothered me with runtime PM, I've never been able to find clear official guidelines (possibly because there are none).
(Along with the fact that, for the OMAP3 ISP, I still don't see what benefits the runtime PM complexity will bring)
Quoted 6 lines
But we have plenty of drivers that do this. A few examples are
drivers/mmc/host/omap_hsmmc.c,drivers/spi/spi-omap2-mcspi.c, and the DSS drivers.IMHO, if possible, for the driver's system suspend call, the best thing to do is to check to see if the driver is currently doing something. If it is,
then ask it to stop. Then wait until it does. When it stops, that other part
Quoted 1 line
of the driver is ideally what should do the pm_runtime_put*().
I don't think I can do that. The omap3-isp driver implements a PM prepare operation that stops all device activity, and a PM suspend operation that turns off the clocks. The reason for that split is that the sensor (which has its own device, its own driver and its own PM operations) needs to be suspended after the ISP is stopped, but before the clocks are turned off.
My suspend handler thus needs to stop the clocks without performing any other operation. Calling pm_runtime_put() there is an option, I'll try it. It seems to be legal, as the hsmmc driver uses pm_runtime_put_sync() in its suspend handler. Is the _sync required there BTW ? Won't system suspend turn the clocks off anyway ? Or would there be a problem at resume time ?
Quoted 2 lines
It's been a long time since I've looked, but I'd be surprised if we had many drivers that operated like that...
Signature · 3 lines
Regards, Laurent Pinchart