Re: [PATCH] OMAP: McBSP: Fix static function warning
On Wednesday 08 September 2010 06:23:43 ext G, Manjunath Kondaiah wrote: This patch fixes sparse warning due non declaration of static function sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol 'omap_mcbsp_st_info_volsw' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: alsa-de...@alsa-project.org Cc: Jarkko Nikula jhnik...@gmail.com Cc: Peter Ujfalusi peter.ujfal...@nokia.com Cc: Liam Girdwood l...@slimlogic.co.uk Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com The patch name could be ASoC: omap-mcbsp: ... Other than that: Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/2] input: CMA3000 Accelerometer driver
From d18a8425a427b97a372bfcd9018e89e93fcad486 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Thu, 26 Aug 2010 17:44:48 +0530 Subject: [PATCH] input: CMA3000 Accelerometer Driver This patch adds support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem and supports sysfs for configuration changes. This is V3 of patch, which fixes open source review comments Signed-off-by: Hemanth V heman...@ti.com Reviewed-by: Jonathan Cameron ji...@cam.ac.uk --- Documentation/input/cma3000_d0x.txt | 112 ++ drivers/input/misc/Kconfig | 25 ++ drivers/input/misc/Makefile |2 + drivers/input/misc/cma3000_d0x.c | 632 ++ drivers/input/misc/cma3000_d0x.h | 53 +++ drivers/input/misc/cma3000_d0x_i2c.c | 144 include/linux/input/cma3000.h| 60 7 files changed, 1028 insertions(+), 0 deletions(-) create mode 100644 Documentation/input/cma3000_d0x.txt create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/input/cma3000.h diff --git a/Documentation/input/cma3000_d0x.txt b/Documentation/input/cma3000_d0x.txt new file mode 100644 index 000..29ab6b7 --- /dev/null +++ b/Documentation/input/cma3000_d0x.txt @@ -0,0 +1,112 @@ +Kernel driver for CMA3000-D0x + + +Supported chips: +* VTI CMA3000-D0x +Datasheet: + CMA3000-D0X Product Family Specification 8281000A.02.pdf + +Author: Hemanth V heman...@ti.com + + +Description +--- +CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and +Free fall modes. + +Motion Detect Mode: Its the low power mode where interrupts are generated only +when motion exceeds the defined thresholds. + +Measurement Mode: This mode is used to read the acceleration data on X,Y,Z +axis and supports 400, 100, 40 Hz sample frequency. + +Free fall Mode: This mode is intented to save system resources. + +Threshold values: Chip supports defining threshold values for above modes +which includes time and g value. Refer product specifications for more details. + +CMA3000 supports both I2C/SPI bus for communication, currently the driver +supports I2C based communication. + +Driver reports acceleration data through input subsystem and supports sysfs +for configuration changes. It generates ABS_MISC event with value 1 when +free fall is detected. + +Platform data need to be configured for initial default values. + +Platform Data +- +fuzz_x: Noise on X Axis + +fuzz_y: Noise on Y Axis + +fuzz_z: Noise on Z Axis + +g_range: G range in milli g i.e 2000 or 8000 + +mode: Default Operating mode + +mdthr: Motion detect threshold value + +mdfftmr: Motion detect and free fall time value + +ffthr: Free fall threshold value + +Input Interface +-- +Input driver version is 1.0.0 +Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 +Input device name: cma3000-acclerometer +Supported events: + Event type 0 (Sync) + Event type 3 (Absolute) +Event code 0 (X) + Value 47 + Min-8000 + Max 8000 + Fuzz 200 +Event code 1 (Y) + Value-28 + Min-8000 + Max 8000 + Fuzz 200 +Event code 2 (Z) + Value905 + Min-8000 + Max 8000 + Fuzz 200 +Event code 40 (Misc) + Value 0 + Min0 + Max1 + Event type 4 (Misc) + +Sysfs entries +- + +mode: + 0: power down mode + 1: 100 Hz Measurement mode + 2: 400 Hz Measurement mode + 3: 40 Hz Measurement mode + 4: Motion Detect mode (default) + 5: 100 Hz Free fall mode + 6: 40 Hz Free fall mode + 7: Power off mode + +grange: + 2000: 2000 mg or 2G Range + 8000: 8000 mg or 8G Range + +mdthr: + X: X * 71mg (8G Range) + X: X * 18mg (2G Range) + +mdfftmr: + X: (X 0x70) * 100 ms (MDTMR) + (X 0x0F) * 2.5 ms (FFTMR 400 Hz) + (X 0x0F) * 10 ms (FFTMR 100 Hz) + +ffthr: + X: (X 2) * 18mg (2G Range) + X: (X 0x0F) * 71 mg (8G Range) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index b49e233..8d718a5 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -438,4 +438,29 @@ config INPUT_ADXL34X_SPI To compile this driver as a module, choose M here: the module will be called adxl34x-spi. +config INPUT_CMA3000 + tristate VTI CMA3000 Tri-axis accelerometer + default n + help + Say Y here if you want to use VTI CMA3000_D0x Accelerometer + driver + + This driver currently only supports I2C interface to the +
[PATCH V3 2/2] omap4: platform changes for CMA3000
From 8082870cc704d901d98cf0d6af90e45860927ceb Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Thu, 26 Aug 2010 17:49:12 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver
Update 4430 SDP board file with platform data for accelerometer driver
and select the driver in kconfig
Signed-off-by: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/Kconfig |2 ++
arch/arm/mach-omap2/board-4430sdp.c | 30 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a928fd6..e87c049 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -255,6 +255,8 @@ config MACH_OMAP_4430SDP
depends on ARCH_OMAP4
select INPUT_TOUCHSCREEN
select TOUCHSCREEN_SYNTM12XX
+ select INPUT_MISC
+ select INPUT_CMA3000_I2C
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ed78cdb..8b94f1f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,8 @@
#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
+#include linux/i2c/cma3000.h
+#include linux/interrupt.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -44,6 +46,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4SDP_MDM_PWR_EN_GPIO 157
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_CMA3000ACCL_GPIO 186
#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
@@ -485,6 +488,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3 = sdp4430_vaux3,
};
+static struct cma3000_platform_data cma3000_platform_data = {
+ .fuzz_x = 25,
+ .fuzz_y = 25,
+ .fuzz_z = 25,
+ .g_range = CMARANGE_8G,
+ .mode = CMAMODE_MOTDET,
+ .mdthr = 0x8,
+ .mdfftmr = 0x33,
+ .ffthr = 0x8,
+ .irqflags = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+ if (gpio_request(OMAP4_CMA3000ACCL_GPIO, Accelerometer) 0) {
+ pr_err(Accelerometer GPIO request failed\n);
+ return;
+ }
+ gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl6030, 0x48),
@@ -518,6 +542,11 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO(hmc5843, 0x1e),
},
+ {
+ I2C_BOARD_INFO(cma3000_accl, 0x1c),
+ .platform_data = cma3000_platform_data,
+ .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+ },
};
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
@@ -570,6 +599,7 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
}
+ omap_cma3000accl_init();
}
static void __init omap_4430sdp_init(void)
--
1.5.4.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: [RESEND/PATCH 0/6] USB: musb-gadget: bug fix
On Wed, Sep 08, 2010 at 12:32:19PM +0800, Ming Lei wrote: CC Felipe / David / Gadiyar / Mike / Sergei 2010/9/8 Greg KH g...@kroah.com: I seem to not have 1/6 here, did it get stuck somewhere? Here is 1/6: http://marc.info/?l=linux-usbm=128387307419605w=2 If you need, I can send the 1/6 to you directly. No need, I'll wait for Felipe to send them to me :) Anyway, I need Felipe's ack before I can accept these. Felipe, expect your comments on the patch set... BTW: The mailbox of felipe.ba...@nokia.com in MAINTAINERS has been obsolete now, and his current box is m...@felipebalbi.com, seems MAINTAINERS should be updated for it. Someone should send me a patch... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe 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] tracing, perf: add more power related events
* Jean Pihet jean.pi...@newoldbits.com wrote: Hi, Here is a patch proposal for adding new trace events for power management. Note: thread restarted after the initial discussions on LKML. Also mind including the ACPI tracepoints we talked about? That way a lot more people could test it, etc. Ingo -- To unsubscribe from this list: send the line unsubscribe 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: Fix CONFIG_LOCAL_TIMERS initialization for multi-omap
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, September 08, 2010 8:48 AM
To: Russell King - ARM Linux
Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org;
bryan...@canonical.com
Subject: [PATCH] omap: Fix CONFIG_LOCAL_TIMERS initialization for multi-
omap
Fix CONFIG_LOCAL_TIMERS initialization for multi-omap
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-
gp.c
index 74fbed8..5a3e606 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -228,8 +228,10 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
#ifdef CONFIG_LOCAL_TIMERS
- twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
- BUG_ON(!twd_base);
+ if (cpu_is_omap44xx()) {
+ twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
+ BUG_ON(!twd_base);
+ }
#endif
omap_dm_timer_init();
Acked-By: Santosh Shilimkar santosh.shilim...@ti.com
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] OMAP: McBSP: Fix static function warning
On Wed, 8 Sep 2010 09:03:09 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: On Wednesday 08 September 2010 06:23:43 ext G, Manjunath Kondaiah wrote: This patch fixes sparse warning due non declaration of static function sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol 'omap_mcbsp_st_info_volsw' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: alsa-de...@alsa-project.org Cc: Jarkko Nikula jhnik...@gmail.com Cc: Peter Ujfalusi peter.ujfal...@nokia.com Cc: Liam Girdwood l...@slimlogic.co.uk Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com The patch name could be ASoC: omap-mcbsp: ... Other than that: Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com Yep, name should start with ASoC. Acked-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: Don't try to send IPI on UP systems with CONFIG_SMP
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Wednesday, September 08, 2010 8:44 AM
To: Russell King - ARM Linux
Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org;
bryan...@canonical.com
Subject: [PATCH] ARM: Don't try to send IPI on UP systems with CONFIG_SMP
This is not needed on UP. Additionally with will cause issues when
booting CONFIG_SMP_ON_UP kernel on earlier ARM cores.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 401e38b..5facdbe 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -207,9 +207,7 @@ __setup(reboot=, reboot_setup);
void machine_shutdown(void)
{
-#ifdef CONFIG_SMP
smp_send_stop();
-#endif
}
void machine_halt(void)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 40dc74f..16ca27b 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -560,12 +560,17 @@ asmlinkage void __exception do_IPI(struct pt_regs
*regs)
void smp_send_reschedule(int cpu)
{
- send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
+ if (is_smp())
+ send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
}
void smp_send_stop(void)
{
cpumask_t mask = cpu_online_map;
+
+ if (!is_smp())
+ return;
+
cpu_clear(smp_processor_id(), mask);
send_ipi_message(mask, IPI_CPU_STOP);
}
The IPI is called too many times, and a check in this path
might be an overhead.
Can we runtime make smp_send_reschedule etc NULL based
on it's UP or SMP boot ?
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 0/6] ARM: l2x0: kexex, cleanup and optimisation
-Original Message- From: Linus Walleij [mailto:linus.ml.wall...@gmail.com] Sent: Tuesday, September 07, 2010 11:49 PM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com; t...@linutronix.de; linux-omap@vger.kernel.org; per.xx.frans...@stericsson.com Subject: Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation 2010/9/7 Santosh Shilimkar santosh.shilim...@ti.com: This series is just repost adding Catalin's ack to the patches and combining Thomas's two rebased kexec patches. It's generated against the mainline 2.6.36-rc3 + Catalin's [PATCH 0/9] Various patches for 2.6.37-rc1 series. Santosh Shilimkar (4): omap4: l2x0: Override the default l2x0_disable ARM: l2x0: Fix coding-style in the cache-l2x0.h ARM: l2x0: Determine the cache size ARM: l2x0: Optimise the range based operations Thomas Gleixner (2): arm: Disable outer (L2) cache in kexec arm: Implement l2x0 cache disable functions FWIW: Acked-by: Linus Walleij linus.wall...@stericsson.com Thanks !! Can you also include the patch by Per Fransson I sent off to Thomas and the list just a few days ago with the subject [PATCH] ARM: ux500 specific L2 cache code in this patch series? Basically I plan to push all these patches to RMK's patch system after getting his OK. I can push your patch along with that. Is that ok with you ? 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 0/5] usb: omap: prepare for OMAP4 EHCI and OHCI support
-Original Message- From: Munegowda, Keshava Sent: Wednesday, August 18, 2010 8:26 AM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava Subject: [PATCH 0/5] usb: omap: prepare for OMAP4 EHCI and OHCI support This series does minor code cleanup in preparation of an upcoming series to add support for EHCI and OHCI on the OMAP4 SoC. The changes are: - Rename clock names to be consistent across OMAP3 and OMAP4 - Remove hardcoding of the number of TLL channels - Move PHY reset earlier in the init sequence These patches do not make any changes to existing functionalities. Diffstat is below: drivers/usb/host/ehci-omap.c | 104 - drivers/usb/host/ohci-omap3.c | 55 ++--- 2 files changed --- Keshava These are minor patches required for the adding omap4 support for EHCI and OHCI in near feature. Requesting for merge to the current merge window, so that the next set of EHCI and OHCI specific changes will be aligned with this patch set. Keshava Munegowda -- To unsubscribe from this list: send the line unsubscribe 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] OMAP:DSS: RFC Patch to add HDMI DSS driver support
On Wed, 2010-09-08 at 06:46 +0200, ext K, Mythri P wrote: Hi Tomi, I have introduced these in the display.h , do you suggest adding prefix like omapdss_hdmi* for all these functions ? Neither of the two HDMI patches you sent modify display.h... Yes, if you export functions from DSS they should be prefixed, as they are global functions. I shall correct the function names. Yes this is just a RFC patch to introduce the HDMI driver and panel as such, if you have no other comments on these 2 patch set I shall incorporate these comments and send out the complete patch series with all the relevant changes in display.h and some overlay.c and manager.c changes. Please don't send incomplete patch sets. It's a waste of reviewer's time to try to review patches that are missing components, or are based on custom kernel. Also make sure checkpatch.pl doesn't give any (or just a few) warnings/errors. Or, if you really want to send an incomplete RFC patch set with errors, make it very clear in the introduction. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Tuesday, September 07, 2010 5:18 PM To: Kevin Hilman Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh; Sawant, Anand Subject: RE: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 04, 2010 4:20 AM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Shilimkar, Santosh; Sawant, Anand Subject: Re: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver G, Manjunath Kondaiah manj...@ti.com writes: If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? Reviewed. Still a long ways to go..., also I didn't see you address the typo pointed out by Mika Westerberg on PATCH 03/11. Sorry. I fixed it in my internal version and forgot to take that change. Thanks for pointing this. It is not mistake. I was cross checking the review comments and Mika Westerberg comment is for v2 version of 03/11 patch and your review is also for v2 version of the series hence Mika Westerberg comments will get addressed in v3 series. -Manjunath-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] usb: omap: prepare for OMAP4 EHCI and OHCI support
On Wed, Sep 08, 2010 at 01:21:04PM +0530, Munegowda, Keshava wrote: -Original Message- From: Munegowda, Keshava Sent: Wednesday, August 18, 2010 8:26 AM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava Subject: [PATCH 0/5] usb: omap: prepare for OMAP4 EHCI and OHCI support This series does minor code cleanup in preparation of an upcoming series to add support for EHCI and OHCI on the OMAP4 SoC. The changes are: - Rename clock names to be consistent across OMAP3 and OMAP4 - Remove hardcoding of the number of TLL channels - Move PHY reset earlier in the init sequence These patches do not make any changes to existing functionalities. Diffstat is below: drivers/usb/host/ehci-omap.c | 104 - drivers/usb/host/ohci-omap3.c | 55 ++--- 2 files changed --- Keshava These are minor patches required for the adding omap4 support for EHCI and OHCI in near feature. Do I already have them in my git tree? Did I forward them to Linus already? Requesting for merge to the current merge window, so that the next set of EHCI and OHCI specific changes will be aligned with this patch set. What do you mean by current? The merge window for .36 is closed now. It's bugfixes-only at the moment. But I can easily queue up stuff for .37 if you want to resend these. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe 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: McBSP: Fix static function warning
On Wed, Sep 08, 2010 at 08:53:43AM +0530, G, Manjunath Kondaiah wrote: This patch fixes sparse warning due non declaration of static function sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol 'omap_mcbsp_st_info_volsw' was not declared. Should it be static? Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: McBSP: Fix static function warning
On Wed, 2010-09-08 at 08:53 +0530, G, Manjunath Kondaiah wrote:
This patch fixes sparse warning due non declaration of static function
sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol 'omap_mcbsp_st_info_volsw'
was not declared. Should it be static?
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: alsa-de...@alsa-project.org
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
sound/soc/omap/omap-mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 86f2139..5768381 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -780,7 +780,7 @@ struct snd_soc_dai omap_mcbsp_dai[] = {
EXPORT_SYMBOL_GPL(omap_mcbsp_dai);
-int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
+static int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
struct soc_mixer_control *mc =
Applied.
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
--
To unsubscribe from this list: send the line unsubscribe 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/2] OMAP: DSS2: Introduce dss_features files
Add dss_features.c and dss_features.h for the dss_features framework
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss_features.c | 171
drivers/video/omap2/dss/dss_features.h | 51 ++
2 files changed, 222 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/dss_features.c
create mode 100644 drivers/video/omap2/dss/dss_features.h
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
new file mode 100644
index 000..e87816f
--- /dev/null
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -0,0 +1,171 @@
+/*
+ * linux/drivers/video/omap2/dss/dss_features.c
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Archit Taneja arc...@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.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/display.h
+#include plat/cpu.h
+
+#include dss_features.h
+
+/* Defines a generic omap register field */
+struct dss_reg_field {
+ enum dss_feat_reg_field id;
+ u8 start, end;
+};
+
+struct omap_dss_features {
+ struct dss_reg_field reg_fields[MAX_DSS_REG_FIELDS];
+ u32 has_feature;
+
+ int num_mgrs;
+ int num_ovls;
+ enum omap_display_type supported_displays[MAX_DSS_MANAGERS];
+ enum omap_color_mode supported_color_modes[MAX_DSS_OVERLAYS];
+};
+
+/* This struct is assigned to one of the below during initialization */
+static struct omap_dss_features omap_current_dss_features;
+
+/* OMAP2 DSS Features */
+static struct omap_dss_features omap2_dss_features = {
+ .reg_fields = {
+ {FIRHINC, 11, 0},
+ {FIRVINC, 27, 16},
+ {FIFOLOWTHRESHOLD, 8, 0},
+ {FIFOHIGHTHRESHOLD, 24, 16},
+ {FIFOSIZE, 8, 0},
+ },
+
+ .num_mgrs = 2,
+ .num_ovls = 3,
+ .supported_displays = {
+ /* OMAP_DSS_CHANNEL_LCD */
+ OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+ OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
+
+ /* OMAP_DSS_CHANNEL_DIGIT */
+ OMAP_DISPLAY_TYPE_VENC,
+ },
+ .supported_color_modes = {
+ /* OMAP_DSS_GFX */
+ OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
+ OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
+ OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
+ OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P,
+
+ /* OMAP_DSS_VIDEO1 */
+ OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
+ OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
+ OMAP_DSS_COLOR_UYVY,
+
+ /* OMAP_DSS_VIDEO2 */
+ OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
+ OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
+ OMAP_DSS_COLOR_UYVY,
+ },
+};
+
+/* OMAP3 DSS Features */
+static struct omap_dss_features omap3_dss_features = {
+ .reg_fields = {
+ {FIRHINC, 12, 0},
+ {FIRVINC, 28, 16},
+ {FIFOLOWTHRESHOLD, 11, 0},
+ {FIFOHIGHTHRESHOLD, 27, 16},
+ {FIFOSIZE, 10, 0},
+ },
+ .has_feature= FEAT_GLOBAL_ALPHA,
+
+ .num_mgrs = 2,
+ .num_ovls = 3,
+ .supported_displays = {
+ /* OMAP_DSS_CHANNEL_LCD */
+ OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+ OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
+
+ /* OMAP_DSS_CHANNEL_DIGIT */
+ OMAP_DISPLAY_TYPE_VENC,
+ },
+ .supported_color_modes = {
+ /* OMAP_DSS_GFX */
+ OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
+ OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
+ OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_ARGB16 |
+ OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
+ OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_ARGB32 |
+ OMAP_DSS_COLOR_RGBA32 | OMAP_DSS_COLOR_RGBX32,
+
+ /* OMAP_DSS_VIDEO1 */
+ OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P |
+ OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
+ OMAP_DSS_COLOR_YUV2 | OMAP_DSS_COLOR_UYVY,
+
+ /* OMAP_DSS_VIDEO2 */
+ OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_ARGB16
[PATCH v2 0/2] OMAP: DSS2: Framework to handle omap version specific DSS features
This is a simple approach to prevent scattered cpu_is_omap checks in DSS2 by bringing all omap version specific DSS features/values to one single place, initialize them and expose a set of functions to DSS2 driver files which return the value/existance of a feature. This method provides the following: -A set of functions which give the value of a feature. -Functions which add and return the start and end bits of a register field which varies across omaps. -A function which checks if a DSS2 feature exists or not on the present omap (omap_dss_has_feature) Whenever a new DSS feature is introduced, its value/existance is specified for all omaps in omap_dss_feature_init(). This patch also fills up a minimal list of features in omap_dss_features_init(). The second patch in the series makes use of dss_features to remove some of the existing omap checks. Archit Taneja (2): OMAP: DSS2: Introduce dss_features files OMAP: DSS2: Use dss_features framework on DSS2 code arch/arm/plat-omap/include/plat/display.h | 31 - drivers/video/omap2/dss/Makefile |2 +- drivers/video/omap2/dss/core.c|3 + drivers/video/omap2/dss/dispc.c | 56 + drivers/video/omap2/dss/dss_features.c| 171 + drivers/video/omap2/dss/dss_features.h| 51 + drivers/video/omap2/dss/manager.c | 33 +++--- drivers/video/omap2/dss/overlay.c | 24 ++--- 8 files changed, 283 insertions(+), 88 deletions(-) create mode 100644 drivers/video/omap2/dss/dss_features.c create mode 100644 drivers/video/omap2/dss/dss_features.h -- Version 2: - Features are initialized statically as opposed to runtime before, function naming for dss_features files has changed. Version 1: https://patchwork.kernel.org/patch/134431/ -- To unsubscribe from this list: send the line unsubscribe 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 1/2] input: CMA3000 Accelerometer driver
Hi Hemanth, I know this is rather late in the process, but I thought I'd just like to make a few suggestions in for possibly clearer interfaces (sysfs) - platform data is fine as is because a board designer can look up the data sheet or documentation. I'm not particularly bothered if you do anything about these now, it's just that they may be worth considering in future (we can support the current ones as well). Oddly enough I've run into lots of issues with trying to come up with generic names for various sysfs parameters as part of IIO design work (some things you have here we still haven't pinned down). ... + +Sysfs entries +- + +mode: + 0: power down mode + 1: 100 Hz Measurement mode + 2: 400 Hz Measurement mode + 3: 40 Hz Measurement mode + 4: Motion Detect mode (default) + 5: 100 Hz Free fall mode + 6: 40 Hz Free fall mode + 7: Power off mode Could break this internal parameter up into a couple of attributes to make it easier to understand (and get rid of the magic numbers. The brackets are used to indicate what mode we are currently in. mode: powerdown [measurement] motiondetect freefall poweroff frequency: 400 [100] 40 (prevent it changing to 400 if we are in free fall mode or even better don't list it as an option. - if people want to configure motion detection, they may have to elect to power down first make relevant settings and power up again) Yes there are nasty corner cases with this approach, but it does get rid of the magic numbers in the original interface. + +grange: + 2000: 2000 mg or 2G Range + 8000: 8000 mg or 8G Range + +mdthr: + X: X * 71mg (8G Range) + X: X * 18mg (2G Range) Sometimes saving characters in a name is a bad idea. motion_detector_threshold would make things clearer. I'd also personally loose the magic multipliers and make it in milli g like your grange above. Obviously things will get a little fiddly if the grange changes. + +mdfftmr: + X: (X 0x70) * 100 ms (MDTMR) +(X 0x0F) * 2.5 ms (FFTMR 400 Hz) +(X 0x0F) * 10 ms (FFTMR 100 Hz) detector_period or something like that and again it would be much nicer to have this in say milliseconds. Again you'd probably need an in driver cache and to update things appropriately if the frequency is changed. I have no idea if this interpreted the same for freefall and motion detection. If it isn't make it two separate attributes to reduce confusion. (with appropriate caching in driver to ensure the right one is written before a mode change). + +ffthr: + X: (X 2) * 18mg (2G Range) + X: (X 0x0F) * 71 mg (8G Range) Again, this would be better in milli g. ... Just some suggestions. I still think the driver is more or less fine as is, but if Dmitry is going to take more accelerometer drivers some of these interfaces will want to be more easily generalized. Naturally I'm biased and think what we have for IIO is the one true way :) Note that we have to cover a much wider range of devices so some of our choices are more complex / involved than may be needed for a narrow set of devices. Note the event naming is currently in flux (as few of our drivers have supported these elements we have be concentrating on other parts). I'll be proposing a clearer scheme shortly (including the mag variant given here). In that case you would have. grange-accel_calibscale + accel_calibscale_available (to tell you what is valid). (there is some debate on whether to use the list approach I suggested above for a restricted case like this). mdthr-accel_mag_rising_value ffthr- free_fall_value? (we don't have this one yet - would need to think about this, it might correspond to accel_mag_falling_value) mdfftmr- accel_mag_rising_period, free_fall_period mode would be effectively covered by whether the following are enabled (and enabling one will disable the other). accel_mag_rising_en free_fall_en sampling_frequency (with sampling_frequency_available) The power down and power off modes are device specific - either runtime power management, or a non standard attribute. This may all seem overly complex, but it does give us an interface we can generalize to pretty much any similar device in a consistent manor (so far!) I'm happy to see your driver go in as it is currently, what bothers me is that we will end up with incompatible interfaces for all the accelerometers Dmitry takes! Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
2010/9/8 Shilimkar, Santosh santosh.shilim...@ti.com: Basically I plan to push all these patches to RMK's patch system after getting his OK. I can push your patch along with that. Is that ok with you ? Yep seems like a plan, thanks! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patch to fix swapping of front and back porches when reading from modedb.c
On Wed, Sep 8, 2010 at 6:39 AM, Tasslehoff Kjappfot tasskj...@gmail.com wrote: Hi list :-) I had trouble getting a standard 800x...@60hz VGA signal to display correctly on my monitors. Measuring the output showed that the front and back porches were swapped both for hsync and vsync. After reading the source I think I found the error in drivers/video/omap2/omapfb/omapfb-main.c. Patch attached. http://www.xfree86.org/3.3.6/fbdev6.html shows the way it should be, but todays code sets: hfp = left margin hbp = right margin vfp = upper margin vbp = lower margin I tested a patched kernel with 800x...@60hz on two different monitors and a vga grabber, and it solved my issues. This looks good. Before this came up, I also thought that front porch meant left margin, and back porch meant margin, but margins are named in relation to pixel data, and porches are named in relation to sync pulses. You might want to add a Signed-off-by line Reviewed-by: russ.d...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 1/2] input: CMA3000 Accelerometer driver
-Original Message- From: linux-input-ow...@vger.kernel.org [mailto:linux-input- ow...@vger.kernel.org] On Behalf Of V, Hemanth Sent: Wednesday, September 08, 2010 1:18 AM To: linux-in...@vger.kernel.org; dmitry.torok...@gmail.com Cc: linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Subject: [PATCH V3 1/2] input: CMA3000 Accelerometer driver From d18a8425a427b97a372bfcd9018e89e93fcad486 Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Thu, 26 Aug 2010 17:44:48 +0530 Subject: [PATCH] input: CMA3000 Accelerometer Driver This patch adds support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem and supports sysfs for configuration changes. This is V3 of patch, which fixes open source review comments Signed-off-by: Hemanth V heman...@ti.com Reviewed-by: Jonathan Cameron ji...@cam.ac.uk --- Documentation/input/cma3000_d0x.txt | 112 ++ drivers/input/misc/Kconfig | 25 ++ drivers/input/misc/Makefile |2 + drivers/input/misc/cma3000_d0x.c | 632 ++ drivers/input/misc/cma3000_d0x.h | 53 +++ drivers/input/misc/cma3000_d0x_i2c.c | 144 include/linux/input/cma3000.h| 60 7 files changed, 1028 insertions(+), 0 deletions(-) create mode 100644 Documentation/input/cma3000_d0x.txt create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/input/cma3000.h diff --git a/Documentation/input/cma3000_d0x.txt b/Documentation/input/cma3000_d0x.txt new file mode 100644 index 000..29ab6b7 --- /dev/null +++ b/Documentation/input/cma3000_d0x.txt @@ -0,0 +1,112 @@ +Kernel driver for CMA3000-D0x + + +Supported chips: +* VTI CMA3000-D0x +Datasheet: + CMA3000-D0X Product Family Specification 8281000A.02.pdf + +Author: Hemanth V heman...@ti.com + + +Description +--- +CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and +Free fall modes. + +Motion Detect Mode: Its the low power mode where interrupts are generated only +when motion exceeds the defined thresholds. + +Measurement Mode: This mode is used to read the acceleration data on X,Y,Z +axis and supports 400, 100, 40 Hz sample frequency. + +Free fall Mode: This mode is intented to save system resources. + +Threshold values: Chip supports defining threshold values for above modes +which includes time and g value. Refer product specifications for more details. + +CMA3000 supports both I2C/SPI bus for communication, currently the driver +supports I2C based communication. + +Driver reports acceleration data through input subsystem and supports sysfs +for configuration changes. It generates ABS_MISC event with value 1 when +free fall is detected. + +Platform data need to be configured for initial default values. + +Platform Data +- +fuzz_x: Noise on X Axis + +fuzz_y: Noise on Y Axis + +fuzz_z: Noise on Z Axis + +g_range: G range in milli g i.e 2000 or 8000 + +mode: Default Operating mode + +mdthr: Motion detect threshold value + +mdfftmr: Motion detect and free fall time value + +ffthr: Free fall threshold value + +Input Interface +-- +Input driver version is 1.0.0 +Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 +Input device name: cma3000-acclerometer +Supported events: + Event type 0 (Sync) + Event type 3 (Absolute) +Event code 0 (X) + Value 47 + Min-8000 + Max 8000 + Fuzz 200 +Event code 1 (Y) + Value-28 + Min-8000 + Max 8000 + Fuzz 200 +Event code 2 (Z) + Value905 + Min-8000 + Max 8000 + Fuzz 200 +Event code 40 (Misc) + Value 0 + Min0 + Max1 + Event type 4 (Misc) + +Sysfs entries +- + +mode: + 0: power down mode + 1: 100 Hz Measurement mode + 2: 400 Hz Measurement mode + 3: 40 Hz Measurement mode + 4: Motion Detect mode (default) + 5: 100 Hz Free fall mode + 6: 40 Hz Free fall mode + 7: Power off mode + +grange: + 2000: 2000 mg or 2G Range + 8000: 8000 mg or 8G Range + +mdthr: + X: X * 71mg (8G Range) + X: X * 18mg (2G Range) + +mdfftmr: + X: (X 0x70) * 100 ms (MDTMR) +(X 0x0F) * 2.5 ms (FFTMR 400 Hz) +(X 0x0F) * 10 ms (FFTMR 100 Hz) + +ffthr: + X: (X 2) * 18mg (2G Range) + X: (X 0x0F) * 71 mg (8G Range) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index b49e233..8d718a5
[PATCH] omap: OMAP_IOMMU not visible in menuconfig
The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote: Can you also include the patch by Per Fransson I sent off to Thomas and the list just a few days ago with the subject [PATCH] ARM: ux500 specific L2 cache code in this patch series? Basically I plan to push all these patches to RMK's patch system after getting his OK. I can push your patch along with that. Is that ok with you ? Or rather a pull request. AFAIK (unless this was fixed recently) the patch system doesn't handle the From: line to set the correct patch author. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote: On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote: Can you also include the patch by Per Fransson I sent off to Thomas and the list just a few days ago with the subject [PATCH] ARM: ux500 specific L2 cache code in this patch series? Basically I plan to push all these patches to RMK's patch system after getting his OK. I can push your patch along with that. Is that ok with you ? Or rather a pull request. AFAIK (unless this was fixed recently) the patch system doesn't handle the From: line to set the correct patch author. Oh Yes... pull request-is also doable... I have all these patches pilled up here already ... http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-for-rmk Well, regarding my patches, I'm only OK for you to submit the cache-l2x0.c one named: ARM: Improve the L2 cache performance when PL310 is used The other patches I'll push separately. Thanks. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
-Original Message- From: Catalin Marinas [mailto:catalin.mari...@arm.com] Sent: Wednesday, September 08, 2010 8:56 PM To: Shilimkar, Santosh Cc: Linus Walleij; linux-arm-ker...@lists.infradead.org; t...@linutronix.de; linux-omap@vger.kernel.org; per.xx.frans...@stericsson.com Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote: On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote: Can you also include the patch by Per Fransson I sent off to Thomas and the list just a few days ago with the subject [PATCH] ARM: ux500 specific L2 cache code in this patch series? Basically I plan to push all these patches to RMK's patch system after getting his OK. I can push your patch along with that. Is that ok with you ? Or rather a pull request. AFAIK (unless this was fixed recently) the patch system doesn't handle the From: line to set the correct patch author. Oh Yes... pull request-is also doable... I have all these patches pilled up here already ... http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/l2x0-for-rmk Well, regarding my patches, I'm only OK for you to submit the cache-l2x0.c one named: ARM: Improve the L2 cache performance when PL310 is used The other patches I'll push separately. Sure. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, September 08, 2010 8:59 PM To: Catalin Marinas Cc: Linus Walleij; linux-arm-ker...@lists.infradead.org; t...@linutronix.de; linux-omap@vger.kernel.org; per.xx.frans...@stericsson.com Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation -Original Message- From: Catalin Marinas [mailto:catalin.mari...@arm.com] Sent: Wednesday, September 08, 2010 8:56 PM To: Shilimkar, Santosh Cc: Linus Walleij; linux-arm-ker...@lists.infradead.org; t...@linutronix.de; linux-omap@vger.kernel.org; per.xx.frans...@stericsson.com Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote: On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote: Can you also include the patch by Per Fransson I sent off to Thomas and the list just a few days ago with the subject [PATCH] ARM: ux500 specific L2 cache code in this patch series? Basically I plan to push all these patches to RMK's patch system after getting his OK. I can push your patch along with that. Is that ok with you ? Or rather a pull request. AFAIK (unless this was fixed recently) the patch system doesn't handle the From: line to set the correct patch author. Oh Yes... pull request-is also doable... I have all these patches pilled up here already ... http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/l2x0-for-rmk Well, regarding my patches, I'm only OK for you to submit the cache-l2x0.c one named: ARM: Improve the L2 cache performance when PL310 is used The other patches I'll push separately. Sure. Here is the updated branch including Per Fransson patch. http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk 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 0/6] ARM: l2x0: kexex, cleanup and optimisation
On Wed, 2010-09-08 at 16:46 +0100, Shilimkar, Santosh wrote: Here is the updated branch including Per Fransson patch. http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk It looks fine to me. -- Catalin -- To unsubscribe from this list: send the line unsubscribe 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] USB: otg: twl4030: fix phy initialization(v1)
Hi Ming Lei Balbi, Thanks for your support and the porblem is resolved. Venkii, On Tue, Sep 7, 2010 at 11:52 PM, venki kaps venkiece2...@gmail.com wrote: Venkii, On Tue, Sep 7, 2010 at 11:45 PM, venki kaps venkiece2...@gmail.com wrote: Venkii, On Tue, Sep 7, 2010 at 9:18 PM, venki kaps venkiece2...@gmail.com wrote: Venkii, On Tue, Sep 7, 2010 at 9:10 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: thanks for your good response. Venkii, On Tue, Sep 7, 2010 at 6:54 PM, Ming Lei tom.leim...@gmail.com wrote: 2010/9/7 venki kaps venkiece2...@gmail.com: Dear USB experts, Is the same fix valid for omap3430 + 2.6.32 Kernel? I have been facing mp3 playback idle current consumption 20mA more after booting without USB cable connected but If USB cable detach and attach happen, then able to hit proper values otherwise irrespective of cold/warm reset the current values increases to 20mA. with cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - SMART standby without cable, OTG_SYSCONFIG standby mode of operation - SMART idle HSOTGUSB_STANDBY - Active Even i have applied patch but still the same issue. Are you applying the patch below? http://marc.info/?l=linux-omapm=128378686221264w=2 The patch(USB: otg: twl4030: fix phy initialization(v1)) above is against 2.6.36-rc3, I don't think you can apply it directly on 2.6.32. And the patch is introduced to fix the problems caused by commit 461c317705eca5cac09a360f488715927fd0a927. which change is committed into mainline 2.6.36-rc3. Yes, this patch i have applied. If you applied the patch, I guess you may see __twl4030_phy_power(twl, 0) is called from .probe. If called, seems your description a little contradictory since you observed __twl4030_phy_power(twl, 0) may hit proper values, right? Yes, __twl4030_phy_power(twl, 0) - the current values are getting proper with or without cable. If not called, could you trace the return value of twl4030_usb_linkstat in twl4030_usb_phy_init? ok, i can do that and update. twl4030_usb_linkstat return value is zero (0) in both twl4030_usb_phy_init/twl4030_usb_irq. WIth twl4030_usb_phy_init, Everything is fine except battery temperature but surprisingly the temperature is fine with PC based usb cable charger and the problem is with travel adapter only. The temperature with TA effected due to the TWL4030 PHY power down on I2c(__twl4030_phy_power(twl, 0)). When TA connect to the phone the battery ADC is not reading proper values since already PHY power down. To resolve the above issue, we have made PHY power on in battery adc on function and PHY power down in battery adc off function. With the above change the problem is resolved. 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 1/2] OMAP2+: PM: initial runtime PM core support
On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.
In order to determine if a device is an omap_device, its parent device
is checked. All omap_devices have a new 'omap_bus' device as their
parent device, so checking for this parent is used to check for valid
omap_devices. If a device is an omap_device, then the appropriate
omap_device functions are called for it. If not, only the generic
runtime PM functions are called.
Device driver's -runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device. Driver's -runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver -runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)
OMAP4 build support from Rajendra Nayak rna...@ti.com.
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
It appears that this one will fail to compile when CONFIG_PM_RUNTIME is unset.
Once you've fixed that you can add my a-b line:
Acked-by: Grant Likely grant.lik...@secretlab.ca
I think this should go via Greg's tree to avoid ordering issues.
---
NOTE: this depends on the driver core patch from me:
[PATCH v2] driver core: platform_bus: allow runtime override of dev_pm_ops
which Greg KH has queued now for 2.6.37:
http://marc.info/?l=linux-kernelm=128276582108006w=2
arch/arm/mach-omap2/Makefile |8 +++-
arch/arm/mach-omap2/pm_bus.c | 82
++
2 files changed, 88 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..ba644c2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -50,13 +50,17 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
pm_bus.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o += -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..e85aced
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,82 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/mutex.h
+
+#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#ifdef CONFIG_PM_RUNTIME
+int omap_pm_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ int r, ret = 0;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ if (!ret dev-parent == omap_bus) {
+ r = omap_device_idle(pdev);
+ WARN_ON(r);
+ }
+
+ return ret;
+};
+
+int omap_pm_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ int r;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ if (dev-parent == omap_bus) {
+ r = omap_device_enable(pdev);
+ WARN_ON(r);
+ }
+
+ return pm_generic_runtime_resume(dev);
+};
+#endif /* CONFIG_PM_RUNTIME */
+
+static int __init omap_pm_runtime_init(void)
+{
+ const struct dev_pm_ops *pm;
+ struct dev_pm_ops *omap_pm;
+
+ pm = platform_bus_get_pm_ops();
+ if (!pm) {
+ pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+ if (!omap_pm) {
+ pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ omap_pm-runtime_suspend =
Re: [PATCH 2/2] OMAP1: PM: add simple runtime PM layer to manage clocks
On Tue, Sep 07, 2010 at 05:54:42PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
On OMAP1, we do not have omap_device + omap_hwmod to manage the
device-specific idle, enable and shutdown. Instead, just
enable/disable device clocks automatically at the runtime PM level.
This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the runtime PM API to manage clocks.
OMAP1 compile fixes Manjunatha GK manj...@ti.com
Cc: Manjunatha GK manj...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Also should go via Greg's tree.
g.
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/pm_bus.c | 98
++
2 files changed, 99 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap1/pm_bus.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index facfaeb..9a304d8 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_OMAP_MPU_TIMER)+= time.o
obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
# Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o
+obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
# DSP
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
new file mode 100644
index 000..c831348
--- /dev/null
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -0,0 +1,98 @@
+/*
+ * Runtime PM support code for OMAP1
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/mutex.h
+#include linux/clk.h
+#include linux/err.h
+
+#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#ifdef CONFIG_PM_RUNTIME
+static int omap1_pm_runtime_suspend(struct device *dev)
+{
+ struct clk *iclk, *fclk;
+ int ret = 0;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ fclk = clk_get(dev, fck);
+ if (!IS_ERR(fclk)) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+
+ iclk = clk_get(dev, ick);
+ if (!IS_ERR(iclk)) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+
+ return 0;
+};
+
+static int omap1_pm_runtime_resume(struct device *dev)
+{
+ int ret = 0;
+ struct clk *iclk, *fclk;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ iclk = clk_get(dev, ick);
+ if (!IS_ERR(iclk)) {
+ clk_enable(iclk);
+ clk_put(iclk);
+ }
+
+ fclk = clk_get(dev, fck);
+ if (!IS_ERR(fclk)) {
+ clk_enable(fclk);
+ clk_put(fclk);
+ }
+
+ return pm_generic_runtime_resume(dev);
+};
+
+static int __init omap1_pm_runtime_init(void)
+{
+ const struct dev_pm_ops *pm;
+ struct dev_pm_ops *omap_pm;
+
+ pm = platform_bus_get_pm_ops();
+ if (!pm) {
+ pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
+ __func__);
+ return -ENODEV;
+ }
+
+ omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+ if (!omap_pm) {
+ pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ omap_pm-runtime_suspend = omap1_pm_runtime_suspend;
+ omap_pm-runtime_resume = omap1_pm_runtime_resume;
+
+ platform_bus_set_pm_ops(omap_pm);
+
+ return 0;
+}
+core_initcall(omap1_pm_runtime_init);
+#endif /* CONFIG_PM_RUNTIME */
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
From: Greg KH [mailto:g...@kroah.com] On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote: This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know if there are any issues or concerns with this patch. Thanks, David Signed-off-by: David Cross david.cr...@cypress.com diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.0 -0700 +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.0 -0700 @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx; __raw_writel(val, reg_addr); } +EXPORT_SYMBOL(gpmc_cs_write_reg); EXPORT_SYMBOL_GPL() perhaps? I don't have an issue with that, though I am not sure I understand why we would want to limit the usage of the function to GPL'd modules. It is probably Tony's call assuming he is ok with exporting the symbol. What about platforms that don't have this symbol, how will the driver build properly then? The driver will require some sort of HAL to build, this is part of the reason for the Kconfig changes. They require a HAL to be selected before the driver can be included. A platform which does not have a gpmc specifically will have some method of configuring the memory interface to talk with an external chip. In that case, whatever functions are used for memory interface configuration will be used. Shouldn't something like this be in a arch-neutral place in the kernel tree? I don't think so, the inclusion of west bridge is architecture specific based on the need to configure an external memory interface to talk to it. Thanks, david --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. --- -- To unsubscribe from this list: send the line unsubscribe 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/2] OMAP2+: PM: initial runtime PM core support
Grant Likely grant.lik...@secretlab.ca writes:
On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.
In order to determine if a device is an omap_device, its parent device
is checked. All omap_devices have a new 'omap_bus' device as their
parent device, so checking for this parent is used to check for valid
omap_devices. If a device is an omap_device, then the appropriate
omap_device functions are called for it. If not, only the generic
runtime PM functions are called.
Device driver's -runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device. Driver's -runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver -runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)
OMAP4 build support from Rajendra Nayak rna...@ti.com.
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
It appears that this one will fail to compile when CONFIG_PM_RUNTIME
is unset. Once you've fixed that you can add my a-b line:
Thanks for catching this.
Acked-by: Grant Likely grant.lik...@secretlab.ca
I think this should go via Greg's tree to avoid ordering issues.
Not a strong preference, but I'd rather see this go via OMAP as we are
building on it in the OMAP tree for this merge window. The ordering
issues will only affect OMAP users and I have taken care of that in my
staging branches that other are using for their runtime PM conversions.
Kevin
---
NOTE: this depends on the driver core patch from me:
[PATCH v2] driver core: platform_bus: allow runtime override of dev_pm_ops
which Greg KH has queued now for 2.6.37:
http://marc.info/?l=linux-kernelm=128276582108006w=2
arch/arm/mach-omap2/Makefile |8 +++-
arch/arm/mach-omap2/pm_bus.c | 82
++
2 files changed, 88 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..ba644c2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -50,13 +50,17 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o
obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3)+= pm34xx.o sleep34xx.o cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4)+= pm44xx.o
+obj-$(CONFIG_ARCH_OMAP3)+= pm34xx.o sleep34xx.o cpuidle34xx.o
pm_bus.o
+obj-$(CONFIG_ARCH_OMAP4)+= pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o += -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..e85aced
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,82 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/init.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
+#include linux/mutex.h
+
+#include plat/omap_device.h
+#include plat/omap-pm.h
+
+#ifdef CONFIG_PM_RUNTIME
+int omap_pm_runtime_suspend(struct device *dev)
+{
+struct platform_device *pdev = to_platform_device(dev);
+int r, ret = 0;
+
+dev_dbg(dev, %s\n, __func__);
+
+ret = pm_generic_runtime_suspend(dev);
+
+if (!ret dev-parent == omap_bus) {
+r = omap_device_idle(pdev);
+WARN_ON(r);
+}
+
+return ret;
+};
+
+int omap_pm_runtime_resume(struct device *dev)
+{
+struct platform_device *pdev = to_platform_device(dev);
+int r;
+
+dev_dbg(dev, %s\n, __func__);
+
+if (dev-parent == omap_bus) {
+r = omap_device_enable(pdev);
+WARN_ON(r);
+}
+
+return pm_generic_runtime_resume(dev);
+};
+#endif /* CONFIG_PM_RUNTIME */
+
+static int __init omap_pm_runtime_init(void)
+{
+const struct dev_pm_ops *pm;
+struct dev_pm_ops *omap_pm;
+
+pm = platform_bus_get_pm_ops();
+if (!pm) {
+pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
+__func__);
+
Re: [PATCH 1/2] OMAP2+: PM: initial runtime PM core support
Grant Likely grant.lik...@secretlab.ca writes:
On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.
In order to determine if a device is an omap_device, its parent device
is checked. All omap_devices have a new 'omap_bus' device as their
parent device, so checking for this parent is used to check for valid
omap_devices. If a device is an omap_device, then the appropriate
omap_device functions are called for it. If not, only the generic
runtime PM functions are called.
Device driver's -runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device. Driver's -runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver -runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)
OMAP4 build support from Rajendra Nayak rna...@ti.com.
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
[...]
+static int __init omap_pm_runtime_init(void)
+{
+const struct dev_pm_ops *pm;
+struct dev_pm_ops *omap_pm;
+
+pm = platform_bus_get_pm_ops();
+if (!pm) {
+pr_err(%s: unable to get dev_pm_ops from platform_bus\n,
+__func__);
+return -ENODEV;
+}
+
+omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+if (!omap_pm) {
+pr_err(%s: unable to alloc memory for new dev_pm_ops\n,
+__func__);
+return -ENOMEM;
+}
+
+omap_pm-runtime_suspend = omap_pm_runtime_suspend;
+omap_pm-runtime_resume = omap_pm_runtime_resume;
This will fail to build when CONFIG_PM_RUNTIME is unset. None of this
file should be build when CONFIG_PM_RUNTIME=n.
FYI... Rather than not building the whole file, I'm fixing this by
adding an #else clause to the #ifdef:
#else
#define omap_pm_runtime_suspend NULL
#define omap_pm_runtime_resume NULL
#endif /* CONFIG_PM_RUNTIME */
This is because I'll also be building on this to hook up the
_[suspend|resume]_noirq() methods which are based on #ifdef
CONFIG_SUSPEND and not CONFIG_PM_RUNTIME.
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] gpmc, EXPORT_SYMBOLS, west bridge related
* Greg KH g...@kroah.com [100907 17:17]: On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote: This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know if there are any issues or concerns with this patch. Thanks, David Signed-off-by: David Cross david.cr...@cypress.com diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.0 -0700 +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.0 -0700 @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx; __raw_writel(val, reg_addr); } +EXPORT_SYMBOL(gpmc_cs_write_reg); EXPORT_SYMBOL_GPL() perhaps? What about platforms that don't have this symbol, how will the driver build properly then? Shouldn't something like this be in a arch-neutral place in the kernel tree? I don't think exporting these functions is a good idea, so NAK from me for that. All the drivers should be generic, and whatever needs to be done that's omap specific should be done in the platform init code. If the driver needs to reconfigure something, such as memory timings, it can be done by passing a retime function pointer to the driver in the platform_data. Then the driver can call that function if it exists. 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: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
* David Cross david.cr...@cypress.com [100908 09:52]: From: Greg KH [mailto:g...@kroah.com] On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote: This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know if there are any issues or concerns with this patch. Thanks, David Signed-off-by: David Cross david.cr...@cypress.com diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.0 -0700 +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c2010-09-01 16:10:21.0 -0700 @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx; __raw_writel(val, reg_addr); } +EXPORT_SYMBOL(gpmc_cs_write_reg); EXPORT_SYMBOL_GPL() perhaps? I don't have an issue with that, though I am not sure I understand why we would want to limit the usage of the function to GPL'd modules. It is probably Tony's call assuming he is ok with exporting the symbol. Exporting these is not a good idea, it should be done in the platform init code like I replied in another message. 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: [PATCH 1/2] OMAP2+: PM: initial runtime PM core support
On Wed, Sep 08, 2010 at 10:24:48AM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote: + omap_pm-runtime_suspend = omap_pm_runtime_suspend; + omap_pm-runtime_resume = omap_pm_runtime_resume; This will fail to build when CONFIG_PM_RUNTIME is unset. None of this file should be build when CONFIG_PM_RUNTIME=n. FYI... Rather than not building the whole file, I'm fixing this by adding an #else clause to the #ifdef: #else #define omap_pm_runtime_suspend NULL #define omap_pm_runtime_resume NULL #endif /* CONFIG_PM_RUNTIME */ This is because I'll also be building on this to hook up the _[suspend|resume]_noirq() methods which are based on #ifdef CONFIG_SUSPEND and not CONFIG_PM_RUNTIME. okay. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2+: PM: initial runtime PM core support
On Wed, Sep 08, 2010 at 10:08:42AM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: On Tue, Sep 07, 2010 at 05:54:41PM -0700, Kevin Hilman wrote: From: Kevin Hilman khil...@ti.com Implement the new runtime PM framework as a thin layer on top of the omap_device API. OMAP specific runtime PM methods are registered with the as custom methods on the platform_bus. In order to determine if a device is an omap_device, its parent device is checked. All omap_devices have a new 'omap_bus' device as their parent device, so checking for this parent is used to check for valid omap_devices. If a device is an omap_device, then the appropriate omap_device functions are called for it. If not, only the generic runtime PM functions are called. Device driver's -runtime_idle() hook is called when the runtime PM usecount reaches zero for that device. Driver's -runtime_suspend() hooks are called just before the device is disabled (via omap_device_idle()), and device driver -runtime_resume() hooks are called just after device has been enabled (via omap_device_enable().) OMAP4 build support from Rajendra Nayak rna...@ti.com. Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com It appears that this one will fail to compile when CONFIG_PM_RUNTIME is unset. Once you've fixed that you can add my a-b line: Thanks for catching this. Acked-by: Grant Likely grant.lik...@secretlab.ca I think this should go via Greg's tree to avoid ordering issues. Not a strong preference, but I'd rather see this go via OMAP as we are building on it in the OMAP tree for this merge window. The ordering issues will only affect OMAP users and I have taken care of that in my staging branches that other are using for their runtime PM conversions. okay. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: McBSP: tx_irq_completion used in rx_irq_handler
Looks like a typo from commit d6d834b010.
Signed-off-by: Scott Ellis sc...@jumpnowtek.com
---
arch/arm/plat-omap/mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e31496e..0c8612f 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -156,7 +156,7 @@ static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void
*dev_id)
/* Writing zero to RSYNC_ERR clears the IRQ */
MCBSP_WRITE(mcbsp_rx, SPCR1, MCBSP_READ_CACHE(mcbsp_rx, SPCR1));
} else {
- complete(mcbsp_rx-tx_irq_completion);
+ complete(mcbsp_rx-rx_irq_completion);
}
return IRQ_HANDLED;
--
To unsubscribe from this list: send the line unsubscribe 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: Don't try to send IPI on UP systems with CONFIG_SMP
* Russell King - ARM Linux li...@arm.linux.org.uk [100908 01:49]:
On Tue, Sep 07, 2010 at 08:14:05PM -0700, Tony Lindgren wrote:
This is not needed on UP. Additionally with will cause issues when
booting CONFIG_SMP_ON_UP kernel on earlier ARM cores.
Doesn't make sense.
Updated below. Basically it's unnecessary to send IPI for one CPU,
and IPI may not be even supported when booting earlier cores
with CONFIG_SMP_ON_UP.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -207,9 +207,7 @@ __setup(reboot=, reboot_setup);
void machine_shutdown(void)
{
-#ifdef CONFIG_SMP
smp_send_stop();
-#endif
This will cause a link error as smp.c is not built for uniprocessor
builds.
Right that should have not made it to the patch.
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -560,12 +560,17 @@ asmlinkage void __exception do_IPI(struct pt_regs
*regs)
void smp_send_reschedule(int cpu)
{
- send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
+ if (is_smp())
+ send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
There won't be any other CPUs to send an IPI to - and all places which
call this are protected by a check for cpu == smp_processor_id() - in
other words, this will never be called for the current CPU.
Good point, it's not needed.
void smp_send_stop(void)
{
cpumask_t mask = cpu_online_map;
+
+ if (!is_smp())
+ return;
+
cpu_clear(smp_processor_id(), mask);
This results in an empty CPU mask. It might be better to do instead:
if (!cpus_empty(mask))
send_ipi_message(mask, IPI_CPU_STOP);
}
OK, so this patch shrinks to the one change below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Tue, 7 Sep 2010 18:41:33 -0700
Subject: [PATCH] ARM: Don't send IPI in smp_send_stop if there's only one CPU
No need to send IPI if there's one CPU, especially when booting
systems with CONFIG_SMP_ON_UP that may not even support IPI.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 40dc74f..32e16da 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -567,7 +567,8 @@ void smp_send_stop(void)
{
cpumask_t mask = cpu_online_map;
cpu_clear(smp_processor_id(), mask);
- send_ipi_message(mask, IPI_CPU_STOP);
+ if (!cpus_empty(mask))
+ send_ipi_message(mask, IPI_CPU_STOP);
}
/*
--
To unsubscribe from this list: send the line unsubscribe 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/6] ARM: Add inline function smp_on_up() for early init testing
* Tony Lindgren t...@atomide.com [100907 20:19]: * Bryan Wu bryan...@canonical.com [100906 03:09]: Tony, I tried your latest branch: devel-smp-on-unicore, kernel boots up but got lots of WARN_ON fired: --- [ cut here ] [1.149719] WARNING: at mm/percpu-vm.c:320 pcpu_alloc+0x2fc/0x888() [1.149780] Modules linked in: [1.149841] [c01b34c8] (unwind_backtrace+0x0/0xe4) from [c01e939c] (warn_slowpath_common+0x4c/0x64) [1.149902] [c01e939c] (warn_slowpath_common+0x4c/0x64) from [c01e93cc] (warn_slowpath_null+0x18/0x1c) [1.149993] [c01e93cc] (warn_slowpath_null+0x18/0x1c) from [c0274730] (pcpu_alloc+0x2fc/0x888) [1.150085] [c0274730] (pcpu_alloc+0x2fc/0x888) from [c0279578] (sget+0x198/0x43c) [1.150146] [c0279578] (sget+0x198/0x43c) from [c0279adc] (get_sb_ns+0x20/0x90) [1.150238] [c0279adc] (get_sb_ns+0x20/0x90) from [c02791a4] (vfs_kern_mount+0x9c/0x18c) [1.150299] [c02791a4] (vfs_kern_mount+0x9c/0x18c) from [c0022280] (init_mqueue_fs+0x68/0xc8) [1.150390] [c0022280] (init_mqueue_fs+0x68/0xc8) from [c01ac5d0] (do_one_initcall+0xcc/0x1a4) [1.150451] [c01ac5d0] (do_one_initcall+0xcc/0x1a4) from [c0008760] (kernel_init+0x148/0x210) [1.150543] [c0008760] (kernel_init+0x148/0x210) from [c01adcf8] (kernel_thread_exit+0x0/0x8) [1.150604] ---[ end trace 1b75b31a2719ed74 ]--- --- It looks like we still missed to set some flag for chuck. Yeah I think there's some .config option that needs to be handled properly to fix this. This seems to disappear when CONFIG_LOCK_STAT is disabled, I wonder why? Here are my current changes to omap3_defconfig that I use for testing. Tony --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -55,6 +55,7 @@ CONFIG_MACH_OMAP_4430SDP=y CONFIG_ARM_THUMBEE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y +CONFIG_SMP=y CONFIG_AEABI=y CONFIG_LEDS=y CONFIG_ZBOOT_ROM_TEXT=0x0 @@ -218,9 +219,9 @@ CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG_WHITELIST is not set CONFIG_USB_MON=y -CONFIG_USB_MUSB_HDRC=y -CONFIG_USB_MUSB_OTG=y -CONFIG_USB_GADGET_MUSB_HDRC=y +# CONFIG_USB_MUSB_HDRC is not set +# CONFIG_USB_MUSB_OTG is not set +# CONFIG_USB_GADGET_MUSB_HDRC is not set CONFIG_USB_MUSB_DEBUG=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y @@ -276,7 +277,7 @@ CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y -CONFIG_LOCK_STAT=y +# CONFIG_LOCK_STAT is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
NEC lcd ON but still blank
Hi all, I'm working on a zoom2 dev board (omap34x-II MDP), and I can't draw anything on the LCD display. I've built kernel 2.6.35 from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git and then applied the following patchs : [PATCH 1/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for zoom boards http://marc.info/?l=linux-omapm=127445506720934w=2 [PATCH 2/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for zoom boards http://marc.info/?l=linux-omapm=127445522921326w=2 [PATCH V6] OMAP: DSS: Add NEC NL8048HL11-01B display panel http://marc.info/?l=linux-omapm=127445535621669w=2 At this time the kernel boots well, and my LCD backlight turns on but I can't draw anything. I've checked, the framebuffer device is present and configured with size of 800x480. Perhaps I've missed something? Thank you in advance. --- Yanick -- To unsubscribe from this list: send the line unsubscribe 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: NEC lcd ON but still blank
Hi, a little more information, i've played with sys filesystem like on this wiki with no chance: http://www.omappedia.org/wiki/Bootargs_for_enabling_display And my kernel boot options are: vram=10M omapdss.def_disp=lcd Thank you. --- yanick -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
Hi Cyril, On 09/08/2010 05:59 PM, Cyril Chemparathy wrote: Hi Mike, [...] So I just pulled this to test it out on a da850 based board (mitydspl138), and I'm having some problems. I'm hoping it's just operator error. Probably not, considering that this series had not been tested on da8xx platforms. Thanks for jumping in! Jumped, pushed, you say tomato, ... ;^) I have a TI TLK100PHP PHY at address 0x3. The boot log shows: [snip] davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 davinci_mdio davinci_mdio.0: detected phy mask fff7 davinci_mdio.0: probed davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown [snip] So far so good. The MDIO code seems to have done its part and latched on to the correct phy. To answer your question from below, the driver unknown implies that the generic phy driver has been attached to the detected phy. and then in the init scripts, following udev population I get a Configuring network interfaces... and the boot process just hangs. Not a peep from emac? Strange. So I went in and set the debug_level to netif_msg_init() to -1 in the davinci_emac driver. The only thing I get during the boot process is: net eth0: DaVinci EMAC Probe found device (regs: 01e23000, irq: 33) which is good (I also added some debug to make sure probe actually completes), but I don't see *anything* else. I guess I would have expected to see something out of the emac_dev_open. So I added some more debug in there, it's hanging in the phy_connect() call. The phy_id it came up with was correct 0:03. [snip] I spent some time today on testing this series on a da830 evm board (sorry, couldn't manage to scrounge up a da850 platform). In the process, I have had to put in some fixes, particularly for the phy-association piece. You can preview these commits on my repo's gitweb [1]. I did apply the requeue on early end-of-queue patch. No difference, which is not surprising as it's dying in the phy_connect. I don't think I need the others, as the correct phy_id is being located by the MDIO probe headed into the phy_connect call (pointer is valid, string is OK, etc.). If I have time I can continue to poke around, but I'm really not up on this chunk of code... -Mike -- To unsubscribe from this list: send the line unsubscribe 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] USB: otg: twl4030: fix phy initialization(v1)
2010/9/8 venki kaps venkiece2...@gmail.com: To resolve the above issue, we have made PHY power on in battery adc on function and PHY power down in battery adc off function. Good news, the temperature is bad value from battery adc if otg phy is power down. Maybe you only need to power on otg phy before reading battery adc, then power down otg phy after the reading if no usb calbe is connected with musb for decreasing power consumption. (I am not familiar with battery adc, just for your refrerence) Anyway, your issue(reading mistaken temperature) is nothing to do with twl_4030 otg driver and the patch, we does need to power down otg phy if no vbus or ID event detected. -- 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 1/6] ARM: Add inline function smp_on_up() for early init testing
Tony, Awesome, this makes SMP kernel work on my omap3 board. Thanks a lot. I will test the same kernel on my omap4 one. -Bryan. On Thu, Sep 9, 2010 at 4:26 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [100907 20:19]: * Bryan Wu bryan...@canonical.com [100906 03:09]: Tony, I tried your latest branch: devel-smp-on-unicore, kernel boots up but got lots of WARN_ON fired: --- [ cut here ] [ 1.149719] WARNING: at mm/percpu-vm.c:320 pcpu_alloc+0x2fc/0x888() [ 1.149780] Modules linked in: [ 1.149841] [c01b34c8] (unwind_backtrace+0x0/0xe4) from [c01e939c] (warn_slowpath_common+0x4c/0x64) [ 1.149902] [c01e939c] (warn_slowpath_common+0x4c/0x64) from [c01e93cc] (warn_slowpath_null+0x18/0x1c) [ 1.149993] [c01e93cc] (warn_slowpath_null+0x18/0x1c) from [c0274730] (pcpu_alloc+0x2fc/0x888) [ 1.150085] [c0274730] (pcpu_alloc+0x2fc/0x888) from [c0279578] (sget+0x198/0x43c) [ 1.150146] [c0279578] (sget+0x198/0x43c) from [c0279adc] (get_sb_ns+0x20/0x90) [ 1.150238] [c0279adc] (get_sb_ns+0x20/0x90) from [c02791a4] (vfs_kern_mount+0x9c/0x18c) [ 1.150299] [c02791a4] (vfs_kern_mount+0x9c/0x18c) from [c0022280] (init_mqueue_fs+0x68/0xc8) [ 1.150390] [c0022280] (init_mqueue_fs+0x68/0xc8) from [c01ac5d0] (do_one_initcall+0xcc/0x1a4) [ 1.150451] [c01ac5d0] (do_one_initcall+0xcc/0x1a4) from [c0008760] (kernel_init+0x148/0x210) [ 1.150543] [c0008760] (kernel_init+0x148/0x210) from [c01adcf8] (kernel_thread_exit+0x0/0x8) [ 1.150604] ---[ end trace 1b75b31a2719ed74 ]--- --- It looks like we still missed to set some flag for chuck. Yeah I think there's some .config option that needs to be handled properly to fix this. This seems to disappear when CONFIG_LOCK_STAT is disabled, I wonder why? Here are my current changes to omap3_defconfig that I use for testing. Tony --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -55,6 +55,7 @@ CONFIG_MACH_OMAP_4430SDP=y CONFIG_ARM_THUMBEE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y +CONFIG_SMP=y CONFIG_AEABI=y CONFIG_LEDS=y CONFIG_ZBOOT_ROM_TEXT=0x0 @@ -218,9 +219,9 @@ CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG_WHITELIST is not set CONFIG_USB_MON=y -CONFIG_USB_MUSB_HDRC=y -CONFIG_USB_MUSB_OTG=y -CONFIG_USB_GADGET_MUSB_HDRC=y +# CONFIG_USB_MUSB_HDRC is not set +# CONFIG_USB_MUSB_OTG is not set +# CONFIG_USB_GADGET_MUSB_HDRC is not set CONFIG_USB_MUSB_DEBUG=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y @@ -276,7 +277,7 @@ CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y -CONFIG_LOCK_STAT=y +# CONFIG_LOCK_STAT is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -- Bryan Wu bryan...@canonical.com Kernel Developer +86.138-1617-6545 Mobile Ubuntu Kernel Team Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig
Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: OMAP_IOMMU not visible in menuconfig
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, September 09, 2010 10:35 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. [sp] You would have noticed that there are mnay OMAP3 variants and some of them are ARM only - detection being runtime, not compile time. All these processors share same defconfig. Keeping/ maintaining specific defconfigs for each processor will be too difficult. ~sanjeev Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
Tony, -Original Message- From: Catalin Marinas [mailto:catalin.mari...@arm.com] Sent: Wednesday, September 08, 2010 9:20 PM To: Shilimkar, Santosh Cc: Linus Walleij; Russell King - ARM Linux; linux-arm- ker...@lists.infradead.org; t...@linutronix.de; linux- o...@vger.kernel.org; per.xx.frans...@stericsson.com Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation On Wed, 2010-09-08 at 16:46 +0100, Shilimkar, Santosh wrote: Here is the updated branch including Per Fransson patch. http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk It looks fine to me. Are you ok if [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable patch gets merged via Russell's tree? http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blobdiff;f=arch/arm/mach-omap2/omap4-common.c;h=b557cc2c4b10e2ba4b6c4d6e3397611fb2de5952;hp=13dc9794dcc2ea68fe9115cff7be9cd8c074a484;hb=e1612fb084e78d5cba127f360803863e87a1e0cd;hpb=32ff2ccc0ca4d22c211fc5f5cc71b3d9a950c8c3 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] gpmc, EXPORT_SYMBOLS, west bridge related
On Wed, Sep 08, 2010 at 10:28:45AM -0700, Tony Lindgren wrote: * Greg KH g...@kroah.com [100907 17:17]: On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote: This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know if there are any issues or concerns with this patch. Thanks, David Signed-off-by: David Cross david.cr...@cypress.com diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.0 -0700 +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c2010-09-01 16:10:21.0 -0700 @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx, reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx; __raw_writel(val, reg_addr); } +EXPORT_SYMBOL(gpmc_cs_write_reg); EXPORT_SYMBOL_GPL() perhaps? What about platforms that don't have this symbol, how will the driver build properly then? Shouldn't something like this be in a arch-neutral place in the kernel tree? I don't think exporting these functions is a good idea, so NAK from me for that. All the drivers should be generic, and whatever needs to be done that's omap specific should be done in the platform init code. Ah, that makes more sense. David, care to make those changes? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe 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: OMAP_IOMMU not visible in menuconfig
From: ext Premi, Sanjeev pr...@ti.com Subject: RE: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Thu, 9 Sep 2010 07:10:05 +0200 -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, September 09, 2010 10:35 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. [sp] You would have noticed that there are mnay OMAP3 variants and some of them are ARM only - detection being runtime, not compile time. All these processors share same defconfig. Setting dependency correctly could solve this? Modified drivers/staging/tidspbridge/Kconfig diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index 93de4f2..ff64d46 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -6,6 +6,7 @@ menuconfig TIDSPBRIDGE tristate DSP Bridge driver depends on ARCH_OMAP3 select OMAP_MBOX_FWK + select OMAP_IOMMU help DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more attached DSPs. The GPP is considered the master or Keeping/ maintaining specific defconfigs for each processor will be too difficult. ~sanjeev Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig
From: Hiroshi DOYU hiroshi.d...@nokia.com Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Thu, 09 Sep 2010 08:24:05 +0300 (EEST) From: ext Premi, Sanjeev pr...@ti.com Subject: RE: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Thu, 9 Sep 2010 07:10:05 +0200 -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, September 09, 2010 10:35 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Hi Sanjeev, From: ext Sanjeev Premi pr...@ti.com Subject: [PATCH] omap: OMAP_IOMMU not visible in menuconfig Date: Wed, 8 Sep 2010 16:51:21 +0200 The menu option to select CONFIG_OMAP_IOMMU was not visible in the menuconfig due to missing description. There's no point to make OMAP_IOMMU visible since this is a kind of feature used by other device implicitly. OMAP_IOMMU on menu might confuse users at kernel menuconfig. Instead this should be automatically selected by its clients when it is selected. For exmaple, the case that DSP or Tesla is selected. There was a discussion about this before. [sp] You would have noticed that there are mnay OMAP3 variants and some of them are ARM only - detection being runtime, not compile time. For the runtime detection, can this be done at platform_device registration time? All these processors share same defconfig. Setting dependency correctly could solve this? Modified drivers/staging/tidspbridge/Kconfig diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index 93de4f2..ff64d46 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -6,6 +6,7 @@ menuconfig TIDSPBRIDGE tristate DSP Bridge driver depends on ARCH_OMAP3 select OMAP_MBOX_FWK + select OMAP_IOMMU help DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more attached DSPs. The GPP is considered the master or Keeping/ maintaining specific defconfigs for each processor will be too difficult. ~sanjeev Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/plat-omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index e39a417..2a114a9 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -98,7 +98,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + tristate OMAP IOMMU support config OMAP_IOMMU_DEBUG tristate Export OMAP IOMMU internals in DebugFS -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
