Eliminates the following sparse warning:
arch/arm/plat-omap/dma.c:137:5: warning: symbol 'omap_dma_in_1510_mode'
was not declared. Should it be static?
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/plat-omap/dma.c |2 +-
1 files changed, 1 insertions(+), 1
On Tue, Jan 18, 2011 at 09:52:45AM +0200, Aaro Koskinen wrote:
Eliminates the following sparse warnings:
arch/arm/mach-omap1/board-voiceblue.c:253:6: warning: symbol
'voiceblue_wdt_enable' was not declared. Should it be static?
arch/arm/mach-omap1/board-voiceblue.c:261:6:
Hi,
would it please be possible improve comments and the commit message and
make them explain better which problem the patch solves, what is the
problem with the current code, how exactly you solve the problem, and
why your solution is the best among other alternative solutions?
I think the
On Tue, Jan 18, 2011 at 10:11:56AM +0200, Felipe Balbi wrote:
On Tue, Jan 18, 2011 at 09:52:45AM +0200, Aaro Koskinen wrote:
Eliminates the following sparse warnings:
arch/arm/mach-omap1/board-voiceblue.c:253:6: warning: symbol
'voiceblue_wdt_enable' was not declared. Should it be
On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
parts of the chip will be reset. If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Cc: Paul Walmsley
On Tue, Jan 18, 2011 at 12:28, Thomas Weber we...@corscience.de wrote:
This patch fixes a wrongly used lcd enable pin.
The Devkit8000 uses twl4030_ledA configured as output gpio only for the
lcd enable line. twl4030_gpio.1 is used through the generic gpio functions
while ledA is used via low
Couple of minor comments.
On Tue, Jan 18, 2011 at 13:19, Sanjeev Premi pr...@ti.com wrote:
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].
On Tue, Jan 18, 2011 at 09:52:44AM +0200, Aaro Koskinen wrote:
Move voiceblue definitions into the board-specific header.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Let's instead simplify this, and allow other platforms to hook into the
reset handler if they choose. This has only been
On Tue, Jan 18, 2011 at 10:36:08AM -, Will Deacon wrote:
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c22c1ad..9c43052 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE) :=$(call
From: Jean Pihet j-pi...@ti.com
The new fncpy API is better suited for copying some
code to SRAM at runtime. This patch changes the ad-hoc
code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
Compile tested on
Dave, Russell,
On Mon, Jan 17, 2011 at 4:46 PM, Dave Martin dave.mar...@linaro.org wrote:
On Mon, Jan 17, 2011 at 2:01 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
On Fri, Jan 14, 2011 at 6:34 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Jan 14, 2011 at 05:13:01PM
On Tue, Jan 18, 2011 at 11:09:22AM +, Russell King - ARM Linux wrote:
I'd rather not in this patch - this patch adds CPU_V6K as an alias for
CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
We could remove it in a later patch though.
Here's a follow-up patch to do
Changes invloves:
1) Addition of hwmod data for omap2/3/4.
2) McSPI driver hwmod adaptation with cleanup of base address
macros and using omap-device API's.
3) Runtime Conversion of McSPI driver.
Changes fomr v3:
---
1) Updated proper Author for all patches which
From: Charulatha V ch...@ti.com
Update omap3 hwmod data file with McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280
From: Charulatha V ch...@ti.com
Update the 2430 hwmod data file with McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219
From: Charulatha V ch...@ti.com
Update the omap2420 hwmod data with the McSPI info.
Add a device attribute structure which will be used
for passing number of chipselects from hwmod data.
Add revision macros to be passed from rev field from
hwmod.
Signed-off-by: Charulatha V ch...@ti.com
From: Benoit Cousson b-cous...@ti.com
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
McSPI runtime conversion.
Changes involves:
1) remove clock framework apis to use runtime framework apis.
2) context restore from runtime resume which is a callback for get_sync.
3) Remove SYSCONFIG(sysc) register handling
(a) Remove context save and restore of sysc reg and remove soft
On Tue, 18 Jan 2011 05:10:39 +0200, Felipe Balbi ba...@ti.com wrote:
NAK. This is totally bogus. The board doesn't really depend on
GPIO_TWL4030, the MMC driver does.
I've looked a little more deeply into this and I'm not entirely
convinced that what you claim is true. It seems that the only
On Tue, 2011-01-18 at 10:45 +0530, ext Taneja, Archit wrote:
Hi,
I was going through the DSS2 code which sets up the FCLK
coming from PRCM and the DISPC divivors to get the required pixel
clock.
The function dss_calc_clock_div() does a brute force search across
all possible values of:
This patch series is an effort to split the clockdomain
framework into platform independent and platform specific parts
as was done for the powerdomain framework.
This certainlly helps remove the various cpu_is_* checks
which exist today in the framework and makes
the code more maintainable and
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
This is in preparation of splitting the clockdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
Signed-off-by: Rajendra Nayak
Define the following architecture specific funtions for omap2/3/4
.clkdm_sleep
.clkdm_wakeup
Convert the platform-independent framework to call these functions.
Also rename the api's by removing the omap2_ preamble.
Hence call omap2_clkdm_wakeup as clkdm_wakeup and
omap2_clkdm_sleep as
Define the following architecture specific funtions for omap2/3/4
.clkdm_allow_idle
.clkdm_deny_idle
Convert the platform-independent framework to call these functions.
Also rename the api's by removing the omap2_ preamble.
Hence call omap2_clkdm_allow_idle as clkdm_allow_idle and
Define the following architecture specific funtions for omap2/3
.clkdm_add_wkdep
.clkdm_del_wkdep
.clkdm_read_wkdep
.clkdm_clear_all_wkdeps
.clkdm_add_sleepdep
.clkdm_del_sleepdep
.clkdm_read_sleepdep
.clkdm_clear_all_sleepdeps
Convert the platform-independent framework to call these functions.
On Mon, Jan 17, 2011 at 07:20:50PM +, Russell King - ARM Linux wrote:
This patch series reworks the ARMv6/ARMv6K support options, code
selection, and bit operations such that it's possible to safely
build a kernel which supports ARMv6, ARMv6K, ARMv7 and ARMv7 SMP
in one image.
Is it
On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
I also wonder what happens with a misaligned ldrex/strex... Does the
alignment trap get invoked? If so, the assertion could be put there
instead if that's not done already, removing this overhead from bitops
calls. In the
On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
On Mon, Jan 17, 2011 at 07:20:50PM +, Russell King - ARM Linux wrote:
This patch series reworks the ARMv6/ARMv6K support options, code
selection, and bit operations such that it's possible to safely
build a kernel which
On Tue, Jan 18, 2011 at 02:40:14PM +, Russell King - ARM Linux wrote:
On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
On Mon, Jan 17, 2011 at 07:20:50PM +, Russell King - ARM Linux wrote:
This patch series reworks the ARMv6/ARMv6K support options, code
On Tue, Jan 18, 2011 at 04:44:52PM +0200, Kirill A. Shutemov wrote:
On Tue, Jan 18, 2011 at 02:40:14PM +, Russell King - ARM Linux wrote:
On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
On Mon, Jan 17, 2011 at 07:20:50PM +, Russell King - ARM Linux wrote:
This
On 18 January 2011 06:00, Nicolas Pitre n...@fluxnic.net wrote:
On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
Add additional instructions to our assembly bitops functions to ensure
that they only operate on word-aligned pointers. This will be necessary
when we switch these operations
Pass the board specific serial pad mux data
to the platform level init code.
Signed-off-by: sricharan r.sricha...@ti.com
---
This is a test patch and not intended for a specific use case.
1) The support to add the pad data to the device hwmod entry and to use
it to dynamically configure the
Hi Russell,
On Mon, Jan 17, 2011 at 10:46:18AM +, Russell King - ARM Linux wrote:
On Mon, Jan 17, 2011 at 11:08:57AM +0100, Uwe Kleine-König wrote:
On Sun, Jan 16, 2011 at 12:19:11PM +, Russell King - ARM Linux wrote:
This does need a fair amount of testing before it can be merged,
Op 18 jan 2011, om 08:49 heeft Sanjeev Premi het volgende geschreven:
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].
This patch
On Tue, Jan 18, 2011 at 04:32:57PM +0100, Uwe Kleine-König wrote:
Hi Russell,
On Mon, Jan 17, 2011 at 10:46:18AM +, Russell King - ARM Linux wrote:
On Mon, Jan 17, 2011 at 11:08:57AM +0100, Uwe Kleine-König wrote:
On Sun, Jan 16, 2011 at 12:19:11PM +, Russell King - ARM Linux
Hello Russell,
On Tue, Jan 18, 2011 at 03:43:44PM +, Russell King - ARM Linux wrote:
On Tue, Jan 18, 2011 at 04:32:57PM +0100, Uwe Kleine-König wrote:
On Mon, Jan 17, 2011 at 10:46:18AM +, Russell King - ARM Linux wrote:
I will continue to mail out patches which I want people to test
On Tue, Jan 18, 2011 at 04:58:51PM +0100, Uwe Kleine-König wrote:
Hello Russell,
On Tue, Jan 18, 2011 at 03:43:44PM +, Russell King - ARM Linux wrote:
On Tue, Jan 18, 2011 at 04:32:57PM +0100, Uwe Kleine-König wrote:
On Mon, Jan 17, 2011 at 10:46:18AM +, Russell King - ARM Linux
Koen Kooi wrote, on 01/18/2011 05:38 PM:
Op 18 jan 2011, om 08:49 heeft Sanjeev Premi het volgende geschreven:
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
Kooi,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Tuesday, January 18, 2011 10:19 PM
To: Koen Kooi
Cc: Sanjeev Premi; l-o List; th...@ti.com; Vishwanath Sripathy
Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
Koen Kooi wrote, on 01/18/2011
This patch series adds support for ADMA on MMC1 MMC2 controllers on OMAP4.
There is no performance improvement observed using ADMA over SDMA.
Advantage using ADMA could be reducing contention over SDMA.
Also the series includes some cleanup.
The series is based on 2.6.37-rc8 and tested on
OMAP4 introduces dedicated internal DMA which is ADMA for its MMC
controllers HSMMC1 HSMMC2.
Renaming use_dma member of the struct omap_hsmmc_host to xfer_type
and defining the transfer modes PIO/SDMA/ADMA that can be used by the
MMC controller.
Signed-off-by: Kishore Kadiyala
Renaming omap_hsmmc_dma_cleanup as omap_hsmmc_xfer_cleanup and doing some
cleanup by handling the error success scenarios during a transfer for
different xfer_type.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Reviewed-by: Sukumar Ghorai s-gho...@ti.com
---
On OMAP4, MMC1 MMC2 controllers support ADMA feature which will
provide direct access to internal data.
Basically ADMA is a DMA controller embedded in the MMC controller.
It fetches each descriptor line [address+length+attributes] from a
descriptor table and executes the corresponding action
Enable ADMA support for MMC1 MMC2 controller on omap4 by updating
features of struct omap_mmc_platform_data.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Reviewed-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 13
On Tuesday 18 January 2011 21:13:43 Artem Bityutskiy wrote:
Hi,
would it please be possible improve comments and the commit message and
make them explain better which problem the patch solves, what is the
problem with the current code, how exactly you solve the problem, and
why your solution
Op 18 jan 2011, om 18:18 heeft Vishwanath Sripathy het volgende geschreven:
Kooi,
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Tuesday, January 18, 2011 10:19 PM
To: Koen Kooi
Cc: Sanjeev Premi; l-o List; th...@ti.com; Vishwanath Sripathy
Subject: Re:
On Tue, 18 Jan 2011, Russell King - ARM Linux wrote:
On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
I also wonder what happens with a misaligned ldrex/strex... Does the
alignment trap get invoked? If so, the assertion could be put there
instead if that's not done
A warning for OMAP.
Your use of the __virt_to_phys() in assembly code for the debug stuff
will break with this patch... please ensure that it is resolved by the
next merge window.
- Forwarded message from Russell King - ARM Linux li...@arm.linux.org.uk
-
Date: Tue, 04 Jan 2011 20:23:18
On Mon, 6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
What happened to the board
On Mon, 17 Jan 2011, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [110115 20:31]:
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
omap_init_mpu_timer(rate);
omap_init_clocksource(rate);
Here's a slightly updated version of this patch, fixing a bug in one of
the comments, and revising the commit message. There's no functional
difference between this and the previous version of this patch.
- Paul
[PATCH] OMAP: counter_32k: init clocksource as part of machine timer init
Hi Tony,
These changes fix the clocksource oops on boot, reduce the amount of
now-unnecessary warning backtraces on OMAP4-only configs, and remove some
warnings from 'make includecheck'.
The following changes since commit e78bf5e6cbe837daa6ab628a5f679548742994d3:
drivers/nfc/pn544.c: fix
* Russell King - ARM Linux li...@arm.linux.org.uk [110118 10:32]:
A warning for OMAP.
Your use of the __virt_to_phys() in assembly code for the debug stuff
will break with this patch... please ensure that it is resolved by the
next merge window.
Sure thanks. I'm aware of this series, will
Hi,
Tomi Valkeinen wrote:
On Tue, 2011-01-18 at 10:45 +0530, ext Taneja, Archit wrote:
Hi,
I was going through the DSS2 code which sets up the FCLK coming
from PRCM and the DISPC divivors to get the required pixel clock.
The function dss_calc_clock_div() does a brute force search across
This patch exports omap_pm_set_min_bus_tput from omap-pm-noop.c to modules,
to allow building omap3-isp as module without another pm implementation.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/plat-omap/omap-pm-noop.c |1 +
1 files changed, 1 insertions(+), 0
In a modular build of the iommu code it's possible that the arch iommu code
isn't loaded when trying to enable the iommu. Instead of blindly following a
null pointer return -NODEV in that case.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/plat-omap/iommu.c |3
Hi Martin
On Tue, 18 Jan 2011, Martin Hostettler wrote:
This patch exports omap_pm_set_min_bus_tput from omap-pm-noop.c to modules,
to allow building omap3-isp as module without another pm implementation.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
We would like device
On Tue, 18 Jan 2011, Tero Kristo wrote:
On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
parts of the chip will be reset. If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results.
Signed-off-by: Tero Kristo
* Paul Walmsley p...@pwsan.com [110118 11:35]:
Here's a slightly updated version of this patch, fixing a bug in one of
the comments, and revising the commit message. There's no functional
difference between this and the previous version of this patch.
Thanks, here are two patches to fix
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 177 +++
2 files changed, 178 insertions(+),
For omap15xx and 730 we need to use the MPU timer
as the 32K timer is not available. For omap16xx
we want to use the 32K timer because of PM. Fix this
by allowing to build in both timers.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap1/Kconfig
+++
Hi Govindraj,
On 1/18/2011 7:30 AM, Govindraj wrote:
On Mon, Jan 17, 2011 at 9:59 PM, Kevin Hilmankhil...@ti.com wrote:
Govindraj.Rgovindraj.r...@ti.com writes:
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Signed-off-by: Charulatha Vch...@ti.com
* Tony Lindgren t...@atomide.com [110118 14:34]:
For omap15xx and 730 we need to use the MPU timer
as the 32K timer is not available. For omap16xx
we want to use the 32K timer because of PM. Fix this
by allowing to build in both timers.
This still needs one more patch to deal with the
Hi Martin,
Thanks for the patch.
On Tuesday 18 January 2011 23:32:16 Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
On Tue, Jan 18, 2011 at 01:05:49PM +0100, Jean Pihet wrote:
Dave, Russell,
On Mon, Jan 17, 2011 at 4:46 PM, Dave Martin dave.mar...@linaro.org wrote:
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
* Russell King - ARM Linux li...@arm.linux.org.uk [110118 15:41]:
On Tue, Jan 18, 2011 at 01:05:49PM +0100, Jean Pihet wrote:
Dave, Russell,
On Mon, Jan 17, 2011 at 4:46 PM, Dave Martin dave.mar...@linaro.org wrote:
One way to work around this is would be to make omap_sram_push() a
On Tue, Jan 18, 2011 at 08:51:52AM -0500, Ben Gamari wrote:
On Tue, 18 Jan 2011 05:10:39 +0200, Felipe Balbi ba...@ti.com wrote:
NAK. This is totally bogus. The board doesn't really depend on
GPIO_TWL4030, the MMC driver does.
I've looked a little more deeply into this and I'm not
Tero,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Tuesday, January 18, 2011 3:18 PM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: [PATCH] OMAP3: CPUIdle: prevent CORE
Tero,
-Original Message-
From: Vishwanath Sripathy [mailto:vishwanath...@ti.com]
Sent: Wednesday, January 19, 2011 10:09 AM
To: Tero Kristo; linux-omap@vger.kernel.org
Cc: Paul Walmsley; Kevin Hilman
Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if
doing so would
69 matches
Mail list logo
