* Paul Walmsley [110712 23:33]:
> Hi Tony,
>
> On Mon, 11 Jul 2011, Tony Lindgren wrote:
>
> > Paul, please use the mainline tags or linux-omap static branches
> > instead of the arm-soc branches. In this case there's only the extra
> > merge commit there, so not a problem. Now it just makes it
Hi Tony,
On Mon, 11 Jul 2011, Tony Lindgren wrote:
> Paul, please use the mainline tags or linux-omap static branches
> instead of the arm-soc branches. In this case there's only the extra
> merge commit there, so not a problem. Now it just makes it a bit
> harder for me to do pull requests and d
* Jan Weitzel [110712 01:36]:
> Am Montag, den 11.07.2011, 04:47 -0700 schrieb Tony Lindgren:
>
> > Then there are two new boards remaining, but they both are waiting
> > on the machine_id patch.
> >
>
> If one of them is our pcm049 OMAP4 board, the machine_id is already in.
> pcm049
* Arnd Bergmann [110711 15:11]:
> On Monday 11 July 2011, Tony Lindgren wrote:
> > Hi Arnd,
> >
> > Below is a summary of the pending omap pull requests as there are still
> > few branches pending.
> >
> > Can you please take a look and see what you can take of these for v3.1
> > merge window?
>
[...]
> A better solution is to just get rid of this macro and use a static
> inline.
>
> The patch below does just this, and I'm including it into my
> gpio-cleanup series (branch: for_3.1/gpio-cleanup-2.) Please rebase
> your updated series on that branch.
Alright! Thanks.
--
Tarun
>
> Kevin
[...]
>
> And also, change all subject prefixes to 'gpio/omap: ...' as requested
> by GPIO maintainer.
Ok.
>
> Kevin
--
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/majord
While using clockdomain force wakeup method, not waiting for powerdomain
to be effectively ON may end up locking the clockdomain FSM until a
next wakeup event occurs.
One such issue was seen on OMAP4430, where L4_PER was periodically
getting stuck in in-transition state when transitioning from fro
From: Rajendra Nayak
Program all powerdomain target state as ON; This is to
prevent domains from hitting low power states (if bootloader
has target states set to something other than ON) and potentially
even losing context while PM is not fully initilized.
The PM late init code can then program t
With CONFIG_PM_RUNTIME disabled, we have a few problems due to the
current way of handling the postsetup_state of each hwmod.
The primary one is that the omap_hwmod internal startup state does not
match the omap_device internal state. For example, with
!CONFIG_PM_RUNTIME, all the hwmods are left
Hello,
Paul Walmsley wrote on Friday, April 29, 2011 8:29 AM:
> On Thu, 28 Apr 2011, Grosen, Mark wrote:
>
>>> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley
>>> Sent: Thursday, April 28, 2011 3:35 PM
>>>
>>> to review these patches
On Tue, Jul 12, 2011 at 10:35:53PM +0300, Péter Ujfalusi wrote:
> Just to avoid confusion (in my part): if I split this patch to one big +
> several small incremental patches, which eventually lead to the current
> situation is what you were asking for?
The rest of the patch looked fine from a
Signed-off-by: Todd Poynor
---
arch/arm/mach-omap2/irq.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 3af2b7a..acbb05c 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -129,6 +12
Shubhrajyoti D writes:
> The keypad data is accessed only at init so making it initdata.
> This removes the section mismatch warning.
>
> Reported-by: Kevin Hilman
> Signed-off-by: Shubhrajyoti D
Acked-by: Kevin Hilman
Tony, if it's not too late, this should probably queue for v3.1 so that
i
Hi,
On Tuesday, July 12, 2011, Kevin Hilman wrote:
> For v3.1, the PM core has some changes that impact various assumptions
> made (by me) during the design and implementation of the PM domain
> support in the omap_device layer.
>
> This series is needed to update our PM domain layer to behave pr
On Saturday 09 July 2011 03:08:10 Mark Brown wrote:
> I've got a few ideas but nothing comprehensive right now; the main thing
> I can think we're missing at the minute is more fine grained hooks
> around stream start in order to allow things to clock off the audio
> stream. Equally well none of t
On Mon, Jul 11, 2011 at 11:01 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 11, 2011 at 03:43:17PM -0700, Dima Zavin wrote:
>> Set a flag on OTG charger event and check it on cable
>> remove event (i.e. USB_EVENT_NONE). This way we will
>> not need to power up the PHY when an external charger
>
>
The keypad data is accessed only at init so making it initdata.
This removes the section mismatch warning.
Reported-by: Kevin Hilman
Signed-off-by: Shubhrajyoti D
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap
On Fri, 2011-07-08 at 11:04 +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 08, 2011 at 01:52:17PM +0530, Raju, Sundaram wrote:
> > I am planning to move TI SDMA driver in OMAP tree
> > into the dmaengine framework.
> >
> > The first immediate issue of concern I noticed is the
> > huge number
"DebBarma, Tarun Kanti" writes:
> Kevin,
> [...]
>>
>> >set_gpio_trigger(bank, gpio, trigger);
>> >} else if (bank->regs->irqctrl) {
>> >reg += bank->regs->irqctrl;
>> > @@ -295,13 +296,7 @@ static int _set_gpio_triggering(struct gpio_bank
>> *bank, int gpio, int trig
On Wed, Jul 6, 2011 at 9:16 PM, DebBarma, Tarun Kanti
wrote:
>> -Original Message-
>> From: Hilman, Kevin
>> Sent: Thursday, July 07, 2011 2:37 AM
>> To: DebBarma, Tarun Kanti
>> Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; t...@atomide.com
>> Subject: Re: [PATCH v3 00/20] GPIO: OMA
Have a new board with the omap4 and toshiba bridge chipset.
The board has two lanes instead of four.
Removed DSI_COMPLEXIO_CFG1 entries for data3_lane, data3_pol,
data4_lane, and data4_pol.
With 4 lanes configured we see traffic on the scope ,but the toshiba
drops it since the board has only
Shubhrajyoti D writes:
> The keypad data is accessed only at init so making it initdata.
> This removes the section mismatch warning.
>
> Reported-by: Kevin Hilman
> Signed-off-by: Shubhrajyoti D
Please Cc: linux-arm-kernel on upstream patches.
Also, as this is specific to a particular board,
Santosh Shilimkar writes:
> On 7/11/2011 4:21 PM, Kevin Hilman wrote:
>> Fix boot crash in watchdog driver when runtime PM is disabled.
>>
>> When runtime PM is disabled, devices should be left enabled so that
>> all device accesses in drivers will succeed even though the runtime PM
>> get/put ca
On Tue, Jul 12, 2011 at 5:01 PM, Raju, Sundaram wrote:
>> -Original Message-
>> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
>> Sent: Tuesday, July 12, 2011 4:51 PM
>> To: Linus Walleij
>> Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
>> ker...@vger.kernel.org; dav
+linux_pm.
Vishwa
> -Original Message-
> From: Govindraj [mailto:govindraj...@gmail.com]
> Sent: Tuesday, July 12, 2011 5:14 PM
> To: linux-omap@vger.kernel.org
> Cc: Kevin Hilman; Paul Walmsley; Basak, Partha; Tony Lindgren;
> Sripathy, Vishwanath; linux-arm-ker...@lists.infradead.org; R
Hi All,
With recent uart runtime conversion I am facing some issues with runtime
API usage with console.
With runtime adaptation the clock cutting is done aggressively with get and put.
as below with console_write API in uart code.
serial_omap_console_write(.)
{
get_sync();
.
> -Original Message-
> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
> Sent: Tuesday, July 12, 2011 4:51 PM
> To: Linus Walleij
> Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com;
> li...@arm.linux
On Tue, Jul 12, 2011 at 3:33 PM, Linus Walleij wrote:
> On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar wrote:
>
>> 1) Striding, in one form or other, is supported by other DMACs as well.
>> The number will only increase in future.
>> Are we to add _DMA_STRIDE_CONFIG for each case ?
>
> If we ar
On Tue, Jul 12, 2011 at 12:56 PM, Raju, Sundaram wrote:
> [Me]
>> [Jassi]
>> > 3) TI may not have just one DMAC IP used in all the SoCs. So if you want
>> > vendor specific defines anyway, please atleast also add DMAC version to
>> > it.
>> > Something like
>> >> DMA_SLAVE_CONFIG,
>> >>
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Tuesday, July 12, 2011 3:33 PM
> To: Jassi Brar
> Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com;
> li...@arm.linux
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Tuesday, July 12, 2011 3:28 PM
> To: Dan Williams
> Cc: Raju, Sundaram; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; davinci-linux-open-sou...@linux.davincidsp.com;
> li...@arm.lin
On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar wrote:
> 1) Striding, in one form or other, is supported by other DMACs as well.
> The number will only increase in future.
> Are we to add _DMA_STRIDE_CONFIG for each case ?
If we are sure about this and striding will work in a similar way on all
On Mon, Jul 11, 2011 at 11:39 PM, Dan Williams wrote:
> On Mon, Jul 11, 2011 at 2:28 AM, Linus Walleij
> wrote:
> ...and I suspect the slave device drivers that use TI DMA are not
> expected to ever work with other dmaengines? Likely the case, but
> just wondering out loud.
Typically the OMAP
On Thu, 9 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote:
> On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
> > On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
> > > Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
> > > > On Fri, Dec 10, 2010
On Tuesday, July 12, 2011, Kevin Hilman wrote:
> This boolean function simply returns whether or not the runtime status
> of the device is 'suspended'. Unlike pm_runtime_suspended(), this
> function returns the runtime status whether or not runtime PM for the
> device has been disabled or not.
>
On Tuesday 12 July 2011 12:09 PM, Vishwanath Sripathy wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shubhrajyoti D
Sent: Tuesday, July 12, 2011 12:02 PM
To: linux-omap@vger.kernel.org
Cc: Shubhrajyoti D
Subject: [P
The keypad data is accessed only at init so making it initdata.
This removes the section mismatch warning.
Reported-by: Kevin Hilman
Signed-off-by: Shubhrajyoti D
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap
Am Montag, den 11.07.2011, 04:47 -0700 schrieb Tony Lindgren:
> Then there are two new boards remaining, but they both are waiting
> on the machine_id patch.
>
If one of them is our pcm049 OMAP4 board, the machine_id is already in.
pcm049 MACH_PCM049 PCM049
38 matches
Mail list logo
