* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-22 13:47 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:47 UTC (permalink / raw)
To: paul, mturquette; +Cc: linux-omap, linux-arm-kernel, Rajendra Nayak
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 here
git://github.com/rrnayak/linux.git prepare-common-clk-3.5-rc3
regards,
Rajendra
[1] http://www.mail-archive.com/linux-omap@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(-)
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-22 13:47 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:47 UTC (permalink / raw)
To: linux-arm-kernel
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 here
git://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(-)
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette; +Cc: linux-omap, linux-arm-kernel, Rajendra Nayak
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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index 502c31e..1d8c693 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -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);
}
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 876becf..a273af0 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -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);
}
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..f0ea558 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -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,
diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c
index 794d827..4c1591a 100644
--- a/arch/arm/mach-omap2/clock3xxx.c
+++ b/arch/arm/mach-omap2/clock3xxx.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5fb47a1..e5f8e48 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -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;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2286410..a33f89d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -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);
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
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);
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;
}
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..102e31a 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 2edeffc..8eee8bc 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/usb-fs.c b/arch/arm/mach-omap2/usb-fs.c
index 1481078..cff7d24 100644
--- a/arch/arm/mach-omap2/usb-fs.c
+++ b/arch/arm/mach-omap2/usb-fs.c
@@ -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);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c
index 502c31e..1d8c693 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -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);
}
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 876becf..a273af0 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -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);
}
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..f0ea558 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -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,
diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c
index 794d827..4c1591a 100644
--- a/arch/arm/mach-omap2/clock3xxx.c
+++ b/arch/arm/mach-omap2/clock3xxx.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5fb47a1..e5f8e48 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -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;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2286410..a33f89d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -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);
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
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);
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;
}
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..102e31a 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 2edeffc..8eee8bc 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/usb-fs.c b/arch/arm/mach-omap2/usb-fs.c
index 1481078..cff7d24 100644
--- a/arch/arm/mach-omap2/usb-fs.c
+++ b/arch/arm/mach-omap2/usb-fs.c
@@ -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);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Chris Ball,
Balaji T K, linux-mmc
In 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Balaji T K <balajitk@ti.com>
Cc: <linux-mmc@vger.kernel.org>
---
drivers/mmc/host/omap.c | 9 ++++++---
drivers/mmc/host/omap_hsmmc.c | 6 +++---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 552196c..331fa89 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -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);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9a7a60a..154baa5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -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);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: Balaji T K <balajitk@ti.com>
Cc: <linux-mmc@vger.kernel.org>
---
drivers/mmc/host/omap.c | 9 ++++++---
drivers/mmc/host/omap_hsmmc.c | 6 +++---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 552196c..331fa89 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -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);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9a7a60a..154baa5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -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);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 03/11] hwrng: omap: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Deepak Saxena,
Matt Mackall
In 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Deepak Saxena <dsaxena@plexity.net>
Cc: Matt Mackall <mpm@selenic.com>
---
drivers/char/hw_random/omap-rng.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 1412565..500604a 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -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);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 03/11] hwrng: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Deepak Saxena <dsaxena@plexity.net>
Cc: Matt Mackall <mpm@selenic.com>
---
drivers/char/hw_random/omap-rng.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 1412565..500604a 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -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);
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Samuel Ortiz
In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
and clk_unprepare() for the various usb host clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/mfd/omap-usb-host.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..dcffa5c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
and clk_unprepare() for the various usb host clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/mfd/omap-usb-host.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..dcffa5c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
(?)
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Tomi Valkeinen,
linux-fbdev
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the omapdss clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: <linux-fbdev@vger.kernel.org>
---
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(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ca8382d..81b474d 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -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)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8195c71..0b7ded3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -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)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 2b89739..62f395d 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -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)
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the omapdss clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: <linux-fbdev@vger.kernel.org>
---
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(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ca8382d..81b474d 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -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)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8195c71..0b7ded3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -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)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 2b89739..62f395d 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -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)
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Grant Likely
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
for omap gpio debounce clock.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/gpio/gpio-omap.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..6a73b01 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
for omap gpio debounce clock.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/gpio/gpio-omap.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4ed172..6a73b01 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 07/11] w1: omap_hdq: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Evgeniy Polyakov
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the hdq clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
---
drivers/w1/masters/omap_hdq.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 5ef385b..1892daf 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 07/11] w1: omap_hdq: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the hdq clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
---
drivers/w1/masters/omap_hdq.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 5ef385b..1892daf 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette; +Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Herbert Xu
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the omap crypto clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/crypto/omap-aes.c | 2 ++
drivers/crypto/omap-sham.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 63e57b5..70da28c 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -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);
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a3fd6fc..ac5e58d 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the omap crypto clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/crypto/omap-aes.c | 2 ++
drivers/crypto/omap-sham.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 63e57b5..70da28c 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -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);
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a3fd6fc..ac5e58d 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 09/11] iommu: omap: add clk_prepare and clk_unprepare
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette
Cc: linux-omap, linux-arm-kernel, Rajendra Nayak, Ohad Ben-Cohen
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the iommu clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/iommu/omap-iommu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index e70ee2b..fa72372 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 09/11] iommu: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the iommu clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/iommu/omap-iommu.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index e70ee2b..fa72372 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -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);
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 10/11] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette; +Cc: linux-omap, linux-arm-kernel, Rajendra Nayak
Moving 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index bace930..7fe2233 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
index 3b4d09a..21e69ab 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..4c826e0 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..51eea69 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2746bce..9e0b342 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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;
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..af822d5 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -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;
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 10/11] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
Moving 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index bace930..7fe2233 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
index 3b4d09a..21e69ab 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..4c826e0 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..51eea69 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -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),
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2746bce..9e0b342 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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;
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..af822d5 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -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;
}
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 11/11] ARM: omap: clk: Remove all direct dereferencing of struct clk
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-22 13:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: paul, mturquette; +Cc: linux-omap, linux-arm-kernel, Rajendra Nayak
While 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c b/arch/arm/mach-omap2/clkt2xxx_apll.c
index b19a1f7..c2d1521 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -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()
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 3d9d746..3a27426 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -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) {
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index d6e34dd..51601db 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -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);
diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c
index 04d551b..1c054ba 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -72,7 +72,9 @@ static const struct clksel *_get_clksel_by_parent(struct clk *clk,
if (!clks->parent) {
/* This indicates a data problem */
WARN(1, "clock: Could not find parent clock %s in clksel array "
- "of clock %s\n", src_clk->name, clk->name);
+ "of clock %s\n",
+ __clk_get_name(src_clk),
+ __clk_get_name(clk));
return NULL;
}
@@ -127,7 +129,8 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct clk *clk,
if (max_div == 0) {
/* This indicates an error in the clksel data */
WARN(1, "clock: Could not find divisor for clock %s parent %s"
- "\n", clk->name, src_clk->parent->name);
+ "\n", __clk_get_name(clk),
+ __clk_get_name(__clk_get_parent(src_clk)));
return 0;
}
@@ -176,8 +179,10 @@ static u32 _clksel_to_divisor(struct clk *clk, u32 field_val)
{
const struct clksel *clks;
const struct clksel_rate *clkr;
+ struct clk *parent;
- clks = _get_clksel_by_parent(clk, clk->parent);
+ parent = __clk_get_parent(clk);
+ clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return 0;
@@ -192,7 +197,9 @@ static u32 _clksel_to_divisor(struct clk *clk, u32 field_val)
if (!clkr->div) {
/* This indicates a data error */
WARN(1, "clock: Could not find fieldval %d for clock %s parent "
- "%s\n", field_val, clk->name, clk->parent->name);
+ "%s\n", field_val,
+ __clk_get_name(clk),
+ __clk_get_name(parent));
return 0;
}
@@ -213,11 +220,13 @@ static u32 _divisor_to_clksel(struct clk *clk, u32 div)
{
const struct clksel *clks;
const struct clksel_rate *clkr;
+ struct clk *parent;
/* should never happen */
WARN_ON(div == 0);
- clks = _get_clksel_by_parent(clk, clk->parent);
+ parent = __clk_get_parent(clk);
+ clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return ~0;
@@ -231,7 +240,9 @@ static u32 _divisor_to_clksel(struct clk *clk, u32 div)
if (!clkr->div) {
pr_err("clock: Could not find divisor %d for clock %s parent "
- "%s\n", div, clk->name, clk->parent->name);
+ "%s\n", div,
+ __clk_get_name(clk),
+ __clk_get_name(parent));
return ~0;
}
@@ -281,16 +292,23 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned long target_rate,
const struct clksel *clks;
const struct clksel_rate *clkr;
u32 last_div = 0;
+ struct clk *parent;
+ unsigned long parent_rate;
+ const char *clk_name;
+
+ parent = __clk_get_parent(clk);
+ parent_rate = __clk_get_rate(parent);
+ clk_name = __clk_get_name(clk);
if (!clk->clksel || !clk->clksel_mask)
return ~0;
pr_debug("clock: clksel_round_rate_div: %s target_rate %ld\n",
- clk->name, target_rate);
+ clk_name, target_rate);
*new_div = 1;
- clks = _get_clksel_by_parent(clk, clk->parent);
+ clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return ~0;
@@ -301,11 +319,11 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned long target_rate,
/* Sanity check */
if (clkr->div <= last_div)
pr_err("clock: clksel_rate table not sorted "
- "for clock %s", clk->name);
+ "for clock %s", clk_name);
last_div = clkr->div;
- test_rate = clk->parent->rate / clkr->div;
+ test_rate = parent_rate / clkr->div;
if (test_rate <= target_rate)
break; /* found it */
@@ -314,16 +332,16 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned long target_rate,
if (!clkr->div) {
pr_err("clock: Could not find divisor for target "
"rate %ld for clock %s parent %s\n", target_rate,
- clk->name, clk->parent->name);
+ clk_name, __clk_get_name(parent));
return ~0;
}
*new_div = clkr->div;
pr_debug("clock: new_div = %d, new_rate = %ld\n", *new_div,
- (clk->parent->rate / clkr->div));
+ (parent_rate / clkr->div));
- return clk->parent->rate / clkr->div;
+ return parent_rate / clkr->div;
}
/*
@@ -345,10 +363,15 @@ void omap2_init_clksel_parent(struct clk *clk)
const struct clksel *clks;
const struct clksel_rate *clkr;
u32 r, found = 0;
+ struct clk *parent;
+ const char *clk_name;
if (!clk->clksel || !clk->clksel_mask)
return;
+ parent = __clk_get_parent(clk);
+ clk_name = __clk_get_name(clk);
+
r = __raw_readl(clk->clksel_reg) & clk->clksel_mask;
r >>= __ffs(clk->clksel_mask);
@@ -358,12 +381,14 @@ void omap2_init_clksel_parent(struct clk *clk)
continue;
if (clkr->val == r) {
- if (clk->parent != clks->parent) {
+ if (parent != clks->parent) {
pr_debug("clock: inited %s parent "
"to %s (was %s)\n",
- clk->name, clks->parent->name,
- ((clk->parent) ?
- clk->parent->name : "NULL"));
+ clk_name,
+ __clk_get_name(clks->parent),
+ ((parent) ?
+ __clk_get_name(parent) :
+ "NULL"));
clk_reparent(clk, clks->parent);
};
found = 1;
@@ -373,7 +398,7 @@ void omap2_init_clksel_parent(struct clk *clk)
/* This indicates a data error */
WARN(!found, "clock: %s: init parent: could not find regval %0x\n",
- clk->name, r);
+ clk_name, r);
return;
}
@@ -391,14 +416,17 @@ unsigned long omap2_clksel_recalc(struct clk *clk)
{
unsigned long rate;
u32 div = 0;
+ struct clk *parent;
div = _read_divisor(clk);
if (div == 0)
- return clk->rate;
+ return __clk_get_rate(clk);
- rate = clk->parent->rate / div;
+ parent = __clk_get_parent(clk);
+ rate = __clk_get_rate(parent) / div;
- pr_debug("clock: %s: recalc'd rate is %ld (div %d)\n", clk->name,
+ pr_debug("clock: %s: recalc'd rate is %ld (div %d)\n",
+ __clk_get_name(clk),
rate, div);
return rate;
@@ -454,9 +482,11 @@ int omap2_clksel_set_rate(struct clk *clk, unsigned long rate)
_write_clksel_reg(clk, field_val);
- clk->rate = clk->parent->rate / new_div;
+ clk->rate = __clk_get_rate(__clk_get_parent(clk)) / new_div;
- pr_debug("clock: %s: set rate to %ld\n", clk->name, clk->rate);
+ pr_debug("clock: %s: set rate to %ld\n",
+ __clk_get_name(clk),
+ __clk_get_rate(clk));
return 0;
}
@@ -498,13 +528,15 @@ int omap2_clksel_set_parent(struct clk *clk, struct clk *new_parent)
clk_reparent(clk, new_parent);
/* CLKSEL clocks follow their parents' rates, divided by a divisor */
- clk->rate = new_parent->rate;
+ clk->rate = __clk_get_rate(new_parent);
if (parent_div > 0)
- clk->rate /= parent_div;
+ __clk_get_rate(clk) /= parent_div;
pr_debug("clock: %s: set parent to %s (new rate %ld)\n",
- clk->name, clk->parent->name, clk->rate);
+ __clk_get_name(clk),
+ __clk_get_name(__clk_get_parent(clk)),
+ __clk_get_rate(clk));
return 0;
}
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index cd7fd0f..6a8a012 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5c4e665..aa00f72 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -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);
}
}
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f0f10be..d390f40 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -63,8 +63,10 @@ static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
const struct dpll_data *dd;
int i = 0;
int ret = -EINVAL;
+ const char *clk_name;
dd = clk->dpll_data;
+ clk_name = __clk_get_name(clk);
state <<= __ffs(dd->idlest_mask);
@@ -76,10 +78,10 @@ static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
if (i == MAX_DPLL_WAIT_TRIES) {
printk(KERN_ERR "clock: %s failed transition to '%s'\n",
- clk->name, (state) ? "locked" : "bypassed");
+ clk_name, (state) ? "locked" : "bypassed");
} else {
pr_debug("clock: %s transition to '%s' in %d loops\n",
- clk->name, (state) ? "locked" : "bypassed", i);
+ clk_name, (state) ? "locked" : "bypassed", i);
ret = 0;
}
@@ -93,7 +95,7 @@ static u16 _omap3_dpll_compute_freqsel(struct clk *clk, u8 n)
unsigned long fint;
u16 f = 0;
- fint = clk->dpll_data->clk_ref->rate / n;
+ fint = __clk_get_rate(clk->dpll_data->clk_ref) / n;
pr_debug("clock: fint is %lu\n", fint);
@@ -138,7 +140,7 @@ static int _omap3_noncore_dpll_lock(struct clk *clk)
u8 ai;
int r;
- pr_debug("clock: locking DPLL %s\n", clk->name);
+ pr_debug("clock: locking DPLL %s\n", __clk_get_name(clk));
ai = omap3_dpll_autoidle_read(clk);
@@ -177,7 +179,7 @@ static int _omap3_noncore_dpll_bypass(struct clk *clk)
return -EINVAL;
pr_debug("clock: configuring DPLL %s for low-power bypass\n",
- clk->name);
+ __clk_get_name(clk));
ai = omap3_dpll_autoidle_read(clk);
@@ -207,7 +209,7 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
if (!(clk->dpll_data->modes & (1 << DPLL_LOW_POWER_STOP)))
return -EINVAL;
- pr_debug("clock: stopping DPLL %s\n", clk->name);
+ pr_debug("clock: stopping DPLL %s\n", __clk_get_name(clk));
ai = omap3_dpll_autoidle_read(clk);
@@ -235,7 +237,7 @@ static void _lookup_dco(struct clk *clk, u8 *dco, u16 m, u8 n)
{
unsigned long fint, clkinp; /* watch out for overflow */
- clkinp = clk->parent->rate;
+ clkinp = __clk_get_rate(__clk_get_parent(clk));
fint = (clkinp / n) * m;
if (fint < 1000000000)
@@ -261,7 +263,7 @@ static void _lookup_sddiv(struct clk *clk, u8 *sd_div, u16 m, u8 n)
unsigned long clkinp, sd; /* watch out for overflow */
int mod1, mod2;
- clkinp = clk->parent->rate;
+ clkinp = __clk_get_rate(__clk_get_parent(clk));
/*
* target sigma-delta to near 250MHz
@@ -370,16 +372,19 @@ int omap3_noncore_dpll_enable(struct clk *clk)
{
int r;
struct dpll_data *dd;
+ struct clk *parent;
dd = clk->dpll_data;
if (!dd)
return -EINVAL;
- if (clk->rate == dd->clk_bypass->rate) {
- WARN_ON(clk->parent != dd->clk_bypass);
+ parent = __clk_get_parent(clk);
+
+ if (__clk_get_rate(clk) == __clk_get_rate(dd->clk_bypass)) {
+ WARN_ON(parent != dd->clk_bypass);
r = _omap3_noncore_dpll_bypass(clk);
} else {
- WARN_ON(clk->parent != dd->clk_ref);
+ WARN_ON(parent != dd->clk_ref);
r = _omap3_noncore_dpll_lock(clk);
}
/*
@@ -446,7 +451,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
omap2_clk_enable(dd->clk_bypass);
omap2_clk_enable(dd->clk_ref);
- if (dd->clk_bypass->rate == rate &&
+ if (__clk_get_rate(dd->clk_bypass) == rate &&
(clk->dpll_data->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
pr_debug("clock: %s: set rate: entering bypass.\n", clk->name);
@@ -469,7 +474,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
}
pr_debug("clock: %s: set rate: locking rate to %lu.\n",
- clk->name, rate);
+ __clk_get_name(clk), rate);
ret = omap3_noncore_dpll_program(clk, dd->last_rounded_m,
dd->last_rounded_n, freqsel);
@@ -547,7 +552,7 @@ void omap3_dpll_allow_idle(struct clk *clk)
if (!dd->autoidle_reg) {
pr_debug("clock: DPLL %s: autoidle not supported\n",
- clk->name);
+ __clk_get_name(clk));
return;
}
@@ -581,7 +586,7 @@ void omap3_dpll_deny_idle(struct clk *clk)
if (!dd->autoidle_reg) {
pr_debug("clock: DPLL %s: autoidle not supported\n",
- clk->name);
+ __clk_get_name(clk));
return;
}
@@ -607,11 +612,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
unsigned long rate;
u32 v;
struct clk *pclk;
+ unsigned long parent_rate;
/* Walk up the parents of clk, looking for a DPLL */
- pclk = clk->parent;
+ pclk = __clk_get_parent(clk);
while (pclk && !pclk->dpll_data)
- pclk = pclk->parent;
+ pclk = __clk_get_parent(pclk);
/* clk does not have a DPLL as a parent? */
WARN_ON(!pclk);
@@ -620,11 +626,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
WARN_ON(!dd->enable_mask);
+ parent_rate = __clk_get_rate(__clk_get_parent(clk));
v = __raw_readl(dd->control_reg) & dd->enable_mask;
v >>= __ffs(dd->enable_mask);
if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd->flags & DPLL_J_TYPE))
- rate = clk->parent->rate;
+ rate = parent_rate;
else
- rate = clk->parent->rate * 2;
+ rate = parent_rate * 2;
return rate;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9e0b342..7891670 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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);
}
}
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..40012e3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -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();
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..ccb229a 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -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
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 11/11] ARM: omap: clk: Remove all direct dereferencing of struct clk
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:48 UTC (permalink / raw)
To: linux-arm-kernel
While 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.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c b/arch/arm/mach-omap2/clkt2xxx_apll.c
index b19a1f7..c2d1521 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -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()
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 3d9d746..3a27426 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -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) {
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index d6e34dd..51601db 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -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);
diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c
index 04d551b..1c054ba 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -72,7 +72,9 @@ static const struct clksel *_get_clksel_by_parent(struct clk *clk,
if (!clks->parent) {
/* This indicates a data problem */
WARN(1, "clock: Could not find parent clock %s in clksel array "
- "of clock %s\n", src_clk->name, clk->name);
+ "of clock %s\n",
+ __clk_get_name(src_clk),
+ __clk_get_name(clk));
return NULL;
}
@@ -127,7 +129,8 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct clk *clk,
if (max_div == 0) {
/* This indicates an error in the clksel data */
WARN(1, "clock: Could not find divisor for clock %s parent %s"
- "\n", clk->name, src_clk->parent->name);
+ "\n", __clk_get_name(clk),
+ __clk_get_name(__clk_get_parent(src_clk)));
return 0;
}
@@ -176,8 +179,10 @@ static u32 _clksel_to_divisor(struct clk *clk, u32 field_val)
{
const struct clksel *clks;
const struct clksel_rate *clkr;
+ struct clk *parent;
- clks = _get_clksel_by_parent(clk, clk->parent);
+ parent = __clk_get_parent(clk);
+ clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return 0;
@@ -192,7 +197,9 @@ static u32 _clksel_to_divisor(struct clk *clk, u32 field_val)
if (!clkr->div) {
/* This indicates a data error */
WARN(1, "clock: Could not find fieldval %d for clock %s parent "
- "%s\n", field_val, clk->name, clk->parent->name);
+ "%s\n", field_val,
+ __clk_get_name(clk),
+ __clk_get_name(parent));
return 0;
}
@@ -213,11 +220,13 @@ static u32 _divisor_to_clksel(struct clk *clk, u32 div)
{
const struct clksel *clks;
const struct clksel_rate *clkr;
+ struct clk *parent;
/* should never happen */
WARN_ON(div == 0);
- clks = _get_clksel_by_parent(clk, clk->parent);
+ parent = __clk_get_parent(clk);
+ clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return ~0;
@@ -231,7 +240,9 @@ static u32 _divisor_to_clksel(struct clk *clk, u32 div)
if (!clkr->div) {
pr_err("clock: Could not find divisor %d for clock %s parent "
- "%s\n", div, clk->name, clk->parent->name);
+ "%s\n", div,
+ __clk_get_name(clk),
+ __clk_get_name(parent));
return ~0;
}
@@ -281,16 +292,23 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned long target_rate,
const struct clksel *clks;
const struct clksel_rate *clkr;
u32 last_div = 0;
+ struct clk *parent;
+ unsigned long parent_rate;
+ const char *clk_name;
+
+ parent = __clk_get_parent(clk);
+ parent_rate = __clk_get_rate(parent);
+ clk_name = __clk_get_name(clk);
if (!clk->clksel || !clk->clksel_mask)
return ~0;
pr_debug("clock: clksel_round_rate_div: %s target_rate %ld\n",
- clk->name, target_rate);
+ clk_name, target_rate);
*new_div = 1;
- clks = _get_clksel_by_parent(clk, clk->parent);
+ clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return ~0;
@@ -301,11 +319,11 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned long target_rate,
/* Sanity check */
if (clkr->div <= last_div)
pr_err("clock: clksel_rate table not sorted "
- "for clock %s", clk->name);
+ "for clock %s", clk_name);
last_div = clkr->div;
- test_rate = clk->parent->rate / clkr->div;
+ test_rate = parent_rate / clkr->div;
if (test_rate <= target_rate)
break; /* found it */
@@ -314,16 +332,16 @@ u32 omap2_clksel_round_rate_div(struct clk *clk, unsigned long target_rate,
if (!clkr->div) {
pr_err("clock: Could not find divisor for target "
"rate %ld for clock %s parent %s\n", target_rate,
- clk->name, clk->parent->name);
+ clk_name, __clk_get_name(parent));
return ~0;
}
*new_div = clkr->div;
pr_debug("clock: new_div = %d, new_rate = %ld\n", *new_div,
- (clk->parent->rate / clkr->div));
+ (parent_rate / clkr->div));
- return clk->parent->rate / clkr->div;
+ return parent_rate / clkr->div;
}
/*
@@ -345,10 +363,15 @@ void omap2_init_clksel_parent(struct clk *clk)
const struct clksel *clks;
const struct clksel_rate *clkr;
u32 r, found = 0;
+ struct clk *parent;
+ const char *clk_name;
if (!clk->clksel || !clk->clksel_mask)
return;
+ parent = __clk_get_parent(clk);
+ clk_name = __clk_get_name(clk);
+
r = __raw_readl(clk->clksel_reg) & clk->clksel_mask;
r >>= __ffs(clk->clksel_mask);
@@ -358,12 +381,14 @@ void omap2_init_clksel_parent(struct clk *clk)
continue;
if (clkr->val == r) {
- if (clk->parent != clks->parent) {
+ if (parent != clks->parent) {
pr_debug("clock: inited %s parent "
"to %s (was %s)\n",
- clk->name, clks->parent->name,
- ((clk->parent) ?
- clk->parent->name : "NULL"));
+ clk_name,
+ __clk_get_name(clks->parent),
+ ((parent) ?
+ __clk_get_name(parent) :
+ "NULL"));
clk_reparent(clk, clks->parent);
};
found = 1;
@@ -373,7 +398,7 @@ void omap2_init_clksel_parent(struct clk *clk)
/* This indicates a data error */
WARN(!found, "clock: %s: init parent: could not find regval %0x\n",
- clk->name, r);
+ clk_name, r);
return;
}
@@ -391,14 +416,17 @@ unsigned long omap2_clksel_recalc(struct clk *clk)
{
unsigned long rate;
u32 div = 0;
+ struct clk *parent;
div = _read_divisor(clk);
if (div == 0)
- return clk->rate;
+ return __clk_get_rate(clk);
- rate = clk->parent->rate / div;
+ parent = __clk_get_parent(clk);
+ rate = __clk_get_rate(parent) / div;
- pr_debug("clock: %s: recalc'd rate is %ld (div %d)\n", clk->name,
+ pr_debug("clock: %s: recalc'd rate is %ld (div %d)\n",
+ __clk_get_name(clk),
rate, div);
return rate;
@@ -454,9 +482,11 @@ int omap2_clksel_set_rate(struct clk *clk, unsigned long rate)
_write_clksel_reg(clk, field_val);
- clk->rate = clk->parent->rate / new_div;
+ clk->rate = __clk_get_rate(__clk_get_parent(clk)) / new_div;
- pr_debug("clock: %s: set rate to %ld\n", clk->name, clk->rate);
+ pr_debug("clock: %s: set rate to %ld\n",
+ __clk_get_name(clk),
+ __clk_get_rate(clk));
return 0;
}
@@ -498,13 +528,15 @@ int omap2_clksel_set_parent(struct clk *clk, struct clk *new_parent)
clk_reparent(clk, new_parent);
/* CLKSEL clocks follow their parents' rates, divided by a divisor */
- clk->rate = new_parent->rate;
+ clk->rate = __clk_get_rate(new_parent);
if (parent_div > 0)
- clk->rate /= parent_div;
+ __clk_get_rate(clk) /= parent_div;
pr_debug("clock: %s: set parent to %s (new rate %ld)\n",
- clk->name, clk->parent->name, clk->rate);
+ __clk_get_name(clk),
+ __clk_get_name(__clk_get_parent(clk)),
+ __clk_get_rate(clk));
return 0;
}
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index cd7fd0f..6a8a012 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -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;
}
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5c4e665..aa00f72 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -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);
}
}
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f0f10be..d390f40 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -63,8 +63,10 @@ static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
const struct dpll_data *dd;
int i = 0;
int ret = -EINVAL;
+ const char *clk_name;
dd = clk->dpll_data;
+ clk_name = __clk_get_name(clk);
state <<= __ffs(dd->idlest_mask);
@@ -76,10 +78,10 @@ static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
if (i == MAX_DPLL_WAIT_TRIES) {
printk(KERN_ERR "clock: %s failed transition to '%s'\n",
- clk->name, (state) ? "locked" : "bypassed");
+ clk_name, (state) ? "locked" : "bypassed");
} else {
pr_debug("clock: %s transition to '%s' in %d loops\n",
- clk->name, (state) ? "locked" : "bypassed", i);
+ clk_name, (state) ? "locked" : "bypassed", i);
ret = 0;
}
@@ -93,7 +95,7 @@ static u16 _omap3_dpll_compute_freqsel(struct clk *clk, u8 n)
unsigned long fint;
u16 f = 0;
- fint = clk->dpll_data->clk_ref->rate / n;
+ fint = __clk_get_rate(clk->dpll_data->clk_ref) / n;
pr_debug("clock: fint is %lu\n", fint);
@@ -138,7 +140,7 @@ static int _omap3_noncore_dpll_lock(struct clk *clk)
u8 ai;
int r;
- pr_debug("clock: locking DPLL %s\n", clk->name);
+ pr_debug("clock: locking DPLL %s\n", __clk_get_name(clk));
ai = omap3_dpll_autoidle_read(clk);
@@ -177,7 +179,7 @@ static int _omap3_noncore_dpll_bypass(struct clk *clk)
return -EINVAL;
pr_debug("clock: configuring DPLL %s for low-power bypass\n",
- clk->name);
+ __clk_get_name(clk));
ai = omap3_dpll_autoidle_read(clk);
@@ -207,7 +209,7 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
if (!(clk->dpll_data->modes & (1 << DPLL_LOW_POWER_STOP)))
return -EINVAL;
- pr_debug("clock: stopping DPLL %s\n", clk->name);
+ pr_debug("clock: stopping DPLL %s\n", __clk_get_name(clk));
ai = omap3_dpll_autoidle_read(clk);
@@ -235,7 +237,7 @@ static void _lookup_dco(struct clk *clk, u8 *dco, u16 m, u8 n)
{
unsigned long fint, clkinp; /* watch out for overflow */
- clkinp = clk->parent->rate;
+ clkinp = __clk_get_rate(__clk_get_parent(clk));
fint = (clkinp / n) * m;
if (fint < 1000000000)
@@ -261,7 +263,7 @@ static void _lookup_sddiv(struct clk *clk, u8 *sd_div, u16 m, u8 n)
unsigned long clkinp, sd; /* watch out for overflow */
int mod1, mod2;
- clkinp = clk->parent->rate;
+ clkinp = __clk_get_rate(__clk_get_parent(clk));
/*
* target sigma-delta to near 250MHz
@@ -370,16 +372,19 @@ int omap3_noncore_dpll_enable(struct clk *clk)
{
int r;
struct dpll_data *dd;
+ struct clk *parent;
dd = clk->dpll_data;
if (!dd)
return -EINVAL;
- if (clk->rate == dd->clk_bypass->rate) {
- WARN_ON(clk->parent != dd->clk_bypass);
+ parent = __clk_get_parent(clk);
+
+ if (__clk_get_rate(clk) == __clk_get_rate(dd->clk_bypass)) {
+ WARN_ON(parent != dd->clk_bypass);
r = _omap3_noncore_dpll_bypass(clk);
} else {
- WARN_ON(clk->parent != dd->clk_ref);
+ WARN_ON(parent != dd->clk_ref);
r = _omap3_noncore_dpll_lock(clk);
}
/*
@@ -446,7 +451,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
omap2_clk_enable(dd->clk_bypass);
omap2_clk_enable(dd->clk_ref);
- if (dd->clk_bypass->rate == rate &&
+ if (__clk_get_rate(dd->clk_bypass) == rate &&
(clk->dpll_data->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
pr_debug("clock: %s: set rate: entering bypass.\n", clk->name);
@@ -469,7 +474,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
}
pr_debug("clock: %s: set rate: locking rate to %lu.\n",
- clk->name, rate);
+ __clk_get_name(clk), rate);
ret = omap3_noncore_dpll_program(clk, dd->last_rounded_m,
dd->last_rounded_n, freqsel);
@@ -547,7 +552,7 @@ void omap3_dpll_allow_idle(struct clk *clk)
if (!dd->autoidle_reg) {
pr_debug("clock: DPLL %s: autoidle not supported\n",
- clk->name);
+ __clk_get_name(clk));
return;
}
@@ -581,7 +586,7 @@ void omap3_dpll_deny_idle(struct clk *clk)
if (!dd->autoidle_reg) {
pr_debug("clock: DPLL %s: autoidle not supported\n",
- clk->name);
+ __clk_get_name(clk));
return;
}
@@ -607,11 +612,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
unsigned long rate;
u32 v;
struct clk *pclk;
+ unsigned long parent_rate;
/* Walk up the parents of clk, looking for a DPLL */
- pclk = clk->parent;
+ pclk = __clk_get_parent(clk);
while (pclk && !pclk->dpll_data)
- pclk = pclk->parent;
+ pclk = __clk_get_parent(pclk);
/* clk does not have a DPLL as a parent? */
WARN_ON(!pclk);
@@ -620,11 +626,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
WARN_ON(!dd->enable_mask);
+ parent_rate = __clk_get_rate(__clk_get_parent(clk));
v = __raw_readl(dd->control_reg) & dd->enable_mask;
v >>= __ffs(dd->enable_mask);
if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd->flags & DPLL_J_TYPE))
- rate = clk->parent->rate;
+ rate = parent_rate;
else
- rate = clk->parent->rate * 2;
+ rate = parent_rate * 2;
return rate;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9e0b342..7891670 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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);
}
}
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..40012e3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -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();
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..ccb229a 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -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
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-22 13:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-22 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
and clk_unprepare() for the omapdss clocks.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: <linux-fbdev@vger.kernel.org>
---
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(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ca8382d..81b474d 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -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)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8195c71..0b7ded3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -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)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 2b89739..62f395d 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -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)
--
1.7.1
^ permalink raw reply related [flat|nested] 119+ messages in thread
* Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 15:57 ` Pankaj Jangra
-1 siblings, 0 replies; 119+ messages in thread
From: Pankaj Jangra @ 2012-06-22 15:57 UTC (permalink / raw)
To: Rajendra Nayak
Cc: paul, mturquette, linux-omap, linux-arm-kernel, Grant Likely
HI,
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> for omap gpio debounce clock.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/gpio/gpio-omap.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Reviewed-by: Pankaj Jangra <jangra.pankaj9@gmail.com>
Regards,
Pankaj Jangra
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-22 15:57 ` Pankaj Jangra
0 siblings, 0 replies; 119+ messages in thread
From: Pankaj Jangra @ 2012-06-22 15:57 UTC (permalink / raw)
To: linux-arm-kernel
HI,
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> for omap gpio debounce clock.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> ?drivers/gpio/gpio-omap.c | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
Reviewed-by: Pankaj Jangra <jangra.pankaj9@gmail.com>
Regards,
Pankaj Jangra
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 17:42 ` Pankaj Jangra
-1 siblings, 0 replies; 119+ messages in thread
From: Pankaj Jangra @ 2012-06-22 17:42 UTC (permalink / raw)
To: Rajendra Nayak; +Cc: paul, mturquette, linux-omap, linux-arm-kernel
Hi,
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> 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.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> 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(-)
>
> }
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 5fb47a1..e5f8e48 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -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);
>
Just a doubt. Isn't it the same clocks you are preparing in omap_hwmod.c ?
> r = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
>
d> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
> 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);
>
> 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;
You should do clk_prepare() after os->_clk = c statement. Otherwise
you are operating on a uninitialized structure pointer.
> }
>
> @@ -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.
> oc->_clk = c;
> }
>
d
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare
@ 2012-06-22 17:42 ` Pankaj Jangra
0 siblings, 0 replies; 119+ messages in thread
From: Pankaj Jangra @ 2012-06-22 17:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> 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.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> ?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(-)
>
> ?}
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 5fb47a1..e5f8e48 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -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);
>
Just a doubt. Isn't it the same clocks you are preparing in omap_hwmod.c ?
> ? ? ? ?r = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
>
d> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
> 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);
>
> ? ? ? ?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;
You should do clk_prepare() after os->_clk = c statement. Otherwise
you are operating on a uninitialized structure pointer.
> ? ? ? ?}
>
> @@ -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.
> ? ? ? ? ? ? ? ?oc->_clk = c;
> ? ? ? ?}
>
d
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 18:23 ` S, Venkatraman
-1 siblings, 0 replies; 119+ messages in thread
From: S, Venkatraman @ 2012-06-22 18:23 UTC (permalink / raw)
To: Rajendra Nayak
Cc: paul, mturquette, linux-omap, linux-arm-kernel, Chris Ball,
Balaji T K, linux-mmc
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> In 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.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Balaji T K <balajitk@ti.com>
> Cc: <linux-mmc@vger.kernel.org>
Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 18:23 ` S, Venkatraman
0 siblings, 0 replies; 119+ messages in thread
From: S, Venkatraman @ 2012-06-22 18:23 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> In 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.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Balaji T K <balajitk@ti.com>
> Cc: <linux-mmc@vger.kernel.org>
Rajendra,
Can this be applied independently, or does this patch have a
dependency on other patches in the series ?
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-22 18:23 ` S, Venkatraman
@ 2012-06-22 18:34 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 18:34 UTC (permalink / raw)
To: S, Venkatraman
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel,
Chris Ball, Balaji T K, linux-mmc
On Fri, 22 Jun 2012, S, Venkatraman wrote:
> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> > In 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.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: Balaji T K <balajitk@ti.com>
> > Cc: <linux-mmc@vger.kernel.org>
>
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 18:34 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 18:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 22 Jun 2012, S, Venkatraman wrote:
> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> > In 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.
> >
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: Balaji T K <balajitk@ti.com>
> > Cc: <linux-mmc@vger.kernel.org>
>
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 07/11] w1: omap_hdq: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 18:35 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 18:35 UTC (permalink / raw)
To: Rajendra Nayak; +Cc: mturquette, linux-omap, linux-arm-kernel, Evgeniy Polyakov
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the hdq clocks.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Evgeniy Polyakov <zbr@ioremap.net>
This one should not be needed soon:
http://marc.info/?l=linux-omap&m=134037453807275&w=2
- Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 07/11] w1: omap_hdq: add clk_prepare and clk_unprepare
@ 2012-06-22 18:35 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 18:35 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the hdq clocks.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Evgeniy Polyakov <zbr@ioremap.net>
This one should not be needed soon:
http://marc.info/?l=linux-omap&m=134037453807275&w=2
- Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 18:58 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 18:58 UTC (permalink / raw)
To: Rajendra Nayak; +Cc: mturquette, linux-omap, linux-arm-kernel, Herbert Xu
Hi
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the omap crypto clocks.
These drivers should be converted to use runtime PM instead, since that
needs to be done anyway.
- Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
@ 2012-06-22 18:58 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 18:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_unprepare() for the omap crypto clocks.
These drivers should be converted to use runtime PM instead, since that
needs to be done anyway.
- Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 19:04 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 19:04 UTC (permalink / raw)
To: Rajendra Nayak
Cc: mturquette, linux-omap, linux-arm-kernel, Samuel Ortiz, keshava_mgowda
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
> and clk_unprepare() for the various usb host clocks.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
@ 2012-06-22 19:04 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 19:04 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
> and clk_unprepare() for the various usb host clocks.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
@ 2012-06-22 19:17 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 19:17 UTC (permalink / raw)
To: Rajendra Nayak
Cc: mturquette, linux-omap, linux-arm-kernel, Grant Likely, Pankaj Jangra
Hi
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> for omap gpio debounce clock.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/gpio/gpio-omap.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c4ed172..6a73b01 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-22 19:17 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-22 19:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Fri, 22 Jun 2012, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> for omap gpio debounce clock.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/gpio/gpio-omap.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c4ed172..6a73b01 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-22 18:34 ` Paul Walmsley
@ 2012-06-25 5:25 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:25 UTC (permalink / raw)
To: Paul Walmsley
Cc: S, Venkatraman, mturquette, linux-omap, linux-arm-kernel,
Chris Ball, Balaji T K, linux-mmc
On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote:
> On Fri, 22 Jun 2012, S, Venkatraman wrote:
>
>> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>>> In 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.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> Cc: Chris Ball<cjb@laptop.org>
>>> Cc: Balaji T K<balajitk@ti.com>
>>> Cc:<linux-mmc@vger.kernel.org>
>>
>> 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.
>
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-25 5:25 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:25 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote:
> On Fri, 22 Jun 2012, S, Venkatraman wrote:
>
>> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>>> In 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.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> Cc: Chris Ball<cjb@laptop.org>
>>> Cc: Balaji T K<balajitk@ti.com>
>>> Cc:<linux-mmc@vger.kernel.org>
>>
>> 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.
>
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 07/11] w1: omap_hdq: add clk_prepare and clk_unprepare
2012-06-22 18:35 ` Paul Walmsley
@ 2012-06-25 5:25 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:25 UTC (permalink / raw)
To: Paul Walmsley; +Cc: mturquette, linux-omap, linux-arm-kernel, Evgeniy Polyakov
On Saturday 23 June 2012 12:05 AM, Paul Walmsley wrote:
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_unprepare() for the hdq clocks.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Cc: Evgeniy Polyakov<zbr@ioremap.net>
>
> This one should not be needed soon:
>
> http://marc.info/?l=linux-omap&m=134037453807275&w=2
Ok, thanks, will drop this one then.
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 07/11] w1: omap_hdq: add clk_prepare and clk_unprepare
@ 2012-06-25 5:25 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:25 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 23 June 2012 12:05 AM, Paul Walmsley wrote:
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_unprepare() for the hdq clocks.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Cc: Evgeniy Polyakov<zbr@ioremap.net>
>
> This one should not be needed soon:
>
> http://marc.info/?l=linux-omap&m=134037453807275&w=2
Ok, thanks, will drop this one then.
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
2012-06-22 18:58 ` Paul Walmsley
@ 2012-06-25 5:29 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:29 UTC (permalink / raw)
To: Paul Walmsley; +Cc: mturquette, linux-omap, linux-arm-kernel, Herbert Xu
On Saturday 23 June 2012 12:28 AM, Paul Walmsley wrote:
> Hi
>
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_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?
>
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
@ 2012-06-25 5:29 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:29 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 23 June 2012 12:28 AM, Paul Walmsley wrote:
> Hi
>
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_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?
>
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-22 19:17 ` Paul Walmsley
@ 2012-06-25 5:30 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:30 UTC (permalink / raw)
To: Paul Walmsley
Cc: mturquette, linux-omap, linux-arm-kernel, Grant Likely,
Pankaj Jangra, Santosh Shilimkar, Tarun Kanti DebBarma
On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
> Hi
>
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> for omap gpio debounce clock.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Cc: Grant Likely<grant.likely@secretlab.ca>
>> ---
>> drivers/gpio/gpio-omap.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c4ed172..6a73b01 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -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()?
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.
>
> Also, it looks to me that the bank->dbck init should be in
> omap_gpio_chip_init(), not gpio_debounce()?
Tarun, can you comment on why the dbck init is in gpio_debounce
and not in omap_gpio_chip_init()?
>
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-25 5:30 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:30 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
> Hi
>
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> for omap gpio debounce clock.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Cc: Grant Likely<grant.likely@secretlab.ca>
>> ---
>> drivers/gpio/gpio-omap.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c4ed172..6a73b01 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -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()?
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.
>
> Also, it looks to me that the bank->dbck init should be in
> omap_gpio_chip_init(), not gpio_debounce()?
Tarun, can you comment on why the dbck init is in gpio_debounce
and not in omap_gpio_chip_init()?
>
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-22 18:23 ` S, Venkatraman
@ 2012-06-25 5:32 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:32 UTC (permalink / raw)
To: S, Venkatraman
Cc: paul, mturquette, linux-omap, linux-arm-kernel, Chris Ball,
Balaji T K, linux-mmc
On Friday 22 June 2012 11:53 PM, S, Venkatraman wrote:
> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>> In 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.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Cc: Chris Ball<cjb@laptop.org>
>> Cc: Balaji T K<balajitk@ti.com>
>> Cc:<linux-mmc@vger.kernel.org>
>
> 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.
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-25 5:32 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:32 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 22 June 2012 11:53 PM, S, Venkatraman wrote:
> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>> In 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.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Cc: Chris Ball<cjb@laptop.org>
>> Cc: Balaji T K<balajitk@ti.com>
>> Cc:<linux-mmc@vger.kernel.org>
>
> 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.
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare
2012-06-22 17:42 ` Pankaj Jangra
@ 2012-06-25 5:36 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:36 UTC (permalink / raw)
To: Pankaj Jangra; +Cc: paul, mturquette, linux-omap, linux-arm-kernel
On Friday 22 June 2012 11:12 PM, Pankaj Jangra wrote:
>> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
>> > index 5fb47a1..e5f8e48 100644
>> > --- a/arch/arm/mach-omap2/display.c
>> > +++ b/arch/arm/mach-omap2/display.c
>> > @@ -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);
>> >
> 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.
>
>> > r = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
>> >
> d> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
>> > 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);
>> >
>> > 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;
> You should do clk_prepare() after os->_clk = c statement. Otherwise
> you are operating on a uninitialized structure pointer.
yes, that was really stupid of me :(. Thanks for catching this.
>> > }
>> >
>> > @@ -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.
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare
@ 2012-06-25 5:36 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 5:36 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 22 June 2012 11:12 PM, Pankaj Jangra wrote:
>> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
>> > index 5fb47a1..e5f8e48 100644
>> > --- a/arch/arm/mach-omap2/display.c
>> > +++ b/arch/arm/mach-omap2/display.c
>> > @@ -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);
>> >
> 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.
>
>> > r = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
>> >
> d> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
>> > 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);
>> >
>> > 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;
> You should do clk_prepare() after os->_clk = c statement. Otherwise
> you are operating on a uninitialized structure pointer.
yes, that was really stupid of me :(. Thanks for catching this.
>> > }
>> >
>> > @@ -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.
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-22 13:48 ` Rajendra Nayak
(?)
@ 2012-06-25 6:07 ` Tomi Valkeinen
-1 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 6:07 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Hi,
On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 6:07 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 6:07 UTC (permalink / raw)
To: Rajendra Nayak
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
Hi,
On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 6:07 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 6:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> and clk_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>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-25 5:30 ` Rajendra Nayak
@ 2012-06-25 6:11 ` DebBarma, Tarun Kanti
-1 siblings, 0 replies; 119+ messages in thread
From: DebBarma, Tarun Kanti @ 2012-06-25 6:11 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Paul Walmsley, mturquette, linux-omap, linux-arm-kernel,
Grant Likely, Pankaj Jangra, Santosh Shilimkar
On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
>>
>> Hi
>>
>> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>>
>>> In preparation of OMAP moving to Common Clk Framework(CCF) add
>>> clk_prepare()
>>> for omap gpio debounce clock.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>> ---
>>> drivers/gpio/gpio-omap.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index c4ed172..6a73b01 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>>> @@ -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()?
>
>
> 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.
>
>
>>
>> Also, it looks to me that the bank->dbck init should be in
>> omap_gpio_chip_init(), not gpio_debounce()?
>
>
> Tarun, can you comment on why the dbck init is in gpio_debounce
> and not in omap_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().
>
>>
>>
>> - Paul
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-25 6:11 ` DebBarma, Tarun Kanti
0 siblings, 0 replies; 119+ messages in thread
From: DebBarma, Tarun Kanti @ 2012-06-25 6:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
>>
>> Hi
>>
>> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>>
>>> In preparation of OMAP moving to Common Clk Framework(CCF) add
>>> clk_prepare()
>>> for omap gpio debounce clock.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>> ---
>>> ?drivers/gpio/gpio-omap.c | ? ?2 ++
>>> ?1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index c4ed172..6a73b01 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>>> @@ -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()?
>
>
> 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.
>
>
>>
>> Also, it looks to me that the bank->dbck init should be in
>> omap_gpio_chip_init(), not gpio_debounce()?
>
>
> Tarun, can you comment on why the dbck init is in gpio_debounce
> and not in omap_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().
>
>>
>>
>> - Paul
>
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-25 5:25 ` Rajendra Nayak
@ 2012-06-25 6:18 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-25 6:18 UTC (permalink / raw)
To: S, Venkatraman, Rajendra Nayak
Cc: mturquette, linux-omap, linux-arm-kernel, Chris Ball, Balaji T K,
linux-mmc
On Mon, 25 Jun 2012, Rajendra Nayak wrote:
> On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote:
> > On Fri, 22 Jun 2012, S, Venkatraman wrote:
> >
> > > On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
> > > > In 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.
> > > >
> > > > Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> > > > Cc: Chris Ball<cjb@laptop.org>
> > > > Cc: Balaji T K<balajitk@ti.com>
> > > > Cc:<linux-mmc@vger.kernel.org>
> > >
> > > 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.
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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-25 6:18 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-25 6:18 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 25 Jun 2012, Rajendra Nayak wrote:
> On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote:
> > On Fri, 22 Jun 2012, S, Venkatraman wrote:
> >
> > > On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
> > > > In 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.
> > > >
> > > > Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> > > > Cc: Chris Ball<cjb@laptop.org>
> > > > Cc: Balaji T K<balajitk@ti.com>
> > > > Cc:<linux-mmc@vger.kernel.org>
> > >
> > > 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.
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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 6:07 ` Tomi Valkeinen
(?)
@ 2012-06-25 6:59 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 6:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_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)
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.
>
> Tom
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 6:59 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 6:59 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_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)
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.
>
> Tom
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-25 6:11 ` DebBarma, Tarun Kanti
@ 2012-06-25 7:02 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 7:02 UTC (permalink / raw)
To: DebBarma, Tarun Kanti
Cc: Paul Walmsley, mturquette, linux-omap, linux-arm-kernel,
Grant Likely, Pankaj Jangra, Santosh Shilimkar
On Monday 25 June 2012 11:41 AM, DebBarma, Tarun Kanti wrote:
> On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak<rnayak@ti.com> wrote:
>> On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
>>>
>>> Hi
>>>
>>> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>>>
>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add
>>>> clk_prepare()
>>>> for omap gpio debounce clock.
>>>>
>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>>> ---
>>>> drivers/gpio/gpio-omap.c | 2 ++
>>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>> index c4ed172..6a73b01 100644
>>>> --- a/drivers/gpio/gpio-omap.c
>>>> +++ b/drivers/gpio/gpio-omap.c
>>>> @@ -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()?
>>
>>
>> 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.
>>
>>
>>>
>>> Also, it looks to me that the bank->dbck init should be in
>>> omap_gpio_chip_init(), not gpio_debounce()?
>>
>>
>> Tarun, can you comment on why the dbck init is in gpio_debounce
>> and not in omap_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().
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.
>
>>
>>>
>>>
>>> - Paul
>>
>>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-25 7:02 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 7:02 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 11:41 AM, DebBarma, Tarun Kanti wrote:
> On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak<rnayak@ti.com> wrote:
>> On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
>>>
>>> Hi
>>>
>>> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>>>
>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add
>>>> clk_prepare()
>>>> for omap gpio debounce clock.
>>>>
>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>>> ---
>>>> drivers/gpio/gpio-omap.c | 2 ++
>>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>> index c4ed172..6a73b01 100644
>>>> --- a/drivers/gpio/gpio-omap.c
>>>> +++ b/drivers/gpio/gpio-omap.c
>>>> @@ -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()?
>>
>>
>> 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.
>>
>>
>>>
>>> Also, it looks to me that the bank->dbck init should be in
>>> omap_gpio_chip_init(), not gpio_debounce()?
>>
>>
>> Tarun, can you comment on why the dbck init is in gpio_debounce
>> and not in omap_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().
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.
>
>>
>>>
>>>
>>> - Paul
>>
>>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 6:59 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 7:11 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>> and clk_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)
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.
>
> Tom
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
2012-06-25 6:18 ` Paul Walmsley
@ 2012-06-25 7:13 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 7:13 UTC (permalink / raw)
To: Paul Walmsley
Cc: S, Venkatraman, mturquette, linux-omap, linux-arm-kernel,
Chris Ball, Balaji T K, linux-mmc
On Monday 25 June 2012 11:48 AM, Paul Walmsley wrote:
> On Mon, 25 Jun 2012, Rajendra Nayak wrote:
>
>> On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote:
>>> On Fri, 22 Jun 2012, S, Venkatraman wrote:
>>>
>>>> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>>>>> In 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.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>>> Cc: Chris Ball<cjb@laptop.org>
>>>>> Cc: Balaji T K<balajitk@ti.com>
>>>>> Cc:<linux-mmc@vger.kernel.org>
>>>>
>>>> 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.
>
> 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?
>
> 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).
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/11] mmc: omap: add clk_prepare and clk_unprepare
@ 2012-06-25 7:13 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 7:13 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 11:48 AM, Paul Walmsley wrote:
> On Mon, 25 Jun 2012, Rajendra Nayak wrote:
>
>> On Saturday 23 June 2012 12:04 AM, Paul Walmsley wrote:
>>> On Fri, 22 Jun 2012, S, Venkatraman wrote:
>>>
>>>> On Fri, Jun 22, 2012 at 7:18 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>>>>> In 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.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>>> Cc: Chris Ball<cjb@laptop.org>
>>>>> Cc: Balaji T K<balajitk@ti.com>
>>>>> Cc:<linux-mmc@vger.kernel.org>
>>>>
>>>> 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.
>
> 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?
>
> 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).
>
> - Paul
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 6:59 ` Rajendra Nayak
(?)
@ 2012-06-25 7:58 ` Tomi Valkeinen
-1 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 7:58 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> > Hi,
> >
> > On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> >> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> >> and clk_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)
>
> 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.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 7:58 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 7:58 UTC (permalink / raw)
To: Rajendra Nayak
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> > Hi,
> >
> > On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> >> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> >> and clk_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)
>
> 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.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 7:58 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 7:58 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> > Hi,
> >
> > On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> >> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> >> and clk_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)
>
> 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.
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>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
2012-06-22 19:04 ` Paul Walmsley
@ 2012-06-25 8:55 ` Munegowda, Keshava
-1 siblings, 0 replies; 119+ messages in thread
From: Munegowda, Keshava @ 2012-06-25 8:55 UTC (permalink / raw)
To: Paul Walmsley
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel, Samuel Ortiz
On Sat, Jun 23, 2012 at 12:34 AM, Paul Walmsley <paul@pwsan.com> wrote:
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
>> and clk_unprepare() for the various usb host clocks.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>
> 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:
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 04/11] mfd: omap-usb: add clk_prepare and clk_unprepare
@ 2012-06-25 8:55 ` Munegowda, Keshava
0 siblings, 0 replies; 119+ messages in thread
From: Munegowda, Keshava @ 2012-06-25 8:55 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jun 23, 2012 at 12:34 AM, Paul Walmsley <paul@pwsan.com> wrote:
> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>
>> In preparation of OMAP moving to Common Clk Framework (CCF) add clk_prepare()
>> and clk_unprepare() for the various usb host clocks.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>
> 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:
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
2012-06-25 7:02 ` Rajendra Nayak
@ 2012-06-25 10:22 ` DebBarma, Tarun Kanti
-1 siblings, 0 replies; 119+ messages in thread
From: DebBarma, Tarun Kanti @ 2012-06-25 10:22 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Paul Walmsley, mturquette, linux-omap, linux-arm-kernel,
Grant Likely, Pankaj Jangra, Santosh Shilimkar
On Mon, Jun 25, 2012 at 12:32 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Monday 25 June 2012 11:41 AM, DebBarma, Tarun Kanti wrote:
>>
>> On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak<rnayak@ti.com> wrote:
>>>
>>> On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
>>>>
>>>>
>>>> Hi
>>>>
>>>> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>>>>
>>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add
>>>>> clk_prepare()
>>>>> for omap gpio debounce clock.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>>>> ---
>>>>> drivers/gpio/gpio-omap.c | 2 ++
>>>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>>> index c4ed172..6a73b01 100644
>>>>> --- a/drivers/gpio/gpio-omap.c
>>>>> +++ b/drivers/gpio/gpio-omap.c
>>>>> @@ -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()?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>>
>>>> Also, it looks to me that the bank->dbck init should be in
>>>> omap_gpio_chip_init(), not gpio_debounce()?
>>>
>>>
>>>
>>> Tarun, can you comment on why the dbck init is in gpio_debounce
>>> and not in omap_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().
>
>
> 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
>>>>
>>>>
>>>> - Paul
>>>
>>>
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/11] gpio/omap: add clk_prepare and clk_unprepare
@ 2012-06-25 10:22 ` DebBarma, Tarun Kanti
0 siblings, 0 replies; 119+ messages in thread
From: DebBarma, Tarun Kanti @ 2012-06-25 10:22 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 25, 2012 at 12:32 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Monday 25 June 2012 11:41 AM, DebBarma, Tarun Kanti wrote:
>>
>> On Mon, Jun 25, 2012 at 11:00 AM, Rajendra Nayak<rnayak@ti.com> ?wrote:
>>>
>>> On Saturday 23 June 2012 12:47 AM, Paul Walmsley wrote:
>>>>
>>>>
>>>> Hi
>>>>
>>>> On Fri, 22 Jun 2012, Rajendra Nayak wrote:
>>>>
>>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add
>>>>> clk_prepare()
>>>>> for omap gpio debounce clock.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>>>> ---
>>>>> ?drivers/gpio/gpio-omap.c | ? ?2 ++
>>>>> ?1 files changed, 2 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>>> index c4ed172..6a73b01 100644
>>>>> --- a/drivers/gpio/gpio-omap.c
>>>>> +++ b/drivers/gpio/gpio-omap.c
>>>>> @@ -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()?
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>>
>>>> Also, it looks to me that the bank->dbck init should be in
>>>> omap_gpio_chip_init(), not gpio_debounce()?
>>>
>>>
>>>
>>> Tarun, can you comment on why the dbck init is in gpio_debounce
>>> and not in omap_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().
>
>
> 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
>>>>
>>>>
>>>> - Paul
>>>
>>>
>>>
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 6:07 ` Tomi Valkeinen
(?)
@ 2012-06-25 11:22 ` Russell King - ARM Linux
-1 siblings, 0 replies; 119+ messages in thread
From: Russell King - ARM Linux @ 2012-06-25 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 25, 2012 at 09:07:58AM +0300, Tomi Valkeinen wrote:
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> > In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> > and clk_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)
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().
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 11:22 ` Russell King - ARM Linux
0 siblings, 0 replies; 119+ messages in thread
From: Russell King - ARM Linux @ 2012-06-25 11:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rajendra Nayak, paul, linux-omap, linux-fbdev, linux-arm-kernel,
mturquette
On Mon, Jun 25, 2012 at 09:07:58AM +0300, Tomi Valkeinen wrote:
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> > In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> > and clk_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)
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().
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 11:22 ` Russell King - ARM Linux
0 siblings, 0 replies; 119+ messages in thread
From: Russell King - ARM Linux @ 2012-06-25 11:22 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 25, 2012 at 09:07:58AM +0300, Tomi Valkeinen wrote:
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> > In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> > and clk_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)
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().
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 7:58 ` Tomi Valkeinen
(?)
@ 2012-06-25 11:48 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 11:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
>> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>>>> and clk_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)
>>
>> 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.
>
> 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.
>
> I'll check if any of the dss clocks are enabled or disabled in atomic
> context.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 11:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 11:48 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
>> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>>>> and clk_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)
>>
>> 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.
>
> 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.
>
> I'll check if any of the dss clocks are enabled or disabled in atomic
> context.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 11:48 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-25 11:52 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote:
> On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
>> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
>>>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
>>>> and clk_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)
>>
>> 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.
>
> 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.
>
> I'll check if any of the dss clocks are enabled or disabled in atomic
> context.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 11:48 ` Rajendra Nayak
(?)
@ 2012-06-25 13:14 ` Tomi Valkeinen
-1 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 13:14 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]
On Mon, 2012-06-25 at 17:18 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote:
> > On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
> >> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> >>>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> >>>> and clk_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)
> >>
> >> 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.
> >
> > 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.
>
> >
> > 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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 13:14 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 13:14 UTC (permalink / raw)
To: Rajendra Nayak
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]
On Mon, 2012-06-25 at 17:18 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote:
> > On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
> >> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> >>>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> >>>> and clk_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)
> >>
> >> 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.
> >
> > 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.
>
> >
> > 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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-25 13:14 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-25 13:14 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2012-06-25 at 17:18 +0530, Rajendra Nayak wrote:
> On Monday 25 June 2012 01:28 PM, Tomi Valkeinen wrote:
> > On Mon, 2012-06-25 at 12:29 +0530, Rajendra Nayak wrote:
> >> On Monday 25 June 2012 11:37 AM, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> >>>> In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> >>>> and clk_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)
> >>
> >> 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.
> >
> > 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.
>
> >
> > 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
-------------- 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/b57df7a5/attachment.sig>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 13:14 ` Tomi Valkeinen
(?)
@ 2012-06-26 5:00 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 5:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote:
> 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.
>
>
> 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 =).
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.
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-26 5:00 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 5:00 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote:
> 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.
>
>
> 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 =).
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.
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-26 5:00 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 5:12 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote:
> 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.
>
>
> 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 =).
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.
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-26 5:00 ` Rajendra Nayak
(?)
@ 2012-06-26 6:55 ` Tomi Valkeinen
-1 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-26 6:55 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
> > 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.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-26 6:55 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-26 6:55 UTC (permalink / raw)
To: Rajendra Nayak
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
> > 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.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-26 6:55 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-26 6:55 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
> > 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.
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>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-26 6:55 ` Tomi Valkeinen
(?)
@ 2012-06-26 7:36 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 7:36 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: paul, mturquette, linux-omap, linux-arm-kernel, linux-fbdev
On Tuesday 26 June 2012 12:25 PM, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
>
>>> 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.
>
> But if I understood correctly, clk_prepare and clk_unprepare are anyway
> no-ops with dss clocks, even when CONFIG_COMMON_CLK is enabled?
With CONFIG_COMMON_CLK enabled, they will do prepare use-counting with
a mutex lock/unlock around it.
>
> 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.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-26 7:36 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 7:36 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 26 June 2012 12:25 PM, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
>
>>> 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.
>
> But if I understood correctly, clk_prepare and clk_unprepare are anyway
> no-ops with dss clocks, even when CONFIG_COMMON_CLK is enabled?
With CONFIG_COMMON_CLK enabled, they will do prepare use-counting with
a mutex lock/unlock around it.
>
> 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.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-26 7:36 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 7:48 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 26 June 2012 12:25 PM, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
>
>>> 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.
>
> But if I understood correctly, clk_prepare and clk_unprepare are anyway
> no-ops with dss clocks, even when CONFIG_COMMON_CLK is enabled?
With CONFIG_COMMON_CLK enabled, they will do prepare use-counting with
a mutex lock/unlock around it.
>
> 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.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
2012-06-25 5:29 ` Rajendra Nayak
@ 2012-06-26 10:39 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-26 10:39 UTC (permalink / raw)
To: Rajendra Nayak; +Cc: mturquette, linux-omap, linux-arm-kernel, Herbert Xu
On Mon, 25 Jun 2012, Rajendra Nayak wrote:
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
@ 2012-06-26 10:39 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-26 10:39 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 25 Jun 2012, Rajendra Nayak wrote:
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
2012-06-26 10:39 ` Paul Walmsley
@ 2012-06-26 10:58 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 10:58 UTC (permalink / raw)
To: Paul Walmsley; +Cc: mturquette, linux-omap, linux-arm-kernel, Herbert Xu
On Tuesday 26 June 2012 04:09 PM, Paul Walmsley wrote:
> 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?
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 08/11] crypto: omap: add clk_prepare and clk_unprepare
@ 2012-06-26 10:58 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-26 10:58 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 26 June 2012 04:09 PM, Paul Walmsley wrote:
> 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?
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-25 13:14 ` Tomi Valkeinen
(?)
@ 2012-06-27 0:47 ` Mike Turquette
-1 siblings, 0 replies; 119+ messages in thread
From: Mike Turquette @ 2012-06-27 0:47 UTC (permalink / raw)
To: linux-arm-kernel
On 20120625-16:14, Tomi Valkeinen wrote:
> 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 =).
>
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
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-27 0:47 ` Mike Turquette
0 siblings, 0 replies; 119+ messages in thread
From: Mike Turquette @ 2012-06-27 0:47 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Rajendra Nayak, paul, linux-omap, linux-arm-kernel, linux-fbdev
On 20120625-16:14, Tomi Valkeinen wrote:
> 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 =).
>
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
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-27 0:47 ` Mike Turquette
0 siblings, 0 replies; 119+ messages in thread
From: Mike Turquette @ 2012-06-27 0:47 UTC (permalink / raw)
To: linux-arm-kernel
On 20120625-16:14, Tomi Valkeinen wrote:
> 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 =).
>
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
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-27 0:47 ` Mike Turquette
(?)
@ 2012-06-27 4:19 ` Tomi Valkeinen
-1 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-27 4:19 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]
On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
> On 20120625-16:14, Tomi Valkeinen wrote:
> > 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 =).
> >
>
> 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.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-27 4:19 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-27 4:19 UTC (permalink / raw)
To: Mike Turquette
Cc: Rajendra Nayak, paul, linux-omap, linux-arm-kernel, linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]
On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
> On 20120625-16:14, Tomi Valkeinen wrote:
> > 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 =).
> >
>
> 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.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-27 4:19 ` Tomi Valkeinen
0 siblings, 0 replies; 119+ messages in thread
From: Tomi Valkeinen @ 2012-06-27 4:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
> On 20120625-16:14, Tomi Valkeinen wrote:
> > 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 =).
> >
>
> 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.
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>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
2012-06-27 4:19 ` Tomi Valkeinen
(?)
@ 2012-06-27 5:19 ` Rajendra Nayak
-1 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-27 5:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mike Turquette, paul, linux-omap, linux-arm-kernel, linux-fbdev,
Hilman, Kevin
On Wednesday 27 June 2012 09:49 AM, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
>> On 20120625-16:14, Tomi Valkeinen wrote:
>>> 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 =).
>>>
>>
>> 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.
>
> 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.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-27 5:19 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-27 5:19 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 27 June 2012 09:49 AM, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
>> On 20120625-16:14, Tomi Valkeinen wrote:
>>> 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 =).
>>>
>>
>> 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.
>
> 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.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
@ 2012-06-27 5:19 ` Rajendra Nayak
0 siblings, 0 replies; 119+ messages in thread
From: Rajendra Nayak @ 2012-06-27 5:31 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 27 June 2012 09:49 AM, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
>> On 20120625-16:14, Tomi Valkeinen wrote:
>>> 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 =).
>>>
>>
>> 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.
>
> 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.
>
> Tomi
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-22 13:47 ` Rajendra Nayak
@ 2012-06-27 12:50 ` Laurent Pinchart
-1 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 12:50 UTC (permalink / raw)
To: Rajendra Nayak; +Cc: paul, mturquette, linux-omap, linux-arm-kernel
Hi Rajendra,
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 uses clk_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 ?
> 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.git prepare-common-clk-3.5-rc3
>
> regards,
> Rajendra
>
> [1] http://www.mail-archive.com/linux-omap@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(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 12:50 ` Laurent Pinchart
0 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 12:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rajendra,
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 uses clk_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 ?
> 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.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(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-27 12:50 ` Laurent Pinchart
@ 2012-06-27 16:36 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-27 16:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel, Sakari Ailus
Hi Laurent
On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 16:36 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-27 16:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Laurent
On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> 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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-27 16:36 ` Paul Walmsley
@ 2012-06-27 18:05 ` Laurent Pinchart
-1 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 18:05 UTC (permalink / raw)
To: Paul Walmsley
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel, Sakari Ailus
Hi Paul,
On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
> On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > 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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 18:05 ` Laurent Pinchart
0 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 18:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Paul,
On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
> On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > 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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-27 18:05 ` Laurent Pinchart
@ 2012-06-27 18:45 ` Laurent Pinchart
-1 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 18:45 UTC (permalink / raw)
To: Paul Walmsley
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel, Sakari Ailus
On Wednesday 27 June 2012 20:05:27 Laurent Pinchart wrote:
> On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
> > On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > > 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 ?
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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 18:45 ` Laurent Pinchart
0 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 18:45 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 27 June 2012 20:05:27 Laurent Pinchart wrote:
> On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
> > On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > > 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 ?
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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-27 18:45 ` Laurent Pinchart
@ 2012-06-27 19:56 ` Laurent Pinchart
-1 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 19:56 UTC (permalink / raw)
To: Paul Walmsley
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel, Sakari Ailus
On Wednesday 27 June 2012 20:45:00 Laurent Pinchart wrote:
> On Wednesday 27 June 2012 20:05:27 Laurent Pinchart wrote:
> > On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
> > > On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > > > 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 ?
>
> 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 ?
> 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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 19:56 ` Laurent Pinchart
0 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 19:56 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 27 June 2012 20:45:00 Laurent Pinchart wrote:
> On Wednesday 27 June 2012 20:05:27 Laurent Pinchart wrote:
> > On Wednesday 27 June 2012 10:36:04 Paul Walmsley wrote:
> > > On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > > > 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 ?
>
> 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 ?
> 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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-27 18:45 ` Laurent Pinchart
@ 2012-06-27 19:59 ` Paul Walmsley
-1 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-27 19:59 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel,
Sakari Ailus, khilman
+ Kevin
On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> OK, I think I've found the information. I'll give this a try.
That sounds great.
> 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 ?
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
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 19:59 ` Paul Walmsley
0 siblings, 0 replies; 119+ messages in thread
From: Paul Walmsley @ 2012-06-27 19:59 UTC (permalink / raw)
To: linux-arm-kernel
+ Kevin
On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> OK, I think I've found the information. I'll give this a try.
That sounds great.
> 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 ?
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
^ permalink raw reply [flat|nested] 119+ messages in thread
* Re: [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
2012-06-27 19:59 ` Paul Walmsley
@ 2012-06-27 20:25 ` Laurent Pinchart
-1 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 20:25 UTC (permalink / raw)
To: Paul Walmsley
Cc: Rajendra Nayak, mturquette, linux-omap, linux-arm-kernel,
Sakari Ailus, khilman
Hi Paul,
On Wednesday 27 June 2012 13:59:21 Paul Walmsley wrote:
> + Kevin
>
> On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > 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 ?
> > 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 ?
>
> 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)
> 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*().
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 ?
> It's been a long time since I've looked, but I'd be surprised if we had
> many drivers that operated like that...
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk
@ 2012-06-27 20:25 ` Laurent Pinchart
0 siblings, 0 replies; 119+ messages in thread
From: Laurent Pinchart @ 2012-06-27 20:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Paul,
On Wednesday 27 June 2012 13:59:21 Paul Walmsley wrote:
> + Kevin
>
> On Wed, 27 Jun 2012, Laurent Pinchart wrote:
> > 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 ?
> > 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 ?
>
> 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)
> 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*().
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 ?
> It's been a long time since I've looked, but I'd be surprised if we had
> many drivers that operated like that...
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 119+ messages in thread
end of thread, other threads:[~2012-06-27 20:25 UTC | newest]
Thread overview: 119+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-22 13:47 [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk Rajendra Nayak
2012-06-22 13:47 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 17:42 ` Pankaj Jangra
2012-06-22 17:42 ` Pankaj Jangra
2012-06-25 5:36 ` Rajendra Nayak
2012-06-25 5:36 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 02/11] mmc: omap: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 18:23 ` S, Venkatraman
2012-06-22 18:23 ` S, Venkatraman
2012-06-22 18:34 ` Paul Walmsley
2012-06-22 18:34 ` Paul Walmsley
2012-06-25 5:25 ` Rajendra Nayak
2012-06-25 5:25 ` Rajendra Nayak
2012-06-25 6:18 ` Paul Walmsley
2012-06-25 6:18 ` Paul Walmsley
2012-06-25 7:13 ` Rajendra Nayak
2012-06-25 7:13 ` Rajendra Nayak
2012-06-25 5:32 ` Rajendra Nayak
2012-06-25 5:32 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 03/11] hwrng: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 04/11] mfd: omap-usb: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 19:04 ` Paul Walmsley
2012-06-22 19:04 ` Paul Walmsley
2012-06-25 8:55 ` Munegowda, Keshava
2012-06-25 8:55 ` Munegowda, Keshava
2012-06-22 13:48 ` [PATCH 05/11] OMAPDSS: " Rajendra Nayak
2012-06-22 13:51 ` Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-25 6:07 ` Tomi Valkeinen
2012-06-25 6:07 ` Tomi Valkeinen
2012-06-25 6:07 ` Tomi Valkeinen
2012-06-25 6:59 ` Rajendra Nayak
2012-06-25 7:11 ` Rajendra Nayak
2012-06-25 6:59 ` Rajendra Nayak
2012-06-25 7:58 ` Tomi Valkeinen
2012-06-25 7:58 ` Tomi Valkeinen
2012-06-25 7:58 ` Tomi Valkeinen
2012-06-25 11:48 ` Rajendra Nayak
2012-06-25 11:52 ` Rajendra Nayak
2012-06-25 11:48 ` Rajendra Nayak
2012-06-25 13:14 ` Tomi Valkeinen
2012-06-25 13:14 ` Tomi Valkeinen
2012-06-25 13:14 ` Tomi Valkeinen
2012-06-26 5:00 ` Rajendra Nayak
2012-06-26 5:12 ` Rajendra Nayak
2012-06-26 5:00 ` Rajendra Nayak
2012-06-26 6:55 ` Tomi Valkeinen
2012-06-26 6:55 ` Tomi Valkeinen
2012-06-26 6:55 ` Tomi Valkeinen
2012-06-26 7:36 ` Rajendra Nayak
2012-06-26 7:48 ` Rajendra Nayak
2012-06-26 7:36 ` Rajendra Nayak
2012-06-27 0:47 ` Mike Turquette
2012-06-27 0:47 ` Mike Turquette
2012-06-27 0:47 ` Mike Turquette
2012-06-27 4:19 ` Tomi Valkeinen
2012-06-27 4:19 ` Tomi Valkeinen
2012-06-27 4:19 ` Tomi Valkeinen
2012-06-27 5:19 ` Rajendra Nayak
2012-06-27 5:31 ` Rajendra Nayak
2012-06-27 5:19 ` Rajendra Nayak
2012-06-25 11:22 ` Russell King - ARM Linux
2012-06-25 11:22 ` Russell King - ARM Linux
2012-06-25 11:22 ` Russell King - ARM Linux
2012-06-22 13:48 ` [PATCH 06/11] gpio/omap: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 15:57 ` Pankaj Jangra
2012-06-22 15:57 ` Pankaj Jangra
2012-06-22 19:17 ` Paul Walmsley
2012-06-22 19:17 ` Paul Walmsley
2012-06-25 5:30 ` Rajendra Nayak
2012-06-25 5:30 ` Rajendra Nayak
2012-06-25 6:11 ` DebBarma, Tarun Kanti
2012-06-25 6:11 ` DebBarma, Tarun Kanti
2012-06-25 7:02 ` Rajendra Nayak
2012-06-25 7:02 ` Rajendra Nayak
2012-06-25 10:22 ` DebBarma, Tarun Kanti
2012-06-25 10:22 ` DebBarma, Tarun Kanti
2012-06-22 13:48 ` [PATCH 07/11] w1: omap_hdq: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 18:35 ` Paul Walmsley
2012-06-22 18:35 ` Paul Walmsley
2012-06-25 5:25 ` Rajendra Nayak
2012-06-25 5:25 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 08/11] crypto: omap: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 18:58 ` Paul Walmsley
2012-06-22 18:58 ` Paul Walmsley
2012-06-25 5:29 ` Rajendra Nayak
2012-06-25 5:29 ` Rajendra Nayak
2012-06-26 10:39 ` Paul Walmsley
2012-06-26 10:39 ` Paul Walmsley
2012-06-26 10:58 ` Rajendra Nayak
2012-06-26 10:58 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 09/11] iommu: " Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 10/11] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 11/11] ARM: omap: clk: Remove all direct dereferencing of struct clk Rajendra Nayak
2012-06-22 13:48 ` Rajendra Nayak
2012-06-27 12:50 ` [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk Laurent Pinchart
2012-06-27 12:50 ` Laurent Pinchart
2012-06-27 16:36 ` Paul Walmsley
2012-06-27 16:36 ` Paul Walmsley
2012-06-27 18:05 ` Laurent Pinchart
2012-06-27 18:05 ` Laurent Pinchart
2012-06-27 18:45 ` Laurent Pinchart
2012-06-27 18:45 ` Laurent Pinchart
2012-06-27 19:56 ` Laurent Pinchart
2012-06-27 19:56 ` Laurent Pinchart
2012-06-27 19:59 ` Paul Walmsley
2012-06-27 19:59 ` Paul Walmsley
2012-06-27 20:25 ` Laurent Pinchart
2012-06-27 20:25 ` Laurent Pinchart
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.