Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
On Thu, 2012-05-31 at 08:41 +0300, Jarkko Nikula wrote: On 05/31/2012 02:35 AM, Ricardo Neri wrote: Build breaks because there some patches [1] that are still missing in Linus' tree. ASoC HDMI audio driver for OMAP[2] now uses the new DSS audio functionality in [1], but ASoC patches were merged first. DSS patches have been accepted and they are part of Tomi's pull request for DSS for K3.5. Hopefully this will be fixed when v3.5-rc1 is out. Then there was an error already in the process if dependent sets didn't go together via the same merge or in next merge window. Remember each commit must compile alone. They are going in in the same merge window. The asoc stuff has been already merged, but the omapdss stuff hasn't. It's true that there's a commit range where the asoc stuff doesn't compile, and I agree that it's not good. But you need to explicitly enable the HDMI ASOC support to get the error. It's quite boring to try to bisect over multiple kernel versions and where most of the time goes solving random unrelated build breakages. How to get arm/arm/, omapdss, omapdrm and asoc driver changes in at the same time? All go through various different trees and maintainers. I haven't found a solution for this. If you have good ideas, please share =). Tomi signature.asc Description: This is a digitally signed message part
Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
On 05/31/2012 09:31 AM, Tomi Valkeinen wrote: It's true that there's a commit range where the asoc stuff doesn't compile, and I agree that it's not good. But you need to explicitly enable the HDMI ASOC support to get the error. You can still hit the build breakage by randconfig or if it's enabled by default in the future and you start bisecting with that config old kernel. It's quite boring to try to bisect over multiple kernel versions and where most of the time goes solving random unrelated build breakages. How to get arm/arm/, omapdss, omapdrm and asoc driver changes in at the same time? All go through various different trees and maintainers. I haven't found a solution for this. If you have good ideas, please share =). One simple - wait for next merge window. It's not that long. Only ~3 months and meanwhile one could keep boss/customer/wife/whatever satisfied by carrying patches in own tree :-) -- Jarkko -- 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 19/19] ARM: OMAP4: powerdomain: update mpu / core off counters during device off
On Wed, 2012-05-30 at 16:08 -0500, Menon, Nishanth wrote:
On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote:
Currently device off does not have any counters / timers of its own
and it is impossible to track the time spent in this state. In device
off, MPU / CORE powerdomains enter OSWR, so normally the RETENTION
state times / counts are increased during device off.
This patch adds a new field to the powerdomain struct for context loss
register, which is checked during pwrdm_post_transition to see if
a device off type context loss has happened. If this is the case,
the counters + timers for OFF state are touched instead of RETENTION.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |1 -
arch/arm/mach-omap2/powerdomain.c |9 +
arch/arm/mach-omap2/powerdomain.h |2 ++
arch/arm/mach-omap2/powerdomains44xx_data.c |2 ++
arch/arm/mach-omap2/prm44xx.c | 15 +++
arch/arm/mach-omap2/prm44xx.h |2 ++
6 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 1f06f97..f187025 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -404,7 +404,6 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
omap4_cm_resume_off();
- omap4_device_clear_prev_off_state();
We should probably delete the function in it's entirety - not just the
call - the original implementation just clears L3 and this
implementation seems superior.
Yeah, that can be done, I don't think it is used anymore after this
change.
}
sar_save_failed:
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..f13bb2c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -156,6 +156,15 @@ static int _pwrdm_state_switch(struct powerdomain
*pwrdm, int flag)
break;
case PWRDM_STATE_PREV:
prev = pwrdm_read_prev_pwrst(pwrdm);
+
+ /*
+* If powerdomain has context offset defined, check if
+* the domain has lost context (i.e. entered off)
+*/
+ if (pwrdm-context_offs)
+ if (omap4_pwrdm_lost_context_rff(pwrdm-prcm_offs,
+
pwrdm-context_offs))
We should wrap this under pwrdm_lost_context(pwrdm)
pwrdm_lost_context should call the arch_pwrdm-lost_context_rff as
needed? the rest of the powerdomain.c does not use OMAP4 specific
APIs.
Yes, that sounds like a good change, I'll change this.
+ prev = PWRDM_POWER_OFF;
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..a427645 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -82,6 +82,7 @@ struct powerdomain;
* @name: Powerdomain name
* @voltdm: voltagedomain containing this powerdomain
* @prcm_offs: the address offset from CM_BASE/PRM_BASE
+ * @context_offs: the address offset for the CONTEXT register
* @prcm_partition: (OMAP4 only) the PRCM partition ID containing @prcm_offs
* @pwrsts: Possible powerdomain power states
* @pwrsts_logic_ret: Possible logic power states when pwrdm in RETENTION
@@ -106,6 +107,7 @@ struct powerdomain {
struct voltagedomain *ptr;
} voltdm;
const s16 prcm_offs;
+ const s16 context_offs;
const u8 pwrsts;
const u8 pwrsts_logic_ret;
const u8 flags;
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index d8701ce..c4de02f 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,6 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs= OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_L3_1_L3_1_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 5,
@@ -205,6 +206,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs= OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs
Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
On 05/31/2012 09:42 AM, Jarkko Nikula wrote: On 05/31/2012 09:31 AM, Tomi Valkeinen wrote: It's true that there's a commit range where the asoc stuff doesn't compile, and I agree that it's not good. But you need to explicitly enable the HDMI ASOC support to get the error. You can still hit the build breakage by randconfig or if it's enabled by default in the future and you start bisecting with that config old kernel. That's true. It's quite boring to try to bisect over multiple kernel versions and where most of the time goes solving random unrelated build breakages. How to get arm/arm/, omapdss, omapdrm and asoc driver changes in at the same time? All go through various different trees and maintainers. I haven't found a solution for this. If you have good ideas, please share =). One simple - wait for next merge window. It's not that long. Only ~3 months and meanwhile one could keep boss/customer/wife/whatever satisfied by carrying patches in own tree :-) Well... I'm not sure how serious you are here =). In some cases that's doable, and we've done it, for example omapdrm had some things delayed until next merge window, so it's definitely an option. But it's quite easy to get some build dependencies between pull requests, so we'd be delaying features all the time. And sometimes even cross dependencies. In the worst case it could end up with delaying some features for a year to get all single pieces in bit by bit. Something I think we could try to do is create some kinds of temporary dummy functions or such which allow the compilation, but of course makes the component not (fully) functional. The temp functions could then be removed in -rc2 or so, when the dependencies are all there. But doesn't feel like an optimal solution either... Tomi signature.asc Description: OpenPGP digital signature
Re: latest kernel for am35xx
Hi! 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. 2012/5/30 Anil Kumar anilkumar...@gmail.com: Hi Lisarden, Please try this. git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git Thanks, Anil On Wed, May 30, 2012 at 2:21 PM, Maxim Podbereznyy lisar...@gmail.com wrote: Hi! I need to use the latest kernel at a am3517 based board where Craneboard schematic was used as a reference. In addition to Cranboard scheme I have wl1271 chip added and therefore I need a kernel - one of the latests to support wireless feature. The job I did: 1) used kernel from Craneboard (Mistral repository) - 2.6.32, no wl1271 support 2) OMAPPSP_04.02.00.07 - 2.6.37, tps65910 driver is broken 3) AM335x PSP 04.06.00.07 - does not compile for am3517evm Can anybody suggest some alive kernel tree where tps65910 and wl1271 chips are supported? Having am3517evm or am3517crane board files would be a great help! Thanks in advance! Max -- 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: [RFC PATCH 0/5] omap: add ocp2scp as a misc driver
Hi Arnd, On Thu, May 31, 2012 at 12:13 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 30 May 2012, Kishon Vijay Abraham I wrote: This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp to which phy drivers are connected. I'm planning to send phy drivers asap. Meanwhile I'd like to get some review comments for this series. I have also plans to send device tree adaptation of the ocp2scp driver. Developed on http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next If it has to be based on some other tree, please let me know. This must be the most pointless driver I've seen in a long time. It doesn't actually do anything at all, it just creates child devices from a static lookup table. 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 then shouldn't there be a separate driver to extract the child nodes of ocp2scp and create a device (using of_platform_populate)? As far as I've seen, the devices are automatically created (by virtue of of_platform_populate() in mach-omap2/board-generic.c in omap case) only for the devices that is connected to the system bus. For other cases, the parent should be responsible for creating the child devices. 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: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
On 05/31/2012 10:00 AM, Tomi Valkeinen wrote: One simple - wait for next merge window. It's not that long. Only ~3 months and meanwhile one could keep boss/customer/wife/whatever satisfied by carrying patches in own tree :-) Well... I'm not sure how serious you are here =). Quite serious :-) In some cases that's doable, and we've done it, for example omapdrm had some things delayed until next merge window, so it's definitely an option. But it's quite easy to get some build dependencies between pull requests, so we'd be delaying features all the time. And sometimes even cross dependencies. In the worst case it could end up with delaying some features for a year to get all single pieces in bit by bit. Something what is usually done is to get ack from maintainers and let code to be merged via another tree. Needs careful planning though in order to avoid preventing e.g. API changes in one subsystem. Something I think we could try to do is create some kinds of temporary dummy functions or such which allow the compilation, but of course makes the component not (fully) functional. The temp functions could then be removed in -rc2 or so, when the dependencies are all there. But doesn't feel like an optimal solution either... Yeah, this might work too. -- Jarkko -- 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
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. my best choice was 3.3-rc7 so far. With final 3.3 frame buffer made problems. wl1271 was working like a charm. I have another PMIC, so I don't know if it works well with tps65910. I just took the master branch of linux-omap.git Best regards, Yegor -- 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
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. then shouldn't there be a separate driver to extract the child nodes of ocp2scp and create a device (using of_platform_populate)? As far as I've seen, the devices are automatically created (by virtue of of_platform_populate() in mach-omap2/board-generic.c in omap case) only for the devices that is connected to the system bus. For other cases, the parent should be responsible for creating the child devices. I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. Arnd -- 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
Hi Arnd, On Thu, May 31, 2012 at 2:52 PM, Arnd Bergmann a...@arndb.de wrote: 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. then shouldn't there be a separate driver to extract the child nodes of ocp2scp and create a device (using of_platform_populate)? As far as I've seen, the devices are automatically created (by virtue of of_platform_populate() in mach-omap2/board-generic.c in omap case) only for the devices that is connected to the system bus. For other cases, the parent should be responsible for creating the child devices. I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. hmm.. ocp2scp has a sysconfig register and it also has a module mode by which it can be enabled/disabled. I was making use of pm_runtime API's to control these registers (Apart from creating child devices, the driver also has a call to pm_runtime_enable). I'm not sure if with simple-bus we'll be able to do those. I have to check on that. 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: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. BR, Konstantin Baydarov. 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 11/11] ARM: DT: Add support to system control module for OMAP4
Hello, On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. 4460: [root@(none) ~]# omapconf read 0x4A002000 4A00 [root@(none) ~]# omapconf read 0x4A002004 4470: [root@(none) ~]# omapconf read 0x4A002000 4B00 [root@(none) ~]# omapconf read 0x4A002004 BR, Konstantin Baydarov. 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 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/31/2012 2:49 PM, Eduardo Valentin wrote: Hello, On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. 4460: [root@(none) ~]# omapconf read 0x4A002000 4A00 [root@(none) ~]# omapconf read 0x4A002004 4470: [root@(none) ~]# omapconf read 0x4A002000 4B00 [root@(none) ~]# omapconf read 0x4A002004 Nice! We do have a cool progression 1 - 2 - 3 for each revision. Well at least for the SCM. 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
[PATCHv3 2/9] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clkt_iclk.c | 21 +
arch/arm/mach-omap2/clockdomain.c | 38 +-
arch/arm/mach-omap2/clockdomain.h |2 +
arch/arm/mach-omap2/powerdomain.c | 20
arch/arm/mach-omap2/powerdomain.h |5
arch/arm/plat-omap/clock.c |6 +
arch/arm/plat-omap/include/plat/clock.h |2 +
7 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 3d43fba..f8c2e77 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -21,6 +21,7 @@
#include clock2xxx.h
#include cm2xxx_3xxx.h
#include cm-regbits-24xx.h
+#include clockdomain.h
/* Private functions */
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v |= (1 clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /* Remove this clock from parent clockdomain usecounts */
+ if (clk-usecount clk-clkdm)
+ clkdm_usecount_dec(clk-clkdm);
+
+ /*
+* Mark as autoidle, so we continue to ignore this clock in
+* parent clkdm usecount calculations
+*/
+ clk-autoidle = true;
}
/* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v = ~(1 clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+ /* Add clock back to parent clockdomain usecount */
+ if (clk-usecount clk-clkdm)
+ clkdm_usecount_inc(clk-clkdm);
+
+ /*
+* Disable autoidle flag so further clkdm usecounts take this
+* clock into account
+*/
+ clk-autoidle = false;
}
/* Public data */
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 8664f5a..c665348 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -907,6 +907,32 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
/* Clockdomain-to-clock/hwmod framework interface code */
+int clkdm_usecount_inc(struct clockdomain *clkdm)
+{
+ int usecount;
+
+ usecount = atomic_inc_return(clkdm-usecount);
+
+ if (usecount == 1)
+ pwrdm_clkdm_enable(clkdm-pwrdm.ptr);
+
+ return usecount;
+}
+
+int clkdm_usecount_dec(struct clockdomain *clkdm)
+{
+ int usecount;
+
+ usecount = atomic_dec_return(clkdm-usecount);
+
+ if (usecount == 0)
+ pwrdm_clkdm_disable(clkdm-pwrdm.ptr);
+
+ BUG_ON(usecount 0);
+
+ return usecount;
+}
+
static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
{
unsigned long flags;
@@ -919,7 +945,7 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
* should be called for every clock instance or hwmod that is
* enabled, so the clkdm can be force woken up.
*/
- if ((atomic_inc_return(clkdm-usecount) 1) autodeps)
+ if ((clkdm_usecount_inc(clkdm) 1) autodeps)
return 0;
spin_lock_irqsave(clkdm-lock, flags);
@@ -944,7 +970,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain
*clkdm)
return -ERANGE;
}
- if (atomic_dec_return(clkdm-usecount) 0)
+ if (clkdm_usecount_dec(clkdm) 0)
return 0;
spin_lock_irqsave(clkdm-lock, flags);
@@ -981,6 +1007,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk-autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
}
@@ -1007,6 +1037,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct
clk *clk)
if (!clk)
return -EINVAL;
+ /* If autoidle clock, do not update clkdm usecounts */
+ if (clk-autoidle)
+ return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
}
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index f7b5860..373399a 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -191,6 +191,8 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk
*clk);
int clkdm_clk_disable(struct clockdomain *clkdm, struct clk
[PATCHv3 5/9] ARM: OMAP3: set autoidle flags for a few clocks
dpll3, dpll4 and sdrc_ick are controlled automatically by hardware.
Thus, reflect this with the autoidle flags, the clocks will no longer
show as active in usecount dumps and will allow the voltdm-sleep /
wakeup calls to work properly.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 4e1a3b0..ca0de28 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -434,6 +434,7 @@ static struct clk dpll3_ck = {
.round_rate = omap2_dpll_round_rate,
.clkdm_name = dpll3_clkdm,
.recalc = omap3_dpll_recalc,
+ .autoidle = true,
};
/*
@@ -617,6 +618,7 @@ static struct clk dpll4_ck = {
.set_rate = omap3_dpll4_set_rate,
.clkdm_name = dpll4_clkdm,
.recalc = omap3_dpll_recalc,
+ .autoidle = true,
};
/*
@@ -1751,6 +1753,7 @@ static struct clk sdrc_ick = {
.flags = ENABLE_ON_INIT,
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
+ .autoidle = true,
};
static struct clk gpmc_fck = {
--
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
[PATCHv3 7/9] ARM: OMAP: clockdomain: add support for preventing domain transitions
Some clockdomains can't support manual domain transitions triggered by clock framework, and must be prevented from doing so. Added clkdm flag CLKDM_SKIP_MANUAL_TRANS for doing this. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/clockdomain.c |6 ++ arch/arm/mach-omap2/clockdomain.h |3 +++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index c665348..fa652b5 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -948,6 +948,9 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm) if ((clkdm_usecount_inc(clkdm) 1) autodeps) return 0; + if (clkdm-flags CLKDM_SKIP_MANUAL_TRANS) + return 0; + spin_lock_irqsave(clkdm-lock, flags); arch_clkdm-clkdm_clk_enable(clkdm); pwrdm_state_switch(clkdm-pwrdm.ptr); @@ -973,6 +976,9 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm) if (clkdm_usecount_dec(clkdm) 0) return 0; + if (clkdm-flags CLKDM_SKIP_MANUAL_TRANS) + return 0; + spin_lock_irqsave(clkdm-lock, flags); arch_clkdm-clkdm_clk_disable(clkdm); pwrdm_state_switch(clkdm-pwrdm.ptr); diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h index 373399a..35ac7ee 100644 --- a/arch/arm/mach-omap2/clockdomain.h +++ b/arch/arm/mach-omap2/clockdomain.h @@ -31,12 +31,15 @@ * * CLKDM_NO_AUTODEPS: Prevent autodeps from being added/removed from this * clockdomain. (Currently, this applies to OMAP3 clockdomains only.) + * CLKDM_SKIP_MANUAL_TRANS: Prevent clockdomain code from attempting to change + * clockdomain state manually. Needed for PER domain on omap3. */ #define CLKDM_CAN_FORCE_SLEEP (1 0) #define CLKDM_CAN_FORCE_WAKEUP (1 1) #define CLKDM_CAN_ENABLE_AUTO (1 2) #define CLKDM_CAN_DISABLE_AUTO (1 3) #define CLKDM_NO_AUTODEPS (1 4) +#define CLKDM_SKIP_MANUAL_TRANS(1 5) #define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO) #define CLKDM_CAN_SWSUP(CLKDM_CAN_FORCE_SLEEP | CLKDM_CAN_FORCE_WAKEUP) -- 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
[PATCHv3 9/9] TEMP: ARM: OMAP3: prevent dpll4 manual enable / disable + prevent core clkdm idle
DPLL4 (PER DPLL) disable can cause issues on omap3, thus prevent
disable / enable by setting the clkops as core_dpll_ops. Also, prevent
l3 / l4 core clkdomain manual transitions as these can cause issues also.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c|2 +-
arch/arm/mach-omap2/clockdomains3xxx_data.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index ca0de28..bbc1a36 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -611,7 +611,7 @@ static struct dpll_data dpll4_dd_3630 __initdata = {
static struct clk dpll4_ck = {
.name = dpll4_ck,
- .ops= clkops_omap3_noncore_dpll_ops,
+ .ops= clkops_omap3_core_dpll_ops,
.parent = sys_ck,
.dpll_data = dpll4_dd,
.round_rate = omap2_dpll_round_rate,
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 0dae4c8..52bf48c 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -232,7 +232,7 @@ static struct clockdomain d2d_clkdm = {
static struct clockdomain core_l3_3xxx_clkdm = {
.name = core_l3_clkdm,
.pwrdm = { .name = core_pwrdm },
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_HWSUP | CLKDM_SKIP_MANUAL_TRANS,
.dep_bit= OMAP3430_EN_CORE_SHIFT,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_L3_MASK,
};
@@ -245,7 +245,7 @@ static struct clockdomain core_l3_3xxx_clkdm = {
static struct clockdomain core_l4_3xxx_clkdm = {
.name = core_l4_clkdm,
.pwrdm = { .name = core_pwrdm },
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_HWSUP | CLKDM_SKIP_MANUAL_TRANS,
.dep_bit= OMAP3430_EN_CORE_SHIFT,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_L4_MASK,
};
--
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
[PATCHv3 6/9] ARM: OMAP: pm-debug: enhanced usecount debug support
Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
their own file, 'usecount'. This file shows the usecounts for every
active domain and their children recursively. 'count' file now only
shows power state counts for powerdomains.
This patch also provices a way to do printk dumps from kernel code,
by calling the pm_dbg_dump_X functions. The plan is to call these
functions once an error condition is detected, e.g. failed suspend.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm-debug.c | 128 ++--
arch/arm/mach-omap2/pm.h |6 ++
2 files changed, 115 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..cfc46a8 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -51,6 +51,7 @@ static int pm_dbg_init(void);
enum {
DEBUG_FILE_COUNTERS = 0,
DEBUG_FILE_TIMERS,
+ DEBUG_FILE_USECOUNT,
};
static const char pwrdm_state_names[][PWRDM_MAX_PWRSTS] = {
@@ -75,23 +76,6 @@ void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
pwrdm-timer = t;
}
-static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
-{
- struct seq_file *s = (struct seq_file *)user;
-
- if (strcmp(clkdm-name, emu_clkdm) == 0 ||
- strcmp(clkdm-name, wkup_clkdm) == 0 ||
- strncmp(clkdm-name, dpll, 4) == 0)
- return 0;
-
- seq_printf(s, %s-%s (%d), clkdm-name,
- clkdm-pwrdm.ptr-name,
- atomic_read(clkdm-usecount));
- seq_printf(s, \n);
-
- return 0;
-}
-
static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
{
struct seq_file *s = (struct seq_file *)user;
@@ -145,11 +129,112 @@ static int pwrdm_dbg_show_timer(struct powerdomain
*pwrdm, void *user)
return 0;
}
+static struct voltagedomain *parent_voltdm;
+static struct powerdomain *parent_pwrdm;
+static struct clockdomain *parent_clkdm;
+
+#define PM_DBG_PRINT(s, fmt, args...) \
+ { \
+ if (s) \
+ seq_printf(s, fmt, ## args);\
+ else\
+ pr_info(fmt, ## args); \
+ }
+
+static int _pm_dbg_dump_clk(struct clk *clk, void *user)
+{
+ struct seq_file *s = user;
+
+ if (clk-clkdm == parent_clkdm clk-usecount !clk-autoidle)
+ PM_DBG_PRINT(s, ck:%s: %d\n, clk-name, clk-usecount);
+
+ return 0;
+}
+
+static int _pm_dbg_dump_hwmod(struct omap_hwmod *oh, void *user)
+{
+ struct seq_file *s = user;
+
+ if (oh-clkdm != parent_clkdm)
+ return 0;
+
+ if (oh-_state != _HWMOD_STATE_ENABLED)
+ return 0;
+
+ PM_DBG_PRINT(s, oh:%s: enabled\n, oh-name);
+
+ return 0;
+}
+
+static int _pm_dbg_dump_clkdm(struct clockdomain *clkdm, void *user)
+{
+ struct seq_file *s = user;
+ u32 usecount;
+
+ if (clkdm-pwrdm.ptr == parent_pwrdm) {
+ usecount = atomic_read(clkdm-usecount);
+ if (usecount) {
+ PM_DBG_PRINT(s, cd:%s: %d\n, clkdm-name,
+ usecount);
+ parent_clkdm = clkdm;
+ omap_hwmod_for_each(_pm_dbg_dump_hwmod, s);
+ omap_clk_for_each(_pm_dbg_dump_clk, s);
+ }
+ }
+ return 0;
+}
+
+static int _pm_dbg_dump_pwrdm(struct powerdomain *pwrdm, void *user)
+{
+ struct seq_file *s = user;
+ u32 usecount;
+
+ if (pwrdm-voltdm.ptr == parent_voltdm) {
+ usecount = atomic_read(pwrdm-usecount);
+ if (usecount) {
+ PM_DBG_PRINT(s, pd:%s: %d\n, pwrdm-name, usecount);
+ parent_pwrdm = pwrdm;
+ clkdm_for_each(_pm_dbg_dump_clkdm, s);
+ }
+ }
+ return 0;
+}
+
+void pm_dbg_dump_pwrdm(struct powerdomain *pwrdm)
+{
+ pr_info(pd:%s: %d\n, pwrdm-name, atomic_read(pwrdm-usecount));
+ parent_pwrdm = pwrdm;
+ clkdm_for_each(_pm_dbg_dump_clkdm, NULL);
+}
+
+void pm_dbg_dump_voltdm(struct voltagedomain *voltdm)
+{
+ pr_info(vd:%s: %d\n, voltdm-name, atomic_read(voltdm-usecount));
+ parent_voltdm = voltdm;
+ pwrdm_for_each(_pm_dbg_dump_pwrdm, NULL);
+}
+
+static int _voltdm_dbg_show_counters(struct voltagedomain *voltdm, void *user)
+{
+ struct seq_file *s = user;
+
+ seq_printf(s, vd:%s: %d\n, voltdm-name,
+ atomic_read(voltdm-usecount));
+
+ parent_voltdm = voltdm;
+ pwrdm_for_each(_pm_dbg_dump_pwrdm, s);
+ return 0;
+}
+
+static int pm_dbg_show_usecount(struct
[PATCHv3 8/9] ARM: OMAP3: prevent per_clkdm from attempting manual domain transitions
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,
--
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
[PATCHv3 1/9] ARM: OMAP: clk: add support for omap_clk_for_each
This works similarly to e.g. pwrdm_for_each(). Needed by enhanced
usecounting debug functionality that will be added to pm-debug.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/clock.c | 33 +++
arch/arm/plat-omap/include/plat/clock.h |2 +
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 62ec5c4..0a0775a 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -355,6 +355,39 @@ int omap_clk_enable_autoidle_all(void)
return 0;
}
+/**
+ * omap_clk_for_each - call a function for each registered clock
+ * @fn: pointer to callback function
+ * @data: void * data to pass to callback function
+ *
+ * Call @fn for each registered clock, passing @data to each function.
+ * @fn must return 0 for success or any other value for failure. If
+ * @fn returns non-zero, the iteration across clocks will stop and
+ * the non-zero return value will be passed to the caller of
+ * omap_clk_for_each(). @fn is called with clockfw_lock held.
+ */
+int omap_clk_for_each(int (*fn)(struct clk *clk, void *user), void *user)
+{
+ struct clk *c;
+ unsigned long flags;
+ int ret = 0;
+
+ if (!fn)
+ return -EINVAL;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+
+ list_for_each_entry(c, clocks, node) {
+ ret = fn(c, user);
+ if (ret)
+ break;
+ }
+
+ spin_unlock_irqrestore(clockfw_lock, flags);
+
+ return ret;
+}
+
int omap_clk_disable_autoidle_all(void)
{
struct clk *c;
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..998947e 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -294,6 +294,8 @@ extern void propagate_rate(struct clk *clk);
extern void recalculate_root_clocks(void);
extern unsigned long followparent_recalc(struct clk *clk);
extern void clk_enable_init_clocks(void);
+extern int omap_clk_for_each(int (*fn)(struct clk *clk, void *user),
+ void *user);
unsigned long omap_fixed_divisor_recalc(struct clk *clk);
extern struct clk *omap_clk_get_by_name(const char *name);
extern int omap_clk_enable_autoidle_all(void);
--
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
[PATCHv3 4/9] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |3 ++
arch/arm/mach-omap2/pm44xx.c |3 ++
arch/arm/mach-omap2/powerdomain.c | 54 +
arch/arm/mach-omap2/powerdomain.h |3 ++
4 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a34023d..b746fe0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -757,6 +757,9 @@ int __init omap3_pm_init(void)
omap_pm_suspend = omap3_pm_suspend;
#endif
+ /* Notify pwrdm usecounters about active CPU */
+ pwrdm_cpu_wakeup();
+
arm_pm_idle = omap3_pm_idle;
omap3_idle_init();
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ea24174..45eef2d 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -206,6 +206,9 @@ int __init omap4_pm_init(void)
omap_pm_suspend = omap4_pm_suspend;
#endif
+ /* Notify pwrdm usecounters about active CPU */
+ pwrdm_cpu_wakeup();
+
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 317bea1..2a2237c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -47,6 +47,7 @@ enum {
static LIST_HEAD(pwrdm_list);
static struct pwrdm_ops *arch_pwrdm;
+static struct powerdomain *mpu_pwrdm, *core_pwrdm;
/* Private functions */
@@ -1008,11 +1009,15 @@ void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
int pwrdm_pre_transition(void)
{
pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
+ /* Decrease mpu / core usecounts to indicate we are entering idle */
+ pwrdm_cpu_idle();
return 0;
}
int pwrdm_post_transition(void)
{
+ /* Increase mpu / core usecounts to indicate we are leaving idle */
+ pwrdm_cpu_wakeup();
pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
@@ -1092,3 +1097,52 @@ bool pwrdm_can_ever_lose_context(struct powerdomain
*pwrdm)
return 0;
}
+
+static void pwrdm_get_idle_cycle_pwrdms(void)
+{
+ mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
+ if (!mpu_pwrdm)
+ pr_err(%s: failed to get mpu_pwrdm\n, __func__);
+
+ core_pwrdm = pwrdm_lookup(core_pwrdm);
+ if (!core_pwrdm)
+ pr_err(%s: failed to get core_pwrdm\n, __func__);
+}
+
+/**
+ * pwrdm_cpu_wakeup - notify pwrdm usecounters about active CPU
+ *
+ * This function must be called just after a CPU has become active.
+ * Some powerdomains have static dependencies with MPU idle cycle,
+ * namely mpu_pwrdm and core_pwrdm. These powerdomains will get
+ * their usecounts increased / decreased each sleep cycle so that
+ * they reach 0 just before all CPUs have reached idle, and wake-up
+ * right after it. This allows the dependent voltage domains to
+ * follow idle cycle properly and trigger their callbacks for
+ * sleep / wakeup, which in turn will control e.g. auto retention
+ * feature.
+ */
+void pwrdm_cpu_wakeup(void)
+{
+ if (!mpu_pwrdm || !core_pwrdm)
+ pwrdm_get_idle_cycle_pwrdms();
+
+ pwrdm_clkdm_enable(mpu_pwrdm);
+ pwrdm_clkdm_enable(core_pwrdm);
+}
+
+/**
+ * pwrdm_cpu_idle - notify pwrdm usecounters about idling CPU
+ *
+ * This function must be called just before CPU is about to idle.
+ * Similar to pwrdm_cpu_wakeup, this is used to make sure the idle
+ * cycle dependent powerdomains follow the sleep cycle properly.
+ */
+void pwrdm_cpu_idle(void)
+{
+ if (!mpu_pwrdm || !core_pwrdm)
+ pwrdm_get_idle_cycle_pwrdms();
+
+ pwrdm_clkdm_disable(mpu_pwrdm);
+ pwrdm_clkdm_disable(core_pwrdm);
+}
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 705b983..ecf7d3d 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -220,6 +220,9 @@ int pwrdm_post_transition(void);
void pwrdm_clkdm_enable(struct powerdomain *pwrdm);
void pwrdm_clkdm_disable(struct powerdomain *pwrdm);
+void pwrdm_cpu_wakeup(void);
+void pwrdm_cpu_idle(void);
+
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
--
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
[PATCHv3 0/9] ARM: OMAP3+: pwrdm changes for usecounting
Hi, Refreshed the patches against latest mainline kernel, and did some updates mainly proposed by Nishanth Menon n...@ti.com. Changes compared to previous version: patch 1: - added check against null pointer patch 2: - added BUG_ON in case clkdm / pwrdm usecount goes negative patch 3: - added BUG_ON in case voltdm usecount goes negative - removed smartreflex enable / disable from voltdm code (this should be added in a separate patch once this is deemed safe) - changed target_state from int to u8 patch 4: - changed idle loop count initializations to happen synchronously with PM init, this avoids potential trouble in a case where a CPU would enter idle before usecount init for the idle has been done - added functions pwrdm_cpu_wakeup + pwrdm_cpu_idle to be called from idle cycle patch 7: - changed flag name from CLKDM_NO_MANUAL_TRANS to CLKDM_SKIP_MANUAL_TRANS patch 9: - added as new patch, would appreciate testing for this one! Tested on omap3 beagle + boot tested on omap4460 panda es. Previous version of this set had some issues with omap3430 devices (n900), which might have been caused by improper clock handling or security on these devices. I can't test these patches myself on n900, so if someone could do this that would be extra nice. git tree also available: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-pwrdm-changes-v3 -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
[PATCHv3 3/9] ARM: OMAP3+: voltage: add support for voltagedomain usecounts
These are updated based on powerdomain usecounts. Also added support
for voltdm-sleep and voltdm-wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |6 +++-
arch/arm/mach-omap2/voltage.c | 56 +
arch/arm/mach-omap2/voltage.h | 11 +++
3 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 4800483..317bea1 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -986,7 +986,8 @@ void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
if (!pwrdm)
return;
- atomic_inc(pwrdm-usecount);
+ if (atomic_inc_return(pwrdm-usecount) == 1)
+ voltdm_pwrdm_enable(pwrdm-voltdm.ptr);
}
void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
@@ -998,6 +999,9 @@ void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
val = atomic_dec_return(pwrdm-usecount);
+ if (!val)
+ voltdm_pwrdm_disable(pwrdm-voltdm.ptr);
+
BUG_ON(val 0);
}
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 4dc60e8..8c6439b 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -38,6 +38,7 @@
#include voltage.h
#include powerdomain.h
+#include smartreflex.h
#include vc.h
#include vp.h
@@ -340,6 +341,61 @@ int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct
powerdomain *pwrdm)
}
/**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount reaches
+ * 1, the domain is awakened from idle and the function will call the
+ * voltagedomain-wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+ if (!voltdm)
+ return;
+
+ if (atomic_inc_return(voltdm-usecount) == 1) {
+ if (voltdm-wakeup)
+ voltdm-wakeup(voltdm);
+ }
+}
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain-sleep callback, and calculate the overall target
+ * state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+ u8 target_state = PWRDM_POWER_OFF;
+ int state;
+ struct powerdomain *pwrdm;
+ int val;
+
+ if (!voltdm)
+ return;
+
+ val = atomic_dec_return(voltdm-usecount);
+
+ BUG_ON(val 0);
+
+ if (val == 0) {
+ /* Determine target state for voltdm */
+ list_for_each_entry(pwrdm, voltdm-pwrdm_list, voltdm_node) {
+ state = pwrdm_read_next_pwrst(pwrdm);
+ if (state target_state)
+ target_state = state;
+ }
+ voltdm-target_state = target_state;
+ if (voltdm-sleep)
+ voltdm-sleep(voltdm);
+ }
+}
+
+/**
* voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
* @voltdm: struct voltagedomain * to iterate over
* @fn: callback function *
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 16a1b09..c1f4ae8 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -54,10 +54,14 @@ struct omap_vfsm_instance {
* @pwrdm_list: list_head linking all powerdomains in this voltagedomain
* @vc: pointer to VC channel associated with this voltagedomain
* @vp: pointer to VP associated with this voltagedomain
+ * @usecount: number of users for this voltagedomain
+ * @target_state: calculated target state for the children of this domain
* @read: read a VC/VP register
* @write: write a VC/VP register
* @read: read-modify-write a VC/VP register
* @sys_clk: system clock name/frequency, used for various timing calculations
+ * @sleep: function to call once the domain enters idle
+ * @wakeup: function to call once the domain wakes up from idle
* @scale: function used to scale the voltage of the voltagedomain
* @nominal_volt: current nominal voltage for this voltage domain
* @volt_data: voltage table having the distinct voltages supported
@@ -73,6 +77,9 @@ struct voltagedomain {
struct omap_vp_instance *vp;
struct omap_voltdm_pmic *pmic;
+ atomic_t usecount;
+ u8 target_state;
+
/* VC/VP register access functions: SoC specific */
u32 (*read) (u8
[PATCHv6 00/14] ARM: OMAP3+: auto ret / auto off support
Hi, This set applies on top of the pwrdm / voltdm usecounting fixes set. Contains some fixes proposed mainly by Nishanth Menon n...@ti.com. http://marc.info/?l=linux-omapm=133847159830867w=2 Changes compared to previous version: - huge patch #3 in set v5 was split into patches 3...6 - dropped omap4 pmic_setup time params, as they are currently not needed (reset value is okay for these), once a board that requires support for this is added, the oscillator setup time calculations should be modified as the pmic_setup time is actually impacting these patch 1: - changed calculation to use DIV_ROUND_UP patch 2: - changed the patch not to alter the parameters, just rename them patch 3...6: - split from patch #3 - separated omap3 / omap4 specific code to their own patches - added support for voltsetup_off_reg for omap4 patch 7: - added error check against null pointers patch 9: - use DIV_ROUND_UP_ULL instead of manual formula patch 10: - new patch, originally part of patch #2 patch set available also via git: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-voltdm-v6 Tested on omap3 beagle, boot tested on omap4460 panda es. -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
[PATCHv6 01/14] ARM: OMAP3+: PM: VP: use uV for max and min voltage limits
From: Nishanth Menon n...@ti.com
Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific for TWL when copied over to
such an implementation causes the system to crash as the MSB bit
was 0 and the voltage got disabled!.
Instead we use actual values and depend on the convertion routines
to abstract out the eccentricities of each PMIC.
With this, we can now move the voltages to a common location in
voltage.h as they are no longer dependent on PMICs and expect the
PMIC's conversion routines to set a cap if the voltage is out of
reach for the PMIC.
Reported-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 17 -
arch/arm/mach-omap2/voltage.h | 22 --
arch/arm/mach-omap2/vp.c |4 ++--
3 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index f515a1a..df4e7c3 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -30,16 +30,6 @@
#define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14
-#define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42
-#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
-
-#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3c
-#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30
-
#define OMAP4_SRI2C_SLAVE_ADDR 0x12
#define OMAP4_VDD_MPU_SR_VOLT_REG 0x55
#define OMAP4_VDD_MPU_SR_CMD_REG 0x56
@@ -53,13 +43,6 @@
#define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39
-#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 0x2D
-#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 0x28
-
static bool is_offset_valid;
static u8 smps_offset;
/*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index c1f4ae8..a0efab7 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -118,6 +118,24 @@ struct omap_volt_data {
u8 vp_errgain;
};
+/* Min and max voltages from OMAP perspective */
+#define OMAP3430_VP1_VLIMITTO_VDDMIN 85
+#define OMAP3430_VP1_VLIMITTO_VDDMAX 1425000
+#define OMAP3430_VP2_VLIMITTO_VDDMIN 90
+#define OMAP3430_VP2_VLIMITTO_VDDMAX 115
+
+#define OMAP3630_VP1_VLIMITTO_VDDMIN 90
+#define OMAP3630_VP1_VLIMITTO_VDDMAX 135
+#define OMAP3630_VP2_VLIMITTO_VDDMIN 90
+#define OMAP3630_VP2_VLIMITTO_VDDMAX 120
+
+#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 141
+#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 126
+#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 83
+#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 120
+
/**
* struct omap_voltdm_pmic - PMIC specific data required by voltage driver.
* @slew_rate: PMIC slew rate (in uv/us)
@@ -144,8 +162,8 @@ struct omap_voltdm_pmic {
u8 vp_erroroffset;
u8 vp_vstepmin;
u8 vp_vstepmax;
- u8 vp_vddmin;
- u8 vp_vddmax;
+ u32 vp_vddmin;
+ u32 vp_vddmax;
u8 vp_timeout_us;
bool i2c_high_speed;
u8 i2c_mcode;
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index f95c1ba..40b3dcc 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -58,8 +58,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
sys_clk_rate = voltdm-sys_clk.rate / 1000;
timeout = (sys_clk_rate * voltdm-pmic-vp_timeout_us) / 1000;
- vddmin = voltdm-pmic-vp_vddmin;
- vddmax = voltdm-pmic-vp_vddmax;
+ vddmin = voltdm-pmic-uv_to_vsel(voltdm-pmic-vp_vddmin);
+ vddmax = voltdm-pmic-uv_to_vsel(voltdm-pmic-vp_vddmax);
waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate,
1000 * voltdm-pmic-slew_rate);
--
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
[PATCHv6 02/14] ARM: OMAP: voltage: renamed vp_vddmin and vp_vddmax fields
These are now called vddmin and vddmax, as these fields will be used
globally for selecting voltage ranges for a pmic channel, and not
only for voltage processor.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 28 ++--
arch/arm/mach-omap2/voltage.h |4 ++--
arch/arm/mach-omap2/vp.c |4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index df4e7c3..c38a530 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -149,8 +149,8 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
+ .vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
+ .vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_MPU_SR_CONTROL_REG,
@@ -170,8 +170,8 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
+ .vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_CORE_SR_CONTROL_REG,
@@ -191,8 +191,8 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
+ .vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
@@ -213,8 +213,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
+ .vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
@@ -235,8 +235,8 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+ .vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
@@ -272,10 +272,10 @@ int __init omap3_twl_init(void)
return -ENODEV;
if (cpu_is_omap3630()) {
- omap3_mpu_pmic.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
- omap3_mpu_pmic.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
- omap3_core_pmic.vp_vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
- omap3_core_pmic.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
+ omap3_mpu_pmic.vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
+ omap3_mpu_pmic.vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
+ omap3_core_pmic.vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
+ omap3_core_pmic.vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
/*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index a0efab7..e7f71ff 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@
[PATCHv6 04/14] ARM: OMAP3: VC: calculate ramp times
OMAP3 VC code now uses voltage deltas + slew rates for calculating actual
ramp times for voltage changes. Previously a static value was used.
Two calculation methods are provided: i2c_timings and off_timings.
I2C timings are used during retention or off mode transition which
is initiated over I2C, and OFF timings are used if PMIC signal
(nsleep) is used to control all the off mode voltages at the same time.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 108 ++---
arch/arm/mach-omap2/vc.h |1 -
2 files changed, 91 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index a1e0fd6..bba0d7c 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -206,29 +206,109 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
return 0;
}
-static void __init omap3_vfsm_init(struct voltagedomain *voltdm)
+/**
+ * omap3_set_i2c_timings - sets i2c sleep timings for a channel
+ * @voltdm: channel to configure
+ * @off_mode: select whether retention or off mode values used
+ *
+ * Calculates and sets up voltage controller to use I2C based
+ * voltage scaling for sleep modes. This can be used for either off mode
+ * or retention. Off mode has additionally an option to use sys_off_mode
+ * pad, which uses a global signal to program the whole power IC to
+ * off-mode.
+ */
+static void omap3_set_i2c_timings(struct voltagedomain *voltdm, bool off_mode)
{
+ unsigned long voltsetup1;
+ u32 tgt_volt;
+
+ if (off_mode)
+ tgt_volt = voltdm-vc_param-off;
+ else
+ tgt_volt = voltdm-vc_param-ret;
+
+ voltsetup1 = (voltdm-vc_param-on - tgt_volt) /
+ voltdm-pmic-slew_rate;
+
+ voltsetup1 = voltsetup1 * voltdm-sys_clk.rate / 8 / 100 + 1;
+
+ voltdm-rmw(voltdm-vfsm-voltsetup_mask,
+ voltsetup1 __ffs(voltdm-vfsm-voltsetup_mask),
+ voltdm-vfsm-voltsetup_reg);
+
/*
-* Voltage Manager FSM parameters init
-* XXX This data should be passed in from the board file
+* pmic is not controlling the voltage scaling during retention,
+* thus set voltsetup2 to 0
*/
- voltdm-write(OMAP3_CLKSETUP, OMAP3_PRM_CLKSETUP_OFFSET);
- voltdm-write(OMAP3_VOLTOFFSET, OMAP3_PRM_VOLTOFFSET_OFFSET);
- voltdm-write(OMAP3_VOLTSETUP2, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ voltdm-write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
}
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+/**
+ * omap3_set_off_timings - sets off-mode timings for a channel
+ * @voltdm: channel to configure
+ *
+ * Calculates and sets up off-mode timings for a channel. Off-mode
+ * can use either I2C based voltage scaling, or alternatively
+ * sys_off_mode pad can be used to send a global command to power IC.
+ * This function first checks which mode is being used, and calls
+ * omap3_set_i2c_timings() if the system is using I2C control mode.
+ * sys_off_mode has the additional benefit that voltages can be
+ * scaled to zero volt level with TWL4030 / TWL5030, I2C can only
+ * scale to 600mV.
+ */
+static void omap3_set_off_timings(struct voltagedomain *voltdm)
{
- static bool is_initialized;
+ unsigned long clksetup;
+ unsigned long voltsetup2;
+ unsigned long voltsetup2_old;
+ u32 val;
- if (is_initialized)
+ /* check if sys_off_mode is used to control off-mode voltages */
+ val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
+ if (!(val OMAP3430_SEL_OFF_MASK)) {
+ /* No, omap is controlling them over I2C */
+ omap3_set_i2c_timings(voltdm, true);
return;
+ }
- omap3_vfsm_init(voltdm);
+ clksetup = voltdm-read(OMAP3_PRM_CLKSETUP_OFFSET);
- is_initialized = true;
+ /* voltsetup 2 in us */
+ voltsetup2 = voltdm-vc_param-on / voltdm-pmic-slew_rate;
+
+ /* convert to 32k clk cycles */
+ voltsetup2 = DIV_ROUND_UP(voltsetup2 * 32768, 100);
+
+ voltsetup2_old = voltdm-read(OMAP3_PRM_VOLTSETUP2_OFFSET);
+
+ /*
+* Update voltsetup2 if higher than current value (needed because
+* we have multiple channels with different ramp times), also
+* update voltoffset always to value recommended by TRM
+*/
+ if (voltsetup2 voltsetup2_old) {
+ voltdm-write(voltsetup2, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ voltdm-write(clksetup - voltsetup2,
+ OMAP3_PRM_VOLTOFFSET_OFFSET);
+ } else
+ voltdm-write(clksetup - voltsetup2_old,
+ OMAP3_PRM_VOLTOFFSET_OFFSET);
+
+ /*
+* omap is not controlling voltage scaling during off-mode,
+* thus set voltsetup1 to 0
+*/
+ voltdm-rmw(voltdm-vfsm-voltsetup_mask, 0,
+ voltdm-vfsm-voltsetup_reg);
+
+ /*
[PATCHv6 05/14] ARM: OMAP4: voltage: add support for VOLTSETUP_x_OFF register
OMAP4 has two VOLTSETUP registers. One is controlling retention and
sleep voltage setup times, the other one off mode setup times. Both
of these need to be setup for stable behavior of the device.
The code setting up the new register will be added in the next
patch.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/voltage.h |2 ++
arch/arm/mach-omap2/voltagedomains44xx_data.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 5381b35..d2d5b2b 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -38,12 +38,14 @@ struct powerdomain;
* data
* @voltsetup_mask: SETUP_TIME* bitmask in the PRM_VOLTSETUP* register
* @voltsetup_reg: register offset of PRM_VOLTSETUP from PRM base
+ * @voltsetup_off_reg: register offset of PRM_VOLTSETUP_OFF from PRM base
*
* XXX What about VOLTOFFSET/VOLTCTRL?
*/
struct omap_vfsm_instance {
u32 voltsetup_mask;
u8 voltsetup_reg;
+ u8 voltsetup_off_reg;
};
/**
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index a2d7d9c..7da35a6 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -34,14 +34,17 @@
static const struct omap_vfsm_instance omap4_vdd_mpu_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
+ .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_MPU_OFF_OFFSET,
};
static const struct omap_vfsm_instance omap4_vdd_iva_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_IVA_RET_SLEEP_OFFSET,
+ .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_IVA_OFF_OFFSET,
};
static const struct omap_vfsm_instance omap4_vdd_core_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_CORE_RET_SLEEP_OFFSET,
+ .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_CORE_OFF_OFFSET,
};
static struct voltagedomain omap4_voltdm_mpu = {
--
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
[PATCHv6 03/14] ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomains
These new structs will hold the sleep voltage levels (omap_vc_params)
and voltage processor min / max voltages (omap_vp_params.) Previously
these were part of the PMIC struct, but they do not really belong there,
as they are OMAP chip specific, not PMIC specific parameters. voltdm
code is also changed to use the new structs.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c| 20 --
arch/arm/mach-omap2/vc.c | 35 ++---
arch/arm/mach-omap2/vc.h |7 +
arch/arm/mach-omap2/vc3xxx_data.c | 22 +++
arch/arm/mach-omap2/vc44xx_data.c | 28
arch/arm/mach-omap2/voltage.h | 18 ++---
arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +++
arch/arm/mach-omap2/voltagedomains44xx_data.c |8 +
arch/arm/mach-omap2/vp.h |7 +
arch/arm/mach-omap2/vp3xxx_data.c | 10 +++
arch/arm/mach-omap2/vp44xx_data.c | 15 ++
11 files changed, 147 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index c38a530..dca1d66 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -141,10 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt= 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
.volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
@@ -162,10 +158,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt= 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
.volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
@@ -183,10 +175,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt= 1375000,
- .onlp_volt = 1375000,
- .ret_volt = 83,
- .off_volt = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -205,10 +193,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt= 1188000,
- .onlp_volt = 1188000,
- .ret_volt = 83,
- .off_volt = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -227,10 +211,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt= 120,
- .onlp_volt = 120,
- .ret_volt = 83,
- .off_volt = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 84da34f..a1e0fd6 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -137,6 +137,8 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm,
vc_cmdval |= (*target_vsel vc-common-cmd_on_shift);
voltdm-write(vc_cmdval, vc-cmdval_reg);
+ voltdm-vc_param-on = target_volt;
+
omap_vp_update_errorgain(voltdm, target_volt);
return 0;
@@ -286,6 +288,30 @@ static void __init omap_vc_i2c_init(struct voltagedomain
*voltdm)
initialized = true;
}
+/**
+ * omap_vc_calc_vsel - calculate vsel value for a channel
+ * @voltdm: channel to calculate value for
+ * @uvolt: microvolt value to convert to vsel
+ *
+ * Converts a microvolt value to vsel value for the used PMIC.
+ * This checks whether the microvolt value is out of bounds, and
+ * adjusts the value accordingly. If unsupported value detected,
+ * warning is thrown.
+ */
+static u8
[PATCHv6 07/14] ARM: OMAP: add support for oscillator setup
This contains startup and shutdown times for the oscillator. By default
use ULONG_MAX. Oscillator setup is used for calculating and setting up
latencies for sleep modes that disable oscillator.
Based on a patch from Nishanth Menon n...@ti.com.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.c | 30 ++
arch/arm/mach-omap2/pm.h |8
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..05ec8ca 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -38,6 +38,36 @@ static struct omap_device_pm_latency *pm_lats;
*/
int (*omap_pm_suspend)(void);
+/**
+ * struct omap2_oscillator - Describe the board main oscillator latencies
+ * @startup_time: oscillator startup latency
+ * @shutdown_time: oscillator shutdown latency
+ */
+struct omap2_oscillator {
+ u32 startup_time;
+ u32 shutdown_time;
+};
+
+static struct omap2_oscillator oscillator = {
+ .startup_time = ULONG_MAX,
+ .shutdown_time = ULONG_MAX,
+};
+
+void omap_pm_setup_oscillator(u32 tstart, u32 tshut)
+{
+ oscillator.startup_time = tstart;
+ oscillator.shutdown_time = tshut;
+}
+
+void omap_pm_get_oscillator(u32 *tstart, u32 *tshut)
+{
+ if (!tstart || !tshut)
+ return;
+
+ *tstart = oscillator.startup_time;
+ *tshut = oscillator.shutdown_time;
+}
+
static int __init _init_omap_device(char *name)
{
struct omap_hwmod *oh;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 312f2de..af1234c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -121,4 +121,12 @@ static inline int omap4_twl_init(void)
}
#endif
+#ifdef CONFIG_PM
+extern void omap_pm_setup_oscillator(u32 tstart, u32 tshut);
+extern void omap_pm_get_oscillator(u32 *tstart, u32 *tshut);
+#else
+static inline void omap_pm_setup_oscillator(u32 tstart, u32 tshut) { }
+static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { }
+#endif
+
#endif
--
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
[PATCHv6 09/14] ARM: OMAP3+: voltage: use oscillator data to calculate setup times
We now use the previously defined oscillator setup / shutdown times
to calculate the register values for CLKSETUP.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 62 ++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 0a37673..5fe2ff1 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -11,14 +11,20 @@
#include linux/delay.h
#include linux/init.h
#include linux/bug.h
+#include linux/io.h
+
+#include asm/div64.h
#include plat/cpu.h
+#include iomap.h
#include voltage.h
#include vc.h
#include prm-regbits-34xx.h
#include prm-regbits-44xx.h
#include prm44xx.h
+#include pm.h
+#include scrm44xx.h
/**
* struct omap_vc_channel_cfg - describe the cfg_channel bitfield
@@ -206,6 +212,18 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
return 0;
}
+/* Convert microsecond value to number of 32kHz clock cycles */
+static inline u32 omap_usec_to_32k(u32 usec)
+{
+ return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
+}
+
+/* Set oscillator setup time for omap3 */
+static void omap3_set_clksetup(u32 usec, struct voltagedomain *voltdm)
+{
+ voltdm-write(omap_usec_to_32k(usec), OMAP3_PRM_CLKSETUP_OFFSET);
+}
+
/**
* omap3_set_i2c_timings - sets i2c sleep timings for a channel
* @voltdm: channel to configure
@@ -222,6 +240,12 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
unsigned long voltsetup1;
u32 tgt_volt;
+ /*
+* Oscillator is shut down only if we are using sys_off_mode pad,
+* thus we set a minimal setup time here
+*/
+ omap3_set_clksetup(1, voltdm);
+
if (off_mode)
tgt_volt = voltdm-vc_param-off;
else
@@ -262,6 +286,7 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
unsigned long voltsetup2;
unsigned long voltsetup2_old;
u32 val;
+ u32 tstart, tshut;
/* check if sys_off_mode is used to control off-mode voltages */
val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
@@ -271,6 +296,9 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
return;
}
+ omap_pm_get_oscillator(tstart, tshut);
+ omap3_set_clksetup(tstart, voltdm);
+
clksetup = voltdm-read(OMAP3_PRM_CLKSETUP_OFFSET);
/* voltsetup 2 in us */
@@ -367,6 +395,30 @@ static u32 omap4_calc_volt_ramp(struct voltagedomain
*voltdm, u32 voltage_diff)
}
/**
+ * omap4_usec_to_val_scrm - convert microsecond value to SCRM module bitfield
+ * @usec: microseconds
+ * @shift: number of bits to shift left
+ * @mask: bitfield mask
+ *
+ * Converts microsecond value to OMAP4 SCRM bitfield. Bitfield is
+ * shifted to requested position, and checked agains the mask value.
+ * If larger, forced to the max value of the field (i.e. the mask itself.)
+ * Returns the SCRM bitfield value.
+ */
+static u32 omap4_usec_to_val_scrm(u32 usec, int shift, u32 mask)
+{
+ u32 val;
+
+ val = omap_usec_to_32k(usec) shift;
+
+ /* Check for overflow, if yes, force to max value */
+ if (val mask)
+ val = mask;
+
+ return val;
+}
+
+/**
* omap4_set_timings - set voltage ramp timings for a channel
* @voltdm: channel to configure
* @off_mode: whether off-mode values are used
@@ -378,6 +430,7 @@ static void omap4_set_timings(struct voltagedomain *voltdm,
bool off_mode)
u32 val;
u32 ramp;
int offset;
+ u32 tstart, tshut;
if (off_mode) {
ramp = omap4_calc_volt_ramp(voltdm,
@@ -399,6 +452,15 @@ static void omap4_set_timings(struct voltagedomain
*voltdm, bool off_mode)
val |= ramp OMAP4430_RAMP_UP_COUNT_SHIFT;
voltdm-write(val, offset);
+
+ omap_pm_get_oscillator(tstart, tshut);
+
+ val = omap4_usec_to_val_scrm(tstart, OMAP4_SETUPTIME_SHIFT,
+ OMAP4_SETUPTIME_MASK);
+ val |= omap4_usec_to_val_scrm(tshut, OMAP4_DOWNTIME_SHIFT,
+ OMAP4_DOWNTIME_MASK);
+
+ __raw_writel(val, OMAP4_SCRM_CLKSETUPTIME);
}
/* OMAP4 specific voltage init functions */
--
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
[PATCHv6 10/14] ARM: OMAP: TWL: change the vddmin / vddmax voltages to spec
As vddmin / vddmax voltages for the pmic only describe the pmic
capabilities now, change the voltages to be according to spec.
TWL data manuals give following values:
TWL4030 (SWCS019L) : VDD1: 600mV ... 1450mV, VDD2: 600mV ... 1500mV
TWL5030 (SWCS030E) : VDD1: 600mV ... 1450mV, VDD2: 600mV ... 1500mV
TWL6030 (SWCS045A) : 0V ... 2100mV
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 27 ++-
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index dca1d66..188f210 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -145,8 +145,8 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
- .vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
+ .vddmin = 60,
+ .vddmax = 145,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_MPU_SR_CONTROL_REG,
@@ -162,8 +162,8 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
- .vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vddmin = 60,
+ .vddmax = 145,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_CORE_SR_CONTROL_REG,
@@ -179,8 +179,8 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
- .vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 210,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
@@ -197,8 +197,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
- .vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 210,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
@@ -215,8 +215,8 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
- .vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 210,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
@@ -251,13 +251,6 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
- if (cpu_is_omap3630()) {
- omap3_mpu_pmic.vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
- omap3_mpu_pmic.vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
- omap3_core_pmic.vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
- omap3_core_pmic.vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
- }
-
/*
* The smartreflex bit on twl4030 specifies if the setting of voltage
* is done over the I2C_SR path. Since this setting is independent of
--
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
[PATCHv6 12/14] ARM: OMAP: beagle: set oscillator startup time to 10ms for rev c4
Based on the oscillator datasheet for this device. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 09aa4b1..4737234 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -488,6 +488,9 @@ static void __init beagle_opp_init(void) opp_disable(mpu_dev, 72000); opp_disable(iva_dev, 52000); } + + /* Set oscillator startup time to 10ms, shutdown not used */ + omap_pm_setup_oscillator(1, ULONG_MAX); } /* Custom OPP enabled for all xM versions */ -- 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
[PATCHv6 11/14] TEMP: ARM: OMAP3: beagle rev-c4: enable OPP6
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 79c6909..09aa4b1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -461,6 +461,35 @@ static void __init beagle_opp_init(void)
return;
}
+ if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+ struct device *mpu_dev, *iva_dev;
+
+ mpu_dev = omap_device_get_by_hwmod_name(mpu);
+ iva_dev = omap_device_get_by_hwmod_name(iva);
+
+ if (!mpu_dev || !iva_dev) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mpu_dev, iva_dev);
+ return;
+ }
+ /* Enable MPU 720MHz opp */
+ r = opp_enable(mpu_dev, 72000);
+
+ /* Enable IVA 520MHz opp */
+ r |= opp_enable(iva_dev, 52000);
+
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+ opp_disable(mpu_dev, 72000);
+ opp_disable(iva_dev, 52000);
+ }
+ }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, OMAP3430_VDD_MPU_OPP5_UV),
+ /* MPU OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(mpu, false, 72000, OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(iva, true, 4, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, OMAP3430_VDD_MPU_OPP5_UV),
+ /* DSP OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(iva, false, 52000, OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
--
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
[PATCHv6 06/14] ARM: OMAP4: VC: calculate ramp times
OMAP4 VC code now uses voltage deltas + slew rates for calculating
actual ramp times for voltage changes. Both retention / sleep +
off mode voltage ramp times are setup at the same time during
initialization.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 94 ++
1 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index bba0d7c..0a37673 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -310,12 +310,106 @@ static void __init omap3_vc_init_channel(struct
voltagedomain *voltdm)
omap3_set_off_timings(voltdm);
}
+/**
+ * omap4_calc_volt_ramp - calculates voltage ramping delays on omap4
+ * @voltdm: channel to calculate values for
+ * @voltage_diff: voltage difference in microvolts
+ *
+ * Calculates voltage ramp prescaler + counter values for a voltage
+ * difference on omap4. Returns a field value suitable for writing to
+ * VOLTSETUP register for a channel in following format:
+ * bits[8:9] prescaler ... bits[0:5] counter. See OMAP4 TRM for reference.
+ */
+static u32 omap4_calc_volt_ramp(struct voltagedomain *voltdm, u32 voltage_diff)
+{
+ u32 prescaler;
+ u32 cycles;
+ u32 time;
+
+ time = voltage_diff / voltdm-pmic-slew_rate;
+
+ cycles = voltdm-sys_clk.rate / 1000 * time / 1000;
+
+ cycles /= 64;
+ prescaler = 0;
+
+ /* shift to next prescaler until no overflow */
+
+ /* scale for div 256 = 64 * 4 */
+ if (cycles 63) {
+ cycles /= 4;
+ prescaler++;
+ }
+
+ /* scale for div 512 = 256 * 2 */
+ if (cycles 63) {
+ cycles /= 2;
+ prescaler++;
+ }
+
+ /* scale for div 2048 = 512 * 4 */
+ if (cycles 63) {
+ cycles /= 4;
+ prescaler++;
+ }
+
+ /* check for overflow = invalid ramp time */
+ if (cycles 63) {
+ pr_warning(%s: invalid setuptime for vdd_%s\n, __func__,
+ voltdm-name);
+ return 0;
+ }
+
+ cycles++;
+
+ return (prescaler OMAP4430_RAMP_UP_PRESCAL_SHIFT) |
+ (cycles OMAP4430_RAMP_UP_COUNT_SHIFT);
+}
+
+/**
+ * omap4_set_timings - set voltage ramp timings for a channel
+ * @voltdm: channel to configure
+ * @off_mode: whether off-mode values are used
+ *
+ * Calculates and sets the voltage ramp up / down values for a channel.
+ */
+static void omap4_set_timings(struct voltagedomain *voltdm, bool off_mode)
+{
+ u32 val;
+ u32 ramp;
+ int offset;
+
+ if (off_mode) {
+ ramp = omap4_calc_volt_ramp(voltdm,
+ voltdm-vc_param-on - voltdm-vc_param-off);
+ offset = voltdm-vfsm-voltsetup_off_reg;
+ } else {
+ ramp = omap4_calc_volt_ramp(voltdm,
+ voltdm-vc_param-on - voltdm-vc_param-ret);
+ offset = voltdm-vfsm-voltsetup_reg;
+ }
+
+ if (!ramp)
+ return;
+
+ val = voltdm-read(offset);
+
+ val |= ramp OMAP4430_RAMP_DOWN_COUNT_SHIFT;
+
+ val |= ramp OMAP4430_RAMP_UP_COUNT_SHIFT;
+
+ voltdm-write(val, offset);
+}
+
/* OMAP4 specific voltage init functions */
static void __init omap4_vc_init_channel(struct voltagedomain *voltdm)
{
static bool is_initialized;
u32 vc_val;
+ omap4_set_timings(voltdm, true);
+ omap4_set_timings(voltdm, false);
+
if (is_initialized)
return;
--
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
[PATCHv6 08/14] ARM: OMAP3+: vp: use new vp_params for calculating vddmin and vddmax
Now we select the vddmin and vddmax values based on both pmic and voltage processor data, this allows usage of different power ICs. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/vp.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index c585dfb..c9277c3 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -58,8 +58,10 @@ void __init omap_vp_init(struct voltagedomain *voltdm) sys_clk_rate = voltdm-sys_clk.rate / 1000; timeout = (sys_clk_rate * voltdm-pmic-vp_timeout_us) / 1000; - vddmin = voltdm-pmic-uv_to_vsel(voltdm-pmic-vddmin); - vddmax = voltdm-pmic-uv_to_vsel(voltdm-pmic-vddmax); + vddmin = max(voltdm-vp_param-vddmin, voltdm-pmic-vddmin); + vddmax = min(voltdm-vp_param-vddmax, voltdm-pmic-vddmax); + vddmin = voltdm-pmic-uv_to_vsel(vddmin); + vddmax = voltdm-pmic-uv_to_vsel(vddmax); waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate, 1000 * voltdm-pmic-slew_rate); -- 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
[PATCHv6 13/14] ARM: OMAP3: vc: auto_ret / auto_off support
Voltage code will now enable / disable auto_ret / auto_off dynamically
according to the voltagedomain usecounts. This is accomplished via
the usage of the voltdm callback functions for sleep / wakeup.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/vc.c | 139 +++--
1 files changed, 120 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 5fe2ff1..78a359e 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -12,6 +12,7 @@
#include linux/init.h
#include linux/bug.h
#include linux/io.h
+#include linux/string.h
#include asm/div64.h
@@ -240,12 +241,6 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
unsigned long voltsetup1;
u32 tgt_volt;
- /*
-* Oscillator is shut down only if we are using sys_off_mode pad,
-* thus we set a minimal setup time here
-*/
- omap3_set_clksetup(1, voltdm);
-
if (off_mode)
tgt_volt = voltdm-vc_param-off;
else
@@ -259,12 +254,6 @@ static void omap3_set_i2c_timings(struct voltagedomain
*voltdm, bool off_mode)
voltdm-rmw(voltdm-vfsm-voltsetup_mask,
voltsetup1 __ffs(voltdm-vfsm-voltsetup_mask),
voltdm-vfsm-voltsetup_reg);
-
- /*
-* pmic is not controlling the voltage scaling during retention,
-* thus set voltsetup2 to 0
-*/
- voltdm-write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
}
/**
@@ -286,7 +275,6 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
unsigned long voltsetup2;
unsigned long voltsetup2_old;
u32 val;
- u32 tstart, tshut;
/* check if sys_off_mode is used to control off-mode voltages */
val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
@@ -296,9 +284,6 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
return;
}
- omap_pm_get_oscillator(tstart, tshut);
- omap3_set_clksetup(tstart, voltdm);
-
clksetup = voltdm-read(OMAP3_PRM_CLKSETUP_OFFSET);
/* voltsetup 2 in us */
@@ -328,17 +313,133 @@ static void omap3_set_off_timings(struct voltagedomain
*voltdm)
*/
voltdm-rmw(voltdm-vfsm-voltsetup_mask, 0,
voltdm-vfsm-voltsetup_reg);
+}
+
+/**
+ * omap3_set_core_ret_timings - set retention timings for core domain
+ * @voltdm: pointer for core voltagedomain struct
+ *
+ * This function is called once core domain is ready to enter
+ * retention. This sets the values for the global setup variables like
+ * oscillator setup time, and the ramp times for voltages.
+ */
+static void omap3_set_core_ret_timings(struct voltagedomain *voltdm)
+{
+ /*
+* Oscillator is not shut down in retention, thus set minimal
+* clock setup time
+*/
+ omap3_set_clksetup(1, voltdm);
- /* voltoffset must be clksetup minus voltsetup2 according to TRM */
- voltdm-write(clksetup - voltsetup2, OMAP3_PRM_VOLTOFFSET_OFFSET);
+ /*
+* Reset voltsetup 2 and voltoffset when entering retention
+* as they are only used when pmic is controlling voltages
+*/
+ voltdm-write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
+ voltdm-write(0, OMAP3_PRM_VOLTOFFSET_OFFSET);
+ omap3_set_i2c_timings(voltdm, false);
}
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+/**
+ * omap3_set_core_off_timings - set off timings for core domain
+ * @voltdm: pointer for core voltagedomain struct
+ *
+ * This function is called once core domain is ready to enter off-mode.
+ * This sets the values for the global setup variables like oscillator
+ * setup time, and the ramp times for voltages.
+ */
+static void omap3_set_core_off_timings(struct voltagedomain *voltdm)
{
+ u32 tstart, tshut;
+
+ omap_pm_get_oscillator(tstart, tshut);
+ omap3_set_clksetup(tstart, voltdm);
omap3_set_off_timings(voltdm);
}
/**
+ * omap3_vc_channel_sleep - idle callback for a voltagedomain
+ * @voltdm: voltage channel that is entering idle
+ *
+ * Prepares voltage channel for entering idle. This gets called from
+ * the voltagedomain code once the usecount for the domain reaches zero.
+ * Function checks the target sleep mode and configures the channel
+ * accordingly.
+ */
+static void omap3_vc_channel_sleep(struct voltagedomain *voltdm)
+{
+ /* Set off timings if entering off */
+ if (voltdm-target_state == PWRDM_POWER_OFF)
+ omap3_set_off_timings(voltdm);
+ else
+ omap3_set_i2c_timings(voltdm, false);
+}
+
+/**
+ * omap3_vc_core_sleep - idle callback for core voltagedomain
+ * @voltdm: pointer to core voltagedomain struct
+ *
+ * Prepares core voltagedomain for idle. This checks the target sleep
+ * mode of the device (highest sleep mode of all powerdomains), and
+ * sets up the device according
[PATCHv6 14/14] ARM: OMAP3+: voltage: remove unused volt_setup_time parameter
This is no longer needed as the ramp times are calculated from
voltage deltas + slew rates.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |5 -
arch/arm/mach-omap2/voltage.h |1 -
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 188f210..ecae989 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -141,7 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
@@ -158,7 +157,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
@@ -175,7 +173,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
@@ -193,7 +190,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
@@ -211,7 +207,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index d2d5b2b..4d02d6e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -155,7 +155,6 @@ struct omap_volt_data {
struct omap_voltdm_pmic {
int slew_rate;
int step_size;
- u16 volt_setup_time;
u16 i2c_slave_addr;
u16 volt_reg_addr;
u16 cmd_reg_addr;
--
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: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi.
On 05/31/2012 04:52 PM, Cousson, Benoit wrote:
On 5/31/2012 2:49 PM, Eduardo Valentin wrote:
Hello,
On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards for
System Control Module (SCM).
...
I believe that CPU-specific bandgap definition should be moved to
bard specific dts.
Mmm, why, since it is CPU specific and not board specific. I has to
be in the SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
if omap4430 bandgap support will be added to omap-bandgap driver the
version of bandgap should specified in dts file. omap4.dtsi is a
common for omap4 boards, that is why I'm suggesting to move bandgap
description to probably board specific file.
OK, I got your point, but in that case we could potentially define a
omap4460.dtsi file.
Another solution is to
determine bandgap type in driver probe function, but in that case
ti,omap4460-bandgap in omap4.dtsi should be replaced to
ti,omap4-bandgap.
Yes, this is the best solution, but that assume that we can identify the
control module version from the HW, which is not necessarily true :-(
The IP_REVISION (offset = 0) value are unfortunately not documented, so we
should read it to check if they are different from omap4430 and 4460.
The bitfield layout in that register is:
IP_REV_MAJOR: 8..10
IP_REV_CUSTOM: 6..7
IP_REV_MINOR: 0..5
The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
CONTROL_GEN_CORE_REVISION: 0x4900
CONTROL_GEN_CORE_HWINFO: 0x0
Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
4460:
[root@(none) ~]# omapconf read 0x4A002000
4A00
[root@(none) ~]# omapconf read 0x4A002004
4470:
[root@(none) ~]# omapconf read 0x4A002000
4B00
[root@(none) ~]# omapconf read 0x4A002004
Nice! We do have a cool progression 1 - 2 - 3 for each revision.
Well at least for the SCM.
Benoit
This patch allows checking of bandgap type dynamically in bandgap driver
probe function by reading omap core control module revision register
CONTROL_GEN_CORE_REVISION. It lets bandgap module to be defined in common
omap4.dtsi, because all cpu specific attributes(irq and tshut number)
were moved to driver.
Patch wasn't tested because I have panda 4430 board.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Index: omap-thermal/arch/arm/boot/dts/omap4.dtsi
===
--- omap-thermal.orig/arch/arm/boot/dts/omap4.dtsi
+++ omap-thermal/arch/arm/boot/dts/omap4.dtsi
@@ -277,9 +277,7 @@
compatible = ti,omap4-control;
ti,hwmods = ctrl_module_core;
bandgap {
- compatible = ti,omap4460-bandgap;
- interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86; /* tshut */
+ compatible = ti,omap4-bandgap;
};
usb {
compatible = ti,omap4-usb-phy;
Index: omap-thermal/drivers/thermal/omap-bandgap.c
===
--- omap-thermal.orig/drivers/thermal/omap-bandgap.c
+++ omap-thermal/drivers/thermal/omap-bandgap.c
@@ -219,12 +219,14 @@ struct omap_temp_sensor {
struct omap_bandgap_data {
boolhas_talert;
boolhas_tshut;
+ int tshut_gpio;
const int *conv_table;
char*fclock_name;
char*div_ck_name;
int sensor_count;
int (*report_temperature)(struct omap_bandgap *bg_ptr, int id);
int (*expose_sensor)(struct omap_bandgap *bg_ptr, int id, char *domain);
+ int irq;
/* this needs to be at the end */
struct omap_temp_sensor sensors[];
@@ -1189,10 +1191,12 @@ static int omap_bandgap_talert_init(stru
static const struct omap_bandgap_data omap4460_data = {
.has_talert = true,
.has_tshut = true,
+ .tshut_gpio = 86,
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
.conv_table = omap4460_adc_to_temp,
.expose_sensor = omap4_thermal_expose_sensor,
+ .irq = 126,
.sensors = {
{
.registers = omap4460_mpu_temp_sensor_registers,
@@ -1206,9 +1210,11 @@ static const struct omap_bandgap_data om
static const struct
Re: [PATCH 1/3] arm/dts: add wdt node for omap3 and omap4
On 05/31/2012 12:51 AM, Xiao Jiang wrote:
Hi Jon and Benoit,
Thanks for reminding, how about below patch?
diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
new file mode 100644
index 000..4272d06
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
@@ -0,0 +1,15 @@
+TI Watchdog Timer (WDT) Controller for OMAP
+
+Required properties:
+- compatible:
+ - ti,omap2-wdt for OMAP2
+ - ti,omap3-wdt for OMAP3
+ - ti,omap4-wdt for OMAP4
+- ti,hwmods: Name of the hwmod associated to the WDT
+
+Examples:
+
+wdt2: wdt@73f98000 {
+ compatible = ti,omap4-wdt;
+ ti,hwmods = wd_timer2;
+};
Yes looks good. Thanks! Minor nit-pick in the example I would just copy
the omap4 node completely with the actual omap4 address :-)
Oops, wrong addr, :). Perhaps we can drop address as you said, since the
right addresses are defined
in wd_timer2 hwmod (see [1]), and wdt also works without the address as
follows.
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f2ab4ea..0017bd8 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -63,5 +63,10 @@
ti,hwmods = uart3;
clock-frequency = 4800;
};
+
+ wdt2: wdt {
+ compatible = ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..dbf8a5b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,10 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ wdt2: wdt {
+ compatible = ti,omap3-wdt, ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..ce74e87 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,10 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ wdt2: wdt {
+ compatible = ti,omap4-wdt, ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
Infos for omap3:
# dmesg|grep Machine
6[0.00] Machine: Generic OMAP3 (Flattened Device Tree), model:
TI OMAP3 EVM (OMAP3530, AM/DM37x)
# dmesg|grep omap_wdt_probe
4[2.552825] in omap_wdt_probe: 299, res-start = 0x48314000
Infos for omap4:
root@localhost:/root dmesg|grep Machine
[0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI
OMAP4 SDP board
root@localhost:/root dmesg|grep omap_wdt_probe
[1.687896] in omap_wdt_probe: 299, res-start = 0x4a314000
So can I drop the wdt addr from dts file? otherwise it is not feasible
to add omap2 wdt node in omap2.dtsi
due to different addrs for omap2420 and omap2430.
Benoit, what is your preference here?
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 4/6] ARM: OMAP4: PMU: Add runtime PM support
Hi Kevin, On 05/30/2012 04:50 PM, Kevin Hilman wrote: [...] I'm guessing you probably know my thoughts since you've already thought through how this should probably look. 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? Kevin P.S. Jon, for readability sake, any objections to moving the PMU device init out of devices.c into pmu.c? devices.c is awful crowded. No objections. I am guessing that pmu was not supported back in the ARM9 days and so this is only really specific to omap2 devices. That being said, should this still go into plat-omap dir or just mach-omap2? 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 4/6] ARM: OMAP4: PMU: Add runtime PM support
Hi 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. I am not sure I follow your last point. Can you elaborate a little more? Thanks 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 4/6] ARM: OMAP4: PMU: Add runtime PM support
Jon Hunter jon-hun...@ti.com writes: Hi Kevin, On 05/30/2012 04:50 PM, Kevin Hilman wrote: [...] I'm guessing you probably know my thoughts since you've already thought through how this should probably look. 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? Kevin P.S. Jon, for readability sake, any objections to moving the PMU device init out of devices.c into pmu.c? devices.c is awful crowded. No objections. I am guessing that pmu was not supported back in the ARM9 days and so this is only really specific to omap2 devices. That being said, should this still go into plat-omap dir or just mach-omap2? I was referring to mach-omap2/devices.c. Probably just pulling out the PMU stuff into mach-omap2/pmu.c will be enough. 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 2/2] ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
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.
Thanks!
Kevin
---
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: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
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.
Cheers
Jon
From b111bcb24737e070ee1ce7ea3d1deb60a4d6f266 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 31 May 2012 13:05:20 -0500
Subject: [PATCH] ARM: PMU: Add runtime PM Support
---
arch/arm/include/asm/pmu.h |2 ++
arch/arm/kernel/perf_event.c | 30 ++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 90114fa..db9f20c 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -43,6 +43,8 @@ struct arm_pmu_platdata {
irq_handler_t pmu_handler);
void (*enable_irq)(int irq);
void (*disable_irq)(int irq);
+ int (*runtime_resume)(struct device *dev);
+ int (*runtime_suspend)(struct device *dev);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 186c8cb..3b2b016 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include asm/cputype.h
#include asm/irq.h
@@ -460,6 +461,8 @@ hw_perf_event_destroy(struct perf_event *event)
armpmu_release_hardware(armpmu);
mutex_unlock(pmu_reserve_mutex);
}
+
+ pm_runtime_put_sync(armpmu-plat_device-dev);
}
static int
@@ -546,6 +549,8 @@ static int armpmu_event_init(struct perf_event *event)
if (armpmu-map_event(event) == -ENOENT)
return -ENOENT;
+ pm_runtime_get_sync(armpmu-plat_device-dev);
+
event-destroy = hw_perf_event_destroy;
if (!atomic_inc_not_zero(active_events)) {
@@ -584,6 +589,26 @@ static void armpmu_disable(struct pmu *pmu)
armpmu-stop();
}
+static int armpmu_runtime_resume(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_resume)
+ return plat-runtime_resume(dev);
+
+ return 0;
+}
+
+static int armpmu_runtime_suspend(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_suspend)
+ return plat-runtime_suspend(dev);
+
+ return 0;
+}
+
static void __init armpmu_init(struct arm_pmu *armpmu)
{
atomic_set(armpmu-active_events, 0);
@@ -650,9 +675,14 @@ static int __devinit armpmu_device_probe(struct
platform_device *pdev)
return 0;
}
+static const struct dev_pm_ops armpmu_dev_pm_ops = {
+ SET_RUNTIME_PM_OPS(armpmu_runtime_suspend, armpmu_runtime_resume, NULL)
+};
+
static struct platform_driver armpmu_driver = {
.driver = {
.name = arm-pmu,
+ .pm = armpmu_dev_pm_ops,
.of_match_table = armpmu_of_device_ids,
},
.probe = armpmu_device_probe,
--
1.7.9.5
--
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 10:05 AM, Jon Hunter wrote: Hi 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. I am not sure I follow your last point. Can you elaborate a little more? By the way, I do see your point now. I have just posted a very simple PM runtime adaption, which I am not sure if this is exactly what you and Kevin have in mind. However, with this implementation we would not need to worry about the mutual exclusion as we don't change the flow. Alternatively, the reserve_pmu() call could be done outside of the runtime pm callbacks. 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 0/2] arm: omap3: am35x: Convert emac to hwmod disable hlt when open
Mark A. Greer mgr...@animalcreek.com writes:
From: Mark A. Greer mgr...@animalcreek.com
These patches convert the davinci emac support for the am35x SoC
to use hwmod and add enable_hlt()/disable_hlt() calls to the
pm_runtime hooks for that driver.
I have converted the davinci_emac driver to use pm_runtime but I
can't formally submit it yet since it requires some changes on the
mach-davinci side that haven't happened yet. I will send it as an
RFC in a reply to this thread.
I haven't seen any patches for the davinci runtime PM support, so I
thought I would do a quick patch to show how easy it is to use some
generic PM core code to manage clocks in runtime PM.
The patch below implments this on davinci but has only been boot tested
on my ancient dm6446 EVM. Combined with Mark's RFC patch to convert
davinci_emac to runtime PM, it was working fine on dm6446 to enable the
emac clocks.
Kevin
From 7a90e650ad8542b7f85076b58703e94bdc058562 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 31 May 2012 09:59:53 -0700
Subject: [PATCH] ARM: davinci: add runtime PM support for clock management
Add runtime PM core support to davinci by using the pm_clk
infrastructure of the PM core.
When runtime PM is enabled, the davinci runtime PM implementation will
use the pm_clk layer to enable/disable clocks on demand. When runtime
PM is disabled, the pm_clk core will automatically enable clocks when
the driver is bound and disable clocks when the driver is unbound.
Cc: Mark A. Greer mgr...@animalcreek.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies on v3.4
arch/arm/mach-davinci/Makefile|1 +
arch/arm/mach-davinci/pm_domain.c | 70 +
2 files changed, 71 insertions(+)
create mode 100644 arch/arm/mach-davinci/pm_domain.c
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..2227eff 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) += board-omapl138-hawk.o
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_SUSPEND) += pm.o sleep.o
+obj-$(CONFIG_HAVE_CLK) += pm_domain.o
diff --git a/arch/arm/mach-davinci/pm_domain.c
b/arch/arm/mach-davinci/pm_domain.c
new file mode 100644
index 000..f34258f
--- /dev/null
+++ b/arch/arm/mach-davinci/pm_domain.c
@@ -0,0 +1,70 @@
+/*
+ * Runtime PM support code for DaVinci
+ *
+ * Author: Kevin Hilman
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/pm_clock.h
+#include linux/platform_device.h
+#include linux/mutex.h
+#include linux/clk.h
+#include linux/err.h
+
+#ifdef CONFIG_PM_RUNTIME
+static int davinci_pm_runtime_suspend(struct device *dev)
+{
+ int ret;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_suspend(dev);
+ if (ret) {
+ pm_generic_runtime_resume(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int davinci_pm_runtime_resume(struct device *dev)
+{
+ dev_dbg(dev, %s\n, __func__);
+ dump_stack();
+
+ pm_clk_resume(dev);
+ return pm_generic_runtime_resume(dev);
+}
+#endif
+
+static struct dev_pm_domain davinci_pm_domain = {
+ .ops = {
+ SET_RUNTIME_PM_OPS(davinci_pm_runtime_suspend,
+ davinci_pm_runtime_resume, NULL)
+ USE_PLATFORM_PM_SLEEP_OPS
+ },
+};
+
+static struct pm_clk_notifier_block platform_bus_notifier = {
+ .pm_domain = davinci_pm_domain,
+};
+
+static int __init davinci_pm_runtime_init(void)
+{
+ pm_clk_add_notifier(platform_bus_type, platform_bus_notifier);
+
+ return 0;
+}
+core_initcall(davinci_pm_runtime_init);
--
1.7.9.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 v2 2/2] arm: omap3: am35x: Disable hlt when using Davinci EMAC
Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com The am35x family of SoCs has a Davinci EMAC ethernet controller on-chip. Unfortunately, the EMAC is unable to wake the PRCM when there is network activity which leads to a hung or extremely slow system when the MPU has executed a 'wfi' instruction (because of pm_idle or CPUidle). To prevent this, add hooks to the EMAC pm_runtime suspend/resume calls so that hlt is disabled whenever the EMAC is in use. Signed-off-by: Mark A. Greer mgr...@animalcreek.com Looks good, Acked-by: Kevin Hilman khil...@ti.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: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
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?
Kevin
Cheers
Jon
From b111bcb24737e070ee1ce7ea3d1deb60a4d6f266 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 31 May 2012 13:05:20 -0500
Subject: [PATCH] ARM: PMU: Add runtime PM Support
---
arch/arm/include/asm/pmu.h |2 ++
arch/arm/kernel/perf_event.c | 30 ++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 90114fa..db9f20c 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -43,6 +43,8 @@ struct arm_pmu_platdata {
irq_handler_t pmu_handler);
void (*enable_irq)(int irq);
void (*disable_irq)(int irq);
+ int (*runtime_resume)(struct device *dev);
+ int (*runtime_suspend)(struct device *dev);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 186c8cb..3b2b016 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/uaccess.h
+#include linux/pm_runtime.h
#include asm/cputype.h
#include asm/irq.h
@@ -460,6 +461,8 @@ hw_perf_event_destroy(struct perf_event *event)
armpmu_release_hardware(armpmu);
mutex_unlock(pmu_reserve_mutex);
}
+
+ pm_runtime_put_sync(armpmu-plat_device-dev);
}
static int
@@ -546,6 +549,8 @@ static int armpmu_event_init(struct perf_event *event)
if (armpmu-map_event(event) == -ENOENT)
return -ENOENT;
+ pm_runtime_get_sync(armpmu-plat_device-dev);
+
event-destroy = hw_perf_event_destroy;
if (!atomic_inc_not_zero(active_events)) {
@@ -584,6 +589,26 @@ static void armpmu_disable(struct pmu *pmu)
armpmu-stop();
}
+static int armpmu_runtime_resume(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_resume)
+ return plat-runtime_resume(dev);
+
+ return 0;
+}
+
+static int armpmu_runtime_suspend(struct device *dev)
+{
+ struct arm_pmu_platdata *plat = dev_get_platdata(dev);
+
+ if (plat-runtime_suspend)
+ return plat-runtime_suspend(dev);
+
+ return 0;
+}
+
static void __init armpmu_init(struct arm_pmu *armpmu)
{
atomic_set(armpmu-active_events, 0);
@@ -650,9 +675,14 @@ static int __devinit armpmu_device_probe(struct
platform_device *pdev)
return 0;
}
+static const struct dev_pm_ops armpmu_dev_pm_ops = {
+ SET_RUNTIME_PM_OPS(armpmu_runtime_suspend, armpmu_runtime_resume, NULL)
+};
+
static struct platform_driver armpmu_driver = {
.driver = {
.name = arm-pmu,
+ .pm = armpmu_dev_pm_ops,
.of_match_table = armpmu_of_device_ids,
},
.probe = armpmu_device_probe,
--
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
On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: I would mark the multiplexed device compatible with simple-bus, which results in the child devices automatically getting added. hmm.. ocp2scp has a sysconfig register and it also has a module mode by which it can be enabled/disabled. I was making use of pm_runtime API's to control these registers (Apart from creating child devices, the driver also has a call to pm_runtime_enable). I see. I'm not sure if with simple-bus we'll be able to do those. I have to check on that. How about making it compatible with both simple-bus and something that handles the pm_runtime requirements? I don't understand enough of what needs to be done for pm_runtime across a lot of devices, but I'd hope that it should be possible to do that in a generic way based on the device definition. Arnd -- 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/3] arm/dts: add wdt node for omap3 and omap4
On 5/31/2012 4:55 PM, Jon Hunter wrote:
On 05/31/2012 12:51 AM, Xiao Jiang wrote:
Hi Jon and Benoit,
Thanks for reminding, how about below patch?
diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
new file mode 100644
index 000..4272d06
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
@@ -0,0 +1,15 @@
+TI Watchdog Timer (WDT) Controller for OMAP
+
+Required properties:
+- compatible:
+ - ti,omap2-wdt for OMAP2
+ - ti,omap3-wdt for OMAP3
+ - ti,omap4-wdt for OMAP4
+- ti,hwmods: Name of the hwmod associated to the WDT
+
+Examples:
+
+wdt2: wdt@73f98000 {
+ compatible = ti,omap4-wdt;
+ ti,hwmods = wd_timer2;
+};
Yes looks good. Thanks! Minor nit-pick in the example I would just copy
the omap4 node completely with the actual omap4 address :-)
Oops, wrong addr, :). Perhaps we can drop address as you said, since the
right addresses are defined
in wd_timer2 hwmod (see [1]), and wdt also works without the address as
follows.
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f2ab4ea..0017bd8 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -63,5 +63,10 @@
ti,hwmods = uart3;
clock-frequency =4800;
};
+
+ wdt2: wdt {
+ compatible = ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..dbf8a5b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,10 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ wdt2: wdt {
+ compatible = ti,omap3-wdt, ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..ce74e87 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,10 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ wdt2: wdt {
+ compatible = ti,omap4-wdt, ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
Infos for omap3:
# dmesg|grep Machine
6[0.00] Machine: Generic OMAP3 (Flattened Device Tree), model:
TI OMAP3 EVM (OMAP3530, AM/DM37x)
# dmesg|grep omap_wdt_probe
4[2.552825] in omap_wdt_probe: 299, res-start = 0x48314000
Infos for omap4:
root@localhost:/root dmesg|grep Machine
[0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI
OMAP4 SDP board
root@localhost:/root dmesg|grep omap_wdt_probe
[1.687896] in omap_wdt_probe: 299, res-start = 0x4a314000
So can I drop the wdt addr from dts file? otherwise it is not feasible
to add omap2 wdt node in omap2.dtsi
due to different addrs for omap2420 and omap2430.
Benoit, what is your preference here?
Get rid of both omap2420 and 2430 :-)
The point is that only OMAP3 and OMAP4 are supposed to be migrated to DT
for the moment.
If you do not have any OMAP2 board to test that, it is anyway safer to
not touch the omap2.dtsi file.
If the 2 or 3 remaining users of OMAP2 boards want to have DT support,
they'll be able to add that themselves.
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: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
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?
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 4/6] ARM: OMAP4: PMU: Add runtime PM support
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.
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 V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Kevin Hilman khil...@ti.com writes: J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Hi Greg, This series has Kevin's comments incorporated. Kevin, Can i have your Ack for this series? Well, as mentioned above, I'm waiting for Rafael's ack, then I will merge it. Because of all the arch/arm/mach-omap2/* changes, I would like to merge this via the OMAP tree to avoid conflicts with other stuff we have changing in arch/arm/mach-omap2/* OK, I had an off-line discussion with Rafael and he's OK that I take these. I will add an ack from Rafael and queue this series up for v3.6. 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: [PATCHv10 00/11] I2C fixes
Shubhrajyoti D shubhrajy...@ti.com writes: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. v9: Fix the comments from Wolfram Sang v10: Add a patch from Neil to the series. Fix kevin comments update the patches with comments. Shubhrajyoti, thanks for the updates. Wolfgang, with these updates and testing a bit better described, I'm OK with you merging it. Merging it now will give it plenty of time to bake in linux-next and get more test exposure. Thanks, Kevin [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. - Did functional tests read write on both the platforms. - Off mode and retention on OMAP3 - On OMAP4 just did echo mem /sys/power/state and wakeup. Did see. [ 1360.595855] Successfully put all powerdomains to target state However didnt see the ret count for other than mpu_pwrdm increase. I think power support for omap4 is minimal. The following changes since commit b48b2c3e50433ff6f7e46186daa7f986bd960215: openrisc: use generic strnlen_user() function (2012-05-27 21:00:32 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-fixes Neil Brown (1): OMAP/I2C - Fix timeout problem during suspend. Shubhrajyoti D (9): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Prevent the register access after pm_runtime_put in probe I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: prevent the overwrite of the errata flags drivers/i2c/busses/i2c-omap.c | 129 - 1 files changed, 63 insertions(+), 66 deletions(-) -- 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
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_*.
Cheers
Jon
[1] http://marc.info/?l=linux-arm-kernelm=131946766428315w=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] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
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)
Thanks for the fix!
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 1/3] 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 Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: port from android] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Wenbiao Wang ww...@ti.com --- arch/arm/mach-omap2/vp.c | 15 +-- arch/arm/mach-omap2/vp.h |2 +- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index f95c1ba..925d869 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm) return; } + /* + * Wait for VP idle Typical latency is 2us. Maximum latency is ~100us + * Depending on if we catch VP in the middle of an SR operation. + */ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout before disable\n, +__func__, voltdm-name); + Shouldn't this bail out here instead of continuing to disable VP? It would be even better to have some error recovery (or at least clean failure) here rather than just printing a warning and continuing. /* Disable VP */ vpconfig = voltdm-read(vp-vpconfig); vpconfig = ~vp-common-vpconfig_vpenable; @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm) VP_IDLE_TIMEOUT, timeout); if (timeout = VP_IDLE_TIMEOUT) - pr_warning(%s: vdd_%s idle timedout\n, - __func__, voltdm-name); + pr_warning(%s: vdd_%s idle timedout after disable\n, +__func__, voltdm-name); vp-enabled = false; diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..0abf895 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -31,7 +31,7 @@ struct voltagedomain; #define OMAP4_VP_VDD_MPU_ID 2 /* XXX document */ -#define VP_IDLE_TIMEOUT 200 +#define VP_IDLE_TIMEOUT 500 Were you planning to insert the comment here as suggested by Eduardo? Kevin #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 2/3] 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. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Vinay Amancha vinayku...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/vp.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 925d869..985091b 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm, u8 target_vsel, current_vsel; int ret, timeout = 0; +/* missing indent + * Wait for VP idle Typical latency is 2us. Maximum latency is ~100us + * This is an additional allowance to ensure we are in proper state + * to enter into forceupdate state transition. + */ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout forceupdate(v=%ld)\n, +__func__, voltdm-name, target_volt); + Again, some clean failure and error recovery should be done here instead of just a print and bail. Kevin 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 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
Nishanth Menon n...@ti.com writes:
Currently we check against the entire 32 bits of the status register
Where, bits 1-31 are marked as reserved and mentioned in TRM as read
returns undefined values.
ouch
Hence, check against purely the vpinidle status bit.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Reported-by: Vinay Amancha vinayku...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Thanks for the fix.
Looking at this combined with the previous patches, since this same
thing is done several places, it looks like we need a helper function
'omap_vp_wait_for_idle()' or similar. That function will do the check,
wait for timeout, and return an error if failure. The callers can than
do appropriate error handling upon failure.
Thanks,
Kevin
---
arch/arm/mach-omap2/vp.c | 15 +--
arch/arm/mach-omap2/vp.h |1 +
arch/arm/mach-omap2/vp3xxx_data.c |1 +
arch/arm/mach-omap2/vp44xx_data.c |1 +
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 985091b..cdcac16 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -128,8 +128,9 @@ int omap_vp_forceupdate_scale(struct voltagedomain
*voltdm,
* This is an additional allowance to ensure we are in proper state
* to enter into forceupdate state transition.
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ 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 forceupdate(v=%ld)\n,
@@ -278,8 +279,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us
* Depending on if we catch VP in the middle of an SR operation.
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ 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 before disable\n,
@@ -293,8 +295,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
/*
* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ 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 after disable\n,
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0abf895..876b5ab 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -73,6 +73,7 @@ struct omap_vp_common {
u8 vpconfig_initvdd;
u8 vpconfig_forceupdate;
u8 vpconfig_vpenable;
+ u8 vstatus_vpidle;
u8 vstepmin_stepmin_shift;
u8 vstepmin_smpswaittimemin_shift;
u8 vstepmax_stepmax_shift;
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c
b/arch/arm/mach-omap2/vp3xxx_data.c
index bd89f80..a65909b 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
.vpconfig_initvdd = OMAP3430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 8c031d1..9d14881 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
.vpconfig_initvdd = OMAP4430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
--
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 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
On 05/31/2012 04:21 PM, Kevin Hilman wrote: diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..0abf895 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -31,7 +31,7 @@ struct voltagedomain; #define OMAP4_VP_VDD_MPU_ID 2 /* XXX document */ -#define VP_IDLE_TIMEOUT 200 +#define VP_IDLE_TIMEOUT 500 Were you planning to insert the comment here as suggested by Eduardo? Oops, ignore this comment. I see you posted a v3 with this added. Sorry, 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 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
On 16:21-20120531, Kevin Hilman 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 Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: port from android] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Wenbiao Wang ww...@ti.com --- arch/arm/mach-omap2/vp.c | 15 +-- arch/arm/mach-omap2/vp.h |2 +- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index f95c1ba..925d869 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm) return; } + /* +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* Depending on if we catch VP in the middle of an SR operation. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout before disable\n, + __func__, voltdm-name); + Shouldn't this bail out here instead of continuing to disable VP? yes - but then the entire voltage path is without error handling :( I think the cleanup should be done independent of this patch - just doing a return at this point might actually not effective. It would be even better to have some error recovery (or at least clean failure) here rather than just printing a warning and continuing. Once VP does not idle, it is an indication that something seriously has gone wrong in the VP state machine. VP in PRM module is reset only on cold reset - so even a traditional arch_reset would not help us here. The intent here is to be completely sure that VP is in idle state before we trigger a disable. With the cleanup of all error handling flows, we might be able to flag all the way back up to calling event (a DVFS event) and may even be able to trigger appropriate recovery mechanism. /* Disable VP */ vpconfig = voltdm-read(vp-vpconfig); vpconfig = ~vp-common-vpconfig_vpenable; @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm) VP_IDLE_TIMEOUT, timeout); if (timeout = VP_IDLE_TIMEOUT) - pr_warning(%s: vdd_%s idle timedout\n, - __func__, voltdm-name); + pr_warning(%s: vdd_%s idle timedout after disable\n, + __func__, voltdm-name); vp-enabled = false; diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..0abf895 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -31,7 +31,7 @@ struct voltagedomain; #define OMAP4_VP_VDD_MPU_ID 2 /* XXX document */ -#define VP_IDLE_TIMEOUT200 +#define VP_IDLE_TIMEOUT500 Were you planning to insert the comment here as suggested by Eduardo? yep. waiting in case we have more comments :) --- 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 2/3] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
On 16:23-20120531, Kevin Hilman wrote: 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. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Vinay Amancha vinayku...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/vp.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 925d869..985091b 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -123,6 +123,18 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm, u8 target_vsel, current_vsel; int ret, timeout = 0; +/* missing indent oops. will fix +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* This is an additional allowance to ensure we are in proper state +* to enter into forceupdate state transition. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout forceupdate(v=%ld)\n, + __func__, voltdm-name, target_volt); + Again, some clean failure and error recovery should be done here instead of just a print and bail. thx - we should at least refuse to do forceupdate at this point. -- 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 3/3] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
On 16:27-20120531, Kevin Hilman wrote: Nishanth Menon n...@ti.com writes: Currently we check against the entire 32 bits of the status register Where, bits 1-31 are marked as reserved and mentioned in TRM as read returns undefined values. ouch Hence, check against purely the vpinidle status bit. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Reported-by: Vinay Amancha vinayku...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Thanks for the fix. Looking at this combined with the previous patches, since this same thing is done several places, it looks like we need a helper function 'omap_vp_wait_for_idle()' or similar. That function will do the check, wait for timeout, and return an error if failure. The callers can than do appropriate error handling upon failure. yep - i think a static inline should do just fine here considering just a test_timeout is involved. will post out a new series in a few mins. -- 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 8/9] ARM: OMAP3: prevent per_clkdm from attempting manual domain transitions
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?
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.
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 00/11] OMAP System Control Module
Hi Eduardo, Eduardo Valentin eduardo.valen...@ti.com writes: Hello Paul and Tony, This is a series of patches adding a basic support for system control module, on OMAP4+ context. It is a working in progress, but I wanted to share already to get your feedback. This is a great start, thanks for working on this. We have been needing to do this for awhile now so I'm glad to see you working on it. I've modeled the driver as an MFD. You will see in this series: . A rework of the system control module header (patch from Santosh, picked from the list) . Device creation for control module core . Early device creation for control module core . The MFD core driver for system control module . The MFD child for usb-phy pin control . The MFD child for bandgap sensor . Very early exposure of OMAP4 thermal zone . All added drivers are only supporting DT probing . The series is based on linux-omap master, as it has the hwmod entries for SCM. The overall idea of this series is to put in place the infrastructure. It is not touching nor removing the existing APIs under mach-omap2/control.c for now. But the target is to have these APIs moved to the MFD core driver. IMO, the best time to create the APIs is when the new MFD children are created. The goal should be that none of these drivers should be doing direct read/writes to the control module. 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 4/6] ARM: OMAP4: PMU: Add runtime PM support
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.
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
[PATCH V4 0/4] ARM: OMAP3+: VP: collate fixes
Reviewing the android code base brought out a few fixes that upstream does not have, so collating them and posting them out in this chain. Nishanth Menon (3): ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit ARM: OMAP3+: PM: VP: move check of idle to separate function ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate Wenbiao Wang (1): ARM: OMAP3+: PM: VP: ensure VP is idle before disable arch/arm/mach-omap2/vp.c | 65 +++-- arch/arm/mach-omap2/vp.h | 10 -- arch/arm/mach-omap2/vp3xxx_data.c |1 + arch/arm/mach-omap2/vp44xx_data.c |1 + 4 files changed, 65 insertions(+), 12 deletions(-) Changes in v4: vp idle moved off to a seperate function reordered patches to reduce loc changes rate controlled warnings Previous revs: V1: http://marc.info/?l=linux-omapm=133736976423629w=2 Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com -- Regards, Nishanth Menon -- 1.7.9.5 -- 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 V2 1/4] ARM: OMAP3+: PM: VP: check only the VPINIDLE status bit
Currently we check against the entire 32 bits of the status register
Where, bits 1-31 are marked as reserved and mentioned in TRM as read
returns undefined values. Hence, check against purely the vpinidle
status bit.
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Reported-by: Vinay Amancha vinayku...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/vp.c |5 +++--
arch/arm/mach-omap2/vp.h |1 +
arch/arm/mach-omap2/vp3xxx_data.c |1 +
arch/arm/mach-omap2/vp44xx_data.c |1 +
4 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index f95c1ba..faefef7 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -270,8 +270,9 @@ void omap_vp_disable(struct voltagedomain *voltdm)
/*
* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us
*/
- omap_test_timeout((voltdm-read(vp-vstatus)),
- VP_IDLE_TIMEOUT, timeout);
+ 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,
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 7c155d2..ac1d6cf 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -73,6 +73,7 @@ struct omap_vp_common {
u8 vpconfig_initvdd;
u8 vpconfig_forceupdate;
u8 vpconfig_vpenable;
+ u8 vstatus_vpidle;
u8 vstepmin_stepmin_shift;
u8 vstepmin_smpswaittimemin_shift;
u8 vstepmax_stepmax_shift;
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c
b/arch/arm/mach-omap2/vp3xxx_data.c
index bd89f80..a65909b 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap3_vp_common = {
.vpconfig_initvdd = OMAP3430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP3430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP3430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP3430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP3430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP3430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP3430_VSTEPMIN_SHIFT,
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 8c031d1..9d14881 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -44,6 +44,7 @@ static const struct omap_vp_common omap4_vp_common = {
.vpconfig_initvdd = OMAP4430_INITVDD_MASK,
.vpconfig_forceupdate = OMAP4430_FORCEUPDATE_MASK,
.vpconfig_vpenable = OMAP4430_VPENABLE_MASK,
+ .vstatus_vpidle = OMAP4430_VPINIDLE_MASK,
.vstepmin_smpswaittimemin_shift = OMAP4430_SMPSWAITTIMEMIN_SHIFT,
.vstepmax_smpswaittimemax_shift = OMAP4430_SMPSWAITTIMEMAX_SHIFT,
.vstepmin_stepmin_shift = OMAP4430_VSTEPMIN_SHIFT,
--
1.7.9.5
--
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 V2 2/4] ARM: OMAP3+: PM: VP: move check of idle to separate function
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,
+ __func__, voltdm-name);
+ WARN_ONCE(vdd_%s idle timedout\n, voltdm-name);
+
+ 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,
+ __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_TIMEOUT200
#define VP_TRANXDONE_TIMEOUT 300
--
1.7.9.5
--
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 V2 3/4] ARM: OMAP3+: PM: VP: check to ensure VP is idle before forceupdate
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,
+ __func__, voltdm-name, target_volt);
+ return ret;
+ }
+
ret = omap_vc_pre_scale(voltdm, target_volt, target_vsel,
current_vsel);
if (ret)
return ret;
--
1.7.9.5
--
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 V2 4/4] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
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]
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,
+ __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_TIMEOUT200
+#define VP_IDLE_TIMEOUT500
#define VP_TRANXDONE_TIMEOUT 300
/**
--
1.7.9.5
--
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 V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman khil...@ti.com wrote: Kevin Hilman khil...@ti.com writes: J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Hi Greg, This series has Kevin's comments incorporated. Kevin, Can i have your Ack for this series? Well, as mentioned above, I'm waiting for Rafael's ack, then I will merge it. Because of all the arch/arm/mach-omap2/* changes, I would like to merge this via the OMAP tree to avoid conflicts with other stuff we have changing in arch/arm/mach-omap2/* OK, I had an off-line discussion with Rafael and he's OK that I take these. I will add an ack from Rafael and queue this series up for v3.6. Thanks Kevin. Thanks, Kevin -- Regards and Thanks, Keerthy -- 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
[PATCHv2 0/3] omap3 and omap4: add device tree support for wdt
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 -- 1.7.3 -- 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
[PATCHv2 3/3] watchdog: omap_wdt: add device tree support
From: Xiao Jiang jgq...@gmail.com
Add device table for omap_wdt to support dt.
Signed-off-by: Xiao Jiang jgq...@gmail.com
---
drivers/watchdog/omap_wdt.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..02ebfd5 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -430,6 +430,12 @@ static int omap_wdt_resume(struct platform_device *pdev)
#defineomap_wdt_resume NULL
#endif
+static const struct of_device_id omap_wdt_of_match[] = {
+ { .compatible = ti,omap3-wdt, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
+
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
.remove = __devexit_p(omap_wdt_remove),
@@ -439,6 +445,7 @@ static struct platform_driver omap_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = omap_wdt,
+ .of_match_table = omap_wdt_of_match,
},
};
--
1.7.3
--
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
