Hola Omar,
On Wed, 14 Mar 2012, Ramirez Luna, Omar wrote:
If we reached here the reset lines will be asserted, and then the code
below touches sysc registers on a module under reset.
Do you know of any case where this would be a problem? Seems like it
would only affect IP blocks that have
On Thu, Mar 15, 2012 at 8:43 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman khil...@ti.com wrote:
Tarun,
Can you investigate an abort during boot on 3630/Zoom3?
Both Tony and I are seeing the abort below on 3630/Zoom3. I'm using
On Wed, 2012-03-14 at 18:33 +0200, Grazvydas Ignotas wrote:
On Wed, Mar 14, 2012 at 1:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
With this we can eliminate some duplicate code in panel drivers.
Also
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be
On Thursday 15 March 2012, Tony Lindgren wrote:
* Cousson, Benoit b-cous...@ti.com [120314 16:41]:
Hi Tony,
Here are the remaining DTS patches for 3.4.
On top of the previous pull request, I just added the MMC DTS since the
driver adaptation just got queued.
It will be still
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 actually merged, there are a few other things I'd
like to do to, incl converting omapfb over to use CMA and remove
omap_vram.. but I
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void *
On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA
* Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
[...]
+ i2c1: i2c@1 {
+ ...
+ dma-request = sdma 2 sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
This is slightly different from how the proposed pwm binding works
These fixes are a collection from other people which resolve various
issues found with the new kautobuilder. They're now a month old, and
as far as I can see, have not been merged into Linus' tree.
What's the status of them, and when are they going to be merged?
Thanks.
Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such as:
`omap_system_dma_remove' referenced in section `.data' of arch/arm/plat-omap/bui
lt-in.o: defined in discarded section `.devexit.text' of
During kernel init, we reset all IP blocks on the OMAP that we can,
even if there is no driver compiled for that IP block. Unlike most IP
blocks, the I2C block requires some extra programming for this to
work. This reset code is incorrectly omitted when the I2C driver is
deselected. In this
OMAPs cpufreq requires the frequency table support, but nothing ensures
that this is selected. This can result in configurations which fail to
build:
drivers/built-in.o:(.data+0x5238): undefined reference to
`cpufreq_freq_attr_scaling_available_freqs'
drivers/cpufreq/omap-cpufreq.c:88:
On Thu, Mar 15, 2012 at 10:28:45AM +, Russell King - ARM Linux wrote:
These fixes are a collection from other people which resolve various
issues found with the new kautobuilder. They're now a month old, and
as far as I can see, have not been merged into Linus' tree.
What's the status
Russell,
On Thu, Mar 15, 2012 at 11:30 AM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such as:
`omap_system_dma_remove' referenced in section `.data'
In case of AM33xx device, there is no consistency between
PWRSTCTRL PWRSTST register offsets in PRM space, for example -
PRM_XXX PWRSTCTRL PWRSTST
===
PRM_PER_MOD: 0x0C, 0x08
PRM_WKUP_MOD: 0x04, 0x08
PRM_MPU_MOD:
In case of AM33XX device, XXX_RSTST register offset is not
consistent across PRM modules/instances,
PRM_XXXRSTST
=
PRM_PER_MOD: 0x04
PRM_WKUP_MOD: 0x0C
PRM_MPU_MOD: NA
PRM_DEVICE_MOD:0x08
This means, we need to pass on XXX_RSTST register
After going round-n-round on how to add support for AM33XX family
of device into kernel, especially for PRM and CM support, we have
decided to handle it separately; as AM33XX-PRCM module is different
than OMAP3 and OMAP4 architecture.
The difference becomes very interesting/weird when it comes to
As far as PRM/CM/PRCM modules are concerned, AM33XX device is
different than OMAP3 and OMAP4 architectures; so we need to
handle it separately.
This patch adds support for, Powerdomain, Powerdomain data,
PRM api's required for AM33XX device.
And also, hooks up AM33XX powerdomain to existing OMAP
Hi everyone,
the following patch set directs to enable predecimation for DMA and VRFB
which consists of two pacthes.
The first patch is based on code written by Lajos Molnar la...@ti.com in
Android Kernel, which updates the code with predecimation logic thereby
increasing the downscaling ability
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 reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver
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 actually merged, there are a few other things I'd
like to
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
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
Hi,
On Thu, Mar 15, 2012 at 07:20:22PM +0530, T Krishnamoorthy, Balaji wrote:
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop
Grazvydas Ignotas nota...@gmail.com writes:
On Wed, Mar 14, 2012 at 7:22 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
[...]
Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables
It seems this one got messed up, it says default
On Thu, Mar 15, 2012 at 7:30 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 15, 2012 at 07:20:22PM +0530, T Krishnamoorthy, Balaji wrote:
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically
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
---
drivers/mmc/host/omap_hsmmc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git
From: Balaji T K balaj...@ti.com
Add Dual data rate support for omap_hsmmc
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b1e9be7..db8af43
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
---
drivers/mmc/host/omap_hsmmc.c |3 +--
1 file changed, 1
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
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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
---
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: Felipe Balbi ba...@ti.com
this will delete some boilerplate code, no functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
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
Hi,
On Thu, Mar 15, 2012 at 08:03:35PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
cmdtype = 0x3;
cmdreg = (cmd-opcode 24) | (resptype 16) | (cmdtype
On Thu, Mar 15, 2012 at 08:03:35PM +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
BTW, since patches are flowing through you now,
On Thu, Mar 15, 2012 at 08:03:38PM +0530, 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 happens with clk enabled.
Signed-off-by: Balaji T K balaj...@ti.com
Cc stable ?
--
balbi
On Thu, Mar 15, 2012 at 08:03:37PM +0530, Venkatraman S wrote:
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
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 the start address for every insmod operation.
MMC command fails
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 would
store the number of power state changes and accesses no registers.
Am
On Thu, Mar 15, 2012 at 1:25 AM, Paul Walmsley p...@pwsan.com wrote:
Hola Omar,
Hola :)
On Wed, 14 Mar 2012, Ramirez Luna, Omar wrote:
If we reached here the reset lines will be asserted, and then the code
below touches sysc registers on a module under reset.
Do you know of any case where
On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote:
Am 09.03.2012 18:22, schrieb George C. Huntington, III:
I would like to make the newer kernel (3.x) work with the AM3517EVM.
I have a 2.6.32 and a 2.6.33 that run well on the board, but the
recent kernels have kernel panics
Am 15.03.2012 16:43, schrieb Mark A. Greer:
On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote:
Am 09.03.2012 18:22, schrieb George C. Huntington, III:
I would like to make the newer kernel (3.x) work with the AM3517EVM.
I have a 2.6.32 and a 2.6.33 that run well on the board, but
I found a some minor issues when looking through pm34xx.c recently
so these patches try to address them. My apologies if they are already
fixed in another branch somewhere. Based on latest k.o. master branch.
Mark
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
It appears that the error paths were overlooked when the
omap3_pm_init() routine had the prcm chain handler code
added. Fix this by adding a goto target and reordering
the error handling code. Also fix how the irq argument
for free_irq() is determined.
CC: Tero Kristo t-kri...@ti.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
---
arch/arm/mach-omap2/pm34xx.c | 17 -
1 files changed, 8 insertions(+), 9
On 3/15/2012 10:22 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type
On Thu, Mar 15, 2012 at 04:52:40PM +0100, Yegor Yefremov wrote:
Am 15.03.2012 16:43, schrieb Mark A. Greer:
On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote:
Am 09.03.2012 18:22, schrieb George C. Huntington, III:
I would like to make the newer kernel (3.x) work with the
From: Jean Pihet j-pi...@ti.com
AVS is a power management technique which controls the operating
voltage of a device in order to optimize (i.e. reduce) its power
consumption. The voltage is adapted depending on static factors
(chip manufacturing process) and dynamic factors (temperature
depending
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 new header file in plat-omap
(arch/arm/plat-omap/include/plat/smartreflex.h).
This change makes the SmartReflex implementation ready for the move
to
From: Jean Pihet j-pi...@ti.com
Associate a name with each SmartReflex instance from the hwmod data,
rather than attempting to reuse the name of a voltage domain. The name
from hwmod better reflects the smartreflex integration in the system.
Also have the name passed to the drivers using pdata,
From: Jean Pihet j-pi...@ti.com
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure.
The SmartReflex driver should not be dependent on whether the host SoC
uses eFuses to store SmartReflex
From: Jean Pihet j-pi...@ti.com
Convert SmartReflex class functions to take a struct omap_sr *, rather than
a struct voltagedomain *. SmartReflex code should be driver code and not
tightly coupled to OMAP subarchitecture-specific structures.
Based on Paul's original code for the SmartReflex
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
arch/arm/mach-omap2/smartreflex.c |2 +-
2 files changed,
From: Jean Pihet j-pi...@ti.com
Add a Kconfig menu (POWER_AVS) and rename the Kconfig options
for the OMAP SmartReflex implementation:
CONFIG_OMAP_SMARTREFLEX renames to CONFIG_POWER_AVS_OMAP
CONFIG_OMAP_SMARTREFLEX_CLASS3 renames to CONFIG_POWER_AVS_OMAP_CLASS3
This change makes the
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index f12ebde..8d3e3c2 100644
---
From: Jean Pihet j-pi...@ti.com
Move some functions from mach-omap2/ dir to the plat/ dir.
The SmartReflex class driver is a user of the basic voltage domains
functions (enable, disable, reset).
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
On Thu, Mar 15, 2012 at 09:42:21AM -0700, Mark A. Greer wrote:
On Thu, Mar 15, 2012 at 04:52:40PM +0100, Yegor Yefremov wrote:
Am 15.03.2012 16:43, schrieb Mark A. Greer:
On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote:
Am 09.03.2012 18:22, schrieb George C. Huntington,
* Paul Walmsley p...@pwsan.com [120315 03:33]:
During kernel init, we reset all IP blocks on the OMAP that we can,
even if there is no driver compiled for that IP block. Unlike most IP
blocks, the I2C block requires some extra programming for this to
work. This reset code is incorrectly
* Jean Pihet jean.pi...@newoldbits.com [120315 04:09]:
Russell,
On Thu, Mar 15, 2012 at 11:30 AM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such
Hi Dave,
On 03/07/2012 12:30 PM, Dave Jones wrote:
On Wed, Mar 07, 2012 at 12:20:41PM -0800, Kevin Hilman wrote:
Dave,
Please pull the following OMAP CPUfreq driver changes for v3.4.
pulled, thanks.
Looks like these got pulled into your fixes branch, but I don't see them
in
Russell King rmk+ker...@arm.linux.org.uk writes:
OMAPs cpufreq requires the frequency table support, but nothing ensures
that this is selected. This can result in configurations which fail to
build:
drivers/built-in.o:(.data+0x5238): undefined reference to
* 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 new header file in plat-omap
(arch/arm/plat-omap/include/plat/smartreflex.h).
Hi Mark,
Mark A. Greer mgree...@gmail.com writes:
found a some minor issues when looking through pm34xx.c recently
so these patches try to address them. My apologies if they are already
fixed in another branch somewhere. Based on latest k.o. master branch.
Thanks for the fixes, they look
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not the case.
Fix this API by adding the
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:
On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman khil...@ti.com wrote:
Tarun,
Can you investigate an abort during boot on 3630/Zoom3?
Both Tony and I are seeing the abort below on 3630/Zoom3. I'm using
arm-soc/for-next and Tony is using
On Thu, Mar 15, 2012 at 10:27:57AM -0700, Kevin Hilman wrote:
Hi Mark,
Mark A. Greer mgree...@gmail.com writes:
found a some minor issues when looking through pm34xx.c recently
so these patches try to address them. My apologies if they are already
fixed in another branch somewhere.
* Paul Walmsley p...@pwsan.com [120315 10:35]:
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/video/omap2/displays/panel-acx565akm.c |7
On pandora we use .set_timings to alter refresh rate,
so add .check_timings/.set_timings functions.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
.../video/omap2/displays/panel-tpo-td043mtea1.c| 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git
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
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V
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
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
-
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:
clk_disable_unused is invoked when CONFIG_OMAP_RESET_CLOCKS=y.
Since clk_disable_unused is called as lateinitcall, there can
be more than a few workqueues executing off secondary CPU(s).
The current code does the following:
a) checks if clk is unused
b) holds lock
c) disables clk
d) unlocks
This series adds device tree support for TI EMIF SDRAM controller
driver. For this, a binding has been added for representing AC timing
parameters and other details of LPDDR2 memories.
This series depends v2 of my series for adding EMIF driver [1]
[1]
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Aneesh V ane...@ti.com
---
v1:
- Removed DDR3 only parameters
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Aneesh V ane...@ti.com
---
v2:
- Addressed comments from Grant Likely:
Converted occurences of __init to __init_or_module
Removed un-necessary instances of #ifdef
Hi
adding Todd to cc
On Thu, 15 Mar 2012, Nishanth Menon wrote:
clk_disable_unused is invoked when CONFIG_OMAP_RESET_CLOCKS=y.
Since clk_disable_unused is called as lateinitcall, there can
be more than a few workqueues executing off secondary CPU(s).
The current code does the following:
a)
On Thu, 15 Mar 2012, Kevin Hilman wrote:
Initially, this was intended as a cleanup because it was just dead code
removal, but since we missed v3.4, maybe we should pull out
ARM: OMAP: clock: cleanup CPUfreq leftovers and submit for 3.4-rc.
If it doesn't go upstream for the 3.4 merge window,
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.
This data will useful for memory controller device
On Thu, Mar 15, 2012 at 11:47:30PM +0530, Aneesh V wrote:
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
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.
This data
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interrupt ReQuest line and
a DMA Request line are really similar for the HW point of view at IP
level.
I'm not sure about that at all levels. Sure, at hardware level they're
the
On Friday 16 March 2012 12:34 AM, Greg KH wrote:
On Thu, Mar 15, 2012 at 11:47:30PM +0530, Aneesh V wrote:
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
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interrupt ReQuest line and
a DMA Request line are really similar for the HW point of view at IP
level.
I'm not sure
On Thursday, March 15, 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
After a clean-up of the interfaces the OMAP IP driver and class
support code is now a generic driver.
Move it to drivers/power/avs/.
The build is controlled by the following Kconfig options:
.
On 3/15/2012 9:41 PM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interrupt ReQuest line and
a DMA Request line are really similar for the HW point
On Thu, Mar 15, 2012 at 10:39:12PM +0100, Cousson, Benoit wrote:
On 3/15/2012 9:41 PM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interrupt
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 reduced
to 16 times by fetching only the necessary pixels in memory. Then
1 - 100 of 111 matches
Mail list logo
