On Tue, Apr 24, 2012 at 5:15 AM, Kevin Hilman wrote:
> "Govindraj.R" writes:
>
>> From: "Govindraj.R"
>>
>> The following commit:
>> (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
>> added default pads for all uarts. But not all boards tend to
>> use all uarts and most of unused uar
On Fri, Apr 20, 2012 at 10:43 PM, Tony Lindgren wrote:
> * Matt Porter [120420 09:04]:
>> On Fri, Mar 30, 2012 at 02:39:32PM -0700, Tony Lindgren wrote:
>> > * Kumar Gala [120330 14:14]:
>> > >
>> > > On Mar 30, 2012, at 1:48 PM, Tony Lindgren wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > * Kumar
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
All the details are at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
.
The setup is:
- Beagleboard (OM
Add missing idle_st bit for 32k-sync timer into the prcm-common
header file, required for hwmod data.
Signed-off-by: Vaibhav Hiremath
Cc: Felipe Balbi
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Paul Walmsley
---
arch/arm/mach-omap2/prcm-common.h |4
1 files changed, 4 insertions(+), 0
Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 & 3 hwmod table.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Felipe Balbi
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 +++
arch/arm/mach-omap2/omap_hw
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the existing 32k-sync timer implementation
without any major code changes
On Tue, Apr 24, 2012 at 3:15 PM, Vaibhav Hiremath wrote:
> Current OMAP code supports couple of clocksource options based
> on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
> and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
>
> This patch series cleans up the ex
On Tue, Apr 24, 2012 at 15:36:43, Shilimkar, Santosh wrote:
> On Tue, Apr 24, 2012 at 3:15 PM, Vaibhav Hiremath wrote:
> > Current OMAP code supports couple of clocksource options based
> > on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
> > and a gptimer which can run on 32KHz o
On Wednesday 18 April 2012 03:41 PM, Russell King wrote:
+/**
+ * vchan_cookie_complete - report completion of a descriptor
+ * vd: virtual descriptor to update
+ *
+ * vc.lock must be held by caller
+ */
+static inline void vchan_cookie_complete(struct virt_dma_desc *vd)
+{
+ struct virt_d
+ Tero
On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
> Hi Grazvydas, Kevin,
>
> I did some gather some performance measurements and statistics using
> custom tracepoints in __omap3_enter_idle.
> All the details are at
> http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measur
Here's another patch - for the OMAP NAND driver.
One thing this doesn't do is configure up the source/destination bursts,
which the old code did:
omap_set_dma_dest_burst_mode(info->dma_ch,
OMAP_DMA_DATA_BURST_16);
On Tue, Apr 24, 2012 at 04:05:29PM +0530, Laxman Dewangan wrote:
> On Wednesday 18 April 2012 03:41 PM, Russell King wrote:
>> +/**
>> + * vchan_cookie_complete - report completion of a descriptor
>> + * vd: virtual descriptor to update
>> + *
>> + * vc.lock must be held by caller
>> + */
>> +stati
On Tuesday 24 April 2012 04:20 PM, Russell King - ARM Linux wrote:
For cyclic case, we will not like to call the dma_cookie_complete() but
want to put the desc in callback list.
So can we have one more arg on this function which byspass the call of
dma_cookie_complete()
See the discussion on
Hi Tero,
On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote:
> Okay thats good (although I wonder why the attachment got corrupted.)
> Did you check if the device suspends / resumes properly also? Can you
> check what do you have in the /proc/interrupts for the hwmod_io
> interrupt just after bo
On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
> + Tero
>
> On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
> > Hi Grazvydas, Kevin,
> >
> > I did some gather some performance measurements and statistics using
> > custom tracepoints in __omap3_enter_idle.
> > All the details are
On Tue, 2012-04-24 at 14:00 +0200, Mohammed, Afzal wrote:
> Hi Tero,
>
> On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote:
> > Okay thats good (although I wonder why the attachment got corrupted.)
> > Did you check if the device suspends / resumes properly also? Can you
> > check what do you h
Hi Tero,
On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo wrote:
> On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
>> + Tero
>>
>> On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
>> > Hi Grazvydas, Kevin,
>> >
>> > I did some gather some performance measurements and statistics using
On Tue, 2012-04-24 at 14:50 +0200, Jean Pihet wrote:
> Hi Tero,
>
> On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo wrote:
> > On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
> >> + Tero
> >>
> >> On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
> >> > Hi Grazvydas, Kevin,
> >> >
> >
From: "Govindraj.R"
With set_wakeup port ops availability from serial_core layer
which will be called when port is opened with state as true
indicating the wakeups can be enabled for this port and state
as false while port shutdown where we can disable the wakeups.
But wakeup can be also enabled
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
V3 :
* replace OMAP4_NUM_STATES and OMAP3_NUM_STATES by ARRAY_SIZE
* Fixed changelog
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle4
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimka
We do not longer need this table as we defined the values
in the driver states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/ar
Add the static declaration for the omap4_idle_data variable because its scope
is in the file only.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
We initialize the omap4_idle_data variable at compile time allowing us
to remove in the next patch the initialization done at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 21 ++---
1 fi
We are storing the 'omap4_idle_data' in the private data field
of the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
--
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 24
1 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/arch/a
As suggested, this table is an optimized version for rx51 and we
remove it in order to consolidate the cpuidle code between omap3
and omap4, we remove this specific data definition which is used
to override the default omap3 latencies but at the cost of extra
code and complexity.
In order to not l
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 86 +---
1 files changed, 60 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.
The errata check is done in the next_valid_state function, no need to check
that in the omap3_idle_init function.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
di
We do not longer need the ''cpuidle_params_table' array as
we defined the states in the driver and we checked they are
all valid.
We also remove the structure definition as it is no longer used.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 28
Initialize the omap3_idle_data array at compile time, that will allow
to remove the initialization at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 37 -
1 files changed, 32 insertions(+), 5 deletio
We are storing the 'omap3_idle_data' in the private data field
of the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly.
As the table is initialized statically, let's remove the initialization at
startup too.
S
Simplify the indentation by removing the useless 'else' statement.
Remove the first loop for the 'idx' search as we have it already
with the 'index' passed as parameter.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 53 +-
Reduce the scope of the omap3_idle_data to the file as it is only used
in cpuidle34xx.c.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arc
Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0
From: "Govindraj.R"
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs.
Add api to control the module level wakeup mechanism from info provided from
hwmod data.
omap_hwmod_enable/disable_wakeup is used from serial.c which should
configure PM_W
From: "Govindraj.R"
The uart module level wakeups enabling and disabling
are now handled from uart driver itself remove the uart module
level configurations from pm code.
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Tero Kristo
Cc: Rajendra Nayak
Cc: Santosh
From: "Govindraj.R"
On omap2/3 module level wakeup is handled using PM_WKEN registers.
Expand the hwmod framework to handle the module level wakeup enable
registers.
Tested on Beagle-xm by enabling and disabling uart wakeups from sysfs
Series depends on following patches for testing.
http://mar
Here's a first pass attempt to reduce the overhead of the pre/post
transitions by allowing them to be called per powerdomain and making
them conditional on powerdomain transtions.
This can be used for testing/measurements to see the reduction the
latencies involved in entering/exiting idle with an
Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Also PRCM register accesses are known to be expensive, so the
additional latency added to the idle path is signficiant.
In order allow the pre/post transitions
We only need to call the pre/post transtion methods when we know the
power state is changing. First, split up the pre/post transition
calls to be per-powerdomain, and then make them conditional on whether
the power domain is actually changing states.
Signed-off-by: Kevin Hilman
---
arch/arm/mac
commit e7410cf7 (02fdb03e69699f26e1370d0e51593dbc8a4e5265) moved
mangement of cam_pwrdm to CPUidle but left some remnants behind,
namely the call to clkcm_allo_idle() for the clockdomains in the MPU
pwrdm. Remove these since they are not necessary and cause unwanted
latency in the idle path.
Cc:
Jean Pihet writes:
> Hi Grazvydas, Kevin,
>
> I did some gather some performance measurements and statistics using
> custom tracepoints in __omap3_enter_idle.
> All the details are at
> http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
>
On Tue, Apr 24, 2012 at 7:53 PM, Kevin Hilman wrote:
> Iteration over all power domains in the idle path is unnecessary since
> only power domains that are transitioning need to be accounted for.
> Also PRCM register accesses are known to be expensive, so the
> additional latency added to the idle
Hi Tero,
On 04/20/2012 04:19 AM, Tero Kristo wrote:
> From: Rajendra Nayak
>
> On OMAP4 most modules/hwmods support module level context status. On
> OMAP3 and earlier, we relyed on the power domain level context status.
> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
> hw
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
[...]
> +/**
> + * omap4_dpll_print_reg - dump out a single DPLL register value
> + * @dpll_reg: register to dump
> + * @name: name of the register
> + * @tuple: content of the register
> + *
> + * Helper dump function to print out a DPLL regis
On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
> Hi Tero,
>
> On 04/20/2012 04:19 AM, Tero Kristo wrote:
> > From: Rajendra Nayak
> >
> > On OMAP4 most modules/hwmods support module level context status. On
> > OMAP3 and earlier, we relyed on the power domain level context status.
> > Iden
* Sebastian Reichel [120421 04:26]:
> Hi,
>
> Missing omap_ssi support is currently the most important missing
> feature, to make the mainline kernel on the Nokia N900 useful, see
> also [0].
>
> Can you prepare SSI inclusion into the mainline kernel, now that HSI
> has been pulled into 3.4? Do
Hi Janusz,
On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti
wrote:
> On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik
> wrote:
>> On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote:
>>> With register offsets now defined for respective OMAP versions we can get
>>> rid
* DebBarma, Tarun Kanti [120424 08:40]:
> Hi Janusz,
>
> On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti
> wrote:
> > On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik
> > wrote:
> >> On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote:
> >>> With register offsets now
* Govindraj.R [120424 07:12]:
> From: "Govindraj.R"
>
> On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
> PM_WKEN1_CORE/PM_WKEN_PER regs.
>
> Add api to control the module level wakeup mechanism from info provided from
> hwmod data.
>
> omap_hwmod_enable/disable_wakeup
Hi,
* Vaibhav Hiremath [120424 02:54]:
> Current OMAP code supports couple of clocksource options based
> on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
> and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
> So there can be 3 options -
>
> 1. 32KHz sync-timer
On Tue, Apr 24, 2012 at 08:23:16AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel [120421 04:26]:
> > Hi,
> >
> > Missing omap_ssi support is currently the most important missing
> > feature, to make the mainline kernel on the Nokia N900 useful, see
> > also [0].
> >
> > Can you prepare SSI i
* Tero Kristo [120420 02:39]:
> +
> +static int omap4_sar_not_accessible(void)
> +{
> + u32 usbhost_state, usbtll_state;
> +
> + /*
> + * Make sure that USB host and TLL modules are not
> + * enabled before attempting to save the context
> + * registers, otherwise this will
* Tero Kristo [120420 02:38]:
> -void omap4_sar_overwrite(void)
> +void omap_sar_overwrite(void)
> {
> u32 val = 0;
> - u32 offset = 0;
> + u32 usb_offset = 0x2ec;
> + u32 usb_offset2 = 0x91c;
>
> - if (cpu_is_omap446x())
> - offset = 0x04;
> + if (cpu_is_o
* Tero Kristo [120420 02:39]:
> @@ -384,6 +386,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
> set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
>
> if (omap4_mpuss_read_prev_context_state()) {
> + /*
> + * Dummy dispatcher call
* Sebastian Reichel [120424 09:31]:
> On Tue, Apr 24, 2012 at 08:23:16AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel [120421 04:26]:
> > > Hi,
> > >
> > > Missing omap_ssi support is currently the most important missing
> > > feature, to make the mainline kernel on the Nokia N900 useful,
* Russell King - ARM Linux [120424 03:42]:
> Here's another patch - for the OMAP NAND driver.
>
> One thing this doesn't do is configure up the source/destination bursts,
> which the old code did:
>
> omap_set_dma_dest_burst_mode(info->dma_ch,
>
Hello All,
I'm pretty new to the OMAP DSS and would like to understand how it works under
Linux/Android. I have read the TRM and understood that the DSS uses DMA to move
pixels from the main memory to several hardware pipelines, with each burst of a
few lines. But I am wondering -
1 - when w
Hi Tero,
Tero Kristo writes:
> On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote:
>> Hi Paul,
>>
>> On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote:
>> > Perhaps you might be willing to add some debugging to omap_mux_late_init()
>> > to find out what part of that function is causi
On 4/24/2012 4:46 PM, Tero Kristo wrote:
On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:19 AM, Tero Kristo wrote:
From: Rajendra Nayak
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relyed on the power domain level co
* Tomi Valkeinen [120423 00:43]:
> Add statics to board-omap4-panda.c's internal functions and data
> structures to remove warnings.
Care to update with the warnings produced?
Tony
> Signed-off-by: Tomi Valkeinen
> ---
> arch/arm/mach-omap2/board-omap4panda.c |8
> 1 files chang
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> This patch adds device off support to OMAP4 device type.
>
> OFF mode is disabled by default, however, there are two ways to enable
> OFF mode:
> a) In the board file, call omap4_pm_off_mode_enable(1)
> b) Enable OFF mode using the debugfs ent
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> From: Santosh Shilimkar
>
> The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
> IVA and Tesla execution.
>
> At wakeup from MPU OFF on HS device only (not GP device), when
> restoring the Secure RAM, the ROM Code reconf
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> From: Rajendra Nayak
>
> On HS devices on the way out of MPU OSWR and OFF ROM code wrongly
> overwrites the CM L3INSTR registers. So to avoid this, save them and
> restore on the way out from MPU OSWR/OFF.
This appears to be an errata. So, i
On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote:
>> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8)
>> > [ 154.907104] 9fa0: beaf1f04
>> > 4006be00 000f 000c
>> > [ 154.915710] 9fc0: 4006c000 8034 ff40 000
On Tue, Apr 24, 2012 at 11:44:15PM +0530, Shubhrajyoti wrote:
> On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote:
> >> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8)
> >> > [ 154.907104] 9fa0: beaf1f04
> >> > 4006be00 000f 000c
> >
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> From: Santosh Shilimkar
>
> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
> The issue occurs when EMIF_SDRAM_CONFIG is restored first before
> EMIF_SDRA
On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote:
> Hi
Hi Paul, Kevin.
> On Wed, 11 Apr 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer"
> >
> > Currently, the OMAP3 cpuidle driver calls omap3_enter_idle()
> > which calls omap_sram_idle(). omap_sram_idle() eventually
> > ca
On Mon, Apr 23, 2012 at 7:06 PM, Russell King
wrote:
> Remove the private DMA API implementation from omap_hsmmc, making it
> use entirely the DMA engine API.
>
> Signed-off-by: Russell King
Since the driver becomes useless without DMA_ENGINE, we probably want
a 'depends on'?
--
Gražvydas
--
On Wed, Apr 25, 2012 at 12:51:09AM +0300, Grazvydas Ignotas wrote:
> On Mon, Apr 23, 2012 at 7:06 PM, Russell King
> wrote:
> > Remove the private DMA API implementation from omap_hsmmc, making it
> > use entirely the DMA engine API.
> >
> > Signed-off-by: Russell King
>
> Since the driver becom
Dnia wtorek, 24 kwietnia 2012 21:06:59 DebBarma, Tarun Kanti pisze:
> Hi Janusz,
>
> Here is the patch, with attachment as well. I have just tested on
> OMAP4 platform.
> Testing on other OMAP2+ platforms is pending. In the meantime can you please
> validate on OMAP1 platform and confirm? Thanks.
On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux [120424 03:42]:
>> Here's another patch - for the OMAP NAND driver.
>>
>> One thing this doesn't do is configure up the source/destination bursts,
>> which the old code did:
>>
>> omap_set_d
On Tue, Apr 24, 2012 at 5:23 PM, Kevin Hilman wrote:
> Here's a first pass attempt to reduce the overhead of the pre/post
> transitions by allowing them to be called per powerdomain and making
> them conditional on powerdomain transtions.
>
> This can be used for testing/measurements to see the re
On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote:
> On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote:
> > Hi
>
> Hi Paul, Kevin.
>
> > On Wed, 11 Apr 2012, Mark A. Greer wrote:
> >
> > > From: "Mark A. Greer"
> > >
> > > Currently, the OMAP3 cpuidle driver calls omap3
On Wed, Apr 25, 2012 at 01:47:21AM +0300, Grazvydas Ignotas wrote:
> On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren wrote:
> > * Russell King - ARM Linux [120424 03:42]:
> >> Here's another patch - for the OMAP NAND driver.
> >>
> >> One thing this doesn't do is configure up the source/destinatio
On Wed, Apr 25, 2012 at 2:29 AM, Russell King - ARM Linux
wrote:
> On Wed, Apr 25, 2012 at 01:47:21AM +0300, Grazvydas Ignotas wrote:
>> On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren wrote:
>> > * Russell King - ARM Linux [120424 03:42]:
>> >> Here's another patch - for the OMAP NAND driver.
>>
Hello Vaibhav, Afzal, Vaibhav,
A few questions while reviewing this patch:
On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
> AM33XX PRCM module consist of, various clockdomains, in all
> total we have 18 clockdomains available, with following
> controlling options,
>- NO Sleep: sleep transition
Hello Vaibhav, Afzal, Vaibhav,
On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
> AM33XX clock implementation is different than any existing OMAP
> family of devices. Although DPLL module is similar to OMAP4
> device, but the usage is very much different than OMAP4.
> AM33XX has different peripheral s
Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79
Signed-off-by: Oleg Matcovschi
---
v1:
initial revision
v2:
resending patch including maintainers
sound/soc/omap/omap-pcm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/oma
Hi Tomi,
Thanks for your comments!
On 04/23/2012 08:17 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
Instead of having an ASoC codec embedded into DSS code, use the generic DSS
device driverinterface for audio support. This allows to any potential user,
inclu
- some debug messages missed spaces. The did this because they
broke a string onto 2 lines - badly. That practice is currently
out of favour, so join the two strings together, insert the space,
and put newlines elsewhere.
- sometimes no error was returned when it should have been
- sometim
There is no gain in having a loop - there is no risk of missing the
interrupt with wait_event_timeout.
Signed-off-by: NeilBrown
---
drivers/w1/masters/omap_hdq.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/mast
Sorry for the scatter-gun list of email address, but while each of
these patches only touches one subsystem, they really needed each
other to provide proper context.
The goal is to ensure that an interrupt that arrives on a TWL4030
connected to an OMAP3, during the 'late-suspend' stage will
cause
All interrupts can wake-from-sleep (I think) so it should be
permissible to call enable_irq_wake(). Setting this flag allows that.
It is needed because without this, an interrupt which is delivered
during late suspend will get ignored but will not cause suspend to
abort.
If enable_irq_wake() is c
Level triggered interrupts do not cause IRQS_PENDING to be set, so
check_wakeup_irqs ignores them.
They don't need to set IRQS_PENDING as the level stays high which
shows that they must be pending. However if such an interrupt fired
during late suspend, it will have been masked so the fact that it
Most of the interrupts that come through this line should trigger
wakeups:
power button
RTC alarm
power available
usb plug/unplug
so mark the interrupt as a wakeup interrupt.
This is particularly important for when the interrupt arrives during
the late suspend phase. Without this setting
On 04/23/2012 08:12 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
In order to avoid duplication of definitions. Use the definitions provided
by asoundef.h. Furthermore, as CEA-861 and IEC-60958 are used by both
DisplayPort and HDMI, this helps to make the code
On 04/23/2012 07:42 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
Signed-off-by: Ricardo Neri
There's a typo in the subject of the typo fix =).
Oops! I totally missed it. I will fix.
And always provide a patch description, please. In the simplest cases it
On 04/23/2012 08:25 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.
Signed-off-by:
On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren wrote:
> * DebBarma, Tarun Kanti [120424 08:40]:
>> Hi Janusz,
>>
>> On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti
>> wrote:
>> > On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik
>> > wrote:
>> >> On Thursday 02 of February 2012 23:00:
On 04/23/2012 08:01 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.
A
On Wed, Apr 25, 2012 at 06:33:26, Paul Walmsley wrote:
> Hello Vaibhav, Afzal, Vaibhav,
>
> On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
>
> > AM33XX clock implementation is different than any existing OMAP
> > family of devices. Although DPLL module is similar to OMAP4
> > device, but the usage i
On Tue, 2012-04-24 at 23:48 -0500, Ricardo Neri wrote:
> On 04/23/2012 08:01 AM, Tomi Valkeinen wrote:
> > On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
> >> Implement the DSS device driver audio support interface in the HDMI
> >> panel driver and generic driver. The implementation relies
On 04/25/2012 05:02 AM, Oleg Matcovschi wrote:
> Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79
> Signed-off-by: Oleg Matcovschi
> ---
> v1:
> initial revision
> v2:
> resending patch including maintainers
>
> sound/soc/omap/omap-pcm.c |4
> 1 files changed, 4 insertions(+), 0 d
On Wed, Apr 25, 2012 at 10:04 AM, DebBarma, Tarun Kanti
wrote:
> On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren wrote:
>> * DebBarma, Tarun Kanti [120424 08:40]:
>>> Hi Janusz,
>>>
>>> On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti
>>> wrote:
>>> > On Sat, Apr 21, 2012 at 7:33 PM, Janu
100 matches
Mail list logo