On Thu, Oct 21, 2010 at 03:17:47PM -0500, Kevin Hilman wrote:
You're right, I wasn't as picky about this before, but will be going
forward. You're the lucky first victim. :)
someone has to be stoned first. Hmm, that does sound ambiguous.
Replacing clk_disable() with put_sync() is the correct
Grazvydas Ignotas wrote:
> On Thu, Oct 21, 2010 at 3:25 PM, Samreen wrote:
>> From: Erik Gilling
>>
>> NEC WVGA LCD NL8048HL11-01B panel support has been added.
>> This panel is being used in zoom2/zoom3/3630 sdp boards.
>>
>
>
>
>> diff --git
> a/drivers/video/omap2/displays/panel-nec-nl804
Hari,
On Thursday, October 21, 2010 3:49 PM Hari Kanigeri wrote:
> Rene,
>
> Thanks for your comment.
>
>
>>> @@ -92,20 +92,25 @@ int omap_mbox_msg_send(struct omap_mbox *mbox,
>>> mbox_msg_t msg) struct omap_mbox_queue *mq = mbox->txq;
>>> int ret = 0, len;
>>>
>>> - spin_lock
Rene,
Thanks for your comment.
>> @@ -92,20 +92,25 @@ int omap_mbox_msg_send(struct omap_mbox *mbox,
>> mbox_msg_t msg) struct omap_mbox_queue *mq = mbox->txq;
>> int ret = 0, len;
>>
>> - spin_lock(&mq->lock);
>> + spin_lock_bh(&mq->lock);
>>
>
> Please check if this scenari
Felipe Balbi writes:
> Add 32k timer hwmod to the database.
>
> Signed-off-by: Felipe Balbi
> ---
Looking closer at this patch, there are some other problems...
[...]
> +static struct omap_hwmod omap2420_counter_32k_hwmod = {
> + .name = "counter_32k",
> + .class =
Felipe Balbi writes:
> On Thu, Oct 21, 2010 at 12:57:41PM -0500, Kevin Hilman wrote:
>>Felipe Balbi writes:
>>
>>> Add 32k timer hwmod to the database.
>>>
>>> Signed-off-by: Felipe Balbi
>>
>>Not sure how this is working correctly on OMAP2 and OMAP3. All the
>>hwmods are mising the oh->prcm.o
Felipe Balbi writes:
> On Thu, Oct 21, 2010 at 12:46:11PM -0500, Kevin Hilman wrote:
>>Felipe Balbi writes:
>>
>>> Trivial patch removing clock framework and adding
>>> pm_runtime API.
>>>
>>> Signed-off-by: Felipe Balbi
>>
>>Minor nit: the runtime PM 'put' calls do not need to be the _sync
>>v
On 10/21/10 13:50, Tim Nordell wrote:
> If one does the following line twice with the old code:
>
> omap_mux_init_signal("uart3_rts_sd.gpio_164", OMAP_PIN_INPUT);
> omap_mux_init_signal("uart3_rts_sd.gpio_164", OMAP_PIN_INPUT);
>
> the compiler optimizes the two const strings into one string
> int
On Thu, Oct 21, 2010 at 12:57:41PM -0500, Kevin Hilman wrote:
Felipe Balbi writes:
Add 32k timer hwmod to the database.
Signed-off-by: Felipe Balbi
Not sure how this is working correctly on OMAP2 and OMAP3. All the
hwmods are mising the oh->prcm.omap2.module_offs field.
Without this, _wa
On Thu, Oct 21, 2010 at 01:00:19PM -0500, Kevin Hilman wrote:
Felipe Balbi writes:
Converted 32k-sync timer to platform_driver
and now using pm_runtime and hwmod.
Tested on 3430 by me and 4430 by Tarun
If someone could test on 2430 and 2420, I would
be really glad.
Hey, don't you have a 24
If one does the following line twice with the old code:
omap_mux_init_signal("uart3_rts_sd.gpio_164", OMAP_PIN_INPUT);
omap_mux_init_signal("uart3_rts_sd.gpio_164", OMAP_PIN_INPUT);
the compiler optimizes the two const strings into one string
internally in the compiler. The old code would modify
On Thu, Oct 21, 2010 at 12:46:11PM -0500, Kevin Hilman wrote:
Felipe Balbi writes:
Trivial patch removing clock framework and adding
pm_runtime API.
Signed-off-by: Felipe Balbi
Minor nit: the runtime PM 'put' calls do not need to be the _sync
versions. You can easily get by using the "nor
Hi Hari,
On Thursday, October 14, 2010 9:13 PM Kanigeri, Hari wrote:
> Schedule the Tasklet to send only when mailbox fifo is full, else
> send the message in the Process context. This would avoid
> needless scheduling of Tasklet for every message transfer
>
> Signed-off-by: Hari Kanigeri
> ---
his include to fix up a build break.
>
> Signed-off-by: Anand Gadiyar
> Cc: Tony Lindgren
> Cc: Ajay Kumar Gupta
> Cc: Felipe Balbi
> Cc: Greg Kroah-Hartman
> ---
> Build break observed with linux-next as of 20101021.
>
> Greg, okay with me to fold this into the
Felipe Balbi writes:
> Converted 32k-sync timer to platform_driver
> and now using pm_runtime and hwmod.
>
> Tested on 3430 by me and 4430 by Tarun
>
> If someone could test on 2430 and 2420, I would
> be really glad.
Hey, don't you have a 2420 device. There were some cool 2420-based
tablets a
Felipe Balbi writes:
> Add 32k timer hwmod to the database.
>
> Signed-off-by: Felipe Balbi
Not sure how this is working correctly on OMAP2 and OMAP3. All the
hwmods are mising the oh->prcm.omap2.module_offs field.
Without this, _wait_target_ready *should* fail, and the hwmod should not
actua
Felipe Balbi writes:
> Trivial patch removing clock framework and adding
> pm_runtime API.
>
> Signed-off-by: Felipe Balbi
Minor nit: the runtime PM 'put' calls do not need to be the _sync
versions. You can easily get by using the "normal" (async) versions
here.
Kevin
> ---
> arch/arm/plat
[updated version of the patch, fixing issues raised by Vishwa]
>From 1661b0f7ad614d221f90eed590040f2cca01c265 Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Thu, 23 Sep 2010 09:54:41 -0700
Subject: [PATCH] OMAP3: CPUidle: trigger early idle notification call chain
During the early part of the
"Sripathy, Vishwanath" writes:
>>
>> During the early part of the CPUidle path (state selection by the
>> governer, checking for device activity, etc.) there is no (good)
>> reason to have interrupts disabled.
>>
>> Therefore, enable interrupts early in the CPUidle path and then
>> trigger the
"Nayak, Rajendra" writes:
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Friday, October 15, 2010 9:10 PM
>> To: Shilimkar, Santosh
>> Cc: Nayak, Rajendra; linux-omap@vger.kernel.org; Paul Walmsley; Cousson,
>> Benoit
>> Subject: Re: [PATCH] OMA
* Gadiyar, Anand [101019 23:21]:
> On Wed, Oct 20, 2010 at 5:16 AM, Gadiyar, Anand wrote:
> > On Wed, Oct 20, 2010 at 5:02 AM, Tony Lindgren wrote:
> >> * Tony Lindgren [101019 15:48]:
> >>> * Gadiyar, Anand [101019 11:26]:
> >>> > On Tue, Oct 19, 2010 at 11:51 PM, Tony Lindgren
> >>> > wrot
* Felipe Balbi [101021 08:32]:
> Hi,
>
> On Thu, Oct 21, 2010 at 09:07:59AM -0500, Roger Quadros wrote:
> >But I'm not sure that omap_udc is used only for OMAP1 architecture.
> >Dave/Tony should confirm this.
>
> Maybe the old omap2420_h4 board still uses it, but from 2430 I think the
> ip isn't
Hi,
On Thu, Oct 21, 2010 at 09:07:59AM -0500, Roger Quadros wrote:
But I'm not sure that omap_udc is used only for OMAP1 architecture.
Dave/Tony should confirm this.
Maybe the old omap2420_h4 board still uses it, but from 2430 I think the
ip isn't even there anymore.
--
balbi
--
To unsubscrib
On 10/21/2010 12:13 PM, Nayak, Rajendra wrote:
Hi Kevin,
What the patch does is reprogram's the sysc value (from the cache)
whenever its lost. So its infact saved in the cache and restored when
needed.
Otherwise, all this patch does is refresh the _sysc_cache with
completely unknown conten
Hi,
On 10/20/2010 05:38 PM, ext Felipe Contreras wrote:
On Wed, Oct 20, 2010 at 3:33 PM, Roger Quadros wrote:
On 10/20/2010 12:23 PM, ext Felipe Contreras wrote:
On Wed, Oct 20, 2010 at 12:14 PM, Roger Quadros
wrote:
USB_G_NOKIA just needs a USB gadget controller to work. The gadget
contro
On Thu, Oct 21, 2010 at 3:25 PM, Samreen wrote:
> From: Erik Gilling
>
> NEC WVGA LCD NL8048HL11-01B panel support has been added.
> This panel is being used in zoom2/zoom3/3630 sdp boards.
>
> diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
> b/drivers/video/omap2/displa
On Thu, 2010-10-21 at 11:02 +0200, ext Grazvydas Ignotas wrote:
> Tomi can you queue this? This has been tested by multiple people now,
> also see here:
> http://marc.info/?l=linux-omap&m=128759415821646&w=2
Yes, I seem to have missed/forgotten this. I'll add it to my tree.
Tomi
--
To unsubscr
Hi,
On Fri, 2010-09-03 at 04:52 +0200, ext stanley.miao wrote:
> Hi, Tomi,
>
> Tomi Valkeinen wrote:
> >
> >
> > Otherwise this looks fine, except that panel-taal.c does not need
> > modifications, as it already handles this case.
> >
>
> I will send a V3 to remove the panel-taal.c part.
>
From: Erik Gilling
NEC WVGA LCD NL8048HL11-01B panel support has been added.
This panel is being used in zoom2/zoom3/3630 sdp boards.
Signed-off-by: Mukund Mittal
Signed-off-by: Rajkumar N
Signed-off-by: Samreen
CC: Subbu Venkatesh
CC: Erik Gilling
---
Version2:
- the brightness updati
Mugdha,
> > >>
> > >> This does not require any smart IPC and it will allow us to get
> > rid of
> > >> the omap_hwspinlock_request_specific() API and its early-callers
> > >> requirement.
> > >
> > > Yes, that would indeed simplify things.
> >
> > Balaji, Nishant, are you OK with this ?
> >
> The
On Thursday 21 October 2010, Ohad Ben-Cohen wrote:
> The change is also pretty trivial:
>
> * move the internal locking implementation to raw_ methods
> * the raw_ methods would save the current interrupt state only if
> given a placeholder
> * wrap those raw_ methods with the desired API (but onl
Hi,
On Thu, Oct 21, 2010 at 1:24 PM, Felipe Balbi wrote:
> On Thu, Oct 21, 2010 at 04:04:27AM -0500, Felipe Contreras wrote:
>>>
>>> wouldn't a user expect USB to be enabled if the board _has_ a USB
>>> connector ?
>>
>> Not if it's not going to be used.
>
> and how would you know before hand if
On Thu, Oct 21, 2010 at 04:20:06AM -0500, Gadiyar, Anand wrote:
Patch usb-am35x-add-musb-support.patch in greg's USB queue
adds backan include of . This file was renamed
by another commit in the omap tree and the file was already
fixed to reflect this.
Remove this include to fix up a build break
hi,
On Thu, Oct 21, 2010 at 04:04:27AM -0500, Felipe Contreras wrote:
wouldn't a user expect USB to be enabled if the board _has_ a USB
connector ?
Not if it's not going to be used.
and how would you know before hand if it's going to be used or not ?
1) Do you think all the OMAP3 boards sh
From: Bernard Blackham
Date: Tue, 19 Oct 2010 10:16:39 +1100
> The smsc95xx driver currently generates a new random MAC address
> every time the interface is brought up. This makes it impossible to
> override using the standard `ifconfig hw ether` approach.
>
> Past patches tried to make the MAC
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Friday, October 15, 2010 9:10 PM
> To: Shilimkar, Santosh
> Cc: Nayak, Rajendra; linux-omap@vger.kernel.org; Paul Walmsley; Cousson,
> Benoit
> Subject: Re: [PATCH] OMAP: hmwod: Update the sysc_cache i
On Thu, Oct 21, 2010 at 11:04 AM, Arnd Bergmann wrote:
> On Thursday 21 October 2010, Ohad Ben-Cohen wrote:
>> This sounds like adding a set of API that resembles spin_{unlock,lock}_irq.
>>
>> My gut feeling here is that while this may be useful and simple at
>> certain places, it is somewhat erro
Sorry, I did missed this mail...
On Saturday 09 October 2010 01:17:46 ext Tony Lindgren wrote:
> Guys, as we're so late into getting 2.6.36 tagged, I'm thinking about just
> queueing these for 2.6.37 for the following reasons:
>
> - The 24xx patch is a fix for commit c12abc0 that's was merged ov
Ajay Kumar Gupta
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
---
Build break observed with linux-next as of 20101021.
Greg, okay with me to fold this into the original patch
if the others in copy agree. It's a trivial enough change.
The patch that renamed plat/control.h is this one:
http://git.ker
> -Original Message-
> From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-
> ow...@vger.kernel.org] On Behalf Of Grazvydas Ignotas
> Sent: Thursday, October 21, 2010 2:32 PM
> To: tomi.valkei...@nokia.com
> Cc: Stanley.Miao; linux-omap@vger.kernel.org; bryan...@canonical.com;
> m
On Thu, Oct 21, 2010 at 10:36 AM, Kamoolkar, Mugdha wrote:
>> wrote:
>> > Yes, that would indeed simplify things.
>>
>> Balaji, Nishant, are you OK with this ?
>>
> The problem with this approach is that the i2c driver would have to
> sync up on the shared memory location that it uses to share th
On Wed, Oct 20, 2010 at 8:54 PM, Felipe Balbi wrote:
> On Wed, Oct 20, 2010 at 11:22:17AM -0500, Felipe Contreras wrote:
>>
>> Users would not need to care... if they enable USB and USB_GADGET, it
>> will be selected automatically for OMAP3, which is what users would
>> expect.
>
> wouldn't a user
On Thursday 21 October 2010, Ohad Ben-Cohen wrote:
> This sounds like adding a set of API that resembles spin_{unlock,lock}_irq.
>
> My gut feeling here is that while this may be useful and simple at
> certain places, it is somewhat error prone; a driver which would
> erroneously use this at the w
Tomi can you queue this? This has been tested by multiple people now,
also see here:
http://marc.info/?l=linux-omap&m=128759415821646&w=2
On Fri, Sep 3, 2010 at 6:03 AM, Stanley.Miao wrote:
> If we blank the panel by
> echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank
>
> Then, we reboot t
> wrote:
> >> Let's take the i2c-omap for example.
> >>
> >> It sounds like it must have a predefined hwspinlock, but what if:
> >>
> >> 1. It will use omap_hwspinlock_request() to dynamically allocate
> a hwspinlock
> >> 2. Obviously, the hwspinlock id number must be communicated to
> the M3
> >>
45 matches
Mail list logo
