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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
2010/9/16 Felipe Balbi : >> 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
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: [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
> -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] 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 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 --- 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, r
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 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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx
On Thu, Sep 16, 2010 at 11:35 AM, Felipe Balbi 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: [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 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
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 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: [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Thursday, September 16, 2010 5:52 AM > To: Shilimkar, Santosh > Cc: linux-arm-ker...@lists.infradead.org; t...@linutronix.de; > catalin.mari...@arm.com; linux-omap@vger.kernel.org > Subject: Re: [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable > > * Santosh Shilimkar [100907 00:50]: > > The machine_kexec() calls outer_disable which can crash on OMAP4 > > becasue of trustzone restrictions. > > > > This patch overrides the default l2x0_disable with a OMAP4 > > specific implementation taking care of trustzone > > > > > @@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void) > > > > */ > > l2x0_init(l2cache_base, 0x0e05, 0xcfff); > > > > + /* > > +* Override default outer_cache.disable with a OMAP4 > > +* specific one > > + */ > > + outer_cache.disable = omap4_l2x0_disable; > > + > > return 0; > > } > > early_initcall(omap_l2_cache_init); > > Just to be sure.. No outer_cache functions get set unless > l2x0_init gets called, right? So omap2 and omap3 functions > always stay NULL with omap3_defconfig? > Yes. -- 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: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Paul, > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, September 16, 2010 3:05 AM > To: Reddy, Teerth > Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath > Subject: RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall > in > SDRC after a Warm-reset > > Teerth, Vishwa, > > On Tue, 25 May 2010, Reddy, Teerth wrote: > > > > -Original Message- > > > From: Paul Walmsley [mailto:p...@pwsan.com] > > > Sent: Wednesday, May 19, 2010 6:03 AM > > > To: Reddy, Teerth > > > Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath > > > Subject: Re: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR > > > stall in SDRC after a Warm-reset > > > > > > On Fri, 23 Apr 2010, Reddy, Teerth wrote: > > > > > > > From: Teerth Reddy > > > > > > > > This patch has the workaround for errata 1.176. > > What's the current status of this patch? Still waiting for an updated > version. We have realized that this errata is not applicable if reset is triggered via dpll3 reset. The rootcasuse of the issues was that incase of warm reset, SDRC is not sensitive to the warm reset, but the interconect is reset on the fly, thus causing a misalignment between SDRC logic, interconect logic and DDR memory state. Hence the workaround was proposed. However, incase of dpll3 reset, sdrc also gets reset. In omap_prcm_arch_reset, system reset is triggered via dpll3 reset, so this WA is not applicable. Regards Vishwa > > > - Paul -- 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/2] Makefile and Kconfig changes for twl4030-madc driver
Makefile amd Kconfig Changes for twl4030-madc driver inclusion. Signed-off-by: Keerthy --- 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
[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
---
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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+
+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++) {
+ if (channels & (1imr, val);
+}
+
+static void twl4030_madc_disable_irq(struct twl4030_madc_data *madc, int id)
+{
+ u8 val;
+
+ val = twl4030
[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
Re: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
On Thu, Sep 16, 2010 at 4:40 AM, Paul Walmsley wrote: > On Wed, 15 Sep 2010, Tony Lindgren wrote: > >> * Paul Walmsley [100915 12:07]: >> > > >> > > This change has been commited to both TI's android 2.6.29 and 2.6.32 >> > > kernels. >> > > The commits can be viewed here: >> > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d >> > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940 >> > > >> > > This patch has been rebased on the latest linux-omap tree and tested on >> > > Kevin Hilman's pm branch. >> >> Sounds like a very important fix. But also a good example of how >> messed up things are with the TI Linux kernel development. >> >> Why has this fix it been sitting in some TI internal tree since >> Fri, 12 Mar 2010? > Er, the Mar 12 commit date is misleading - it's likely a customer-internal tree. It was committed to a TI internal tree 29 June/15 July, and sent to the list within a week of the second revision. The people who discovered this are on customer support - we spend a significant amount of time solving bugs like these, but have very little gap before the next big one strikes. We work tight production schedules, getting products out and only just have enough time to inform internal teams, but not enough to check if these fixes apply to internal trees (mainline is far far away) and get them there. (FWIW, Jon's been responsible for discovering and fixing more bugs on OMAP than almost anyone else I know.) For this specific patch, I'm not sure if other TI PM teams even knew about the existence of this patch until end-June. > 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. > >> This same bug has been patched in three different trees? But not in >> the mainline kernel? >> >> And this is happening all the time with the TI fixes. > > Yeah. OMAP4 has been demonstrably different - almost every single patch reaches mainline almost as soon as it is discovered. We had new silicon woken up with near-mainline code, and new boards supported in mainline even before the number of boards were in the mid-double digits. We're working very hard to keep things this way - give us a break. Stop inciting flame wars. A little support and understanding on your part would go a long way. - 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: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Hi, > -Original Message- > From: Balbi, Felipe > Sent: Wednesday, September 15, 2010 12:41 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 Tue, Sep 14, 2010 at 09:11:26AM -0500, G, Manjunath Kondaiah wrote: > >There are several places in kernel code (ex: > >tools/perf/util/include/linux/bitops.h:static __always_inline int > >test_bit(unsigned int nr, const unsigned long *addr)) which > are using > >__always_inline attribute to make sure functions are inlined. > > those are special cases. Generally, compiler is much better > than humans for choosing what should be inlined or not. > > >Ok, Agreed. We can have inline functions and expanding all > macros in > >mach-omap dma driver code. > >However, there is common dma driver(in plat-omap) which has code for > >both omap1 and omap2plus which uses this macro. > > well, that can be patched, right ? 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. -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: OMAP3 DSP MMU fault + off mode issue
On Thu, Sep 16, 2010 at 7:34 AM, Felipe Contreras wrote: > On Wed, Sep 15, 2010 at 7:03 PM, venki kaps wrote: >> In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging >> enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE. > > Indeed, I added that configuration in order to avoid that possibly > troublesome code in a production system. I haven't seen it working > properly yet. Thanks for the information. Even I have not used that configuration but in production system, We could avoid the DSP task information to be printed by the MPU dspbridge when DSP MMU fault ocurrs. Venkii, -- 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/6] omap4: l2x0: Override the default l2x0_disable
* Santosh Shilimkar [100907 00:50]: > The machine_kexec() calls outer_disable which can crash on OMAP4 > becasue of trustzone restrictions. > > This patch overrides the default l2x0_disable with a OMAP4 > specific implementation taking care of trustzone > @@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void) > >*/ > l2x0_init(l2cache_base, 0x0e05, 0xcfff); > > + /* > + * Override default outer_cache.disable with a OMAP4 > + * specific one > + */ > + outer_cache.disable = omap4_l2x0_disable; > + > return 0; > } > early_initcall(omap_l2_cache_init); Just to be sure.. No outer_cache functions get set unless l2x0_init gets called, right? So omap2 and omap3 functions always stay NULL with omap3_defconfig? 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
[PATCH v2 2/2] OMAP1: PM: add simple runtime PM layer to manage clocks
On OMAP1, we do not have omap_device + omap_hwmod to manage the
device-specific idle, enable and shutdown. Instead, just
enable/disable device clocks automatically at the runtime PM level.
This allows drivers to not have any OMAP1 specific clock management
and allows them to simply use the runtime PM API to manage clocks.
OMAP1 compile fixes Manjunatha GK
Cc: Manjunatha GK
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/pm_bus.c | 98 ++
2 files changed, 99 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap1/pm_bus.c
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index facfaeb..9a304d8 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_OMAP_MPU_TIMER) += time.o
obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
# Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o
+obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
# DSP
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
new file mode 100644
index 000..8b66392
--- /dev/null
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -0,0 +1,98 @@
+/*
+ * Runtime PM support code for OMAP1
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_PM_RUNTIME
+static int omap1_pm_runtime_suspend(struct device *dev)
+{
+ struct clk *iclk, *fclk;
+ int ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ fclk = clk_get(dev, "fck");
+ if (!IS_ERR(fclk)) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+
+ iclk = clk_get(dev, "ick");
+ if (!IS_ERR(iclk)) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+
+ return 0;
+};
+
+static int omap1_pm_runtime_resume(struct device *dev)
+{
+ int ret = 0;
+ struct clk *iclk, *fclk;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ iclk = clk_get(dev, "ick");
+ if (!IS_ERR(iclk)) {
+ clk_enable(iclk);
+ clk_put(iclk);
+ }
+
+ fclk = clk_get(dev, "fck");
+ if (!IS_ERR(fclk)) {
+ clk_enable(fclk);
+ clk_put(fclk);
+ }
+
+ return pm_generic_runtime_resume(dev);
+};
+
+static int __init omap1_pm_runtime_init(void)
+{
+ const struct dev_pm_ops *pm;
+ struct dev_pm_ops *omap_pm;
+
+ pm = platform_bus_get_pm_ops();
+ if (!pm) {
+ pr_err("%s: unable to get dev_pm_ops from platform_bus\n",
+ __func__);
+ return -ENODEV;
+ }
+
+ omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+ if (!omap_pm) {
+ pr_err("%s: unable to alloc memory for new dev_pm_ops\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ omap_pm->runtime_suspend = omap1_pm_runtime_suspend;
+ omap_pm->runtime_resume = omap1_pm_runtime_resume;
+
+ platform_bus_set_pm_ops(omap_pm);
+
+ return 0;
+}
+core_initcall(omap1_pm_runtime_init);
+#endif /* CONFIG_PM_RUNTIME */
--
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
[PATCH v2 1/2] OMAP2+: PM: initial runtime PM core support
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. OMAP specific runtime PM methods are registered with
the as custom methods on the platform_bus.
In order to determine if a device is an omap_device, its parent device
is checked. All omap_devices have a new 'omap_device_parent_ device
as their parent device, so checking for this parent is used to check
for valid omap_devices. If a device is an omap_device, then the
appropriate omap_device functions are called for it. If not, only the
generic runtime PM functions are called.
Device driver's ->runtime_idle() hook is called when the runtime PM
usecount reaches zero for that device. Driver's ->runtime_suspend()
hooks are called just before the device is disabled (via
omap_device_idle()), and device driver ->runtime_resume() hooks are
called just after device has been enabled (via omap_device_enable().)
OMAP4 build support from Rajendra Nayak .
OMAP2 build support from Charulatha V
Cc: Rajendra Nayak
Cc: Charulatha V
Acked-by: Grant Likely
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/Makefile | 10 +++-
arch/arm/mach-omap2/pm_bus.c | 85 ++
2 files changed, 92 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm_bus.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..b48ca60 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -49,14 +49,18 @@ obj-$(CONFIG_ARCH_OMAP2)+= sdrc2xxx.o
# Power Management
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
-obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
+obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
pm_bus.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+ifeq ($(CONFIG_PM_VERBOSE),y)
+CFLAGS_pm_bus.o+= -DDEBUG
+endif
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
new file mode 100644
index 000..784989f
--- /dev/null
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -0,0 +1,85 @@
+/*
+ * Runtime PM support code for OMAP
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#ifdef CONFIG_PM_RUNTIME
+int omap_pm_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ int r, ret = 0;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ ret = pm_generic_runtime_suspend(dev);
+
+ if (!ret && dev->parent == &omap_device_parent) {
+ r = omap_device_idle(pdev);
+ WARN_ON(r);
+ }
+
+ return ret;
+};
+
+int omap_pm_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ int r;
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ if (dev->parent == &omap_device_parent) {
+ r = omap_device_enable(pdev);
+ WARN_ON(r);
+ }
+
+ return pm_generic_runtime_resume(dev);
+};
+#else
+#define omap_pm_runtime_suspend NULL
+#define omap_pm_runtime_resume NULL
+#endif /* CONFIG_PM_RUNTIME */
+
+static int __init omap_pm_runtime_init(void)
+{
+ const struct dev_pm_ops *pm;
+ struct dev_pm_ops *omap_pm;
+
+ pm = platform_bus_get_pm_ops();
+ if (!pm) {
+ pr_err("%s: unable to get dev_pm_ops from platform_bus\n",
+ __func__);
+ return -ENODEV;
+ }
+
+ omap_pm = kmemdup(pm, sizeof(struct dev_pm_ops), GFP_KERNEL);
+ if (!omap_pm) {
+ pr_err("%s: unable to alloc memory for new dev_pm_ops\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ omap_pm->runtime_suspend = omap_pm_runtime_suspend;
+ omap_pm->runtime_resume = omap_pm_runtime_resume;
+
+ platform_bus_set_pm_ops(omap_pm);
+
+ return 0;
+}
+core_initcall(omap_pm_runtime_init);
--
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
[PATCH v2 0/2] OMAP: runtime PM core for 2.6.37
A minor re-spin of the runtime PM series, targetted for 2.6.37. - rebased to v2.6.36-rc4 - Acks from Grant added - update for name change of the omap_device parent device (c.f. https://patchwork.kernel.org/patch/180152/) Also available in my pm-runtime branch: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-runtime Kevin Hilman (2): OMAP2+: PM: initial runtime PM core support OMAP1: PM: add simple runtime PM layer to manage clocks arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/pm_bus.c | 98 ++ arch/arm/mach-omap2/Makefile | 10 +++- arch/arm/mach-omap2/pm_bus.c | 85 4 files changed, 191 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-omap1/pm_bus.c create mode 100644 arch/arm/mach-omap2/pm_bus.c -- 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
[PATCH] OMAP4: HSMMC cmd line reset change
OMAP4: HSMMC cmd line reset change
The cmd line reset logic is changed in OMAP4 ES2. The new procedure
is to monitor a 0->1 transition and then 1->0 transition.The earlier
logic would fail on ES2 chips because the loop could exit even before
the reset is actually complete.
Signed-off-by: Madhusudhan Chikkature
---
drivers/mmc/host/omap_hsmmc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4526d27..750ba7d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -976,12 +976,19 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
unsigned long bit)
{
unsigned long i = 0;
+ unsigned long j = 0;
unsigned long limit = (loops_per_jiffy *
msecs_to_jiffies(MMC_TIMEOUT_MS));
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base, SYSCTL) | bit);
+ if (cpu_is_omap44xx() && bit == SRC) {
+ while ((!(OMAP_HSMMC_READ(host->base, SYSCTL) & bit))
+ && (j++ < limit))
+ cpu_relax();
+ }
+
while ((OMAP_HSMMC_READ(host->base, SYSCTL) & bit) &&
(i++ < limit))
cpu_relax();
--
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 10/10] OMAP: omap_device: make all devices a child of a new parent device
In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new common parent
device.
Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.
Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.
In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform
Acked-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 12
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index bad4c3d..28e2d1a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -36,6 +36,8 @@
#include
+extern struct device omap_device_parent;
+
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN 0
#define OMAP_DEVICE_STATE_ENABLED 1
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7f05f49..8215b1b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -465,6 +465,7 @@ int omap_device_register(struct omap_device *od)
{
pr_debug("omap_device: %s: registering\n", od->pdev.name);
+ od->pdev.dev.parent = &omap_device_parent;
return platform_device_register(&od->pdev);
}
@@ -737,3 +738,14 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+struct device omap_device_parent = {
+ .init_name = "omap",
+ .parent = &platform_bus,
+};
+
+static int __init omap_device_init(void)
+{
+ return device_register(&omap_device_parent);
+}
+core_initcall(omap_device_init);
--
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
[PATCH 09/10] Revert "OMAP: omap_device: add omap_device_is_valid()"
This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206.
The dereference method of checking for a valid omap_device when
wrapping a platform_device is rather unsafe and dangerous.
Instead, a better way of checking for a valid omap-device is
to use a common parent device for all omap_devices, then a check
can simply be made using the device parent. The only user of this
API was the initial version of the runtime PM core for OMAP. This
has now been switched to check device parent, so there are no more
users of this API.
Acked-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |2 --
arch/arm/plat-omap/omap_device.c | 20
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 25cd9ac..bad4c3d 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -62,7 +62,6 @@
*
*/
struct omap_device {
- u32 magic;
struct platform_device pdev;
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
@@ -82,7 +81,6 @@ int omap_device_shutdown(struct platform_device *pdev);
/* Core code interface */
-bool omap_device_is_valid(struct omap_device *od);
int omap_device_count_resources(struct omap_device *od);
int omap_device_fill_resources(struct omap_device *od, struct resource *res);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..7f05f49 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -90,12 +90,6 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
-/*
- * OMAP_DEVICE_MAGIC: used to determine whether a struct omap_device
- * obtained via container_of() is in fact a struct omap_device
- */
-#define OMAP_DEVICE_MAGIC 0xf00dcafe
-
/* Private functions */
/**
@@ -414,8 +408,6 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
od->pm_lats = pm_lats;
od->pm_lats_cnt = pm_lats_cnt;
- od->magic = OMAP_DEVICE_MAGIC;
-
if (is_early_device)
ret = omap_early_device_register(od);
else
@@ -627,18 +619,6 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
}
/**
- * omap_device_is_valid - Check if pointer is a valid omap_device
- * @od: struct omap_device *
- *
- * Return whether struct omap_device pointer @od points to a valid
- * omap_device.
- */
-bool omap_device_is_valid(struct omap_device *od)
-{
- return (od && od->magic == OMAP_DEVICE_MAGIC);
-}
-
-/**
* omap_device_get_pwrdm - return the powerdomain * associated with @od
* @od: struct omap_device *
*
--
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
[PATCH 08/10] OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts
From: Paul Walmsley
When the clockdomain layer initializes, place all clockdomains into
software-supervised mode, and clear all wakeup and sleep dependencies
immediately, rather than waiting for the PM code to do this later.
This fixes a major bug where critical sleep dependencies added by the
hwmod code are cleared during late PM init.
As a side benefit, the _init_{wk,sleep}dep_usecount() functions are no
longer needed, so remove them.
Kevin Hilman did all the really hard work on
this, identifying the problem and finding the bug.
Signed-off-by: Paul Walmsley
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/clockdomain.c | 110 +
arch/arm/mach-omap2/pm34xx.c |3 -
2 files changed, 15 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 5d80cb8..6fb61b1 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -258,97 +258,6 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
*clkdm, int enable)
}
-/**
- * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
- * @clkdm: clockdomain to initialize wkdep usecounts
- *
- * Initialize the wakeup dependency usecount variables for clockdomain @clkdm.
- * If a wakeup dependency is present in the hardware, the usecount will be
- * set to 1; otherwise, it will be set to 0. Software should clear all
- * software wakeup dependencies prior to calling this function if it wishes
- * to ensure that all usecounts start at 0. No return value.
- */
-static void _init_wkdep_usecount(struct clockdomain *clkdm)
-{
- u32 v;
- struct clkdm_dep *cd;
-
- if (!clkdm->wkdep_srcs)
- return;
-
- for (cd = clkdm->wkdep_srcs; cd->clkdm_name; cd++) {
- if (!omap_chip_is(cd->omap_chip))
- continue;
-
- if (!cd->clkdm && cd->clkdm_name)
- cd->clkdm = _clkdm_lookup(cd->clkdm_name);
-
- if (!cd->clkdm) {
- WARN(!cd->clkdm, "clockdomain: %s: wkdep clkdm %s not "
-"found\n", clkdm->name, cd->clkdm_name);
- continue;
- }
-
- v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
- PM_WKDEP,
- (1 << cd->clkdm->dep_bit));
-
- if (v)
- pr_debug("clockdomain: %s: wakeup dependency already "
-"set to wake up when %s wakes\n",
-clkdm->name, cd->clkdm->name);
-
- atomic_set(&cd->wkdep_usecount, (v) ? 1 : 0);
- }
-}
-
-/**
- * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
- * @clkdm: clockdomain to initialize sleepdep usecounts
- *
- * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
- * If a sleep dependency is present in the hardware, the usecount will be
- * set to 1; otherwise, it will be set to 0. Software should clear all
- * software sleep dependencies prior to calling this function if it wishes
- * to ensure that all usecounts start at 0. No return value.
- */
-static void _init_sleepdep_usecount(struct clockdomain *clkdm)
-{
- u32 v;
- struct clkdm_dep *cd;
-
- if (!cpu_is_omap34xx())
- return;
-
- if (!clkdm->sleepdep_srcs)
- return;
-
- for (cd = clkdm->sleepdep_srcs; cd->clkdm_name; cd++) {
- if (!omap_chip_is(cd->omap_chip))
- continue;
-
- if (!cd->clkdm && cd->clkdm_name)
- cd->clkdm = _clkdm_lookup(cd->clkdm_name);
-
- if (!cd->clkdm) {
- WARN(!cd->clkdm, "clockdomain: %s: sleepdep clkdm %s "
-"not found\n", clkdm->name, cd->clkdm_name);
- continue;
- }
-
- v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
- OMAP3430_CM_SLEEPDEP,
- (1 << cd->clkdm->dep_bit));
-
- if (v)
- pr_debug("clockdomain: %s: sleep dependency already "
-"set to prevent from idling until %s "
-"idles\n", clkdm->name, cd->clkdm->name);
-
- atomic_set(&cd->sleepdep_usecount, (v) ? 1 : 0);
- }
-};
-
/* Public functions */
/**
@@ -379,12 +288,17 @@ void clkdm_init(struct clockdomain **clkdms,
_autodep_lookup(autodep);
/*
-* Ensure that the *dep_usecount registers reflect the current
-* state of the PRCM.
+* Put all clockdomains into software-supervised mode; PM code
+* should later enable hardware-supervised mode as appropriate
*/
[PATCH 06/10] omap: pm-debug: Enable wakeup_timer_milliseconds debugfs entry
From: Santosh Shilimkar
Commit 8e2efde9 added milliseconds suspend wakeup time support but
same interface is not exported through debugfs
This patch enables the debugfs hook for wakeup_timer_milliseconds
Signed-off-by: Santosh Shilimkar
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 655f9df..af00c17 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -638,6 +638,9 @@ static int __init pm_dbg_init(void)
&sleep_while_idle, &pm_dbg_option_fops);
(void) debugfs_create_file("wakeup_timer_seconds", S_IRUGO | S_IWUGO, d,
&wakeup_timer_seconds, &pm_dbg_option_fops);
+ (void) debugfs_create_file("wakeup_timer_milliseconds",
+ S_IRUGO | S_IWUGO, d, &wakeup_timer_milliseconds,
+ &pm_dbg_option_fops);
pm_dbg_init_done = 1;
return 0;
--
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
[PATCH 07/10] omap: pm: Move set_pwrdm_state routine to common pm.c
From: Santosh Shilimkar
The set_pwrdm_state() is needed on omap4 as well so move
this routine to common pm.c file so that it's available for omap3/4
Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm.c | 50 +++
arch/arm/mach-omap2/pm.h |2 +-
arch/arm/mach-omap2/pm34xx.c | 53 +++--
3 files changed, 55 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index c93921d..4477d5d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -18,6 +18,9 @@
#include
#include
+#include
+#include
+
static struct omap_device_pm_latency *pm_lats;
static struct device *mpu_dev;
@@ -83,6 +86,53 @@ static void omap2_init_processor_devices(void)
_init_omap_device("l3_main", &l3_dev);
}
+/*
+ * This sets pwrdm state (other than mpu & core. Currently only ON &
+ * RET are supported. Function is assuming that clkdm doesn't have
+ * hw_sup mode enabled.
+ */
+int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
+{
+ u32 cur_state;
+ int sleep_switch = 0;
+ int ret = 0;
+
+ if (pwrdm == NULL || IS_ERR(pwrdm))
+ return -EINVAL;
+
+ while (!(pwrdm->pwrsts & (1 << state))) {
+ if (state == PWRDM_POWER_OFF)
+ return ret;
+ state--;
+ }
+
+ cur_state = pwrdm_read_next_pwrst(pwrdm);
+ if (cur_state == state)
+ return ret;
+
+ if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
+ omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
+ sleep_switch = 1;
+ pwrdm_wait_transition(pwrdm);
+ }
+
+ ret = pwrdm_set_next_pwrst(pwrdm, state);
+ if (ret) {
+ printk(KERN_ERR "Unable to set state of powerdomain: %s\n",
+ pwrdm->name);
+ goto err;
+ }
+
+ if (sleep_switch) {
+ omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
+ pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
+ }
+
+err:
+ return ret;
+}
+
static int __init omap2_common_pm_init(void)
{
omap2_init_processor_devices();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4fd021f..0a1 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -20,7 +20,7 @@ extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
-extern int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
+extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
struct cpuidle_params {
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bc24fbd..f5f1dbd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -483,51 +483,6 @@ int omap3_can_sleep(void)
return 1;
}
-/* This sets pwrdm state (other than mpu & core. Currently only ON &
- * RET are supported. Function is assuming that clkdm doesn't have
- * hw_sup mode enabled. */
-int set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
-{
- u32 cur_state;
- int sleep_switch = 0;
- int ret = 0;
-
- if (pwrdm == NULL || IS_ERR(pwrdm))
- return -EINVAL;
-
- while (!(pwrdm->pwrsts & (1 << state))) {
- if (state == PWRDM_POWER_OFF)
- return ret;
- state--;
- }
-
- cur_state = pwrdm_read_next_pwrst(pwrdm);
- if (cur_state == state)
- return ret;
-
- if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
- omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
- sleep_switch = 1;
- pwrdm_wait_transition(pwrdm);
- }
-
- ret = pwrdm_set_next_pwrst(pwrdm, state);
- if (ret) {
- printk(KERN_ERR "Unable to set state of powerdomain: %s\n",
- pwrdm->name);
- goto err;
- }
-
- if (sleep_switch) {
- omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
- pwrdm_wait_transition(pwrdm);
- pwrdm_state_switch(pwrdm);
- }
-
-err:
- return ret;
-}
-
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -569,7 +524,7 @@ static int omap3_pm_suspend(void)
pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
/* Set ones wanted by suspend */
list_for_each_entry(pwrst, &pwrst_list, node) {
- if (set_pwrdm_state(pwrst->pwrdm, pwrst->next_state))
+ if (omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state))
goto restore;
if (pwrdm_clear_all_prev_pwrst(pwrst->pwrdm))
goto restore;
@@
[PATCH 05/10] omap: pm-debug: Move common debug code to pm-debug.c
From: Santosh Shilimkar
This patch moves omap2_pm_wakeup_on_timer() and pm debug entries
form pm34xx.c to pm-debug.c and export it, so that it is available
to other OMAPs
Signed-off-by: Santosh Shilimkar
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c | 18 ++
arch/arm/mach-omap2/pm.h |2 ++
arch/arm/mach-omap2/pm34xx.c | 18 --
3 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 056ff17..655f9df 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "prm.h"
#include "cm.h"
@@ -353,6 +354,23 @@ void pm_dbg_update_time(struct powerdomain *pwrdm, int
prev)
pwrdm->timer = t;
}
+void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
+{
+ u32 tick_rate, cycles;
+
+ if (!seconds && !milliseconds)
+ return;
+
+ tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
+ cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
+ omap_dm_timer_stop(gptimer_wakeup);
+ omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
+
+ pr_info("PM: Resume timer in %u.%03u secs"
+ " (%d ticks at %d ticks/sec.)\n",
+ seconds, milliseconds, cycles, tick_rate);
+}
+
static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
{
struct seq_file *s = (struct seq_file *)user;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 3de6ece..4fd021f 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -48,9 +48,11 @@ extern struct omap_dm_timer *gptimer_wakeup;
#ifdef CONFIG_PM_DEBUG
extern void omap2_pm_dump(int mode, int resume, unsigned int us);
+extern void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds);
extern int omap2_pm_debug;
#else
#define omap2_pm_dump(mode, resume, us)do {} while (0);
+#define omap2_pm_wakeup_on_timer(seconds, milliseconds)do {} while (0);
#define omap2_pm_debug 0
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bb2ba1e..bc24fbd 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
@@ -550,23 +549,6 @@ out:
#ifdef CONFIG_SUSPEND
static suspend_state_t suspend_state;
-static void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
-{
- u32 tick_rate, cycles;
-
- if (!seconds && !milliseconds)
- return;
-
- tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
- cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
- omap_dm_timer_stop(gptimer_wakeup);
- omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
-
- pr_info("PM: Resume timer in %u.%03u secs"
- " (%d ticks at %d ticks/sec.)\n",
- seconds, milliseconds, cycles, tick_rate);
-}
-
static int omap3_pm_prepare(void)
{
disable_hlt();
--
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
[PATCH 04/10] OMAP4: pm.c extensions for OMAP4 support
From: Thara Gopinath
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.
Signed-off-by: Thara Gopinath
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm.c | 20 +++-
arch/arm/plat-omap/include/plat/common.h |3 ++-
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..c93921d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -21,8 +21,9 @@
static struct omap_device_pm_latency *pm_lats;
static struct device *mpu_dev;
-static struct device *dsp_dev;
+static struct device *iva_dev;
static struct device *l3_dev;
+static struct device *dsp_dev;
struct device *omap2_get_mpuss_device(void)
{
@@ -30,10 +31,10 @@ struct device *omap2_get_mpuss_device(void)
return mpu_dev;
}
-struct device *omap2_get_dsp_device(void)
+struct device *omap2_get_iva_device(void)
{
- WARN_ON_ONCE(!dsp_dev);
- return dsp_dev;
+ WARN_ON_ONCE(!iva_dev);
+ return iva_dev;
}
struct device *omap2_get_l3_device(void)
@@ -42,6 +43,13 @@ struct device *omap2_get_l3_device(void)
return l3_dev;
}
+struct device *omap4_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+EXPORT_SYMBOL(omap4_get_dsp_device);
+
/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
static int _init_omap_device(char *name, struct device **new_dev)
{
@@ -69,7 +77,9 @@ static int _init_omap_device(char *name, struct device
**new_dev)
static void omap2_init_processor_devices(void)
{
_init_omap_device("mpu", &mpu_dev);
- _init_omap_device("iva", &dsp_dev);
+ _init_omap_device("iva", &iva_dev);
+ if (cpu_is_omap44xx())
+ _init_omap_device("dsp", &dsp_dev);
_init_omap_device("l3_main", &l3_dev);
}
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..c45dbb9 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -91,7 +91,8 @@ void omap3_map_io(void);
})
extern struct device *omap2_get_mpuss_device(void);
-extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
+extern struct device *omap4_get_dsp_device(void);
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
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
[PATCH 03/10] OMAP3: PM: move device-specific special cases from PM core into CPUidle
In an effort to simplify the core idle path, move any device-specific
special case handling from the core PM idle path into the CPUidle
pre-idle checking path.
This keeps the core, interrupts-disabled idle path streamlined and
independent of any device-specific handling, and also allows CPUidle
to do the checking only for certain C-states as needed. This patch
has the device checks in place for all states with the CHECK_BM flag,
namely all states >= C2.
This patch was inspired by a similar patch written by Tero Kristo as
part of a larger series to add INACTIVE state support.
Cc: Tero Kristo
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/cpuidle34xx.c | 50 ++--
arch/arm/mach-omap2/pm34xx.c | 14 +-
2 files changed, 48 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3d3d035..0923b82 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -60,7 +60,8 @@ struct omap3_processor_cx {
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
-struct powerdomain *mpu_pd, *core_pd;
+struct powerdomain *mpu_pd, *core_pd, *per_pd;
+struct powerdomain *cam_pd;
/*
* The latencies/thresholds for various C states have
@@ -233,14 +234,54 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
+ u32 core_next_state, per_next_state = 0, per_saved_state = 0;
+ u32 cam_state;
+ struct omap3_processor_cx *cx;
+ int ret;
if ((state->flags & CPUIDLE_FLAG_CHECK_BM) && omap3_idle_bm_check()) {
BUG_ON(!dev->safe_state);
new_state = dev->safe_state;
+ goto select_state;
+ }
+
+ cx = cpuidle_get_statedata(state);
+ core_next_state = cx->core_state;
+
+ /*
+* Prevent idle completely if CAM is active.
+* CAM does not have wakeup capability in OMAP3.
+*/
+ cam_state = pwrdm_read_pwrst(cam_pd);
+ if (cam_state == PWRDM_POWER_ON) {
+ new_state = dev->safe_state;
+ goto select_state;
}
+ /*
+* Prevent PER off if CORE is not in retention or off as this
+* would disable PER wakeups completely.
+*/
+ per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
+ if ((per_next_state == PWRDM_POWER_OFF) &&
+ (core_next_state > PWRDM_POWER_RET)) {
+ per_next_state = PWRDM_POWER_RET;
+ pwrdm_set_next_pwrst(per_pd, per_next_state);
+ }
+
+ /* Are we changing PER target state? */
+ if (per_next_state != per_saved_state)
+ pwrdm_set_next_pwrst(per_pd, per_next_state);
+
+select_state:
dev->last_state = new_state;
- return omap3_enter_idle(dev, new_state);
+ ret = omap3_enter_idle(dev, new_state);
+
+ /* Restore original PER state if it was modified */
+ if (per_next_state != per_saved_state)
+ pwrdm_set_next_pwrst(per_pd, per_saved_state);
+
+ return ret;
}
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
@@ -328,7 +369,8 @@ void omap_init_power_states(void)
cpuidle_params_table[OMAP3_STATE_C2].threshold;
omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
- omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
+ omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID |
+ CPUIDLE_FLAG_CHECK_BM;
/* C3 . MPU CSWR + Core inactive */
omap3_power_states[OMAP3_STATE_C3].valid =
@@ -426,6 +468,8 @@ int __init omap3_idle_init(void)
mpu_pd = pwrdm_lookup("mpu_pwrdm");
core_pd = pwrdm_lookup("core_pwrdm");
+ per_pd = pwrdm_lookup("per_pwrdm");
+ cam_pd = pwrdm_lookup("cam_pwrdm");
omap_init_power_states();
cpuidle_register_driver(&omap3_idle_driver);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 429268e..bb2ba1e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,7 +346,6 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- int per_state_modified = 0;
if (!_omap_sram_idle)
return;
@@ -391,19 +390,10 @@ void omap_sram_idle(void)
if (per_next_state < PWRDM_POWER_ON) {
omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
- if (per_next_state == PWRDM_POWER_OFF) {
- if (core_next_state == PWRDM_POWER_ON) {
-
[PATCH 02/10] OMAP: PM debugfs removing OMAP3 hardcodings.
From: Thara Gopinath
This patch removes omap3 hardcodings from pm-debug.c
so that enabling PM debugfs support does break compilation
for other OMAP's. This is a preparatory patch for supporting
OMAP4 pm entries through PM debugfs.
Signed-off-by: Thara Gopinath
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c | 21 -
arch/arm/mach-omap2/pm34xx.c |5 -
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 723b44e..056ff17 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -37,6 +37,10 @@
#include "pm.h"
int omap2_pm_debug;
+u32 enable_off_mode;
+u32 sleep_while_idle;
+u32 wakeup_timer_seconds;
+u32 wakeup_timer_milliseconds;
#define DUMP_PRM_MOD_REG(mod, reg)\
regs[reg_count].name = #mod "." #reg; \
@@ -494,8 +498,10 @@ int pm_dbg_regset_init(int reg_set)
static int pwrdm_suspend_get(void *data, u64 *val)
{
- int ret;
- ret = omap3_pm_get_suspend_state((struct powerdomain *)data);
+ int ret = -EINVAL;
+
+ if (cpu_is_omap34xx())
+ ret = omap3_pm_get_suspend_state((struct powerdomain *)data);
*val = ret;
if (ret >= 0)
@@ -505,7 +511,10 @@ static int pwrdm_suspend_get(void *data, u64 *val)
static int pwrdm_suspend_set(void *data, u64 val)
{
- return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
+ if (cpu_is_omap34xx())
+ return omap3_pm_set_suspend_state(
+ (struct powerdomain *)data, (int)val);
+ return -EINVAL;
}
DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
@@ -553,8 +562,10 @@ static int option_set(void *data, u64 val)
*option = val;
- if (option == &enable_off_mode)
- omap3_pm_off_mode_enable(val);
+ if (option == &enable_off_mode) {
+ if (cpu_is_omap34xx())
+ omap3_pm_off_mode_enable(val);
+ }
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b5e5bcb..429268e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -55,11 +55,6 @@
#define OMAP343X_TABLE_VALUE_OFFSET 0x30
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32
-u32 enable_off_mode;
-u32 sleep_while_idle;
-u32 wakeup_timer_seconds;
-u32 wakeup_timer_milliseconds;
-
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
--
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
[PATCH 01/10] OMAP3: PM: whitespace cleanup around IO wakeup enable
Cleanup indentation around IO wakeup enable, the '\' terminator is
not required in C when wrapping an expression past end-of-line.
Whitespace change only.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7b03426..b5e5bcb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -385,9 +385,9 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (omap3_has_io_wakeup() && \
- (per_next_state < PWRDM_POWER_ON ||
- core_next_state < PWRDM_POWER_ON)) {
+ if (omap3_has_io_wakeup() &&
+ (per_next_state < PWRDM_POWER_ON ||
+core_next_state < PWRDM_POWER_ON)) {
prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
--
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
[PATCH 00/10] OMAP: misc PM queue for 2.6.37
Various OMAP PM related updates targetted for 2.6.37. Also available in my pm-next branch: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-next Kevin Hilman (4): OMAP3: PM: whitespace cleanup around IO wakeup enable OMAP3: PM: move device-specific special cases from PM core into CPUidle Revert "OMAP: omap_device: add omap_device_is_valid()" OMAP: omap_device: make all devices a child of a new parent device Paul Walmsley (1): OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts Santosh Shilimkar (3): omap: pm-debug: Move common debug code to pm-debug.c omap: pm-debug: Enable wakeup_timer_milliseconds debugfs entry omap: pm: Move set_pwrdm_state routine to common pm.c Thara Gopinath (2): OMAP: PM debugfs removing OMAP3 hardcodings. OMAP4: pm.c extensions for OMAP4 support arch/arm/mach-omap2/clockdomain.c | 110 - arch/arm/mach-omap2/cpuidle34xx.c | 50 +++- arch/arm/mach-omap2/pm-debug.c| 42 - arch/arm/mach-omap2/pm.c | 70 +++- arch/arm/mach-omap2/pm.h |4 +- arch/arm/mach-omap2/pm34xx.c | 99 ++ arch/arm/plat-omap/include/plat/common.h |3 +- arch/arm/plat-omap/include/plat/omap_device.h |4 +- arch/arm/plat-omap/omap_device.c | 32 +++- 9 files changed, 191 insertions(+), 223 deletions(-) -- 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
[PATCH v6 7/7] omap: zoom: add mmc3/wl1271 device support
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.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index de88635..5b3b711 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,6 +30,7 @@
#include "hsmmc.h"
#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -185,6 +187,12 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = "external",
@@ -202,6 +210,14 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+ {
+ .name = "wl1271",
+ .mmc= 3,
+ .wires = 4,
+ .gpio_wp= -EINVAL,
+ .gpio_cd= -EINVAL,
+ .nonremovable = true,
+ },
{} /* Terminator */
};
@@ -313,6 +329,9 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
+ if (wl12xx_set_platform_data(&omap_zoom_wlan_data))
+ pr_err("error setting wl12xx data\n");
+
omap_i2c_init();
platform_device_register(&omap_vwlan_device);
usb_musb_init(&musb_board_data);
--
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 v6 6/7] omap: zoom: add fixed regulator device for wlan
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -27,6 +28,8 @@
#include "mux.h"
#include "hsmmc.h"
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply
= {
.supply = "vmmc",
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.2",
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = &zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &zoom_vmmc3_supply,
+};
+
+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,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = "external",
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(&omap_vwlan_device);
usb_musb_init(&musb_board_data);
enable_board_wakeup_source();
}
--
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 v6 5/7] wl1271: make ref_clock configurable by board
The wl1271 device is using a reference clock that may change
between board to board.
Make the ref_clock parameter configurable by board settings
instead of having a hard coded value in the sources.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271.h |1 +
drivers/net/wireless/wl12xx/wl1271_boot.c | 11 +++
drivers/net/wireless/wl12xx/wl1271_boot.h |1 -
drivers/net/wireless/wl12xx/wl1271_sdio.c |1 +
drivers/net/wireless/wl12xx/wl1271_spi.c |2 ++
include/linux/wl12xx.h|1 +
6 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index faa5925..4134f44 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -330,6 +330,7 @@ struct wl1271 {
void (*set_power)(bool enable);
int irq;
+ int ref_clock;
spinlock_t wl_lock;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c
b/drivers/net/wireless/wl12xx/wl1271_boot.c
index f36430b..fc21db8 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -457,17 +457,20 @@ int wl1271_boot(struct wl1271 *wl)
{
int ret = 0;
u32 tmp, clk, pause;
+ int ref_clock = wl->ref_clock;
wl1271_boot_hw_version(wl);
- if (REF_CLOCK == 0 || REF_CLOCK == 2 || REF_CLOCK == 4)
+ if (ref_clock == 0 || ref_clock == 2 || ref_clock == 4)
/* ref clk: 19.2/38.4/38.4-XTAL */
clk = 0x3;
- else if (REF_CLOCK == 1 || REF_CLOCK == 3)
+ else if (ref_clock == 1 || ref_clock == 3)
/* ref clk: 26/52 */
clk = 0x5;
+ else
+ return -EINVAL;
- if (REF_CLOCK != 0) {
+ if (ref_clock != 0) {
u16 val;
/* Set clock type (open drain) */
val = wl1271_top_reg_read(wl, OCP_REG_CLK_TYPE);
@@ -516,7 +519,7 @@ int wl1271_boot(struct wl1271 *wl)
wl1271_debug(DEBUG_BOOT, "clk2 0x%x", clk);
/* 2 */
- clk |= (REF_CLOCK << 1) << 4;
+ clk |= (ref_clock << 1) << 4;
wl1271_write32(wl, DRPW_SCRATCH_START, clk);
wl1271_set_partition(wl, &part_table[PART_WORK]);
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.h
b/drivers/net/wireless/wl12xx/wl1271_boot.h
index f829699..f73b0b1 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.h
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.h
@@ -46,7 +46,6 @@ struct wl1271_static_data {
/* delay between retries */
#define INIT_LOOP_DELAY 50
-#define REF_CLOCK2
#define WU_COUNTER_PAUSE_VAL 0x3FF
#define WELP_ARM_COMMAND_VAL 0x4
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 987ecdc..f2f0466 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -234,6 +234,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
}
wl->irq = wlan_data->irq;
+ wl->ref_clock = wlan_data->board_ref_clock;
ret = request_irq(wl->irq, wl1271_irq, 0, DRIVER_NAME, wl);
if (ret < 0) {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index de56d8d..ced0a9e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -372,6 +372,8 @@ static int __devinit wl1271_probe(struct spi_device *spi)
goto out_free;
}
+ wl->ref_clock = pdata->board_ref_clock;
+
wl->irq = spi->irq;
if (wl->irq < 0) {
wl1271_error("irq missing in platform data");
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index bd70563..95deae3 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -29,6 +29,7 @@ struct wl12xx_platform_data {
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
+ int board_ref_clock;
};
int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
--
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 v6 4/7] wl1271: take irq info from private board data
Remove the hard coded irq information, and instead take
the irq information from the board's platform data.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/wl12xx/wl1271_sdio.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_sdio.c
b/drivers/net/wireless/wl12xx/wl1271_sdio.c
index 1d5dc72..987ecdc 100644
--- a/drivers/net/wireless/wl12xx/wl1271_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1271_sdio.c
@@ -29,14 +29,12 @@
#include
#include
#include
+#include
#include "wl1271.h"
#include "wl12xx_80211.h"
#include "wl1271_io.h"
-
-#define RX71_WL1271_IRQ_GPIO 42
-
#ifndef SDIO_VENDOR_ID_TI
#define SDIO_VENDOR_ID_TI 0x0097
#endif
@@ -208,6 +206,7 @@ static int __devinit wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
struct ieee80211_hw *hw;
+ const struct wl12xx_platform_data *wlan_data;
struct wl1271 *wl;
int ret;
@@ -227,13 +226,15 @@ static int __devinit wl1271_probe(struct sdio_func *func,
/* Grab access to FN0 for ELP reg. */
func->card->quirks |= MMC_QUIRK_LENIENT_FN0;
- wl->irq = gpio_to_irq(RX71_WL1271_IRQ_GPIO);
- if (wl->irq < 0) {
- ret = wl->irq;
- wl1271_error("could not get irq!");
+ wlan_data = wl12xx_get_platform_data();
+ if (IS_ERR(wlan_data)) {
+ ret = PTR_ERR(wlan_data);
+ wl1271_error("missing wlan platform data: %d", ret);
goto out_free;
}
+ wl->irq = wlan_data->irq;
+
ret = request_irq(wl->irq, wl1271_irq, 0, DRIVER_NAME, wl);
if (ret < 0) {
wl1271_error("request_irq() failed: %d", ret);
--
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 v6 3/7] wl12xx: add platform data passing support
Add a simple mechanism to pass platform data to the
SDIO instances of wl12xx.
This way there is no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
Originally proposed by Russell King.
Signed-off-by: Ohad Ben-Cohen
---
drivers/net/wireless/Makefile |2 +
drivers/net/wireless/wl12xx/Kconfig|5 +++-
drivers/net/wireless/wl12xx/wl12xx_platform_data.c | 28
include/linux/wl12xx.h |3 ++
4 files changed, 37 insertions(+), 1 deletions(-)
create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 5d4ce4d..85af697 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -50,5 +50,7 @@ obj-$(CONFIG_ATH_COMMON) += ath/
obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
obj-$(CONFIG_WL12XX) += wl12xx/
+# small builtin driver bit
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
obj-$(CONFIG_IWM) += iwmc3200wifi/
diff --git a/drivers/net/wireless/wl12xx/Kconfig
b/drivers/net/wireless/wl12xx/Kconfig
index 2f98058..4a8bb25 100644
--- a/drivers/net/wireless/wl12xx/Kconfig
+++ b/drivers/net/wireless/wl12xx/Kconfig
@@ -74,4 +74,7 @@ config WL1271_SDIO
If you choose to build a module, it'll be called
wl1271_sdio. Say N if unsure.
-
+config WL12XX_PLATFORM_DATA
+ bool
+ depends on WL1271_SDIO != n
+ default y
diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
new file mode 100644
index 000..973b110
--- /dev/null
+++ b/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
@@ -0,0 +1,28 @@
+#include
+#include
+#include
+
+static const struct wl12xx_platform_data *platform_data;
+
+int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
+{
+ if (platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+const struct wl12xx_platform_data *wl12xx_get_platform_data(void)
+{
+ if (!platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return platform_data;
+}
+EXPORT_SYMBOL(wl12xx_get_platform_data);
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 015687a..bd70563 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -31,4 +31,7 @@ struct wl12xx_platform_data {
bool use_eeprom;
};
+int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
+const struct wl12xx_platform_data *wl12xx_get_platform_data(void);
+
#endif
--
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 v6 2/7] wl1271: propagate set_power's return value
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
---
drivers/net/wireless/wl12xx/wl1271.h |2 +-
drivers/net/wireless/wl12xx/wl1271_io.h |9 ++---
drivers/net/wireless/wl12xx/wl1271_main.c |4 +++-
drivers/net/wireless/wl12xx/wl1271_sdio.c | 15 +--
drivers/net/wireless/wl12xx/wl1271_spi.c |4 +++-
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h
b/drivers/net/wireless/wl12xx/wl1271.h
index dd3cee6..faa5925 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -313,7 +313,7 @@ struct wl1271_if_operations {
bool fixed);
void (*reset)(struct wl1271 *wl);
void (*init)(struct wl1271 *wl);
- void (*power)(struct wl1271 *wl, bool enable);
+ int (*power)(struct wl1271 *wl, bool enable);
struct device* (*dev)(struct wl1271 *wl);
void (*enable_irq)(struct wl1271 *wl);
void (*disable_irq)(struct wl1271 *wl);
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);
+ if (ret == 0)
+ set_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
+
+ return ret;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c
b/drivers/net/wireless/wl12xx/wl1271_main.c
index 8e55cf8..af26150 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -621,7 +621,9 @@ static int wl1271_chip_wakeup(struct wl1271 *wl)
int ret = 0;
msleep(WL1271_PRE_POWER_ON_SLEEP);
- wl1271_power_on(wl);
+ ret = wl1271_power_on(wl);
+ if (ret < 0)
+ goto out;
msleep(WL1271_POWER_ON_SLEEP);
wl1271_io_reset(wl);
wl1271_io_init(wl);
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;
}
-static void wl1271_sdio_power_off(struct wl1271 *wl)
+static int wl1271_sdio_power_off(struct wl1271 *wl)
{
struct sdio_func *func = wl_to_func(wl);
sdio_claim_host(func);
sdio_disable_func(func);
sdio_release_host(func);
+
+ return 0;
}
-static void wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_sdio_set_power(struct wl1271 *wl, bool enable)
{
/* Let the SDIO stack handle wlan_enable control, so we
* keep host claimed while wlan is in use to keep wl1271
* alive.
*/
if (enable)
- wl1271_sdio_power_on(wl);
+ return wl1271_sdio_power_on(wl);
else
- wl1271_sdio_power_off(wl);
-
+ return wl1271_sdio_power_off(wl);
}
static struct wl1271_if_operations sdio_ops = {
diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c
b/drivers/net/wireless/wl12xx/wl1271_spi.c
index c3fdab7..de56d8d 100644
--- a/drivers/net/wireless/wl12xx/wl1271_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
@@ -312,10 +312,12 @@ static irqreturn_t wl1271_irq(int irq, void *cookie)
return IRQ_HANDLED;
}
-static void wl1271_spi_set_power(struct wl1271 *wl, bool enable)
+static int wl1271_spi_set_power(struct wl1271 *wl, bool enable)
{
if (wl->set_power)
wl->set_power(enable);
+
+ return 0;
}
static struct wl1271_if_operations spi_ops = {
--
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 v6 0/7] native wl1271 support on ZOOM
This patchset adds wl1271 support on ZOOM2/3 boards. Only basic support is included; power manipulation is submitted separately as SDIO Runtime PM support. Changes since v5: - rebase to wireless-testing - remove 2nd copy from wl12xx_platform_data (keep the 1st one though) Thanks, Ohad Ben-Cohen (7): wl12xx: make wl12xx.h common to both spi and sdio wl1271: propagate set_power's return value wl12xx: add platform data passing support wl1271: take irq info from private board data wl1271: make ref_clock configurable by board omap: zoom: add fixed regulator device for wlan omap: zoom: add mmc3/wl1271 device support arch/arm/mach-omap2/board-zoom-peripherals.c | 54 drivers/net/wireless/Makefile |2 + drivers/net/wireless/wl12xx/Kconfig|5 ++- drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +- drivers/net/wireless/wl12xx/wl1251_spi.c |2 +- drivers/net/wireless/wl12xx/wl1271.h |3 +- drivers/net/wireless/wl12xx/wl1271_boot.c | 11 +++-- drivers/net/wireless/wl12xx/wl1271_boot.h |1 - drivers/net/wireless/wl12xx/wl1271_io.h|9 ++- drivers/net/wireless/wl12xx/wl1271_main.c |4 +- drivers/net/wireless/wl12xx/wl1271_sdio.c | 31 +++- drivers/net/wireless/wl12xx/wl1271_spi.c |8 ++- drivers/net/wireless/wl12xx/wl12xx_platform_data.c | 28 ++ include/linux/spi/wl12xx.h | 34 include/linux/wl12xx.h | 38 ++ 15 files changed, 170 insertions(+), 62 deletions(-) create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c delete mode 100644 include/linux/spi/wl12xx.h create mode 100644 include/linux/wl12xx.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 v6 1/7] 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.
Signed-off-by: Ohad Ben-Cohen
---
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 +
5 files changed, 37 insertions(+), 37 deletions(-)
delete mode 100644 include/linux/spi/wl12xx.h
create mode 100644 include/linux/wl12xx.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
#include
#include
-#include
+#include
#include
#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
#include
#include
-#include
+#include
#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
#include
#include
-#include
+#include
#include
#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
- *
- * 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 (C) 2009 Nokia Corporation
+ *
+ * Contact: Luciano Coelho
+ *
+ * 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_WL12XX_H
+#define _LINUX_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
--
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] omap: Update omap3_defconfig to work with SMP_ON_UP
* Shilimkar, Santosh [100915 11:18]: > > > Here is the patch which fixes most of the omap4 issues with common > Omap3_defconfig. Good to hear, thanks! > To enable local Timers for es1.0, I made some progress but looks like > it needs more changes in generic code. Will have a look at it tomorrow. OK > The patch is on top of the patches being discussed here. It's boot-tested > with single image on OMAP3 and OMAP4 SMP. Looks good to me. 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] omap3: Prevent SDRC deadlock when L3 is changing frequency
On Wed, 15 Sep 2010, Tony Lindgren wrote: > * Paul Walmsley [100915 12:07]: > > > > > > This change has been commited to both TI's android 2.6.29 and 2.6.32 > > > kernels. > > > The commits can be viewed here: > > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d > > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940 > > > > > > This patch has been rebased on the latest linux-omap tree and tested on > > > Kevin Hilman's pm branch. > > Sounds like a very important fix. But also a good example of how > messed up things are with the TI Linux kernel development. > > Why has this fix it been sitting in some TI internal tree since > Fri, 12 Mar 2010? 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. > This same bug has been patched in three different trees? But not in > the mainline kernel? > > And this is happening all the time with the TI fixes. Yeah. - Paul -- 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 2/2] OMAP: omap_device: make all devices a child of a new parent device
Paul Walmsley writes: > Hi Kevin, > > On Tue, 14 Sep 2010, Kevin Hilman wrote: > >> From: Kevin Hilman >> >> In order to help differentiate omap_devices from normal >> platform_devices, make them all a parent of a new common parent >> device. >> >> Then, in order to determine if a platform_device is also an >> omap_device, checking the parent is all that is needed. >> >> Users of this feature are the runtime PM core for OMAP, where we need >> to know if a device being passed in is an omap_device or not in order >> to know whether to call the omap_device API with it. >> >> In addition, all omap_devices will now show up under /sys/devices/omap >> instead of /sys/devices/platform >> >> Signed-off-by: Kevin Hilman > > At least with the current state of the Linux kernel codebase, I think it > would be better to have an omap_bus/omap_bus_type. But as we've > discussed, that is a lot of work, and this solution seems to solve the > immediate problem -- how to determine if a device is really an omap_device > -- while being minimally invasive to the rest of the kernel code and > device model. So, looks good to me for now, > > Acked-by: Paul Walmsley > > and feel free to merge this and patch 1/2 through your tree... > OK, will do. Thanks, 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 v2 2/2] OMAP: omap_device: make all devices a child of a new parent device
Hi Kevin,
On Tue, 14 Sep 2010, Kevin Hilman wrote:
> From: Kevin Hilman
>
> In order to help differentiate omap_devices from normal
> platform_devices, make them all a parent of a new common parent
> device.
>
> Then, in order to determine if a platform_device is also an
> omap_device, checking the parent is all that is needed.
>
> Users of this feature are the runtime PM core for OMAP, where we need
> to know if a device being passed in is an omap_device or not in order
> to know whether to call the omap_device API with it.
>
> In addition, all omap_devices will now show up under /sys/devices/omap
> instead of /sys/devices/platform
>
> Signed-off-by: Kevin Hilman
At least with the current state of the Linux kernel codebase, I think it
would be better to have an omap_bus/omap_bus_type. But as we've
discussed, that is a lot of work, and this solution seems to solve the
immediate problem -- how to determine if a device is really an omap_device
-- while being minimally invasive to the rest of the kernel code and
device model. So, looks good to me for now,
Acked-by: Paul Walmsley
and feel free to merge this and patch 1/2 through your tree...
- Paul
> ---
> Changes since v1:
> - renamed the device from omap_bus to omap_parent_device to be more
> clear that this is not a bus.
>
> arch/arm/plat-omap/include/plat/omap_device.h |2 ++
> arch/arm/plat-omap/omap_device.c | 12
> 2 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> b/arch/arm/plat-omap/include/plat/omap_device.h
> index bad4c3d..28e2d1a 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -36,6 +36,8 @@
>
> #include
>
> +extern struct device omap_device_parent;
> +
> /* omap_device._state values */
> #define OMAP_DEVICE_STATE_UNKNOWN0
> #define OMAP_DEVICE_STATE_ENABLED1
> diff --git a/arch/arm/plat-omap/omap_device.c
> b/arch/arm/plat-omap/omap_device.c
> index 7f05f49..8215b1b 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -465,6 +465,7 @@ int omap_device_register(struct omap_device *od)
> {
> pr_debug("omap_device: %s: registering\n", od->pdev.name);
>
> + od->pdev.dev.parent = &omap_device_parent;
> return platform_device_register(&od->pdev);
> }
>
> @@ -737,3 +738,14 @@ int omap_device_enable_clocks(struct omap_device *od)
> /* XXX pass along return value here? */
> return 0;
> }
> +
> +struct device omap_device_parent = {
> + .init_name = "omap",
> + .parent = &platform_bus,
> +};
> +
> +static int __init omap_device_init(void)
> +{
> + return device_register(&omap_device_parent);
> +}
> +core_initcall(omap_device_init);
> --
> 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
Re: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
* Paul Walmsley [100915 12:07]: > > > > This change has been commited to both TI's android 2.6.29 and 2.6.32 > > kernels. > > The commits can be viewed here: > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940 > > > > This patch has been rebased on the latest linux-omap tree and tested on > > Kevin Hilman's pm branch. Sounds like a very important fix. But also a good example of how messed up things are with the TI Linux kernel development. Why has this fix it been sitting in some TI internal tree since Fri, 12 Mar 2010? This same bug has been patched in three different trees? But not in the mainline kernel? And this is happening all the time with the TI fixes. 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 v2 1/2] Revert "OMAP: omap_device: add omap_device_is_valid()"
On Tue, 14 Sep 2010, Kevin Hilman wrote: > From: Kevin Hilman > > This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206. > > The dereference method of checking for a valid omap_device when > wrapping a platform_device is rather unsafe and dangerous. > > Instead, a better way of checking for a valid omap-device is > to use a common parent device for all omap_devices, then a check > can simply be made using the device parent. The only user of this > API was the initial version of the runtime PM core for OMAP. This > has now been switched to check device parent, so there are no more > users of this API. > > Signed-off-by: Kevin Hilman Agreed, this is a much better approach. Acked-by: Paul Walmsley - Paul -- 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: OMAP3 DSP MMU fault + off mode issue
On Wed, Sep 15, 2010 at 7:03 PM, venki kaps wrote: > In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging > enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE. Indeed, I added that configuration in order to avoid that possibly troublesome code in a production system. I haven't seen it working properly yet. -- Felipe Contreras -- 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/5] OMAP: McSPI: Implement McSPI in HWMOD way
Grant Likely writes: [...] > What I'm thinking about doing at the embedded microconf is asking a > few people (you included) to speak briefly about what they are doing > to describe their platforms, and see if any common functionality > bubbles to the top. Sounds great. > I think it is to easy to get focused on our own problem domain and > miss that others are working on very similar problems in isolation. Completely agree. Looking forward to LPC. 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
[PATCH 4/4] OMAP3: OPP: add OPP table data and initialization
From: Nishanth Menon
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/opp3xxx_data.c | 126
arch/arm/mach-omap2/pm.c |6 ++
arch/arm/mach-omap2/pm.h |1 +
4 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..33acca9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -57,6 +57,8 @@ obj-$(CONFIG_PM_DEBUG)+= pm-debug.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
+obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
+
endif
# PRCM
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
new file mode 100644
index 000..df0bfa0
--- /dev/null
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP3 resource init/change_level/validate_level functions
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ * History:
+ *
+ */
+
+#include
+#include
+
+#include
+#include
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+ /* MPU OPP1 */
+ OMAP_OPP_DEF("mpu", true, 12500, 975000),
+ /* MPU OPP2 */
+ OMAP_OPP_DEF("mpu", true, 25000, 1075000),
+ /* MPU OPP3 */
+ OMAP_OPP_DEF("mpu", true, 5, 120),
+ /* MPU OPP4 */
+ OMAP_OPP_DEF("mpu", true, 55000, 127),
+ /* MPU OPP5 */
+ OMAP_OPP_DEF("mpu", true, 6, 135),
+
+ /*
+* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
+* almost the same than the one at 83MHz thus providing very little
+* gain for the power point of view. In term of energy it will even
+* increase the consumption due to the very negative performance
+* impact that frequency will do to the MPU and the whole system in
+* general.
+*/
+ OMAP_OPP_DEF("l3_main", false, 4150, 975000),
+ /* L3 OPP2 */
+ OMAP_OPP_DEF("l3_main", true, 8300, 105),
+ /* L3 OPP3 */
+ OMAP_OPP_DEF("l3_main", true, 16600, 115),
+
+
+ /* DSP OPP1 */
+ OMAP_OPP_DEF("iva", true, 9000, 975000),
+ /* DSP OPP2 */
+ OMAP_OPP_DEF("iva", true, 18000, 1075000),
+ /* DSP OPP3 */
+ OMAP_OPP_DEF("iva", true, 36000, 120),
+ /* DSP OPP4 */
+ OMAP_OPP_DEF("iva", true, 4, 127),
+ /* DSP OPP5 */
+ OMAP_OPP_DEF("iva", true, 43000, 135),
+};
+static u32 omap34xx_opp_def_size = ARRAY_SIZE(omap34xx_opp_def_list);
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
+ /* MPU OPP1 - OPP50 */
+ OMAP_OPP_DEF("mpu", true, 3, 93),
+ /* MPU OPP2 - OPP100 */
+ OMAP_OPP_DEF("mpu", true, 6, 110),
+ /* MPU OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF("mpu", false, 8, 126),
+ /* MPU OPP4 - OPP-SB */
+ OMAP_OPP_DEF("mpu", false, 10, 135),
+
+ /* L3 OPP1 - OPP50 */
+ OMAP_OPP_DEF("l3_main", true, 1, 93),
+ /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OMAP_OPP_DEF("l3_main", true, 2, 1137500),
+
+ /* DSP OPP1 - OPP50 */
+ OMAP_OPP_DEF("iva", true, 26000, 93),
+ /* DSP OPP2 - OPP100 */
+ OMAP_OPP_DEF("iva", true, 52000, 110),
+ /* DSP OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF("iva", false, 66000, 126),
+ /* DSP OPP4 - OPP-SB */
+ OMAP_OPP_DEF("iva", false, 8, 135),
+};
+static u32 omap36xx_opp_def_size = ARRAY_SIZE(omap36xx_opp_def_list);
+
+/* Temp variable to allow multiple calls */
+static u8 __initdata omap3_table_init;
+
+int __init omap3_pm_init_opp_table(void)
+{
+ struct omap_opp_def *opp_def, *omap3_opp_def_list;
+ u32 omap3_opp_def_size;
+ int i, r;
+
+ /*
+* Allow multiple calls, but initialize only if not already initalized
+* even if the previous call failed, coz, no reason we'd succeed again
+*/
+
[PATCH 3/4] OMAP3: remove OPP interfaces from OMAP PM layer
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/io.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 31 +---
arch/arm/plat-omap/omap-pm-noop.c | 11 +-
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b9ea70b..c09bf10 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,8 +323,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
- /* The OPP tables have to be registered before a clk init */
- omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+ omap_pm_if_early_init();
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..c5b533d 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,24 +19,7 @@
#include
#include "powerdomain.h"
-
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data. Can vary by OMAP chip and board.
- */
-struct omap_opp {
- unsigned long rate;
- u8 opp_id;
- u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
+#include
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
* framework starts. The "_if_" is to avoid name collisions with the
* PM idle-loop code.
*/
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
/**
* omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
* The main initialization code. OPP tables are passed in here. The
* "_if_" is to avoid name collisions with the PM idle-loop code.
*/
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
int __init omap_pm_if_init(void);
+#endif
/**
* omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
#include
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
/*
* Device-driver-originated constraints (via board-*.c files)
*/
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
/* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
{
- mpu_opps = mpu_opp_table;
- dsp_opps = dsp_opp_table;
- l3_opps = l3_opp_table;
return 0;
}
--
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
[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon
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-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=12580924752&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
incorporated.
Cc: Benoit Cousson
Cc: Madhusudhan Chikkature Rajashekar
Cc: Phil Carmody
Cc: Roberto Granados Dorado
Cc: Santosh Shilimkar
Cc: Sergio Alberto Aguirre Rodriguez
Cc: Tero Kristo
Cc: Eduardo Valentin
Cc: Paul Walmsley
Cc: Romit Dasgupta
Cc: Sanjeev Premi
Cc: Thara Gopinath
Cc: Vishwanath BS
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
---
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 the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2. opp_find_freq_exact - exact search function
+3. opp_find_freq_floor - round_up search function
+4. opp_find_freq_ceil - round_down search function
+
+OPP modifier functions:
+--
+This allows opp layer users to add customized OPPs or change the table
+for any need they may have
+5. opp_add - add a new OPP - NOTE: use st
[PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
From: Paul Walmsley
The OPP layer code should be independent of the PMIC,
introduce the TWL/TPS-specific code out to its own file.
Signed-off-by: Paul Walmsley
Signed-off-by: Romit Dasgupta
Signed-off-by: Phil Carmody
Signed-off-by: Nishanth Menon
Signed-off-by: Kevin Hilman
---
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
+
+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
+
+/**
+ * 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
[PATCH 0/4] OMAP OPP layer for 2.6.37
This series introduces a layer to manage Operating Performance Points (OPPs) for OMAP SoCs. Special thanks to Nishanth for doing the bulk of the work on this series and to Thara for doing significant review, testing and updates. Kevin Hilman (1): OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon (2): OMAP: introduce OPP layer for device-specific OPPs OMAP3: OPP: add OPP table data and initialization Paul Walmsley (1): OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Documentation/arm/OMAP/omap_pm| 83 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/io.c |3 +- arch/arm/mach-omap2/opp3xxx_data.c| 126 +++ arch/arm/mach-omap2/pm.c |6 + arch/arm/mach-omap2/pm.h |1 + arch/arm/plat-omap/Makefile |6 + arch/arm/plat-omap/include/plat/omap-pm.h | 31 +-- arch/arm/plat-omap/include/plat/opp.h | 145 arch/arm/plat-omap/include/plat/opp_twl_tps.h | 21 ++ arch/arm/plat-omap/omap-pm-noop.c | 11 +- arch/arm/plat-omap/opp.c | 461 + arch/arm/plat-omap/opp_twl_tps.c | 41 +++ 13 files changed, 904 insertions(+), 33 deletions(-) create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c create mode 100644 arch/arm/plat-omap/include/plat/opp.h create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h create mode 100644 arch/arm/plat-omap/opp.c create mode 100644 arch/arm/plat-omap/opp_twl_tps.c -- 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
RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
Pramod, Teerth, On Thu, 1 Jul 2010, Paul Walmsley wrote: > Pramod, Teerth, > > On Mon, 7 Jun 2010, Gurav , Pramod wrote: > > > Can you please push these patches if you don't you are OK with them? > > As we discussed in Bangalore, these patches need some changes: > > 1. The delay needs to be precisely characterized in terms of what the > hardware actually needs. It should not be necessary to add any extra > timing slop, due to unknown sources, in the code. Unknown sources of > delay can cause problems if, for example, a customer changes some board > characteristics (such as sys_clk frequency, or DPLL multipliers/dividers) > that the delay depends on. > > Also, my understanding is that RX-51 shipped without unknown timing > factors in this code. Please work with the hardware people to precisely > characterize the delay, assuming that it does not match what is documented > in the TRM. > > 2. Please split out the individual components of the delay calculation to > the code that handles those clocks. For example, HSDIVIDER change delay > should be calculated by code that handles the HSDIVIDER. DPLL relock > delay should be calculated by code in the dpll*.c files. etc. Any updates on these patches? - Paul -- 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/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 V
---
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 @@
#include
#include
#include
-#include
#include
#include
#include
#include
+#include
#include
#include
Why do you have to access the PRCM from the driver?
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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency
Jon, one other brief note: On Wed, 21 Jul 2010, Jon Hunter wrote: > diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S > index de99ba2..e87e730 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 aux ctrl register > + bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction > + mcr p15, 0, r10, c1, c0, 0 @ write aux ctrl register Please be careful with the whitespace between the opcode and the arguments - I will fix this in the current patch but it seems best to keep this consistent. - Paul -- 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 9:29 AM, Anti Sullin 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. 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 v5 4/6] OMAP4: hwmod data: Add watchdog timer
On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:
From: Benoit Cousson
Add watchdog timer hwmod data for OMAP4 chip
Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
---
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 :-(
Benoit
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 68
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..06851f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,72 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
+ .name = "wd_timer",
+ .sysc =&omap44xx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap44xx_wd_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer2_irqs[] = {
+ { .irq = 80 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x4a314000,
+ .pa_end = 0x4a31407f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__wd_timer2 = {
+ .master =&omap44xx_l4_wkup_hwmod,
+ .slave =&omap44xx_wd_timer2_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
+ .addr = omap44xx_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* wd_timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer2_slaves[] = {
+ &omap44xx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
+ .name = "wd_timer2",
+ .class =&omap44xx_wd_timer_hwmod_class,
+ .mpu_irqs = omap44xx_wd_timer2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
+ .main_clk = "wd_timer2_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
&omap44xx_dmm_hwmod,
@@ -472,6 +538,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* mpu class */
&omap44xx_mpu_hwmod,
+ /* wd_timer class */
+ &omap44xx_wd_timer2_hwmod,
NULL,
};
--
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: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset
Teerth, Vishwa, On Tue, 25 May 2010, Reddy, Teerth wrote: > > -Original Message- > > From: Paul Walmsley [mailto:p...@pwsan.com] > > Sent: Wednesday, May 19, 2010 6:03 AM > > To: Reddy, Teerth > > Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath > > Subject: Re: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR > > stall in SDRC after a Warm-reset > > > > On Fri, 23 Apr 2010, Reddy, Teerth wrote: > > > > > From: Teerth Reddy > > > > > > This patch has the workaround for errata 1.176. What's the current status of this patch? Still waiting for an updated version. - Paul -- 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
On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:
Add watchdog timer hwmod data for OMAP3 chip
Signed-off-by: Charulatha V
---
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.
+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 (1<< 5)
#define OMAP3430_EN_GPIO1_MASK(1<< 3)
#define OMAP3430_EN_GPIO1_SHIFT 3
#define OMAP3430_EN_GPT12_MASK(1<< 1)
That part is not related to the subject of this patch. You should
probably put that in another patch.
Benoit
--
To unsubscribe from this list: send the line "uns
Re: [PATCH v5 4/6] OMAP4: hwmod data: Add watchdog timer
Hi Charu,
On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:
From: Benoit Cousson
Add watchdog timer hwmod data for OMAP4 chip
Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
---
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/
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 68
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..06851f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,72 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_wd_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
+ .name = "wd_timer",
+ .sysc =&omap44xx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap44xx_wd_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer2_irqs[] = {
+ { .irq = 80 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer2_addrs[] = {
+ {
+ .pa_start = 0x4a314000,
+ .pa_end = 0x4a31407f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__wd_timer2 = {
+ .master =&omap44xx_l4_wkup_hwmod,
+ .slave =&omap44xx_wd_timer2_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
+ .addr = omap44xx_wd_timer2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_wd_timer2_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* wd_timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer2_slaves[] = {
+ &omap44xx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
+ .name = "wd_timer2",
+ .class =&omap44xx_wd_timer_hwmod_class,
+ .mpu_irqs = omap44xx_wd_timer2_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
+ .main_clk = "wd_timer2_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_wd_timer2_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
&omap44xx_dmm_hwmod,
@@ -472,6 +538,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* mpu class */
&omap44xx_mpu_hwmod,
+ /* wd_timer class */
+ &omap44xx_wd_timer2_hwmod,
NULL,
};
What about the wd_timer3? It is in the audio backend, and I'm not sure
who will use it, but it does exist.
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 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
On Fri, Sep 10, 2010 at 03:15:35PM -0700, Kevin Hilman wrote: > Grant Likely writes: > > > On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote: > >> Grant Likely writes: > >> > >> > On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V wrote: > >> >> This patch series implements McSPI Module in HWMOD FW way > >> >> and use the runtime PM layer. > >> > > >> > Hi Charulatha, > >> > > >> > I'll go through and review the patches, but I'm unfamiliar with HWMOD. > >> > Is there a description of HWMOD that you can point me at? > >> > >> Hi Grant, > >> > >> If you want to skip my rambling, the source for omap_hwmod is in mainline: > >> > >>arch/arm/mach-omap2/omap_hwmod.c > >>arch/arm/plat-omap/include/plat/omap_hwmod.h > >> > >> omap_hwmod is short for OMAP hardware module. It is essentially a > >> central way of describing each IP block in an OMAP SoC, and the way they > >> are connected together to make an SoC. An omap_hwmod for a given IP > >> block contains base address, IRQs, DMA channels etc. (as would a device > >> tree node) but also includes information on any master/slave interfaces > >> to model how IP blocks are connected on the SoC and many other details. > > > > Hi Kevin, > > > > This seems to be a common issue for more than just OMAP SoCs, and I've > > seen a number of approaches to solving it; both internal to the kernel > > (AMBA bus, HWMOD, ad-hoc pdata, etc) and via external data (FDT, SFI). > > It doesn't seem like there is a lot of cross-pollination going on > > either. > > > > I'm thinking about scheduling a discussion in the embedded > > microconference at Plumbers to talk about the encoding and handling of > > SoC and machine interconnection data. There should be enough examples > > now that we can agree on some common infrastructure for handling these > > kinds of things without inventing new infrastructure from scratch for > > each SoC family. What do you think? > > The discussion is certainly worthwhile, and I would love to participate. > As with everything, the devil is in the details. And I'm afraid that > while at a high-level, describing one SoC or another might look similar, > when it gets down to the details, there will be *tons* of things that > are unique to each SoC. > > For example, if you look into the omap_hwmod code and data structures, > you will see that most of the stuff described in there is extremly OMAP > specific (mostly clock/power related), and only ever visible to OMAP > specific code. > > The question to me is what is the end goal of having a common > infrastructure to model SoC-unique features that are only touched by > SoC-specific code? And who would maintain such an infrastructure? You're right, there is no point generalizing stuff that is truly SoC specific. I'm interested in identifying the bits and techniques that are useful to other SoCs and architectures. I'm happy to maintain any infrastructure if need be. > Personally, I would rather keep focus on infrastructure efforts that > would actually be common across SoCs (common kernel binaries, etc.) and > visible to drivers (PM frameworks like CPUidle, runtime PM, etc.) All > the gory SoC specifics should be hidden by the SoC-specific > implementations of these frameworks, and maintained by folks who really > understand the SoC. Yes, I agree. > So, all that that I question the need for a common > framework to define SoC internals. Well for an example, we've talked a lot about the platform_bus_type. Associativity between devices (parent/child) is a core part of the Linux device model, and it is a common problem to know what the device topology is for handing init and PM ordering. I'd like to know what topology you need to describe for the OMAP SoCs. Does the Linux driver model topology provide any of the information you need, or does OMAP HWMOD implement its own topology infrastructure? What is missing from the driver model that requires a lookaside to HWMOD to obtain the SoC topology? I'm certainly not arguing that all SoC specific infrastructure needs to be generalized. Rather I want to find common features and techniques that can be used by SoC specific code. > That being said, I'm totally in favor of the direction that the FDT is > going in, and very much support the ways it will unify much of the > hardware description. However, I think it has limits. Of course it does; it's only a data structure! :-D It can encode data about the hardware; but it cannot describe operating system behaviour. > And at least for > OMAP, I envision using the device tree to describe connections at the > board level, but continuing to use omap_hwmod to describe the SoC > itself. At the very least, the structure of the SoC probably needs to be reflected in the device tree. A lot of the time nodes for internal SoC devices end up becoming 'handles' to describe attachments to external hardware. ie. i2c device nodes hanging off an SoC i2c controller, or interrupt connections. Since t
Re: [PATCH] OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts
Paul Walmsley writes:
> When the clockdomain layer initializes, place all clockdomains into
> software-supervised mode, and clear all wakeup and sleep dependencies
> immediately, rather than waiting for the PM code to do this later.
> This fixes a major bug where critical sleep dependencies added by the
> hwmod code are cleared during late PM init.
>
> As a side benefit, the _init_{wk,sleep}dep_usecount() functions are no
> longer needed, so remove them.
>
> Kevin Hilman did all the really hard work on
> this, identifying the problem and finding the bug.
>
> Signed-off-by: Paul Walmsley
> Cc: Kevin Hilman
Thanks Paul.
I'll queue this in pm-next for 2.6.37 along with the other changes that
depend on it.
Kevin
> ---
> arch/arm/mach-omap2/clockdomain.c | 110
> +
> arch/arm/mach-omap2/pm34xx.c |3 -
> 2 files changed, 15 insertions(+), 98 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c
> b/arch/arm/mach-omap2/clockdomain.c
> index 5d80cb8..6fb61b1 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -258,97 +258,6 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
> *clkdm, int enable)
>
> }
>
> -/**
> - * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
> - * @clkdm: clockdomain to initialize wkdep usecounts
> - *
> - * Initialize the wakeup dependency usecount variables for clockdomain
> @clkdm.
> - * If a wakeup dependency is present in the hardware, the usecount will be
> - * set to 1; otherwise, it will be set to 0. Software should clear all
> - * software wakeup dependencies prior to calling this function if it wishes
> - * to ensure that all usecounts start at 0. No return value.
> - */
> -static void _init_wkdep_usecount(struct clockdomain *clkdm)
> -{
> - u32 v;
> - struct clkdm_dep *cd;
> -
> - if (!clkdm->wkdep_srcs)
> - return;
> -
> - for (cd = clkdm->wkdep_srcs; cd->clkdm_name; cd++) {
> - if (!omap_chip_is(cd->omap_chip))
> - continue;
> -
> - if (!cd->clkdm && cd->clkdm_name)
> - cd->clkdm = _clkdm_lookup(cd->clkdm_name);
> -
> - if (!cd->clkdm) {
> - WARN(!cd->clkdm, "clockdomain: %s: wkdep clkdm %s not "
> - "found\n", clkdm->name, cd->clkdm_name);
> - continue;
> - }
> -
> - v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
> - PM_WKDEP,
> - (1 << cd->clkdm->dep_bit));
> -
> - if (v)
> - pr_debug("clockdomain: %s: wakeup dependency already "
> - "set to wake up when %s wakes\n",
> - clkdm->name, cd->clkdm->name);
> -
> - atomic_set(&cd->wkdep_usecount, (v) ? 1 : 0);
> - }
> -}
> -
> -/**
> - * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
> - * @clkdm: clockdomain to initialize sleepdep usecounts
> - *
> - * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
> - * If a sleep dependency is present in the hardware, the usecount will be
> - * set to 1; otherwise, it will be set to 0. Software should clear all
> - * software sleep dependencies prior to calling this function if it wishes
> - * to ensure that all usecounts start at 0. No return value.
> - */
> -static void _init_sleepdep_usecount(struct clockdomain *clkdm)
> -{
> - u32 v;
> - struct clkdm_dep *cd;
> -
> - if (!cpu_is_omap34xx())
> - return;
> -
> - if (!clkdm->sleepdep_srcs)
> - return;
> -
> - for (cd = clkdm->sleepdep_srcs; cd->clkdm_name; cd++) {
> - if (!omap_chip_is(cd->omap_chip))
> - continue;
> -
> - if (!cd->clkdm && cd->clkdm_name)
> - cd->clkdm = _clkdm_lookup(cd->clkdm_name);
> -
> - if (!cd->clkdm) {
> - WARN(!cd->clkdm, "clockdomain: %s: sleepdep clkdm %s "
> - "not found\n", clkdm->name, cd->clkdm_name);
> - continue;
> - }
> -
> - v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
> - OMAP3430_CM_SLEEPDEP,
> - (1 << cd->clkdm->dep_bit));
> -
> - if (v)
> - pr_debug("clockdomain: %s: sleep dependency already "
> - "set to prevent from idling until %s "
> - "idles\n", clkdm->name, cd->clkdm->name);
> -
> - atomic_set(&cd->sleepdep_usecount, (v) ? 1 : 0);
> - }
> -};
> -
> /* Public functions */
>
> /**
> @@ -379,12 +288,17 @@ void clkdm_init(struct clockdomain **clkdms,
> _autodep_lookup(autodep);
>
> /*
> -
Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Tony Lindgren writes: > * Kevin Hilman [100915 07:37]: >> Hi Wim, >> >> "Varadarajan, Charulatha" writes: >> >> > 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 V >> >> With your ack, I'll be glad to merge this via the OMAP tree since it >> depends on the rest of the series for the OMAP platform specific >> changes. > > Just checking.. The pm_runtime functions are implemented as > clk_enable/disable functions for omap1, right? Yes. 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 6/7] omap4: Workaround for CMD line reset.
> -Original Message- > From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] > Sent: Tuesday, September 14, 2010 11:49 AM > To: Chikkature Rajashekar, Madhusudhan; 'kishore kadiyala' > Cc: linux-omap@vger.kernel.org; t...@atomide.com; > khil...@deeprootsystems.com > Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset. > > Madhu, > > -Original Message- > > From: Chikkature Rajashekar, Madhusudhan > > Sent: Tuesday, September 14, 2010 9:28 PM > > To: 'kishore kadiyala'; Shilimkar, Santosh > > Cc: linux-omap@vger.kernel.org; t...@atomide.com; > > khil...@deeprootsystems.com > > Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset. > > > > > > > > > -Original Message- > > > From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] > > > Sent: Tuesday, September 14, 2010 10:47 AM > > > To: Madhusudhan Chikkature; Santosh Shilimkar > > > Cc: linux-omap@vger.kernel.org; t...@atomide.com; > > > khil...@deeprootsystems.com > > > Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset. > > > > > > Hi Madhu, > > > > > > On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar > > > wrote: > > > > From: Madhusudhan Chikkature > > > > > > > > Add a delay after CMD line reset to accomdate the reset to complete. > > > > The SYSCTL seems to reflect SRC immediately which might not really > > > > be indicating the complete of reset. This is observed only with > ES2.0 > > > > silicon > > > > > > > > Signed-off-by: Madhusudhan Chikkature > > > > --- > > > > drivers/mmc/host/omap_hsmmc.c | 8 > > > > 1 files changed, 8 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/drivers/mmc/host/omap_hsmmc.c > > > b/drivers/mmc/host/omap_hsmmc.c > > > > index 4a8776f..1c359f0 100644 > > > > --- a/drivers/mmc/host/omap_hsmmc.c > > > > +++ b/drivers/mmc/host/omap_hsmmc.c > > > > @@ -986,6 +986,14 @@ static inline void > > > omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host, > > > > (i++ < limit)) > > > > cpu_relax(); > > > > > > > > + /* > > > > + * On OMAP4 ES2 the SRC is zero in the first loop itself > > > strangely > > > > + * vs on ES1 it takes some time. > > > > + * Could be a an issue on ES2 to indicate reset complete > even > > > before > > > > + * it is complete. > > > > + */ > > > > + udelay(500); > > > > > > Since the above work around is applicable only for OMAP4 ES2 , > > > shouldn't this udelay be avoided for other OMAP versions > > > > > I did not post this to Linux omap at all. What patch are you talking > > about? > > > I have posted this patch on Tony and Kevin's request keeping the original > author. This is needed to get MMC working on ES2.0 samples. > > Do you have fresh version of this patch? > Yes. There is a TRM update lately that explains the procedure for CMD line reset changes in ES2. I will post that patch. Regards, Madhu > Regards, > Santosh -- 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: Upcoming merge window, marked all the patchwork patches before v2.6.35 as archived
* Gadiyar, Anand [100915 11:36]: > > I posted this patch [1] a while ago fixing a bunch of compile warnings > that show up with omap3_defconfig and omap_4430sdp_defconfig builds. I > can't seem to locate it in patchworks; not sure how that happened. > > Any chance you can pick this up (before more folks on LAKML start > yelling about no-one caring for build warnings...)? Would you like me > to post this again? > > - Anand > > [1] http://marc.info/?l=linux-omap&m=128212353619711&w=2 Thanks, adding that with Felipe's ack. For some reason I could not find this in patchwork at all, I guess it must have been pretty broken at some point. Anyways, for the other patches, please just repost so we'll have all the pending patches in one queue in patchwork. 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] omap3: Prevent SDRC deadlock when L3 is changing frequency
Hi Jon, I regret the delay: On Wed, 21 Jul 2010, Jon Hunter wrote: > From: Jon Hunter > > 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 AUX 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. > > This change has been commited to both TI's android 2.6.29 and 2.6.32 kernels. > The commits can be viewed here: > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940 > > This patch has been rebased on the latest linux-omap tree and tested on > Kevin Hilman's pm branch. > > Signed-off-by: Jon Hunter Really nice changelog. I wish every patch had a description this good. Patch looks really good, too. Queued for 2.6.37. - Paul -- 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: Upcoming merge window, marked all the patchwork patches before v2.6.35 as archived
On Thu, Sep 16, 2010 at 12:01 AM, Tony Lindgren wrote: > Hi all, > > Here's some important info regarding posted patches and the > upcoming merge window. > > > UPCOMING MERGE WINDOW > > Just to remind everybody, we want to have our omap patches reviewed > and queued into for-next by -rc6. That is less than two weeks from > today. > > If you have a larger set of patches, please set them up into a git > branch after review for pulling. Please remember that anything > touching arch/arm/*omap*/ must be also reviewed on the linux-arm-kernel > list, so Cc that list too so I don't have to repost the patches before > applying. Basically see the instructions here (server currently down?): > > http://www.elinux.org/OMAP_patch_merging_process > > > POSTED PATCHES AND PATCHWORK > > To cope with the patch overload, I added all the patchwork > patches into archived-v2.6.35 bundle when v2.6.35 got tagged: > > http://patchwork.kernel.org/bundle/tmlind/archived-v2.6.35/?archive=both > > However, at that point the patchwork instance on kernel.org was buggy, > and I could not mark them all archived. > > Anyways, I've marked them all archived now. This means they do not > appear as new patches any longer, and patchwork.kernel.org is > usable again for tracking what's already queued up. > > I plan on archiving everything when a new major release comes out, > maybe even after some -rc releases if necessary. > > So the current list of patches we're working with for the upcoming > merge window is: > > http://patchwork.kernel.org/project/linux-omap/list/ > > Please everybody, check if your patch got archived, and if so, > repost as needed against v2.6.36-rc4. > > In general, if something got archived, please don't consider it > rejected. It just means that you have to repost, fix and complain > until the patch is ready and integrated :) The standard Linux way > you know. > Tony, I posted this patch [1] a while ago fixing a bunch of compile warnings that show up with omap3_defconfig and omap_4430sdp_defconfig builds. I can't seem to locate it in patchworks; not sure how that happened. Any chance you can pick this up (before more folks on LAKML start yelling about no-one caring for build warnings...)? Would you like me to post this again? - Anand [1] http://marc.info/?l=linux-omap&m=128212353619711&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Hi All, > 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 V This is all omap specific code. So if Kevin and Tony are fine with the code then tou gave my ACK also. Kind regards, WIm. -- 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
Upcoming merge window, marked all the patchwork patches before v2.6.35 as archived
Hi all, Here's some important info regarding posted patches and the upcoming merge window. UPCOMING MERGE WINDOW Just to remind everybody, we want to have our omap patches reviewed and queued into for-next by -rc6. That is less than two weeks from today. If you have a larger set of patches, please set them up into a git branch after review for pulling. Please remember that anything touching arch/arm/*omap*/ must be also reviewed on the linux-arm-kernel list, so Cc that list too so I don't have to repost the patches before applying. Basically see the instructions here (server currently down?): http://www.elinux.org/OMAP_patch_merging_process POSTED PATCHES AND PATCHWORK To cope with the patch overload, I added all the patchwork patches into archived-v2.6.35 bundle when v2.6.35 got tagged: http://patchwork.kernel.org/bundle/tmlind/archived-v2.6.35/?archive=both However, at that point the patchwork instance on kernel.org was buggy, and I could not mark them all archived. Anyways, I've marked them all archived now. This means they do not appear as new patches any longer, and patchwork.kernel.org is usable again for tracking what's already queued up. I plan on archiving everything when a new major release comes out, maybe even after some -rc releases if necessary. So the current list of patches we're working with for the upcoming merge window is: http://patchwork.kernel.org/project/linux-omap/list/ Please everybody, check if your patch got archived, and if so, repost as needed against v2.6.36-rc4. In general, if something got archived, please don't consider it rejected. It just means that you have to repost, fix and complain until the patch is ready and integrated :) The standard Linux way you know. 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] omap: Update omap3_defconfig to work with SMP_ON_UP
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, September 15, 2010 9:41 PM
> To: Shilimkar, Santosh
> Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; linux-
> o...@vger.kernel.org; bryan...@canonical.com
> Subject: Re: [PATCH] omap: Update omap3_defconfig to work with SMP_ON_UP
>
> * Shilimkar, Santosh [100914 23:03]:
> > >
> > > Sounds like you're having these problems anyways and they
> > > are not related to the defconfigs?
> > >
> > Well the issues are because of defconfig but mostly fixable.
> > Will hold on my comments till I test the new defconfig on OMAP4.
>
> OK
>
> > > Considering Linus' earlier comments on the defconfigs, I don't
> > > see any reasonds not to merge this patch. If TI wants to fix up
> > > some other things, there's still about two weeks before -rc6.
> > >
> > Sure. I am just saying let's attempt to fix the remaining issues
> > and if it doesn't happen in next week, anyway this patch will
> > get merged.
>
> OK let's plan on doing that.
>
Here is the patch which fixes most of the omap4 issues with common
Omap3_defconfig.
To enable local Timers for es1.0, I made some progress but looks like
it needs more changes in generic code. Will have a look at it tomorrow.
The patch is on top of the patches being discussed here. It's boot-tested
with single image on OMAP3 and OMAP4 SMP.
>From 26c908cd9baf3cc0b22f04f29cbeb26e08ad05e8 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Wed, 15 Sep 2010 22:40:19 +0530
Subject: [PATCH] omap: Update and rename common defconfig for omap2plus devices
This patch addresses below things:
- Renaming existing omap3_defconfig which has OMAP2, OMAP3 and OMAP4 builds
enabled to more appropriate name 'omap2plus_defconfig'
- L1 cache shift is suppose to be 5 on OMAP4 where as it is 6 on previous
OMAPs. Keeping it to 5 is safer option for OMAP4 and previous OMAPs. For
OMAP3 only build the shift would be still 6
- Enable needed Errata's for OMAP4 to work with DMA based device drivers
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
- Enable the Micrel ethernet controller
CONFIG_KS8851=y
CONFIG_KS8851_MLL=y
With above three changes, OMAP4 ethernet, mmc etc works reliably.
Signed-off-by: Santosh Shilimkar
---
.../{omap3_defconfig => omap2plus_defconfig} |3 +++
arch/arm/mach-omap2/Kconfig|4 +++-
2 files changed, 6 insertions(+), 1 deletions(-)
rename arch/arm/configs/{omap3_defconfig => omap2plus_defconfig} (99%)
diff --git a/arch/arm/configs/omap3_defconfig
b/arch/arm/configs/omap2plus_defconfig
similarity index 99%
rename from arch/arm/configs/omap3_defconfig
rename to arch/arm/configs/omap2plus_defconfig
index 833a9bc..3d27dd0 100644
--- a/arch/arm/configs/omap3_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -53,6 +53,7 @@ CONFIG_MACH_SBC3530=y
CONFIG_MACH_OMAP_3630SDP=y
CONFIG_MACH_OMAP_4430SDP=y
CONFIG_ARM_THUMBEE=y
+CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
@@ -139,6 +140,8 @@ CONFIG_SMSC_PHY=y
CONFIG_NET_ETHERNET=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
+CONFIG_KS8851=y
+CONFIG_KS8851_MLL=y
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=y
CONFIG_LIBERTAS_SDIO=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b48bacf..bb85f24 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,7 +35,7 @@ config ARCH_OMAP3
default y
select CPU_V7
select USB_ARCH_HAS_EHCI
- select ARM_L1_CACHE_SHIFT_6
+ select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
config ARCH_OMAP4
bool "TI OMAP4"
@@ -43,6 +43,8 @@ config ARCH_OMAP4
depends on ARCH_OMAP2PLUS
select CPU_V7
select ARM_GIC
+ select PL310_ERRATA_588369
+ select ARM_ERRATA_720789
comment "OMAP Core Type"
depends on ARCH_OMAP2
--
1.6.0.4
0001-omap-Update-and-rename-common-defconfig-for-omap2pl.patch
Description: 0001-omap-Update-and-rename-common-defconfig-for-omap2pl.patch
Re: [PATCH v4 0/2] OMAP: DSS2: Framework to handle omap version specific DSS features
* arc...@ti.com [100915 07:00]: > From: Archit Taneja > > This is a simple approach to prevent scattered cpu_is_omap checks > in DSS2 by bringing all omap version specific DSS features/values to one > single place, initialize them and expose a set of functions to DSS2 driver > files which return the value/existance of a feature. Glad to hear. We should absolutely not use cpu_is_omap checks anywhere in the drivers. The drivers should be arch independent. Basically any driver using those is broken from Linux point of view. The current mess is: $ grep -r cpu_is_omap drivers/ | wc -l 139 The right way to replace those is to pass feature flags from the platform_data. 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 v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
* Kevin Hilman [100915 07:37]: > Hi Wim, > > "Varadarajan, Charulatha" writes: > > > 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 V > > With your ack, I'll be glad to merge this via the OMAP tree since it > depends on the rest of the series for the OMAP platform specific > changes. Just checking.. The pm_runtime functions are implemented as clk_enable/disable functions for omap1, right? 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 v5 5/6] OMAP2PLUS: WDT: use omap_device_build for device registration
* Varadarajan, Charulatha [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.
> 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.
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: Using C++ style inheritance for board files
* Elvis Dowson [100914 12:58]: > > For example, I have a platform that is based on board-overo.c. Instead copy > pasting and creating a new board-overo-variant.c, if the core structures were > defined as classes, I could potentially inherit from the base overo board > definition, and add my own specific modifications. Uhh, let's leave c++ out of this.. You can already easily share most of the code among boards by having multiple MACHINE entries in the board-*.c file. See board-n8x0.c for example. Then you can spend some effort to create common platform device init code, see gpmc-*.c and hsmmc.c for examples. 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
[PATCH] OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts
When the clockdomain layer initializes, place all clockdomains into
software-supervised mode, and clear all wakeup and sleep dependencies
immediately, rather than waiting for the PM code to do this later.
This fixes a major bug where critical sleep dependencies added by the
hwmod code are cleared during late PM init.
As a side benefit, the _init_{wk,sleep}dep_usecount() functions are no
longer needed, so remove them.
Kevin Hilman did all the really hard work on
this, identifying the problem and finding the bug.
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mach-omap2/clockdomain.c | 110 +
arch/arm/mach-omap2/pm34xx.c |3 -
2 files changed, 15 insertions(+), 98 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 5d80cb8..6fb61b1 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -258,97 +258,6 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
*clkdm, int enable)
}
-/**
- * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
- * @clkdm: clockdomain to initialize wkdep usecounts
- *
- * Initialize the wakeup dependency usecount variables for clockdomain @clkdm.
- * If a wakeup dependency is present in the hardware, the usecount will be
- * set to 1; otherwise, it will be set to 0. Software should clear all
- * software wakeup dependencies prior to calling this function if it wishes
- * to ensure that all usecounts start at 0. No return value.
- */
-static void _init_wkdep_usecount(struct clockdomain *clkdm)
-{
- u32 v;
- struct clkdm_dep *cd;
-
- if (!clkdm->wkdep_srcs)
- return;
-
- for (cd = clkdm->wkdep_srcs; cd->clkdm_name; cd++) {
- if (!omap_chip_is(cd->omap_chip))
- continue;
-
- if (!cd->clkdm && cd->clkdm_name)
- cd->clkdm = _clkdm_lookup(cd->clkdm_name);
-
- if (!cd->clkdm) {
- WARN(!cd->clkdm, "clockdomain: %s: wkdep clkdm %s not "
-"found\n", clkdm->name, cd->clkdm_name);
- continue;
- }
-
- v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
- PM_WKDEP,
- (1 << cd->clkdm->dep_bit));
-
- if (v)
- pr_debug("clockdomain: %s: wakeup dependency already "
-"set to wake up when %s wakes\n",
-clkdm->name, cd->clkdm->name);
-
- atomic_set(&cd->wkdep_usecount, (v) ? 1 : 0);
- }
-}
-
-/**
- * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
- * @clkdm: clockdomain to initialize sleepdep usecounts
- *
- * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
- * If a sleep dependency is present in the hardware, the usecount will be
- * set to 1; otherwise, it will be set to 0. Software should clear all
- * software sleep dependencies prior to calling this function if it wishes
- * to ensure that all usecounts start at 0. No return value.
- */
-static void _init_sleepdep_usecount(struct clockdomain *clkdm)
-{
- u32 v;
- struct clkdm_dep *cd;
-
- if (!cpu_is_omap34xx())
- return;
-
- if (!clkdm->sleepdep_srcs)
- return;
-
- for (cd = clkdm->sleepdep_srcs; cd->clkdm_name; cd++) {
- if (!omap_chip_is(cd->omap_chip))
- continue;
-
- if (!cd->clkdm && cd->clkdm_name)
- cd->clkdm = _clkdm_lookup(cd->clkdm_name);
-
- if (!cd->clkdm) {
- WARN(!cd->clkdm, "clockdomain: %s: sleepdep clkdm %s "
-"not found\n", clkdm->name, cd->clkdm_name);
- continue;
- }
-
- v = prm_read_mod_bits_shift(clkdm->pwrdm.ptr->prcm_offs,
- OMAP3430_CM_SLEEPDEP,
- (1 << cd->clkdm->dep_bit));
-
- if (v)
- pr_debug("clockdomain: %s: sleep dependency already "
-"set to prevent from idling until %s "
-"idles\n", clkdm->name, cd->clkdm->name);
-
- atomic_set(&cd->sleepdep_usecount, (v) ? 1 : 0);
- }
-};
-
/* Public functions */
/**
@@ -379,12 +288,17 @@ void clkdm_init(struct clockdomain **clkdms,
_autodep_lookup(autodep);
/*
-* Ensure that the *dep_usecount registers reflect the current
-* state of the PRCM.
+* Put all clockdomains into software-supervised mode; PM code
+* should later enable hardware-supervised mode as appropriate
*/
list_for_each_entry(clkdm, &cl
Re: [PATCH] nand/omap2: fix compile error with DMA Config
* Cliff Brake [100910 14:46]: > With CONFIG_MTD_NAND_OMAP_PREFETCH_DMA, there is a compile > error that this patch fixes. This should go via linux-mtd, can you please repost? Regards, Tony > Signed-off-by: Cliff Brake > --- > drivers/mtd/nand/omap2.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c > index 133d515..513e0a7 100644 > --- a/drivers/mtd/nand/omap2.c > +++ b/drivers/mtd/nand/omap2.c > @@ -413,7 +413,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info > *mtd, void *addr, > prefetch_status = gpmc_read_status(GPMC_PREFETCH_COUNT); > } while (prefetch_status); > /* disable and stop the PFPW engine */ > - gpmc_prefetch_reset(); > + gpmc_prefetch_reset(info->gpmc_cs); > > dma_unmap_single(&info->pdev->dev, dma_addr, len, dir); > return 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 -- 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] overo twl4030: fix twl4030 IRQ (used for usb otg detection)
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.
This patch fixes the TWL4030 IRQ mapping. The TWL4030 IRQ is used to signal USB
OTG
connection events. If this does not work, the USB OTG and peripheral modes
do not work.
GPIO112 mux is wrong in bootloader, too. In case the board uses an older
bootloader, we'll try to re-mux it in kernel (requires CONFIG_OMAP_MUX).
TWL4030 IRQ1 requires pull-up to be activated on GPIO112. If it is not
(bootloader did not do it and kernel has CONFIG_OMAP_MUX disabled)
the kernel would have a stuck interrupt. To avoid freeze, spurious interrupt
detection is added to TWL4030.
Signed-off-by: Anti Sullin
---
diff -pur linux-2.6.34/arch/arm/mach-omap2/board-overo.c
linux-2.6.34-ok/arch/arm/mach-omap2/board-overo.c
--- linux-2.6.34/arch/arm/mach-omap2/board-overo.c 2010-05-17
00:17:36.0 +0300
+++ linux-2.6.34-ok/arch/arm/mach-omap2/board-overo.c 2010-09-14
19:49:00.0 +0300
@@ -52,6 +52,7 @@
#define OVERO_GPIO_BT_XGATE15
#define OVERO_GPIO_W2W_NRESET 16
+#define OVERO_GPIO_TPS65950_IRQ112
#define OVERO_GPIO_PENDOWN 114
#define OVERO_GPIO_BT_NRESET 164
#define OVERO_GPIO_USBH_CPEN 168
@@ -353,7 +354,7 @@ static struct i2c_board_info __initdata
{
I2C_BOARD_INFO("tps65950", 0x48),
.flags = I2C_CLIENT_WAKE,
- .irq = INT_34XX_SYS_NIRQ,
+ .irq = OMAP_GPIO_IRQ(OVERO_GPIO_TPS65950_IRQ),
.platform_data = &overo_twldata,
},
};
@@ -422,6 +423,21 @@ static struct omap_musb_board_data musb_
static void __init overo_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+
+ /* Mux GPIO112 to pull-up input. In case bad bootloader is used,
+* override mux settings manually here.
+* Requires CONFIG_OMAP_MUX! */
+ omap_mux_set_gpio(OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP,
+ OVERO_GPIO_TPS65950_IRQ);
+
+ if ((gpio_request(OVERO_GPIO_TPS65950_IRQ, "TPS65950_IRQ") == 0) &&
+ (gpio_direction_input(OVERO_GPIO_TPS65950_IRQ) == 0)) {
+ gpio_export(OVERO_GPIO_TPS65950_IRQ, 0);
+ } else {
+ printk(KERN_ERR "could not obtain gpio for TPS65950 IRQ\n");
+ return;
+ }
+
overo_i2c_init();
platform_add_devices(overo_devices, ARRAY_SIZE(overo_devices));
omap_serial_init();
diff -pur linux-2.6.34/drivers/mfd/twl4030-irq.c
linux-2.6.34-ok/drivers/mfd/twl4030-irq.c
--- linux-2.6.34/drivers/mfd/twl4030-irq.c 2010-05-17 00:17:36.0
+0300
+++ linux-2.6.34-ok/drivers/mfd/twl4030-irq.c 2010-09-14 19:50:25.0
+0300
@@ -312,6 +312,14 @@ static int twl4030_irq_thread(void *data
continue;
}
+ /* Check for spurious interrupts */
+ if (!pih_isr) {
+ printk(KERN_ERR "Spurious TWL4030 interrupt"
+ " detected. Terminating %s.\n",
+ __func__);
+ break;
+ }
+
/* these handlers deal with the relevant SIH irq status */
local_irq_disable();
for (module_irq = twl4030_irq_base;
@@ -832,7 +840,7 @@ int twl4030_init_irq(int irq_num, unsign
init_completion(&irq_event);
- status = request_irq(irq_num, handle_twl4030_pih, IRQF_DISABLED,
+ status = request_irq(irq_num, handle_twl4030_pih, IRQF_TRIGGER_LOW |
IRQF_DISABLED,
"TWL4030-PIH", &irq_event);
if (status < 0) {
pr_err("twl4030: could not claim irq%d: %d\n", irq_num, status);
--
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 0/7] native wl1271 support on ZOOM
On Wed, Sep 15, 2010 at 6:34 PM, Tony Lindgren wrote: > * John W. Linville [100915 06:21]: >> On Wed, Sep 15, 2010 at 01:08:18PM +0200, Vitaly Wool wrote: >> > On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen wrote: >> > > On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen wrote: >> > >> This patchset adds wl1271 support on ZOOM2/3 boards. >> > > >> > > Tony, John, let me please suggest merging this through the wireless tree. >> > > >> > > wl1271 is a moving target - it keeps changing in the wireless tree and >> > > merging this patchset there will allow wl1271 developers to have >> > > everything in a single tree (and prevent merge conflicts in >> > > linux-next). >> > >> > Thanks Ohad, that's what I was about to suggest as well. :) >> >> OK, that is fine with me if the omap folks agree? > > Yes sounds good to me Great, I will rebase to wireless-testing an resubmit. > I think there's still at least some platform_data > conversation going on though. Last issue was resolved today with Russell's (and yours) latest answer. Thanks, Ohad. > > 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 v5 3/7] wireless: wl12xx: add platform data passing support
* Vitaly Wool [100915 01:18]: > 2010/9/15 Ohad Ben-Cohen : > >> Sorry for pushing at this, but why would you mark data that's meant to > >> be used after init phase as __initdata? > > > > I can remove the first copying as well if Russell is ok with it. > > I personally think it's not worth it. This copying basically happens > only once and this point is s irrelevant. My position therefore > is: let's get the current implementation in, and if Michal is > uncomfortable with that, he can come up with the patch. Let's > concentrate on the real problems. This becomes an issue when compiling in support for multiple boards.. All the data that's not in use for the booted board should be __initdata. 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/15] change default_llseek action
On Wednesday 15 September 2010, valdis.kletni...@vt.edu wrote: > Show Details > On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said: > > > This changes all instances of struct file_operations in > > the kernel to have a .llseek operation and then changes > > the default to no_llseek, which returns -ESPIPE, which > > is what we had decided some time ago in a discussion > > with Christoph Hellwig. > > I don't suppose there's any clean way to throw a build error or a > printk_on_once() or something if we encounter an unconverted 'struct > file_operations', is there? I have this creeping fear that this patch will go > upstream during the merge window - as will 12 new staging/ drivers from > authors > who didn't get the memo yet. > > Other than the "missed converting a new usage" issue, it looks OK to me. One advantage of the scripted approach is that I can run the script repeatedly, and send a patch after -rc1 fixing up all the new file operations. Moreover, any new drivers are by definition not regressions and staging drivers are expected to have issues. IIRC the most common llseek operation is 'noop_llseek', which usually means it should have been 'no_llseek' to start with, but since this has been in a released kernel, some random user application might expect a seek on that file to succeed without error. Arnd -- 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 0/7] native wl1271 support on ZOOM
* John W. Linville [100915 06:21]: > On Wed, Sep 15, 2010 at 01:08:18PM +0200, Vitaly Wool wrote: > > On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen wrote: > > > On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen wrote: > > >> This patchset adds wl1271 support on ZOOM2/3 boards. > > > > > > Tony, John, let me please suggest merging this through the wireless tree. > > > > > > wl1271 is a moving target - it keeps changing in the wireless tree and > > > merging this patchset there will allow wl1271 developers to have > > > everything in a single tree (and prevent merge conflicts in > > > linux-next). > > > > Thanks Ohad, that's what I was about to suggest as well. :) > > OK, that is fine with me if the omap folks agree? Yes sounds good to me, I think there's still at least some platform_data conversation going on though. 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] omap: Update omap3_defconfig to work with SMP_ON_UP
* Shilimkar, Santosh [100914 23:03]: > > > > Sounds like you're having these problems anyways and they > > are not related to the defconfigs? > > > Well the issues are because of defconfig but mostly fixable. > Will hold on my comments till I test the new defconfig on OMAP4. OK > > Considering Linus' earlier comments on the defconfigs, I don't > > see any reasonds not to merge this patch. If TI wants to fix up > > some other things, there's still about two weeks before -rc6. > > > Sure. I am just saying let's attempt to fix the remaining issues > and if it doesn't happen in next week, anyway this patch will > get merged. OK let's plan on doing that. > > > > - LOCAL_TIMERS hangs on omap4, disable it for now. > > > > > > This is expected on omap4 ES1.0 and hence not enabled > > > in the omap_4430sdp_defconfig. > > > > Maybe add a check for ES1.0 there to the init then? > > > Yes but its ARM generic code and I don't want to pollute it > with omap checks.. Will see if some other trick can fix this. Maybe in smp_twd.c return from twd_timer_setup early if twd_base is NULL? 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 v5 3/7] wireless: wl12xx: add platform data passing support
W dniu 15 września 2010 10:25 użytkownik Russell King - ARM Linux napisał: > On Mon, Sep 06, 2010 at 09:42:41PM +0200, Michał Mirosław wrote: >> W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux >> napisał: >> > On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote: >> >> 2010/9/1 Ohad Ben-Cohen : >> >> > Add a simple mechanism to pass platform data to the >> >> > SDIO instances of wl12xx. >> [cut patch] >> >> Why do you need all that copying? Isn't the data constant? >> > The first copy is to allow platforms to have their data marked with >> > __initdata. The second copy probably isn't necessary, but avoids >> > problems where the driver may decide to modify the platform data. >> Sorry for pushing at this, but why would you mark data that's meant to >> be used after init phase as __initdata? > Because you may have many instances of the data (due to multiple platform > support), and only need one of them at run-time. Ah. That makes sense. Thanks, Michał Mirosław -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] change default_llseek action
On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell wrote: > Hi Arnd, > > On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann wrote: >> >> Stephen, please add >> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek > > Added from today. > > Thanks for adding your subsystem tree as a participant of linux-next. As > you may know, this is not a judgment of your code. The purpose of > linux-next is for integration testing and to lower the impact of > conflicts between subsystems in the next merge window. > > You will need to ensure that the patches/commits in your tree/series have > been: > * submitted under GPL v2 (or later) and include the Contributor's > Signed-off-by, I should note this should say the code should be GPL-compatible, it doesn't need to be GPLv2 (or later). Furthermore the contributors of the subsystem respect the individual licenses of the files through the Developers Certificate of Origin, which tells the developers what the meaning of Signed-off-by means. Luis -- 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: OMAP3 DSP MMU fault + off mode issue
Venkii,
On Wed, Sep 15, 2010 at 9:12 PM, venki kaps wrote:
> Venkii,
> On Wed, Sep 15, 2010 at 8:02 PM, Kevin Hilman
> wrote:
>> venki kaps writes:
>>
>>> On Tue, Sep 14, 2010 at 8:54 PM, venki kaps wrote:
On Tue, Sep 14, 2010 at 1:28 AM, venki kaps wrote:
> Dear all,
>
> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel
> 2.6.32).
>
> The issue is describing as below mentioned way,
> 1). The Device is getting DSP MMU Fault when playing MP4 video
> clip.
>
> The system is not hitting off mode in the below scenario,
> 2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
> mode ---> Never hits off mode
>
> But surprisingly the system is hitting off mode in the below scenario,
> 3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
> Fault -> allow off mode ---> perfectly works
>
>
> - Could you please describe the root cause about the above issues 1 & 2?
> - How could solve the above issues?
I have found the issue with UART3.
In System configuration register (SYSC),-
IDLEMODE - Smart idle ---> working scenario -->
system hits off mode.
IDLEMODE - No idle ---> Non working scenario
--> system never hits off mode.
Could you please explain why UART3 is not able to hit smart idle after
DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
off ---> Never hits off mode).,
>>>
>>> My problem is resolved.GPtimer7 was not reset during the MMU FAULT
>>> occurrence before the first power cycle.
>>> So this pending interrupt is preventing the system sleep entry.
>>> Now it works fine after resetting Gptimer7 in pm suspend path.
>>
>> Sounds like a patch is needed for DSPBridge who manages that timer.
>
> Patchwork DSPBRIDGE: MMU-Fault debugging enhancements,
> https://patchwork.kernel.org/patch/91577/
> From the above patch, please see the below comment
> /*
> * Send a GP Timer interrupt to DSP
> * The DSP expects a GP timer interrupt after an
> * MMU-Fault Request GPTimer
> */
>
> The above changes allow for DSP task information to be printed
> by the MPU dspbridge when DSP MMU fault ocurrs.
>
> This above changes will be required during development.
> In my scenario, it is not required so i have just commented.
>
> Index: android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c
> ===
> --- android-2.6.32.9.orig/drivers/dsp/bridge/wmd/ue_deh.c
> 2010-08-24 18:19:19.0 +0900
> +++ android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c 2010-09-16
> 00:28:52.0 +0900
> @@ -285,7 +285,8 @@
> * The DSP expects a GP timer interrupt after an
> * MMU-Fault Request GPTimer
> */
> - if (timer) {
> + if (0) {
> omap_dm_timer_enable(timer);
> /* Enable overflow interrupt */
> omap_dm_timer_set_int_enable(timer,
>
In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging
enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE.
>> 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] tracing, perf: add more power related events
On Thu, Sep 9, 2010 at 9:54 AM, Ingo Molnar wrote: >> I think the ACPI tracepoints can be added on top of the proposed >> patch. Is that ok? > > Yeah - and the OMAP thing can be split up too if the OMAP folks prefer > it that way, but we still want to _see_ all the patches in this thread > together so that we have a critical mass of people interested in all > this ... Any chance to get the patch merged in? What is needed wrt to ACPI support? > > Thanks, > > Ingo Thanks, Jean -- 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: OMAP3 DSP MMU fault + off mode issue
Venkii,
On Wed, Sep 15, 2010 at 8:02 PM, Kevin Hilman
wrote:
> venki kaps writes:
>
>> On Tue, Sep 14, 2010 at 8:54 PM, venki kaps wrote:
>>> On Tue, Sep 14, 2010 at 1:28 AM, venki kaps wrote:
Dear all,
I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel
2.6.32).
The issue is describing as below mentioned way,
1). The Device is getting DSP MMU Fault when playing MP4 video clip.
The system is not hitting off mode in the below scenario,
2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off
mode ---> Never hits off mode
But surprisingly the system is hitting off mode in the below scenario,
3). System boot ->allow off mode ->play mp4 clip ->DSP MMU
Fault -> allow off mode ---> perfectly works
- Could you please describe the root cause about the above issues 1 & 2?
- How could solve the above issues?
>>>
>>> I have found the issue with UART3.
>>> In System configuration register (SYSC),-
>>> IDLEMODE - Smart idle ---> working scenario -->
>>> system hits off mode.
>>> IDLEMODE - No idle ---> Non working scenario
>>> --> system never hits off mode.
>>>
>>> Could you please explain why UART3 is not able to hit smart idle after
>>> DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow
>>> off ---> Never hits off mode).,
>>
>> My problem is resolved.GPtimer7 was not reset during the MMU FAULT
>> occurrence before the first power cycle.
>> So this pending interrupt is preventing the system sleep entry.
>> Now it works fine after resetting Gptimer7 in pm suspend path.
>
> Sounds like a patch is needed for DSPBridge who manages that timer.
Patchwork DSPBRIDGE: MMU-Fault debugging enhancements,
https://patchwork.kernel.org/patch/91577/
>From the above patch, please see the below comment
/*
* Send a GP Timer interrupt to DSP
* The DSP expects a GP timer interrupt after an
* MMU-Fault Request GPTimer
*/
The above changes allow for DSP task information to be printed
by the MPU dspbridge when DSP MMU fault ocurrs.
This above changes will be required during development.
In my scenario, it is not required so i have just commented.
Index: android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c
===
--- android-2.6.32.9.orig/drivers/dsp/bridge/wmd/ue_deh.c
2010-08-24 18:19:19.0 +0900
+++ android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c2010-09-16
00:28:52.0 +0900
@@ -285,7 +285,8 @@
* The DSP expects a GP timer interrupt after an
* MMU-Fault Request GPTimer
*/
- if (timer) {
+ if (0) {
omap_dm_timer_enable(timer);
/* Enable overflow interrupt */
omap_dm_timer_set_int_enable(timer,
> 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 00/15] change default_llseek action
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said: > This changes *all* instances of struct file_operations in > the kernel to have a .llseek operation and then changes > the default to no_llseek, which returns -ESPIPE, which > is what we had decided some time ago in a discussion > with Christoph Hellwig. I don't suppose there's any clean way to throw a build error or a printk_on_once() or something if we encounter an unconverted 'struct file_operations', is there? I have this creeping fear that this patch will go upstream during the merge window - as will 12 new staging/ drivers from authors who didn't get the memo yet. Other than the "missed converting a new usage" issue, it looks OK to me. pgpxEkcNJDXEM.pgp Description: PGP signature
RE: OMAP3 DSP MMU fault + off mode issue
venki kaps wrote: ... > > My problem is resolved.GPtimer7 was not reset during the MMU FAULT > occurrence before the first power cycle. So this pending interrupt is > preventing the system sleep entry. > Now it works fine after resetting Gptimer7 in pm suspend path. > That's doesn't sound right, why the problem is not occurring after the first suspend-resume cycle. DSP is in charge of clearing the overflow interrupt and if it is doing it after the first transition to Core OFF, why wouldn't be doing it for the first one. Moreover from the logs sent internally (since it is the same issue and oddly the same resolution), the trace log dump printed is generated in the dsp after clearing the interrupts, so the problem could be the gptimer is configured to autoreload instead of oneshoot or the dsp write is not posted to clear the interrupt (which might be valid issues), but also they could happen after the first transition to OFF. I'm sorry if I didn't ask you for logs but I was seeing this issue internally (and assumed you'll be in the same team of people :)), and given that more information was posted there than here..., but still, if available send the changes you have made. Regards, Omar -- 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 v4 00/10] split out emac cpdma and mdio for reuse
Cyril Chemparathy writes: > Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine. > These hardware modules are not restricted to EMAC device alone. For example, > CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules > internally. This patch series separates out EMAC's MDIO and CPDMA > functionality, allowing these individual pieces to be reused across TI > hardware. [...] > Changes from v3 (rolled in "post cpdma/mdio refactoring fixes" series): > 1. allow forced 100/full mode instead of phy auto-detect > 2. specify phy_id on boards that had a phy_mask defined earlier > 3. requeue cpdma descriptors when EOQ at submit > 4. use calculated mdio bus access times instead of hardcoded delays > 5. work around emac soft-reset impact on mdio controller state > 6. extend register dumps to include cpdma registers > 7. updated sign offs and acks Thanks Cyril for one more spin with these updates. Queuing this one for 2.6.37 in davinci-next. davinci git is now updated with this series (may take a bit to propagate to kernel.org mirrors though) 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
[PATCH] omap mmc: extended to pass host capabilities from board file
wires variable is renamed, extended and this single variable to be used to
pass the platform capabilities, e.g DDR mode. Also removed the hardcoded
value was using as bus-width.
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-2430sdp.c |3 ++-
arch/arm/mach-omap2/board-3430sdp.c |5 +++--
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/board-cm-t35.c |5 +++--
arch/arm/mach-omap2/board-devkit8000.c |3 ++-
arch/arm/mach-omap2/board-igep0020.c |5 +++--
arch/arm/mach-omap2/board-ldp.c |3 ++-
arch/arm/mach-omap2/board-n8x0.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |3 ++-
arch/arm/mach-omap2/board-omap3evm.c |3 ++-
arch/arm/mach-omap2/board-omap3pandora.c |7 ---
arch/arm/mach-omap2/board-omap3stalker.c |3 ++-
arch/arm/mach-omap2/board-omap3touchbook.c |3 ++-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-overo.c|5 +++--
arch/arm/mach-omap2/board-rx51-peripherals.c |5 +++--
arch/arm/mach-omap2/board-zoom-peripherals.c |5 +++--
arch/arm/mach-omap2/devices.c| 16 +---
arch/arm/mach-omap2/hsmmc.c | 16 ++--
arch/arm/mach-omap2/hsmmc.h |3 ++-
arch/arm/plat-omap/include/plat/mmc.h|7 +++
drivers/mmc/host/omap.c |2 +-
drivers/mmc/host/omap_hsmmc.c| 18 ++
23 files changed, 67 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 8538e41..fc178a0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -190,7 +191,7 @@ static int __init omap2430_i2c_init(void)
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.mmc= 1,
- .wires = 4,
+ .caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ext_clock = 1,
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 67b95b5..3eb9839 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -353,12 +354,12 @@ static struct omap2_hsmmc_info mmc[] = {
/* 8 bits (default) requires S6.3 == ON,
* so the SIM card isn't used; else 4 bits.
*/
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 4,
},
{
.mmc= 2,
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 7,
},
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..e379bef 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -193,12 +193,12 @@ static struct omap_musb_board_data musb_board_data = {
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
- .wires = 8,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable = true,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e10bc10..b72009a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -579,14 +580,14 @@ static struct twl4030_keypad_data cm_t35_kp_data = {
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
- .wires = 4,
+ .caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
- .wires = 4,
+ .caps = MMC_CAP_4_BIT_DATA,
.transceiver= 1,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/
Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs
Hi Wim,
"Varadarajan, Charulatha" writes:
> 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 V
With your ack, I'll be glad to merge this via the OMAP tree since it
depends on the rest of the series for the OMAP platform specific
changes.
Kevin
> ---
> 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 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -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 http://vger.kernel.org/majordomo-info.html
Re: OMAP3 DSP MMU fault + off mode issue
venki kaps writes: > On Tue, Sep 14, 2010 at 8:54 PM, venki kaps wrote: >> On Tue, Sep 14, 2010 at 1:28 AM, venki kaps wrote: >>> Dear all, >>> >>> I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel >>> 2.6.32). >>> >>> The issue is describing as below mentioned way, >>> 1). The Device is getting DSP MMU Fault when playing MP4 video clip. >>> >>> The system is not hitting off mode in the below scenario, >>> 2). System boot ->play mp4 clip ->DSP MMU Fault -> allow off >>> mode ---> Never hits off mode >>> >>> But surprisingly the system is hitting off mode in the below scenario, >>> 3). System boot ->allow off mode ->play mp4 clip ->DSP MMU >>> Fault -> allow off mode ---> perfectly works >>> >>> >>> - Could you please describe the root cause about the above issues 1 & 2? >>> - How could solve the above issues? >> >> I have found the issue with UART3. >> In System configuration register (SYSC),- >> IDLEMODE - Smart idle ---> working scenario --> >> system hits off mode. >> IDLEMODE - No idle ---> Non working scenario >> --> system never hits off mode. >> >> Could you please explain why UART3 is not able to hit smart idle after >> DSP MMU fault ( System boot ->play mp4 clip ->DSP MMU Fault -> allow >> off ---> Never hits off mode)., > > My problem is resolved.GPtimer7 was not reset during the MMU FAULT > occurrence before the first power cycle. > So this pending interrupt is preventing the system sleep entry. > Now it works fine after resetting Gptimer7 in pm suspend path. Sounds like a patch is needed for DSPBridge who manages that timer. 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
[PATCH v4 05/10] davinci: cleanup mdio arch code and switch to phy_id
This patch removes davinci architecture code that has now been rendered useless by the previous patches in the MDIO separation series. In addition, the earlier phy_mask definitions have been replaced with corresponding phy_id definitions. Signed-off-by: Cyril Chemparathy Tested-by: Michael Williamson Tested-by: Caglar Akyuz --- arch/arm/mach-davinci/board-da830-evm.c |7 ++- arch/arm/mach-davinci/board-da850-evm.c |7 ++- arch/arm/mach-davinci/board-dm365-evm.c |7 ++- arch/arm/mach-davinci/board-dm644x-evm.c|8 ++-- arch/arm/mach-davinci/board-dm646x-evm.c|7 ++- arch/arm/mach-davinci/board-mityomapl138.c |8 ++-- arch/arm/mach-davinci/board-neuros-osd2.c |7 ++- arch/arm/mach-davinci/board-sffsdr.c|7 ++- arch/arm/mach-davinci/devices-da8xx.c |2 -- arch/arm/mach-davinci/dm365.c |1 - arch/arm/mach-davinci/dm644x.c |1 - arch/arm/mach-davinci/dm646x.c |1 - arch/arm/mach-davinci/include/mach/dm365.h |1 - arch/arm/mach-davinci/include/mach/dm644x.h |1 - arch/arm/mach-davinci/include/mach/dm646x.h |1 - 15 files changed, 16 insertions(+), 50 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index ef1ab0b..1bb89d3 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -31,9 +31,7 @@ #include #include -#define DA830_EVM_PHY_MASK 0x0 -#define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */ - +#define DA830_EVM_PHY_ID "" /* * USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4]. */ @@ -558,9 +556,8 @@ static __init void da830_evm_init(void) da830_evm_usb_init(); - soc_info->emac_pdata->phy_mask = DA830_EVM_PHY_MASK; - soc_info->emac_pdata->mdio_max_freq = DA830_EVM_MDIO_FREQUENCY; soc_info->emac_pdata->rmii_en = 1; + soc_info->emac_pdata->phy_id = DA830_EVM_PHY_ID; ret = davinci_cfg_reg_list(da830_cpgmac_pins); if (ret) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index ac2297c..5e435b0 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -38,9 +38,7 @@ #include #include -#define DA850_EVM_PHY_MASK 0x1 -#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */ - +#define DA850_EVM_PHY_ID "0:00" #define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8) #define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15) @@ -678,8 +676,7 @@ static int __init da850_evm_config_emac(void) /* Enable/Disable MII MDIO clock */ gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en); - soc_info->emac_pdata->phy_mask = DA850_EVM_PHY_MASK; - soc_info->emac_pdata->mdio_max_freq = DA850_EVM_MDIO_FREQUENCY; + soc_info->emac_pdata->phy_id = DA850_EVM_PHY_ID; ret = da8xx_register_emac(); if (ret) diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index bdea2da..a06b84c 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -54,9 +54,7 @@ static inline int have_tvp7002(void) return 0; } -#define DM365_EVM_PHY_MASK (0x2) -#define DM365_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */ - +#define DM365_EVM_PHY_ID "0:01" /* * A MAX-II CPLD is used for various board control functions. */ @@ -535,8 +533,7 @@ fail: /* ... and ENET ... */ dm365evm_emac_configure(); - soc_info->emac_pdata->phy_mask = DM365_EVM_PHY_MASK; - soc_info->emac_pdata->mdio_max_freq = DM365_EVM_MDIO_FREQUENCY; + soc_info->emac_pdata->phy_id = DM365_EVM_PHY_ID; resets &= ~BIT(3); /* ... and AIC33 */ diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 65bb940..44a2f0a 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -39,9 +39,7 @@ #include #include -#define DM644X_EVM_PHY_MASK(0x2) -#define DM644X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */ - +#define DM644X_EVM_PHY_ID "0:01" #define LXT971_PHY_ID (0x001378e2) #define LXT971_PHY_MASK(0xfff0) @@ -707,9 +705,7 @@ static __init void davinci_evm_init(void) davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); - soc_info->emac_pdata->phy_mask = DM644X_EVM_PHY_MASK; - soc_info->emac_pdata->mdio_max_freq = DM644X_EVM_MDIO_FREQUENCY; - + soc_info->emac_pdata->phy_id = DM644X_EVM_PHY_ID; /* Register the fixup for PHY on DaVinci */ phy_regist
[PATCH v4 02/10] davinci: add mdio platform devices
This patch adds mdio platform devices on SoCs that have the necessary
hardware. Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock. Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.
Signed-off-by: Cyril Chemparathy
Acked-by: David S. Miller
Tested-by: Michael Williamson
Tested-by: Caglar Akyuz
---
arch/arm/mach-davinci/devices-da8xx.c | 29 +-
arch/arm/mach-davinci/dm365.c | 22 +++-
arch/arm/mach-davinci/dm644x.c | 22 +++-
arch/arm/mach-davinci/dm646x.c | 21 ++-
arch/arm/mach-davinci/include/mach/dm365.h |1 +
arch/arm/mach-davinci/include/mach/dm644x.h |1 +
arch/arm/mach-davinci/include/mach/dm646x.h |1 +
7 files changed, 92 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index caeb7f4..9039221 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -352,7 +352,7 @@ int __init da8xx_register_watchdog(void)
static struct resource da8xx_emac_resources[] = {
{
.start = DA8XX_EMAC_CPPI_PORT_BASE,
- .end= DA8XX_EMAC_CPPI_PORT_BASE + 0x5000 - 1,
+ .end= DA8XX_EMAC_CPPI_PORT_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -396,9 +396,34 @@ static struct platform_device da8xx_emac_device = {
.resource = da8xx_emac_resources,
};
+static struct resource da8xx_mdio_resources[] = {
+ {
+ .start = DA8XX_EMAC_MDIO_BASE,
+ .end= DA8XX_EMAC_MDIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device da8xx_mdio_device = {
+ .name = "davinci_mdio",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(da8xx_mdio_resources),
+ .resource = da8xx_mdio_resources,
+};
+
int __init da8xx_register_emac(void)
{
- return platform_device_register(&da8xx_emac_device);
+ int ret;
+
+ ret = platform_device_register(&da8xx_mdio_device);
+ if (ret < 0)
+ return ret;
+ ret = platform_device_register(&da8xx_emac_device);
+ if (ret < 0)
+ return ret;
+ ret = clk_add_alias(NULL, dev_name(&da8xx_mdio_device.dev),
+ NULL, &da8xx_emac_device.dev);
+ return ret;
}
static struct resource da830_mcasp1_resources[] = {
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6b6f4c6..71f0f9d 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -699,7 +699,7 @@ static struct emac_platform_data dm365_emac_pdata = {
static struct resource dm365_emac_resources[] = {
{
.start = DM365_EMAC_BASE,
- .end= DM365_EMAC_BASE + 0x47ff,
+ .end= DM365_EMAC_BASE + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
{
@@ -734,6 +734,21 @@ static struct platform_device dm365_emac_device = {
.resource = dm365_emac_resources,
};
+static struct resource dm365_mdio_resources[] = {
+ {
+ .start = DM365_EMAC_MDIO_BASE,
+ .end= DM365_EMAC_MDIO_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_mdio_device = {
+ .name = "davinci_mdio",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(dm365_mdio_resources),
+ .resource = dm365_mdio_resources,
+};
+
static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_VDINT0]= 2,
[IRQ_VDINT1]= 6,
@@ -1220,7 +1235,12 @@ static int __init dm365_init_devices(void)
davinci_cfg_reg(DM365_INT_EDMA_CC);
platform_device_register(&dm365_edma_device);
+
+ platform_device_register(&dm365_mdio_device);
platform_device_register(&dm365_emac_device);
+ clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
+ NULL, &dm365_emac_device.dev);
+
/* Add isif clock alias */
clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
platform_device_register(&dm365_vpss_device);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 40fec31..c103b2c 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -330,7 +330,7 @@ static struct emac_platform_data dm644x_emac_pdata = {
static struct resource dm644x_emac_resources[] = {
{
.start = DM644X_EMAC_BASE,
- .end= DM644X_EMAC_BASE + 0x47ff,
+ .end= DM644X_EMAC_BASE + SZ_16K - 1,
.flags = IORESOURC
