Hi Ohad,
>From: Ohad Ben-Cohen [o...@wizery.com]
>Sent: Tuesday, June 08, 2010 9:35 PM
>To: Sapiens, Rene; Guzman Lugo, Fernando
>Cc: Hiroshi DOYU; linux-omap@vger.kernel.org;
>linux-arm-ker...@lists.infradead.org; Kanigeri, Hari
>Subject: Re: [PATCH 09/1
>From: Hiroshi DOYU [hiroshi.d...@nokia.com]
>Sent: Wednesday, June 09, 2010 12:07 AM
>To: o...@wizery.com
>Cc: Guzman Lugo, Fernando; Chitriki Rudramuni, Deepak; Ramirez Luna, Omar;
>Kanigeri, Hari; linux-omap@vger.kernel.org
>Subject: Re: [PATCH v3 4/4]
From: ext Ohad Ben-Cohen
Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Date: Tue, 8 Jun 2010 04:54:55 +0200
> On Mon, Jun 7, 2010 at 6:14 PM, Guzman Lugo, Fernando
> wrote:
>> I think the best thing to do here is remove the spinlock
>
> I'm afraid we can't do that: we ne
On Tue, 8 Jun 2010, da...@lang.hm wrote:
>
> having suspend blockers inside the kernel adds significant complexity, it's
> worth it only if the complexity buys you enough. In this case the question is
> if the suspend blockers would extend the sleep time enough more to matter. As
> per my other
Hi Rene,
On Tue, Jun 8, 2010 at 7:16 PM, Sapiens, Rene wrote:
> In mbox_rx_work() you are removing the lines that enable back the mbox irq
> for the RX case, but inside __mbox_rx_interrupt() this interrupt is
> disabled in the case that the kfifo for Rx mailbox gets full. So I think that
>
2010/6/8 Alan Stern :
> On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
>
>> The patch that modifies evdev (posted in this patchset) uses an ioctl
>> to enable the suspend blocker. Not all input devices are used for
>> wakeup events and those don't need to block suspend.
>
> But you do have a 1-1 corresp
On Mon, 7 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool wrote:
2010/6/6 :
as an example (taken from this thread).
system A needs to wake up to get a
Renaming and deleting unused variables, few enhancement on
error path.
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/rmgr/drv_interface.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/dri
A function containing driver low lever initializations has been
created. Now device entry should be available only if the startup
call has completed successfully, in case of error rollback any
of the changes that apply.
Now, device entry is created after bridge initializations
have been completed.
Split the functions to have cleaner error handling paths, this
will aslo cover a case where bridge initialization has failed but
device entry is still available which leads to unknown behavior.
Omar Ramirez Luna (2):
DSPRBIDGE: split probe from bridge initializations
DSPBRIDGE: reorganize prob
Hi Ohad,
In mbox_rx_work() you are removing the lines that enable back the mbox irq for
the RX case, but inside __mbox_rx_interrupt() this interrupt is disabled in
the case that the kfifo for Rx mailbox gets full. So I think that we need to
enable it back as soon as there is space in this kf
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Tuesday, June 08, 2010 5:05 AM
> Sorry for the delay, here's some more info on this issue. So it looks
> like starting with 3630 there are dedicated pull-up for all the I2C bus
On Mon, Jun 7, 2010 at 6:14 PM, Guzman Lugo, Fernando
wrote:
> I think the best thing to do here is remove the spinlock
I'm afraid we can't do that: we need it to support OMAP4 syslink IPC
use cases which have multiple simultaneous sending contexts.
>, if not, you are preventing that omap_mbox_
On Tue, 8 Jun 2010 15:41:40 -0500, Sergio Aguirre wrote:
> This fixes the following warning:
>
> drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend':
> drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state'
>
> Introduced by commit ID:
>
> commit 1a13f8fa76c880be41d
This fixes the following warning:
drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend':
drivers/mmc/host/omap_hsmmc.c:2275: warning: unused variable 'state'
Introduced by commit ID:
commit 1a13f8fa76c880be41d6b1e6a2b44404bcbfdf9e
Author: Matt Fleming
Date: Wed May 26 14:42:08
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Tuesday, June 08, 2010 4:56 AM
> To: felipe.contre...@gmail.com
> Cc: Guzman Lugo, Fernando; o...@wizery.com; Chitriki Rudramuni, Deepak;
> Ramirez Luna, Omar; Kanigeri, Hari; linux-omap@vger.kernel.org
> Su
Reviewed-by: Vimal Singh
On Fri, Jun 4, 2010 at 1:10 PM, Sukumar Ghorai wrote:
> The following set of patches applies on top of for-next branch.
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git
> Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle bo
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Monday, June 07, 2010 10:40 PM
> To: o...@wizery.com
> Cc: Chitriki Rudramuni, Deepak; Guzman Lugo, Fernando; Ramirez Luna, Omar;
> Kanigeri, Hari; linux-omap@vger.kernel.org
> Subject: Re: [PATCH v3 4/4] om
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
> The patch that modifies evdev (posted in this patchset) uses an ioctl
> to enable the suspend blocker. Not all input devices are used for
> wakeup events and those don't need to block suspend.
But you do have a 1-1 correspondence, right? That is, the i
From: Kevin Hilman
Checking to se if the IO daisy chain is enabled should be checking the
PM_WKEN register, not the PM_WKST register. Reading PM_WKST tells us
if an event occurred, not whether or not it is enabled.
Apparently, we've been lucky until now in that a pending event has not
been ther
From: Kevin Hilman
The addition of the new debounce code (commit
168ef3d9a56bd8bffe0ef4189c450888b4aefefe) broke the auto-disable of
debounce clocks on idle by forgetting to update the debounce clock
enable mask.
Add back the updating of bank->dbck_enable_mask so debounce clocks are
auto-disable
From: Tero Kristo
The kernel timer queue is being run currently from a GP timer running in a one
shot mode, which works in a way that when it expires, it will also stop.
Usually during this situation, the interrupt handler will ack the interrupt,
load a new value to the timer and start it again.
From: Santosh Shilimkar
With latest linus's tip, omap3_defconfig is broken.
LD init/built-in.o
LD .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o: In function `ads7846_dev_init':
linux-2.6/arch/arm/mach-omap2/board-omap3stalker.c:542: undefined reference to
`omap_set_gpio_debounce'
li
From: Amit Kucheria
Fixes following error,
CC arch/arm/mach-omap2/usb-ehci.o
arch/arm/mach-omap2/usb-ehci.c:263: error: implicit declaration of function
'DMA_BIT_MASK'
arch/arm/mach-omap2/usb-ehci.c:263: error: initializer element is not constant
make[1]: *** [arch/arm/mach-omap2/usb-ehci.o
Hi all,
Here are few omap fixes for review. I've moved anything that's not
absolutely needed as a fix into for-next as requested by Linus.
Regards,
Tony
---
Amit Kucheria (1):
omap: fix build failure due to missing include dma-mapping.h
Kevin Hilman (2):
omap: GPIO: fix auto-disab
* Hiroshi DOYU [100607 14:45]:
> From: ext Tony Lindgren
> Subject: Re: [GIT PULL] omap iommu: fixes for 2.6.35-rc1
> Date: Mon, 7 Jun 2010 13:17:48 +0200
>
> > Since Linus only wants regression fixes nowadays during the -rc
> > cycle, few more questions below.
> >
> > * Hiroshi DOYU [100602 1
On Mon, 7 Jun 2010 20:05:56 -0700
Arve Hjønnevåg wrote:
Hi,
>
> If you read an event that occurred after you blocked the task
> freezing, then tasks will never get frozen again (until more events
> occur). I think my original description was less confusing, but it
> seems you got completely dist
Hi,
* Sonasath, Moiz [100323 00:40]:
> Tony,
>
> > -Original Message-
> > From: Sonasath, Moiz
> > Sent: Friday, February 26, 2010 1:15 PM
> > To: linux-omap@vger.kernel.org
> > Cc: t...@atomide.com; Sonasath, Moiz; Pais, Allen; Pandita, Vikram
> > Subject: [PATCH V3 2/2]OMAP: Disable in
From: ext Felipe Contreras
Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Date: Tue, 8 Jun 2010 11:43:28 +0200
> On Tue, Jun 8, 2010 at 6:46 AM, Hiroshi DOYU wrote:
>> From: "ext Guzman Lugo, Fernando"
>>> I think the best thing to do here is remove the spinlock, if not,
On Tue, Jun 8, 2010 at 6:55 AM, Hiroshi DOYU wrote:
> From: ext Ohad Ben-Cohen
> Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
> Date: Tue, 8 Jun 2010 05:11:50 +0200
>
>> Hi Deepak,
>>
>> On Mon, Jun 7, 2010 at 6:27 PM, Deepak Chitriki
>> wrote:
Ohad Ben-Cohen wrote
On Tue, Jun 8, 2010 at 6:46 AM, Hiroshi DOYU wrote:
> From: "ext Guzman Lugo, Fernando"
>> I think the best thing to do here is remove the spinlock, if not,
>> you are preventing that omap_mbox_msg_send be executed from a
>> tasklet or isr context. That maybe in this moment it is not called
>> bu
On Tuesday 08 June 2010, Arve Hjønnevåg wrote:
> 2010/6/6 Rafael J. Wysocki :
> > On Sunday 06 June 2010, Arve Hjønnevåg wrote:
...
> If individual processes are frozen, we run into problems that we
> cannot run into if we freeze and thaw all processes.
Not individual processes, but the processes
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It has USB phy built inside the IP itself.
Also added ARCH_AM35x which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used to for below
purposes,
- Select am3517.c instead of omap2430.c
On Mon, 2010-06-07 at 18:17 +0200, ext Luke-Jr wrote:
> On Monday 07 June 2010 02:47:34 am Tomi Valkeinen wrote:
> > I don't have any device that uses RFBI so I can't test it, but how about
> > this patch:
>
> Unfortunately, I can't test it either since N8x0 has no mainline support for
> video ou
34 matches
Mail list logo
