Re: [RFC PATCHv4 0/7] HSI framework and drivers
2010/12/14 Carlos Chinea carlos.chi...@nokia.com: Here you have the fourth round of the HSI framework patches. I'd like to notify that this out-of-tree framework is also in use for the ST-Ericsson Ux500s, and we've had great success with it. You can add my: Acked-by: Linus Walleij linus.wall...@linaro.org Possibly some ST-Ericsson people can add Tested-by tags as well. We will integrate Ux500 support whenever it's suitable, either after the merge or as add-on patches for Carlos patch series. (If Carlos would like to keep them in his series.) Yours, Linus Walleij -- 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] OMAP4: clockdomain: Follow recommended enable sequence
Hi Kevin/Paul, On 3/11/2011 10:17 PM, Kevin Hilman wrote: Rajendra Nayakrna...@ti.com writes: [...] It's also breaking boot on OMAP35xx BeagleBoard rev C2. The kernel boot messages are below - omap2plus_defconfig + DEBUG_LL. Reverting the patch fixes it. Could you please take a look? I got hold of a Beagle, a sticker on which says rev C1D. Not sure if there is a better way to identify the rev, but this one seems to boot fine for me even with this patch. I just applied this one patch on top of the the tag 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux- integration. In the process of testing Santosh's OMAP4 PM series (which includes $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine is a C3.) Specifially, with $SUBJECT patch applied, none of the powerdomains ever reach inactive or RET during idle (suspend seems to work fine.) Just reverting $SUBJECT patch makes things go back to working normally. I pushed the test branch I used which is a merge of Santosh's v3 branch with my pm branch (branch: tmp/santosh-omap4-pm) I tested by first doing a suspend test and confirming all the powerdomains hit retention. That worked fine. Then I did an idle test: echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 1 /debug/pm_debug/sleep_while_idle and waited for the UARTs to timeout. Well after the UART timeouts expired, I do not see any powerdomains transitioning from ON. What's even more strange is that the same thing is working fine on all the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a different 3530-based platform, the OMAP3EVM. I tried to reproduce this on a Beagle rev C3, but I don't seem to be seeing this issue. I was able to hit OFF mode in both suspend and idle. I also tried removing autodeps completely on OMAP3 and ran into some issues/aborts with GPIO restore path with OFF mode enabled. Besides these, debugging some McBSP related crashes showed up another issue with this patch. Since the clockdomain is programmed back to HW_AUTO (if supported) in the clock framework, this happens *before* waiting for the module to become accessible. (On OMAP4, the check to make sure the module is accessible happens in the hwmod framework, unlike in older OMAP's, where it was part of the clock framework) So instead of implementing the recommended sequence of -1- Force clkdm to SW_WKUP -2- Configure desired module mode to enable or auto -3- Wait for the desired module idle status to be FUNC -4- Program clkdm in HW_AUTO(if supported) ..it was actually implementing the wrong sequence as below -1- Force clkdm to SW_WKUP -2- Configure desired module mode to enable or auto -3- Program clkdm in HW_AUTO(if supported) -4- Wait for the desired module idle status to be FUNC This however was only a problem on OMAP4. Fixing this would require moving the clockdomain programming back to HW_AUTO as part of the hwmod framework. However this sequence is recommended even for optional clock enabling, and hence might have to be handled at the clock framework as well. (Since optional clocks are still controlled by drivers using clock framework directly). Any suggestions on how to handle this without duplicating much of this across clock and hwmod framework? regards, Rajendra 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 -- 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/7] OMAP2+: voltage: move PRCM mod offets into VDD structure
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Saturday, March 19, 2011 5:49 AM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsely; Cousson, Benoit
Subject: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets
into VDD structure
Eliminate need for global variables for the various PRM
module offsets by
making them part of the VDD structure.
Eventually, these will likely be moved again, or more likely removed,
but for now just getting rid of them as global variabes so that the
voltage domain initialization can be cleaned up.
Signed-off-by: Kevin Hilman khil...@ti.com
[sp] This is almost what I intended to do in the clean-up patches
posted earlier; but for few differences.
Putting them here as well.
[snip...snip]
diff --git a/arch/arm/mach-omap2/voltage.h
b/arch/arm/mach-omap2/voltage.h
index e9f5408..44edc1e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -133,6 +133,9 @@ struct omap_vdd_info {
struct dentry *debug_dir;
u32 curr_volt;
bool vp_enabled;
+
+ s16 prm_mod;
+ s16 prm_irqst_mod;
[sp] Can we match the type with the functions these are eventually
passed to?
Also, prm_mod is comstant for the silicon.
Shouldn't it be a local static instead. Else, same value is
repeated for each vdd.
~sanjeev
[snip...snip]
--
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: cpufreq support for the Beagleboard.
Cpufreq for omap is not mainlined yet. Patches for supporting omap cpufreq are posted at https://patchwork.kernel.org/patch/495021/ Same are available at git://gitorious.org/omap-pm/linux.git omap_dvfs Vishwa -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of javier Martin Sent: Monday, March 21, 2011 4:12 PM To: linux-omap@vger.kernel.org Subject: cpufreq support for the Beagleboard. Hi, I am testing latest 2.6.38 stable kernel with my Beagleboard xM. I have enabled CONFIG_CPU_FREQ option and several governors. However, when I boot the board and execute cpufreq-info I get the following: root@beagleboard:~# cpufreq-info cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. I've read some information in this wiki: http://elinux.org/OMAP_Power_Management It seems that cpufreq is still not in mainline but it should be already on pm branch of omap repository. However, I've also tried compiling this one and I've got the same problem. Could anyone clarify whether cpufreq is supported or not in the Beagleboard xM and where? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] OMAP3: Support processor group selection by a peripheral
OMAP3 has PM_processor_nameGRPSEL_domain_name registers which can be programmed to allow a peripheral to choose a processor group which it expects to wake up. This RFC series is an attempt to provide omap_device layer api's for drivers to be able to do this instead of direct PRCM accesses within drivers which is the case today. Something similar exists on OMAP4, in the form of wakeup dependencies, which are not addressed in this series for now. Rajendra Nayak (3): OMAP3: PRM: Add grpsel programming support OMAP3: hwmod: Add support to associate an initiator with a hwmod OMAP3: omap_device: Add support to associate a device with an initiator arch/arm/mach-omap2/omap_hwmod.c | 33 arch/arm/mach-omap2/prcm-common.h|1 - arch/arm/mach-omap2/prm2xxx_3xxx.c | 70 ++ arch/arm/mach-omap2/prm2xxx_3xxx.h |4 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h |9 +++ arch/arm/plat-omap/omap_device.c | 54 6 files changed, 170 insertions(+), 1 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
[RFC 2/3] OMAP3: hwmod: Add support to associate an initiator with a hwmod
Add hwmod api's to add and delete an initiator
association with an hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 33 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..d4826be 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2369,3 +2369,36 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+int omap_hwmod_add_initiator_user(struct omap_hwmod *oh, u8 init_id)
+{
+ if (oh-_state != _HWMOD_STATE_ENABLED)
+ return -EINVAL;
+
+ if (cpu_is_omap34xx()) {
+ return omap2_prm_module_enable_initiator_wakeup(
+ oh-prcm.omap2.module_offs,
+ oh-prcm.omap2.idlest_reg_id,
+ oh-prcm.omap2.idlest_idle_bit,
+ init_id);
+ }
+
+ return -EINVAL;
+}
+
+int omap_hwmod_del_initiator_user(struct omap_hwmod *oh, u8 init_id)
+{
+ if (oh-_state == _HWMOD_STATE_ENABLED)
+ return -EINVAL;
+
+ if (cpu_is_omap34xx()) {
+ return omap2_prm_module_disable_initiator_wakeup(
+ oh-prcm.omap2.module_offs,
+ oh-prcm.omap2.idlest_reg_id,
+ oh-prcm.omap2.idlest_idle_bit,
+ init_id);
+ }
+
+ return -EINVAL;
+
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 4bd7354..fe47448 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -590,6 +590,8 @@ int omap_hwmod_add_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh);
int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh);
+int omap_hwmod_add_initiator_user(struct omap_hwmod *oh, u8 init_id);
+int omap_hwmod_del_initiator_user(struct omap_hwmod *oh, u8 init_id);
int omap_hwmod_set_clockact_both(struct omap_hwmod *oh);
int omap_hwmod_set_clockact_main(struct omap_hwmod *oh);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] OMAP3: omap_device: Add support to associate a device with an initiator
These api's are meant to to used by drivers to
associate/disassociate a device from a given initiator.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/plat-omap/omap_device.c | 54 ++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9bbda9a..0cd05d2 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -662,6 +662,60 @@ int omap_device_shutdown(struct platform_device *pdev)
return ret;
}
+static int omap_device_add_initiator_user(struct platform_device *pdev,
+ u8 init_id)
+{
+ int i;
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED)
+ return -EINVAL;
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ omap_hwmod_add_initiator_user(od-hwmods[i], init_id);
+
+ return 0;
+}
+
+inline int omap_device_add_mpu_user(struct platform_device *pdev)
+{
+ return omap_device_add_initiator_user(pdev, OMAP_INIT_MPU);
+}
+
+inline int omap_device_add_iva_user(struct platform_device *pdev)
+{
+ return omap_device_add_initiator_user(pdev, OMAP_INIT_IVA);
+}
+
+static int omap_device_del_initiator_user(struct platform_device *pdev,
+ u8 init_id)
+{
+ int i;
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
+ if (od-_state == OMAP_DEVICE_STATE_ENABLED)
+ return -EINVAL;
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ omap_hwmod_del_initiator_user(od-hwmods[i], init_id);
+
+ return 0;
+}
+
+inline int omap_device_del_mpu_user(struct platform_device *pdev)
+{
+ return omap_device_del_initiator_user(pdev, OMAP_INIT_MPU);
+}
+
+inline int omap_device_del_iva_user(struct platform_device *pdev)
+{
+ return omap_device_del_initiator_user(pdev, OMAP_INIT_IVA);
+}
+
/**
* omap_device_align_pm_lat - activate/deactivate device to match wakeup lat
lim
* @od: struct omap_device *
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/3] OMAP3: PRM: Add grpsel programming support
Add api's to support programming the
PM_processorGRPSEL_domain registers which are
needed for proper peripheral wakeup configuration.
Also add unique identifiers for all initiators.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prcm-common.h|1 -
arch/arm/mach-omap2/prm2xxx_3xxx.c | 70 ++
arch/arm/mach-omap2/prm2xxx_3xxx.h |4 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |7 +++
4 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 0363dcb..be6b3c2 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -397,7 +397,6 @@
#define OMAP3430_EN_CORE_SHIFT 0
#define OMAP3430_EN_CORE_MASK (1 0)
-
/*
* MAX_MODULE_HARDRESET_WAIT: Maximum microseconds to wait for an OMAP
* submodule to exit hardreset
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 051213f..77aade2 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -19,11 +19,21 @@
#include plat/common.h
#include plat/cpu.h
#include plat/prcm.h
+#include plat/omap_hwmod.h
#include prm2xxx_3xxx.h
#include cm2xxx_3xxx.h
#include prm-regbits-24xx.h
#include prm-regbits-34xx.h
+#include prm2xxx_3xxx.h
+
+static const u8 prm_mpugrpsel_offs[] = {
+ OMAP3430_PM_MPUGRPSEL1, 0, OMAP3430ES2_PM_MPUGRPSEL3,
+};
+
+static const u8 prm_ivagrpsel_offs[] = {
+ OMAP3430_PM_IVAGRPSEL1, 0, OMAP3430ES2_PM_IVAGRPSEL3,
+};
u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
@@ -156,3 +166,63 @@ int omap2_prm_deassert_hardreset(s16 prm_mod, u8
rst_shift, u8 st_shift)
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+
+static int _get_initiator_grpsel(u8 grpsel_id, u8 initiator_id,
+ u8 *prm_grpsel_reg)
+{
+ switch (initiator_id) {
+ case OMAP_INIT_MPU:
+ if (grpsel_id ARRAY_SIZE(prm_mpugrpsel_offs))
+ return -EINVAL;
+ *prm_grpsel_reg = prm_mpugrpsel_offs[grpsel_id - 1];
+ break;
+ case OMAP_INIT_IVA:
+ if (grpsel_id ARRAY_SIZE(prm_ivagrpsel_offs))
+ return -EINVAL;
+ *prm_grpsel_reg = prm_ivagrpsel_offs[grpsel_id - 1];
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+int omap2_prm_module_enable_initiator_wakeup(s16 prcm_mod, u8 grpsel_id,
+u8 grpsel_shift, u8 initiator_id)
+{
+ u8 prm_grpsel_reg;
+ u32 mask;
+ int ret;
+
+ if (!grpsel_id || !cpu_is_omap34xx())
+ return -EINVAL;
+
+ mask = 1 grpsel_shift;
+
+ ret = _get_initiator_grpsel(grpsel_id, initiator_id, prm_grpsel_reg);
+ if (ret)
+ return ret;
+
+ omap2_prm_set_mod_reg_bits(mask, prcm_mod, prm_grpsel_reg);
+ return 0;
+}
+
+int omap2_prm_module_disable_initiator_wakeup(s16 prcm_mod, u8 grpsel_id,
+ u8 grpsel_shift, u8 initiator_id)
+{
+ u8 prm_grpsel_reg;
+ u32 mask;
+ int ret;
+
+ if (!grpsel_id || !cpu_is_omap34xx())
+ return -EINVAL;
+
+ mask = 1 grpsel_shift;
+
+ ret = _get_initiator_grpsel(grpsel_id, initiator_id, prm_grpsel_reg);
+ if (ret)
+ return ret;
+
+ omap2_prm_clear_mod_reg_bits(mask, prcm_mod, prm_grpsel_reg);
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index a1fc62a..08ae2b9 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -302,6 +302,10 @@ extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16
idx, u32 mask);
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8
st_shift);
+extern int omap2_prm_module_enable_initiator_wakeup(s16 module, u8 grpsel_id,
+ u8 shift, u8 init_id);
+extern int omap2_prm_module_disable_initiator_wakeup(s16 module, u8 grpsel_id,
+ u8 shift, u8 init_id);
#endif /* CONFIG_ARCH_OMAP4 */
#endif
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..4bd7354 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -431,6 +431,13 @@ struct omap_hwmod_omap4_prcm {
#define _HWMOD_STATE_IDLE 5
#define _HWMOD_STATE_DISABLED 6
+/* Unique initiator identifiers */
+#define OMAP_INIT_MPU 1
+#define OMAP_INIT_IVA
Re: cpufreq support for the Beagleboard.
Hi, thank you for your fast answer. I've been testing the repository you pointed me and I found that only 300MHz and 600MHz can be selected in the Beagleboard xM. Couldn't we work until 1000MHz? Do you know what's left for those patches to enter mainline? Is anybody working on it? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: [GIT PULL] omap display subsystem changes for 2.6.39
Hi, On Mon, 2011-03-21 at 04:51 -0500, Tomi Valkeinen wrote: Hi Paul, Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a bit of them, and many changes also in arch/arm/mach-omap2, which unfortunately couldn't go through Tony's linux-omap tree due to dependencies on DSS driver code. The patches are mostly aiming to get OMAP4 display support up and running and both HDMI and DVI outputs should now work on Blaze and Panda boards. One problem I noticed just now, the committer names seem a bit messed up. For example, Archit Taneja has three different style names there. Do you think I should rebase and fix them? Not a big job, but it'll mean, well, rebasing. There's a minor conflict in Overo's board file. I have pushed for-paul-merged branch to gitorious, which contains a merge with Linus' tree. I'm not sure that is the best way to show how to fix the conflict, but hopefully it'll give the idea. Tomi The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34: Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-paul I forgot to mention that this branch is based on Tony's omap-for-linus branch, which got merged last week. Tomi -- 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 1/3] OMAP3: PRM: Add grpsel programming support
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Rajendra Nayak
Sent: Monday, March 21, 2011 4:40 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; b-cous...@ti.com; Rajendra Nayak
Subject: [RFC 1/3] OMAP3: PRM: Add grpsel programming support
Add api's to support programming the
PM_processorGRPSEL_domain registers which are
needed for proper peripheral wakeup configuration.
Also add unique identifiers for all initiators.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prcm-common.h|1 -
arch/arm/mach-omap2/prm2xxx_3xxx.c | 70
++
arch/arm/mach-omap2/prm2xxx_3xxx.h |4 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |7 +++
4 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 0363dcb..be6b3c2 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -397,7 +397,6 @@
#define OMAP3430_EN_CORE_SHIFT0
#define OMAP3430_EN_CORE_MASK (1 0)
-
Stray change...
/*
* MAX_MODULE_HARDRESET_WAIT: Maximum microseconds to wait for an OMAP
* submodule to exit hardreset
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 051213f..77aade2 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -19,11 +19,21 @@
#include plat/common.h
#include plat/cpu.h
#include plat/prcm.h
+#include plat/omap_hwmod.h
#include prm2xxx_3xxx.h
#include cm2xxx_3xxx.h
#include prm-regbits-24xx.h
#include prm-regbits-34xx.h
+#include prm2xxx_3xxx.h
+
+static const u8 prm_mpugrpsel_offs[] = {
+ OMAP3430_PM_MPUGRPSEL1, 0, OMAP3430ES2_PM_MPUGRPSEL3,
+};
+
+static const u8 prm_ivagrpsel_offs[] = {
+ OMAP3430_PM_IVAGRPSEL1, 0, OMAP3430ES2_PM_IVAGRPSEL3,
+};
u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
{
@@ -156,3 +166,63 @@ int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift, u8 st_shift)
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+
+static int _get_initiator_grpsel(u8 grpsel_id, u8 initiator_id,
+ u8
*prm_grpsel_reg)
+{
+ switch (initiator_id) {
+ case OMAP_INIT_MPU:
+ if (grpsel_id ARRAY_SIZE(prm_mpugrpsel_offs))
+ return -EINVAL;
+ *prm_grpsel_reg = prm_mpugrpsel_offs[grpsel_id - 1];
+ break;
+ case OMAP_INIT_IVA:
+ if (grpsel_id ARRAY_SIZE(prm_ivagrpsel_offs))
+ return -EINVAL;
+ *prm_grpsel_reg = prm_ivagrpsel_offs[grpsel_id - 1];
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+int omap2_prm_module_enable_initiator_wakeup(s16 prcm_mod, u8
grpsel_id,
+ u8 grpsel_shift, u8
initiator_id)
+{
+ u8 prm_grpsel_reg;
+ u32 mask;
+ int ret;
+
+ if (!grpsel_id || !cpu_is_omap34xx())
+ return -EINVAL;
+
+ mask = 1 grpsel_shift;
+
+ ret = _get_initiator_grpsel(grpsel_id, initiator_id,
prm_grpsel_reg);
+ if (ret)
+ return ret;
+
+ omap2_prm_set_mod_reg_bits(mask, prcm_mod, prm_grpsel_reg);
+ return 0;
+}
+
+int omap2_prm_module_disable_initiator_wakeup(s16 prcm_mod,
u8 grpsel_id,
+ u8 grpsel_shift, u8
initiator_id)
+{
+ u8 prm_grpsel_reg;
+ u32 mask;
+ int ret;
+
+ if (!grpsel_id || !cpu_is_omap34xx())
+ return -EINVAL;
+
+ mask = 1 grpsel_shift;
+
+ ret = _get_initiator_grpsel(grpsel_id, initiator_id,
prm_grpsel_reg);
+ if (ret)
+ return ret;
+
+ omap2_prm_clear_mod_reg_bits(mask, prcm_mod, prm_grpsel_reg);
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index a1fc62a..08ae2b9 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -302,6 +302,10 @@ extern u32
omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8
rst_shift, u8 st_shift);
+extern int omap2_prm_module_enable_initiator_wakeup(s16
module, u8 grpsel_id,
+ u8 shift, u8 init_id);
+extern int omap2_prm_module_disable_initiator_wakeup(s16
module, u8 grpsel_id,
+ u8 shift, u8 init_id);
#endif/* CONFIG_ARCH_OMAP4 */
#endif
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..4bd7354 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++
Re: [PATCH 1/7] OMAP2+: hwmod: remove unused voltagedomain pointer
Hi Kevin,
On 3/19/2011 1:18 AM, Hilman, Kevin wrote:
The voltage domain pointer currently in struct omap_hwmod is not used
and does not belong here. Instead, voltage domains will be associated
with powerdomains in forthcoming patches.
Technically speaking, an IP, and thus the hwmod does belong to a voltage
domain, a power domain and a clock domain.
What is maybe important to add is that since clkdm pwrdm voltdm, we
can potentially avoid providing the information for the each domain type.
At some point the hwmod will have to contain a clkdm instead of relying
on the main_clk to get it... but that's another topic...
Signed-off-by: Kevin Hilmankhil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..a5fa7c1 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -520,7 +520,6 @@ struct omap_hwmod {
struct clk *_clk;
struct omap_hwmod_opt_clk *opt_clks;
char*vdd_name;
And what about vdd_name? It should probably be removed as well.
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 2/3] OMAP3: hwmod: Add support to associate an initiator with a hwmod
Rajendra,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Rajendra Nayak
Sent: Monday, March 21, 2011 4:40 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; b-cous...@ti.com; Rajendra Nayak
Subject: [RFC 2/3] OMAP3: hwmod: Add support to associate an
initiator with a hwmod
Add hwmod api's to add and delete an initiator
association with an hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 33
++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..d4826be 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2369,3 +2369,36 @@ int omap_hwmod_no_setup_reset(struct
omap_hwmod *oh)
return 0;
}
+
+int omap_hwmod_add_initiator_user(struct omap_hwmod *oh, u8 init_id)
+{
+ if (oh-_state != _HWMOD_STATE_ENABLED)
+ return -EINVAL;
+
+ if (cpu_is_omap34xx()) {
+ return omap2_prm_module_enable_initiator_wakeup(
+
oh-prcm.omap2.module_offs,
+
oh-prcm.omap2.idlest_reg_id,
+
oh-prcm.omap2.idlest_idle_bit,
+ init_id);
+ }
+
+ return -EINVAL;
Why are you returning error when it not a omap34xx?
Is it not that this API will be called for only omap34xx?
+}
+
+int omap_hwmod_del_initiator_user(struct omap_hwmod *oh, u8 init_id)
+{
+ if (oh-_state == _HWMOD_STATE_ENABLED)
+ return -EINVAL;
+
+ if (cpu_is_omap34xx()) {
+ return omap2_prm_module_disable_initiator_wakeup(
+
oh-prcm.omap2.module_offs,
+
oh-prcm.omap2.idlest_reg_id,
+
oh-prcm.omap2.idlest_idle_bit,
+ init_id);
+ }
+
+ return -EINVAL;
Ditto...
+
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 4bd7354..fe47448 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -590,6 +590,8 @@ int omap_hwmod_add_initiator_dep(struct
omap_hwmod *oh,
struct omap_hwmod *init_oh);
int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh);
+int omap_hwmod_add_initiator_user(struct omap_hwmod *oh, u8 init_id);
+int omap_hwmod_del_initiator_user(struct omap_hwmod *oh, u8 init_id);
int omap_hwmod_set_clockact_both(struct omap_hwmod *oh);
int omap_hwmod_set_clockact_main(struct omap_hwmod *oh);
--
Regards,
Hema
1.7.0.4
--
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 3/3] OMAP3: omap_device: Add support to associate a device with an initiator
Rajendra,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Rajendra Nayak
Sent: Monday, March 21, 2011 4:40 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; b-cous...@ti.com; Rajendra Nayak
Subject: [RFC 3/3] OMAP3: omap_device: Add support to
associate a device with an initiator
These api's are meant to to used by drivers to
associate/disassociate a device from a given initiator.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/plat-omap/omap_device.c | 54
++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 9bbda9a..0cd05d2 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -662,6 +662,60 @@ int omap_device_shutdown(struct
platform_device *pdev)
return ret;
}
+static int omap_device_add_initiator_user(struct
platform_device *pdev,
+u8 init_id)
+{
+ int i;
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED)
+ return -EINVAL;
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ omap_hwmod_add_initiator_user(od-hwmods[i], init_id);
Not checking for return value.
+
+ return 0;
+}
+
+inline int omap_device_add_mpu_user(struct platform_device *pdev)
+{
+ return omap_device_add_initiator_user(pdev, OMAP_INIT_MPU);
+}
+
+inline int omap_device_add_iva_user(struct platform_device *pdev)
+{
+ return omap_device_add_initiator_user(pdev, OMAP_INIT_IVA);
Ditto..
+}
+
+static int omap_device_del_initiator_user(struct
platform_device *pdev,
+u8 init_id)
+{
+ int i;
+ struct omap_device *od;
+
+ od = _find_by_pdev(pdev);
+
+ if (od-_state == OMAP_DEVICE_STATE_ENABLED)
+ return -EINVAL;
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ omap_hwmod_del_initiator_user(od-hwmods[i], init_id);
+
+ return 0;
+}
+
+inline int omap_device_del_mpu_user(struct platform_device *pdev)
+{
+ return omap_device_del_initiator_user(pdev, OMAP_INIT_MPU);
+}
+
+inline int omap_device_del_iva_user(struct platform_device *pdev)
+{
+ return omap_device_del_initiator_user(pdev, OMAP_INIT_IVA);
+}
+
/**
* omap_device_align_pm_lat - activate/deactivate device to
match wakeup lat lim
* @od: struct omap_device *
--
1.7.0.4
--
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: cpufreq support for the Beagleboard.
-Original Message- From: javier Martin [mailto:javier.mar...@vista-silicon.com] Sent: Monday, March 21, 2011 5:40 PM To: Vishwanath Sripathy Cc: linux-omap@vger.kernel.org Subject: Re: cpufreq support for the Beagleboard. Hi, thank you for your fast answer. I've been testing the repository you pointed me and I found that only 300MHz and 600MHz can be selected in the Beagleboard xM. Couldn't we work until 1000MHz? 1G is disabled by default in OPP table I suppose. Pls enable it (in omap36xx_opp_def_list) if your board supports it. Do you know what's left for those patches to enter mainline? Is anybody working on it? OMAP cpufreq is undergoing some architecture/design changes and this is WIP. Vishwa Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
[PATCH 0/2] USB: twl4030-usb: fix isp1707 xceiver powering
These two patches introduce phy_power calls form board files to twl4030-usb. This fixes a problem in Nokia N900, where the ISP1707 serial tranceiver did not get disabled during phy power down. Based on patches used on n900 maemo kernel, mainly from Heikki Krogerus. Commentstesting appreciated. Basic test done on MeeGo + linux usb that the ISP powering happens correctly. Also simple data transfer tests done with backported patches on MeeGo n900 kernel. Cross posting to linux-omap, but I propose that we'd push these to linux-usb. Patches based on linux-usb master. Kalle Jokiniemi (2): USB: twl4030-usb: do board specific phy_power up/down OMAP3: rx51: specify phy_power for usb tranceiver arch/arm/mach-omap2/board-rx51-peripherals.c | 32 ++ drivers/usb/otg/twl4030-usb.c|9 ++- 2 files changed, 40 insertions(+), 1 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
[PATCH 1/2] USB: twl4030-usb: do board specific phy_power up/down
In case some board has special powering sequences for
the USB tranceiver, call those during __twl4030_phy_power
calls.
This is a preparation patch to allow powering down the
ISP1707 USB serial tranceiver in Nokia N900.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
---
drivers/usb/otg/twl4030-usb.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 6ca505f..dea99b1 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -348,13 +348,20 @@ static void twl4030_i2c_access(struct twl4030_usb *twl,
int on)
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
- u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
+ u8 pwr;
+ struct twl4030_usb_data *board = twl-dev-platform_data;
+
+ pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
if (on)
pwr = ~PHY_PWR_PHYPWD;
else
pwr |= PHY_PWR_PHYPWD;
+ /* do board specific power up/down, if available */
+ if (board-phy_power)
+ board-phy_power(twl-dev, 0, on);
+
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Problems with powermanagement (suspend/wake/shutdown) on OMAP3530.
We have a board with OMAP3530 (based on BeagleBoard C3), but with PWRON
connected. I want to be able to put the board in suspend and shutdown
from sw, and make it wake when it senses PWRON.
Currently I compile my own Angstrom-rootfs with OpenEmbedded, and
therefore run the linux-omap-psp 2.6.32 kernel from
git://arago-project.org/git/projects/linux-omap3.git.
By default the powerbutton worked, but pressing for 8 seconds did
nothing. I pulled in some twl4030_scripts and setup from a TI Android
Kernel with working powermanagement (patch attached), and that got the 8
second reboot working, but I don't know how to get suspend/wake/shutdown
working.
Suspend:
The following was output in my serial console:
root@board1:~# echo mem /sys/power/state
[ 4042.726776] PM: Syncing filesystems ... done.
Then I pressed Ctrl-C and got some more output:
^C[ 4046.452270] Freezing user space processes ... (elapsed 0.01
seconds) done.
[ 4046.478424] Freezing remaining freezable tasks ... (elapsed 0.01
seconds) done.
[ 4046.501892] Suspending console(s) (use no_console_suspend to debug)
I tried using no_console_suspend, and saw a crash in mmc_suspend_host
(attached).
Shutdown:
The patch gives me pm_power_off = twl4030_poweroff, but I don't know
how to shutdown my board in a way that would cause this function to be run.
And that's pretty much where I am now. I've collected some pieces of the
puzzle, but I'm not entirely sure it's the right puzzle. Should I be
able to achieve my goals with this kernel? If so, what's missing/wrong?
Regards,
Tasslehoff
From c8d51a054bc5c6f926846aa8b1e61bc0c705cb83 Mon Sep 17 00:00:00 2001
From: tasslehoff tasskj...@gmail.com
Date: Tue, 15 Mar 2011 15:33:33 +0100
Subject: [PATCH] Add powerscript and i2c driver for twl4030_poweroff.
---
arch/arm/mach-omap2/board-omap3beagle.c | 109 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/twl4030-poweroff.c| 200 +++
3 files changed, 310 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/chips/twl4030-poweroff.c
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 6dc7b23..fd247d1 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -404,6 +404,105 @@ static int beagle_twl_gpio_setup(struct device *dev,
return 0;
}
+
+static struct twl4030_ins __initdata sleep_on_seq[] = {
+ /* Turn OFF VAUX2 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VAUX2, RES_STATE_OFF), 2},
+ /* Turn off HFCLKOUT */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_HFCLKOUT, RES_STATE_OFF), 2},
+ /* Turn OFF VDD1 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VDD1, RES_STATE_OFF), 2},
+ /* Turn OFF VDD2 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VDD2, RES_STATE_OFF), 2},
+ /* Turn OFF VPLL1 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VPLL1, RES_STATE_OFF), 2},
+};
+
+static struct twl4030_script sleep_on_script __initdata = {
+ .script = sleep_on_seq,
+ .size = ARRAY_SIZE(sleep_on_seq),
+ .flags = TWL4030_SLEEP_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_p12_seq[] __initdata = {
+ /* Turn on VAUX2 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VAUX2, RES_STATE_ACTIVE), 2},
+ /* Turn on HFCLKOUT */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
+ /* Turn ON VDD1 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VDD1, RES_STATE_ACTIVE), 2},
+ /* Turn ON VDD2 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VDD2, RES_STATE_ACTIVE), 2},
+ /* Turn ON VPLL1 */
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VPLL1, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p12_script __initdata = {
+ .script = wakeup_p12_seq,
+ .size = ARRAY_SIZE(wakeup_p12_seq),
+ .flags = TWL4030_WAKEUP12_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+ {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+ .script = wakeup_p3_seq,
+ .size = ARRAY_SIZE(wakeup_p3_seq),
+ .flags = TWL4030_WAKEUP3_SCRIPT,
+};
+
+static struct twl4030_ins wrst_seq[] __initdata = {
+/*
+ * Reset twl4030.
+ * Reset VDD1 regulator.
+ * Reset VDD2 regulator.
+ * Reset VPLL1 regulator.
+ * Enable sysclk output.
+ * Reenable twl4030.
+ */
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VDD1, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VDD2, RES_STATE_WRST), 15},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VPLL1, RES_STATE_WRST), 0x60},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_P1, RES_VAUX2, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+ .script = wrst_seq,
+ .size = ARRAY_SIZE(wrst_seq),
+ .flags = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *twl4030_scripts[] __initdata = {
+ sleep_on_script,
+ wakeup_p12_script,
+ wakeup_p3_script,
+ wrst_script,
+};
+
+static struct twl4030_resconfig
Re: [PATCH 1/2] USB: twl4030-usb: do board specific phy_power up/down
Hello.
Kalle Jokiniemi wrote:
In case some board has special powering sequences for
the USB tranceiver, call those during __twl4030_phy_power
calls.
This is a preparation patch to allow powering down the
ISP1707 USB serial tranceiver in Nokia N900.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
---
drivers/usb/otg/twl4030-usb.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 6ca505f..dea99b1 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -348,13 +348,20 @@ static void twl4030_i2c_access(struct twl4030_usb *twl,
int on)
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
- u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
+ u8 pwr;
Why change this line? Also, some prefer that initialized variables precede
uninitialized ones...
+ struct twl4030_usb_data *board = twl-dev-platform_data;
+
+ pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
if (on)
pwr = ~PHY_PWR_PHYPWD;
else
pwr |= PHY_PWR_PHYPWD;
+ /* do board specific power up/down, if available */
+ if (board-phy_power)
+ board-phy_power(twl-dev, 0, on);
+
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
}
WBR, Sergei
--
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.6.39] spi/omap_mcspi: Fix broken last word xfer
Commit adef658 spi/omap_mcspi: catch xfers of non-multiple SPI word size
broke the transmission of last word in cases where access is multiple of
word size and word size is 16 or 32 bits.
Fix this by replacing the test c (word_len3) in do-while loops with
c = 'pointer increment size'. This ensures that the last word is
transmitted in above case and still allow to break the loop and prevent
variable c underflow in cases where word size != 'pointer increment size'.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Michael Jones michael.jo...@matrix-vision.de
---
I noticed the issue with wl1251 WLAN driver on Nokia N900 using today's
vanilla head a44f99c7efdb88fa41128065c9a9445c19894e34.
---
drivers/spi/omap2_mcspi.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 3a5ed06..6f86ba0 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -517,7 +517,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_vdbg(spi-dev, read-%d %02x\n,
word_len, *(rx - 1));
}
- } while (c (word_len3));
+ } while (c);
} else if (word_len = 16) {
u16 *rx;
const u16 *tx;
@@ -564,7 +564,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_vdbg(spi-dev, read-%d %04x\n,
word_len, *(rx - 1));
}
- } while (c (word_len3));
+ } while (c = 2);
} else if (word_len = 32) {
u32 *rx;
const u32 *tx;
@@ -611,7 +611,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
dev_vdbg(spi-dev, read-%d %08x\n,
word_len, *(rx - 1));
}
- } while (c (word_len3));
+ } while (c = 4);
}
/* for TX_ONLY mode, be sure all words have shifted out */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: rx51: specify phy_power for usb tranceiver
Hello.
Kalle Jokiniemi wrote:
This patch allows the ISP1707 USB tranceiver on Nokia
N900 to be disabled when usb cable is disconnected.
This saves approximately 14mA of battery current.
Patch based on work done by Heikki Krogerus on N900
maemo kernel.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
Cc: Heikki Krogerus heikki.kroge...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 32 ++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e75e240..9dd22bc 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
[...]
@@ -534,8 +537,36 @@ static struct twl4030_gpio_platform_data rx51_gpio_data = {
.setup = rx51_twlgpio_setup,
};
+static void __init rx51_xceiv_init(void)
+{
+ if (gpio_request(RX51_USB_TRANSCEIVER_RST_GPIO, NULL) 0)
+ BUG();
Why not:
BUG_ON(gpio_request(RX51_USB_TRANSCEIVER_RST_GPIO, NULL) 0);
WBR, Sergei
--
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] OMAP3: rx51: specify phy_power for usb tranceiver
Hi,
On Mon, 21 Mar 2011, Sergei Shtylyov wrote:
This patch allows the ISP1707 USB tranceiver on Nokia
N900 to be disabled when usb cable is disconnected.
This saves approximately 14mA of battery current.
Patch based on work done by Heikki Krogerus on N900
maemo kernel.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
Cc: Heikki Krogerus heikki.kroge...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 32
++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e75e240..9dd22bc 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
[...]
@@ -534,8 +537,36 @@ static struct twl4030_gpio_platform_data
rx51_gpio_data = {
.setup = rx51_twlgpio_setup,
};
+static void __init rx51_xceiv_init(void)
+{
+ if (gpio_request(RX51_USB_TRANSCEIVER_RST_GPIO, NULL) 0)
+ BUG();
Why not:
BUG_ON(gpio_request(RX51_USB_TRANSCEIVER_RST_GPIO, NULL) 0);
Well, there should not be no BUG() there in the first place. If the GPIO
cannot be requested there should be an error log and phy_power should
be set to NULL.
A.
--
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] OMAP3: rx51: specify phy_power for usb tranceiver
On Mon, 21 Mar 2011 15:50:20 +0200
Kalle Jokiniemi kalle.jokini...@nokia.com wrote:
This patch allows the ISP1707 USB tranceiver on Nokia
N900 to be disabled when usb cable is disconnected.
This saves approximately 14mA of battery current.
I can measure that these two patches save about 14 mA.
+static void __init rx51_xceiv_init(void)
+{
+ if (gpio_request(RX51_USB_TRANSCEIVER_RST_GPIO, NULL) 0)
+ BUG();
+ gpio_direction_output(RX51_USB_TRANSCEIVER_RST_GPIO, 1);
+}
gpio_request_one makes this function needless.
+static int rx51_xceiv_power(struct device *dev, int iD, int on)
+{
+ unsigned long timeout;
+
+ if (!on) {
+ /* Let musb go stdby before powering down the transceiver */
+ timeout = jiffies + msecs_to_jiffies(100);
+ while (!time_after(jiffies, timeout))
+ if (omap2_cm_read_mod_reg(CORE_MOD, CM_IDLEST1)
+ OMAP3430ES2_ST_HSOTGUSB_STDBY_MASK)
+ break;
+ if (!(omap2_cm_read_mod_reg(CORE_MOD, CM_IDLEST1)
+ OMAP3430ES2_ST_HSOTGUSB_STDBY_MASK))
+ WARN(1, could not put musb to sleep\n);
+ }
+ gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
+
Hmm... 100 ms busy loop. I wonder are there better ways in usb to
achieve this gpio control than this loop here and playing with these
registers? I believe musb/phy/etc has knowledge when they are idle and
can do some board specific stuff?
--
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: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets into VDD structure
Santosh Shilimkar santosh.shilim...@ti.com writes:
Minor comment.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Saturday, March 19, 2011 5:49 AM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsely; Benoit Cousson
Subject: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets into VDD
structure
Eliminate need for global variables for the various PRM module
offsets by
making them part of the VDD structure.
Eventually, these will likely be moved again, or more likely
removed,
but for now just getting rid of them as global variabes so that the
voltage domain initialization can be cleaned up.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.c | 109 --
---
arch/arm/mach-omap2/voltage.h |6 +-
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 10 +-
arch/arm/mach-omap2/voltagedomains44xx_data.c | 12 ++-
4 files changed, 67 insertions(+), 70 deletions(-)
[]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-
omap2/voltage.h
index e9f5408..44edc1e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -133,6 +133,9 @@ struct omap_vdd_info {
struct dentry *debug_dir;
u32 curr_volt;
bool vp_enabled;
+
+s16 prm_mod;
+s16 prm_irqst_mod;
Can you also add kernel doc for above two
entries?
Yes, thanks.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets into VDD structure
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Saturday, March 19, 2011 5:49 AM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsely; Cousson, Benoit
Subject: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets
into VDD structure
Eliminate need for global variables for the various PRM
module offsets by
making them part of the VDD structure.
Eventually, these will likely be moved again, or more likely removed,
but for now just getting rid of them as global variabes so that the
voltage domain initialization can be cleaned up.
Signed-off-by: Kevin Hilman khil...@ti.com
[sp] This is almost what I intended to do in the clean-up patches
posted earlier; but for few differences.
Putting them here as well.
[snip...snip]
diff --git a/arch/arm/mach-omap2/voltage.h
b/arch/arm/mach-omap2/voltage.h
index e9f5408..44edc1e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -133,6 +133,9 @@ struct omap_vdd_info {
struct dentry *debug_dir;
u32 curr_volt;
bool vp_enabled;
+
+s16 prm_mod;
+s16 prm_irqst_mod;
[sp] Can we match the type with the functions these are eventually
passed to?
Yes, will change them to u16.
Also, prm_mod is comstant for the silicon.
Shouldn't it be a local static instead. Else, same value is
repeated for each vdd.
Yes. As the changelog says these will likely be moved (or likely
removed all together) with further VC/VP cleanups which will move this
code into a dedicated VC/VP layers.
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: [GIT PULL] omap display subsystem changes for 2.6.39
On Mon, Mar 21, 2011 at 3:21 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Paul, Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a bit of them, and many changes also in arch/arm/mach-omap2, which unfortunately couldn't go through Tony's linux-omap tree due to dependencies on DSS driver code. The patches are mostly aiming to get OMAP4 display support up and running and both HDMI and DVI outputs should now work on Blaze and Panda boards. One problem I noticed just now, the committer names seem a bit messed up. For example, Archit Taneja has three different style names there. Do you think I should rebase and fix them? Not a big job, but it'll mean, well, rebasing. There's a minor conflict in Overo's board file. I have pushed for-paul-merged branch to gitorious, which contains a merge with Linus' tree. I'm not sure that is the best way to show how to fix the conflict, but hopefully it'll give the idea. Tomi The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34: Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-paul Archit Taneja (9): OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c OMAP2PLUS: DSS2: FEATURES: DISPC overlay code cleanup OMAP2PLUS: DSS2: FEATURES: Function to Provide the max fck supported OMAP2PLUS: DSS2: Make members of dss_clk_source generic OMAP2PLUS: DSS2: Use dss features to get clock source names of current OMAP OMAP2PLUS: DSS2: DSI: Generalize DSI PLL Clock Naming OMAP: DSS2: Functions to request/release DSI VCs OMAP: DSS2: Use request / release calls in Taal for DSI Virtual Channels. Jani Nikula (1): OMAP: DSS2: Fix def_disp module param description Janorkar, Mayuresh (2): OMAPFB: Adding a check for timings in set_def_mode OMAP: OMAPFB: Adding help for FB_OMAP_LCD_VGA option Jarkko Nikula (1): omapfb: Fix linker error in drivers/video/omap/lcd_2430sdp.c K, Mythri P (1): OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 PANDA Mayuresh Janorkar (2): OMAP2PLUS: DSS2: Add OMAP4 Kconfig support OMAP4: DSS2: Add hwmod device names for OMAP4. Murthy, Raghuveer (5): OMAP: DSS2: Adding dss_features for independent core clk divider OMAP: DSS2: Renaming register macro DISPC_DIVISOR(ch) OMAP4: DSS2: Using dss_features to set independent core clock divider OMAP: DSS2: Implement OMAP4 DSS fclk support OMAP4: PandaBoard: Adding DVI support Mythri P K (9): OMAP4: DSS2: Add display type HDMI to DSS2 OMAP4: DSS2: HDMI: Select between HDMI VENC clock source. OMAP4: DSS2: HDMI: Dispc gamma enable set/reset function for TV. OMAP4: DSS2: HDMI: HDMI driver header file addition OMAP4: DSS2: HDMI: HDMI driver addition in the DSS OMAP4: DSS2: HDMI: HDMI panel driver addition in the DSS OMAP4: DSS2: HDMI: Add makefile and kconfig changes to enable HDMI in OMAP4 OMAP4: DSS: HDMI: Call to HDMI module init to register driver. OMAP4: HDMI: Add HDMI structure in the board file for OMAP4 SDP Samreen (1): OMAP2/3/4: DSS2: Enable Display SubSystem as modules Semwal, Sumit (2): OMAP2PLUS:DSS2: add opt_clock_available in pdata OMAP2PLUS:DSS2: Use opt_clock_available from pdata Senthilvadivu Guruswamy (9): OMAP2,3: DSS2: Build omap_device for each DSS HWIP OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit to driver OMAP2, 3: DSS2: Move clocks from core driver to dss driver OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit to driver OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit to driver OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit to driver OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit to driver OMAP2,3: DSS2: Use platform device to get baseaddr OMAP2,3: DSS2: Get DSS IRQ from platform device Steve Sakoman (5): OMAP: DSS2: Add support for LG Philips LB035Q02 panel OMAP: DSS2: Add DSS2 support for Overo omap: overo: Add regulator for ads7846 OMAP: Add gpio-leds support for Overo OMAP: Add gpio-keys support for Overo Sumit Semwal (4): OMAP2, 3: DSS2: remove forced clk-disable from omap_dss_remove OMAP2,3: DSS2: replace printk with dev_dbg in init OMAP2PLUS: clocks: Align DSS clock names and roles OMAP4: DSS2: clocks: Add ick as dummy clock Taneja, Archit (5): OMAP2PLUS: DSS2: Cleanup clock source related code OMAP4: DSS2: Clock source changes for OMAP4 OMAP2PLUS: DSS2: FEATURES: Fix usage of dss_reg_field and dss_clk_source_name OMAP: DSS2:
Re: [GIT PULL] omap display subsystem changes for 2.6.39
On Mon, 2011-03-21 at 12:43 -0500, John S wrote: On Mon, Mar 21, 2011 at 3:21 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Paul, Here are OMAP display subsystem patches for 2.6.39 merge window. Quite a bit of them, and many changes also in arch/arm/mach-omap2, which unfortunately couldn't go through Tony's linux-omap tree due to dependencies on DSS driver code. snip some of these patches had problems related to HDMI: http://www.spinics.net/lists/linux-omap/msg48740.html Was this issue resolved? No. We haven't been able to reproduce, and I haven't heard of anyone else reporting problems. So I believe the patches are good enough for rc1. Tomi -- 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 v12 4/9] OMAP2+: dmtimer: convert to platform devices
Tony Lindgren t...@atomide.com writes: * Santosh Shilimkar santosh.shilim...@ti.com [110318 21:31]: * Kevin Hilman khil...@ti.com [110317 14:58]: Tony Lindgren t...@atomide.com writes: In the long run, think local timer for runtime, and then wakeup timer that gets only programmed when we enter idle. The local timer will continue operating normally after we wake-up and the wakeuptimer will be just one shot event. Of course in the omap[23] case the local timer is really a there's are real local timers. This is already the case for OMAP4 with PM series. But it doesn't work the way it is stated above. Wakeup timer is always programmed and kept handy by the timer framework because switching of clock event happened dynamically and it's too late to reprogram the next timer expiry etc. What framework does, is just switch the clock-event to wakeup capable clock-event. Hmm, the next_timer_interrupt gets called before we enter idle, is that what you mean maybe? Assuming so, to set up the wake-up timer we can read the programmed value from hardware to program the wake-up timer when entering suspend-idle or off-idle. That part can be done just fine with dmtimer framework. But in general, we don't really want to start changing the physical clock for WFI idle because of the time it takes to lock it. For retention-idle and off-idle, we have much more time. But in these case there's really no need to change the sources, all we care about is the physical timer wake-up event and can then restore the local timer. Why do you want to waste one timer hardware for this purpose alone especially when generic framework has a support? In this setup the additional wake-up timer is only needed in the retention-idle and off-idle cases. For keeping the wake-up timer separate, there are at least three reasons that I can think of: 1. We don't need to touch the clockevent and clocksource code after init except to restore them when waking from retention-idle or off-idle. 2. We don't need to initialize anything early for omaps except clock framework to set up the clockevent and clocksource. 3. We can avoid switching the physical clock for the timer which cuts down latencies at least for the basic WFI case. Not sure I fully understand what you're proposing. Maybe it's time to see some patches. What it sounds like you're proposing is to to have up to 3 physical timers reserved and not managed by the dmtimer driver 1) clocksource 2) clockevent and 3) wakeup timer. This sounds fine in theory, but I suspect it will lead to a couple things that I don't like. 1) duplicated code that managages these reserved timers and the dmtimer driver: init, read, (re)program, reset, etc. And 2) the reserved timers will have no PM, again, unless the code is duplicated from the dmtimer driver. Maybe I'm not fully understanding your proposal. I'll wait until I see patches. The one thing I do like with the above approach, assuming I understood it, is that the dmtimer driver would not need the support for the early platform devices. That is hacky, but frankly I prefer early platform devices to what I understand above. In addition, we already have a usecase for switching the clocksource as well. We currently setup a single clocksource (not using the timer_32ka dmtimer.) However, we already have use-cases where we would like to switch to a higher resolution clocksource (e.g. trace infrastructure for PM instrumentation.) I agree with Kevin. Infact I tried prototyping this one. Clock-event switching works seamlessly. Clock-source switching though isn't supported yet by generic timer framework. Sure. We need to be able to change between the local timer and the dmtimer also, and I don't see how the current dmtimer series would make that any easier. Again that can be done with a separate physical timer, no need to switch and reprogram the clocksource. If this can done via existing timer framework, I don't see point wasting another physical timer for this. In this setup we don't really need to do anything via existing timer framework, except to restore the clockevent and clocksource when waking up from retention-idle or off-idle. I agree your basic point of making clock-source and clock-event not depend on any frameworks. This is probably essential considering any generic kernel changes can impact these. Recent early_init() was a good example. May be I hold on my comments since you plan to do some patches for system timer handling. Yes, we need to cut down the early_init dependencies to minimum. The reason for that is that then we can initialize everything else that's omap specific in normal way much later than we do currently. For the timer, clock framework is essential to init early, but hwmod is not. IMO, the hwmod for a given timer should be considered lower level framework than the clock framework, and the
Re: cpufreq support for the Beagleboard.
On 03/21/2011 08:24 AM, Vishwanath Sripathy wrote: -Original Message- From: javier Martin [mailto:javier.mar...@vista-silicon.com] Sent: Monday, March 21, 2011 5:40 PM To: Vishwanath Sripathy Cc: linux-omap@vger.kernel.org Subject: Re: cpufreq support for the Beagleboard. Hi, thank you for your fast answer. I've been testing the repository you pointed me and I found that only 300MHz and 600MHz can be selected in the Beagleboard xM. Couldn't we work until 1000MHz? 1G is disabled by default in OPP table I suppose. Pls enable it (in omap36xx_opp_def_list) if your board supports it. My understanding was that the mainline kernel needed support for SmartReflex 1.5 and Adaptive Body Biasing (ABB), as found in TI's linux-omap-psp 2.6.32, before it was safe to enable the 1GHz OPP on the DM3730 (for e.g., Beagleboard xM). Is this not the case? Can we really just flip the bit in the OPP table? Do you know what's left for those patches to enter mainline? Is anybody working on it? OMAP cpufreq is undergoing some architecture/design changes and this is WIP. Vishwa Thanks, Matt Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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 -- 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 v12 4/9] OMAP2+: dmtimer: convert to platform devices
* Kevin Hilman khil...@ti.com [110321 11:31]: Tony Lindgren t...@atomide.com writes: * Santosh Shilimkar santosh.shilim...@ti.com [110318 21:31]: * Kevin Hilman khil...@ti.com [110317 14:58]: Tony Lindgren t...@atomide.com writes: In the long run, think local timer for runtime, and then wakeup timer that gets only programmed when we enter idle. The local timer will continue operating normally after we wake-up and the wakeuptimer will be just one shot event. Of course in the omap[23] case the local timer is really a there's are real local timers. This is already the case for OMAP4 with PM series. But it doesn't work the way it is stated above. Wakeup timer is always programmed and kept handy by the timer framework because switching of clock event happened dynamically and it's too late to reprogram the next timer expiry etc. What framework does, is just switch the clock-event to wakeup capable clock-event. Hmm, the next_timer_interrupt gets called before we enter idle, is that what you mean maybe? Assuming so, to set up the wake-up timer we can read the programmed value from hardware to program the wake-up timer when entering suspend-idle or off-idle. That part can be done just fine with dmtimer framework. But in general, we don't really want to start changing the physical clock for WFI idle because of the time it takes to lock it. For retention-idle and off-idle, we have much more time. But in these case there's really no need to change the sources, all we care about is the physical timer wake-up event and can then restore the local timer. Why do you want to waste one timer hardware for this purpose alone especially when generic framework has a support? In this setup the additional wake-up timer is only needed in the retention-idle and off-idle cases. For keeping the wake-up timer separate, there are at least three reasons that I can think of: 1. We don't need to touch the clockevent and clocksource code after init except to restore them when waking from retention-idle or off-idle. 2. We don't need to initialize anything early for omaps except clock framework to set up the clockevent and clocksource. 3. We can avoid switching the physical clock for the timer which cuts down latencies at least for the basic WFI case. Not sure I fully understand what you're proposing. Maybe it's time to see some patches. What it sounds like you're proposing is to to have up to 3 physical timers reserved and not managed by the dmtimer driver 1) clocksource 2) clockevent and 3) wakeup timer. Only the clocksource and clockevent timers are reserved and not managed by dmtimer code. And this is only for omap2 and 3. For omap4+, clocksource and clockevent should eventually use the local timers instead of dmtimers during the runtime. The wake-up timer can be done the same way for omap2, 3 and 4+, and that can be managed by the dmtimer code and it can be a regular device driver. This sounds fine in theory, but I suspect it will lead to a couple things that I don't like. 1) duplicated code that managages these reserved timers and the dmtimer driver: init, read, (re)program, reset, etc. And 2) the reserved timers will have no PM, again, unless the code is duplicated from the dmtimer driver. There should not be a problem with duplicated code, that can be avoided. And I believe the only PM needed on omap2 3 is to stop the clock, so that code can be shared too. For omap4+, the dmtimer is only needed for wake-up. Maybe I'm not fully understanding your proposal. I'll wait until I see patches. The one thing I do like with the above approach, assuming I understood it, is that the dmtimer driver would not need the support for the early platform devices. That is hacky, but frankly I prefer early platform devices to what I understand above. Well the dmtimer code can then become just a regular platform_device based driver, except for clockevent and clocksource on omap2 3. Yes, we need to cut down the early_init dependencies to minimum. The reason for that is that then we can initialize everything else that's omap specific in normal way much later than we do currently. For the timer, clock framework is essential to init early, but hwmod is not. IMO, the hwmod for a given timer should be considered lower level framework than the clock framework, and the hwmod for a timer should be initialized before a timer is used for anything, including a clocksource, clockevent etc. Yes that's true for all the other drivers. But the irq handler code, clockevent and clocksource are special cases as they are needed early. So in this case it makes sense to treat them separately to avoid the additional dependencies. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
RE: cpufreq support for the Beagleboard.
-Original Message- From: Matt Johnson [mailto:johns...@crhc.illinois.edu] Sent: Tuesday, March 22, 2011 12:15 AM To: Vishwanath Sripathy Cc: javier Martin; linux-omap@vger.kernel.org Subject: Re: cpufreq support for the Beagleboard. On 03/21/2011 08:24 AM, Vishwanath Sripathy wrote: -Original Message- From: javier Martin [mailto:javier.mar...@vista-silicon.com] Sent: Monday, March 21, 2011 5:40 PM To: Vishwanath Sripathy Cc: linux-omap@vger.kernel.org Subject: Re: cpufreq support for the Beagleboard. Hi, thank you for your fast answer. I've been testing the repository you pointed me and I found that only 300MHz and 600MHz can be selected in the Beagleboard xM. Couldn't we work until 1000MHz? 1G is disabled by default in OPP table I suppose. Pls enable it (in omap36xx_opp_def_list) if your board supports it. My understanding was that the mainline kernel needed support for SmartReflex 1.5 and Adaptive Body Biasing (ABB), as found in TI's linux-omap-psp 2.6.32, before it was safe to enable the 1GHz OPP on the DM3730 (for e.g., Beagleboard xM). Is this not the case? Can we really just flip the bit in the OPP table? Sorry, I should have been more explicit. Yes you need to have ABB and SR enabled before enabling 1G. Vishwa Do you know what's left for those patches to enter mainline? Is anybody working on it? OMAP cpufreq is undergoing some architecture/design changes and this is WIP. Vishwa Thanks, Matt Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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 -- 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: [GIT PULL] omap display subsystem changes for 2.6.39
On Mon, Mar 21, 2011 at 11:51:23AM +0200, Tomi Valkeinen wrote: One problem I noticed just now, the committer names seem a bit messed up. For example, Archit Taneja has three different style names there. Do you think I should rebase and fix them? Not a big job, but it'll mean, well, rebasing. No need, this is what .mailmap is for. It seems there are quite a few variations, I've added entries now for all of: Archit Taneja arc...@ti.com Mayuresh Janorkar ma...@ti.com Mythri P K mythr...@ti.com Sumit Semwal sumit.sem...@ti.com which traps all of the offenders in these patches. There seems to be a general issue of author names and sign-offs using reverse order naming, I assume because this is some absurd convention used by TI's mail servers. We can of course continue fixing them up as they pop up, but people should ideally be aware of the need for consistency before committing things, too. A bit of name mangling is certainly a lesser evil than rewriting history, though. There's a minor conflict in Overo's board file. I have pushed for-paul-merged branch to gitorious, which contains a merge with Linus' tree. I'm not sure that is the best way to show how to fix the conflict, but hopefully it'll give the idea. Seemed pretty straightforward, I took care of it and made sure that it still built. I assume Tony or someone will yell loudly if I've inadvertently broken something :-) Pulled now. I'll send things off to Linus shortly. -- 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: [GIT PULL] omap display subsystem changes for 2.6.39
On Tue, 2011-03-22 at 00:40 -0500, Paul Mundt wrote: On Mon, Mar 21, 2011 at 11:51:23AM +0200, Tomi Valkeinen wrote: One problem I noticed just now, the committer names seem a bit messed up. For example, Archit Taneja has three different style names there. Do you think I should rebase and fix them? Not a big job, but it'll mean, well, rebasing. No need, this is what .mailmap is for. It seems there are quite a few variations, I've added entries now for all of: Archit Taneja arc...@ti.com Mayuresh Janorkar ma...@ti.com Mythri P K mythr...@ti.com Sumit Semwal sumit.sem...@ti.com which traps all of the offenders in these patches. There seems to be a general issue of author names and sign-offs using reverse order naming, I assume because this is some absurd convention used by TI's mail servers. Yes, TI's mail servers have this nice feature. We can of course continue fixing them up as they pop up, but people should ideally be aware of the need for consistency before committing things, too. A bit of name mangling is certainly a lesser evil than rewriting history, though. I think the mix of multiple different styles is a result of me taking some patches from emails (thus getting Lastname, Firstname style names) and some directly from git trees or patch attachments (thus getting whatever was configured in .gitconfig). We'll need to see (in TI) how to make this more sensible. There's a minor conflict in Overo's board file. I have pushed for-paul-merged branch to gitorious, which contains a merge with Linus' tree. I'm not sure that is the best way to show how to fix the conflict, but hopefully it'll give the idea. Seemed pretty straightforward, I took care of it and made sure that it still built. I assume Tony or someone will yell loudly if I've inadvertently broken something :-) Pulled now. I'll send things off to Linus shortly. Thanks! Tomi -- 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
