Re: [PATCH] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
Hi Kevin, Nishanth,
On 06/01/12 02:15, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not
present)
makes the logic:
for (i = 0; i opp_def_size; i++) {
snip
if (!oh || !oh-od) {
snip
continue;
}
snip
opp_def++;
}
In short, the moment we hit a Bad OPP, we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)
Cc: Kevin Hilman khil...@ti.com
Cc: Steve Sakoman st...@sakoman.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
Good catch.
Queuing for my next set of PM fixes for v3.5-rc (branch: for_3.5/fixes/pm-2)
I think this should also apply for stable, right?
If it should, can you please add a
Cc: sta...@vger.kernel.org
?
Thanks
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
On Fri, Jun 1, 2012 at 2:03 AM, Igor Grinberg grinb...@compulab.co.il wrote:
On 06/01/12 02:15, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not
present)
makes the logic:
for (i = 0; i opp_def_size; i++) {
snip
if (!oh || !oh-od) {
snip
continue;
}
snip
opp_def++;
}
In short, the moment we hit a Bad OPP, we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)
Cc: Kevin Hilman khil...@ti.com
Cc: Steve Sakoman st...@sakoman.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
Good catch.
Queuing for my next set of PM fixes for v3.5-rc (branch: for_3.5/fixes/pm-2)
I think this should also apply for stable, right?
If it should, can you please add a
Cc: sta...@vger.kernel.org
I would like to think so, but punting over to Kevin on that decision.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap: dma: Clear status registers on enable/disable irq.
On 05/16/2012 12:35 AM, Oleg Matcovschi wrote: Use omap_disable_channel_irq() function instead of directly accessing CICR. The omap_disable_chanel_irq() function clears pending interrupts and disables interrupt on channel. Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt status register. Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- v1 initial revision v2 Review by Tony Lindgren --- arch/arm/plat-omap/dma.c | 59 + 1 files changed, 28 insertions(+), 31 deletions(-) Tested on BeagleBoard by using mmc and audio Tested-by: Jarkko Nikula jarkko.nik...@bitmer.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 8/9] ARM: OMAP3: prevent per_clkdm from attempting manual domain transitions
On Thu, 2012-05-31 at 18:40 -0500, Jon Hunter wrote:
Hi Tero,
On 05/31/2012 08:29 AM, Tero Kristo wrote:
Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain will
attempt to enter software supervised idle, which is not supported by the
hardware/kernel that well, and causes multiple problems. First of all,
coming back from idle, PER domain remains idle as the wakedeps have
been disabled for the domain, and this causes a crash with the GPIO
code, as the resume code attempts to access domain which is not active.
Just enabling the interface clocks for the GPIO does not help, as they
are autoidled and don't bring the domain out of idle. Secondly, there
are multiple erratas for omap3, which say that the wakedeps should be
enabled for the PER domain, see e.g. errata i582 for omap3630.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clockdomains3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 6038adb..0dae4c8 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -282,7 +282,7 @@ static struct clockdomain usbhost_clkdm = {
static struct clockdomain per_clkdm = {
.name = per_clkdm,
.pwrdm = { .name = per_pwrdm },
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_HWSUP_SWSUP | CLKDM_SKIP_MANUAL_TRANS,
.dep_bit= OMAP3430_EN_PER_SHIFT,
.wkdep_srcs = per_wkdeps,
.sleepdep_srcs = per_sleepdeps,
So this change is just preventing software from clearing the wakeup-deps
and keeping the PER clock domain always in HW_AUTO?
Basically yes.
Sorry for the dumb question, but what is the circumstance under which we
want to clear the wakeup-deps when we disable the clock domain? I am
just curious why this is being done in the first place.
Not sure, maybe Paul can answer that question. Personally I don't see
much point in fiddling with the wakedeps.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v4] ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events
On Wed, Apr 25, 2012 at 2:17 AM, Govindraj.R govindraj.r...@ti.com wrote:
[...]
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,13 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
not suppose to be used on omap4\n);
return 0;
}
+static inline void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod,
+ u8 prm_reg_id, u8 prm_reg_shift, bool set_wake)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
^ minor comment - we should not return a value in a function returning void
[...]
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
On Thu, May 31, 2012 at 8:28 AM, Tero Kristo t-kri...@ti.com wrote: minor comment: +void pwrdm_clkdm_enable(struct powerdomain *pwrdm) snip +void pwrdm_clkdm_disable(struct powerdomain *pwrdm) I know the understand that rest of the code lacks kernel-doc, but at least can we ensure that the new functions does? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 13/14] ARM: OMAP3: vc: auto_ret / auto_off support
On Thu, May 31, 2012 at 8:55 AM, Tero Kristo t-kri...@ti.com wrote: + case PWRDM_POWER_RET: Apologies on hijacking this thread, but I do think we need to revisit this series after rebase on top of Jean's series - it otherwise results a mess of different sets of macros. IMHO though, it might be a good time to discuss if we would like to switch from macros to enums to become as much as possible type safe in usage - it is just too easy for later developers who will maintain this code from mistakenly using wrong macros at the wrong place and causing others to spend weeks debugging? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
On Fri, 1 Jun 2012, Menon, Nishanth wrote: On Thu, May 31, 2012 at 8:28 AM, Tero Kristo t-kri...@ti.com wrote: minor comment: +void pwrdm_clkdm_enable(struct powerdomain *pwrdm) snip +void pwrdm_clkdm_disable(struct powerdomain *pwrdm) I know the understand that rest of the code lacks kernel-doc, Almost all of the powerdomain code has kerneldoc present. but at least can we ensure that the new functions does? Indeed: http://www.spinics.net/lists/arm-kernel/msg164548.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] omap: add ocp2scp as a misc driver
* Arnd Bergmann a...@arndb.de [120531 02:26]: On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: Just put the devices you actually want into the device tree instead and have them automatically created. But shouldn't device tree support and non-device tree support co-exist till the non-device tree is completely knocked out of the kernel? Even Well, it's a new driver, so there is no regression in supporting it only on DT-enabled boards. OMAP5 is DT-only anyway and OMAP4 only supports two boards that should both be working with the generic DT code already. I agree, let's keep the new omap4/5 drivers DT only. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] usb: gadget: omap_udc: remove useless print
* Felipe Balbi ba...@ti.com [120529 05:22]:
that print isn't needed at all. Remove it
and move the use_dma reinitialization to
probe() function.
Note that ideally we would drop all
cpu_is_* and machine_is_* checks from
this driver instead. Later patches will
come to get rid of those.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/omap_udc.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index aa2d174..5e7b891 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -2800,6 +2800,9 @@ static int __init omap_udc_probe(struct platform_device
*pdev)
struct clk *dc_clk = NULL;
struct clk *hhc_clk = NULL;
+ if (cpu_is_omap7xx())
+ use_dma = 0;
+
/* NOTE: knows the order of the resources! */
if (!request_mem_region(pdev-resource[0].start,
pdev-resource[0].end - pdev-resource[0].start + 1,
I think this would break omap_udc for 7xx as it then tries to use
DMA as USED_MA is set by default?
Setting use_dma = 0 twice is unncessary though :)
Regards,
Tony
@@ -3096,16 +3099,6 @@ static struct platform_driver udc_driver = {
static int __init udc_init(void)
{
- /* Disable DMA for omap7xx -- it doesn't work right. */
- if (cpu_is_omap7xx())
- use_dma = 0;
-
- INFO(%s, version: DRIVER_VERSION
-#ifdef USE_ISO
- (iso)
-#endif
- %s\n, driver_desc,
- use_dma ? (dma) : );
return platform_driver_probe(udc_driver, omap_udc_probe);
}
module_init(udc_init);
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] usb: gadget: omap_udc: remove useless print
Hi, On Fri, Jun 01, 2012 at 04:01:24AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [120529 05:22]: that print isn't needed at all. Remove it and move the use_dma reinitialization to probe() function. Note that ideally we would drop all cpu_is_* and machine_is_* checks from this driver instead. Later patches will come to get rid of those. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/gadget/omap_udc.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c index aa2d174..5e7b891 100644 --- a/drivers/usb/gadget/omap_udc.c +++ b/drivers/usb/gadget/omap_udc.c @@ -2800,6 +2800,9 @@ static int __init omap_udc_probe(struct platform_device *pdev) struct clk *dc_clk = NULL; struct clk *hhc_clk = NULL; + if (cpu_is_omap7xx()) + use_dma = 0; + /* NOTE: knows the order of the resources! */ if (!request_mem_region(pdev-resource[0].start, pdev-resource[0].end - pdev-resource[0].start + 1, I think this would break omap_udc for 7xx as it then tries to use DMA as USED_MA is set by default? I'm clearing it in the start of probe function. There's not functional changes at all. use_dma is ON by default, then our probe gets called and first thing we do is clear use_dma to zero when we're running on omap7xx. I don't see the issue, maybe I'm missing something. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 02/11] ARM: OMAP: expose control.h to mach area
* Valentin, Eduardo eduardo.valen...@ti.com [120528 03:34]: Hello, On Mon, May 28, 2012 at 12:25 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin eduardo.valen...@ti.com wrote: This patch exposes the definitions under control.h to drivers outside the machine code. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- After second thought, this complete header movement needs to avoided. Drivers should not anyway include something like mach/control.h May be split the control.h header file data into .. - defines used by mach-omap2/* files which can remain in control.h in existing location. OK.. - common functions/defines used across drivers/*, mach-omap2/*, plat-omap/*, should go to include/linux/omap_control.h Right.. - Driver specific defines like thermal, usb etc, should go to respective drivers file. Indeed. What do you think ? I think we are in line. And I believe I saw a similar comment by Benoit in other email thread. Having a better thinking of this, it makes sense to have the definition specific to drivers in the driver scope only, as they are going to be used only there anyway. I will drop this patch off and update the remaining changes accordingly (drop the change in control.h for thermal specific and move it to omap_bandgap.h). Yes good, we should not expose these to the other drivers, that will lead into misuse of these defines from various other drivers that we may not notice until it's too late. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
* Cousson, Benoit b-cous...@ti.com [120529 06:29]: On 5/28/2012 1:35 PM, Eduardo Valentin wrote: Mmm, we can have up to 4 control module instances in OMAP4. Well, I'm not sure it worth considering them as separate devices. Is that your plan as well? At least for now I was focusing on the ctrl_module_core ... OK, that's a good start already :-) But since they all have different base address, it will be trick to handle them with only a single entry. Indeed. We can always add the support latter on. I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set? We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning. These should be separate driver instances for the control modules. And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs. Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver. We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type
* Eduardo Valentin eduardo.valen...@ti.com [120528 04:28]: On Mon, May 28, 2012 at 03:32:50PM +0530, Shilimkar, Santosh wrote: On Fri, May 25, 2012 at 6:23 PM, Cousson, Benoit b-cous...@ti.com wrote: OK, not really related to that patch, but the previous cpu_is_omap24xx makes me think of that :-) What about the omapX_check_revision used by cpu_is_XXX? This call is the very first one to require the control module access in order to get the ID_CODE inside the control module. So far it still use that ugly hard coded phys - virtual address macro that is sued for that. Agree with Benoits comment. One way to deal with this is, store the register offset with init and then just use it here. That way you can get rid of all cpu_is_() from this function. I see. I need to check how this storing would look like. Probably we can do the storing when the early device gets probed. As this needs to be initialized very early I'd rather avoid dependencies to drivers for this. Maybe that register can be read and saved when the device gets built? It's ioremapped anyways at that point. That is assuming we don't need to export it to drivers or constantly read it.. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
* Eduardo Valentin eduardo.valen...@ti.com [120525 01:31]:
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret;
+
+ if (on) {
+ ret = omap_control_readl(dev, CONTROL_DEV_CONF, val);
+ if (!ret (val PHY_PD)) {
+ ret = omap_control_writel(dev, ~PHY_PD,
+ CONTROL_DEV_CONF);
+ /* XXX: add proper documentation for this delay */
+ mdelay(200);
+ }
+ } else {
+ ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
I'm not quite convinced that we should export omap_control_read/write
to drivers. If there's a clear register area this USB phy driver can
manage, then ioremaping it separately makes sense. If it's just one
register, then exporting something like omap_control_usb_phy_set()
might be better for ensuring that drivers don't mess up things for
other drivers.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] usb: gadget: omap_udc: remove useless print
* Felipe Balbi ba...@ti.com [120601 04:13]: Hi, On Fri, Jun 01, 2012 at 04:01:24AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [120529 05:22]: that print isn't needed at all. Remove it and move the use_dma reinitialization to probe() function. Note that ideally we would drop all cpu_is_* and machine_is_* checks from this driver instead. Later patches will come to get rid of those. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/gadget/omap_udc.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c index aa2d174..5e7b891 100644 --- a/drivers/usb/gadget/omap_udc.c +++ b/drivers/usb/gadget/omap_udc.c @@ -2800,6 +2800,9 @@ static int __init omap_udc_probe(struct platform_device *pdev) struct clk *dc_clk = NULL; struct clk *hhc_clk = NULL; + if (cpu_is_omap7xx()) + use_dma = 0; + /* NOTE: knows the order of the resources! */ if (!request_mem_region(pdev-resource[0].start, pdev-resource[0].end - pdev-resource[0].start + 1, I think this would break omap_udc for 7xx as it then tries to use DMA as USED_MA is set by default? I'm clearing it in the start of probe function. There's not functional changes at all. use_dma is ON by default, then our probe gets called and first thing we do is clear use_dma to zero when we're running on omap7xx. I don't see the issue, maybe I'm missing something. OK thanks for clarifying, sounds like it should work then. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 01/24] clk: Add CLK_IS_BASIC flag to identify basic clocks
Most platforms end up using a mix of basic clock types and
some which use clk_hw_foo struct for filling in custom platform
information when the clocks don't fit into basic types supported.
In platform code, its useful to know if a clock is using a basic
type or clk_hw_foo, which helps platforms know if they can
safely use to_clk_hw_foo to derive the clk_hw_foo pointer from
clk_hw.
Mark all basic clocks with a CLK_IS_BASIC flag.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
See patch 8 and 11 in the series to know why I came up
with this patch. I don;t know if this is the right way
to handle my situation. Feedback is welcome.
drivers/clk/clk-divider.c |2 +-
drivers/clk/clk-fixed-factor.c |2 +-
drivers/clk/clk-fixed-rate.c |2 +-
drivers/clk/clk-gate.c |2 +-
drivers/clk/clk-mux.c |2 +-
include/linux/clk-private.h|2 +-
include/linux/clk-provider.h |1 +
7 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e4911ee..53f9dd7 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -266,7 +266,7 @@ struct clk *clk_register_divider(struct device *dev, const
char *name,
init.name = name;
init.ops = clk_divider_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ? parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index c8c003e..a489985 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -82,7 +82,7 @@ struct clk *clk_register_fixed_factor(struct device *dev,
const char *name,
init.name = name;
init.ops = clk_fixed_factor_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = parent_name;
init.num_parents = 1;
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index cbd2462..7e14645 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -63,7 +63,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const
char *name,
init.name = name;
init.ops = clk_fixed_rate_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ? parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 578465e..15114fe 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -130,7 +130,7 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
init.name = name;
init.ops = clk_gate_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ? parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index fd36a8e..508c032 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -106,7 +106,7 @@ struct clk *clk_register_mux(struct device *dev, const char
*name,
init.name = name;
init.ops = clk_mux_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = parent_names;
init.num_parents = num_parents;
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 2479239..0835bda 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -64,7 +64,7 @@ struct clk {
.parent_names = _parent_names, \
.num_parents = ARRAY_SIZE(_parent_names), \
.parents = _parents,\
- .flags = _flags,\
+ .flags = _flags | CLK_IS_BASIC, \
}
#define DEFINE_CLK_FIXED_RATE(_name, _flags, _rate,\
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 22bc067..a969614 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -25,6 +25,7 @@
#define CLK_SET_RATE_PARENTBIT(2) /* propagate rate change up one level */
#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */
#define CLK_IS_ROOTBIT(4) /* root clk, has no parent */
+#define CLK_IS_BASIC BIT(5) /* Basic clk, can't do a to_clk_foo() */
struct clk_hw;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 00/24] Move OMAP2+ over to use COMMON clock
Hi, This RFC series is based of Mikes' latest clk-next. I will rebase it once 3.5-rc1 is out and post with more testing thats in progress. Meanwhile, the RFC is for me to get some early feedback on the patches. This series retains the static clock declarations and also all data and code in mach-omap folders and does not move it as yet to drivers/clk. I know its desierable that we move away from static declaration of data and move over to drivers/clk but thats not addressed by this series. Also the series moves over only OMAP2+ (OMAP2/3/4) to use COMMON clk and leaves OMAP1 still using OMAP clock framework. The series does not break git-bisect at any point and to do so adds new data in completely different files and uses some ifdefferry in code too, and switches over in one patch to move from OMAP clock to COMMON clock. Then deletes all old data files and all the ifdeferrey around. All of the new data for OMAP2/3/4 in the new COMMON clock format is autogenerated, OMAP4 by hacking the existing python scripts, and OMAP2/3 by converting the existing C99 structs to JSON format (Thanks to Paul Walmsley for this) and then having python to read the JSON format and generate the C99 structs back in the form COMMON clk expects. The patches also depend on 2 of my patches posted here http://comments.gmane.org/gmane.linux.kernel/1298747 I have not reposted them becasue one of them is already picked up by Mike, and the other is already under discussion. The series with all dependent patches can be found here git://github.com/rrnayak/linux.git clk-next-omap regards, Rajendra Mike Turquette (1): ARM: omap4: cm: add bitfield width values Rajendra Nayak (23): clk: Add CLK_IS_BASIC flag to identify basic clocks ARM: omap: clk: convert all clk_enable to clk_prepare_enable ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage ARM: omap: clk: Nuke plat clock.c clock.h if CONFIG_COMMON_CLK ARM: omap: clk: Remove all direct dereferncing of struct clk ARM: omap: hwmod: Fix up hwmod based clkdm accesses ARM: omap4: clk: Convert to common clk ARM: omap3: clk: Convert to common clk ARM: omap2: clk: Convert to common clk ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle ARM: omap: clk: Define a function to enable clocks at init ARM: omap4: clk: Add 44xx data using common struct clk ARM: omap3: clk: Add 3xxx data using common struct clk ARM: omap2: clk: Add 24xx data using common struct clk ARM: omap: clk: Switch to COMMON clk ARM: omap: clk: Use plat clock.c clock.h only for OMAP1 ARM: omap: hwmod: Cleanup !CONFIG_COMMON_CLK parts ARM: omap4: clk: Cleanup !CONFIG_COMMON_CLK parts ARM: omap3: clk: Cleanup !CONFIG_COMMON_CLK parts ARM: omap2: clk: Cleanup !CONFIG_COMMON_CLK parts ARM: omap4: clk: Delete old OMAP clock data ARM: omap3: clk: Delete old OMAP clock data ARM: omap2: clk: Delete old OMAP clock data arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/Makefile |8 +- 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/cclock2420_data.c| 2284 +++ arch/arm/mach-omap2/cclock2430_data.c| 2408 arch/arm/mach-omap2/cclock3xxx_data.c| 3953 ++ arch/arm/mach-omap2/cclock44xx_data.c| 2602 + arch/arm/mach-omap2/clkt2xxx_apll.c | 36 +- arch/arm/mach-omap2/clkt2xxx_dpll.c | 10 +- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 12 +- arch/arm/mach-omap2/clkt2xxx_osc.c | 14 +- arch/arm/mach-omap2/clkt2xxx_sys.c |8 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 15 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 25 +- arch/arm/mach-omap2/clkt_clksel.c| 200 +- arch/arm/mach-omap2/clkt_dpll.c | 49 +- arch/arm/mach-omap2/clkt_iclk.c | 36 +- arch/arm/mach-omap2/clock.c | 328 +-- arch/arm/mach-omap2/clock.h | 334 ++- arch/arm/mach-omap2/clock2420_data.c | 2009 - arch/arm/mach-omap2/clock2430.c |9 +- arch/arm/mach-omap2/clock2430_data.c | 2108 -- arch/arm/mach-omap2/clock2xxx.c |2 +- arch/arm/mach-omap2/clock2xxx.h | 37 +- arch/arm/mach-omap2/clock34xx.c | 53 +- arch/arm/mach-omap2/clock3517.c | 23 +- arch/arm/mach-omap2/clock36xx.c | 24 +- arch/arm/mach-omap2/clock36xx.h |2 +- arch/arm/mach-omap2/clock3xxx.c | 15 +- arch/arm/mach-omap2/clock3xxx.h |8 +- arch/arm/mach-omap2/clock3xxx_data.c | 3632 --- arch/arm/mach-omap2/clock44xx_data.c | 3466 -- arch/arm/mach-omap2/clock_common_data.c |
[RFC 04/24] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
Moving to COMMON clk 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.
Based on original changes from Mike Turquette.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 12 ++--
arch/arm/plat-omap/omap_device.c |6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7aa73f8..6c7c322 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -559,8 +559,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;
@@ -595,8 +595,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;
@@ -622,8 +622,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 d50cbc6..16bcace 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 07/24] ARM: omap: hwmod: Fix up hwmod based clkdm accesses
hwmod uses deferencing the clk pointer to acccess the clkdm.
With COMMON clk hwoever this will need to be deferenced through
the clk_hw_omap pointer, so do the necessary changes.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 65 --
1 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index ddea015..91d0f19 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -130,7 +130,11 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/io.h
+#ifdef CONFIG_COMMON_CLK
+#include linux/clk-provider.h
+#else
#include linux/clk.h
+#endif
#include linux/delay.h
#include linux/err.h
#include linux/list.h
@@ -497,6 +501,25 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
return 0;
}
+struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
+{
+ struct clk_hw_omap *clk;
+
+ if (oh-clkdm) {
+ return oh-clkdm;
+ } else if (oh-_clk) {
+#ifdef CONFIG_COMMON_CLK
+ clk = to_clk_hw_omap(__clk_get_hw(oh-_clk));
+ return clk-clkdm;
+#else
+ return oh-_clk-clkdm;
+#endif
+ }
+
+ pr_err(%s: %s does not have .clkdm\n, __func__, oh-name);
+ return NULL;
+}
+
/**
* _add_initiator_dep: prevent @oh from smart-idling while @init_oh is active
* @oh: struct omap_hwmod *
@@ -512,13 +535,18 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
*/
static int _add_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod
*init_oh)
{
- if (!oh-_clk)
+ struct clockdomain *clkdm, *init_clkdm;
+
+ clkdm = _get_clkdm(oh);
+ init_clkdm = _get_clkdm(init_oh);
+
+ if (!clkdm || !init_clkdm)
return -EINVAL;
- if (oh-_clk-clkdm oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
+ if (clkdm clkdm-flags CLKDM_NO_AUTODEPS)
return 0;
- return clkdm_add_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
+ return clkdm_add_sleepdep(clkdm, init_clkdm);
}
/**
@@ -536,13 +564,18 @@ static int _add_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh)
*/
static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod
*init_oh)
{
- if (!oh-_clk)
+ struct clockdomain *clkdm, *init_clkdm;
+
+ clkdm = _get_clkdm(oh);
+ init_clkdm = _get_clkdm(init_oh);
+
+ if (!clkdm || !init_clkdm)
return -EINVAL;
- if (oh-_clk-clkdm oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
+ if (clkdm clkdm-flags CLKDM_NO_AUTODEPS)
return 0;
- return clkdm_del_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
+ return clkdm_del_sleepdep(clkdm, init_clkdm);
}
/**
@@ -567,7 +600,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
return -EINVAL;
}
- if (!oh-_clk-clkdm)
+ if (!_get_clkdm(oh))
pr_warning(omap_hwmod: %s: missing clockdomain for %s.\n,
oh-name, oh-main_clk);
@@ -2371,10 +2404,17 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
struct powerdomain *omap_hwmod_get_pwrdm(struct omap_hwmod *oh)
{
struct clk *c;
+ struct clockdomain *clkdm;
+#ifdef CONFIG_COMMON_CLK
+ struct clk_hw_omap *clk;
+#endif
if (!oh)
return NULL;
+ if (oh-clkdm)
+ return oh-clkdm-pwrdm.ptr;
+
if (oh-_clk) {
c = oh-_clk;
} else {
@@ -2383,11 +2423,16 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
c = oh-slaves[oh-_mpu_port_index]-_clk;
}
- if (!c-clkdm)
+#ifdef CONFIG_COMMON_CLK
+ clk = to_clk_hw_omap(__clk_get_hw(c));
+ clkdm = clk-clkdm;
+#else
+ clkdm = c-clkdm;
+#endif
+ if (!clkdm)
return NULL;
- return c-clkdm-pwrdm.ptr;
-
+ return clkdm-pwrdm.ptr;
}
/**
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 03/24] ARM: omap: clk: convert all clk_enable to clk_prepare_enable
This is done in preperation of moving OMAP clock management to using COMMON clk. Based on initial changes from Mike turquette. Signed-off-by: Rajendra Nayak rna...@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| 14 +++--- arch/arm/mach-omap2/omap_phy_internal.c | 12 ++-- arch/arm/mach-omap2/pm24xx.c|4 ++-- arch/arm/mach-omap2/usb-fs.c|4 ++-- arch/arm/plat-omap/counter_32k.c|2 +- 11 files changed, 31 insertions(+), 31 deletions(-) diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index 768ece2..3133ad0 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 0bbbabe..076eeb1 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 1b782ba..adb6690 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -156,7 +156,7 @@ static void __init omap4_ehci_init(void) return; } clk_set_rate(phy_ref_clk, 1920); - 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 db5a88a..2661988 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -335,7 +335,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(); @@ -362,7 +362,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 00d5108..3334224 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -735,7 +735,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
[RFC 06/24] ARM: omap: clk: Remove all direct dereferncing of struct clk
While we work on moving to COMMON clk, 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 similar to the ones that
are defined with COMMON clk.
Signed-off-by: Rajendra Nayak rna...@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 | 41 +++-
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, 123 insertions(+), 71 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,
[RFC 05/24] ARM: omap: clk: Nuke plat clock.c clock.h if CONFIG_COMMON_CLK
Moving to COMMON clk, plat/clock.c and plat/clock.h files will no
longer be used. Move whatever is useful for OMAP2+ for implementing
platform code into mach/clock.h.
plat/clock.c which has most of usecounting/locking infrastructure will
be used only for OMAP1 until that is moved to use COMMON clk.
plat/clock.h will have the OMAP struct clk definition intact which
will also be used only on OMAP1.
A later patch which enables CONFIG_COMMON_CLK on OMAP2+ will get rid
of all OMAP2+ specific contents from plat/clock.h which are now moved
to mach/clock.h
Based on the original changes from Mike Turquette.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.h | 227 +++
arch/arm/mach-omap2/clock3xxx.h |2 +
arch/arm/mach-omap2/omap_hwmod.c|1 +
arch/arm/mach-omap2/pm-debug.c |1 +
arch/arm/plat-omap/clock.c |2 +
arch/arm/plat-omap/include/plat/clock.h |2 +
6 files changed, 235 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index a1bb23a..f18fe80 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -20,6 +20,233 @@
#include plat/clock.h
+#ifdef CONFIG_COMMON_CLK
+
+#include linux/clk-provider.h
+#include linux/list.h
+
+#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
+
+struct clockdomain;
+
+#ifdef CONFIG_ARCH_OMAP2PLUS
+
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X (1 0)
+#define RATE_IN_243X (1 1)
+#define RATE_IN_3430ES1(1 2)/* 3430ES1 rates only */
+#define RATE_IN_3430ES2PLUS(1 3)/* 3430 ES = 2 rates only */
+#define RATE_IN_36XX (1 4)
+#define RATE_IN_4430 (1 5)
+#define RATE_IN_TI816X (1 6)
+#define RATE_IN_4460 (1 7)
+#define RATE_IN_AM33XX (1 8)
+#define RATE_IN_TI814X (1 9)
+
+#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
+#define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
+#define RATE_IN_3XXX (RATE_IN_34XX | RATE_IN_36XX)
+#define RATE_IN_44XX (RATE_IN_4430 | RATE_IN_4460)
+
+/* RATE_IN_3430ES2PLUS_36XX includes 34xx/35xx with ES =2, and all 36xx/37xx
*/
+#define RATE_IN_3430ES2PLUS_36XX (RATE_IN_3430ES2PLUS | RATE_IN_36XX)
+
+/* Platform flags for the clkdev-OMAP integration code */
+#define CK_242X(1 4)
+#define CK_243X(1 5)/* 243x, 253x */
+#define CK_3430ES1 (1 6)/* 34xxES1 only */
+#define CK_3430ES2PLUS (1 7)/* 34xxES2, ES3, non-Sitara 35xx only */
+#define CK_3505(1 8)
+#define CK_3517(1 9)
+#define CK_36XX(1 10) /* 36xx/37xx-specific clocks */
+#define CK_443X(1 11)
+#define CK_TI816X (1 12)
+#define CK_446X(1 13)
+
+#define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
+#define CK_AM35XX (CK_3505 | CK_3517) /* all Sitara AM35xx */
+#define CK_3XXX(CK_34XX | CK_AM35XX | CK_36XX)
+
+/**
+ * struct clksel_rate - register bitfield values corresponding to clk divisors
+ * @val: register bitfield value (shifted to bit 0)
+ * @div: clock divisor corresponding to @val
+ * @flags: (see struct clksel_rate.flags possibilities above)
+ *
+ * @val should match the value of a read from struct clk.clksel_reg
+ * AND'ed with struct clk.clksel_mask, shifted right to bit 0.
+ *
+ * @div is the divisor that should be applied to the parent clock's rate
+ * to produce the current clock's rate.
+ */
+struct clksel_rate {
+ u32 val;
+ u8 div;
+ u8 flags;
+};
+
+/**
+ * struct clksel - available parent clocks, and a pointer to their divisors
+ * @parent: struct clk * to a possible parent clock
+ * @rates: available divisors for this parent clock
+ *
+ * A struct clksel is always associated with one or more struct clks
+ * and one or more struct clksel_rates.
+ */
+struct clksel {
+ struct clk *parent;
+ const struct clksel_rate*rates;
+};
+
+/**
+ * struct dpll_data - DPLL registers and integration data
+ * @mult_div1_reg: register containing the DPLL M and N bitfields
+ * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
+ * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
+ * @clk_bypass: struct clk pointer to the clock's bypass clock input
+ * @clk_ref: struct clk pointer to the clock's reference clock input
+ * @control_reg: register containing the DPLL mode bitfield
+ * @enable_mask: mask of the DPLL mode bitfield in @control_reg
+ * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
+ * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
+ * @max_multiplier: maximum valid non-bypass multiplier value (actual)
+ * @last_rounded_n: cache of the last N result
[RFC 11/24] ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle
Platforms can call omap2_init_clk_hw_omap_clocks() to register a clock
using clk_hw_omap. omap2_clk_enable_autoidle_all() and
omap2_clk_disable_autoidle_all() can then be used to run through
all the clocks which support autoidle to enable/disable them.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.c | 34 ++
arch/arm/mach-omap2/clock.h |3 +++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 6139ab6..4c7fa4b 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -50,6 +50,7 @@ u16 cpu_mask;
static bool clkdm_control = true;
#ifdef CONFIG_COMMON_CLK
+LIST_HEAD(clk_hw_omap_clocks);
/*
* Used for clocks that have the same value as the parent clock,
@@ -343,6 +344,37 @@ static int __init omap_clk_setup(char *str)
}
__setup(mpurate=, omap_clk_setup);
+void omap2_init_clk_hw_omap_clocks(struct clk *clk)
+{
+ struct clk_hw_omap *c;
+
+ if (__clk_get_flags(clk) CLK_IS_BASIC)
+ return;
+
+ c = to_clk_hw_omap(__clk_get_hw(clk));
+ list_add(c-node, clk_hw_omap_clocks);
+}
+
+int omap2_clk_enable_autoidle_all(void)
+{
+ struct clk_hw_omap *c;
+
+ list_for_each_entry(c, clk_hw_omap_clocks, node)
+ if (c-ops c-ops-allow_idle)
+ c-ops-allow_idle(c);
+ return 0;
+}
+
+int omap2_clk_disable_autoidle_all(void)
+{
+ struct clk_hw_omap *c;
+
+ list_for_each_entry(c, clk_hw_omap_clocks, node)
+ if (c-ops c-ops-allow_idle)
+ c-ops-allow_idle(c);
+ return 0;
+}
+
const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
.allow_idle = omap3_dpll_allow_idle,
.deny_idle = omap3_dpll_deny_idle,
@@ -359,6 +391,8 @@ const struct clk_hw_omap_ops clkhwops_wait = {
.find_idlest= omap2_clk_dflt_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};
+late_initcall(omap2_clk_enable_autoidle_all);
+
#else
int omap2_dflt_clk_enable(struct clk *clk)
{
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index f09ca8d..fd73f7a 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -401,6 +401,9 @@ void omap2_clk_dflt_find_companion(struct clk_hw_omap *clk,
void __iomem **other
u8 *other_bit);
void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk, void __iomem
**idlest_reg,
u8 *idlest_bit, u8 *idlest_val);
+void omap2_init_clk_hw_omap_clocks(struct clk *clk);
+int omap2_clk_enable_autoidle_all(void);
+int omap2_clk_disable_autoidle_all(void);
#else
int omap2_dflt_clk_enable(struct clk *clk);
void omap2_dflt_clk_disable(struct clk *clk);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 09/24] ARM: omap3: clk: Convert to common clk
Convert all OMAP3 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 13
arch/arm/mach-omap2/clkt_iclk.c| 15 +
arch/arm/mach-omap2/clock.h| 22 -
arch/arm/mach-omap2/clock34xx.c| 51
arch/arm/mach-omap2/clock3517.c| 31 +--
arch/arm/mach-omap2/clock36xx.c| 25 +--
arch/arm/mach-omap2/clock36xx.h|4 ++
arch/arm/mach-omap2/clock3xxx.c| 10 +-
arch/arm/mach-omap2/clock3xxx.h|7
9 files changed, 168 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 51601db..7e550b1 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -47,8 +47,15 @@
* Program the DPLL M2 divider with the rounded target rate. Returns
* -EINVAL upon error, or 0 upon success.
*/
+#ifdef CONFIG_COMMON_CLK
+int omap3_core_dpll_m2_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+#else
int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)
{
+#endif
u32 new_div = 0;
u32 unlock_dll = 0;
u32 c;
@@ -66,7 +73,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
return -EINVAL;
sdrcrate = __clk_get_rate(sdrc_ick_p);
+#ifdef CONFIG_COMMON_CLK
+ clkrate = __clk_get_rate(hw-clk);
+#else
clkrate = __clk_get_rate(clk);
+#endif
if (rate clkrate)
sdrcrate = ((rate / clkrate) 1);
else
@@ -117,7 +128,9 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
sdrc_cs0-rfr_ctrl, sdrc_cs0-actim_ctrla,
sdrc_cs0-actim_ctrlb, sdrc_cs0-mr,
0, 0, 0, 0);
+#ifndef CONFIG_COMMON_CLK
clk-rate = rate;
+#endif
return 0;
}
diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 7787fbb..b3aa8d3 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -29,7 +29,11 @@
/* Private functions */
/* XXX */
+#ifdef CONFIG_COMMON_CLK
+void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk)
+#else
void omap2_clkt_iclk_allow_idle(struct clk *clk)
+#endif
{
u32 v, r;
@@ -41,7 +45,11 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
}
/* XXX */
+#ifdef CONFIG_COMMON_CLK
+void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk)
+#else
void omap2_clkt_iclk_deny_idle(struct clk *clk)
+#endif
{
u32 v, r;
@@ -52,6 +60,12 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
__raw_writel(v, (__force void __iomem *)r);
}
+#ifdef CONFIG_COMMON_CLK
+const struct clk_hw_omap_ops clkhwops_iclk = {
+ .allow_idle = omap2_clkt_iclk_allow_idle,
+ .deny_idle = omap2_clkt_iclk_deny_idle,
+};
+#else
/* Public data */
const struct clkops clkops_omap2_iclk_dflt_wait = {
@@ -83,4 +97,5 @@ const struct clkops clkops_omap2_mdmclk_dflt_wait = {
.allow_idle = omap2_clkt_iclk_allow_idle,
.deny_idle = omap2_clkt_iclk_deny_idle,
};
+#endif
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 80a3fe2..f09ca8d 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -351,8 +351,13 @@ int omap2_clksel_set_parent(struct clk *clk, struct clk
*new_parent);
#endif
/* clkt_iclk.c public functions */
+#ifdef CONFIG_COMMON_CLK
+extern void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk);
+extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
+#else
extern void omap2_clkt_iclk_allow_idle(struct clk *clk);
extern void omap2_clkt_iclk_deny_idle(struct clk *clk);
+#endif
#ifdef CONFIG_COMMON_CLK
u8 omap2_init_dpll_parent(struct clk_hw *hw);
@@ -428,8 +433,20 @@ extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
extern const struct clk_hw_omap_ops clkhwops_wait;
extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
-#endif
-
+extern const struct clk_hw_omap_ops clkhwops_iclk;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_dss_usbhost_wait;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_dss_usbhost_wait;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait;
+extern const struct
[RFC 12/24] ARM: omap: clk: Define a function to enable clocks at init
Platform code can use omap2_clk_enable_init_clocks() to enable a
list of clocks that are needed to be enabled at init.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock.c | 11 +++
arch/arm/mach-omap2/clock.h |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 4c7fa4b..cdfa9c5 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -375,6 +375,17 @@ int omap2_clk_disable_autoidle_all(void)
return 0;
}
+void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks)
+{
+ struct clk *init_clk;
+ int i;
+
+ for (i = 0; i num_clocks; i++) {
+ init_clk = clk_get(NULL, clk_names[i]);
+ clk_prepare_enable(init_clk);
+ }
+}
+
const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
.allow_idle = omap3_dpll_allow_idle,
.deny_idle = omap3_dpll_deny_idle,
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index fd73f7a..5767751 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -404,6 +404,7 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
void __iomem **idlest_r
void omap2_init_clk_hw_omap_clocks(struct clk *clk);
int omap2_clk_enable_autoidle_all(void);
int omap2_clk_disable_autoidle_all(void);
+void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
#else
int omap2_dflt_clk_enable(struct clk *clk);
void omap2_dflt_clk_disable(struct clk *clk);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 10/24] ARM: omap2: clk: Convert to common clk
Convert all OMAP2 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt2xxx_apll.c | 51 ++
arch/arm/mach-omap2/clkt2xxx_dpll.c | 16 -
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 21 +++
arch/arm/mach-omap2/clkt2xxx_osc.c | 14 +++
arch/arm/mach-omap2/clkt2xxx_sys.c |8 -
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 18 +
arch/arm/mach-omap2/clock2430.c | 11 ++
arch/arm/mach-omap2/clock2xxx.c |1 +
arch/arm/mach-omap2/clock2xxx.h | 30 +++
arch/arm/mach-omap2/pm24xx.c |8
10 files changed, 176 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c
b/arch/arm/mach-omap2/clkt2xxx_apll.c
index c2d1521..a147188 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -43,8 +43,14 @@ void __iomem *cm_idlest_pll;
/* Private functions */
/* Enable an APLL if off */
+#ifdef CONFIG_COMMON_CLK
+static int omap2_clk_apll_enable(struct clk_hw *hw, u32 status_mask)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+#else
static int omap2_clk_apll_enable(struct clk *clk, u32 status_mask)
{
+#endif
u32 cval, apll_mask;
apll_mask = EN_APLL_LOCKED clk-enable_bit;
@@ -59,7 +65,11 @@ 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,
+#ifdef CONFIG_COMMON_CLK
+OMAP24XX_CM_IDLEST_VAL, __clk_get_name(hw-clk));
+#else
OMAP24XX_CM_IDLEST_VAL, __clk_get_name(clk));
+#endif
/*
* REVISIT: Should we return an error code if omap2_wait_clock_ready()
@@ -68,39 +78,69 @@ static int omap2_clk_apll_enable(struct clk *clk, u32
status_mask)
return 0;
}
+#ifdef CONFIG_COMMON_CLK
+int omap2_clk_apll96_enable(struct clk_hw *clk)
+#else
static int omap2_clk_apll96_enable(struct clk *clk)
+#endif
{
return omap2_clk_apll_enable(clk, OMAP24XX_ST_96M_APLL_MASK);
}
+#ifdef CONFIG_COMMON_CLK
+int omap2_clk_apll54_enable(struct clk_hw *clk)
+#else
static int omap2_clk_apll54_enable(struct clk *clk)
+#endif
{
return omap2_clk_apll_enable(clk, OMAP24XX_ST_54M_APLL_MASK);
}
+#ifdef CONFIG_COMMON_CLK
+void _apll96_allow_idle(struct clk_hw_omap *clk)
+#else
static void _apll96_allow_idle(struct clk *clk)
+#endif
{
omap2xxx_cm_set_apll96_auto_low_power_stop();
}
+#ifdef CONFIG_COMMON_CLK
+void _apll96_deny_idle(struct clk_hw_omap *clk)
+#else
static void _apll96_deny_idle(struct clk *clk)
+#endif
{
omap2xxx_cm_set_apll96_disable_autoidle();
}
+#ifdef CONFIG_COMMON_CLK
+void _apll54_allow_idle(struct clk_hw_omap *clk)
+#else
static void _apll54_allow_idle(struct clk *clk)
+#endif
{
omap2xxx_cm_set_apll54_auto_low_power_stop();
}
+#ifdef CONFIG_COMMON_CLK
+void _apll54_deny_idle(struct clk_hw_omap *clk)
+#else
static void _apll54_deny_idle(struct clk *clk)
+#endif
{
omap2xxx_cm_set_apll54_disable_autoidle();
}
/* Stop APLL */
+#ifdef CONFIG_COMMON_CLK
+void omap2_clk_apll_disable(struct clk_hw *hw)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+#else
static void omap2_clk_apll_disable(struct clk *clk)
{
+#endif
u32 cval;
cval = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
@@ -109,7 +149,17 @@ static void omap2_clk_apll_disable(struct clk *clk)
}
/* Public data */
+#ifdef CONFIG_COMMON_CLK
+const struct clk_hw_omap_ops clkhwops_apll54 = {
+ .allow_idle = _apll54_allow_idle,
+ .deny_idle = _apll54_deny_idle,
+};
+const struct clk_hw_omap_ops clkhwops_apll96 = {
+ .allow_idle = _apll96_allow_idle,
+ .deny_idle = _apll96_deny_idle,
+};
+#else
const struct clkops clkops_apll96 = {
.enable = omap2_clk_apll96_enable,
.disable= omap2_clk_apll_disable,
@@ -123,6 +173,7 @@ const struct clkops clkops_apll54 = {
.allow_idle = _apll54_allow_idle,
.deny_idle = _apll54_deny_idle,
};
+#endif
/* Public functions */
diff --git a/arch/arm/mach-omap2/clkt2xxx_dpll.c
b/arch/arm/mach-omap2/clkt2xxx_dpll.c
index 1502a7b..a1f9915 100644
--- a/arch/arm/mach-omap2/clkt2xxx_dpll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_dpll.c
@@ -31,7 +31,11 @@
* REVISIT: DPLL can optionally enter low-power bypass by writing 0x1
* instead. Add some mechanism to optionally enter this mode.
*/
+#ifdef CONFIG_COMMON_CLK
+void _allow_idle(struct clk_hw_omap *clk)
+#else
static void _allow_idle(struct clk *clk)
+#endif
{
if (!clk
[RFC 16/24] ARM: omap: clk: Switch to COMMON clk
Select COMMON_CLK for ARCH_OMAP2 and switch over to using new data files for OMAP2/3/4. The older data files which get removed in subsequent patches. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/Makefile |8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8141b76..b5b7b76 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS_TYPICAL select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 + select COMMON_CLK help Compile a kernel suitable for booting most boards diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 49f92bc..785b861 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -138,14 +138,14 @@ obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o \ clkt2xxx_virt_prcm_set.o \ clkt2xxx_apll.o clkt2xxx_osc.o \ clkt2xxx_dpll.o clkt_iclk.o -obj-$(CONFIG_SOC_OMAP2420) += clock2420_data.o -obj-$(CONFIG_SOC_OMAP2430) += clock2430.o clock2430_data.o +obj-$(CONFIG_SOC_OMAP2420) += cclock2420_data.o +obj-$(CONFIG_SOC_OMAP2430) += clock2430.o cclock2430_data.o obj-$(CONFIG_ARCH_OMAP3) += $(clock-common) clock3xxx.o \ clock34xx.o clkt34xx_dpll3m2.o \ clock3517.o clock36xx.o \ - dpll3xxx.o clock3xxx_data.o \ + dpll3xxx.o cclock3xxx_data.o \ clkt_iclk.o -obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o \ +obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) cclock44xx_data.o \ dpll3xxx.o dpll44xx.o # OMAP2 clock rate set data (old OPP data) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 08/24] ARM: omap4: clk: Convert to common clk
Convert all OMAP4 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.
This converts all apis which will be called directly from COMMON
clk to take a struct clk_hw parameter, and all the internal platform
apis to take a struct clk_hw_omap parameter.
Changes are based off the original patch from Mike Turquette.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt_clksel.c | 144 ++-
arch/arm/mach-omap2/clkt_dpll.c | 54 ++-
arch/arm/mach-omap2/clkt_iclk.c |4 +
arch/arm/mach-omap2/clock.c | 184 +--
arch/arm/mach-omap2/clock.h | 59 +++-
arch/arm/mach-omap2/dpll3xxx.c| 194 -
arch/arm/mach-omap2/dpll44xx.c| 37 +++
7 files changed, 660 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c
b/arch/arm/mach-omap2/clkt_clksel.c
index 1c054ba..c99222a 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -41,7 +41,11 @@
#include linux/kernel.h
#include linux/errno.h
+#ifdef CONFIG_COMMON_CLK
+#include linux/clk-provider.h
+#else
#include linux/clk.h
+#endif
#include linux/io.h
#include linux/bug.h
@@ -60,11 +64,18 @@
* the element associated with the supplied parent clock address.
* Returns a pointer to the struct clksel on success or NULL on error.
*/
+#ifdef CONFIG_COMMON_CLK
+static const struct clksel *_get_clksel_by_parent(struct clk_hw_omap *clk,
+#else
static const struct clksel *_get_clksel_by_parent(struct clk *clk,
+#endif
struct clk *src_clk)
{
const struct clksel *clks;
+ if (!src_clk)
+ return NULL;
+
for (clks = clk-clksel; clks-parent; clks++)
if (clks-parent == src_clk)
break; /* Found the requested parent */
@@ -74,7 +85,11 @@ static const struct clksel *_get_clksel_by_parent(struct clk
*clk,
WARN(1, clock: Could not find parent clock %s in clksel array
of clock %s\n,
__clk_get_name(src_clk),
+#ifdef CONFIG_COMMON_CLK
+ __clk_get_name(clk-hw.clk));
+#else
__clk_get_name(clk));
+#endif
return NULL;
}
@@ -96,6 +111,7 @@ static const struct clksel *_get_clksel_by_parent(struct clk
*clk,
* success (in this latter case, the corresponding register bitfield
* value is passed back in the variable pointed to by @field_val)
*/
+#ifndef CONFIG_COMMON_CLK
static u8 _get_div_and_fieldval(struct clk *src_clk, struct clk *clk,
u32 *field_val)
{
@@ -138,6 +154,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct
clk *clk,
return max_div;
}
+#endif
/**
* _write_clksel_reg() - program a clock's clksel register in hardware
@@ -152,7 +169,11 @@ static u8 _get_div_and_fieldval(struct clk *src_clk,
struct clk *clk,
* take into account any time the hardware might take to switch the
* clock source.
*/
+#ifdef CONFIG_COMMON_CLK
+static void _write_clksel_reg(struct clk_hw_omap *clk, u32 field_val)
+#else
static void _write_clksel_reg(struct clk *clk, u32 field_val)
+#endif
{
u32 v;
@@ -175,13 +196,22 @@ static void _write_clksel_reg(struct clk *clk, u32
field_val)
* before calling. Returns 0 on error or returns the actual integer divisor
* upon success.
*/
+#ifdef CONFIG_COMMON_CLK
+static u32 _clksel_to_divisor(struct clk_hw_omap *clk, u32 field_val)
+#else
static u32 _clksel_to_divisor(struct clk *clk, u32 field_val)
+#endif
{
const struct clksel *clks;
const struct clksel_rate *clkr;
struct clk *parent;
+#ifdef CONFIG_COMMON_CLK
+ parent = __clk_get_parent(clk-hw.clk);
+#else
parent = __clk_get_parent(clk);
+#endif
+
clks = _get_clksel_by_parent(clk, parent);
if (!clks)
return 0;
@@ -198,7 +228,11 @@ static u32 _clksel_to_divisor(struct clk *clk, u32
field_val)
/* This indicates a data error */
WARN(1, clock: Could not find fieldval %d for clock %s parent
%s\n, field_val,
+#ifdef CONFIG_COMMON_CLK
+__clk_get_name(clk-hw.clk),
+#else
__clk_get_name(clk),
+#endif
__clk_get_name(parent));
return 0;
}
@@ -216,7 +250,11 @@ static u32 _clksel_to_divisor(struct clk *clk, u32
field_val)
* register field value _before_ left-shifting (i.e., LSB is at bit
* 0); or returns 0x (~0) upon error.
*/
+#ifdef CONFIG_COMMON_CLK
+static u32 _divisor_to_clksel(struct clk_hw_omap *clk, u32 div)
+#else
static u32 _divisor_to_clksel(struct clk *clk, u32
[RFC 18/24] ARM: omap: hwmod: Cleanup !CONFIG_COMMON_CLK parts
Clean all #ifdef's added as part of fixing the clkdm
accesses from hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e153298..0085353 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -130,11 +130,7 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/io.h
-#ifdef CONFIG_COMMON_CLK
#include linux/clk-provider.h
-#else
-#include linux/clk.h
-#endif
#include linux/delay.h
#include linux/err.h
#include linux/list.h
@@ -507,12 +503,8 @@ struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
if (oh-clkdm) {
return oh-clkdm;
} else if (oh-_clk) {
-#ifdef CONFIG_COMMON_CLK
clk = to_clk_hw_omap(__clk_get_hw(oh-_clk));
return clk-clkdm;
-#else
- return oh-_clk-clkdm;
-#endif
}
pr_err(%s: %s does not have .clkdm\n, __func__, oh-name);
@@ -2404,9 +2396,7 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
{
struct clk *c;
struct clockdomain *clkdm;
-#ifdef CONFIG_COMMON_CLK
struct clk_hw_omap *clk;
-#endif
if (!oh)
return NULL;
@@ -2422,12 +2412,8 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
c = oh-slaves[oh-_mpu_port_index]-_clk;
}
-#ifdef CONFIG_COMMON_CLK
clk = to_clk_hw_omap(__clk_get_hw(c));
clkdm = clk-clkdm;
-#else
- clkdm = c-clkdm;
-#endif
if (!clkdm)
return NULL;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 17/24] ARM: omap: clk: Use plat clock.c clock.h only for OMAP1
Get rid of all OMAP2+ content from plat/clock.h and use it along with plat/clock.c only for OMAP1. Get rid of all '#include plat/clock.h' from OMAP2+ files. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/clkt2xxx_apll.c |1 - arch/arm/mach-omap2/clkt2xxx_dpll.c |2 - arch/arm/mach-omap2/clkt2xxx_dpllcore.c |1 - arch/arm/mach-omap2/clkt2xxx_osc.c |2 - arch/arm/mach-omap2/clkt2xxx_sys.c |2 - arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |1 - arch/arm/mach-omap2/clkt34xx_dpll3m2.c |1 - arch/arm/mach-omap2/clkt_clksel.c|2 - arch/arm/mach-omap2/clkt_dpll.c |1 - arch/arm/mach-omap2/clkt_iclk.c |1 - arch/arm/mach-omap2/clock.c |1 - arch/arm/mach-omap2/clock.h |6 - arch/arm/mach-omap2/clock2430.c |1 - arch/arm/mach-omap2/clock2xxx.c |1 - arch/arm/mach-omap2/clock34xx.c |2 - arch/arm/mach-omap2/clock3517.c |2 - arch/arm/mach-omap2/clock36xx.c |2 - arch/arm/mach-omap2/clock3xxx.c |1 - arch/arm/mach-omap2/clockdomain.c|1 - arch/arm/mach-omap2/clockdomain.h|1 - arch/arm/mach-omap2/common.c |1 - arch/arm/mach-omap2/dpll3xxx.c |1 - arch/arm/mach-omap2/dpll44xx.c |1 - arch/arm/mach-omap2/omap_hwmod.c |1 - arch/arm/mach-omap2/pm-debug.c |1 - arch/arm/mach-omap2/pm24xx.c |1 - arch/arm/mach-omap2/sdram-nokia.c|1 - arch/arm/mach-omap2/sdrc.c |1 - arch/arm/mach-omap2/sdrc2xxx.c |1 - arch/arm/plat-omap/Makefile |3 +- arch/arm/plat-omap/clock.c |2 - arch/arm/plat-omap/counter_32k.c |2 - arch/arm/plat-omap/include/plat/clock.h | 140 -- drivers/spi/spi-omap2-mcspi.c|1 - 34 files changed, 2 insertions(+), 187 deletions(-) diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c b/arch/arm/mach-omap2/clkt2xxx_apll.c index a147188..882eab9 100644 --- a/arch/arm/mach-omap2/clkt2xxx_apll.c +++ b/arch/arm/mach-omap2/clkt2xxx_apll.c @@ -21,7 +21,6 @@ #include linux/clk.h #include linux/io.h -#include plat/clock.h #include plat/prcm.h #include clock.h diff --git a/arch/arm/mach-omap2/clkt2xxx_dpll.c b/arch/arm/mach-omap2/clkt2xxx_dpll.c index a1f9915..4bc699c 100644 --- a/arch/arm/mach-omap2/clkt2xxx_dpll.c +++ b/arch/arm/mach-omap2/clkt2xxx_dpll.c @@ -14,8 +14,6 @@ #include linux/clk.h #include linux/io.h -#include plat/clock.h - #include clock.h #include cm2xxx_3xxx.h #include cm-regbits-24xx.h diff --git a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c index d5e9c94..fd7b9ab 100644 --- a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c +++ b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c @@ -25,7 +25,6 @@ #include linux/clk.h #include linux/io.h -#include plat/clock.h #include plat/sram.h #include plat/sdrc.h diff --git a/arch/arm/mach-omap2/clkt2xxx_osc.c b/arch/arm/mach-omap2/clkt2xxx_osc.c index 3b1d13f..52a4508 100644 --- a/arch/arm/mach-omap2/clkt2xxx_osc.c +++ b/arch/arm/mach-omap2/clkt2xxx_osc.c @@ -23,8 +23,6 @@ #include linux/clk.h #include linux/io.h -#include plat/clock.h - #include clock.h #include clock2xxx.h #include prm2xxx_3xxx.h diff --git a/arch/arm/mach-omap2/clkt2xxx_sys.c b/arch/arm/mach-omap2/clkt2xxx_sys.c index 12164a6..d68b3bc 100644 --- a/arch/arm/mach-omap2/clkt2xxx_sys.c +++ b/arch/arm/mach-omap2/clkt2xxx_sys.c @@ -22,8 +22,6 @@ #include linux/clk.h #include linux/io.h -#include plat/clock.h - #include clock.h #include clock2xxx.h #include prm2xxx_3xxx.h diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c index a0b2b28..eb7f553 100644 --- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c +++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c @@ -34,7 +34,6 @@ #include linux/slab.h #include plat/cpu.h -#include plat/clock.h #include plat/sram.h #include plat/sdrc.h diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c index 7e550b1..74cc4ed 100644 --- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c +++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c @@ -21,7 +21,6 @@ #include linux/clk.h #include linux/io.h -#include plat/clock.h #include plat/sram.h #include plat/sdrc.h diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c index c99222a..396f7fb 100644 --- a/arch/arm/mach-omap2/clkt_clksel.c +++ b/arch/arm/mach-omap2/clkt_clksel.c @@ -49,8 +49,6 @@ #include linux/io.h #include linux/bug.h -#include plat/clock.h - #include clock.h /* Private functions */ diff --git a/arch/arm/mach-omap2/clkt_dpll.c
[RFC 20/24] ARM: omap3: clk: Cleanup !CONFIG_COMMON_CLK parts
Clean all #ifdef's added to OMAP3 clock code to make it COMMON clk
ready, now that CONFIG_COMMON_CLK is enabled.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 13 --
arch/arm/mach-omap2/clock.h| 16 ---
arch/arm/mach-omap2/clock34xx.c| 68 +---
arch/arm/mach-omap2/clock3517.c| 34 +---
arch/arm/mach-omap2/clock36xx.c| 19 -
arch/arm/mach-omap2/clock36xx.h|4 --
arch/arm/mach-omap2/clock3xxx.c|8
arch/arm/mach-omap2/clock3xxx.h|5 --
8 files changed, 3 insertions(+), 164 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 74cc4ed..df266c7 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -46,15 +46,10 @@
* Program the DPLL M2 divider with the rounded target rate. Returns
* -EINVAL upon error, or 0 upon success.
*/
-#ifdef CONFIG_COMMON_CLK
int omap3_core_dpll_m2_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
-#else
-int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate)
-{
-#endif
u32 new_div = 0;
u32 unlock_dll = 0;
u32 c;
@@ -72,11 +67,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
return -EINVAL;
sdrcrate = __clk_get_rate(sdrc_ick_p);
-#ifdef CONFIG_COMMON_CLK
clkrate = __clk_get_rate(hw-clk);
-#else
- clkrate = __clk_get_rate(clk);
-#endif
if (rate clkrate)
sdrcrate = ((rate / clkrate) 1);
else
@@ -127,10 +118,6 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
sdrc_cs0-rfr_ctrl, sdrc_cs0-actim_ctrla,
sdrc_cs0-actim_ctrlb, sdrc_cs0-mr,
0, 0, 0, 0);
-#ifndef CONFIG_COMMON_CLK
- clk-rate = rate;
-#endif
-
return 0;
}
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b2e73aa..1bd4505 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -330,13 +330,8 @@ int omap2_clksel_set_rate(struct clk_hw *hw, unsigned long
rate,
int omap2_clksel_set_parent(struct clk_hw *hw, u8 field_val);
/* clkt_iclk.c public functions */
-#ifdef CONFIG_COMMON_CLK
extern void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk);
extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
-#else
-extern void omap2_clkt_iclk_allow_idle(struct clk *clk);
-extern void omap2_clkt_iclk_deny_idle(struct clk *clk);
-#endif
u8 omap2_init_dpll_parent(struct clk_hw *hw);
unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk);
@@ -398,7 +393,6 @@ extern const struct clksel_rate gfx_l3_rates[];
extern const struct clksel_rate dsp_ick_rates[];
extern struct clk dummy_ck;
-#ifdef CONFIG_COMMON_CLK
extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
extern const struct clk_hw_omap_ops clkhwops_wait;
@@ -416,15 +410,5 @@ extern const struct clk_hw_omap_ops clkhwops_apll54;
extern const struct clk_hw_omap_ops clkhwops_apll96;
extern const struct clk_hw_omap_ops clkhwops_omap2xxx_dpll;
extern const struct clk_hw_omap_ops clkhwops_omap2430_i2chs_wait;
-#else
-extern const struct clkops clkops_omap2_iclk_dflt_wait;
-extern const struct clkops clkops_omap2_iclk_dflt;
-extern const struct clkops clkops_omap2_iclk_idle_only;
-extern const struct clkops clkops_omap2_mdmclk_dflt_wait;
-extern const struct clkops clkops_omap2xxx_dpll_ops;
-extern const struct clkops clkops_omap3_noncore_dpll_ops;
-extern const struct clkops clkops_omap3_core_dpll_ops;
-extern const struct clkops clkops_omap4_dpllmx_ops;
-#endif /* CONFIG_COMMON_CLK */
#endif
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 16da66e..4f6700d 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -37,11 +37,7 @@
* from the CM_{I,F}CLKEN bit. Pass back the correct info via
* @idlest_reg and @idlest_bit. No return value.
*/
-#ifdef CONFIG_COMMON_CLK
static void omap3430es2_clk_ssi_find_idlest(struct clk_hw_omap *clk,
-#else
-static void omap3430es2_clk_ssi_find_idlest(struct clk *clk,
-#endif
void __iomem **idlest_reg,
u8 *idlest_bit,
u8 *idlest_val)
@@ -53,7 +49,6 @@ static void omap3430es2_clk_ssi_find_idlest(struct clk *clk,
*idlest_bit = OMAP3430ES2_ST_SSI_IDLE_SHIFT;
*idlest_val = OMAP34XX_CM_IDLEST_VAL;
}
-#ifdef CONFIG_COMMON_CLK
const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait = {
.find_idlest=
[RFC 21/24] ARM: omap2: clk: Cleanup !CONFIG_COMMON_CLK parts
Clean all #ifdef's added to OMAP2 clock code to make it COMMON clk
ready, now that CONFIG_COMMON_CLK is enabled.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt2xxx_apll.c | 54 --
arch/arm/mach-omap2/clkt2xxx_dpll.c | 16
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 18 -
arch/arm/mach-omap2/clkt2xxx_osc.c | 20 -
arch/arm/mach-omap2/clkt2xxx_sys.c |8
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 16
arch/arm/mach-omap2/clock2430.c | 13 --
arch/arm/mach-omap2/clock2xxx.h | 19 -
arch/arm/mach-omap2/pm24xx.c |8
9 files changed, 0 insertions(+), 172 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c
b/arch/arm/mach-omap2/clkt2xxx_apll.c
index 882eab9..32cff88 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -42,14 +42,9 @@ void __iomem *cm_idlest_pll;
/* Private functions */
/* Enable an APLL if off */
-#ifdef CONFIG_COMMON_CLK
static int omap2_clk_apll_enable(struct clk_hw *hw, u32 status_mask)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
-#else
-static int omap2_clk_apll_enable(struct clk *clk, u32 status_mask)
-{
-#endif
u32 cval, apll_mask;
apll_mask = EN_APLL_LOCKED clk-enable_bit;
@@ -64,11 +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,
-#ifdef CONFIG_COMMON_CLK
OMAP24XX_CM_IDLEST_VAL, __clk_get_name(hw-clk));
-#else
-OMAP24XX_CM_IDLEST_VAL, __clk_get_name(clk));
-#endif
/*
* REVISIT: Should we return an error code if omap2_wait_clock_ready()
@@ -77,69 +68,40 @@ static int omap2_clk_apll_enable(struct clk *clk, u32
status_mask)
return 0;
}
-#ifdef CONFIG_COMMON_CLK
int omap2_clk_apll96_enable(struct clk_hw *clk)
-#else
-static int omap2_clk_apll96_enable(struct clk *clk)
-#endif
{
return omap2_clk_apll_enable(clk, OMAP24XX_ST_96M_APLL_MASK);
}
-#ifdef CONFIG_COMMON_CLK
int omap2_clk_apll54_enable(struct clk_hw *clk)
-#else
-static int omap2_clk_apll54_enable(struct clk *clk)
-#endif
{
return omap2_clk_apll_enable(clk, OMAP24XX_ST_54M_APLL_MASK);
}
-#ifdef CONFIG_COMMON_CLK
void _apll96_allow_idle(struct clk_hw_omap *clk)
-#else
-static void _apll96_allow_idle(struct clk *clk)
-#endif
{
omap2xxx_cm_set_apll96_auto_low_power_stop();
}
-#ifdef CONFIG_COMMON_CLK
void _apll96_deny_idle(struct clk_hw_omap *clk)
-#else
-static void _apll96_deny_idle(struct clk *clk)
-#endif
{
omap2xxx_cm_set_apll96_disable_autoidle();
}
-#ifdef CONFIG_COMMON_CLK
void _apll54_allow_idle(struct clk_hw_omap *clk)
-#else
-static void _apll54_allow_idle(struct clk *clk)
-#endif
{
omap2xxx_cm_set_apll54_auto_low_power_stop();
}
-#ifdef CONFIG_COMMON_CLK
void _apll54_deny_idle(struct clk_hw_omap *clk)
-#else
-static void _apll54_deny_idle(struct clk *clk)
-#endif
{
omap2xxx_cm_set_apll54_disable_autoidle();
}
/* Stop APLL */
-#ifdef CONFIG_COMMON_CLK
void omap2_clk_apll_disable(struct clk_hw *hw)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
-#else
-static void omap2_clk_apll_disable(struct clk *clk)
-{
-#endif
u32 cval;
cval = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
@@ -148,7 +110,6 @@ static void omap2_clk_apll_disable(struct clk *clk)
}
/* Public data */
-#ifdef CONFIG_COMMON_CLK
const struct clk_hw_omap_ops clkhwops_apll54 = {
.allow_idle = _apll54_allow_idle,
.deny_idle = _apll54_deny_idle,
@@ -158,21 +119,6 @@ const struct clk_hw_omap_ops clkhwops_apll96 = {
.allow_idle = _apll96_allow_idle,
.deny_idle = _apll96_deny_idle,
};
-#else
-const struct clkops clkops_apll96 = {
- .enable = omap2_clk_apll96_enable,
- .disable= omap2_clk_apll_disable,
- .allow_idle = _apll96_allow_idle,
- .deny_idle = _apll96_deny_idle,
-};
-
-const struct clkops clkops_apll54 = {
- .enable = omap2_clk_apll54_enable,
- .disable= omap2_clk_apll_disable,
- .allow_idle = _apll54_allow_idle,
- .deny_idle = _apll54_deny_idle,
-};
-#endif
/* Public functions */
diff --git a/arch/arm/mach-omap2/clkt2xxx_dpll.c
b/arch/arm/mach-omap2/clkt2xxx_dpll.c
index 4bc699c..9fcde14 100644
--- a/arch/arm/mach-omap2/clkt2xxx_dpll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_dpll.c
@@ -29,11 +29,7 @@
* REVISIT: DPLL can optionally enter low-power bypass by writing 0x1
* instead. Add some mechanism to optionally enter this mode.
*/
-#ifdef CONFIG_COMMON_CLK
void _allow_idle(struct clk_hw_omap *clk)
-#else
-static void _allow_idle(struct clk *clk)
-#endif
{
if (!clk
[RFC 19/24] ARM: omap4: clk: Cleanup !CONFIG_COMMON_CLK parts
Clean all #ifdef's added to OMAP4 clock code to make it COMMON clk
ready, now that CONFIG_COMMON_CLK is enabled.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clkt_clksel.c | 204 -
arch/arm/mach-omap2/clkt_dpll.c | 50 -
arch/arm/mach-omap2/clkt_iclk.c | 46 -
arch/arm/mach-omap2/clock.c | 301 ---
arch/arm/mach-omap2/clock.h | 45 -
arch/arm/mach-omap2/clock_common_data.c |7 +-
arch/arm/mach-omap2/dpll3xxx.c | 198
arch/arm/mach-omap2/dpll44xx.c | 33
8 files changed, 1 insertions(+), 883 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c
b/arch/arm/mach-omap2/clkt_clksel.c
index 396f7fb..8dd87e2 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -41,11 +41,7 @@
#include linux/kernel.h
#include linux/errno.h
-#ifdef CONFIG_COMMON_CLK
#include linux/clk-provider.h
-#else
-#include linux/clk.h
-#endif
#include linux/io.h
#include linux/bug.h
@@ -62,11 +58,7 @@
* the element associated with the supplied parent clock address.
* Returns a pointer to the struct clksel on success or NULL on error.
*/
-#ifdef CONFIG_COMMON_CLK
static const struct clksel *_get_clksel_by_parent(struct clk_hw_omap *clk,
-#else
-static const struct clksel *_get_clksel_by_parent(struct clk *clk,
-#endif
struct clk *src_clk)
{
const struct clksel *clks;
@@ -83,11 +75,7 @@ static const struct clksel *_get_clksel_by_parent(struct clk
*clk,
WARN(1, clock: Could not find parent clock %s in clksel array
of clock %s\n,
__clk_get_name(src_clk),
-#ifdef CONFIG_COMMON_CLK
__clk_get_name(clk-hw.clk));
-#else
- __clk_get_name(clk));
-#endif
return NULL;
}
@@ -95,66 +83,6 @@ static const struct clksel *_get_clksel_by_parent(struct clk
*clk,
}
/**
- * _get_div_and_fieldval() - find the new clksel divisor and field value to use
- * @src_clk: planned new parent struct clk *
- * @clk: struct clk * that is being reparented
- * @field_val: pointer to a u32 to contain the register data for the divisor
- *
- * Given an intended new parent struct clk * @src_clk, and the struct
- * clk * @clk to the clock that is being reparented, find the
- * appropriate rate divisor for the new clock (returned as the return
- * value), and the corresponding register bitfield data to program to
- * reach that divisor (returned in the u32 pointed to by @field_val).
- * Returns 0 on error, or returns the newly-selected divisor upon
- * success (in this latter case, the corresponding register bitfield
- * value is passed back in the variable pointed to by @field_val)
- */
-#ifndef CONFIG_COMMON_CLK
-static u8 _get_div_and_fieldval(struct clk *src_clk, struct clk *clk,
- u32 *field_val)
-{
- const struct clksel *clks;
- const struct clksel_rate *clkr, *max_clkr = NULL;
- u8 max_div = 0;
-
- clks = _get_clksel_by_parent(clk, src_clk);
- if (!clks)
- return 0;
-
- /*
-* Find the highest divisor (e.g., the one resulting in the
-* lowest rate) to use as the default. This should avoid
-* clock rates that are too high for the device. XXX A better
-* solution here would be to try to determine if there is a
-* divisor matching the original clock rate before the parent
-* switch, and if it cannot be found, to fall back to the
-* highest divisor.
-*/
- for (clkr = clks-rates; clkr-div; clkr++) {
- if (!(clkr-flags cpu_mask))
- continue;
-
- if (clkr-div max_div) {
- max_div = clkr-div;
- max_clkr = clkr;
- }
- }
-
- 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_get_name(clk),
-__clk_get_name(__clk_get_parent(src_clk)));
- return 0;
- }
-
- *field_val = max_clkr-val;
-
- return max_div;
-}
-#endif
-
-/**
* _write_clksel_reg() - program a clock's clksel register in hardware
* @clk: struct clk * to program
* @v: clksel bitfield value to program (with LSB at bit 0)
@@ -167,11 +95,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct
clk *clk,
* take into account any time the hardware might take to switch the
* clock source.
*/
-#ifdef CONFIG_COMMON_CLK
static void _write_clksel_reg(struct clk_hw_omap *clk, u32 field_val)
-#else
-static void _write_clksel_reg(struct clk *clk, u32 field_val)
-#endif
{
u32 v;
@@ -194,21 +118,13 @@ static void
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgren t...@atomide.com wrote: * Cousson, Benoit b-cous...@ti.com [120529 06:29]: On 5/28/2012 1:35 PM, Eduardo Valentin wrote: Mmm, we can have up to 4 control module instances in OMAP4. Well, I'm not sure it worth considering them as separate devices. Is that your plan as well? At least for now I was focusing on the ctrl_module_core ... OK, that's a good start already :-) But since they all have different base address, it will be trick to handle them with only a single entry. Indeed. We can always add the support latter on. I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set? We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning. These should be separate driver instances for the control modules. And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs. Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver. We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. This sounds a good idea. With this we may not even need a core control module drivers if all the individual drivers take care of the registers they care. Mapping shouldn't be a problem as you mentioned. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
On 6/1/2012 2:30 PM, Shilimkar, Santosh wrote: On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgrent...@atomide.com wrote: * Cousson, Benoitb-cous...@ti.com [120529 06:29]: On 5/28/2012 1:35 PM, Eduardo Valentin wrote: Mmm, we can have up to 4 control module instances in OMAP4. Well, I'm not sure it worth considering them as separate devices. Is that your plan as well? At least for now I was focusing on the ctrl_module_core ... OK, that's a good start already :-) But since they all have different base address, it will be trick to handle them with only a single entry. Indeed. We can always add the support latter on. I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set? We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning. These should be separate driver instances for the control modules. And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs. Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver. We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. This sounds a good idea. With this we may not even need a core control module drivers if all the individual drivers take care of the registers they care. Mapping shouldn't be a problem as you mentioned. We should keep the MFD for PM / OCP single port correctness. Other than that it will be mostly useless, indeed. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
Hi Benoit, On Wed, May 30, 2012 at 8:53 PM, Cousson, Benoit b-cous...@ti.com wrote: On 5/30/2012 4:51 PM, Shilimkar, Santosh wrote: On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham Ikis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? I have a series that will remove all these clock nodes. I should be able to post that soon. Potentially at that time, Kishon might be able to drop that patch. Will you be sending a patch for *[RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp* also or I have to keep that as part of my series? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
* Tony Lindgren t...@atomide.com [120601 04:43]:
* Eduardo Valentin eduardo.valen...@ti.com [120525 01:31]:
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret;
+
+ if (on) {
+ ret = omap_control_readl(dev, CONTROL_DEV_CONF, val);
+ if (!ret (val PHY_PD)) {
+ ret = omap_control_writel(dev, ~PHY_PD,
+ CONTROL_DEV_CONF);
+ /* XXX: add proper documentation for this delay */
+ mdelay(200);
+ }
+ } else {
+ ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
I'm not quite convinced that we should export omap_control_read/write
to drivers. If there's a clear register area this USB phy driver can
manage, then ioremaping it separately makes sense. If it's just one
register, then exporting something like omap_control_usb_phy_set()
might be better for ensuring that drivers don't mess up things for
other drivers.
After chatting with Benoit a bit we came to the conclusion that the
clock and powerdomain state needs to be managed for the children by
the SCM core driver so the children can't be completely independent.
But rather than exporting omap_control_read/write, maybe you can
register the usb/bandgap whatever children with SCM core driver,
then have the runtime PM calls from children be passthrough calls
to the parent?
Maybe Kevin has some better ideas here?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
On 6/1/2012 2:52 PM, ABRAHAM, KISHON VIJAY wrote: Hi Benoit, On Wed, May 30, 2012 at 8:53 PM, Cousson, Benoitb-cous...@ti.com wrote: On 5/30/2012 4:51 PM, Shilimkar, Santosh wrote: On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham Ikis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? I have a series that will remove all these clock nodes. I should be able to post that soon. Potentially at that time, Kishon might be able to drop that patch. Will you be sending a patch for *[RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp* also or I have to keep that as part of my series? Good point. In fact, I'm fixing both at the same time to avoid any bisect issue. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] Move OMAP2+ over to use COMMON clock
On Fri, 1 Jun 2012, Rajendra Nayak wrote: This RFC series is based of Mikes' latest clk-next. I will rebase it once 3.5-rc1 is out and post with more testing thats in progress. Meanwhile, the RFC is for me to get some early feedback on the patches. Please describe further what's been tested with this series, and what hasn't been. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
Hi, Tony. On 06/01/2012 03:29 PM, Tony Lindgren wrote: * Cousson, Benoit b-cous...@ti.com [120529 06:29]: On 5/28/2012 1:35 PM, Eduardo Valentin wrote: Mmm, we can have up to 4 control module instances in OMAP4. Well, I'm not sure it worth considering them as separate devices. Is that your plan as well? At least for now I was focusing on the ctrl_module_core ... OK, that's a good start already :-) But since they all have different base address, it will be trick to handle them with only a single entry. Indeed. We can always add the support latter on. I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set? We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning. These should be separate driver instances for the control modules. And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs. Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver. We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c: ... .virtual= L4_44XX_VIRT, .pfn= __phys_to_pfn(L4_44XX_PHYS), .length= L4_44XX_SIZE, .type= MT_DEVICE, ... So ioremap() always returns same virtual address (0xfc002000). BR, Konstantin Baydarov. Regards, Tony ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
Igor Grinberg grinb...@compulab.co.il writes:
Hi Kevin, Nishanth,
On 06/01/12 02:15, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not
present)
makes the logic:
for (i = 0; i opp_def_size; i++) {
snip
if (!oh || !oh-od) {
snip
continue;
}
snip
opp_def++;
}
In short, the moment we hit a Bad OPP, we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)
Cc: Kevin Hilman khil...@ti.com
Cc: Steve Sakoman st...@sakoman.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
Good catch.
Queuing for my next set of PM fixes for v3.5-rc (branch: for_3.5/fixes/pm-2)
I think this should also apply for stable, right?
If it should, can you please add a
Cc: sta...@vger.kernel.org
Yes, added.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/3] omap3 and omap4: add device tree support for wdt
On 05/31/2012 11:44 PM, jgq...@gmail.com wrote: From: Xiao Jiang jgq...@gmail.com Changes compared to previous version: - created document for omap wdt - some modifications per the comments from Benoit and Jon This series is based on latest Linus'tree, and also can be applied to dt branch of linux-omap tree. Tested with omap4430 blaze board and am37xx board. Xiao Jiang (3): arm/dts: add wdt node for omap3 and omap4 OMAP: avoid build wdt platform device if with dt support watchdog: omap_wdt: add device tree support .../devicetree/bindings/watchdog/omap-wdt.txt | 14 ++ arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |2 +- drivers/watchdog/omap_wdt.c|7 +++ 5 files changed, 32 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/omap-wdt.txt Thanks! Looks good to me. Reviewed-by: Jon Hunter jon-hun...@ti.com Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Tony Lindgren t...@atomide.com writes:
* Tony Lindgren t...@atomide.com [120601 04:43]:
* Eduardo Valentin eduardo.valen...@ti.com [120525 01:31]:
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret;
+
+ if (on) {
+ ret = omap_control_readl(dev, CONTROL_DEV_CONF, val);
+ if (!ret (val PHY_PD)) {
+ ret = omap_control_writel(dev, ~PHY_PD,
+CONTROL_DEV_CONF);
+ /* XXX: add proper documentation for this delay */
+ mdelay(200);
+ }
+ } else {
+ ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
I'm not quite convinced that we should export omap_control_read/write
to drivers. If there's a clear register area this USB phy driver can
manage, then ioremaping it separately makes sense. If it's just one
register, then exporting something like omap_control_usb_phy_set()
might be better for ensuring that drivers don't mess up things for
other drivers.
After chatting with Benoit a bit we came to the conclusion that the
clock and powerdomain state needs to be managed for the children by
the SCM core driver so the children can't be completely independent.
But rather than exporting omap_control_read/write, maybe you can
register the usb/bandgap whatever children with SCM core driver,
then have the runtime PM calls from children be passthrough calls
to the parent?
Maybe Kevin has some better ideas here?
Handling this with parent/child relationships is the way to go for
runtime PM.
In MFD, are all sub-devices always children of the core device in the
LDM? If so, it seems relatively easy to handle. If the parent/child
relationships are modeled correctly in the LDM, then the children do not
have to know anything about their parent, the runtime PM core will handle
this (parent will not be runtime suspended until all the children are.)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120601 06:44]: On 06/01/2012 03:29 PM, Tony Lindgren wrote: We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c: ... .virtual= L4_44XX_VIRT, .pfn= __phys_to_pfn(L4_44XX_PHYS), .length= L4_44XX_SIZE, .type= MT_DEVICE, ... So ioremap() always returns same virtual address (0xfc002000). Hmm I guess you mean L4_44XX_VIRT + offset. Otherwise drivers would not work at all.. Or else I don't follow you. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
* Kevin Hilman khil...@ti.com [120601 07:11]:
Tony Lindgren t...@atomide.com writes:
* Tony Lindgren t...@atomide.com [120601 04:43]:
* Eduardo Valentin eduardo.valen...@ti.com [120525 01:31]:
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+u32 val;
+int ret;
+
+if (on) {
+ret = omap_control_readl(dev, CONTROL_DEV_CONF, val);
+if (!ret (val PHY_PD)) {
+ret = omap_control_writel(dev, ~PHY_PD,
+ CONTROL_DEV_CONF);
+/* XXX: add proper documentation for this delay
*/
+mdelay(200);
+}
+} else {
+ret = omap_control_writel(dev, PHY_PD,
CONTROL_DEV_CONF);
+}
+
+return ret;
+}
+EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
I'm not quite convinced that we should export omap_control_read/write
to drivers. If there's a clear register area this USB phy driver can
manage, then ioremaping it separately makes sense. If it's just one
register, then exporting something like omap_control_usb_phy_set()
might be better for ensuring that drivers don't mess up things for
other drivers.
After chatting with Benoit a bit we came to the conclusion that the
clock and powerdomain state needs to be managed for the children by
the SCM core driver so the children can't be completely independent.
But rather than exporting omap_control_read/write, maybe you can
register the usb/bandgap whatever children with SCM core driver,
then have the runtime PM calls from children be passthrough calls
to the parent?
Maybe Kevin has some better ideas here?
Handling this with parent/child relationships is the way to go for
runtime PM.
In MFD, are all sub-devices always children of the core device in the
LDM? If so, it seems relatively easy to handle. If the parent/child
relationships are modeled correctly in the LDM, then the children do not
have to know anything about their parent, the runtime PM core will handle
this (parent will not be runtime suspended until all the children are.)
OK, so the parent-child relationship is there for DT case, but how do
we set it for non-DT case? Call something like this from children:
omap_scm_register(dev, OMAP_SCM_USB_PHY) that then does device_move?
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
On 06/01/2012 06:13 PM, Tony Lindgren wrote: * Konstantin Baydarov kbaida...@dev.rtsoft.ru [120601 06:44]: On 06/01/2012 03:29 PM, Tony Lindgren wrote: We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c: ... .virtual= L4_44XX_VIRT, .pfn= __phys_to_pfn(L4_44XX_PHYS), .length= L4_44XX_SIZE, .type= MT_DEVICE, ... So ioremap() always returns same virtual address (0xfc002000). Hmm I guess you mean L4_44XX_VIRT + offset. Otherwise drivers would not work at all.. Or else I don't follow you. Right. I mean when 0x4A00 2000(scm base) is remapped in scm driver, ioremap() always returns same virtual address (0xfc002000). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
On 05/31/2012 07:27 PM, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
Hi Kevin,
On 05/31/2012 05:36 PM, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
Hi Kevin,
On 05/31/2012 03:42 PM, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
Hi Kevin, Will,
On 05/30/2012 08:29 PM, Will Deacon wrote:
Hi Kevin,
On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote:
Basically, I don't like the result when we have to hack around missing
runtime PM support for a driver, so IMO, the driver should be updated.
IOW, it looks to me like the armpmu driver should grow runtime PM
support. The current armpmu_release|reserve should probably be
replaced
with runtime PM get/put, and the functionality in those functions would
be the runtime PM callbacks instead.
Will, any objections to armpmu growing runtime PM support?
My plan for the armpmu reservation is to kill the global reservation
scheme
that we currently have and push those function pointers into the
arm_pmu,
so that fits with what you'd like.
The only concern I have is that we need the mutual exclusion even when
we
don't have support for runtime PM. If we can solve that then I'm fine
with
the approach.
To add a bit more food for thought, I had implemented a quick patch to
add runtime PM support for PMU. You will notice that I have been
conservative on where I have placed the pm_runtime_get/put calls,
because I am not too familiar with the PMU driver to know exactly
where we need to maintain the PMU context. So right now these are just
around the reserve_hardware/release_hardware calls. This works on OMAP
for some quick testing. However, I would need to make sure this does
not break compilation without runtime PM enabled.
Let me know your thoughts.
That looks good, but I'm curious what would be done in the new
plat-runtime_* hooks. Maybe the irq enable/disable stuff in the pmu
driver needs to be moved into the runtime PM hooks?
For omap4, the plat-runtime_* hooks look like ...
+static int omap4_pmu_runtime_resume(struct device *dev)
+{
+ /* configure CTI0 for PMU IRQ routing */
+ cti_unlock(omap4_cti[0]);
+ cti_map_trigger(omap4_cti[0], 1, 6, 2);
+ cti_enable(omap4_cti[0]);
+
+ /* configure CTI1 for PMU IRQ routing */
+ cti_unlock(omap4_cti[1]);
+ cti_map_trigger(omap4_cti[1], 1, 6, 3);
+ cti_enable(omap4_cti[1]);
+
+ return 0;
+}
+
+static int omap4_pmu_runtime_suspend(struct device *dev)
+{
+ cti_disable(omap4_cti[0]);
+ cti_disable(omap4_cti[1]);
+
+ return 0;
+}
This is what I have implemented so far and currently testing. So really
just using the hooks to configure the cross triggering interface.
Is this what you were thinking?
Basically, yes.
But since I haven't studied the PMU driver closely, I have some dumb
questions. My concern is that these look bsically like the
plat-irq_[enable|disable] hooks, so I guess the root of my question is
do we need both the irq enable/disable and runtime suspend/resume hooks
in plat? or can we get by with one set.
No you are right. The way it is now we could get by with just the one of
hooks. However, the main reason I added the new hooks would be if there
are other places we can call the pm_runtime_* functions. I am not too
familiar with the flow in which the functions are called in the PMU
driver and so this was a simple attempt to push the PM runtime framework
in the PMU driver.
Hmmm ... however, now looking at the history behind the plat-irq_*
hooks, I see that Ming specifically added these for omap4 [1]. I was
under the impression other architectures may be using this. I guess not.
So if it is preferred we could do-away with the plat-irq_* and replace
with the plat-runtime_*.
Yes, that would certainly be my preference from a runtime PM readability
PoV. I guess it's Will's call since it's his code.
Ok great.
Will, let me know your thoughts. I have a V2 series ready to post, I
just need to know your thoughts on handling this runtime PM business. Or
if you would just like me to send it out for review anyway, I can do
that too.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: OMAP3: PM: optimize cpuidle C1 state latency
The C1 state latency can be improved by optimizing the cpuidle low level code. The first patch is a precaution fix for patch 2. Patches 2 3 are optimization changes. Rebased on top of the for_3.6/pm/performance branch of khilman's tree [1]. Tested on Beagleboard using a DMA-enabled copy from NAND flash to /dev/null. [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Jean Pihet (3): ARM: OMAP3: PM: cpuidle: default to C1 in next_valid_state ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state arch/arm/mach-omap2/cpuidle34xx.c | 71 ++--- 1 files changed, 27 insertions(+), 44 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP3: PM: cpuidle: default to C1 in next_valid_state
If the next state is no found in the next_valid_state function,
fallback to the default value of C1 (which is state 0).
This prevents the use of a bogus state -1 in the rest of the cpuidle
code.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 207bc1c..f619a92 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -178,7 +178,7 @@ static int next_valid_state(struct cpuidle_device *dev,
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
int idx;
- int next_index = -1;
+ int next_index = 0; /* C1 is the default value */
if (enable_off_mode) {
mpu_deepest_state = PWRDM_POWER_OFF;
@@ -209,12 +209,6 @@ static int next_valid_state(struct cpuidle_device *dev,
}
}
- /*
-* C1 is always valid.
-* So, no need to check for 'next_index == -1' outside
-* this loop.
-*/
-
return next_index;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
One of the main contributors of the low power code latency is
the PER power domain. To optimize the high-performance and
low-latency C1 state, prevent any PER state which is lower
than the CORE state in C1.
Reported and suggested by Kevin Hilman.
Reported-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 41 +++-
1 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f619a92..2e2f1c6 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -222,23 +222,22 @@ static int next_valid_state(struct cpuidle_device *dev,
* the device to the specified or a safer state.
*/
static int omap3_enter_idle_bm(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
+ struct cpuidle_driver *drv,
int index)
{
int new_state_idx;
- u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
+ u32 core_next_state, per_next_state = 0, per_saved_state = 0;
struct omap3_idle_statedata *cx;
int ret;
/*
-* Prevent idle completely if CAM is active.
+* Use only C1 if CAM is active.
* CAM does not have wakeup capability in OMAP3.
*/
- cam_state = pwrdm_read_pwrst(cam_pd);
- if (cam_state == PWRDM_POWER_ON) {
+ if (pwrdm_read_pwrst(cam_pd) == PWRDM_POWER_ON)
new_state_idx = drv-safe_state_index;
- goto select_state;
- }
+ else
+ new_state_idx = next_valid_state(dev, drv, index);
/*
* FIXME: we currently manage device-specific idle states
@@ -248,24 +247,28 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*its own code.
*/
- /*
-* Prevent PER off if CORE is not in retention or off as this
-* would disable PER wakeups completely.
-*/
- cx = omap3_idle_data[index];
+ /* Program PER state */
+ cx = omap3_idle_data[new_state_idx];
core_next_state = cx-core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
- if ((per_next_state == PWRDM_POWER_OFF)
- (core_next_state PWRDM_POWER_RET))
- per_next_state = PWRDM_POWER_RET;
+ if (new_state_idx == 0) {
+ /* In C1 do not allow PER state lower than CORE state */
+ if (per_next_state core_next_state)
+ per_next_state = core_next_state;
+ } else {
+ /*
+* Prevent PER OFF if CORE is not in RETention or OFF as this
+* would disable PER wakeups completely.
+*/
+ if ((per_next_state == PWRDM_POWER_OFF)
+ (core_next_state PWRDM_POWER_RET))
+ per_next_state = PWRDM_POWER_RET;
+ }
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
- new_state_idx = next_valid_state(dev, drv, index);
-
-select_state:
ret = omap3_enter_idle(dev, drv, new_state_idx);
/* Restore original PER state if it was modified */
@@ -282,7 +285,7 @@ struct cpuidle_driver omap3_idle_driver = {
.owner =THIS_MODULE,
.states = {
{
- .enter= omap3_enter_idle,
+ .enter= omap3_enter_idle_bm,
.exit_latency = 2 + 2,
.target_residency = 5,
.flags= CPUIDLE_FLAG_TIME_VALID,
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 2e2f1c6..e6ae3fe 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -77,20 +77,6 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -108,8 +94,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -131,8 +117,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Hi Kevin,
On Thu, May 31, 2012 at 6:29 PM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
It is not needed to iterate through all the clock domains of a
power domain in order to allow or deny it to idle.
Why? (I know the answer, but would like it answered here.)
This patch allows or denies only the first registered clock domain
of a power domain, and so optimizes the latency of the low power
code. The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihet j-pi...@ti.com
Other than the changelog update, it looks good but also needs a rebase
like the previous patch.
After that, I'll add them to my for_3.6/pm/performance branch and queue
for v3.6.
The new series has been sent as '[PATCH 0/3] ARM: OMAP3: PM: optimize
cpuidle C1 state latency' with the suggested changes (changelog
updated, rebased on for_3.6/pm/performance).
Note: with the code from the branch the CORE does not idle. The
optimization changes have been tested OK though.
Thanks!
Kevin
Regards,
Jean
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 353dd8d..d44b68a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -73,20 +73,6 @@ struct omap3_idle_statedata
omap3_idle_data[OMAP3_NUM_STATES];
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
-static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_allow_idle(clkdm);
- return 0;
-}
-
-static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
- struct clockdomain *clkdm)
-{
- clkdm_deny_idle(clkdm);
- return 0;
-}
-
static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -105,8 +91,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Deny idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
+ clkdm_deny_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_deny_idle(core_pd-pwrdm_clkdms[0]);
}
/*
@@ -128,8 +114,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
/* Re-allow idle for C1 */
if (index == 0) {
- pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
- pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
+ clkdm_allow_idle(mpu_pd-pwrdm_clkdms[0]);
+ clkdm_allow_idle(core_pd-pwrdm_clkdms[0]);
}
return_sleep_time:
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
On Fri, Jun 1, 2012 at 6:54 PM, Cousson, Benoit b-cous...@ti.com wrote: On 6/1/2012 2:52 PM, ABRAHAM, KISHON VIJAY wrote: Hi Benoit, On Wed, May 30, 2012 at 8:53 PM, Cousson, Benoitb-cous...@ti.com wrote: On 5/30/2012 4:51 PM, Shilimkar, Santosh wrote: On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham Ikis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? I have a series that will remove all these clock nodes. I should be able to post that soon. Potentially at that time, Kishon might be able to drop that patch. Will you be sending a patch for *[RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp* also or I have to keep that as part of my series? Good point. In fact, I'm fixing both at the same time to avoid any bisect issue. Thanks :-) -Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
Jean Pihet jean.pi...@newoldbits.com writes: Hi Kevin, On Thu, May 31, 2012 at 6:29 PM, Kevin Hilman khil...@ti.com wrote: jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com It is not needed to iterate through all the clock domains of a power domain in order to allow or deny it to idle. Why? (I know the answer, but would like it answered here.) This patch allows or denies only the first registered clock domain of a power domain, and so optimizes the latency of the low power code. The functions _cpuidle_allow_idle and _cpuidle_deny_idle are not used anymore and so are removed. Signed-off-by: Jean Pihet j-pi...@ti.com Other than the changelog update, it looks good but also needs a rebase like the previous patch. After that, I'll add them to my for_3.6/pm/performance branch and queue for v3.6. The new series has been sent as '[PATCH 0/3] ARM: OMAP3: PM: optimize cpuidle C1 state latency' with the suggested changes (changelog updated, rebased on for_3.6/pm/performance). Note: with the code from the branch the CORE does not idle. The optimization changes have been tested OK though. That's OK, I know the causes of the CORE idle retention problems and have fixes for those queued up. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: latest kernel for am35xx
[Somehow this didn't get out the first time so resending.] On Thu, May 31, 2012 at 08:36:05PM -0700, Mark A. Greer wrote: On Thu, May 31, 2012 at 10:08:44AM +0300, Maxim Podbereznyy wrote: Hi! Hi Maxim http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git Does anyone knows a working branch/tag for am3517evm? I need the board boots fine with Ethernet enabled and working. I read a few messages at e2e forum and all of them report about broken features.. I need wl1271 support in the kernel therefore I have to use on the latest kernels. There are several issues with the am35x code in the current community. However, if you checkout k.o. v3.4, use omap2plus_defconfig, enable CONFIG_TI_DAVINCI_EMAC, and add 'nohlt' to the cmdline, you will be able to boot the am3517evm. Don't try a Suspend-to-RAM though. Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP3: PM: optimize cpuidle C1 state latency
Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: The C1 state latency can be improved by optimizing the cpuidle low level code. The first patch is a precaution fix for patch 2. Patches 2 3 are optimization changes. Rebased on top of the for_3.6/pm/performance branch of khilman's tree [1]. Tested on Beagleboard using a DMA-enabled copy from NAND flash to /dev/null. Thanks for following this through. Adding this series to my for_3.6/pm/performance branch. Also FYI, combining your series with the various fixes for CORE retention, I'm seeing CORE hit retention in idle just fine on 3430/n900 and 3530/Overo. Thanks! Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP3: PM: optimize cpuidle C1 state latency
On Fri, Jun 1, 2012 at 6:26 PM, Kevin Hilman khil...@ti.com wrote: Hi Jean, Jean Pihet jean.pi...@newoldbits.com writes: The C1 state latency can be improved by optimizing the cpuidle low level code. The first patch is a precaution fix for patch 2. Patches 2 3 are optimization changes. Rebased on top of the for_3.6/pm/performance branch of khilman's tree [1]. Tested on Beagleboard using a DMA-enabled copy from NAND flash to /dev/null. Thanks for following this through. Adding this series to my for_3.6/pm/performance branch. Great! Also FYI, combining your series with the various fixes for CORE retention, I'm seeing CORE hit retention in idle just fine on 3430/n900 and 3530/Overo. Nice, thx for testing! Thanks! Kevin Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
Hello, On Fri, Jun 01, 2012 at 02:43:54PM +0200, Cousson Benoit wrote: On 6/1/2012 2:30 PM, Shilimkar, Santosh wrote: On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgrent...@atomide.com wrote: * Cousson, Benoitb-cous...@ti.com [120529 06:29]: On 5/28/2012 1:35 PM, Eduardo Valentin wrote: Mmm, we can have up to 4 control module instances in OMAP4. Well, I'm not sure it worth considering them as separate devices. Is that your plan as well? At least for now I was focusing on the ctrl_module_core ... OK, that's a good start already :-) But since they all have different base address, it will be trick to handle them with only a single entry. Indeed. We can always add the support latter on. I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set? We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning. These should be separate driver instances for the control modules. And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs. Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver. We can have a static map for the SCM, so ioremapping each driver individually should not be an issue. Within this series I kept the original MFD setup in the original driver found in the TI Android tree. But in fact, I agree with Tony here. In general, ideally it would be good if we could setup this driver family, having for each driver their respective resources; a separated individual io area, IRQs, locking, APIs, etc. But, the issue is to avoid having hard coded io areas in the code, and move them to auto generated data, DT/hwmod. This sounds a good idea. With this we may not even need a core control module drivers if all the individual drivers take care of the registers they care. Mapping shouldn't be a problem as you mentioned. We should keep the MFD for PM / OCP single port correctness. Other than that it will be mostly useless, indeed. Then, I guess the idea of having 1 static mapping for the MFD core, either in DT or hwmod, is to maintain the single OCP port we have today for SCM. But, Benoit, IIRC, from our previous discussions, we won't have the io area for children autogenerated anyway, as they don't have any OCP. I suppose this applies also for clock data? If children data won't be autogenerated, assuming we are relying on the autogenerated data, it means that SCM core area is the boundary that will be ioremapped and protected. But then we still have a flaw because children can still stomp between each other. Not to mention non-children users and the pin ctrl simple. That said, if we want to have these io areas properly assigned to their drivers, we either have children area autogenerated, in DT / hwmod. Or we have them in the code. Assuming you still want to have the MFD core, for matching w/ the OCP single port, it would still need to have the resources for its children in the driver code. Or we hack them in the DT entries. Like I already did in this series for the thermal IRQ :-) Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: latest kernel for am35xx
Hey Mark! I don't like to look stupid, but I don't find v3.4 tag here: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=tags please have a look at. There are only a few candidates there for the v3.4 2012/6/1 Mark A. Greer mgr...@animalcreek.com: [Somehow this didn't get out the first time so resending.] On Thu, May 31, 2012 at 08:36:05PM -0700, Mark A. Greer wrote: On Thu, May 31, 2012 at 10:08:44AM +0300, Maxim Podbereznyy wrote: Hi! Hi Maxim http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git Does anyone knows a working branch/tag for am3517evm? I need the board boots fine with Ethernet enabled and working. I read a few messages at e2e forum and all of them report about broken features.. I need wl1271 support in the kernel therefore I have to use on the latest kernels. There are several issues with the am35x code in the current community. However, if you checkout k.o. v3.4, use omap2plus_defconfig, enable CONFIG_TI_DAVINCI_EMAC, and add 'nohlt' to the cmdline, you will be able to boot the am3517evm. Don't try a Suspend-to-RAM though. Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] Move OMAP2+ over to use COMMON clock
On 20120601-17:37, Rajendra Nayak wrote: Hi, This RFC series is based of Mikes' latest clk-next. I will rebase it once 3.5-rc1 is out and post with more testing thats in progress. Meanwhile, the RFC is for me to get some early feedback on the patches. This series retains the static clock declarations Hi Rajendra, Thanks for sending this out. FYI I'm looking into using bootmem to get rid of the terrible static init macros. That's just something to consider for the future since I do not know when I will have time to implement that. Hopefully that change could make it possible to get rid of the static init macros entirely. It won't block acceptance of these patches though. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: latest kernel for am35xx
On Fri, Jun 01, 2012 at 09:23:07PM +0400, Maxim Podbereznyy wrote: Hey Mark! Hi Maxim. I don't like to look stupid, but I don't find v3.4 tag here: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=tags please have a look at. There are only a few candidates there for the v3.4 I'm sorry, I wasn't very clear. The repository I meant was git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git That repository should have a tag called 'v3.4'. Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: omap-mcbsp: Add pm_runtime_get/put functions call for McBSP.
pm_runtime_get_sync() and put_sync() are not called by McBSP driver. This is introducing a problem with PM and Audio Backend due to missing get/put for McBSP IP. Signed-off-by: Sebastien Guiriec s-guir...@ti.com --- sound/soc/omap/omap-mcbsp.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 1046083..007d239 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -117,6 +117,8 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream, struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai); int err = 0; + pm_runtime_get_sync(mcbsp-dev); + if (!cpu_dai-active) err = omap_mcbsp_request(mcbsp); @@ -165,6 +167,8 @@ static void omap_mcbsp_dai_shutdown(struct snd_pcm_substream *substream, omap_mcbsp_free(mcbsp); mcbsp-configured = 0; } + + pm_runtime_put_sync(mcbsp-dev); } static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd, -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap-mcbsp: Add pm_runtime_get/put functions call for McBSP.
On Fri, Jun 01, 2012 at 10:12:52PM +0200, Sebastien Guiriec wrote: pm_runtime_get_sync() and put_sync() are not called by McBSP driver. This is introducing a problem with PM and Audio Backend due to missing get/put for McBSP IP. They are called by the core. Probably you're just pointing your struct device at some virtual device instead of the physical device, either enabling runtime PM for the virtual device (assuming it's a child of the physical device) or changing the pointer to the physical device (which might make for better dev_ logging potentially) should resolve the issue. + pm_runtime_put_sync(mcbsp-dev); No need for this, anyway - just use regular _put(). We don't care if the device is actually suspended before we return, the PM core can do that at it's leisure. signature.asc Description: Digital signature
Re: [RFC 00/24] Move OMAP2+ over to use COMMON clock
Hi Rajendra, Paul, On 06/01/2012 07:07 AM, Rajendra Nayak wrote: Hi, This RFC series is based of Mikes' latest clk-next. I will rebase it once 3.5-rc1 is out and post with more testing thats in progress. Meanwhile, the RFC is for me to get some early feedback on the patches. This series retains the static clock declarations and also all data and code in mach-omap folders and does not move it as yet to drivers/clk. I know its desierable that we move away from static declaration of data and move over to drivers/clk but thats not addressed by this series. Also the series moves over only OMAP2+ (OMAP2/3/4) to use COMMON clk and leaves OMAP1 still using OMAP clock framework. I had wanted to move the file mach-omap2/clkt_sel.c into plat-omap/clkt_sel.c so that this could be used by omap1. The reason for doing this is to fix clock configuration for dmtimers, which right now is complete broken. I have posted a series here [1], however, it appears that patch #1 to move clkt_sel.c never made it to the mailing list :-( Looking at this series, all the functions on clkt_sel.c have been converted to the clock common framework and so this will probably no longer work for omap1. So there are possibly a couple solutions ... 1. Move omap1 to the common clock framework (I am sure this would be preferred but a lot more work). 2. Duplicate the appropriate functions from the current clkt_sel.c in an equivalent file in mach-omap1. [1] http://marc.info/?l=linux-omapm=133771799505501w=2 Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 4/4] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
Nishanth Menon n...@ti.com writes:
From: Wenbiao Wang ww...@ti.com
Voltage Processor state machine transition to disable need to
occur from IDLE state. When we transition OPP in a functioning
system, the call sequence for an OPP transition is as follows:
omap_sr_disable
- sr class 3 disable
- vp disable
- sr disable
forceupdate to voltage/frequency scale depending on which OPP
we are transitioning to.
If we hit a critical timing window where SR had commanded VP
for a voltage transition and VP is in the middle of operating
on that command, it needs to go through a few states before
going to update state(where it actually sends the command to
VC). Initial view of h/w owners is that the state disable of VP
is expected to be sampled for the next transition.
Instead, to be on a safer side, we ensure that the valid states
of the VP state machine is diligently followed by software. This
can be done by waiting for VP to be in idle prior to disabling
VP. Existing prints have been updated to ensure context is
available on error messages.
As part of this change, increase timeout for VP idle check to
improbable 500uSec to be certain that system is indeed unable
to continue before crashing out with error(worst case expectancy
remains the same 3-100uSec depending on when we caught VP).
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
[n...@ti.com: port from android]
and you also convert to use new _vp_wait_for_idle()
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Wenbiao Wang ww...@ti.com
---
arch/arm/mach-omap2/vp.c |4
arch/arm/mach-omap2/vp.h |5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 2a8a085..9a72deb 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -308,6 +308,10 @@ void omap_vp_disable(struct voltagedomain *voltdm)
return;
}
+ if (_vp_wait_for_idle(voltdm, vp)) {
+ pr_warn_ratelimited(%s: vdd_%s timedout!Ignore and try\n,
s/timedout/timed out/
no space after '!', also I don't get the Ignore and try part
Kevin
+ __func__, voltdm-name);
+ }
/* Disable VP */
vpconfig = voltdm-read(vp-vpconfig);
vpconfig = ~vp-common-vpconfig_vpenable;
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 4655b39..4b4eeb6 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -33,9 +33,10 @@ struct voltagedomain;
/*
* Time out for Voltage processor in micro seconds. Typical latency is 2uS,
* but worst case latencies could be around 3-200uS depending on where we
- * interrupted VP's operation.
+ * interrupted VP's operation. Use an improbable timeout value to be
+ * sure that timeout events are beyond doubt.
*/
-#define VP_IDLE_TIMEOUT 200
+#define VP_IDLE_TIMEOUT 500
#define VP_TRANXDONE_TIMEOUT 300
/**
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/4] ARM: OMAP3+: PM: VP: move check of idle to separate function
Nishanth Menon n...@ti.com writes:
In general, the idle check tends to be time sensitive so that the
followon operation after the idle status verification is done in
a timely manner. However, since we'd be using this in multiple
places in follow-on patches, isolate this out to a separate inline
function.
As part of this change, convert the pr_warning to a rate limited
warning as the situation is most probably going to stick around
(since Voltage Processor state machine might be stuck) + a WARN_ONCE
to ensure adequate attention is received. Document the information
about idle timeout. Based on the idea from Kevin Hilman.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vp.c | 55
--
arch/arm/mach-omap2/vp.h |6 -
2 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index faefef7..4723879 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -1,5 +1,6 @@
#include linux/kernel.h
#include linux/init.h
+#include linux/ratelimit.h
#include common.h
@@ -9,6 +10,45 @@
#include prm-regbits-44xx.h
#include prm44xx.h
+/**
+ * _vp_wait_for_idle() - wait for voltage processor to idle
+ * @voltdm: voltage domain
+ * @vp: voltage processor instance
+ *
+ * In some conditions, it is important to ensure that Voltage Processor
+ * is idle before performing operations on the Voltage Processor(VP).
+ * This is primarily to ensure that VP state machine does not enter into
+ * invalid state.
+ *
+ * Returns -ETIMEDOUT if timeout occurs - This could be critical failure
+ * as it indicates that Voltage processor might have it's state machine
+ * stuck up without recovering out(theoretically should never happen
+ * ofcourse). Returns 0 if idle state is detected.
+ *
+ * Note: callers are expected to ensure requisite checks are performed
+ * on the pointers passed.
+ */
+static inline int _vp_wait_for_idle(struct voltagedomain *voltdm,
+ struct omap_vp_instance *vp)
+{
+ int timeout;
+
+ omap_test_timeout((voltdm-read(vp-vstatus)
+vp-common-vstatus_vpidle), VP_IDLE_TIMEOUT,
+ timeout);
+
+ if (timeout = VP_IDLE_TIMEOUT) {
+ /* Dont spam the console but ensure we catch attention */
+ pr_warn_ratelimited(%s: vdd_%s idle timedout\n,
s/idle timedout/timeout waiting for VP idle/
+ __func__, voltdm-name);
+ WARN_ONCE(vdd_%s idle timedout\n, voltdm-name);
+
Maybe just leave the WARN_ONCE() here since all the callers are using
the rate-limited pr_warn() in the case of error. Otherwise, there will
b a bunch of duplicated messages on the console.
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
static u32 _vp_set_init_voltage(struct voltagedomain *voltdm, u32 volt)
{
struct omap_vp_instance *vp = voltdm-vp;
@@ -241,7 +281,6 @@ void omap_vp_disable(struct voltagedomain *voltdm)
{
struct omap_vp_instance *vp;
u32 vpconfig;
- int timeout;
if (!voltdm || IS_ERR(voltdm)) {
pr_warning(%s: VDD specified does not exist!\n, __func__);
@@ -267,16 +306,10 @@ void omap_vp_disable(struct voltagedomain *voltdm)
vpconfig = ~vp-common-vpconfig_vpenable;
voltdm-write(vpconfig, vp-vpconfig);
- /*
- * Wait for VP idle Typical latency is 2us. Maximum latency is ~100us
- */
- omap_test_timeout((voltdm-read(vp-vstatus)
-vp-common-vstatus_vpidle), VP_IDLE_TIMEOUT,
- timeout);
-
- if (timeout = VP_IDLE_TIMEOUT)
- pr_warning(%s: vdd_%s idle timedout\n,
- __func__, voltdm-name);
+ if (_vp_wait_for_idle(voltdm, vp)) {
+ pr_warn_ratelimited(%s: vdd_%s timedout after disable!!\n,
s/timedout/VP idle timeout/
+ __func__, voltdm-name);
+ }
vp-enabled = false;
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index ac1d6cf..4655b39 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -30,7 +30,11 @@ struct voltagedomain;
#define OMAP4_VP_VDD_IVA_ID 1
#define OMAP4_VP_VDD_MPU_ID 2
-/* XXX document */
+/*
+ * Time out for Voltage processor in micro seconds. Typical latency is 2uS,
+ * but worst case latencies could be around 3-200uS depending on where we
+ * interrupted VP's operation.
+ */
#define VP_IDLE_TIMEOUT 200
#define VP_TRANXDONE_TIMEOUT 300
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH V2 3/4] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
Nishanth Menon n...@ti.com writes:
Ideally in the flow of DVFS programming, VP should be in idle state
(since we disabled it) before entering forceupdate. Ensure that
this is the case. Not doing this could cause VP statemachine
to enter invalid states. Use ratelimited warnings to prevent spam
if VP state machine is stuck.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Vinay Amancha vinayku...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vp.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 4723879..2a8a085 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -163,6 +163,13 @@ int omap_vp_forceupdate_scale(struct voltagedomain
*voltdm,
u8 target_vsel, current_vsel;
int ret, timeout = 0;
+ ret = _vp_wait_for_idle(voltdm, vp);
+ if (ret) {
+ pr_warn_ratelimited(%s: vdd_%s idle timedout (v=%ld)\n,
nit: s/idle timedout/VP idle timeout/
Kevin
+ __func__, voltdm-name, target_volt);
+ return ret;
+ }
+
ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel,
current_vsel);
if (ret)
return ret;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 4/4] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
Regards,
Nishanth Menon
On Fri, Jun 1, 2012 at 4:03 PM, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
From: Wenbiao Wang ww...@ti.com
Voltage Processor state machine transition to disable need to
occur from IDLE state. When we transition OPP in a functioning
system, the call sequence for an OPP transition is as follows:
omap_sr_disable
- sr class 3 disable
- vp disable
- sr disable
forceupdate to voltage/frequency scale depending on which OPP
we are transitioning to.
If we hit a critical timing window where SR had commanded VP
for a voltage transition and VP is in the middle of operating
on that command, it needs to go through a few states before
going to update state(where it actually sends the command to
VC). Initial view of h/w owners is that the state disable of VP
is expected to be sampled for the next transition.
Instead, to be on a safer side, we ensure that the valid states
of the VP state machine is diligently followed by software. This
can be done by waiting for VP to be in idle prior to disabling
VP. Existing prints have been updated to ensure context is
available on error messages.
As part of this change, increase timeout for VP idle check to
improbable 500uSec to be certain that system is indeed unable
to continue before crashing out with error(worst case expectancy
remains the same 3-100uSec depending on when we caught VP).
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
[n...@ti.com: port from android]
and you also convert to use new _vp_wait_for_idle()
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Wenbiao Wang ww...@ti.com
---
arch/arm/mach-omap2/vp.c | 4
arch/arm/mach-omap2/vp.h | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 2a8a085..9a72deb 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -308,6 +308,10 @@ void omap_vp_disable(struct voltagedomain *voltdm)
return;
}
+ if (_vp_wait_for_idle(voltdm, vp)) {
+ pr_warn_ratelimited(%s: vdd_%s timedout!Ignore and try\n,
s/timedout/timed out/
no space after '!',
Kinda wanted to stay under 80 character and not split string out to
two lines and make sparse angry, yet did not want to loose information
which was being presented out.
also I don't get the Ignore and try part
if we fail, just try the disable anyways.. (at least till we have
voltage processor recovery mechanism(cold reset) introduced upstream -
the intent of the patch was not to introduce a recovery mechanism, but
to ensure proper checkpoint is in place)..
+ __func__, voltdm-name);
+ }
/* Disable VP */
vpconfig = voltdm-read(vp-vpconfig);
vpconfig = ~vp-common-vpconfig_vpenable;
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 4655b39..4b4eeb6 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -33,9 +33,10 @@ struct voltagedomain;
/*
* Time out for Voltage processor in micro seconds. Typical latency is
2uS,
* but worst case latencies could be around 3-200uS depending on where we
- * interrupted VP's operation.
+ * interrupted VP's operation. Use an improbable timeout value to be
+ * sure that timeout events are beyond doubt.
*/
-#define VP_IDLE_TIMEOUT 200
+#define VP_IDLE_TIMEOUT 500
#define VP_TRANXDONE_TIMEOUT 300
/**
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] Move OMAP2+ over to use COMMON clock
Hi Rajendra, On 06/01/2012 07:07 AM, Rajendra Nayak wrote: Hi, This RFC series is based of Mikes' latest clk-next. I will rebase it once 3.5-rc1 is out and post with more testing thats in progress. Meanwhile, the RFC is for me to get some early feedback on the patches. This series retains the static clock declarations and also all data and code in mach-omap folders and does not move it as yet to drivers/clk. I know its desierable that we move away from static declaration of data and move over to drivers/clk but thats not addressed by this series. Also the series moves over only OMAP2+ (OMAP2/3/4) to use COMMON clk and leaves OMAP1 still using OMAP clock framework. The series does not break git-bisect at any point and to do so adds new data in completely different files and uses some ifdefferry in code too, and switches over in one patch to move from OMAP clock to COMMON clock. Then deletes all old data files and all the ifdeferrey around. All of the new data for OMAP2/3/4 in the new COMMON clock format is autogenerated, OMAP4 by hacking the existing python scripts, and OMAP2/3 by converting the existing C99 structs to JSON format (Thanks to Paul Walmsley for this) and then having python to read the JSON format and generate the C99 structs back in the form COMMON clk expects. The patches also depend on 2 of my patches posted here http://comments.gmane.org/gmane.linux.kernel/1298747 I have not reposted them becasue one of them is already picked up by Mike, and the other is already under discussion. The series with all dependent patches can be found here git://github.com/rrnayak/linux.git clk-next-omap regards, Rajendra Mike Turquette (1): ARM: omap4: cm: add bitfield width values Rajendra Nayak (23): clk: Add CLK_IS_BASIC flag to identify basic clocks ARM: omap: clk: convert all clk_enable to clk_prepare_enable ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage ARM: omap: clk: Nuke plat clock.c clock.h if CONFIG_COMMON_CLK ARM: omap: clk: Remove all direct dereferncing of struct clk ARM: omap: hwmod: Fix up hwmod based clkdm accesses ARM: omap4: clk: Convert to common clk ARM: omap3: clk: Convert to common clk ARM: omap2: clk: Convert to common clk ARM: omap: clk: list all clk_hw_omap clks to enable/disable autoidle ARM: omap: clk: Define a function to enable clocks at init ARM: omap4: clk: Add 44xx data using common struct clk ARM: omap3: clk: Add 3xxx data using common struct clk ARM: omap2: clk: Add 24xx data using common struct clk ARM: omap: clk: Switch to COMMON clk ARM: omap: clk: Use plat clock.c clock.h only for OMAP1 With regard to the above patch, I am not sure why it is necessary to move the existing definitions out of plat-omap/clock.h to put in mach-omap2/clock.h. Eventually, if we move omap1 to the common clock framework, won't we need to move them back? It would seem to me that by keeping them in plat clock.h it will be easier to migrate omap1 to the common clock framework (assuming thats our goal). Also, by adding the common clock definitions to the plat clock.h it will be easier for migrating omap1 too. Obviously, we would need to keep the #ifdef COMMON_CLK around this code so it can compile for both omap1 and omap2+ today. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
