Re: [GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38
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, Guzman Lugo, Fernando wrote: On Thu, Dec 2, 2010 at 6:33 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote: Hi Tony, The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71: Linus Torvalds (1): Linux 2.6.37-rc4 are available in the git repository at: git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38 Fernando Guzman Lugo (5): OMAP: mailbox: change full flag per mailbox queue instead of global omap: iovmm - no gap checking for fixed address omap: iovmm - add superpages support to fixed da address omap: iovmm - replace __iounmap with omap_iounmap This change is wrong. Nothing should be directly referencing omap_iounmap nor for that matter omap_ioremap. Both are implementation details of the standard ioremap/iounmap APIs. Use the official APIs rather than the implementation details behind them. if you see where the function is used, you will see that it is not calling the function, it is use as a parameter in unmap_vm_area(), if I used iounmap which is a macro there I will get a compilation error. Hmm, yes, because iounmap() is defined as a macro rather than iounmap. The solution to this is to fix iounmap and __arch_iounmap macros so they aren't macros which take arguments. That will then allow them to be used in the way you desire. yes, that way it can be used in the function parameter. what is the right thing to do? 1) You send your patch and then I send the new version of the patches. 2) I make a new series of the patches with the change to iounmap and I include your patch in the series. Can you please suggest the approach we take here ? So, either you send your suggested change as a patch and Fernando's patch will be based on it, or he can take a TODO action item to patch again if you plan to send this change later. Right, the patches are in my git tree, under the 'io' branch: http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git io which you can use to base stuff off of. Make sure your tree has commits up to 2.6.37-rc5 before pulling to avoid grabbing MB's of pack files. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: use the right type for list_is_last
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 argument 1 of 'list_is_last' from incompatible pointer type include/linux/list.h:170: note: expected 'const struct list_head *' but argument is of type 'struct rmm_ovly_sect *' I was about to send the same patch. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- 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
Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
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] 2.6.37-rc5-00062-gd8b8a63 #8
[ 191.059906] -
[ 191.064453] inconsistent {IN-SOFTIRQ-W} - {SOFTIRQ-ON-W} usage.
[ 191.070709] dummy/1544 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 191.075988] ((mq-lock)-rlock){+.?...}, at: [bf000744]
omap_mbox_msg_send+0x18/0xa4 [mailbox]
[ 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] _raw_spin_lock+0x30/0x40
[ 191.105957] [bf000744] omap_mbox_msg_send+0x18/0xa4 [mailbox]
[ 191.112335] [bf014a08] sm_interrupt_dsp+0xe0/0x114 [bridgedriver]
[ 191.119201] [bf0122d4] io_dpc+0x364/0x6c4 [bridgedriver]
[ 191.125152] [c0067294] tasklet_action+0x70/0x100
[ 191.130371] [c0067974] __do_softirq+0xc4/0x1b4
[ 191.135375] [c0067b44] do_softirq+0x44/0x68
[ 191.140136] [c0067bcc] run_ksoftirqd+0x64/0x10c
[ 191.145233] [c007c3a0] kthread+0x84/0x8c
[ 191.149688] [c003aad0] kernel_thread_exit+0x0/0x8
[ 191.154968] irq event stamp: 3602
[ 191.158447] hardirqs last enabled at (3602): [c0067dd0]
local_bh_enable_ip+0xe0/0xf4
[ 191.166809] hardirqs last disabled at (3600): [c0067d50]
local_bh_enable_ip+0x60/0xf4
[ 191.175170] softirqs last enabled at (3601): [bf00f848]
bridge_chnl_add_io_req+0x2f4/0x348 [bridgedriver]
[ 191.185485] softirqs last disabled at (3599): [c0373f24]
_raw_spin_lock_bh+0x14/0x4c
[ 191.193756]
[ 191.193756] other info that might help us debug this:
[ 191.200592] 1 lock held by dummy/1544:
[ 191.204498] #0: (node_mgr_obj-node_mgr_lock){+.+.+.}, at: [bf025da0]
node_create+0x88/0x28c [bridgedriver]
[ 191.215240]
[ 191.215240] stack backtrace:
[ 191.219818] [c003eca4] (unwind_backtrace+0x0/0xec) from [c008caf4]
(print_usage_bug+0x170/0x1b4)
[ 191.229370] [c008caf4] (print_usage_bug+0x170/0x1b4) from [c008ce90]
(mark_lock+0x358/0x628)
[ 191.238555] [c008ce90] (mark_lock+0x358/0x628) from [c008e9a0]
(__lock_acquire+0x67c/0x17c4)
[ 191.247741] [c008e9a0] (__lock_acquire+0x67c/0x17c4) from [c008fbc0]
(lock_acquire+0xd8/0xfc)
[ 191.257019] [c008fbc0] (lock_acquire+0xd8/0xfc) from [c0373d3c]
(_raw_spin_lock+0x30/0x40)
[ 191.266021] [c0373d3c] (_raw_spin_lock+0x30/0x40) from [bf000744]
(omap_mbox_msg_send+0x18/0xa4 [mailbox])
[ 191.276519] [bf000744] (omap_mbox_msg_send+0x18/0xa4 [mailbox]) from
[bf014a08] (sm_interrupt_dsp+0xe0/0x114 [bridgedriver])
[ 191.288696] [bf014a08] (sm_interrupt_dsp+0xe0/0x114 [bridgedriver]) from
[bf00f85c] (bridge_chnl_add_io_req+0x308/0x348 [bridgedriver])
[ 191.301910] [bf00f85c] (bridge_chnl_add_io_req+0x308/0x348
[bridgedriver]) from [bf021694] (send_message+0x14c/0x164 [bridgedriver])
[ 191.314880] [bf021694] (send_message+0x14c/0x164 [bridgedriver]) from
[bf021f18] (disp_node_create+0x4c8/0x508 [bridgedriver])
[ 191.327301] [bf021f18] (disp_node_create+0x4c8/0x508 [bridgedriver]) from
[bf025ea8] (node_create+0x190/0x28c [bridgedriver])
[ 191.339630] [bf025ea8] (node_create+0x190/0x28c [bridgedriver]) from
[bf019018] (api_call_dev_ioctl+0xf0/0x118 [bridgedriver])
[ 191.352081] [bf019018] (api_call_dev_ioctl+0xf0/0x118 [bridgedriver])
from [bf02e0dc] (bridge_ioctl+0x148/0x17c [bridgedriver])
[ 191.364532] [bf02e0dc] (bridge_ioctl+0x148/0x17c [bridgedriver]) from
[c00f5870] (vfs_ioctl+0x20/0x3c)
[ 191.374633] [c00f5870] (vfs_ioctl+0x20/0x3c) from [c00f5f5c]
(do_vfs_ioctl+0x4fc/0x544)
[ 191.383361] [c00f5f5c] (do_vfs_ioctl+0x4fc/0x544) from [c00f5ff0]
(sys_ioctl+0x4c/0x6c)
[ 191.392089] [c00f5ff0] (sys_ioctl+0x4c/0x6c) from [c003a0c0]
(ret_fast_syscall+0x0/0x3c)
Googling for a solution returned a pretty long mail thread (http://www.mail-
archive.com/linux-omap@vger.kernel.org/msg30492.html) and a dspbridge patch
(https://patchwork.kernel.org/patch/107522/) part of a bigger patch set.
That code doesn't seem to have hit mainline. Do you have a status update on
this ?
--
Regards,
Laurent Pinchart
--
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: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
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] _raw_spin_lock+0x30/0x40
[ 191.105957] [bf000744] omap_mbox_msg_send+0x18/0xa4 [mailbox]
[ 191.112335] [bf014a08] sm_interrupt_dsp+0xe0/0x114 [bridgedriver]
[ 191.119201] [bf0122d4] io_dpc+0x364/0x6c4 [bridgedriver]
[ 191.125152] [c0067294] tasklet_action+0x70/0x100
[ 191.130371] [c0067974] __do_softirq+0xc4/0x1b4
[ 191.135375] [c0067b44] do_softirq+0x44/0x68
[ 191.140136] [c0067bcc] run_ksoftirqd+0x64/0x10c
[ 191.145233] [c007c3a0] kthread+0x84/0x8c
[ 191.149688] [c003aad0] kernel_thread_exit+0x0/0x8
[ 191.154968] irq event stamp: 3602
[ 191.158447] hardirqs last enabled at (3602): [c0067dd0]
local_bh_enable_ip+0xe0/0xf4
[ 191.166809] hardirqs last disabled at (3600): [c0067d50]
local_bh_enable_ip+0x60/0xf4
[ 191.175170] softirqs last enabled at (3601): [bf00f848]
bridge_chnl_add_io_req+0x2f4/0x348 [bridgedriver]
[ 191.185485] softirqs last disabled at (3599): [c0373f24]
_raw_spin_lock_bh+0x14/0x4c
[ 191.193756]
[ 191.193756] other info that might help us debug this:
[ 191.200592] 1 lock held by dummy/1544:
[ 191.204498] #0: (node_mgr_obj-node_mgr_lock){+.+.+.}, at: [bf025da0]
node_create+0x88/0x28c [bridgedriver]
[ 191.215240]
[ 191.215240] stack backtrace:
[ 191.219818] [c003eca4] (unwind_backtrace+0x0/0xec) from [c008caf4]
(print_usage_bug+0x170/0x1b4)
[ 191.229370] [c008caf4] (print_usage_bug+0x170/0x1b4) from [c008ce90]
(mark_lock+0x358/0x628)
[ 191.238555] [c008ce90] (mark_lock+0x358/0x628) from [c008e9a0]
(__lock_acquire+0x67c/0x17c4)
[ 191.247741] [c008e9a0] (__lock_acquire+0x67c/0x17c4) from [c008fbc0]
(lock_acquire+0xd8/0xfc)
[ 191.257019] [c008fbc0] (lock_acquire+0xd8/0xfc) from [c0373d3c]
(_raw_spin_lock+0x30/0x40)
[ 191.266021] [c0373d3c] (_raw_spin_lock+0x30/0x40) from [bf000744]
(omap_mbox_msg_send+0x18/0xa4 [mailbox])
[ 191.276519] [bf000744] (omap_mbox_msg_send+0x18/0xa4 [mailbox]) from
[bf014a08] (sm_interrupt_dsp+0xe0/0x114 [bridgedriver])
[ 191.288696] [bf014a08] (sm_interrupt_dsp+0xe0/0x114 [bridgedriver]) from
[bf00f85c] (bridge_chnl_add_io_req+0x308/0x348 [bridgedriver])
[ 191.301910] [bf00f85c] (bridge_chnl_add_io_req+0x308/0x348
[bridgedriver]) from [bf021694] (send_message+0x14c/0x164 [bridgedriver])
[ 191.314880] [bf021694] (send_message+0x14c/0x164 [bridgedriver]) from
[bf021f18] (disp_node_create+0x4c8/0x508 [bridgedriver])
[ 191.327301] [bf021f18] (disp_node_create+0x4c8/0x508 [bridgedriver]) from
[bf025ea8] (node_create+0x190/0x28c [bridgedriver])
[ 191.339630] [bf025ea8] (node_create+0x190/0x28c [bridgedriver]) from
[bf019018] (api_call_dev_ioctl+0xf0/0x118 [bridgedriver])
[ 191.352081] [bf019018] (api_call_dev_ioctl+0xf0/0x118 [bridgedriver])
from [bf02e0dc] (bridge_ioctl+0x148/0x17c [bridgedriver])
[ 191.364532] [bf02e0dc] (bridge_ioctl+0x148/0x17c [bridgedriver]) from
[c00f5870] (vfs_ioctl+0x20/0x3c)
[ 191.374633] [c00f5870] (vfs_ioctl+0x20/0x3c) from [c00f5f5c]
(do_vfs_ioctl+0x4fc/0x544)
[ 191.383361] [c00f5f5c] (do_vfs_ioctl+0x4fc/0x544) from [c00f5ff0]
(sys_ioctl+0x4c/0x6c)
[ 191.392089] [c00f5ff0] (sys_ioctl+0x4c/0x6c) from [c003a0c0]
(ret_fast_syscall+0x0/0x3c)
Googling for a solution returned a pretty long mail thread (http://www.mail-
archive.com/linux-omap@vger.kernel.org/msg30492.html)
Yeah, the problem was (is??) that dspbridge uses mailbox from both
process context and softirq context (its tasklet).
and a dspbridge patch
(https://patchwork.kernel.org/patch/107522/) part of a bigger patch set.
That code doesn't seem to have hit mainline. Do you have a status update on
this ?
Big parts of it are being pursued by Hari nowadays, but anyway they
are not relevant to the lockdep problem, so don't wait for it...
There are two possible solutions to the lockdep problem:
1. Have dspbridge defer messages to a workqueue instead of a tasklet
or
2. Add sufficient locking into mailbox that would allow softirq usage too
I recommended to follow (1), but that needs verification that
performance isn't hurt (it shouldn't since that context is anyway
meant to defer messages in case the bridge is still waiting for
previous ones to be processed by the dsp).
But otherwise (2) will work too (see proposal by Deepak in the
original bug report).
Looping in Omar, Fernando, Felipe, Deepak, Hari,...
Thanks,
Ohad.
--
Regards,
Laurent Pinchart
--
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] dspbridge: Fix atoi to support hexadecimal numbers correctly
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 of the trailing 'h' character.
As the atoi() return value is never checked for an error anyway, replace
strict_strtoul() with simple_strtoul() to ignore the suffix.
This fix gets rid of the following assertion failed messages that were
printed when running the dsp-dummy test application.
drivers/staging/tidspbridge/rmgr/nldr.c, line 1691:
Assertion (segid == MEMINTERNALID || segid == MEMEXTERNALID) failed.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/tidspbridge/rmgr/dbdcd.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c
b/drivers/staging/tidspbridge/rmgr/dbdcd.c
index 3581a55..b76f26c 100644
--- a/drivers/staging/tidspbridge/rmgr/dbdcd.c
+++ b/drivers/staging/tidspbridge/rmgr/dbdcd.c
@@ -1020,8 +1020,6 @@ static s32 atoi(char *psz_buf)
{
char *pch = psz_buf;
s32 base = 0;
- unsigned long res;
- int ret_val;
while (isspace(*pch))
pch++;
@@ -1033,9 +1031,7 @@ static s32 atoi(char *psz_buf)
base = 16;
}
- ret_val = strict_strtoul(pch, base, res);
-
- return ret_val ? : res;
+ return simple_strtoul(pch, NULL, base);
}
/*
--
1.7.2.2
--
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/9 v3] usb: musb: Remove board_data parameter from musb_platform_init()
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 Lindgrent...@atomide.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Cousson, Benoitb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com For the davinci changes: Acked-by: Kevin Hilmankhil...@deeprootsystems.com Kevin --- drivers/usb/musb/blackfin.c |2 +- drivers/usb/musb/davinci.c |2 +- drivers/usb/musb/musb_core.c |2 +- drivers/usb/musb/musb_core.h |2 +- drivers/usb/musb/omap2430.c |6 -- drivers/usb/musb/tusb6010.c |2 +- 6 files changed, 9 insertions(+), 7 deletions(-) Grr. This misses changes to da8xx.c and am35x.c -- which breaks the compilation for them! Greg, could you drop it from your usb-next branch? Or should we send a patch adding these glue layers? I can't drop patches from a git branch, sorry, it doesn't work that way anymore. OTOH, you could revert it (as breaking the build). Dunno if that makes sense... Again, I trust the musb maintainer here to handle this type of thing, not me. So take it up with him. Done already. And he's on the CC here too... thanks, greg k-h WBR, Sergei -- 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: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
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] =
[ 191.051269] [ INFO: inconsistent lock state ]
[ 191.055816] 2.6.37-rc5-00062-gd8b8a63 #8
[ 191.059906] -
[ 191.064453] inconsistent {IN-SOFTIRQ-W} - {SOFTIRQ-ON-W} usage.
[ 191.070709] dummy/1544 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 191.075988] ((mq-lock)-rlock){+.?...}, at: [bf000744]
omap_mbox_msg_send+0x18/0xa4 [mailbox]
[ 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] _raw_spin_lock+0x30/0x40
[ 191.105957] [bf000744] omap_mbox_msg_send+0x18/0xa4 [mailbox]
[ 191.112335] [bf014a08] sm_interrupt_dsp+0xe0/0x114 [bridgedriver]
[ 191.119201] [bf0122d4] io_dpc+0x364/0x6c4 [bridgedriver]
[ 191.125152] [c0067294] tasklet_action+0x70/0x100
[ 191.130371] [c0067974] __do_softirq+0xc4/0x1b4
[ 191.135375] [c0067b44] do_softirq+0x44/0x68
[ 191.140136] [c0067bcc] run_ksoftirqd+0x64/0x10c
[ 191.145233] [c007c3a0] kthread+0x84/0x8c
[ 191.149688] [c003aad0] kernel_thread_exit+0x0/0x8
[ 191.154968] irq event stamp: 3602
I noticed this too, but this patch should fix it:
https://patchwork.kernel.org/patch/365292/
Ionut.
--
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] staging: tidspbridge: rmgr/node.c code cleanup
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 the changes reduce the code
indentation level and simplifiy the code. No functional
changes were done.
snip
/*
* Check stream mode. Default is STRMMODE_PROCCOPY.
*/
- if (!status pattrs) {
- if (pattrs-strm_mode != STRMMODE_PROCCOPY)
- status = -EPERM;/* illegal stream mode */
-
- }
- if (status)
- goto func_end;
+ if (pattrs pattrs-strm_mode != STRMMODE_PROCCOPY)
+ return -EPERM; /* illegal stream mode */
While cleaning up and reviewing the code I saw this check, which unless
it's intentional I think it looks like a bug. See comment below.
snip
+ strm_mode = pattrs ? pattrs-strm_mode : STRMMODE_PROCCOPY;
+ switch (strm_mode) {
+ case STRMMODE_RDMA:
...
+
+ case STRMMODE_ZEROCOPY:
...
+ case STRMMODE_PROCCOPY:
It looks like all modes are handled here although the only one that
could escape the validation from above is STRMMODE_PROCCOPY.
I tried removing the first check and tested with the
userspace-dspbridge strmcopy application, but I noticed the DSP hangs if
I try to use it with anything else than the copy mode.
Are the other modes (rdma, zerocopy) not supported at all?
No, those modes are not supported... the only one working for dsp
streams is proc-copy.
Is there any plan to make them work? If not, maybe the code that handles
them should be removed...
Thanks,
Ionut.
--
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: Inconsistent lock state caused by omap_mbox_msg_send() called from tidspbridge
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 mailbox tasklet. Ionut. -- 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] staging: tidspbridge: use the right type for list_is_last
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 1 of 'list_is_last' from incompatible pointer type include/linux/list.h:170: note: expected 'const struct list_head *' but argument is of type 'struct rmm_ovly_sect *' Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/staging/tidspbridge/rmgr/rmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tidspbridge/rmgr/rmm.c b/drivers/staging/tidspbridge/rmgr/rmm.c index aae8657..5a3f09c 100644 --- a/drivers/staging/tidspbridge/rmgr/rmm.c +++ b/drivers/staging/tidspbridge/rmgr/rmm.c @@ -144,7 +144,7 @@ int rmm_alloc(struct rmm_target_obj *target, u32 segid, u32 size, new_sect-addr = addr; new_sect-size = size; new_sect-page = segid; - if (list_is_last(sect, target-ovly_list)) + if (list_is_last(sect-list_elem, target-ovly_list)) /* Put new section at the end of the list */ list_add_tail(new_sect-list_elem, target-ovly_list); Sorry, I added this warning by mistake, so ... Acked-by: Ionut Nicu ionut.n...@mindbit.ro -- 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 0/2] Misc LED-related IGEPv2 patches
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 call gpio_set_value right after gpio_direction_output omap3: igepv2: LED gpio-led:green:d1 is active low arch/arm/mach-omap2/board-igep0020.c | 21 + 1 files changed, 9 insertions(+), 12 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap3: igepv2: Don't call gpio_set_value right after gpio_direction_output
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(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..20b88c1 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -342,24 +342,21 @@ static void __init igep2_leds_init(void)
static inline void igep2_leds_init(void)
{
if ((gpio_request(IGEP2_GPIO_LED0_RED, gpio-led:red:d0) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED0_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_RED, 0);
- gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_RED\n);
if ((gpio_request(IGEP2_GPIO_LED0_GREEN, gpio-led:green:d0) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
- gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n);
if ((gpio_request(IGEP2_GPIO_LED1_RED, gpio-led:red:d1) == 0)
- (gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
+ (gpio_direction_output(IGEP2_GPIO_LED1_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED1_RED, 0);
- gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
}
@@ -397,10 +394,9 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
-(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0)) {
+(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
- gpio_set_value(gpio + TWL4030_GPIO_MAX + 1, 0);
- } else
+ else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
#else
igep2_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3: igepv2: LED gpio-led:green:d1 is active low
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 a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 20b88c1..41a4b25 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -317,6 +317,7 @@ static struct gpio_led igep2_gpio_leds[] = {
.name = gpio-led:green:d1,
.default_trigger= heartbeat,
.gpio = -EINVAL, /* gets replaced */
+ .active_low = 1,
},
};
@@ -394,7 +395,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
-(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
+(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
--
1.7.2.2
--
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
linux-next: manual merge of the trivial tree with the omap tree
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 (suspend: constify
platform_suspend_ops) from the trivial tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/pm24xx.c
index aaeea49,aa9764e..000
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@@ -354,13 -326,7 +354,13 @@@ static void omap2_pm_finish(void
enable_hlt();
}
+static void omap2_pm_end(void)
+{
+ suspend_state = PM_SUSPEND_ON;
+}
+
- static struct platform_suspend_ops omap_pm_ops = {
+ static const struct platform_suspend_ops omap_pm_ops = {
+ .begin = omap2_pm_begin,
.prepare= omap2_pm_prepare,
.enter = omap2_pm_enter,
.finish = omap2_pm_finish,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor
- 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 V heman...@ti.com
Date: Wed, 1 Dec 2010 16:28:51 +0530
Subject: [PATCH] omap4: Add platform changes for Ambient Light sensor
Register BH1780GLI Ambient light sensor, which is an I2C device
for 4430SDP board.
Tony, would you be pulling these patches for the next merge window.
Thanks
Hemanth
Signed-off-by: Hemanth V heman...@ti.com
---
BH1780GLI Driver is part of mainline kernel
arch/arm/mach-omap2/board-4430sdp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 49b5a7b..d8ef903 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -465,6 +465,9 @@ static struct i2c_board_info __initdata
sdp4430_i2c_3_boardinfo[] = {
{
I2C_BOARD_INFO(tmp105, 0x48),
},
+ {
+ I2C_BOARD_INFO(bh1780, 0x29),
+ },
};
static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
{
--
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
--
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
