Op 2 mei 2012, om 10:47 heeft Russ Dill het volgende geschreven:
[0.198272] omap-mcbsp.3: alias fck already exists
[3.461212] clock: dpll1_ck failed transition to 'locked'
What's happening in those 3.3 seconds?
regards,
Koen
--
To unsubscribe from this list: send the line
Hi Tony,
As you would have already seen, v4 of GPMC driver conversion has been
posted (this is v4-alt). I undertand the risk involved in converting
all board files to use new interface in a single patch series. But to
have a decent set of patches, I feel this is required. But this may
bring us to
Convert GPMC code to driver. Boards using GPMC should provide driver
with type of configuration, timing, CS. Platform devices would then be
created for each connected peripheral (details also to be passed by
board so that it reaches respective driver). And GPMC driver would
populate memory
Create API for platforms to adapt gpmc to HWMOD
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 52 +++-
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
This has been made for migrating boards one by one so that
old new interface can coexist. As a board is migrated to
new interface, return from gpmc_driver_migration w/o doing
anything; add a machine_is_ check for that board to return
Signed-off-by: Afzal Mohammed af...@ti.com
---
New interface for working with gpmc driver has been added
without modifying the existing interface. Latter has been kept
for migrating boards one by one, once all boards are migrated
to use the new interace, old interface to be deleted along with
renaming of new interface to old one
gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information
Note: This uses new interface for initializing smsc911x,
old interface should be removed once all boards are
converted to use new interface. So also machine_is_
check in gpmc.c as well
On Fri, 27 Apr 2012, Hiremath, Vaibhav wrote:
I will be waiting for your comment and conformation on, which family AM33xx
device should fall in? Please refer to the mail-chain -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67275.html
This decision turns out to be pretty
On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
From: Axel Haslam axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.
Hello Vaibhav,
I've reworked these patches somewhat to separate the PRM and CM changes
into their own patches. Also, the omap_hwmod changes have been separated
and moved into a different series, as have the clock tree changes.
So now, pending for 3.5, there are the SCM, voltagedomain, PRM,
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
Hi
On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with
On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote:
Hello Vaibhav,
I've reworked these patches somewhat to separate the PRM and CM changes
into their own patches. Also, the omap_hwmod changes have been separated
and moved into a different series, as have the clock tree changes.
So
This series has some miscellianeous clean up patches which help to add future
OMAP2+ device support with bit less changes. It is a preparatory series for
adding minimal OMAP5 support.
Boot tested on below platforms:
- OMAP2430 SDP
- OMAP3430 SDP
- OMAP4430 SDP
Thanks for Tony and Benoit for
Since OMAP4 code base now makes use of OMAP4 specific PRCM functions,
cm2xxx_3xxx.c need not be compiled for OMAP4 only builds.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |5 +
1 files changed, 1
Current OMAP code doesn't use any of the OMAP_WKG_ENB_SECURE_*
registers.
So remove those defines.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile | 160 -
1 files changed, 78 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 56ed62e..669e2b1 100644
cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code
cpu checks accordingly so that there is no need to patch
the file for any future OMAP2+ devices.
In long run, all these attributes should come from hwmod dev_attr based
on DMA IP version.
Signed-off-by: Santosh Shilimkar
EMIF, GMPC and DMM driver can ioremap() the address
space as part of driver intialisation and there is
no need to have static IO mapping for them.
Hence remove the un-used static IP space and let
the respective drivers manage it as part if driver
init.
Signed-off-by: Santosh Shilimkar
All OMAP2PLUS arch based machines makes use of mach-omap2 directory.
So just add one entry so that there is no need to patch this file
for any OMAP2+ devices.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/Makefile |4 +---
1 files changed, 1 insertions(+), 3
From: R Sricharan r.sricha...@ti.com
Instead of statically defining seperate arrays for every OMAP4+ archs,
have a generic init function to populate the arrays. This avoids the
need for creating new array for every arch added in the future that
reuses the prm and cm registers read/write code.
On Wed, May 02, 2012 at 14:50:21, Kristo, Tero wrote:
On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
From: Axel Haslam axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or
On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote:
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile | 160 -
1 files changed, 78 insertions(+), 82 deletions(-)
diff --git
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER)
are saved and restored here during an OFF
On Wed, May 2, 2012 at 3:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote:
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile | 160
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original state
post wakeup from OFF mode.
The rest of the DPLL's in OMAP4
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com
wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
It is observed that
Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven:
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com
wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra Nayak rna...@ti.com
SAR/ROM code restores only CORE DPLL to its original
On Wed, May 2, 2012 at 4:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 15:48:01, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 3:40 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
Hi Tero,
On Fri, Apr 20, 2012 at 15:03:34, Kristo, Tero wrote:
From: Rajendra
Hi Jean-Philippe,
On Monday 30 April 2012 12:23:27 jean-philippe francois wrote:
Hi,
I am trying to get a working preview from a CMOS sensor with a CFA bayer
pattern.
Does the CCDC_COLPTN register have any effect on previewer CFA interpolation
?
No it doesn't. The CCDC COLPTN register
On Wed, May 2, 2012 at 4:20 PM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven:
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com
wrote:
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
I am just guessing if that's indeed the case ;)
Haven't done any measurements to really check if that's indeed the case
though.
You
Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:
On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute
thomas2.kl...@uni-dortmund.de wrote:
Hi,
I finally had some time to do more tests on this problem. Findings below.
Great, I guess we are close to find the issue :)
Am 20.03.2012 20:47,
On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
I am just guessing if that's indeed the case ;)
Haven't done
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
I am just guessing if that's indeed the case ;)
I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and
have noticed a couple of issues...
Firstly, it fails to build drivers/mfd/omap-usb-host.c if you have:
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_HCD_OMAP=y
On Wed, May 02, 2012 at 17:16:19, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 5:10 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
How ?
SRAM is sower memory than DDR so I don't see how it
will reduce latency.
On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote:
[...]
How ?
On Wed, May 02, 2012 at 17:28:17, Shilimkar, Santosh wrote:
On Wed, May 2, 2012 at 5:25 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Wed, May 02, 2012 at 17:17:08, Menon, Nishanth wrote:
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com
wrote:
On Wed, May 02,
From: Peter Ujfalusi peter.ujfal...@ti.com
If dtb is provided the needed device will be created dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git
From: Peter Ujfalusi peter.ujfal...@ti.com
If dtb is provided the needed device will be created dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Hi,
On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote:
I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and
have noticed a couple of issues...
Firstly, it fails to build drivers/mfd/omap-usb-host.c if you have:
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
-Original Message-
From: Archit Taneja a0393...@ti.com
To: Joe Woodward j...@terrafix.co.uk
Cc: linux-omap@vger.kernel.org
Date: Wed, 2 May 2012 17:54:21 +0530
Subject: Re: Problems with 3.4-rc5
Hi,
On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote:
I've just given 3.4-rc5 a
Hello,
This series adds common configuration for the V1V8, V2V1 regulators from
twl6030. These regulators are commonly used to feed the twl6040 audio IC on
OMAP4 based boards (SDP4430, PandaBoards).
The regulator support for the twl6040 MFD driver will be going via MFD tree to
avoid cross tree
These supplies going to be needed for the twl6040 driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
These supplies going to be needed for the twl6040 driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
V1V8 supply from twl6030 commonly used as VIO for the machine.
V2V1 is adviced to supply the twl6040, and also to feed the twl6030's
VCXIO_IN, and VDAC_IN inputs.
Create the common regulator configurations for these regulators:
Make the V2V1 as supply_regulator for VCXIO, VDAC.
Add twl6040
twl6040 has three power supply source:
VBAT needs to be connected to VBAT, VIO, and V2V1.
Add regulator support for the VIO, V2V1 supplies.
Initially handle the two supply together with bulk commands.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Mark Brown
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,
movind SoC init code to
OMAP1, omap_32k_timer_init() function always returns true,
irrespective of whether error occurred while initializing 32k sync
counter as a kernel clocksource or not and execution will never
fallback to mpu_timer clocksource init code.
This patch adds check for return value from function
Depending on the bootloader, passing command-line arguments
with spaces may have issues. Some bootloaders doesn't seem
to pass along the quotes, passing only 'gp' part of the string,
which leads to wrong clocksource override configuration.
So this patch changes gp timer = gp_timer, for
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)
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
just checking on this one to
Currently in the 1.153 errata handling while waiting for transmitter
underflow if NACK is got the XUDF(Transmit underflow) flag is also set.
The flag is set after wait for the condition is over.
Cc: Alexander Shishkin virtu...@slind.org
Acked-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by:
By definition, wait_for_completion_timeout() returns an unsigned value and
therefore, it is not necessary to check if the return value is less than zero
as this is not possible.
This is based on a patch from Jon Hunter jon-hun...@ti.com
Changes from his patch
- Declare a long as the
Currently in probe
pm_runtime_put(dev-dev);
...
/* i2c device drivers may be active on return from add_adapter() */
adap-nr = pdev-id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev-dev, failure adding adapter\n);
goto
Currently the i2c driver calls the pm_runtime_enable and never
the disable. This may cause a warning when pm_runtime_enable
checks for the count match.Attempting to fix the same by calling
pm_runtime_disable in the error and the remove path.
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak
From: Tasslehoff Kjappfot tasskj...@gmail.com
i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again.
Prevent the overwrite of the errata flags.Move the errata handling to a unified
place in probe to prevent such errors. Thus preventing the overwrite of erratum
1p153.
On OMAP4 we were writing 1 to IRQENABLE_CLR which cleared only
the arbitration lost interrupt. The patch intends to fix the same by writing 0
to the IE register clearing all interrupts.
This is based on the work done by Vikram Pandita vikram.pand...@ti.com.
The changes from the original patch
The patch series does the following
- Warn fixes if CONFIG_PM_RUNTIME is not selected.
- In case of i2c remove register access was done without any
get_sync fix the same.
- Folds a patch from Tasslehoff to prevent any merge conflicts.
- Prevents the XDUF flag to be set if the underflow
In omap_i2c_remove we are accessing the I2C_CON register without
enabling the clocks. Fix the same by enabling the clocks and disabling
it.
This fixes the following crash.
[ 154.723022] [ cut here ]
[ 154.725677] WARNING: at
The section number in the recent errata document has changed.
Rename the erratum 1p153 to the unique id i462 instead, so that
it is easier to reference. Also change the function name and comments
to reflect the same.
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D
If PM runtime get_sync fails return with the error
so that no further reads/writes goes through the interface.
This will avoid possible abort. Add a error message in case
of failure with the cause of the failure.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not
omap-usb-host calls cpu_is_omap3430, which is defined in plat/cpu.h.
Reported-by: Guillaume GARDET guillaume.gar...@opensuse.org
Signed-off-by: Jeff Mahoney je...@suse.com
---
drivers/mfd/omap-usb-host.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/mfd/omap-usb-host.c
+++
The define should be the result of 1 Bit number.
Bit number for GPOCTL.GPO3 field is 2, which results
in 0x4 value.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
include/linux/mfd/twl6040.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
In memory, They are in this particular order:
- CSI2A
- CSIPHY1
- CSI2B
- CSIPHY2
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git
NOTE: This isn't the whole list of features that the
ISS supports, but the only ones supported at the moment.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/ov5650.c | 733 ++
include/media/ov5650.h | 10 +
4 files changed, 750 insertions(+), 0
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig| 16 +
arch/arm/mach-omap2/Makefile |2 +
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 16 ++
arch/arm/mach-omap2/Makefile |1 +
Also add support for following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/configs/omap2plus_defconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2b8cf73..5259691 100644
--- a/arch/arm/mach-omap2/devices.c
+++
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
Hi everyone,
It's been a long time since last version (5 months)! :)
This is the third version of the OMAP4 ISS driver,
which uses Media Controller and videobuf2 frameworks.
This patchset should apply cleanly on top of v3.4-rc5 kernel tag.
This driver attempts to provide an fully open source
On Wed, May 2, 2012 at 10:15 AM, Sergio Aguirre saagui...@ti.com wrote:
Hi everyone,
It's been a long time since last version (5 months)! :)
This is the third version of the OMAP4 ISS driver,
which uses Media Controller and videobuf2 frameworks.
This patchset should apply cleanly on top of
On Wed, May 02, 2012 at 02:08:36AM -0600, Paul Walmsley (p...@pwsan.com) wrote:
Allow the OMAP HDQ1W driver to be built for all OMAP2+ SoCs by
adjusting KConfig dependencies. The previous dependency required
either SOC_OMAP2430 or ARCH_OMAP3 to be set, but the HDQ IP block is
present on
* Shilimkar, Santosh santosh.shilim...@ti.com [120502 03:18]:
On Wed, May 2, 2012 at 3:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, May 02, 2012 at 03:18:08PM +0530, Santosh Shilimkar wrote:
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
On Wed, May 02, 2012 at 12:20:24PM +0530, Santosh Shilimkar wrote:
Greg,
On Wednesday 02 May 2012 10:46 AM, Greg KH wrote:
On Fri, Apr 27, 2012 at 05:54:02PM +0530, Santosh Shilimkar wrote:
Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
EMIF is an SDRAM
From: Santosh Shilimkar santosh.shilim...@ti.com
HIGMEM support in kernel is quite mature now and we have boards
like ZOOM, PANDA, SDP where 1 GB memories are installed. With
HIGHMEM disabled not all of the 1GB of RAM (only ~700MB) can be
accessed. Hence, enable HIGMEM to make use of the entire
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if
Hi Vaibhav,
On 05/02/2012 08:56 AM, 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
Vaibhav Hiremath hvaib...@ti.com writes:
OMAP1, omap_32k_timer_init() function always returns true,
irrespective of whether error occurred while initializing 32k sync
counter as a kernel clocksource or not and execution will never
fallback to mpu_timer clocksource init code.
This patch adds
Vaibhav Hiremath hvaib...@ti.com writes:
Depending on the bootloader, passing command-line arguments
with spaces may have issues. Some bootloaders doesn't seem
to pass along the quotes, passing only 'gp' part of the string,
which leads to wrong clocksource override configuration.
For
Vaibhav Hiremath hvaib...@ti.com writes:
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.
On Tue, May 01, 2012 at 10:47:35AM +0200, Jean Pihet wrote:
Hi Mark,
Hi Jean. Thanks for the review.
On Mon, Apr 30, 2012 at 11:25 PM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer mgr...@animalcreek.com
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
family of SoC's which is OMAP-based. The incorporation is
incomplete in that the EMAC cannot unblock the [ARM] core if
its blocked on a 'wfi' instruction. This is an issue with
the cpu_idle
Hi Tony,
On Mon, 23 Apr 2012, Tony Lindgren wrote:
Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
Made a few
On Wed, 2 May 2012, Paul Walmsley wrote:
Hi Tony,
On Mon, 23 Apr 2012, Tony Lindgren wrote:
Add MMC for 2420 so we can pass the DMA request lines the same
way as we already do on omap2430 and later.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com
wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
Recently a patch went in for tidspbridge code, to ioremap
SCM registers and solve a build break[1]. However it has
been pointed out before that this is a layer violation
given that control module should handle its own registers, this
series is an attempt to create APIs for the users of these
SCM contains boot addr and boot mode registers to control
other processors on different OMAP versions. It controls the
boot address and mode for DSP based subsystems like: IVA 2.1
(OMAP2430), IVA 2.2 (OMAP3) and DSP (OMAP4).
If contained within SCM registers, when a processor is
booting it uses
Provide an interface for a driver to call SCM functions to
set a boot address and boot mode.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/dsp.c |4
arch/arm/plat-omap/include/plat/dsp.h |3 +++
2 files changed, 7 insertions(+), 0
Instead of ioremapping SCM registers, use the correspondent layer
to write into them.
This allows us to get rid of a layer violation, since the registers
are no longer touched by driver code.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/staging/tidspbridge/core/tiomap3430.c
On Thu, May 03, 2012 at 01:26:18, Hunter, Jon wrote:
Hi Vaibhav,
On 05/02/2012 08:56 AM, 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
On Tue, May 1, 2012 at 3:50 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 05/01/2012 11:55 AM, Shilimkar, Santosh wrote:
On May 1, 2012 1:46 PM, Daniel Lezcanodaniel.lezc...@linaro.org
wrote:
On 05/01/2012 12:58 AM, Kevin Hilman wrote:
Daniel Lezcanodaniel.lezc...@linaro.org
1 - 100 of 111 matches
Mail list logo
