Nishanth,
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/mux.c |7 +++
arch/arm/plat-omap/include/plat/mux.h |5 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c
On Wednesday 28 October 2009 08:53:34 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote:
Yeah, maybe I took the SMP safeness into play without looking any code,
my bad =) I was remembering a different version of this McBSP thing, now
that I looked into it, it looked different.
Right, I reviewed the
Hi,
On Thu, Oct 29, 2009 at 06:56:03AM +0100, ext Gupta, Ajay Kumar wrote:
Felipe,
-Original Message-
From: Menon, Nishanth
Sent: Thursday, October 29, 2009 11:06 AM
To: Gupta, Ajay Kumar; Gadiyar, Anand; linux-omap@vger.kernel.org
Cc: felipe.ba...@nokia.com; t...@atomide.com
Dirk Behme wrote:
Madhusudhan wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Phaneendra Kumar Alapati
Sent: Wednesday, October 28, 2009 8:19 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP35xx: Added
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Thursday, October 29, 2009 12:29 PM
To: Gupta, Ajay Kumar
Cc: linux-omap@vger.kernel.org; Balbi Felipe (Nokia-D/Helsinki); Menon,
Nishanth; Gadiyar, Anand
Subject: Re: [PATCH 3/3] omap3evm: musb: Update
On Wed, 28 Oct 2009 08:53:34 +0200
Eero Nurkkala ext-eero.nurkk...@nokia.com wrote:
On Wed, 2009-10-28 at 06:52 +0100, Ujfalusi Peter (Nokia-D/Tampere)
Yeah, but I think this locking issue has nothing to do with SMP safe or not.
On playback start in omap_mcbsp_request the mcbsp-free is
On Thu, 29 Oct 2009 08:35:51 +0200
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
The spinlocks are unnecessary. In the above example, you get the same
with just return mcbsp-dma_op_mode;
- Peter's patch is a good cleanup.
Jarkko: are we going to take this?
Yep, you can have my
All of the OMAP3 IVA physical address macros in
plat-omap/include/plat/omap34xx.h are wrong[1]:
OMAP34XX_IVA_INTC_BASE: The IVA interrupt controller does not appear
to be accessible from the L3 interconnect, and in any case is
definitely not at 0x4000; the latter address appears to be the
Paul/Kevin,
As Madhu explained it looks like there are instances
where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 + VDD2
scaling). I understand that this should be done by cpufreq governors but here
is reason that I think the current cpufreq
Hi Kevin,
Made some patches to enable setting RX-51 cpu idle parameters
as we use them. Added valid field passing to cpuidle_params
in the process.
Tested on RX-51. Applies on top of linux-omap/pm branch.
Kalle Jokiniemi (3):
OMAP:PM: Fix non-cpu idle builds using omap3_pm_init_cpuidle
Building without CONFIG_CPU_IDLE causes build to fail if
cpu idle parameters are tried to pass using
omap3_pm_init_cpuidle function.
Fixed by defining a dummy function for non-cpu idle
builds.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
arch/arm/mach-omap2/pm.h |7 +++
Different boards benefit differently from the available
seven C-states for cpu idle. In most cases, only few,
properly spaced (in terms of consumption and latency)
C-states are required to make the power management
optimal. Hence we need a possibility to pass which
C-states are actually used for
OK, let's try this once more, since my mail did not seem to go to
linux-omap.
Sorry for the spam.
See my comments below:
On Fri, 2009-10-23 at 18:53 +0300, Sonasath, Moiz wrote:
Hello Jokiniemi!
-Original Message-
From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
Sent:
Hi,
On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote:
I was thinking on adding a musb_hdrc_board_data which would group
board-specific data such as this one.
Musb's init phase is quite messy as of today so we would need to clean
that up. Anyways, the main idea is:
Dirk and Madhu, Thanks for the review/comments. I have explained below
the reasons behind certain changes i made esp the interrupt enabling
and irq routine changes.
On Thu, Oct 29, 2009 at 2:22 AM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Dirk Behme
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091028 06:17]:
This is an attempt to start rework of the mux framework keeping as
much backward compatibility as possible.
The patch serie introduces a new mux configuration interface that
follows the ideas of PXA MFP implementation
Hi Kevin,
On Wed, 2009-10-21 at 14:51 +0300, Kalle Jokiniemi wrote:
Hello,
Here are some fruits from digging out the latency sources
of our idle loop. The main latency source was powerdomain
state counter updating at beginning and end of the idle
loop. Also PER previous state reading
On Thu, Oct 29, 2009 at 01:30:41PM +0530, Aggarwal, Anuj wrote:
I rebased my both audio and l-o trees but could not find this patch
there. Is there a problem in this which I have to fix and re-submit?
You should always CC the relevant maintainers on patches, otherwise
there is no guarantee
Hi,
On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote:
I was thinking on adding a musb_hdrc_board_data which would group
board-specific data such as this one.
Musb's init phase is quite messy as of today so we would need to clean
that up. Anyways, the main idea
On Thu, Oct 29, 2009 at 01:09:25PM +0530, Dasgupta, Romit wrote:
[Reflowed into 80 columns - you might want to look at your MUA setup.]
The sampling intervals for the cpufreq governors are quite large
and thus the latency for the frequency change to occur is large.
This was
Hi Romit,
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit
Paul/Kevin,
Enable Nand suport on the OMAP3EVM.
Signed-off-by: Sriramakrishnan s...@ti.com
---
This patch has been generated against the tip of for-next branch.
arch/arm/configs/omap3_evm_defconfig |2 +
arch/arm/mach-omap2/board-omap3evm.c | 102 ++
2 files changed,
Hi,
On Wed, 2009-10-28 at 08:13 +0100, ext Govindraj.R wrote:
From 0f017ffac2990876331a2378e7845d91b2e0088c Mon Sep 17 00:00:00 2001
From: Govindraj R govindraj.r...@ti.com
Date: Wed, 28 Oct 2009 12:23:02 +0530
Subject: [PATCHv2 2/3] OMAP UART: Add platform data for omap-serial driver.
Currently the default silicon - in absence of
identification - is set to OMAP3630 ES1.0.
Though, condition may/should not arise; but
the default should be latest in the most
common silicon variant - currently OMAP3430
ES3.1.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c
On Thu, Oct 29, 2009 at 12:30 PM, Dirk Behme dirk.be...@googlemail.com wrote:
Dirk Behme wrote:
I promised to come back with test results. As mentioned in this thread
already, I can't test on my own yet, instead Steve (many, many thanks!)
tests it on Overo air. Overo air uses Marvell's
Hello Benoit,
One comment below:
In fact, this is Mike who started that analysis. We discussed that internally
and
our point is that if the CPUFreq ondemand or conservative heuristic is not
able
to increase quickly enough the CPU need to handle correctly the UI, we
Dasgupta, Romit ro...@ti.com writes:
Hello Benoit,
One comment below:
In fact, this is Mike who started that analysis. We discussed that
internally and
our point is that if the CPUFreq ondemand or conservative heuristic is not
able
to increase quickly enough the
* Mike Rapoport m...@compulab.co.il [091029 02:45]:
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091028 06:17]:
This is an attempt to start rework of the mux framework keeping as
much backward compatibility as possible.
The patch serie introduces a new mux configuration
* Mike Rapoport m...@compulab.co.il [091028 06:17]:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/mux.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index
Enable Nand support on am3517evm
Signed-off-by: Sriramakrishnan s...@ti.com
---
This patch builds on the am3517evm board support patch submitted earlier.
http://marc.info/?l=linux-omapm=125673923227266w=2
arch/arm/configs/am3517_evm_defconfig | 103 -
Hi, all!
I need to transfer block of data using sDMA from memory address
to RFBI_PARAM FIFO, so to put that into display module.
I do this like this:
/* DMA */
#define RFBI_BASE 0x48050800
#define RFBI_PARAM 0x0050
static void configure_dma(int dma_ch, u32 data, int size)
{
int nblk;
* Tony Lindgren t...@atomide.com [091029 08:50]:
* Mike Rapoport m...@compulab.co.il [091028 06:17]:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/mux.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git
On Thu, Oct 29, 2009 at 11:29:39AM +0100, ext Gupta, Ajay Kumar wrote:
Hi,
On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote:
I was thinking on adding a musb_hdrc_board_data which would group
board-specific data such as this one.
Musb's init phase is quite
This patch series add support for OMAP3517 / AM3517 EVM in ASOC.
It also enables the required drivers - I2C and McBSP, along with
Alsa SoC subsystem, in the default configuration for the EVM.
Anuj Aggarwal (4):
Audio: Adding OMAP3517 / AM3517 EVM support in ASOC
Audio: Modifying
Adding support for OMAP3517 / AM3517 EVM in Alsa SoC.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
sound/soc/omap/am3517evm.c | 202
1 files changed, 202 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/omap/am3517evm.c
diff
Modifying the Kconfig and Makefile in sound/soc/omap folder
to add support for OMAP3517 / AM3517 EVM in Alsa SoC.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
sound/soc/omap/Kconfig |9 +
sound/soc/omap/Makefile |2 ++
2 files changed, 11 insertions(+), 0 deletions(-)
Adding I2C bus registration code in board-evm file for OMAP3517 /
AM3517 EVM for AIC23 audio codec.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git
Enabling Audio for OMAP3517 / AM3517 EVM in the defconfig.
Also enabling McBSP and I2C drivers as both are required for
audio on this EVM.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/configs/am3517_evm_defconfig | 78 +++-
1 files changed, 75
On Thu, Oct 29, 2009 at 6:51 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [091029 08:50]:
* Mike Rapoport m...@compulab.co.il [091028 06:17]:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/mux.c | 25 +++--
1
* Mike Rapoport mike.rapop...@gmail.com [091029 13:28]:
On Thu, Oct 29, 2009 at 6:51 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [091029 08:50]:
* Mike Rapoport m...@compulab.co.il [091028 06:17]:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
Hi all,
Here's an initial version of the new mux code to play with.
Big thanks to Paul Benoit for the 34xx mux data!
To try out the new code, compile a kernel with CONFIG_OMAP_MUX
and CONFIG_DEBUG_FS and these patches. The series is also
availabe in the l-o git in mux branch.
To see the mux
From: Mike Rapoport m...@compulab.co.il
intoduce omap_mux_{read,write}
Signed-off-by: Mike Rapoport m...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 44 ++--
1 files changed, 38 insertions(+), 6
Initially only for 34xx. Keep the old code working
until the data has been converted to the new style
format.
REVISIT: Add support for cmdline parsing
REVISIT: Add a function to get mux register by GPIO pin
REVISIT: Add a function to set an array of mux entries
Signed-off-by: Tony Lindgren
Add new style mux init functions to omap3 board-*.c files
REVISIT: Check package type for each board CBB for now
REVISIT: Remove OMAP_MUX_ALL_DYNAMIC debug option
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c |9 +
Add debugfs support for new mux code
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 143 +
1 files changed, 143 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index
Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS. This causes ondemand and conservative governors to
sample CPU load more often resulting in more responsive behavior.
Tested on Android 2.6.29; using this value and conservative governor, CORE
power
Comments below...
Phaneendra Kumar Alapati wrote:
Dirk and Madhu, Thanks for the review/comments. I have explained below
the reasons behind certain changes i made esp the interrupt enabling
and irq routine changes.
On Thu, Oct 29, 2009 at 2:22 AM, Madhusudhan madhu...@ti.com wrote:
Mike Turquette mturque...@gmail.com writes:
Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS. This causes ondemand and conservative governors to
sample CPU load more often resulting in more responsive behavior.
Tested on Android 2.6.29; using this
Hi Tony,
On Thu, Oct 29, 2009 at 10:35 PM, Tony Lindgren t...@atomide.com wrote:
Hi all,
Here's an initial version of the new mux code to play with.
Big thanks to Paul Benoit for the 34xx mux data!
To try out the new code, compile a kernel with CONFIG_OMAP_MUX
and CONFIG_DEBUG_FS and
Kevin Hilman wrote:
Dasgupta, Romit ro...@ti.com writes:
Hello Benoit,
One comment below:
In fact, this is Mike who started that analysis. We discussed that internally
and
our point is that if the CPUFreq ondemand or conservative heuristic is not able
to increase
Kevin Hilman wrote:
Mike Turquette mturque...@gmail.com writes:
Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS. This causes ondemand and conservative governors to
sample CPU load more often resulting in more responsive behavior.
Tested on Android
Mike Turquette mturque...@ti.com writes:
Kevin Hilman wrote:
Mike Turquette mturque...@gmail.com writes:
Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS. This causes ondemand and conservative governors to
sample CPU load more often resulting in
* Mike Rapoport mike.rapop...@gmail.com [091029 14:19]:
Hi Tony,
On Thu, Oct 29, 2009 at 10:35 PM, Tony Lindgren t...@atomide.com wrote:
Hi all,
Here's an initial version of the new mux code to play with.
Big thanks to Paul Benoit for the 34xx mux data!
To try out the new code,
On Fri, Oct 30, 2009 at 12:22:17AM +0530, Anuj Aggarwal wrote:
This patch series add support for OMAP3517 / AM3517 EVM in ASOC.
It also enables the required drivers - I2C and McBSP, along with
Alsa SoC subsystem, in the default configuration for the EVM.
Anuj Aggarwal (4):
Audio: Adding
With CONFIG_PM=y, the omapfb/lcd device on Amstrad Delta, after initially
starting correctly, breaks with the following error messages:
omapfb omapfb: resetting (status 0xff96,reset count 1)
...
omapfb omapfb: resetting (status 0xff96,reset count 100)
omapfb omapfb: too many reset
Kalle Jokiniemi kalle.jokini...@digia.com writes:
From: Kalle Jokiniemi ext-kalle.jokini...@nokia.com
The biggest source of latency in idle loop (omap_sram_idle
function) comes from updating the state counters for each
power domain. The two purposes of these counters are to
provide debug
Madhusudhan madhu...@ti.com writes:
-Original Message-
From: Mike Turquette [mailto:mturque...@ti.com]
Sent: Thursday, October 29, 2009 4:38 PM
To: Kevin Hilman
Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan;
'Paul Walmsley'; linux-omap@vger.kernel.org;
Thursday 29 October 2009 23:39:44 Janusz Krzysztofik napisał(a):
Since PM area is quite new to me, I am not sure if there may be a better
solution. AFAICS, the standard way to prevent an ARM_CLKCT1 bit being
s/ARM_CLKCT1/ARM_IDLECT1/
switched to idle is to enable a clock that uses it
Hi all,
Today's linux-next merge of the omap tree got a conflict in
arch/arm/mach-omap1/serial.c between commit
c33da3a80074094303d643a90ef589330b491270 (omap1: Fix redundant UARTs pin
muxing that can break other hardware support) from Linus' tree and
commits
Hi all,
Today's linux-next merge of the omap tree got conflicts in
arch/arm/mach-omap2/board-3430sdp.c, arch/arm/mach-omap2/board-ldp.c,
arch/arm/mach-omap2/board-omap3evm.c,
arch/arm/mach-omap2/board-omap3pandora.c,
arch/arm/mach-omap2/board-rx51-peripherals.c,
arch/arm/mach-omap2/board-rx51.c
From a36dac7ee6140ffa23f0adc024964aaf3e266e5f Mon Sep 17 00:00:00 2001
From: Tao Hu ta...@motorola.com
Date: Thu, 29 Oct 2009 17:17:21 -0500
Subject: [PATCH] Fix race condition in omap_request_dma()
The bug could cause irq enable bit of one DMA channel is
cleared unexpectedly when 2 (or more)
61 matches
Mail list logo
