Hello Suresh,
On Wed, 9 Jun 2010 12:50:39 -0700
Suresh Rajashekara wrote:
> I have an application (running on 2.6.29-omap1) which puts an OMAP1
> system to suspend aggressively. The system wakes up every 4 seconds
> and stays awake for about 35 milliseconds and sleeps again for another
> 4 secon
* Dmitry Torokhov [100601 23:07]:
> On Tue, Jun 01, 2010 at 09:53:58PM +0300, Felipe Balbi wrote:
> > On Tue, Jun 01, 2010 at 05:14:09PM +0200, ext Arce, Abraham wrote:
> > >I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what
> > >you are suggesting is to check at runtime?
> >
> >
Hi,
1. What is the alternative way of submitting defconfig changes/files to LO?
2. Can any of you give me examples?
Regards,
Rajkumar N.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, June 09, 2010 3:57 PM
> To: Nagarajan,
On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
> 1. What is the alternative way of submitting defconfig changes/files to LO?
I don't think we have any alternative yet.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a mess
On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> Do we at least have a clean way that a driver can
> reject a system suspend? I've lost track of many
> issues, but maybe this could be phrased as a QOS
> constraint: the current config of driver X needs
> clock Y active to enter the targ
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
> > You've lost me. If the power manager is sitting inside a select/poll,
> > how can it miss the event (given that the event will make data
> > available to be read on one of the descriptors being polled)?
> >
>
> It cannot sit inside of select/poll al
I have spent the past few weeks whacking at a problem with the 2.6.33
dspbridge kernel, and I'm hoping someone can help me out.
With a straight-up build of the head of the dspbridge kernel
(currently 2.6.33), doing an arecord fails to capture data. Using
JTAG, I was able to trace through the kern
On Thu, 10 Jun 2010, David Brownell wrote:
> This is a bit off the topic of Android
> flamage, but I thought it would be worth
> highlighting an example where the current
> frameworks may still have a deficiency...
> one that likewise relates to needing to
> block entry ot a system suspend state,
On Fri, 11 Jun 2010, James Bottomley wrote:
> On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> > Do we at least have a clean way that a driver can
> > reject a system suspend? I've lost track of many
> > issues, but maybe this could be phrased as a QOS
> > constraint: the current confi
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Felipe Contreras
> Sent: Friday, June 11, 2010 8:43 AM
> To: Nagarajan, Rajkumar
> Cc: Laurent Pinchart; linux-me...@vger.kernel.org; Hiremath, Vaibhav;
> linux-omap@v
On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, James Bottomley wrote:
> > The one thing that does look difficult is that these power constraints
> > are device (and sometimes SoC) specific. Expressing them in a generic
> > way for the cpu govenors to make sense
On Fri, 2010-06-11 at 10:46 -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, James Bottomley wrote:
>
> > On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
> > > Do we at least have a clean way that a driver can
> > > reject a system suspend? I've lost track of many
> > > issues, but maybe
Hi Sergio,
On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Felipe Contreras
> > Sent: Friday, June 11, 2010 8:43 AM
> > To: Nagarajan, Rajkumar
> > Cc: Lau
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Friday, June 11, 2010 10:08 AM
> To: Aguirre, Sergio
> Cc: Felipe Contreras; Nagarajan, Rajkumar; linux-me...@vger.kernel.org;
> Hiremath, Vaibhav; linux-omap@vger.kernel.org
> Subj
Laurent Pinchart wrote:
> On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
> > > On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
> > > > 1. What is the alternative way of submitting defconfig changes/files to
> > >
> > > LO?
> >
> > I don't think defconfig changes are prohibited
On Mon, May 24, 2010 at 5:42 PM, Hiroshi DOYU wrote:
> From: ext Felipe Contreras
> Subject: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()
> Date: Sat, 22 May 2010 19:14:24 +0200
>
>> No need to dynamically register mailboxes one by one.
>
> Can you squash this into [PATCH 10/14]?
On Fri, Jun 11, 2010 at 6:17 PM, Felipe Contreras
wrote:
> On Mon, May 24, 2010 at 5:42 PM, Hiroshi DOYU wrote:
>> From: ext Felipe Contreras
>> Subject: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()
>> Date: Sat, 22 May 2010 19:14:24 +0200
>>
>>> No need to dynamically register
Hi Anand,
On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote:
> Laurent Pinchart wrote:
> > On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
> > > > On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
> > > > > 1. What is the alternative way of submitting defconfig
> > > > > change
Felipe,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe
> Balbi
> Sent: Wednesday, April 07, 2010 11:04 PM
> To: ext Kevin Hilman
> Cc: Balbi Felipe (Nokia-D/Helsinki); Linux OMAP Mailing List
> Subject: Re: [PAT
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Friday, June 11, 2010 10:26 AM
> To: Gadiyar, Anand
> Cc: Aguirre, Sergio; Felipe Contreras; Nagarajan, Rajkumar; linux-
> me...@vger.kernel.org; Hiremath, Vaibhav; linux-omap@vger.kernel.org
On 11/06/10 16:14, Gadiyar, Anand wrote:
> Laurent Pinchart wrote:
>> On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
> 1. What is the alternative way of submitting defconfig changes/files to
LO?
>>>
>>> I don't t
From: Felipe Contreras <--global>
Hi,
These are hopefully non-functional changes. Just shuffling code around, and
removing unecessary stuff.
This v4 includes minor changes suggested by Felipe Balbi, Hiroshi, and Russell.
Comments from Felipe Balbi, Tony Lindgren, Hiroshi DOYU, and Russell King.
Signed-off-by: Felipe Contreras
---
arch/arm/plat-omap/mailbox.c | 44 +-
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 36b3aa2..38a6cb1 100644
--- a/arch/arm/plat-omap/m
And fix a few compilation warnings.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c |6 ++
arch/arm/mach-omap1/mailbox.c |2 +-
arch/arm/mach-omap2/mailbox.c | 10 ++
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap1/device
OMAP4 ones messed up the organization.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/mailbox.c | 68 +
1 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 8c1070c.
CONFIG_OMAP_DSP is not in mainline, CONFIG_OMAP_MBOX_FWK is.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 462b59c..da796f2 100644
---
Based on omap2 code.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 15bf2a2..211b9fc 100644
--- a/arch/arm/
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/mailbox.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index edcfec6..f67cb2c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/ma
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c |1 -
arch/arm/mach-omap2/mailbox.c |3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 211b9fc..590ac66 100644
--- a/arch/arm/mach-omap
Nobody is using them.
Signed-off-by: Felipe Contreras
---
arch/arm/plat-omap/include/plat/mailbox.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0c3c4a5..aad8bf8 100644
Will be useful to identify them later.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c |1 +
arch/arm/mach-omap2/devices.c |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index da796f2
It's more extensible this way.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 42
arch/arm/mach-omap2/mailbox.c | 107 +
2 files changed, 66 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c
No need to dynamically register mailboxes one by one.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c | 25 ++--
arch/arm/mach-omap2/mailbox.c | 22 ++-
arch/arm/plat-omap/include/plat/mailbox.h |5 +-
arch/arm/plat-omap/mailbox.c
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/mailbox.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 55d8b77..4c0c112 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/
omap{1,2}-mailbox are modules that provide the 'omap-mailbox' driver.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap1/mailbox.c |4 ++--
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/mailbox.c |6 ++
4 files changed, 6 i
Remove kernel.h and module.h since they are not used correctly anyway.
Also, remove device.h since it comes along with platform_device.h
(always will I guess).
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c |3 ---
arch/arm/mach-omap2/mailbox.c |
On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
wrote:
> My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
> unless someone can convince him not to.
Huh? I thought he was only threatening to remove them[1]. I don't
think he said he was going to do that without any alterna
On Fri, 11 Jun 2010, Mark Brown wrote:
> On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> > On Fri, 11 Jun 2010, James Bottomley wrote:
>
> > > The one thing that does look difficult is that these power constraints
> > > are device (and sometimes SoC) specific. Expressing them in a
On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, Mark Brown wrote:
>
> > On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> > > On Fri, 11 Jun 2010, James Bottomley wrote:
> >
> > > > The one thing that does look difficult is that these power constraints
> >
As pointer by Ben Ohand, the variable rq_full flag is a global
variable, so if there are multiple mailbox user there will be
conflics. Now there is a full flag per mailbox queue.
Reported-by: Ohad Ben-Cohen
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/plat-omap/include/plat/mailbox.h |1
2010/6/11 Alan Stern :
> On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
>
>> > You've lost me. If the power manager is sitting inside a select/poll,
>> > how can it miss the event (given that the event will make data
>> > available to be read on one of the descriptors being polled)?
>> >
>>
>> It cann
>From: Ramirez Luna, Omar
>
>These set of patches gets rid of the custom error codes still present.
>
>Although there are a lot of patches most of them are just replacements
>which were broken into single patches to avoid big patch files.
>
>One of the patches creates a help file with the matching
--- On Fri, 6/11/10, James Bottomley wrote:
> > Do we at least have a clean way that a driver can
> > reject a system suspend? I've lost track of
> many
> > issues, but maybe this could be phrased as a QOS
> > constraint: the current config of driver X
> needs
> > clock Y active to enter the
43 matches
Mail list logo
