Hi,
Tomi Valkeinen wrote:
> Hi,
>
> On Mon, 2010-09-20 at 22:18 +0200, ext Jorge Bustamante wrote:
>> Hi,
>>
>> We (TI) have been working on a DSI video mode driver for OMAP4 and I
>
> I hope it's also for OMAP3?
>
>> am aware that other people are working with similar drivers. We had to
>> tw
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> Ramirez Luna, Omar
> Sent: Wednesday, October 27, 2010 3:23 AM
> To: Tony Lindgren; Hiroshi DOYU
> Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez
> Lu
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Omar
> Ramirez Luna
> Sent: Wednesday, October 27, 2010 3:23 AM
> To: Tony Lindgren; Hiroshi DOYU
> Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez
> Lun
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> Ramirez Luna, Omar
> Sent: Wednesday, October 27, 2010 3:23 AM
> To: Tony Lindgren; Hiroshi DOYU
> Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez
> Lu
Hi,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
> Manjunath Kondaiah
> Sent: Tuesday, October 26, 2010 6:55 PM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; Cousson, Benoit;
> K
> -Original Message-
> From: Menon, Nishanth
> Sent: Tuesday, October 26, 2010 8:19 PM
> To: G, Manjunath Kondaiah
> Cc: linux-omap@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Cousson, Benoit; Kevin
> Hilman; Shilimkar, Santosh
> Subject: Re: [PATCH v3 01/13] OMAP: DMA: R
* Rafael J. Wysocki (r...@sisk.pl) wrote:
> On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > * Alan Stern (st...@rowland.harvard.edu) wrote:
> > > On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> > >
> > > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > > On Tue, 2010-10-26 at 11
On Tuesday 26 October 2010 08:57:01 pm Rafael J. Wysocki wrote:
> On Tuesday, October 26, 2010, Thomas Renninger wrote:
> > >
> > > Ok, that's at least generic. Needs the review of Rafael, to determine
> > > whether this state value is all we want to know when we enter suspend.
> > He already gave
Changes in V3:
- PWR_EVENT_EXIT is -1 now instead of 0x
- Use cpu_{idle,frequency} instead of processor_{idle,frequency}
events
- Fixed a copy and paste bug (poll_idle should throw and event
state of zero, not 1)
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mar
Changes in V3:
- PWR_EVENT_EXIT is -1 now instead of 0x
- Use cpu_{idle,frequency} instead of processor_{idle,frequency}
events
Changes in V2:
- Hanlde PWR_EVENT_EXIT instead of 0 to recon non-power state
The transition was rather smooth, only part I had to fiddle
some time was
cpu_idle events (transition into sleep state and exiting) are
both fired in pm_idle().
Entering sleep state and exiting should always get fired inside
pm_idle() already.
This is a revert of commit c882e0feb937af4e5b991cbd1c
Signed-off-by: Thomas Renninger
CC: Robert Schoene
CC: Arjan van de Ve
power_frequency moved to drivers/cpufreq/cpufreq.c which has
to be compiled in, no need to export it.
intel_idle can a be module though...
Signed-off-by: Thomas Renninger
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet
On Wednesday, October 27, 2010, Rafael J. Wysocki wrote:
> On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > * Alan Stern (st...@rowland.harvard.edu) wrote:
> > > On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> > >
> > > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > > On Tue, 2
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> * Rafael J. Wysocki (r...@sisk.pl) wrote:
> > On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > >
> > > > > +
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> * Alan Stern (st...@rowland.harvard.edu) wrote:
> > On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> >
> > > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > > >
> > > > > +
HWMOD support for omap2430 and 2420.
Compiled tested only.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 55
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 54 +++
2 files changed, 109 insertions(+), 0 de
Remove unreachable return statement.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/mailbox.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index b8fd120..2dd0e07 100644
--- a/arch/arm/mach-omap2/
From: Felipe Contreras
So that we can enable the main clock.
Signed-off-by: Felipe Contreras
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/devices.c | 19 +--
arch/arm/mach-omap2/mailbox.c | 21 +
arch/arm/plat-omap/in
HWMOD support for omap2 and omap3 chips, plus cleanups.
1. omap: mailbox: initial hwmod support for omap3
Changes were made to:
- Rebase to latest code.
- Detect the hwmod by filling prcm union for omap2, without
this it was unable to build the hwmod at runtime.
- Replace magic number for define
From: Felipe Contreras
HWMOD support for omap3.
Signed-off-by: Felipe Contreras
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/devices.c | 100 ---
arch/arm/mach-omap2/mailbox.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |
Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.
Given that 2430 has an iva too include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/mailbox.c | 16 ++--
1 files chan
* Rafael J. Wysocki (r...@sisk.pl) wrote:
> On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > >
> > > > + trace_runtime_pm_usage(dev,
> > > > atomic_read(&dev->power.us
* Alan Stern (st...@rowland.harvard.edu) wrote:
> On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
>
> > * Peter Zijlstra (pet...@infradead.org) wrote:
> > > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > > >
> > > > + trace_runtime_pm_usage(dev,
> > > > atomic_read(&dev->power.us
On Tuesday, October 26, 2010, Arjan van de Ven wrote:
> On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:
> > On Tuesday, October 26, 2010, Pierre Tardy wrote:
> >> On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki wrote:
> >>> On Tuesday, October 26, 2010, Pierre Tardy wrote:
> On Tue, Oct 26
On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra wrote:
On Tue, 2010-10-26 at 11:56 -
On Tuesday, October 26, 2010, Pierre Tardy wrote:
> On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki wrote:
> > On Tuesday, October 26, 2010, Pierre Tardy wrote:
> >> On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra
> >> wrote:
> >> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> >>
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> Sent: Tuesday, October 26, 2010 2:38 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com;
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki wrote:
> On Tuesday, October 26, 2010, Pierre Tardy wrote:
>> On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra
>> wrote:
>> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
>> >>
>> >> + trace_runtime_pm_usage(dev,
>> >> atomic_re
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> Sent: Tuesday, October 26, 2010 2:27 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com;
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
fernando.l...@ti.com wrote:
> > fernando.l...@ti.com wrote:
> > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
> > > > wrote:
> > > > > The device address is assigned by tidspbridge no need for
> > > > that parameter anymore.
> > > > >
> > > > > Signed-off-by: Fernando Guzman Lugo
> >
fernando.l...@ti.com wrote:
> > fernando.l...@ti.com wrote:
> > > > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
> > > > wrote:
> > > > > So that avoid non-killable process.
> > > >
> > > > It would be useful to interrupt these tasks from user-space.
> > > > A separate ioctl to do that
On Tuesday, October 26, 2010, Pierre Tardy wrote:
> On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> >>
> >> + trace_runtime_pm_usage(dev,
> >> atomic_read(&dev->power.usage_count)+1);
> >> atomic_inc(&dev->power.us
* Ohad Ben-Cohen [101026 04:45]:
> On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren wrote:
> >> if you feel that (2) is justifiable/desirable, I would be more
> >> than happy to submit that version.
> >
> > Yes (2) please. I would assume there will be more use of this. And then
> > we (or probably
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
> * Peter Zijlstra (pet...@infradead.org) wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > >
> > > + trace_runtime_pm_usage(dev,
> > > atomic_read(&dev->power.usage_count)+1);
> > > atomic_inc(&dev->power.us
On Tuesday, October 26, 2010, Ingo Molnar wrote:
>
> * Thomas Renninger wrote:
>
> > On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
> > >
> > > * Thomas Renninger wrote:
> > >
> > > > Changes in V2:
> > > > - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> > > > -
On Tuesday, October 26, 2010, Thomas Renninger wrote:
> On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
> >
> > * Jean Pihet wrote:
> ..
> > > >> +#ifndef _TRACE_POWER_ENUM_
> > > >> +#define _TRACE_POWER_ENUM_
> > > >> +enum {
> > > >> + POWER_NONE = 0,
> > > >> + POWER_CSTATE = 1
On Tuesday, October 26, 2010, Thomas Renninger wrote:
> Changes in V2:
> - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> - Use u32 instead of u64 for cpuid, state which is by far enough
>
> New power trace events:
> power:processor_idle
> power:processor_frequency
> power:mac
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
> * Peter Zijlstra (pet...@infradead.org) wrote:
> > On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> > >
> > > + trace_runtime_pm_usage(dev,
> > > atomic_read(&dev->power.usage_count)+1);
> > > atomic_inc(&dev->power.usage_coun
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra wrote:
> On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
>>
>> + trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
>> atomic_inc(&dev->power.usage_count);
>
> That's terribly racy..
>
I know. I'm not proud of
* Peter Zijlstra (pet...@infradead.org) wrote:
> On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
> >
> > + trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> > atomic_inc(&dev->power.usage_count);
>
> That's terribly racy..
Looking at the original code,
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> Sent: Tuesday, October 26, 2010 12:08 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com;
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
>
> + trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
> atomic_inc(&dev->power.usage_count);
That's terribly racy..
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> Sent: Tuesday, October 26, 2010 12:03 PM
> To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
> Cc: gre...@suse.de; hiroshi.d...@nokia.com;
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
On Tue, Oct 26, 2010 at 12:13 PM, Felipe Contreras
wrote:
>> arch/arm/plat-omap/include/plat/iva2_dsp.h | 56
>> +
>
> Why not use the already existing dsp.h?
Good point, I guess when the patch was made dsp.h didn't exist, but
since the user of those defines is pm34x
On Tue, Oct 26, 2010 at 7:15 PM, Omar Ramirez Luna wrote:
> This is the patch series shared by Paul, for a short term fix to
> a compile break due SCM layer layer violations from tidspbridge
> driver, where the latter is used to write directly into registers
> and use SCM layer macros, among other
fernando.l...@ti.com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
> > wrote:
> > > The device address is assigned by tidspbridge no need for
> > that parameter anymore.
> > >
> > > Signed-off-by: Fernando Guzman Lugo
> >
> > This would break the API with user-space, right?
fernando.l...@ti.com wrote:
> > On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
> > wrote:
> > > So that avoid non-killable process.
> >
> > It would be useful to interrupt these tasks from user-space.
> > A separate ioctl to do that would be needed.
>
> I don't see use case where that c
> I would like to see a slightly more advanced tracepoint do the runtime pm
> framework;
> specifically I'd like to see the "comm" of the process that's taking a
> refcount on a device
> (that way, powertop can track which process keeps a device busy)
>
>
Yes, the "comm" for this tracepoint should
Hi,
I am using 2.6.32 with omap3evm board.
The audio skips a couple of frames at the first interrupt on palyback
(TWL4030) when I use small period size (10msec). But the same
parameters work fine on capture. With large period/frame size, it
works fine also.
The skip causes extra delays (30ms
From: Paul Walmsley
DSPBridge currently tries to __raw_writel() to the System Control
Module to control the DSP boot process. This is a layering violation;
this is SoC-specific code, and belongs in a file in
arch/arm/mach-omap2/*. None of those CM and PRM register accesses
through struct platfo
This is the patch series shared by Paul, for a short term fix to
a compile break due SCM layer layer violations from tidspbridge
driver, where the latter is used to write directly into registers
and use SCM layer macros, among other layer bypassing.
patch: "staging: tidspbridge: use new SCM DSP bo
From: Paul Walmsley
Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These
registers wound up in the System Control Module. Other kernel code
that wishes to control the DSP's boot process should now use these
functions to do so; subsequent patches implement this in the two
in-tree us
From: Paul Walmsley
Update the DSP reset code in pm34xx.c to use one of the new SCM DSP
boot control functions, omap2430_ctrl_set_dsp_bootmode().
This reset code should be moved out to a separate function to be
called by the hwmod reset process at some point. Also, 2430
should be initializing t
From: Paul Walmsley
Use the new functions from SCM layer instead of handling registers
directly with __raw_writel, as explained in:
http://marc.info/?l=linux-omap&m=128779652429922&w=2
Signed-off-by: Paul Walmsley
Signed-off-by: Omar Ramirez Luna
---
drivers/staging/tidspbridge/core/tiomap34
On 10/26/2010 8:32 AM, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnar wrote:
How will future PCI (or other device) power saving tracepoints be called?
Might be more consistent to use:
power:cpu_idle
power:machine_idle
power:device_idle
Agree with this.
FYI, I have a
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Tuesday, October 26, 2010 6:46 AM
> To: Guzman Lugo, Fernando
> Cc: gre...@suse.de; felipe.contre...@nokia.com;
> hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org;
> andy.shevche...@gmail.com
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
> Sent: Monday, October 25, 2010 7:59 PM
> To: Guzman Lugo, Fernando
> Cc: gre...@suse.de; felipe.contre...@nokia.com;
> hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org;
> andy.shevche...@gmail.com;
> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> Sent: Tuesday, October 26, 2010 9:44 AM
> To: gre...@suse.de; Guzman Lugo, Fernando
> Cc: hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org;
> andy.shevche...@gmail.com; linux-omap@vger.kernel.org;
On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnar wrote:
> How will future PCI (or other device) power saving tracepoints be called?
>
> Might be more consistent to use:
>
> power:cpu_idle
> power:machine_idle
> power:device_idle
Agree with this.
FYI, I have a runtime_pm tracepoint currently cooki
On Tue, Oct 26, 2010 at 9:43 AM, Felipe Contreras
wrote:
> gre...@suse.de wrote:
>> On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote:
>> > This set of patches fix some issues found in lastest tree.
>> >
>> > Fernando Guzman Lugo (8):
>> > staging: tidspbridge - remove req_add
G, Manjunath Kondaiah had written, on 10/26/2010 08:25 AM, the following:
[...]
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@
#undef DEBUG
+enum {
+ GCR1 =
gre...@suse.de wrote:
> On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote:
> > This set of patches fix some issues found in lastest tree.
> >
> > Fernando Guzman Lugo (8):
> > staging: tidspbridge - remove req_addr from proc_map
> > staging: tidspbridge - add kconfig paramet
On Tue, Oct 26, 2010 at 12:43 AM, Paul Walmsley wrote:
>> arch/arm/mach-omap2/dsp.c | 4
>> arch/arm/plat-omap/include/plat/dsp.h | 4
>> drivers/staging/tidspbridge/core/tiomap3430.c | 13 ++---
>
> Could you please split the tiomap3430.c chan
On Tuesday 26 October 2010 15:17:43 Thomas Renninger wrote:
> On Tuesday 26 October 2010 13:54:22 Ingo Molnar wrote:
> >
> > * Thomas Renninger wrote:
...
> If cpuidle is not registered, the events you get are arch specific.
> I mean they are arch specific anyway, but with cpuidle you can
> build
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can be
exploited for scatter gather scenarios, currently available in OMAP3630
and OMAP4430.
The feature works as described below.
1. A sDMA channel is programmed to be in 'l
Enable runtime pm and use pm_runtime_get and pm_runtime_put
for OMAP DMA driver.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/plat-omap/dma.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/ar
Register OMAP1 DMA driver as platform device and add support
for registering through platform device layer using resource
structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap1/dma.c | 182 ++
Prepare omap2+ dma driver to use hwmod infrastructure
so that DMA driver can register as platform device.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/dma.c | 86
arch/arm
Convert DMA library into DMA platform driver and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource
structures for getting platform data.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hi
Add OMAP3 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 93
1 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap
From: Benoit Cousson
Add OMAP4 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah
Signed-off-by: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99
1 files changed, 99 insertions(+), 0 deletions(-
Add OMAP2430 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-o
Add OMAP2420 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-o
The low level read/write macros are replaced with static inline functions
and register offsets are handled through static register offset tables
mapped through enumeration constants.
The objective of this patch is to prepare for omap dma driver cleanup
and dma hwmod implementation. The code optimi
Implement errata handling to use flags instead of cpu_is_*
and cpu_class_* in the code.
The errata flags are initialized at init time and during runtime
we are using the errata variable (via the IS_DMA_ERRATA macro)
to execute the required errata workaround.
Reused errata handling patch from Pete
This patch introduces OMAP DMA device attributes for using the same in
DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)
Signed-off-by: G, Manjunath Kondaiah
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Santosh Shilimkar
---
arch/arm/plat-omap/include/plat/dma.h | 20 +
This patch series converts DMA library into platform device and hwmod
adaptation is done for omap2+ processors.
It also replaces cpu_*is* checks by moving omap1 and omap2+ processor
code into repsective mach-omapx directories. The common code in plat-omap
will use device attributes for different
On Tuesday 26 October 2010 13:54:22 Ingo Molnar wrote:
>
> * Thomas Renninger wrote:
>
..
> As you state above: POWER_NONE does not make sense at all.
> > The whole thing (type= attribute that vanishes now) is
> > passed to userspace, but never gets used there because the
> > same info is in the
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Identifying if a module has lost context requires atleast on
* Julia Lawall :
> Delete successive assignments to the same location. Initialize the out_y
> field as well as the out_x field, rather than initializing the out_x field
> twice.
Hi there!
An identical patch is already in the -mm tree:
> The patch titled
> drivers/video/omap/blizzard.c: sus
Certain errata's in OMAP2+ processors will require disabling
master standby mode before completing on going operation. Without
this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going o
On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren wrote:
>> if you feel that (2) is justifiable/desirable, I would be more
>> than happy to submit that version.
>
> Yes (2) please. I would assume there will be more use of this. And then
> we (or probably me again!) don't have to deal with cleaning up
* Thomas Renninger wrote:
> On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
> >
> > * Jean Pihet wrote:
> ..
> > > >> +#ifndef _TRACE_POWER_ENUM_
> > > >> +#define _TRACE_POWER_ENUM_
> > > >> +enum {
> > > >> + POWER_NONE = 0,
> > > >> + POWER_CSTATE = 1,
> > > >> + POWER_PS
On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
>
> * Jean Pihet wrote:
..
> > >> +#ifndef _TRACE_POWER_ENUM_
> > >> +#define _TRACE_POWER_ENUM_
> > >> +enum {
> > >> + POWER_NONE = 0,
> > >> + POWER_CSTATE = 1,
> > >> + POWER_PSTATE = 2,
> > >> +};
> > >> +#endif
> > >
> > > S
On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo wrote:
> The device address is assigned by tidspbridge no need for that parameter
> anymore.
>
> Signed-off-by: Fernando Guzman Lugo
This would break the API with user-space, right?
I think this change should be delayed, preferably after we
* Jean Pihet wrote:
> Ingo,
>
> On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar wrote:
> >
> > * Thomas Renninger wrote:
> >
> >> Changes in V2:
> >> - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> >> - Use u32 instead of u64 for cpuid, state which is by far enough
>
> ...
* Thomas Renninger wrote:
> On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
> >
> > * Thomas Renninger wrote:
> >
> > > Changes in V2:
> > > - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> > > - Use u32 instead of u64 for cpuid, state which is by far enough
> > >
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap
Hi Kevin,
Sorry for that late reply, I missed that email a little bit.
On 10/14/2010 8:56 PM, Kevin Hilman wrote:
On Sat, 2010-09-25 at 18:21 +0530, Thara Gopinath wrote:
diff --git a/arch/arm/plat-omap/include/plat/control.h
b/arch/arm/plat-omap/include/plat/control.h
index 042eb6e..1e8f6ec 1
On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
>
> * Thomas Renninger wrote:
>
> > Changes in V2:
> > - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> > - Use u32 instead of u64 for cpuid, state which is by far enough
> >
> > New power trace events:
> > power:proces
On Tue, Oct 26, 2010 at 6:36 PM, Artem Bityutskiy
wrote:
> On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote:
>> This patch adds code that I think was lost when it was applied the commit
>> 5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support
>>
>> Test case:
>> 1.
* Arjan van de Ven wrote:
> On 10/26/2010 12:10 AM, Ingo Molnar wrote:
> >+
> >>+ TP_STRUCT__entry(
> >>+ __field(u32,state )
> >>+ __field(u32,cpu_id )
> >Trace entries can carry a cpu_id of the current processor a
From: Julia Lawall
Delete successive assignments to the same location. Initialize the out_y
field as well as the out_x field, rather than initializing the out_x field
twice.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
ex
On 10/26/2010 12:10 AM, Ingo Molnar wrote:
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ __field(u32,cpu_id )
Trace entries can carry a cpu_id of the current processor already. Can this
cpu_id
ever be
On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote:
> This patch adds code that I think was lost when it was applied the commit
> 5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support
>
> Test case:
> 1. Stress a jffs2 filesystem using
> bonnie++ -u 0:0 -s 32 -m
Hi,
Oo-ops. Right, the pull request is for 2.6.37. Missed the key, there...
Tomi
On Tue, 2010-10-26 at 10:14 +0200, ext Shilimkar, Santosh wrote:
> Tomi,
> Did you mean '[GIT PULL] omap DSS changes for 2.6.37' and
> not '[GIT PULL] omap DSS changes for 2.6.27'?
>
> > -Original Message---
Tomi,
Did you mean '[GIT PULL] omap DSS changes for 2.6.37' and
not '[GIT PULL] omap DSS changes for 2.6.27'?
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen
> Sent: Tuesday, October 26, 2010 1:24 PM
>
Ingo,
On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar wrote:
>
> * Thomas Renninger wrote:
>
>> Changes in V2:
>> - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
>> - Use u32 instead of u64 for cpuid, state which is by far enough
...
>>
>> +#define PWR_EVENT_EXIT 0x
>
On Tue, Oct 26, 2010 at 1:33 AM, Thomas Renninger wrote:
> Changes in V2:
> - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
> - Use u32 instead of u64 for cpuid, state which is by far enough
>
> New power trace events:
> power:processor_idle
> power:processor_frequency
> power:ma
Hi Linus,
Please pull OMAP display subsystem changes:
The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00:
Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-linus
Archit Taneja (2)
1 - 100 of 101 matches
Mail list logo
