On Wed, Mar 14, 2012 at 20:22:37, Laurent Pinchart wrote:
Hi Vaibhav,
Thanks for the patch.
On Friday 09 March 2012 17:44:03 Vaibhav Hiremath wrote:
Patch fixes below build warning and section miss-match warning
from omap_vout driver -
You should probably not refer to patch below in
On Wed, Mar 14, 2012 at 21:00:25, Laurent Pinchart wrote:
Hi Vaibhav,
On Friday 09 March 2012 17:41:57 Vaibhav Hiremath wrote:
When rotation is enabled and driver is configured in USERPTR
buffer exchange mechanism, in specific use-case driver reports
an error,
DMA transaction error
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
Thank you both for missing my point.
#define OMAP24XX_DMA_SHA1MD5_RX 13 /* S_DMA_12 */
#define OMAP34XX_DMA_SHA2MD5_RX 13 /* S_DMA_12 */
#define OMAP242X_DMA_EXT_DMAREQ214 /* S_DMA_13 */
On Thursday 15 March 2012, Nicolas Ferre wrote:
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
+/**
+ * of_dma_to_resource - Decode a node's DMA and
Von: Kevin Hilman [mailto:khil...@ti.com]
Menon, Nishanth n...@ti.com writes:
On Wed, Mar 14, 2012 at 16:15, Kevin Hilman khil...@ti.com wrote:
Maximilian Schwerin m...@tigris.de writes:
From: Steve Sakoman st...@sakoman.com
Don't try to add IVA OPPs for OMAP3 versions not
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using set_overlay_info()
when the physical address for the overlay is still not configured. This happens
in omap_vout_probe()
On Fri, 2012-03-16 at 01:04 +0200, Ville Syrjälä wrote:
On Thu, Mar 15, 2012 at 05:18:52PM +0530, Chandrabhanu Mahapatra wrote:
In OMAP3 DISPC video overlays suffer from some undocumented horizontal
position
and timing related limitations leading to SYNCLOST errors. Whenever the
image
On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Addng the offset to platform_device resource structure
increments
On Fri, Mar 16, 2012 at 04:02:16PM +0530, S, Venkatraman wrote:
On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100
On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote:
On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
Well, as I said, it's not an issue for me and from my side it can be
improved later.
yeah, when CMA is
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info()
when the physical address for the
On 3/16/2012 11:03 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
We do have
On Friday 16 March 2012, Cousson, Benoit wrote:
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
ISA dma api or a platform specific variant
Hi,
I have trouble getting the Ethernet port on a Gumstix Overo with Tobi
expansion board to work with current kernel versions. With the latest
commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa),
the output from loading the smsc911x driver is as follows:
du14:~# modprobe
On Fri, Mar 16, 2012 at 3:58 AM, Ville Syrjälä syrj...@sci.fi wrote:
On Thu, Mar 15, 2012 at 05:18:28PM +0530, Chandrabhanu Mahapatra wrote:
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times,
and
up to 2 times in OMAP2. However, with predecimation, the image can be
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Reference: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git omap/dt
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/board-h2.c|8
arch/arm/mach-omap1/board-h3.c|8
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQi
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
Hello.
On 16-03-2012 3:07, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Currently, pm34xx.c has a mix of printk() and pr_*() statements
so replace the printk() statements with the equivalent pr_*()
statements.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
If transceiver is attached to a MMC host of ES2.1 OMAP, it seems
2.1.1.128 erratum doesn't apply and there is no data corruption,
probably because of different signal timing. The workaround for this
erratum disables multiblock reads, which causes dramatic loss of
performance (over 75% slower), so
On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
On Friday 16 March 2012, Cousson, Benoit wrote:
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either
On Thu, Mar 15, 2012 at 8:42 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
On Thursday 15 March 2012 08:03 PM, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
call context save api after enabling runtime pm
to make sure register access in context save api
If I am not mistaken the api
On 03/16/2012 02:28 PM, Cousson, Benoit :
On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
On Friday 16 March 2012, Cousson, Benoit wrote:
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the
Chris,
Here are a group of fixes posted by Felipe and Balaji for the
OMAP hsmmc driver in the past few days.
I've rebased them to the lastest mmc-next and posted them
here again. These have also been tested on OMAP4 development platform.
Please feel to apply directly or pull if that's
From: Balaji T K balaj...@ti.com
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed,
From: Balaji T K balaj...@ti.com
Add Dual data rate support for omap_hsmmc
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c
From: Balaji T K balaj...@ti.com
pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host-base) follows immediately.
Reported-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Cc: stable
From: Balaji T K balaj...@ti.com
call context save api after enabling runtime pm
to make sure register access in context save api happens with clk enabled.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Cc: stable sta...@vger.kernel.org
---
From: Felipe Balbi ba...@ti.com
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S
From: Felipe Balbi ba...@ti.com
if we put probe() on __init section, that will never
work for multiple module insertions/removals.
In order to make it work properly, move probe to
__devinit section and use platform_driver_register()
instead of platform_driver_probe().
Signed-off-by: Felipe
From: Balaji T K balaj...@ti.com
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Addng the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC command fails on re-insertion as module due to incorrect register base.
Fix this by
From: Felipe Balbi ba...@ti.com
this will delete some boilerplate code, no functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff
Hi Tarun,
On 3/16/2012 1:24 PM, Tarun Kanti DebBarma wrote:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Thanks for the board
On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
On Fri, Mar 16, 2012 at 7:16 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Tarun,
On 3/16/2012 1:24 PM, Tarun Kanti DebBarma wrote:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with
There is no more need to have saved_wakeup because bank-context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{}
as we already have them as part of bank-context now. Also, remove un-used
variable from gpio_irq_handler. Also, the suspend/resume callbacks are
removed bacause they are not needed any more.
The fixes include correction
This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.
Signed-off-by: Tarun Kanti DebBarma
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone explain to me this:
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
commit 672e302e3c (ARM: OMAP: use edge/level handlers from generic IRQ
framework) removed retrigger support in favor of using generic IRQ
framework. This patch cleans up some unused remnants of that removal.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask()
which writes to dataout register and the dataout context must be saved.
It is missing in the first function, _set_gpio_dataout_reg(). Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh
The GPIO trigger parameter is of type unsigned.
enum {
IRQ_TYPE_NONE = 0x,
IRQ_TYPE_EDGE_RISING= 0x0001,
IRQ_TYPE_EDGE_FALLING = 0x0002,
IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_EDGE_RISING),
Since we already have bank-context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
_gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets
In omap_gpio_runtime_suspend/resume() the context save/restore should
be independent of bank-enabled_non_wakeup_gpios. This was preventing
context restore of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs-irqenable
instead of overwriting it with
There are two ways through which wakeup_en register can be programmed
using gpiolib APIs as shown below. It is seen that in the second case
in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated
correctly, its value is not programmed in wakeup_en register. Fix this.
On Fri, Mar 16, 2012 at 4:34 AM, Ville Syrjälä syrj...@sci.fi wrote:
On Thu, Mar 15, 2012 at 05:18:52PM +0530, Chandrabhanu Mahapatra wrote:
In OMAP3 DISPC video overlays suffer from some undocumented horizontal
position
and timing related limitations leading to SYNCLOST errors. Whenever the
2012/3/16 Tomi Valkeinen tomi.valkei...@ti.com:
On Fri, 2012-03-16 at 01:04 +0200, Ville Syrjälä wrote:
On Thu, Mar 15, 2012 at 05:18:52PM +0530, Chandrabhanu Mahapatra wrote:
In OMAP3 DISPC video overlays suffer from some undocumented horizontal
position
and timing related limitations
On 10:26-20120316, Maximilian Schwerin wrote:
[...]
+
+ if ((strcmp(opp_def-hwmod_name,iva) ==
0) !omap3_has_iva())
+ continue;
+
oh = omap_hwmod_lookup(opp_def-hwmod_name);
if (!oh || !oh-od
The series consists of two patches.
Patch1 of the series makes omap4 keypad independent of the
architecture by moving platform_data to linux/platform_data
Patch2 add support for omap5 onchip keypad.
Tested on omap4430sdp using 3.3-rc6.
Tested on omap5 board using 3.1 custom kernel.
Felipe
From: Felipe Balbi ba...@ti.com
This patch allows us to drop the OMAP depencendy
from the OMAP4 keypad driver.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|1 +
arch/arm/mach-omap2/devices.c
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
On Fri, Mar 16, 2012 at 7:21 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K
Hi Ohad,
Ohad Ben-Cohen wrote:
The resource table is an array of 'struct fw_resource' members, where
each resource entry is expressed as a single member of that array.
This approach got us this far, but it has a few drawbacks:
1. Different resource entries end up overloading the same members
Hi Tony,
On Thu, Mar 15, 2012 at 6:14 PM, Tony Lindgren t...@atomide.com wrote:
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com [120315 09:47]:
From: Jean Pihet j-pi...@ti.com
Move the platform specific macros from the smartreflex header file
(arch/arm/mach-omap2/smartreflex.h) in a
subsystem
before attempting to add IVA OPP
On 10:26-20120316, Maximilian Schwerin wrote:
[...]
+
+ if ((strcmp(opp_def-hwmod_name,iva) ==
0) !omap3_has_iva())
+ continue;
+
oh = omap_hwmod_lookup(opp_def-hwmod_name
On Fri, Mar 16, 2012 at 10:47, Maximilian Schwerin
maximilian.schwe...@tigris.de wrote:
sorry my fault! This was not what I was thinking of as generic. Works as
expected!
Can i take it as an acked-by?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe
On Fri, Mar 16, 2012 at 7:20 AM, Nishanth Menon n...@ti.com wrote:
From 5275d09c9f1a16c8f0814745e1c313c6cca049f6 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Fri, 16 Mar 2012 09:13:24 -0500
Subject: [PATCH] OMAP2+: OPP: allow OPP enumeration to continue if device is
not
Hi Keshava,
On Thu, Mar 08, 2012 at 08:30:21PM +0530, Munegowda, Keshava wrote:
On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi
On platforms such as OMAP3, certain variants may not have IVA, SGX
or some specific component. We currently have a check to aid fixing
wrong population of OPP entries for issues such as typos. This however
causes a conflict with valid requirement where the SoC variant does
not actually have the
Hi Keshava,
On Mon, Mar 05, 2012 at 08:13:45PM +0530, Munegowda, Keshava wrote:
On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda keshava_mgo...@ti.com
wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The TLL configuration is removed from the UHH driver and implemented as
a
On Friday, March 16, 2012 07:56:28 PM Sourav Poddar wrote:
From: Felipe Balbi ba...@ti.com
This patch allows us to drop the OMAP depencendy
from the OMAP4 keypad driver.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
On Fri, Mar 16, 2012 at 04:42:16PM +0400, Sergei Shtylyov wrote:
Hello.
On 16-03-2012 3:07, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
@@ -463,7 +462,7 @@ restore:
list_for_each_entry(pwrst,pwrst_list, node) {
state =
Hi,
* Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]:
Hi,
I have trouble getting the Ethernet port on a Gumstix Overo with Tobi
expansion board to work with current kernel versions. With the latest
commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa),
the output
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers.
Right now this is used by the TI EMIF SDRAM controller
driver.
Hi Greg,
On Friday 16 March 2012 12:32 AM, Greg KH wrote:
On Thu, Mar 15, 2012 at 11:47:31PM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
Hi,
On Fri, Mar 16, 2012 at 09:36:19AM -0700, Dmitry Torokhov wrote:
On Friday, March 16, 2012 07:56:28 PM Sourav Poddar wrote:
From: Felipe Balbi ba...@ti.com
This patch allows us to drop the OMAP depencendy
from the OMAP4 keypad driver.
Signed-off-by: Felipe Balbi ba...@ti.com
On Sat, Mar 17, 2012 at 02:28:47AM +0530, Aneesh V wrote:
Hi Greg,
On Friday 16 March 2012 12:32 AM, Greg KH wrote:
On Thu, Mar 15, 2012 at 11:47:31PM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of
On Sat, Mar 17, 2012 at 02:20:07AM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device
On Saturday 17 March 2012 03:13 AM, Greg KH wrote:
On Sat, Mar 17, 2012 at 02:20:07AM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data
Add a driver for the EMIF SDRAM controller used in TI SoCs
EMIF is an SDRAM controller that supports, based on its revision,
one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
for LPDDR2.
The driver supports the following features:
- Calculates the DDR AC timing parameters to be
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers.
Right now this is used by the TI EMIF SDRAM controller
driver.
Add register offsets and bit field definitions
for EMIF module in TI SoCs
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v1:
- Improved commit log
- Corrected copyright year
- Changed file name in order to add other defines
needed by the driver in the same file in
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage change handling
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of an LPDDR2
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v2:
- Corrected the frequency value shown in
register cache dump
-
On Saturday 17 March 2012 03:03 AM, Greg KH wrote:
On Sat, Mar 17, 2012 at 02:28:47AM +0530, Aneesh V wrote:
Hi Greg,
[...]
I have fixed these comments and pushed my latest patches at:
git://github.com/aneeshv/linux.git
branch: emif-upstream-v4
Sorry, but I don't take git pulls for stuff
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Cc: Greg KH g...@kroah.com
Signed-off-by:
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Cc: Greg KH g...@kroah.com
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
On Friday 16 March 2012, Arnd Bergmann wrote:
Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so
that platform ports can gather speed? Several people are waiting for a
somewhat stable version before starting their ports.
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
Date: Fri, 16 Mar 2012 16:06:30 -0600
Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API
is not
Sometime during the last week, the OMAP4430SDP stopped booting - it now
stops with no kernel messages output:
http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=69
The previously booted version:
http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=57
worked fine
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
No, please don't do this. This effectively marks the architectures using
the
Hi,
Adding Tomi to this thread.
* Russell King - ARM Linux li...@arm.linux.org.uk [120316 16:14]:
Sometime during the last week, the OMAP4430SDP stopped booting - it now
stops with no kernel messages output:
http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=69
The
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
No, please don't do this. This
On 03/16/2012 05:54 PM, Rob Herring wrote:
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
On Fri, Mar 16, 2012 at 11:08:43PM +0200, Felipe Balbi wrote:
Hi,
On Fri, Mar 16, 2012 at 09:36:19AM -0700, Dmitry Torokhov wrote:
On Friday, March 16, 2012 07:56:28 PM Sourav Poddar wrote:
From: Felipe Balbi ba...@ti.com
This patch allows us to drop the OMAP depencendy
from the
Hi Sourav,
On Fri, Mar 16, 2012 at 07:56:29PM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Signed-off-by:
91 matches
Mail list logo
