Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Hi, On Wed, Sep 15, 2010 at 10:40:08PM -0500, G, Manjunath Kondaiah wrote: In that case, the dma_read/dma_write macros will be splitted into: static inline void omap1_dma_write(...); static inline void omap2_dma_write(...); static inline u32 omap1_dma_read(...); static inline u32 omap2_dma_read(...); i.e., Two macro definitions will expand into four internal functions. why do you need separate methods for omap1 and omap2 ?? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
Hi, On Wed, Sep 15, 2010 at 08:10:15AM -0500, Sergei Shtylyov wrote: I don't see what to rework. The last short packet should still satisfy (request-actual == request-length) condition, no? of course not, it's short not zero. so the last short packet can be anything from 1 to 511 bytes. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Wednesday, September 15, 2010 2:15 PM This patch fixes this problem by ensuring the branch prediction logic is disabled while changing the L3 clock frequency. The branch prediction logic is disabled by clearing the Z-bit in the ARM AUX CTRL register. Small correction, Z bit is in CR register. AUX CTRL figures in with the ASA feature. Really nice changelog. I wish every patch had a description this good. Patch looks really good, too. Queued for 2.6.37. It is system specific if this change is required. It is probably safer to have it than not. If the AUX CTRL register has the ASA bit/feature active to allow speculative accesses to propagate past the L2 boundary the Z bit should be cleared as in the patch. However, if ASA bit is not activated then Z bit clearing should not be necessary as speculation will be squashed if there is no L2 hit (so no DDR request will be generated). It is not recommended to enable ASA bit as it is known to cause some issues on EMU/HS devices. It was also projected as loosing more than it gained across some benchmarks. Early boot loaders used to set the ASA. It was removed long back. Some kernels kept the value and opened up the lockup window. I don't recall the linux-omap open kernel having the issue. Some vendor ones did over time. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] overo twl4030: fix twl4030 IRQ (used for usb otg detection)
On Wed, Sep 15, 2010 at 04:28:57PM -0500, Steve Sakoman wrote: On Wed, Sep 15, 2010 at 9:29 AM, Anti Sullin anti.sul...@artecdesign.ee wrote: I was not getting OTG USB vbus/id pin change interrupts on Gumstix Overo and the reason was a mis-configured irq. I added some more checks to avoid having a non-bootable kernel on boards with bootloaders that have wrong pinmux. The changes of twl4030 should be tested on other boards too. --- Gumstix Overo has TPS65950 (TWL4030) IRQ1 connected to GPIO112. I don't think that this change should be made. From what I understand from my discussions with Gumstix, early versions of the Overo COM used GPIO112 as indicated above. However all fab revisions =2516 use GPIO0, so the code is correct for current and future versions of Overo COMs (as is the bootloader pinmuxing). In fact, future versions of Overo will use GPIO112 for a revision ID. Not an ideal situation, but I think we should leave things as they are since it matches current and future production. People with older boards will certainly need to use this patch to get vbus/id interrupts. it would be better to get all boards working. Can't you use ATAG_REVISION or system_rev to differentiate the board revisions and change gpio number accordingly ?? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
On Thu, Sep 16, 2010 at 11:35 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Sep 15, 2010 at 08:10:15AM -0500, Sergei Shtylyov wrote: I don't see what to rework. The last short packet should still satisfy (request-actual == request-length) condition, no? of course not, it's short not zero. so the last short packet can be anything from 1 to 511 bytes. If it's TX, both condtions should automatically be true, right? - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
On Thu, Sep 16, 2010 at 01:15:32AM -0500, Gadiyar, Anand wrote: On Thu, Sep 16, 2010 at 11:35 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Sep 15, 2010 at 08:10:15AM -0500, Sergei Shtylyov wrote: I don't see what to rework. The last short packet should still satisfy (request-actual == request-length) condition, no? of course not, it's short not zero. so the last short packet can be anything from 1 to 511 bytes. If it's TX, both condtions should automatically be true, right? even in mode1 ? I have to revist my docs, but afaict mode1 won't transmit last short packet, no matter if it's tx or rx. Could be wrong, though. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Woodruff, Richard Sent: Thursday, September 16, 2010 11:36 AM To: Paul Walmsley; Hunter, Jon Cc: linux-omap; khil...@deeprootsystems.com; t...@atomide.com Subject: RE: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Wednesday, September 15, 2010 2:15 PM This patch fixes this problem by ensuring the branch prediction logic is disabled while changing the L3 clock frequency. The branch prediction logic is disabled by clearing the Z-bit in the ARM AUX CTRL register. Small correction, Z bit is in CR register. AUX CTRL figures in with the ASA feature. Really nice changelog. I wish every patch had a description this good. Patch looks really good, too. Queued for 2.6.37. It is system specific if this change is required. It is probably safer to have it than not. If the AUX CTRL register has the ASA bit/feature active to allow speculative accesses to propagate past the L2 boundary the Z bit should be cleared as in the patch. However, if ASA bit is not activated then Z bit clearing should not be necessary as speculation will be squashed if there is no L2 hit (so no DDR request will be generated). It is not recommended to enable ASA bit as it is known to cause some issues on EMU/HS devices. It was also projected as loosing more than it gained across some benchmarks. Early boot loaders used to set the ASA. It was removed long back. Some kernels kept the value and opened up the lockup window. I don't recall the linux-omap open kernel having the issue. Some vendor ones did over time. The code seems to be correct but just the description has typo. The code is using control register. I just corrected the description and white space issue. Here is updated patch. Paul, You can use this version if you like From fd4250671a1ae8deb718ac3688ea8971df7524cf Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Thu, 16 Sep 2010 12:03:23 +0530 Subject: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency When changing the L3 clock frequency, the CPU is executing from internal RAM and the SDRC clock is disabled. During this time accesses made to external DDR are stalled. If the ARM subsystem attempts to access the DDR while the SDRC clock is disabled this will stall the CPU until the access to the SDRC timeouts. A timeout on the SDRC should never occur. Once a timeout occurs all the following accesses will be aborted and the DDR is no longer accessible. Although the code being executed in the internal RAM does not directly access the DDR, it was found that the branch prediction logic in the CPU may cause the CPU to prefetch code from a DDR location while the SDRC clock is disabled. This was causing an SDRC timeout which resulted in a system hang. This patch fixes this problem by ensuring the branch prediction logic is disabled while changing the L3 clock frequency. The branch prediction logic is disabled by clearing the Z-bit in the ARM CTRL register. Disabling the branch prediction logic does not have any noticable impact on the execution time of this code section. The hardware observability signals were used to monitor the sdrc idle time with and without this patch when operating at different CPU frequencies (150MHz, 500MHz and 600MHz) and the total sdrc idle time when changing frequenct was in the range of 9-11us. This was measured on an omap3430 SDP running the omapzoom p-android-omap-2.6.29 branch. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/sram34xx.S |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index de99ba2..3637274 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -129,8 +129,11 @@ ENTRY(omap3_sram_configure_core_dpll) ldr r4, [sp, #80] str r4, omap_sdrc_mr_1_val skip_cs1_params: + mrc p15, 0, r8, c1, c0, 0 @ read ctrl register + bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction + mcr p15, 0, r10, c1, c0, 0 @ write ctrl register dsb @ flush buffered writes to interconnect - + isb @ prevent speculative exec past here cmp r3, #1 @ if increasing SDRC clk rate, bleqconfigure_sdrc @ program the SDRC regs early (for RFR) cmp r1, #SDRC_UNLOCK_DLL@ set the intended DLL state @@ -148,6 +151,7 @@ skip_cs1_params: beq return_to_sdram @ return to SDRAM code, otherwise, bl configure_sdrc @ reprogram SDRC regs now return_to_sdram: + mcr p15, 0, r8, c1, c0, 0 @
RE: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
-Original Message-
From: Balbi, Felipe
Sent: Thursday, September 16, 2010 11:33 AM
To: G, Manjunath Kondaiah
Cc: Balbi, Felipe; Kevin Hilman; linux-omap@vger.kernel.org;
Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device
registration
Hi,
On Wed, Sep 15, 2010 at 10:40:08PM -0500, G, Manjunath Kondaiah wrote:
In that case, the dma_read/dma_write macros will be splitted into:
static inline void omap1_dma_write(...); static inline void
omap2_dma_write(...); static inline u32 omap1_dma_read(...); static
inline u32 omap2_dma_read(...);
i.e., Two macro definitions will expand into four internal functions.
why do you need separate methods for omap1 and omap2 ??
Current macro definition is:
#define dma_read(reg) \
({ \
u32 __val; \
if (cpu_class_is_omap1()) \
__val = __raw_readw(omap_dma_base + OMAP1_DMA_##reg); \
else\
__val = __raw_readl(omap_dma_base + OMAP_DMA4_##reg); \
__val; \
})
Since we are expanding abbrevated register offsets into full macro, hence
these macros should be used in respective read/write functions(omap1 and
omap2plus).
Any other better methods?
-Manjunath--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Hi,
On Thu, Sep 16, 2010 at 01:32:58AM -0500, G, Manjunath Kondaiah wrote:
#define dma_read(reg) \
({ \
u32 __val; \
if (cpu_class_is_omap1()) \
__val = __raw_readw(omap_dma_base + OMAP1_DMA_##reg); \
else\
__val = __raw_readl(omap_dma_base + OMAP_DMA4_##reg); \
__val; \
})
Since we are expanding abbrevated register offsets into full macro,
hence these macros should be used in respective read/write
functions(omap1 and omap2plus).
Any other better methods?
generally we always define static inlines for read{b,w,l} and write{b,
w, l}, so instead of calling them omap1_* and omap2_* call them
something like omap_dma_readw(), omap_dma_readl().
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Balbi,
-Original Message-
From: Balbi, Felipe
Sent: Thursday, September 16, 2010 12:11 PM
To: G, Manjunath Kondaiah
Cc: Balbi, Felipe; Kevin Hilman; linux-omap@vger.kernel.org;
Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device
registration
Hi,
On Thu, Sep 16, 2010 at 01:32:58AM -0500, G, Manjunath Kondaiah wrote:
#define dma_read(reg)
\
({
\
u32 __val;
\
if (cpu_class_is_omap1())
\
__val = __raw_readw(omap_dma_base +
OMAP1_DMA_##reg); \
else
\
__val = __raw_readl(omap_dma_base +
OMAP_DMA4_##reg); \
__val;
\
})
Since we are expanding abbrevated register offsets into full macro,
hence these macros should be used in respective read/write
functions(omap1 and omap2plus).
Any other better methods?
generally we always define static inlines for read{b,w,l} and
write{b, w, l}, so instead of calling them omap1_* and
omap2_* call them something like omap_dma_readw(), omap_dma_readl().
I am ok with naming convention. But two macros will get converted into
four static inline functions and respective functions will get repeated in
mach-omap1 and mach-omap2.
Due to this, two macros in plat-omap will get converted into 8 static inline
functions.
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
2010/9/16 Felipe Balbi ba...@ti.com: If it's TX, both condtions should automatically be true, right? even in mode1 ? I have to revist my docs, but afaict mode1 won't transmit last short packet, no matter if it's tx or rx. Could be wrong, though. Seems short packet is always sent using mode 0, see txstate. -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Hi Felipe,
On 9/16/2010 8:53 AM, G, Manjunath Kondaiah wrote:
Balbi,
Stupid question, is your first name Felipe or balbi?
You sign with balbi... that's with it is confusing...
Thanks,
Benoit
-Original Message-
From: Balbi, Felipe
Sent: Thursday, September 16, 2010 12:11 PM
To: G, Manjunath Kondaiah
Cc: Balbi, Felipe; Kevin Hilman; linux-omap@vger.kernel.org;
Cousson, Benoit; Shilimkar, Santosh
Subject: Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device
registration
Hi,
On Thu, Sep 16, 2010 at 01:32:58AM -0500, G, Manjunath Kondaiah wrote:
#define dma_read(reg)
\
({
\
u32 __val;
\
if (cpu_class_is_omap1())
\
__val = __raw_readw(omap_dma_base +
OMAP1_DMA_##reg); \
else
\
__val = __raw_readl(omap_dma_base +
OMAP_DMA4_##reg); \
__val;
\
})
Since we are expanding abbrevated register offsets into full macro,
hence these macros should be used in respective read/write
functions(omap1 and omap2plus).
Any other better methods?
generally we always define static inlines for read{b,w,l} and
write{b, w, l}, so instead of calling them omap1_* and
omap2_* call them something like omap_dma_readw(), omap_dma_readl().
I am ok with naming convention. But two macros will get converted into
four static inline functions and respective functions will get repeated in
mach-omap1 and mach-omap2.
Due to this, two macros in plat-omap will get converted into 8 static inline
functions.
-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Hi, On Thu, Sep 16, 2010 at 01:58:13AM -0500, Cousson, Benoit wrote: Stupid question, is your first name Felipe or balbi? You sign with balbi... that's with it is confusing... Felipe. Balbi is family name. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] twl4030-madc driver
On Thu, 16 Sep 2010 11:04:24 +0530, Keerthy wrote: MADC(Monitoring ADC) driver enables monitoring analog signals using analog-to-digital conversion (ADC) on the input source. The MADC driver is being added under the Hwmon class of drivers. To get the context, the last set of comments can be found here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19981.html Several people have contributed to this driver on the linux-omap list. Keerthy (2): hwmon: twl4030: Driver for twl4030 madc module Makefile and Kconfig changes for twl4030-madc driver arch/arm/mach-omap2/Kconfig |4 + drivers/hwmon/Kconfig|4 + drivers/hwmon/Makefile |1 + drivers/hwmon/twl4030-madc.c | 584 ++ include/linux/i2c/twl4030-madc.h | 118 5 files changed, 711 insertions(+), 0 deletions(-) create mode 100644 drivers/hwmon/twl4030-madc.c create mode 100644 include/linux/i2c/twl4030-madc.h Please send hwmon drivers to the lm-sensors list as instructed by MAINTAINERS. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 0/4] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on linux-2.6. v4: resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (5): Merge branches 'master' and 'master' of git://git.kernel.org/.../torvalds/linux-2.6 omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-flash.c |5 +- arch/arm/mach-omap2/gpmc.c | 15 ++- arch/arm/plat-omap/include/plat/gpmc.h |9 +- arch/arm/plat-omap/include/plat/irqs.h |1 + arch/arm/plat-omap/include/plat/nand.h |7 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 --- 7 files changed, 294 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 3/4] omap: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-flash.c |3 ++-
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 29 +
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 4871d71..5f74c8f 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -144,7 +144,8 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
gpmc_nand_init(board_nand_data);
}
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 5e69463..2e026e4 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -23,6 +23,12 @@ struct omap_nand_platform_data {
int gpmc_irq;
unsigned long phys_base;
int devsize;
+ enum {
+ OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT = 0,
+ /* 1-bit s/w ecc and layout different from romcode */
+ OMAP_ECC_HAMMING_CODE_HW,/* 1-bit ecc, romcode layout */
+ OMAP_ECC_HAMMING_CODE_SW,/* 1-bit ecc, romcode layout */
+ } ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d457b9b..dbbd699 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,7 +7,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#define CONFIG_MTD_NAND_OMAP_HWECC
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -658,8 +657,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -879,8 +876,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1059,17 +1054,19 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
info-nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info-nand.ecc.bytes= 3;
- info-nand.ecc.size = 512;
- info-nand.ecc.calculate= omap_calculate_ecc;
- info-nand.ecc.hwctl= omap_enable_hwecc;
- info-nand.ecc.correct = omap_correct_data;
- info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) ||
+ (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW)) {
+ info-nand.ecc.bytes= 3;
+ info-nand.ecc.size = 512;
+ info-nand.ecc.calculate= omap_calculate_ecc;
+ info-nand.ecc.hwctl= omap_enable_hwecc;
+ info-nand.ecc.correct = omap_correct_data;
+ info-nand.ecc.mode = NAND_ECC_HW;
+
+ } else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_SW) {
+ info-nand.ecc.mode = NAND_ECC_SOFT;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 2/4] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 24 +++-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 86a6f78..8871a91 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -58,7 +58,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -592,15 +591,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
/**
* gpmc_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
* @dma_mode: dma mode enable (1) or disable (0)
* @u32_count: number of bytes to be transferred
* @is_write: prefetch read(0) or write post(1) mode
*/
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ printk(KERN_ERR PREFETCH Fifo Threshold is not supported\n);
+ return -1;
+ } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
@@ -608,7 +611,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d834740..d457b9b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -275,7 +275,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -319,7 +320,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -373,10 +375,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+
[PATCH RESEND v4 4/4] omap: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-flash.c |2 +-
drivers/mtd/nand/omap2.c | 34 ++
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 5f74c8f..d71c511 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -145,7 +145,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW;
gpmc_nand_init(board_nand_data);
}
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index dbbd699..33c356b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -128,6 +128,20 @@ const int use_dma;
const int use_interrupt;
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -945,6 +959,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1079,6 +1094,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata-ecc_opt != OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) {
+ offset = (info-nand.options NAND_BUSWIDTH_16) ? 2 : 1;
+ if (info-mtd.oobsize == 16) {
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ omap_oobinfo.eccbytes = 3;
+ } else
+ omap_oobinfo.eccbytes = 3 * 4;
+
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for NAND.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |2 +
arch/arm/mach-omap2/gpmc.c |4 +
arch/arm/plat-omap/include/plat/gpmc.h |4 +
arch/arm/plat-omap/include/plat/irqs.h |1 +
arch/arm/plat-omap/include/plat/nand.h |1 +
drivers/mtd/nand/Kconfig | 14 ++-
drivers/mtd/nand/omap2.c | 198 +++-
7 files changed, 217 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ac834aa..4871d71 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -17,6 +17,7 @@
#include linux/mtd/physmap.h
#include linux/io.h
+#include plat/irqs.h
#include plat/gpmc.h
#include plat/nand.h
#include plat/onenand.h
@@ -133,6 +134,7 @@ static struct omap_nand_platform_data board_nand_data = {
.nand_setup = NULL,
.gpmc_t = nand_timings,
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .gpmc_irq = INT_34XX_GPMC_IRQ,
.dev_ready = NULL,
.devsize= 0,/* '0' for 8-bit, '1' for 16-bit device */
};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index f46933b..86a6f78 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -487,6 +487,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
u32 regval = 0;
switch (cmd) {
+ case GPMC_ENABLE_IRQ:
+ gpmc_write_reg(GPMC_IRQENABLE, wval);
+ break;
+
case GPMC_SET_IRQ_STATUS:
gpmc_write_reg(GPMC_IRQSTATUS, wval);
break;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..054e704 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -41,6 +41,8 @@
#define GPMC_NAND_ADDRESS 0x000b
#define GPMC_NAND_DATA 0x000c
+#define GPMC_ENABLE_IRQ0x000d
+
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
@@ -78,6 +80,8 @@
#define WR_RD_PIN_MONITORING 0x0060
#define GPMC_PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
#define GPMC_PREFETCH_STATUS_COUNT(val)(val 0x3fff)
+#define GPMC_IRQ_FIFOEVENTENABLE 0x01
+#define GPMC_IRQ_COUNT_EVENT 0x02
/*
* Note that all values in this struct are in nanoseconds, while
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index c01d9f0..fd6d677 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -318,6 +318,7 @@
#define INT_34XX_PRCM_MPU_IRQ 11
#define INT_34XX_MCBSP1_IRQ16
#define INT_34XX_MCBSP2_IRQ17
+#define INT_34XX_GPMC_IRQ 20
#define INT_34XX_MCBSP3_IRQ22
#define INT_34XX_MCBSP4_IRQ23
#define INT_34XX_CAM_IRQ 24
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..5e69463 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -20,6 +20,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8b4b67c..88cea0c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -112,6 +112,9 @@ config MTD_NAND_OMAP_PREFETCH
help
The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
to improve the performance.
+GPMC PREFETCH can be configured eigther in MPU interrupt mode or in DMA
+interrupt mode. If not selected any of them prefetch will be used in
+polling mode.
config MTD_NAND_OMAP_PREFETCH_DMA
depends on MTD_NAND_OMAP_PREFETCH
@@ -120,7 +123,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA
help
The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
+Say y for DMA mode
+
+config MTD_NAND_OMAP_PREFETCH_IRQ
+ depends on MTD_NAND_OMAP_PREFETCH !MTD_NAND_OMAP_PREFETCH_DMA
+ bool IRQ mode
+ default n
+ help
+The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
+or in DMA interrupt mode.
+Say y for IRQ mode
config MTD_NAND_IDS
tristate
diff --git
[PATCH 1/5] omap3: Introduce CompuLab CM-T3517 module.
Add basic suppot, enable uart and led.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig |7 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-cm-t3517.c | 109 ++
3 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b48bacf..da1c37d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -214,6 +214,13 @@ config MACH_CM_T35
select OMAP_PACKAGE_CUS
select OMAP_MUX
+config MACH_CM_T3517
+ bool CompuLab CM-T3517 module
+ depends on ARCH_OMAP3
+ default y
+ select OMAP_PACKAGE_CBB
+ select OMAP_MUX
+
config MACH_IGEP0020
bool IGEP v2 board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..7d991d0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_MACH_OMAP_3630SDP) +=
board-3630sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
+obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
new file mode 100644
index 000..507d2d5
--- /dev/null
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -0,0 +1,109 @@
+/*
+ * linux/arch/arm/mach-omap2/board-cm-t3517.c
+ *
+ * Support for the CompuLab CM-T3517 modules
+ *
+ * Copyright (C) 2010 CompuLab, Ltd.
+ * Author: Igor Grinberg grinb...@compulab.co.il
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/leds.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/control.h
+
+#include mux.h
+
+#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+static struct gpio_led cm_t3517_leds[] = {
+ [0] = {
+ .gpio = 186,
+ .name = cm-t3517:green,
+ .default_trigger= heartbeat,
+ .active_low = 0,
+ },
+};
+
+static struct gpio_led_platform_data cm_t3517_led_pdata = {
+ .num_leds = ARRAY_SIZE(cm_t3517_leds),
+ .leds = cm_t3517_leds,
+};
+
+static struct platform_device cm_t3517_led_device = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = cm_t3517_led_pdata,
+ },
+};
+
+static void __init cm_t3517_init_leds(void)
+{
+ platform_device_register(cm_t3517_led_device);
+}
+#else
+static inline void cm_t3517_init_leds(void) {}
+#endif
+
+
+static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
+};
+
+static void __init cm_t3517_init_irq(void)
+{
+ omap_board_config = cm_t3517_config;
+ omap_board_config_size = ARRAY_SIZE(cm_t3517_config);
+
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_board_mux board_mux[] __initdata = {
+ /* GPIO186 - Green LED */
+ OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+
+static void __init cm_t3517_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+ cm_t3517_init_leds();
+}
+
+MACHINE_START(CM_T3517, Compulab CM-T3517)
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xd800) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = cm_t3517_init_irq,
+ .init_machine = cm_t3517_init,
+ .timer = omap_timer,
+MACHINE_END
--
1.7.1
--
To unsubscribe from this list: send the line
[PATCH 0/5] Support for CompuLab CM-T3517 modules
CompuLab CM-T3517 module is based on AM3517 (Sitara) SoC. CM-T3517 supports on-board 256/128MB DDR2 DRAM, 512/128MB NAND flash, WIFI-BlueTooth combo chip, USB HUB, AC97 Codec, TouchScreen controller, RTC. This patch series add a basic support for CM-T3517 and some of its peripheral devices. Based on: commit da22d713d1149f528a734a10ea264c91a804662a Merge: 8f3ce99 8475b9e Author: Tony Lindgren t...@atomide.com Date: Mon Sep 13 21:17:04 2010 -0700 Linux-omap rebuilt: Updated to -rc4 Igor Grinberg (5): omap3: Introduce CompuLab CM-T3517 module. omap3: cm-t3517: add support for v3020 rtc. omap3: cm-t3517: add support for usb host. omap3: cm-t3517: add support for NAND flash omap3: cm-t3517: add support for TI HECC arch/arm/mach-omap2/Kconfig |7 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-cm-t3517.c | 295 ++ 3 files changed, 303 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] omap3: cm-t3517: add support for v3020 rtc.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c | 36 ++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 507d2d5..2b41c6d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -27,6 +27,7 @@
#include linux/platform_device.h
#include linux/gpio.h
#include linux/leds.h
+#include linux/rtc-v3020.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -69,6 +70,35 @@ static void __init cm_t3517_init_leds(void)
static inline void cm_t3517_init_leds(void) {}
#endif
+#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
+#define RTC_IO_GPIO(153)
+#define RTC_WR_GPIO(154)
+#define RTC_RD_GPIO(160)
+#define RTC_CS_GPIO(163)
+
+struct v3020_platform_data cm_t3517_v3020_pdata = {
+ .use_gpio = 1,
+ .gpio_cs= RTC_CS_GPIO,
+ .gpio_wr= RTC_WR_GPIO,
+ .gpio_rd= RTC_RD_GPIO,
+ .gpio_io= RTC_IO_GPIO,
+};
+
+static struct platform_device cm_t3517_rtc_device = {
+ .name = v3020,
+ .id = -1,
+ .dev= {
+ .platform_data = cm_t3517_v3020_pdata,
+ }
+};
+
+static void __init cm_t3517_init_rtc(void)
+{
+ platform_device_register(cm_t3517_rtc_device);
+}
+#else
+static inline void cm_t3517_init_rtc(void) {}
+#endif
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -86,6 +116,11 @@ static void __init cm_t3517_init_irq(void)
static struct omap_board_mux board_mux[] __initdata = {
/* GPIO186 - Green LED */
OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* RTC GPIOs: IO, WR#, RD#, CS# */
+ OMAP3_MUX(MCBSP4_DR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -95,6 +130,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+ cm_t3517_init_rtc();
}
MACHINE_START(CM_T3517, Compulab CM-T3517)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] omap3: cm-t3517: add support for TI HECC
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c | 45 ++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index d4399e7..ff927db 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/can/platform/ti_hecc.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -44,6 +45,8 @@
#include plat/nand.h
#include plat/gpmc.h
+#include mach/am35xx.h
+
#include mux.h
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
@@ -77,6 +80,47 @@ static void __init cm_t3517_init_leds(void)
static inline void cm_t3517_init_leds(void) {}
#endif
+#if defined(CONFIG_CAN_TI_HECC) || defined(CONFIG_CAN_TI_HECC_MODULE)
+static struct resource cm_t3517_hecc_resources[] = {
+ {
+ .start = AM35XX_IPSS_HECC_BASE,
+ .end= AM35XX_IPSS_HECC_BASE + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_HECC0_IRQ,
+ .end= INT_35XX_HECC0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct ti_hecc_platform_data cm_t3517_hecc_pdata = {
+ .scc_hecc_offset= AM35XX_HECC_SCC_HECC_OFFSET,
+ .scc_ram_offset = AM35XX_HECC_SCC_RAM_OFFSET,
+ .hecc_ram_offset= AM35XX_HECC_RAM_OFFSET,
+ .mbx_offset = AM35XX_HECC_MBOX_OFFSET,
+ .int_line = AM35XX_HECC_INT_LINE,
+ .version= AM35XX_HECC_VERSION,
+};
+
+static struct platform_device cm_t3517_hecc_device = {
+ .name = ti_hecc,
+ .id = 1,
+ .num_resources = ARRAY_SIZE(cm_t3517_hecc_resources),
+ .resource = cm_t3517_hecc_resources,
+ .dev= {
+ .platform_data = cm_t3517_hecc_pdata,
+ },
+};
+
+static void cm_t3517_init_hecc(void)
+{
+ platform_device_register(cm_t3517_hecc_device);
+}
+#else
+static inline void cm_t3517_init_hecc(void) {}
+#endif
+
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
@@ -236,6 +280,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
+ cm_t3517_init_hecc();
}
MACHINE_START(CM_T3517, Compulab CM-T3517)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] omap3: cm-t3517: add support for NAND flash
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c | 54 ++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 23cd9a1..d4399e7 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -29,6 +29,9 @@
#include linux/gpio.h
#include linux/leds.h
#include linux/rtc-v3020.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/partitions.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -38,6 +41,8 @@
#include plat/common.h
#include plat/control.h
#include plat/usb.h
+#include plat/nand.h
+#include plat/gpmc.h
#include mux.h
@@ -144,6 +149,54 @@ static inline int cm_t3517_init_usbh(void)
}
#endif
+#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition cm_t3517_nand_partitions[] = {
+ {
+ .name = xloader,
+ .offset = 0,/* Offset = 0x0 */
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = uboot,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = uboot environment,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 2 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = linux,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = rootfs,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data cm_t3517_nand_data = {
+ .parts = cm_t3517_nand_partitions,
+ .nr_parts = ARRAY_SIZE(cm_t3517_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .cs = 0,
+};
+
+static void __init cm_t3517_init_nand(void)
+{
+ if (gpmc_nand_init(cm_t3517_nand_data) 0)
+ pr_err(CM-T3517: NAND initialization failed\n);
+}
+#else
+static inline void cm_t3517_init_nand(void) {}
+#endif
+
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -180,6 +233,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+ cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] omap3: cm-t3517: add support for usb host.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c | 51 ++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 2b41c6d..23cd9a1 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -25,6 +25,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
+#include linux/delay.h
#include linux/gpio.h
#include linux/leds.h
#include linux/rtc-v3020.h
@@ -36,6 +37,7 @@
#include plat/board.h
#include plat/common.h
#include plat/control.h
+#include plat/usb.h
#include mux.h
@@ -100,6 +102,48 @@ static void __init cm_t3517_init_rtc(void)
static inline void cm_t3517_init_rtc(void) {}
#endif
+#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
+#define HSUSB1_RESET_GPIO (146)
+#define HSUSB2_RESET_GPIO (147)
+#define USB_HUB_RESET_GPIO (152)
+
+static struct ehci_hcd_omap_platform_data cm_t3517_ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = HSUSB1_RESET_GPIO,
+ .reset_gpio_port[1] = HSUSB2_RESET_GPIO,
+ .reset_gpio_port[2] = -EINVAL,
+};
+
+static int cm_t3517_init_usbh(void)
+{
+ int err;
+
+ err = gpio_request(USB_HUB_RESET_GPIO, usb hub rst);
+ if (err) {
+ pr_err(CM-T3517: usb hub reset gpio request failed: %d\n,
+ err);
+ } else {
+ gpio_direction_output(USB_HUB_RESET_GPIO, 0);
+ udelay(10);
+ gpio_set_value(USB_HUB_RESET_GPIO, 1);
+ msleep(1);
+ }
+
+ usb_ehci_init(cm_t3517_ehci_pdata);
+
+ return 0;
+}
+#else
+static inline int cm_t3517_init_usbh(void)
+{
+ return 0;
+}
+#endif
+
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -121,6 +165,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* HSUSB1 RESET */
+ OMAP3_MUX(UART2_TX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* HSUSB2 RESET */
+ OMAP3_MUX(UART2_RX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* CM-T3517 USB HUB nRESET */
+ OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -131,6 +181,7 @@ static void __init cm_t3517_init(void)
omap_serial_init();
cm_t3517_init_leds();
cm_t3517_init_rtc();
+ cm_t3517_init_usbh();
}
MACHINE_START(CM_T3517, Compulab CM-T3517)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
Hi,
On Thu, Sep 16, 2010 at 03:54:39AM -0500, Igor Grinberg wrote:
put a description here.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
[snip]
+static int cm_t3517_init_usbh(void)
+{
+ int err;
+
+ err = gpio_request(USB_HUB_RESET_GPIO, usb hub rst);
+ if (err) {
+ pr_err(CM-T3517: usb hub reset gpio request failed: %d\n,
+ err);
+ } else {
if (err) {
pr_err(...);
return err;
}
gpio_direction_output(...);
this will save you on identation level.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
Hi,
On 09/16/10 11:00, Felipe Balbi wrote:
Hi,
On Thu, Sep 16, 2010 at 03:54:39AM -0500, Igor Grinberg wrote:
put a description here.
This is a relatively small patch, is the subject not descriptive enough?
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
[snip]
+static int cm_t3517_init_usbh(void)
+{
+int err;
+
+err = gpio_request(USB_HUB_RESET_GPIO, usb hub rst);
+if (err) {
+pr_err(CM-T3517: usb hub reset gpio request failed: %d\n,
+ err);
+} else {
if (err) {
pr_err(...);
return err;
}
gpio_direction_output(...);
this will save you on identation level.
Yes it will, but even if the hub reset gpio is for some reason unavailable,
we don't want to disable ehci completely...
There are other ports, that are not wired through the hub.
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, August 28, 2010 5:23 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage
domain instance in the
voltage driver.
Thara Gopinath th...@ti.com writes:
This patch introduces a user list of devices associated with each
voltage domain instance. The user list is implemented using plist
structure with priority node populated with the voltage values.
This patch also adds an API which will take in a device and
requested voltage as parameters, adds the info to the user list
and returns back the maximum voltage requested by all the user
devices. This can be used anytime to get the voltage that the
voltage domain instance can be transitioned into.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 94
+
arch/arm/plat-omap/include/plat/voltage.h |2 +
2 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6a07fe9..4624250 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -24,6 +24,9 @@
#include linux/clk.h
#include linux/err.h
#include linux/debugfs.h
+#include linux/spinlock.h
+#include linux/plist.h
+#include linux/slab.h
#include plat/omap-pm.h
#include plat/omap34xx.h
@@ -95,6 +98,20 @@ struct vp_reg_val {
};
/**
+ * omap_vdd_user_list - The per vdd user list
+ *
+ * @dev: The device asking for the vdd to be set at a
particular
+ * voltage
+ * @node : The list head entry
+ * @volt : The voltage requested by the device dev
+ */
+struct omap_vdd_user_list {
+ struct device *dev;
+ struct plist_node node;
+ u32 volt;
+};
+
+/**
* omap_vdd_info - Per Voltage Domain info
*
* @volt_data : voltage table having the distinct voltages
supported
@@ -105,6 +122,9 @@ struct vp_reg_val {
* vp registers
* @volt_clk : the clock associated with the vdd.
* @opp_dev: the 'struct device' associated with this vdd.
+ * @user_lock : the lock to be used by the plist user_list
+ * @user_list : the list head maintaining the various users
+ * of this vdd with the voltage requested by each user.
* @volt_data_count: Number of distinct voltages supported by this
vdd.
* @nominal_volt : Nominal voltaged for this vdd.
* cmdval_reg : Voltage controller cmdval register.
@@ -117,6 +137,9 @@ struct omap_vdd_info{
struct clk *volt_clk;
struct device *opp_dev;
struct voltagedomain voltdm;
+ spinlock_t user_lock;
+ struct plist_head user_list;
+ struct mutex scaling_mutex;
int volt_data_count;
unsigned long nominal_volt;
u8 cmdval_reg;
@@ -785,11 +808,18 @@ static void __init vdd_data_configure(struct
omap_vdd_info *vdd)
struct dentry *vdd_debug;
char name[16];
#endif
+
if (cpu_is_omap34xx())
omap3_vdd_data_configure(vdd);
else if (cpu_is_omap44xx())
omap4_vdd_data_configure(vdd);
+ /* Init the plist */
+ spin_lock_init(vdd-user_lock);
+ plist_head_init(vdd-user_list, vdd-user_lock);
+ /* Init the DVFS mutex */
+ mutex_init(vdd-scaling_mutex);
+
#ifdef CONFIG_PM_DEBUG
strcpy(name, vdd_);
strcat(name, vdd-voltdm.name);
@@ -1142,6 +1172,70 @@ unsigned long omap_vp_get_curr_volt(struct
voltagedomain *voltdm)
}
/**
+ * omap_voltage_add_userreq : API to keep track of various requests to
+ * scale the VDD and returns the best possible
+ * voltage the VDD can be put to.
+ * @volt_domain: pointer to the voltage domain.
+ * @dev : the device pointer.
+ * @volt : the voltage which is requested by the device.
+ *
+ * This API is to be called before the actual voltage scaling is
+ * done to determine what is the best possible voltage the VDD can
+ * be put to. This API adds the device dev in the user list of the
+ * vdd volt_domain with volt as the requested voltage. The user list
+ * is a plist with the priority element absolute voltage values.
+ * The API then finds the maximum of all the requested voltages for
+ * the VDD and returns it back through volt pointer itself.
+ * Returns error value in case of any errors.
+ */
+int omap_voltage_add_userreq(struct voltagedomain *voltdm, struct device
*dev,
+ unsigned long *volt)
How about just omap_voltage_add_request()
Also, do we need both voltdm and dev? With your other patches, can't we
look up the voltm based on dev? Or, is there a need for a device to add
a request in a voltage domain other than the one to which it belongs?
Also, how
RE: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, August 28, 2010 6:23 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list
associated with a voltage
domain
Thara Gopinath th...@ti.com writes:
This patch adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
I think this should be done in two steps.
During init, each OPP
---
arch/arm/plat-omap/include/plat/opp.h |9 +
arch/arm/plat-omap/opp.c | 28
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 0e580ed..a4c1669 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -18,6 +18,7 @@
#include linux/cpufreq.h
#include plat/common.h
+#include plat/voltage.h
/**
* struct omap_opp_def - OMAP OPP Definition
@@ -86,6 +87,9 @@ int opp_disable(struct omap_opp *opp);
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count);
#else
static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
{
@@ -149,5 +153,10 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
{
}
+static inline struct device **opp_init_voltage_params(
+ struct voltagedomain *voltdm, int *dev_count)
+{
+}
+
#endif /* CONFIG_PM */
#endif /* __ASM_ARM_OMAP_OPP_H */
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index a3dea82..72dd62a 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -502,3 +502,31 @@ void opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
}
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count)
+{
+ struct device_opp *dev_opp;
+ struct device **dev_list;
+ int count = 0, i = 0;
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (!dev_opp-oh-vdd_name)
+ continue;
+
+ if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
+ dev_opp-oh-voltdm = voltdm;
Couldn't we assign the voltdm at opp_add() time since you added it as
part of the hwmod?
We cannot as the voltage layer is not initialized at the point of opp_add.
Having said this, today voltage layer is dependent on opp layer only to figure
out
the current nominal voltage from the opp table. If that can be some how
decoupled we
can initialize voltage layer early on and implement this.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 02, 2010 6:04 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list
associated with a voltage
domain
Thara Gopinath th...@ti.com writes:
This patch adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
I don't think the OPP layer is the right place for this after all.
How about something like this in the voltage layer:
omap_voltage_add_device(struct voltagedomain *voltdm, struct device *dev)
During omap_device_build(), if the hwmod has a voltage domain, it
calls this function to register it with the voltage layer.
This mandates voltage layer to be initialized before the first omap_device_build
has happened. I think that is going to be a very confusing sequencing. Also
today
voltage layer init happens later in the system.
This function then creates a list (internal to voltage layer) of all the
devices in a voltage domain rather than having to query the OPP layer
for it.
Kevin
---
arch/arm/plat-omap/include/plat/opp.h |9 +
arch/arm/plat-omap/opp.c | 28
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 0e580ed..a4c1669 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -18,6 +18,7 @@
#include linux/cpufreq.h
#include plat/common.h
+#include plat/voltage.h
/**
* struct omap_opp_def - OMAP OPP Definition
@@ -86,6 +87,9 @@ int opp_disable(struct omap_opp *opp);
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count);
#else
static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
{
@@ -149,5 +153,10 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
{
}
+static inline struct device **opp_init_voltage_params(
+ struct voltagedomain *voltdm, int *dev_count)
+{
+}
+
#endif /* CONFIG_PM */
#endif /* __ASM_ARM_OMAP_OPP_H */
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index a3dea82..72dd62a 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -502,3 +502,31 @@ void opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
}
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count)
+{
+ struct device_opp *dev_opp;
+ struct device **dev_list;
+ int count = 0, i = 0;
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (!dev_opp-oh-vdd_name)
+ continue;
+
+ if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
+ dev_opp-oh-voltdm = voltdm;
+ count++;
+ }
+ }
+
+ dev_list = kzalloc(sizeof(struct device *) * count, GFP_KERNEL);
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (dev_opp-oh-voltdm == voltdm)
+ dev_list[i++] = dev_opp-dev;
+ }
+
+ *dev_count = count;
+ return dev_list;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/7] wl12xx: make wl12xx.h common to both spi and sdio
On Thu, 2010-09-16 at 01:22 +0200, ext Ohad Ben-Cohen wrote: Move wl12xx.h outside of the spi-specific location, so it can be shared with both spi and sdio solutions. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Hi, wl12xx.h seems to be included also in arch/arm/mach-omap2/board-rx51-peripherals.c, so that should be changed too. Best Regards, Teemu Paasikivi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 03, 2010 5:12 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit Subject: Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures. Thara Gopinath th...@ti.com writes: This patch extends the device opp structure to contain pointers to scale the operating rate of the device and to retrieve the operating rate of the device. This patch also adds the three new APIs in the opp layer namely opp_set_rate that can be called to set a new operating rate for a device, opp_get_rate that can be called to retrieve the operating frequency for a device and opp_populate_rate_fns to populte the device specific set_rate and get_rate API's. The opp_set_rate and opp_get_rate does some routine error checks and finally calls into the device specific set_rate and get_rate APIs populated through opp_populate_rate_fns. Signed-off-by: Thara Gopinath th...@ti.com As I think about this more, I'm not sure the OPP layer is the right layer for the get/set rate functions. The OPP layer is currently just the data store for OPP data. To me, these set/get functions are better associated directly with an omap_device instead of an OPP. For instance, the new OPP APIs are a bit confusing in terms of OPPs. e.g: opp_get_rate(). What is the rate of an OPP, and what's the difference with opp_get_freq()? What's really happening is the rate is being changed for a device, and the need for specific hooks are at the device level, not the OPP level. For example, this current approach would not scale if you needed multiple devices in the same domain that each needed custom set_rate/get_rate hooks. So instead, what about adding custom hooks at the omap_device level? They could be registered at omap_device_build() time in the device specific code. This is exactly what I had in my mind when I started implementing this. But then Paul said hwmod or omap_device is not the place to keep it. Also I do not want the set rate get rate APIs for devices that require changes dividers in the PRCM clock module to be spread out in the system. Makes it very very difficult to debug. If we agree to add the set_rate and get_rate in the omap_device structure, I would like to have one more API in the omap_device layer to register these APIs device wise. Thus we can keep these set rate and get rate APIs in one single file. Also if we move these hooks to omap_device struct we will need to rename the current omap_device_set_rate (the main API) to omap_device_scale and introduce a new omap_device_set_rate which just finds out the omap device from the passed dev pointer and does a od-set_rate. Similarly for get rate also. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] twl4030-madc driver
MADC(Monitoring ADC) driver enables monitoring analog signals using analog-to-digital conversion (ADC) on the input source. The MADC driver is being added under the Hwmon class of drivers. To get the context, the last set of comments can be found here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19981.html Several people have contributed to this driver on the linux-omap list. Keerthy (2): hwmon: twl4030: Driver for twl4030 madc module Makefile and Kconfig changes for twl4030-madc driver arch/arm/mach-omap2/Kconfig |4 + drivers/hwmon/Kconfig|4 + drivers/hwmon/Makefile |1 + drivers/hwmon/twl4030-madc.c | 584 ++ include/linux/i2c/twl4030-madc.h | 118 5 files changed, 711 insertions(+), 0 deletions(-) create mode 100644 drivers/hwmon/twl4030-madc.c create mode 100644 include/linux/i2c/twl4030-madc.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] hwmon: twl4030: Driver for twl4030 madc module
MADC driver is added under hwmon drivers. This driver monitors the real time
conversion of analog signals like battery temperature,
battery type, battery level etc. User can also ask for the conversion on a
particular channel using the sysfs nodes.
Several people have contributed to this driver on the linux-omap list.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/hwmon/twl4030-madc.c | 584 ++
include/linux/i2c/twl4030-madc.h | 118
2 files changed, 702 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
diff --git a/drivers/hwmon/twl4030-madc.c b/drivers/hwmon/twl4030-madc.c
new file mode 100644
index 000..b96fccd
--- /dev/null
+++ b/drivers/hwmon/twl4030-madc.c
@@ -0,0 +1,584 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/types.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/platform_device.h
+#include linux/miscdevice.h
+#include linux/slab.h
+#include linux/i2c/twl.h
+#include linux/i2c/twl4030-madc.h
+#include linux/sysfs.h
+#include linux/hwmon.h
+#include linux/hwmon-sysfs.h
+
+#include linux/uaccess.h
+
+
+struct twl4030_madc_data {
+ struct device *hwmon_dev;
+ struct mutexlock;
+ struct work_struct ws;
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+
+static struct twl4030_madc_data *the_madc;
+
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct twl4030_madc_request req;
+ int status;
+ unsigned long val;
+
+ req.channels = (1 attr-index);
+ req.method = TWL4030_MADC_SW2;
+ req.func_cb = NULL;
+
+ val = twl4030_madc_conversion(req);
+ if (likely(val = 0))
+ val = req.rbuf[attr-index];
+ else
+ return val;
+ status = sprintf(buf, %lu\n, val);
+ return status;
+}
+
+static
+const struct twl4030_madc_conversion_method twl4030_conversion_methods[] = {
+ [TWL4030_MADC_RT] = {
+ .sel= TWL4030_MADC_RTSELECT_LSB,
+ .avg= TWL4030_MADC_RTAVERAGE_LSB,
+ .rbase = TWL4030_MADC_RTCH0_LSB,
+ },
+ [TWL4030_MADC_SW1] = {
+ .sel= TWL4030_MADC_SW1SELECT_LSB,
+ .avg= TWL4030_MADC_SW1AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW1,
+ },
+ [TWL4030_MADC_SW2] = {
+ .sel= TWL4030_MADC_SW2SELECT_LSB,
+ .avg= TWL4030_MADC_SW2AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW2,
+ },
+};
+
+static int twl4030_madc_read(struct twl4030_madc_data *madc, u8 reg)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, val, reg);
+ if (ret) {
+ dev_dbg(madc-hwmon_dev, unable to read register 0x%X\n, reg);
+ return ret;
+ }
+
+ return val;
+}
+
+static void twl4030_madc_write(struct twl4030_madc_data *madc, u8 reg, u8 val)
+{
+ int ret;
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, val, reg);
+ if (ret)
+ dev_err(madc-hwmon_dev,
+ unable to write register 0x%X\n, reg);
+}
+
+static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8
reg)
+{
+ u8 msb, lsb;
+
+ /*
+*For each ADC channel, we have MSB and LSB register pair. MSB address
+*is always LSB address+1. reg parameter is the addr of LSB register
+*/
+ msb = twl4030_madc_read(madc, reg + 1);
+ lsb = twl4030_madc_read(madc, reg);
+
+ return (int)(((msb 8) | lsb) 6);
+}
+
+static int twl4030_madc_read_channels(struct twl4030_madc_data *madc,
+ u8 reg_base, u16 channels, int *buf)
+{
+ int count = 0;
+ u8 reg, i;
+
+ if (unlikely(!buf))
+ return 0;
+
+ for (i = 0; i TWL4030_MADC_MAX_CHANNELS; i++) {
[PATCH 2/2] Makefile and Kconfig changes for twl4030-madc driver
Makefile amd Kconfig Changes for twl4030-madc driver inclusion. Signed-off-by: Keerthy j-keer...@ti.com --- arch/arm/mach-omap2/Kconfig |4 drivers/hwmon/Kconfig |4 drivers/hwmon/Makefile |1 + 3 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b48bacf..139137b 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -170,6 +170,8 @@ config MACH_OMAP_3430SDP depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select HWMON + select TWL4030_MADC config MACH_NOKIA_N800 bool @@ -206,6 +208,8 @@ config MACH_OMAP_ZOOM3 depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBP + select HWMON + select TWL4030_MADC config MACH_CM_T35 bool CompuLab CM-T35 module diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 4d4d09b..47d66b9 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -39,6 +39,10 @@ config HWMON_DEBUG_CHIP comment Native drivers +config TWL4030_MADC + tristate + depends on HWMON TWL4030_CORE + config SENSORS_ABITUGURU tristate Abit uGuru (rev 1 2) depends on X86 EXPERIMENTAL diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index e3c2484..24b3b17 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_SENSORS_W83792D) += w83792d.o obj-$(CONFIG_SENSORS_W83793) += w83793.o obj-$(CONFIG_SENSORS_W83781D) += w83781d.o obj-$(CONFIG_SENSORS_W83791D) += w83791d.o +obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Thursday, September 16, 2010 3:27 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon n...@ti.com
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omapm=126033945313269w=2
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
incorporated.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
Cc: Roberto Granados Dorado x0095...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Documentation/arm/OMAP/omap_pm| 83 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 145 +++
arch/arm/plat-omap/opp.c | 461
+
4 files changed, 694 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..6527cdf 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,86 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is
RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gopinath, Thara [...] diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat- omap/include/plat/opp.h new file mode 100644 index 000..997b56e --- /dev/null +++ b/arch/arm/plat-omap/include/plat/opp.h [..] + +#ifdef CONFIG_PM + [..] +struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq); + +int opp_add(const struct omap_opp_def *opp_def); + +int opp_enable(struct omap_opp *opp); + +int opp_disable(struct omap_opp *opp); + +void opp_init_cpufreq_table(struct device *dev, + struct cpufreq_frequency_table **table); +#else Hello Kevin, IN case of CONFIG_PM not being defined the else part will cause a compilation break as the signature of these APIs defined in the else part do not match with the signature in the if part. Thanks for the catch. Will send a patch for this. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
-Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 4:02 PM To: Gopinath, Thara; Kevin Hilman; linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gopinath, Thara [...] diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat- omap/include/plat/opp.h new file mode 100644 index 000..997b56e --- /dev/null +++ b/arch/arm/plat-omap/include/plat/opp.h [..] + +#ifdef CONFIG_PM + [..] +struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq); + +int opp_add(const struct omap_opp_def *opp_def); + +int opp_enable(struct omap_opp *opp); + +int opp_disable(struct omap_opp *opp); + +void opp_init_cpufreq_table(struct device *dev, + struct cpufreq_frequency_table **table); +#else Hello Kevin, IN case of CONFIG_PM not being defined the else part will cause a compilation break as the signature of these APIs defined in the else part do not match with the signature in the if part. Thanks for the catch. Will send a patch for this. I learnt this the hard way by actually hitting the issue :-)!! Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Thursday, September 16, 2010 3:27 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
From: Paul Walmsley p...@pwsan.com
The OPP layer code should be independent of the PMIC,
introduce the TWL/TPS-specific code out to its own file.
Hello Kevin,
I have been using this code for a while now. I really do not think wee need a
separate
file for implementing the vsel to voltage in (uV) and vice versa formulas.
Today only voltage
layer is interested in these conversions. Voltage layer has a structure that
can be populated with
the information required from the PMIC. We only need to add two more function
pointers to this structure. This info can then be passed from the actual PMIC
driver file. This will make it much
more simpler for OMAP4 where we have different formulas between different
revisions of PMIC. Also
in the omap voltage code we will no longer have to hard code
omap_twl_vsel_to_uv and omap_twl_uv_to_vsel. So please consider dropping this
patch from this series.
Regards
Thara
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/include/plat/opp_twl_tps.h | 21 +
arch/arm/plat-omap/opp_twl_tps.c | 41
+
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h
create mode 100644 arch/arm/plat-omap/opp_twl_tps.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index c718a0a..a88879c 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# OPP support in (OMAP3+ only at the moment)
ifdef CONFIG_PM
obj-$(CONFIG_ARCH_OMAP3) += opp.o
+obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o
endif
# omap_device support (OMAP2+ only at the moment)
diff --git a/arch/arm/plat-omap/include/plat/opp_twl_tps.h b/arch/arm/plat-
omap/include/plat/opp_twl_tps.h
new file mode 100644
index 000..8784e5f
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
@@ -0,0 +1,21 @@
+/*
+ * opp_twl_tps.h - TWL/TPS-specific headers for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX This code belongs as part of some other TWL/TPS code.
+ */
+#ifndef _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+#define _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+
+#include linux/kernel.h
+
+unsigned long omap_twl_vsel_to_uv(const u8 vsel);
+u8 omap_twl_uv_to_vsel(unsigned long uV);
+
+#endif
diff --git a/arch/arm/plat-omap/opp_twl_tps.c
b/arch/arm/plat-omap/opp_twl_tps.c
new file mode 100644
index 000..112f106
--- /dev/null
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -0,0 +1,41 @@
+/*
+ * opp_twl_tps.c - TWL/TPS-specific functions for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX This code should be part of some other TWL/TPS code.
+ */
+
+#include plat/opp_twl_tps.h
+
+/**
+ * omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
+ * @vsel: TWL/TPS VSEL value to convert
+ *
+ * Returns the microvolts DC that the TWL/TPS family of PMICs should
+ * generate when programmed with @vsel.
+ */
+unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return (((vsel * 125) + 6000)) * 100;
+}
+
+/**
+ * omap_twl_uv_to_vsel - convert microvolts DC to TWL/TPS VSEL value
+ * @uv: microvolts DC to convert
+ *
+ * Returns the VSEL value necessary for the TWL/TPS family of PMICs to
+ * generate an output voltage equal to or greater than @uv microvolts DC.
+ */
+u8 omap_twl_uv_to_vsel(unsigned long uv)
+{
+ /* Round up to higher voltage */
+ return DIV_ROUND_UP(uv - 60, 12500);
+}
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/7] wl12xx: make wl12xx.h common to both spi and sdio
On Thu, Sep 16, 2010 at 12:17 PM, Teemu Paasikivi ext-teemu.3.paasik...@nokia.com wrote: On Thu, 2010-09-16 at 01:22 +0200, ext Ohad Ben-Cohen wrote: Move wl12xx.h outside of the spi-specific location, so it can be shared with both spi and sdio solutions. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Hi, wl12xx.h seems to be included also in arch/arm/mach-omap2/board-rx51-peripherals.c, so that should be changed too. Thanks for catching this, I now see there are several spi/wl12xx.h users (rx51, omap3pandora and MAINTAINERS). An update is coming. Best Regards, Teemu Paasikivi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-OPP][PATCH] OMAP: Modifying the frequency comparison logic.
-Original Message- From: Menon, Nishanth Sent: Thursday, August 26, 2010 6:00 AM To: Kevin Hilman Cc: Gopinath, Thara; linux-omap@vger.kernel.org Subject: RE: [PM-OPP][PATCH] OMAP: Modifying the frequency comparison logic. -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, August 25, 2010 5:41 PM To: Menon, Nishanth Cc: Gopinath, Thara; linux-omap@vger.kernel.org Subject: Re: [PM-OPP][PATCH] OMAP: Modifying the frequency comparison logic. Menon, Nishanth n...@ti.com writes: From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, August 24, 2010 4:14 PM Menon, Nishanth n...@ti.com writes: thara gopinath th...@ti.com writes: From: Thara Gopinath th...@ti.com [...] The above is not correct as we expect the framework to return back the opp table entry corresponding to 266 Mhz. [...] b. Do the comparison in Mhz in the opp layer rather than in Hz. This would mean we will divide the rate passed into the opp layer API and the rates stored in the opp tables by 100 to get the rates in Mhz and do the necessary comparision. In this approach any vague frequency like 266.045Mhz will get mapped to 266 Mhz in the opp table. But if the passed rate is 267 Mhz, the opp framework will still rerturn an error or the next highest opp table entry This patch implements solution b. The scenario mentioned above is esp true for OMAP4 dpll_iva where we do end up with such weird frequencies due to sys clk being at 38.4 Mhz. I agree that solution b is better, although it makes the '_exact' function a bit less exact. :/ solution b is fine with me, but the kerneldoc for these find functions should be updated to describe the new matching technique. I agree, I suggest one improvement though - the search accuracy will vary Based on the silicon rev, one size will probably not fit every silicon and Domains we have - I suggest having accuracy as a parameter as part of domain Registration/configurable parameter e.g. + unsigned long rate = temp_opp-rate / 100; Will probably configurable to the exactness we expect to handle per domain/silicon family. The more I think about, I think we should leave the 'exact' find the way it is, especially as we move to device OPPs we will probably want to have more precise matching. What about adding another function that does a find closest? Just my 2cents: With accuracy as a param? Why would you need accuracy for find closest? How close should closest be? There has to be a parameter for this - something like as close as 10Mhz, but beyond the match fails. Currently this patch introduces a hardcoded accuracy which could be Carried forward. But, On different silicon the deltas due to sysclk can vary - there is no silver bullet algo we can write which will be accurate for all silicon and domain combination.. Further, is'nt ceil and floor functions we have a more specific Implementation of closest? in the sense, it says closest to which Direction - up or down.. [...] Rest of the discussion seems aligned. Hello Kevin, I am not sure about the conclusion of this discussion. For me we should avoid putting possible weird frequencies like 266789501.. Hence the round off to /10^6. If on some platforms due to sys clk we have frequency 267 instead of 266, I would prefer to edit the opp table through the opp framework APIs. This is my opinion. I may not have fully understood the concerns discussed in this forum. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
Hello. On 16-09-2010 10:05, Felipe Balbi wrote: I don't see what to rework. The last short packet should still satisfy (request-actual == request-length) condition, no? of course not, it's short not zero. so the last short packet can be anything from 1 to 511 bytes. Sigh. Where have I said anything different? What I meant is that the last short packet is already counted in request-actual, otherwise the condition (request-actual (musb_ep-packet_sz - 1)) wouldn't work. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 01/17] wl12xx: make wl12xx.h common to both spi and sdio
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Update all users of spi/wl12xx.h accordingly
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
MAINTAINERS |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
drivers/net/wireless/wl12xx/wl1251_sdio.c|2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c |2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c |2 +-
include/linux/spi/wl12xx.h | 34 --
include/linux/wl12xx.h | 34 ++
8 files changed, 40 insertions(+), 40 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 14ab8ca..b656c14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6416,7 +6416,7 @@ W:http://wireless.kernel.org
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
S: Maintained
F: drivers/net/wireless/wl12xx/wl1271*
-F: include/linux/spi/wl12xx.h
+F: include/linux/wl12xx.h
WL3501 WIRELESS PCMCIA CARD DRIVER
M: Arnaldo Carvalho de Melo a...@ghostprotocols.net
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index dd3af2b..7ea1eb4 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -25,7 +25,7 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/leds.h
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a5eb87..ce28a85 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -14,7 +14,7 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/clk.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index c0b68b0..74ba9ce 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/irq.h
#include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index 334ded9..320de79 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -24,7 +24,7 @@
#include linux/slab.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include wl1251.h
#include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 4cb99c5..c3fdab7 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/slab.h
#include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a20bccf..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Luciano Coelho luciano.coe...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_platform_data {
- void (*set_power)(bool enable);
- /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
- int irq;
- bool use_eeprom;
-};
-
-#endif
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
new file mode 100644
index 000..015687a
--- /dev/null
+++ b/include/linux/wl12xx.h
@@ -0,0 +1,34 @@
+/*
+ * This file is part of wl12xx
+ *
+ * Copyright
RE: [PATCH] usb: omap: ohci: Missing driver unregister in module exit
-Original Message- From: Munegowda, Keshava Sent: Tuesday, September 14, 2010 4:40 AM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Gadiyar, Anand; Kamat, Nishant; Munegowda, Keshava Subject: [PATCH] usb: omap: ohci: Missing driver unregister in module exit The un-registration of OHCI driver was not done in the ohci_hcd_mod_exit function. This was affecting rmmod command not to work for OMAP3 platforms. The platform driver un-registration for OMAP3 platforms is perfomed while removing the OHCI module from kernel. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com --- drivers/usb/host/ohci-hcd.c |3 +++ 1 file changed, 3 insertions(+) Index: linux-2.6/drivers/usb/host/ohci-hcd.c === --- linux-2.6.orig/drivers/usb/host/ohci-hcd.c +++ linux-2.6/drivers/usb/host/ohci-hcd.c @@ -1270,6 +1270,9 @@ static void __exit ohci_hcd_mod_exit(voi #ifdef PLATFORM_DRIVER platform_driver_unregister(PLATFORM_DRIVER); #endif +#ifdef OMAP3_PLATFORM_DRIVER + platform_driver_unregister(OMAP3_PLATFORM_DRIVER); +#endif #ifdef PS3_SYSTEM_BUS_DRIVER ps3_ohci_driver_unregister(PS3_SYSTEM_BUS_DRIVER); #endif Hi Greg, Do you any comments on this patch? Keshava Munegowda -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/7] wl12xx: make wl12xx.h common to both spi and sdio
Hi John,
On Thu, Sep 16, 2010 at 1:16 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Move wl12xx.h outside of the spi-specific location,
so it can be shared with both spi and sdio solutions.
Update all users of spi/wl12xx.h accordingly
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
This updates the first patch in the patchset.
Please tell me if you prefer me to resubmit the whole set.
Thanks,
Ohad.
MAINTAINERS | 2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
drivers/net/wireless/wl12xx/wl1251_sdio.c | 2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_spi.c | 2 +-
include/linux/spi/wl12xx.h | 34
--
include/linux/wl12xx.h | 34
++
8 files changed, 40 insertions(+), 40 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 14ab8ca..b656c14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6416,7 +6416,7 @@ W: http://wireless.kernel.org
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
S: Maintained
F: drivers/net/wireless/wl12xx/wl1271*
-F: include/linux/spi/wl12xx.h
+F: include/linux/wl12xx.h
WL3501 WIRELESS PCMCIA CARD DRIVER
M: Arnaldo Carvalho de Melo a...@ghostprotocols.net
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index dd3af2b..7ea1eb4 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -25,7 +25,7 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
#include linux/i2c/twl.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/mtd/partitions.h
#include linux/mtd/nand.h
#include linux/leds.h
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a5eb87..ce28a85 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -14,7 +14,7 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/i2c.h
#include linux/i2c/twl.h
#include linux/clk.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c
b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index c0b68b0..74ba9ce 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -24,7 +24,7 @@
#include linux/mmc/sdio_func.h
#include linux/mmc/sdio_ids.h
#include linux/platform_device.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/irq.h
#include wl1251.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c
b/drivers/net/wireless/wl12xx/wl1251_spi.c
index 334ded9..320de79 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -24,7 +24,7 @@
#include linux/slab.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include wl1251.h
#include wl1251_reg.h
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index 4cb99c5..c3fdab7 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/crc7.h
#include linux/spi/spi.h
-#include linux/spi/wl12xx.h
+#include linux/wl12xx.h
#include linux/slab.h
#include wl1271.h
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
deleted file mode 100644
index a20bccf..000
--- a/include/linux/spi/wl12xx.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * This file is part of wl12xx
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Luciano Coelho luciano.coe...@nokia.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef _LINUX_SPI_WL12XX_H
-#define _LINUX_SPI_WL12XX_H
-
-struct wl12xx_platform_data {
- void (*set_power)(bool enable);
- /* SDIO
Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
Gopinath, Thara had written, on 09/16/2010 05:40 AM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, September 16, 2010 3:27 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code From: Paul Walmsley p...@pwsan.com The OPP layer code should be independent of the PMIC, introduce the TWL/TPS-specific code out to its own file. Hello Kevin, I have been using this code for a while now. I really do not think wee need a separate file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage This split introduces a PMIC level abstraction already. Do you have a suggestion which file it should go to? It is definitely not part of opp.c, not part of other existing twl files as well. the job of this file was to introduce conversion routines which can be used by any layer (voltage layer if need be - it used to be srf and smartreflex before).. in fact one of your voltage layer patches introduces capability for 6030 as well http://marc.info/?l=linux-omapm=128213020927919w=2 layer is interested in these conversions. Voltage layer has a structure that can be populated with the information required from the PMIC. We only need to add two more function pointers to this structure. This info can then be passed from the actual PMIC driver file. This will make it much more simpler for OMAP4 where we have different formulas between different revisions of PMIC. Also in the omap voltage code we will no longer have to hard code omap_twl_vsel_to_uv and omap_twl_uv_to_vsel. I think the problem is with the voltage layer (which has not been posted upstream) which is using hard coded function pointer. What the patchset should have done is to introduce function pointers registration from twl_tps.c to voltage layer and voltage layer should ideally been using function pointers by itself. So please consider dropping this patch from this series. I think I disagree - rationale for having this separated as a pmic specific file is still sound, only the implementation of the future framework should have changed (it should be using function pointers instead of hardcoded function names). in fact I can add additional suggestion for the voltage layer: the pmic selection should be done from a board file - This will allow voltage layer to handle numerous PMICs and combination of PMICs controlling various domains as well.. the only neat way to handle it is ofcourse using function pointers. PS: Suggestion - please fix your mailer to round off for 70/80 chars.. - might be good to point folks to rfc patchset for voltage layer to give context. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
2010/9/15 Kevin Hilman khil...@deeprootsystems.com: OMAP SOCs have a standard set of tuples consisting of frequency and voltage pairs that the device will support per voltage domain. These are called Operating Performance Points or OPPs. (...) This introduces a common handling OPP mechanism accross all OMAPs. As a start this is used for OMAP3. OPPs are a generic concept, it's in silicon construction textbooks and all. Should this code not be made generic instead? You wouldn't make regulators or even DMA platform-specific these days, so why should OPPs be? What in this code is actually OMAP-specific, more than that you name some functions omap_*, and how hard would it be to put it under arch/arm/common/*.c arch/arm/include/asm/*.h Possible even higher up in the directory hiearchy in include/linux/opp.h for the header and drivers/opp/*.c, because I think SuperH and power are not that different in this respect. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Linus Walleij had written, on 09/16/2010 07:19 AM, the following: 2010/9/15 Kevin Hilman khil...@deeprootsystems.com: OMAP SOCs have a standard set of tuples consisting of frequency and voltage pairs that the device will support per voltage domain. These are called Operating Performance Points or OPPs. (...) This introduces a common handling OPP mechanism accross all OMAPs. As a start this is used for OMAP3. OPPs are a generic concept, it's in silicon construction textbooks and all. Should this code not be made generic instead? You wouldn't make regulators or even DMA platform-specific these days, so why should OPPs be? As far as I see this patch : hwmod[1] which is omap specific which inturn depends on omap_device. - this impacts opp_add function in the opp layer. [1] http://marc.info/?l=linux-omapm=128226580816341w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LCD on Zoom2 dev board with DSS
Hi,
I solved my problem. It appeared the PIN which controls LCD's reset
signal (VGA_nRESET/h_GPIO_96) was not configured as a GPIO, and the
driver tries to use it as GPIO, so the logical value was 0. We had to
modify the OMAP MUX, and select this PIN (CAM_XCLKA) as an output GPIO
(OMAP_MUX_MODE4).
Be aware of changing this PIN will probably disable the camera, because
it was previously configured as a clock.
There is the patch for the LCD (diff -Naur):
--- a/arch/arm/mach-omap2/board-zoom2.c 2010-09-15 15:27:05.148399721
+0200
+++ b/arch/arm/mach-omap2/board-zoom2.c 2010-09-15 14:46:09.792900019
+0200
@@ -71,6 +71,7 @@
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ OMAP3_MUX(CAM_XCLKA, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
Le lundi 13 septembre 2010 à 14:43 +0200, Yanick Saugy a écrit :
Hi all,
I'm working on a zoom2 dev board (omap34x-II MDP). There is my actual config :
I've built kernel 2.6.35 from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
and then applied the following patchs :
[PATCH 1/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for zoom boards
http://marc.info/?l=linux-omapm=127445506720934w=2
[PATCH 2/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for zoom boards
http://marc.info/?l=linux-omapm=127445522921326w=2
[PATCH V6] OMAP: DSS: Add NEC NL8048HL11-01B display panel
http://marc.info/?l=linux-omapm=127445535621669w=2
Finally I've enabled DSS and lcd NEC_NL8048HL11 in kernel config file.
At this time the kernel boots well, and my LCD backlight turns on but I can't
see TUX while booting, and I can't draw anything after logging in.
I've checked, the framebuffer device is present and configured with size of
800x480.
I've played with sys filesystem like on this wiki, but nothing happened:
http://www.omappedia.org/wiki/Bootargs_for_enabling_display
To enable DSS at boot time, I passed following boot options:
vram=10M omapdss.def_disp=lcd
Perhaps I've missed something?
Thank you in advance.
---
Yanick
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] overo twl4030: fix twl4030 IRQ (used for usb otg detection)
On Wed, Sep 15, 2010 at 11:07 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Sep 15, 2010 at 04:28:57PM -0500, Steve Sakoman wrote: On Wed, Sep 15, 2010 at 9:29 AM, Anti Sullin anti.sul...@artecdesign.ee wrote: I was not getting OTG USB vbus/id pin change interrupts on Gumstix Overo and the reason was a mis-configured irq. I added some more checks to avoid having a non-bootable kernel on boards with bootloaders that have wrong pinmux. The changes of twl4030 should be tested on other boards too. --- Gumstix Overo has TPS65950 (TWL4030) IRQ1 connected to GPIO112. I don't think that this change should be made. From what I understand from my discussions with Gumstix, early versions of the Overo COM used GPIO112 as indicated above. However all fab revisions =2516 use GPIO0, so the code is correct for current and future versions of Overo COMs (as is the bootloader pinmuxing). In fact, future versions of Overo will use GPIO112 for a revision ID. Not an ideal situation, but I think we should leave things as they are since it matches current and future production. People with older boards will certainly need to use this patch to get vbus/id interrupts. it would be better to get all boards working. Can't you use ATAG_REVISION or system_rev to differentiate the board revisions and change gpio number accordingly ?? Agreed. Gumstix doesn't provide an easy way of determining the layout revision via software (the boards are marked with the rev number, but that doesn't do much good!). I'm investigating methods to figure this out, but haven't yet found anything reliable. When I do I'll post a patch. Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP4: ES2 PRCM diff series
The PRCM IP in OMAP4430 ES2 is completely validated and is expected to be functional, unlike the one in ES1 which was untested and non functional. This series of patches brings in all the differences introducted by PRCM in ES2.0. Includes additional registers added, some removed, bitfields in registers moved around. Some changes in clock tree modelling and some in powerdomain states supported. This series is tested on OMAP4430 ES2 using the below series http://www.spinics.net/lists/linux-omap/msg36023.html and also boot tested on OMAP4430 ES1 and applied on latest mainline. Patches based on mainline rc4 are available here: http://gitorious.org/omap-pm/linux for_2.6.37 Rajendra Nayak (4): OMAP4: PM: Update PRCM register bitshits and masks for ES2 OMAP4: PM: Define additional registers for ES2 OMAP4: clocks: Update clock tree for ES2 OMAP4: powerdomain: Update DSS logic state for ES2 Santosh Shilimkar (1): OMAP4: powerdomain: add context_offset field arch/arm/mach-omap2/clock44xx_data.c | 168 ++ arch/arm/mach-omap2/cm-regbits-44xx.h | 327 ++--- arch/arm/mach-omap2/cm44xx.h | 90 +++- arch/arm/mach-omap2/powerdomains44xx.h| 16 ++- arch/arm/mach-omap2/prm-regbits-44xx.h| 194 --- arch/arm/mach-omap2/prm44xx.h | 14 +- arch/arm/plat-omap/include/plat/powerdomain.h |2 + 7 files changed, 525 insertions(+), 286 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 1/6] OMAP3: hwmod data: Add watchdog timer
-Original Message-
From: Cousson, Benoit
Sent: Thursday, September 16, 2010 2:57 AM
To: Varadarajan, Charulatha
Cc: t...@atomide.com; w...@iguana.be; linux-watch...@vger.kernel.org;
khil...@deeprootsystems.com; p...@pwsan.com; Nayak, Rajendra; Basak,
Partha; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 1/6] OMAP3: hwmod data: Add watchdog timer
On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:
Add watchdog timer hwmod data for OMAP3 chip
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 61
arch/arm/mach-omap2/prcm-common.h |4 ++
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-
omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..a9812a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -36,6 +36,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +198,65 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/* WDTIMER2- L4_WKUP interface */
Minor point, but the name convention is wd_timerX. It is valid for all
other comments in this file.
Okay.
+static struct omap_hwmod_addr_space omap3xxx_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x48314000,
+ .pa_end = 0x4831407f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__wd_timer2 = {
+ .master =omap3xxx_l4_wkup_hwmod,
+ .slave =omap3xxx_wd_timer2_hwmod,
+ .clk= wdt2_ick,
+ .addr = omap3xxx_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* WDTIMER common */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_wd_timer_hwmod_class = {
+ .name = wd_timer,
+ .sysc =omap3xxx_wd_timer_sysc,
+};
+
+/* WDTIMER2 */
+static struct omap_hwmod_ocp_if *omap3xxx_wd_timer2_slaves[] = {
+ omap3xxx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod = {
+ .name = wd_timer2,
+ .class =omap3xxx_wd_timer_hwmod_class,
+ .main_clk = wdt2_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_WDT2_SHIFT,
+ .module_offs = WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_EN_WDT2_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -204,6 +264,7 @@ static __initdata struct omap_hwmod
*omap3xxx_hwmods[] = {
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
omap3xxx_iva_hwmod,
+ omap3xxx_wd_timer2_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-
omap2/prcm-common.h
index 995b7ed..e190c64 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -237,6 +237,8 @@
#define OMAP24XX_ST_USB_MASK (1 0)
/* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
+#define OMAP24XX_EN_WDT2_SHIFT 3
+#define OMAP24XX_EN_WDT2_MASK (1 3)
#define OMAP24XX_EN_GPIOS_SHIFT 2
#define OMAP24XX_EN_GPIOS_MASK(1 2)
#define OMAP24XX_EN_GPT1_SHIFT0
@@ -344,6 +346,8 @@
#define OMAP3430_ST_D2D_MASK (1 3)
/* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
+#define OMAP3430_EN_WDT2_SHIFT 5
+#define OMAP3430_EN_WDT2_MASK
RE: [PATCH v5 4/6] OMAP4: hwmod data: Add watchdog timer
-Original Message- From: Cousson, Benoit Sent: Thursday, September 16, 2010 3:05 AM To: Varadarajan, Charulatha Cc: t...@atomide.com; w...@iguana.be; linux-watch...@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com; Nayak, Rajendra; Basak, Partha; linux-omap@vger.kernel.org Subject: Re: [PATCH v5 4/6] OMAP4: hwmod data: Add watchdog timer On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote: From: Benoit Coussonb-cous...@ti.com Add watchdog timer hwmod data for OMAP4 chip Signed-off-by: Benoit Coussonb-cous...@ti.com Signed-off-by: Charulatha Vch...@ti.com --- This patch is extracted from the below patch sent by Benoit OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0 https://patchwork.kernel.org/patch/99052/ Since that one, I sent a newer version: OMAP4: hwmod: Add initial data for OMAP4430 ES1 ES2 https://patchwork.kernel.org/patch/117347/ In fact the patch that really contains all the data is not there, probably because of its size :-( Okay add this link also. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 5/6] OMAP2PLUS: WDT: use omap_device_build for device registration
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, September 15, 2010 11:23 PM
To: Varadarajan, Charulatha
Cc: w...@iguana.be; linux-watch...@vger.kernel.org;
khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Nayak,
Rajendra; Basak, Partha; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 5/6] OMAP2PLUS: WDT: use omap_device_build for
device registration
* Varadarajan, Charulatha ch...@ti.com [100914 22:18]:
Use omap_device_build API instead of platform_device_register for
watchdog timer device registration.
For OMAP2PLUS chips, the device specific data defined in centralized
hwmod database will be used.
snip
static void omap_init_wdt(void)
{
- if (cpu_is_omap16xx())
- wdt_resources[0].start = 0xfffeb000;
- else if (cpu_is_omap2420())
- wdt_resources[0].start = 0x48022000; /* WDT2 */
- else if (cpu_is_omap2430())
- wdt_resources[0].start = 0x49016000; /* WDT2 */
- else if (cpu_is_omap343x())
- wdt_resources[0].start = 0x48314000; /* WDT2 */
- else if (cpu_is_omap44xx())
- wdt_resources[0].start = 0x4a314000;
- else
- return;
-
- wdt_resources[0].end = wdt_resources[0].start + 0x4f;
-
- (void) platform_device_register(omap_wdt_device);
+ if (cpu_class_is_omap2())
+ omap2_init_wdt();
+ else if (cpu_is_omap16xx())
+ (void) platform_device_register(omap1_wdt_device);
+ return;
}
#else
static inline void omap_init_wdt(void) {}
Please just split this into separate omap_init_wdt functions
under mach-omap1 and mach-omap2. Then set them up with
subsys_initcall and make sure you return early from the
subsys_initcall if the platform is not the right one.
Okay.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishanth Menon wrote:
Linus Walleij had written, on 09/16/2010 07:19 AM, the following:
2010/9/15 Kevin Hilman khil...@deeprootsystems.com:
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs.
(...)
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
OPPs are a generic concept, it's in silicon construction textbooks and all.
Should this code not be made generic instead? You wouldn't make
regulators or even DMA platform-specific these days, so why should
OPPs be?
As far as I see this patch :
hwmod[1] which is omap specific which inturn depends on omap_device. -
this impacts opp_add function in the opp layer.
Then wrap your local OPP in some clever way:
struct omap_opp {
struct hwmod foo;
struct opp opp;
};
container_of() is your friend.
Alternatively and not as elegant is to provide an
void *private_data; in the generic opp struct.
And similar design patterns for code and other
platform-specific hooks. Overridable struct opp_ops
for example, the same way we just abstracted the
l2x0 operations for example.
It's not like there are no precedents in the linux kernel
on how to handle a superclass of some struct, so
how hard can it be?
The fact that a single struct member is OMAP-specific doesn't
nix the fact that the major part of this OPP framework
is generic code.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] OMAP4: powerdomain: Update DSS logic state for ES2
From: Rajendra Nayak rna...@ti.com
DSS on ES2 supports only OSWR, hence remove the support
for CSWR from the powerdomain framework.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains44xx.h|2 +-
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx.h
b/arch/arm/mach-omap2/powerdomains44xx.h
index c721951..9c01b55 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.h
+++ b/arch/arm/mach-omap2/powerdomains44xx.h
@@ -98,7 +98,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_DSS_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_ON,
- .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* dss_mem */
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index fb6ec74..3ea7220 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -32,6 +32,7 @@
/* Powerdomain allowable state bitfields */
#define PWRSTS_ON (1 PWRDM_POWER_ON)
+#define PWRSTS_OFF (1 PWRDM_POWER_OFF)
#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | \
(1 PWRDM_POWER_ON))
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP4: PM: Define additional registers for ES2
From: Rajendra Nayak rna...@ti.com 4430 ES2 has a few new registers added and a few modified from ES1. This patch adds all the register changes in PRM and CM for OMAP4430 ES2. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoît Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/cm44xx.h | 90 - arch/arm/mach-omap2/prm44xx.h | 14 --- 2 files changed, 96 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h index 336d948..3c35a87 100644 --- a/arch/arm/mach-omap2/cm44xx.h +++ b/arch/arm/mach-omap2/cm44xx.h @@ -195,6 +195,42 @@ #define OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET 0x0088 #define OMAP4430_CM1_ABE_WDT3_CLKCTRL OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_MOD, 0x0088) +/* CM1.RESTORE_CM1 register offsets */ +#define OMAP4_CM_CLKSEL_CORE_RESTORE_OFFSET0x +#define OMAP4430_CM_CLKSEL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x) +#define OMAP4_CM_DIV_M2_DPLL_CORE_RESTORE_OFFSET 0x0004 +#define OMAP4430_CM_DIV_M2_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0004) +#define OMAP4_CM_DIV_M3_DPLL_CORE_RESTORE_OFFSET 0x0008 +#define OMAP4430_CM_DIV_M3_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0008) +#define OMAP4_CM_DIV_M4_DPLL_CORE_RESTORE_OFFSET 0x000c +#define OMAP4430_CM_DIV_M4_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x000c) +#define OMAP4_CM_DIV_M5_DPLL_CORE_RESTORE_OFFSET 0x0010 +#define OMAP4430_CM_DIV_M5_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0010) +#define OMAP4_CM_DIV_M6_DPLL_CORE_RESTORE_OFFSET 0x0014 +#define OMAP4430_CM_DIV_M6_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0014) +#define OMAP4_CM_DIV_M7_DPLL_CORE_RESTORE_OFFSET 0x0018 +#define OMAP4430_CM_DIV_M7_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0018) +#define OMAP4_CM_CLKSEL_DPLL_CORE_RESTORE_OFFSET 0x001c +#define OMAP4430_CM_CLKSEL_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x001c) +#define OMAP4_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE_OFFSET 0x0020 +#define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0020) +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE_OFFSET 0x0024 +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0024) +#define OMAP4_CM_CLKMODE_DPLL_CORE_RESTORE_OFFSET 0x0028 +#define OMAP4430_CM_CLKMODE_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0028) +#define OMAP4_CM_SHADOW_FREQ_CONFIG2_RESTORE_OFFSET0x002c +#define OMAP4430_CM_SHADOW_FREQ_CONFIG2_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x002c) +#define OMAP4_CM_SHADOW_FREQ_CONFIG1_RESTORE_OFFSET0x0030 +#define OMAP4430_CM_SHADOW_FREQ_CONFIG1_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0030) +#define OMAP4_CM_AUTOIDLE_DPLL_CORE_RESTORE_OFFSET 0x0034 +#define OMAP4430_CM_AUTOIDLE_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0034) +#define OMAP4_CM_MPU_CLKSTCTRL_RESTORE_OFFSET 0x0038 +#define OMAP4430_CM_MPU_CLKSTCTRL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0038) +#define OMAP4_CM_CM1_PROFILING_CLKCTRL_RESTORE_OFFSET 0x003c +#define OMAP4430_CM_CM1_PROFILING_CLKCTRL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x003c) +#define OMAP4_CM_DYN_DEP_PRESCAL_RESTORE_OFFSET0x0040 +#define OMAP4430_CM_DYN_DEP_PRESCAL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0040) + /* CM2 */ /* CM2.OCP_SOCKET_CM2 register offsets */ @@ -252,8 +288,6 @@ #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_PER OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0068) #define OMAP4_CM_SSC_MODFREQDIV_DPLL_PER_OFFSET0x006c #define OMAP4430_CM_SSC_MODFREQDIV_DPLL_PER OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x006c) -#define OMAP4_CM_EMU_OVERRIDE_DPLL_PER_OFFSET 0x0070 -#define OMAP4430_CM_EMU_OVERRIDE_DPLL_PER OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0070) #define OMAP4_CM_CLKMODE_DPLL_USB_OFFSET 0x0080 #define OMAP4430_CM_CLKMODE_DPLL_USB OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0080) #define OMAP4_CM_IDLEST_DPLL_USB_OFFSET0x0084 @@ -296,6 +330,8 @@ #define OMAP4430_CM_ALWON_SR_IVA_CLKCTRL OMAP44XX_CM2_REGADDR(OMAP4430_CM2_ALWAYS_ON_MOD, 0x0030) #define OMAP4_CM_ALWON_SR_CORE_CLKCTRL_OFFSET 0x0038 #define OMAP4430_CM_ALWON_SR_CORE_CLKCTRL
[PATCH 3/5] OMAP4: clocks: Update clock tree for ES2
From: Rajendra Nayak rna...@ti.com
This patch updates the clock tree with all the
changes in OMAP4430 ES2.
clock nodes added
-1- tie_low_clock_ck
-2- abe_dpll_bypass_clk_mux_ck
clock nodes deleted
-1- dpll_sys_ref_clk
-2- per_sgx_fclk
-3- usbphyocp2scp_ick
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clock44xx_data.c | 168 ++
1 files changed, 70 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..6e5a893 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -175,21 +175,27 @@ static struct clk sys_clkin_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk tie_low_clock_ck = {
+ .name = tie_low_clock_ck,
+ .rate = 0,
+ .ops= clkops_null,
+};
+
static struct clk utmi_phy_clkout_ck = {
.name = utmi_phy_clkout_ck,
- .rate = 1200,
+ .rate = 6000,
.ops= clkops_null,
};
static struct clk xclk60mhsp1_ck = {
.name = xclk60mhsp1_ck,
- .rate = 1200,
+ .rate = 6000,
.ops= clkops_null,
};
static struct clk xclk60mhsp2_ck = {
.name = xclk60mhsp2_ck,
- .rate = 1200,
+ .rate = 6000,
.ops= clkops_null,
};
@@ -201,39 +207,23 @@ static struct clk xclk60motg_ck = {
/* Module clocks and DPLL outputs */
-static const struct clksel_rate div2_1to2_rates[] = {
- { .div = 1, .val = 0, .flags = RATE_IN_4430 },
- { .div = 2, .val = 1, .flags = RATE_IN_4430 },
- { .div = 0 },
-};
-
-static const struct clksel dpll_sys_ref_clk_div[] = {
- { .parent = sys_clkin_ck, .rates = div2_1to2_rates },
+static const struct clksel abe_dpll_bypass_clk_mux_sel[] = {
+ { .parent = sys_clkin_ck, .rates = div_1_0_rates },
+ { .parent = sys_32k_ck, .rates = div_1_1_rates },
{ .parent = NULL },
};
-static struct clk dpll_sys_ref_clk = {
- .name = dpll_sys_ref_clk,
+static struct clk abe_dpll_bypass_clk_mux_ck = {
+ .name = abe_dpll_bypass_clk_mux_ck,
.parent = sys_clkin_ck,
- .clksel = dpll_sys_ref_clk_div,
- .clksel_reg = OMAP4430_CM_DPLL_SYS_REF_CLKSEL,
- .clksel_mask= OMAP4430_CLKSEL_0_0_MASK,
.ops= clkops_null,
- .recalc = omap2_clksel_recalc,
- .round_rate = omap2_clksel_round_rate,
- .set_rate = omap2_clksel_set_rate,
-};
-
-static const struct clksel abe_dpll_refclk_mux_sel[] = {
- { .parent = dpll_sys_ref_clk, .rates = div_1_0_rates },
- { .parent = sys_32k_ck, .rates = div_1_1_rates },
- { .parent = NULL },
+ .recalc = followparent_recalc,
};
static struct clk abe_dpll_refclk_mux_ck = {
.name = abe_dpll_refclk_mux_ck,
- .parent = dpll_sys_ref_clk,
- .clksel = abe_dpll_refclk_mux_sel,
+ .parent = sys_clkin_ck,
+ .clksel = abe_dpll_bypass_clk_mux_sel,
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP4430_CM_ABE_PLL_REF_CLKSEL,
.clksel_mask= OMAP4430_CLKSEL_0_0_MASK,
@@ -244,7 +234,7 @@ static struct clk abe_dpll_refclk_mux_ck = {
/* DPLL_ABE */
static struct dpll_data dpll_abe_dd = {
.mult_div1_reg = OMAP4430_CM_CLKSEL_DPLL_ABE,
- .clk_bypass = sys_clkin_ck,
+ .clk_bypass = abe_dpll_bypass_clk_mux_ck,
.clk_ref= abe_dpll_refclk_mux_ck,
.control_reg= OMAP4430_CM_CLKMODE_DPLL_ABE,
.modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
@@ -310,6 +300,12 @@ static struct clk abe_clk = {
.set_rate = omap2_clksel_set_rate,
};
+static const struct clksel_rate div2_1to2_rates[] = {
+ { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
static const struct clksel aess_fclk_div[] = {
{ .parent = abe_clk, .rates = div2_1to2_rates },
{ .parent = NULL },
@@ -380,14 +376,14 @@ static struct clk dpll_abe_m3_ck = {
};
static const struct clksel core_hsd_byp_clk_mux_sel[] = {
- { .parent = dpll_sys_ref_clk, .rates = div_1_0_rates },
+ { .parent = sys_clkin_ck, .rates = div_1_0_rates },
{ .parent = dpll_abe_m3_ck, .rates = div_1_1_rates },
{ .parent = NULL },
};
static struct clk core_hsd_byp_clk_mux_ck = {
.name = core_hsd_byp_clk_mux_ck,
- .parent = dpll_sys_ref_clk,
+ .parent = sys_clkin_ck,
.clksel =
[PATCH 1/5] OMAP4: PM: Update PRCM register bitshits and masks for ES2
From: Rajendra Nayak rna...@ti.com This patch updates the PRM and CM register bitshifts and masks for OMAP4430 ES2.0. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoît Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/cm-regbits-44xx.h | 327 ++-- arch/arm/mach-omap2/prm-regbits-44xx.h | 194 +++ 2 files changed, 342 insertions(+), 179 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-44xx.h b/arch/arm/mach-omap2/cm-regbits-44xx.h index ac8458e..92ebfd4 100644 --- a/arch/arm/mach-omap2/cm-regbits-44xx.h +++ b/arch/arm/mach-omap2/cm-regbits-44xx.h @@ -1,8 +1,8 @@ /* * OMAP44xx Clock Management register bits * - * Copyright (C) 2009 Texas Instruments, Inc. - * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2009-2010 Texas Instruments, Inc. + * Copyright (C) 2009-2010 Nokia Corporation * * Paul Walmsley (p...@pwsan.com) * Rajendra Nayak (rna...@ti.com) @@ -25,19 +25,22 @@ #include cm.h -/* Used by CM_L3_1_DYNAMICDEP, CM_MPU_DYNAMICDEP, CM_TESLA_DYNAMICDEP */ +/* + * Used by CM_L3_1_DYNAMICDEP, CM_L3_1_DYNAMICDEP_RESTORE, CM_MPU_DYNAMICDEP, + * CM_TESLA_DYNAMICDEP + */ #define OMAP4430_ABE_DYNDEP_SHIFT 3 #define OMAP4430_ABE_DYNDEP_MASK BITFIELD(3, 3) /* * Used by CM_D2D_STATICDEP, CM_DUCATI_STATICDEP, CM_SDMA_STATICDEP, - * CM_L3INIT_STATICDEP, CM_SDMA_STATICDEP_RESTORE, CM_MPU_STATICDEP, - * CM_TESLA_STATICDEP + * CM_L3INIT_STATICDEP, CM_D2D_STATICDEP_RESTORE, CM_SDMA_STATICDEP_RESTORE, + * CM_MPU_STATICDEP, CM_TESLA_STATICDEP */ #define OMAP4430_ABE_STATDEP_SHIFT 3 #define OMAP4430_ABE_STATDEP_MASK BITFIELD(3, 3) -/* Used by CM_L4CFG_DYNAMICDEP */ +/* Used by CM_L4CFG_DYNAMICDEP, CM_L4CFG_DYNAMICDEP_RESTORE */ #define OMAP4430_ALWONCORE_DYNDEP_SHIFT16 #define OMAP4430_ALWONCORE_DYNDEP_MASK BITFIELD(16, 16) @@ -53,7 +56,7 @@ #define OMAP4430_AUTO_DPLL_MODE_SHIFT 0 #define OMAP4430_AUTO_DPLL_MODE_MASK BITFIELD(0, 2) -/* Used by CM_L4CFG_DYNAMICDEP */ +/* Used by CM_L4CFG_DYNAMICDEP, CM_L4CFG_DYNAMICDEP_RESTORE */ #define OMAP4430_CEFUSE_DYNDEP_SHIFT 17 #define OMAP4430_CEFUSE_DYNDEP_MASKBITFIELD(17, 17) @@ -97,6 +100,10 @@ #define OMAP4430_CLKACTIVITY_CAM_PHY_CTRL_GCLK_SHIFT 9 #define OMAP4430_CLKACTIVITY_CAM_PHY_CTRL_GCLK_MASKBITFIELD(9, 9) +/* Used by CM_ALWON_CLKSTCTRL */ +#define OMAP4430_CLKACTIVITY_CORE_ALWON_32K_GFCLK_SHIFT12 +#define OMAP4430_CLKACTIVITY_CORE_ALWON_32K_GFCLK_MASK BITFIELD(12, 12) + /* Used by CM_EMU_CLKSTCTRL */ #define OMAP4430_CLKACTIVITY_CORE_DPLL_EMU_CLK_SHIFT 9 #define OMAP4430_CLKACTIVITY_CORE_DPLL_EMU_CLK_MASKBITFIELD(9, 9) @@ -145,10 +152,6 @@ #define OMAP4430_CLKACTIVITY_DUCATI_GCLK_SHIFT 8 #define OMAP4430_CLKACTIVITY_DUCATI_GCLK_MASK BITFIELD(8, 8) -/* Used by CM_L3INIT_CLKSTCTRL, CM_L3INIT_CLKSTCTRL_RESTORE */ -#define OMAP4430_CLKACTIVITY_EMAC_50MHZ_CLK_SHIFT 10 -#define OMAP4430_CLKACTIVITY_EMAC_50MHZ_CLK_MASK BITFIELD(10, 10) - /* Used by CM_EMU_CLKSTCTRL */ #define OMAP4430_CLKACTIVITY_EMU_SYS_CLK_SHIFT 8 #define OMAP4430_CLKACTIVITY_EMU_SYS_CLK_MASK BITFIELD(8, 8) @@ -185,10 +188,6 @@ #define OMAP4430_CLKACTIVITY_HSIC_P2_GFCLK_SHIFT 27 #define OMAP4430_CLKACTIVITY_HSIC_P2_GFCLK_MASK BITFIELD(27, 27) -/* Used by CM_L3INIT_CLKSTCTRL */ -#define OMAP4430_CLKACTIVITY_INIT_32K_GFCLK_SHIFT 31 -#define OMAP4430_CLKACTIVITY_INIT_32K_GFCLK_MASK BITFIELD(31, 31) - /* Used by CM_L3INIT_CLKSTCTRL, CM_L3INIT_CLKSTCTRL_RESTORE */ #define OMAP4430_CLKACTIVITY_INIT_48MC_GFCLK_SHIFT 13 #define OMAP4430_CLKACTIVITY_INIT_48MC_GFCLK_MASK BITFIELD(13, 13) @@ -233,9 +232,9 @@ #define OMAP4430_CLKACTIVITY_IVAHD_ROOT_CLK_SHIFT 8 #define OMAP4430_CLKACTIVITY_IVAHD_ROOT_CLK_MASK BITFIELD(8, 8) -/* Used by CM_L3INIT_CLKSTCTRL, CM_L3INIT_CLKSTCTRL_RESTORE */ -#define OMAP4430_CLKACTIVITY_L3INIT_DPLL_ALWON_CLK_SHIFT 14 -#define OMAP4430_CLKACTIVITY_L3INIT_DPLL_ALWON_CLK_MASK BITFIELD(14, 14) +/* Used by CM_D2D_CLKSTCTRL */ +#define OMAP4430_CLKACTIVITY_L3X2_D2D_GICLK_SHIFT 10 +#define OMAP4430_CLKACTIVITY_L3X2_D2D_GICLK_MASK BITFIELD(10, 10) /* Used by CM_L3_1_CLKSTCTRL, CM_L3_1_CLKSTCTRL_RESTORE */ #define OMAP4430_CLKACTIVITY_L3_1_GICLK_SHIFT 8 @@ -337,10 +336,6 @@ #define OMAP4430_CLKACTIVITY_PER_ABE_24M_GFCLK_SHIFT 25 #define
[PATCH 5/5] OMAP4: powerdomain: add context_offset field
From: Santosh Shilimkar santosh.shilim...@ti.com
Context register in various power domain is not at same offset
on OMAP4. Mainly the CPUx context resgiters againts rest of
them. This patch adds a field in power-domain strucures to handle
this.
This will be needed to make pwrdm_clear_all_prev_pwrst API work on
OMAP4.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains44xx.h| 14 ++
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx.h
b/arch/arm/mach-omap2/powerdomains44xx.h
index 9c01b55..65e919b 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.h
+++ b/arch/arm/mach-omap2/powerdomains44xx.h
@@ -40,6 +40,7 @@ static struct powerdomain core_44xx_pwrdm = {
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 5,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* core_nret_bank */
[1] = PWRSTS_OFF_RET, /* core_ocmram */
@@ -64,6 +65,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* gfx_mem */
},
@@ -81,6 +83,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks= 2,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_RET, /* aessmem */
[1] = PWRDM_POWER_OFF, /* periphmem */
@@ -100,6 +103,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks= 1,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* dss_mem */
},
@@ -117,6 +121,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 3,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_RET, /* tesla_edma */
[1] = PWRSTS_OFF_RET, /* tesla_l1 */
@@ -137,6 +142,7 @@ static struct powerdomain wkup_44xx_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_ON,
.banks= 1,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* wkup_bank */
},
@@ -153,6 +159,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
+ .context_offset = 0x18,
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF_RET, /* cpu0_l1 */
},
@@ -169,6 +176,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
+ .context_offset = 0x18,
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF_RET, /* cpu1_l1 */
},
@@ -184,6 +192,7 @@ static struct powerdomain emu_44xx_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* emu_bank */
},
@@ -200,6 +209,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 3,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF_RET, /* mpu_l1 */
[1] = PWRSTS_OFF_RET, /* mpu_l2 */
@@ -220,6 +230,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRDM_POWER_OFF,
.banks= 4,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* hwa_mem */
[1] = PWRSTS_OFF_RET, /* sl2_mem */
@@ -242,6 +253,7 @@ static struct powerdomain cam_44xx_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
+ .context_offset = 0x24,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* cam_mem */
},
@@
RE: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
-Original Message-
From: Cousson, Benoit
Sent: Thursday, September 16, 2010 3:11 AM
To: Varadarajan, Charulatha
Cc: t...@atomide.com; w...@iguana.be; linux-watch...@vger.kernel.org;
khil...@deeprootsystems.com; p...@pwsan.com; Nayak, Rajendra; Basak,
Partha; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk
FW APIs
On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:
Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings instead of using
clock FW APIs.
Signed-off-by: Charulatha Vch...@ti.com
---
drivers/watchdog/omap_wdt.c | 42 +++
---
1 files changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 76b58ab..dbbc580 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -38,11 +38,11 @@
#includelinux/err.h
#includelinux/platform_device.h
#includelinux/moduleparam.h
-#includelinux/clk.h
#includelinux/bitops.h
#includelinux/io.h
#includelinux/uaccess.h
#includelinux/slab.h
+#includelinux/pm_runtime.h
#includemach/hardware.h
#includeplat/prcm.h
Why do you have to access the PRCM from the driver?
This has nothing to do with hwmod patch series.
The reason for using prcm header is to support
GET_BOOT_STATUS ioctl which uses omap_prcm_get_reset_sources()
case WDIOC_GETBOOTSTATUS:
if (cpu_is_omap16xx())
return put_user(__raw_readw(ARM_SYSST),
(int __user *)arg);
if (cpu_is_omap24xx())
return put_user(omap_prcm_get_reset_sources(),
(int __user *)arg);
-V Charulatha
Benoit
@@ -61,8 +61,6 @@ struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
int omap_wdt_users;
- struct clk *ick;
- struct clk *fck;
struct resource *mem;
struct miscdevice omap_wdt_miscdev;
};
@@ -146,8 +144,7 @@ static int omap_wdt_open(struct inode *inode, struct
file *file)
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;
- clk_enable(wdev-ick);/* Enable the interface clock */
- clk_enable(wdev-fck);/* Enable the functional clock */
+ pm_runtime_get_sync(wdev-dev);
/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) 0x01)
@@ -177,8 +174,7 @@ static int omap_wdt_release(struct inode *inode,
struct file *file)
omap_wdt_disable(wdev);
- clk_disable(wdev-ick);
- clk_disable(wdev-fck);
+ pm_runtime_put_sync(wdev-dev);
#else
printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
#endif
@@ -292,19 +288,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
wdev-omap_wdt_users = 0;
wdev-mem = mem;
-
- wdev-ick = clk_get(pdev-dev, ick);
- if (IS_ERR(wdev-ick)) {
- ret = PTR_ERR(wdev-ick);
- wdev-ick = NULL;
- goto err_clk;
- }
- wdev-fck = clk_get(pdev-dev, fck);
- if (IS_ERR(wdev-fck)) {
- ret = PTR_ERR(wdev-fck);
- wdev-fck = NULL;
- goto err_clk;
- }
+ wdev-dev =pdev-dev;
wdev-base = ioremap(res-start, resource_size(res));
if (!wdev-base) {
@@ -314,8 +298,8 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, wdev);
- clk_enable(wdev-ick);
- clk_enable(wdev-fck);
+ pm_runtime_enable(wdev-dev);
+ pm_runtime_get_sync(wdev-dev);
omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -333,11 +317,7 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
__raw_readl(wdev-base + OMAP_WATCHDOG_REV) 0xFF,
timer_margin);
- /* autogate OCP interface clock */
- __raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
-
- clk_disable(wdev-ick);
- clk_disable(wdev-fck);
+ pm_runtime_put_sync(wdev-dev);
omap_wdt_dev = pdev;
@@ -349,12 +329,6 @@ err_misc:
err_ioremap:
wdev-base = NULL;
-
-err_clk:
- if (wdev-ick)
- clk_put(wdev-ick);
- if (wdev-fck)
- clk_put(wdev-fck);
kfree(wdev);
err_kzalloc:
@@ -386,8 +360,6 @@ static int __devexit omap_wdt_remove(struct
platform_device *pdev)
release_mem_region(res-start, resource_size(res));
platform_set_drvdata(pdev, NULL);
- clk_put(wdev-ick);
- clk_put(wdev-fck);
iounmap(wdev-base);
kfree(wdev);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 4/5] OMAP4: powerdomain: Update DSS logic state for ES2
DSS on ES2 supports only OSWR, hence remove the support
for CSWR from the powerdomain framework.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains44xx.h|2 +-
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx.h
b/arch/arm/mach-omap2/powerdomains44xx.h
index c721951..9c01b55 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.h
+++ b/arch/arm/mach-omap2/powerdomains44xx.h
@@ -98,7 +98,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.prcm_offs= OMAP4430_PRM_DSS_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
.pwrsts = PWRSTS_OFF_RET_ON,
- .pwrsts_logic_ret = PWRSTS_OFF_RET,
+ .pwrsts_logic_ret = PWRSTS_OFF,
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRDM_POWER_OFF, /* dss_mem */
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index fb6ec74..3ea7220 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -32,6 +32,7 @@
/* Powerdomain allowable state bitfields */
#define PWRSTS_ON (1 PWRDM_POWER_ON)
+#define PWRSTS_OFF (1 PWRDM_POWER_OFF)
#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | \
(1 PWRDM_POWER_ON))
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP4: PM: Define additional registers for ES2
4430 ES2 has a few new registers added and a few modified from ES1. This patch adds all the register changes in PRM and CM for OMAP4430 ES2. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoît Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/cm44xx.h | 90 - arch/arm/mach-omap2/prm44xx.h | 14 --- 2 files changed, 96 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h index 336d948..3c35a87 100644 --- a/arch/arm/mach-omap2/cm44xx.h +++ b/arch/arm/mach-omap2/cm44xx.h @@ -195,6 +195,42 @@ #define OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET 0x0088 #define OMAP4430_CM1_ABE_WDT3_CLKCTRL OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_MOD, 0x0088) +/* CM1.RESTORE_CM1 register offsets */ +#define OMAP4_CM_CLKSEL_CORE_RESTORE_OFFSET0x +#define OMAP4430_CM_CLKSEL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x) +#define OMAP4_CM_DIV_M2_DPLL_CORE_RESTORE_OFFSET 0x0004 +#define OMAP4430_CM_DIV_M2_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0004) +#define OMAP4_CM_DIV_M3_DPLL_CORE_RESTORE_OFFSET 0x0008 +#define OMAP4430_CM_DIV_M3_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0008) +#define OMAP4_CM_DIV_M4_DPLL_CORE_RESTORE_OFFSET 0x000c +#define OMAP4430_CM_DIV_M4_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x000c) +#define OMAP4_CM_DIV_M5_DPLL_CORE_RESTORE_OFFSET 0x0010 +#define OMAP4430_CM_DIV_M5_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0010) +#define OMAP4_CM_DIV_M6_DPLL_CORE_RESTORE_OFFSET 0x0014 +#define OMAP4430_CM_DIV_M6_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0014) +#define OMAP4_CM_DIV_M7_DPLL_CORE_RESTORE_OFFSET 0x0018 +#define OMAP4430_CM_DIV_M7_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0018) +#define OMAP4_CM_CLKSEL_DPLL_CORE_RESTORE_OFFSET 0x001c +#define OMAP4430_CM_CLKSEL_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x001c) +#define OMAP4_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE_OFFSET 0x0020 +#define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0020) +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE_OFFSET 0x0024 +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0024) +#define OMAP4_CM_CLKMODE_DPLL_CORE_RESTORE_OFFSET 0x0028 +#define OMAP4430_CM_CLKMODE_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0028) +#define OMAP4_CM_SHADOW_FREQ_CONFIG2_RESTORE_OFFSET0x002c +#define OMAP4430_CM_SHADOW_FREQ_CONFIG2_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x002c) +#define OMAP4_CM_SHADOW_FREQ_CONFIG1_RESTORE_OFFSET0x0030 +#define OMAP4430_CM_SHADOW_FREQ_CONFIG1_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0030) +#define OMAP4_CM_AUTOIDLE_DPLL_CORE_RESTORE_OFFSET 0x0034 +#define OMAP4430_CM_AUTOIDLE_DPLL_CORE_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0034) +#define OMAP4_CM_MPU_CLKSTCTRL_RESTORE_OFFSET 0x0038 +#define OMAP4430_CM_MPU_CLKSTCTRL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0038) +#define OMAP4_CM_CM1_PROFILING_CLKCTRL_RESTORE_OFFSET 0x003c +#define OMAP4430_CM_CM1_PROFILING_CLKCTRL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x003c) +#define OMAP4_CM_DYN_DEP_PRESCAL_RESTORE_OFFSET0x0040 +#define OMAP4430_CM_DYN_DEP_PRESCAL_RESTORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0040) + /* CM2 */ /* CM2.OCP_SOCKET_CM2 register offsets */ @@ -252,8 +288,6 @@ #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_PER OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0068) #define OMAP4_CM_SSC_MODFREQDIV_DPLL_PER_OFFSET0x006c #define OMAP4430_CM_SSC_MODFREQDIV_DPLL_PER OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x006c) -#define OMAP4_CM_EMU_OVERRIDE_DPLL_PER_OFFSET 0x0070 -#define OMAP4430_CM_EMU_OVERRIDE_DPLL_PER OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0070) #define OMAP4_CM_CLKMODE_DPLL_USB_OFFSET 0x0080 #define OMAP4430_CM_CLKMODE_DPLL_USB OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0080) #define OMAP4_CM_IDLEST_DPLL_USB_OFFSET0x0084 @@ -296,6 +330,8 @@ #define OMAP4430_CM_ALWON_SR_IVA_CLKCTRL OMAP44XX_CM2_REGADDR(OMAP4430_CM2_ALWAYS_ON_MOD, 0x0030) #define OMAP4_CM_ALWON_SR_CORE_CLKCTRL_OFFSET 0x0038 #define OMAP4430_CM_ALWON_SR_CORE_CLKCTRL
[PATCH 3/5] OMAP4: clocks: Update clock tree for ES2
This patch updates the clock tree with all the
changes in OMAP4430 ES2.
clock nodes added
-1- tie_low_clock_ck
-2- abe_dpll_bypass_clk_mux_ck
clock nodes deleted
-1- dpll_sys_ref_clk
-2- per_sgx_fclk
-3- usbphyocp2scp_ick
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoît Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clock44xx_data.c | 168 ++
1 files changed, 70 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..6e5a893 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -175,21 +175,27 @@ static struct clk sys_clkin_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk tie_low_clock_ck = {
+ .name = tie_low_clock_ck,
+ .rate = 0,
+ .ops= clkops_null,
+};
+
static struct clk utmi_phy_clkout_ck = {
.name = utmi_phy_clkout_ck,
- .rate = 1200,
+ .rate = 6000,
.ops= clkops_null,
};
static struct clk xclk60mhsp1_ck = {
.name = xclk60mhsp1_ck,
- .rate = 1200,
+ .rate = 6000,
.ops= clkops_null,
};
static struct clk xclk60mhsp2_ck = {
.name = xclk60mhsp2_ck,
- .rate = 1200,
+ .rate = 6000,
.ops= clkops_null,
};
@@ -201,39 +207,23 @@ static struct clk xclk60motg_ck = {
/* Module clocks and DPLL outputs */
-static const struct clksel_rate div2_1to2_rates[] = {
- { .div = 1, .val = 0, .flags = RATE_IN_4430 },
- { .div = 2, .val = 1, .flags = RATE_IN_4430 },
- { .div = 0 },
-};
-
-static const struct clksel dpll_sys_ref_clk_div[] = {
- { .parent = sys_clkin_ck, .rates = div2_1to2_rates },
+static const struct clksel abe_dpll_bypass_clk_mux_sel[] = {
+ { .parent = sys_clkin_ck, .rates = div_1_0_rates },
+ { .parent = sys_32k_ck, .rates = div_1_1_rates },
{ .parent = NULL },
};
-static struct clk dpll_sys_ref_clk = {
- .name = dpll_sys_ref_clk,
+static struct clk abe_dpll_bypass_clk_mux_ck = {
+ .name = abe_dpll_bypass_clk_mux_ck,
.parent = sys_clkin_ck,
- .clksel = dpll_sys_ref_clk_div,
- .clksel_reg = OMAP4430_CM_DPLL_SYS_REF_CLKSEL,
- .clksel_mask= OMAP4430_CLKSEL_0_0_MASK,
.ops= clkops_null,
- .recalc = omap2_clksel_recalc,
- .round_rate = omap2_clksel_round_rate,
- .set_rate = omap2_clksel_set_rate,
-};
-
-static const struct clksel abe_dpll_refclk_mux_sel[] = {
- { .parent = dpll_sys_ref_clk, .rates = div_1_0_rates },
- { .parent = sys_32k_ck, .rates = div_1_1_rates },
- { .parent = NULL },
+ .recalc = followparent_recalc,
};
static struct clk abe_dpll_refclk_mux_ck = {
.name = abe_dpll_refclk_mux_ck,
- .parent = dpll_sys_ref_clk,
- .clksel = abe_dpll_refclk_mux_sel,
+ .parent = sys_clkin_ck,
+ .clksel = abe_dpll_bypass_clk_mux_sel,
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP4430_CM_ABE_PLL_REF_CLKSEL,
.clksel_mask= OMAP4430_CLKSEL_0_0_MASK,
@@ -244,7 +234,7 @@ static struct clk abe_dpll_refclk_mux_ck = {
/* DPLL_ABE */
static struct dpll_data dpll_abe_dd = {
.mult_div1_reg = OMAP4430_CM_CLKSEL_DPLL_ABE,
- .clk_bypass = sys_clkin_ck,
+ .clk_bypass = abe_dpll_bypass_clk_mux_ck,
.clk_ref= abe_dpll_refclk_mux_ck,
.control_reg= OMAP4430_CM_CLKMODE_DPLL_ABE,
.modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
@@ -310,6 +300,12 @@ static struct clk abe_clk = {
.set_rate = omap2_clksel_set_rate,
};
+static const struct clksel_rate div2_1to2_rates[] = {
+ { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
static const struct clksel aess_fclk_div[] = {
{ .parent = abe_clk, .rates = div2_1to2_rates },
{ .parent = NULL },
@@ -380,14 +376,14 @@ static struct clk dpll_abe_m3_ck = {
};
static const struct clksel core_hsd_byp_clk_mux_sel[] = {
- { .parent = dpll_sys_ref_clk, .rates = div_1_0_rates },
+ { .parent = sys_clkin_ck, .rates = div_1_0_rates },
{ .parent = dpll_abe_m3_ck, .rates = div_1_1_rates },
{ .parent = NULL },
};
static struct clk core_hsd_byp_clk_mux_ck = {
.name = core_hsd_byp_clk_mux_ck,
- .parent = dpll_sys_ref_clk,
+ .parent = sys_clkin_ck,
.clksel = core_hsd_byp_clk_mux_sel,
.init
[PATCH 1/5] OMAP4: PM: Update PRCM register bitshits and masks for ES2
This patch updates the PRM and CM register bitshifts and masks for OMAP4430 ES2.0. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoît Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/cm-regbits-44xx.h | 327 ++-- arch/arm/mach-omap2/prm-regbits-44xx.h | 194 +++ 2 files changed, 342 insertions(+), 179 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-44xx.h b/arch/arm/mach-omap2/cm-regbits-44xx.h index ac8458e..92ebfd4 100644 --- a/arch/arm/mach-omap2/cm-regbits-44xx.h +++ b/arch/arm/mach-omap2/cm-regbits-44xx.h @@ -1,8 +1,8 @@ /* * OMAP44xx Clock Management register bits * - * Copyright (C) 2009 Texas Instruments, Inc. - * Copyright (C) 2009 Nokia Corporation + * Copyright (C) 2009-2010 Texas Instruments, Inc. + * Copyright (C) 2009-2010 Nokia Corporation * * Paul Walmsley (p...@pwsan.com) * Rajendra Nayak (rna...@ti.com) @@ -25,19 +25,22 @@ #include cm.h -/* Used by CM_L3_1_DYNAMICDEP, CM_MPU_DYNAMICDEP, CM_TESLA_DYNAMICDEP */ +/* + * Used by CM_L3_1_DYNAMICDEP, CM_L3_1_DYNAMICDEP_RESTORE, CM_MPU_DYNAMICDEP, + * CM_TESLA_DYNAMICDEP + */ #define OMAP4430_ABE_DYNDEP_SHIFT 3 #define OMAP4430_ABE_DYNDEP_MASK BITFIELD(3, 3) /* * Used by CM_D2D_STATICDEP, CM_DUCATI_STATICDEP, CM_SDMA_STATICDEP, - * CM_L3INIT_STATICDEP, CM_SDMA_STATICDEP_RESTORE, CM_MPU_STATICDEP, - * CM_TESLA_STATICDEP + * CM_L3INIT_STATICDEP, CM_D2D_STATICDEP_RESTORE, CM_SDMA_STATICDEP_RESTORE, + * CM_MPU_STATICDEP, CM_TESLA_STATICDEP */ #define OMAP4430_ABE_STATDEP_SHIFT 3 #define OMAP4430_ABE_STATDEP_MASK BITFIELD(3, 3) -/* Used by CM_L4CFG_DYNAMICDEP */ +/* Used by CM_L4CFG_DYNAMICDEP, CM_L4CFG_DYNAMICDEP_RESTORE */ #define OMAP4430_ALWONCORE_DYNDEP_SHIFT16 #define OMAP4430_ALWONCORE_DYNDEP_MASK BITFIELD(16, 16) @@ -53,7 +56,7 @@ #define OMAP4430_AUTO_DPLL_MODE_SHIFT 0 #define OMAP4430_AUTO_DPLL_MODE_MASK BITFIELD(0, 2) -/* Used by CM_L4CFG_DYNAMICDEP */ +/* Used by CM_L4CFG_DYNAMICDEP, CM_L4CFG_DYNAMICDEP_RESTORE */ #define OMAP4430_CEFUSE_DYNDEP_SHIFT 17 #define OMAP4430_CEFUSE_DYNDEP_MASKBITFIELD(17, 17) @@ -97,6 +100,10 @@ #define OMAP4430_CLKACTIVITY_CAM_PHY_CTRL_GCLK_SHIFT 9 #define OMAP4430_CLKACTIVITY_CAM_PHY_CTRL_GCLK_MASKBITFIELD(9, 9) +/* Used by CM_ALWON_CLKSTCTRL */ +#define OMAP4430_CLKACTIVITY_CORE_ALWON_32K_GFCLK_SHIFT12 +#define OMAP4430_CLKACTIVITY_CORE_ALWON_32K_GFCLK_MASK BITFIELD(12, 12) + /* Used by CM_EMU_CLKSTCTRL */ #define OMAP4430_CLKACTIVITY_CORE_DPLL_EMU_CLK_SHIFT 9 #define OMAP4430_CLKACTIVITY_CORE_DPLL_EMU_CLK_MASKBITFIELD(9, 9) @@ -145,10 +152,6 @@ #define OMAP4430_CLKACTIVITY_DUCATI_GCLK_SHIFT 8 #define OMAP4430_CLKACTIVITY_DUCATI_GCLK_MASK BITFIELD(8, 8) -/* Used by CM_L3INIT_CLKSTCTRL, CM_L3INIT_CLKSTCTRL_RESTORE */ -#define OMAP4430_CLKACTIVITY_EMAC_50MHZ_CLK_SHIFT 10 -#define OMAP4430_CLKACTIVITY_EMAC_50MHZ_CLK_MASK BITFIELD(10, 10) - /* Used by CM_EMU_CLKSTCTRL */ #define OMAP4430_CLKACTIVITY_EMU_SYS_CLK_SHIFT 8 #define OMAP4430_CLKACTIVITY_EMU_SYS_CLK_MASK BITFIELD(8, 8) @@ -185,10 +188,6 @@ #define OMAP4430_CLKACTIVITY_HSIC_P2_GFCLK_SHIFT 27 #define OMAP4430_CLKACTIVITY_HSIC_P2_GFCLK_MASK BITFIELD(27, 27) -/* Used by CM_L3INIT_CLKSTCTRL */ -#define OMAP4430_CLKACTIVITY_INIT_32K_GFCLK_SHIFT 31 -#define OMAP4430_CLKACTIVITY_INIT_32K_GFCLK_MASK BITFIELD(31, 31) - /* Used by CM_L3INIT_CLKSTCTRL, CM_L3INIT_CLKSTCTRL_RESTORE */ #define OMAP4430_CLKACTIVITY_INIT_48MC_GFCLK_SHIFT 13 #define OMAP4430_CLKACTIVITY_INIT_48MC_GFCLK_MASK BITFIELD(13, 13) @@ -233,9 +232,9 @@ #define OMAP4430_CLKACTIVITY_IVAHD_ROOT_CLK_SHIFT 8 #define OMAP4430_CLKACTIVITY_IVAHD_ROOT_CLK_MASK BITFIELD(8, 8) -/* Used by CM_L3INIT_CLKSTCTRL, CM_L3INIT_CLKSTCTRL_RESTORE */ -#define OMAP4430_CLKACTIVITY_L3INIT_DPLL_ALWON_CLK_SHIFT 14 -#define OMAP4430_CLKACTIVITY_L3INIT_DPLL_ALWON_CLK_MASK BITFIELD(14, 14) +/* Used by CM_D2D_CLKSTCTRL */ +#define OMAP4430_CLKACTIVITY_L3X2_D2D_GICLK_SHIFT 10 +#define OMAP4430_CLKACTIVITY_L3X2_D2D_GICLK_MASK BITFIELD(10, 10) /* Used by CM_L3_1_CLKSTCTRL, CM_L3_1_CLKSTCTRL_RESTORE */ #define OMAP4430_CLKACTIVITY_L3_1_GICLK_SHIFT 8 @@ -337,10 +336,6 @@ #define OMAP4430_CLKACTIVITY_PER_ABE_24M_GFCLK_SHIFT 25 #define OMAP4430_CLKACTIVITY_PER_ABE_24M_GFCLK_MASK
RE: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
-Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 5:45 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Gopinath, Thara had written, on 09/16/2010 05:40 AM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, September 16, 2010 3:27 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code From: Paul Walmsley p...@pwsan.com The OPP layer code should be independent of the PMIC, introduce the TWL/TPS-specific code out to its own file. Hello Kevin, I have been using this code for a while now. I really do not think wee need a separate file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage This split introduces a PMIC level abstraction already. Do you have a suggestion which file it should go to? It is definitely not part of opp.c, not part of other existing twl files as well. the job of this file was to introduce conversion routines which can be used by any layer (voltage layer if need be - it used to be srf and smartreflex before).. in fact one of your voltage layer patches introduces capability for 6030 as well http://marc.info/?l=linux-omapm=128213020927919w=2 Yes one of my patches has introduces this coz I had no other way to add OMAP4 support. But I still do not understand why cant these APIs be implemented in twl-core.c or twl4030-power.c? layer is interested in these conversions. Voltage layer has a structure that can be populated with the information required from the PMIC. We only need to add two more function pointers to this structure. This info can then be passed from the actual PMIC driver file. This will make it much more simpler for OMAP4 where we have different formulas between different revisions of PMIC. Also in the omap voltage code we will no longer have to hard code omap_twl_vsel_to_uv and omap_twl_uv_to_vsel. I think the problem is with the voltage layer (which has not been posted upstream) which is using hard coded function pointer. What the patchset should have done is to introduce function pointers registration from twl_tps.c to voltage layer and voltage layer should ideally been using function pointers by itself. So please consider dropping this patch from this series. I think I disagree - rationale for having this separated as a pmic specific file is still sound, only the implementation of the future framework should have changed (it should be using function pointers instead of hardcoded function names). in fact I can add additional suggestion for the voltage layer: the pmic selection should be done from a board file - This will allow voltage layer to handle numerous PMICs and combination of PMICs controlling various domains as well.. the only neat way to handle it is ofcourse using function pointers. Exactly if voltage layer has to use a func ptr, why not let them be populated by the PMIC driver files directly? PS: Suggestion - please fix your mailer to round off for 70/80 char. Will try. - might be good to point folks to rfc patchset for voltage layer to give context. https://patchwork.kernel.org/patch/119429/ -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishant,
Since you are anyways re-sending this you might as well fix these nits.
On 09/16/2010 12:56 AM, ext Kevin Hilman wrote:
From: Nishanth Menonn...@ti.com
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
new file mode 100644
index 000..17f93b2
--- /dev/null
+++ b/arch/arm/plat-omap/opp.c
@@ -0,0 +1,461 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Romit Dasguptaro...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/**
+ * opp_get_voltage() - Gets the voltage corresponding to an opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * Return voltage in micro volt corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_voltage(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
If !opp-enabled, then is it really an invalid parameter being passed?
I'm not user if people need to know the voltage of a disabled OPP, but
do we need to limit it?
+ pr_err(%s: Invalid parameters being passed\n, __func__);
+ return 0;
+ }
+
+ return opp-u_volt;
+}
+
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
ditto.
+ pr_err(%s: Invalid parameters being passed\n, __func__);
+ return 0;
+ }
+
+ return opp-rate;
+}
+
+/**
+ * opp_get_opp_count() - Get number of opps enabled in the opp list
+ * @opp_type: OPP type we want to count
+ *
+ * This functions returns the number of opps if there are any OPPs enabled,
+ * else returns corresponding error value.
+ */
+int opp_get_opp_count(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return -ENODEV;
+
+ return dev_opp-enabled_opp_count;
+}
+
+/**
+ * opp_find_freq_exact() - search for an exact frequency
+ * @opp_type: OPP type we want to search in.
+ * @freq: frequency to search for
+ * @enabled: enabled/disabled OPP to search for
+ *
+ * Searches for exact match in the opp list and returns handle to the matching
+ * opp if found, else returns ERR_PTR in case of error and should be handled
+ * using IS_ERR.
+ *
+ * Note enabled is a modifier for the search. if enabled=true, then the match
is
Good to add some punctuation after 'Note'.
+ * for exact matching frequency and is enabled. if false, the match is for
exact
+ * frequency which is disabled.
+ */
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
On 9/16/2010 3:37 PM, Varadarajan, Charulatha wrote: From: Cousson, Benoit Sent: Thursday, September 16, 2010 3:11 AM On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote: Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync() for enabling/disabling the clocks, sysconfig settings instead of using clock FW APIs. Signed-off-by: Charulatha Vch...@ti.com --- drivers/watchdog/omap_wdt.c | 42 +++ --- 1 files changed, 7 insertions(+), 35 deletions(-) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 76b58ab..dbbc580 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -38,11 +38,11 @@ #includelinux/err.h #includelinux/platform_device.h #includelinux/moduleparam.h -#includelinux/clk.h #includelinux/bitops.h #includelinux/io.h #includelinux/uaccess.h #includelinux/slab.h +#includelinux/pm_runtime.h #includemach/hardware.h #includeplat/prcm.h Why do you have to access the PRCM from the driver? This has nothing to do with hwmod patch series. Yes, I know, but since you removed some include, I was wondering if that one was still useful. The reason for using prcm header is to support GET_BOOT_STATUS ioctl which uses omap_prcm_get_reset_sources() Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Roger Quadros had written, on 09/16/2010 08:54 AM, the following:
Since you are anyways re-sending this you might as well fix these nits.
thanks for reviewing..
[..]
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
new file mode 100644
index 000..17f93b2
--- /dev/null
+++ b/arch/arm/plat-omap/opp.c
@@ -0,0 +1,461 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Romit Dasguptaro...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/**
+ * opp_get_voltage() - Gets the voltage corresponding to an opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * Return voltage in micro volt corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_voltage(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
If !opp-enabled, then is it really an invalid parameter being passed?
I'm not user if people need to know the voltage of a disabled OPP, but
do we need to limit it?
+ pr_err(%s: Invalid parameters being passed\n, __func__);
+ return 0;
+ }
+
+ return opp-u_volt;
+}
+
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
ditto.
Yes, the intent here was for opp operational apis to function ONLY on
the enabled opps - this helps to pull out any bugs in the users
who might be unintentionally using bad params.
do you have any usecase you can think of where we might want to use
these on a disabled opp?
+ pr_err(%s: Invalid parameters being passed\n, __func__);
+ return 0;
+ }
+
+ return opp-rate;
+}
+
+/**
+ * opp_get_opp_count() - Get number of opps enabled in the opp list
+ * @opp_type: OPP type we want to count
+ *
+ * This functions returns the number of opps if there are any OPPs enabled,
+ * else returns corresponding error value.
+ */
+int opp_get_opp_count(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ dev_opp = find_device_opp(dev);
+ if (IS_ERR(dev_opp))
+ return -ENODEV;
+
+ return dev_opp-enabled_opp_count;
+}
+
+/**
+ * opp_find_freq_exact() - search for an exact frequency
+ * @opp_type: OPP type we want to search in.
+ * @freq: frequency to search for
+ * @enabled: enabled/disabled OPP to search for
+ *
+ * Searches for exact match in the opp list and returns handle to the matching
+ * opp if found, else returns ERR_PTR in case of error and should be handled
+ * using IS_ERR.
+ *
+ * Note enabled is a modifier for the search. if enabled=true, then the match
is
Good to add some punctuation after 'Note'.
Thanks will do
+ * for exact matching frequency and is enabled. if false, the match is for
exact
+ * frequency which is disabled.
+ */
cheers,
-roger
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
Gopinath, Thara had written, on 09/16/2010 08:51 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 5:45 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Gopinath, Thara had written, on 09/16/2010 05:40 AM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, September 16, 2010 3:27 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code From: Paul Walmsley p...@pwsan.com The OPP layer code should be independent of the PMIC, introduce the TWL/TPS-specific code out to its own file. Hello Kevin, I have been using this code for a while now. I really do not think wee need a separate file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage This split introduces a PMIC level abstraction already. Do you have a suggestion which file it should go to? It is definitely not part of opp.c, not part of other existing twl files as well. the job of this file was to introduce conversion routines which can be used by any layer (voltage layer if need be - it used to be srf and smartreflex before).. in fact one of your voltage layer patches introduces capability for 6030 as well http://marc.info/?l=linux-omapm=128213020927919w=2 Yes one of my patches has introduces this coz I had no other way to add OMAP4 support. But I still do not understand why cant these APIs be implemented in twl-core.c or twl4030-power.c? Why there? Twl power does regulator operations not conversion operations. core is not the place either as it is function independent. layer is interested in these conversions. Voltage layer has a structure that can be populated with the information required from the PMIC. We only need to add two more function pointers to this structure. This info can then be passed from the actual PMIC driver file. This will make it much more simpler for OMAP4 where we have different formulas between different revisions of PMIC. Also in the omap voltage code we will no longer have to hard code omap_twl_vsel_to_uv and omap_twl_uv_to_vsel. I think the problem is with the voltage layer (which has not been posted upstream) which is using hard coded function pointer. What the patchset should have done is to introduce function pointers registration from twl_tps.c to voltage layer and voltage layer should ideally been using function pointers by itself. So please consider dropping this patch from this series. I think I disagree - rationale for having this separated as a pmic specific file is still sound, only the implementation of the future framework should have changed (it should be using function pointers instead of hardcoded function names). in fact I can add additional suggestion for the voltage layer: the pmic selection should be done from a board file - This will allow voltage layer to handle numerous PMICs and combination of PMICs controlling various domains as well.. the only neat way to handle it is ofcourse using function pointers. Exactly if voltage layer has to use a func ptr, why not let them be populated by the PMIC driver files directly? Again, we are going into the details of how voltage layer will be implemented.. What suggestion do you do when on board x vdd1 is driven by PMIC1, vdd2 by PMIC2? it will have to be somesort of different registration mechanism. but nothing prevents the framework from registering the pointers defined in twl_tps.c PS: Suggestion - please fix your mailer to round off for 70/80 char. Will try. - might be good to point folks to rfc patchset for voltage layer to give context. https://patchwork.kernel.org/patch/119429/ thanks.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lm-sensors] [PATCH 2/2] Makefile and Kconfig changes for twl4030-madc driver
On Thu, Sep 16, 2010 at 06:23:32AM -0400, Keerthy wrote: Makefile amd Kconfig Changes for twl4030-madc driver inclusion. Signed-off-by: Keerthy j-keer...@ti.com --- arch/arm/mach-omap2/Kconfig |4 drivers/hwmon/Kconfig |4 drivers/hwmon/Makefile |1 + 3 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b48bacf..139137b 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -170,6 +170,8 @@ config MACH_OMAP_3430SDP depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select HWMON + select TWL4030_MADC config MACH_NOKIA_N800 bool @@ -206,6 +208,8 @@ config MACH_OMAP_ZOOM3 depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBP + select HWMON + select TWL4030_MADC config MACH_CM_T35 bool CompuLab CM-T35 module diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig While it may make sense to have the above changes in a separate patch, the two files below should be part of patch #1, since they are logically part of the driver, and the driver itself won't make any sense in the code without being enabled in Kconfig/Makefile. index 4d4d09b..47d66b9 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -39,6 +39,10 @@ config HWMON_DEBUG_CHIP comment Native drivers +config TWL4030_MADC Please use SENSORS_TWL4030_MADC or SENSORS_TWL4030 to be in line with all other definitions. Also, please retain alphabetical order. + tristate + depends on HWMON TWL4030_CORE + HWMON is really redundant here and should be removed. config SENSORS_ABITUGURU tristate Abit uGuru (rev 1 2) depends on X86 EXPERIMENTAL diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index e3c2484..24b3b17 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -16,6 +16,7 @@ obj-$(CONFIG_SENSORS_W83792D) += w83792d.o obj-$(CONFIG_SENSORS_W83793) += w83793.o obj-$(CONFIG_SENSORS_W83781D)+= w83781d.o obj-$(CONFIG_SENSORS_W83791D)+= w83791d.o +obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o Again, please retain alphabetical order. There is a reason for the other sensors to be out of order (see comments in the Makefile), but presumably that does not apply this one. If it does, please add comment/reason indicating that/if this is the case. obj-$(CONFIG_SENSORS_ABITUGURU) += abituguru.o obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o -- 1.7.0.4 ___ lm-sensors mailing list lm-sens...@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Roger Quadros had written, on 09/16/2010 09:20 AM, the following:
[...]
+/**
+ * opp_get_freq() - Gets the frequency corresponding to an opp
+ * @opp: opp for which frequency has to be returned for
+ *
+ * Return frequency in hertz corresponding to the opp, else
+ * return 0
+ */
+unsigned long opp_get_freq(const struct omap_opp *opp)
+{
+ if (unlikely(!opp || IS_ERR(opp)) || !opp-enabled) {
ditto.
Yes, the intent here was for opp operational apis to function ONLY on
the enabled opps - this helps to pull out any bugs in the users
who might be unintentionally using bad params.
OK.
do you have any usecase you can think of where we might want to use
these on a disabled opp?
Not really. Based on what is an OPP enabled/disabled? Is it possible for
an initially enabled OPP to be disabled at some point in time? What
triggers this disable?
OR does an OPP enabled at boot time remain enabled throughout the power
session?
At this point - enable/disable is done at init time - there is
flexibility for board files to define their own custom OPPs (as some
custom boards need to). they dont change once this initial definition is
done. there are plans to do dynamic enable disable based on previous
discussion in l-o - the framework to use opp layer in that manner is yet
to go up yet.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Hi Linus,
Linus Walleij linus.wall...@stericsson.com writes:
2010/9/15 Kevin Hilman khil...@deeprootsystems.com:
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs.
(...)
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
OPPs are a generic concept, it's in silicon construction textbooks and all.
Should this code not be made generic instead? You wouldn't make
regulators or even DMA platform-specific these days, so why should
OPPs be?
You're right.
What in this code is actually OMAP-specific
Only the users. ;)
We currently register OPPs using an OMAP hwmod name, but we could easily
change that to use a struct device instead which would make this
much more generic (note we manage OPPs per-device, not just for the CPU)
The patch below[1] demonstrates quickly how easily we could remove all OMAP
specific stuff from opp.[ch], and move it to the OMAP-specific code that
does the opp_add()
more than that you name
some functions omap_*, and how hard would it be to put it under
arch/arm/common/*.c
arch/arm/include/asm/*.h
Possible even higher up in the directory hiearchy in include/linux/opp.h
for the header and drivers/opp/*.c, because I think SuperH and power
are not that different in this respect.
Yeah, I guess this isn't ARM specific either, so should be at a higher
level.
Nishanth, can take my hack below and continue this evolution? As I
demonstrate with this hack, this won't really change anything for us.
Kevin
From 96c4e27ba0cb3d9a056693340c6221bc093bce2c Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Thu, 16 Sep 2010 07:58:16 -0700
Subject: [PATCH] OPP: remove OMAP specifics to make more generic
Internal OPP management is based on 'struct device *', so
we don't need to have omap_hwmod specific knowledge in this layer.
Change opp_add() to take a 'struct device *' instead of using
the OMAP hwmod in the opp_def to lookup the struct device.
Move OMAP-specific hwmod lookups into the OMAP specific layer
which adds OPPs to the database.
Quickly tested on OMAP3 to see that all OPPs are still registered
correctly with CPUfreq
---
arch/arm/mach-omap2/opp3xxx_data.c| 18 +-
arch/arm/plat-omap/include/plat/opp.h |2 +-
arch/arm/plat-omap/opp.c | 24 ++--
3 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index e337aeb..f3f9ae4 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -23,6 +23,7 @@
#include plat/opp.h
#include plat/cpu.h
+#include plat/omap_device.h
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
@@ -114,7 +115,22 @@ int __init omap3_pm_init_opp_table(void)
opp_def = omap3_opp_def_list;
for (i = 0; i omap3_opp_def_size; i++) {
- r = opp_add(opp_def++);
+ struct omap_hwmod *oh;
+ struct device *dev;
+
+ if (!opp_def-hwmod_name) {
+ pr_err(%s: missing name of omap_hwmod, ignoring.\n,
__func__);
+ return -EINVAL;
+ }
+ oh = omap_hwmod_lookup(opp_def-hwmod_name);
+ if (!oh || !oh-od) {
+ pr_warn(%s: no hwmod or odev for %s, cannot add
OPPs.\n,
+ __func__, opp_def-hwmod_name);
+ return -EINVAL;
+ }
+ dev = oh-od-pdev.dev;
+
+ r = opp_add(dev, opp_def++);
if (r)
pr_err(unable to add OPP %ld Hz for %s\n,
opp_def-freq, opp_def-hwmod_name);
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 9af8c83..82cfdd6 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -75,7 +75,7 @@ struct omap_opp *opp_find_freq_floor(struct device *dev,
unsigned long *freq);
struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq);
-int opp_add(const struct omap_opp_def *opp_def);
+int opp_add(struct device *dev, const struct omap_opp_def *opp_def);
int opp_enable(struct omap_opp *opp);
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index b26326b..f5295ca 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -21,7 +21,6 @@
#include linux/list.h
#include plat/opp.h
-#include plat/omap_device.h
/**
* struct omap_opp - OMAP OPP description structure
@@ -58,7 +57,6 @@ struct omap_opp {
struct device_opp {
struct list_head node;
- struct omap_hwmod *oh;
struct device *dev;
struct list_head opp_list;
@@ -291,29 +289,12
Re: [PATCH 1/5] OMAP4: PM: Update PRCM register bitshits and masks for ES2
OMAP4: PM: Update PRCM register bitshits and masks for ES2 hmm, bit shits... Looks like ES2 added another special register feature. Sounds like an operation to randomly trash register contents?;) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [lm-sensors] [PATCH 1/2] hwmon: twl4030: Driver for twl4030 madc module
On Thu, Sep 16, 2010 at 06:23:24AM -0400, Keerthy wrote:
MADC driver is added under hwmon drivers. This driver monitors the real time
conversion of analog signals like battery temperature,
battery type, battery level etc. User can also ask for the conversion on a
particular channel using the sysfs nodes.
Number of comments inline. This is not a complete review; I think there
is some cleanup to be done before that is possible.
Please run the driver through Lindent. While I understand that people prefer
their personal touch, it makes it easier to have a single coding style in the
kernel.
I commented on this a couple of times below - the driver mixes generic ADC
reading functions with hwmon functionality. Generic ADC reading functionality
should be moved into another driver, possibly to mfd.
Several people have contributed to this driver on the linux-omap list.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/hwmon/twl4030-madc.c | 584
++
include/linux/i2c/twl4030-madc.h | 118
2 files changed, 702 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/twl4030-madc.c
create mode 100644 include/linux/i2c/twl4030-madc.h
diff --git a/drivers/hwmon/twl4030-madc.c b/drivers/hwmon/twl4030-madc.c
new file mode 100644
index 000..b96fccd
--- /dev/null
+++ b/drivers/hwmon/twl4030-madc.c
@@ -0,0 +1,584 @@
+/*
It is customary to add a brief description as well as the author here.
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/types.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/platform_device.h
+#include linux/miscdevice.h
+#include linux/slab.h
+#include linux/i2c/twl.h
+#include linux/i2c/twl4030-madc.h
+#include linux/sysfs.h
+#include linux/hwmon.h
+#include linux/hwmon-sysfs.h
+
+#include linux/uaccess.h
+
+
Extra blank line. Lindent will remove it.
+struct twl4030_madc_data {
+ struct device *hwmon_dev;
+ struct mutexlock;
+ struct work_struct ws;
+ struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+ int imr;
+ int isr;
+};
+
+static struct twl4030_madc_data *the_madc;
+
This variable should not exist. See other comments later.
+static ssize_t madc_read(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct twl4030_madc_request req;
+ int status;
+ unsigned long val;
+
+ req.channels = (1 attr-index);
+ req.method = TWL4030_MADC_SW2;
+ req.func_cb = NULL;
+
+ val = twl4030_madc_conversion(req);
+ if (likely(val = 0))
+ val = req.rbuf[attr-index];
+ else
+ return val;
+ status = sprintf(buf, %lu\n, val);
+ return status;
+}
+
+static
+const struct twl4030_madc_conversion_method twl4030_conversion_methods[] = {
+ [TWL4030_MADC_RT] = {
+ .sel= TWL4030_MADC_RTSELECT_LSB,
+ .avg= TWL4030_MADC_RTAVERAGE_LSB,
+ .rbase = TWL4030_MADC_RTCH0_LSB,
+ },
+ [TWL4030_MADC_SW1] = {
+ .sel= TWL4030_MADC_SW1SELECT_LSB,
+ .avg= TWL4030_MADC_SW1AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW1,
+ },
+ [TWL4030_MADC_SW2] = {
+ .sel= TWL4030_MADC_SW2SELECT_LSB,
+ .avg= TWL4030_MADC_SW2AVERAGE_LSB,
+ .rbase = TWL4030_MADC_GPCH0_LSB,
+ .ctrl = TWL4030_MADC_CTRL_SW2,
+ },
+};
+
+static int twl4030_madc_read(struct twl4030_madc_data *madc, u8 reg)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, val, reg);
Structural comment. If there is a i2c master, why don't you have an I2C
master driver instead of calling a platform dependent i2c function ?
I see this function called from all over the place, so maybe there is a
reason. Just looks odd, though.
+ if (ret) {
+ dev_dbg(madc-hwmon_dev, unable to
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Gopinath, Thara th...@ti.com writes: [...] + * omap_voltage_add_userreq : API to keep track of various requests to + *scale the VDD and returns the best possible + *voltage the VDD can be put to. + * @volt_domain: pointer to the voltage domain. + * @dev : the device pointer. + * @volt : the voltage which is requested by the device. + * + * This API is to be called before the actual voltage scaling is + * done to determine what is the best possible voltage the VDD can + * be put to. This API adds the device dev in the user list of the + * vdd volt_domain with volt as the requested voltage. The user list + * is a plist with the priority element absolute voltage values. + * The API then finds the maximum of all the requested voltages for + * the VDD and returns it back through volt pointer itself. + * Returns error value in case of any errors. + */ +int omap_voltage_add_userreq(struct voltagedomain *voltdm, struct device *dev, + unsigned long *volt) How about just omap_voltage_add_request() Also, do we need both voltdm and dev? With your other patches, can't we look up the voltm based on dev? Or, is there a need for a device to add a request in a voltage domain other than the one to which it belongs? Also, how does one remove a voltage request? Hello Kevin, I could rename this API to what you have suggested. Yes we do need voltdm and dev. Let us say I have three devices in a voltdm and I need to maintain a request for each of these devices. OK, thanks for clarifying. When a omap_device_set_rate API is called by the device to lower its rate the voltage request will automatically get lowered. OK, but what about removing a request when a device no longer has any voltage constraints. [...] Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
Gopinath, Thara th...@ti.com writes:
[...]
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count)
+{
+ struct device_opp *dev_opp;
+ struct device **dev_list;
+ int count = 0, i = 0;
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (!dev_opp-oh-vdd_name)
+ continue;
+
+ if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
+ dev_opp-oh-voltdm = voltdm;
Couldn't we assign the voltdm at opp_add() time since you added it as
part of the hwmod?
We cannot as the voltage layer is not initialized at the point of opp_add.
Having said this, today voltage layer is dependent on opp layer only to
figure out
the current nominal voltage from the opp table. If that can be some how
decoupled we
can initialize voltage layer early on and implement this.
We could decouple the voltage init into and early init and late init to
handle this.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, September 02, 2010 6:04 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain Thara Gopinath th...@ti.com writes: This patch adds an API in the opp layer that can be used by the voltage layer to get a list of all the scalable devices belonging to a particular voltage domain. This API is to be typically called only once by the voltage layer per voltage domain instance and the device list should be stored. This approach makes it easy during dvfs to scale all the devices associated with a voltage domain and then scale the voltage domain. Signed-off-by: Thara Gopinath th...@ti.com I don't think the OPP layer is the right place for this after all. How about something like this in the voltage layer: omap_voltage_add_device(struct voltagedomain *voltdm, struct device *dev) During omap_device_build(), if the hwmod has a voltage domain, it calls this function to register it with the voltage layer. This mandates voltage layer to be initialized before the first omap_device_build has happened. I think that is going to be a very confusing sequencing. Also today voltage layer init happens later in the system. If we split into an early and late init, that would help here too. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures.
Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 03, 2010 5:12 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit Subject: Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures. Thara Gopinath th...@ti.com writes: This patch extends the device opp structure to contain pointers to scale the operating rate of the device and to retrieve the operating rate of the device. This patch also adds the three new APIs in the opp layer namely opp_set_rate that can be called to set a new operating rate for a device, opp_get_rate that can be called to retrieve the operating frequency for a device and opp_populate_rate_fns to populte the device specific set_rate and get_rate API's. The opp_set_rate and opp_get_rate does some routine error checks and finally calls into the device specific set_rate and get_rate APIs populated through opp_populate_rate_fns. Signed-off-by: Thara Gopinath th...@ti.com As I think about this more, I'm not sure the OPP layer is the right layer for the get/set rate functions. The OPP layer is currently just the data store for OPP data. To me, these set/get functions are better associated directly with an omap_device instead of an OPP. For instance, the new OPP APIs are a bit confusing in terms of OPPs. e.g: opp_get_rate(). What is the rate of an OPP, and what's the difference with opp_get_freq()? What's really happening is the rate is being changed for a device, and the need for specific hooks are at the device level, not the OPP level. For example, this current approach would not scale if you needed multiple devices in the same domain that each needed custom set_rate/get_rate hooks. So instead, what about adding custom hooks at the omap_device level? They could be registered at omap_device_build() time in the device specific code. This is exactly what I had in my mind when I started implementing this. But then Paul said hwmod or omap_device is not the place to keep it. IIRC, Paul's concern was that *hwmod* was not the right place for this (and I agree.) However, I think omap_device is the right place for this. Paul? Also I do not want the set rate get rate APIs for devices that require changes dividers in the PRCM clock module to be spread out in the system. Makes it very very difficult to debug. If we agree to add the set_rate and get_rate in the omap_device structure, I would like to have one more API in the omap_device layer to register these APIs device wise. Thus we can keep these set rate and get rate APIs in one single file. Agreed. And those functions should be in the respective device-specific file, where the omap_device_build() etc are done for that device. Also if we move these hooks to omap_device struct we will need to rename the current omap_device_set_rate (the main API) to omap_device_scale and introduce a new omap_device_set_rate which just finds out the omap device from the passed dev pointer and does a od-set_rate. Similarly for get rate also. Yes, that's what I was thinking. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Kevin Hilman had written, on 09/16/2010 10:08 AM, the following: [..] more than that you name some functions omap_*, and how hard would it be to put it under arch/arm/common/*.c arch/arm/include/asm/*.h Possible even higher up in the directory hiearchy in include/linux/opp.h for the header and drivers/opp/*.c, because I think SuperH and power are not that different in this respect. Yeah, I guess this isn't ARM specific either, so should be at a higher level. Nishanth, can take my hack below and continue this evolution? As I demonstrate with this hack, this won't really change anything for us. thanks.. The only contention ahead is: where do we want this? Is drivers/opp/opp_core.c the right place? Given that this is just a support library and not really a driver? for some reason lib/opp.c does'nt sound just right either :( [..] -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Nishanth Menon n...@ti.com writes: Kevin Hilman had written, on 09/16/2010 10:08 AM, the following: [..] more than that you name some functions omap_*, and how hard would it be to put it under arch/arm/common/*.c arch/arm/include/asm/*.h Possible even higher up in the directory hiearchy in include/linux/opp.h for the header and drivers/opp/*.c, because I think SuperH and power are not that different in this respect. Yeah, I guess this isn't ARM specific either, so should be at a higher level. Nishanth, can take my hack below and continue this evolution? As I demonstrate with this hack, this won't really change anything for us. thanks.. The only contention ahead is: where do we want this? Is drivers/opp/opp_core.c the right place? Given that this is just a support library and not really a driver? for some reason lib/opp.c does'nt sound just right either :( Well, since it's not really a driver, I don't think drivers/* is appropriate. lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Handle __flush_icache_all for CONFIG_SMP_ON_UP
On Tue, 2010-09-14 at 11:59 -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100906 03:36]: Here's my latest patch (which is combined from two patches.) I think that patch is now done assuming the fixes I've posted are merged, so here's my S-O-B for the bits I've contributed: Signed-off-by: Tony Lindgren t...@atomide.com Anybody else care to ack? Acked-by: Catalin Marinas catalin.mari...@arm.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
2010/9/16 Kevin Hilman khil...@deeprootsystems.com: lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. I second this. I would love to see the generic OPP stuff in lib/opp/* so we put it in the right place from the beginning and don't have to painfully refactor everything later (clk.h especially comes to mind.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Linus Walleij had written, on 09/16/2010 12:07 PM, the following: 2010/9/16 Kevin Hilman khil...@deeprootsystems.com: lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. I second this. I would love to see the generic OPP stuff in lib/opp/* so we put it in the right place from the beginning and don't have to painfully refactor everything later (clk.h especially comes to mind.) cool.. digging a bit deeper into lib directory, I propose the following: lib/opp.c include/linux/opp.h any soc specific data (for registration etc) - goes to arch/arch/mach-soc/oppdata_xyz.c or what ever they choose the intent being lib/ is no place to put mach or arch specific data definitions.. it is just noise.. if folks are ok with this, will post a new rev soonish.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, September 16, 2010 10:40 PM To: Linus Walleij Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs Linus Walleij had written, on 09/16/2010 12:07 PM, the following: 2010/9/16 Kevin Hilman khil...@deeprootsystems.com: lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. I second this. I would love to see the generic OPP stuff in lib/opp/* so we put it in the right place from the beginning and don't have to painfully refactor everything later (clk.h especially comes to mind.) cool.. digging a bit deeper into lib directory, I propose the following: lib/opp.c include/linux/opp.h any soc specific data (for registration etc) - goes to arch/arch/mach-soc/oppdata_xyz.c or what ever they choose the intent being lib/ is no place to put mach or arch specific data definitions.. it is just noise.. if folks are ok with this, will post a new rev soonish.. If you like may be you can take this thread over lkml just to get more wider perspective -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/7] omap: zoom: add fixed regulator device for wlan
* Ohad Ben-Cohen o...@wizery.com [100915 16:23]:
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
snip
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = vwl1271,
+ .microvolts = 180, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = zoom_vmmc3,
+};
These are usually aligned with tabs before the = sign.
+static struct platform_device omap_vwlan_device = {
+ .name = reg-fixed-voltage,
+ .id = 1,
+ .dev = {
+ .platform_data = zoom_vwlan,
+ },
+};
Like in this struct.
After that's fixed, here's my ack for these to go via the
wireless tree:
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/7] omap: zoom: add mmc3/wl1271 device support
* Ohad Ben-Cohen o...@wizery.com [100915 16:23]: Add MMC3 support on ZOOM, which has the wl1271 device hardwired to. The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ line, and power-controlled by a GPIO-based fixed regulator. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] overo twl4030: fix twl4030 IRQ (used for usb otg detection)
On Thu, Sep 16, 2010 at 10:40 AM, Tony Lindgren t...@atomide.com wrote: * Steve Sakoman sako...@gmail.com [100916 05:48]: Agreed. Gumstix doesn't provide an easy way of determining the layout revision via software (the boards are marked with the rev number, but that doesn't do much good!). Unless you use the camera interface during early init to detect that revision printed on the circuit board ;) That was my first idea too :-) I'm investigating methods to figure this out, but haven't yet found anything reliable. When I do I'll post a patch. How about add something to u-boot that allows setenv system_rev in u-boot? Maybe it already has this feature as system_rev is arm-linux generic atag. The hard part is creating the code to figure out how the board is wired :-) I have some promising approaches, but nothing working yet. Once that is done the rest is easy! Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
* Igor Grinberg grinb...@compulab.co.il [100916 02:04]: Hi, On 09/16/10 11:00, Felipe Balbi wrote: Hi, On Thu, Sep 16, 2010 at 03:54:39AM -0500, Igor Grinberg wrote: put a description here. This is a relatively small patch, is the subject not descriptive enough? In that case just copy the subject (without the [PATCH] part) to the description for all of your patches. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] omap3: Introduce CompuLab CM-T3517 module.
* Igor Grinberg grinb...@compulab.co.il [100916 01:46]: Add basic suppot, enable uart and led. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- arch/arm/mach-omap2/Kconfig |7 ++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-cm-t3517.c | 109 ++ 3 files changed, 117 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c Looks like you're missing the debug uart entry for arch/arm/plat-omap/include/plat/uncompress.h? You can test this by enabling DEBUG_LL and EARLY_PRINTK in your .config, then pass earlyprintk in the kernel cmdline. Might become handy for debugging the early init process for your board. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Shilimkar, Santosh santosh.shilim...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, September 16, 2010 10:40 PM To: Linus Walleij Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs Linus Walleij had written, on 09/16/2010 12:07 PM, the following: 2010/9/16 Kevin Hilman khil...@deeprootsystems.com: lib/opp/* seems more appropriate to me with the header at include/linux/opp.h as Linus suggested. I second this. I would love to see the generic OPP stuff in lib/opp/* so we put it in the right place from the beginning and don't have to painfully refactor everything later (clk.h especially comes to mind.) cool.. digging a bit deeper into lib directory, I propose the following: lib/opp.c include/linux/opp.h any soc specific data (for registration etc) - goes to arch/arch/mach-soc/oppdata_xyz.c or what ever they choose the intent being lib/ is no place to put mach or arch specific data definitions.. it is just noise.. if folks are ok with this, will post a new rev soonish.. If you like may be you can take this thread over lkml just to get more wider perspective I propose Nishanth does the slight rework to move this to lib/ and then post to l-o, l-a-k and lkml for RFC. Note that only the generic parts should be posted first, the OMAP specific usage of this can be fixed after the generic parts are accepted. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 01/17] wl12xx: make wl12xx.h common to both spi and sdio
On Thu, 2010-09-16 at 13:16 +0200, ext Ohad Ben-Cohen wrote: Move wl12xx.h outside of the spi-specific location, so it can be shared with both spi and sdio solutions. Update all users of spi/wl12xx.h accordingly Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- Acked-by: Luciano Coelho luciano.coe...@nokia.com I just wonder why the wl12xx.h move wasn't detected as a rename. Did you forget to use the -M option in format-patch? -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
* Gadiyar, Anand gadi...@ti.com [100915 21:51]: About two months of it is my fault, since it was posted to l-o on July 21. But all the time between 12 March and 21 July is up to TI to answer. This really could have been a useful patch for certain vendors to have that are using CORE DVFS on their currently-shipping OMAP3 devices. Sure, and I'm certain those other vendors have an equal number of critical bug fixes sitting in their own trees, which they steadfastly refuse to share with other competing vendors until their own products are out. (I have specific examples in mind, but don't want to start another flame war). Grow up - when a bug is discovered in the field, people are not likely to share with others in the interest of their own product timelines. While this may overall be less beneficial for everyone, that is indeed how many think and work. I don't buy this. But maybe some of TI's customers can comment on this? AFAIK everybody wants to avoid the duplicate effort of finding and fixing these bugs. TI is the only party who is even aware of all the bugs fixed in various places. And it's TI who should follow up that the bugfixes get posted in a timely manner. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] OMAP: mach-omap2: Fix miscellaneous sparse warnings
* G, Manjunath Kondaiah manj...@ti.com [100826 13:50]:
From: Manjunatha GK manj...@ti.com
This patch fixes miscellaneous sparse warnings in mach-omap2.
arch/arm/mach-omap2/board-am3517evm.c:141:17: warning: Initializer entry
defined twice
arch/arm/mach-omap2/board-am3517evm.c:142:18: also defined here
arch/arm/mach-omap2/irq.c:50:35: warning: Using plain integer as NULL pointer
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c |1 -
arch/arm/mach-omap2/irq.c |2 +-
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index ae22ea8..b091741 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -139,7 +139,6 @@ static void am3517_evm_ethernet_init(struct
emac_platform_data *pdata)
static struct i2c_board_info __initdata am3517evm_i2c1_boardinfo[] = {
{
I2C_BOARD_INFO(s35390a, 0x30),
- .type = s35390a,
},
};
OK, I2C_BOARD_INFO sets it too.
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 26aeef5..02fd942 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -47,7 +47,7 @@ static struct omap_irq_bank {
} __attribute__ ((aligned(4))) irq_banks[] = {
{
/* MPU INTC */
- .base_reg = 0,
+ .base_reg = (void __iomem *)0,
.nr_irqs= 96,
},
};
The base_reg line you can remove, the static data area gets zeroed
during init.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP2/TWL: Fix Sparse warnings
* G, Manjunath Kondaiah manj...@ti.com [100826 13:50]: This patch series fixes sparse warnings for OMAP and TWL code. For better readabilty the patches are categorised based on type of sparse warnigns. The sparse warning logs are embedded with each patch followed by fix. Build and boot tested on omap3 with omap3_defconfig. Manjunatha GK (11): OMAP: mach-omap2: Fix incorrect assignment warnings OMAP: mach-omap2: Fix static declaration warnings OMAP: mach-omap2: Fix static function warnings OMAP: mach-omap2: Fix miscellaneous sparse warnings OMAP: plat-omap: Fix static function warnings OMAP: McBSP: Fix static function warning OMAP: HSMMC: Fix unused variable warning OMAP: NAND: Fix static declaration warning TWL CORE: Fix sparse warning TWL IRQ: Fix fucntion declaration warnings TWL4030: Codec: Fix fucntion declaration error Looks like these are almost ready to go. Please repost against v2.6.36-rc4 with linux-arm-kernel list Cc'd. Also check that the related driver list is Cc'd. Then, assuming no more comments, can you set up a git branch somewhere for me to pull? For more info, see Merging patches using git at: http://www.elinux.org/OMAP_patch_merging_process#Patch_submission_checklist Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/7] wl1271: propagate set_power's return value
On Thu, 2010-09-16 at 01:22 +0200, ext Ohad Ben-Cohen wrote:
Make it possible for the set power method to indicate a
success/failure return value. This is needed to support
more complex power on/off operations such as SDIO
power manipulations.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Some comments below.
diff --git a/drivers/net/wireless/wl12xx/wl1271_io.h
b/drivers/net/wireless/wl12xx/wl1271_io.h
index bc806c7..c1f92e6 100644
--- a/drivers/net/wireless/wl12xx/wl1271_io.h
+++ b/drivers/net/wireless/wl12xx/wl1271_io.h
@@ -144,10 +144,13 @@ static inline void wl1271_power_off(struct wl1271 *wl)
clear_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
}
-static inline void wl1271_power_on(struct wl1271 *wl)
+static inline int wl1271_power_on(struct wl1271 *wl)
{
- wl-if_ops-power(wl, true);
- set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+ int ret = wl-if_ops-power(wl, true);
I think it look nicer if you keep the int ret in one line by itself
and then do a ret = wl-if_ops... on another one.
+ if (ret == 0)
+ set_bit(WL1271_FLAG_GPIO_POWER, wl-flags);
+
+ return ret;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index b5d9565..1d5dc72 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -159,35 +159,38 @@ static void wl1271_sdio_raw_write(struct wl1271 *wl,
int addr, void *buf,
wl1271_error(sdio write failed (%d), ret);
}
-static void wl1271_sdio_power_on(struct wl1271 *wl)
+static int wl1271_sdio_power_on(struct wl1271 *wl)
{
struct sdio_func *func = wl_to_func(wl);
sdio_claim_host(func);
sdio_enable_func(func);
sdio_release_host(func);
+
+ return 0;
}
You seem to always return 0, so the whole chain to pass the value up
seems unnecessary. Is this just a preparation for a future patch?
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/7] omap: zoom: add fixed regulator device for wlan
On Thu, Sep 16, 2010 at 7:44 PM, Tony Lindgren t...@atomide.com wrote: These are usually aligned with tabs before the = sign. Fixed. Acked-by: Tony Lindgren t...@atomide.com Thanks, Tony. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/7] wl1271: propagate set_power's return value
On Thu, Sep 16, 2010 at 9:40 PM, Luciano Coelho
luciano.coe...@nokia.com wrote:
+ int ret = wl-if_ops-power(wl, true);
I think it look nicer if you keep the int ret in one line by itself
and then do a ret = wl-if_ops... on another one.
Fixed.
+static int wl1271_sdio_power_on(struct wl1271 *wl)
{
struct sdio_func *func = wl_to_func(wl);
sdio_claim_host(func);
sdio_enable_func(func);
sdio_release_host(func);
+
+ return 0;
}
You seem to always return 0, so the whole chain to pass the value up
seems unnecessary. Is this just a preparation for a future patch?
Yes, it's soon going to be:
static int wl1271_sdio_power_on(struct wl1271 *wl)
{
struct sdio_func *func = wl_to_func(wl);
int ret;
ret = pm_runtime_get_sync(func-dev);
if (ret)
goto out;
sdio_claim_host(func);
sdio_enable_func(func);
sdio_release_host(func);
out:
return ret;
}
Thanks,
Ohad.
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 01/17] wl12xx: make wl12xx.h common to both spi and sdio
On Thu, Sep 16, 2010 at 8:35 PM, Luciano Coelho luciano.coe...@nokia.com wrote: Acked-by: Luciano Coelho luciano.coe...@nokia.com I just wonder why the wl12xx.h move wasn't detected as a rename. Did you forget to use the -M option in format-patch? I thought it's because I stripped the SPI_ from the #ifndef _LINUX_SPI_WL12XX_H, but it should be smarter than that. Probably the -M. Thanks, Ohad. -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/7] wl1271: propagate set_power's return value
On Thu, 2010-09-16 at 21:53 +0200, ext Ohad Ben-Cohen wrote:
On Thu, Sep 16, 2010 at 9:40 PM, Luciano Coelho
luciano.coe...@nokia.com wrote:
+ int ret = wl-if_ops-power(wl, true);
I think it look nicer if you keep the int ret in one line by itself
and then do a ret = wl-if_ops... on another one.
Fixed.
+static int wl1271_sdio_power_on(struct wl1271 *wl)
{
struct sdio_func *func = wl_to_func(wl);
sdio_claim_host(func);
sdio_enable_func(func);
sdio_release_host(func);
+
+ return 0;
}
You seem to always return 0, so the whole chain to pass the value up
seems unnecessary. Is this just a preparation for a future patch?
Yes, it's soon going to be:
static int wl1271_sdio_power_on(struct wl1271 *wl)
{
struct sdio_func *func = wl_to_func(wl);
int ret;
ret = pm_runtime_get_sync(func-dev);
if (ret)
goto out;
sdio_claim_host(func);
sdio_enable_func(func);
sdio_release_host(func);
out:
return ret;
}
Ok, that was the only explanation I could think of ;)
Acked-by: Luciano Coelho luciano.coe...@nokia.com
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
