Re: [GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38

2010-12-12 Thread Russell King - ARM Linux
On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote: Ruseell, On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 08:50:07AM -0600,

Re: [PATCH] staging: tidspbridge: use the right type for list_is_last

2010-12-12 Thread Laurent Pinchart
Hi Omar, On Wednesday 08 December 2010 23:20:23 Omar Ramirez Luna wrote: Removes the following warning: CC [M] drivers/staging/tidspbridge/rmgr/rmm.o drivers/staging/tidspbridge/rmgr/rmm.c: In function 'rmm_alloc': drivers/staging/tidspbridge/rmgr/rmm.c:147: warning: passing

Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge

2010-12-12 Thread Laurent Pinchart
Hi Ohad, While testing the tidspbridge driver (2.6.37-rc5, plus patches from the dspbridge branch in linux-omap-2.6) I ran into the following lock inconsistency: [ 191.045166] = [ 191.051269] [ INFO: inconsistent lock state ] [ 191.055816]

Re: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge

2010-12-12 Thread Ohad Ben-Cohen
Hi Laurent, On Sun, Dec 12, 2010 at 2:44 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com [  191.085479] {IN-SOFTIRQ-W} state was registered at: [  191.090576]   [c008e914] __lock_acquire+0x5f0/0x17c4 [  191.095947]   [c008fbc0] lock_acquire+0xd8/0xfc [  191.100860]   [c0373d3c]

[PATCH] dspbridge: Fix atoi to support hexadecimal numbers correctly

2010-12-12 Thread Laurent Pinchart
For some strange reason, the DSP base image node/object properties description string stores hexadecimal numbers with a 'h' or 'H' suffix instead of a '0x' prefix. This causes parsing issue because the dspbridge atoi() implementation relies on strict_strtoul(), which will return an error because

Re: [PATCH 2/9 v3] usb: musb: Remove board_data parameter from musb_platform_init()

2010-12-12 Thread Sergei Shtylyov
Hello. On 11-12-2010 20:43, Greg KH wrote: Removed the board_data parameter being passed to musb_platform_init function as board data can be extracted from device structure which is already member of musb structure. Signed-off-by: Hema HKhem...@ti.com Cc: Felipe Balbiba...@ti.com Cc: Tony

Re: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge

2010-12-12 Thread Ionut Nicu
Hi Laurent, On Sun, 2010-12-12 at 13:44 +0100, Laurent Pinchart wrote: Hi Ohad, While testing the tidspbridge driver (2.6.37-rc5, plus patches from the dspbridge branch in linux-omap-2.6) I ran into the following lock inconsistency: [ 191.045166] = [

Re: [PATCH 1/2] staging: tidspbridge: rmgr/node.c code cleanup

2010-12-12 Thread Ionut Nicu
Hi, On Thu, 2010-12-09 at 17:03 -0600, Ramirez Luna, Omar wrote: Hi Ionut, On Thu, Dec 9, 2010 at 4:22 PM, Ionut Nicu ionut.n...@mindbit.ro wrote: Hi Omar, On Thu, 2010-12-09 at 23:47 +0200, Ionut Nicu wrote: Reorganized some code in rmgr/node.c to increase its readability. Most of

Re: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge

2010-12-12 Thread Ohad Ben-Cohen
On Sun, Dec 12, 2010 at 4:15 PM, Ionut Nicu ionut.n...@mindbit.ro wrote: I noticed this too, but this patch should fix it: https://patchwork.kernel.org/patch/365292/ True. And in this patch the move to spin_lock_bh() is justifiable, too, since it adds a sending path which is parallel to the

Re: [PATCH] staging: tidspbridge: use the right type for list_is_last

2010-12-12 Thread Ionut Nicu
Hi Omar, On Wed, 2010-12-08 at 16:20 -0600, Omar Ramirez Luna wrote: Removes the following warning: CC [M] drivers/staging/tidspbridge/rmgr/rmm.o drivers/staging/tidspbridge/rmgr/rmm.c: In function 'rmm_alloc': drivers/staging/tidspbridge/rmgr/rmm.c:147: warning: passing argument

[PATCH 0/2] Misc LED-related IGEPv2 patches

2010-12-12 Thread Laurent Pinchart
Hi, Here are two small patches for the IGEPv2 board file to cleanup LED support and configure the heartbeat LED as active low. The second patch is valid for revision C hardware, I don't know if the LED is active low on revision B hardware as well. Laurent Pinchart (2): omap3: igepv2: Don't

[PATCH 1/2] omap3: igepv2: Don't call gpio_set_value right after gpio_direction_output

2010-12-12 Thread Laurent Pinchart
gpio_direction_output() has a value argument, there's no need to call gpio_set_value() explicitly right after. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/arm/mach-omap2/board-igep0020.c | 20 1 files changed, 8 insertions(+), 12 deletions(-)

[PATCH 2/2] omap3: igepv2: LED gpio-led:green:d1 is active low

2010-12-12 Thread Laurent Pinchart
Make sure the LED is turned off at boot time, and configure the GPIO LED device as active low. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/arm/mach-omap2/board-igep0020.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git

linux-next: manual merge of the trivial tree with the omap tree

2010-12-12 Thread Stephen Rothwell
Hi Jiri, Today's linux-next merge of the trivial tree got a conflict in arch/arm/mach-omap2/pm24xx.c between commit e83df17f178360a8e7874441bca04a710c869e42 (OMAP2+: PM/serial: fix console semaphore acquire during suspend) from the omap tree and commit 2f55ac072f5344519348c0c94b3d2f4cca46847b

Re: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor

2010-12-12 Thread Hemanth V
- Original Message - From: Hemanth V heman...@ti.com To: linux-omap@vger.kernel.org Sent: Thursday, December 02, 2010 12:59 PM Subject: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor From 10f5f9f918e197f4052ac66b4e4cfb4b72646878 Mon Sep 17 00:00:00 2001 From: Hemanth