RE: [PATCH v8 6/11] OMAP1: dmtimer: conversion to platform devices
Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Thursday, January 06, 2011 5:21 AM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCH v8 6/11] OMAP1: dmtimer: conversion to platform
devices
Hi Tarun,
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Thara Gopinath th...@ti.com
Convert OMAP1 dmtimers into a platform devices and then registers with
device model framework so that it can be bound to corresponding driver.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Cousson, Benoit b-cous...@ti.com
One minor nit...
[...]
+int __init omap1_dm_timer_init(void)
+{
+ int i;
+ int ret;
+ struct dmtimer_platform_data *pdata;
+ struct platform_device *pdev;
+
+ pr_debug(%s: +\n, __func__);
stray debug print?
I kept for debugging; well it can be removed.
--
Tarun
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] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
Hi, Kevin Hilman [khil...@ti.com]: Aaro Koskinen aaro.koski...@nokia.com writes: Make !CONFIG_SUSPEND init declarations identical on all OMAPs and eliminate some ifdefs. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com I like this solution, but it introduces compiler warnings: [...] As you likely noticed, removing the const leads to checkpatch warnings: WARNING: struct platform_suspend_ops should normally be const so the choice is between a checkpatch warning or a bunch of compiler warnings. Alternatively, I just posted a patch[1] to linux-pm propsing to fix this at the source. Let's see what happens there. Merging $SUBJECT patch will depend on how this is fixed upstream. Sorry, I should have mentioned this when I posted the patch. I was aware of this issue, but I thought this was already fixed in upstream. Check the following commit in linux-next: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=2f55ac072f5344519348c0c94b3d2f4cca46847b (suspend: constify platform_suspend_ops) A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Current OMAP build failures
I've observed the following issues while building 2.6.37 + my devel branch. I don't believe any of them to be due to anything in my tree, so would be in 2.6.37 as well. === omap1 === arch/arm/plat-omap/built-in.o: In function `omap2_i2c_add_bus': arch/arm/plat-omap/i2c.c:169: undefined reference to `omap2_i2c_mux_pins' $ grep omap2_i2c_mux_pins arch/arm/*omap* -r arch/arm/mach-omap2/i2c.c:void __init omap2_i2c_mux_pins(int bus_id) arch/arm/plat-omap/i2c.c: omap2_i2c_mux_pins(bus_id); arch/arm/plat-omap/include/plat/i2c.h:void __init omap2_i2c_mux_pins(int bus_id); So, OMAP1 doesn't provide this symbol. === omap2 === arch/arm/plat-omap/devices.c:253: warning: ■omap_init_wdt■ defined but not used arch/arm/mach-omap2/irq.c:64: warning: ■intc_context■ defined but not used arch/arm/mach-omap2/prcm.c:122: warning: ■prcm_context■ defined but not used Missing __maybe_unused or something else? It also comes with three section mismatches: WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices() The function omap_early_device_register() references the function __init early_platform_add_devices(). This is often because omap_early_device_register lacks a __init annotation or the annotation of early_platform_add_devices is wrong. As early_platform_add_devices() is marked __init, so too should be omap_early_device_register(). WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices() The function omap_device_build_ss() references the function __init early_platform_add_devices(). This is often because omap_device_build_ss lacks a __init annotation or the annotation of early_platform_add_devices is wrong. This looks like omap_early_device_register() has been inlined into omap_device_build_ss(), and it doesn't look like it can be marked __init. Rather than passing an 'is_early_device' into this function, split out the common code into a separate function which takes a function pointer to the registration function. Then you can have two additional functions, one marked __init which uses omap_early_device_register() and one not marked __init using omap_device_register(). This also means that we get the init-section type checking further up the chain. WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from the variable h4_config to the (unknown reference) .init.data:(unknown) The variable h4_config references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Maybe it shouldn't be marked __initdata? === omap3 === WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init() The function sdp3430_twl_gpio_setup() references the function __init omap2_hsmmc_init(). This is often because sdp3430_twl_gpio_setup lacks a __init annotation or the annotation of omap2_hsmmc_init is wrong. Missing __init on sdp3430_twl_gpio_setup ? WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices() The function omap_early_device_register() references the function __init early_platform_add_devices(). This is often because omap_early_device_register lacks a __init annotation or the annotation of early_platform_add_devices is wrong. As before. WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices() The function omap_device_build_ss() references the function __init early_platform_add_devices(). This is often because omap_device_build_ss lacks a __init annotation or the annotation of early_platform_add_devices is wrong. As before. WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe() The variable twl_driver references the function __init twl_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, twl_probe shouldn't be __init ? === omap4 === Nothing apparantly new over omap3. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
On Wed, Jan 05, 2011 at 04:25:32PM -0800, Kevin Hilman wrote:
As you likely noticed, removing the const leads to checkpatch warnings:
WARNING: struct platform_suspend_ops should normally be const
so the choice is between a checkpatch warning or a bunch of compiler
warnings.
checkpatch should not be checking that data declarations are const.
That's a decision for those people declaring them to decide upon, as
they may need to modify the structure before registration.
By doing so, we end up encouraging people to write more code - such
as declaring it __initconst, and then kmalloc'ing, memcpy'ing and
modifying that before registering it.
-static struct platform_suspend_ops omap_pm_ops = {
- .begin = omap2_pm_begin,
- .enter = omap2_pm_enter,
- .end= omap2_pm_end,
- .valid = suspend_valid_only_mem,
+static const struct platform_suspend_ops omap_pm_ops[] = {
+ {
+ .begin = omap2_pm_begin,
+ .enter = omap2_pm_enter,
+ .end= omap2_pm_end,
+ .valid = suspend_valid_only_mem,
+ }
};
-#else
-static const struct platform_suspend_ops __initdata omap_pm_ops;
#endif /* CONFIG_SUSPEND */
/* XXX This function should be shareable between OMAP2xxx and OMAP3 */
@@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
omap24xx_cpu_suspend_sz);
}
- suspend_set_ops(omap_pm_ops);
+ suspend_set_ops(omap_pm_ops);
Utterly yuck. Declaring it as a single element array just to avoid an
ifdef. That's worse than having an ifdef here.
There's another solution. Don't mess about with sticking such stuff in
the header either.
#ifdef WHATEVER
static const struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
.enter = omap2_pm_enter,
.end= omap2_pm_end,
.valid = suspend_valid_only_mem,
};
#define PM_OPS omap_pm_ops
#else
#define PM_OPS NULL
#endif
...
suspend_set_ops(PM_OPS);
That keeps it all nice and local, and you can see exactly what's going on
without having it spread across many different random files.
--
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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Thu, Jan 06, 2011 at 09:26:40AM +0530, Keerthy wrote:
---
drivers/hwmon/Kconfig| 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/twl4030-madc.c | 794
++
include/linux/i2c/twl4030-madc.h | 118 ++
4 files changed, 924 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
hwmon drivers are also expected to have a file under Documentation.
+struct twl4030_madc_data {
+ struct device *hwmon_dev;
+ struct mutex lock;/* mutex protecting this data structire */
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+static struct twl4030_madc_data *twl4030_madc;
I'd expect this to be per driver instance rather than global (I know
it's vanishingly unlikely that you'll get multiple twl4030s in a single
system but it's nicer).
+/*
+ * sysfs hook function
+ */
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct twl4030_madc_request req;
+ long val;
+
+ req.channels = (1 attr-index);
+ req.method = TWL4030_MADC_SW2;
+ req.func_cb = NULL;
+ val = twl4030_madc_conversion(req);
+ if (val = 0)
+ val = req.rbuf[attr-index];
+ else
+ return val;
+ return sprintf(buf, %ld\n, val);
Does this return data in the appropriate units - milivolts for voltages?
+/*
+ * Enables irq.
+ * @madc - pointer to twl4030_madc_data struct
+ * @id - irq number to be enabled
+ * can take one of TWL4030_MADC_RT, TWL4030_MADC_SW1, TWL4030_MADC_SW2
+ * corresponding to RT, SW1, SW2 conversion requests.
+ * If the i2c read fails it returns an error else returns 0.
+ */
+static int twl4030_madc_enable_irq(struct twl4030_madc_data *madc, int id)
It'd be good to clarify that this is interrupt sources within this
module rather than Linux interrupt numbers.
+ dev_dbg(madc-hwmon_dev,
+ Disable interrupt failed%d\n, i);
+ }
+
+ madc-requests[i].result_pending = 1;
+ }
+ mutex_lock(madc-lock);
+ for (i = 0; i TWL4030_MADC_NUM_METHODS; i++) {
+
+ r = madc-requests[i];
In general through the driver your use of blank lines is really odd
which doesn't help readability.
+ switch (conv_method) {
+ case TWL4030_MADC_SW1:
+ case TWL4030_MADC_SW2:
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
+ TWL4030_MADC_SW_START, method-ctrl);
+ if (ret) {
+ dev_err(madc-hwmon_dev,
+ unable to write ctrl register 0x%X\n, method-ctrl);
+ return ret;
+ }
+ break;
+ case TWL4030_MADC_RT:
+ default:
+ break;
This looks odd - the function won't actually do anything for non-SW
conversions but won't return an error?
+/* sysfs nodes to read individual channels from user side */
+static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, madc_read, NULL, 0);
+static SENSOR_DEVICE_ATTR(in1_input, S_IRUGO, madc_read, NULL, 1);
+static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, madc_read, NULL, 2);
+static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, madc_read, NULL, 3);
+static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, madc_read, NULL, 4);
+static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, madc_read, NULL, 5);
+static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, madc_read, NULL, 6);
+static SENSOR_DEVICE_ATTR(in7_input, S_IRUGO, madc_read, NULL, 7);
+static SENSOR_DEVICE_ATTR(in8_input, S_IRUGO, madc_read, NULL, 8);
+static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, madc_read, NULL, 9);
+static SENSOR_DEVICE_ATTR(in10_input, S_IRUGO, madc_read, NULL, 10);
+static SENSOR_DEVICE_ATTR(in11_input, S_IRUGO, madc_read, NULL, 11);
+static SENSOR_DEVICE_ATTR(in12_input, S_IRUGO, madc_read, NULL, 12);
+static SENSOR_DEVICE_ATTR(in13_input, S_IRUGO, madc_read, NULL, 13);
+static SENSOR_DEVICE_ATTR(in14_input, S_IRUGO, madc_read, NULL, 14);
+static SENSOR_DEVICE_ATTR(in15_input, S_IRUGO, madc_read, NULL, 15);
I suspect some of these are temperatures, some are voltages and that
some are fixed to particular inputs? The temperatures should be temp_
and if the inputs are from known sources it'd be good to label them.
+ madc-imr = (pdata-irq_line == 1) ?
+ TWL4030_MADC_IMR1 : TWL4030_MADC_IMR2;
+ madc-isr = (pdata-irq_line == 1) ?
+ TWL4030_MADC_ISR1 : TWL4030_MADC_ISR2;
This looks really odd - what's going on here? Comments might help.
+
+MODULE_DESCRIPTION(TWL4030 ADC driver);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(J Keerthy);
A MODULE_ALIAS to enable automatic loading of teh driver would also be
good.
--
To unsubscribe from this list: send the
Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Wed, Jan 05, 2011 at 09:33:28PM -0800, Guenter Roeck wrote: [...] +EXPORT_SYMBOL_GPL(twl4030_madc_conversion); [...] +EXPORT_SYMBOL_GPL(twl4030_get_madc_conversion); No symbol export from hwmon drivers. Other parts of the kernel should not depend on HWMON configuration. Why? It's not like hwmon has an unreasonably large core or similar. I would suggest to check if drivers/staging/iio would be a better fit. That does have the problem that it's in staging and constantly churning, though. When I've looked at it it seemed like awfully hard work to use for devices like this. What I've done in some of my drivers is put the ADC core in the MFD core (it's used by both hwmon and power supply function drivers, plus any board specific stuff people do). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
Hi,
Russell King - ARM Linux [li...@arm.linux.org.uk]:
-static struct platform_suspend_ops omap_pm_ops = {
- .begin = omap2_pm_begin,
- .enter = omap2_pm_enter,
- .end= omap2_pm_end,
- .valid = suspend_valid_only_mem,
+static const struct platform_suspend_ops omap_pm_ops[] = {
+ {
+ .begin = omap2_pm_begin,
+ .enter = omap2_pm_enter,
+ .end= omap2_pm_end,
+ .valid = suspend_valid_only_mem,
+ }
};
-#else
-static const struct platform_suspend_ops __initdata omap_pm_ops;
#endif /* CONFIG_SUSPEND */
/* XXX This function should be shareable between OMAP2xxx and OMAP3 */
@@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
omap24xx_cpu_suspend_sz);
}
- suspend_set_ops(omap_pm_ops);
+ suspend_set_ops(omap_pm_ops);
Utterly yuck. Declaring it as a single element array just to avoid an
ifdef. That's worse than having an ifdef here.
Why it is worse? Reducing the amount of different preprocessor branches will
result in better compile test / static analysis coverage.
There's another solution. Don't mess about with sticking such stuff in
the header either.
#ifdef WHATEVER
static const struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
.enter = omap2_pm_enter,
.end= omap2_pm_end,
.valid = suspend_valid_only_mem,
};
#define PM_OPS omap_pm_ops
#else
#define PM_OPS NULL
#endif
...
suspend_set_ops(PM_OPS);
That keeps it all nice and local, and you can see exactly what's going on
without having it spread across many different random files.
I don't think it's obviously better or simpler. There's already made a mistake
in
your example...
A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Current OMAP build failures
Russell, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Thursday, January 06, 2011 4:34 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Current OMAP build failures Have you used any custom build/ additional build flags for omap2/3/4 reported issues ? I just rebased Tony's 'omap-for-linus' branch with 2.6.37 and it not seems to report below issues. May be it's getting fixed as part of 2.6.38 omap queue or my build config is not same as yours. I used omap2plus_defconfig. === omap2 === arch/arm/plat-omap/devices.c:253: warning: │omap_init_wdt│ defined but not used arch/arm/mach-omap2/irq.c:64: warning: │intc_context│ defined but not used arch/arm/mach-omap2/prcm.c:122: warning: │prcm_context│ defined but not used Missing __maybe_unused or something else? These seems to be fixed in omap queue. It also comes with three section mismatches: WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices() The function omap_early_device_register() references the function __init early_platform_add_devices(). This is often because omap_early_device_register lacks a __init annotation or the annotation of early_platform_add_devices is wrong. As early_platform_add_devices() is marked __init, so too should be omap_early_device_register(). I don't see this one. May be fixed WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices() The function omap_device_build_ss() references the function __init early_platform_add_devices(). This is often because omap_device_build_ss lacks a __init annotation or the annotation of early_platform_add_devices is wrong. This looks like omap_early_device_register() has been inlined into omap_device_build_ss(), and it doesn't look like it can be marked __init. Rather than passing an 'is_early_device' into this function, split out the common code into a separate function which takes a function pointer to the registration function. Then you can have two additional functions, one marked __init which uses omap_early_device_register() and one not marked __init using omap_device_register(). This also means that we get the init-section type checking further up the chain. This too WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from the variable h4_config to the (unknown reference) .init.data:(unknown) The variable h4_config references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Maybe it shouldn't be marked __initdata? This too === omap3 === WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init() The function sdp3430_twl_gpio_setup() references the function __init omap2_hsmmc_init(). This is often because sdp3430_twl_gpio_setup lacks a __init annotation or the annotation of omap2_hsmmc_init is wrong. Missing __init on sdp3430_twl_gpio_setup ? This too WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices() The function omap_early_device_register() references the function __init early_platform_add_devices(). This is often because omap_early_device_register lacks a __init annotation or the annotation of early_platform_add_devices is wrong. As before. This too WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices() The function omap_device_build_ss() references the function __init early_platform_add_devices(). This is often because omap_device_build_ss lacks a __init annotation or the annotation of early_platform_add_devices is wrong. As before. This too WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe() The variable twl_driver references the function __init twl_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, twl_probe shouldn't be __init ? I only see the twl_probe section miss-match. Have attached full build log for reference. Regards, Santosh 2.6.37_omap_for_linus.tar.bz2 Description: Binary data
Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
On Thu, 2011-01-06 at 16:08 +0900, Paul Mundt wrote:
(Trying an alternate address for Richard, and adding Andrew to Cc..)
On Thu, Dec 09, 2010 at 02:41:50PM +0100, Janusz Krzysztofik wrote:
This patch extends the LED backlight tirgger driver with an option that
allows
for inverting the trigger output polarity.
With the invertion option provided, I (ab)use the backlight trigger for
driving a LED that indicates LCD display blank condtition on my Amstrad
Delta
videophone. Since the machine has no dedicated power LED, it was not
possible
to distinguish if the display was blanked, or the machine was turned off,
without touching it.
The invert sysfs control is patterned after a similiar function of the GPIO
trigger driver.
Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
Retested on linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Richard Purdie rpur...@rpsys.net
Acked-by: Richard Purdie richard.pur...@linuxfoundation.org
I'll let Andrew take the patch though.
---
Resent because I still can't see any response received, while yet another
merge window is going to pass away soon.
Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh.
Only
tried to clean up the commit message slightly - maybe my English is not
good
enough to bother with, if not the code?
v1 - v2 changes:
- improve some conditional expressions to be more readable; thanks to Ralph
Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
- refresh against linux-2.6.36-rc5.
drivers/leds/ledtrig-backlight.c | 60
---
1 file changed, 56 insertions(+), 4 deletions(-)
diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c
linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
--- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 2010-09-24
15:35:13.0 +0200
+++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03
15:59:49.0 +0200
@@ -26,6 +26,7 @@ struct bl_trig_notifier {
int brightness;
int old_status;
struct notifier_block notifier;
+ unsigned invert;
};
static int fb_notifier_callback(struct notifier_block *p,
@@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
struct led_classdev *led = n-led;
struct fb_event *fb_event = data;
int *blank = fb_event-data;
+ int new_status = *blank ? BLANK : UNBLANK;
switch (event) {
case FB_EVENT_BLANK :
- if (*blank n-old_status == UNBLANK) {
+ if (new_status == n-old_status)
+ break;
+
+ if ((n-old_status == UNBLANK) ^ n-invert) {
n-brightness = led-brightness;
led_set_brightness(led, LED_OFF);
- n-old_status = BLANK;
- } else if (!*blank n-old_status == BLANK) {
+ } else {
led_set_brightness(led, n-brightness);
- n-old_status = UNBLANK;
}
+
+ n-old_status = new_status;
+
break;
}
return 0;
}
+static ssize_t bl_trig_invert_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+
+ return sprintf(buf, %s\n, n-invert ? yes : no);
+}
+
+static ssize_t bl_trig_invert_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t num)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+ unsigned invert;
+ int ret;
+
+ ret = sscanf(buf, %u, invert);
+ if (ret 1) {
+ dev_err(dev, invalid value\n);
+ return -EINVAL;
+ }
+
+ n-invert = !!invert;
+
+ /* After inverting, we need to update the LED. */
+ if ((n-old_status == BLANK) ^ n-invert)
+ led_set_brightness(led, LED_OFF);
+ else
+ led_set_brightness(led, n-brightness);
+
+ return num;
+}
+static DEVICE_ATTR(invert, 0644, bl_trig_invert_show,
bl_trig_invert_store);
+
static void bl_trig_activate(struct led_classdev *led)
{
int ret;
@@ -66,6 +107,10 @@ static void bl_trig_activate(struct led_
return;
}
+ ret = device_create_file(led-dev, dev_attr_invert);
+ if (ret)
+ goto err_invert;
+
n-led = led;
n-brightness = led-brightness;
n-old_status = UNBLANK;
@@ -74,6 +119,12 @@ static void bl_trig_activate(struct led_
ret = fb_register_client(n-notifier);
if (ret)
dev_err(led-dev, unable to register backlight trigger\n);
+
+ return;
+
+err_invert:
+ led-trigger_data = NULL;
+ kfree(n);
}
Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public ML
as well.
shweta.gul...@ti.com wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulatishweta.gul...@ti.com
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
---
The patch is generated on top of Kevin's PM branch. It's needed for SR
functionality on the current pm branch. Have tested SR with this patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, 110),
+ OPP_INITIALIZER(mpu, true, 3, 93),
/* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, 120),
+ OPP_INITIALIZER(mpu, true, 6, 110),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, 126),
+ OPP_INITIALIZER(mpu, true, 8, 126),
I disagree. This is not $subject. Also - not all boards will be capable
of supporting all higher frequencies rt? - remember the 3630 experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
/* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 100800, 135),
+ OPP_INITIALIZER(mpu, true, 100800, 135),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1, 93),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
Kevin Hilman wrote, on 01/05/2011 05:28 PM:
Nishanth Menonn...@ti.com writes:
Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz
OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely.
For the moment, we tweak the default table to allow for 800Mhz OPP usage.
Isn't this common to any board using 3730 (or 3630?)
no it is not. only certain boards are capable of higher frequencies -
there is a procedure called PDN analysis and vmin search that needs to
be performed to guarentee this.
IOW, what is Beagle specific about this?
beagle is one of the boards capable of higher frequencies.
Kevin
Reported-by: Koen Kooik...@beagleboard.org
Tested-by: Koen Kooik...@beagleboard.org
Signed-off-by: Nishanth Menonn...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..0b99b80 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -23,6 +23,7 @@
#includelinux/gpio.h
#includelinux/input.h
#includelinux/gpio_keys.h
+#includelinux/opp.h
#includelinux/mtd/mtd.h
#includelinux/mtd/partitions.h
@@ -44,10 +45,12 @@
#includeplat/gpmc.h
#includeplat/nand.h
#includeplat/usb.h
+#includeplat/omap_device.h
#include mux.h
#include hsmmc.h
#include timer-gp.h
+#include pm.h
#define NAND_BLOCK_SIZE SZ_128K
@@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
+static void __init beagle_opp_init(void)
+{
+ int r = 0;
+
+ /* Initialize the omap3 opp table */
+ if (omap3_opp_init()) {
+ pr_err(%s: opp default init failed\n, __func__);
+ return;
+ }
+
+ /* Custom OPP enabled for XM */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *dh = omap_hwmod_lookup(iva);
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mh, dh);
+ r = -EINVAL;
+ } else {
+ /* Enable MPU 1GHz and lower opps */
+ dev =mh-od-pdev.dev;
+ r = opp_enable(dev, 8);
+ /* TODO: MPU 1GHz needs SR and ABB */
+
+ /* Enable IVA 800MHz and lower opps */
+ dev =dh-od-pdev.dev;
+ r |= opp_enable(dev, 66000);
+ /* TODO: DSP 800MHz needs SR and ABB */
+ }
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+ dev =mh-od-pdev.dev;
+ opp_disable(dev, 8);
+ dev =dh-od-pdev.dev;
+ opp_disable(dev, 66000);
+ }
+ }
+}
+
static void __init omap3_beagle_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
beagle_display_init();
+ beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Errors when building for omap4 only
Hi all,
I was trying to build OMAP4 only kernel from the linux-omap master.
Came across few failures caused by exclusion of OMAP3/3 specific code via
#ifdef.
My repo is at:
commit fa3b4e23ec20cfc944db7cc2b30b0d82c20e4472
Author: Tony Lindgren t...@atomide.com
Date: Thu Dec 30 12:47:00 2010 -0800
cbus: Fix retu_rtc_do_reset
Sharing my observations here, before I send formal patch(es).
1) Starting with omap2plus_defconfig, removed the OMAP2 and OMAP3
from the build leads to these errors during compilation:
CC arch/arm/mach-omap2/clockdomain.o
arch/arm/mach-omap2/clockdomain.c: In function '_enable_hwsup':
arch/arm/mach-omap2/clockdomain.c:251: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:254: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function '_disable_hwsup':
arch/arm/mach-omap2/clockdomain.c:277: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:280: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_sleep':
arch/arm/mach-omap2/clockdomain.c:744: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_wakeup':
arch/arm/mach-omap2/clockdomain.c:789: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_enable':
arch/arm/mach-omap2/clockdomain.c:922: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:926: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c: In function 'omap2_clkdm_clk_disable':
arch/arm/mach-omap2/clockdomain.c:994: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
arch/arm/mach-omap2/clockdomain.c:998: error: 'struct clockdomain' has no
member named 'clktrctrl_mask'
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
This patch fixes these errors:
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index de3faa2..9b459c2 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -103,9 +103,7 @@ struct clockdomain {
const char *name;
struct powerdomain *ptr;
} pwrdm;
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
const u16 clktrctrl_mask;
-#endif
const u8 flags;
const u8 dep_bit;
const u8 prcm_partition;
2) With this patch compilation moves ahead, but fails at linker stage with
these errors:
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/pm-debug.c:335:
undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/pm-debug.c:121:
undefined reference to `omap2_prm_read_mod_reg'
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/pm-debug.c:123:
undefined reference to `omap2_prm_read_mod_reg'
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/pm-debug.c:124:
undefined reference to `omap2_prm_read_mod_reg'
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/pm-debug.c:125:
undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap_prcm_arch_reset':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/prcm.c:106:
undefined reference to `omap2_prm_set_mod_reg_bits'
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/prcm.c:108:
undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `omap_prcm_get_reset_sources':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/prcm.c:53:
undefined reference to `omap2_prm_read_mod_reg'
arch/arm/mach-omap2/built-in.o: In function `clkdm_clear_all_wkdeps':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/clockdomain.c:545:
undefined reference to `omap2_prm_clear_mod_reg_bits'
arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/clockdomain.c:475:
undefined reference to `omap2_prm_clear_mod_reg_bits'
arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/clockdomain.c:511:
undefined reference to `omap2_prm_read_mod_bits_shift'
arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep':
/db/psp_git/users/a0756819/linux-omap-2.6/arch/arm/mach-omap2/clockdomain.c:440:
undefined reference to `omap2_prm_set_mod_reg_bits'
make: *** [.tmp_vmlinux1] Error 1
This patch is required to fix these errors:
diff
Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven: Kevin Hilman wrote, on 01/05/2011 05:28 PM: Nishanth Menonn...@ti.com writes: Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely. For the moment, we tweak the default table to allow for 800Mhz OPP usage. Isn't this common to any board using 3730 (or 3630?) no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this. What about the new 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work: r...@usrp-e1xx:~# cpufreq-set -f 72 [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 But: r...@usrp-e1xx:~# dmesg | grep 720 [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp 720mhz ) [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=720 vram=16M mem=...@0x8000 mem=3...@0x8800 omapfb.mode=dvi:1024x768mr...@60 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] overo_opp_init: 720MHz MPU OPPs enabled! [0.00] Switched to new clocking rate (Crystal/Core/MPU): 26.0/224/720 MHz r...@usrp-e1xx:~# cpufreq-info cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: omap CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 125 MHz - 720 MHz available frequency steps: 125 MHz, 250 MHz, 500 MHz, 550 MHz, 600 MHz, 720 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 125 MHz and 720 MHz. The governor userspace may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). cpufreq stats: 125 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 550 MHz:0.00%, 600 MHz:100.00%, 720 MHz:0.00% (1) So how do I properly get 720MHz on those parts? regards, Koen 0001-omap3-add-support-for-720MHz-MPU-OPP.patch Description: Binary data 0002-OMAP35x-Add-support-for-720MHz-part.patch Description: Binary data 0003-OMAP3-beagle-C4-enable-upto-720MHz-OPP.patch Description: Binary data 0004-OMAP3-Overo-Tide-enable-upto-720MHz-OPP.patch Description: Binary data
OMAP3 and OMAP4 M-Shield Mobile Security Technology with linux-omap
Dear list members, I haven't found the information if linux can use the M-Shield HW, do you know this? I have seen the official page http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123navigationId=12316contentId=4629DCMP=WTBUHQS=Other+EM+m-shield but I haven't seen which with SW does this technology is able to use. I'am new to OMAP ;-) Thanks for help BR Aleks -- 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 v8 0/11] dmtimer adaptation to platform_driver
Kevin, [...] Also, testing with PM on 34xx/n900, I noticed that this series prevents PER and CORE from hitting retention during suspend. I haven't debugged why yet. I have not done power testing. I will try this out right away and confirm. Here is a brief update on pm test. (1) Without dmtimer patch series: [ 305.641204] Powerdomain (core_pwrdm) didn't enter target state 1 [ 305.647491] Could not enter target state in pm_suspend (2) With dmtimer patch series: [ 25.291503] Powerdomain (core_pwrdm) didn't enter target state 1 [ 25.297790] Powerdomain (per_pwrdm) didn't enter target state 1 [ 25.303985] Could not enter target state in pm_suspend I will debug further. -- Tarun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
Koen Kooi had written, on 01/06/2011 07:00 AM, the following: Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven: Kevin Hilman wrote, on 01/05/2011 05:28 PM: Nishanth Menonn...@ti.com writes: Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely. For the moment, we tweak the default table to allow for 800Mhz OPP usage. Isn't this common to any board using 3730 (or 3630?) no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this. What about the new 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work: for 3530, keep in mind that not *all* boards can support 720MHz (esp the old 3430 boards, like my poor SDP3430). since we consider 3530 as 3430 as well, add a default disabled 720MHz OPP in the 3430 table and enable it: a) if this has anything to do with board behavior (which, unlike 36xx, I dont think is the case for 35xx), enable similar to this patch on the required boards on a need basis (e.g. based on board rev) b) if this is a silicon behavior, then, you should modify the omap3_opp_init to ensure that for the right silicon this is enabled (e.g. only for 3530 rev X onwards or something similar) - but you will need some way to detect it in s/w (not through bootargs please!) r...@usrp-e1xx:~# cpufreq-set -f 72 [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 This is coz we dont have 720MHz and max enabled freq is 600MHz so it falls back to that freq. But: r...@usrp-e1xx:~# dmesg | grep 720 [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp 720mhz ) [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=720 vram=16M mem=...@0x8000 mem=3...@0x8800 omapfb.mode=dvi:1024x768mr...@60 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] overo_opp_init: 720MHz MPU OPPs enabled! [0.00] Switched to new clocking rate (Crystal/Core/MPU): 26.0/224/720 MHz r...@usrp-e1xx:~# cpufreq-info cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: omap CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 125 MHz - 720 MHz available frequency steps: 125 MHz, 250 MHz, 500 MHz, 550 MHz, 600 MHz, 720 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 125 MHz and 720 MHz. The governor userspace may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). cpufreq stats: 125 MHz:0.00%, 250 MHz:0.00%, 500 MHz:0.00%, 550 MHz:0.00%, 600 MHz:100.00%, 720 MHz:0.00% (1) So how do I properly get 720MHz on those parts? as discussed above. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Errors when building for omap4 only
Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Thursday, January 06, 2011 6:18 PM To: linux-omap Mailing List Subject: Errors when building for omap4 only Hi all, I was trying to build OMAP4 only kernel from the linux-omap master. Came across few failures caused by exclusion of OMAP3/3 specific code via #ifdef. These are addressed already. You could look at below series http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.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
LCD driver
Hi, Plz let me know the location of LCD panel driver for OMAP3 EVM (AM37xx EVM). Iam using the latest 2.6 kernel. thanks kalyan alle -- 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: Errors when building for omap4 only
-Original Message- From: Shilimkar, Santosh Sent: Thursday, January 06, 2011 7:19 PM To: Premi, Sanjeev; linux-omap Mailing List Subject: RE: Errors when building for omap4 only Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Thursday, January 06, 2011 6:18 PM To: linux-omap Mailing List Subject: Errors when building for omap4 only Hi all, I was trying to build OMAP4 only kernel from the linux-omap master. Came across few failures caused by exclusion of OMAP3/3 specific code via #ifdef. These are addressed already. You could look at below series http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.html Great! I missed the series. Question (after quick browse): Don't addition stubs add too many strings to the code? ~sanjeev-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
On Thu, Jan 06, 2011 at 12:05:51PM +, aaro.koski...@nokia.com wrote:
Hi,
Russell King - ARM Linux [li...@arm.linux.org.uk]:
-static struct platform_suspend_ops omap_pm_ops = {
- .begin = omap2_pm_begin,
- .enter = omap2_pm_enter,
- .end= omap2_pm_end,
- .valid = suspend_valid_only_mem,
+static const struct platform_suspend_ops omap_pm_ops[] = {
+ {
+ .begin = omap2_pm_begin,
+ .enter = omap2_pm_enter,
+ .end= omap2_pm_end,
+ .valid = suspend_valid_only_mem,
+ }
};
-#else
-static const struct platform_suspend_ops __initdata omap_pm_ops;
#endif /* CONFIG_SUSPEND */
/* XXX This function should be shareable between OMAP2xxx and OMAP3 */
@@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
omap24xx_cpu_suspend_sz);
}
- suspend_set_ops(omap_pm_ops);
+ suspend_set_ops(omap_pm_ops);
Utterly yuck. Declaring it as a single element array just to avoid an
ifdef. That's worse than having an ifdef here.
Why it is worse? Reducing the amount of different preprocessor branches will
result in better compile test / static analysis coverage.
You're not doing that. You're just spreading the yuck around making it
far worse:
- in some header file
#ifndef CONFIG_FOO
#define omap_pm_ops NULL
#endif
- in lots of C files
#ifdef CONFIG_FOO
static const struct platform_suspend_ops omap_pm_ops[] = {
{
...
}
};
#endif
suspend_set_ops(omap_pm_ops);
So, rather than just having the full story in each file, it's spread
across two files. Not only that, but over time CONFIG_FOO will probably
change, and that will lead to compile errors.
You're creating an array just to be able to use the symbol as a pointer.
That's a hack rather than an elegant solution.
So no, your implementation is _NOT_ a sane approach.
I'm going to explicitly say NAK to your patch here and now. I really
don't like it one bit. It's a complete hack through and through, and
that hack is spread across many files.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, January 06, 2011 7:15 PM To: Koen Kooi Cc: Hilman, Kevin; l-o; l-a; Tony Subject: Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP Koen Kooi had written, on 01/06/2011 07:00 AM, the following: Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven: Kevin Hilman wrote, on 01/05/2011 05:28 PM: Nishanth Menonn...@ti.com writes: Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely. For the moment, we tweak the default table to allow for 800Mhz OPP usage. Isn't this common to any board using 3730 (or 3630?) no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this. What about the new 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=ko en/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work: for 3530, keep in mind that not *all* boards can support 720MHz (esp the old 3430 boards, like my poor SDP3430). since we consider 3530 as 3430 as well, add a default disabled 720MHz OPP in the 3430 table and enable it: a) if this has anything to do with board behavior (which, unlike 36xx, I dont think is the case for 35xx), enable similar to this patch on the required boards on a need basis (e.g. based on board rev) b) if this is a silicon behavior, then, you should modify the omap3_opp_init to ensure that for the right silicon this is enabled (e.g. only for 3530 rev X onwards or something similar) - but you will need some way to detect it in s/w (not through bootargs please!) Nishanth, Some of the patches generic that Koen attached are based on my submissions. As part of migration to 2.6.37, I am in process of validating them on internal integration tree. Will post them soon... may be end of tomorrow. I will be testing them on OMAP3EVM. ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] OMAP4: DMIC: Add DMIC codec platform devices
This creates the DMIC codec platform devices.
The platform devices create an instance of the driver during boot up.
Signed-off-by: David Lambert dlamb...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..e7745cf 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -505,6 +505,16 @@ static void __init omap_sfh7741prox_init(void)
}
}
+static struct platform_device codec_dmic0 = {
+ .name = dmic-codec,
+ .id = -1,
+};
+
+static inline void omap_dmic_init(void)
+{
+ platform_device_register(codec_dmic0);
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
@@ -528,6 +538,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_dmic_init();
}
static void __init omap_4430sdp_map_io(void)
--
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 v2 0/4] Adding OMAP DMIC driver to kernel
This is a patch series to add the OMAP Digital Microphone driver for OMAP4. It includes the driver, a generic DMIC codec, platform devices, as well as HWMOD entries for OMAP44xx chipsets. David Lambert (4): ASoC: DMIC: Adding the OMAP DMIC driver ASoC: DMIC codec: Adding a generic DMIC codec OMAP4: hwmod: add entries for DMIC driver OMAP4: DMIC: Add DMIC codec platform devices arch/arm/mach-omap2/board-4430sdp.c| 11 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 91 + arch/arm/plat-omap/devices.c | 35 ++ arch/arm/plat-omap/include/plat/dmic.h | 82 sound/soc/codecs/Kconfig |3 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/dmic.c| 81 sound/soc/omap/Kconfig |4 + sound/soc/omap/Makefile|2 + sound/soc/omap/omap-dmic.c | 553 10 files changed, 864 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/dmic.h create mode 100644 sound/soc/codecs/dmic.c create mode 100644 sound/soc/omap/omap-dmic.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] OMAP4: hwmod: add entries for DMIC driver
Adds HWMOD entries for the OMAP DMIC driver and creates
a platform device. The HWMOD entires define the system
resource requirements for the drvier such as DMA addresses, channels,
and IRQ's. Placing this information in the HWMOD database allows
for more generic drivers to be written and having the specific
implementation details defined in HWMOD.
Signed-off-by: David Lambert dlamb...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 91
arch/arm/plat-omap/devices.c | 35 +++
2 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7274db4..f9b2ad3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -383,6 +383,95 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
};
/*
+ * 'dmic' class
+ * digital microphone controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dmic_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_dmic_hwmod_class = {
+ .name = omap-dmic,
+ .sysc = omap44xx_dmic_sysc,
+};
+
+/* dmic */
+static struct omap_hwmod omap44xx_dmic_hwmod;
+static struct omap_hwmod_irq_info omap44xx_dmic_irqs[] = {
+ { .irq = 114 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_dmic_sdma_reqs[] = {
+ { .dma_req = 66 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dmic_addrs[] = {
+ {
+ .pa_start = 0x4012e000,
+ .pa_end = 0x4012e07f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - dmic */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_dmic_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_dmic_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dmic_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_dmic_dma_addrs[] = {
+ {
+ .pa_start = 0x4902e000,
+ .pa_end = 0x4902e07f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - dmic (dma) */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic_dma = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_dmic_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_dmic_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dmic_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* dmic slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dmic_slaves[] = {
+ omap44xx_l4_abe__dmic,
+ omap44xx_l4_abe__dmic_dma,
+};
+
+static struct omap_hwmod omap44xx_dmic_hwmod = {
+ .name = omap-dmic,
+ .class = omap44xx_dmic_hwmod_class,
+ .mpu_irqs = omap44xx_dmic_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dmic_irqs),
+ .sdma_reqs = omap44xx_dmic_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dmic_sdma_reqs),
+ .main_clk = dmic_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM1_ABE_DMIC_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_dmic_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_dmic_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
* 'mpu_bus' class
* instance(s): mpu_private
*/
@@ -826,6 +915,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_l4_cfg_hwmod,
omap44xx_l4_per_hwmod,
omap44xx_l4_wkup_hwmod,
+ /* dmic class */
+ omap44xx_dmic_hwmod,
/* mpu_bus class */
omap44xx_mpu_private_hwmod,
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index fc81912..b347f75 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -72,6 +72,40 @@ void omap_mcbsp_register_board_cfg(struct
omap_mcbsp_platform_data *config,
/*-*/
+#if defined(CONFIG_SND_OMAP_SOC_DMIC) || \
+ defined(CONFIG_SND_OMAP_SOC_DMIC_MODULE)
+
+static struct omap_device_pm_latency omap_dmic_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static void omap_init_dmic(void)
+{
+ struct
[PATCH v2 2/4] ASoC: DMIC codec: Adding a generic DMIC codec
This codec is to be used by the DMIC driver to
control the DMIC codec. This driver will be used on future
implementations of the DMIC driver to support codec specific
features.
At this time, the codec driver just registers the codec DAI.
Signed-off-by: David Lambert dlamb...@ti.com
---
sound/soc/codecs/Kconfig |3 ++
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/dmic.c | 81 +
3 files changed, 86 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/dmic.c
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0f33db2..f6c6d31 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -166,6 +166,9 @@ config SND_SOC_L3
config SND_SOC_DA7210
tristate
+config SND_SOC_DMIC
+ tristate
+
config SND_SOC_MAX98088
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 10e5e09..9139cf9 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -14,6 +14,7 @@ snd-soc-cs42l51-objs := cs42l51.o
snd-soc-cs4270-objs := cs4270.o
snd-soc-cx20442-objs := cx20442.o
snd-soc-da7210-objs := da7210.o
+snd-soc-dmic-objs := dmic.o
snd-soc-l3-objs := l3.o
snd-soc-max98088-objs := max98088.o
snd-soc-pcm3008-objs := pcm3008.o
@@ -91,6 +92,7 @@ obj-$(CONFIG_SND_SOC_CS42L51) += snd-soc-cs42l51.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o
obj-$(CONFIG_SND_SOC_DA7210) += snd-soc-da7210.o
+obj-$(CONFIG_SND_SOC_DMIC) += snd-soc-dmic.o
obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o
obj-$(CONFIG_SND_SOC_MAX98088) += snd-soc-max98088.o
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
new file mode 100644
index 000..57e9dac
--- /dev/null
+++ b/sound/soc/codecs/dmic.c
@@ -0,0 +1,81 @@
+/*
+ * dmic.c -- SoC audio for Generic Digital MICs
+ *
+ * Author: Liam Girdwood l...@slimlogic.co.uk
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/platform_device.h
+#include linux/slab.h
+#include sound/core.h
+#include sound/pcm.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+
+static struct snd_soc_dai_driver dmic_dai = {
+ .name = dmic-hifi,
+ .capture = {
+ .stream_name = Capture,
+ .channels_min = 1,
+ .channels_max = 8,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS,
+ .formats = SNDRV_PCM_FMTBIT_S32_LE
+ | SNDRV_PCM_FMTBIT_S24_LE
+ | SNDRV_PCM_FMTBIT_S16_LE,
+ },
+};
+
+static struct snd_soc_codec_driver soc_dmic = {};
+
+static int __devinit dmic_dev_probe(struct platform_device *pdev)
+{
+ return snd_soc_register_codec(pdev-dev,
+ soc_dmic, dmic_dai, 1);
+}
+
+static int __devexit dmic_dev_remove(struct platform_device *pdev)
+{
+ snd_soc_unregister_codec(pdev-dev);
+ return 0;
+}
+
+MODULE_ALIAS(platform:dmic-codec);
+
+static struct platform_driver dmic_driver = {
+ .driver = {
+ .name = dmic-codec,
+ .owner = THIS_MODULE,
+ },
+ .probe = dmic_dev_probe,
+ .remove = __devexit_p(dmic_dev_remove),
+};
+
+static int __init dmic_init(void)
+{
+ return platform_driver_register(dmic_driver);
+}
+module_init(dmic_init);
+
+static void __exit dmic_exit(void)
+{
+ platform_driver_unregister(dmic_driver);
+}
+module_exit(dmic_exit);
+
+MODULE_DESCRIPTION(Generic DMIC driver);
+MODULE_AUTHOR(Liam Girdwood l...@slimlogic.co.uk);
+MODULE_LICENSE(GPL);
--
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 v2 1/4] ASoC: DMIC: Adding the OMAP DMIC driver
This patch adds support for the OMAP4 digital microphone DAI. This DAI can support support recording in 2, 4, or 6 channels When provided with a 19.2Mhz functional clock, can encode at 96Khz or 192Khz (all channels must have the same sample rate). Details of the hardware interface can be found in the OMAP4 TRM in Section 23.7 Signed-off-by: David Lambert dlamb...@ti.com --- arch/arm/plat-omap/include/plat/dmic.h | 82 + sound/soc/omap/Kconfig |4 + sound/soc/omap/Makefile|2 + sound/soc/omap/omap-dmic.c | 553 4 files changed, 641 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/dmic.h create mode 100644 sound/soc/omap/omap-dmic.c diff --git a/arch/arm/plat-omap/include/plat/dmic.h b/arch/arm/plat-omap/include/plat/dmic.h new file mode 100644 index 000..a72e080 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/dmic.h @@ -0,0 +1,82 @@ +/* + * omap-dmic.h -- OMAP Digital Microphone Controller + * + * Author: Liam Girdwood l...@slimlogic.co.uk + *David Lambert dlamb...@ti.com + *Misael Lopez Cruz misael.lo...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ASM_ARCH_OMAP_DMIC_H +#define __ASM_ARCH_OMAP_DMIC_H + +#define OMAP44XX_DMIC_L3_BASE 0x4902e000 + +#define OMAP_DMIC_REVISION 0x00 +#define OMAP_DMIC_SYSCONFIG0x10 +#define OMAP_DMIC_IRQSTATUS_RAW0x24 +#define OMAP_DMIC_IRQSTATUS0x28 +#define OMAP_DMIC_IRQENABLE_SET0x2C +#define OMAP_DMIC_IRQENABLE_CLR0x30 +#define OMAP_DMIC_IRQWAKE_EN 0x34 +#define OMAP_DMIC_DMAENABLE_SET0x38 +#define OMAP_DMIC_DMAENABLE_CLR0x3C +#define OMAP_DMIC_DMAWAKEEN0x40 +#define OMAP_DMIC_CTRL 0x44 +#define OMAP_DMIC_DATA 0x48 +#define OMAP_DMIC_FIFO_CTRL0x4C +#define OMAP_DMIC_FIFO_DMIC1R_DATA 0x50 +#define OMAP_DMIC_FIFO_DMIC1L_DATA 0x54 +#define OMAP_DMIC_FIFO_DMIC2R_DATA 0x58 +#define OMAP_DMIC_FIFO_DMIC2L_DATA 0x5C +#define OMAP_DMIC_FIFO_DMIC3R_DATA 0x60 +#define OMAP_DMIC_FIFO_DMIC3L_DATA 0x64 + +/* + * DMIC_IRQ bit fields + * IRQSTATUS_RAW, IRQSTATUS, IRQENABLE_SET, IRQENABLE_CLR + */ + +#define OMAP_DMIC_IRQ (1 0) +#define OMAP_DMIC_IRQ_FULL (1 1) +#define OMAP_DMIC_IRQ_ALMST_EMPTY (1 2) +#define OMAP_DMIC_IRQ_EMPTY(1 3) +#define OMAP_DMIC_IRQ_MASK 0x07 + +/* + * DMIC_DMAENABLE bit fields + */ + +#define OMAP_DMIC_DMA_ENABLE 0x1 + +/* + * DMIC_CTRL bit fields + */ + +#define OMAP_DMIC_UP1_ENABLE 0x0001 +#define OMAP_DMIC_UP2_ENABLE 0x0002 +#define OMAP_DMIC_UP3_ENABLE 0x0004 +#define OMAP_DMIC_FORMAT 0x0008 +#define OMAP_DMIC_POLAR1 0x0010 +#define OMAP_DMIC_POLAR2 0x0020 +#define OMAP_DMIC_POLAR3 0x0040 +#define OMAP_DMIC_POLAR_MASK 0x0070 +#define OMAP_DMIC_CLK_DIV_SHIFT7 +#define OMAP_DMIC_CLK_DIV_MASK 0x0380 +#defineOMAP_DMIC_RESET 0x0400 + +#define OMAP_DMIC_ENABLE_MASK 0x007 + +#define OMAP_DMICOUTFORMAT_LJUST (0 3) +#define OMAP_DMICOUTFORMAT_RJUST (1 3) + +/* + * DMIC_FIFO_CTRL bit fields + */ + +#define OMAP_DMIC_THRES_MAX0xF + +#endif diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index a088db6..fe40488 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -9,6 +9,9 @@ config SND_OMAP_SOC_MCBSP config SND_OMAP_SOC_MCPDM tristate +config SND_OMAP_SOC_DMIC + tristate + config SND_OMAP_SOC_N810 tristate SoC Audio support for Nokia N810 depends on SND_OMAP_SOC MACH_NOKIA_N810 I2C @@ -103,6 +106,7 @@ config SND_OMAP_SOC_SDP4430 depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP select SND_OMAP_SOC_MCPDM select SND_SOC_TWL6040 + select SND_SOC_DMIC help Say Y if you want to add support for SoC audio on Texas Instruments SDP4430. diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index ba9fc65..6ff27f5 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -1,9 +1,11 @@ # OMAP Platform Support snd-soc-omap-objs := omap-pcm.o +snd-soc-omap-dmic-objs := omap-dmic.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o snd-soc-omap-mcpdm-objs := omap-mcpdm.o mcpdm.o obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o +obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c new
Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
Premi, Sanjeev had written, on 01/06/2011 07:58 AM, the following: [..] Some of the patches generic that Koen attached are based on my submissions. As part of migration to 2.6.37, I am in process of validating them on internal integration tree. Will post them soon... may be end of tomorrow. I will be testing them on OMAP3EVM. Sure. please do post them to l-o and cc l-a - I suppose until then, they are unofficial if they are lying around in some private tree(even if viewable over internet ;) ). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
Op 6 jan 2011, om 14:44 heeft Nishanth Menon het volgende geschreven: Koen Kooi had written, on 01/06/2011 07:00 AM, the following: Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven: Kevin Hilman wrote, on 01/05/2011 05:28 PM: Nishanth Menonn...@ti.com writes: Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely. For the moment, we tweak the default table to allow for 800Mhz OPP usage. Isn't this common to any board using 3730 (or 3630?) no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this. What about the new 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work: for 3530, keep in mind that not *all* boards can support 720MHz (esp the old 3430 boards, like my poor SDP3430). Right, that's why it's a different SKU and we can probe for it, see the 0002 patch I attached. since we consider 3530 as 3430 as well, add a default disabled 720MHz OPP in the 3430 table That's what 0001 does :) and enable it: a) if this has anything to do with board behavior (which, unlike 36xx, I dont think is the case for 35xx), enable similar to this patch on the required boards on a need basis (e.g. based on board rev) That's what 0003 and 0004 are doing for overo and beagle b) if this is a silicon behavior, then, you should modify the omap3_opp_init to ensure that for the right silicon this is enabled (e.g. only for 3530 rev X onwards or something similar) - but you will need some way to detect it in s/w (not through bootargs please!) See 0002, it does it as an omap feature. r...@usrp-e1xx:~# cpufreq-set -f 72 [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 This is coz we dont have 720MHz and max enabled freq is 600MHz so it falls back to that freq. Even after 0001 adds it to the table and 0004 enables it? regards, Koen-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Errors when building for omap4 only
-Original Message- From: Premi, Sanjeev [mailto:pr...@ti.com] Sent: Thursday, January 06, 2011 7:26 PM To: Shilimkar, Santosh; linux-omap Mailing List Subject: RE: Errors when building for omap4 only -Original Message- From: Shilimkar, Santosh Sent: Thursday, January 06, 2011 7:19 PM To: Premi, Sanjeev; linux-omap Mailing List Subject: RE: Errors when building for omap4 only Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Thursday, January 06, 2011 6:18 PM To: linux-omap Mailing List Subject: Errors when building for omap4 only Hi all, I was trying to build OMAP4 only kernel from the linux-omap master. Came across few failures caused by exclusion of OMAP3/3 specific code via #ifdef. These are addressed already. You could look at below series http://www.mail-archive.com/linux- o...@vger.kernel.org/msg41712.html Great! I missed the series. Question (after quick browse): Don't addition stubs add too many strings to the code? They do. But we want these functions to throw warning when they are used on wrong SOCS. So that wrong usage is avoided and if exist can be killed. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
Koen Kooi had written, on 01/06/2011 08:01 AM, the following: Op 6 jan 2011, om 14:44 heeft Nishanth Menon het volgende geschreven: Koen Kooi had written, on 01/06/2011 07:00 AM, the following: Op 6 jan 2011, om 13:24 heeft Nishanth Menon het volgende geschreven: Kevin Hilman wrote, on 01/05/2011 05:28 PM: Nishanth Menonn...@ti.com writes: Beagle XM uses 3730 and the board design allows enabling 800MHz and 1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz safely. For the moment, we tweak the default table to allow for 800Mhz OPP usage. Isn't this common to any board using 3730 (or 3630?) no it is not. only certain boards are capable of higher frequencies - there is a procedure called PDN analysis and vmin search that needs to be performed to guarentee this. What about the new 3530s that can run at 720MHz? Those have been speed binned and given a different SKU. I'm using the attached 4 patches (Tony master + beagle patches _+ dvfs: http://dominion.thruhere.net/git/cgit.cgi/linux-omap/log/?h=koen/beagle-next) on my beagle C4 and overo tide to get 720MHz. They don't really work: for 3530, keep in mind that not *all* boards can support 720MHz (esp the old 3430 boards, like my poor SDP3430). Right, that's why it's a different SKU and we can probe for it, see the 0002 patch I attached. please discuss with Sanjeev on patch ownership and post required series using git send-email :) since we consider 3530 as 3430 as well, add a default disabled 720MHz OPP in the 3430 table That's what 0001 does :) and enable it: a) if this has anything to do with board behavior (which, unlike 36xx, I dont think is the case for 35xx), enable similar to this patch on the required boards on a need basis (e.g. based on board rev) That's what 0003 and 0004 are doing for overo and beagle then it is wrong. see below b) if this is a silicon behavior, then, you should modify the omap3_opp_init to ensure that for the right silicon this is enabled (e.g. only for 3530 rev X onwards or something similar) - but you will need some way to detect it in s/w (not through bootargs please!) See 0002, it does it as an omap feature. if it is OMAP feature, you should be doing this in omap3_opp_init instead of each and every board file! (basically patches 3 and 4 are wrong!). r...@usrp-e1xx:~# cpufreq-set -f 72 [ 104.976318] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 104.986236] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 [ 104.996032] platform iva.0: omap_voltage_scale: Already at the requestedrate 43000 [ 105.006408] platform mpu.0: omap_voltage_scale: Already at the requestedrate 6 This is coz we dont have 720MHz and max enabled freq is 600MHz so it falls back to that freq. Even after 0001 adds it to the table and 0004 enables it? a) have you checked if the clock framework has the required bits? b) voltage layer maintains it's own voltage table as well (surprise :D).. so you need to add to that as well! see the secret table in arch/arm/mach-omap2/voltage.c - I prefer all voltage and frequency information to be in a centralized location to prevent mess like this from happening, but sorry we gotta merge these two tables at some point ahead IMHO, we are not there yet. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
-Original Message- From: Menon, Nishanth Sent: Thursday, January 06, 2011 7:31 PM To: Premi, Sanjeev Cc: Koen Kooi; Hilman, Kevin; l-o; l-a; Tony Subject: Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP Premi, Sanjeev had written, on 01/06/2011 07:58 AM, the following: [..] Some of the patches generic that Koen attached are based on my submissions. As part of migration to 2.6.37, I am in process of validating them on internal integration tree. Will post them soon... may be end of tomorrow. I will be testing them on OMAP3EVM. Sure. please do post them to l-o and cc l-a - I suppose until then, they are unofficial if they are lying around in some private tree(even if viewable over internet ;) ). That's what I meant by submitting :) My plans were tomorrow/MON - wasn't expecting this thread to happen!! ~sanjeev -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
-Original Message-
From: Premi, Sanjeev [mailto:pr...@ti.com]
Sent: Thursday, January 06, 2011 8:03 PM
To: Shilimkar, Santosh; linux-omap@vger.kernel.org
Cc: Hilman, Kevin; t...@atomide.com; linux-arm-
ker...@lists.infradead.org; Shilimkar, Santosh; Paul Walmsley
Subject: RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
for undefined reference to 'omap2_prm_read_mod_reg'
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Santosh Shilimkar
Sent: Wednesday, January 05, 2011 4:27 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh;
Paul Walmsley
Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break
fix for undefined reference to 'omap2_prm_read_mod_reg'
[snip]
#ifndef __ASSEMBLER__
-
+/*
+ * Stub omap2xxx/omap3xxx functions so that common files
+ * continue to build when custom builds are used
+ */
+#if defined(CONFIG_ARCH_OMAP4)
!(defined(CONFIG_ARCH_OMAP2) || \
+ defined(CONFIG_ARCH_OMAP3))
+static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN_ONCE(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
Looking forward, the warning of incorrect SOC may be required
for when kernel is build for one specific SOC.
Wouldn't it be easy/better to have common global function:
void wrong_soc(char* func, int soc_id)
{
WARN_ONCE(1, Function %s cannot be used for %d, func,
soc_id);
}
OR we could have soc specific functions e.g.
void omap2xxx_only (char* func)
{
WARN_ONCE(1, Function %s is specific to OMAP2XXX);
}
..etc..
Later these functions can be called from the stubs.
This is prelim idea, will need to be worked upon.
Not sure. May appear like over engineering considering it's a
stub.
Paul can comment.
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 5:52 PM
To: Gulati, Shweta
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public ML
as well.
shweta.gul...@ti.com wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulatishweta.gul...@ti.com
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
---
The patch is generated on top of Kevin's PM branch. It's needed for SR
functionality on the current pm branch. Have tested SR with this patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, 110),
+ OPP_INITIALIZER(mpu, true, 3, 93),
/* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, 120),
+ OPP_INITIALIZER(mpu, true, 6, 110),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
Actually no. The latest voltage layer pushed uses these voltages. Also
We have been having this setting in the internal android code base for
some time now without anybody having issues. So till the new voltages
are conveyed officially, these remain the official voltage.
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, 126),
+ OPP_INITIALIZER(mpu, true, 8, 126),
I disagree. This is not $subject. Also - not all boards will be capable
of supporting all higher frequencies rt? - remember the 3630 experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
I am not sure about this for OMAP4. Have you come across a board
where these OPPs cannot be supported? We have been enabling these
OPPs internally now for quite some time across all OMAP4 boards.
But still if you guys are paranoid about boards breaking, I am ok
With keeping these OPPs disabled by default. But then anybody running
the mainline code with a 800Mhz or 1GHz x-loader, will see a couple
of warns in the kernel code.
Regards
Thara
/* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 100800, 135),
+ OPP_INITIALIZER(mpu, true, 100800, 135),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1, 93),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
Gopinath, Thara had written, on 01/06/2011 08:52 AM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 5:52 PM
To: Gulati, Shweta
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public ML
as well.
shweta.gul...@ti.com wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulatishweta.gul...@ti.com
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
---
The patch is generated on top of Kevin's PM branch. It's needed for SR
functionality on the current pm branch. Have tested SR with this patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, 110),
+ OPP_INITIALIZER(mpu, true, 3, 93),
/* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, 120),
+ OPP_INITIALIZER(mpu, true, 6, 110),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
Actually no. The latest voltage layer pushed uses these voltages. Also
Arrgh... another reason to avoid messy duplicate tables!!
We have been having this setting in the internal android code base for
some time now without anybody having issues. So till the new voltages
are conveyed officially, these remain the official voltage.
Funny,
how many versions of internal code bases are present?
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, 126),
+ OPP_INITIALIZER(mpu, true, 8, 126),
I disagree. This is not $subject. Also - not all boards will be capable
of supporting all higher frequencies rt? - remember the 3630 experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
I am not sure about this for OMAP4. Have you come across a board
where these OPPs cannot be supported? We have been enabling these
OPPs internally now for quite some time across all OMAP4 boards.
*all* as in how many? SDP/Blaze, Panda and??? How many boards are
available which is in production?
But still if you guys are paranoid about boards breaking, I am ok
With keeping these OPPs disabled by default. But then anybody running
the mainline code with a 800Mhz or 1GHz x-loader, will see a couple
of warns in the kernel code.
You do have the option of enabling the frequency for specific boards
like SDP/Blaze (e.g. if you have h/w team's signoff that these can do
high frequencies - and I think they do).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
, usbtll_ick, CK_3430ES2 | CK_AM35XX), ditto, should probably be: + CLK(ehci-omap.0, usbtll_ick, usbtll_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), - CLK(mmci-omap-hs.2, ick, mmchs3_ick, CK_3430ES2 | CK_AM35XX), - CLK(NULL, icr_ick, icr_ick, CK_343X), - CLK(omap-aes, ick, aes2_ick, CK_343X), - CLK(omap-sham, ick, sha12_ick, CK_343X), - CLK(NULL, des2_ick, des2_ick, CK_343X), + CLK(mmci-omap-hs.2, ick, mmchs3_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), + CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX), + CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX), + CLK(omap-sham, ick, sha12_ick, CK_34XX | CK_36XX), + CLK(NULL, des2_ick, des2_ick, CK_34XX | CK_36XX), CLK(mmci-omap-hs.1, ick, mmchs2_ick, CK_3XXX), CLK(mmci-omap-hs.0, ick, mmchs1_ick, CK_3XXX), - CLK(NULL, mspro_ick, mspro_ick, CK_343X), + CLK(NULL, mspro_ick, mspro_ick, CK_34XX | CK_36XX), CLK(omap_hdq.0, ick, hdq_ick, CK_3XXX), CLK(omap2_mcspi.4, ick, mcspi4_ick, CK_3XXX), CLK(omap2_mcspi.3, ick, mcspi3_ick, CK_3XXX), @@@ -3361,14 -3355,17 +3363,17 @@@ CLK(omapdss, video_fck, dss_96m_fck, CK_3XXX), CLK(omapdss, dss2_fck, dss2_alwon_fck, CK_3XXX), CLK(omapdss, ick, dss_ick_3430es1, CK_3430ES1), - CLK(omapdss, ick, dss_ick_3430es2, CK_3430ES2 | CK_AM35XX), - CLK(NULL, cam_mclk, cam_mclk, CK_343X), - CLK(NULL, cam_ick, cam_ick, CK_343X), - CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_343X), - CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2 | CK_AM35XX), + CLK(omapdss, ick, dss_ick_3430es2, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), + CLK(NULL, cam_mclk, cam_mclk, CK_34XX | CK_36XX), + CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX), + CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX), + CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), + CLK(ehci-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2 | CK_AM35XX), ditto - CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2 | CK_AM35XX), + CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), + CLK(ehci-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2 | CK_AM35XX), ditto - CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2 | CK_AM35XX), + CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX), + CLK(ehci-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2 | CK_AM35XX), ditto - CLK(NULL, usim_fck, usim_fck, CK_3430ES2), + CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS | CK_36XX), CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX), CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX), CLK(NULL, gpio1_dbck, gpio1_dbck, CK_3XXX), diff --cc arch/arm/mach-omap2/clock44xx_data.c index c426adc,bfcd19f..000 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@@ -3198,6 -2937,10 +3198,7 @@@ static struct omap_clk omap44xx_clks[] CLK(NULL, uart3_fck, uart3_fck, CK_443X), CLK(NULL, uart4_fck, uart4_fck, CK_443X), CLK(NULL, usb_host_fs_fck, usb_host_fs_fck, CK_443X), + CLK(ehci-omap.0, fs_fck, usb_host_fs_fck, CK_443X), - CLK(NULL, usb_host_hs_utmi_p3_clk, usb_host_hs_utmi_p3_clk, CK_443X), - CLK(NULL, usb_host_hs_hsic60m_p1_clk, usb_host_hs_hsic60m_p1_clk, CK_443X), - CLK(NULL, usb_host_hs_hsic60m_p2_clk, usb_host_hs_hsic60m_p2_clk, CK_443X), I'm not sure these 3 nodes should be removed. AFAIR, they were just slightly moved in lo branch. Even with the fixes above, ehci on my beagle xM/Panda still doesn't work with 2.6.37-next-20110106+, follows the failure messages: [ 57.918182] bus: 'platform': really_probe: probing driver ehci-omap with device ehci-omap.0 [ 57.918243] ehci-omap ehci-omap.0: failed to get ehci port0 regulator [ 57.918273] ehci-omap ehci-omap.0: failed to get ehci port1 regulator [ 57.918304] ehci-omap ehci-omap.0: starting TI EHCI USB Controller [ 57.918457] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x10 [ 57.918487] ehci-omap ehci-omap.0: TLL RESET DONE [ 57.918487] ehci-omap ehci-omap.0: OMAP3 ES version ES2.1 [ 57.918518] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=31c [ 58.922302] ehci-omap ehci-omap.0: phy reset operation timed out [ 59.930114] ehci-omap ehci
Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: On Wed, Jan 05, 2011 at 09:33:28PM -0800, Guenter Roeck wrote: [...] +EXPORT_SYMBOL_GPL(twl4030_madc_conversion); [...] +EXPORT_SYMBOL_GPL(twl4030_get_madc_conversion); No symbol export from hwmon drivers. Other parts of the kernel should not depend on HWMON configuration. Why? It's not like hwmon has an unreasonably large core or similar. Because it creates an unnecessary dependency, and because it is not hwmon's responsibility to provide infrastructure for other subsystems or drivers. I would suggest to check if drivers/staging/iio would be a better fit. That does have the problem that it's in staging and constantly churning, though. When I've looked at it it seemed like awfully hard work to use for devices like this. What I've done in some of my drivers is put the ADC core in the MFD core (it's used by both hwmon and power supply function drivers, plus any board specific stuff people do). Fine as well. I think I had suggested that earlier already. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-next: manual merge of the usb tree with the omap tree
Ming Lei wrote: Hi, 2010/12/24 Cousson, Benoit b-cous...@ti.com: + Paul the omap clock guru. At first glance, that seems almost good. Except for a couple of nodes that seems to lose their 3630 support. I'm just wondering why the original usb clock node is kept after the introduction of the ehci-omap.0 clock node. But this is anyway harmless. What commits are generating this conflict? On 12/23/2010 7:18 AM, Stephen Rothwell wrote: Hi Greg, Today's linux-next merge of the usb tree got a conflict in arch/arm/mach-omap2/clock3xxx_data.c and arch/arm/mach-omap2/clock44xx_data.c between various commits from the omap tree and various commits from the usb tree. I did a quick fix (which may be completely wrong - see below). snip I'm not sure these 3 nodes should be removed. AFAIR, they were just slightly moved in lo branch. Even with the fixes above, ehci on my beagle xM/Panda still doesn't work with 2.6.37-next-20110106+, follows the failure messages: [ 57.918182] bus: 'platform': really_probe: probing driver ehci-omapwith device ehci-omap.0 [ 57.918243] ehci-omap ehci-omap.0: failed to get ehci port0 regulator [ 57.918273] ehci-omap ehci-omap.0: failed to get ehci port1 regulator [ 57.918304] ehci-omap ehci-omap.0: starting TI EHCI USB Controller [ 57.918457] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x10 [ 57.918487] ehci-omap ehci-omap.0: TLL RESET DONE [ 57.918487] ehci-omap ehci-omap.0: OMAP3 ES version ES2.1 [ 57.918518] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=31c [ 58.922302] ehci-omap ehci-omap.0: phy reset operation timed out [ 59.930114] ehci-omap ehci-omap.0: phy reset operation timed out [ 59.930145] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [ 59.930175] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park [ 59.930206] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [ 59.936218] drivers/usb/core/inode.c: creating file 'devices' [ 59.936279] drivers/usb/core/inode.c: creating file '001' Any ideas? I'll take a look in a short while. I don't have an XM to test, so you'll have to help me out here. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 8:29 PM
To: Gopinath, Thara
Cc: Gulati, Shweta; l-o
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
Gopinath, Thara had written, on 01/06/2011 08:52 AM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 5:52 PM
To: Gulati, Shweta
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public
ML
as well.
shweta.gul...@ti.com wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulatishweta.gul...@ti.com
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
---
The patch is generated on top of Kevin's PM branch. It's needed for
SR
functionality on the current pm branch. Have tested SR with this
patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
-OPP_INITIALIZER(mpu, true, 3, 110),
+OPP_INITIALIZER(mpu, true, 3, 93),
/* MPU OPP2 - OPP100 */
-OPP_INITIALIZER(mpu, true, 6, 120),
+OPP_INITIALIZER(mpu, true, 6, 110),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
Actually no. The latest voltage layer pushed uses these voltages. Also
Arrgh... another reason to avoid messy duplicate tables!!
Oh there is a patch in my bag where we use a single macro for each voltage
across the voltage and opp layer!! Not yet posted because I am waiting for
voltage layer to be merged.
We have been having this setting in the internal android code base for
some time now without anybody having issues. So till the new voltages
are conveyed officially, these remain the official voltage.
Funny,
how many versions of internal code bases are present?
http://dev.omapzoom.org/?p=santosh/kernel-omap4-
base.git;a=blob;f=arch/arm/mach-
omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a
What are you complaining about here? I thought Shweta's patch
was making the mpu entries in the opp table similar to the
ones in the link above. Anything I am missing?
/* MPU OPP3 - OPP-Turbo */
-OPP_INITIALIZER(mpu, false, 8, 126),
+OPP_INITIALIZER(mpu, true, 8, 126),
I disagree. This is not $subject. Also - not all boards will be
capable
of supporting all higher frequencies rt? - remember the 3630
experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
I am not sure about this for OMAP4. Have you come across a board
where these OPPs cannot be supported? We have been enabling these
OPPs internally now for quite some time across all OMAP4 boards.
*all* as in how many? SDP/Blaze, Panda and??? How many boards are
available which is in production?
All as in SDP, Blaze and Panda, today by default we boot up at 1 Ghz.
I have not heard of anybody asking to lower the frequencies. If you are
talking about any customer board, I am not the person to comment.
Regards
Thara
But still if you guys are paranoid about boards breaking, I am ok
With keeping these OPPs disabled by default. But then anybody running
the mainline code with a 800Mhz or 1GHz x-loader, will see a couple
of warns in the kernel code.
You do have the option of enabling the frequency for specific boards
like SDP/Blaze (e.g. if you have h/w team's signoff that these can do
high frequencies - and I think they do).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following: [..] Actually no. The latest voltage layer pushed uses these voltages. Also Arrgh... another reason to avoid messy duplicate tables!! Oh there is a patch in my bag where we use a single macro for each voltage across the voltage and opp layer!! Not yet posted because I am waiting for voltage layer to be merged. I think I would find that patch interesting - Just fyi, the SR series is already in omap-for-linus branch and slated for .38-rc1, so feel free to post additional changes. We have been having this setting in the internal android code base for some time now without anybody having issues. So till the new voltages are conveyed officially, these remain the official voltage. Funny, how many versions of internal code bases are present? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=blob;f=arch/arm/mach- omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a What are you complaining about here? I thought Shweta's patch was making the mpu entries in the opp table similar to the ones in the link above. Anything I am missing? Yes, I am lost as to what the official voltage at PMIC level is for each OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu kernel, generic linux tree, android kernel tree etc - so the claim of one tree containing official table is kinda interesting as one wonders what one gets with other trees ;). /* MPU OPP3 - OPP-Turbo */ - OPP_INITIALIZER(mpu, false, 8, 126), + OPP_INITIALIZER(mpu, true, 8, 126), I disagree. This is not $subject. Also - not all boards will be capable of supporting all higher frequencies rt? - remember the 3630 experience? is'nt it wiser to enable it based on board capabilities - e.g. similar to the patch I did for beagle XM yesterday - we wont be able to enable higher frequencies on SDP3630 as we have not guarenteed with PDN analysis that it is ok. I am not sure about this for OMAP4. Have you come across a board where these OPPs cannot be supported? We have been enabling these OPPs internally now for quite some time across all OMAP4 boards. *all* as in how many? SDP/Blaze, Panda and??? How many boards are available which is in production? All as in SDP, Blaze and Panda, today by default we boot up at 1 Ghz. I have not heard of anybody asking to lower the frequencies. If you are talking about any customer board, I am not the person to comment. Right, so lets keep it disabled for the moment as it does not even match $subject and violates the concept of a single patch doing a single thing - enabling higher frequencies at this point of time is premature IMHO. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Hi, 2011/1/6 Anand Gadiyar gadi...@ti.com: I'll take a look in a short while. I don't have an XM to test, so you'll have to help me out here. No problem for me, :-) thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
-Original Message- From: Menon, Nishanth Sent: Thursday, January 06, 2011 8:49 PM To: Gopinath, Thara Cc: Gulati, Shweta; l-o Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following: [..] Actually no. The latest voltage layer pushed uses these voltages. Also Arrgh... another reason to avoid messy duplicate tables!! Oh there is a patch in my bag where we use a single macro for each voltage across the voltage and opp layer!! Not yet posted because I am waiting for voltage layer to be merged. I think I would find that patch interesting - Just fyi, the SR series is already in omap-for-linus branch and slated for .38-rc1, so feel free to post additional changes. Yes I will post it. We have been having this setting in the internal android code base for some time now without anybody having issues. So till the new voltages are conveyed officially, these remain the official voltage. Funny, how many versions of internal code bases are present? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=blob;f=arch/arm/mach- omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a What are you complaining about here? I thought Shweta's patch was making the mpu entries in the opp table similar to the ones in the link above. Anything I am missing? Yes, I am lost as to what the official voltage at PMIC level is for each OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu kernel, generic linux tree, android kernel tree etc - so the claim of one tree containing official table is kinda interesting as one wonders what one gets with other trees ;). Are you sure all these tree do not have the same voltage values for mpu rail on OMAP4? Because as far as I am aware I am the one who has been writing this code and I have never used any other values. So then it is kind of interesting! /* MPU OPP3 - OPP-Turbo */ - OPP_INITIALIZER(mpu, false, 8, 126), + OPP_INITIALIZER(mpu, true, 8, 126), I disagree. This is not $subject. Also - not all boards will be capable of supporting all higher frequencies rt? - remember the 3630 experience? is'nt it wiser to enable it based on board capabilities - e.g. similar to the patch I did for beagle XM yesterday - we wont be able to enable higher frequencies on SDP3630 as we have not guarenteed with PDN analysis that it is ok. I am not sure about this for OMAP4. Have you come across a board where these OPPs cannot be supported? We have been enabling these OPPs internally now for quite some time across all OMAP4 boards. *all* as in how many? SDP/Blaze, Panda and??? How many boards are available which is in production? All as in SDP, Blaze and Panda, today by default we boot up at 1 Ghz. I have not heard of anybody asking to lower the frequencies. If you are talking about any customer board, I am not the person to comment. Right, so lets keep it disabled for the moment as it does not even match $subject and violates the concept of a single patch doing a single thing - enabling higher frequencies at this point of time is premature IMHO. Ah! I am not debating the subject vs content issue here at all! You are very much in the right regarding that. All I am asking is is there a genuine issue in enabling the higher OPP's for mpu on OMAP4 today. 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] omap: wd_timer: Fix crash frm wdt_probe when!CONFIG_RUNTIME_PM
On Thu, Jan 06, 2011 at 09:27:32AM +0530, Santosh Shilimkar wrote: -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, January 06, 2011 3:49 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Paul Walmsley; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when!CONFIG_RUNTIME_PM On Wed, Jan 05, 2011 at 07:10:55PM +0530, Santosh Shilimkar wrote: Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism' introduced watchdog timer state state management using postsetup_state. This was done to allow some board files to support watchdog coverage throughout kernel initialization and it work as intended when RUNTIME_PM is enabled. With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog to remain enabled the omap_wdt_probe crashesh. This is because hwmod in absense of runtime PM unable to turn watchdog clocks because it's state is set to be disabled. For rest of the device, the state is set as enabled in absense of RUNTIME_PM Err... wasn't this provoked by an attempt to fix the LDP issue, that is (I believe) because the boot loader enables the watchdog and pre- hwmod kernels used to disable it. Post-hwmod kernels stopped disabling the watchdog, resulting in a few seconds booting userspace before the system resets itself. Yes. That's managed through the shutdown part. Apart from that there is another enhancement done in case some one wants to have WDT running throughout the kernel boot. Good - and just to confirm, the fix for LDP watchdogging will be submitted in the current merge window? -- 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
RFBI worked example
Hi, I am trying to setup an OMAP3530 based system for RFBI video output using external triggering. Looking at the omap dss2 source code (and also searching around) I cannot find any worked example of how to use the rfbi driver. I know that RFBI has worked in the past for a Nokia N800 device. Can you dig out any source code that shows how to use the RFBI driver? In particular I need to see how the omap_rfbi_prepare_update() and omap_rfbi_update() calls operate with their callback. I am thinking that I should simply call omap_rfbi_update() in a thread and wait for the completion call back after each call. I want to confirm that this is the correct way to run the driver. Thanks, Ben Ben Tucker Senior Software Engineer MPC Data Limited e-mail: btuc...@mpc-data.co.uk web: www.mpc-data.co.uk tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601 ddi: +44 (0) 1225 710660 MPC Data Limited is a company registered in England and Wales with company number 05507446 Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14 7FJ VAT no: 850625238 The information in this email and in the attached documents is confidential and may be legally privileged. Any unauthorized review, copying, disclosure or distribution is prohibited and may be unlawful. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. When addressed to our clients any opinions or advice contained in this email is subject to the terms and conditions expressed in the governing contract. -- 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
More LDP stuff
During boot, apart from the watchdog issue, I'm also seeing: Clocking rate (Crystal/Core/MPU): 26.0/266/500 MHz Reprogramming SDRC clock to 26600 Hz dpll3_m2_clk rate change failed: -22 Is that something to be concerned about? ads7846 spi1.0: unable to get regulator: -19 Is something missing from the ldp support code to declare this regulator? mmcblk0: retrying using single block read (repeated many times) Is the OMAP HSMMC driver really unable to handle multi-block read requests, or is something missing on the LDP to make it work? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
Gopinath, Thara had written, on 01/06/2011 09:26 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, January 06, 2011 8:49 PM To: Gopinath, Thara Cc: Gulati, Shweta; l-o Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following: [..] Actually no. The latest voltage layer pushed uses these voltages. Also Arrgh... another reason to avoid messy duplicate tables!! Oh there is a patch in my bag where we use a single macro for each voltage across the voltage and opp layer!! Not yet posted because I am waiting for voltage layer to be merged. I think I would find that patch interesting - Just fyi, the SR series is already in omap-for-linus branch and slated for .38-rc1, so feel free to post additional changes. Yes I will post it. We have been having this setting in the internal android code base for some time now without anybody having issues. So till the new voltages are conveyed officially, these remain the official voltage. Funny, how many versions of internal code bases are present? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=blob;f=arch/arm/mach- omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a What are you complaining about here? I thought Shweta's patch was making the mpu entries in the opp table similar to the ones in the link above. Anything I am missing? Yes, I am lost as to what the official voltage at PMIC level is for each OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu kernel, generic linux tree, android kernel tree etc - so the claim of one tree containing official table is kinda interesting as one wonders what one gets with other trees ;). Are you sure all these tree do not have the same voltage values for mpu rail on OMAP4? Because as far as I am aware I am the one who has been writing this code and I have never used any other values. So then it is kind of interesting! I take this back. Apologies, I missed your point and had been lazy to research earlier - looking at the code yet again, I decided to look up official documentation :) and I finally get it - I was wrong to depend on some internal tree code base :( Just FYI I looked at the public DM: http://focus.ti.com/pdfs/wtbu/SWPS041B_FinalEPDF_12_22_2010.pdf it pointed to the operating conditions Addendum which I only found in TI internal site (unfortunately). As per this max voltages are (MPU domain) 3 - 976mV (nom 930mV) 6 - 1.155 (nom 1.1V) 8 - 1.323 (nom 1.26 which is coded in) 100800 - Nom is 1.35V (we have put that in) Keep in mind that the voltage we put in the table is the PMIC voltage and the DM addendum states nominal voltage at OMAP ball level(you need to read (1) footnote to get the secret ;) ). What we need is to add additional voltage to provide at PMIC ball leve for typical board characteristics (this is pointed by the Max voltage in the addendum) and we allow SR to adjust to optimal voltage for that device on that board. So the right table (if you are changing the values should be to switch to Max ones). I am ok on changing the voltages now that I have official documentation to back the change :). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
It's probably expected, but I can't get the EHCI USB port to work on a beagle board XM (36xx) using the current omap tree. It this most likely due to these clock issues? the (very old) angstrom 2.6.32 kernel works fine, as a comparison. -brad -- 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 v8 0/11] dmtimer adaptation to platform_driver
Hi Tarun,
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
dmtimer adaptation to platform_driver.
This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.
Tested on following platforms:
OMAP1710 H3 SDP
OMAP2420 SDP
OMAP2430 SDP
OMAP3430 SDP
OMAP3630 SDP
OMAP4430 SDP
How exactly was this tested? Boot tested only? Do you have a test
that attempts to request/configure/enable all the timers? The timer-gp
code allows all the way to GPT12 which obviously will not work in this
series.
I have test case which acquires a timer, configures timeout, and enables.
After timeout, the timer is stopped and released. This is done for all
Supported timers in the platform.
With regard to the timers tested, it is based upon the platform:
OMAP2420 = 12 timers
OMAP2430 = 12 timers
OMAP3xxx = 11 timers
OMAP3 actually has 12 timers. GPT12 is a secure timer on HS devices,
but is available for general use on GP (and notably on 35xx devices,
like Beagle.)
Older TRMs listed 12 timers, but I see now that GPT12 is not in the main
TRM but is moved to the HS Security addendum.
As was discussed in early reviews of this series, we really need some
sort of capabilities assocaited with these timers. e.g., some are PWM
capable, others can interrupt the IVA or modem, and some are
conditionally available.
Until some generic support for timer capabilities is available, I
suggest you add hwmods for all timers which will keep current
functionality.
OMAP44xx = 11 timers
I am not sure if I have understood your comments correctly.
Try booting on Beagle to see what I mean, and note especially the call
to
omap2_gp_clockevent_set_gptimer(12);
in Beagle's board file.
Kevin
Also, testing with PM on 34xx/n900, I noticed that this series prevents
PER and CORE from hitting retention during suspend. I haven't debugged
why yet.
I have not done power testing. I will try this out right away and confirm.
--
Tarun
Kevin
Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Branch: origin/omap-for-linus
v8:
(1) Baselined on Tony's tree in omap-for-linus branch
(2) The last patch in v7 series has been removed because it is fixed
by following patch:
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable
TODO:
(1) OFF Mode support
(2) Upgrade timeout implementation in low-level read/write access to
return
error condition to EXPORT APIs. This is re-frained in the present
implementation
because that would involve change to EXPORTED APIs. Besides, there is no
clear
design as yet which is agreed upon by the community.
v7:
(1) In omap1_dm_timer_set_src(), the computation of shift value to
respective
dmtimer clock source was corrected:
From:
int n = (pdev-id) 1;
To:
int n = (pdev-id - 1) 1;
This change is needed because dmtimer is indexed from 1 now instead of
0.
(2) In omap1_dm_timer_init(void) memory resource end address chnaged:
From:
res[0].end = base + 0xff;
To:
res[0].end = base + 0x46;
This was causing request_mem_region() failure in driver probe().
(3) In the export APIs there are some calls which are not applicable to
OMAP1.
They have been made conditional now. They include following calls:
timer-fclk = clk_get(timer-pdev-dev, fck);
omap_dm_timer_enable()
omap_dm_timer_disable()
(4) Remove usage of cpu_is_omap16xx() and instead a flag has been added
in
struct dmtimer_platform_data {
...
u32 is_omap16xx:1;
}
This flag is set to 1 in mach-omap1/dmtimer.c and set to 0 in mach-
omap2/dmtimer.c
This flag is used in plat-omap/dmtimer.c wherever it needs to distiguish
omap16xx.
(5) Remove #include plat/omap_device.h from mach-omap1/dmtimer.c
(6) Instead of using macros like INT_24XX_GPTIMERx, use the numbers
directly in OMAP2420, OMAP2430 and OMAP3xxx hwmod database.
(7) pm_runtime_get_sync() and pm_runtime_put_sync() return value check
modified
from positive to negative value:
if (pm_runtime_get_sync(...) 0) {
...
}
v6:
(1) Removed reset functions to mach-omap1/dmtimer.c.
Access to reset function from plat-omap/dmtimer.c is provided by means
of function pointer.
(2) Remove multiple calls to omap_device_build() for registering timer
devices
during early and regular initialization. Regular device registration is
now done
by reading data from temporary list. This list is populated during early
init
where timer data is read from hwmod database and corresponding memory
allocated.
(3) kfree(pdata) under error condition since platform_device_unregister
does
not free its pdata.
(4) Removed extra header inclusion in mach-omap2 and plat-omap
NOTE: omap_dm_timer.id field could not be removed because during
regular boot
RE: [PATCH] omap: wd_timer: Fix crash frm wdt_probewhen!CONFIG_RUNTIME_PM
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, January 06, 2011 8:57 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Paul Walmsley; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probewhen!CONFIG_RUNTIME_PM [.] Yes. That's managed through the shutdown part. Apart from that there is another enhancement done in case some one wants to have WDT running throughout the kernel boot. Good - and just to confirm, the fix for LDP watchdogging will be submitted in the current merge window? Yes. It's in the queue already. -- 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: More LDP stuff
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Thursday, January 06, 2011 9:07 PM To: linux-omap@vger.kernel.org Subject: More LDP stuff During boot, apart from the watchdog issue, I'm also seeing: Clocking rate (Crystal/Core/MPU): 26.0/266/500 MHz Reprogramming SDRC clock to 26600 Hz dpll3_m2_clk rate change failed: -22 Is that something to be concerned about? DDR is not getting reconfigured and needs to rely on bootloder settings. Should be ok because DVFS is not yet supported yet. ads7846 spi1.0: unable to get regulator: -19 Is something missing from the ldp support code to declare this regulator? Am not sure what is connected to SPI on LDP. But mostly not an important peripheral. mmcblk0: retrying using single block read (repeated many times) Is the OMAP HSMMC driver really unable to handle multi-block read requests, or is something missing on the LDP to make it work? Not sure. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven: It's probably expected, but I can't get the EHCI USB port to work on a beagle board XM (36xx) using the current omap tree. It this most likely due to these clock issues? You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
aaro.koski...@nokia.com writes: Hi, Kevin Hilman [khil...@ti.com]: Aaro Koskinen aaro.koski...@nokia.com writes: Make !CONFIG_SUSPEND init declarations identical on all OMAPs and eliminate some ifdefs. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com I like this solution, but it introduces compiler warnings: [...] As you likely noticed, removing the const leads to checkpatch warnings: WARNING: struct platform_suspend_ops should normally be const so the choice is between a checkpatch warning or a bunch of compiler warnings. Alternatively, I just posted a patch[1] to linux-pm propsing to fix this at the source. Let's see what happens there. Merging $SUBJECT patch will depend on how this is fixed upstream. Sorry, I should have mentioned this when I posted the patch. I was aware of this issue, but I thought this was already fixed in upstream. Check the following commit in linux-next: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=2f55ac072f5344519348c0c94b3d2f4cca46847b (suspend: constify platform_suspend_ops) ah, thanks. somehow I missed that one when looking to see if this was already fixed. 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: Current OMAP build failures
Hi Russell, Russell King - ARM Linux li...@arm.linux.org.uk writes: I've observed the following issues while building 2.6.37 + my devel branch. I don't believe any of them to be due to anything in my tree, so would be in 2.6.37 as well. What defconfig are you using for these builds? 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
4430SDP boot failure
This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37... It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built. Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment. For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on. Texas Instruments X-Loader 1.41 (Apr 19 2010 - 13:31:11) mmc read: Invalid size Starting OS Bootloader from MMC/SD1 ... U-Boot 1.1.4-g9e955085-dirty (Nov 19 2009 - 13:01:21) Load address: 0x80e8 DRAM: 512 MB Flash: 0 kB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk1p2 rw mem=512M console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0 OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test mmc read: Invalid size 1843088 bytes read OMAP44XX SDP # bootm 8030 ## Booting image at 8030 ... Image Name: Linux-2.6.37+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1843024 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. X-Loader hangs -- 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: Current OMAP build failures
On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote: Hi Russell, Russell King - ARM Linux li...@arm.linux.org.uk writes: I've observed the following issues while building 2.6.37 + my devel branch. I don't believe any of them to be due to anything in my tree, so would be in 2.6.37 as well. What defconfig are you using for these builds? I couldn't say offhand because they're built from configs created a while back. I tend to just re-run the build with appropriate O= arguments to test things. I can send the defconfigs if it'd help. -- 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: 4430SDP boot failure
Russell King - ARM Linux had written, on 01/06/2011 11:08 AM, the following: [..] For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on. [..] 1843088 bytes read OMAP44XX SDP # bootm 8030 ## Booting image at 8030 ... Image Name: Linux-2.6.37+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1843024 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. X-Loader hangs http://gitorious.org/x-loader/x-loader/blobs/master/cpu/omap4/start.S#line40 I think we can improve this to provide rationale if data abort/ other causes for the hang. But in this case, I am not sure it might help - what we need to add is boot reason information probably. It does look to me that a reset took place (u-boot hooks up it's own handlers for irq,fiq,abort etc, but they were'nt triggered) - so either kernel abort took place and a wdt trigger caused x-loader to come up in some unexpected configuration that it could'nt handle OR a reset of somesort took place. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows on OMAP
Sorry if this is off topic on a Linux mailing list, but maybe it's of some interest here, too: Windows on OMAP presented at Microsoft's CES keynote yesterday: http://www.youtube.com/watch?v=xKc_XGuvNIk#t=1m53s Best regards Dirk Btw.: Is anybody able to identify the OMAP board used there? And with this the OMAP? OMAP3? OMAP4? -- 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: Current OMAP build failures
* Russell King - ARM Linux li...@arm.linux.org.uk [110106 09:09]:
On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
Hi Russell,
Russell King - ARM Linux li...@arm.linux.org.uk writes:
I've observed the following issues while building 2.6.37 + my devel
branch. I don't believe any of them to be due to anything in my tree,
so would be in 2.6.37 as well.
What defconfig are you using for these builds?
I couldn't say offhand because they're built from configs created a while
back. I tend to just re-run the build with appropriate O= arguments to
test things.
I can send the defconfigs if it'd help.
I have the following patch queued up as commit
be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
which should fix the compile error you're seeing. This seems to be related
to some option in the .config that's not happening with any of the
defconfigs.
Regards,
Tony
commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
Author: Tony Lindgren t...@atomide.com
Date: Tue Dec 7 16:25:40 2010 -0800
omap: Fix undefined reference to omap2_i2c_mux_pins
In some cases we can get error function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:136: undefined reference to `omap2_i2c_mux_pins'
arch/arm/plat-omap/i2c.c:141: undefined reference to `omap_hwmod_lookup'
arch/arm/plat-omap/i2c.c:157: undefined reference to `omap_device_build'
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a6cf4e9..db9c4ef 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -130,6 +130,7 @@ static struct omap_device_pm_latency omap_i2c_latency[] = {
},
};
+#ifdef CONFIG_ARCH_OMAP2PLUS
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -166,6 +167,12 @@ static inline int omap2_i2c_add_bus(int bus_id)
return PTR_ERR(od);
}
+#else
+static inline int omap2_i2c_add_bus(int bus_id)
+{
+ return 0;
+}
+#endif
static int __init omap_i2c_add_bus(int bus_id)
{
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Koen Kooi had written, on 01/06/2011 10:59 AM, the following: Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven: It's probably expected, but I can't get the EHCI USB port to work on a beagle board XM (36xx) using the current omap tree. It this most likely due to these clock issues? You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.-- Alrite, if it is ok with you and Tony, I will help post the split up - this will help multiple things: a) prevents the patch being held off because of multiline comments and the link b) git bisect can isolate to a specific change. c) A patch should do a single logical thing for helping (b). -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
Hi Santosh
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4
selected. This is because common files make references to the functions
which are defined only for omap2xxx and omap3xxx.
...
This patch adds stubs for these functions so that build continues to work.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.h | 63
+++-
1 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 53d44f6..843f329 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -228,7 +228,67 @@
#ifndef __ASSEMBLER__
-
+/*
+ * Stub omap2xxx/omap3xxx functions so that common files
+ * continue to build when custom builds are used
+ */
+#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) ||\
+ defined(CONFIG_ARCH_OMAP3))
+static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN_ONCE(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
I think it would be best to use WARN() on these, rather than WARN_ONCE().
That's because these could be called from different parts of the code
base, and the stack backtrace will help someone figure out all the code
that needs to be fixed.
Once you do that, this patch is
Acked-by: Paul Walmsley p...@pwsan.com
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
On Wed, 5 Jan 2011, Santosh Shilimkar wrote: struct clockdomain member clktrctrl_mask is available for only for OMAP2 and OMAP3 architectures. Technially it is also used only for these archs but this breaks the build with custom OMAP4 configuration. ... Fix the build break by dropping the #ifdef as suggested by Paul Walmsley Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com Acked-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
Eduardo Valentin eduardo.valen...@nokia.com writes: On Wed, Jan 05, 2011 at 03:22:51PM -0800, ext Kevin Hilman wrote: Eduardo Valentin eduardo.valen...@nokia.com writes: Hello Russell, On Wed, Jan 05, 2011 at 06:19:18PM +, Russell King wrote: On Wed, Jan 05, 2011 at 07:58:03PM +0200, Eduardo Valentin wrote: Currently, if one calls disable_irq(gpio_irq), the irq won't get disabled. This is happening because the omap gpio code defines only a .mask callback. And the default_disable function is just a stub. The result is that, when someone calls disable_irq for an irq in a gpio line, it will be kept enabled. This patch solves this issue by setting the .disable callback to point to the same .mask callback. Amd this is a problem because? errr.. because the interrupt is enabled when it was supposed to be disabled? As Russell pointed out, it's not actually supposed to be. With lazy disable, what disable_irq() does is prevent the *handler* from ever being called. If another interrupt arrives, it will be caught by the genirq core, marked as IRQ_PENDING and then masked. This don't disable unless we really have to is the desired behavior of the lazy disable feature. Right. I'm convinced that the handler won't be called because of the lazy disable mechanism. The way this works is that although it isn't disabled at that point, if it never triggers, then everything remains happy. However, if it does trigger, the genirq code will then mask the interrupt and won't call the handler. Right.. I didn't see from this point. I will check how that gets unmasked. But even so, if I understood correctly what you described, it would still open a time window which the system would see at least 1 interrupt during the time it was not suppose to. And that can wakeup a system which is in deep sleep mode, either via dynamic idle or static suspend. It is unlikely, I know. But it can still happen. And can be avoided. If the GPIO is configured as a wakeup source, then wouldn't you want activity on that GPIO to wake up the system? Yes I would want it.. of course, if the interrupt is enabled though.. I'm still trying to find a valid situation where someone disables an irq but still wants its activity to be a wakeup source. I couldn't find so far.. If you don't want wakeups on that GPIO, then the driver should probably be using disable_irq_wake(). Yes. Let's take this situation. Let's assume a driver, at its suspend callback, explicitly reports to the system that its irq can be disabled and also should not be seen as a wakeup source, by calling disable_irq(gpio_irq) and disable_irq_wake(gpio_irq). What should be the expected system behavior when the user says echo mem /sys/power/state? From the point we are done with devices suspend, that gpio will still be marked as an irq, at the bank level. But its corresponding pad will have its wakeup bit disabled. Would that work? I think yes, in most cases. Now let's take the WFI instruction as a divisor for 2 situations: A - common / working case: an interrupt on that gpio still happens after the WFI instruction. Since the system is in sleep mode and the pad for that gpio is not wakeup capable, then nothing would happen and the system won't wakeup. Then, I think everyone is happy here. B - corner case: an interrupt on that gpio happens before the WFI instruction. Since the system is active, the gpio bank can still report this interrupt and will do it. The suspend won't happen due to a irq which has been explicitly marked as disabled and wakeup incapable. Then, would that be the expected behavior? Assuming that the driver has explicitly said to the system, you should not bother about this at all. Well, expected behaviour would be that GPIO bank should not be reporting the this interrupt at all since it has been disabled. However, since you're asking, I assume that you're not seeing this expected behavior. Ignoring wakeups for a second, if this corner case happens on a non-wakeup capable GPIO using lazy disable, I would not expect suspend to be prevented. The genirq core would see the IRQ, mark it as IRQ_PENDING, mask it and return. and suspend should continue. hmm... however, if the IRQ happens after interrupts are disabled, the genirq core won't handle it, and our PM core will see a pending interrupt and abort idle/suspend. Are you seeing this corner case for a wakeup-enable GPIO or a non wakeup-enabled GPIO? /me looks at code I'm assuming now it's for a wakeup-enabled GPIO. Another more likely possibility is that the IRQ arrives between the time the driver does its disable_irq_wake() and when the GPIO driver actually suspends. We currently defer disalbing the bank-level IRQ wakeup capabilities until the suspend method of the GPIO driver is run (which is very late in the suspend cycle, since it is a sysdev.) Thinking about this some
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote: This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37... It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built. Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment. For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on. And another thing: turning on DEBUG in the decompressor breaks the build on OMAP: `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o Is there a reason why this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 omap_uart_lsr: .word 0 .popsection can't be in the BSS section? With that fixed, and a debug version of the decompressor built, when I load and run this I get the same results - without the debugging output. If I put additional debugging earlier in the decompressor, I don't see it decompressing the kernel at all. Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port. -- 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 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
On Wed, 5 Jan 2011, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: struct clockdomain member clktrctrl_mask is available for only for OMAP2 and OMAP3 architectures. Technially it is also used only for these archs but this breaks the build with custom OMAP4 configuration. I'll queue patches 3-5 for the 2.6.38-rc fixes cycle. With Paul's ack, I can queue the others too, or Paul can decide to take them via his tree. Paul can decide. I've acked one and requested minor changes on the other, after which it can be acked by me. You're welcome to take them at that point. Just a request, maybe you can post a branch with just these patches in them; that way Rajendra and/or I can rebase his new clockdomain changes on it until -rc1 comes out. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current OMAP build failures
On Thu, Jan 06, 2011 at 09:49:51AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [110106 09:09]: On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote: Hi Russell, Russell King - ARM Linux li...@arm.linux.org.uk writes: I've observed the following issues while building 2.6.37 + my devel branch. I don't believe any of them to be due to anything in my tree, so would be in 2.6.37 as well. What defconfig are you using for these builds? I couldn't say offhand because they're built from configs created a while back. I tend to just re-run the build with appropriate O= arguments to test things. I can send the defconfigs if it'd help. I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d which should fix the compile error you're seeing. This seems to be related to some option in the .config that's not happening with any of the defconfigs. That'll be because I have: CONFIG_I2C_OMAP=y in my config, whereas most OMAP1 defconfigs don't have it enabled with the exception of omap_h2_1610_defconfig. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
Santosh Shilimkar santosh.shilim...@ti.com writes:
-Original Message-
From: Premi, Sanjeev [mailto:pr...@ti.com]
Sent: Thursday, January 06, 2011 8:03 PM
To: Shilimkar, Santosh; linux-omap@vger.kernel.org
Cc: Hilman, Kevin; t...@atomide.com; linux-arm-
ker...@lists.infradead.org; Shilimkar, Santosh; Paul Walmsley
Subject: RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
for undefined reference to 'omap2_prm_read_mod_reg'
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Santosh Shilimkar
Sent: Wednesday, January 05, 2011 4:27 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh;
Paul Walmsley
Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break
fix for undefined reference to 'omap2_prm_read_mod_reg'
[snip]
#ifndef __ASSEMBLER__
-
+/*
+ * Stub omap2xxx/omap3xxx functions so that common files
+ * continue to build when custom builds are used
+ */
+#if defined(CONFIG_ARCH_OMAP4)
!(defined(CONFIG_ARCH_OMAP2) ||\
+ defined(CONFIG_ARCH_OMAP3))
+static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
+{
+ WARN_ONCE(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
Looking forward, the warning of incorrect SOC may be required
for when kernel is build for one specific SOC.
Wouldn't it be easy/better to have common global function:
void wrong_soc(char* func, int soc_id)
{
WARN_ONCE(1, Function %s cannot be used for %d, func,
soc_id);
}
OR we could have soc specific functions e.g.
void omap2xxx_only (char* func)
{
WARN_ONCE(1, Function %s is specific to OMAP2XXX);
}
..etc..
Later these functions can be called from the stubs.
This is prelim idea, will need to be worked upon.
Not sure. May appear like over engineering considering it's a
stub.
Paul can comment.
I guess Sanjeev's approach is meant eliminate duplicate strings that
waste space.
Sanjeev, did you check whether multiple copies of the exact same string
actually exist in the binary? I'm wondering if gcc is smart enough to
only have one copy of the string (but have doubts.)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
Hi Kevin, On Wed, Jan 05, 2011 at 08:54:48AM -0800, Kevin Hilman wrote: I had assumed it was recent changes since the patch didn't apply cleanly, but am glad to be wrong. :) The patch should apply cleanly on the latest mainline. Do you want me to rebase it against some other tree and resend? Thanks, MW -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Koen Kooi k...@dominion.thruhere.net writes: Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven: It's probably expected, but I can't get the EHCI USB port to work on a beagle board XM (36xx) using the current omap tree. It this most likely due to these clock issues? You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.-- IMO, it doesn't need to be split up. But it does have to fix the other comments I made on the same thread[1] 1) add a descriptive changelog, and 2) Cc linux-arm-kernel Kevin [1] http://article.gmane.org/gmane.linux.ports.arm.omap/48920 -- 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: 4430SDP boot failure
On Thu, Jan 06, 2011 at 06:00:30PM +, Russell King - ARM Linux wrote: Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port. I'm sorry, I think this crap has to go. Trying to make it fit every platform in one kernel is just too complicated. It _needs_ to be something so damned simple that it always works without fail, every single time someone wants to use it. The current code really hasn't a hope of doing that. Yes, that means you only configure it when you're not building a multi- platform kernel, but that's worth giving up if in return we have something that is 100% reliable. As it is, I need to invent new debugging code to debug this mess. Sorry, I'm actually not going to bother - as the LL debug stuff was my debugging code to debug exactly these kinds of boot problems. Someone else can have the pain of sorting out this breakage, and tell me when they expect OMAP to work again. -- 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: 4430SDP boot failure
* Russell King - ARM Linux li...@arm.linux.org.uk [110106 10:00]: On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote: This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37... It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built. Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment. For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on. And another thing: turning on DEBUG in the decompressor breaks the build on OMAP: `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o Is there a reason why this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 omap_uart_lsr: .word 0 .popsection can't be in the BSS section? BSS works too, got a patch for that? With that fixed, and a debug version of the decompressor built, when I load and run this I get the same results - without the debugging output. If I put additional debugging earlier in the decompressor, I don't see it decompressing the kernel at all. Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port. Can you please check if you have some older bootloader that passes some wrong machine ID? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:
Koen Kooi k...@dominion.thruhere.net writes:
Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
It's probably expected, but I can't get the EHCI USB port to work
on a beagle board XM (36xx) using the current omap tree.
It this most likely due to these clock issues?
You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
I'm currently too lazy to split it up like Nishant wants as I don't
see the point splitting for the sake of splitting.--
IMO, it doesn't need to be split up.
But it does have to fix the other comments I made on the same thread[1]
1) add a descriptive changelog, and
2) Cc linux-arm-kernel
Kevin,
there are four things being done in the patch:
a) fix GPIO number for EHCI power on
b) fix GPIO number for DVI reset line
c) switch on DVI
d) switch on Camera
I have split the first 2 up. I just splitting the (c) up when I noticed
the code is confusing - I will reply in thread to the original patch.
I apologize, but I disagree - as far as I see it, these are separate
changes being done.
--
Regards,
Nishanth Menon
From c03fd107da409806ec15d508db6c7c352244a1f4 Mon Sep 17 00:00:00 2001
From: Koen Kooi k...@beagleboard.org
Date: Thu, 6 Jan 2011 12:08:15 -0600
Subject: [PATCH 1/2] omap3: beaglexm: fix EHCI power up GPIO dir
EHCI enable power pin is inverted (active high) in comparison
to vanilla beagle which is active low. Handle this case conditionally.
[...@ti.com: helped split up]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..1b5aa7a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,9 +297,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
gpio_request(gpio + 1, EHCI_nOC);
gpio_direction_input(gpio + 1);
- /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
+ /*
+ * TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
+ * high / others active low)
+ */
gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR);
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ else
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.6.3.3
From d34971b71d61f3fc20e724a48dbdfe347aa53802 Mon Sep 17 00:00:00 2001
From: Koen Kooi k...@beagleboard.org
Date: Thu, 6 Jan 2011 12:14:00 -0600
Subject: [PATCH 2/2] omap3: beaglexm: fix DVI reset GPIO
GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 1b5aa7a..d628f5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -199,7 +199,7 @@ static struct omap_dss_device beagle_dvi_device = {
.name = dvi,
.driver_name = generic_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = 170,
+ .reset_gpio = -EINVAL,
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
};
@@ -308,6 +308,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
else
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ /* DVI reset GPIO is different between beagle revisions */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ beagle_dvi_device.reset_gpio = 129;
+ else
+ beagle_dvi_device.reset_gpio = 170;
+
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.6.3.3
Re: 4430SDP boot failure
* Russell King - ARM Linux li...@arm.linux.org.uk [110106 10:17]: On Thu, Jan 06, 2011 at 06:00:30PM +, Russell King - ARM Linux wrote: Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port. I'm sorry, I think this crap has to go. Trying to make it fit every platform in one kernel is just too complicated. It _needs_ to be something so damned simple that it always works without fail, every single time someone wants to use it. The current code really hasn't a hope of doing that. Yes, that means you only configure it when you're not building a multi- platform kernel, but that's worth giving up if in return we have something that is 100% reliable. As it is, I need to invent new debugging code to debug this mess. Sorry, I'm actually not going to bother - as the LL debug stuff was my debugging code to debug exactly these kinds of boot problems. Someone else can have the pain of sorting out this breakage, and tell me when they expect OMAP to work again. Something that could help with the DEBUG_LL code is to pass optional debug UART info masked into the machine_id using the high bits.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
On Thu, 6 Jan 2011, Kevin Hilman wrote: Koen Kooi k...@dominion.thruhere.net writes: Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven: It's probably expected, but I can't get the EHCI USB port to work on a beagle board XM (36xx) using the current omap tree. It this most likely due to these clock issues? You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.-- IMO, it doesn't need to be split up. But it does have to fix the other comments I made on the same thread[1] 1) add a descriptive changelog, and 2) Cc linux-arm-kernel and glancing at the patch 3) Fix the multiline comments to conform to Documentation/CodingStyle as I think Nishanth mentioned. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
Paul Walmsley p...@pwsan.com writes: On Wed, 5 Jan 2011, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: struct clockdomain member clktrctrl_mask is available for only for OMAP2 and OMAP3 architectures. Technially it is also used only for these archs but this breaks the build with custom OMAP4 configuration. I'll queue patches 3-5 for the 2.6.38-rc fixes cycle. With Paul's ack, I can queue the others too, or Paul can decide to take them via his tree. Paul can decide. I've acked one and requested minor changes on the other, after which it can be acked by me. You're welcome to take them at that point. Just a request, maybe you can post a branch with just these patches in them; that way Rajendra and/or I can rebase his new clockdomain changes on it until -rc1 comes out. Sure, will do. I currently have a 'fixes-for-tony' branch in my tree which has all the fixes I've collected for the -rc cycle. If you prefer something separate with only the prm and clockdomain patches from this series, I can do that as well. 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 v2] ARM: OMAP: Power on EHCI, serial, camera and DVI on beagleboard-xM
Koen,
Apologies on a late response.
Koen Kooi had written, on 12/19/2010 08:42 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..4756ac7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,13 +297,35 @@ static int beagle_twl_gpio_setup(struct device *dev,
[..]
+
+/* Power on DVI, Serial and PWR led */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, nDVI_PWR_EN);
+ gpio_direction_output(gpio + 1, 0);
+ }
earlier in this function, we do:
gpio_request(gpio + 1, EHCI_nOC);
gpio_direction_input(gpio + 1);
here we do
gpio_request(gpio + 1, nDVI_PWR_EN);
gpio_direction_output(gpio + 1, 0);
I am confused. is gpio+1 input or output line? and what level should it
be on?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: Power on EHCI, serial, camera and DVI on beagleboard-xM
Op 6 jan 2011, om 19:29 heeft Nishanth Menon het volgende geschreven:
Koen,
Apologies on a late response.
Koen Kooi had written, on 12/19/2010 08:42 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..4756ac7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,13 +297,35 @@ static int beagle_twl_gpio_setup(struct device *dev,
[..]
+
+ /* Power on DVI, Serial and PWR led */
+if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+gpio_request(gpio + 1, nDVI_PWR_EN);
+gpio_direction_output(gpio + 1, 0);
+}
earlier in this function, we do:
gpio_request(gpio + 1, EHCI_nOC);
gpio_direction_input(gpio + 1);
here we do
gpio_request(gpio + 1, nDVI_PWR_EN);
gpio_direction_output(gpio + 1, 0);
I am confused. is gpio+1 input or output line? and what level should it be on?
On early revB prototypes it was used to sense USB overcurrent, I'm not sure
what the current status is for that pin on revB and revC, but on xM it controls
the DVI, serial and led block.
Adding Gerald to CC: to see if he has some pearls of wisdom on this :)
regards,
Koen--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
Mika Westerberg mika.westerb...@iki.fi writes: Hi Kevin, On Wed, Jan 05, 2011 at 08:54:48AM -0800, Kevin Hilman wrote: I had assumed it was recent changes since the patch didn't apply cleanly, but am glad to be wrong. :) The patch should apply cleanly on the latest mainline. Do you want me to rebase it against some other tree and resend? No, it's fine. I'll be queueing it for .38-rc2 and it's in my 'fixes-for-tony' branch. 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: linux-next: manual merge of the usb tree with the omap tree
Nishanth Menon n...@ti.com writes: Kevin Hilman had written, on 01/06/2011 12:15 PM, the following: Koen Kooi k...@dominion.thruhere.net writes: Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven: It's probably expected, but I can't get the EHCI USB port to work on a beagle board XM (36xx) using the current omap tree. It this most likely due to these clock issues? You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.-- IMO, it doesn't need to be split up. But it does have to fix the other comments I made on the same thread[1] 1) add a descriptive changelog, and 2) Cc linux-arm-kernel Kevin, there are four things being done in the patch: a) fix GPIO number for EHCI power on b) fix GPIO number for DVI reset line c) switch on DVI d) switch on Camera I have split the first 2 up. I just splitting the (c) up when I noticed the code is confusing - I will reply in thread to the original patch. I apologize, but I disagree - as far as I see it, these are separate changes being done. Sure, but there are all tiny and isolated. For me, what's missing is just a changlog describing all the changes. Feel free to break it up if you prefer, but IMO it would be mergable as a single patch if there was a descriptive changelog actually mentioning all the changes made (as you just did above.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: fix suspend_set_ops() to take const pointer
On Wed, 2011-01-05 at 16:22 -0800, Kevin Hilman wrote:
checkpatch warns that pointers for certain structs should be const,
and platform_suspend_ops is one of those structs. If you follow this
suggestion you trade a checkpatch warning for a compiler warning of
the form:
warning: passing argument 1 of 'suspend_set_ops' discards qualifiers from
pointer target type
Fix suspend_set_ops() to take a const pointer so everyone expects
const.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies to v2.6.37, but also applies cleanly to suspend-2.6/linux-next
Oops, plese disregard. This is already fixed in linux-next.
Kevin
include/linux/suspend.h |4 ++--
kernel/power/suspend.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 2669751..bb98383 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -122,7 +122,7 @@ struct platform_suspend_ops {
* suspend_set_ops - set platform dependent suspend operations
* @ops: The new suspend operations to set.
*/
-extern void suspend_set_ops(struct platform_suspend_ops *ops);
+extern void suspend_set_ops(const struct platform_suspend_ops *ops);
extern int suspend_valid_only_mem(suspend_state_t state);
/**
@@ -147,7 +147,7 @@ extern int pm_suspend(suspend_state_t state);
#else /* !CONFIG_SUSPEND */
#define suspend_valid_only_mem NULL
-static inline void suspend_set_ops(struct platform_suspend_ops *ops) {}
+static inline void suspend_set_ops(const struct platform_suspend_ops *ops) {}
static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
#endif /* !CONFIG_SUSPEND */
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ecf7705..0c0af3d 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -36,7 +36,7 @@ static struct platform_suspend_ops *suspend_ops;
* suspend_set_ops - Set the global suspend method table.
* @ops: Pointer to ops structure.
*/
-void suspend_set_ops(struct platform_suspend_ops *ops)
+void suspend_set_ops(const struct platform_suspend_ops *ops)
{
mutex_lock(pm_mutex);
suspend_ops = ops;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Tony Lindgren t...@atomide.com [110106 10:20]: * Russell King - ARM Linux li...@arm.linux.org.uk [110106 10:00]: On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote: And another thing: turning on DEBUG in the decompressor breaks the build on OMAP: `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o Is there a reason why this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 omap_uart_lsr: .word 0 .popsection can't be in the BSS section? BSS works too, got a patch for that? Actually BSS won't work here, that's not initialized early enough.. But it seems that the only patch that's needed is the following. Care to give it a try? Here's what I'm getting with this patch and DEBUG enabled for the uncompress code on my omap4 panda: Uncompressing Linux... done, booting the kernel. 00AC3990:0AE7:00C5187F 802C9EBC-80849D3C80008000 80849D9C 80008000: E321F0D3 EE109F10 EB0F216F E1B0A005 0A0F217E EBD8 E1B08005 0A94 80008020: EBE5 EB0F214B EB04 E59FD008 E28FE000 E28AF010 EA0F213B C00083F4 80008040: E59F4204 E1A4 E3A03000 E2806901 E4803004 E4803004 E4803004 E4803004 80008060: E136 1AF9 E59A7008 E28F0F7D E8900068 E043 E0855000 E0866000 80008080: E1A05A25 E1A06A26 E1873A05 E7843105 E1350006 12855001 1AFA E1A0300F 800080A0: E1A03A23 E1873A03 E2840A03 E5A03000 E59F6198 E284 E0846926 E156 800080C0: E2833601 94803004 9AFB E2840A03 E3876102 E5806000 EE117F10 E3170001 800080E0: 059F716C 159F716C E2873004 E5977000 E5933000 E357 1353 1A43 [0.00] Linux version 2.6.37-1-g98859f0-dirty (tml...@baageli) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #468 SMP Thu Jan 6 11:46:09 PST 2011 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled ... Regards, Tony From: Tony Lindgren t...@atomide.com Date: Thu, 6 Jan 2011 11:29:39 -0800 Subject: [PATCH] ARM: Fix low-level decompress debug code for omap If DEBUG is enabled for decompress code, the system will hang as the debug UART is not specified. Fix this by adding the necessary code for omap2plus. Note that this won't work properly with multi-omap support compiled in. Also the debug UART used needs to be patched in if not omap UART3. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0 mov \rb, #0x5000 add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT .endm +#elif defined(CONFIG_ARCH_OMAP2PLUS) +#include plat/multi.h +#ifdef MULTI_OMAP2) +#error Low-level uncompress debug code won't work with multi-omap +#elif defined(CONFIG_ARCH_OMAP2) + .macro loadsp, rb, tmp + ldr \rb, =OMAP2_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP3) + .macro loadsp, rb, tmp + ldr \rb, =OMAP3_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP4) + .macro loadsp, rb, tmp + ldr \rb, =OMAP4_UART3_BASE /* patch accordingly */ + .endm +#endif #else .macro loadsp, rb, tmp addruart \rb, \tmp -- 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] ARM: OMAP: Power on EHCI, serial, camera and DVI on beagleboard-xM
You are correct. On the -xM over current is from the USB HUB driver as there
are four ports. So that gets detected by the USB hub device and reported back.
Gerald
-Original Message-
From: Koen Kooi [mailto:k...@dominion.thruhere.net]
Sent: Thursday, January 06, 2011 12:33 PM
To: Menon, Nishanth
Cc: Koen Kooi; l-o Mailing List; Coley, Gerald
Subject: Re: [PATCH v2] ARM: OMAP: Power on EHCI, serial, camera and DVI on
beagleboard-xM
Op 6 jan 2011, om 19:29 heeft Nishanth Menon het volgende geschreven:
Koen,
Apologies on a late response.
Koen Kooi had written, on 12/19/2010 08:42 AM, the following:
[...]
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..4756ac7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,13 +297,35 @@ static int beagle_twl_gpio_setup(struct device *dev,
[..]
+
+ /* Power on DVI, Serial and PWR led */
+if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+gpio_request(gpio + 1, nDVI_PWR_EN);
+gpio_direction_output(gpio + 1, 0);
+}
earlier in this function, we do:
gpio_request(gpio + 1, EHCI_nOC);
gpio_direction_input(gpio + 1);
here we do
gpio_request(gpio + 1, nDVI_PWR_EN);
gpio_direction_output(gpio + 1, 0);
I am confused. is gpio+1 input or output line? and what level should it be on?
On early revB prototypes it was used to sense USB overcurrent, I'm not sure
what the current status is for that pin on revB and revC, but on xM it controls
the DVI, serial and led block.
Adding Gerald to CC: to see if he has some pearls of wisdom on this :)
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] omap3: beaglexm: fix DVI reset GPIO
From: Koen Kooi k...@beagleboard.org
GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 1b5aa7a..d628f5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -199,7 +199,7 @@ static struct omap_dss_device beagle_dvi_device = {
.name = dvi,
.driver_name = generic_panel,
.phy.dpi.data_lines = 24,
- .reset_gpio = 170,
+ .reset_gpio = -EINVAL,
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
};
@@ -308,6 +308,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
else
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ /* DVI reset GPIO is different between beagle revisions */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ beagle_dvi_device.reset_gpio = 129;
+ else
+ beagle_dvi_device.reset_gpio = 170;
+
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] omap3: beaglexm: fix EHCI power up GPIO dir
From: Koen Kooi k...@beagleboard.org EHCI enable power pin is inverted (active high) in comparison to vanilla beagle which is active low. Handle this case conditionally. [...@ti.com: helped split up] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Koen Kooi k...@beagleboard.org --- arch/arm/mach-omap2/board-omap3beagle.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 6c12760..1b5aa7a 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -297,9 +297,16 @@ static int beagle_twl_gpio_setup(struct device *dev, gpio_request(gpio + 1, EHCI_nOC); gpio_direction_input(gpio + 1); - /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ + /* +* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active +* high / others active low) +*/ gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); + else + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] omap3: beaglexm: power on DVI
From: Koen Kooi k...@beagleboard.org
TFP410 DVI chip is used to provide display out.
this chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
GPIO + 1 was used to sense USB overcurrent in vanilla beagle
[...@ti.com: helped split up the patch]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@beagleboard.org
---
arch/arm/mach-omap2/board-omap3beagle.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d628f5e..7c82730 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -293,9 +293,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
-
- gpio_request(gpio + 1, EHCI_nOC);
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, EHCI_nOC);
+ gpio_direction_input(gpio + 1);
+ }
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -317,6 +318,19 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /*
+* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 2 control varies depending on the board rev as follows:
+* P7/P8 revisions(prototype): Camera EN
+* A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+*/
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, nDVI_PWR_EN);
+ gpio_direction_output(gpio + 1, 0);
+ gpio_request(gpio + 2, DVI_LDO_EN);
+ gpio_direction_output(gpio + 2, 1);
+ }
+
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] OMAP3: beaglexm: GPIO fixes
Thanks for splitting it up! Now I can work on the patches for xM rev C where the pins changed again :) Op 6 jan 2011, om 20:54 heeft Nishanth Menon het volgende geschreven: Hi, As discussed in the threads: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ http://marc.info/?t=12154003084r=1w=2 here is the split up series with commit message after discussion: http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21 Koen Kooi (3): omap3: beaglexm: fix EHCI power up GPIO dir omap3: beaglexm: fix DVI reset GPIO omap3: beaglexm: power on DVI arch/arm/mach-omap2/board-omap3beagle.c | 37 ++ 1 files changed, 32 insertions(+), 5 deletions(-) v3: split up the series, addressed review comments v2: http://marc.info/?t=12927697792r=1w=2 Reenable the PMU stat LED v1: http://marc.info/?t=12917257101r=1w=2 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote: On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: Why? It's not like hwmon has an unreasonably large core or similar. Because it creates an unnecessary dependency, and because it is not hwmon's responsibility to provide infrastructure for other subsystems or drivers. hwmon isn't really doing anything, though. The *driver* is doing something but it doesn't really impact the core that much. Not that I'm particularly sold on putting the ADC core in here, but total NACK based on that alone seems rather harsh. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Kevin Hilman had written, on 01/06/2011 12:38 PM, the following: [..] Feel free to break it up if you prefer, but IMO it would be mergable as just for the record, posted the same here: http://marc.info/?l=linux-omapm=129434370207879w=2 [..] -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [110106 10:00]:
On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote:
This looks like something's rather broken on OMAP4 too - even with the
DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with
vanilla 2.6.37. So, no OMAP platform I have seems to be usable with
2.6.37...
It's worth noting that the kernel which was originally supplied with the
board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have
previous kernels I've built.
Is there yet an updated uboot for this platform which works with ethernet,
and which has the uboot environment saving implemented? Or are we stuck
with having to catch uboot before it runs the default settings and paste
the commands in each time? Also, if possible please extend the default
timeout - I can only just get from the board to the terminal to stop it
booting the default environment.
For TI folk: it may be an idea to make X-loader say why it's hanging so
that we know what is going on.
And another thing: turning on DEBUG in the decompressor breaks the build
on OMAP:
`.data' referenced in section `.text' of arch/arm/boot/compressed/head.o:
defined in discarded section `.data' of arch/arm/boot/compressed/head.o
`.data' referenced in section `.text' of arch/arm/boot/compressed/head.o:
defined in discarded section `.data' of arch/arm/boot/compressed/head.o
Is there a reason why this:
.pushsection .data
omap_uart_phys: .word 0
omap_uart_virt: .word 0
omap_uart_lsr: .word 0
.popsection
can't be in the BSS section?
BSS works too, got a patch for that?
Yes.
sed -i '/\.pushsection \.data/,/\.popsection/ {
s/\.data/.bss/;
s/.word\t0/.space\t4/;
}' arch/arm/mach-omap2/include/mach/debug-macro.S
With that fixed, and a debug version of the decompressor built, when I
load and run this I get the same results - without the debugging output.
If I put additional debugging earlier in the decompressor, I don't see
it decompressing the kernel at all.
Therefore, I believe the debugging address calculation stuff in
arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken,
causing an abort when it tries to access the serial port.
Can you please check if you have some older bootloader that passes
some wrong machine ID?
If previous kernels didn't explicitly force the SDP4430 platform ID
number (which they didn't for OMAP back to 2007), then it must be
correct as previous kernels booted fine when only configured for
the SDP4430.
It must also be correct as the decompressor can select the correct port
for outputting the Decompressing kernel... message.
So by implication I think we can say that the ID number is correct.
I've just tried forcing it to use OMAP4 UART3, which seems to be what
the decompressor is using for its output:
090c puts:
90c: e3a03802mov r3, #131072 ; 0x2
910: e38314faorr r1, r3, #-100663296 ; 0xfa00
914: e3833312orr r3, r3, #1207959552 ; 0x4800
918: e4d02001ldrbr2, [r0], #1
91c: e332teq r2, #0 ; 0x0
920: 01a0f00emoveq pc, lr
924: e5c32000strbr2, [r3]
928: e3a01802mov r1, #131072 ; 0x2
92c: e2511001subsr1, r1, #1 ; 0x1
930: 1afdbne 92c puts+0x20
934: e332000ateq r2, #10 ; 0xa
938: 03a0200dmoveq r2, #13 ; 0xd
93c: 0af8beq 924 puts+0x18
940: e330teq r0, #0 ; 0x0
944: 1af3bne 918 puts+0xc
948: e1a0f00emov pc, lr
0x4802 is the only UART address contained within the disassembly for
the decompressor to use, so that must be the correct address.
However, even with that, it causes the 'X-Loader hangs' before producing
any output. No idea what to try next - and it's soo much hastle to keep
moving SD cards around - which the laptop sometimes doesn't recognise -
just to try new kernels that I'm wasting quite a bit of effort on each
iteration it's untrue.
As I said previously, I think someone else can look into this - someone
who understands the hardware quirks of OMAP, who has a decent test setup,
and has the tools necessary to do hardware debug on OMAP.
(If it could do dhcp/tftp - and be configured to do that from powerup
without interruption, then I might feel differently as that would
significantly reduce the hastle factor and amount of time involved with
testing each iteration.)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: 4430SDP boot failure
* Tony Lindgren t...@atomide.com [110106 11:52]: --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -71,6 +71,23 @@ wait: mrc p14, 0, pc, c0, c1, 0 mov \rb, #0x5000 add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT .endm +#elif defined(CONFIG_ARCH_OMAP2PLUS) +#include plat/multi.h +#ifdef MULTI_OMAP2) ^ Looks like my last change to this patch from if defined to ifdef broke the warning above with an unbalanced bracket.. Thanks Nishant for catching that, updated patch below. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Thu, 6 Jan 2011 11:29:39 -0800 Subject: [PATCH] ARM: Fix low-level decompress debug code for omap If DEBUG is enabled for decompress code, the system will hang as the debug UART is not specified. Fix this by adding the necessary code for omap2plus. Note that this won't work properly with multi-omap support compiled in. Also the debug UART used needs to be patched in if not omap UART3. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0 mov \rb, #0x5000 add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT .endm +#elif defined(CONFIG_ARCH_OMAP2PLUS) +#include plat/multi.h +#ifdef MULTI_OMAP2 +#error Low-level uncompress debug code won't work with multi-omap +#elif defined(CONFIG_ARCH_OMAP2) + .macro loadsp, rb, tmp + ldr \rb, =OMAP2_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP3) + .macro loadsp, rb, tmp + ldr \rb, =OMAP3_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP4) + .macro loadsp, rb, tmp + ldr \rb, =OMAP4_UART3_BASE /* patch accordingly */ + .endm +#endif #else .macro loadsp, rb, tmp addruart \rb, \tmp -- 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: 4430SDP boot failure
* Russell King - ARM Linux li...@arm.linux.org.uk [110106 12:32]:
On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [110106 10:00]:
can't be in the BSS section?
BSS works too, got a patch for that?
Yes.
sed -i '/\.pushsection \.data/,/\.popsection/ {
s/\.data/.bss/;
s/.word\t0/.space\t4/;
}' arch/arm/mach-omap2/include/mach/debug-macro.S
That does not work as BSS gets cleared in head-common.S.. See my other patch.
Can you please check if you have some older bootloader that passes
some wrong machine ID?
If previous kernels didn't explicitly force the SDP4430 platform ID
number (which they didn't for OMAP back to 2007), then it must be
correct as previous kernels booted fine when only configured for
the SDP4430.
It must also be correct as the decompressor can select the correct port
for outputting the Decompressing kernel... message.
So by implication I think we can say that the ID number is correct.
OK thanks.
I've just tried forcing it to use OMAP4 UART3, which seems to be what
the decompressor is using for its output:
090c puts:
90c: e3a03802mov r3, #131072 ; 0x2
910: e38314faorr r1, r3, #-100663296 ; 0xfa00
914: e3833312orr r3, r3, #1207959552 ; 0x4800
918: e4d02001ldrbr2, [r0], #1
91c: e332teq r2, #0 ; 0x0
920: 01a0f00emoveq pc, lr
924: e5c32000strbr2, [r3]
928: e3a01802mov r1, #131072 ; 0x2
92c: e2511001subsr1, r1, #1 ; 0x1
930: 1afdbne 92c puts+0x20
934: e332000ateq r2, #10 ; 0xa
938: 03a0200dmoveq r2, #13 ; 0xd
93c: 0af8beq 924 puts+0x18
940: e330teq r0, #0 ; 0x0
944: 1af3bne 918 puts+0xc
948: e1a0f00emov pc, lr
0x4802 is the only UART address contained within the disassembly for
the decompressor to use, so that must be the correct address.
However, even with that, it causes the 'X-Loader hangs' before producing
any output. No idea what to try next - and it's soo much hastle to keep
moving SD cards around - which the laptop sometimes doesn't recognise -
just to try new kernels that I'm wasting quite a bit of effort on each
iteration it's untrue.
As I said previously, I think someone else can look into this - someone
who understands the hardware quirks of OMAP, who has a decent test setup,
and has the tools necessary to do hardware debug on OMAP.
I think I got it fixed, see the other patch I just posted.
(If it could do dhcp/tftp - and be configured to do that from powerup
without interruption, then I might feel differently as that would
significantly reduce the hastle factor and amount of time involved with
testing each iteration.)
Yes these new boards badly need the Ethernet working in u-boot..
Anyways, I can debug the DEBUG_LL booting issue further if the patch
I posted does not help.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110106 11:52]: --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0 mov \rb, #0x5000 add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT .endm +#elif defined(CONFIG_ARCH_OMAP2PLUS) +#include plat/multi.h +#ifdef MULTI_OMAP2) ^ Looks like my last change to this patch from if defined to ifdef broke the warning above with an unbalanced bracket.. Thanks Nishant for catching that, updated patch below. Just tried that patch, but I now have bigger problems: OMAP44XX SDP # mmcinit 0 OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test 0 bytes read OMAP44XX SDP # God knows why it's doing this now, as the file is present on the SD card: -rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 20:35 uImage-test is what's on the SD card - with no FAT errors: $ fsck.msdos /dev/mmcblk0p1 dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN /dev/mmcblk0p1: 8 files, 10249/142266 clusters The file's not corrupt either: $ md5sum /media/boot/uImage-test be3edd928f1dbb3c15215b1a8a62fa1f /media/boot/uImage-test $ md5sum ../build/omap4/arch/arm/boot/uImage be3edd928f1dbb3c15215b1a8a62fa1f ../build/omap4/arch/arm/boot/uImage Nope, still won't work: OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0 OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test 0 bytes read OMAP44XX SDP # However, it can still boot the uImage contained on the SD card, so the card must be okay, and the SDP must still be able to successfully read from the card. I can only assume that uboot's FAT support is buggered in some way. We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny. So, I give up at this point with the OMAP4430SDP board. It's not worth spending the time with this kind of unreliability. -- 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: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
On Thu, 9 Dec 2010 14:41:50 +0100
Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
This patch extends the LED backlight tirgger driver with an option that
allows
for inverting the trigger output polarity.
With the invertion option provided, I (ab)use the backlight trigger for
driving a LED that indicates LCD display blank condtition on my Amstrad Delta
videophone. Since the machine has no dedicated power LED, it was not possible
to distinguish if the display was blanked, or the machine was turned off,
without touching it.
The invert sysfs control is patterned after a similiar function of the GPIO
trigger driver.
Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
Retested on linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Richard Purdie rpur...@rpsys.net
---
Resent because I still can't see any response received, while yet another
merge window is going to pass away soon.
Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh.
Only
tried to clean up the commit message slightly - maybe my English is not good
enough to bother with, if not the code?
v1 - v2 changes:
- improve some conditional expressions to be more readable; thanks to Ralph
Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
- refresh against linux-2.6.36-rc5.
drivers/leds/ledtrig-backlight.c | 60
---
1 file changed, 56 insertions(+), 4 deletions(-)
diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c
linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
--- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c2010-09-24
15:35:13.0 +0200
+++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03
15:59:49.0 +0200
@@ -26,6 +26,7 @@ struct bl_trig_notifier {
int brightness;
int old_status;
struct notifier_block notifier;
+ unsigned invert;
};
static int fb_notifier_callback(struct notifier_block *p,
@@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
struct led_classdev *led = n-led;
struct fb_event *fb_event = data;
int *blank = fb_event-data;
+ int new_status = *blank ? BLANK : UNBLANK;
switch (event) {
case FB_EVENT_BLANK :
- if (*blank n-old_status == UNBLANK) {
+ if (new_status == n-old_status)
+ break;
+
+ if ((n-old_status == UNBLANK) ^ n-invert) {
n-brightness = led-brightness;
led_set_brightness(led, LED_OFF);
- n-old_status = BLANK;
- } else if (!*blank n-old_status == BLANK) {
+ } else {
led_set_brightness(led, n-brightness);
- n-old_status = UNBLANK;
}
+
+ n-old_status = new_status;
+
break;
}
return 0;
}
+static ssize_t bl_trig_invert_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+
+ return sprintf(buf, %s\n, n-invert ? yes : no);
+}
I think this should show 0 or 1, to match the thing which the user
wrote here.
+static ssize_t bl_trig_invert_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t num)
+{
+ struct led_classdev *led = dev_get_drvdata(dev);
+ struct bl_trig_notifier *n = led-trigger_data;
+ unsigned invert;
+ int ret;
+
+ ret = sscanf(buf, %u, invert);
Here we should use strict_strtoul() so the kernel correctly rejects
input of the form 42foo.
+ if (ret 1) {
+ dev_err(dev, invalid value\n);
+ return -EINVAL;
+ }
And here it would be better to disallow any input other than 0 or 1.
Because 2 makes no sense and who knows, some time in the future we
might *want* to permit 2.
So...
---
a/drivers/leds/ledtrig-backlight.c~leds-add-output-inversion-option-to-backlight-trigger-fix
+++ a/drivers/leds/ledtrig-backlight.c
@@ -65,7 +65,7 @@ static ssize_t bl_trig_invert_show(struc
struct led_classdev *led = dev_get_drvdata(dev);
struct bl_trig_notifier *n = led-trigger_data;
- return sprintf(buf, %s\n, n-invert ? yes : no);
+ return sprintf(buf, %u\n, n-invert);
}
static ssize_t bl_trig_invert_store(struct device *dev,
@@ -73,16 +73,17 @@ static ssize_t bl_trig_invert_store(stru
{
struct led_classdev *led = dev_get_drvdata(dev);
struct bl_trig_notifier *n = led-trigger_data;
- unsigned invert;
+ unsigned long invert;
int ret;
- ret = sscanf(buf, %u, invert);
- if (ret 1) {
- dev_err(dev, invalid value\n);
+ ret = strict_strtoul(buf, 10, invert);
+ if (ret 0)
+ return ret;
+
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote: We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny. So, I give up at this point with the OMAP4430SDP board. It's not worth spending the time with this kind of unreliability. To top it off, the crappy 3rd party ftdi_sio driver I have to use for the SDP board just oopsed my x86 kernel. Do you get the impression that if something can go wrong, it will go wrong... I think I'll leave the 4430SDP alone until I have more patience for it. I might see about setting up the ARM Realview platform as a remote terminal for the 4430SDP so at least these kinds of crashes don't take out my work machine. -- 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: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote: On Thu, 9 Dec 2010 14:41:50 +0100 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store); This new sysfs file should be documented. Where would be an appropriate place for that? Documentation/leds-class.txt doesn't mention a sysfs API at all. -- in Documentation/ABI/, where all sysfs interface info lives. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
On Thu, 6 Jan 2011 13:08:56 -0800 Randy Dunlap randy.dun...@oracle.com wrote: On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote: On Thu, 9 Dec 2010 14:41:50 +0100 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store); This new sysfs file should be documented. Where would be an appropriate place for that? Documentation/leds-class.txt doesn't mention a sysfs API at all. -- in Documentation/ABI/, where all sysfs interface info lives. Spose so. Documentation/ABI/stable/sysfs-class-backlight does have some stuff in it. Personally I tend to regard Documentation/ABI/ as fairly useless incomprehensible stuff, maintained to keep Greg happy ;) It'd be better to have a nice little well-maintained document for a subsystem such as this which actually explains its operation in a useful-to-humans way. Rather than just mechanically filling out forms. But a Documentation/ABI update is a heck of a lot better than nothing. -- 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: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
On 01/06/11 13:16, Andrew Morton wrote: On Thu, 6 Jan 2011 13:08:56 -0800 Randy Dunlap randy.dun...@oracle.com wrote: On Thu, 6 Jan 2011 13:04:40 -0800 Andrew Morton wrote: On Thu, 9 Dec 2010 14:41:50 +0100 Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store); This new sysfs file should be documented. Where would be an appropriate place for that? Documentation/leds-class.txt doesn't mention a sysfs API at all. -- in Documentation/ABI/, where all sysfs interface info lives. Spose so. Documentation/ABI/stable/sysfs-class-backlight does have some stuff in it. Personally I tend to regard Documentation/ABI/ as fairly useless incomprehensible stuff, maintained to keep Greg happy ;) It'd be better to have a nice little well-maintained document for a subsystem such as this which actually explains its operation in a useful-to-humans way. Rather than just mechanically filling out forms. But a Documentation/ABI update is a heck of a lot better than nothing. Yes, I was giving you the where it currently lives, not what is best. I agree with you. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the usb tree with the omap tree
Nishanth Menon n...@ti.com writes: Kevin Hilman had written, on 01/06/2011 12:38 PM, the following: [..] Feel free to break it up if you prefer, but IMO it would be mergable as just for the record, posted the same here: http://marc.info/?l=linux-omapm=129434370207879w=2 Thanks, and this is even more mergable. :) 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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote: On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote: On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: Why? It's not like hwmon has an unreasonably large core or similar. Because it creates an unnecessary dependency, and because it is not hwmon's responsibility to provide infrastructure for other subsystems or drivers. hwmon isn't really doing anything, though. The *driver* is doing something but it doesn't really impact the core that much. Not that I'm particularly sold on putting the ADC core in here, but total NACK based on that alone seems rather harsh. Possibly. However, I had suggested the following earlier (to the 1st version of the patch): I commented on this a couple of times below - the driver mixes generic ADC reading functions with hwmon functionality. Generic ADC reading functionality should be moved into another driver, possibly to mfd. Obviously that was ignored. Maybe someone is willing to listen this time around. I won't let people break modularity just for convenience in a subsystem I am responsible for. And forcing the hwmon subsystem, and with it a specific hwmon driver, to exist just because the adc functionality it provides is needed by some other (most likely unrelated) subsystem / driver _does_ break modularity. Worse, it is completely unnecessary to do so. Other twl4030 functionality was extracted into generic code. twl-core.c, twl4030-codec.c, twl4030-irq.c, twl4030-power.c are all in mfd. I fail to see the problem with mfd/twl4030-adc.c. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: mux: fix buffer overrun
* Aaro Koskinen aaro.koski...@nokia.com [110105 08:39]:
memcpy() copies 8 bytes too much (omap_mux_entry vs. omap_mux). Correct
by replacing memcpy() with struct assignment, which is safer.
Thanks will queue as a fix after the merge window.
Tony
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/mux.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 17bd639..df8d2f2 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -893,7 +893,7 @@ static struct omap_mux * __init omap_mux_list_add(
return NULL;
m = entry-mux;
- memcpy(m, src, sizeof(struct omap_mux_entry));
+ entry-mux = *src;
#ifdef CONFIG_OMAP_MUX
if (omap_mux_copy_names(src, m)) {
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] OMAP3: beaglexm: GPIO fixes
Nishanth Menon n...@ti.com writes: Hi, As discussed in the threads: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/ http://marc.info/?t=12154003084r=1w=2 here is the split up series with commit message after discussion: http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21 Koen Kooi (3): omap3: beaglexm: fix EHCI power up GPIO dir omap3: beaglexm: fix DVI reset GPIO omap3: beaglexm: power on DVI arch/arm/mach-omap2/board-omap3beagle.c | 37 ++ 1 files changed, 32 insertions(+), 5 deletions(-) v3: split up the series, addressed review comments Thanks, queueing for the .38-rc cycle. Kevin v2: http://marc.info/?t=12927697792r=1w=2 Reenable the PMU stat LED v1: http://marc.info/?t=12917257101r=1w=2 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ASoC: DMIC: Adding the OMAP DMIC driver
On Thu, Jan 06, 2011 at 08:00:36AM -0600, David Lambert wrote:
@@ -103,6 +106,7 @@ config SND_OMAP_SOC_SDP4430
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_4430SDP
select SND_OMAP_SOC_MCPDM
select SND_SOC_TWL6040
+ select SND_SOC_DMIC
help
Say Y if you want to add support for SoC audio on Texas Instruments
SDP4430.
Any tweaks to specific machines should be done separately to adding the
new drivers.
+ struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
+ int ctrl, div_sel = -EINVAL;
+
+ if (div_id != OMAP_DMIC_CLKDIV)
+ return -ENODEV;
+
+ switch (dmic-clk_freq) {
+ case 1920:
+ if (div == 5)
+ div_sel = 0x1;
+ else if (div == 8)
+ div_sel = 0x0;
I suggested switch statements previously; you didn't comment on my
reply.
+static irqreturn_t omap_dmic_irq_handler(int irq, void *dev_id)
+{
+ struct omap_dmic *dmic = dev_id;
My comments on this function appear to have been mostly ignored also.
+ switch (rate) {
+ case 192000:
+ div = 5;
+ break;
+ default:
+ div = 8;
Shouldn't the default case be a case 96000?
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ break;
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ break;
Remove the empty cases, they're handled by the default.
+
+MODULE_AUTHOR(David Lambert dlamb...@ti.com);
+MODULE_DESCRIPTION(OMAP DMIC SoC Interface);
+MODULE_LICENSE(GPL);
As also previously noted you should have a MODULE_ALIAS.
--
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
