We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple
save_state handling in omap_sram_idle() and just use 2 save_state
definitions
save_state = 1, all logic and memory lost, MPU hits OFF
save_state = 0, nothing lost, MPU hits CSWR or shallower state
Signed-off-by: Rajendra Nayak
pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency
operations done within cpuidle to do Powerdomain level book-keeping to know
what state transitions for different Powerdomains have been triggered.
This is also useful to do a restore-on-demand in some cases when we know
With .power_on/.power_down hooks now available within the powerdomain
framework, its possible to clean a lot of mpu/core power_on/power_down
related code within omap_sram_idle into respective callbacks for these
powerdomains.
This should atleast also optimise the core domain context save
in
With usecounting added to Powerdomains, its now possible to track Powerdomain
transitions, including when a Powerdomain is turned on and turned down.
Add support for hooking up callbacks for such events, which can be used to
do things like context save/restore etc. which today is mostly stuffed
Hi,
Here are some CPUidle/Suspend cleanup patches done by adding
some more functionality in the OMAP Powerdomain framework.
They mostly cleanup OMAP3 but the same ideas can be used/
applied for OMAP4 and beyond.
The series is based off Teros' series [1] to add usecounting
support within the OMAP
Add device tree data for tps65910 regulator by adding all the
consumers necessary for AM335X-EVM. The data will be map to a
regulator constraints which is required for regulator set_voltage
and get_voltage calls.
All tps65910 PMIC regulator constraints are placed in a seperate
device tree include
Adds tps65910 regulator device tree data, which adds I2C node
with I2C frequency and tps65910 PMIC I2C slave address.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git
This patch series add AM33XX regulators (tps65910/tps65217) device
tree data to am335x-evm and am335x-bone dts files. These patches
are based on Tony L devel-dt tree and tested on AM335x EVM and
Bone devices.
Resending patch 1 2 to group all the regulator DT data files.
AnilKumar Ch (4):
ARM:
Add device tree data for tps65217 regulator by adding all the consumers
necessary for AM335X-BeagleBone. The data will be map to a regulator
constraints which is required for regulator set_voltage and get_voltage
calls.
All tps65217 PMIC regulator constraints are placed in a seperate device
tree
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak rna...@ti.com wrote:
We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple
save_state handling in omap_sram_idle() and just use 2 save_state
definitions
With current mainline code, this is indeed true.
save_state = 1, all logic
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak rna...@ti.com wrote:
pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency
operations done within cpuidle to do Powerdomain level book-keeping to know
what state transitions for different Powerdomains have been triggered.
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak rna...@ti.com wrote:
With usecounting added to Powerdomains, its now possible to track Powerdomain
transitions, including when a Powerdomain is turned on and turned down.
Add support for hooking up callbacks for such events, which can be used to
On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 19 Jul 2012, S, Venkatraman wrote:
From this, one can only infer that the card is not responding at all,
and all attempts
are returning with a timeout (CTO=Command Time Out).
Looks to me like the card is responding
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayak rna...@ti.com wrote:
With .power_on/.power_down hooks now available within the powerdomain
framework, its possible to clean a lot of mpu/core power_on/power_down
related code within omap_sram_idle into respective callbacks for these
Adds pinctrl support to AM33XX family of devices. These patches were
tested on AM335x-Bone and AM335x-EVM
Changes from v1:
- Rebased the patches based on latest pinctrl-single driver
AnilKumar Ch (2):
arm/dts: Add AM33XX basic pinctrl support
arm/dts: Configure pinmuxs for user leds
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git
Add basic pinctrl support for AM33XX family of devices by adding DT
data to am33xx dtsi file. These patches are based on pinctrl-single
driver and tested on am335x-evm am335x-bone devices.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 files
Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji:
On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 19 Jul 2012, S, Venkatraman wrote:
From this, one can only infer that the card is not responding at all,
and all attempts
are returning with a timeout
Am 20.07.2012 09:39, schrieb Yegor Yefremov:
Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji:
On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 19 Jul 2012, S, Venkatraman wrote:
From this, one can only infer that the card is not responding at all,
and all
On Fri, Jul 20, 2012 at 4:25 AM, Greg KH gre...@linuxfoundation.org wrote:
On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote:
On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote:
This commit
On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayakrna...@ti.com wrote:
pwrdm_pre_transition()/pwrdm_post_transition() have always been high latency
operations done within cpuidle to do Powerdomain level book-keeping to know
what state
Hi,
On Tuesday 17 July 2012 09:57 PM, Jassi Brar wrote:
[CC'ing OMAPDSS matinainer]
On 17 July 2012 19:31, Raphael Assenat r...@8d.com wrote:
Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
Display panels are board specific and there is no limit to the number
of panels
Hi Kishon,
On Thu, Jul 19, 2012 at 5:04 PM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote:
Hi,
On Fri, Jul 13, 2012 at 8:27 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in
On Thu, 2012-07-19 at 17:30 -0600, Paul Walmsley wrote:
Hi
On Thu, 19 Jul 2012, Tero Kristo wrote:
Subject: [PATCHv7 07/12] ARM: OMAP4: PM: put all domains to OSWR during
suspend
Currently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper
state that saves more power,
On Friday 20 July 2012, Vinod Koul wrote:
Required property:
dmas: list of one or more dma specifiers, each consisting of
- phandle pointing to dma controller node
- flags word, a bit map that can hold these flags
* 0x0001 channel can be used for transfer from
On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayakrna...@ti.com wrote:
pwrdm_pre_transition()/pwrdm_post_transition() have always been high
latency
operations done within
On Fri, 2012-07-20 at 11:34 +0530, Rajendra Nayak wrote:
Hi,
Here are some CPUidle/Suspend cleanup patches done by adding
some more functionality in the OMAP Powerdomain framework.
They mostly cleanup OMAP3 but the same ideas can be used/
applied for OMAP4 and beyond.
The series is based
On Friday 20 July 2012 02:29 PM, Tero Kristo wrote:
On Fri, 2012-07-20 at 11:34 +0530, Rajendra Nayak wrote:
Hi,
Here are some CPUidle/Suspend cleanup patches done by adding
some more functionality in the OMAP Powerdomain framework.
They mostly cleanup OMAP3 but the same ideas can be used/
Vinod Koul vinod.k...@linux.intel.com writes:
4. A dma controller requiring complex configuration:
dma: dmaengine@4800 {
compatible = foo,foo-sdma
reg = 0x4800 0x1000;
interrupts = 4;
#dma-cells = 6; /* phandle,
On Thu, 2012-07-19 at 17:21 -0600, Paul Walmsley wrote:
Hi
On Thu, 19 Jul 2012, Tero Kristo wrote:
On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
next powerstate during wakeup from OSWR / OFF, programming it to ON.
This will prevent successive entries to
On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren t...@atomide.com wrote:
* Shilimkar, Santosh santosh.shilim...@ti.com [120718 02:49]:
The patch simply make them depend on DMA_OMAP since DMA_OMAP
will select DMA_ENGINE automatically
This won't be true if the DMA selection are not done
at
framework so
build error is fixed if CONFIG_REGULATOR is not set.
drivers/built-in.o: In function `tps65217_probe':
tps65217.c:(.devinit.text+0x13e37): undefined reference
to `of_regulator_match'
This patch is based on linux-next (20120720) tree
Signed-off-by: AnilKumar Ch anilku...@ti.com
On Fri, 2012-07-20 at 08:39 +, Arnd Bergmann wrote:
On Friday 20 July 2012, Vinod Koul wrote:
Required property:
dmas: list of one or more dma specifiers, each consisting of
- phandle pointing to dma controller node
- flags word, a bit map that can hold these flags
On Fri, 2012-07-20 at 11:08 +0200, Robert Jarzmik wrote:
Vinod Koul vinod.k...@linux.intel.com writes:
4. A dma controller requiring complex configuration:
dma: dmaengine@4800 {
compatible = foo,foo-sdma
reg = 0x4800 0x1000;
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
Fix OMAP EHCI suspend/resume failure (i693) is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
On Fri, Jul 20, 2012 at 3:13 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
Fix OMAP EHCI suspend/resume failure (i693) is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the
On Fri, Jul 20, 2012 at 12:16:26PM +0530, AnilKumar Ch wrote:
+ vio_reg: regulator@1 {
+ reg = 1;
+ regulator-compatible = vio;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt =
On Fri, Jul 20, 2012 at 12:16:27PM +0530, AnilKumar Ch wrote:
+ dcdc1_reg: regulator@0 {
+ reg = 0;
+ regulator-compatible = dcdc1;
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt =
On Fri, Jul 20, 2012 at 2:58 PM, S, Venkatraman svenk...@ti.com wrote:
On Thu, Jul 19, 2012 at 5:02 PM, Tony Lindgren t...@atomide.com wrote:
* Shilimkar, Santosh santosh.shilim...@ti.com [120718 02:49]:
The patch simply make them depend on DMA_OMAP since DMA_OMAP
will select DMA_ENGINE
From: Arnd Bergmann a...@arndb.de
This warning recently appeared with omap2plus_defconfig:
WARNING: drivers/spi/built-in.o(.devinit.text+0x3c4): Section mismatch in
reference from the function omap2_mcspi_probe() to the function
.init.text:omap2_mcspi_master_setup()
The function __devinit
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in omap4-sdp dts file.
Tested on omap4430 sdp with 3.5-rc6 kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely
Hi Mark,
Thanks for the review.
On Fri, Jul 20, 2012 at 15:29:36, Mark Brown wrote:
On Fri, Jul 20, 2012 at 12:16:26PM +0530, AnilKumar Ch wrote:
+ vio_reg: regulator@1 {
+ reg = 1;
+ regulator-compatible = vio;
+
On Fri, Jul 20, 2012 at 11:27:36AM +, AnilKumar, Chimata wrote:
On Fri, Jul 20, 2012 at 15:29:36, Mark Brown wrote:
Every regulator here has a rather large voltage range specified with no
consumers added. Are you sure these voltage ranges make sense in your
design and you've not just
On Fri, Jul 20, 2012 at 2:21 PM, Tero Kristo t-kri...@ti.com wrote:
On Fri, 2012-07-20 at 13:38 +0530, Rajendra Nayak wrote:
On Friday 20 July 2012 12:55 PM, Shilimkar, Santosh wrote:
On Fri, Jul 20, 2012 at 11:34 AM, Rajendra Nayakrna...@ti.com
wrote:
On 20 July 2012 13:41, Archit Taneja a0393...@ti.com wrote:
On Tuesday 17 July 2012 09:57 PM, Jassi Brar wrote:
Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
Display panels are board specific and there is no limit to the number
of panels that could be connected to omap
On Fri, Jul 6, 2012 at 4:01 PM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
add FB_BLANK_NORMAL, FB_BLANK_VSYNC_SUSPEND and FB_BLANK_HSYNC_SUSPEND
modes (copy drivers/video/omap2/omapfb/omapfb-main.c implementation).
Otherwise X-server will complain
On Friday 20 July 2012 05:43 PM, Jassi Brar wrote:
On 20 July 2012 13:41, Archit Taneja a0393...@ti.com wrote:
On Tuesday 17 July 2012 09:57 PM, Jassi Brar wrote:
Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
Display panels are board specific and there is no limit to
+ Dave Miller and DaVinci list
Hi Mark,
On 7/20/2012 3:52 AM, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@ti.com
Signed-off-by: Mark A. Greer
On Thu, 2012-07-19 at 17:21 -0600, Paul Walmsley wrote:
Hi
On Thu, 19 Jul 2012, Tero Kristo wrote:
On OMAP4430 HS / EMU chips, ROM code appears to re-configure L4PER domain
next powerstate during wakeup from OSWR / OFF, programming it to ON.
This will prevent successive entries to
Instead of harcoding in the driver some of potentially countless sets
of parameters that could define a panel, have the board provide the
parameters to the panel driver.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
arch/arm/mach-omap2/board-2430sdp.c |4 +-
On 20 July 2012 18:14, Archit Taneja a0393...@ti.com wrote:
On Friday 20 July 2012 05:43 PM, Jassi Brar wrote:
It's true that currently omap platforms don't share the same panels, but
there is no stopping us to do that. We could remove the default panel and
attach a new one, even though we
On Fri, 20 Jul 2012, Rajendra Nayak wrote:
We do not support MPU OSWR on OMAP3. Get rid of the complex/multiple
save_state handling in omap_sram_idle() and just use 2 save_state
definitions
save_state = 1, all logic and memory lost, MPU hits OFF
save_state = 0, nothing lost, MPU hits CSWR
On Fri, Jul 20, 2012 at 11:23:01AM -0700, David Miller wrote:
From: Mark A. Greer mgr...@animalcreek.com
Date: Thu, 19 Jul 2012 15:22:57 -0700
From: Mark A. Greer mgr...@animalcreek.com
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori nsek...@ti.com
CC: Kevin
On Thu, Jul 19, 2012 at 04:59:06PM -0600, Paul Walmsley wrote:
+ Ilya
Hi Mark
Maybe try something like this on top of the patch that disables the
MPU DPLL autoidle?
I don't know what am35xx_enable_emac_int() is supposed to do. It seems
strange to clear the interrupt status bits when
On Fri, Jul 20, 2012 at 06:52:20PM +0530, Sekhar Nori wrote:
+ Dave Miller and DaVinci list
Hi Mark,
On 7/20/2012 3:52 AM, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori nsek...@ti.com
CC:
Hi Paul,
On 07/16/2012 01:38 PM, Paul Walmsley wrote:
Hi Jon,
On Mon, 16 Jul 2012, Jon Hunter wrote:
Yes I see that makes sense. However, patch #7 has already changed the
mapping of the flags. I had intended that patch #7 and #8 would be
applied together. However, I could see that patch
Hi Will,
On 07/13/2012 09:00 AM, Will Deacon wrote:
Jon,
[cutting out realms of context!]
On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
Another proposal I also thought of is re-working the flags to describe
the HW mode to be used when turning on the CLKDM, when the CLKDM is
From: Mark A. Greer mgr...@animalcreek.com
The '#include mach/mux.h' line in davinci_emac.c
causes a compile error because that header file
isn't found. It turns out that the #include isn't
needed because the driver isn't (and shoudn't be)
touching the mux anyway, so remove it.
CC: Sekhar Nori
From: Mark A. Greer mgr...@animalcreek.com
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
a) Sorry for the bad patch earlier.
b) Now applies on top of net-next.
c) This
Sigh, please ignore this series. I'll resend with [0/2].
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark A. Greer mgr...@animalcreek.com
This series fixes a compile error in, and adds pm_runtime support
to, the davinci_emac driver.
To test on a davinci platform, you will need another patch just
submitted to netdev:
http://marc.info/?l=linux-netdevm=134282758408187w=2
Mark A.
From: Mark A. Greer mgr...@animalcreek.com
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
a) Sorry for the bad patch earlier.
b) Now applies on top of net-next.
c) This
From: Mark A. Greer mgr...@animalcreek.com
The '#include mach/mux.h' line in davinci_emac.c
causes a compile error because that header file
isn't found. It turns out that the #include isn't
needed because the driver isn't (and shoudn't be)
touching the mux anyway, so remove it.
CC: Sekhar Nori
63 matches
Mail list logo
