Tony,
On Mon, May 7, 2012 at 11:04 PM, Tony Lindgren t...@atomide.com wrote:
* R, Sricharan r.sricha...@ti.com [120506 00:42]:
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i
On Tue, May 8, 2012 at 10:39 AM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 2 May 2012, Santosh Shilimkar wrote:
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
On Tue, May 8, 2012 at 10:45 AM, Paul Walmsley p...@pwsan.com wrote:
On Wed, 2 May 2012, Santosh Shilimkar wrote:
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
Hi Jon,
On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote:
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default?
Hi Jon,
On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote:
Clk_prd is a platform data passed to the driver, so platform code
updates it, where else can it be done ?
The point is that you can pass what ever you like. You do not need to
pass the frequency you can pass the clock handle
Hi Jon,
On Mon, May 07, 2012 at 21:53:34, Hunter, Jon wrote:
Write protect is a pin and there is only one. Like the waitpins and CS
signals this needs to be associated with a device. It would make sense
that this is associated with the cs data.
As far as platform are concerned, it is
On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote:
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add request_mem_region). This change
prevented the Amstrad Delta NAND
On Tue, 2012-05-08 at 09:54 +0530, Archit Taneja wrote:
Hi,
On Monday 07 May 2012 08:17 PM, Tomi Valkeinen wrote:
Hi,
dss_ovl|mgr_enable|disable functions handle GO, so you could have a
look at them. However, setting the timings is a bit different, so I'm
not sure how it should be
On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote:
On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote:
A call to request_mem_region() has been introduced in the omap-gpio
driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40,
gpio/omap: Use devm_ API and add
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430 SDP, OMAP3430 SDP and OMAP4430 SDP platforms.
I have dropped {[PATCH 7/7] ARM: OMAP4+: Add prm and cm base init function}
from this set since Paul is taking that one in his queue.
On Tue, 2012-05-08 at 10:33 +0530, Archit Taneja wrote:
On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a
need to
use the omap_dss_device struct to get the
On Tuesday 08 May 2012 04:33 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120502 02:51]:
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
On Tuesday 08 May 2012 03:56 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120507 02:53]:
Tony,
On Thursday 03 May 2012 12:56 PM, R Sricharan wrote:
The series adds minimal OMAP5 support.
OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB
L2 cache. The
On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:
On Tue, 2012-05-08 at 10:33 +0530, Archit Taneja wrote:
On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a
On 05/03/2012 11:22 PM, Venkatraman S wrote:
Standard eMMC (Embedded MultiMedia Card) specification expects to execute
one request at a time. If some requests are more important than others, they
can't be aborted while the flash procedure is in progress.
New versions of the eMMC standard
On 05/07/12 17:48, Alan Stern wrote:
On Mon, 7 May 2012, Igor Grinberg wrote:
On 05/07/12 17:04, Alan Stern wrote:
On Sun, 6 May 2012, Igor Grinberg wrote:
Hi Alan,
...
Sorry, for being jumpy...
Samuel has not answered yet (it has been more then two weeks already)
and I'd like this to
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
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
to RET. Instead there are
Hi Paul,
Thanks for the review. Do you plan to review the full set before I
start to address the comments.
On Mon, May 7, 2012 at 8:41 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet
ping x2
On 04/19/12 13:40, Igor Grinberg wrote:
ping!
Tony, can this please, go into 3.5?
On 03/28/12 11:51, Igor Grinberg wrote:
Enable the power off feature of the TPS65930 on-board PMIC.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c |
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
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
to RET. Instead there are
Paul,
On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings and to
Hi Russ,
On 05/07/12 23:00, Russ Dill wrote:
This removes several boot warnings from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a combination of leftover code and revision confusion.
Additionally, xM support is currently
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen tomi.valkei...@ti.com [120503 07:01]:
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's
the
first set of patches from that ordeal. There's nothing DT specific in these
On Tue, 2012-05-08 at 13:08 +0530, Archit Taneja wrote:
On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:
I'm not sure if it applies here, but as a general strategy, I suggest
doing things in apply.c that require data from apply.c's internal data.
When that's not possible, apply.c
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power
From: Govindraj.R govindraj.r...@ti.com
On omap2/3 module level wakeup is handled using PM_WKEN registers.
Expand the hwmod framework to handle the module level wakeup enable
registers.
Patch series based on:
git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5
Tested on Beagle-xm
From: Govindraj.R govindraj.r...@ti.com
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs.
Add soc specific api to control the module level wakeup mechanism in hwmod
layer. omap_hwmod_enable/disable_wakeup is used from serial.c which should
From: Govindraj.R govindraj.r...@ti.com
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 p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc:
On Tuesday 08 May 2012 02:22 PM, Tomi Valkeinen wrote:
On Tue, 2012-05-08 at 13:08 +0530, Archit Taneja wrote:
On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:
I'm not sure if it applies here, but as a general strategy, I suggest
doing things in apply.c that require data from apply.c's
On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
On OMAP4, there is no support to read previous
On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley p...@pwsan.com wrote:
Govindraj,
After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 (ARM: OMAP2+:
UART: Fix incorrect population of default uart pads), the kernel does not
return from static suspend when off-mode is enabled upon an
On Tuesday 08 May 2012 02:39 PM, Tero Kristo wrote:
On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
Hi Tony,
On 5/7/2012 7:37 PM, Tony Lindgren wrote:
* R, Sricharanr.sricha...@ti.com [120506 20:39]:
+config MACH_OMAP5_SEVM
+ bool OMAP5 sevm Board
+ depends on ARCH_OMAP5
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
No need for it here
Hi Juan,
On Tue, May 8, 2012 at 1:09 AM, Gutierrez, Juan jgutier...@ti.com wrote:
Startup it is now only used to enable pm runtime of the whole mbox module.
Btw I really doubt we need to do that in a machine-specific handler,
or whether we really need this startup/shutdown abstraction at all.
On Tue, 2012-05-08 at 14:45 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:39 PM, Tero Kristo wrote:
On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero
An overlay manager's timings (the manager size, and blanking parameters if an
LCD manager) are DISPC shadow registers, and they should hence follow the
correct programming model.
This set makes the timings an extra_info parameter in manager's private data .
The interface drivers now apply the
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Signed-off-by: Archit Taneja arc...@ti.com
---
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by
On Mon, May 07, 2012 at 10:51:53, J, KEERTHY wrote:
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
AnilKumar, Chimata anilku...@ti.com writes:
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
Hi Mark,
Mark Brown broo...@opensource.wolfsonmicro.com writes:
On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a need
to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need
to
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Hi Kevin Jon,
On 5/8/2012 1:28 AM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Kevin,
On 05/07/2012 12:15 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Will,
On 04/26/2012 01:07 PM, Will Deacon wrote:
On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will
On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now
Hi Benoit,
On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Kevin Jon,
On 5/8/2012 1:28 AM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Kevin,
On 05/07/2012 12:15 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Will,
On
Hi Tony,
On Tue, May 01, 2012 at 17:49:03, Mohammed, Afzal wrote:
GPMC driver conversion patch series. Some peripherals has GPMC helper
functions, these has been modified to cater to the needs of GPMC
driver. All the boards using GPMC has been adapted to use the new
GPMC driver.
GPMC HWMOD
Cleanups for the legacy omap mmc driver to remove clutter and
make it well behaved as module.
Venkatraman S (3):
mmc: omap: convert to per instance workqueue
mmc: omap: make it behave well as module
mmc: omap: convert to module_platform_driver
drivers/mmc/host/omap.c | 48
Currently, a global mmc_omap_wq is created for all instances of
omap hosts, which can lead to races and doesn't lend itself to
unload the module cleanly.
Instead, create per instance workqueue and remove the common workqueue.
Signed-off-by: Venkatraman S svenk...@ti.com
---
Use proper __devinit and __devexit annotation for driver
functions. Instantiate the probe function for driver_ops
instead of a probe in the register function.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c |9 +
1 files changed, 5 insertions(+), 4
Get rid of boilerplate code by using module_platform_driver macro,
no functional changes.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap.c
On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote:
On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
Checking the validity of all the settings is a bit tricky, but currently
I think, as a rule of thumb, we should accept any settings when things
are disabled. So, until the
On Mon, 2012-05-07 at 16:51 +0530, Archit Taneja wrote:
The first patch in this series is a follow up on the previously posted series
'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
required for HDMI and DPI interfaces to work properly, it ensures manager
timings are
On Mon, 2012-05-07 at 18:50 +0530, Archit Taneja wrote:
The HDMI CORE registers are dumped incorrectly due to incorrect register
offset
calculations. They are also dumped in a random order, with some of the
registers
repeated. This series fixes these issues.
The patches apply over:
Hi,
On Tuesday 08 May 2012 05:34 PM, Tomi Valkeinen wrote:
On Mon, 2012-05-07 at 18:50 +0530, Archit Taneja wrote:
The HDMI CORE registers are dumped incorrectly due to incorrect register offset
calculations. They are also dumped in a random order, with some of the registers
repeated. This
On Tuesday 08 May 2012 05:28 PM, Tomi Valkeinen wrote:
On Mon, 2012-05-07 at 16:51 +0530, Archit Taneja wrote:
The first patch in this series is a follow up on the previously posted series
'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is
required for HDMI and DPI
On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote:
On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote:
On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
Checking the validity of all the settings is a bit tricky, but currently
I think, as a rule of thumb, we should accept any
Salut Jean,
On 5/8/2012 1:23 PM, Jean Pihet wrote:
Hi Benoit,
On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Kevin Jon,
On 5/8/2012 1:28 AM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.comwrites:
Hi Kevin,
On 05/07/2012 12:15 PM, Kevin Hilman wrote:
On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote:
From: R Sricharan r.sricha...@ti.com
ARM decompressor code setups entire 4GB address space pages.
Out of the 4GB, about 256MB are setup with normal memory attributes
for needed DRAM and the rest of the address space as
Hello,
On Thu, May 03, 2012 at 08:26:18AM +0100, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
On Tuesday 08 May 2012 06:17 PM, Will Deacon wrote:
Hello,
On Thu, May 03, 2012 at 08:26:18AM +0100, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi Paul,
This is patch 13/39 14/39 of v4 OMAP GPMC driver conversion
series modified and squashed into one.
Regards
Afzal
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 ++
Hi Paul,
On Mon, May 07, 2012 at 16:42:16, Mohammed, Afzal wrote:
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk
On Tue, May 8, 2012 at 2:37 PM, Cousson, Benoit b-cous...@ti.com wrote:
Salut Jean,
On 5/8/2012 1:23 PM, Jean Pihet wrote:
Hi Benoit,
On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Kevin Jon,
On 5/8/2012 1:28 AM, Kevin Hilman wrote:
Jon
On Tue, May 08, 2012 at 04:19:46PM +0600, joseph daniel wrote:
Hi all,
I am getting the following warnings while compiling the 3.4-rc6 kernel
with the .config attached.
warning: (MOUSE_APPLETOUCH MOUSE_BCM5974 MOUSE_SYNAPTICS_USB
JOYSTICK_XPAD TABLET_USB_ACECAD TABLET_USB_AIPTEK
On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote:
Hi Kevin, Paul,
On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote:
Ok, I can replicate it now. It seems to be somehow PM related. I
normally have USB gadget
I'm attempting to build a linux kernel (3.4-rc4) for the AM/DM37x Evaluation
Module. I built my own cross tools using CrossTools-ng (gcc4.4.3, glibc2.9,
binutils2.21.1a). I am using the bootloader that came on the board and booting
from the mmc card. Below is the output I get at startup.
Paul Walmsley p...@pwsan.com writes:
On Thu, 19 Apr 2012, Igor Grinberg wrote:
IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
Just tested this on a 3517EVM and the same problem is there too.
Does adding nohlt on the cmdline make a difference?
The AM35x has
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
SX1 board requirese i2c, so select it in Kconfig, otherwise I have the
following build error:
arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_write_byte':
arch/arm/mach-omap1/board-sx1.c:58:2: error: implicit declaration of function
Jean Pihet jean.pi...@newoldbits.com writes:
[...]
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO
and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid
next
power state
On Tue, May 8, 2012 at 6:11 PM, Catalin Marinas catalin.mari...@arm.com wrote:
On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote:
From: R Sricharan r.sricha...@ti.com
ARM decompressor code setups entire 4GB address space pages.
Out of the 4GB, about 256MB are setup with normal
On 5/8/2012 4:00 PM, Kevin Hilman wrote:
Jean Pihetjean.pi...@newoldbits.com writes:
[...]
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO
and SW_WAKEUP. AFAIK, the issue with that EMU CD is
On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan r.sricha...@ti.com
Date: Mon, 7 May 2012 15:11:58 +0530
Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address
space.
With addition to TI81XX, AM33XX family of devices, the number
of interrupts supported has increased to 128, compared to 96.
The current implementation for irq handling is hardcoded to use
96 interrupts (with 3 register-sets to handle), this patch cleanups
the code, to increase maximum number of
On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote:
On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan r.sricha...@ti.com
Date: Mon, 7 May 2012 15:11:58 +0530
Subject: [PATCH] ARM:
On Tue, May 08, 2012 at 03:20:43PM +0100, Santosh Shilimkar wrote:
On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote:
On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote:
From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001
From: R Sricharan
In current implementation, some places we are still using
ARCH_OMAPx config option, making it difficult to add new devices;
for example, while adding am33xx device support I came across multiple
instances where I had to patch the existing code to make it work for
am33xx.
This patch tries to
All OMAP2PLUS based devices, builds omap-device.o target;
so just add one entry so that there is no need to patch this file
for any future OMAP2+ devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by Makefile
rule.
Signed-off-by:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_SDRC to handle sdrc,
so that we can reuse same
This patch cleans up dpll_data structure, making structure
fields definition based on feature availability for given SoC,
managed using Kconfig rules.
SOC_HAS_DPLL_IDLE: idle state
SOC_HAS_DPLL_RECAL: recalibration capability
SOC_HAS_DPLL_DCO_SEL: dco selection
SOC_HAS_DPLL_SDDIV: sigma-delta div
Hi Afzal,
On 05/08/2012 01:18 AM, Mohammed, Afzal wrote:
Hi Jon,
On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote:
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+
Hi Afzal,
On 05/08/2012 01:24 AM, Mohammed, Afzal wrote:
Hi Jon,
On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote:
Clk_prd is a platform data passed to the driver, so platform code
updates it, where else can it be done ?
The point is that you can pass what ever you like. You do not
Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating
On Mon, 7 May 2012, Mohammed, Afzal wrote:
On Sun, May 06, 2012 at 07:34:07, Paul Walmsley wrote:
(attribution lost)
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+
Hi,
On Tue, 8 May 2012, Afzal Mohammed wrote:
This is patch 13/39 14/39 of v4 OMAP GPMC driver conversion
series modified and squashed into one.
...
+ /* HWMOD_INIT_NO_RESET can be removed once kernel is updated
+ * to configure GPMC for all peripherals, right now many
+ *
Hi
On Tue, 8 May 2012, Mohammed, Afzal wrote:
If HWMOD_NO_INIT_RESET is not present, it would break GPMC on
many of the existing boards.
IMHO, that should also be fixed as part of your changes, to remove what
seems to be an unnecessary bootloader dependency.
* Paul Walmsley p...@pwsan.com [120507 22:35]:
On Mon, 7 May 2012, Tony Lindgren wrote:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html
I see. Yeah, the problem is that it's hard to figure out which SoCs
should go into SOC_OMAP3PLUS. AM33xx? TI81xx? etc. Some
* Hiremath, Vaibhav hvaib...@ti.com [120507 22:52]:
On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120507 12:22]:
* Paul Walmsley p...@pwsan.com [120507 12:11]:
Hi,
On Fri, 4 May 2012, Tony Lindgren wrote:
How about we add
Hi Kevin,
thanks for the suggestion,
On Tue, 8 May 2012, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
On Thu, 19 Apr 2012, Igor Grinberg wrote:
IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken?
Just tested this on a 3517EVM and the same problem
* Cousson, Benoit b-cous...@ti.com [120508 02:23]:
Hi Tony,
On 5/7/2012 7:37 PM, Tony Lindgren wrote:
* R, Sricharanr.sricha...@ti.com [120506 20:39]:
+config MACH_OMAP5_SEVM
+ bool OMAP5 sevm Board
+ depends on ARCH_OMAP5
+
config OMAP3_EMU
bool OMAP3 debugging
* Santosh Shilimkar santosh.shilim...@ti.com [120508 00:27]:
On Tuesday 08 May 2012 03:56 AM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120507 02:53]:
Tony,
On Thursday 03 May 2012 12:56 PM, R Sricharan wrote:
The series adds minimal OMAP5 support.
OMAP5430
* Tomi Valkeinen tomi.valkei...@ti.com [120508 01:48]:
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen tomi.valkei...@ti.com [120503 07:01]:
Hi,
I started cleaning up and restructuring omapdss for device tree, and
here's the
first set of
On Tue, 8 May 2012, Raja, Govindraj wrote:
On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley p...@pwsan.com wrote:
The same is discussed in this thread as in here:
http://www.spinics.net/lists/linux-omap/msg68659.html
OK.
Could you please fix this? We probably aren't too far from the
* Vaibhav Hiremath hvaib...@ti.com [120508 08:10]:
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,12 +20,16 @@ config ARCH_OMAP2PLUS_TYPICAL
help
Compile a kernel suitable for booting most boards
+config SOC_HAS_SDRC
+ bool SDRAM Controller
* Vaibhav Hiremath hvaib...@ti.com [120508 08:10]:
This patch cleans up dpll_data structure, making structure
fields definition based on feature availability for given SoC,
managed using Kconfig rules.
SOC_HAS_DPLL_IDLE: idle state
SOC_HAS_DPLL_RECAL: recalibration capability
Cousson, Benoit b-cous...@ti.com writes:
On 5/8/2012 4:00 PM, Kevin Hilman wrote:
Jean Pihetjean.pi...@newoldbits.com writes:
[...]
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO
and
Paul Walmsley p...@pwsan.com writes:
Hi Kevin,
thanks for the suggestion,
On Tue, 8 May 2012, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
On Thu, 19 Apr 2012, Igor Grinberg wrote:
IMO this can be seen on any AM35xx based board with EMAC, or am I
mistaken?
Just
1 - 100 of 195 matches
Mail list logo
