RE: [PATCH 07/12] System Control Module context save/restore
> >>> #define OMAP3430_PRM_RSTST \ > >>> OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, RM_RSTST) > >>> +static struct omap3_control_module_regs control_ctx; > >>> + > >> I'm not sure what this patch was generated against, but it doesn't > >> apply against linux-omap. The PRM_RSTST definition above is not in > >> linux-omap code. > >> > >> Kevin > > > > There is no reference to PRM_RSTST in this patch. It uses > RM_RSTST which > > can be found in arch/arm/mach-omap2/prm.h. > > You can see in the above quoted text that your 7/12 patch > adds some code > immediately after a line which defines OMAP3430_PRM_RSTST. > Since this > existing code is not in linux-omap, and I couldn't find it in > previous > patches, it's not clear what this patch was generated against. > > Kevin Yes, those lines are not present in linux-omap and are added by patch [PATCH 03/06] scratchpad populate posted by me on 08/26/2008. It is part of the patch set [PATCH 00/06] OMAP3 CPUidle patches - supports C0-C5 posted the same day. To summarise I have posted 2 patch sets as discussed earlier for CPUIdle 1) [PATCH 00/06] OMAP3 CPUidle patches - supports C0-C5 - posted on 08/26/2008 2) [PATCH 00/12] OMAP3 CPUidle context save/restore patches - supports C6 - posted on 09/01/2008 Apart from these the following patch set posted by Jouni is needed for these patches to apply 1) [PATCH 0/4] Refreshed PM workaround patches 2. - posted on 07/15/2008 NOTE: Patch 1/4 from this set is already pushed in l-o mainline. So if you apply the patches in the following order on top of commit 81c893795c2e1fbe0bf5f638e.. I am hoping they should work. 1) [PATCH 0/4] Refreshed PM workaround patches 2. 2) [PATCH 00/06] OMAP3 CPUidle patches - supports C0-C5 3) [PATCH 00/12] OMAP3 CPUidle context save/restore patches -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESENDING][PATCH 1/2]OMAP3 NAND: Add NAND support on OMAP3430
On Wednesday 10 September 2008, vimal singh wrote: > [VS: updated for SZ_.. macros] > + /* All the partition sizes are listed in terms of NAND block size > ... > + .size = SZ_512K, > ... > + .size = SZ_512K, > ... But now they're not "in terms of NAND block size". Wouldn't it be better to use either 4 * SZ_128K or 4 * NAND_BLOCK_SIZE? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.27-rc6-omap1] mach-omap2: fix more arch_initcall() breakage
From: David Brownell <[EMAIL PROTECTED]>
Remove more bogus arch_initcall() logic in mach-omap2/board-xyx.c files.
They broke a multi-OMAP build I did, at *RUN TIME* not build time, since
it tried to do the i2c init for every board linked in the kernel.
Remember, init_machine() entries run at arch_initcall() time; that's
where any board-specific init logic should normally go. Any initcalls
in the mach-*/*c files should normally be guarded by tests to make sure
they only run on the relevant hardware (board, cpu). Better yet, get
rid of the initcalls; init_machine() can *explicitly* call the right
version of that code, and pass in board-specific config data; and there
are hooks that can handle cpu-specific stuff too.
A quick glance suggests most of the remaining initcall logic in the
mach-omap2 directory is similarly broken... this patch gets rid of
one frequently-cloned idiom, it should help.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-2430sdp.c |4 ++--
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap2evm.c |4 ++--
arch/arm/mach-omap2/board-omap3evm.c |4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -392,6 +392,8 @@ static int __init omap2430_i2c_init(void
static void __init omap_2430sdp_init(void)
{
+ omap2430_i2c_init();
+
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_board_config = sdp2430_config;
omap_board_config_size = ARRAY_SIZE(sdp2430_config);
@@ -416,8 +418,6 @@ static void __init omap_2430sdp_map_io(v
omap2_map_common_io();
}
-arch_initcall(omap2430_i2c_init);
-
MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
/* Maintainer: Syed Khasim - Texas Instruments Inc */
.phys_io= 0x4800,
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -354,6 +354,7 @@ extern void __init sdp3430_flash_init(vo
static void __init omap_3430sdp_init(void)
{
+ omap3430_i2c_init();
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
@@ -378,7 +379,6 @@ static void __init omap_3430sdp_map_io(v
omap2_set_globals_343x();
omap2_map_common_io();
}
-arch_initcall(omap3430_i2c_init);
MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
/* Maintainer: Syed Khasim - Texas Instruments Inc */
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -223,6 +223,7 @@ static int __init omap_i2c_init(void)
static void __init omap_ldp_init(void)
{
+ omap_i2c_init();
platform_add_devices(ldp_devices, ARRAY_SIZE(ldp_devices));
omap_board_config = ldp_config;
omap_board_config_size = ARRAY_SIZE(ldp_config);
@@ -242,7 +243,6 @@ static void __init omap_ldp_map_io(void)
omap2_set_globals_343x();
omap2_map_common_io();
}
-arch_initcall(omap_i2c_init);
MACHINE_START(OMAP_LDP, "OMAP LDP board")
.phys_io= 0x4800,
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -261,6 +261,8 @@ static struct platform_device *omap2_evm
static void __init omap2_evm_init(void)
{
+ omap2_evm_i2c_init();
+
platform_add_devices(omap2_evm_devices, ARRAY_SIZE(omap2_evm_devices));
omap_board_config = omap2_evm_config;
omap_board_config_size = ARRAY_SIZE(omap2_evm_config);
@@ -275,8 +277,6 @@ static void __init omap2_evm_map_io(void
omap2_map_common_io();
}
-arch_initcall(omap2_evm_i2c_init);
-
MACHINE_START(OMAP2EVM, "OMAP2EVM Board")
/* Maintainer: Arun KS <[EMAIL PROTECTED]> */
.phys_io= 0x4800,
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -223,6 +223,8 @@ static struct platform_device *omap3_evm
static void __init omap3_evm_init(void)
{
+ omap3_evm_i2c_init();
+
platform_add_devices(omap3_evm_devices, ARRAY_SIZE(omap3_evm_devices));
omap_board_config = omap3_evm_config;
omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
@@ -238,8 +240,6 @@ static void __init omap3_evm_init(void)
ads7846_dev_init();
}
-arch_initcall(omap3_evm_i2c_init);
-
static void __init omap3_evm_map_io(void)
{
omap2_set_globals_343x();
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESENDING][PATCH 1/2]OMAP3 NAND: Add NAND support on OMAP3430
Hi,
Below is the updated patch after fixing Tony's comment.
From: Teerth Reddy <[EMAIL PROTECTED]>
This patch adds NAND support on 3430sdp board
[VS: updated for SZ_.. macros]
Signed-off-by: Teerth Reddy <[EMAIL PROTECTED]>
Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-3430sdp-flash.c | 88 --
arch/arm/plat-omap/include/mach/gpmc.h| 10 +++
2 files changed, 93 insertions(+), 5 deletions(-)
Index: linux-omap-2.6_27_08_2008/arch/arm/mach-omap2/board-3430sdp-flash.c
===
---
linux-omap-2.6_27_08_2008.orig/arch/arm/mach-omap2/board-3430sdp-flash.c
2008-08-27
11:40:26.0 +0530
+++
linux-omap-2.6_27_08_2008/arch/arm/mach-omap2/board-3430sdp-flash.c
2008-09-11
11:10:44.0 +0530
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
static struct mtd_partition sdp_nor_partitions[] = {
/* bootloader (U-Boot, etc) in first sector */
@@ -137,6 +138,61 @@
/* Onenand setup does nothing at present */
return 0;
}
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = "X-Loader-NAND",
+ .offset = 0,
+ .size = SZ_512K,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot-NAND",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = SZ_512K,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "Boot Env-NAND",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x10 */
+ .size = SZ_256K,
+ },
+ {
+ .name = "Kernel-NAND",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x14 */
+ .size = SZ_4M,
+ },
+ {
+ .name = "File System - NAND",
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x54 */
+ },
+};
+
+static struct omap_nand_platform_data sdp_nand_data = {
+ .parts = sdp_nand_partitions,
+ .nr_parts = ARRAY_SIZE(sdp_nand_partitions),
+ .nand_setup = NULL,
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+};
+
+static struct resource sdp_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nand_device = {
+ .name = "omap2-nand",
+ .id = 0,
+ .dev= {
+ .platform_data = &sdp_nand_data,
+ },
+ .num_resources = 1,
+ .resource = &sdp_nand_resource,
+};
+
+
/**
* sdp3430_flash_init - Identify devices connected to GPMC and register.
*
@@ -145,7 +201,11 @@
void __init sdp3430_flash_init(void)
{
u8 cs = 0;
+ u8 nandcs = GPMC_CS_NUM + 1;
u8 onenandcs = GPMC_CS_NUM + 1;
+ unsigned long gpmc_base_add;
+
+ gpmc_base_add = OMAP34XX_GPMC_VIRT;
/* Configure start address and size of NOR device */
if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
@@ -163,25 +223,43 @@
while (cs < GPMC_CS_NUM) {
u32 ret = 0;
- ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
/*
- * xloader/Uboot would have programmed the oneNAND
+ * xloader/Uboot would have programmed the NAND/oneNAND
* base address for us This is a ugly hack. The proper
* way of doing this is to pass the setup of u-boot up
* to kernel using kernel params - something on the
* lines of machineID. Check if oneNAND is configured
*/
- if ((ret & 0x3F) == (ONENAND_MAP >> 24))
+ if ((ret & 0xC00) == 0x800) {
+ /* Found it!! */
+ if (nandcs > GPMC_CS_NUM)
+ nandcs = cs;
+ } else {
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
+ if ((ret & 0x3F) == (ONENAND_MAP >> 24))
onenandcs = cs;
+ }
cs++;
}
- if (onenandcs > GPMC_CS_NUM) {
- printk(KERN_INFO "OneNAND: Unable to find configuration "
+ if ((nandcs > GPMC_CS_NUM) && (onenandcs > GPMC_CS_NUM)) {
+ printk(KERN_INFO "NAND/OneNAND: Unable to find configuration "
" in GPMC\n ");
retur
Re: [PATCH 07/12] System Control Module context save/restore
Rajendra Nayak wrote: -Original Message- From: Kevin Hilman [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 8:18 PM To: Rajendra Nayak Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 07/12] System Control Module context save/restore "Rajendra Nayak" <[EMAIL PROTECTED]> writes: This patch adds the System control module context save/restore Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]> --- arch/arm/mach-omap2/control.c | 105 ++ arch/arm/plat-omap/include/mach/control.h | 61 + 2 files changed, 165 insertions(+), 1 deletion(-) Index: linux-omap-2.6/arch/arm/mach-omap2/control.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/control.c 2008-09-01 18:11:34.0 +0530 +++ linux-omap-2.6/arch/arm/mach-omap2/control.c 2008-09-01 18:11:54.0 +0530 @@ -73,6 +73,8 @@ void omap_ctrl_writel(u32 val, u16 offse #define OMAP3430_PRM_RSTST \ OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, RM_RSTST) +static struct omap3_control_module_regs control_ctx; + I'm not sure what this patch was generated against, but it doesn't apply against linux-omap. The PRM_RSTST definition above is not in linux-omap code. Kevin There is no reference to PRM_RSTST in this patch. It uses RM_RSTST which can be found in arch/arm/mach-omap2/prm.h. You can see in the above quoted text that your 7/12 patch adds some code immediately after a line which defines OMAP3430_PRM_RSTST. Since this existing code is not in linux-omap, and I couldn't find it in previous patches, it's not clear what this patch was generated against. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 07/12] System Control Module context save/restore
> -Original Message-
> From: Kevin Hilman [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 10, 2008 8:18 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH 07/12] System Control Module context save/restore
>
> "Rajendra Nayak" <[EMAIL PROTECTED]> writes:
>
> > This patch adds the System control module context save/restore
> >
> > Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> > ---
> > arch/arm/mach-omap2/control.c | 105
> ++
> > arch/arm/plat-omap/include/mach/control.h | 61 +
> > 2 files changed, 165 insertions(+), 1 deletion(-)
> >
> > Index: linux-omap-2.6/arch/arm/mach-omap2/control.c
> > ===
> > --- linux-omap-2.6.orig/arch/arm/mach-omap2/control.c
> 2008-09-01
> > 18:11:34.0 +0530
> > +++ linux-omap-2.6/arch/arm/mach-omap2/control.c
> 2008-09-01 18:11:54.0
> > +0530
> > @@ -73,6 +73,8 @@ void omap_ctrl_writel(u32 val, u16 offse
> >
> > #define OMAP3430_PRM_RSTST \
> > OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, RM_RSTST)
> > +static struct omap3_control_module_regs control_ctx;
> > +
>
> I'm not sure what this patch was generated against, but it doesn't
> apply against linux-omap. The PRM_RSTST definition above is not in
> linux-omap code.
>
> Kevin
There is no reference to PRM_RSTST in this patch. It uses RM_RSTST which
can be found in arch/arm/mach-omap2/prm.h.
There patches were generated on top of commit 81c893795c2e1fbe0bf5..
>
> > /* Clears the scratchpad contents in case of cold boot-
> > called during bootup*/
> > void omap3_clear_scratchpad_contents(void)
> > @@ -190,4 +192,107 @@ void omap3_save_scratchpad_contents(void
> > &sdrc_block_contents, sizeof(sdrc_block_contents));
> > }
> >
> > +void omap3_save_control_ctx(void)
> > +{
> > + control_ctx.sysconfig =
> omap_ctrl_readl(OMAP2_CONTROL_SYSCONFIG);
> > + control_ctx.devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
> > + control_ctx.mem_dftrw0 =
> omap_ctrl_readl(OMAP343X_CONTROL_MEM_DFTRW0);
> > + control_ctx.mem_dftrw1 =
> omap_ctrl_readl(OMAP343X_CONTROL_MEM_DFTRW1);
> > + control_ctx.msuspendmux_0 =
> > + omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_0);
> > + control_ctx.msuspendmux_1 =
> > + omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_1);
> > + control_ctx.msuspendmux_2 =
> > + omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_2);
> > + control_ctx.msuspendmux_3 =
> > + omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_3);
> > + control_ctx.msuspendmux_4 =
> > + omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_4);
> > + control_ctx.msuspendmux_5 =
> > + omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_5);
> > + control_ctx.sec_ctrl = omap_ctrl_readl(OMAP2_CONTROL_SEC_CTRL);
> > + control_ctx.devconf1 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
> > + control_ctx.csirxfe = omap_ctrl_readl(OMAP343X_CONTROL_CSIRXFE);
> > + control_ctx.iva2_bootaddr =
> > + omap_ctrl_readl(OMAP343X_CONTROL_IVA2_BOOTADDR);
> > + control_ctx.iva2_bootmod =
> > + omap_ctrl_readl(OMAP343X_CONTROL_IVA2_BOOTMOD);
> > + control_ctx.debobs_0 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_0);
> > + control_ctx.debobs_1 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_1);
> > + control_ctx.debobs_2 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_2);
> > + control_ctx.debobs_3 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_3);
> > + control_ctx.debobs_4 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_4);
> > + control_ctx.debobs_5 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_5);
> > + control_ctx.debobs_6 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_6);
> > + control_ctx.debobs_7 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_7);
> > + control_ctx.debobs_8 =
> omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_8);
> > + control_ctx.prog_io0 =
> omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO0);
> > + control_ctx.prog_io1 =
> omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO1);
> > + control_ctx.dss_dpll_spreading =
> > + omap_ctrl_readl(OMAP343X_CONTROL_DSS_DPLL_SPREADING);
> > + control_ctx.core_dpll_spreading =
> > + omap_ctrl_readl(OMAP343X_CONTROL_CORE_DPLL_SPREADING);
> > + control_ctx.per_dpll_spreading =
> > + omap_ctrl_readl(OMAP343X_CONTROL_PER_DPLL_SPREADING);
> > + control_ctx.usbhost_dpll_spreading =
> > + omap_ctrl_readl(OMAP343X_CONTROL_USBHOST_DPLL_SPREADING);
> > + control_ctx.pbias_lite =
> omap_ctrl_readl(OMAP343X_CONTROL_PBIAS_LITE);
> > + control_ctx.temp_sensor =
> omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
> > + control_ctx.sramldo4 =
> omap_ctrl_readl(OMAP343X_CONTROL_SRAMLDO4);
> > + control_ctx.sramldo5 =
> omap_ctrl_readl(OMAP343X_CONTROL_SRAMLDO5);
> > + control_ctx.csi = omap_ctrl_readl(OMAP343X_CONTROL_CSI);
> > + re
Re: HSMMC pending fixes
- Original Message -
From: "Tony Lindgren" <[EMAIL PROTECTED]>
To: "Woodruff, Richard" <[EMAIL PROTECTED]>
Cc: "Jarkko Lavinen" <[EMAIL PROTECTED]>;
Sent: Thursday, September 11, 2008 5:35 AM
Subject: Re: HSMMC pending fixes
>* Woodruff, Richard <[EMAIL PROTECTED]> [080818 14:09]:
>> Hi,
>>
>> > [EMAIL PROTECTED] On Behalf Of Jarkko Lavinen
>>
>>
>> > 2: Disable smartidle mode while suspending (workaround)
>>
>> This was the work around we had in internal trees for a long time.
>>
>> However Madhu C. recently updated this based on an internal investigation.
>> It is required to reset the command pin to clear the system for sleep. This
>> allows retention to work.
>>
>> The non-idle work around when profiled showed it was taking a huge amount of
>> time for the clock re-enable to work. This actually would noticeably reduce
>> MMC throughput when doing aggressive clock cutting in the driver and
>> increase power usage.
>>
>> + } else {
>> + OMAP_HSMMC_WRITE(host->base, SYSCTL,
>> + OMAP_HSMMC_READ(host->base, SYSCTL) | SRD);
>> + while (OMAP_HSMMC_READ(host->base, SYSCTL) & SRD) ;
>>
>> If you use a really long time out then perhaps it doesn't matter. But if
>> you try and be aggressive it will hurt you.
>
> Pushing all except the workaround. Madhu, can you please send a patch
> for what Richard is describing?
Tony, I have already posted the above fix to L-o. I see that it is merged as
well. With this fix, I guess there is no need to disable smart idle mode while
suspending. Am I missing any other thing here?
Regards,
Madhu
>
> Thanks,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BRIDGE] Rebase and sync with omapzoom bridge patch update
Hi Felipe, From: "ext Felipe Contreras" <[EMAIL PROTECTED]> Subject: Re: [BRIDGE] Rebase and sync with omapzoom bridge patch update Date: Wed, 10 Sep 2008 15:49:51 +0300 > On Wed, Sep 10, 2008 at 3:41 PM, Hiroshi DOYU <[EMAIL PROTECTED]> wrote: > > Hi, > > > > It seems that the following site doesn't work with git. > > So please use: > > > > $ wget http://4869037.web.fc2.com/tidspbridge-20080910.tgz > > > > From: Hiroshi DOYU <[EMAIL PROTECTED]> > > Subject: [BRIDGE] Rebase and sync with omapzoom bridge patch update > > Date: Wed, 10 Sep 2008 06:53:32 +0300 (EEST) > > > >> Hi, > >> > >> I have updated all TI BRIDGE patches and rebased them against the > >> latest linux-omap again for easy integration of them. You can get it > >> by: > >> git fetch http://4869037.web.fc2.com/linux.git bridge: > > This works fine here... Thanks for letting me know. I will check it again, or find the better way... Hiroshi DOYU -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][OMAP 3/4+] BRIDGE: Module ISR removed
Hi Fernando, Added to the bridge patchsets against l-o, too. From: "ext Guzman Lugo, Fernando" <[EMAIL PROTECTED]> Subject: [PATCH][OMAP 3/4+] BRIDGE: Module ISR removed Date: Wed, 10 Sep 2008 20:01:33 -0500 > > This patch removes ISR module completely > > Signed-off-by: Fernando Guzman Lugo <[EMAIL PROTECTED]> > --- > arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h |1 - > arch/arm/plat-omap/include/mach/bridge/io_sm.h|3 +- > arch/arm/plat-omap/include/mach/bridge/isr.h | 154 > drivers/dsp/bridge/pmgr/chnl.c|1 - > drivers/dsp/bridge/services/isr.c | 261 > - > drivers/dsp/bridge/services/services.c| 10 +- > drivers/dsp/bridge/wmd/_deh.h |2 - > drivers/dsp/bridge/wmd/io_sm.c| 46 ++-- > drivers/dsp/bridge/wmd/mmu_fault.c|6 +- > drivers/dsp/bridge/wmd/mmu_fault.h|2 +- > drivers/dsp/bridge/wmd/tiomap_sm.c|1 - > drivers/dsp/bridge/wmd/ue_deh.c | 14 +- > 12 files changed, 38 insertions(+), 463 deletions(-) > delete mode 100644 arch/arm/plat-omap/include/mach/bridge/isr.h > delete mode 100644 drivers/dsp/bridge/services/isr.c > > diff --git a/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h > b/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h > index f6a6c69..4e82639 100644 > --- a/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h > +++ b/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h > @@ -57,7 +57,6 @@ > > #include > #include > -#include > #include > > #include > diff --git a/arch/arm/plat-omap/include/mach/bridge/io_sm.h > b/arch/arm/plat-omap/include/mach/bridge/io_sm.h > index 413108f..892c06a 100644 > --- a/arch/arm/plat-omap/include/mach/bridge/io_sm.h > +++ b/arch/arm/plat-omap/include/mach/bridge/io_sm.h > @@ -132,8 +132,7 @@ > * Interrupts are disabled and EOI for this interrupt has been sent. > * Ensures: > */ > - extern bool IO_ISR(IN void *pRefData); > - > + irqreturn_t IO_ISR(int irq, IN void *pRefData); > /* > * IO_RequestChnl > * Purpose: > diff --git a/arch/arm/plat-omap/include/mach/bridge/isr.h > b/arch/arm/plat-omap/include/mach/bridge/isr.h > deleted file mode 100644 > index fb397bb..000 > --- a/arch/arm/plat-omap/include/mach/bridge/isr.h > +++ /dev/null > @@ -1,154 +0,0 @@ > -/* > - * bridge/inc/isr.h > - * > - * DSP-BIOS Bridge driver support functions for TI OMAP processors. > - * > - * Copyright (C) 2005-2006 Texas Instruments, Inc. > - * > - * This package 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. > - * > - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR > - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED > - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. > - */ > - > - > -/* > - * isr.h > - * Purpose: > - * Interrupt services. > - * > - * Public Functions: > - * ISR_Exit > - * ISR_Init > - * ISR_Install > - * ISR_Uninstall > - * > - * Notes: > - * > - *! Revision History: > - *! > - *! 01-Mar-2004 vp: Added IVA related functions. > - *! 06-Feb-2003 kc: Added ISR_MAILBOX1 (renamed from DSP_MAILBOX1). > - *! 05-Nov-2001 kc: Added interrupt type param to ISR_Install. > - *! 31-Jan-2000 rr: Comments modified after code review. > - *! 29-Oct-1999 kc: Moved header files to within ifdefed 'extern "C"'. > - *! 17-Sep-1997 gp: Added CFG_HOSTRES struct as argument to ISR_Install, > thus > - *! breaking backward compatibility with Ver. 1.0 mini > drivers. > - *! 18-Aug-1997 cr: Added explicit CDECL identifiers. > - *! 03-Feb-1996 gp: Changed behaviour of ISR_SimulateInt. > - *! 24-Jul-1996 gp: Created. > - */ > - > -#ifndef ISR_ > -#define ISR_ > -#include > -#include > - > -/* Interrupt Object handle: */ > - struct ISR_IRQ; > - > -/* ISR install type (private) */ > -#define ISR_MAILBOX10x0080 /* Arbitrary value */ > -#define ISR_MAILBOX2 0x0081 > - > -/* Temporary until the baseport defines it */ > -#define MAIL_U3_MPU_IRQ34 > -/* > - * ISR_PROC > - * Purpose: > - * Routine to service an interrupt. > - * Parameters: > - * pRefData: Ptr to user data: passed in via ISR_Install. > - * Returns: > - * TRUE if the interrupt was handled; FALSE otherwise. > - * Requires: > - * ISR code must be in locked memory. > - * All data touched must be locked. > - * No resources should be acquired within the ISR. > - * May only call asynchrounous services. > - * Ensures: > - * This routine must not affect the state of the physical PIC. > - * (i.e.; don't send an EOI). > - */ > - typed
Re: [PATCH] MUSB: Set INDEX register to 0 before accessing CONFIGDATA
On Thu, Sep 11, 2008 at 3:01 AM, Felipe Balbi <[EMAIL PROTECTED]> wrote: > On Mon, Sep 08, 2008 at 11:12:24AM +0800, Bryan Wu wrote: >> On Sun, Sep 7, 2008 at 1:04 PM, David Brownell <[EMAIL PROTECTED]> wrote: >> > On Thursday 04 September 2008, Gadiyar, Anand wrote: >> >> From: Anand Gadiyar <[EMAIL PROTECTED]> >> >> >> >> The Index register needs to be zero to access CONFIGDATA. >> >> musb_ep_select()will not set the MUSB_INDEX register unless INDEXED >> >> mode addressing is used. This change will set the register correctly >> >> in INDEXED as well as FLAT mode. >> >> >> >> Signed-off-by: Anand Gadiyar <[EMAIL PROTECTED]> >> >> CC: Ajay Kumar Gupta <[EMAIL PROTECTED]> >> > >> > ACK. I *know* it was originally written that way. I think >> > the change was one of the Blackfin patches ... I hope this >> > isn't one of those cases where the Blackfin version of this >> > core acts differently. (Like clearing that DMA IRQ status...) >> > >> >> For Blackfin, the register MUSB_CONFIGDATA is not exported out to software. >> So in the musb driver, Blackfin code can not access the MUSB_CONFIGDATA. >> The configuration is fixed in the software. > > What happens if you try to read/write to the register ? Does it screw up > things somehow or just ignores ?? > Since there is no such register MUSB_CONFIGDATA in Blackfin memory space, we can not access to such address. If we don't define this register, compiling will fail in Blackfin > If it just ignores (and same for the other unexistent registers) we can > drop that patch adding ifdefs to te register accesses otherwise we're > gonna have to think about another solution to abstract that. > Currently, I just added ifdefs to those registers which does not exist in Blackfin. I also want to find an elegant way to solve this difference instead of using ugly ifdefs here. -Bryan > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in twl4030backupbatt_voltage()
- Original Message - From: "Tony Lindgren" <[EMAIL PROTECTED]> To: "Madhusudhan Chikkature" <[EMAIL PROTECTED]> Cc: "Adrian Hunter" <[EMAIL PROTECTED]>; Sent: Wednesday, September 10, 2008 9:09 PM Subject: Re: Bug in twl4030backupbatt_voltage() >* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080910 06:12]: >> >> - Original Message - >> From: "Adrian Hunter" <[EMAIL PROTECTED]> >> To: "Tony Lindgren" <[EMAIL PROTECTED]> >> Cc: ; <[EMAIL PROTECTED]> >> Sent: Wednesday, September 10, 2008 12:58 PM >> Subject: Re: Bug in twl4030backupbatt_voltage() >> >> >> > Tony Lindgren wrote: >> >> * Adrian Hunter <[EMAIL PROTECTED]> [080903 08:08]: >> >>> In the omap tree, commit f91fd98be045bec9c18e13110f22dafd44cb84b5 >> >>> fixed a bug with the use of function twl4030_madc_conversion() >> >>> relating to the local variable 'struct twl4030_madc_request req' >> >>> not being fully initialised. >> >>> >> >>> The same problem appears to be in the function >> >>> twl4030backupbatt_voltage() which is in >> >>> drivers/power/twl4030_bci_battery.c >> >> >> >> Thanks, I'll initialize it to NULL. Wouldn't it have been easier just >> >> to write a patch instead of the description above? :) >> > >> > Apparently. >> > >> > There is also req.do_avg which should be zero, if you assume the >> > programmer's >> > intent was to have uninitialised members set to zero. >> I guess, I did not look at all the other members of the >> "twl4030_madc_request" structure. I might have missed it. >> The do_avg and func_cb fields can both be set to NULL. > > Can you please check the code and send a patch? Yes. I will do that. Regards, Madhu > > Thanks, > > Tony > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3][OMAP 3/4]table end for wcd command definitions
Thanks for your comments. From: "ext Russell King - ARM Linux" <[EMAIL PROTECTED]> Subject: Re: [PATCH 2/3][OMAP 3/4]table end for wcd command definitions Date: Wed, 10 Sep 2008 20:38:30 +0100 > On Wed, Sep 10, 2008 at 08:44:14AM -0700, Tony Lindgren wrote: > > * Hiroshi DOYU <[EMAIL PROTECTED]> [080909 21:08]: > > > Hi, > > > > > > Although this TI bridge patches are not integrated and a bit > > > independent S/W component, it would be nice to get some comments just > > > on this bridge header file location from kernel maintainer's > > > perspective. > > > > > > "arch/arm/plat-omap/include/mach/bridge" > > > or "arch/arm/plat-omap/include/bridge"? > > > > How about put the bridge specific headers under include/linux/dspbridge? > > Then you can have just the omap specific headers under > > arch/arm/plat-omap/include/mach. > > There's an advantage to having them under arch/arm/plat-omap/include/dspbridge > - it's portable. If ever they need to become more visible, they can be easily > moved to arch/arm/include/dspbridge or include/dspbridge instead. "arch/arm/plat-omap/include/dspbridge" sounds reasonable, at least, for the meanwhile. For this header file directory name, 'dsp' prefix is needed in "include/'dsp'bridge" because "bridge" is too generic naming and, instead, "drivers/'dsp'/bridge" has 'dsp' in its path already. Hiroshi DOYU -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Load triton2 scripts.
On Wed, Sep 10, 2008 at 5:08 PM, Tony Lindgren <[EMAIL PROTECTED]> wrote: > * Kalle Jokiniemi <[EMAIL PROTECTED]> [080825 03:28]: >> From: ext Peter 'p2' De Schrijver <[EMAIL PROTECTED]> >> >> This patch loads the triton2 (twl4030) with scripts that will cut off VDD1 >> and VDD2 voltages when SYS_OFF_MODE signal is set. > > Pushing today. I guess we should remove the CONFIG_DISABLE_HFCLK at > some point? This patch causes a build error due to a missing define: | CC drivers/i2c/chips/twl4030-power.o | drivers/i2c/chips/twl4030-power.c:152: error: 'RES_TYPE_R7' undeclared here (not in a function) Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][OMAP 3/4+] BRIDGE: Module ISR removed
This patch removes ISR module completely Signed-off-by: Fernando Guzman Lugo <[EMAIL PROTECTED]> --- arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h |1 - arch/arm/plat-omap/include/mach/bridge/io_sm.h|3 +- arch/arm/plat-omap/include/mach/bridge/isr.h | 154 drivers/dsp/bridge/pmgr/chnl.c|1 - drivers/dsp/bridge/services/isr.c | 261 - drivers/dsp/bridge/services/services.c| 10 +- drivers/dsp/bridge/wmd/_deh.h |2 - drivers/dsp/bridge/wmd/io_sm.c| 46 ++-- drivers/dsp/bridge/wmd/mmu_fault.c|6 +- drivers/dsp/bridge/wmd/mmu_fault.h|2 +- drivers/dsp/bridge/wmd/tiomap_sm.c|1 - drivers/dsp/bridge/wmd/ue_deh.c | 14 +- 12 files changed, 38 insertions(+), 463 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/bridge/isr.h delete mode 100644 drivers/dsp/bridge/services/isr.c diff --git a/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h b/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h index f6a6c69..4e82639 100644 --- a/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h +++ b/arch/arm/plat-omap/include/mach/bridge/_chnl_sm.h @@ -57,7 +57,6 @@ #include #include -#include #include #include diff --git a/arch/arm/plat-omap/include/mach/bridge/io_sm.h b/arch/arm/plat-omap/include/mach/bridge/io_sm.h index 413108f..892c06a 100644 --- a/arch/arm/plat-omap/include/mach/bridge/io_sm.h +++ b/arch/arm/plat-omap/include/mach/bridge/io_sm.h @@ -132,8 +132,7 @@ * Interrupts are disabled and EOI for this interrupt has been sent. * Ensures: */ - extern bool IO_ISR(IN void *pRefData); - + irqreturn_t IO_ISR(int irq, IN void *pRefData); /* * IO_RequestChnl * Purpose: diff --git a/arch/arm/plat-omap/include/mach/bridge/isr.h b/arch/arm/plat-omap/include/mach/bridge/isr.h deleted file mode 100644 index fb397bb..000 --- a/arch/arm/plat-omap/include/mach/bridge/isr.h +++ /dev/null @@ -1,154 +0,0 @@ -/* - * bridge/inc/isr.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Copyright (C) 2005-2006 Texas Instruments, Inc. - * - * This package 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. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - - -/* - * isr.h - * Purpose: - * Interrupt services. - * - * Public Functions: - * ISR_Exit - * ISR_Init - * ISR_Install - * ISR_Uninstall - * - * Notes: - * - *! Revision History: - *! - *! 01-Mar-2004 vp: Added IVA related functions. - *! 06-Feb-2003 kc: Added ISR_MAILBOX1 (renamed from DSP_MAILBOX1). - *! 05-Nov-2001 kc: Added interrupt type param to ISR_Install. - *! 31-Jan-2000 rr: Comments modified after code review. - *! 29-Oct-1999 kc: Moved header files to within ifdefed 'extern "C"'. - *! 17-Sep-1997 gp: Added CFG_HOSTRES struct as argument to ISR_Install, thus - *! breaking backward compatibility with Ver. 1.0 mini drivers. - *! 18-Aug-1997 cr: Added explicit CDECL identifiers. - *! 03-Feb-1996 gp: Changed behaviour of ISR_SimulateInt. - *! 24-Jul-1996 gp: Created. - */ - -#ifndef ISR_ -#define ISR_ -#include -#include - -/* Interrupt Object handle: */ - struct ISR_IRQ; - -/* ISR install type (private) */ -#define ISR_MAILBOX10x0080 /* Arbitrary value */ -#define ISR_MAILBOX2 0x0081 - -/* Temporary until the baseport defines it */ -#define MAIL_U3_MPU_IRQ34 -/* - * ISR_PROC - * Purpose: - * Routine to service an interrupt. - * Parameters: - * pRefData: Ptr to user data: passed in via ISR_Install. - * Returns: - * TRUE if the interrupt was handled; FALSE otherwise. - * Requires: - * ISR code must be in locked memory. - * All data touched must be locked. - * No resources should be acquired within the ISR. - * May only call asynchrounous services. - * Ensures: - * This routine must not affect the state of the physical PIC. - * (i.e.; don't send an EOI). - */ - typedef bool (CDECL *ISR_PROC) (void *pRefData); - -/* - * ISR_Exit - * Purpose: - * Discontinue usage of the ISR module. - * Parameters: - * Returns: - * Requires: - * ISR_Init() was previously called. - * Ensures: - * Resources acquired in ISR_Init() are freed. - */ - extern void CDECL ISR_Exit(); - -/* - * ISR_Init - * Purpose: - * Initialize the ISR module's private state. - * Parameters: - * Returns: - *
Re: [PATCH] Fixed CPU type check for OMAP3
* Tero Kristo <[EMAIL PROTECTED]> [080908 08:01]:
> ES version definitions were incorrect, also GP/EMU/SEC etc. types were not
> detected at all.
I've redone the id.c, the old one was getting messy for omap2. Maybe
try my patch I posted on Tuesday and see how it works for you?
Also one comment below.
> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/id.c |11 +--
> arch/arm/plat-omap/include/mach/cpu.h |2 +-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index a526c0f..290b88c 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
> { .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 },
> };
>
> +static const char omap3_revs[][4] = {
> + "1.0",
> + "2.0",
> + "2.1",
> + "3.0"
> +};
> +
> static struct omap_chip_id omap_chip;
>
> /**
> @@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
>* Note that rev cannot be used directly as ES1.0 uses value 0.
>*/
> if (hawkeye == 0xb7ae) {
> - system_rev = 0x3430 | ((1 + rev) << 12);
> - pr_info("OMAP%04x ES2.%i\n", system_rev >> 16, rev);
> + _set_system_rev(0x3430 | (rev << 12), rev);
> + pr_info("OMAP%04x ES%s\n", system_rev >> 16, omap3_revs[rev]);
> _set_omap_chip();
> return;
> diff --git a/arch/arm/plat-omap/include/mach/cpu.h
> b/arch/arm/plat-omap/include/mach/cpu.h
> index e046418..e170d29 100644
> --- a/arch/arm/plat-omap/include/mach/cpu.h
> +++ b/arch/arm/plat-omap/include/mach/cpu.h
> @@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
> #define OMAP3430_REV_ES1_0 0x3430
> #define OMAP3430_REV_ES2_0 0x34301000
> #define OMAP3430_REV_ES2_1 0x34302000
> -#define OMAP3430_REV_ES2_2 0x34303000
> +#define OMAP3430_REV_ES3_0 0x34303000
>
> /*
> * omap_chip bits
Are you sure ES3.0 gives a three for revision? I believe 2.2 had 3, or
is the revision register broken again?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Patch for Touch Screen noise on OMAP3EVM.
* A NAVEEN <[EMAIL PROTECTED]> [080907 23:09]:
>
>
> When git kernel tree is used on a OMAP3EVM board file for touch screen
> testing, it shows lot of jitter. With this patch the jitter can be
> reduced.
Ah but this applies, pushing today.
Tony
> Signed-off-by: Naveen Atmakuri <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-omap3evm.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 4963f0f..9a4784e 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -27,6 +27,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -132,8 +134,16 @@ static int ads7846_get_pendown_state(void)
> }
>
> struct ads7846_platform_data ads7846_config = {
> + .x_max = 0x0fff,
> + .y_max = 0x0fff,
> + .x_plate_ohms = 180,
> + .pressure_max = 255,
> + .debounce_max = 10,
> + .debounce_tol = 3,
> + .debounce_rep = 1,
> .get_pendown_state = ads7846_get_pendown_state,
> .keep_vref_on = 1,
> + .settle_delay_usecs = 150,
> };
>
> static struct omap2_mcspi_device_config ads7846_mcspi_config = {
> --
> 1.5.6
>
>
> Warm Regards,
> Naveen Atmakuri.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Patch for Touch Screen noise on OMAP3EVM.
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080907 22:54]:
>
>
> When git kernel tree is used on a OMAP3EVM board file for touch screen
> testing, it shows lot of jitter. With this patch the jitter can be
> reduced.
This does not seem to apply, can you please refresh?
Thanks,
Tony
> Signed-off-by: Naveen Atmakuri <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-omap3evm.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 4963f0f..9a4784e 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -27,6 +27,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -132,8 +134,16 @@ static int ads7846_get_pendown_state(void)
> }
>
> struct ads7846_platform_data ads7846_config = {
> + .x_max = 0x0fff,
> + .y_max = 0x0fff,
> + .x_plate_ohms = 180,
> + .pressure_max = 255,
> + .debounce_max = 10,
> + .debounce_tol = 3,
> + .debounce_rep = 1,
> .get_pendown_state = ads7846_get_pendown_state,
> .keep_vref_on = 1,
> + .settle_delay_usecs = 150,
> };
>
> static struct omap2_mcspi_device_config ads7846_mcspi_config = {
> --
> 1.5.6
>
> Warm Regards,
> Naveen Atmakuri.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] OMAP3 camera driver: OMAP34XXCAM: Add Sensors Support.
* Aguirre Rodriguez, Sergio Alberto <[EMAIL PROTECTED]> [080829 16:35]:
> From: Sergio Aguirre <[EMAIL PROTECTED]>
>
> OMAP34XX: CAM: Add Sensors Support
>
> This adds support in OMAP34xx SDP board file for Sensor and Lens
> driver.
Should this be in board-3430sdp-camera.c or something like that?
Tony
>
> Signed-off-by: Sergio Aguirre <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-3430sdp.c | 228
>
> 1 file changed, 228 insertions(+)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2008-08-25
> 11:00:18.0 -0500
> +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c2008-08-25
> 12:16:46.0 -0500
> @@ -42,6 +42,19 @@
> #include
> #include
>
> +#ifdef CONFIG_VIDEO_OMAP3
> +#include
> +#include <../drivers/media/video/omap34xxcam.h>
> +#include <../drivers/media/video/isp/ispreg.h>
> +#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
> +#include <../drivers/media/video/mt9p012.h>
> +#endif
> +#endif
> +
> +#ifdef CONFIG_VIDEO_DW9710
> +#include <../drivers/media/video/dw9710.h>
> +#endif
> +
> #include
> #include
> #include
> @@ -266,6 +279,216 @@
> },
> };
>
> +#ifdef CONFIG_VIDEO_DW9710
> +static int dw9710_lens_power_set(enum v4l2_power power)
> +{
> +
> + return 0;
> +}
> +
> +static int dw9710_lens_set_prv_data(void *priv)
> +{
> + struct omap34xxcam_hw_config *hwc = priv;
> +
> + hwc->dev_index = 0;
> + hwc->dev_minor = 0;
> + hwc->dev_type = OMAP34XXCAM_SLAVE_LENS;
> +
> + return 0;
> +}
> +
> +static struct dw9710_platform_data sdp3430_dw9710_platform_data = {
> + .power_set = dw9710_lens_power_set,
> + .priv_data_set = dw9710_lens_set_prv_data,
> +};
> +#endif
> +
> +#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
> +static void __iomem *fpga_map_addr;
> +
> +static struct omap34xxcam_sensor_config cam_hwc = {
> + .sensor_isp = 0,
> + .xclk = OMAP34XXCAM_XCLK_A,
> +};
> +
> +static void enable_fpga_vio_1v8(u8 enable)
> +{
> + u16 reg_val;
> +
> + fpga_map_addr = ioremap(DEBUG_BASE, 4096);
> + reg_val = readw(fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
> +
> + /* Ensure that the SPR_GPIO1_3v3 is 0 - powered off.. 1 is on */
> + if (reg_val & FPGA_SPR_GPIO1_3v3) {
> + reg_val |= FPGA_SPR_GPIO1_3v3;
> + reg_val |= FPGA_GPIO6_DIR_CTRL; /* output mode */
> + writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
> + /* give a few milli sec to settle down
> + * Let the sensor also settle down.. if required..
> + */
> + if (enable)
> + mdelay(10);
> + }
> +
> + if (enable) {
> + reg_val |= FPGA_SPR_GPIO1_3v3 | FPGA_GPIO6_DIR_CTRL;
> + writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
> + }
> + /* Vrise time for the voltage - should be less than 1 ms */
> + mdelay(1);
> +}
> +
> +static int mt9p012_sensor_set_prv_data(void *priv)
> +{
> + struct omap34xxcam_hw_config *hwc = priv;
> +
> + hwc->u.sensor.xclk = cam_hwc.xclk;
> + hwc->u.sensor.sensor_isp = cam_hwc.sensor_isp;
> + hwc->dev_index = 0;
> + hwc->dev_minor = 0;
> + hwc->dev_type = OMAP34XXCAM_SLAVE_SENSOR;
> + return 0;
> +}
> +
> +static struct isp_interface_config mt9p012_if_config = {
> + .ccdc_par_ser = ISP_PARLL,
> + .dataline_shift = 0x1,
> + .hsvs_syncdetect = ISPCTRL_SYNC_DETECT_VSRISE,
> + .vdint0_timing = 0x0,
> + .vdint1_timing = 0x0,
> + .strobe = 0x0,
> + .prestrobe = 0x0,
> + .shutter = 0x0,
> + .u.par.par_bridge = 0x0,
> + .u.par.par_clk_pol = 0x0,
> +};
> +
> +static int mt9p012_sensor_power_set(enum v4l2_power power)
> +{
> + switch (power) {
> + case V4L2_POWER_OFF:
> + /* Power Down Sequence */
> +#ifdef CONFIG_TWL4030_CORE
> + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> + VAUX_DEV_GRP_NONE, TWL4030_VAUX2_DEV_GRP);
> +#else
> +#error "no power companion board defined!"
> +#endif
> + enable_fpga_vio_1v8(0);
> + omap_free_gpio(MT9P012_RESET_GPIO);
> + iounmap(fpga_map_addr);
> + omap_free_gpio(MT9P012_STANDBY_GPIO);
> + break;
> + case V4L2_POWER_ON:
> + /* Power Up Sequence */
> + isp_configure_interface(&mt9p012_if_config);
> +
> + /* Request and configure gpio pins */
> + if (omap_request_gpio(MT9P012_STANDBY_GPIO) != 0) {
> + printk(KERN_WARNING "Could not request GPIO %d for "
> + "AF D88\n", MT9P012_STANDBY_GPIO);
> + return -EIO;
> + }
> +
> + /* Request and configure gpi
Re: [PATCH 14/15] OMAP3 camera driver: OMAP34XXCAM: Camera Base Address.
* Aguirre Rodriguez, Sergio Alberto <[EMAIL PROTECTED]> [080829 16:34]:
> From: Sergio Aguirre <[EMAIL PROTECTED]>
>
> ARM: OMAP: OMAP34XXCAM: Camera Base Address.
>
> Adding OMAP 3 Camera registers base address, and Platform Device.
Pushing today.
Tony
> Signed-off-by: Sergio Aguirre <[EMAIL PROTECTED]>
> Signed-off-by: Sameer Venkatraman <[EMAIL PROTECTED]>
> Signed-off-by: Mohit Jalori <[EMAIL PROTECTED]>
> ---
> arch/arm/plat-omap/include/mach-omap2/devices.c | 26
> ++
> arch/arm/plat-omap/include/plat-omap/include/mach/omap34xx.h |1 +
> 2 files changed, 27 insertions(+)
>
> --- a/arch/arm/plat-omap/include/mach/omap34xx.h
> +++ b/arch/arm/plat-omap/include/mach/omap34xx.h
> @@ -63,6 +63,7 @@
> #define OMAP2_CM_BASEOMAP3430_CM_BASE
> #define OMAP2_PRM_BASE OMAP3430_PRM_BASE
> #define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP34XX_IC_BASE)
> +#define OMAP34XX_CAMERA_BASE (L4_34XX_BASE + 0xBC000)
>
> #endif
>
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -50,6 +50,32 @@
> {
> platform_device_register(&omap_cam_device);
> }
> +
> +#elif defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
> +
> +static struct resource cam_resources[] = {
> + {
> + .start = OMAP34XX_CAMERA_BASE,
> + .end= OMAP34XX_CAMERA_BASE + 0x1B70,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = INT_34XX_CAM_IRQ,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
> +
> +static struct platform_device omap_cam_device = {
> + .name = "omap34xxcam",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(cam_resources),
> + .resource = cam_resources,
> +};
> +
> +static inline void omap_init_camera(void)
> +{
> + platform_device_register(&omap_cam_device);
> +}
> #else
> static inline void omap_init_camera(void)
> {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2: Fix definition of SGX clock register bits
* Daniel Stone <[EMAIL PROTECTED]> [080827 02:47]: > On Wed, Aug 27, 2008 at 12:50:37AM -0600, ext Paul Walmsley wrote: > > Hello Daniel, > > > > On Wed, 27 Aug 2008, Daniel Stone wrote: > > > > > Yep, looks fine to me: just wasn't really sure what to put. Should I > > > resend, or? > > > > yes, please resend - that will make it convenient for Tony to apply the > > patches. > > Hi, > I'll do that. Thanks a lot for the review. ping, any news on the updated patch? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESENDING][PATCH 1/2]OMAP3 NAND: Add NAND support on OMAP3430
* vimal singh <[EMAIL PROTECTED]> [080826 03:42]:
> From: Teerth Reddy <[EMAIL PROTECTED]>
>
> This patch adds NAND support on 3430sdp board
>
> Signed-off-by: Teerth Reddy <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-3430sdp-flash.c | 88
> --
> arch/arm/plat-omap/include/mach/gpmc.h| 10 +++
> 2 files changed, 93 insertions(+), 5 deletions(-)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp-flash.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp-flash.c
> +++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp-flash.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> static struct mtd_partition sdp_nor_partitions[] = {
> /* bootloader (U-Boot, etc) in first sector */
> @@ -137,6 +138,61 @@ static int sdp_onenand_setup(void __iome
> /* Onenand setup does nothing at present */
> return 0;
> }
> +
> +static struct mtd_partition sdp_nand_partitions[] = {
> + /* All the partition sizes are listed in terms of NAND block size */
> + {
> + .name = "X-Loader-NAND",
> + .offset = 0,
> + .size = 4 * (64 * 2048),
> + .mask_flags = MTD_WRITEABLE,/* force read-only */
> + },
> + {
> + .name = "U-Boot-NAND",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
> + .size = 4 * (64 * 2048),
> + .mask_flags = MTD_WRITEABLE,/* force read-only */
> + },
> + {
> + .name = "Boot Env-NAND",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x10 */
> + .size = 2 * (64 * 2048),
> + },
> + {
> + .name = "Kernel-NAND",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x14 */
> + .size = 32 * (64 * 2048),
> + },
> + {
> + .name = "File System - NAND",
> + .size = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x54 */
> + },
> +};
> +
Can you please update this to use the SZ_.. defines for .size as done
now for sdp_nor_partitions?
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Load triton2 scripts.
* Kalle Jokiniemi <[EMAIL PROTECTED]> [080825 03:28]: > From: ext Peter 'p2' De Schrijver <[EMAIL PROTECTED]> > > This patch loads the triton2 (twl4030) with scripts that will cut off VDD1 > and VDD2 voltages when SYS_OFF_MODE signal is set. Pushing today. I guess we should remove the CONFIG_DISABLE_HFCLK at some point? Tony > Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]> > Signed-off-by: Kalle Jokiniemi <[EMAIL PROTECTED]> > --- > drivers/i2c/chips/Makefile|2 +- > drivers/i2c/chips/twl4030-power.c | 337 > + > 2 files changed, 338 insertions(+), 1 deletions(-) > create mode 100644 drivers/i2c/chips/twl4030-power.c > > diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile > index 9e245b1..ad5f5db 100644 > --- a/drivers/i2c/chips/Makefile > +++ b/drivers/i2c/chips/Makefile > @@ -24,7 +24,7 @@ obj-$(CONFIG_GPIOEXPANDER_OMAP) += gpio_expander_omap.o > obj-$(CONFIG_MENELAUS) += menelaus.o > obj-$(CONFIG_SENSORS_TSL2550)+= tsl2550.o > obj-$(CONFIG_SENSORS_TSL2563)+= tsl2563.o > -obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-pwrirq.o > +obj-$(CONFIG_TWL4030_CORE) += twl4030-core.o twl4030-pwrirq.o > twl4030-power.o > obj-$(CONFIG_TWL4030_GPIO) += twl4030-gpio.o > obj-$(CONFIG_TWL4030_USB)+= twl4030-usb.o > obj-$(CONFIG_TWL4030_POWEROFF) += twl4030-poweroff.o > diff --git a/drivers/i2c/chips/twl4030-power.c > b/drivers/i2c/chips/twl4030-power.c > new file mode 100644 > index 000..195c3c4 > --- /dev/null > +++ b/drivers/i2c/chips/twl4030-power.c > @@ -0,0 +1,337 @@ > +/* > + * linux/drivers/i2c/chips/twl4030-power.c > + * > + * Handle TWL4030 Power initialization > + * > + * Copyright (C) 2008 Nokia Corporation > + * Copyright (C) 2006 Texas Instruments, Inc > + * > + * Written byKalle Jokiniemi > + * Peter De Schrijver <[EMAIL PROTECTED]> > + * > + * This file is subject to the terms and conditions of the GNU General > + * Public License. See the file "COPYING" in the main directory of this > + * archive for more details. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#include > +#include > +#include > + > +#define PWR_P1_SW_EVENTS 0x10 > +#define PWR_DEVOFF (1<<0) > + > +#define PHY_TO_OFF_PM_MASTER(p) (p - 0x36) > +#define PHY_TO_OFF_PM_RECIEVER(p)(p - 0x5b) > + > +/* resource - hfclk */ > +#define R_HFCLKOUT_DEV_GRP PHY_TO_OFF_PM_RECIEVER(0xe6) > + > +/* PM events */ > +#define R_P1_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x46) > +#define R_P2_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x47) > +#define R_P3_SW_EVENTS PHY_TO_OFF_PM_MASTER(0x48) > +#define R_CFG_P1_TRANSITION PHY_TO_OFF_PM_MASTER(0x36) > +#define R_CFG_P2_TRANSITION PHY_TO_OFF_PM_MASTER(0x37) > +#define R_CFG_P3_TRANSITION PHY_TO_OFF_PM_MASTER(0x38) > + > +#define LVL_WAKEUP 0x08 > + > +#define ENABLE_WARMRESET (1<<4) > + > +/* sequence script */ > + > +#define END_OF_SCRIPT0x3f > + > +#define R_SEQ_ADD_A2SPHY_TO_OFF_PM_MASTER(0x55) > +#define R_SEQ_ADD_SA12 PHY_TO_OFF_PM_MASTER(0x56) > +#define R_SEQ_ADD_S2A3 PHY_TO_OFF_PM_MASTER(0x57) > +#define R_SEQ_ADD_WARM PHY_TO_OFF_PM_MASTER(0x58) > +#define R_MEMORY_ADDRESS PHY_TO_OFF_PM_MASTER(0x59) > +#define R_MEMORY_DATAPHY_TO_OFF_PM_MASTER(0x5a) > + > +/* Power bus message definitions */ > + > +#define DEV_GRP_NULL 0x0 > +#define DEV_GRP_P1 0x1 > +#define DEV_GRP_P2 0x2 > +#define DEV_GRP_P3 0x4 > + > +#define RES_GRP_RES 0x0 > +#define RES_GRP_PP 0x1 > +#define RES_GRP_RC 0x2 > +#define RES_GRP_PP_RC0x3 > +#define RES_GRP_PR 0x4 > +#define RES_GRP_PP_PR0x5 > +#define RES_GRP_RC_PR0x6 > +#define RES_GRP_ALL 0x7 > + > +#define RES_TYPE2_R0 0x0 > + > +#define RES_TYPE_ALL 0x7 > + > +#define RES_STATE_WRST 0xF > +#define RES_STATE_ACTIVE 0xE > +#define RES_STATE_SLEEP 0x8 > +#define RES_STATE_OFF0x0 > + > +/* > +*Power Bus Message Format > +* > +*Broadcast Message (16 Bits) > +*DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4] > +*RES_STATE[3:0] > +* > +*Singular Message (16 Bits) > +*DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0] > +* > +*/ > + > +#define MSG_BROADCAST(devgrp, grp, type, type2, state)
Re: HSMMC pending fixes
* Woodruff, Richard <[EMAIL PROTECTED]> [080818 14:09]:
> Hi,
>
> > [EMAIL PROTECTED] On Behalf Of Jarkko Lavinen
>
>
> > 2: Disable smartidle mode while suspending (workaround)
>
> This was the work around we had in internal trees for a long time.
>
> However Madhu C. recently updated this based on an internal investigation.
> It is required to reset the command pin to clear the system for sleep. This
> allows retention to work.
>
> The non-idle work around when profiled showed it was taking a huge amount of
> time for the clock re-enable to work. This actually would noticeably reduce
> MMC throughput when doing aggressive clock cutting in the driver and increase
> power usage.
>
> + } else {
> + OMAP_HSMMC_WRITE(host->base, SYSCTL,
> + OMAP_HSMMC_READ(host->base, SYSCTL) | SRD);
> + while (OMAP_HSMMC_READ(host->base, SYSCTL) & SRD) ;
>
> If you use a really long time out then perhaps it doesn't matter. But if you
> try and be aggressive it will hurt you.
Pushing all except the workaround. Madhu, can you please send a patch
for what Richard is describing?
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Add 3430 SDP board level support for HSMMC2
* David Brownell <[EMAIL PROTECTED]> [080908 12:26]: > On Wednesday 13 August 2008, Madhusudhan Chikkature wrote: > > > A better way to do this would be to let the boards say exactly > > > what the hardware configuration is, rather than requiring all > > > OMAP3 boards to be set up exactly like the SDP... > > > > I think the initial version was written specific to SDP. Later > > on it was changed to hsmmc.c and the platforms which required > > simillar setup as SDP started using it. > > Right ... > > > > Now, if support for a new board is required which is unlike SDP a > > new file can still be added for that perticular board, right? > > Each board already gets a board-XYZ.c file. So the clean way > to do this is to have that file set up its hsmmc config ... NOT > to clone versions of hsmmc.c for each board! Madhu, are you planning to abstract hsmmc.c further so various boards can use it? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Enable 4-bit in HSMMC1 and HSMMC2 platform data
* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080812 23:13]:
> From: Madhusudhan Chikkature<[EMAIL PROTECTED]>
>
> ARM: OMAP3: Enable 4-bit support for HSMMC.
>
> This patch provides the fix to enable 4-bit support for HSMMC.
Pushing today.
Tony
> Signed-off-by: Madhusudhan Chikkature<[EMAIL PROTECTED]>
> Signed-off-by: purushotam<[EMAIL PROTECTED]>
> ---
> arch/arm/plat-omap/devices.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-omap-2.6/arch/arm/plat-omap/devices.c
> ===
> --- linux-omap-2.6.orig/arch/arm/plat-omap/devices.c 2008-08-07
> 15:56:52.0 +0530
> +++ linux-omap-2.6/arch/arm/plat-omap/devices.c 2008-08-11
> 10:57:37.0
> +0530
> @@ -289,13 +289,17 @@ static void __init omap_init_mmc(void)
> mmc = &mmc_conf->mmc[0];
>
> if (cpu_is_omap2430() || cpu_is_omap34xx()) {
> - if (mmc->enabled)
> + if (mmc->enabled) {
> + mmc1_data.conf = *mmc;
> (void) platform_device_register(&mmc_omap_device1);
> + }
>
> #if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
> mmc = &mmc_conf->mmc[1];
> - if (mmc->enabled)
> + if (mmc->enabled) {
> + mmc2_data.conf = *mmc;
> (void) platform_device_register(&mmc_omap_device2);
> + }
> #endif
>
> return;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: fix memory corruption when using more than max endpoints
* Felipe Balbi <[EMAIL PROTECTED]> [080910 04:27]:
> On Wed, Sep 10, 2008 at 02:20:35PM +0300, ext Kevin Hilman wrote:
> > Felipe Balbi wrote:
> >> Let's keep linux-usb on the loop for musb related patches ;-)
> >>
> >> On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
> >>> There is no check if platform code passes in more endpoints (num_eps)
> >>> than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
> >>> that allocate_instance() happily writes past the end of 'struct musb'
> >>> corrupting memory.
> >>>
> >>> The fix below increases the max to 32 (used on omap3) and also adds a
> >>> BUG() if the platform code requests more than the max.
> >>>
> >>> This memory corruption was triggering various forms of crashes/panics
> >>> with kmem_cache_alloc() in the backtrace.
> >>>
> >>> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
> >>
> >> Looks ok, I'll put to my series.
> >>
> >>> ---
> >>> drivers/usb/musb/musb_core.c |1 +
> >>> drivers/usb/musb/musb_core.h |2 +-
> >>> 2 files changed, 2 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> >>> index c939f81..a132d9f 100644
> >>> --- a/drivers/usb/musb/musb_core.c
> >>> +++ b/drivers/usb/musb/musb_core.c
> >>> @@ -1806,6 +1806,7 @@ allocate_instance(struct device *dev,
> >>> musb->ctrl_base = mbase;
> >>> musb->nIrq = -ENODEV;
> >>> musb->config = config;
> >>> + BUG_ON(musb->config->num_eps > MUSB_C_NUM_EPS);
> >>
> >> It's good to have this check here.
> >>
> >>> for (epnum = 0, ep = musb->endpoints;
> >>> epnum < musb->config->num_eps;
> >>> epnum++, ep++) {
> >>> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> >>> index 8222725..5040ceb 100644
> >>> --- a/drivers/usb/musb/musb_core.h
> >>> +++ b/drivers/usb/musb/musb_core.h
> >>> @@ -153,7 +153,7 @@ static inline void musb_host_rx(struct musb *m, u8 e)
> >>> {}
> >>> /** CONSTANTS
> >>> /
> >>> #ifndef MUSB_C_NUM_EPS
> >>> -#define MUSB_C_NUM_EPS ((u8)16)
> >>> +#define MUSB_C_NUM_EPS ((u8)32)
> >>
> >> 16 is the right number.
> >>
> >
> > If 16 is the right number, arch/arm/mach-omap2/usb-musb.c going to trigger
> > this BUG every time since it sets num_eps = 32.
> >
> > I don't know much about MUSB enbpoints, but if 16 is the correct max, then
> > the platform code should be updated.
>
> Check recent Dave's patches to usb-musb.c ;-)
I guess you're talking about 8cc4af26d1e2b01cd9dc2c5e6b166d08946bc2e6
that I just pushed?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc3-omap1] tweak musb_hdrc SOC init code
* David Brownell <[EMAIL PROTECTED]> [080902 12:58]: > On Tuesday 02 September 2008, Felipe Balbi wrote: > > > > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > > > Acked-by: Felipe Balbi <[EMAIL PROTECTED]> > > > > > + > > > + /* REVISIT charge pump on TWL4030 can supply up to > > > + * 100 mA ... but this value is board-specific, like > > > + * "mode", and should be passed to usb_musb_init(). > > > + */ > > > + .power = 50, /* up to 100 mA */ > > > > We can add some parameters to usb_musb_init(); > > Something similar should be done to hsmmc_init(), as of now it only > > registers one slot and some boards have more than one. > > Let's wait till the twl4030 usb init gets some board-specific > parameterization. The MUSB init code should be called after > the TWL4030 is initialized, so it can use TWL facilities right > away. Pushing this to l-o tree today. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 clock: remove extra init from csi2_96m_fck
* Paul Walmsley <[EMAIL PROTECTED]> [080909 09:59]:
>
> csi2_96m_fck no longer should attempt to init its clockdomain pointer; the
> clock framework now does this by default. Applies on top of the "Update
> powerdomains and clockdomains" series sent earlier.
>
> Verified on 3430SDP ES2.
Pushing today.
Tony
>
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/clock34xx.h |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
> index 65568c3..56ae83f 100644
> --- a/arch/arm/mach-omap2/clock34xx.h
> +++ b/arch/arm/mach-omap2/clock34xx.h
> @@ -2298,7 +2298,6 @@ static struct clk cam_ick = {
> static struct clk csi2_96m_fck = {
> .name = "csi2_96m_fck",
> .parent = &core_96m_fck,
> - .init = &omap2_init_clk_clkdm,
> .enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430_CAM_MOD, CM_FCLKEN),
> .enable_bit = OMAP3430_EN_CSI2_SHIFT,
> .flags = CLOCK_IN_OMAP343X,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix occasional i2c driver hang
* Jason Marini <[EMAIL PROTECTED]> [080828 12:31]:
> The i2c driver contains a while loop that has no timeout. If i2c is in a
> funky state and OMAP_I2C_CON_STT remains asserted, the kernel hangs. Insert
> the standard i2c timeout into the loop.
Pushing today.
Tony
> Signed-off-by: Jason P Marini <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 3c4e581..3a7b6ef 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -440,9 +440,16 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
>
> if (dev->b_hw && stop) {
> + unsigned long delay = jiffies + OMAP_I2C_TIMEOUT;
> +
> /* H/w behavior: dont write stt and stp together.. */
> while (omap_i2c_read_reg(dev, OMAP_I2C_CON_REG) &
> OMAP_I2C_CON_STT) {
> - /* Dont do anything - this will come in a couple of
> loops at max*/
> + /* Let the user know if i2c is in a bad state */
> + if (time_after (jiffies, delay)) {
> + dev_err(dev->dev, "controller timed out "
> + "waiting for start condition to finish\n");
> + return -ETIMEDOUT;
> + }
> }
> w |= OMAP_I2C_CON_STP;
> w &= ~OMAP_I2C_CON_STT;
> --
> 1.5.5.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap24xx is broken in current head
* Tony Lindgren <[EMAIL PROTECTED]> [080811 08:32]: > * Koen Kooi <[EMAIL PROTECTED]> [080811 18:00]: > > > > Op 11 aug 2008, om 16:50 heeft Tony Lindgren het volgende geschreven: > > > >> * Igor Stoppa <[EMAIL PROTECTED]> [080810 20:39]: > >>> On Sun, 2008-08-10 at 14:37 +0200, ext Koen Kooi wrote: > >>> > "Broken as hell" if you want to do anything NEON related with it. > >>> > >>> yup > >>> Very unlucky but very true. > I > use 2007q3 with the -Os fix for compiling omap3 kernels > >>> > >>> Felipe: that's also what we should use internally, since it's the > >>> only > >>> one approved by our system performance team. > >> > >> I'll revert this patch for now to avoid adding a compiler dependency > >> as we already have a pile of other issues to solve. > > > > Speaking of compiler dependencies, how about applying my patch that > > enable vanilla gcc to compile the kernel? Russel (or Erik) seems to be > > fond of rejecting my mails to the LAKML list, so I can't post it there. A > > copy of it can be found here: > > > > http://ewi546.ewi.utwente.nl/git/?p=openembedded.git;a=blob;f=packages/linux/linux-omap2-git/beagleboard/no-harry-potter.diff;h=2bb20ab9c025312fcf0434de5bcb88aeceb4f87f;hb=HEAD > > That seems like a good patch, you should see what the issue is with > posting to LAKML. Maybe add it to Russell's patch system meanwhile? :) > > Meanwhile, yeah I'd say if that works on more compilers, let's add it > to l-o tree. I still don't see this patch anywhere.. Koen, what's your mail problem with LAKML? Maybe Russell can help with this issue? Anyways, I'll apply this to l-o tree. Seems like the dash is the right naming according to this: http://sourceware.org/ml/binutils/2006-12/msg00149.html Tony > > Tony > > > > regards, > > > > Koen > > > >> > >> > >> Let's plan on re-applying this patch once the other issues are out of > >> the way. > >> > >> Tony > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-omap" > >> in > >> the body of a message to [EMAIL PROTECTED] > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patch for proper Cortex-A8 cache configuration output
* Tony Lindgren <[EMAIL PROTECTED]> [080808 03:41]: > * Dirk Behme <[EMAIL PROTECTED]> [080807 19:38]: > > > > Recent ARM kernel doesn't detect and output Cortex-A8 cache > > configuration correctly. Result is something like this in kernel's boot > > messages: > > > > -- cut -- > > ... > > CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f > > ... > > CPU0: D VIPT write-through cache > > CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets > > ... > > -- cut -- > > > > Catalin sent a patch for this to linux-arm-kernel list: > > > > http://lists.arm.linux.org.uk/lurker/message/20080704.150532.983f01ca.en.html > > > > Result: > > > > -- cut -- > > ... > > CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3 > > CPU0: Level 1 cache is separate instruction and data > > CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, > > supports RA > > CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets, > > supports RA WB WT > > CPU0: Level 2 cache is unified > > CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 > > sets, > > supports WA RA WB WT > > ... > > -- cut -- > > > > Some people really like this and this patch is used in some private > > trees, e.g. for BeagleBoard. > > > > Unfortunately, RMK doesn't like the patch. He prefers to completely > > remove 'broken' configuration output completely. > > > > What's about applying this patch locally to OMAP git until upstream ARM > > kernel has a fix/remove solution for this? > > Yeah, let's try it out next week after updating to rc2. There will be > also move of the headers to go under plat-omap, so let's get all that > done first. I guess Catalin will submit his patch at some point after 2.6.28 opens. I'll apply it l-o tree, and remove the L2 debug info we had in id.c to clean up id.c in the future patches. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: testers wanted: isp1301_omap conversion to new-style i2c driver
Hi, * Felipe Balbi <[EMAIL PROTECTED]> [080821 07:47]: > On Fri, Aug 08, 2008 at 12:45:52PM +0300, Tony Lindgren wrote: > > Yeah, I will add it to linux-omap for testing for sure. This should be > > easy to test though, it either works or does not.. But we need to find > > somebody to boot it and connect USB cable to it :) > > Hi Carlos, > > could you test it for us on H2 ?? > > Do you guys still have H2 boards there ? Jean, sorry for the long delay on getting this tested. Here's what happens on H2 after Felipe's and your isp_1301.c patches: # otg: b_idle, SWITCH to gadget, ctrl 018021 otg: a_idle, SWITCH to host, ctrl 080021 otg: a_vbus_err, VBUS_ERR 2000 ctrl 140821 hub 1-0:1.0: unable to enumerate USB device on port 2 So things work the same as before them. Here's my ack for the following patches: i2c/isp1301_omap: Convert to a new-style i2c driver, part 1 i2c/isp1301_omap: Convert to a new-style i2c driver, part 2 Acked-by: Tony Lindgren <[EMAIL PROTECTED]> Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3][OMAP 3/4]table end for wcd command definitions
On Wed, Sep 10, 2008 at 08:44:14AM -0700, Tony Lindgren wrote: > * Hiroshi DOYU <[EMAIL PROTECTED]> [080909 21:08]: > > Hi, > > > > Although this TI bridge patches are not integrated and a bit > > independent S/W component, it would be nice to get some comments just > > on this bridge header file location from kernel maintainer's > > perspective. > > > > "arch/arm/plat-omap/include/mach/bridge" > > or "arch/arm/plat-omap/include/bridge"? > > How about put the bridge specific headers under include/linux/dspbridge? > Then you can have just the omap specific headers under > arch/arm/plat-omap/include/mach. There's an advantage to having them under arch/arm/plat-omap/include/dspbridge - it's portable. If ever they need to become more visible, they can be easily moved to arch/arm/include/dspbridge or include/dspbridge instead. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omapzoom tree broken?
On Tue, Sep 09, 2008 at 07:54:15PM +0100, Russell King - ARM Linux wrote: > Looks like the pack index was corrupted; removing the one it just fetched > and repulling has made it happier. > > However, it's made me unhappier. Again, can we please have it accessible > via the git protocol. Or at least can whoever looks after that tree avoid > repacking it except maybe once a month? > > Why? I don't want to have to keep on fetching 300 odd MB of pack files > every time I pull from this tree. 10 minutes into my current pull and > I only have 80MB... another 220MB to go. IOW, 45 minutes for a pull. > > This really isn't practical. Sure, repacking should be avoided on servers for that. Do what you want with your local copy and repack sure helps making git a bit faster, still it's not good for the server side since we'd have to pull the packs again and again. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: Set INDEX register to 0 before accessing CONFIGDATA
On Mon, Sep 08, 2008 at 11:12:24AM +0800, Bryan Wu wrote: > On Sun, Sep 7, 2008 at 1:04 PM, David Brownell <[EMAIL PROTECTED]> wrote: > > On Thursday 04 September 2008, Gadiyar, Anand wrote: > >> From: Anand Gadiyar <[EMAIL PROTECTED]> > >> > >> The Index register needs to be zero to access CONFIGDATA. > >> musb_ep_select()will not set the MUSB_INDEX register unless INDEXED > >> mode addressing is used. This change will set the register correctly > >> in INDEXED as well as FLAT mode. > >> > >> Signed-off-by: Anand Gadiyar <[EMAIL PROTECTED]> > >> CC: Ajay Kumar Gupta <[EMAIL PROTECTED]> > > > > ACK. I *know* it was originally written that way. I think > > the change was one of the Blackfin patches ... I hope this > > isn't one of those cases where the Blackfin version of this > > core acts differently. (Like clearing that DMA IRQ status...) > > > > For Blackfin, the register MUSB_CONFIGDATA is not exported out to software. > So in the musb driver, Blackfin code can not access the MUSB_CONFIGDATA. > The configuration is fixed in the software. What happens if you try to read/write to the register ? Does it screw up things somehow or just ignores ?? If it just ignores (and same for the other unexistent registers) we can drop that patch adding ifdefs to te register accesses otherwise we're gonna have to think about another solution to abstract that. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM:OMAP3: Smartreflex disable/enable fix
* Kalle Jokiniemi <[EMAIL PROTECTED]> [080829 04:54]: > On pe, 2008-08-29 at 11:47 +0100, ext Russell King - ARM Linux wrote: > > On Fri, Aug 29, 2008 at 01:05:44PM +0300, Kalle Jokiniemi wrote: > > > Smartreflex modules have to be disabled when device enters WFI. > > > Previously only suspend idle path had these calls. By moving the > > > disable/enable calls to omap_sram_idle, all idle paths will be covered. > > > > Won't deleting the calls from the suspend path break suspend/resume? > > No, since omap3_pm_suspend calls omap_sram_idle. The disabling is just > moves one step later. Also omap3_pm_idle and the idle loop in cpu idle > call omap_sram_idle, so they get covered as well. Pushing today. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: remove wrong scale call for gfx_plane
* arun c <[EMAIL PROTECTED]> [080909 00:47]: > The gfx_plane doesn't support scaling. Pushing today. Tony > > Signed-off-by: Arun C <[EMAIL PROTECTED]> > --- > drivers/video/omap/dispc.c |3 +-- > drivers/video/omap/omapfb_main.c |6 -- > 2 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c > index 82ba030..ce4c4de 100644 > --- a/drivers/video/omap/dispc.c > +++ b/drivers/video/omap/dispc.c > @@ -519,8 +519,7 @@ static int omap_dispc_set_scale(int plane, > if ((unsigned)plane > OMAPFB_PLANE_NUM) > return -ENODEV; > > - if (plane == OMAPFB_PLANE_GFX && > - (out_width != orig_width || out_height != orig_height)) > + if (out_width != orig_width || out_height != orig_height) > return -EINVAL; > > enable_lcd_clocks(1); > diff --git a/drivers/video/omap/omapfb_main.c > b/drivers/video/omap/omapfb_main.c > index 1ffe74c..d176a2c 100644 > --- a/drivers/video/omap/omapfb_main.c > +++ b/drivers/video/omap/omapfb_main.c > @@ -223,13 +223,15 @@ static int ctrl_change_mode(struct fb_info *fbi) > if((r = fbdev->ctrl->set_rotate(var->rotate)) < 0) > return r; > > - if (fbdev->ctrl->set_scale != NULL) > + if ((fbdev->ctrl->set_scale != NULL) && (plane->idx > 0)) > r = fbdev->ctrl->set_scale(plane->idx, > var->xres, var->yres, > plane->info.out_width, > plane->info.out_height); > + if (r < 0) > + return r; > > - return r; > + return 0; > } > > /* > -- > 1.5.3.4 > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: Fix omapfb's problem on OMAP3430sdp
* stanley.miao <[EMAIL PROTECTED]> [080907 20:28]:
> Prune off a empty line.
>
> Fix omapfb's problem on OMAP3430sdp.
Pushing today.
Tony
>
> ---
> drivers/video/omap/lcd_2430sdp.c | 17 +
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap/lcd_2430sdp.c
> b/drivers/video/omap/lcd_2430sdp.c
> index 9af6cd0..b456e02 100644
> --- a/drivers/video/omap/lcd_2430sdp.c
> +++ b/drivers/video/omap/lcd_2430sdp.c
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include
> @@ -45,6 +46,10 @@ static unsigned enable_gpio;
> #define ENABLE_VAUX3_DEDICATED 0x03
> #define ENABLE_VAUX3_DEV_GRP 0x20
>
> +#define ENABLE_VPLL2_DEDICATED 0x05
> +#define ENABLE_VPLL2_DEV_GRP0xE0
> +#define TWL4030_VPLL2_DEV_GRP 0x33
> +#define TWL4030_VPLL2_DEDICATED 0x36
>
> #define t2_out(c, r, v) twl4030_i2c_write_u8(c, r, v)
>
> @@ -82,6 +87,13 @@ static int sdp2430_panel_enable(struct lcd_panel
> *panel)
> ded_val = ENABLE_VAUX3_DEDICATED;
> grp_reg = TWL4030_VAUX3_DEV_GRP;
> grp_val = ENABLE_VAUX3_DEV_GRP;
> +
> + if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
> + t2_out(PM_RECEIVER, ENABLE_VPLL2_DEDICATED,
> + TWL4030_VPLL2_DEDICATED);
> + t2_out(PM_RECEIVER, ENABLE_VPLL2_DEV_GRP,
> + TWL4030_VPLL2_DEV_GRP);
> + }
> } else {
> ded_reg = TWL4030_VAUX2_DEDICATED;
> ded_val = ENABLE_VAUX2_DEDICATED;
> @@ -104,6 +116,11 @@ static void sdp2430_panel_disable(struct lcd_panel
> *panel)
> {
> omap_set_gpio_dataout(enable_gpio, 0);
> omap_set_gpio_dataout(backlight_gpio, 0);
> + if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
> + t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEDICATED);
> + t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEV_GRP);
> + mdelay(4);
> + }
> }
>
> static unsigned long sdp2430_panel_get_caps(struct lcd_panel *panel)
> --
> 1.5.6.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] This patch fixes the typo which breaks the build on OMAP1
* Jarkko Nikula <[EMAIL PROTECTED]> [080910 00:19]:
> On Tue, 9 Sep 2008 13:10:59 +0530
> "ext Arun KS" <[EMAIL PROTECTED]> wrote:
>
> > diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
> > index a217cf2..3a4cc4b 100644
> > --- a/sound/soc/omap/omap-mcbsp.c
> > +++ b/sound/soc/omap/omap-mcbsp.c
> > @@ -96,7 +96,7 @@ static const int omap24xx_dma_reqs[][2] = {
> > #endif
> > };
> > #else
> > -static const int omap2420_dma_reqs[][2] = {};
> > +static const int omap24xx_dma_reqs[][2] = {};
> > #endif
> >
> Thanks, this is true. Is it ok if I add this fix directly in my
> original patch when I have chance to send it to alsa-devel?
Pushing today to l-o tree.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 clock: camera module has no target IDLEST bit
Hello Russell, On Fri, 5 Sep 2008, Russell King - ARM Linux wrote: > On Fri, Sep 05, 2008 at 01:34:03PM -0600, Paul Walmsley wrote: > > We must not attempt to wait for the CAM module to become ready after > > clock enable, since it has no target IDLEST bit. > > Grrr. These things seem to be collecting here, and in need of a > more generic and elegant solution. (Please always do that rather > than extending an already existing hack.) OK, I will send some patches to clean up that function somewhat also. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/12] OMAP3 clock: remove duplicate call to omap2_init_clk_clkdm()
The OMAP3 arch clock init code already calls omap2_init_clk_clkdm(), so there
is no reason to call it again in the per-clock init.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h | 18 --
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 8fe87e3..56ae83f 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1337,7 +1337,6 @@ static struct clk gfx_l3_ick = {
static struct clk gfx_cg1_ck = {
.name = "gfx_cg1_ck",
.parent = &gfx_l3_fck, /* REVISIT: correct? */
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP3430ES1_EN_2D_SHIFT,
.flags = CLOCK_IN_OMAP3430ES1,
@@ -1348,7 +1347,6 @@ static struct clk gfx_cg1_ck = {
static struct clk gfx_cg2_ck = {
.name = "gfx_cg2_ck",
.parent = &gfx_l3_fck, /* REVISIT: correct? */
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP3430ES1_EN_3D_SHIFT,
.flags = CLOCK_IN_OMAP3430ES1,
@@ -1392,7 +1390,6 @@ static struct clk sgx_fck = {
static struct clk sgx_ick = {
.name = "sgx_ick",
.parent = &l3_ick,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430ES2_SGX_MOD, CM_ICLKEN),
.enable_bit = OMAP3430ES2_EN_SGX_SHIFT,
.flags = CLOCK_IN_OMAP3430ES2,
@@ -1405,7 +1402,6 @@ static struct clk sgx_ick = {
static struct clk d2d_26m_fck = {
.name = "d2d_26m_fck",
.parent = &sys_ck,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430ES1_EN_D2D_SHIFT,
.flags = CLOCK_IN_OMAP3430ES1,
@@ -1768,7 +1764,6 @@ static struct clk ssi_sst_fck = {
static struct clk core_l3_ick = {
.name = "core_l3_ick",
.parent = &l3_ick,
- .init = &omap2_init_clk_clkdm,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
.clkdm = { .name = "core_l3_clkdm" },
@@ -1830,7 +1825,6 @@ static struct clk pka_ick = {
static struct clk core_l4_ick = {
.name = "core_l4_ick",
.parent = &l4_ick,
- .init = &omap2_init_clk_clkdm,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
.clkdm = { .name = "core_l4_clkdm" },
@@ -2230,7 +2224,6 @@ static struct clk dss1_alwon_fck = {
static struct clk dss_tv_fck = {
.name = "dss_tv_fck",
.parent = &omap_54m_fck,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_TV_SHIFT,
.flags = CLOCK_IN_OMAP343X,
@@ -2241,7 +2234,6 @@ static struct clk dss_tv_fck = {
static struct clk dss_96m_fck = {
.name = "dss_96m_fck",
.parent = &omap_96m_fck,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_TV_SHIFT,
.flags = CLOCK_IN_OMAP343X,
@@ -2252,7 +2244,6 @@ static struct clk dss_96m_fck = {
static struct clk dss2_alwon_fck = {
.name = "dss2_alwon_fck",
.parent = &sys_ck,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_DSS2_SHIFT,
.flags = CLOCK_IN_OMAP343X,
@@ -2264,7 +2255,6 @@ static struct clk dss_ick = {
/* Handles both L3 and L4 clocks */
.name = "dss_ick",
.parent = &l4_ick,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, CM_ICLKEN),
.enable_bit = OMAP3430_CM_ICLKEN_DSS_EN_DSS_SHIFT,
.flags = CLOCK_IN_OMAP343X,
@@ -2298,7 +2288,6 @@ static struct clk cam_ick = {
/* Handles both L3 and L4 clocks */
.name = "cam_ick",
.parent = &l4_ick,
- .init = &omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430_CAM_MOD, CM_ICLKEN),
.enable_bit = OMAP3430_EN_CAM_SHIFT,
.flags = CLOCK_IN_OMAP343X,
@@ -2309,7 +2298,6 @@ static struct clk cam_ick = {
static struct clk csi2_96m_fck = {
.name = "csi2_96m_fck",
.parent = &core_96m_fck,
- .init
[PATCH v2 10/12] OMAP2 clockdomain: add virt_opp_clkdm
Every OMAP2/3 clock will need to be associated with a clockdomain.
However, the "virt_prcm_set" clock has no clockdomain, since it is a
virtual clock without any hardware referents. So, create a new
clockdomain, "virt_clkdm", for this clock. This clockdomain should be
reusable for OMAP3 virtual clock nodes.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock24xx.h|1 +
arch/arm/mach-omap2/clockdomains.h | 11 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index e339f6d..63349fa 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -2666,6 +2666,7 @@ static struct clk virt_prcm_set = {
.name = "virt_prcm_set",
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
VIRTUAL_CLOCK | ALWAYS_ENABLED | DELAYED_APP,
+ .clkdm = { .name = "virt_opp_clkdm" },
.parent = &mpu_ck, /* Indexed by mpu speed, no parent */
.recalc = &omap2_table_mpu_recalc, /* sets are keyed on
mpu rate */
.set_rate = &omap2_select_table_rate,
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 5234be1..bafa650 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -34,6 +34,16 @@ static struct clockdomain cm_clkdm = {
};
/*
+ * virt_opp_clkdm is intended solely for use with virtual OPP clocks,
+ * e.g., virt_prcm_set, until OPP handling is rationalized.
+ */
+static struct clockdomain virt_opp_clkdm = {
+ .name = "virt_opp_clkdm",
+ .pwrdm = { .name = "wkup_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX),
+};
+
+/*
* 2420-only clockdomains
*/
@@ -307,6 +317,7 @@ static struct clockdomain *clockdomains_omap[] = {
&cm_clkdm,
&prm_clkdm,
+ &virt_opp_clkdm,
#ifdef CONFIG_ARCH_OMAP2420
&mpu_2420_clkdm,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/12] OMAP3 PRCM: add DPLL1-5 powerdomains, clockdomains
Each DPLL exists in its own powerdomain (cf 34xx TRM figure 4-18) and
clockdomain; so, create powerdomain and clockdomain structures for them.
These are used in a following patch for DPLL-related clocks.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clockdomains.h | 35
arch/arm/mach-omap2/powerdomains.h |5 +
arch/arm/mach-omap2/powerdomains34xx.h | 31
3 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index 2156668..5234be1 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -249,6 +249,36 @@ static struct clockdomain emu_clkdm = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+static struct clockdomain dpll1_clkdm = {
+ .name = "dpll1_clkdm",
+ .pwrdm = { .name = "dpll1_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct clockdomain dpll2_clkdm = {
+ .name = "dpll2_clkdm",
+ .pwrdm = { .name = "dpll2_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct clockdomain dpll3_clkdm = {
+ .name = "dpll3_clkdm",
+ .pwrdm = { .name = "dpll3_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct clockdomain dpll4_clkdm = {
+ .name = "dpll4_clkdm",
+ .pwrdm = { .name = "dpll4_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct clockdomain dpll5_clkdm = {
+ .name = "dpll5_clkdm",
+ .pwrdm = { .name = "dpll5_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+};
+
#endif /* CONFIG_ARCH_OMAP34XX */
/*
@@ -310,6 +340,11 @@ static struct clockdomain *clockdomains_omap[] = {
&usbhost_clkdm,
&per_clkdm,
&emu_clkdm,
+ &dpll1_clkdm,
+ &dpll2_clkdm,
+ &dpll3_clkdm,
+ &dpll4_clkdm,
+ &dpll5_clkdm,
#endif
NULL,
diff --git a/arch/arm/mach-omap2/powerdomains.h
b/arch/arm/mach-omap2/powerdomains.h
index fba3440..51623e2 100644
--- a/arch/arm/mach-omap2/powerdomains.h
+++ b/arch/arm/mach-omap2/powerdomains.h
@@ -179,6 +179,11 @@ static struct powerdomain *powerdomains_omap[] __initdata
= {
&emu_pwrdm,
&sgx_pwrdm,
&usbhost_pwrdm,
+ &dpll1_pwrdm,
+ &dpll2_pwrdm,
+ &dpll3_pwrdm,
+ &dpll4_pwrdm,
+ &dpll5_pwrdm,
#endif
NULL
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index adbfa91..446a1ed 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -341,6 +341,37 @@ static struct powerdomain usbhost_pwrdm = {
},
};
+static struct powerdomain dpll1_pwrdm = {
+ .name = "dpll1_pwrdm",
+ .prcm_offs = MPU_MOD,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct powerdomain dpll2_pwrdm = {
+ .name = "dpll2_pwrdm",
+ .prcm_offs = OMAP3430_IVA2_MOD,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct powerdomain dpll3_pwrdm = {
+ .name = "dpll3_pwrdm",
+ .prcm_offs = PLL_MOD,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct powerdomain dpll4_pwrdm = {
+ .name = "dpll4_pwrdm",
+ .prcm_offs = PLL_MOD,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+static struct powerdomain dpll5_pwrdm = {
+ .name = "dpll5_pwrdm",
+ .prcm_offs = PLL_MOD,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
+};
+
+
#endif/* CONFIG_ARCH_OMAP34XX */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/12] OMAP2/3 clock: warn if clock is missing clockdomain
At this point, all OMAP2/3 clocks should be associated with a clockdomain.
Warn in clk_register() if any are missing a clockdomain
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 88c8ef4..eee5511 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -78,8 +78,10 @@ void omap2_init_clk_clkdm(struct clk *clk)
{
struct clockdomain *clkdm;
- if (!clk->clkdm.name)
+ if (!clk->clkdm.name) {
+ pr_err("clock: %s: missing clockdomain", clk->name);
return;
+ }
clkdm = clkdm_lookup(clk->clkdm.name);
if (clkdm) {
@@ -87,8 +89,8 @@ void omap2_init_clk_clkdm(struct clk *clk)
clk->name, clk->clkdm.name);
clk->clkdm.ptr = clkdm;
} else {
- pr_debug("clock: could not associate clk %s to "
-"clkdm %s\n", clk->name, clk->clkdm.name);
+ pr_err("clock: %s: could not associate to clkdm %s\n",
+ clk->name, clk->clkdm.name);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/12] OMAP3 clock: mark DPLL clocks with their DPLLx clockdomains
Mark each DPLL clock as belonging to their respective DPLL clockdomain.
cf. 34xx TRM Table 4-27 (among other references).
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 0c2acea..682f43a 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -323,6 +323,7 @@ static struct clk dpll1_ck = {
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES | ALWAYS_ENABLED,
.round_rate = &omap2_dpll_round_rate,
.set_rate = &omap3_noncore_dpll_set_rate,
+ .clkdm = { .name = "dpll1_clkdm" },
.recalc = &omap3_dpll_recalc,
};
@@ -335,6 +336,7 @@ static struct clk dpll1_x2_ck = {
.parent = &dpll1_ck,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll1_clkdm" },
.recalc = &omap3_clkoutx2_recalc,
};
@@ -357,6 +359,7 @@ static struct clk dpll1_x2m2_ck = {
.clksel = div16_dpll1_x2m2_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll1_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -394,6 +397,7 @@ static struct clk dpll2_ck = {
.disable= &omap3_noncore_dpll_disable,
.round_rate = &omap2_dpll_round_rate,
.set_rate = &omap3_noncore_dpll_set_rate,
+ .clkdm = { .name = "dpll2_clkdm" },
.recalc = &omap3_dpll_recalc,
};
@@ -416,6 +420,7 @@ static struct clk dpll2_m2_ck = {
.clksel = div16_dpll2_m2x2_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll2_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -447,6 +452,7 @@ static struct clk dpll3_ck = {
.dpll_data = &dpll3_dd,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES | ALWAYS_ENABLED,
.round_rate = &omap2_dpll_round_rate,
+ .clkdm = { .name = "dpll3_clkdm" },
.recalc = &omap3_dpll_recalc,
};
@@ -459,6 +465,7 @@ static struct clk dpll3_x2_ck = {
.parent = &dpll3_ck,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll3_clkdm" },
.recalc = &omap3_clkoutx2_recalc,
};
@@ -512,6 +519,7 @@ static struct clk dpll3_m2_ck = {
.clksel = div31_dpll3m2_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll3_clkdm" },
.round_rate = &omap2_clksel_round_rate,
.set_rate = &omap3_core_dpll_m2_set_rate,
.recalc = &omap2_clksel_recalc,
@@ -549,6 +557,7 @@ static struct clk dpll3_m2x2_ck = {
.clksel = dpll3_m2x2_ck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll3_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -568,6 +577,7 @@ static struct clk dpll3_m3_ck = {
.clksel = div16_dpll3_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll3_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -578,6 +588,7 @@ static struct clk dpll3_m3x2_ck = {
.enable_reg = _OMAP34XX_CM_REGADDR(PLL_MOD, CM_CLKEN),
.enable_bit = OMAP3430_PWRDN_EMU_CORE_SHIFT,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES | INVERT_ENABLE,
+ .clkdm = { .name = "dpll3_clkdm" },
.recalc = &omap3_clkoutx2_recalc,
};
@@ -596,6 +607,7 @@ static struct clk emu_core_alwon_ck = {
.clksel = emu_core_alwon_ck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll3_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -631,6 +643,7 @@ static struct clk dpll4_ck = {
.disable= &omap3_noncore_dpll_disable,
.round_rate = &omap2_dpll_round_rate,
.set_rate = &omap3_noncore_dpll_set_rate,
+ .clkdm = { .name = "dpll4_clkdm" },
.recalc = &omap3_dpll_recalc,
};
@@ -644,6 +657,7 @@ static struct clk dpll4_x2_ck = {
.parent = &dpll4_ck,
.flags = CLOCK_IN
[PATCH v2 09/12] OMAP2/3 clock: note clockdomains for remaining clocks
Fill in clockdomains for all remaining clocks. On OMAP2, these mostly
involve IVA and DSP clocks; on OMAP3, these mostly involve some core_l4_clkdm
devices and the secure peripherals.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock24xx.h |7 ++-
arch/arm/mach-omap2/clock34xx.h | 26 +-
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 5845850..e339f6d 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -1090,12 +1090,13 @@ static struct clk dsp_irate_ick = {
.parent = &dsp_fck,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X | DELAYED_APP |
CONFIG_PARTICIPANT | PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dsp_clkdm" },
.clksel_reg = _CM_REG_OFFSET(OMAP24XX_DSP_MOD, CM_CLKSEL),
.clksel_mask= OMAP24XX_CLKSEL_DSP_IF_MASK,
.clksel = dsp_irate_ick_clksel,
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
- .set_rate = &omap2_clksel_set_rate
+ .set_rate = &omap2_clksel_set_rate
};
/* 2420 only */
@@ -1103,6 +1104,7 @@ static struct clk dsp_ick = {
.name = "dsp_ick", /* apparently ipi and isp */
.parent = &dsp_irate_ick,
.flags = CLOCK_IN_OMAP242X | DELAYED_APP | CONFIG_PARTICIPANT,
+ .clkdm = { .name = "dsp_clkdm" },
.enable_reg = _CM_REG_OFFSET(OMAP24XX_DSP_MOD, CM_ICLKEN),
.enable_bit = OMAP2420_EN_DSP_IPI_SHIFT, /* for ipi */
};
@@ -1112,6 +1114,7 @@ static struct clk iva2_1_ick = {
.name = "iva2_1_ick",
.parent = &dsp_irate_ick,
.flags = CLOCK_IN_OMAP243X | DELAYED_APP | CONFIG_PARTICIPANT,
+ .clkdm = { .name = "dsp_clkdm" },
.enable_reg = _CM_REG_OFFSET(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_CM_FCLKEN_DSP_EN_DSP_SHIFT,
};
@@ -1691,6 +1694,7 @@ static struct clk gpt7_ick = {
.name = "gpt7_ick",
.parent = &l4_ck,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X,
+ .clkdm = { .name = "core_l4_clkdm" },
.enable_reg = _CM_REG_OFFSET(CORE_MOD, CM_ICLKEN1),
.enable_bit = OMAP24XX_EN_GPT7_SHIFT,
.recalc = &followparent_recalc,
@@ -2586,6 +2590,7 @@ static struct clk mmchs2_fck = {
.id = 2,
.parent = &func_96m_ck,
.flags = CLOCK_IN_OMAP243X,
+ .clkdm = { .name = "core_l4_clkdm" },
.enable_reg = _CM_REG_OFFSET(CORE_MOD, OMAP24XX_CM_FCLKEN2),
.enable_bit = OMAP2430_EN_MMCHS2_SHIFT,
.recalc = &followparent_recalc,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 682f43a..8fe87e3 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -795,7 +795,7 @@ static struct clk virt_omap_54m_fck = {
.clksel = virt_omap_54m_fck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = "cm_clkdm" },
+ .clkdm = { .name = "dpll4_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -1020,6 +1020,7 @@ static struct clk omap_120m_fck = {
.clksel = omap_120m_fck_clksel,
.flags = CLOCK_IN_OMAP3430ES2 | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "dpll5_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -1175,6 +1176,7 @@ static struct clk arm_fck = {
.clksel = arm_fck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "mpu_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -1189,6 +1191,7 @@ static struct clk emu_mpu_alwon_ck = {
.parent = &mpu_ck,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "mpu_clkdm" },
.recalc = &followparent_recalc,
};
@@ -1306,6 +1309,7 @@ static struct clk gfx_l3_ck = {
.enable_reg = _OMAP34XX_CM_REGADDR(GFX_MOD, CM_ICLKEN),
.enable_bit = OMAP_EN_GFX_SHIFT,
.flags = CLOCK_IN_OMAP3430ES1,
+ .clkdm = { .name = "gfx_3430es1_clkdm" },
.recalc = &followparent_recalc,
};
@@ -1459,6 +1463,7 @@ static struct clk ts_fck = {
.enable_reg = _OMAP34XX_CM_REGADDR(CORE_MOD,
OMAP3430ES2_CM_FCLKEN3),
.enable_bit = OMAP3430ES2_EN
[PATCH v2 06/12] OMAP2/3 clockdomain: remove wkup_clkdm
Remove wkup_clkdm, as it has been completely replaced by prm_clkdm and
cm_clkdm.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clockdomains.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index ec5a720..2156668 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -21,13 +21,6 @@
* sys_clkout/sys_clkout2.
*/
-/* This is an implicit clockdomain - it is never defined as such in TRM */
-static struct clockdomain wkup_clkdm = {
- .name = "wkup_clkdm",
- .pwrdm = { .name = "wkup_pwrdm" },
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
-};
-
static struct clockdomain prm_clkdm = {
.name = "prm_clkdm",
.pwrdm = { .name = "wkup_pwrdm" },
@@ -282,7 +275,6 @@ static struct clkdm_pwrdm_autodep clkdm_pwrdm_autodeps[] = {
static struct clockdomain *clockdomains_omap[] = {
- &wkup_clkdm,
&cm_clkdm,
&prm_clkdm,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/12] OMAP2/3 clock: convert wkup_clkdm CM clocks to cm_clkdm
Convert existing wkup_clkdm clocks that should be in the CM clockdomain
to cm_clkdm. (A later patch will add CM clockdomain associations for
unassociated clocks.)
References:
OMAP2420 Multimedia Processor Silicon Revision 2.1.1, 2.2 TRM Version Q
Figure 5-9
- func_54m_ck, core_ck, func_96m_ck, func_48m_ck, func_12m_ck
OMAP34xx Multimedia Device Silicon Revision 3.0 Version I TRM
Figure 4-35
- sys_clkout2
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock24xx.h | 16
arch/arm/mach-omap2/clock34xx.h |2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 8915b52..5845850 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -757,7 +757,7 @@ static struct clk func_54m_ck = {
.parent = &apll54_ck, /* can also be alt_clk */
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES | PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.init = &omap2_init_clksel_parent,
.clksel_reg = _CM_REG_OFFSET(PLL_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_54M_SOURCE,
@@ -770,7 +770,7 @@ static struct clk core_ck = {
.parent = &dpll_ck, /* can also be 32k */
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
ALWAYS_ENABLED | RATE_PROPAGATES,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &followparent_recalc,
};
@@ -797,7 +797,7 @@ static struct clk func_96m_ck = {
.parent = &apll96_ck,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES | PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.init = &omap2_init_clksel_parent,
.clksel_reg = _CM_REG_OFFSET(PLL_MOD, CM_CLKSEL1),
.clksel_mask= OMAP2430_96M_SOURCE,
@@ -830,7 +830,7 @@ static struct clk func_48m_ck = {
.parent = &apll96_ck,/* 96M or Alt */
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES | PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.init = &omap2_init_clksel_parent,
.clksel_reg = _CM_REG_OFFSET(PLL_MOD, CM_CLKSEL1),
.clksel_mask= OMAP24XX_48M_SOURCE,
@@ -846,7 +846,7 @@ static struct clk func_12m_ck = {
.fixed_div = 4,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES | PARENT_CONTROLS_CLOCK,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_fixed_divisor_recalc,
};
@@ -945,7 +945,7 @@ static struct clk sys_clkout2_src = {
.name = "sys_clkout2_src",
.parent = &func_54m_ck,
.flags = CLOCK_IN_OMAP242X | RATE_PROPAGATES | OFFSET_GR_MOD,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.enable_reg = _GR_MOD_OFFSET(OMAP24XX_PRCM_CLKOUT_CTRL_OFFSET),
.enable_bit = OMAP2420_CLKOUT2_EN_SHIFT,
.init = &omap2_init_clksel_parent,
@@ -968,7 +968,7 @@ static struct clk sys_clkout2 = {
.parent = &sys_clkout2_src,
.flags = CLOCK_IN_OMAP242X | PARENT_CONTROLS_CLOCK |
OFFSET_GR_MOD,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.clksel_reg = _GR_MOD_OFFSET(OMAP24XX_PRCM_CLKOUT_CTRL_OFFSET),
.clksel_mask= OMAP2420_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
@@ -981,7 +981,7 @@ static struct clk emul_ck = {
.name = "emul_ck",
.parent = &func_54m_ck,
.flags = CLOCK_IN_OMAP242X | OFFSET_GR_MOD,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "cm_clkdm" },
.enable_reg = _GR_MOD_OFFSET(OMAP24XX_PRCM_CLKEMUL_CTRL_OFFSET),
.enable_bit = OMAP24XX_EMULATION_EN_SHIFT,
.recalc = &followparent_recalc,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 7bd6f56..01414e2 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1023,7 +1023,7 @@ static struct clk clkout2_src_ck = {
.clksel_mask= OMAP3430_CLKOUT2SOURCE_MASK,
.clksel = clkout2_src_clksel,
.flags = CLOCK_IN_
[PATCH v2 05/12] OMAP2/3 clock: mark the rest of the CM clocks as belonging to cm_clkdm
Mark CM clocks with no clockdomain as belonging to the CM clockdomain.
References for the OMAP3xxx clocks:
OMAP34xx Multimedia Device Silicon Revision 3.0 Version I TRM
Figure 4-13:
- sys_ck
Figure 4-35:
- sys_clkout2
Figure 4-37:
- corex2_fck, core_ck, dss_tv_fck
Figure 4-38:
- omap_96m_alwon_fck
Figure 4-39:
- corex2_fck, cm_96m_fck, omap_96m_fck, omap_54m_fck, omap_12m_fck,
dpll1_fck, dpll2_fck, rm_ick, dss_tv_fck
Section 4.7.3.2:
- omap_96m_alwon_fck, omap_96m_fck, omap_48m_fck
OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.0 Security
Addendum Version B TRM
Figure 3-19:
- cpefuse_fck
Table 3-57:
- dss_tv_fck
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 01414e2..0c2acea 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -225,10 +225,15 @@ static struct clk sys_ck = {
static struct clk sys_altclk = {
.name = "sys_altclk",
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES | ALWAYS_ENABLED,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &propagate_rate,
};
-/* Optional external clock input for some McBSPs */
+/*
+ * Optional external clock input for some McBSPs
+ * Apparently this is not really in prm_clkdm, but rather is fed into
+ * both CORE and PER separately.
+ */
static struct clk mcbsp_clks = {
.name = "mcbsp_clks",
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES | ALWAYS_ENABLED,
@@ -526,6 +531,7 @@ static struct clk core_ck = {
.clksel = core_ck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -699,6 +705,7 @@ static struct clk cm_96m_fck = {
.parent = &omap_96m_alwon_fck,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &followparent_recalc,
};
@@ -727,6 +734,7 @@ static struct clk omap_96m_fck = {
.clksel = omap_96m_fck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -769,6 +777,7 @@ static struct clk virt_omap_54m_fck = {
.clksel = virt_omap_54m_fck_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -796,6 +805,7 @@ static struct clk omap_54m_fck = {
.clksel = omap_54m_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -823,6 +833,7 @@ static struct clk omap_48m_fck = {
.clksel = omap_48m_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -832,6 +843,7 @@ static struct clk omap_12m_fck = {
.fixed_div = 4,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_fixed_divisor_recalc,
};
@@ -1048,6 +1060,7 @@ static struct clk sys_clkout2 = {
.clksel_mask= OMAP3430_CLKOUT2_DIV_MASK,
.clksel = sys_clkout2_clksel,
.flags = CLOCK_IN_OMAP343X | PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -1058,6 +1071,7 @@ static struct clk corex2_fck = {
.parent = &dpll3_m2x2_ck,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES |
PARENT_CONTROLS_CLOCK,
+ .clkdm = { .name = "cm_clkdm" },
.recalc = &followparent_recalc,
};
@@ -1075,10 +1089,6 @@ static const struct clksel div4_core_clksel[] = {
{ .parent = NULL }
};
-/*
- * REVISIT: Are these in DPLL power domain or CM power domain? docs
- * may be inconsistent here?
- */
static struct clk dpll1_fck = {
.name = "dpll1_fck",
.parent = &core_ck,
@@ -1088,6 +1098,7 @@ static struct
[PATCH v2 02/12] OMAP2/3 clock: convert wkup_clkdm PRM clocks to prm_clkdm
Convert existing wkup_clkdm clocks that should be in the PRM clockdomain
to prm_clkdm. (A later patch will add PRM clockdomain associations for
unassociated clocks.)
References for the OMAP2xxx clocks:
OMAP2420 Multimedia Processor Silicon Revision 2.1.1, 2.2 TRM Version Q
Figure 4-11:
- alt_ck
Figure 5-7:
- func_32k_ck, osc_ck, sys_ck
Figure 5-8 (assumes that "Level 0" = PRM)
- dpll_ck, apll96_ck, apll54_ck, func_54m_ck
Section 5.4.1.1:
- sys_clkout_src, sys_clkout
Section 29.3.1.1:
- gpios_fck, mpu_wdt_fck, mpu_wdt_ick
References for the OMAP3xxx clocks:
OMAP34xx Multimedia Device Silicon Revision 3.0 Version I TRM
Figure 4-54:
- gpt1_fck, wkup_32k_fck, wdt2_fck, wkup_l4_fck, omap_32ksync_ick,
gpt1_ick
Section 25.3.1.1.3:
- gpio1_fck, gpio1_ick
OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.0 Security
Addendum Version B TRM
Table 2-5:
- usim_ick
Figure 3-29:
- wdt1_ick, gpt12_ick
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock24xx.h | 29 -
arch/arm/mach-omap2/clock34xx.h | 25 -
2 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 4de6d9b..7224450 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -635,7 +635,7 @@ static struct clk func_32k_ck = {
.rate = 32000,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_FIXED | ALWAYS_ENABLED | RATE_PROPAGATES,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -644,7 +644,7 @@ static struct clk osc_ck = {/* (*12, *13,
19.2, *26, 38.4)MHz */
.name = "osc_ck",
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.enable = &omap2_enable_osc_ck,
.disable= &omap2_disable_osc_ck,
.recalc = &omap2_osc_clk_recalc,
@@ -656,7 +656,7 @@ static struct clk sys_ck = {/* (*12, *13,
19.2, 26, 38.4)MHz */
.parent = &osc_ck,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
ALWAYS_ENABLED | RATE_PROPAGATES,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &omap2_sys_clk_recalc,
};
@@ -665,7 +665,7 @@ static struct clk alt_ck = {/* Typical 54M
or 48M, may not exist */
.rate = 5400,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_FIXED | ALWAYS_ENABLED | RATE_PROPAGATES,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -697,7 +697,7 @@ static struct clk dpll_ck = {
.dpll_data = &dpll_dd,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES | ALWAYS_ENABLED,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &omap2_dpllcore_recalc,
.set_rate = &omap2_reprogram_dpllcore,
};
@@ -708,7 +708,7 @@ static struct clk apll96_ck = {
.rate = 9600,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_FIXED | RATE_PROPAGATES | ENABLE_ON_INIT,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.enable_reg = _CM_REG_OFFSET(PLL_MOD, CM_CLKEN),
.enable_bit = OMAP24XX_EN_96M_PLL_SHIFT,
.enable = &omap2_clk_fixed_enable,
@@ -722,7 +722,7 @@ static struct clk apll54_ck = {
.rate = 5400,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_FIXED | RATE_PROPAGATES | ENABLE_ON_INIT,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.enable_reg = _CM_REG_OFFSET(PLL_MOD, CM_CLKEN),
.enable_bit = OMAP24XX_EN_54M_PLL_SHIFT,
.enable = &omap2_clk_fixed_enable,
@@ -899,7 +899,7 @@ static struct clk sys_clkout_src = {
.parent = &func_54m_ck,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_PROPAGATES | OFFSET_GR_MOD,
- .clkdm = { .name = "wkup_clkdm" },
+ .clkdm = { .name = "prm_clkdm" },
.enable_reg = _GR_MOD_OFFSET(OMAP24XX_PRCM_CLKO
[PATCH v2 03/12] OMAP2/3 clock: annotate PRM clocks that are missing clockdomains
Some PRM clocks are missing clockdomain assignments; add them.
Also, in OMAP2xxx clock tree, standardize the name for wdt1_osc_ck.
References for the OMAP2xxx clocks:
OMAP2420 Multimedia Processor Silicon Revision 2.1.1, 2.2 TRM Version Q
Table 18-41:
- wdt1_osc_ck
References for the OMAP3xxx clocks:
OMAP34xx Multimedia Device Silicon Revision 3.0 Version I TRM
Figure 4-13:
- sys_clkout1,
Table 4-37:
- sys_ck
Table 4-38:
- omap_32k_fck, osc_sys_ck,
Figure 4-56:
- sr1_fck, sr2_fck
Figure 4-57:
- omap_96m_alwon_fck
Section 4.7.7.13:
- sr1_fck, sr2_fck
OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.0 Security
Addendum Version B TRM
Table 2-5:
- usim_fck
Figure 3-29:
- secure_32k_fck, gpt12_fck, wdt1_fck
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock24xx.h |3 ++-
arch/arm/mach-omap2/clock34xx.h | 18 ++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 7224450..8915b52 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -852,9 +852,10 @@ static struct clk func_12m_ck = {
/* Secure timer, only available in secure mode */
static struct clk wdt1_osc_ck = {
- .name = "ck_wdt1_osc",
+ .name = "wdt1_osc_ck",
.parent = &osc_ck,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &followparent_recalc,
};
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index c825a37..7bd6f56 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -74,6 +74,7 @@ static struct clk omap_32k_fck = {
.rate = 32768,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -82,6 +83,7 @@ static struct clk secure_32k_fck = {
.rate = 32768,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -91,6 +93,7 @@ static struct clk virt_12m_ck = {
.rate = 1200,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -99,6 +102,7 @@ static struct clk virt_13m_ck = {
.rate = 1300,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -107,6 +111,7 @@ static struct clk virt_16_8m_ck = {
.rate = 1680,
.flags = CLOCK_IN_OMAP3430ES2 | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -115,6 +120,7 @@ static struct clk virt_19_2m_ck = {
.rate = 1920,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -123,6 +129,7 @@ static struct clk virt_26m_ck = {
.rate = 2600,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -131,6 +138,7 @@ static struct clk virt_38_4m_ck = {
.rate = 3840,
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &propagate_rate,
};
@@ -185,6 +193,7 @@ static struct clk osc_sys_ck = {
/* REVISIT: deal with autoextclkmode? */
.flags = CLOCK_IN_OMAP343X | RATE_FIXED | RATE_PROPAGATES |
ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -209,6 +218,7 @@ static struct clk sys_ck = {
.clksel_mask= OMAP_SYSCLKDIV_MASK,
.clksel = sys_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES | ALWAYS_ENABLED,
+ .clkdm = { .name = "prm_clkdm" },
.recalc = &omap2_clksel_recalc,
};
@@ -222,6 +2
[PATCH v2 01/12] OMAP2/3 clockdomains: add CM and PRM clkdms
Add clockdomains for the CM and PRM. These will ultimately replace the
"wkup_clkdm", which appears to not actually exist on the hardware.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clockdomains.h| 19 +++
arch/arm/plat-omap/include/mach/powerdomain.h |4 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index e17c369..ec5a720 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -14,6 +14,11 @@
/*
* OMAP2/3-common clockdomains
+ *
+ * Even though the 2420 has a single PRCM module from the
+ * interconnect's perspective, internally it does appear to have
+ * separate PRM and CM clockdomains. The usual test case is
+ * sys_clkout/sys_clkout2.
*/
/* This is an implicit clockdomain - it is never defined as such in TRM */
@@ -23,6 +28,18 @@ static struct clockdomain wkup_clkdm = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
};
+static struct clockdomain prm_clkdm = {
+ .name = "prm_clkdm",
+ .pwrdm = { .name = "wkup_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
+};
+
+static struct clockdomain cm_clkdm = {
+ .name = "cm_clkdm",
+ .pwrdm = { .name = "core_pwrdm" },
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
+};
+
/*
* 2420-only clockdomains
*/
@@ -266,6 +283,8 @@ static struct clkdm_pwrdm_autodep clkdm_pwrdm_autodeps[] = {
static struct clockdomain *clockdomains_omap[] = {
&wkup_clkdm,
+ &cm_clkdm,
+ &prm_clkdm,
#ifdef CONFIG_ARCH_OMAP2420
&mpu_2420_clkdm,
diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h
b/arch/arm/plat-omap/include/mach/powerdomain.h
index 4948cb7..69c9e67 100644
--- a/arch/arm/plat-omap/include/mach/powerdomain.h
+++ b/arch/arm/plat-omap/include/mach/powerdomain.h
@@ -50,9 +50,9 @@
/*
* Maximum number of clockdomains that can be associated with a powerdomain.
- * CORE powerdomain is probably the worst case.
+ * CORE powerdomain on OMAP3 is the worst case
*/
-#define PWRDM_MAX_CLKDMS 3
+#define PWRDM_MAX_CLKDMS 4
/* XXX A completely arbitrary number. What is reasonable here? */
#define PWRDM_TRANSITION_BAILOUT 10
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/12] Update OMAP2/3 powerdomains, clockdomains
This second version adds two fixes: it removes the extraneous init from csi2_96m_fck, and associates virt_opp_clkdm with wkup_pwrdm. ... This series updates the in-kernel OMAP2/3 clockdomain and powerdomain structures: - Split the placeholder clockdomain "wkup_clkdm" into "cm_clkdm" and "prm_clkdm". This more accurately reflects the hardware. - Add powerdomains and clockdomains for DPLLs 1 through 5 on OMAP3. - Associate every clock in OMAP2/3 clock tree with an appropriate clockdomain. Boot-tested on 2430SDP and 3430SDP. --- size: textdata bss dec hex filename 3441382 157936 105728 3705046 3888d6 vmlinux.3430sdp.orig 3441638 158440 105728 3705806 388bce vmlinux.3430sdp arch/arm/mach-omap2/clock.c |8 + arch/arm/mach-omap2/clock24xx.h | 56 ++ arch/arm/mach-omap2/clock34xx.h | 140 ++--- arch/arm/mach-omap2/clockdomains.h| 65 +++- arch/arm/mach-omap2/powerdomains.h|5 + arch/arm/mach-omap2/powerdomains34xx.h| 31 ++ arch/arm/plat-omap/include/mach/powerdomain.h |4 - 7 files changed, 239 insertions(+), 70 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3][OMAP 3/4]table end for wcd command definitions
* Hiroshi DOYU <[EMAIL PROTECTED]> [080909 21:08]: > Hi, > > Although this TI bridge patches are not integrated and a bit > independent S/W component, it would be nice to get some comments just > on this bridge header file location from kernel maintainer's > perspective. > > "arch/arm/plat-omap/include/mach/bridge" > or "arch/arm/plat-omap/include/bridge"? How about put the bridge specific headers under include/linux/dspbridge? Then you can have just the omap specific headers under arch/arm/plat-omap/include/mach. Tony > >Hiroshi DOYU > > From: Hiroshi DOYU <[EMAIL PROTECTED]> > Subject: Re: [PATCH 2/3][OMAP 3/4]table end for wcd command definitions > Date: Fri, 29 Aug 2008 08:03:13 +0300 (EEST) > > > Hi Omar, > > > > I just noticed that the bridge specific header files are located > > under "linux/arch/arm/plat-omap/include/mach/bridge/", but it may be > > better to have them under "arch/arm/plat-omap/include/bridge/" because > > those header files are not related to the omap archtecture so much and > > mostly used for bridge specific purpose, although omap is the only > > platform to have bridge with dsp;) For me, it would make more sense > > logically, and also practically grepp'ing would work more nicely > > without any fancy tools like specifiying the directories to search. > > > > Any comments? > > > > Hiroshi DOYU > > > > From: "ext Ramirez Luna, Omar" <[EMAIL PROTECTED]> > > Subject: [PATCH 2/3][OMAP 3/4]table end for wcd command definitions > > Date: Thu, 28 Aug 2008 20:30:44 -0500 > > > > > Added the table end 'CMD_BASE_END_OFFSET' define in wcdioctl.h > > > > > > Signed-off-by: Omar Ramirez Luna <[EMAIL PROTECTED]> > > > --- > > > > > > Index: omapkernel/arch/arm/plat-omap/include/mach/bridge/wcdioctl.h > > > === > > > --- omapkernel.orig/arch/arm/plat-omap/include/mach/bridge/wcdioctl.h > > > 2008-08-22 19:03:10.0 -0500 > > > +++ omapkernel/arch/arm/plat-omap/include/mach/bridge/wcdioctl.h > > > 2008-08-22 19:20:05.0 -0500 > > > @@ -515,4 +515,5 @@ > > > #define CMD_CMM_GETINFO_OFFSET (CMD_CMM_BASE_OFFSET + 3) > > > #define CMD_CMM_END_OFFSET CMD_CMM_GETINFO_OFFSET > > > > > > +#define CMD_BASE_END_OFFSET CMD_CMM_END_OFFSET > > > #endif /* WCDIOCTL_ */ > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] Adds support for CPUIdle safe state
Hello Rajendra, On Mon, 1 Sep 2008, Rajendra Nayak wrote: > This patch adds the support to move to a safe-state on bm activity > > Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]> > --- > arch/arm/mach-omap2/cpuidle34xx.c | 152 > +++--- > 1 files changed, 79 insertions(+), 73 deletions(-) > > Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c > === > --- linux-omap-2.6.orig/arch/arm/mach-omap2/cpuidle34xx.c 2008-09-01 > 18:25:25.0 +0530 > +++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c 2008-09-01 > 18:27:10.0 +0530 > @@ -269,6 +272,7 @@ int omap3_idle_init(void) > struct omap3_processor_cx *cx; > struct cpuidle_state *state; > struct cpuidle_device *dev; > + char clk_name[11]; Nothing in this patch uses this - please drop or move to the patch that uses this variable. > > omap3_clear_scratchpad_contents(); > omap3_save_scratchpad_contents(); - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in twl4030backupbatt_voltage()
* Madhusudhan Chikkature <[EMAIL PROTECTED]> [080910 06:12]: > > - Original Message - > From: "Adrian Hunter" <[EMAIL PROTECTED]> > To: "Tony Lindgren" <[EMAIL PROTECTED]> > Cc: ; <[EMAIL PROTECTED]> > Sent: Wednesday, September 10, 2008 12:58 PM > Subject: Re: Bug in twl4030backupbatt_voltage() > > > > Tony Lindgren wrote: > >> * Adrian Hunter <[EMAIL PROTECTED]> [080903 08:08]: > >>> In the omap tree, commit f91fd98be045bec9c18e13110f22dafd44cb84b5 > >>> fixed a bug with the use of function twl4030_madc_conversion() > >>> relating to the local variable 'struct twl4030_madc_request req' > >>> not being fully initialised. > >>> > >>> The same problem appears to be in the function > >>> twl4030backupbatt_voltage() which is in > >>> drivers/power/twl4030_bci_battery.c > >> > >> Thanks, I'll initialize it to NULL. Wouldn't it have been easier just > >> to write a patch instead of the description above? :) > > > > Apparently. > > > > There is also req.do_avg which should be zero, if you assume the > > programmer's > > intent was to have uninitialised members set to zero. > I guess, I did not look at all the other members of the > "twl4030_madc_request" structure. I might have missed it. > The do_avg and func_cb fields can both be set to NULL. Can you please check the code and send a patch? Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/12] CORE OFF support in omap_sram_idle
On Mon, 1 Sep 2008, Rajendra Nayak wrote:
> This patch updates omap_sram_idle with CORE OFF support
>
> Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 37
> arch/arm/mach-omap2/pm.h |2 +
> arch/arm/mach-omap2/pm34xx.c | 43
> ++
> 3 files changed, 82 insertions(+)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/cpuidle34xx.c 2008-09-01
> 18:12:35.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c 2008-09-01
> 18:25:25.0 +0530
> @@ -26,11 +26,48 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> #include "cpuidle34xx.h"
>
> +static int padconf_saved;
> +void omap3_save_core_ctx(void)
> +{
> + u32 control_padconf_off;
> + if (!padconf_saved) {
> +/* Save the padconf registers */
> +control_padconf_off =
> + omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
> +control_padconf_off |= START_PADCONF_SAVE;
> +omap_ctrl_writel(control_padconf_off,
> + OMAP343X_CONTROL_PADCONF_OFF);
> +/* wait for the save to complete */
> +while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
> + & PADCONF_SAVE_DONE);
This while() should call cpu_relax().
> +padconf_saved = 1;
> + }
> + /* Save the Interrupt controller context */
> + omap3_save_intc_ctx();
> + /* Save the GPMC context */
> + omap3_save_gpmc_ctx();
> + /* Save the system control module context, padconf already save above*/
> + omap3_save_control_ctx();
> +}
> +
> +void omap3_restore_core_ctx(void)
> +{
> + /* Restore the control module context, padconf restored by h/w */
> + omap3_restore_control_ctx();
> + /* Restore the GPMC context */
> + omap3_restore_gpmc_ctx();
> + /* Restore the interrupt controller context */
> + omap3_restore_intc_ctx();
> + padconf_saved = 0;
> +}
> +
> #ifdef CONFIG_CPU_IDLE
>
> struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
> Index: linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/pm34xx.c 2008-09-01
> 18:23:19.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c 2008-09-01
> 18:24:02.0
> +0530
> @@ -27,10 +27,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> +#include
> #include
>
> #include "cm.h"
> @@ -58,6 +61,7 @@ static struct powerdomain *mpu_pwrdm, *n
> static struct powerdomain *core_pwrdm, *per_pwrdm;
>
> int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
> +void omap3_restore_sram_ctx(void);
>
> u32 context_mem[128];
>
> @@ -91,6 +95,16 @@ static void gpio_fclk_mask(u32 *fclk)
> *fclk &= ~(0x1f << 13);
> }
>
> +void omap3_save_per_ctx(void)
> +{
> + omap3_gpio_save();
> +}
> +
> +void omap3_restore_per_ctx(void)
> +{
> + omap3_gpio_restore();
> +}
> +
> /* PRCM Interrupt Handler for wakeups */
> static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
> {
> @@ -225,6 +239,7 @@ void omap_sram_idle(void)
> int mpu_next_state = PWRDM_POWER_ON;
> int per_next_state = PWRDM_POWER_ON;
> int core_next_state = PWRDM_POWER_ON;
> + int core_prev_state, per_prev_state;
>
> if (!_omap_sram_idle)
> return;
> @@ -261,15 +276,27 @@ void omap_sram_idle(void)
> /* PER changes only with core */
> per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
> if (per_next_state < PWRDM_POWER_ON) {
> + if (per_next_state == PWRDM_POWER_OFF) {
> + omap3_save_per_ctx();
> + omap3_save_uart_ctx(2);
> + }
> if (clocks_off_while_idle) {
> per_gpio_clk_disable();
> omap_serial_enable_clocks(0, 2);
> }
> }
> + if (core_next_state == PWRDM_POWER_OFF) {
> + omap3_save_core_ctx();
> + omap3_save_prcm_ctx();
> + omap3_save_uart_ctx(0);
> + omap3_save_uart_ctx(1);
> + }
> if (clocks_off_while_idle) {
> omap_serial_enable_clocks(0, 0);
> omap_serial_enable_clocks(0, 1);
> }
> + if (core_next_state == PWRDM_POWER_OFF)
> + omap3_save_prcm_ctx();
> /* Enable IO-PAD wakeup */
> prm_set_mod_reg_bits(OMAP3430_
Re: [PATCH 06/12] Interrupt Controller context save/restore
Hello Rajendra,
a few minor comments:
On Mon, 1 Sep 2008, Rajendra Nayak wrote:
> This patch adds the Intrpt controller context save/restore
This patch makes several references to '96'. Please set up a macro for
this number -- something like INTCPS_NR_IRQS, and use that in place of
'96' throughout this patch.
>
> Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> ---
> + |binary
> arch/arm/mach-omap2/.irq.c.swp |0
> arch/arm/mach-omap2/irq.c | 48
> +
> arch/arm/plat-omap/include/mach/irqs.h | 14 +
> 2 files changed, 62 insertions(+)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/irq.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/irq.c 2008-09-01
> 18:11:28.0
> +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/irq.c 2008-09-01 18:11:54.0
> +0530
> @@ -24,6 +24,9 @@
> #define INTC_SYSCONFIG 0x0010
> #define INTC_SYSSTATUS 0x0014
> #define INTC_CONTROL 0x0048
> +#define INTC_PROTECTION 0x004C
> +#define INTC_IDLE0x0050
> +#define INTC_THRESHOLD 0x0068
> #define INTC_MIR_CLEAR0 0x0088
> #define INTC_MIR_SET00x008c
> #define INTC_PENDING_IRQ00x0098
> @@ -167,3 +170,48 @@ void __init omap_init_irq(void)
> }
> }
>
> +#ifdef CONFIG_ARCH_OMAP3
> +static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
> +void omap3_save_intc_ctx(void)
> +{
> + int ind = 0, i = 0;
> + for (ind = 0; ind < ARRAY_SIZE(irq_banks); ind++) {
> + struct omap_irq_bank *bank = irq_banks + ind;
> + intc_context[ind].sysconfig =
> + intc_bank_read_reg(bank, INTC_SYSCONFIG);
> + intc_context[ind].protection =
> + intc_bank_read_reg(bank, INTC_PROTECTION);
> + intc_context[ind].idle =
> + intc_bank_read_reg(bank, INTC_IDLE);
> + intc_context[ind].threshold =
> + intc_bank_read_reg(bank, INTC_THRESHOLD);
> + for (i = 0; i < 96; i++)
> + intc_context[ind].ilr[i] =
> + intc_bank_read_reg(bank, (0x100 + 0x4*ind));
> + }
> + /* MIRs are saved and restore with other PRCM registers */
> +}
> +
> +void omap3_restore_intc_ctx(void)
> +{
> + int ind = 0, i = 0;
> +
> + for (ind = 0; ind < ARRAY_SIZE(irq_banks); ind++) {
> + struct omap_irq_bank *bank = irq_banks + ind;
> + intc_bank_write_reg(intc_context[ind].sysconfig,
> + bank, INTC_SYSCONFIG);
> + intc_bank_write_reg(intc_context[ind].sysconfig,
> + bank, INTC_SYSCONFIG);
> + intc_bank_write_reg(intc_context[ind].protection,
> + bank, INTC_PROTECTION);
> + intc_bank_write_reg(intc_context[ind].idle,
> + bank, INTC_IDLE);
> + intc_bank_write_reg(intc_context[ind].threshold,
> + bank, INTC_THRESHOLD);
> + for (i = 0; i < 96; i++)
> + intc_bank_write_reg(intc_context[ind].ilr[i],
> + bank, (0x100 + 0x4*ind));
> + }
> + /* MIRs are saved and restore with other PRCM registers */
> +}
> +#endif /* CONFIG_ARCH_OMAP3 */
> Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/irqs.h
> ===
> --- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/irqs.h
> 2008-09-01
> 18:11:28.0 +0530
> +++ linux-omap-2.6/arch/arm/plat-omap/include/mach/irqs.h 2008-09-01
> 18:11:54.0 +0530
> @@ -368,8 +368,22 @@
> #define OMAP_IRQ_BIT(irq)(1 << ((irq) % 32))
>
> #ifndef __ASSEMBLY__
> +/* Structure to save interrupt controller context */
> +struct omap3_intc_regs {
> + u32 sysconfig;
> + u32 protection;
> + u32 idle;
> + u32 threshold;
> + u32 ilr[96];
> + u32 mir_0;
> + u32 mir_1;
> + u32 mir_2;
There is no point including MIR regs here if they are not used.
> +};
> +
> extern void omap_init_irq(void);
> extern int omap_irq_pending(void);
> +void omap3_save_intc_ctx(void);
> +void omap3_restore_intc_ctx(void);
> #endif
>
> #include
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] PRCM context save/restore
On Mon, 1 Sep 2008, Rajendra Nayak wrote:
> This patch adds the context save restore functions for PRCM module
This patch reads and writes from the INTCPS MIR registers, but is in
prcm.c. prcm.c should call INTCPS functions in mach-omap2/irq.c to do
this. I suggest something similar to the following:
1. In arch/arm/plat-omap/include/mach/irqs.h, add:
#define INTCPS_NR_MIR_REGS 3
/**
* struct intcps_mir_ctx - INTCPS interrupt mask context
* @mir: contents of the INTPCS MIR registers
*
* Contents of the INTCPS MIR (interrupt mask) registers -
* used by omap_intcps_{save,restore}_mir() during PRCM context
* save/restore (*not* INTCPS).
*/
struct intcps_mir_ctx {
u32 mir[INTCPS_NR_MIR_REGS];
}
2. In the same file, in the #ifndef __ASSEMBLY__ section, add:
void omap_intcps_save_mir(struct intc_mir_ctx *c);
void omap_intcps_restore_mir(struct intc_mir_ctx *c);
- In mach-omap2/irq.c in the register offsets section, add the three
INTC_MIR registers.
- Add this code to mach-omap2/irq.c:
void omap_intcps_save_mir(struct intc_mir_ctx *c)
{
for (i = 0; i < INTCPS_NR_MIR_REGS; i++)
c->mir[i] = intc_bank_read_reg(&irq_banks[0], INTC_MIR0 + (0x20
* i));
}
void omap_intcps_restore_mir(struct intc_mir_ctx *c)
{
for (i = 0; i < INTCPS_NR_MIR_REGS; i++)
intc_bank_write_reg(c->mir[i], &irq_banks[0], INTC_MIR0 + (0x20
* i));
}
>
> Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/prcm.c| 291
> ++
> arch/arm/mach-omap2/prm.h |2
> arch/arm/plat-omap/include/mach/control.h |2
> arch/arm/plat-omap/include/mach/prcm.h| 92 +
> 4 files changed, 387 insertions(+)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/prcm.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/prcm.c2008-09-01
> 18:11:28.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/prcm.c 2008-09-01 18:11:53.0
> +0530
> @@ -22,6 +22,7 @@
> #include
>
> #include "clock.h"
> +#include "cm.h"
> #include "prm.h"
> #include "prm-regbits-24xx.h"
>
> @@ -125,3 +126,293 @@ void __init omap2_set_globals_prcm(struc
> prm_base = omap2_globals->prm;
> cm_base = omap2_globals->cm;
> }
> +
> +#ifdef CONFIG_ARCH_OMAP3
> +#include "clock34xx.h"
> +struct prcm_context_regs prcm_context;
The above should be static. Please move the #include to the top of the
file.
Add a "static struct intcps_mir_ctx mir_ctx;" here.
> +void omap3_save_prcm_ctx(void)
> +{
> + prcm_context.intc_mir_0 = omap_readl(INTC_MIR_0);
> + prcm_context.intc_mir_1 = omap_readl(INTC_MIR_1);
> + prcm_context.intc_mir_2 = omap_readl(INTC_MIR_2);
Replace these with a call to omap_intcps_save_mir(&mir_ctx);
> + prcm_context.control_padconf_sys_nirq =
> + omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_SYSNIRQ);
> + prcm_context.iva2_cm_clksel2 =
> + cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSEL2);
> + prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG);
> + prcm_context.sgx_cm_clksel =
> + cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL);
> + prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
> + prcm_context.dss_cm_clksel =
> + cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL);
> + prcm_context.cam_cm_clksel =
> + cm_read_mod_reg(OMAP3430_CAM_MOD, CM_CLKSEL);
> + prcm_context.per_cm_clksel =
> + cm_read_mod_reg(OMAP3430_PER_MOD, CM_CLKSEL);
> + prcm_context.emu_cm_clksel =
> + cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSEL1);
> + prcm_context.emu_cm_clkstctrl =
> + cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSTCTRL);
> + prcm_context.pll_cm_autoidle2 =
> + cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
> + prcm_context.pll_cm_clksel5 =
> + cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
> + prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
> + prcm_context.iva2_cm_fclken =
> + cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_FCLKEN);
> + prcm_context.core_cm_fclken1 =
> + cm_read_mod_reg(CORE_MOD, CM_FCLKEN1);
> + prcm_context.core_cm_fclken3 =
> + cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
> + prcm_context.sgx_cm_fclken =
> + cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_FCLKEN);
> + prcm_context.wkup_cm_fclken =
> + cm_read_mod_reg(WKUP_MOD, CM_FCLKEN);
> + prcm_context.dss_cm_fclken =
> + cm_read_mod_reg(OMAP3430_DSS_MOD, CM_FCLKEN);
> + prcm_context.cam_cm_fclken =
> + cm_read_mod_reg(OMAP3430_CAM_MOD, CM_FCLKEN);
> + prcm_context.per_cm_fclken =
> +
Re: [PATCH 07/12] System Control Module context save/restore
"Rajendra Nayak" <[EMAIL PROTECTED]> writes:
> This patch adds the System control module context save/restore
>
> Signed-off-by: Rajendra Nayak <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/control.c | 105
> ++
> arch/arm/plat-omap/include/mach/control.h | 61 +
> 2 files changed, 165 insertions(+), 1 deletion(-)
>
> Index: linux-omap-2.6/arch/arm/mach-omap2/control.c
> ===
> --- linux-omap-2.6.orig/arch/arm/mach-omap2/control.c 2008-09-01
> 18:11:34.0 +0530
> +++ linux-omap-2.6/arch/arm/mach-omap2/control.c 2008-09-01
> 18:11:54.0
> +0530
> @@ -73,6 +73,8 @@ void omap_ctrl_writel(u32 val, u16 offse
>
> #define OMAP3430_PRM_RSTST \
> OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, RM_RSTST)
> +static struct omap3_control_module_regs control_ctx;
> +
I'm not sure what this patch was generated against, but it doesn't
apply against linux-omap. The PRM_RSTST definition above is not in
linux-omap code.
Kevin
> /* Clears the scratchpad contents in case of cold boot-
> called during bootup*/
> void omap3_clear_scratchpad_contents(void)
> @@ -190,4 +192,107 @@ void omap3_save_scratchpad_contents(void
>&sdrc_block_contents, sizeof(sdrc_block_contents));
> }
>
> +void omap3_save_control_ctx(void)
> +{
> + control_ctx.sysconfig = omap_ctrl_readl(OMAP2_CONTROL_SYSCONFIG);
> + control_ctx.devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
> + control_ctx.mem_dftrw0 = omap_ctrl_readl(OMAP343X_CONTROL_MEM_DFTRW0);
> + control_ctx.mem_dftrw1 = omap_ctrl_readl(OMAP343X_CONTROL_MEM_DFTRW1);
> + control_ctx.msuspendmux_0 =
> +omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_0);
> + control_ctx.msuspendmux_1 =
> +omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_1);
> + control_ctx.msuspendmux_2 =
> +omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_2);
> + control_ctx.msuspendmux_3 =
> +omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_3);
> + control_ctx.msuspendmux_4 =
> +omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_4);
> + control_ctx.msuspendmux_5 =
> +omap_ctrl_readl(OMAP2_CONTROL_MSUSPENDMUX_5);
> + control_ctx.sec_ctrl = omap_ctrl_readl(OMAP2_CONTROL_SEC_CTRL);
> + control_ctx.devconf1 = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
> + control_ctx.csirxfe = omap_ctrl_readl(OMAP343X_CONTROL_CSIRXFE);
> + control_ctx.iva2_bootaddr =
> +omap_ctrl_readl(OMAP343X_CONTROL_IVA2_BOOTADDR);
> + control_ctx.iva2_bootmod =
> +omap_ctrl_readl(OMAP343X_CONTROL_IVA2_BOOTMOD);
> + control_ctx.debobs_0 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_0);
> + control_ctx.debobs_1 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_1);
> + control_ctx.debobs_2 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_2);
> + control_ctx.debobs_3 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_3);
> + control_ctx.debobs_4 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_4);
> + control_ctx.debobs_5 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_5);
> + control_ctx.debobs_6 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_6);
> + control_ctx.debobs_7 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_7);
> + control_ctx.debobs_8 = omap_ctrl_readl(OMAP343X_CONTROL_DEBOBS_8);
> + control_ctx.prog_io0 = omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO0);
> + control_ctx.prog_io1 = omap_ctrl_readl(OMAP343X_CONTROL_PROG_IO1);
> + control_ctx.dss_dpll_spreading =
> +omap_ctrl_readl(OMAP343X_CONTROL_DSS_DPLL_SPREADING);
> + control_ctx.core_dpll_spreading =
> +omap_ctrl_readl(OMAP343X_CONTROL_CORE_DPLL_SPREADING);
> + control_ctx.per_dpll_spreading =
> +omap_ctrl_readl(OMAP343X_CONTROL_PER_DPLL_SPREADING);
> + control_ctx.usbhost_dpll_spreading =
> +omap_ctrl_readl(OMAP343X_CONTROL_USBHOST_DPLL_SPREADING);
> + control_ctx.pbias_lite = omap_ctrl_readl(OMAP343X_CONTROL_PBIAS_LITE);
> + control_ctx.temp_sensor = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
> + control_ctx.sramldo4 = omap_ctrl_readl(OMAP343X_CONTROL_SRAMLDO4);
> + control_ctx.sramldo5 = omap_ctrl_readl(OMAP343X_CONTROL_SRAMLDO5);
> + control_ctx.csi = omap_ctrl_readl(OMAP343X_CONTROL_CSI);
> + return;
> +}
> +
> +void omap3_restore_control_ctx(void)
> +{
> + omap_ctrl_writel(control_ctx.sysconfig, OMAP2_CONTROL_SYSCONFIG);
> + omap_ctrl_writel(control_ctx.devconf0, OMAP2_CONTROL_DEVCONF0);
> + omap_ctrl_writel(control_ctx.mem_dftrw0, OMAP343X_CONTROL_MEM_DFTRW0);
> + omap_ctrl_writel(control_ctx.mem_dftrw1, OMAP343X_CONTROL_MEM_DFTRW1);
> + omap_ctrl_writel(control_ctx.msuspendmux_0,
> +OMAP2_CONTROL_MSUSPENDMUX_0);
> + omap_ctrl_writel(control_ctx.msuspendmux_1,
> +
RE: 3430: can't find mmc debounce clock
On Wed, 10 Sep 2008, Woodruff, Richard wrote: > > > > I read that the mmc has 3 clocks: fixed functional clock (MMCi_FCLK), > > > interface clock (MMCi_ICLK) and debounce clock (MMCi_32). > > > > > > But, when I look in clock34xx.h, I can only see two of those - there > > > is the "mmchs_fck" and "mmchs_ick". There is no struct clk for the > > > debounce clock. Only when I look in older kernels I can see also the > > > "mmchsdb2_fck". > > > > > > So where is the debounce clock struct ? (I want to 'get' and 'enable' > > it...) > > > > The debounce clocks are controlled by gpio[1-6]_fck. Perhaps we should > > rename them, but that's what the current tree uses. > > With out looking, that's a bit confusing to me. Perhaps it's a porting > wonder... Ugh, sorry, the above is wrong. Richard's solution below is right. > 2430 did have a separate MMC denounce clock which is controllable at the PRCM > level. This is the name you mention above (2430 name). I don't think 3430 > provides the same control. A 32K clock is fed into the MMC block, but it is > probably controlled locally in MMC block not through clock API at PRCM level. > > Maybe you just need an ifdef or is_cpu_ call. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - Omapzoom] [NAND] Add prefetch and DMA support
Hi, > On Monday 08 September 2008, Kamat, Nishant wrote: > > +config MTD_NAND_OMAP_PREFETCH > > + bool "GPMC prefetch support for NAND Flash device" > > + depends on MTD_NAND && MTD_NAND_OMAP2 > > + default n > > + help > > +The NAND device can be accessed for Read/Write using GPMC PREFETCH > > engine > > +to improve the performance. > > Is there a reason this isn't always enabled, and the choice is just > whether to use DMA or not? Currently I had kept this for experimentation purpose. I will enable it in next patch. > I'd be interested to see performance measurements for the three cases. > > - current/slow code > - the readsw() update I sent previously > - this "prefetch engine" I will do these measurements. > And I'd expect this "prefetch engine" code would also be improved by > using readsw() and writesw() when DMA isn't in use. > > On one ARM926 I observed a 16% speedup *just* from switching from > slow byte-at-a-time PIO to using readsb ... this current code has > that same pessimization. > - Dave-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in twl4030backupbatt_voltage()
- Original Message - From: "Adrian Hunter" <[EMAIL PROTECTED]> To: "Tony Lindgren" <[EMAIL PROTECTED]> Cc: ; <[EMAIL PROTECTED]> Sent: Wednesday, September 10, 2008 12:58 PM Subject: Re: Bug in twl4030backupbatt_voltage() > Tony Lindgren wrote: >> * Adrian Hunter <[EMAIL PROTECTED]> [080903 08:08]: >>> In the omap tree, commit f91fd98be045bec9c18e13110f22dafd44cb84b5 >>> fixed a bug with the use of function twl4030_madc_conversion() >>> relating to the local variable 'struct twl4030_madc_request req' >>> not being fully initialised. >>> >>> The same problem appears to be in the function >>> twl4030backupbatt_voltage() which is in drivers/power/twl4030_bci_battery.c >> >> Thanks, I'll initialize it to NULL. Wouldn't it have been easier just >> to write a patch instead of the description above? :) > > Apparently. > > There is also req.do_avg which should be zero, if you assume the programmer's > intent was to have uninitialised members set to zero. I guess, I did not look at all the other members of the "twl4030_madc_request" structure. I might have missed it. The do_avg and func_cb fields can both be set to NULL. Regards, Madhu > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 3430: can't find mmc debounce clock
> > I read that the mmc has 3 clocks: fixed functional clock (MMCi_FCLK), > > interface clock (MMCi_ICLK) and debounce clock (MMCi_32). > > > > But, when I look in clock34xx.h, I can only see two of those - there > > is the "mmchs_fck" and "mmchs_ick". There is no struct clk for the > > debounce clock. Only when I look in older kernels I can see also the > > "mmchsdb2_fck". > > > > So where is the debounce clock struct ? (I want to 'get' and 'enable' > it...) > > The debounce clocks are controlled by gpio[1-6]_fck. Perhaps we should > rename them, but that's what the current tree uses. With out looking, that's a bit confusing to me. Perhaps it's a porting wonder... 2430 did have a separate MMC denounce clock which is controllable at the PRCM level. This is the name you mention above (2430 name). I don't think 3430 provides the same control. A 32K clock is fed into the MMC block, but it is probably controlled locally in MMC block not through clock API at PRCM level. Maybe you just need an ifdef or is_cpu_ call. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BRIDGE] Rebase and sync with omapzoom bridge patch update
On Wed, Sep 10, 2008 at 3:41 PM, Hiroshi DOYU <[EMAIL PROTECTED]> wrote: > Hi, > > It seems that the following site doesn't work with git. > So please use: > > $ wget http://4869037.web.fc2.com/tidspbridge-20080910.tgz > > From: Hiroshi DOYU <[EMAIL PROTECTED]> > Subject: [BRIDGE] Rebase and sync with omapzoom bridge patch update > Date: Wed, 10 Sep 2008 06:53:32 +0300 (EEST) > >> Hi, >> >> I have updated all TI BRIDGE patches and rebased them against the >> latest linux-omap again for easy integration of them. You can get it >> by: >> git fetch http://4869037.web.fc2.com/linux.git bridge: This works fine here... -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3430: can't find mmc debounce clock
On Mon, 8 Sep 2008, Budhee Jamaich wrote: > I read that the mmc has 3 clocks: fixed functional clock (MMCi_FCLK), > interface clock (MMCi_ICLK) and debounce clock (MMCi_32). > > But, when I look in clock34xx.h, I can only see two of those - there > is the "mmchs_fck" and "mmchs_ick". There is no struct clk for the > debounce clock. Only when I look in older kernels I can see also the > "mmchsdb2_fck". > > So where is the debounce clock struct ? (I want to 'get' and 'enable' it...) The debounce clocks are controlled by gpio[1-6]_fck. Perhaps we should rename them, but that's what the current tree uses. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BRIDGE] Rebase and sync with omapzoom bridge patch update
Hi, It seems that the following site doesn't work with git. So please use: $ wget http://4869037.web.fc2.com/tidspbridge-20080910.tgz From: Hiroshi DOYU <[EMAIL PROTECTED]> Subject: [BRIDGE] Rebase and sync with omapzoom bridge patch update Date: Wed, 10 Sep 2008 06:53:32 +0300 (EEST) > Hi, > > I have updated all TI BRIDGE patches and rebased them against the > latest linux-omap again for easy integration of them. You can get it > by: > git fetch http://4869037.web.fc2.com/linux.git bridge: > > Most of the patches come directly from OMAPZOOM(Thanks, TI bridge > team) and I just collected them;) > > which includes the following patches. > > Fernando Guzman Lugo (1): > BRIDGE: Remove sparse warnings from wcd > > Hiroshi DOYU (12): > BRIDGE: Kconfig Entry > BRIDGE: Header files > BRIDGE: Doff image dynamic loader > BRIDGE: Generic Utilities > BRIDGE: Hardware Interfaces > BRIDGE: Platform Manager > BRIDGE: Resource Manager > BRIDGE: Services > BRIDGE: Mini driver > BRIDGE: README > BRIDGE: Fix header path > BRIDGE: Sync omapzoom bridge patches > > Omar Ramirez Luna (6): > BRIDGE: Ceanup GT sparse warnings > BRIDGE: Cleanup static declarations warnings > BRIDGE: Remove unused clk structs > BRIDGE: Clean up unusedvariables > BRIDGE: Cosmetic changes reported from checkpatch > BRIDGE: Checkpatch Cleanup > > Ramesh Gupta (2): > BRIDGE: Power management changes > BRIDGE: OMAP PM Bug softlockup fix > > ext Ramirez Luna, Omar (1): > BRIDGE: OMAP CSL wrappers removed > > [EMAIL PROTECTED] (1): > BRIDGE: Add wcd table end > > If you find some missing patches against omapzoom, please let me know. > > Hiroshi DOYU > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] McBSP DMA support for 34xx
- Original Message - From: "Jarkko Nikula" <[EMAIL PROTECTED]> To: "ext shekhar, chandra" <[EMAIL PROTECTED]> Cc: "Tony Lindgren" <[EMAIL PROTECTED]>; Sent: Wednesday, September 10, 2008 4:44 PM Subject: Re: [PATCH 1/2] McBSP DMA support for 34xx On Wed, 10 Sep 2008 15:47:34 +0530 "ext shekhar, chandra" <[EMAIL PROTECTED]> wrote: Most importantly, 4> McBSP buffer ( To save power, for 34xx). OMAP3430 McBSP interface 2 has 5k buffer for audio. handling of this buffer should be specific to McBSP. Actually it's not specific to McBSP only. I haven't paid attention into these HW buffering issues but they have an effect. Like - IRCC ALSA expects that playback/record is really stopped when trigger callback returns - How HW buffering affects pointer callback? Some low-latency audio algorithms require that buffer position is known very precisely. E.g. if modifying already queued audio buffer content but which is not played out yet This harware buffer is not user accessible, but during data transfer it is related to dma transfer. During data transfer instead of element sync, packet sync data transfer can be used. DMA request length can be configured buffer threshold and packet sync transfer can be used instead of element sync. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: fix memory corruption when using more than max endpoints
On Wed, Sep 10, 2008 at 02:20:35PM +0300, ext Kevin Hilman wrote:
> Felipe Balbi wrote:
>> Let's keep linux-usb on the loop for musb related patches ;-)
>>
>> On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
>>> There is no check if platform code passes in more endpoints (num_eps)
>>> than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
>>> that allocate_instance() happily writes past the end of 'struct musb'
>>> corrupting memory.
>>>
>>> The fix below increases the max to 32 (used on omap3) and also adds a
>>> BUG() if the platform code requests more than the max.
>>>
>>> This memory corruption was triggering various forms of crashes/panics
>>> with kmem_cache_alloc() in the backtrace.
>>>
>>> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
>>
>> Looks ok, I'll put to my series.
>>
>>> ---
>>> drivers/usb/musb/musb_core.c |1 +
>>> drivers/usb/musb/musb_core.h |2 +-
>>> 2 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>>> index c939f81..a132d9f 100644
>>> --- a/drivers/usb/musb/musb_core.c
>>> +++ b/drivers/usb/musb/musb_core.c
>>> @@ -1806,6 +1806,7 @@ allocate_instance(struct device *dev,
>>> musb->ctrl_base = mbase;
>>> musb->nIrq = -ENODEV;
>>> musb->config = config;
>>> + BUG_ON(musb->config->num_eps > MUSB_C_NUM_EPS);
>>
>> It's good to have this check here.
>>
>>> for (epnum = 0, ep = musb->endpoints;
>>> epnum < musb->config->num_eps;
>>> epnum++, ep++) {
>>> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
>>> index 8222725..5040ceb 100644
>>> --- a/drivers/usb/musb/musb_core.h
>>> +++ b/drivers/usb/musb/musb_core.h
>>> @@ -153,7 +153,7 @@ static inline void musb_host_rx(struct musb *m, u8 e) {}
>>> /** CONSTANTS /
>>> #ifndef MUSB_C_NUM_EPS
>>> -#define MUSB_C_NUM_EPS ((u8)16)
>>> +#define MUSB_C_NUM_EPS ((u8)32)
>>
>> 16 is the right number.
>>
>
> If 16 is the right number, arch/arm/mach-omap2/usb-musb.c going to trigger
> this BUG every time since it sets num_eps = 32.
>
> I don't know much about MUSB enbpoints, but if 16 is the correct max, then
> the platform code should be updated.
Check recent Dave's patches to usb-musb.c ;-)
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: fix memory corruption when using more than max endpoints
Felipe Balbi wrote:
Let's keep linux-usb on the loop for musb related patches ;-)
On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
There is no check if platform code passes in more endpoints (num_eps)
than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
that allocate_instance() happily writes past the end of 'struct musb'
corrupting memory.
The fix below increases the max to 32 (used on omap3) and also adds a
BUG() if the platform code requests more than the max.
This memory corruption was triggering various forms of crashes/panics
with kmem_cache_alloc() in the backtrace.
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Looks ok, I'll put to my series.
---
drivers/usb/musb/musb_core.c |1 +
drivers/usb/musb/musb_core.h |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c939f81..a132d9f 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1806,6 +1806,7 @@ allocate_instance(struct device *dev,
musb->ctrl_base = mbase;
musb->nIrq = -ENODEV;
musb->config = config;
+ BUG_ON(musb->config->num_eps > MUSB_C_NUM_EPS);
It's good to have this check here.
for (epnum = 0, ep = musb->endpoints;
epnum < musb->config->num_eps;
epnum++, ep++) {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 8222725..5040ceb 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -153,7 +153,7 @@ static inline void musb_host_rx(struct musb *m, u8 e) {}
/** CONSTANTS /
#ifndef MUSB_C_NUM_EPS
-#define MUSB_C_NUM_EPS ((u8)16)
+#define MUSB_C_NUM_EPS ((u8)32)
16 is the right number.
If 16 is the right number, arch/arm/mach-omap2/usb-musb.c going to
trigger this BUG every time since it sets num_eps = 32.
I don't know much about MUSB enbpoints, but if 16 is the correct max,
then the platform code should be updated.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] McBSP DMA support for 34xx
On Wed, 10 Sep 2008 15:47:34 +0530 "ext shekhar, chandra" <[EMAIL PROTECTED]> wrote: > Most importantly, > 4> McBSP buffer ( To save power, for 34xx). > OMAP3430 McBSP interface 2 has 5k buffer for audio. handling of this > buffer should be specific to McBSP. > Actually it's not specific to McBSP only. I haven't paid attention into these HW buffering issues but they have an effect. Like - IRCC ALSA expects that playback/record is really stopped when trigger callback returns - How HW buffering affects pointer callback? Some low-latency audio algorithms require that buffer position is known very precisely. E.g. if modifying already queued audio buffer content but which is not played out yet Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
Hi,
> On Mon, Sep 08, 2008 at 01:03:35PM -0500, [EMAIL PROTECTED] wrote:
> > +#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
> > + static int use_prefetch = 1;
> > +
> > + /* "modprobe ... use_prefetch=0" etc */
> > + module_param(use_prefetch, bool, 0);
> > + MODULE_PARM_DESC(use_prefetch, "enable/disable use of PREFETCH");
>
> Don't indent C code just because there's preprocessor stuff around it.
Ok, I will remove it.
> > + init_completion(&info->comp);
> > + dma_sync_single_for_cpu(&info->pdev->dev,
> > + virt_to_phys(addr), count, DMA_TO_DEVICE);
>
> Please read the DMA API and use the proper functions. This is an abuse
> of the DMA API.
>
> > + omap_start_dma(info->dma_ch);
> > + wait_for_completion(&info->comp);
> > + if (!is_write)
> > + dma_sync_single_for_cpu(&info->pdev->dev,
> > + virt_to_phys(addr), count, DMA_FROM_DEVICE);
>
> Ditto. This is an abuse of the API. This is how it's supposed to work:
>
>
> enum dma_direction dir = is_write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> dma_addr_t dma_addr;
>
> dma_addr = dma_map_single(&info->pdev->dev, addr, count, dir);
>
> /* setup and start DMA using dma_addr */
>
> wait_for_completion(&info->comp);
>
> dma_unmap_single(&info->pdev->dev, dma_addr, count, dir);
>
I will fix this in my next patch.
> > @@ -201,11 +304,33 @@
> > struct omap_nand_info *info = container_of(mtd,
> > struct omap_nand_info, mtd);
> > u16 *p = (u16 *) buf;
> > -
> > - len >>= 1;
> > -
> > - while (len--)
> > - *p++ = cpu_to_le16(readw(info->nand.IO_ADDR_R));
>
> This driver needs work (see endianness explaination below.)
This has been fixed by David Brownell, and I will re-base my patch on top of it.
> > + while (len) {
> > + bytes_to_read = ((prefetch_status >> 24) &
> > 0x7F) >> 1;
> > + for (i = 0; (i < bytes_to_read) && (len);
> > i++, len -= 2)
> > + *p++ = cpu_to_le16(*(volatile u16
> > *)(info->nand_pref_fifo_add));
>
> Yet you dereference it. This is illegal according to the Linux APIs.
> Use __raw_readw() here.
Ok, I will do this.
> Moreover, 'p' is a pointer to CPU endian memory, not le16 memory, so
> using cpu_to_le16 is wrong here. What endian is there data in flash?
Accessing nand flash is done by prefetch engine, which is also part of omap,
so has same endianness.
Yes I will remove cpu_to_le16 in my next patch.
Thanks,
vimal--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: fix memory corruption when using more than max endpoints
Let's keep linux-usb on the loop for musb related patches ;-)
On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
> There is no check if platform code passes in more endpoints (num_eps)
> than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
> that allocate_instance() happily writes past the end of 'struct musb'
> corrupting memory.
>
> The fix below increases the max to 32 (used on omap3) and also adds a
> BUG() if the platform code requests more than the max.
>
> This memory corruption was triggering various forms of crashes/panics
> with kmem_cache_alloc() in the backtrace.
>
> Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
Looks ok, I'll put to my series.
> ---
> drivers/usb/musb/musb_core.c |1 +
> drivers/usb/musb/musb_core.h |2 +-
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index c939f81..a132d9f 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1806,6 +1806,7 @@ allocate_instance(struct device *dev,
> musb->ctrl_base = mbase;
> musb->nIrq = -ENODEV;
> musb->config = config;
> + BUG_ON(musb->config->num_eps > MUSB_C_NUM_EPS);
It's good to have this check here.
> for (epnum = 0, ep = musb->endpoints;
> epnum < musb->config->num_eps;
> epnum++, ep++) {
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index 8222725..5040ceb 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -153,7 +153,7 @@ static inline void musb_host_rx(struct musb *m, u8 e) {}
> /** CONSTANTS /
>
> #ifndef MUSB_C_NUM_EPS
> -#define MUSB_C_NUM_EPS ((u8)16)
> +#define MUSB_C_NUM_EPS ((u8)32)
16 is the right number.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] McBSP DMA support for 34xx
- Original Message - From: "Tony Lindgren" <[EMAIL PROTECTED]> To: "shekhar, chandra" <[EMAIL PROTECTED]> Cc: "Jarkko Nikula" <[EMAIL PROTECTED]>; Sent: Tuesday, September 09, 2008 10:01 PM Subject: Re: [PATCH 1/2] McBSP DMA support for 34xx * shekhar, chandra <[EMAIL PROTECTED]> [080828 04:21]: - Original Message - From: "Jarkko Nikula" <[EMAIL PROTECTED]> To: "ext chandra shekhar" <[EMAIL PROTECTED]> Cc: Sent: Thursday, August 28, 2008 4:22 PM Subject: Re: [PATCH 1/2] McBSP DMA support for 34xx On Thu, 28 Aug 2008 13:56:00 +0530 (IST) "ext chandra shekhar" <[EMAIL PROTECTED]> wrote: This patch supports DMA chaining mode and one time configuration for entire transfer to improve performance. Signed-off-by: chandra shekhar <[EMAIL PROTECTED]> --- arch/arm/mach-omap2/mcbsp.c | 702 +- arch/arm/plat-omap/mcbsp.c| 19 - include/asm-arm/arch-omap/mcbsp.h | 127 +- 3 files changed, 811 insertions(+), 37 deletions(-) Hi What's the expected use case for DMA chaining mode or existing driver which would get improved performance? There should have some reason why this amount of new lines should be added. current McBSP ( arch/arm/plat-omap/mcbsp.c) code request and releases dma channel for each transfer . so there is latency involved. Chaining help with smooth audio play because we can enque the buffer while another transfer is ongoing. But the omap ASoC does already circular dma that automatically loops back to the beginning of fifo as long as there's data. How would the chaining help with this? Maybe update your codec to work with omap ASoC and see if you still need chaining? Yes, Codec driver can be modified to adapt OMAP ASoC. but there are some additional features. 1> 16/24 bit mono and stereo data transfer 2> Separate Rx and Tx path, enable only respective path. 3> data transfer in 8,16,32 bit mode Most importantly, 4> McBSP buffer ( To save power, for 34xx). OMAP3430 McBSP interface 2 has 5k buffer for audio. handling of this buffer should be specific to McBSP. Apart from that this is a generic McBSP code which will not interrupt the ASoC functionality. In OMAP ASoC code the channel is linked to itself , i am not sure about latency in that case, but if DMA channels are available we can use chaining of two channels in ASoC. this might reduce latency. Also ideally this should cover also OMAP1's from 16xx onward since they can link DMA channels together as well? Current code might even work for 16xx and later versions for 16 bit data. ( or can be extended to work on 16xx and later versions) but i dont have board or TRM to check for any changes in DMA subsytem or McBSP. better to play safe. 2430 onwards McBSP dxr/drr is 32 bits, which allows 24 bit mono/stereo transfer easily. if we had to have 16 bit dxr1,2/drr1,2 then we will have to perform the manipulation on data for 24 bit ops. we will have to consider all the options before extending it to 16xx. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in twl4030backupbatt_voltage()
Tony Lindgren wrote: * Adrian Hunter <[EMAIL PROTECTED]> [080903 08:08]: In the omap tree, commit f91fd98be045bec9c18e13110f22dafd44cb84b5 fixed a bug with the use of function twl4030_madc_conversion() relating to the local variable 'struct twl4030_madc_request req' not being fully initialised. The same problem appears to be in the function twl4030backupbatt_voltage() which is in drivers/power/twl4030_bci_battery.c Thanks, I'll initialize it to NULL. Wouldn't it have been easier just to write a patch instead of the description above? :) Apparently. There is also req.do_avg which should be zero, if you assume the programmer's intent was to have uninitialised members set to zero. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] This patch fixes the typo which breaks the build on OMAP1
On Tue, 9 Sep 2008 13:10:59 +0530
"ext Arun KS" <[EMAIL PROTECTED]> wrote:
> diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
> index a217cf2..3a4cc4b 100644
> --- a/sound/soc/omap/omap-mcbsp.c
> +++ b/sound/soc/omap/omap-mcbsp.c
> @@ -96,7 +96,7 @@ static const int omap24xx_dma_reqs[][2] = {
> #endif
> };
> #else
> -static const int omap2420_dma_reqs[][2] = {};
> +static const int omap24xx_dma_reqs[][2] = {};
> #endif
>
Thanks, this is true. Is it ok if I add this fix directly in my
original patch when I have chance to send it to alsa-devel?
Acked-by: Jarkko Nikula <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
