Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On Thu, May 26, 2011 at 22:06, Santosh Shilimkar santosh.shilim...@ti.com wrote: On 5/26/2011 11:40 PM, Kevin Hilman wrote: So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. We are running only one instance and for the exact same reason as above. You are completely right and that's the whole intention of those CPUMASK two lines in the initialization code. What am I missing? Not at all. So not have cpufreq driver registered at all for CPU1? Life would be a lot simpler in omap2-cpufreq.c as a result. but that said, two views: a) future silicon somewhere ahead might need the current infrastructure to scale into different tables.. b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but* cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but .../cpu1/online is present). Keep in mind that userspace is usually written chip independent. IMHO registering drivers for both devices do make sense they reflect what the reality of the system is. 2 cpus scaling together - why do we want to OMAP specific stuff here? 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: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On 5/27/2011 11:37 AM, Menon, Nishanth wrote: On Thu, May 26, 2011 at 22:06, Santosh Shilimkar santosh.shilim...@ti.com wrote: On 5/26/2011 11:40 PM, Kevin Hilman wrote: So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. We are running only one instance and for the exact same reason as above. You are completely right and that's the whole intention of those CPUMASK two lines in the initialization code. What am I missing? Not at all. So not have cpufreq driver registered at all for CPU1? Life would be a lot simpler in omap2-cpufreq.c as a result. but that said, two views: a) future silicon somewhere ahead might need the current infrastructure to scale into different tables.. b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but* cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but .../cpu1/online is present). Keep in mind that userspace is usually written chip independent. IMHO registering drivers for both devices do make sense they reflect what the reality of the system is. 2 cpus scaling together - why do we want to OMAP specific stuff here? It's not OMAP specific Nishant. And this feature is supported by CPUFREQ driver. My Intel machine uses the same exact scheme for CPUFREQ. It's feature provided specifically for hardwares with individual CPU scaling limitation. Instead of CPU's, whole CPU cluster scales together. Both CPU's still have same consistent view of all CPUFREQ controls. But in back-ground, CPU1 is carrying only symbolic links. We make use of related/affected cpu feature which is supported by generic CPUFREQ driver. Nothing OMAP-specific here. And as I said i n other thread, if at all in future we get CPU's which can scale indepedently, we just need to change that one line where we specify the relation between CPU's. It's as trivial as that. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap updates for 2.6.40
* Koen Kooi k...@dominion.thruhere.net [110526 19:02]: Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: Hi Linus, Please pull omap updates for this merge window from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus This contains clean-up to shrink down omap specific code a bit. Also included are some fixes. But basically no new code at this point. What about updates to board files? Like adding support for the xM rev C to board-omap3beagle.c. Sorry we're doing only code coalescing and fixes for this merge window as discussed on LAKML. Otherwise it's hard to see the code coalescing in the diffstats, so new code will need to wait a bit. I'll take a look and see if we can justify some fix like trivial patches like the revision detection patches during the -rc cycle. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 5/27/2011 1:24 AM, Hilman, Kevin wrote:
Nishanth Menonn...@ti.com writes:
From: Moiz Sonasathm-sonas...@ti.com
For OMAP4460, GPIO-7 of bank1 is used for controling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
drop to 0.9 V.
ouch. I knew one of these days something like this was going to happen
with GPIO resets.
BTW, don't we have the same kind of issue with the debug UART? I
remember that you had to do some hacks at some point to change these
hwmod flags in the UART code.
In general we do not want to reset nor idle an IP that was potentially
already properly configured by bootloader or early Linux boot code.
Regards,
Benoit
Re: $SUBJECT, hwmod is not an acronym. Please use lower case.
Originally from:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae4f0de03b17c064d9ce90a580230f1a596ec1
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menonn...@ti.com
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2f51a5a..27319c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
{ .role = dbclk, .clk = gpio1_dbclk },
};
-static struct omap_hwmod omap44xx_gpio1_hwmod = {
+static struct omap_hwmod omap443x_gpio1_hwmod = {
.name = gpio1,
.class =omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio1_irqs,
@@ -1761,7 +1761,27 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
.dev_attr =gpio_dev_attr,
.slaves = omap44xx_gpio1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+static struct omap_hwmod omap446x_gpio1_hwmod = {
+ .name = gpio1,
+ .class =omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_gpio1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs),
+ .main_clk = gpio1_ick,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
+ },
+ },
+ .opt_clks = gpio1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks),
+ .dev_attr =gpio_dev_attr,
+ .slaves = omap44xx_gpio1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
};
This is a board-specific problem that you've fixed in a way that
affects every 4460-based device.
Rather than setting the flag in the hwmod data, you need to fix this
in a board-specific way.
The hwmod layer provides an API for this: omap_hwmod_no_setup_reset()
which should be called by board-specific code.
Kevin
/* gpio2 */
@@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_dss_venc_hwmod,
/* gpio class */
- omap44xx_gpio1_hwmod,
+ omap443x_gpio1_hwmod,
+ omap446x_gpio1_hwmod,
omap44xx_gpio2_hwmod,
omap44xx_gpio3_hwmod,
omap44xx_gpio4_hwmod,
--
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/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups
On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman khil...@ti.com wrote: Inspired by Jean's work to move PM code to modules, I decided it's time to remove a bunch of ugly and difficult to maintain code from PM debug. Indeed this code is a spaghetti mess and makes pm-debug difficult to be modularized. The main chunk here is removing the register dump features for OMAP2/OMAP3 which are awful to read, and impossible to scale for OMAP4+. Also, there are now some userspace /dev/mem-based tools (like omapconf) that can handle this type of thing much better, and with a much better interface and display. Agree. However we still need the equivalent of [1] to retrieve the PRCM registers just before and after the WFI instructions. I would like to propose some replacement when the current code clean-up is settled down a bit. [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=5dd36389eb6ef4837a2aad128e4bd0226468c171 Regards, Jean Series applies to v2.6.39. Kevin Hilman (4): OMAP3: PM debug: remove sleep_while_idle feature OMAP2: PM debug: remove register dumping OMAP3: PM debug: remove register dumping OMAP2: PM debug: move wakeup timer into clockevent code arch/arm/mach-omap2/pm-debug.c | 362 - arch/arm/mach-omap2/pm.h | 9 - arch/arm/mach-omap2/pm24xx.c | 6 +- arch/arm/mach-omap2/pm34xx.c | 6 - arch/arm/mach-omap2/timer-gp.c | 33 +++- arch/arm/plat-omap/include/plat/dmtimer.h | 1 - 6 files changed, 32 insertions(+), 385 deletions(-) -- 1.7.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: [PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature
On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman khil...@ti.com wrote: Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is currently available as an OMAP-specific debugfs entry. This duplicates existing ARM-generic functionality available as a boot-time option using the boot cmdline option 'hohlt'. 'nohlt' is only for the default arch idle handler (pm_idle). It does not apply to the cpuidle handler (omap3_enter_idle) which depends on CONFIG_CPU_IDLE. If runtime configuration of this is needed, then adding a debugfs entry for the ARM-generic hlt/nohlt interface should be added. Is there a need for it? Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] Some omap_device/hwmod/pwrdomain patches
I came up with these patches while implementing pm runtime adaptation for DSS driver. I'm not quite sure on who's turf they belong, or do they even belong together, but here they are anyway. get_context_loss_count patch was discussed on l-o with Kevin. The omap_device_reset patch I made as some parts of DSS currently presume that the HW module is reset when it is enabled, and the reset is better handled in hwmod code. Changes in v2 * Dropped can-ever-lose-context patch * Use INT_MAX instead of ~(1 31) when masking the ctx loss count Tomi Tomi Valkeinen (2): OMAP: change get_context_loss_count ret value to int OMAP: add omap_device_reset() arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/powerdomain.c | 14 ++ arch/arm/mach-omap2/powerdomain.h |2 +- arch/arm/plat-omap/include/plat/omap-pm.h |4 ++-- arch/arm/plat-omap/include/plat/omap_device.h |3 ++- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +- arch/arm/plat-omap/omap-pm-noop.c | 24 +--- arch/arm/plat-omap/omap_device.c | 25 - 8 files changed, 58 insertions(+), 18 deletions(-) -- 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
[PATCHv2 1/2] OMAP: change get_context_loss_count ret value to int
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.
Change the functions to return an int, with negative value meaning an
error.
OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |2 +-
arch/arm/mach-omap2/powerdomain.c | 14 ++
arch/arm/mach-omap2/powerdomain.h |2 +-
arch/arm/plat-omap/include/plat/omap-pm.h |4 ++--
arch/arm/plat-omap/include/plat/omap_device.h |2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +-
arch/arm/plat-omap/omap-pm-noop.c | 24 +---
arch/arm/plat-omap/omap_device.c |2 +-
8 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..4f0d554 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2332,7 +2332,7 @@ ohsps_unlock:
* Returns the context loss count of the powerdomain assocated with @oh
* upon success, or zero if no powerdomain exists for @oh.
*/
-u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
+int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..9d53a34 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -935,16 +935,16 @@ int pwrdm_post_transition(void)
* @pwrdm: struct powerdomain * to wait for
*
* Context loss count is the sum of powerdomain off-mode counter, the
- * logic off counter and the per-bank memory off counter. Returns 0
+ * logic off counter and the per-bank memory off counter. Returns negative
* (and WARNs) upon error, otherwise, returns the context loss count.
*/
-u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
{
int i, count;
if (!pwrdm) {
WARN(1, powerdomain: %s: pwrdm is null\n, __func__);
- return 0;
+ return -ENODEV;
}
count = pwrdm-state_counter[PWRDM_POWER_OFF];
@@ -953,7 +953,13 @@ u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
for (i = 0; i pwrdm-banks; i++)
count += pwrdm-ret_mem_off_counter[i];
- pr_debug(powerdomain: %s: context loss count = %u\n,
+ /*
+* Context loss count has to be a non-negative value. Clear the sign
+* bit to get a value range from 0 to INT_MAX.
+*/
+ count = INT_MAX;
+
+ pr_debug(powerdomain: %s: context loss count = %d\n,
pwrdm-name, count);
return count;
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index d23d979..012827f 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -207,7 +207,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
-u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index c0a7520..68df031 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -350,9 +350,9 @@ unsigned long omap_pm_cpu_get_freq(void);
* driver must restore device context. If the number of context losses
* exceeds the maximum positive integer, the function will wrap to 0 and
* continue counting. Returns the number of context losses for this device,
- * or zero upon error.
+ * or negative value upon error.
*/
-u32 omap_pm_get_dev_context_loss_count(struct device *dev);
+int omap_pm_get_dev_context_loss_count(struct device *dev);
void omap_pm_enable_off_mode(void);
void omap_pm_disable_off_mode(void);
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..70d31d0 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -107,7 +107,7 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);
int omap_device_align_pm_lat(struct platform_device *pdev,
[PATCHv2 2/2] OMAP: add omap_device_reset()
Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 23 +++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 70d31d0..bcf1b35 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -108,6 +108,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
int omap_device_get_context_loss_count(struct platform_device *pdev);
+int omap_device_reset(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9753f71..4e6fc1b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -324,6 +324,29 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
}
/**
+ * omap_device_reset - reset hwmods of given device
+ * @pdev: struct platform_device *
+ *
+ * Reset all hwmods associated with the given device. If a reset of a hwmod
+ * fails the rest of the hwmods are skipped and the error is returned.
+ */
+int omap_device_reset(struct platform_device *pdev)
+{
+ struct omap_device *od;
+ int i, r;
+
+ od = _find_by_pdev(pdev);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ r = omap_hwmod_reset(od-hwmods[i]);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+
+/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
*
--
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 08/13] OMAP2+: PM: provide the next timer event API to PM modules
On Fri, May 27, 2011 at 1:00 AM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Provide omap_pm_tick_nohz_get_sleep_length_us so that the code
from the OMAP PM modules can use it.
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch is doing more than mentioned in the changelog.
Agree, there is a bit of clean-up/rework as well. Will re-organize.
...
+#endif
+
+#ifdef CONFIG_NO_HZ
+unsigned long omap_pm_tick_nohz_get_sleep_length_us(void)
+{
+ return ktime_to_us(tick_nohz_get_sleep_length());
+}
+EXPORT_SYMBOL(omap_pm_tick_nohz_get_sleep_length_us);
+#endif
Usage of this is OMAP2-specific and needed for this very old, debug-only
interface.
I was inspired by some of what you did in this series, and
will attempt to make your life easier by just removing this code all
together. I just posted a series for that.
Only OMAP2 uses it currently but I think it is useful to have the time
to next tick available for debug purpose.
BTW this change implements it in a more generic way:
tick_nohz_get_sleep_length is generic and also used by e.g. cpuidle to
determine the next state to enter.
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] OMAP2+: PM: export suspend_set_ops to PM modules
On Fri, May 27, 2011 at 1:09 AM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Export the suspend_set_ops API as omap_pm_suspend_set_ops in the pm
generic code, under CONFIG_SUSPEND.
Note -hack warning-: since the 'suspend_valid_only_mem' function is
not exported to modules, fill the 'valid' field value of
'struct platform_suspend_ops' in the common code.
Signed-off-by: Jean Pihet j-pi...@ti.com
Can you try the patch below instead? If that works, I'll submit to
Rafael/linux-pm.
This is much cleaner! We need this pushed upstream.
Acked-by: Jean Pihet j-pi...@ti.com
Thanks,
Jean
Kevin
From d3aca6317f5f92a5fd4fbaf1d039232c83cac4f4 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 26 May 2011 16:10:13 -0700
Subject: [PATCH] PM: export suspend_set_ops, suspend_valid_only_mem
Some platforms wish to implement their PM core code as modules. To
do so, these functions need to be exported for modules.
Reported-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
kernel/power/suspend.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 6275970..eca495d 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -44,6 +44,7 @@ void suspend_set_ops(const struct platform_suspend_ops *ops)
suspend_ops = ops;
mutex_unlock(pm_mutex);
}
+EXPORT_SYMBOL(suspend_set_ops);
bool valid_state(suspend_state_t state)
{
@@ -65,6 +66,7 @@ int suspend_valid_only_mem(suspend_state_t state)
{
return state == PM_SUSPEND_MEM;
}
+EXPORT_SYMBOL(suspend_valid_only_mem);
static int suspend_test(int level)
{
--
1.7.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
Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio
On Fri, May 27, 2011 at 1:35 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote:
Move OMAP GPIO driver to drivers/gpio. Builds whenever
CONFIG_ARCH_OMAP=y.
Signed-off-by: Kevin Hilman khil...@ti.com
Patch unfortunately doesn't apply cleanly to Linus' tree. There's
been some changes to gpio.c compared to the tree this patch was
prepared against.
Also, if you use the -M flag when preparing the patch, then I'll be
able to see what the changes are during the move, and fix things up
intelligently if anything breaks.
Can you respin and repost the series quickly?
While you're at it, can you name the moved file
drivers/gpio/gpio-omap.c? ('-' instead of '_'. Why, yes, I am a
nitpicker.)
g.
--
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
Error while rotating LCD fb - detected fb_set_par error, error code: -22
Hi, I am using a omap3530 http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=omap3530 based board. I am trying to rotate the LCD using*/sys/class/graphics/fb0/rotate*. The rotation works only for 0 degree and 270 degrees. When trying to rotate for 90 or 180 degree it give error message *detected fb_set_par error, error code: -22 *and does not rotate. The log output is below.* * / # cat /proc/cmdline omapdss.def_disp=lcd30 console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait lpj=1949696 omapfb.rotate=1 omapfb.rotate_type=1 omap_vout.vid1_static_vrf b_alloc=y omapfb.vrfb=y / # echo 0 /sys/class/graphics/fb0/rotate detected fb_set_par error, error code: -22 / # echo 1 /sys/class/graphics/fb0/rotate / # echo 2 /sys/class/graphics/fb0/rotate detected fb_set_par error, error code: -22 / # echo 3 /sys/class/graphics/fb0/rotate / # echo 1 /sys/class/graphics/fb0/rotate Can some one help me in solving this issue. Regards, HM Thalib -- 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: OMAP: Get rid of section mismatch warnings
* Russell King - ARM Linux li...@arm.linux.org.uk [110526 16:51]:
On Thu, May 26, 2011 at 06:37:32AM -0700, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [110526 05:56]:
On 5/26/2011 6:30 PM, Silesh C V wrote:
Get rid of the following and 8 other similar section mismatch
warnings
I send this [1] patch a month back. It's still not considered
though even after reminder.
[1] https://patchwork.kernel.org/patch/684831/
Applying now into devel-fixes with additional fixes from Silesh.
Updated patch below.
I also have this from a while back. There's also some nastyness in
twl4030-power.c which requires basically s/__init/__devinit/ to almost
the entire file.
OK thanks. Kevin, can you queue this fix? Assuming the move of omap
gpio to drivers/gpio happens this merge window, this needs to be
updated for the path.
Regards,
Tony
8
From: Russell King rmk+ker...@arm.linux.org.uk
Fix various section mismatch warnings:
WARNING: arch/arm/plat-omap/built-in.o(.devinit.text+0x46c): Section mismatch
in reference from the function omap_gpio_probe() to the function
.init.text:omap_gpio_chip_init()
The function __devinit omap_gpio_probe() references
a function __init omap_gpio_chip_init().
If omap_gpio_chip_init is only used by omap_gpio_probe then
annotate omap_gpio_chip_init with a matching annotation.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x423c): Section mismatch in
reference from the function pm_dbg_regset_init() to the function
.init.text:pm_dbg_init()
The function pm_dbg_regset_init() references
the function __init pm_dbg_init().
This is often because pm_dbg_regset_init lacks a __init
annotation or the annotation of pm_dbg_init is wrong.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
--
arch/arm/mach-omap2/pm-debug.c |4 ++--
arch/arm/plat-omap/gpio.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..3800ee0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1629,7 +1629,7 @@ static void omap_gpio_mod_init(struct gpio_bank *bank,
int id)
}
}
-static void __init omap_gpio_chip_init(struct gpio_bank *bank)
+static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
{
int j;
static int gpio;
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 125f565..169e930 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -189,7 +189,7 @@ static struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
-static int __init pm_dbg_init(void);
+static int pm_dbg_init(void);
enum {
DEBUG_FILE_COUNTERS = 0,
@@ -595,7 +595,7 @@ static int option_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(pm_dbg_option_fops, option_get, option_set,
%llu\n);
-static int __init pm_dbg_init(void)
+static int pm_dbg_init(void)
{
int i;
struct dentry *d;
--
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: OMAP: Get rid of section mismatch warnings
* Igor Grinberg grinb...@compulab.co.il [110526 17:05]: On 05/26/11 16:37, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110526 05:56]: On 5/26/2011 6:30 PM, Silesh C V wrote: Get rid of the following and 8 other similar section mismatch warnings I send this [1] patch a month back. It's still not considered though even after reminder. [1] https://patchwork.kernel.org/patch/684831/ Applying now into devel-fixes with additional fixes from Silesh. Updated patch below. Can this [1] also be applied to the devel-fixes, please? It is a month old today... Applying thanks. Regards, Tony [1] https://patchwork.kernel.org/patch/733531/ -- 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 updates for 2.6.40
* Tony Lindgren t...@atomide.com [110527 09:29]: * Koen Kooi k...@dominion.thruhere.net [110526 19:02]: Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: Hi Linus, Please pull omap updates for this merge window from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus This contains clean-up to shrink down omap specific code a bit. Also included are some fixes. But basically no new code at this point. What about updates to board files? Like adding support for the xM rev C to board-omap3beagle.c. Sorry we're doing only code coalescing and fixes for this merge window as discussed on LAKML. Otherwise it's hard to see the code coalescing in the diffstats, so new code will need to wait a bit. I'll take a look and see if we can justify some fix like trivial patches like the revision detection patches during the -rc cycle. Koen, the patch above needs to be refreshed to apply to current mainline kernel. It also seems to contain some whitespace errors. Care to refresh it and repost? Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 5/27/2011 9:26 AM, Govindraj wrote: On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit b-cous...@ti.com mailto:b-cous...@ti.com wrote: On 5/27/2011 1:24 AM, Hilman, Kevin wrote: Nishanth Menonn...@ti.com mailto:n...@ti.com writes: From: Moiz Sonasathm-sonas...@ti.com mailto:m-sonas...@ti.com For OMAP4460, GPIO-7 of bank1 is used for controling the TPS modes, hence GPIO1 should not be reset during init as reset will cause the TPS voltage to drop to 0.9 V. ouch. I knew one of these days something like this was going to happen with GPIO resets. BTW, don't we have the same kind of issue with the debug UART? I remember that you had to do some hacks at some point to change these hwmod flags in the UART code. Yes. we use below flags. uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; Yeah, that's ugly... we do have to get rid of that as well using some board settings / API. 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: [GIT PULL] omap updates for 2.6.40
Op 27 mei 2011, om 13:04 heeft Tony Lindgren het volgende geschreven: * Tony Lindgren t...@atomide.com [110527 09:29]: * Koen Kooi k...@dominion.thruhere.net [110526 19:02]: Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: Hi Linus, Please pull omap updates for this merge window from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus This contains clean-up to shrink down omap specific code a bit. Also included are some fixes. But basically no new code at this point. What about updates to board files? Like adding support for the xM rev C to board-omap3beagle.c. Sorry we're doing only code coalescing and fixes for this merge window as discussed on LAKML. Otherwise it's hard to see the code coalescing in the diffstats, so new code will need to wait a bit. I'll take a look and see if we can justify some fix like trivial patches like the revision detection patches during the -rc cycle. Koen, the patch above needs to be refreshed to apply to current mainline kernel. It also seems to contain some whitespace errors. Care to refresh it and repost? I'm refreshing it right now and will after testing. regards, Koen-- 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 2/2] OMAP: add omap_device_reset()
Hi Tomi,
On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:
Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.
We've never exposed it because we are trying to avoid that any driver
play with asynchronous HW reset. That can lead to undefined HW behavior :-(
Do you have some strong need for that?
Regards,
Benoit
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 23 +++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 70d31d0..bcf1b35 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -108,6 +108,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
int omap_device_get_context_loss_count(struct platform_device *pdev);
+int omap_device_reset(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9753f71..4e6fc1b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -324,6 +324,29 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
}
/**
+ * omap_device_reset - reset hwmods of given device
+ * @pdev: struct platform_device *
+ *
+ * Reset all hwmods associated with the given device. If a reset of a hwmod
+ * fails the rest of the hwmods are skipped and the error is returned.
+ */
+int omap_device_reset(struct platform_device *pdev)
+{
+ struct omap_device *od;
+ int i, r;
+
+ od = _find_by_pdev(pdev);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ r = omap_hwmod_reset(od-hwmods[i]);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+
+/**
* omap_device_count_resources - count number of struct resource entries
needed
* @od: struct omap_device *
*
--
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] OMAP3: beagle: add support for beagleboard xM revision C
The USB enable GPIO has been inverted again and the USER button moved.
Future revisions will now fall back to xM rev C instead of unknown.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v1:
* updated against mainline to take Igors gpio cleanup into account
* removed xM rev B checks, no boards with that ID were ever produced,
rev B boards show up as rev A
* double checked whitespace:
total: 0 errors, 0 warnings, 89 lines checked
patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has no
obvious style problems and is ready for submission.
arch/arm/mach-omap2/board-omap3beagle.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..177769b 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -63,7 +63,9 @@
* AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
* C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
* C4 = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1 - unused
+ * XMC = GPIO173, GPIO172, GPIO171: 0 1 0
*/
enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -71,6 +73,7 @@ enum {
OMAP3BEAGLE_BOARD_C1_3,
OMAP3BEAGLE_BOARD_C4,
OMAP3BEAGLE_BOARD_XM,
+ OMAP3BEAGLE_BOARD_XMC,
};
static u8 omap3_beagle_version;
@@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
+ case 2:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+ break;
default:
printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n, beagle_rev);
- omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
}
}
@@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
{
int r, usb_pwr_level;
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
@@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
* high / others active low)
* DVI reset GPIO is different between beagle revisions
*/
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ if (cpu_is_omap3630()) {
beagle_dvi_device.reset_gpio = 129;
/*
-* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 1 on xM controls the TFP410's enable line (active low)
* gpio + 2 control varies depending on the board rev as below:
* P7/P8 revisions(prototype): Camera EN
* A2+ revisions (production): LDO (DVI, serial, led blocks)
@@ -295,7 +301,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure DVI_LDO_EN\n,
__func__);
} else {
- usb_pwr_level = GPIOF_OUT_INIT_LOW;
beagle_dvi_device.reset_gpio = 170;
/*
* REVISIT: need ehci-omap hooks for external VBUS
@@ -305,6 +310,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ /* Only xM rev A and xM rev B use active high */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ else
+ usb_pwr_level = GPIOF_OUT_INIT_LOW;
+
gpio_request_one(gpio + TWL4030_GPIO_MAX, usb_pwr_level, nEN_USB_PWR);
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
@@ -525,7 +536,7 @@ static void __init beagle_opp_init(void)
}
/* Custom OPP enabled for XM */
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
struct omap_hwmod *dh = omap_hwmod_lookup(iva);
struct device *dev;
@@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+
+ if (cpu_is_omap3630())
+ gpio_buttons[0].gpio = 4;
+
Re: [PATCHv2 2/2] OMAP: add omap_device_reset()
On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undefined HW behavior :-( Do you have some strong need for that? DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. Why does it lead to undefined HW behaviour? Isn't it much better to reset the HW before starting to use it to be 100% sure it's in known and valid state? Especially in error situations it may be difficult (even impossible) to recover without reset. DISPC has been known to froze in some sync lost situations, and, if I recall right, if DSI transfer is aborted the only way to recover is to reset the DSI block (on OMAP3). 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 v2] OMAP3: beagle: add support for beagleboard xM revision C
Hi Koen, Please CC LAKML for patches like this, otherwise Tony, will have to post all of them before pull requesting. On 05/27/11 15:40, Koen Kooi wrote: The USB enable GPIO has been inverted again and the USER button moved. Future revisions will now fall back to xM rev C instead of unknown. Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- Changes since v1: * updated against mainline to take Igors gpio cleanup into account * removed xM rev B checks, no boards with that ID were ever produced, rev B boards show up as rev A * double checked whitespace: total: 0 errors, 0 warnings, 89 lines checked patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has no obvious style problems and is ready for submission. arch/arm/mach-omap2/board-omap3beagle.c | 31 +++ 1 files changed, 23 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index be71426..177769b 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c [...] @@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void) omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); omap3_beagle_init_rev(); omap3_beagle_i2c_init(); + + if (cpu_is_omap3630()) + gpio_buttons[0].gpio = 4; Don't get me wrong, I want this patch in mainline as soon as possible. Just curious, what the hell happened to indentation here? :) checkpatch.pl does not spot things like this... interesting... If you want to leave this as is, go ahead, I don't mind, just curious. -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: beagle: add support for beagleboard xM revision C
The USB enable GPIO has been inverted again and the USER button moved
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
* fixed indentation error checkpatch missed
Changes since v1:
* updated against mainline to take Igors gpio cleanup into account
* removed xM rev B checks, no boards with that ID were ever produced, rev B
boards show up as rev A
* double checked whitespace:
total: 0 errors, 0 warnings, 89 lines checked
patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch
has no obvious style problems and is ready for submission.
arch/arm/mach-omap2/board-omap3beagle.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..81fff9d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -63,7 +63,9 @@
* AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
* C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
* C4 = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1 - unused
+ * XMC = GPIO173, GPIO172, GPIO171: 0 1 0
*/
enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -71,6 +73,7 @@ enum {
OMAP3BEAGLE_BOARD_C1_3,
OMAP3BEAGLE_BOARD_C4,
OMAP3BEAGLE_BOARD_XM,
+ OMAP3BEAGLE_BOARD_XMC,
};
static u8 omap3_beagle_version;
@@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
+ case 2:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+ break;
default:
printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n, beagle_rev);
- omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
}
}
@@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
{
int r, usb_pwr_level;
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
@@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
* high / others active low)
* DVI reset GPIO is different between beagle revisions
*/
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ if (cpu_is_omap3630()) {
beagle_dvi_device.reset_gpio = 129;
/*
-* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 1 on xM controls the TFP410's enable line (active low)
* gpio + 2 control varies depending on the board rev as below:
* P7/P8 revisions(prototype): Camera EN
* A2+ revisions (production): LDO (DVI, serial, led blocks)
@@ -295,7 +301,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure DVI_LDO_EN\n,
__func__);
} else {
- usb_pwr_level = GPIOF_OUT_INIT_LOW;
beagle_dvi_device.reset_gpio = 170;
/*
* REVISIT: need ehci-omap hooks for external VBUS
@@ -305,6 +310,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ /* Only xM rev A and xM rev B use active high */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ else
+ usb_pwr_level = GPIOF_OUT_INIT_LOW;
+
gpio_request_one(gpio + TWL4030_GPIO_MAX, usb_pwr_level, nEN_USB_PWR);
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
@@ -525,7 +536,7 @@ static void __init beagle_opp_init(void)
}
/* Custom OPP enabled for XM */
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
struct omap_hwmod *dh = omap_hwmod_lookup(iva);
struct device *dev;
@@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+
+ if (cpu_is_omap3630())
+ gpio_buttons[0].gpio = 4;
+
platform_add_devices(omap3_beagle_devices,
Re: [PATCH] OMAP3: beagle: add support for beagleboard xM revision C
That was meant to say '[PATCH v3]', sorry about that.
Op 27 mei 2011, om 15:32 heeft Koen Kooi het volgende geschreven:
The USB enable GPIO has been inverted again and the USER button moved
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
* fixed indentation error checkpatch missed
Changes since v1:
* updated against mainline to take Igors gpio cleanup into account
* removed xM rev B checks, no boards with that ID were ever produced, rev
B boards show up as rev A
* double checked whitespace:
total: 0 errors, 0 warnings, 89 lines checked
patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has
no obvious style problems and is ready for submission.
arch/arm/mach-omap2/board-omap3beagle.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..81fff9d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -63,7 +63,9 @@
*AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
*C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
*C4 = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1 - unused
+ * XMC = GPIO173, GPIO172, GPIO171: 0 1 0
*/
enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -71,6 +73,7 @@ enum {
OMAP3BEAGLE_BOARD_C1_3,
OMAP3BEAGLE_BOARD_C4,
OMAP3BEAGLE_BOARD_XM,
+ OMAP3BEAGLE_BOARD_XMC,
};
static u8 omap3_beagle_version;
@@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
+ case 2:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+ break;
default:
printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n, beagle_rev);
- omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
}
}
@@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
{
int r, usb_pwr_level;
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
@@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
* high / others active low)
* DVI reset GPIO is different between beagle revisions
*/
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ if (cpu_is_omap3630()) {
beagle_dvi_device.reset_gpio = 129;
/*
- * gpio + 1 on Xm controls the TFP410's enable line (active low)
+ * gpio + 1 on xM controls the TFP410's enable line (active low)
* gpio + 2 control varies depending on the board rev as below:
* P7/P8 revisions(prototype): Camera EN
* A2+ revisions (production): LDO (DVI, serial, led blocks)
@@ -295,7 +301,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure DVI_LDO_EN\n,
__func__);
} else {
- usb_pwr_level = GPIOF_OUT_INIT_LOW;
beagle_dvi_device.reset_gpio = 170;
/*
* REVISIT: need ehci-omap hooks for external VBUS
@@ -305,6 +310,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
+ /* Only xM rev A and xM rev B use active high */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ else
+ usb_pwr_level = GPIOF_OUT_INIT_LOW;
+
gpio_request_one(gpio + TWL4030_GPIO_MAX, usb_pwr_level, nEN_USB_PWR);
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
@@ -525,7 +536,7 @@ static void __init beagle_opp_init(void)
}
/* Custom OPP enabled for XM */
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
struct omap_hwmod *dh = omap_hwmod_lookup(iva);
struct device *dev;
@@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+
+ if (cpu_is_omap3630())
+
Re: [PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C
Op 27 mei 2011, om 15:20 heeft Igor Grinberg het volgende geschreven: Hi Koen, Please CC LAKML for patches like this, otherwise Tony, will have to post all of them before pull requesting. On 05/27/11 15:40, Koen Kooi wrote: The USB enable GPIO has been inverted again and the USER button moved. Future revisions will now fall back to xM rev C instead of unknown. Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- Changes since v1: * updated against mainline to take Igors gpio cleanup into account * removed xM rev B checks, no boards with that ID were ever produced, rev B boards show up as rev A * double checked whitespace: total: 0 errors, 0 warnings, 89 lines checked patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has no obvious style problems and is ready for submission. arch/arm/mach-omap2/board-omap3beagle.c | 31 +++ 1 files changed, 23 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index be71426..177769b 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c [...] @@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void) omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); omap3_beagle_init_rev(); omap3_beagle_i2c_init(); + +if (cpu_is_omap3630()) +gpio_buttons[0].gpio = 4; Don't get me wrong, I want this patch in mainline as soon as possible. Just curious, what the hell happened to indentation here? :) Thanks for spotting that! Copy/paste with a non tab aware terminal. checkpatch.pl does not spot things like this... interesting... If you want to leave this as is, go ahead, I don't mind, just curious. I sent a new one, but screwed up the subject, I'll see if someone objects to that and resend as needed. regards, Koen-- 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: Error while rotating LCD fb - detected fb_set_par error, error code: -22
On Friday 27 May 2011 03:40 PM, Mohamed Thalib H wrote: Hi, I am using a omap3530 http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=omap3530 based board. I am trying to rotate the LCD using*/sys/class/graphics/fb0/rotate*. The rotation works only for 0 degree and 270 degrees. When trying to rotate for 90 or 180 degree it give error message *detected fb_set_par error, error code: -22 *and does not rotate. The log output is below.* * / # cat /proc/cmdline omapdss.def_disp=lcd30 console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait lpj=1949696 omapfb.rotate=1 omapfb.rotate_type=1 omap_vout.vid1_static_vrf b_alloc=y omapfb.vrfb=y / # echo 0 /sys/class/graphics/fb0/rotate detected fb_set_par error, error code: -22 / # echo 1 /sys/class/graphics/fb0/rotate / # echo 2 /sys/class/graphics/fb0/rotate detected fb_set_par error, error code: -22 / # echo 3 /sys/class/graphics/fb0/rotate / # echo 1 /sys/class/graphics/fb0/rotate Can some one help me in solving this issue. Regards, HM Thalib For you info I am using 2.6.34 kernel. LCD size is 240x480 While tracing though the source code I have found out that in file *drivers/video/omap2/dss/overlay.c *function *dss_check_overlay() *it is checking if *dw info-pos_x + outw *which is *(240 0 + 400)* that is if my overlay width is smaller than screen size, if so return error. Have any one faced the same scenario. If I am doing something wrong, Please let me know the correct steps to rotate the screen. -- 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 2/2] OMAP: add omap_device_reset()
On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undefined HW behavior :-( Do you have some strong need for that? DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. Why does it lead to undefined HW behaviour? Isn't it much better to reset the HW before starting to use it to be 100% sure it's in known and valid state? In theory, but since your are resetting only the DSS IP, it can leads to side effect at SoC level. Especially wrt to clock management. Especially in error situations it may be difficult (even impossible) to recover without reset. DISPC has been known to froze in some sync lost situations, and, if I recall right, if DSI transfer is aborted the only way to recover is to reset the DSI block (on OMAP3). In case of recovery error it makes sense. What we did with hardreset is to re-assert the reset upon disable of the module and then the next enable will de-assert it. Softreset does not do that today. My only concern is that people might start abusing that kind of API to use that for funtionnal purpose instead of error recovery. This other issue is that it will add another OMAP specific IP to the driver. 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: [PATCHv2 2/2] OMAP: add omap_device_reset()
On 5/27/2011 8:13 PM, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undefined HW behavior :-( Do you have some strong need for that? DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. Why does it lead to undefined HW behaviour? Isn't it much better to reset the HW before starting to use it to be 100% sure it's in known and valid state? In theory, but since your are resetting only the DSS IP, it can leads to side effect at SoC level. Especially wrt to clock management. Especially in error situations it may be difficult (even impossible) to recover without reset. DISPC has been known to froze in some sync lost situations, and, if I recall right, if DSI transfer is aborted the only way to recover is to reset the DSI block (on OMAP3). In case of recovery error it makes sense. What we did with hardreset is to re-assert the reset upon disable of the module and then the next enable will de-assert it. Softreset does not do that today. I didn't notice this patch but Paul reported an issue on beagle which was making L3 error handling driver hang. Later on after debugging we noticed, that DSS initiator was throwing timeout error. As a temporary fix, we removed the timeout error from the handler since root-cause was not known. [1] I am not sure but may be a proper DSS reset might fix that issue as well. Regards Santosh [1] https://patchwork.kernel.org/patch/769482/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Some omap_device/hwmod/pwrdomain patches
Tomi Valkeinen tomi.valkei...@ti.com writes: [...] This isn't something in general that drivers should be aware of, so I'd rather not see this exposed to drivers (unless there's a real need.) Ok, I'll drop the patch. I don't think there's any need for this in DSS. As soon as I finish the move to device power domains (hopefully for 2.6.41), the driver's callbacks will only be called if the device has lost context, so checking for context loss will not be needed at all at the driver level. This sounds good. Runtime PM's suspend resume callbacks or something else? Runtime PM callbacks. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Govindraj govindraj...@gmail.com writes: On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit b-cous...@ti.com wrote: On 5/27/2011 1:24 AM, Hilman, Kevin wrote: Nishanth Menonn...@ti.com writes: From: Moiz Sonasathm-sonas...@ti.com For OMAP4460, GPIO-7 of bank1 is used for controling the TPS modes, hence GPIO1 should not be reset during init as reset will cause the TPS voltage to drop to 0.9 V. ouch. I knew one of these days something like this was going to happen with GPIO resets. BTW, don't we have the same kind of issue with the debug UART? I remember that you had to do some hacks at some point to change these hwmod flags in the UART code. Yes. we use below flags. uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; This is a hack (written by me) because the UART driver is not runtime PM adapted. When UART driver is runtime PM adapted, this will not be needed. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/2] OMAP: add omap_device_reset()
On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote: On 5/27/2011 8:13 PM, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undefined HW behavior :-( Do you have some strong need for that? DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. Why does it lead to undefined HW behaviour? Isn't it much better to reset the HW before starting to use it to be 100% sure it's in known and valid state? In theory, but since your are resetting only the DSS IP, it can leads to side effect at SoC level. Especially wrt to clock management. Especially in error situations it may be difficult (even impossible) to recover without reset. DISPC has been known to froze in some sync lost situations, and, if I recall right, if DSI transfer is aborted the only way to recover is to reset the DSI block (on OMAP3). In case of recovery error it makes sense. What we did with hardreset is to re-assert the reset upon disable of the module and then the next enable will de-assert it. Softreset does not do that today. I didn't notice this patch but Paul reported an issue on beagle which was making L3 error handling driver hang. Later on after debugging we noticed, that DSS initiator was throwing timeout error. As a temporary fix, we removed the timeout error from the handler since root-cause was not known. [1] I am not sure but may be a proper DSS reset might fix that issue as well. Yeah, but this is the issue... people will start abusing that to fix any kind of problems instead of finding the root cause. That should be use only to fix real HW issue that cannot be solve properly by SW. 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/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups
Jean Pihet jean.pi...@newoldbits.com writes: On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman khil...@ti.com wrote: Inspired by Jean's work to move PM code to modules, I decided it's time to remove a bunch of ugly and difficult to maintain code from PM debug. Indeed this code is a spaghetti mess and makes pm-debug difficult to be modularized. The main chunk here is removing the register dump features for OMAP2/OMAP3 which are awful to read, and impossible to scale for OMAP4+. Also, there are now some userspace /dev/mem-based tools (like omapconf) that can handle this type of thing much better, and with a much better interface and display. Agree. However we still need the equivalent of [1] to retrieve the PRCM registers just before and after the WFI instructions. Correct, but as that patch is not upstream, I'm not considering it as support that needs to be maintained. I would like to propose some replacement when the current code clean-up is settled down a bit. Great! Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=5dd36389eb6ef4837a2aad128e4bd0226468c171 Regards, Jean Series applies to v2.6.39. Kevin Hilman (4): OMAP3: PM debug: remove sleep_while_idle feature OMAP2: PM debug: remove register dumping OMAP3: PM debug: remove register dumping OMAP2: PM debug: move wakeup timer into clockevent code arch/arm/mach-omap2/pm-debug.c | 362 - arch/arm/mach-omap2/pm.h | 9 - arch/arm/mach-omap2/pm24xx.c | 6 +- arch/arm/mach-omap2/pm34xx.c | 6 - arch/arm/mach-omap2/timer-gp.c | 33 +++- arch/arm/plat-omap/include/plat/dmtimer.h | 1 - 6 files changed, 32 insertions(+), 385 deletions(-) -- 1.7.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][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Hi Kevin, On 5/27/2011 4:59 PM, Hilman, Kevin wrote: Govindrajgovindraj...@gmail.com writes: [...] uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; This is a hack (written by me) because the UART driver is not runtime PM adapted. When UART driver is runtime PM adapted, this will not be needed. The UART can support reset and idle? There is no assumption for the UART used during the early debug phase? Don't we have to maintain its state? It will be indeed better if we don't have to. 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: [PATCHv2 2/2] OMAP: add omap_device_reset()
On 5/27/2011 8:30 PM, Cousson, Benoit wrote: On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote: On 5/27/2011 8:13 PM, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undefined HW behavior :-( Do you have some strong need for that? DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. Why does it lead to undefined HW behaviour? Isn't it much better to reset the HW before starting to use it to be 100% sure it's in known and valid state? In theory, but since your are resetting only the DSS IP, it can leads to side effect at SoC level. Especially wrt to clock management. Especially in error situations it may be difficult (even impossible) to recover without reset. DISPC has been known to froze in some sync lost situations, and, if I recall right, if DSI transfer is aborted the only way to recover is to reset the DSI block (on OMAP3). In case of recovery error it makes sense. What we did with hardreset is to re-assert the reset upon disable of the module and then the next enable will de-assert it. Softreset does not do that today. I didn't notice this patch but Paul reported an issue on beagle which was making L3 error handling driver hang. Later on after debugging we noticed, that DSS initiator was throwing timeout error. As a temporary fix, we removed the timeout error from the handler since root-cause was not known. [1] I am not sure but may be a proper DSS reset might fix that issue as well. Yeah, but this is the issue... people will start abusing that to fix any kind of problems instead of finding the root cause. May be you are right. But shouldn't we do a proper reset of the IP. On this same topic, I have a patch for timer IP too. As per TRM, soft reset is not enough to properly reset the timer IP and expecting the additional register to be used for reseting the timer IP. That should be use only to fix real HW issue that cannot be solve properly by SW. I agree but TRM doesn't say the softreset is enough to ensure the certain IP's are properly reseted. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature
Jean Pihet jean.pi...@newoldbits.com writes: On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman khil...@ti.com wrote: Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is currently available as an OMAP-specific debugfs entry. This duplicates existing ARM-generic functionality available as a boot-time option using the boot cmdline option 'hohlt'. 'nohlt' is only for the default arch idle handler (pm_idle). It does not apply to the cpuidle handler (omap3_enter_idle) which depends on CONFIG_CPU_IDLE. AFAICT, it affects CPUidle also, since CPUidle replaces pm_idle, which is protected by the hlt_counter check. I think the CPUidle folks are looking for a way to replace using pm_idle though. After that happens, there are a couple options. 1) add a check for hlt_counter in the CPUidle path, or 2) just disable CPUidle at Kconfig level. If runtime configuration of this is needed, then adding a debugfs entry for the ARM-generic hlt/nohlt interface should be added. Is there a need for it? I don't think so.But my point was that if anyone wants this feature back, this would be the way to add it. 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: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On Fri, May 27, 2011 at 1:26 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/27/2011 11:37 AM, Menon, Nishanth wrote:
On Thu, May 26, 2011 at 22:06, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/26/2011 11:40 PM, Kevin Hilman wrote:
So here's a dumb question, being rather ignorant of CPUfreq on SMP.
Should we be running a CPUfreq instance on both CPUs when they cannot be
scaled independently?
What is being scaled here is actually the cluster (the MPU SS via
dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to
have a an instance of the driver per scalable device, which in this case
is a single MPU SS.
We are running only one instance and for the exact same reason as above.
You are completely right and that's the whole intention of those
CPUMASK two lines in the initialization code.
What am I missing?
Not at all.
So not have cpufreq driver registered at all for CPU1? Life would be a
lot simpler in omap2-cpufreq.c as a result. but that said, two views:
a) future silicon somewhere ahead might need the current
infrastructure to scale into different tables..
b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but*
cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but
.../cpu1/online is present). Keep in mind that userspace is usually
written chip independent. IMHO registering drivers for both devices do
make sense they reflect what the reality of the system is. 2 cpus
scaling together - why do we want to OMAP specific stuff here?
It's not OMAP specific Nishant.
And this feature is supported by CPUFREQ driver. My Intel machine
uses the same exact scheme for CPUFREQ. It's feature provided
specifically for hardwares with individual CPU scaling
limitation. Instead of CPU's, whole CPU cluster scales
together.
Both CPU's still have same consistent view of all CPUFREQ controls.
But in back-ground, CPU1 is carrying only symbolic links.
We make use of related/affected cpu feature which is
supported by generic CPUFREQ driver. Nothing OMAP-specific
here.
Santosh is referring to this code in our cpufreq driver:
/*
* On OMAP SMP configuartion, both processors share the voltage
* and clock. So both CPUs needs to be scaled together and hence
* needs software co-ordination. Use cpufreq affected_cpus
* interface to handle this scenario. Additional is_smp() check
* is to keep SMP_ON_UP build working.
*/
if (is_smp()) {
policy-shared_type = CPUFREQ_SHARED_TYPE_ANY;
cpumask_or(cpumask, cpumask_of(policy-cpu), cpumask);
cpumask_copy(policy-cpus, cpumask);
}
policy-cpus knows about each CPU now (in fact, due to this you will
see /sys/devices/system/cpu/cpu1/cpufreq is in fact a symlink to its
cpu0 sibling!)
This is pretty good in fact, since governors like ondemand take into
consideration *all* of the CPUs in policy-cpus:
/* Get Absolute Load - in terms of freq */
max_load_freq = 0; - tracks greatest need across all CPUs
for_each_cpu(j, policy-cpus) {
... find max_load_freq ...
Ultimate effect is that we run a single workqueue only on CPU0
(kondemand or whatever) that takes the load characteristics of both
CPU0 and CPU1 into account.
Regards,
Mike
And as I said i n other thread, if at all in future we get
CPU's which can scale indepedently, we just need to change
that one line where we specify the relation between CPU's.
It's as trivial as that.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] OMAP: don't trace functions called from sched_clock
Tony,
On Sun, May 8, 2011 at 14:51, Rabin Vincent ra...@rab.in wrote:
omap_readl() is used from the sched_clock() implementations and so must
be marked notrace to avoid recursion in ftrace. Same thing with
mpu_read() for OMAP1.
Signed-off-by: Rabin Vincent ra...@rab.in
Comments on this patch? This is a bugfix; the function graph tracer
will crash and burn on OMAP without this.
---
arch/arm/mach-omap1/io.c | 2 +-
arch/arm/mach-omap1/time.c | 2 +-
arch/arm/mach-omap2/io.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 870886a..36ec2d7 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -158,7 +158,7 @@ u16 omap_readw(u32 pa)
}
EXPORT_SYMBOL(omap_readw);
-u32 omap_readl(u32 pa)
+u32 notrace omap_readl(u32 pa)
{
return __raw_readl(OMAP1_IO_ADDRESS(pa));
}
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 6885d2f..88c5c5e 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -203,7 +203,7 @@ static struct irqaction omap_mpu_timer2_irq = {
.handler = omap_mpu_timer2_interrupt,
};
-static cycle_t mpu_read(struct clocksource *cs)
+static cycle_t notrace mpu_read(struct clocksource *cs)
{
return ~omap_mpu_timer_read(1);
}
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 441e79d..f1987b1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -441,7 +441,7 @@ u16 omap_readw(u32 pa)
}
EXPORT_SYMBOL(omap_readw);
-u32 omap_readl(u32 pa)
+u32 notrace omap_readl(u32 pa)
{
return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
}
--
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] GPIO: OMAP: move to drivers/gpio
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, May 27, 2011 at 1:35 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote:
Move OMAP GPIO driver to drivers/gpio. Builds whenever
CONFIG_ARCH_OMAP=y.
Signed-off-by: Kevin Hilman khil...@ti.com
Patch unfortunately doesn't apply cleanly to Linus' tree. There's
been some changes to gpio.c compared to the tree this patch was
prepared against.
Also, if you use the -M flag when preparing the patch, then I'll be
able to see what the changes are during the move, and fix things up
intelligently if anything breaks.
Can you respin and repost the series quickly?
While you're at it, can you name the moved file
drivers/gpio/gpio-omap.c? ('-' instead of '_'. Why, yes, I am a
nitpicker.)
OK, I rebased onto RMK's for-linus branch (already pulled by Linus),
which contained some other changes touching gpio.c.I also s/_/-/ in
the filename.
Below is pull request.
Thanks,
Kevin
The following changes since commit 9a55d9752d8abfc62f1ab05ccc790d22a0c8e7c0:
Merge branch 'devel-stable' into for-linus (2011-05-23 19:28:04 +0100)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
for_2.6.40/gpio-move
Kevin Hilman (2):
GPIO: OMAP: move register offset defines into plat/gpio.h
GPIO: OMAP: move to drivers/gpio
arch/arm/plat-omap/Makefile|2 +-
arch/arm/plat-omap/include/plat/gpio.h | 103 +++
drivers/gpio/Makefile |1 +
.../plat-omap/gpio.c = drivers/gpio/gpio-omap.c | 105
4 files changed, 105 insertions(+), 106 deletions(-)
rename arch/arm/plat-omap/gpio.c = drivers/gpio/gpio-omap.c (93%)
--
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 00/14] GPIO: OMAP: first round of cleanup
Hi Grant, Grant Likely grant.lik...@secretlab.ca writes: On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote: Start moving SoC-specific register handling out of the driver by passing in register offsets in via platform data. Also, move OMAP1 MPUIO IRQ handling over to genric IRQ chip. Applies on top of Tony's for-next branch (which include's the generic IRQ chip work from tglx) and the OMAP GPIO driver move to drivers/gpio. Hey Kevin, If you've got a branch with this series in it and tested, then I'd be happy to pull that instead of applying the patches myself. Being very late in the cycle, I'd prefer to save this for 2.6.41. Let's just do the move for 2.6.40, and I'll (re)submit this early in the 2.6.41 cycle. 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/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature
On Fri, May 27, 2011 at 5:26 PM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman khil...@ti.com wrote: Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is currently available as an OMAP-specific debugfs entry. This duplicates existing ARM-generic functionality available as a boot-time option using the boot cmdline option 'hohlt'. 'nohlt' is only for the default arch idle handler (pm_idle). It does not apply to the cpuidle handler (omap3_enter_idle) which depends on CONFIG_CPU_IDLE. AFAICT, it affects CPUidle also, since CPUidle replaces pm_idle, which is protected by the hlt_counter check. That is correct, please ignore my comment. I think the CPUidle folks are looking for a way to replace using pm_idle though. After that happens, there are a couple options. 1) add a check for hlt_counter in the CPUidle path, or 2) just disable CPUidle at Kconfig level. 1) makes sense if the kernel parameter is used to enable/disable idle. If runtime configuration of this is needed, then adding a debugfs entry for the ARM-generic hlt/nohlt interface should be added. Is there a need for it? I don't think so. But my point was that if anyone wants this feature back, this would be the way to add it. Kevin Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio
Kevin Hilman khil...@ti.com writes: [...] OK, I rebased onto RMK's for-linus branch (already pulled by Linus), which contained some other changes touching gpio.c.I also s/_/-/ in the filename. Below is pull request. BTW, apologies for the ssh URL. I used it because I just pushed it, and wanted to be sure you didn't have to wait for the mirrors. Kevin The following changes since commit 9a55d9752d8abfc62f1ab05ccc790d22a0c8e7c0: Merge branch 'devel-stable' into for-linus (2011-05-23 19:28:04 +0100) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_2.6.40/gpio-move Kevin Hilman (2): GPIO: OMAP: move register offset defines into plat/gpio.h GPIO: OMAP: move to drivers/gpio arch/arm/plat-omap/Makefile|2 +- arch/arm/plat-omap/include/plat/gpio.h | 103 +++ drivers/gpio/Makefile |1 + .../plat-omap/gpio.c = drivers/gpio/gpio-omap.c | 105 4 files changed, 105 insertions(+), 106 deletions(-) rename arch/arm/plat-omap/gpio.c = drivers/gpio/gpio-omap.c (93%) -- 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 2/2] OMAP: add omap_device_reset()
On Fri, 2011-05-27 at 16:43 +0200, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undefined HW behavior :-( Do you have some strong need for that? DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of course, but requires extra work. I noticed the problem with DSI driver, it didn't work anymore if I didn't reset it. Why does it lead to undefined HW behaviour? Isn't it much better to reset the HW before starting to use it to be 100% sure it's in known and valid state? In theory, but since your are resetting only the DSS IP, it can leads to side effect at SoC level. Especially wrt to clock management. Out of interest, can you tell more what problems it could cause? Can they be solved in the hwmod reset code? Also one thing to note, VENC needs a softreset after changing certain configurations, as per TRM. However, VENC doesn't use the standard syscontrol mechanism, so that cannot be done via omap_device interface anyway. Especially in error situations it may be difficult (even impossible) to recover without reset. DISPC has been known to froze in some sync lost situations, and, if I recall right, if DSI transfer is aborted the only way to recover is to reset the DSI block (on OMAP3). In case of recovery error it makes sense. What we did with hardreset is to re-assert the reset upon disable of the module and then the next enable will de-assert it. Softreset does not do that today. My only concern is that people might start abusing that kind of API to use that for funtionnal purpose instead of error recovery. Why do you see it's abusing? I think it's a good driver design to reset the HW before starting operation. Perhaps it's true that in some cases reset could hide (or fix, in a way) a bug in the driver, but in the end what we want is a driver that works in every situation. And doing a HW reset sounds a good way to make the driver more robust. This other issue is that it will add another OMAP specific IP to the driver. I presume IP == API. And that is true. But isn't reset functionality present in most HW blocks, and thus would it make a good addition to the generic API? 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][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Cousson, Benoit b-cous...@ti.com writes: Hi Kevin, On 5/27/2011 4:59 PM, Hilman, Kevin wrote: Govindrajgovindraj...@gmail.com writes: [...] uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; This is a hack (written by me) because the UART driver is not runtime PM adapted. When UART driver is runtime PM adapted, this will not be needed. The UART can support reset and idle? There is no assumption for the UART used during the early debug phase? No. As long as the UART driver is doing runtime PM properly, there are no assumptions required. Kevin Don't we have to maintain its state? It will be indeed better if we don't have to. 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 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Cousson, Benoit b-cous...@ti.com writes: [...] In general we do not want to reset nor idle an IP that was potentially already properly configured by bootloader or early Linux boot code. Actually, the opposite is true. The kernel should not make any assumptions about what the bootloader has or has not done. We need to have a kernel that can boot from any bootloader (or none, like using kexec) and be able to start from a known hardware state. Any use of HWMOD_INIT_NO_IDLE, HWMOD_INIT_NO_RESET should be a rare exception and well documented. 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] GPIO: OMAP: move to drivers/gpio
On Fri, May 27, 2011 at 09:04:37AM -0700, Kevin Hilman wrote: Kevin Hilman khil...@ti.com writes: [...] OK, I rebased onto RMK's for-linus branch (already pulled by Linus), which contained some other changes touching gpio.c.I also s/_/-/ in the filename. Below is pull request. BTW, apologies for the ssh URL. I used it because I just pushed it, and wanted to be sure you didn't have to wait for the mirrors. Kevin Merged, thanks. g. -- 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] OMAP: don't trace functions called from sched_clock
Rabin Vincent ra...@rab.in writes: omap_readl() is used from the sched_clock() implementations and so must be marked notrace to avoid recursion in ftrace. Same thing with mpu_read() for OMAP1. Signed-off-by: Rabin Vincent ra...@rab.in 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] ARM: OMAP: Get rid of section mismatch warnings
Tony Lindgren t...@atomide.com writes: * Russell King - ARM Linux li...@arm.linux.org.uk [110526 16:51]: On Thu, May 26, 2011 at 06:37:32AM -0700, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [110526 05:56]: On 5/26/2011 6:30 PM, Silesh C V wrote: Get rid of the following and 8 other similar section mismatch warnings I send this [1] patch a month back. It's still not considered though even after reminder. [1] https://patchwork.kernel.org/patch/684831/ Applying now into devel-fixes with additional fixes from Silesh. Updated patch below. I also have this from a while back. There's also some nastyness in twl4030-power.c which requires basically s/__init/__devinit/ to almost the entire file. OK thanks. Kevin, can you queue this fix? Assuming the move of omap gpio to drivers/gpio happens this merge window, this needs to be updated for the path. Yeah, I'll take care of this. GPIO move is now merged for 2.6.40, so I'll queue this as a fix for the first -rc cycle. 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
boot hang using OMAP for-next + Russell's for-linus
FYI... I just found this, but won't be able to look into it until next week, so if anyone needs a weekend debug project... Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+ busybox initramfs) kernel on my 3430/n900 just fine. I then tried to merge in Russell's for-linus branch and it hangs during boot. It appears to hang in the init/registration of i2c busses. Commenting out the i2c bus registration from board-rx51-peripherals and disabling a few of the users of i2c, I was able to boot. 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: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
Turquette, Mike mturque...@ti.com writes:
On Fri, May 27, 2011 at 1:26 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/27/2011 11:37 AM, Menon, Nishanth wrote:
On Thu, May 26, 2011 at 22:06, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/26/2011 11:40 PM, Kevin Hilman wrote:
So here's a dumb question, being rather ignorant of CPUfreq on SMP.
Should we be running a CPUfreq instance on both CPUs when they cannot be
scaled independently?
What is being scaled here is actually the cluster (the MPU SS via
dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to
have a an instance of the driver per scalable device, which in this case
is a single MPU SS.
We are running only one instance and for the exact same reason as above.
You are completely right and that's the whole intention of those
CPUMASK two lines in the initialization code.
What am I missing?
Not at all.
So not have cpufreq driver registered at all for CPU1? Life would be a
lot simpler in omap2-cpufreq.c as a result. but that said, two views:
a) future silicon somewhere ahead might need the current
infrastructure to scale into different tables..
b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but*
cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but
.../cpu1/online is present). Keep in mind that userspace is usually
written chip independent. IMHO registering drivers for both devices do
make sense they reflect what the reality of the system is. 2 cpus
scaling together - why do we want to OMAP specific stuff here?
It's not OMAP specific Nishant.
And this feature is supported by CPUFREQ driver. My Intel machine
uses the same exact scheme for CPUFREQ. It's feature provided
specifically for hardwares with individual CPU scaling
limitation. Instead of CPU's, whole CPU cluster scales
together.
Both CPU's still have same consistent view of all CPUFREQ controls.
But in back-ground, CPU1 is carrying only symbolic links.
We make use of related/affected cpu feature which is
supported by generic CPUFREQ driver. Nothing OMAP-specific
here.
Santosh is referring to this code in our cpufreq driver:
/*
* On OMAP SMP configuartion, both processors share the voltage
* and clock. So both CPUs needs to be scaled together and hence
* needs software co-ordination. Use cpufreq affected_cpus
* interface to handle this scenario. Additional is_smp() check
* is to keep SMP_ON_UP build working.
*/
if (is_smp()) {
policy-shared_type = CPUFREQ_SHARED_TYPE_ANY;
cpumask_or(cpumask, cpumask_of(policy-cpu), cpumask);
cpumask_copy(policy-cpus, cpumask);
}
policy-cpus knows about each CPU now (in fact, due to this you will
see /sys/devices/system/cpu/cpu1/cpufreq is in fact a symlink to its
cpu0 sibling!)
This is pretty good in fact, since governors like ondemand take into
consideration *all* of the CPUs in policy-cpus:
/* Get Absolute Load - in terms of freq */
max_load_freq = 0; - tracks greatest need across all CPUs
for_each_cpu(j, policy-cpus) {
... find max_load_freq ...
Ultimate effect is that we run a single workqueue only on CPU0
(kondemand or whatever) that takes the load characteristics of both
CPU0 and CPU1 into account.
OK, makes sense. Thanks for the description.
All of this came up because this series is going through contortions to
make two CPUfreq registrations only using one freq_table, protect
against concurrent access from different CPUs etc., which led me to
wonder why we need two registrations.
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 pm_wip/voltdm_nm] ARM: OMAP: Explicitly mask VPVOLTAGE field
Hi Todd,
Todd Poynor toddpoy...@google.com writes:
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 - u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask and shift symbols
already defined, added as new fields in struct omap_vp_common.
Signed-off-by: Todd Poynor toddpoy...@google.com
Thanks for the patch. Indeed it's better to make this explict.
Minor nit: we don't need both the mask and the shift defined. Just add
the mask, and the code can use __ffs(mask) to get the shift value. This
is what I've done in the rest of the VC/VP code.
Also, can you make the subject prefix 'OMAP: VP: ...'
Thanks,
Kevin
---
arch/arm/mach-omap2/vp.c |3 ++-
arch/arm/mach-omap2/vp.h |4
arch/arm/mach-omap2/vp3xxx_data.c |3 +++
arch/arm/mach-omap2/vp44xx_data.c |2 ++
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index e7d38f6..c3b7fde 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -227,7 +227,8 @@ unsigned long omap_vp_get_curr_volt(struct voltagedomain
*voltdm)
return 0;
}
- curr_vsel = voltdm-read(vp-voltage);
+ curr_vsel = (voltdm-read(vp-voltage) vp-common-vpvoltage_mask)
+ vp-common-vpvoltage_shift;
if (!voltdm-pmic || !voltdm-pmic-vsel_to_uv) {
pr_warning(%s: PMIC function to convert vsel to voltage
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0d63267..cb62a7b 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -63,6 +63,8 @@ struct omap_vp_ops {
* @vlimitto_vddmin_shift: VDDMIN field shift in PRM_VP*_VLIMITTO reg
* @vlimitto_vddmax_shift: VDDMAX field shift in PRM_VP*_VLIMITTO reg
* @vlimitto_timeout_shift: TIMEOUT field shift in PRM_VP*_VLIMITTO reg
+ * @vpvoltage_mask: VPVOLTAGE field mask in PRM_VP*_VOLTAGE reg
+ * @vpvoltage_shift: VPVOLTAGE field shift in PRM_VP*_VOLTAGE reg
*/
struct omap_vp_common {
u32 vpconfig_erroroffset_mask;
@@ -79,6 +81,8 @@ struct omap_vp_common {
u8 vlimitto_vddmin_shift;
u8 vlimitto_vddmax_shift;
u8 vlimitto_timeout_shift;
+ u8 vpvoltage_mask;
+ u8 vpvoltage_shift;
const struct omap_vp_ops *ops;
};
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c
b/arch/arm/mach-omap2/vp3xxx_data.c
index d429c44..0b149e0 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -51,6 +51,9 @@ static const struct omap_vp_common omap3_vp_common = {
.vlimitto_vddmin_shift = OMAP3430_VDDMIN_SHIFT,
.vlimitto_vddmax_shift = OMAP3430_VDDMAX_SHIFT,
.vlimitto_timeout_shift = OMAP3430_TIMEOUT_SHIFT,
+ .vpvoltage_mask = OMAP3430_VPVOLTAGE_MASK,
+ .vpvoltage_shift = OMAP3430_VPVOLTAGE_SHIFT,
+
.ops = omap3_vp_ops,
};
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 0daf2a4..174d6f7 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -51,6 +51,8 @@ static const struct omap_vp_common omap4_vp_common = {
.vlimitto_vddmin_shift = OMAP4430_VDDMIN_SHIFT,
.vlimitto_vddmax_shift = OMAP4430_VDDMAX_SHIFT,
.vlimitto_timeout_shift = OMAP4430_TIMEOUT_SHIFT,
+ .vpvoltage_mask = OMAP4430_VPVOLTAGE_MASK,
+ .vpvoltage_shift = OMAP4430_VPVOLTAGE_SHIFT,
.ops = omap4_vp_ops,
};
--
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] PM: export suspend_set_ops, suspend_valid_only_mem
Some platforms wish to implement their PM core suspend code as
modules. To do so, these functions need to be exported to modules.
Reported-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v2.6.39
kernel/power/suspend.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 6275970..eca495d 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -44,6 +44,7 @@ void suspend_set_ops(const struct platform_suspend_ops *ops)
suspend_ops = ops;
mutex_unlock(pm_mutex);
}
+EXPORT_SYMBOL(suspend_set_ops);
bool valid_state(suspend_state_t state)
{
@@ -65,6 +66,7 @@ int suspend_valid_only_mem(suspend_state_t state)
{
return state == PM_SUSPEND_MEM;
}
+EXPORT_SYMBOL(suspend_valid_only_mem);
static int suspend_test(int level)
{
--
1.7.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
Re: [PATCH 09/13] OMAP2+: PM: export suspend_set_ops to PM modules
Jean Pihet jean.pi...@newoldbits.com writes: On Fri, May 27, 2011 at 1:09 AM, Kevin Hilman khil...@ti.com wrote: jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com Export the suspend_set_ops API as omap_pm_suspend_set_ops in the pm generic code, under CONFIG_SUSPEND. Note -hack warning-: since the 'suspend_valid_only_mem' function is not exported to modules, fill the 'valid' field value of 'struct platform_suspend_ops' in the common code. Signed-off-by: Jean Pihet j-pi...@ti.com Can you try the patch below instead? If that works, I'll submit to Rafael/linux-pm. This is much cleaner! We need this pushed upstream. OK, thanks. I just sent it to linux-pm. 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] OMAP: don't trace functions called from sched_clock
Kevin Hilman khil...@ti.com writes: Rabin Vincent ra...@rab.in writes: omap_readl() is used from the sched_clock() implementations and so must be marked notrace to avoid recursion in ftrace. Same thing with mpu_read() for OMAP1. Signed-off-by: Rabin Vincent ra...@rab.in Acked-by: Kevin Hilman khil...@ti.com I also meant to suggest this should probably queue for .40-rc series. 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 pm_wip/voltdm_nm] OMAP: VP: Explicitly mask VPVOLTAGE field
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 - u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask symbol
already defined, added as a new field in struct omap_vp_common.
Signed-off-by: Todd Poynor toddpoy...@google.com
---
V2 based on Kevin's feedback (thanks!):
* Drop the shift field, use __ffs().
* Updated subject prefix.
arch/arm/mach-omap2/vp.c |3 ++-
arch/arm/mach-omap2/vp.h |2 ++
arch/arm/mach-omap2/vp3xxx_data.c |2 ++
arch/arm/mach-omap2/vp44xx_data.c |1 +
4 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index e7d38f6..3807620 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -227,7 +227,8 @@ unsigned long omap_vp_get_curr_volt(struct voltagedomain
*voltdm)
return 0;
}
- curr_vsel = voltdm-read(vp-voltage);
+ curr_vsel = (voltdm-read(vp-voltage) vp-common-vpvoltage_mask)
+__ffs(vp-common-vpvoltage_mask);
if (!voltdm-pmic || !voltdm-pmic-vsel_to_uv) {
pr_warning(%s: PMIC function to convert vsel to voltage
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0d63267..f78752b 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -63,6 +63,7 @@ struct omap_vp_ops {
* @vlimitto_vddmin_shift: VDDMIN field shift in PRM_VP*_VLIMITTO reg
* @vlimitto_vddmax_shift: VDDMAX field shift in PRM_VP*_VLIMITTO reg
* @vlimitto_timeout_shift: TIMEOUT field shift in PRM_VP*_VLIMITTO reg
+ * @vpvoltage_mask: VPVOLTAGE field mask in PRM_VP*_VOLTAGE reg
*/
struct omap_vp_common {
u32 vpconfig_erroroffset_mask;
@@ -79,6 +80,7 @@ struct omap_vp_common {
u8 vlimitto_vddmin_shift;
u8 vlimitto_vddmax_shift;
u8 vlimitto_timeout_shift;
+ u8 vpvoltage_mask;
const struct omap_vp_ops *ops;
};
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c
b/arch/arm/mach-omap2/vp3xxx_data.c
index d429c44..260c554 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -51,6 +51,8 @@ static const struct omap_vp_common omap3_vp_common = {
.vlimitto_vddmin_shift = OMAP3430_VDDMIN_SHIFT,
.vlimitto_vddmax_shift = OMAP3430_VDDMAX_SHIFT,
.vlimitto_timeout_shift = OMAP3430_TIMEOUT_SHIFT,
+ .vpvoltage_mask = OMAP3430_VPVOLTAGE_MASK,
+
.ops = omap3_vp_ops,
};
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 0daf2a4..b4e7704 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -51,6 +51,7 @@ static const struct omap_vp_common omap4_vp_common = {
.vlimitto_vddmin_shift = OMAP4430_VDDMIN_SHIFT,
.vlimitto_vddmax_shift = OMAP4430_VDDMAX_SHIFT,
.vlimitto_timeout_shift = OMAP4430_TIMEOUT_SHIFT,
+ .vpvoltage_mask = OMAP4430_VPVOLTAGE_MASK,
.ops = omap4_vp_ops,
};
--
1.7.3.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
[PATCH] OMAP: L3 interconnect: Error reporting cleanups
* Make variables static.
* Define L3 TARG instance offsets, and read/write STDERRLOG registers
relative to those offsets, rather than defining STDERRLOG_MAIN
instance offsets and accessing other registers via offsets from
that register.
* Use ffs() to find error source from the L3_FLAGMUX_REGERRn
register.
* Remove extra l3_base[] entry.
* Modify L3 custom error message for consistency with standard
error message.
Signed-off-by: Todd Poynor toddpoy...@google.com
---
V2 updated for feedback from Santosh (thanks!).
arch/arm/mach-omap2/omap_l3_noc.c | 38 +-
arch/arm/mach-omap2/omap_l3_noc.h | 82 ++--
2 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index 7b9f190..3593279 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -29,6 +29,7 @@
#include omap_l3_noc.h
+
/*
* Interrupt Handler for L3 error detection.
* 1) Identify the L3 clockdomain partition to which the error belongs to.
@@ -56,10 +57,10 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
{
struct omap4_l3 *l3 = _l3;
- int inttype, i, j;
+ int inttype, i;
int err_src = 0;
- u32 std_err_main_addr, std_err_main, err_reg;
- u32 base, slave_addr, clear;
+ u32 l3_targ_base, std_err_main, err_reg;
+ u32 base, clear;
char *source_name;
/* Get the Type of interrupt */
@@ -76,37 +77,36 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Get the corresponding error and analyse */
if (err_reg) {
/* Identify the source from control status register */
- for (j = 0; !(err_reg (1 j)); j++)
- ;
-
- err_src = j;
+ err_src = __ffs(err_reg);
/* Read the stderrlog_main_source from clk domain */
- std_err_main_addr = base + *(l3_targ[i] + err_src);
- std_err_main = readl(std_err_main_addr);
+ l3_targ_base = base + (*(l3_targ[i] + err_src));
+ std_err_main = readl(l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
switch (std_err_main CUSTOM_ERROR) {
case STANDARD_ERROR:
source_name =
- l3_targ_stderrlog_main_name[i][err_src];
-
- slave_addr = std_err_main_addr +
- L3_SLAVE_ADDRESS_OFFSET;
+ l3_targ_inst_name[i][err_src];
WARN(true, L3 standard error: SOURCE:%s at
address 0x%x\n,
- source_name, readl(slave_addr));
+source_name,
+readl(l3_targ_base +
+ L3_TARG_STDERRLOG_SLVOFSLSB));
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, std_err_main_addr);
+ writel(clear, l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
break;
case CUSTOM_ERROR:
source_name =
- l3_targ_stderrlog_main_name[i][err_src];
+ l3_targ_inst_name[i][err_src];
- WARN(true, CUSTOM SRESP error with
SOURCE:%s\n,
- source_name);
+ WARN(true, L3 custom error: SOURCE:%s\n,
+source_name);
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, std_err_main_addr);
+ writel(clear, l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
break;
default:
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h
b/arch/arm/mach-omap2/omap_l3_noc.h
index 359b833..b553fa7 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.h
+++ b/arch/arm/mach-omap2/omap_l3_noc.h
@@ -23,63 +23,63 @@
#ifndef __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H
#define __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H
-/*
- * L3 register offsets
- */
#define L3_MODULES 3
#define CLEAR_STDERR_LOG (1 31)
#define CUSTOM_ERROR 0x2
#define
