Hi Felipe,
On Mon, May 17, 2010 at 3:05 AM, Felipe Contreras
wrote:
> On Mon, May 17, 2010 at 2:25 AM, Ohad Ben-Cohen wrote:
>> Out of curiosity, what board/environment do you use to play with
>> the code ? I'd like to run the same use cases you do, so I can
>> reproduce any issue you may bump i
Hi Hari,
From: ext Hari Kanigeri
Subject: [PATCH 1/2] omap: iommu-update irq mask to be specific about twl
Date: Tue, 18 May 2010 01:12:29 +0200
> Update the irq mask so that is is clear that the MMU
~~typo?
> interrupt is related to TWL fault.
>
> Signed-off-by:
Hi Hari,
From: ext Hari Kanigeri
Subject: [PATCH 2/2] omap: iommu-add functionality to get TLB miss interrupt
Date: Tue, 18 May 2010 01:12:30 +0200
> In order to enable TLB miss interrupt, the TWL should be
> disabled. This patch provides the functionality to get the
> MMU fault interrupt for a
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Tuesday, May 18, 2010 8:23 AM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; Krishnamoorthy, Balaji T
> Subject: Re: [PATCH 1/3] omap4: Add i2c board support on omap4430 sdp platform
>
> * Santosh Shil
Hi All,
I have been trying to find the reason for the problem I am facing with
CFS and process with SCHED_FIFO.
Here is a small program I wrote.
/* Lets call this V1 */
#include
#include
/* There are other includes but for brevity I have not shown */
main ()
{
/* I have even tried using the
* Anders, David [100517 13:13]:
> Add initial support for the OMAP4430 based Panda board.
>
> Signed-off-by: David Anders
> +
> +static void __init omap4_panda_init_irq(void)
> +{
> + omap2_init_common_hw(NULL, NULL);
> +#ifdef CONFIG_OMAP_32K_TIMER
> + omap2_gp_clockevent_set_gpt
* Tony Lindgren [100517 19:47]:
> * Santosh Shilimkar [100512 01:22]:
> > This patch adds the i2c board support for OMAP4430 SDP platform. The
> > necessary drivers support patch is posted earlier.
> >
> > https://patchwork.kernel.org/patch/80659/
> >
> > --- a/arch/arm/plat-omap/i2c.c
> > +++ b
* kishore kadiyala [100515 11:16]:
> Adding a flag to determine the card detect type which can be
> either GPIO or NON-GPIO.MMC1 Controller of OMAP4 have NON-GPIO
> interrupt line from twl6030 for card detect.
>
> Signed-off-by: Kishore Kadiyala
> ---
> arch/arm/mach-omap2/board-2430sdp.c
* Santosh Shilimkar [100512 01:22]:
> This patch adds the i2c board support for OMAP4430 SDP platform. The
> necessary drivers support patch is posted earlier.
>
> https://patchwork.kernel.org/patch/80659/
>
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -35,6 +35,7 @@
>
Hi,
* kishore kadiyala [100515 11:15]:
> Adding MMC1 and MMC2 controllers support for OMAP4
>
> V4:
> - Rebased to "for_next" branch[LO].
> - The first 3 patches [1,2,3] in the series are Minimal set of changes
> with which MMC1/MMC2 works [No card detect for MMC1]on OMAP4 but with
> depende
Add stalker board to omap3_defconfig
Signed-off-by: Tony Lindgren
---
arch/arm/configs/omap3_defconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig
index 0eb1bc9..94dfcf0 100644
--- a/arch/arm/configs
From: Anand Gadiyar
- Update the omap3_defconfig to sync up with the generated .config
- Increase CONFIG_LOG_BUF_SHIFT to 16 to allow the entire
boot log to be captured
(useful when using boot time tracer, for example)
Signed-off-by: Anand Gadiyar
Signed-off-by: Tony Lindgren
---
arch/arm
From: Jason Lam
Add OMAP3 Stalker board LK-S defconfig.
Signed-off-by: Jason Lam
Signed-off-by: Tony Lindgren
---
arch/arm/configs/omap3_stalker_lks_defconfig | 1691 ++
1 files changed, 1691 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/omap3_stal
From: Jason
Add support for OMAP3Stalker boards
Signed-off-by: Jason Lam
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Kconfig |6
arch/arm/mach-omap2/Makefile |2
arch/arm/mach-omap2/board-omap3stalker.c | 672 ++
3 files
From: kishore kadiyala
Enables HSMMC support for OMAP4430 defconfig
Signed-off-by: Kishore Kadiyala
Signed-off-by: Tony Lindgren
---
arch/arm/configs/omap_4430sdp_defconfig | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/configs/omap_4430sd
From: kishore kadiyala
In OMAP4, MMC1 PBIAS and its associated IO is software-controlled
by CONTROL_PBIAS and CONTROL_MMC1 registers. This patch adds PBIAS
configuration for MMC1 Controller during power-ON and power-OFF
of regulator.
Signed-off-by: Kishore Kadiyala
Signed-off-by: Tony Lindgren
From: kishore kadiyala
Adding support for MMC1 & MMC2 controllers of OMAP4430 SDP
to board file.
Signed-off-by: Kishore Kadiyala
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-4430sdp.c | 59 +++
2 fi
From: kishore kadiyala
This patch adds dummy Interface clocks for MMC controllers
Signed-off-by: Kishore Kadiyala
Acked-by: Paul Walmsley
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/ar
From: Balaji T K
This patch enables RTC and regulator support on omap4430 sdp
platform. Also sync up the defconfig with latest kernel
Signed-off-by: Balaji T K
Signed-off-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
---
arch/arm/configs/omap_4430sdp_defconfig | 330 +++
From: Balaji T K
This patch adds i2c1 peripherals data to
omap4430 sdp board file.
Signed-off-by: Rajendra Nayak
Signed-off-by: Balaji T K
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c | 177 +++
1 files changed, 176 insertions(+), 1 de
Add support for i2c init for omap4.
This patch is based on and earlier patch by
Santosh Shilimkar .
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/i2c.c | 33 ++---
1 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch
From: Santosh Shilimkar
This patch adds the i2c board support for OMAP4430 SDP platform.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Balaji T K
Signed-off-by: Tony Lindgren
---
arch/arm/configs/omap_4430sdp_defconfig | 46 ++-
arch/arm/mach-omap2/board-4430s
Add separate omap_i2c_add_bus functions for mach-omap1
and mach-omap2. Make the mach-omap2 init set the interrupt
dynamically to support.
This is needed to add support for omap4 in a way that
works with multi-omap builds. This will eventually get
fixed with the omap hwmods.
Signed-off-by: Tony Li
Hi all,
Here are few more patches for review. These
patches have been posted earlier to linux-omap list,
but have not quite been ready to go until now.
The series adds omap4 I2C and MMC support, and adds
a new omap3 board Stalker.
Please note that that the omap4 MMC support depends
on two other
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next
Initial commit ID (Likely to change): 6ab41a6b4798817a99d79d9e23ca09702894b743
PatchWorks
http://patchwork.kernel.org/patch/99221/
Git (Likely to change, and takes a while to get mirrored)
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next
Initial commit ID (Likely to change): 97f84097ecdf7568d4d39e710cfda3e533441e1d
PatchWorks
http://patchwork.kernel.org/patch/96821/
Git (Likely to change, and takes a while to get mirrored)
In order to enable TLB miss interrupt, the TWL should be
disabled. This patch provides the functionality to get the
MMU fault interrupt for a TLB miss in the cases where the
users are working with the locked TLB entries and with TWL
disabled.
New interface is added to disable twl and enable TLB mis
The current iommu module doesn't provide the mechanism to get MMU fault on
TLB miss when working with locked TLB entries and TWL disabled.
To get the TLB miss interrupt, the TWL should be disabled.
This patch set provides the mechanism to disable TWL and enable TLB miss
interrupt.
Hari Kanigeri (
Update the irq mask so that is is clear that the MMU
interrupt is related to TWL fault.
Signed-off-by: Hari Kanigeri
---
arch/arm/mach-omap2/iommu2.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
inde
On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
wrote:
>
> The fundamental problem is one of idleness. What we want is the
> system to be idle in order to hit the lowest power states. We can't
> get there because the system is not truly idle.
>
> So, there are basically two solutions:
>
> 1) find
Mike Chan writes:
> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> wrote:
>>
and #2, the battery lifetime on the N770 and N800 (both of which I have)
is **appalling** **bad**.
>>>
>>> Appalling bad compared to what?
>>>
>>> Wha
If "disable" means cutting off the clock of the timer, then no.
The clock for the timer is needed so DSP can clear the timer IRQ status
register.
If it is to stop the timer from counting, then it is fine.
-Original Message-
From: Jansson, Cris
Sent: Monday, May 17, 2010 4:53 PM
To: Feli
The safe thing to do is disable the timer after the DSP has completed the dump.
During the dump processing, the DSP will clear the timer interrupt. I don't
know what would happen if the timer were disabled prior to that.
Best Regards,
Cris
-Original Message-
From: Felipe Contreras [m
Hi Cris,
On Mon, May 17, 2010 at 10:39 PM, Jansson, Cris wrote:
> Thanks for forwarding the thread.
>
> In wait_for_timer(), should return be used inside the loop? It will result
> in omap_dm_timer_disable(timer) not being called. I believe it should be
> called in all outcomes.
Yes, that's
On Mon, May 17, 2010 at 1:17 PM, Vitaly Wool wrote:
> On Mon, May 17, 2010 at 10:07 PM, Mike Chan wrote:
>> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool wrote:
>>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>>> wrote:
>>>
> and #2, the battery lifetime on the N770 and N800 (both of whic
On 05/12/2010 09:16 PM, Xianghua Xiao wrote:
> I'm unsure if the newest "top" (or /proc/PID/stat) reports the correct
> cpu usage when CFS/BFS is used, as you mentioned it seems failed to do
> that. I will try to stress the system and see who fails first under
> same workload, maybe that's the onl
On Monday 17 May 2010, Brian Swetland wrote:
> On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi wrote:
...
> > but can anyone write an app that holds a suspend_blocker ?? If so, then
> > your goal is already broken, right ? I mean, if anyone can keep a
> > suspend_blocker held forever, you'll never
On Mon, May 17, 2010 at 10:07 PM, Mike Chan wrote:
> On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool wrote:
>> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
>> wrote:
>>
and #2, the battery lifetime on the N770 and N800 (both of which I have)
is **appalling** **bad**.
>>>
>>> Appalling b
Add initial support for the OMAP4430 based Panda board.
Signed-off-by: David Anders
---
arch/arm/configs/omap4_panda_defconfig | 1094
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap
opp_get_opp_id should handle the error cases that might hit it. check
parameters before using it
Signed-off-by: Nishanth Menon
Cc: Eduardo Valentin
Cc: Jouni Hogander
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc: Rajendra Nayak
Cc: Sanjeev Premi
Cc: Tero Kristo
Cc: Tony Lindgren
Cc: Vishwanath
The following cleanups are done for upstreaming OPP layer on top of the
current OPP layer in PM branch
Nishanth Menon (2):
omap: opp: make opp_get_opp_id robust
omap: opp: documentation update
Documentation/arm/OMAP/omap_pm| 66 +
arch/arm/plat-omap/include/plat/opp.h |
move the documentation from header to c, cleanup missing function
documentation for the functions
Signed-off-by: Nishanth Menon
Cc: Eduardo Valentin
Cc: Jouni Hogander
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc: Rajendra Nayak
Cc: Sanjeev Premi
Cc: Tero Kristo
Cc: Tony Lindgren
Cc: Vishwanath
On Mon, May 17, 2010 at 12:27 PM, Vitaly Wool wrote:
> On Mon, May 17, 2010 at 6:12 PM, Kevin Hilman
> wrote:
>
>>> and #2, the battery lifetime on the N770 and N800 (both of which I have)
>>> is **appalling** **bad**.
>>
>> Appalling bad compared to what?
>>
>> What's probably more interesting i
On Mon, 2010-05-17 at 22:39 +0300, Felipe Balbi wrote:
> hi,
>
> On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
> > that's a whole other story. Hardware issues are things which in 99.999%
> > of the cases we can't change. We have to work around them. Software
> > bugs, on the other
Fernando,
Thanks for forwarding the thread.
In wait_for_timer(), should return be used inside the loop? It will result in
omap_dm_timer_disable(timer) not being called. I believe it should be called
in all outcomes.
> + for (c = 0; c < GPTIMER_IRQ_WAIT_MAX_CNT; c++)
> + if ((
hi,
On Mon, May 17, 2010 at 10:38:40PM +0300, Felipe Balbi wrote:
> that's a whole other story. Hardware issues are things which in 99.999%
> of the cases we can't change. We have to work around them. Software
> bugs, on the other hand, can be fixed much more easily. I'm sure you
> agree with that
Hi,
On Mon, May 17, 2010 at 03:24:27PM -0400, James Bottomley wrote:
> Surely, depending on your UART FIFO depth, of course, a serial console
> interrupts once every 16 characters or so ... how do you filter out that
> storm of interrupts refreshing the powertop screen from the actual
> applicatio
On Mon, 2010-05-17 at 21:12 +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> > Have you actually tried this? On my N1 with CM5.0.6 just running
> > powertop requires me to keep the USB system up (debugging cable) and
> > paths into the usb co
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject:
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject: [
+Cris
+Stanley
Loop in DSP guys in case they would have something to add.
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Sunday, May 16, 2010 10:46 AM
> To: linux-omap
> Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
> Subject:
James Bottomley writes:
> The technical reason for wanting suspend blockers (as has been stated
> more times than I can be bothered to go back and count) is that no-one
> can currently produce a working model for race free kernel to user work
> handoff
At least I've never heard this technial rea
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach. Toward this
>> goal we're not even req
On Mon, May 17, 2010 at 09:39:05PM +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
> > For a large majority of apps, running in the background while the
> > device is asleep (screen off) is not essential, they don't request the
> > "keep device awake" p
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach. Toward this
>> goal we're not even req
Hi,
On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
> We (Google) would like to allow completely open app distribution with
> minimal hurdles, and avoid the walled garden approach. Toward this
> goal we're not even requiring the use of a central app store for
> distribution.
I un
On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi wrote:
>
>> The technical reason for wanting suspend blockers (as has been stated
>> more times than I can be bothered to go back and count) is that no-one
>> can currently produce a working model for race free kernel to user work
>> handoff and, in t
Hi,
On Mon, May 17, 2010 at 06:58:20PM +0100, Matthew Garrett wrote:
> We know that this problem is mostly uninteresting if your userland is
> well written. The sad truth is that it's impossible to trust that your
> userland is well written, and broadly impossible to communicate to users
> that
Hi,
On Mon, May 17, 2010 at 01:59:39PM -0400, James Bottomley wrote:
> Have you actually tried this? On my N1 with CM5.0.6 just running
> powertop requires me to keep the USB system up (debugging cable) and
> paths into the usb console ... all of this produces significant wakeup
> distortion, mos
On Mon, 2010-05-17 at 20:47 +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > > For userspace, apps that have polling behavior or are ill-behaved must
> > > be found and fixed. Thanks to tools like powertop, this is a farily
> > > easy task.
> >
> >
On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote:
> IMO the real fix would be on that particular poll(), changing the
> timeout e.g. based on cpufreq notifications or even relying completely
> on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a
> crude example tryi
On Mon, 2010-05-17 at 13:04 -0400, James Bottomley wrote:
> I'm not sure this is real world, either. Developers can fire up
> powertop from the command line when their phone isn't idling for as long
> as it should. But a phone is a consumer device: the average smart phone
> user just wants to br
On Mon, May 17, 2010 at 01:04:45PM -0400, James Bottomley wrote:
> > For userspace, apps that have polling behavior or are ill-behaved must
> > be found and fixed. Thanks to tools like powertop, this is a farily
> > easy task.
>
> That's a bit glib ... powertop can detect power consumption stats
* Tomi Valkeinen [100517 03:21]:
> Hi,
>
> On Mon, 2010-05-17 at 11:44 +0200, ext Russell King - ARM Linux wrote:
> > On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
> > > On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
> > > wrote:
> > > >> because it also uses rese
On Mon, 2010-05-17 at 08:40 -0700, Kevin Hilman wrote:
> > Also, how does it handle the issue of ill-behaved apps?
>
> For userspace, apps that have polling behavior or are ill-behaved must
> be found and fixed. Thanks to tools like powertop, this is a farily
> easy task.
That's a bit glib ... p
Alan Stern writes:
> On Fri, 14 May 2010, Brian Swetland wrote:
>
>> In tickless mode, the time until next timer is a signed int, so the
>> longest the kernel will ever sleep is ~2 seconds at a go. In
>> practice, userspace entities often have polling behavior that can
>> trigger more often than
> -Original Message-
> From: Vimal Singh [mailto:vimal.neww...@gmail.com]
> Sent: 2010-05-17 19:57
> To: Ghorai, Sukumar
> Cc: linux-omap@vger.kernel.org; artem.bityuts...@nokia.com;
> t...@atomide.com; sako...@gmail.com; linux-...@lists.infradead.org
> Subject: Re: [PATCH v2 1/2] omap3 n
On Mon, May 17, 2010 at 9:52 AM, Ghorai, Sukumar wrote:
[...]
>> > @@ -108,11 +108,27 @@ static u32 gpmc_read_reg(int idx)
>> > return __raw_readl(gpmc_base + idx);
>> > }
>> >
>> > +static void gpmc_cs_write_byte(int cs, int idx, u8 val)
>> > +{
>> > + void __iomem *reg_addr;
>> > +
If we are not able to register then it is better to have watchdog in disabled
state than noticing a system reboot.
Signed-off-by: Ameya Palande
---
drivers/watchdog/twl4030_wdt.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/twl4030_wdt.c b/drivers/wa
MUSB RTL version 1.8 onward (OMAP3630, AM/DM37x, OMAP4) DMA requires
the buffers to be aligned on a four byte boundary. This affects USB
CDC/RNDIS class application where buffers are always unaligned.
Use system DMA for unaligned buffers as a workaround of this issue.
Current patch set supports d
MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels are
simultaneously enabled which results in DMA lockup.
Use system DMA for all RX channels as a workaround of this issue as this
will have minimal throughput overhead based on the fact that Rx transfers
are done in DMA mode-0 on
Added is_inventra_dma_enabled() funtion which would be required
for adding workaround for Inventra DMA issues. It can also be
used at other places instead of #ifdefs.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/musb_dma.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Current gadget Tx path always programs DMA in mode-1 if request length
is more than packet size. As system DMA can work only in mode-0 so
updating the DMA mode and transfer length for it.
Also fixed an issue in device Tx completion path where 'is_dma' is
getting set unconditionally. This would fai
OTG base physical address is required in calculating physical address
of endpoint FIFO which is needed by system dma.
Signed-off-by: Ajay Kumar Gupta
---
Patch created against linus'tree + all musb patches in Greg's queue
drivers/usb/musb/musb_core.c |6 --
drivers/usb/musb/musb_core.h
Use optimal values of transfer element based on buffer address in system
DMA programming. This would improve the performance.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/musbhsdma.c | 29 ++---
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/dri
Hi,
>
> Hi Peter,
>
> The RES_TYPE field is same for all messages.
>
> The resource which can go to low-power mode with clk_req sig de-asserting is
> configured as RES_TYPE2 = '2'. And the resource which can go to low-power
> mode with sys_off sig de-asserting is configured as RES_TYPE2 = '1'.
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode and there are on-going
discussions on location of CPPI4.1 DMA.
Signed-off-by: Ajay Kumar Gupta
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
- fixed multip
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It supports upto 500mA of power in host mode.
Signed-off-by: Ajay Kumar Gupta
---
Patch created against linus'tree + all musb patches in Greg's queue
and patches available in linux-omap/for-next branch.
arch/arm/mach-omap2/board
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta
---
Patch created against linus'tree + all musb patches in Greg's queue
Changes from v2:
- fixed multipline comment style
drivers/usb/musb/am3517.c
Hi,
On Mon, 2010-05-17 at 11:44 +0200, ext Russell King - ARM Linux wrote:
> On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
> > On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
> > wrote:
> > >> because it also uses reserve_bootmem() in
> > >> drivers/video/omap2/vram
On Mon, May 17, 2010 at 12:02:34PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
From: Felipe Balbi
move everything to a common location. No functional
changes.
Signed-off-by: Felipe Balbi
sorry, this patch shouldn't be here... it was a broken cherry-pick from
myself. Please ignore this on
From: Felipe Balbi
stop using the omap-specific implementations for gpio
debouncing now that gpiolib provides its own support.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-3430sdp.c|4 +---
arch/arm/mach-omap2/board-ldp.c|3 +--
arch/arm/mach-omap2/boar
From: Felipe Balbi
move everything to a common location. No functional
changes.
Signed-off-by: Felipe Balbi
---
arch/arm/plat-omap/gpio.c | 143
arch/arm/plat-omap/include/plat/gpio.h | 143
2 files changed, 143 i
From: Felipe Balbi
Hi all,
I'm resending this series since no-one has had any further
comments for quite some time.
Adding Andrew Morton to the loop also since David Brownell
didn't pick the patch neither comment to any version of it.
Felipe Balbi (5):
gpiolib: introduce set_debounce method
From: Felipe Balbi
nobody uses that anymore, so remove and expect drivers
to use the gpiolib implementation.
Signed-off-by: Felipe Balbi
---
arch/arm/plat-omap/gpio.c | 73 -
1 files changed, 0 insertions(+), 73 deletions(-)
diff --git a/arch/arm/
From: Felipe Balbi
OMAP support debouncing of gpio lines, implement
the method using gpiolib.
Signed-off-by: Felipe Balbi
---
arch/arm/plat-omap/gpio.c | 68 +
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.
From: Felipe Balbi
Few architectures, like OMAP, allow you to set
a debouncing time for the gpio before generating
the IRQ. Teach gpiolib about that.
Signed-off-by: Felipe Balbi
---
drivers/gpio/gpiolib.c | 43 +++
include/asm-generic/gpio.h |5
On Mon, May 17, 2010 at 12:38:55PM +0300, Grazvydas Ignotas wrote:
> On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
> wrote:
> >> because it also uses reserve_bootmem() in
> >> drivers/video/omap2/vram.c and later ioremap on RAM. Perhaps LMB can
> >> be used to fix that too?
> >
> > WTF
On Fri, May 14, 2010 at 1:16 PM, Russell King - ARM Linux
wrote:
>> because it also uses reserve_bootmem() in
>> drivers/video/omap2/vram.c and later ioremap on RAM. Perhaps LMB can
>> be used to fix that too?
>
> WTF is reserve_bootmem doing in a driver?
IIRC Tony refused any new fb related code
> si...@santesteban.eu wrote:
>> > si...@santesteban.eu wrote:
>> >> Hi I am using a v4l2 usb video capturer (em28xx based), and it is
>> working
>> >> fine for around 5 minutes. However, it stops capturing after this
>> time.
>> >>
>> >> There is no error message sent to kmsg ot the application, w
On Fri, 2010-05-14 at 21:09 +0200, ext Tony Lindgren wrote:
> * Tomi Valkeinen [100512 01:54]:
> > Hi,
> >
> > On Mon, 2010-05-10 at 22:20 +0200, ext Tony Lindgren wrote:
> > > * Stephen Rothwell [100506 22:05]:
> > > > Hi Tomi,
> > > >
> > > > Today's linux-next merge of the omap_dss2 tree got
97 matches
Mail list logo
