Re: [PATCH 1/3] ARM: OMAP: 32k counter: resolve sparse warnings
On Monday 24 December 2012 06:54 AM, Paul Walmsley wrote: Commit 1fe97c8f6a1de67a5f56e029a818903d5bed8017 (ARM: OMAP: Make OMAP clocksource source selection using kernel param) results in a new warning from sparse: arch/arm/plat-omap/counter_32k.c:86:12: warning: symbol 'omap_init_clocksource_32k' was not declared. Should it be static? Fix by adding a temporary header file, needed until the 32k counter code is moved to drivers/. arch/arm/plat-omap/include/plat/counter-32k.h can't be added due to ARM CONFIG_ARCH_MULTIPLATFORM restrictions on the use of the plat/ include path shortcut. Signed-off-by: Paul Walmsley p...@pwsan.com Looks good to my eyes. Acked-by : Santosh Shilimkar santosh.shilim...@ti.com -- 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
Re: [PATCH 00/15] OMAP SHAM AES Crypto Updates
On Sun, Dec 23, 2012 at 05:03:45PM +0100, Peter Korsgaard wrote: Mark == Mark A Greer mgr...@animalcreek.com writes: Hi, Huh, does am335x have a sham module? I don't see any mention of that in spruh73g.pdf Mark Yes. It has sham, aes, and rng modules. Ok, interesting. Mark They are not described in the TRM. In fact, I had to use the Mark omap4 description (closely guarded by TI) because AFAIK there Mark isn't a doc for the am33xx. The am33xx modules are identical to Mark the omap4 ones except for the register addresses and dma channels Mark so that doc worked. Odd. How did you figure out the am335x base address / dma channels? From the SDK code. :) That is, the am335x evm SDK from TI. I looked at it to determine the addresses, etc. Mark -- -- 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
Re: [PATCH 00/15] OMAP SHAM AES Crypto Updates
On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote: Hi Mark, On Fri, 21 Dec 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com [This series supersedes the hwmod related patches sent in the crypto: omap-sham updates and crypto: omap-aes updates series a few weeks ago.] This series adds hwmod support for the OMAP SHAM and AES modules on OMAP2, OMAP3, and OMAP4/AM33XX SoCs. It also adds device tree info for those modules. Thanks for working on this, this will get us much closer to being able to convert the hwmod code into an OMAP bus. I haven't looked closely at these patches yet, but a few comments/questions: - Looks like the two DTS patches are the ones with direct dependencies on the DMA Engine support patches that you mentioned. The patch(es) that convert the drivers to use dma_request_slave_channel_compat() will cause problems too if the patch that adds that call isn't in your branch. AFAIK, this is the latest version, https://patchwork.kernel.org/patch/1459231/ from Jon Hunter. Any objection to me taking the series without those two patches? Then once the DMA Engine series goes in, maybe those AM33xx DTS patches can go up? No, no objections at all. I will track/resubmit/whatever the ones that need to go in later. - The patch series causes AM3517/3505 to crash. I'd guess this is due to the SHAM/AES modules being initialized on those chips, but they probably don't exist there. Can you change the initialization for those on OMAP3 to only take place on OMAP34xx/36xx GP? I guess you'd need to create new lists for those in the hwmod init. Oh. :( Sure, I'll do what you suggest when I'm back to work in the new year. Thanks Paul. Mark -- -- 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
Re: [PATCH 00/15] OMAP SHAM AES Crypto Updates
On Tue, Dec 25, 2012 at 12:29:37PM -0700, Mark A. Greer wrote: On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote: Hi Mark, On Fri, 21 Dec 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com [This series supersedes the hwmod related patches sent in the crypto: omap-sham updates and crypto: omap-aes updates series a few weeks ago.] This series adds hwmod support for the OMAP SHAM and AES modules on OMAP2, OMAP3, and OMAP4/AM33XX SoCs. It also adds device tree info for those modules. Thanks for working on this, this will get us much closer to being able to convert the hwmod code into an OMAP bus. I haven't looked closely at these patches yet, but a few comments/questions: - Looks like the two DTS patches are the ones with direct dependencies on the DMA Engine support patches that you mentioned. The patch(es) that convert the drivers to use dma_request_slave_channel_compat() will cause problems too if the patch that adds that call isn't in your branch. AFAIK, this is the latest version, https://patchwork.kernel.org/patch/1459231/ from Jon Hunter. Oops, sorry, please disregard this comment. I had the wrong patchset in mind when I wrote it. Mark -- -- 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
Re: [PATCH 2/3] ARM: OMAP AM33xx: hwmod data: resolve sparse warnings
On 12/24/2012 6:55 AM, Paul Walmsley wrote: Commit 70384a6af0914d5dcec034643941e29d3e3e69f7 (ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module) adds two new sparse warnings: arch/arm/mach-omap2/omap_hwmod_33xx_data.c:2518:30: warning: symbol 'am33xx_mdio_addr_space' was not declared. Should it be static? arch/arm/mach-omap2/omap_hwmod_33xx_data.c:2526:26: warning: symbol 'am33xx_cpgmac0__mdio' was not declared. Should it be static? Fix by marking the two new records as static. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Peter Korsgaard jac...@sunsite.dk Cc: Richard Cochran richardcoch...@gmail.com Cc: David S. Miller da...@davemloft.net Looks good to me. Acked-by : Mugunthan V N mugunthan...@ti.com -- 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
Re: [PATCH v2 0/2] cpts fixes for v3.8-rc2
On 12/24/2012 12:49 PM, Richard Cochran wrote: Changed in v2: Use clk_prepare_enable instead of clk_prepare + clk_enable. The new cpts driver has two small issues, but it otherwise seems to be working in -rc1. Thanks, Richard Richard Cochran (2): cpts: fix build error by removing useless code. cpts: fix a run time warn_on. drivers/net/ethernet/ti/cpts.c |3 +-- drivers/net/ethernet/ti/cpts.h |1 - 2 files changed, 1 insertions(+), 3 deletions(-) Looks good to me. Acked-by : Mugunthan V N mugunthan...@ti.com -- 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
[PATCH] arm: omap: Remove apollon board support
From: Kyungmin Park kyungmin.p...@samsung.com
As apollon board doesn't used anymore, remove it.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..d4e4f95 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -165,12 +165,6 @@ config MACH_OMAP_H4
select OMAP_DEBUG_DEVICES
select OMAP_PACKAGE_ZAF
-config MACH_OMAP_APOLLON
- bool OMAP 2420 Apollon board
- depends on SOC_OMAP2420
- default y
- select OMAP_PACKAGE_ZAC
-
config MACH_OMAP_2430SDP
bool OMAP 2430 SDP board
depends on SOC_OMAP2430
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a8004f3..25ca2a1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -220,7 +220,6 @@ endif
obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o
-obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65468f6..ca7c5d4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -783,9 +783,6 @@ static int __devinit gpmc_mem_init(void)
* even if we didn't boot from ROM.
*/
boot_rom_space = BOOT_ROM_SPACE;
- /* In apollon the CS0 is mapped as 0x */
- if (machine_is_omap_apollon())
- boot_rom_space = 0;
gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
gpmc_mem_root.end = GPMC_MEM_END;
diff --git a/arch/arm/mach-omap2/include/mach/uncompress.h
b/arch/arm/mach-omap2/include/mach/uncompress.h
index 8e3546d..e278451 100644
--- a/arch/arm/mach-omap2/include/mach/uncompress.h
+++ b/arch/arm/mach-omap2/include/mach/uncompress.h
@@ -115,7 +115,6 @@ static inline void arch_decomp_setup(void)
do {
/* omap2 based boards using UART1 */
DEBUG_LL_OMAP2(1, omap_2430sdp);
- DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
/* omap2 based boards using UART3 */
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 54ca8ae..c904f42 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -291,30 +291,6 @@ static struct panel_config generic_dpi_panels[] = {
.name = h4,
},
- /* Unknown panel used in Samsung OMAP2 Apollon */
- {
- {
- .x_res = 480,
- .y_res = 272,
-
- .pixel_clock= 6250,
-
- .hsw= 41,
- .hfp= 2,
- .hbp= 2,
-
- .vsw= 10,
- .vfp= 2,
- .vbp= 2,
-
- .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
- .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
- .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
- .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
- .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
- },
- .name = apollon,
- },
/* FocalTech ETM070003DH6 */
{
{
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
deleted file mode 100644
index 5d0a61f..000
--- a/arch/arm/mach-omap2/board-apollon.c
+++ /dev/null
@@ -1,342 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-apollon.c
- *
- * Copyright (C) 2005,2006 Samsung Electronics
- * Author: Kyungmin Park kyungmin.p...@samsung.com
- *
- * Modified from mach-omap/omap2/board-h4.c
- *
- * Code for apollon OMAP2 board. Should work on many OMAP2 systems where
- * the bootloader passes the board-specific data to the kernel.
- * Do not put any board specific code to this file; create a new machine
- * type if you need custom low-level initializations.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/mtd/mtd.h
-#include linux/mtd/partitions.h
-#include linux/mtd/onenand.h
-#include linux/delay.h
-#include linux/leds.h
-#include linux/err.h
-#include linux/clk.h
-#include
RE: [PATCH 02/12] ARM: OMAP2+: PM: introduce power domains functional states
Hi Paul, A minor comment below. On Sun, Dec 09, 2012 at 23:23:01, Paul Walmsley wrote: [...] + + pr_debug(powerdomain: convert pwrst (%0x,%0x) to fpwrst %0x\n, + pwrst, logic, *fpwrst); + This function alone does not print the powerdomain name. Can you add that in the final version? Regards, Vaibhav -- 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
RE: [PATCH 09/12] ARM: OMAP2+: powerdomain: skip register reads for powerdomains known to be on
Hi Paul,
On Mon, Dec 10, 2012 at 01:33:28, Paul Walmsley wrote:
There's no need to determine the current power state for powerdomains
that must be on while the kernel is running. We mark these
powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
powerdomain marked with that flag is reported as being in the ON power
state while the kernel is running.
[...]
diff --git a/arch/arm/mach-omap2/powerdomains33xx_data.c
b/arch/arm/mach-omap2/powerdomains33xx_data.c
index 869adb8..acb148a 100644
--- a/arch/arm/mach-omap2/powerdomains33xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains33xx_data.c
@@ -123,7 +123,8 @@ static struct powerdomain mpu_33xx_pwrdm = {
.pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags = (PWRDM_HAS_LOWPOWERSTATECHANGE |
+PWRDM_ACTIVE_WITH_KERNEL),
In case of AM33xx, this flag should be set for PER and WKUP pwrdms also.
EMIF, L3, L4 etc come under PER so this domain can't transition on an active
system. PRCM and Control module come under WKUP, so the WKUP should the kernel
should attempt to transition WKUP domain also.
Regards,
Vaibhav
RE: [PATCH 09/12] ARM: OMAP2+: powerdomain: skip register reads for powerdomains known to be on
On Wed, Dec 26, 2012 at 11:51:46, Bedia, Vaibhav wrote:
Hi Paul,
On Mon, Dec 10, 2012 at 01:33:28, Paul Walmsley wrote:
There's no need to determine the current power state for powerdomains
that must be on while the kernel is running. We mark these
powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
powerdomain marked with that flag is reported as being in the ON power
state while the kernel is running.
[...]
diff --git a/arch/arm/mach-omap2/powerdomains33xx_data.c
b/arch/arm/mach-omap2/powerdomains33xx_data.c
index 869adb8..acb148a 100644
--- a/arch/arm/mach-omap2/powerdomains33xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains33xx_data.c
@@ -123,7 +123,8 @@ static struct powerdomain mpu_33xx_pwrdm = {
.pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags = (PWRDM_HAS_LOWPOWERSTATECHANGE |
+ PWRDM_ACTIVE_WITH_KERNEL),
In case of AM33xx, this flag should be set for PER and WKUP pwrdms also.
EMIF, L3, L4 etc come under PER so this domain can't transition on an active
system. PRCM and Control module come under WKUP, so
... the kernel should not attempt to change the WKUP power domain state.
Regards,
Vaibhav
--
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
RE: [PATCH 09/10] ARM: OMAP2+: clockdomain: convert existing atomic usecounts into spinlock-protected shorts/ints
Hi Paul,
On Sun, Dec 09, 2012 at 06:53:43, Paul Walmsley wrote:
The atomic usecounts seem to be confusing, and are no longer needed
since the operations that they are attached to really should take
place under lock. Replace the atomic counters with simple integers,
protected by the enclosing powerdomain spinlock.
[...]
@@ -1063,7 +1123,8 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain
*clkdm)
* should be called for every clock instance or hwmod that is
* enabled, so the clkdm can be force woken up.
*/
- if ((atomic_inc_return(clkdm-usecount) 1) autodeps) {
+ clkdm-usecount++;
+ if (clkdm-usecount 1 autodeps) {
pwrdm_unlock(clkdm-pwrdm.ptr);
return 0;
}
This is not directly related to this patch but something I noticed when I
enabled
the various debug prints.
if the clkdm-usecount is 1, there is still a call to
arch_clkdm-clkdm_clk_enable().
Won't the usecount 1 guarantee that the clkdm is in the right state and the
PRCM
access can be skipped?
Regards,
Vaibhav
--
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
