From: Tero Kristo tero.kri...@nokia.com
Previously omap_sram_idle() did not know about the difference between ON and
INACTIVE states, which complicated the state handling in these cases. Now,
the following changes are done in the idle logic:
- Check for IO-chain arming is changed to reflect
From: Tero Kristo tero.kri...@nokia.com
Improvements compared to previous set:
- Fixed wrong pwrdm state check on IO chain arming on patch 2
- Improved changelog on patch 2 4
- Moved FCLK checks inside clockdomain code from powerdomain code in patch 5
- Some style changes on patch 6
Still, I
From: Tero Kristo tero.kri...@nokia.com
Currently only ON, RET and OFF are supported, and ON is arguably broken as it
allows the powerdomain to enter INACTIVE state unless idle is prevented.
Now, pwrdm code prevents idle if ON is selected, and also adds support for
INACTIVE. This simplifies the
From: Tero Kristo tero.kri...@nokia.com
Following hacks will be moved inside cpuidle in subsequent patch:
- CAM domain prevents idle completely
- PER should not go OFF if core remains active
This simplifies the design and allows cpuidle to keep better track of which
power states system will
From: Tero Kristo tero.kri...@nokia.com
pwrdm_can_idle(pwrdm) will check if the specified powerdomain can enter
idle. This is done by checking all clockdomains under the powerdomain
if they can idle also.
omap2_clkdm_can_idle(clkdm) will check if the specified clockdomain can
enter idle. This
From: Tero Kristo tero.kri...@nokia.com
New powerdomain code support for INACTIVE state removes the need to control
clockdomains directly from cpuidle. Also, cpuidle state definitions can now
directly support ON / INACTIVE simplifying the implementation.
Signed-off-by: Tero Kristo
From: Tero Kristo tero.kri...@nokia.com
Following checks are made (and their reasoning):
- If CAM domain is active, prevent idle completely
* CAM pwrdm does not have HW wakeup capability
- If PER is likely to remain on, prevent PER off
* Saves on unnecessary context save/restore
- If CORE
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
The workaround is:
For DPLL2 (DSP) select
Hi Paul,
Some patches in this series seem to be missing, specifically 5/8 and 6/8.
Can you please re-post?
regards,
Rajendra
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Thursday, December 03, 2009
On Fri, Dec 04, 2009 at 03:35:21PM +0530, Nayak, Rajendra wrote:
Some patches in this series seem to be missing, specifically 5/8 and 6/8.
Can you please re-post?
Probably because they're on the large side.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Hi Vishwanath,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP
Benoit
-Original Message-
From: Cousson, Benoit
Sent: Friday, December 04, 2009 3:46 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR
operation
Hi Vishwanath,
From:
Sergey Lapin wrote:
On Thu, Dec 3, 2009 at 9:29 AM, Dasgupta, Romit ro...@ti.com wrote:
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-
omap.c
index 449b6b6..f94df20 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++
From: Sripathy, Vishwanath
Benoit
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
From: Cousson, Benoit
Sent: Friday, December 04, 2009 3:46 PM
To: Sripathy, Vishwanath;
-Original Message-
From: Cousson, Benoit
Sent: Friday, December 04, 2009 4:27 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [PATCH]OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR
operation
From: Sripathy, Vishwanath
Benoit
Texas
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
From: Sripathy, Vishwanath
-Original Message-
From: Cousson, Benoit
Sent: Friday, December 04, 2009 4:27 PM
To: Sripathy,
Janusz Krzysztofik napisał(a):
Thursday 03 December 2009 21:03:02 Tony Lindgren napisał(a):
Hi,
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091203 04:29]:
Reserve space inside omap_mcbsp structure for storing cached copies of
McBSP register values.
Modify the MCBSP_WRITE() macro to update the
Hi all,
Please ignore previous patch, it has a compilation error.
Correct patch is present below.
-vimal
From e024a2e6aa2051259ad904daff13bdac73b3b1b8 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c'
Ahh.. this is my bad.
[...]
+ err = gpmc_nand_setup((void __iomem *)
+ gpmc_nand_data-gpmc_cs_baseaddr);
we just do not need casting here.
Apologies for making noise and confusion.
Please take this one.
-vimal
From
This patch got line wrapped.
--
---
Regards,
Govindraj.R
On Fri, Dec 4, 2009 at 6:44 PM, Vimal Singh vimal.neww...@gmail.com wrote:
Ahh.. this is my bad.
[...]
+ err = gpmc_nand_setup((void __iomem *)
+ gpmc_nand_data-gpmc_cs_baseaddr);
we just
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from
Hi all,
We now have separate mach/omap include directories for mach-omap1
and mach-omap2. The common headers are now in plat/omap.
The omap730 and omap850 support has been merged into omap7xx
support.
We've reclaimend more address space by separately mapping the
L3 and L4 buses for mach-omap2.
* Vikram Pandita vikram.pand...@ti.com [091203 15:27]:
OMAP3xxx and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort.
OMAP3xxx:
UART IP revision = 0x52 have this issue
MVR register format is:
Bits Field Name Description
* Vishwanath BS vishwanath...@ti.com [091204 01:20]:
From: Shweta Gulati shweta.gul...@ti.com
DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, December 04, 2009 1:04 PM
To: Pandita, Vikram
Cc: linux-omap@vger.kernel.org; Cousson, Benoit
Subject: Re: [PATCH v2] omap: serial: fix non-empty uart fifo read abort
snip
+
+#ifdef CONFIG_ARCH_OMAP4
+
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091204 04:56]:
Janusz Krzysztofik napisał(a):
snip
I think I've already found one part of the answer myself: you
probably mean putting each table definition in a corresponding
arch/arm/mach-omap[12]/mcbsp.c source file, don't you?
Well I did not
Pandita, Vikram said the following on 12/04/2009 09:15 PM:
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, December 04, 2009 1:04 PM
To: Pandita, Vikram
Cc: linux-omap@vger.kernel.org; Cousson, Benoit
Subject: Re: [PATCH v2] omap: serial: fix
Hello all,
Are there any comments for this driver? Do I need to re-submit? Please
let me know.
Thank you,
Chris
chud...@kionix.com wrote:
From: Chris Hudson chud...@kionix.com
This is a request for comments regarding adding driver support for the Kionix
KXTE9 digital tri-axis
On Wed, Nov 18, 2009 at 07:09:10PM +0530, Anand Gadiyar wrote:
omap3: zoom2/3: make MMC slot work again
Commit 12f8dfb56 accidentally broke MMC on zoom2/3.
The .vmmc1 field of zoom_twldata was deleted. Restoring it
allows the MMC slot to work again
Hmm. This was posted 2 weeks ago and not
Hi,
Looks good, just one comment below.
* Govindraj.R govindraj.r...@ti.com [091204 05:37]:
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next-vol2
Initial commit ID (Likely to change): f75bfe73652315f984829aff15ea8f76a7970ff8
PatchWorks
http://patchwork.kernel.org/patch/61013/
Git (Likely to change, and takes a while to get
Hi,
* Vimal Singh vimal.neww...@gmail.com [091203 06:09]:
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Thu, 26 Nov 2009 16:10:24 +0530
Subject: [PATCH] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
This patch
* Grazvydas Ignotas nota...@gmail.com [091203 08:05]:
On Thu, Dec 3, 2009 at 4:15 PM, Vimal Singh vimal.neww...@gmail.com wrote:
From 948584f4157a9eb99ba085968d23add28cbfd160 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 1 Dec 2009 11:36:56 +0530
Subject: [PATCH]
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: master
Initial commit ID (Likely to change): 3929b04e6e48d1294376eac04e47bb7cdf6a085d
PatchWorks
http://patchwork.kernel.org/patch/64520/
Git (Likely to change, and takes a while to get mirrored)
* Cory Maccarrone darkstar6...@gmail.com [091203 07:28]:
On Thu, Dec 3, 2009 at 5:28 AM, Belisko Marek marek.beli...@gmail.com wrote:
Hi,
when make htcherald_defconfig on current linux-omap tree
(82f1d8f22f2c65e70206e40a6f17688bf64a892c) compilation fails
in
* Paul Walmsley p...@pwsan.com [091129 22:44]:
On Fri, 27 Nov 2009, Janusz Krzysztofik wrote:
All of the LCD DMA code in plat-omap/dma.c appears to be OMAP1-only (and
apparently only is available on a subset of OMAP1 chips).
Looks good.
Reviewed-by: Paul Walmsley p...@pwsan.com
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next-vol2
Initial commit ID (Likely to change): fde592f136f1bb5861121272a2530b781922936a
PatchWorks
http://patchwork.kernel.org/patch/62077/
Git (Likely to change, and takes a while to get
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next-vol2
Initial commit ID (Likely to change): dd1a4ddb989eded52aac34a85cea2f2b122fbc84
PatchWorks
http://patchwork.kernel.org/patch/62078/
Git (Likely to change, and takes a while to get
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next-vol2
Initial commit ID (Likely to change): adbfd7019b24673f8d8210d610b10ac7bd3fad30
PatchWorks
http://patchwork.kernel.org/patch/62079/
Git (Likely to change, and takes a while to get
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next-vol2
Initial commit ID (Likely to change): d6ebf3557861e5d023e11e027cd321b5e39f885b
PatchWorks
http://patchwork.kernel.org/patch/62142/
Git (Likely to change, and takes a while to get
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next-vol2
Initial commit ID (Likely to change): a216a2003b1822b3262510b575d65994013ece58
PatchWorks
http://patchwork.kernel.org/patch/62207/
Git (Likely to change, and takes a while to get
OMAP3xxx and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort.
OMAP3xxx:
UART IP revision = 0x52 have this issue
MVR register format is:
Bits Field Name Description Type Reset
31:8 RESERVED
42 matches
Mail list logo
