RE: OMAP3 Clock CPU frequency
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of msin...@eastcoreng.com Sent: Monday, August 30, 2010 12:33 AM To: linux-omap@vger.kernel.org Subject: OMAP3 Clock CPU frequency Kevin Hilman wrote: FWIW, the SR hwmods are still not enabling by default because the clock fwk fails due to missing clockdomain. I've been manually working around by adding .clkdm_name = wkup_clkdm, to sr*_fck, but I know that's not the correct fix. Kevin That only seems to eliminate the warning. I'm seeing omap_hwmod: sr1_hwmod: cannot be enabled (3) because oh-prcm.omap2 is Null on the call to omap2_cm_wait_module_ready() cpufreq changing does not occur. Which version of these patches are you using? The V2 version does have oh-prcm.omap2 populated for smartreflex. Regards Thara
RE: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shubhrajyoti D
Sent: Tuesday, August 24, 2010 10:58 AM
To: linux-omap@vger.kernel.org
Cc: Datta, Shubhrajyoti
Subject: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
omap 4430sdp board support for the GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 61
+++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..85b0e0c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
@@ -40,6 +41,8 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON 48
#define ETH_KS8851_QUART 138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO188
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -77,11 +80,47 @@ static struct gpio_led sdp4430_gpio_leds[] = {
};
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+ {
+ .desc = Proximity Sensor,
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+ .active_low = 0,
+ }
+};
+
static struct gpio_led_platform_data sdp4430_led_data = {
.leds = sdp4430_gpio_leds,
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static int omap_prox_activate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ return 0;
+}
+
+static void omap_prox_deactivate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+ .buttons= sdp4430_gpio_keys,
+ .nbuttons = ARRAY_SIZE(sdp4430_gpio_keys),
+ .enable = omap_prox_activate,
+ .disable= omap_prox_deactivate,
+};
+
+static struct platform_device sdp4430_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_gpio_keys_data,
+ },
+};
+
static struct platform_device sdp4430_leds_gpio = {
.name = leds-gpio,
.id = -1,
@@ -161,6 +200,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
};
@@ -426,6 +466,26 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+static void __init omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(%s:failed to request GPIO %d, error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 0);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+ }
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
@@ -448,6 +508,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_sfh7741prox_init();
Hello Shubro,
I believe you are calling omap_sfh7741prox_init at the end of omap_4430sdp_init
which means your sdp4430_gpio_keys_device is registered much before this.
This could mean that the probe of your gpio-keys driver could get called before
omap_sfh7741prox_init. Assume this is the case and your probe calls into
pdata-enable
or pdata-disable which is omap_prox_activate/omap_prox_deactivate as per this
patch, these API's will try accessing gpio APIs for OMAP4_SFH7741_ENABLE_GPIO
without
a gpio_request happening for this pin as omap_sfh7741prox_init is called later.
Maybe such a case might never arise. But I would say you should do a
request_gpio for
OMAP4_SFH7741_ENABLE_GPIO before the driver probe is called.
Regards
Thara
--
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] I2C: Fix for suspend/resume issue in i2c-core
In current i2c core driver, pm_runtime_set_active call from i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the child_count of
the device's parent. However, matching pm_runtime_set_suspended is not called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
---
drivers/i2c/i2c-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+ int ret;
if (pm_runtime_suspended(dev))
return 0;
if (pm)
- return pm-suspend ? pm-suspend(dev) : 0;
+ ret = pm-suspend ? pm-suspend(dev) : 0;
+ else
+ ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
- return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+ if (!ret) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+ }
+ return ret;
}
static int i2c_device_pm_resume(struct device *dev)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 Clock CPU frequency
Is it in mainline yet or still a patch? -Original Message- From: Gopinath, Thara [mailto:th...@ti.com] Sent: Monday, August 30, 2010 6:29 AM To: msin...@eastcoreng.com; linux-omap@vger.kernel.org Subject: RE: OMAP3 Clock CPU frequency -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of msin...@eastcoreng.com Sent: Monday, August 30, 2010 12:33 AM To: linux-omap@vger.kernel.org Subject: OMAP3 Clock CPU frequency Kevin Hilman wrote: FWIW, the SR hwmods are still not enabling by default because the clock fwk fails due to missing clockdomain. I've been manually working around by adding .clkdm_name = wkup_clkdm, to sr*_fck, but I know that's not the correct fix. Kevin That only seems to eliminate the warning. I'm seeing omap_hwmod: sr1_hwmod: cannot be enabled (3) because oh-prcm.omap2 is Null on the call to omap2_cm_wait_module_ready() cpufreq changing does not occur. Which version of these patches are you using? The V2 version does have oh-prcm.omap2 populated for smartreflex. Regards Thara No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3093 - Release Date: 08/29/10 14:34:00 -- 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 CPUIDLE: CPU Idle latency measurement
Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. Regards Vishwa Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2: add cpuidle and cpufreq events tracing
On Fri, Aug 27, 2010 at 2:01 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Kevin,
On Wed, Aug 25, 2010 at 8:22 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Hi Jean,
Jean Pihet jean.pi...@newoldbits.com writes:
...
Add the cpuidle power_start and power_end events. The state
parameter of power_start has the following meaning:
- -1: from the suspend handler (omap3_pm_suspend),
- 1: from the default idle handler (omap3_pm_idle),
- other values are the C-states from the cpuidle handler
(omap3_enter_idle).
Are these definitions standard across other arches too? The use of
POWER_CSTATE from supend seems less than intuitive.
Only x86 is using those events, and only for idle (values = 0).
I have added -1 to differentiate the suspend from the regular idle but
it sems that it is not the best option.
Is a new type of power event more suited, e.g. POWER_SSTATE? If so I
will have to add it in the event definition header (in
include/trace/events/power.h) and the patch will be submitted to LKML.
Yes, I think a new event is probably more appropriate, but should be
discussed on LKML.
Indeed.
Here is a respin of the patch, on top of the l-o tree. The rest of the
changes are discussed on LKML.
Kevin
Jean
---
Add the cpuidle power_start and power_end events. The state
parameter of power_start has the following meaning:
- 1: from the default idle handler (omap3_pm_idle),
- other values are the C-states from the cpuidle handler
(omap3_enter_idle).
Add the cpufreq power_frequency event, with the state
parameter being the target CPU frequency.
Cf. http://omappedia.org/wiki/Power_Management_Debug_and_Profiling
for more details on PM debug and profiling.
Signed-off-by: Jean Pihet jpi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |2 ++
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/plat-omap/cpu-omap.c |5 -
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..6113bd9 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -24,6 +24,7 @@
#include linux/sched.h
#include linux/cpuidle.h
+#include trace/events/power.h
#include plat/prcm.h
#include plat/irqs.h
@@ -130,6 +131,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
local_fiq_disable();
+ trace_power_start(POWER_CSTATE, cx-type, smp_processor_id());
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f25bc3d..04bc758 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/delay.h
#include linux/slab.h
+#include trace/events/power.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -588,6 +589,7 @@ static void omap3_pm_idle(void)
if (omap_irq_pending() || need_resched())
goto out;
+ trace_power_start(POWER_CSTATE, 1, smp_processor_id());
omap_sram_idle();
out:
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index df08829..cc4e41f 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -25,6 +25,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include trace/events/power.h
#include mach/hardware.h
#include plat/clock.h
@@ -116,8 +117,10 @@ static int omap_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
freq = target_freq * 1000;
- if (opp_find_freq_ceil(mpu_dev, freq))
+ if (opp_find_freq_ceil(mpu_dev, freq)) {
+ trace_power_frequency(POWER_PSTATE, freq, smp_processor_id());
omap_pm_cpu_set_freq(freq);
+ }
#endif
return ret;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 1/2 v2] omap3: sr: fix memory leak and simplify the code
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, August 25, 2010 2:55 AM To: Menon, Nishanth; Gopinath, Thara Cc: linux-omap; Artem Bityutskiy; Peter p2 De Schrijver Subject: Re: [PM-SR][PATCH 1/2 v2] omap3: sr: fix memory leak and simplify the code Nishanth Menon n...@ti.com writes: From: Artem Bityutskiy artem.bityuts...@nokia.com This patch fixes the following problem indicated by kmemleak: kmemleak: unreferenced object 0xdf93c280 (size 64): kmemleak: backtrace: kmemleak: [c00df6d4] create_object+0x104/0x200 kmemleak: [c00d7638] kmem_cache_alloc+0xe4/0xf4 kmemleak: [c000fc38] omap_devinit_smartreflex+0x44/0x244 kmemleak: [c003a33c] do_one_initcall+0x5c/0x1b8 kmemleak: [c00083fc] kernel_init+0x94/0x110 kmemleak: [c003ba04] kernel_thread_exit+0x0/0x8 The reason is that 'omap_devinit_smartreflex()' allocates 'sr_data', then passes it to 'omap_device_build()', which 'kmemdup()'s it and uses the copy. But 'omap_devinit_smartreflex()' never frees 'sr_data'. This patch make 'sr_data' to be a stack variable, which eliminates the memory leak and simplifies the code a bit. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com, Cc: Peter p2 De Schrijver peter.de-schrij...@nokia.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Acked-by: Nishanth Menon n...@ti.com --- Changes from V1: rebased to latest pm-sr branch default of sr_data set to 0 to make it equivalent to kzalloc NOTE: this probably should be squashed when being send upstream along with rest of SR series Thara, you appear to have fixed this problem differently in your latest series. Looks like you just ensured kfree() was always done, correct? In the future, it would be helpful if you would reply to these proposed fixes on the list so we know if they are incorporated or handled differently. Yes.. you r correct.. I missed replying on this one. Sorry for the confusion. Will take care of this in future. It is indeed fixed by ensuring kfree() always. Regards, Thara -- 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] OMAP4: pm.c extensions for OMAP4 support
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, August 25, 2010 4:43 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand
Subject: Re: [PATCH v2] OMAP4: pm.c extensions for OMAP4 support
On Tue, 2010-08-24 at 14:58 -0700, Kevin Hilman wrote:
Thara Gopinath th...@ti.com writes:
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.
Signed-off-by: Thara Gopinath th...@ti.com
---
v2: Removed fixing of l3_main hwmod for OMAP4 as Benoit has
already submitted a pach fixing the same.
OK, applying this to pm-fixes.
No second thought, not yet...
arch/arm/mach-omap2/pm.c | 19 ++-
arch/arm/plat-omap/include/plat/common.h |3 ++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..a98b5e8 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -21,8 +21,9 @@
static struct omap_device_pm_latency *pm_lats;
static struct device *mpu_dev;
-static struct device *dsp_dev;
+static struct device *iva_dev;
static struct device *l3_dev;
+static struct device *dsp_dev;
struct device *omap2_get_mpuss_device(void)
{
@@ -30,10 +31,10 @@ struct device *omap2_get_mpuss_device(void)
return mpu_dev;
}
-struct device *omap2_get_dsp_device(void)
+struct device *omap2_get_iva_device(void)
{
- WARN_ON_ONCE(!dsp_dev);
- return dsp_dev;
+ WARN_ON_ONCE(!iva_dev);
+ return iva_dev;
}
struct device *omap2_get_l3_device(void)
@@ -42,6 +43,13 @@ struct device *omap2_get_l3_device(void)
return l3_dev;
}
+struct device *omap4_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+EXPORT_SYMBOL(omap4_get_dsp_device);
+
/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
static int _init_omap_device(char *name, struct device **new_dev)
{
@@ -69,7 +77,8 @@ static int _init_omap_device(char *name, struct device
**new_dev)
static void omap2_init_processor_devices(void)
{
_init_omap_device(mpu, mpu_dev);
- _init_omap_device(iva, dsp_dev);
+ _init_omap_device(iva, iva_dev);
+ _init_omap_device(dsp, dsp_dev);
this one causes the noisy WARN to be tirggered on !OMAP4. Since !OMAP4
doesn't have a DSP, we shouldn't be warning users about a missing dsp
hwmod.
Hello Kevin,
I will put a OMAP4 check across this and repost.
Regards
Thara
Kevin
_init_omap_device(l3_main, l3_dev);
}
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..c45dbb9 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -91,7 +91,8 @@ void omap3_map_io(void);
})
extern struct device *omap2_get_mpuss_device(void);
-extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
+extern struct device *omap4_get_dsp_device(void);
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
RE: OMAP3 Clock CPU frequency
-Original Message- From: Matt Singer [mailto:msin...@eastcoreng.com] Sent: Monday, August 30, 2010 6:02 PM To: Gopinath, Thara; linux-omap@vger.kernel.org Subject: RE: OMAP3 Clock CPU frequency Is it in mainline yet or still a patch? Hello Matt, It is not in mainline and is only a patch series. Link to the series http://marc.info/?l=linux-omapm=128170725127719w=2 Link to the specific patch http://marc.info/?l=linux-omapm=128170725327731w=2 Hope this helps you. One advice to you would be not to top post while replying to the mailing list. It is a bad etiquette. Regards Thara -Original Message- From: Gopinath, Thara [mailto:th...@ti.com] Sent: Monday, August 30, 2010 6:29 AM To: msin...@eastcoreng.com; linux-omap@vger.kernel.org Subject: RE: OMAP3 Clock CPU frequency -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of msin...@eastcoreng.com Sent: Monday, August 30, 2010 12:33 AM To: linux-omap@vger.kernel.org Subject: OMAP3 Clock CPU frequency Kevin Hilman wrote: FWIW, the SR hwmods are still not enabling by default because the clock fwk fails due to missing clockdomain. I've been manually working around by adding .clkdm_name = wkup_clkdm, to sr*_fck, but I know that's not the correct fix. Kevin That only seems to eliminate the warning. I'm seeing omap_hwmod: sr1_hwmod: cannot be enabled (3) because oh-prcm.omap2 is Null on the call to omap2_cm_wait_module_ready() cpufreq changing does not occur. Which version of these patches are you using? The V2 version does have oh-prcm.omap2 populated for smartreflex. Regards Thara No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3093 - Release Date: 08/29/10 14:34:00 -- 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] New API to modify the autoidle bits of sysconfig register
Kishon Vijay Abraham I kis...@ti.com writes:
Though the sysconfig register values shouldn't be modified directly by
the driver, MCBSP should be considered a special case where sysconfig
registers need to be modified dynamically by the driver.
For e.g MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone.
This patch creates a new API that forms a wrapper to
_set_module_autoidle() to modify the AUTOIDLE bit.
Since driver should not be using hwmod directly, how is this API going
to be used? Will this only be called from arch/arm/mach-omap2/mcbsp.c?
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Partha Basak p-bas...@ti.com
Subject should contain prefix like 'OMAP: hwmod: ...'
Kevin
---
arch/arm/mach-omap2/omap_hwmod.c | 29
++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 9bd99ad..0d38404 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -969,6 +969,35 @@ int _omap_hwmod_idle(struct omap_hwmod *oh)
}
/**
+ * omap_hwmod_set_module_autoidle - set the hwmod's OCP slave autoidle
+ * @oh: struct omap_hwmod *
+ * @autoidle: desired AUTOIDLE bitfield value (0 or 1)
+ *
+ * Sets the IP block's OCP slave autoidle in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the AUTOIDLE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_module_autoidle().
+ */
+int omap_hwmod_set_module_autoidle(struct omap_hwmod *oh, u8 autoidle)
+{
+ u32 v;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ retval = _set_module_autoidle(oh, autoidle, v);
+
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
+/**
* _shutdown - shutdown an omap_hwmod
* @oh: struct omap_hwmod *
*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6adbb63..7042b86 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -526,6 +526,7 @@ int omap_hwmod_hardreset_deassert(struct omap_hwmod *oh,
const char *name);
int omap_hwmod_hardreset_state(struct omap_hwmod *oh, const char *name);
int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
+int omap_hwmod_set_module_autoidle(struct omap_hwmod *oh, u8 autoidle)
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
--
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: OMAP4430 Public TRM is Available Now!
On Aug 27, 2:11 pm, Felipe Balbi wrote: In addition, you can find the first public version of the OMAP4430 Clock Tree Tool under Technical Documents section. tried that one, doesn't work with ubuntu 10.04, Gentoo or Debian Sid. Doesn't go passed splash screen. We have informed the developers of CTT. They are planning to publish an updated CTT tool (v1.7.0.3) with this issue fixed in a few days - stay tuned. --jayabharath -- 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
Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
Hi Dmitry, When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. -- balbi -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
Hi Felipe, On Mon, Aug 30, 2010 at 11:04:39AM -0500, Felipe Balbi wrote: Hi Dmitry, When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. I got persuaded that 3-axis accelerometers are most often indended to be used as input devices so I decided I should take these in (adxl134x is there). I still think that sensor devices in general are better suited to IIO subsystem and I hope it will get out of staging soon. Once it is out of staging we may think about creating a IIO-to-input bridge (copuld be either in kernel or a userspace solution based on uinput) to route sensors that are indeed used as HIDs. Hope this makes sense. -- Dmitry -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
Hi, On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. I got persuaded that 3-axis accelerometers are most often indended to be used as input devices so I decided I should take these in (adxl134x is there). I still think that sensor devices in general are better suited to IIO subsystem and I hope it will get out of staging soon. Once it is out of staging we may think about creating a IIO-to-input bridge (copuld be either in kernel or a userspace solution based on uinput) to route sensors that are indeed used as HIDs. Hope this makes sense. It kinda does, but such sensors will be more and more used as input devices, specially for gaming on mobile devices. For example a proximity sensor might be used as the trigger button on a first person shooting game; accelerometers will be used to walk through the map and a magnetometer might be used to look behind you and a gyroscope to turn around your own axis. In the end, the user is the one moving the device around and generating such events, so why not avoiding yet another subsystem if we will have to resort to solutions such as iio-to-input bridge, which smells like a hackish solution to get input events from sensors anyway. I really hope I could convince you that, on mobile at least, sensors will be mostly used as HID devices and will give app developers new ways for them to allow users to interact with their app. Take a look at how a gyroscope is used on iphone, for instance [1]. [1] http://www.youtube.com/watch?v=ORcu-c-qnjg -- balbi -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, Aug 30, 2010 at 12:10:41PM -0500, Felipe Balbi wrote: Hi, On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. I got persuaded that 3-axis accelerometers are most often indended to be used as input devices so I decided I should take these in (adxl134x is there). I still think that sensor devices in general are better suited to IIO subsystem and I hope it will get out of staging soon. Once it is out of staging we may think about creating a IIO-to-input bridge (copuld be either in kernel or a userspace solution based on uinput) to route sensors that are indeed used as HIDs. Hope this makes sense. It kinda does, but such sensors will be more and more used as input devices, specially for gaming on mobile devices. For example a proximity sensor might be used as the trigger button on a first person shooting game; accelerometers will be used to walk through the map and a magnetometer might be used to look behind you and a gyroscope to turn around your own axis. In the end, the user is the one moving the device around and generating such events, so why not avoiding yet another subsystem if we will have to resort to solutions such as iio-to-input bridge, which smells like a hackish solution to get input events from sensors anyway. I really hope I could convince you that, on mobile at least, sensors will be mostly used as HID devices and will give app developers new ways for them to allow users to interact with their app. Take a look at how a gyroscope is used on iphone, for instance [1]. [1] http://www.youtube.com/watch?v=ORcu-c-qnjg My response to this - are gyroscopes will _only_ be used to turn around in a game? Are proximity sensor is _only_ usable as a trigger in FPS? Won't we ever see such chips controlling technological processes? I do hope that answerrs are no, no and yes. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] omap4 hsmmc : Adding card detect support for MMC1
Adding card detect callback function and card detect configuration
function for MMC1 Controller.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, Card detect interrupt source is
twl6030 and the card detect call back function provides card present/absent
status by reading MMC Control register.
Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |7 +++-
drivers/mfd/twl6030-irq.c | 76 +++
drivers/mmc/host/omap_hsmmc.c |4 +-
include/linux/i2c/twl.h | 31 ++
4 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..a49f285 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err(Failed configuring MMC1 card detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..91a6a45 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include linux/irq.h
#include linux/kthread.h
#include linux/i2c/twl.h
+#include linux/platform_device.h
/*
* TWL6030 (unlike its predecessors, which had two level interrupt handling)
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ }
+
+ /*
+* Intially Configuring MMC_CTRL for receving interrupts
+* Card status on TWL6030 for MMC1
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ }
+ reg_val = ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ return ret;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
+
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -EIO;
+ u8 read_reg = 0;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+
+ switch (pdev-id) {
+ case 0:
+ /*
+* BIT0 of REG_MMC_CTRL
+* 0 - Card not present ,1 - Card present
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, read_reg,
+ TWL6030_MMCCTRL);
+ if (ret = 0)
+ ret = read_reg STS_MMC;
+ break;
+ default:
+ pr_err(Unkown MMC controller %d in %s\n, pdev-id, __func__);
+ }
+ return ret;
+}
[PATCH 0/3] OMAP hsmmc : card detect and Register offset handling
Hi, The patch series includes : adding carddetect feature for MMC1 controller on OMAP4 and register offset handling for OMAP3 OMAP4 and followed by a fix when CONFIG_MMC_OMAP_HS not selected for OMAP4. Patch series has been tested on OMAP3430SDP and OMAP4430SDP Kishore Kadiyala (2): omap4 hsmmc : Adding card detect support for MMC1 omap3/omap4 hsmmc: Register offset handling Benoit Cousson (1); omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set arch/arm/mach-omap2/board-4430sdp.c | 15 ++- arch/arm/mach-omap2/devices.c | 30 +++-- arch/arm/mach-omap2/hsmmc.c |6 + arch/arm/plat-omap/include/plat/mmc.h | 78 ++- drivers/mfd/twl6030-irq.c | 76 ++ drivers/mmc/host/omap_hsmmc.c | 255 +++-- include/linux/i2c/twl.h | 31 7 files changed, 340 insertions(+), 151 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set
Avoid possible crash if CONFIG_MMC_OMAP_HS is not set
Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a49f285..ac8541c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -240,8 +240,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
{
- struct omap_mmc_platform_data *pdata = dev-platform_data;
+ struct omap_mmc_platform_data *pdata;
+ /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!dev) {
+ pr_err(Failed omap4_twl6030_hsmmc_set_late_init\n);
+ return;
+ }
+ pdata = dev-platform_data;
pdata-init = omap4_twl6030_hsmmc_late_init;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.
For generic handling, OMAP3 and OMAP4 has different array's of
register offset maintained and right one is choosen during run time.
Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/devices.c | 30 +++--
arch/arm/mach-omap2/hsmmc.c |6 +
arch/arm/plat-omap/include/plat/mmc.h | 78 ++-
drivers/mmc/host/omap_hsmmc.c | 251 +++--
4 files changed, 218 insertions(+), 147 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..03add6e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
#define MMCHS_SYSCONFIG_SWRESET(1 1)
#define MMCHS_SYSSTATUS0x0014
#define MMCHS_SYSSTATUS_RESETDONE (1 0)
+#define OMAP4_MMCHS_SYSCONFIG_SWRESET (1 0)
+#define OMAP4_MMCHS_OFFSET 0x100
static struct platform_device dummy_pdev = {
.dev = {
@@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
static void __init omap_hsmmc_reset(void)
{
u32 i, nr_controllers;
+ u32 reg_val = 0;
+ u32 reg_off = 0;
if (cpu_is_omap242x())
return;
@@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
break;
}
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
dummy_pdev.id = i;
dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
iclk = clk_get(dev, ick);
@@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
break;
}
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)
+ if (cpu_is_omap44xx())
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ else
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ omap_writel(reg_val, base + MMCHS_SYSCONFIG);
+
+ reg_off = MMCHS_SYSSTATUS;
+ if (cpu_is_omap44xx())
+ reg_off += OMAP4_MMCHS_OFFSET;
+ v = omap_readl(base + reg_off);
+
+ while (!(omap_readl(base + reg_off)
MMCHS_SYSSTATUS_RESETDONE))
cpu_relax();
@@ -745,13 +755,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +772,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
} else if (cpu_is_omap44xx()) {
- if (i 3) {
- base += OMAP4_MMC_REG_OFFSET;
+ if (i 3)
irq += OMAP44XX_IRQ_GIC_START;
- }
size = OMAP4_HSMMC_SIZE;
name = mmci-omap-hs;
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..d93b704 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -262,6 +262,12 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-slots[0].internal_clock = !c-ext_clock;
mmc-dma_mask = 0x;
+ /* Register offset Mapping */
+ if (cpu_is_omap44xx())
+ mmc-regs_map = (u16 *) omap4_mmc_reg_map;
+ else
+ mmc-regs_map = (u16 *) omap3_mmc_reg_map;
+
mmc-get_context_loss_count = hsmmc_get_context_loss;
mmc-slots[0].switch_pin = c-gpio_cd;
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On 08/30/10 18:10, Felipe Balbi wrote: Hi, On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. I got persuaded that 3-axis accelerometers are most often indended to be used as input devices so I decided I should take these in (adxl134x is there). I still think that sensor devices in general are better suited to IIO subsystem and I hope it will get out of staging soon. Once it is out of staging we may think about creating a IIO-to-input bridge (copuld be either in kernel or a userspace solution based on uinput) to route sensors that are indeed used as HIDs. I'll look into the userspace option. Might well be a quicker option in the near future not to mention providing a good example of using our userspace interfaces... Hope this makes sense. It kinda does, but such sensors will be more and more used as input devices, specially for gaming on mobile devices. For example a proximity sensor might be used as the trigger button on a first person shooting game; accelerometers will be used to walk through the map and a magnetometer might be used to look behind you and a gyroscope to turn around your own axis. In the end, the user is the one moving the device around and generating such events, so why not avoiding yet another subsystem if we will have to resort to solutions such as iio-to-input bridge, which smells like a hackish solution to get input events from sensors anyway. I really hope I could convince you that, on mobile at least, sensors will be mostly used as HID devices and will give app developers new ways for them to allow users to interact with their app. Take a look at how a gyroscope is used on iphone, for instance [1]. [1] http://www.youtube.com/watch?v=ORcu-c-qnjg Kind of an obvious point, but there are lots of sensors in these classes that no one is ever going to use for input. Take a high g acceleromter (anything above c.10g for this purpose) or the sorts of IMU's IIO currently has, which are simply too expensive / large. Or take mid to high spec ADCs. For other uses the requirements are typically very different and could not be added to input without major disruption. Personally I see no problem with having two drivers in kernel for a device assuming they are sufficiently different in purpose. I agree we have some fragmentation here and ideally these device might all sit on some 'uber' subsystem providing all things to all men. Unfortunately that would probably come with massive complexity and at the end of the day we already have subsystems doing a very good job of handling some classes of device. The intent of IIO was always to cover the ground that is out of scope for hwmon and input. As you have probably seen this does indeed add a fair bit of complexity! We're working on cleaning things up. Large set of fixes on linux-iio today (including a few abi fixes for the magnetometer you mention above :) Still if anyone wants to speed up our move to mainline we always appreciate code review! *looks hopeful* I'm always happy to direct people towards the most dubious bits or advise anyone porting a driver. We have a reasonable team now (thanks partly to exposure we got by being in staging!), but more help is always good. Jonathan (IIO 'maintainer' in case anyone didn't guess) -- 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
Nagging free/reclaim gpio's
I've got a module that claims gpio's when it is loaded and frees them when it is unloaded. It looks like something goes wrong when I free them: gpio_unexport: gpio144 status -22 gpio_unexport: gpio146 status -22 gpio_unexport: gpio14 status -22 gpio_unexport: gpio21 status -22 gpio_unexport: gpio22 status -22 gpio_unexport: gpio23 status -22 Then when I try to reclaim them I get this: gpio_request: gpio-175 (sysfs) status -16 export_store: status -16 gpio_request: gpio-175 (sysfs) status -16 export_store: status -16 gpio_request: gpio-114 (sysfs) status -16 export_store: status -16 gpio_request: gpio-114 (sysfs) status -16 export_store: status -16 gpio_request: gpio-173 (sysfs) status -16 export_store: status -16 gpio_request: gpio-173 (sysfs) status -16 export_store: status -16 This has to be silly, but I can't find the problem. Everything works fine, I just would like the messages to go away :) Philip -- 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] I2C: Fix for suspend/resume issue in i2c-core
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the child_count of
the device's parent. However, matching pm_runtime_set_suspended is not called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Kevin
---
drivers/i2c/i2c-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+ int ret;
if (pm_runtime_suspended(dev))
return 0;
if (pm)
- return pm-suspend ? pm-suspend(dev) : 0;
+ ret = pm-suspend ? pm-suspend(dev) : 0;
+ else
+ ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
- return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+ if (!ret) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+ }
+ return ret;
}
static int i2c_device_pm_resume(struct device *dev)
--
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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
Hi, On Mon, 30 Aug 2010 10:21:44 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: My response to this - are gyroscopes will _only_ be used to turn around in a game? Are proximity sensor is _only_ usable as a trigger in FPS? Won't we ever see such chips controlling technological processes? similarly, will accelerometers always be used as input devices ? of course not, they have been used e.g. to spin down hard disks on laptops when they are shaken too hard. Still they have quite a fair bit of usage as input devices; you've seen it yourself, right ? in the end of the day, when you put those on mobile devices like e.g. cellphones, app developers will be really keen on creating new ways for interacting with apps (be it a game or not) using those devices, so I will agree with Jonathan that, maybe, having two separate drivers for different purposes would make sense, although that might cause a bit of trouble if user ends up enabling the wrong driver when building custom kernel for his device. My hope is that we can make use of a well known and uniform API for all input devices in a device, be it a keypad, touchscreen, accelerometer, magnetometer, gyro, or whatever. -- balbi -- 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: Nagging free/reclaim gpio's
Hi, On Mon, 30 Aug 2010 14:25:39 -0400, Philip Balister phi...@balister.org wrote: I've got a module that claims gpio's when it is loaded and frees them when it is unloaded. It looks like something goes wrong when I free them: gpio_unexport: gpio144 status -22 gpio_unexport: gpio146 status -22 gpio_unexport: gpio14 status -22 gpio_unexport: gpio21 status -22 gpio_unexport: gpio22 status -22 gpio_unexport: gpio23 status -22 this is telling you, you have entered invalid arguments to gpio_unexport. Then when I try to reclaim them I get this: gpio_request: gpio-175 (sysfs) status -16 export_store: status -16 gpio_request: gpio-175 (sysfs) status -16 export_store: status -16 gpio_request: gpio-114 (sysfs) status -16 export_store: status -16 gpio_request: gpio-114 (sysfs) status -16 export_store: status -16 gpio_request: gpio-173 (sysfs) status -16 export_store: status -16 gpio_request: gpio-173 (sysfs) status -16 export_store: status -16 This has to be silly, but I can't find the problem. Everything works fine, I just would like the messages to go away :) it's telling you that the gpio is busy, claimed by sysfs usage, so you can't claim it again. -- balbi -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, 30 Aug 2010 11:04:39 -0500 Felipe Balbi m...@felipebalbi.com wrote: Hi Dmitry, When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. I would certainly vote for them being input when they are sometimes used that way - compasses for example do get used by applications (like compass programs, some of the real cool visualisation tools and things like live/game mixed gaming environments) and accelerometers are gaming inputs. Proximity is also input for some stuff although usually of much more interest to the GUI manager than the GUI apps. ALS is more of a dual purpose thing -light levels are input features to the GUI on PDAs, although on many embedded devices they are most definitely part of the IIO subsystem. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
On Fri, Aug 27, 2010 at 09:12:24AM +0300, Hiroshi DOYU wrote:
Hi Catalin,
From: Hiroshi DOYU hiroshi.d...@nokia.com
Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias
Date: Tue, 10 Aug 2010 18:49:03 +0300 (EEST)
snip
The performance impact is indeed pretty high, though some parts of the
code look over-engineered to me (the __scan_block function with a loop
going through an array of two function pointers - I think the compiler
cannot figure out what to inline). You could just extend the
find_and_get_object() to search both trees under a single spinlock
region (as locking also takes time).
Ok, a good point.
Now there's not much difference with the attached patch, a new version
of alias.
/ # modprobe kmemleak-special-test use_alias=0
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 2.30s
user0m 0.00s
sys 0m 2.30s
/ # modprobe kmemleak-special-test use_alias=1
/ # time echo scan /sys/kernel/debug/kmemleak
real0m 3.91s
user0m 0.00s
sys 0m 3.91s
It would be nice if you could have some time to take a look at this
patch and give some comments.
From a5670d69b2cafe85f6f26f6951097210d3b9917f Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU hiroshi.d...@nokia.com
Date: Thu, 17 Jun 2010 13:36:45 +0300
Subject: [PATCH 1/1] kmemleak: Fix false positive with address alias
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by aliasing of address. A client module can register an
alias address to an original pointer.
A typical use case could be the IOMMU pagetable allocation which
stores pointers to the second level of page tables with some
conversion, for example, a physical address with attribute bits. Right
now I don't have other use cases but I hope that there could be some
that this special scan works with.
A few questions below...
Thanx, Paul
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
---
include/linux/kmemleak.h |8 ++
mm/kmemleak.c| 208
+++---
2 files changed, 204 insertions(+), 12 deletions(-)
diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index 99d9a67..9e2af3a 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -34,6 +34,8 @@ extern void kmemleak_not_leak(const void *ptr) __ref;
extern void kmemleak_ignore(const void *ptr) __ref;
extern void kmemleak_scan_area(const void *ptr, size_t size, gfp_t gfp)
__ref;
extern void kmemleak_no_scan(const void *ptr) __ref;
+extern void kmemleak_add_alias(const void *ptr, const void *new) __ref;
+extern void kmemleak_unalias(const void *alias) __ref;
static inline void kmemleak_alloc_recursive(const void *ptr, size_t size,
int min_count, unsigned long flags,
@@ -92,6 +94,12 @@ static inline void kmemleak_erase(void **ptr)
static inline void kmemleak_no_scan(const void *ptr)
{
}
+static inline void kmemleak_add_alias(const void *ptr, const void *new)
+{
+}
+static inline void kmemleak_unalias(const void *alias)
+{
+}
#endif /* CONFIG_DEBUG_KMEMLEAK */
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 2c0d032..3875cb7 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -157,6 +157,13 @@ struct kmemleak_object {
unsigned long jiffies; /* creation timestamp */
pid_t pid; /* pid of the current task */
char comm[TASK_COMM_LEN]; /* executable name */
+ struct kmemleak_alias *alias; /* if a pointer is modified */
+};
+
+struct kmemleak_alias {
+ struct list_head alias_list;
+ struct prio_tree_node tree_node;
+ struct kmemleak_object *object;
};
/* flag representing the memory block allocation status */
@@ -179,13 +186,18 @@ struct kmemleak_object {
static LIST_HEAD(object_list);
/* the list of gray-colored objects (see color_gray comment below) */
static LIST_HEAD(gray_list);
+/* the list of objects with alias (see alias comment below) */
+static LIST_HEAD(alias_list);
/* prio search tree for object boundaries */
static struct prio_tree_root object_tree_root;
+/* prio search tree for alias object boundaries */
+static struct prio_tree_root alias_tree_root;
/* rw_lock protecting the access to object_list and prio_tree_root */
static DEFINE_RWLOCK(kmemleak_lock);
/* allocation caches for kmemleak internal data */
static struct kmem_cache *object_cache;
+static struct kmem_cache *alias_cache;
static struct kmem_cache *scan_area_cache;
/* set
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, Aug 30, 2010 at 09:40:25PM +0100, Alan Cox wrote: On Mon, 30 Aug 2010 11:04:39 -0500 Felipe Balbi m...@felipebalbi.com wrote: Hi Dmitry, When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc on the input layer because they are not user input, although I didn't fully agree with you, we had to modify the drivers and, I believe, one of them is sitting in staging under the industrial i/o subsystem. Are you now accepting sensor drivers on the input layer ? that will make our life a lot easier but we need some definition to avoid having to re-work drivers when we want to push them to mainline. I would certainly vote for them being input when they are sometimes used that way - compasses for example do get used by applications (like compass programs, some of the real cool visualisation tools and things like live/game mixed gaming environments) and accelerometers are gaming inputs. But do you believe that input should be the primary residence for the devices when they are only _sometimes_ used as input devices? Or it would make sense to employ a converter from XXX to input (either purely in-kernel or userspace over uinput)? Thanks. -- Dmitry -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, Aug 30, 2010 at 01:52:18PM -0500, Felipe Balbi wrote: Hi, On Mon, 30 Aug 2010 10:21:44 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: My response to this - are gyroscopes will _only_ be used to turn around in a game? Are proximity sensor is _only_ usable as a trigger in FPS? Won't we ever see such chips controlling technological processes? similarly, will accelerometers always be used as input devices ? of course not, they have been used e.g. to spin down hard disks on laptops when they are shaken too hard. Still they have quite a fair bit of usage as input devices; you've seen it yourself, right ? This is a fair point. I was told that the main purpose for the chips in question (specifically 3-axis accelerometers) is to be used as HIDs. But it could be that I should not have merged adxl and instead waited for IIO. in the end of the day, when you put those on mobile devices like e.g. cellphones, app developers will be really keen on creating new ways for interacting with apps (be it a game or not) using those devices, so I will agree with Jonathan that, maybe, having two separate drivers for different purposes would make sense, although that might cause a bit of trouble if user ends up enabling the wrong driver when building custom kernel for his device. No, I do not believe that maintaining 2 separate devices for the same hardware with the only difference is how data is presented to userspace is a viable option. My hope is that we can make use of a well known and uniform API for all input devices in a device, be it a keypad, touchscreen, accelerometer, magnetometer, gyro, or whatever. If only we could agree what input devices are... -- Dmitry -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: But do you believe that input should be the primary residence for the devices when they are only _sometimes_ used as input devices? Or it would make sense to employ a converter from XXX to input (either purely in-kernel or userspace over uinput)? Umm... You've brought that up before as an objection, but what _is_ that other model that you would convert from? IOW what *is* that XXX that you talk about? So I think accelerometers etc should be seen as input devices for the simple reason that (a) They really *are* input devices in all the most common cases. If you have a phone with an accelerometer, it really is used as an input device quite like a joystick. The fact that there are specialized and rare cases where people may have some fancier accelerometer that isn't necessarily seen that way, and where it is used for some fancy scientific experiment or whatever doesn't change this in *any* way. The common case that almost everybody cares about - and that is getting more common - is the simple and obvious input case. How is a Wii accelerometer in any way different from a joystick? How is a phone accelerometer any different from one? The answer is clear: they aren't different! So it makes 100% sense to expose them under the same subsystem. (b) You cannot even name your XXX thing. It clearly makes sense (at least within Tue context of a driver for some embedded phone chip) to see it as an input device. And nothing else comes to mind. You'd have to expose it as some random character device and then everybody would just have to make it emulate an input device in user space anyway. What's the point of that? None. That's what the point is. So I really don't understand why you're fighting the input device angle. It makes sense as an input device. It does NOT make sense as anything else. Really - what else could a phone accelerometer (or GPS device, for that matter) really be? It very much is about user input - even if it isn't a keyboard. Linus -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, Aug 30, 2010 at 02:28:37PM -0700, Linus Torvalds wrote: On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: But do you believe that input should be the primary residence for the devices when they are only _sometimes_ used as input devices? Or it would make sense to employ a converter from XXX to input (either purely in-kernel or userspace over uinput)? Umm... You've brought that up before as an objection, but what _is_ that other model that you would convert from? IOW what *is* that XXX that you talk about? IIO which is currently in staging. So I think accelerometers etc should be seen as input devices for the simple reason that (a) They really *are* input devices in all the most common cases. If you have a phone with an accelerometer, it really is used as an input device quite like a joystick. The fact that there are specialized and rare cases where people may have some fancier accelerometer that isn't necessarily seen that way, and where it is used for some fancy scientific experiment or whatever doesn't change this in *any* way. The common case that almost everybody cares about - and that is getting more common - is the simple and obvious input case. How is a Wii accelerometer in any way different from a joystick? How is a phone accelerometer any different from one? The answer is clear: they aren't different! So it makes 100% sense to expose them under the same subsystem. (b) You cannot even name your XXX thing. It clearly makes sense (at I can - see above. least within Tue context of a driver for some embedded phone chip) to see it as an input device. And nothing else comes to mind. You'd have to expose it as some random character device and then everybody would just have to make it emulate an input device in user space anyway. What's the point of that? None. That's what the point is. So I really don't understand why you're fighting the input device angle. It makes sense as an input device. It does NOT make sense as anything else. Really - what else could a phone accelerometer That is why I started taking accelerometers in. But I am concerned that taking accelerometers (which indeed are most often input devices) will lead people to try and use the same for temperature, ALS and other sensors that are more often used in industrial process controls. (or GPS device, for that matter) really be? But why GPS should be input device? It has nothing to do with user input. It very much is about user input - even if it isn't a keyboard. -- Dmitry -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: That is why I started taking accelerometers in. But I am concerned that taking accelerometers (which indeed are most often input devices) will lead people to try and use the same for temperature, ALS and other sensors that are more often used in industrial process controls. You're just being silly. Nobody writes a driver for a temperature sensor or ambient light sensor. They write a driver for a specific *chip* that is used in cellphones etc, and that happens to have an ambient light and temperature sensor on it. And in that context, it really does make sense to see it as an input driver. And the fact that there are industrial uses for ALS sensors that aren't necessarily at all interested on the input layer should not matter at all. So don't bring up ALS isn't always input because within the context of a driver for some highly integrated cellphone model, it really IS input, and there is no ambiguity at all. So your sometimes it is, and sometimes it isn't argument is bogus. The ambiguity simply doesn't exist when seen in context. (or GPS device, for that matter) really be? But why GPS should be input device? It has nothing to do with user input. What? OF COURSE it is an input driver. It's the user moving the device around. It's EXACTLY the same thing as an accelerometer in that respect. Sure, it's a bit less precise and measures movement wrt some external frame, but technically they are almost exactly the same. If you se doing a navigation app, the accelerometer, the compass and the GPS are all equally (but differently) important. Again - it's not a user touching buttons. But it IS a user moving around. Linus -- 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 1/1] ARM: Add initial hibernation support
On Fri, 2010-07-16 at 12:10 +0300, Hiroshi DOYU wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Fri, 16 Jul 2010 09:52:44 +0200 On Thu, Jul 15, 2010 at 12:08:07PM +0300, Hiroshi DOYU wrote: From: ext Russell King - ARM Linux li...@arm.linux.org.uk Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 10:41:18 +0200 On Thu, Jul 15, 2010 at 08:34:50AM +0300, Hiroshi DOYU wrote: Russell, would it be possible to put this into your next merge queue? I think it needs quite a bit of rework - I certainly don't like all those CP15 register accesses there - that's asking for lots of ifdefs to spring up as more CPUs are supported. Eg, what about ensuring that state such as iWMMXt on PXA CPUs is properly restored? Right. This arch specific part can be something like suspend-v[3-7].S to accomodate those differences It's not quite that simple - things like iWMMXt aren't part of the ARM arch specs. We already have code which knows what needs to be saved across a power-off transition - its what we use for our normal suspend/resume functionality, so we should look at re-using that code for hibernate as well. We really don't want to be maintaining two sets of code doing the same thing. Could you explain which code you're refering for the existing one? The code which handles saving state for the existing suspend/resume support. This code already saves the necessary state from CP15 and any other state which needs to be saved prior to putting the system into low power mode. Every machine class which supports suspend today has their own chunk of code which does this, normally called something like sleep.S Ok, it seems to be the way to try to make use of the existing one for suspend-to-ram with some modifications. [sorry to be late to the party here] At least on OMAP, we already have everything needed to save/restore context for off-mode transitions handled in the suspend (and idle) paths. So, at least in terms of context save/restore, there should be minimal changes needed there. 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, Aug 30, 2010 at 03:05:32PM -0700, Linus Torvalds wrote: On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: That is why I started taking accelerometers in. But I am concerned that taking accelerometers (which indeed are most often input devices) will lead people to try and use the same for temperature, ALS and other sensors that are more often used in industrial process controls. You're just being silly. Nobody writes a driver for a temperature sensor or ambient light sensor. They write a driver for a specific *chip* that is used in cellphones etc, and that happens to have an ambient light and temperature sensor on it. And? Yes, they have a ALS and temperature sensors. They also have voltage regulators, pwm, ADC and a bunch of other stuff wired on. You are not arguing that all of those should be input devices just because they happen to reside on the same chip? And in that context, it really does make sense to see it as an input driver. And the fact that there are industrial uses for ALS sensors that aren't necessarily at all interested on the input layer should not matter at all. I think it does matter; we should have standard interface for certain functionality that makes sense for everyone. So far cellphone guys wanted to plumb such devices through input not necessarily because these are HID events but because: 1. Input transport via evdev is very convenient 2. There is no other standard alternative Once there is standard interface for such sensors they will happily use it and will not look back. So don't bring up ALS isn't always input because within the context of a driver for some highly integrated cellphone model, it really IS input, and there is no ambiguity at all. So your sometimes it is, and sometimes it isn't argument is bogus. The ambiguity simply doesn't exist when seen in context. Sure, for a particular cell phone there is no ambiguity, the sensor has certain functionality assigned that is well known. But does this mean that we should not expect parts being reused at all anymore? (or GPS device, for that matter) really be? But why GPS should be input device? It has nothing to do with user input. What? OF COURSE it is an input driver. It's the user moving the device around. It's EXACTLY the same thing as an accelerometer in that respect. Sure, it's a bit less precise and measures movement wrt some external frame, but technically they are almost exactly the same. If you se doing a navigation app, the accelerometer, the compass and the GPS are all equally (but differently) important. Again - it's not a user touching buttons. But it IS a user moving around. Right, but do you expect that movement to cause an immediate action? When you press a key - something happens; when you swing a Wii controller - the device reacts. And really you can swap joysticks, motion controllers, Sony's 6-axis and so forth and the application would be hard pressed to tell the difference. I am unsure how you would play a game with GPS as an input device. -- Dmitry -- 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/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Will Deacon will.dea...@arm.com [100823 09:51]: Hi Tony, Hi all, Here are some experimental patches to allow booting ARMv7 SMP kernel on UP to some extent. Posting these early in case it is of any help as I know at least Bryan Wu is working on similar issues. The patches are very much work in progress, and does not quite boot to init yet so there's all kinds of things to fix. But at least these patches allow booting to the point where the fixing issues might be a bit easier.. Currently it boots to the point where there are tons of WARNING: at mm/percpu-vm.c:320 pcpu_alloc prints. I've got some similar hacks for the RealView boards which I've used to build a Kernel that can boot on the PB-A8 and PBX-A9. Whilst this is the wrong way of going about solving the problem [Russell's code patching is a lot neater and more scaleable] you might be interested in looking at the code anyway: http://www.linux-arm.org/git?p=linux-2.6-wd.git;a=shortlog;h=refs/heads/smp-up-hacks Only v7 cores are supported and TEX remapping is used to avoid having to worry about setting the shared attribute at runtime. Yuck! Heh cool, I'll take a look at those :) Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Tony Lindgren t...@atomide.com [100820 04:59]:
* Russell King - ARM Linux li...@arm.linux.org.uk [100819 13:13]:
On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote:
Looks like something is not quite right with smp_on_up part of
__fixup_smp,
returning early before smp_on_up does not produce that.
It's probably overwriting some register it shouldn't be. I might be
able to look at this sometime during the coming week... assuming that
the weather is as bad as they forecast and I have 'net connectivity.
This seems to fix it.
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 30 Aug 2010 13:52:52 -0700
Subject: [PATCH] ARM: Fix smp_on_up to not trash r1 and r2
We need to preserve r1 and r2 for __mmap_switched. So
use r3, r6, r7 instead of r1, r2, r3. We can trash
r3, r6, r7 as they get corrupted in __create_page_tables
anyways.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -353,14 +353,14 @@ __fixup_smp:
smp_on_up:
adr r0, 1f
- ldmia r0, {r1, r2, r3}
- sub r1, r0, r1
- add r2, r2, r1
- add r3, r3, r1
-2: cmp r2, r3
- ldmia r2!, {r0, r4}
+ ldmia r0, {r3, r6, r7}
+ sub r3, r0, r3
+ add r6, r6, r3
+ add r7, r7, r3
+2: cmp r6, r7
+ ldmia r6!, {r0, r4}
movhs pc, lr
- str r4, [r0, r1]
+ str r4, [r0, r3]
b 2b
ENDPROC(__fixup_smp)
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Kevin Hilman khil...@deeprootsystems.com writes:
+if (!found) {
+user = kzalloc(sizeof(struct omap_vdd_user_list), GFP_KERNEL);
+if (!user) {
+pr_err(%s: Unable to creat a new user for vdd_%s\n,
+__func__, voltdm-name);
+mutex_unlock(vdd-scaling_mutex);
+return -ENOMEM;
+}
+user-dev = dev;
+} else {
+plist_del(user-node, vdd-user_list);
hmm... if we get here, we didn't find a match, so 'user' points to the
last element in the list (which is the highest voltage request, I
guess), or even NULL if the list is empty. Then, this node is deleted.
-ECONFUSED
OK, I'm a bit dense.
It took me a few reads, now I think I know what's going on here.
If we get here, we found a match, and you delete the existing value for
that device so that inserting a new one (with a new voltage) will be
kept in the right order. Right?
Some comments might help clarify things here.
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/8] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath th...@ti.com writes:
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+unsigned long omap_voltage_get_nom_volt(struct voltagedomain *voltdm)
+{
+ struct omap_opp *opp;
+ struct omap_vdd_info *vdd;
+ unsigned long freq;
+
+ if (!voltdm || IS_ERR(voltdm)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return 0;
+ }
+
+ vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
+
+ freq = vdd-volt_clk-rate;
+ opp = opp_find_freq_ceil(vdd-opp_dev, freq);
+ if (IS_ERR(opp)) {
+ pr_warning(%s: Unable to find OPP for vdd_%s freq%ld\n,
+ __func__, voltdm-name, freq);
+ return 0;
+ }
+
+ /*
+ * Use higher freq voltage even if an exact match is not available
+ * we are probably masking a clock framework bug, so warn
+ */
+ if (unlikely(freq != vdd-volt_clk-rate))
+ pr_warning(%s: Available freq %ld != dpll freq %ld.\n,
+ __func__, freq, vdd-volt_clk-rate);
+
+ return opp_get_voltage(opp);
+}
Minor nit...
Rather than having to look this up in the OPP table every time, couldn't
this be initialized and stored in struct voltagedomain?
Whenever the voltage is changed, it's updated in struct voltagedomain
and doesn't have to be continually looked up in the OPP layer.
+/**
+ * omap_vp_get_curr_volt : API to get the current vp voltage.
+ * @voltdm: pointer to the VDD.
+ *
+ * This API returns the current voltage for the specified voltage processor
+ */
+unsigned long omap_vp_get_curr_volt(struct voltagedomain *voltdm)
+{
+ struct omap_vdd_info *vdd;
+ u8 curr_vsel;
+
+ if (!voltdm || IS_ERR(voltdm)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return 0;
+ }
+
+ vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
+
+ curr_vsel = voltage_read_reg(vdd-vp_offs.voltage);
+ return omap_twl_vsel_to_uv(curr_vsel);
+}
This too. No need to read from the HW, if we just keep track of all
the changes in 'struct voltagedomain'.
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/8] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath th...@ti.com writes:
+/*
+ * vc_bypass_scale_voltage - VC bypass method of voltage scaling
+ */
+static int vc_bypass_scale_voltage(struct omap_vdd_info *vdd,
+ unsigned long target_volt)
+{
+ struct omap_volt_data *volt_data;
+ u32 vc_bypass_value, vc_cmdval, vc_valid, vc_bypass_val_reg_offs;
+ u32 vp_errgain_val, vc_cmd_on_mask;
+ u32 loop_cnt = 0, retries_cnt = 0;
+ u32 smps_steps = 0, smps_delay = 0;
+ u8 vc_data_shift, vc_slaveaddr_shift, vc_regaddr_shift;
+ u8 vc_cmd_on_shift;
+ u8 target_vsel, current_vsel, sr_i2c_slave_addr;
+
+ if (cpu_is_omap34xx()) {
+ vc_cmd_on_shift = OMAP3430_VC_CMD_ON_SHIFT;
+ vc_cmd_on_mask = OMAP3430_VC_CMD_ON_MASK;
+ vc_data_shift = OMAP3430_DATA_SHIFT;
+ vc_slaveaddr_shift = OMAP3430_SLAVEADDR_SHIFT;
+ vc_regaddr_shift = OMAP3430_REGADDR_SHIFT;
+ vc_valid = OMAP3430_VALID_MASK;
+ vc_bypass_val_reg_offs = OMAP3_PRM_VC_BYPASS_VAL_OFFSET;
+ sr_i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR;
+ }
cpu_is_* should not be used every time this path is taken. Rather, all
the SoC conditional values should be initialized once at init time.
[...]
+/* VP force update method of voltage scaling */
+static int vp_forceupdate_scale_voltage(struct omap_vdd_info *vdd,
+ unsigned long target_volt)
+{
+ struct omap_volt_data *volt_data;
+ u32 vc_cmd_on_mask, vc_cmdval, vpconfig;
+ u32 smps_steps = 0, smps_delay = 0;
+ int timeout = 0;
+ u8 target_vsel, current_vsel;
+ u8 vc_cmd_on_shift;
+ u8 prm_irqst_reg_offs, ocp_mod;
+
+ if (cpu_is_omap34xx()) {
+ vc_cmd_on_shift = OMAP3430_VC_CMD_ON_SHIFT;
+ vc_cmd_on_mask = OMAP3430_VC_CMD_ON_MASK;
+ prm_irqst_reg_offs = OMAP3_PRM_IRQSTATUS_MPU_OFFSET;
+ ocp_mod = OCP_MOD;
+ }
ditto.
Same goes for the OMAP4 patches which add to this.
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 10/13] OMAP3: Introduce custom set rate and get rate APIs for scalable devices
Thara Gopinath th...@ti.com writes:
This patch also introduces omap3_mpu_set_rate, omap3_iva_set_rate,
omap3_l3_set_rate, omap3_mpu_get_rate, omap3_iva_get_rate,
omap3_l3_get_rate as device specific set rate and get rate
APIs for OMAP3 mpu, iva and l3_main devices. This patch also
calls into opp_populate_rate_fns during system init to register
various set_rate and get_rate APIs with the generic opp
framework.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/cpufreq34xx.c | 104
+
1 files changed, 104 insertions(+), 0 deletions(-)
These don't belong in cpufreq34xx.c (now known as opp3xxx_data.c) This
file is only for the OPP data itself. Any SoC specific code should go
into pm34xx.c.
Kevin
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
index 195b5bc..8b9ef72 100644
--- a/arch/arm/mach-omap2/cpufreq34xx.c
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -24,8 +24,22 @@
#include plat/opp.h
#include plat/cpu.h
+#include plat/clock.h
+
+#include cm-regbits-34xx.h
+#include prm.h
#include omap3-opp.h
+static int omap3_mpu_set_rate(struct device *dev, unsigned long rate);
+static int omap3_iva_set_rate(struct device *dev, unsigned long rate);
+static int omap3_l3_set_rate(struct device *dev, unsigned long rate);
+
+static unsigned long omap3_mpu_get_rate(struct device *dev);
+static unsigned long omap3_iva_get_rate(struct device *dev);
+static unsigned long omap3_l3_get_rate(struct device *dev);
+
+struct clk *dpll1_clk, *dpll2_clk, *dpll3_clk;
+
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
OMAP_OPP_DEF(mpu, true, 12500, 975000),
@@ -92,12 +106,82 @@ static struct omap_opp_def __initdata
omap36xx_opp_def_list[] = {
};
static u32 omap36xx_opp_def_size = ARRAY_SIZE(omap36xx_opp_def_list);
+
+static int omap3_mpu_set_rate(struct device *dev, unsigned long rate)
+{
+ unsigned long cur_rate = omap3_mpu_get_rate(dev);
+ int ret;
+
+#ifdef CONFIG_CPU_FREQ
+ struct cpufreq_freqs freqs_notify;
+
+ freqs_notify.old = cur_rate / 1000;
+ freqs_notify.new = rate / 1000;
+ freqs_notify.cpu = 0;
+ /* Send pre notification to CPUFreq */
+ cpufreq_notify_transition(freqs_notify, CPUFREQ_PRECHANGE);
+#endif
+ ret = clk_set_rate(dpll1_clk, rate);
+ if (ret) {
+ dev_warn(dev, %s: Unable to set rate to %ld\n,
+ __func__, rate);
+ return ret;
+ }
+
+#ifdef CONFIG_CPU_FREQ
+ /* Send a post notification to CPUFreq */
+ cpufreq_notify_transition(freqs_notify, CPUFREQ_POSTCHANGE);
+#endif
+
+#ifndef CONFIG_CPU_FREQ
+ /*Update loops_per_jiffy if processor speed is being changed*/
+ loops_per_jiffy = compute_lpj(loops_per_jiffy,
+ cur_rate / 1000, rate / 1000);
+#endif
+ return 0;
+}
+
+static unsigned long omap3_mpu_get_rate(struct device *dev)
+{
+ return dpll1_clk-rate;
+}
+
+static int omap3_iva_set_rate(struct device *dev, unsigned long rate)
+{
+ return clk_set_rate(dpll2_clk, rate);
+}
+
+static unsigned long omap3_iva_get_rate(struct device *dev)
+{
+ return dpll2_clk-rate;
+}
+
+static int omap3_l3_set_rate(struct device *dev, unsigned long rate)
+{
+ int l3_div;
+
+ l3_div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL)
+ OMAP3430_CLKSEL_L3_MASK;
+
+ return clk_set_rate(dpll3_clk, rate * l3_div);
+}
+
+static unsigned long omap3_l3_get_rate(struct device *dev)
+{
+ int l3_div;
+
+ l3_div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL)
+ OMAP3430_CLKSEL_L3_MASK;
+ return dpll3_clk-rate / l3_div;
+}
+
/* Temp variable to allow multiple calls */
static u8 __initdata omap3_table_init;
int __init omap3_pm_init_opp_table(void)
{
struct omap_opp_def *opp_def, *omap3_opp_def_list;
+ struct device *dev;
u32 omap3_opp_def_size;
int i, r;
@@ -122,6 +206,26 @@ int __init omap3_pm_init_opp_table(void)
opp_def-freq, opp_def-hwmod_name);
}
+ dpll1_clk = clk_get(NULL, dpll1_ck);
+ dpll2_clk = clk_get(NULL, dpll2_ck);
+ dpll3_clk = clk_get(NULL, dpll3_m2_ck);
+
+ /* Populate the set rate and get rate for mpu, iva and l3 device */
+ dev = omap2_get_mpuss_device();
+ if (dev)
+ opp_populate_rate_fns(dev, omap3_mpu_set_rate,
+ omap3_mpu_get_rate);
+
+ dev = omap2_get_iva_device();
+ if (dev)
+ opp_populate_rate_fns(dev, omap3_iva_set_rate,
+ omap3_iva_get_rate);
+
+ dev = omap2_get_l3_device();
+ if (dev)
+ opp_populate_rate_fns(dev, omap3_l3_set_rate,
+ omap3_l3_get_rate);
+
return 0;
}
--
To unsubscribe from this list: send the
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
Hi Vishwa, On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. There are two other issues when we use 32k timer for latency measurement. snip + + /* take care of overflow */ + if (postidle_time preidle_time) + postidle_time += (u32) 0x; + if (wkup_time sleep_time) + wkup_time += (u32) 0x; + snip 1.We are checking postidle_time preidle_time to find out whether there had been an over flow or not. There can be situations in which the timer overflows and still we have a greater postidle_time. 2. We are doing the correction for one overflow. What happens if the timer overflows for a second or third time. Can we keep track of the number of overflows and then do the correction accordingly? Regards, Silesh Regards Vishwa Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 CPUIDLE: CPU Idle latency measurement
-Original Message- From: Silesh C V [mailto:sailes...@gmail.com] Sent: Tuesday, August 31, 2010 9:53 AM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. There are two other issues when we use 32k timer for latency measurement. snip + + /* take care of overflow */ + if (postidle_time preidle_time) + postidle_time += (u32) 0x; + if (wkup_time sleep_time) + wkup_time += (u32) 0x; + snip 1.We are checking postidle_time preidle_time to find out whether there had been an over flow or not. There can be situations in which the timer overflows and still we have a greater postidle_time. 2. We are doing the correction for one overflow. What happens if the timer overflows for a second or third time. Can we keep track of the number of overflows and then do the correction accordingly? Unfortunately, there is no way to check if overflow happens more than once in 32k timer and as you said, theoretically it's possible that if timer overflows more than once, these calculation will wrong. Having said that, do you really see any usecase where system will idle for more than 37 hours in single cpuidle execution to cause timer overflow? Vishwa Regards, Silesh Regards Vishwa Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
Hi, On Mon, 30 Aug 2010 15:43:52 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Mon, Aug 30, 2010 at 03:05:32PM -0700, Linus Torvalds wrote: On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: That is why I started taking accelerometers in. But I am concerned that taking accelerometers (which indeed are most often input devices) will lead people to try and use the same for temperature, ALS and other sensors that are more often used in industrial process controls. You're just being silly. Nobody writes a driver for a temperature sensor or ambient light sensor. They write a driver for a specific *chip* that is used in cellphones etc, and that happens to have an ambient light and temperature sensor on it. And? Yes, they have a ALS and temperature sensors. They also have voltage regulators, pwm, ADC and a bunch of other stuff wired on. You are not arguing that all of those should be input devices just because they happen to reside on the same chip? And in that context, it really does make sense to see it as an input driver. And the fact that there are industrial uses for ALS sensors that aren't necessarily at all interested on the input layer should not matter at all. I think it does matter; we should have standard interface for certain functionality that makes sense for everyone. So far cellphone guys wanted to plumb such devices through input not necessarily because these are HID events but because: 1. Input transport via evdev is very convenient 2. There is no other standard alternative Once there is standard interface for such sensors they will happily use it and will not look back. I disagree. If the device is used as input and currently app developers have to find other ways to use such input data, having a standard interface other than input layer will just make the mess standardized, but it will still be a mess. So don't bring up ALS isn't always input because within the context of a driver for some highly integrated cellphone model, it really IS input, and there is no ambiguity at all. So your sometimes it is, and sometimes it isn't argument is bogus. The ambiguity simply doesn't exist when seen in context. Sure, for a particular cell phone there is no ambiguity, the sensor has certain functionality assigned that is well known. But does this mean that we should not expect parts being reused at all anymore? Why are we trying to overengineer on such simple devices ? Wasn't it so that we will design and implement solutions when the problem arrives ? Why are we trying to think of all cases such a simple device might be used just for the sake of not being input device ? (or GPS device, for that matter) really be? But why GPS should be input device? It has nothing to do with user input. What? OF COURSE it is an input driver. It's the user moving the device around. It's EXACTLY the same thing as an accelerometer in that respect. Sure, it's a bit less precise and measures movement wrt some external frame, but technically they are almost exactly the same. If you se doing a navigation app, the accelerometer, the compass and the GPS are all equally (but differently) important. Again - it's not a user touching buttons. But it IS a user moving around. Right, but do you expect that movement to cause an immediate action? When you press a key - something happens; when you swing a Wii controller - the device reacts. And really you can swap joysticks, motion controllers, Sony's 6-axis and so forth and the application would be hard pressed to tell the difference. I am unsure how you would play a game with GPS as an input device. it might not be used on a game, but on a map application, that IS input. You're failing to see input devices are used in cases other than gaming. -- balbi -- 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] OMAP: hwmod: New API to modify the autoidle bits of sysconfig register
On Monday 30 August 2010 08:56 PM, Kevin Hilman wrote:
Kishon Vijay Abraham Ikis...@ti.com writes:
Though the sysconfig register values shouldn't be modified directly by
the driver, MCBSP should be considered a special case where sysconfig
registers need to be modified dynamically by the driver.
For e.g MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone.
This patch creates a new API that forms a wrapper to
_set_module_autoidle() to modify the AUTOIDLE bit.
Since driver should not be using hwmod directly, how is this API going
to be used? Will this only be called from arch/arm/mach-omap2/mcbsp.c?
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same. So we are planning to
store the omap_hwmod structure in platform_data during
arch_initcall (in the callback to omap_hwmod_for_each_by_class). So
whenever the
AUTOIDLE bits need to be reset or set, we pass the stored
omap_hwmod structure to this API. Currently, the functions that needs
AUTOIDLE
bit to be modified (omap_st_on, omap_st_off) resides in plat-omap.
-Kishon
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Charulatha Vch...@ti.com
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Partha Basakp-bas...@ti.com
Subject should contain prefix like 'OMAP: hwmod: ...'
Kevin
---
arch/arm/mach-omap2/omap_hwmod.c | 29 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9bd99ad..0d38404 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -969,6 +969,35 @@ int _omap_hwmod_idle(struct omap_hwmod *oh)
}
/**
+ * omap_hwmod_set_module_autoidle - set the hwmod's OCP slave autoidle
+ * @oh: struct omap_hwmod *
+ * @autoidle: desired AUTOIDLE bitfield value (0 or 1)
+ *
+ * Sets the IP block's OCP slave autoidle in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the AUTOIDLE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_module_autoidle().
+ */
+int omap_hwmod_set_module_autoidle(struct omap_hwmod *oh, u8 autoidle)
+{
+ u32 v;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ retval = _set_module_autoidle(oh, autoidle,v);
+
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
+/**
* _shutdown - shutdown an omap_hwmod
* @oh: struct omap_hwmod *
*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 6adbb63..7042b86 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -526,6 +526,7 @@ int omap_hwmod_hardreset_deassert(struct omap_hwmod *oh,
const char *name);
int omap_hwmod_hardreset_state(struct omap_hwmod *oh, const char *name);
int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
+int omap_hwmod_set_module_autoidle(struct omap_hwmod *oh, u8 autoidle);
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
--
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/8 v2]usb: musb: hwmod and runtime pm support for musb
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, August 26, 2010 5:29 AM To: Kalliguddi, Hema Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Felipe Balbi; Tony Lindgren; Cousson, Benoit; Paul Walmsley Subject: Re: [PATCH 0/8 v2]usb: musb: hwmod and runtime pm support for musb Hema HK hem...@ti.com writes: Cc: Felipe Balbi felipe.ba...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com This patch series makes OMAP2PLUS musb Module implemented in HWMOD FW way. It also implements musb driver to use the runtime pm apis. PATCH[1/8 v2] and [PATCH 2/8 v2] are the pre-requisites for the hwmod support for the usb module. PATCH[6/8 v2] is core-offmode usb fix patch for the OMAP3 in idle path. As per the OMAP usbotg specification[1] musb sysconfig register has to be set to force idle and force standby when not used and set smart idle/standby during operation.otherwise core-off will be prevented by musb. [1]: http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf This patch series is created on origin/pm-wip/hwmods-omap4. This patch series is tested on OMAP3630 zoom3 and OMAP4430 SDP. On OMAP3630 zoom3, off mode is tested on origin/pm branch using omap3_pm_defconfig. This IP is on OMAP2 as well, but I don't see any hwmods for OMAP2. Please also add hwmods for OMAP2 and test as well. OK. I will do that and post a patch. Thanks, Kevin Version History: --- Vesrion v2: Fixed review comments. Removed the omap_hwmod.h inclusion from musb.h file which was breaking the non-omap platform build. Using the runtime pm apis in the idle path(interrupts disabled). Added the omap4 hwmod data base. Version v1: initial version of the patch series. Some of the links for v1 http://www.spinics.net/lists/linux-usb/msg34570.html http://www.spinics.net/lists/linux-omap/msg34568.html http://www.spinics.net/lists/linux-usb/msg34544.html http://www.spinics.net/lists/linux-usb/msg34540.html http://www.spinics.net/lists/linux-usb/msg34589.html http://www.spinics.net/lists/linux-usb/msg34554.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32973.html Cousson, Benoit (1): usb: musb: HWMOD database structures addition for OMAP4 Hema HK (7): usb: musb: Adding names for IRQs in resource structure usb: musb: Remove board_data parameter from musb_platform_init() usb: musb: HWMOD database structures addition for OMAP3 usb: musb: Using omap_device_build for musb device registration usb: musb: Offmode fix for idle path OMAP: Hwmod api changes usb : musb: Using runtime pm apis for musb. arch/arm/mach-davinci/usb.c |2 + arch/arm/mach-omap2/omap_hwmod.c | 18 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 100 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 92 arch/arm/mach-omap2/pm34xx.c |9 ++ arch/arm/mach-omap2/usb-musb.c| 188 - arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/usb.h |9 ++ arch/arm/plat-omap/omap_device.c | 43 ++ arch/blackfin/mach-bf527/boards/cm_bf527.c|2 + arch/blackfin/mach-bf527/boards/ezbrd.c |2 + arch/blackfin/mach-bf527/boards/ezkit.c |2 + arch/blackfin/mach-bf548/boards/cm_bf548.c|2 + arch/blackfin/mach-bf548/boards/ezkit.c |2 + drivers/usb/musb/blackfin.c |2 +- drivers/usb/musb/cppi_dma.c |2 +- drivers/usb/musb/davinci.c|2 +- drivers/usb/musb/musb_core.c | 26 +++- drivers/usb/musb/musb_core.h |3 +- drivers/usb/musb/musbhsdma.c |2 +- drivers/usb/musb/omap2430.c | 87 ++-- drivers/usb/musb/tusb6010.c |2 +- include/linux/usb/musb.h | 20 +++ 23 files changed, 522 insertions(+), 97 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8 v2]usb: musb: hwmod and runtime pm support for musb
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, August 26, 2010 5:29 AM To: Kalliguddi, Hema Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Felipe Balbi; Tony Lindgren; Cousson, Benoit; Paul Walmsley Subject: Re: [PATCH 0/8 v2]usb: musb: hwmod and runtime pm support for musb Hema HK hem...@ti.com writes: Cc: Felipe Balbi felipe.ba...@nokia.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com This patch series makes OMAP2PLUS musb Module implemented in HWMOD FW way. It also implements musb driver to use the runtime pm apis. PATCH[1/8 v2] and [PATCH 2/8 v2] are the pre-requisites for the hwmod support for the usb module. PATCH[6/8 v2] is core-offmode usb fix patch for the OMAP3 in idle path. As per the OMAP usbotg specification[1] musb sysconfig register has to be set to force idle and force standby when not used and set smart idle/standby during operation.otherwise core-off will be prevented by musb. [1]: http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf This patch series is created on origin/pm-wip/hwmods-omap4. This patch series is tested on OMAP3630 zoom3 and OMAP4430 SDP. On OMAP3630 zoom3, off mode is tested on origin/pm branch using omap3_pm_defconfig. This IP is on OMAP2 as well, but I don't see any hwmods for OMAP2. Please also add hwmods for OMAP2 and test as well. OK. I will do that and post a patch. Thanks, Kevin Version History: --- Vesrion v2: Fixed review comments. Removed the omap_hwmod.h inclusion from musb.h file which was breaking the non-omap platform build. Using the runtime pm apis in the idle path(interrupts disabled). Added the omap4 hwmod data base. Version v1: initial version of the patch series. Some of the links for v1 http://www.spinics.net/lists/linux-usb/msg34570.html http://www.spinics.net/lists/linux-omap/msg34568.html http://www.spinics.net/lists/linux-usb/msg34544.html http://www.spinics.net/lists/linux-usb/msg34540.html http://www.spinics.net/lists/linux-usb/msg34589.html http://www.spinics.net/lists/linux-usb/msg34554.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32973.html Cousson, Benoit (1): usb: musb: HWMOD database structures addition for OMAP4 Hema HK (7): usb: musb: Adding names for IRQs in resource structure usb: musb: Remove board_data parameter from musb_platform_init() usb: musb: HWMOD database structures addition for OMAP3 usb: musb: Using omap_device_build for musb device registration usb: musb: Offmode fix for idle path OMAP: Hwmod api changes usb : musb: Using runtime pm apis for musb. arch/arm/mach-davinci/usb.c |2 + arch/arm/mach-omap2/omap_hwmod.c | 18 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 100 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 92 arch/arm/mach-omap2/pm34xx.c |9 ++ arch/arm/mach-omap2/usb-musb.c| 188 - arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/usb.h |9 ++ arch/arm/plat-omap/omap_device.c | 43 ++ arch/blackfin/mach-bf527/boards/cm_bf527.c|2 + arch/blackfin/mach-bf527/boards/ezbrd.c |2 + arch/blackfin/mach-bf527/boards/ezkit.c |2 + arch/blackfin/mach-bf548/boards/cm_bf548.c|2 + arch/blackfin/mach-bf548/boards/ezkit.c |2 + drivers/usb/musb/blackfin.c |2 +- drivers/usb/musb/cppi_dma.c |2 +- drivers/usb/musb/davinci.c|2 +- drivers/usb/musb/musb_core.c | 26 +++- drivers/usb/musb/musb_core.h |3 +- drivers/usb/musb/musbhsdma.c |2 +- drivers/usb/musb/omap2430.c | 87 ++-- drivers/usb/musb/tusb6010.c |2 +- include/linux/usb/musb.h | 20 +++ 23 files changed, 522 insertions(+), 97 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nagging free/reclaim gpio's
Hi, On Mon, 30 Aug 2010 15:48:59 -0400, Philip Balister phi...@balister.org wrote: this is telling you, you have entered invalid arguments to gpio_unexport. I'm calling gpio_free, it must then be calling gpio_unexport for me ... yes, but please always keep the list in Cc. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap4 hsmmc : Adding card detect support for MMC1
On Mon, Aug 30, 2010 at 11:18:23PM +0530, kishore kadiyala wrote:
Adding card detect callback function and card detect configuration
function for MMC1 Controller.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, Card detect interrupt source is
twl6030 and the card detect call back function provides card present/absent
status by reading MMC Control register.
Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
[...]
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ }
+
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ }
Shouldn't this be
pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
return ret;
?
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
Shouldn't this be,
pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
ret);
return ret;
?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
