[PATCH 0/1] Fix HW SAVEANDRESTORE shift define
Here's a patch that fixes a bug in enabling and disabling hardware save-and-restore functionality in powerdomain.c code. This affects power management, as it also fixes a hw bug in off-mode, but I think this should be applied directly to linux-omap. As this part of code is already there and its setting up wrong bits in PM_PWSTCTRL registers. Kalle Jokiniemi (1): ARM: OMAP3: Fix HW SAVEANDRESTORE shift define -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: Fix HW SAVEANDRESTORE shift define
The OMAP3430ES2_SAVEANDRESTORE_SHIFT macro is used by powerdomain code in "1 << OMAP3430ES2_SAVEANDRESTORE_SHIFT" manner, but the definition was also (1 << 4), meaning we actually modified bit 16. So the definition needs to be 4. This fixes also a cold reset HW bug in OMAP3430 ES3.x where some of the efuse bits are not isolated during wake-up from off mode. This can cause randomish cold resets with off mode. Enabling the USBTLL hardware SAVEANDRESTORE causes the core power up assert to be delayed in a way that we will not get faulty values when boot ROM is reading the unisolated registers. Signed-off-by: Kalle Jokiniemi --- arch/arm/mach-omap2/prm-regbits-34xx.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h index d73eee8..d792c29 100644 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h @@ -409,7 +409,7 @@ /* PM_PREPWSTST_CAM specific bits */ /* PM_PWSTCTRL_USBHOST specific bits */ -#define OMAP3430ES2_SAVEANDRESTORE_SHIFT (1 << 4) +#define OMAP3430ES2_SAVEANDRESTORE_SHIFT 4 /* RM_RSTST_PER specific bits */ -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29... for real this time
"Premi, Sanjeev" writes: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >> Sent: Thursday, March 26, 2009 4:26 AM >> To: linux-omap@vger.kernel.org >> Subject: PM branch rebased to 2.6.29... for real this time >> >> Hello, >> >> The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is >> out, I've rebased the PM brach onto linux-omap HEAD just after the >> 2.6.29 merge. >> >> Minimal retention and off-mode on Beagle and RX51. > > Another problem that I found on OMAP3EVM: > > When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), > the kernel did not boot-up. The last few statements are: There are known problems with CPUfreq on top of the new clock notifiers series. I am waiting for Rajendra to re-send his series which removes the virt clocks on top of the latest PM branch. > <3>clock: dpll5_ck failed transition to 'locked' > clock: dpll5_ck failed transition to 'locked' > <6>Disabling unused clock "dpll4_m6x2_ck" > Disabling unused clock "dpll4_m6x2_ck" > <6>Disabling unused clock "dpll3_m3x2_ck" > Disabling unused clock "dpll3_m3x2_ck" > <6>Disabling unused clock "sys_clkout1" > Disabling unused clock "sys_clkout1" > > The PC is at the WFI statement. > > Tried other combinations as well: > > 1) only CPUidle enabled - okay. > 2) only CPUfreq enabled - not okay. > Sounds to me like CPUfreq is changing frequencies during bootup. Did you select ondemand as the default CPUfreq governor? If so, can you try with performance as the default governor. If you're already using performance, then u-boot is setting a slower speed and CPUfreq may decide to change it during boot. If so, can you try the userspace governor as the default governor. This should prevent any automatic CPUFreq changes during bootup. 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: PM branch rebased to 2.6.29
Russ Dill writes: [...] > > r...@beagleboard:/sys/power# echo 1 > clocks_off_while_idle > r...@beagleboard:/sys/power# echo 1 > enable_off_mode > r...@beagleboard:/sys/power# echo 1 > voltage_off_while_idle > r...@beagleboard:/sys/power# echo mem > state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Suspending console(s) (use no_console_suspend to debug) > omapfb omapfb: timeout waiting for FRAME DONE > Successfully put all powerdomains to target state > Restarting tasks ... done. > > Neato :) This is still with all the user processes running an with a > NAND filesystem. I'm still getting rather high ~8...@5v power > consumption, so I'll need to further investigate what rails the > twl4030 is actually turning off. Great! glad it worked for you. The kernel has some work to do to be sure that *everything* is properly init'd to allow proper idle states. Until then, unfortunately we have to rely on more gentle bootloaders. And FWIW, on my Beagle, I've never seen < 80mA either, but I haven't done any further digging. 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: PM branch rebased to 2.6.29
On Tue, Mar 31, 2009 at 4:33 PM, Kevin Hilman wrote: > Russ Dill writes: > >>> Russ, >>> >>> With the dump below, what was the output after you resumed? Which >>> powerdomains did not hit their target state? It looks like PER and >>> CORE did not hit target state. >> >> yes, yes, and yes. >> >>> Also, you didn't mention what hardware you're using or your .config or >>> your bootloader etc. All of these play an important role. >> >> Beagleboard B7, X-Loader 1.41, U-Boot 1.3.3 > > Not familiar with the all u-boot versions for this board, but is this > u-boot out of Steve Sakoman's tree? I had lots of problems with the > TI bootloader leaving Beagle in a strange state and switched to using > the one from Steve's tree. I have X-Loader 1.41 and: > > U-Boot 2009.01-rc1-00067-g8c6db17 (Jan 15 2009 - 16:31:00) I've updated: U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31) >>> >>> Here is at least one problem. >>> >>> Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the >>> source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK >>> is used as the timer source. >>> >>> Based on this, you must have: >>> >>> System Type --> TI OMAP Implementations --> System Timer >>> >>> set to 'MPU timer'. Please change to 32k timer. Using MPU timer will >>> keep timers not in WKUP powerdomain (which is all of them except GPT1) >>> running across suspend, preventing PER from hitting RET. >>> >>> Using the 32k timer only uses GPT1 and sources it from the 32k clock, both >>> of which are in the WKUP powerdomain. >> >> Nope, I have the following kernel message: >> >> OMAP clockevent source: GPTIMER12 at 32768 Hz >> >> and the following Kconfig options (also see the attached .config) > > Right, I forgot Beagle is using GPT12, not GPT1. nevermind. > >> Texas Instruments X-Loader 1.41 >> Starting OS Bootloader... >> >> >> U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) > > First recommendation is to upgrade your bootloder: > > http://elinux.org/BeagleBoard#U-Boot > > The earlier bootloaders seem to be blindly enabling reserved bits in > some of the PM registers which can leave the chip in an undefined > state. > >> OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz >> OMAP3 Beagle Board + LPDDR/NAND >> DRAM: 128 MB >> NAND: 256 MiB >> In: serial >> Out: serial >> Err: serial >> Audio Tone on Speakers ... complete >> Hit any key to stop autoboot: 0 >> >> NAND read: device 0 offset 0x28, size 0x40 >> 4194304 bytes read: OK >> ## Booting kernel from Legacy Image at 8000 ... >> Image Name: Linux-2.6.29-omap1-pm >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 1476992 Bytes = 1.4 MB >> Load Address: 80008000 >> Entry Point: 80008000 >> Verifying Checksum ... OK >> Loading Kernel Image ... OK >> OK >> >> Starting kernel ... >> >> Uncompressing >> Linux >> done, booting the kern. >> Linux version 2.6.29-omap1-pm (r...@russ-laptop) (gcc version 4.3.1 >> (GCC) ) #47 PREEMPT Tue Mar 31 14:13:51 MST 2009 >> CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f >> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache >> Machine: OMAP3 Beagle Board >> Memory policy: ECC disabled, Data cache writeback >> OMAP3430 ES3.0 >> SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 >> Kernel command line: console=ttyS2,115200n8 root=/dev/mtdblock4 >> rootfstype=jffs2 rw g_ether.host_addr=B6:A3:A1:7D:8F:F0 >> omapfb.mode=dvi:126 >> Unknown boot option `g_ether.host_addr=B6:A3:A1:7D:8F:F0': ignoring >> Unknown boot option `omapfb.mode=dvi:1280x720M-16': ignoring >> Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz >> Reprogramming SDRC >> GPMC revision 5.0 >> IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts >> Total of 96 interrupts on 1 active controller >> OMAP34xx GPIO hardware version 2.5 >> PID hash table entries: 512 (order: 9, 2048 bytes) >> OMAP clockevent source: GPTIMER12 at 32768 Hz >> Console: colour dummy device 80x30 >> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) >> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) >> Memory: 128MB = 128MB total >> Memory: 126648KB available (2692K code, 299K data, 96K init) >> Calibrating delay loop... 491.57 BogoMIPS (lpj=1921024) >> Mount-cache hash table entries: 512 >> CPU: Testing write buffer coherency: ok >> net_namespace: 544 bytes >> regulator: core version 0.5 >> NET: Registered protocol family 16 >> Found NAND on CS0 >> Registering NAND on CS0 >> OMAP DMA hardware revision 4.0 >> bio: create slab at 0 >> i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz >> twl4030: PIH (irq 7) chaining IRQs 368..375 >> twl4030: power (irq 373) chaining IRQs 376..383 >> twl4030: gpio (irq 368) chaining IRQs 384..401 >> beagle_twl_gpio_setup:145 >> twl4030_mmc_init:324 >> twl4030_mmc_
RE: [PATCH 1/4] [OMAPZOOM] [UPDATE]DSPBRIDGE: Memory lock for DMM.
Hi,
New update of this patch with the comments from Ameya Palande about
some build warnings.
>From a5ab7e038b72e62358279ef3c4e64b2f260c Mon Sep 17 00:00:00 2001
From: Hari Kanigeri
Date: Thu, 26 Mar 2009 15:47:50 -0500
Subject: [PATCH] DSPBRIDGE: Memory lock for DMM.
Lock down the pages that are mapped to DSP virtual memory to prevent from
getting swapped out
Signed-off-by: Hari Kanigeri
---
arch/arm/plat-omap/include/dspbridge/dbdefs.h |3 +
drivers/dsp/bridge/hw/hw_mmu.h|1 +
drivers/dsp/bridge/wmd/io_sm.c| 24 +++--
drivers/dsp/bridge/wmd/tiomap3430.c | 133 +++-
4 files changed, 144 insertions(+), 17 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbdefs.h
b/arch/arm/plat-omap/include/dspbridge/dbdefs.h
index 7f5a2bf..9782693 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbdefs.h
@@ -571,6 +571,9 @@ bit 6 - MMU element size = 64bit (valid only for non mixed
page entries)
#define DSP_MAPVMALLOCADDR 0x0080
+#define DSP_MAPDONOTLOCK 0x0100
+
+
#define GEM_CACHE_LINE_SIZE 128
#define GEM_L1P_PREFETCH_SIZE 128
diff --git a/drivers/dsp/bridge/hw/hw_mmu.h b/drivers/dsp/bridge/hw/hw_mmu.h
index 065f0dd..b1e2458 100644
--- a/drivers/dsp/bridge/hw/hw_mmu.h
+++ b/drivers/dsp/bridge/hw/hw_mmu.h
@@ -51,6 +51,7 @@ struct HW_MMUMapAttrs_t {
enum HW_Endianism_t endianism;
enum HW_ElementSize_t elementSize;
enum HW_MMUMixedSize_t mixedSize;
+ bool donotlockmpupage;
} ;
extern HW_STATUS HW_MMU_Enable(const void __iomem *baseAddress);
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index bd936eb..301bd72 100755
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -553,6 +553,8 @@ func_cont1:
mapAttrs = DSP_MAPLITTLEENDIAN;
mapAttrs |= DSP_MAPPHYSICALADDR;
mapAttrs |= DSP_MAPELEMSIZE32;
+ mapAttrs |= DSP_MAPDONOTLOCK;
+
while (numBytes && DSP_SUCCEEDED(status)) {
/* To find the max. page size with which both PA & VA are
* aligned */
@@ -690,18 +692,18 @@ func_cont:
mapAttrs = DSP_MAPLITTLEENDIAN;
mapAttrs |= DSP_MAPPHYSICALADDR;
mapAttrs |= DSP_MAPELEMSIZE32;
+ mapAttrs |= DSP_MAPDONOTLOCK;
+
/* Map the L4 peripherals */
- {
- i = 0;
- while (L4PeripheralTable[i].physAddr && DSP_SUCCEEDED(status)) {
- status = hIOMgr->pIntfFxns->pfnBrdMemMap
- (hIOMgr->hWmdContext,
- L4PeripheralTable[i].physAddr,
- L4PeripheralTable[i].dspVirtAddr,
- HW_PAGE_SIZE_4KB, mapAttrs);
- DBC_Assert(DSP_SUCCEEDED(status));
- i++;
- }
+ i = 0;
+ while (L4PeripheralTable[i].physAddr && DSP_SUCCEEDED(status)) {
+ status = hIOMgr->pIntfFxns->pfnBrdMemMap
+ (hIOMgr->hWmdContext, L4PeripheralTable[i].physAddr,
+ L4PeripheralTable[i].dspVirtAddr, HW_PAGE_SIZE_4KB,
+ mapAttrs);
+ if (DSP_FAILED(status))
+ break;
+ i++;
}
if (DSP_SUCCEEDED(status)) {
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 983465a..c9849e3 100755
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -28,6 +28,8 @@
/* --- Host OS */
#include
+#include
+#include
#include "../arch/arm/mach-omap2/prcm-regs.h"
#include "../arch/arm/mach-omap2/cm-regbits-34xx.h"
#include "../arch/arm/mach-omap2/ti-compat.h"
@@ -90,6 +92,7 @@
#define MMU_LARGE_PAGE_MASK 0x
#define MMU_SMALL_PAGE_MASK 0xF000
#define PAGES_II_LVL_TABLE 512
+#define phys_to_page(phys) pfn_to_page((phys) >> PAGE_SHIFT)
#define MMU_GFLUSH 0x60
@@ -1372,6 +1375,11 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
return DSP_EINVALIDARG;
}
}
+ if (attrs & DSP_MAPDONOTLOCK)
+ hwAttrs.donotlockmpupage = 1;
+ else
+ hwAttrs.donotlockmpupage = 0;
+
if (attrs & DSP_MAPVMALLOCADDR) {
status = MemMapVmalloc(hDevContext, ulMpuAddr, ulVirtAddr,
ulNumBytes, ulMapAttr);
@@ -1488,12 +1496,20 @@ static DSP_STATUS WMD_BRD_MemUnMap(struct
WMD_DEV_CONTEXT *hDevContext,
u32 remBytes;
u32 remBytesL2;
u32 vaCurr;
+ struct page *pg = NULL;
DSP_STATUS status = DSP_SOK;
struct WMD_DEV_CONTEXT *pDevContext = hDevContext;
Re: [PATCH 3/3] ARM: OMAP3: Enable IO-CHAIN wakeup
Kalle Jokiniemi writes:
> OMAP 3430 ES3.1 chips have a separate bit for IO daisy-chain
> wake up enabling. It needs to be enabled when entering
> retention or off state, otherwise waking up might not work
> in all situations.
>
> Signed-off-by: Kalle Jokiniemi
Thanks, pushed after...
> ---
> arch/arm/mach-omap2/pm34xx.c | 37 +--
> arch/arm/mach-omap2/prm-regbits-34xx.h |2 +
> 2 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7bbbcce..4345df1 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -101,6 +101,34 @@ static inline void omap3_per_restore_context(void)
> omap3_gpio_restore_context();
> }
>
> +static void omap3_enable_io_chain(void)
> +{
> + int timeout = 0;
> +
> + if (omap_rev() >= OMAP3430_REV_ES3_1) {
> + prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN, WKUP_MOD, PM_WKEN);
> + /* Do a readback to assure write has been done */
> + prm_read_mod_reg(WKUP_MOD, PM_WKEN);
> +
> + while (!(prm_read_mod_reg(WKUP_MOD, PM_WKST) &
> + OMAP3430_ST_IO_CHAIN)) {
> + timeout++;
> + if (timeout > 1000) {
> + printk(KERN_ERR "Wake up daisy chain "
> + "activation failed.\n");
> + return;
> + }
> + prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN, WKUP_MOD, PM_WKST);
fixing this screwy indent.
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 2/3] ARM: OMAP3: Fix secure sram saving
Kalle Jokiniemi writes:
> The secure sram context save uses dma channels 0 and 1.
> In order to avoid collision between kernel DMA transfers and
> ROM code dma transfers, we need to reserve DMA channels 0
> 1 on high security devices.
>
> A bug in ROM code leaves dma irq status bits uncleared.
> Hence those irq status bits need to be cleared when restoring
> DMA context after off mode.
>
> There was also a faulty parameter given to PPA in the secure
> ram context save assembly code, which caused interrupts to
> be enabled during secure ram context save. This caused the
> save to fail sometimes, which resulted the saved context
> to be corrupted, but also left DMA channels in secure mode.
> The secure mode DMA channels caused "DMA secure error with
> device 0" errors to be displayed.
>
> Signed-off-by: Kalle Jokiniemi
> Signed-off-by: Jouni Hogander
Thanks, pushing after fixing this minor checkpatch warning:
WARNING: braces {} are not necessary for single statement blocks
#82: FILE: arch/arm/plat-omap/dma.c:2337:
+ if (cpu_is_omap34xx() && (omap_type() != OMAP2_DEVICE_TYPE_GP)) {
+ dma_write(0x3 , IRQSTATUS_L0);
+ }
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM:OMAP3: Enable SDRC workaround for ES3.1
Kalle Jokiniemi writes: > Enable a workaround to manually restart the SDRC > auto-refresh after wake-up from off mode also on > ES3.1 silicon revision chips. > > Signed-off-by: Kalle Jokiniemi Thanks, pushing to PM branch. 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 2/2] OMAP3: PM: Invoke omap3_save_scratchpad_contents() only once at boot time
Kim Kyuwon writes:
> If CONFIG_CPU_IDLE is y, omap3_save_scratchpad_contents() is called
> twice at boot time. This patch let it be invoked only once.
>
> Signed-off-by: Kim Kyuwon
Thanks, pushing to PM branch.
Kevin
> ---
> arch/arm/mach-omap2/cpuidle34xx.c |2 --
> arch/arm/mach-omap2/pm34xx.c |5 ++---
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index a5eba31..056fb5f 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -271,8 +271,6 @@ int omap3_idle_init(void)
> struct cpuidle_state *state;
> struct cpuidle_device *dev;
>
> - omap3_save_scratchpad_contents();
> -
> mpu_pd = pwrdm_lookup("mpu_pwrdm");
> core_pd = pwrdm_lookup("core_pwrdm");
> per_pd = pwrdm_lookup("per_pwrdm");
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index ff9f28d..001baa9 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -967,6 +967,8 @@ int __init omap3_pm_init(void)
> #endif /* CONFIG_SUSPEND */
>
> pm_idle = omap3_pm_idle;
> +
> + omap3_save_scratchpad_contents();
> omap3_idle_init();
>
> pwrdm_add_wkdep(neon_pwrdm, mpu_pwrdm);
> @@ -984,10 +986,7 @@ int __init omap3_pm_init(void)
> if (!omap3_secure_ram_storage)
> printk(KERN_ERR "Memory allocation failed when"
> "allocating for secure sram context\n");
> - }
> - omap3_save_scratchpad_contents();
>
> - if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> local_irq_disable();
> local_fiq_disable();
>
> --
> 1.5.2.5
>
>
> --
> Kim Kyuwon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3: PM: Fix compile error with 'CONFIG_OMAP_PM_SRF=y'
Kim Kyuwon writes: > This patch fixes below compile error. The header file > 'mach/omap34xx.h' declared all needed symbols. > > CC arch/arm/mach-omap2/pm.o > CC arch/arm/mach-omap2/resource34xx.o > arch/arm/mach-omap2/resource34xx.c: In function 'resource_access_opp_lock': > arch/arm/mach-omap2/resource34xx.c:174: error: 'VDD1_OPP' undeclared > (first use in this function) > arch/arm/mach-omap2/resource34xx.c:177: error: 'VDD2_OPP' undeclared > (first use in this function) > arch/arm/mach-omap2/resource34xx.c:209: error: 'MAX_VDD1_OPP' > undeclared (first use in this function) > > make[1]: *** [arch/arm/mach-omap2/resource34xx.o] Error 1 > arch/arm/mach-omap2/pm.c: In function 'vdd_opp_show': > arch/arm/mach-omap2/pm.c:140: error: 'VDD1_OPP' undeclared (first use > in this function) > arch/arm/mach-omap2/pm.c:140: error: (Each undeclared identifier is > reported only once > > make[1]: *** [arch/arm/mach-omap2/pm.o] Error 1 > > Signed-off-by: Kim Kyuwon Thanks, pushing to PM branch. Kevin > --- > arch/arm/mach-omap2/pm.c |1 + > arch/arm/mach-omap2/resource34xx.c |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c > index e64a80e..c0f1ae8 100644 > --- a/arch/arm/mach-omap2/pm.c > +++ b/arch/arm/mach-omap2/pm.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include "prm-regbits-34xx.h" > #include "pm.h" > diff --git a/arch/arm/mach-omap2/resource34xx.c > b/arch/arm/mach-omap2/resource34xx.c > index 2328323..4db9289 100644 > --- a/arch/arm/mach-omap2/resource34xx.c > +++ b/arch/arm/mach-omap2/resource34xx.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > #include "smartreflex.h" > #include "resource34xx.h" > #include "pm.h" > -- > 1.5.2.5 > > > -- > Kim Kyuwon -- 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: PM: Add the wakeup source driver, v2
Kim Kyuwon writes:
> Sometimes, it is necessary to find out "what does wake up my board
> from suspend?". Notifying wake-up source feature may be used to blame
> unexpected wake-up events which increase power consumption. And user
> mode applications can act smartly according to the wake-up event from
> Suspend-to-RAM state to minimize power consumption. Note that this
> driver can't inform wake-up events from idle state. This driver uses
> sysfs interface to give information to user mode applications like:
Hi Kim,
Thanks for addressing my comments. This is now more streamlined
during the wakeup/resume path as I suggested. Thanks. A few more
minor comments below...
> cat /sys/power/omap_resume_irq
> cat /sys/power/omap_resume_event
>
> This driver also privides the unified GPIO wake-up source
> configuration. specific GPIO settings in the board files are:
>
> /* Wakeup source configuration */
> static struct gpio_wake boardname_gpio_wake[] = {
> { 23, IRQF_TRIGGER_RISING,"BT_WAKEUP",1},
> { 24, IRQF_TRIGGER_RISING,"USB_DETECT", 1},
> };
>
> static struct omap_wake_platform_data boardname_wake_data = {
> .gpio_wakes = boardname_gpio_wake,
> .gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
> };
>
> static struct platform_device boardname_wakeup = {
> .name = "omap-wake",
> .id = -1,
> .dev= {
> .platform_data = &boardname_wake_data,
> },
> };
>
> The patch adds Kconfig options "OMAP34xx wakeup source support" under
> "System type"->"TI OMAP implementations" menu.
>
> Signed-off-by: Kim Kyuwon
> ---
> arch/arm/mach-omap2/Makefile |1 +
> arch/arm/mach-omap2/irq.c | 21 +-
> arch/arm/mach-omap2/pm34xx.c | 12 +
> arch/arm/mach-omap2/prcm-common.h |4 +
> arch/arm/mach-omap2/prm-regbits-34xx.h |6 +
> arch/arm/mach-omap2/wake34xx.c | 539
>
> arch/arm/plat-omap/Kconfig |9 +
> arch/arm/plat-omap/include/mach/irqs.h |4 +
> arch/arm/plat-omap/include/mach/pm.h | 10 +
> arch/arm/plat-omap/include/mach/wake.h | 30 ++
> 10 files changed, 633 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/mach-omap2/wake34xx.c
> create mode 100644 arch/arm/plat-omap/include/mach/wake.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 16c6fb8..29ad0f1 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o
> obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
> +obj-$(CONFIG_OMAP_WAKE) += wake34xx.o
> endif
>
> # SmartReflex driver
> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
> index be4b596..6da285e 100644
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -33,9 +33,6 @@
> #define INTC_MIR_SET00x008c
> #define INTC_PENDING_IRQ00x0098
>
> -/* Number of IRQ state bits in each MIR register */
> -#define IRQ_BITS_PER_REG 32
> -
> /*
> * OMAP2 has a number of different interrupt controllers, each interrupt
> * controller is identified as its own "bank". Register definitions are
> @@ -193,6 +190,24 @@ int omap_irq_pending(void)
> return 0;
> }
>
> +void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
> +{
> + int i, idx = 0;
> +
minor detail, but how about the more common 'j' instead of idx.
> + for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
> + struct omap_irq_bank *bank = irq_banks + i;
> + int irq;
> +
> + for (irq = 0; irq < bank->nr_irqs && idx < len;
> + irq += IRQ_BITS_PER_REG) {
> + int offset = irq & (~(IRQ_BITS_PER_REG - 1));
> +
> + pending_irqs[idx++] = intc_bank_read_reg(bank,
> + (INTC_PENDING_IRQ0 + offset));
> + }
> + }
> +}
> +
> void __init omap_init_irq(void)
> {
> unsigned long nr_of_irqs = 0;
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 9102cee..2d17906 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -91,6 +91,13 @@ static struct prm_setup_times prm_setup = {
> .voltsetup2 = 0xff,
> };
>
> +static struct pm_wakeup_status omap3_pm_wkst;
> +
> +void omap3_get_wakeup_status(struct pm_wakeup_status **pm_wkst)
> +{
> + *pm_wkst = &omap3_pm_wkst;
> +}
> +
Can you rename this to omap3_get_last_wake_state()
> static inline void omap3_per_save_context(void)
> {
> omap3_gpio_save_context();
> @@ -174,6 +181,7 @@ static irqreturn_t prcm_interrupt_handler (int
> irq,
Re: PM branch rebased to 2.6.29
Russ Dill writes: >> Russ, >> >> With the dump below, what was the output after you resumed? Which >> powerdomains did not hit their target state? It looks like PER and >> CORE did not hit target state. > > yes, yes, and yes. > >> Also, you didn't mention what hardware you're using or your .config or >> your bootloader etc. All of these play an important role. > > Beagleboard B7, X-Loader 1.41, U-Boot 1.3.3 Not familiar with the all u-boot versions for this board, but is this u-boot out of Steve Sakoman's tree? I had lots of problems with the TI bootloader leaving Beagle in a strange state and switched to using the one from Steve's tree. I have X-Loader 1.41 and: U-Boot 2009.01-rc1-00067-g8c6db17 (Jan 15 2009 - 16:31:00) >> >> Here is at least one problem. >> >> Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the >> source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK >> is used as the timer source. >> >> Based on this, you must have: >> >> System Type --> TI OMAP Implementations --> System Timer >> >> set to 'MPU timer'. Please change to 32k timer. Using MPU timer will >> keep timers not in WKUP powerdomain (which is all of them except GPT1) >> running across suspend, preventing PER from hitting RET. >> >> Using the 32k timer only uses GPT1 and sources it from the 32k clock, both >> of which are in the WKUP powerdomain. > > Nope, I have the following kernel message: > > OMAP clockevent source: GPTIMER12 at 32768 Hz > > and the following Kconfig options (also see the attached .config) Right, I forgot Beagle is using GPT12, not GPT1. nevermind. > Texas Instruments X-Loader 1.41 > Starting OS Bootloader... > > > U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) First recommendation is to upgrade your bootloder: http://elinux.org/BeagleBoard#U-Boot The earlier bootloaders seem to be blindly enabling reserved bits in some of the PM registers which can leave the chip in an undefined state. > OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz > OMAP3 Beagle Board + LPDDR/NAND > DRAM: 128 MB > NAND: 256 MiB > In:serial > Out: serial > Err: serial > Audio Tone on Speakers ... complete > Hit any key to stop autoboot: 0 > > NAND read: device 0 offset 0x28, size 0x40 > 4194304 bytes read: OK > ## Booting kernel from Legacy Image at 8000 ... >Image Name: Linux-2.6.29-omap1-pm >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:1476992 Bytes = 1.4 MB >Load Address: 80008000 >Entry Point: 80008000 >Verifying Checksum ... OK >Loading Kernel Image ... OK > OK > > Starting kernel ... > > Uncompressing > Linux > done, booting the kern. > Linux version 2.6.29-omap1-pm (r...@russ-laptop) (gcc version 4.3.1 > (GCC) ) #47 PREEMPT Tue Mar 31 14:13:51 MST 2009 > CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f > CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache > Machine: OMAP3 Beagle Board > Memory policy: ECC disabled, Data cache writeback > OMAP3430 ES3.0 > SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 > Kernel command line: console=ttyS2,115200n8 root=/dev/mtdblock4 > rootfstype=jffs2 rw g_ether.host_addr=B6:A3:A1:7D:8F:F0 > omapfb.mode=dvi:126 > Unknown boot option `g_ether.host_addr=B6:A3:A1:7D:8F:F0': ignoring > Unknown boot option `omapfb.mode=dvi:1280x720M-16': ignoring > Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz > Reprogramming SDRC > GPMC revision 5.0 > IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts > Total of 96 interrupts on 1 active controller > OMAP34xx GPIO hardware version 2.5 > PID hash table entries: 512 (order: 9, 2048 bytes) > OMAP clockevent source: GPTIMER12 at 32768 Hz > Console: colour dummy device 80x30 > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > Memory: 128MB = 128MB total > Memory: 126648KB available (2692K code, 299K data, 96K init) > Calibrating delay loop... 491.57 BogoMIPS (lpj=1921024) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > net_namespace: 544 bytes > regulator: core version 0.5 > NET: Registered protocol family 16 > Found NAND on CS0 > Registering NAND on CS0 > OMAP DMA hardware revision 4.0 > bio: create slab at 0 > i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz > twl4030: PIH (irq 7) chaining IRQs 368..375 > twl4030: power (irq 373) chaining IRQs 376..383 > twl4030: gpio (irq 368) chaining IRQs 384..401 > beagle_twl_gpio_setup:145 > twl4030_mmc_init:324 > twl4030_mmc_init:339 > regulator: VMMC1: 1850 <--> 3150 mV normal standby > regulator: VDAC: 1800 mV normal standby > regulator: VUSB1V5: 1500 <--> 0 mV normal standby > regulator: VUSB1V8: 1800 <--> 0 mV normal standby > regulator: VUSB3V1: 3100
Re: Problems bringing up new PM 2.6.29 tree on Logic 35x LV SOM
On Thu, 2009-03-26 at 15:13 -0600, Paul Walmsley wrote:
> On Thu, 26 Mar 2009, Peter Barada wrote:
>
> > I changed the call to omap_init_common_hw to pass in four NULLs (as I
> > think the sdrc params for mt46h32m32lf6 (somehow?) don't match the
> > mt29c2g24maklajg-75 used on our board.
>^^
>
> This is why you can't use the MT46H32M32LF-6 parameters. The -75 part is
> slower. You'll need to plug in the -75 timings from the Micron datasheet
> 1gb_ddr_mobile_sdram_t48m.pdf into calc-sdrc-params.c. Using those
> values, create a new file, sdram-micron-mt46h32m32lf-75.h, for that part,
> and pass in the new SDRAM register structure via omap_init_common_hw() in
> your board-*.c file.
Ok, I've gone back and started over from scratch with Kevin's PM branch
(2.6.29). First I ported u-boot 2009.03 from the beagle u-boot git tree
to my board(using beagle code as a starting point), and I have that
working, copmlete with ethernet, NAND, etc. I also took your sdrc timing
generator, and created a mt29c2g24maklajg-75.h for 2.6.29 that contains
the following structure:
static struct omap_sdrc_params mt29c2g24maklajg_75_sdrc_params[] = {
[0] = {
.rate= 16600,
.actim_ctrla = 0x9b6246c7,
.actim_ctrlb = 0x00011217,
.rfr_ctrl= 0x0004dc01,
.mr = 0x0032,
},
[1] = {
.rate= 165941176,
.actim_ctrla = 0x9b6246c7,
.actim_ctrlb = 0x00011217,
.rfr_ctrl= 0x0004dc01,
.mr = 0x0032,
},
[2] = {
.rate= 1,
.actim_ctrla = 0x7a99b485,
.actim_ctrlb = 0x00011213,
.rfr_ctrl= 0x0003dd01,
.mr = 0x0032,
},
[3] = {
.rate= 8300,
.actim_ctrla = 0x51d12484,
.actim_ctrlb = 0x0001120c,
.rfr_ctrl= 0x00025501,
.mr = 0x0032,
},
[4] = {
.rate= 82970588,
.actim_ctrla = 0x51d12484,
.actim_ctrlb = 0x0001120c,
.rfr_ctrl= 0x00025501,
.mr = 0x0032,
},
[5] = {
.rate= ,
.actim_ctrla = 0x414d2243,
.actim_ctrlb = 0x0001120a,
.rfr_ctrl= 0x0001d501,
.mr = 0x0032,
},
[6] = {
.rate= 0
},
};
And using this(and kernel code based on the beagle configuration), I can
boot up 2.6.29 until it wedges trying to program the twl40930 over I2C.
Using the new u-boot, I see from its output:
Clocking rate (Crystal/DPLL/ARM core): 26.0/332/1000 MHz
Which doesn't look right at all. Before I go too far, I found in u-boot
that the I2C code in the tree made the assumption that the I2C clock was
based on 12Mhz, and blindly calculated the PSC and SCL values directly
from that instead of looking at I2C_IP_CLK (96Mhz). I wonder if this is
what's (partially) biting me on the 2.6.29 startup.
Before I dig too deep,
1) Does u-boot, if loaded into ram and started up, setup the clocks from
scratch? I'm asking since Logic has a primarly bootloader, LoLo, that
sets up the world, then I load/invoke u-boot, which then loads/boots the
kernel. I can envision the clock setup in LoLo being incorrect, iff
u-boot does not program clocks that are already setup(i.e. if u-boot
reprograms all the clocks, then it shouldn't matter if LoLo set them up
incorrectly).
2) Any ideas why the kernel would think the core is running at 1000Mhz?
Dumping DPLL3
>
> - Paul
--
Peter Barada
--
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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: > Thanks, > Vaibhav Hiremath > > > > APPROACH 3 - > > > -- > > > > > > . > > > > > > (Any other approach which I could not think of would be > > > > appreciated) > > > > > I would prefer second approach, since this will provide standard > > > interface to applications independent on underneath hardware. > > > > > > There may be many number of such configuration parameters required > > > > for > > > > > different such devices, we need to work on this and come up with > > > > some > > > > > standard capability fields covering most of available devices. > > > > > > Does anybody have some other opinions on this? > > > Any suggestions will be helpful here, > > > > FYI: I have very little time to look at this for the next 2-3 weeks. > > As you > > know I'm working on the last pieces of the v4l2_subdev conversion > > for 2.6.30 > > that should be finished this week. After that I'm attending the > > Embedded > > Linux Conference in San Francisco. > > > > But I always thought that something like this would be just a > > regular video > > device that can do both 'output' and 'capture'. For a resizer I > > would > > expect that you set the 'output' size (the size of your source > > image) and > > the 'capture' size (the size of the resized image), then just send > > the > > frames to the device (== resizer) and get them back on the capture > > side. > > [Hiremath, Vaibhav] Yes, it is possible to do that. > > Hans, > > I went through the link referred by Sergio and I think we should inherit > some implementation for CODECs here for such devices. > > V4L2_BUF_TYPE_CODECIN - To access the input format. > V4L2_BUF_TYPE_CODECOUT - To access the output format. > > It makes sense, since such memory-to-memory devices will mostly being > used from codecs context. And this would be more clear from user > application. I haven't had the time to look at this yet. > And as acknowledged by you, we can use VIDIOC_S_FMT for setting > parameters. > > One thing I am not able to convince myself is that, using "priv" field > for custom configuration. I would prefer and recommend capability based > interface, where application will query the capability of the device for > luma enhancement, filter coefficients (number of coeff and depth), > interpolation type, etc... These things are always hard to do since the capabilities are so hardware dependent. You either end up with a controls-like API (where you basically can enumerate the capabilities), or you go for a split API: part is for common functionality, and another part is purely device specific. > This way we can make sure that, any such future devices can be adapted by > this framework. > > > > Hans, > Have you get a chance to look at Video-Buf layer issues I mentioned in > original draft? No, but videobuf is more Mauro's expertise. As I said, I will have very little time to really look into this until some 2-3 weeks from now :-( Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Don't warn user about expected behaviour in mmc-twl4030
On Mon, Mar 30, 2009 at 01:53:43PM -0700, David Brownell wrote: > So when are you going to fix the regulator docs to report that: > ALL regulator consumers must start by enabling and > then disabling the regulator. The documention should not be changed to say that since only consumers that need the regulator to be off at startup should do this, and then probably only if they find that it is already enabled. Other consumers do not need to do this. Consumers that want to enable a regulator at startup can do so directly. Consumers that don't need a specific state (for example, because they are able to share the regulator and don't need it enabling) should just leave it alone. -- 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
[RFC][PATCH] LAN9211 and LAN9221 NFS mounting and overrun fix on omap LDP
The patch below I am reposting it, because I could not get a chance to
communicate with Actual athor, I will be glad if someone can comment
on it.
-- Forwarded message --
From: Subramani Venkatesh
Date: Wed, Mar 25, 2009 at 12:38 PM
Subject: [RFC][PATCH] LAN9211 and LAN9221 NFS mounting and overrun fix
on omap LDP
To: n...@cam.org
Cc: linux-arm
Hi,
I need your comment on the patch I generated on 2.6.27 Linux ARM for omap LDP.
With this patch we are able to mount the NFS even with heavy traffic
like ping -f option, without which NFS retrying and hangs.
I am not sure whether this problem is fixed with the new the kernel, I
need your comments whether we can intergrate with the kernel or not.
>From 9bd50055785492f52877fc719ec5ad02dd183a99 Mon Sep 17 00:00:00 2001
From: Subramani Venkatesh
Date: Wed, 25 Mar 2009 12:23:45 -0400
Subject: [PATCH] LAN9211 NFS bootup fix
This patch fixs the problem of Mounting NFS file system, when there
is too much traffic on the Network.
We still face the Overrun issues, but we still have NFS working.
NFS mounting issue is found on Omap LDP target boards.
Signed-off-by: Subramani Venkatesh
---
drivers/net/smc911x.c | 6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 7aa8c49..f3343ae 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -,6 +,12 @@ static irqreturn_t smc911x_interrupt(int irq,
void *dev_id)
smc911x_rcv(dev);
}
SMC_ACK_INT(lp, INT_STS_RSFL_);
+ if (rx_overrun) {
+ DBG(SMC_DEBUG_RX, "%s: RX Enable\n", dev->name);
+ SMC_GET_MAC_CR(lp, cr);
+ SMC_SET_MAC_CR(lp, cr|MAC_CR_RXEN_);
+ }
+
}
/* Handle transmit FIFO available */
if (status & INT_STS_TDFA_) {
--
1.5.4.3
Regards,
Subbu
--
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/4] ARM: OMAP3: Add support for 3430 SDP, v3
On Tue, Mar 31, 2009 at 05:12:18PM +0530, Gadiyar, Anand wrote: > I could not run the 3430 SDP defconfig from mainline. The image hangs at > "Starting kernel ...". Enabling CONFIG_DEBUG_LL does not help. Did you add the necessary patch to kernel/printk.c ? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
Russ Dill writes: > On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman > wrote: >> Russ Dill writes: >> >>> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote: >> [...] I had found that two drivers that could prevent clocks_off are USB and DSS because of the way they use clk_enable(). Can you try building without theses drivers just for verification? >>> >>> Building without dss makes things worse: >>> >>> Powerdomain (dss_pwrdm) didn't enter target state 0 >>> >>> Maybe by looking at what the dss driver is doing I can get core and >>> per to turn off. >> >> Russ, >> >> Can you try with the latest HEAD of PM branch. After suspend/resume, >> do >> >> # cat /debug/pm_debug/registers/1 >> >> and post results to list. We can then see the exact state of PM >> registers before going into WFI. Russ, With the dump below, what was the output after you resumed? Which powerdomains did not hit their target state? It looks like PER and CORE did not hit target state. Also, you didn't mention what hardware you're using or your .config or your bootloader etc. All of these play an important role. > r...@beagleboard:/sys# cat /debug/pm_debug/registers/1 > MOD: CM_IVA2 (48014000) > 04 => 0037 20 => 0001 34 => 0001 40 => 0009680c > 44 => 0001 48 => 0003 > MOD: CM_OCP (48004800) > 00 => 0010 10 => 0001 > MOD: CM_MPU (48004900) > 04 => 0037 24 => 0001 34 => 0001 40 => 0011f40c > 44 => 0001 48 => 0003 4c => 0001 > MOD: CM_CORE (48004a00) > 10 => 0042 20 => ffbd 24 => 001f 28 => 000d > 30 => fed9 34 => 001f 38 => 000c 40 => 030a > 48 => 003f 4c => 0003 > MOD: CM_SGX (48004b00) > 20 => 0001 48 => 0003 > MOD: CM_WKUP (48004c00) > 10 => 000e 20 => 02f1 30 => 003f 40 => 0015 Here is at least one problem. Offset 0x40 is CM_CLKSEL_WKUP, and bit 0 shows which clock is the source clock for GPTIMER1. Here, bit 0 is 1 which means SYS_CLK is used as the timer source. Based on this, you must have: System Type --> TI OMAP Implementations --> System Timer set to 'MPU timer'. Please change to 32k timer. Using MPU timer will keep timers not in WKUP powerdomain (which is all of them except GPT1) running across suspend, preventing PER from hitting RET. Using the 32k timer only uses GPT1 and sources it from the 32k clock, both of which are in the WKUP powerdomain. > MOD: CM_CCR (48004d00) > 00 => f8311037 04 => 0017 20 => 0201 30 => 0009 > 34 => 0001 40 => 094c0c00 44 => 0001b00c 48 => 0009 > 50 => 0001 70 => 0003 > MOD: CM_DSS (48004e00) > 20 => 0003 30 => 0001 40 => 1006 48 => 0003 > MOD: CM_CAM (48004f00) > 20 => 0001 30 => 0001 40 => 0004 48 => 0003 > MOD: CM_PER (48005000) > 10 => 0003e000 20 => 1fff 30 => 0003 40 => 00ff > 44 => 0006 48 => 0003 4c => 0001 > MOD: CM_EMU (48005100) > 40 => 03020a50 48 => 0002 4c => 0001 > MOD: CM_NEON (48005300) > 48 => 0003 > MOD: CM_USB (48005400) > 20 => 0003 30 => 0001 48 => 0003 > MOD: PRM_IVA2 (48316000) > 50 => 0007 e0 => 00ff0f04 f8 => 0007 > MOD: PRM_OCP (48306800) > 04 => 0010 14 => 0001 1c => 0201 > MOD: PRM_MPU (48306900) > 58 => 0005 d4 => 0012 e0 => 00030104 e4 => 00c7 > e8 => 00c7 > MOD: PRM_CORE (48306a00) > 58 => 0301 a0 => c33ffe18 a4 => c33ffe18 a8 => c33ffe18 > e0 => 000f0304 e4 => 00f7 e8 => 00f7 f0 => 0004 > f4 => 0004 f8 => 0004 > MOD: PRM_SGX (48306b00) > e0 => 00030104 > MOD: PRM_WKUP (48306c00) > a0 => 010b a4 => 010b > MOD: PRM_CCR (48306d00) > 40 => 0003 > MOD: PRM_DSS (48306e00) > 58 => 0005 a0 => 0001 e0 => 00030104 > MOD: PRM_CAM (48306f00) > 58 => 0001 e0 => 00030104 > MOD: PRM_PER (48307000) > 58 => 0001 a0 => 0003efff a4 => 0003efff a8 => 0003efff > c8 => 0007 e0 => 00030104 e4 => 0007 e8 => 0007 > MOD: PRM_EMU (48307100) > 58 => 0005 e4 => 0103 > MOD: PRM_GLBL (48307200) > 20 => 00120012 24 => 0001 2c => 301e1e30 30 => 2c1e1e2c > 34 => 0012 38 => 0018 54 => 1006 58 => 0001 > 60 => 000e 64 => 0050 70 => 0088 90 => 0fff0fff > 94 => 00ff 98 => 00ff 9c => 0002 a0 => 00ff > c4 => 0001 e4 => 0001 > MOD: PRM_NEON (48307300) > 58 => 0005 c8 => 0002 e0 => 0004 e4 => 0003 > e8 => 0003 > MOD: PRM_USB (48307400) > 58 => 0001 a0 => 0001 a4 => 0001 a8 => 0001 > e0 => 00030104 > > >> Also, post dump of >> > > r...@beagleboard:/sys# cat /debug/pm_debug/count > usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1 > sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1 > per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1 > dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3 > cam_pwrdm (OFF),OFF:1,RET
[PATCH] DSPBRIDGE: Fix module build warnings
Signed-off-by: Ameya Palande
---
drivers/dsp/bridge/rmgr/drv_interface.c |6
drivers/dsp/bridge/rmgr/node.c |1 -
drivers/dsp/bridge/wmd/tiomap3430.c | 39 ---
3 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 350e1b5..981354a 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -685,12 +685,6 @@ static int bridge_release(struct inode *ip, struct file
*filp)
return status;
}
-static void bridge_free(struct device *dev)
-{
- /* nothing to Free */
-}
-
-
/* This function provides IO interface to the bridge driver. */
static int bridge_ioctl(struct inode *ip, struct file *filp, unsigned int code,
unsigned long args)
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 51b4b12..66a6284 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -3471,7 +3471,6 @@ static DSP_STATUS GetRMSFxns(struct NODE_MGR *hNodeMgr)
}
}
}
-func_end:
return status;
}
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 1fca3e5..b489da1 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -2034,26 +2034,27 @@ static DSP_STATUS PteSet(struct PgTableAttrs *pt, u32
pa, u32 va,
if (pfn_valid(__phys_to_pfn(patemp))) {
pg = phys_to_page(patemp);
get_page(pg);
+ if (page_count(pg) <= 1) {
+ printk(KERN_EMERG "DSPBRIDGE:MAP "
+ "function: COUNT 0 FOR PA "
+ "0x%x\n", patemp);
+ printk(KERN_EMERG "Bad page state"
+ "in process '%s'\n"
+ "page:%p flags:0x%0*lx "
+ "mapping:%p mapcount:%d "
+ "count:%d\n"
+ "Trying to fix it up, but "
+ "a reboot is needed\n"
+ "Backtrace:\n",
+ current->comm, pg,
+ (int)(2*sizeof(unsigned long)),
+ (unsigned long)pg->flags,
+ pg->mapping, page_mapcount(pg),
+ page_count(pg));
+ dump_stack();
+ BUG_ON(1);
+ }
}
- if (page_count(pg) <= 1) {
- printk(KERN_EMERG "DSPBRIDGE:MAP function: "
- "COUNT 0 FOR PA 0x%x\n", patemp);
- printk(KERN_EMERG "Bad page state"
- KERN_EMERG "in process '%s'\n"
- KERN_EMERG "page:%p flags:0x%0*lx "
- KERN_EMERG "mapping:%p mapcount:%d "
- KERN_EMERG "count:%d\n"
- KERN_EMERG "Trying to fix it up, but "
- KERN_EMERG "a reboot is needed\n"
- KERN_EMERG "Backtrace:\n",
- current->comm, pg,
- (int)(2*sizeof(unsigned long)),
- (unsigned long)pg->flags, pg->mapping,
- page_mapcount(pg), page_count(pg));
- dump_stack();
- BUG_ON(1);
- }
-
patemp += HW_PAGE_SIZE_4KB;
}
}
--
1.6.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 3/4] ARM: OMAP3: Add support for 3430 SDP, v3
* Gadiyar, Anand [090331 06:38]: > > > * Tony Lindgren [090316 11:14]: > > > > * Russell King - ARM Linux [090315 08:48]: > > > > > On Sun, Mar 15, 2009 at 03:47:01PM +, Russell King - ARM Linux > > > > > wrote: > > > > > > On Fri, Mar 13, 2009 at 03:47:26PM -0700, Tony Lindgren wrote: > > > > > > > +#include > > > > > > > +#include > > > > > > > > > > > > Shouldn't this be linux/gpio.h ? > > > > > > > > > > Note that Syed Mohammed Khasim address is not valid. > > > > > > > > Thanks, updated patch below. > > > > > > Oops, forgot to run stg refresh before sending out this, v3 below > > > > > > Tony > > > > > > > Tony, Russell, > > > > Sorry for not catching this before it got merged. > > > > I could not run the 3430 SDP defconfig from mainline. The image hangs at > > "Starting kernel ...". Enabling CONFIG_DEBUG_LL does not help. > > > > The omap_3430sdp_defconfig seems to have too many differences from the > > defconfigs for other OMAP3 boards. In fact, it's not even similar to the > > file present in the linux-omap tree. > > > > So I took the SDP defconfig from the l-o tree and replaced the one on > > mainline with it. And we have a compile break in a display file. Removing > > CONFIG_FB_OMAP works around the compile break. > > > > Please consider merging this patch (l-o SDP defconfig minus CONFIG_FB_OMAP) > > so that we can finally use an SDP with mainline. > > > > > Oops. Now, this doesn't work for me either. Sorry for the noise. What do you get with CONFIG_DEBUG_LL and the attached hack applied? Tony --- a/kernel/printk.c +++ b/kernel/printk.c @@ -44,6 +44,10 @@ void asmlinkage __attribute__((weak)) early_printk(const char *fmt, ...) #define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT) +#ifdef CONFIG_DEBUG_LL +extern void printascii(char *); +#endif + /* printk's without a loglevel use this.. */ #define DEFAULT_MESSAGE_LOGLEVEL 4 /* KERN_WARNING */ @@ -667,6 +671,9 @@ asmlinkage int vprintk(const char *fmt, va_list args) printed_len += vscnprintf(printk_buf + printed_len, sizeof(printk_buf) - printed_len, fmt, args); +#ifdef CONFIG_DEBUG_LL + printascii(printk_buf); +#endif /* * Copy the output into log_buf. If the caller didn't provide
[PATCH] DSPBRIDGE: Logical code cleanup in bridge_open()
Signed-off-by: Ameya Palande
---
drivers/dsp/bridge/rmgr/drv_interface.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index d9504cc..350e1b5 100755
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -585,7 +585,7 @@ static int bridge_open(struct inode *ip, struct file *filp)
DSP_STATUS dsp_status = DSP_SOK;
HANDLE hDrvObject = NULL;
struct PROCESS_CONTEXT*pPctxt = NULL;
- struct PROCESS_CONTEXT *pTmp = NULL;
+ struct PROCESS_CONTEXT *next_node = NULL;
struct PROCESS_CONTEXT*pCtxtclosed = NULL;
struct PROCESS_CONTEXT*pCtxttraverse = NULL;
struct task_struct *tsk = NULL;
@@ -600,6 +600,7 @@ static int bridge_open(struct inode *ip, struct file *filp)
DRV_GetProcCtxtList(&pCtxtclosed, (struct DRV_OBJECT *)hDrvObject);
while (pCtxtclosed != NULL) {
tsk = find_task_by_vpid(pCtxtclosed->pid);
+ next_node = pCtxtclosed->next;
if ((tsk == NULL) || (tsk->exit_state == EXIT_ZOMBIE)) {
@@ -637,14 +638,11 @@ static int bridge_open(struct inode *ip, struct file
*filp)
}
}
}
- pTmp = pCtxtclosed->next;
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
pCtxtclosed,
(void *)pCtxtclosed->pid);
- } else {
- pTmp = pCtxtclosed->next;
}
- pCtxtclosed = pTmp;
+ pCtxtclosed = next_node;
}
func_cont:
dsp_status = CFG_GetObject((u32 *)&hDrvObject, REG_DRV_OBJECT);
--
1.6.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: PM branch rebased to 2.6.29... for real this time
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Thursday, March 26, 2009 4:26 AM > To: linux-omap@vger.kernel.org > Subject: PM branch rebased to 2.6.29... for real this time > > Hello, > > The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is > out, I've rebased the PM brach onto linux-omap HEAD just after the > 2.6.29 merge. > > Minimal retention and off-mode on Beagle and RX51. Another problem that I found on OMAP3EVM: When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), the kernel did not boot-up. The last few statements are: <3>clock: dpll5_ck failed transition to 'locked' clock: dpll5_ck failed transition to 'locked' <6>Disabling unused clock "dpll4_m6x2_ck" Disabling unused clock "dpll4_m6x2_ck" <6>Disabling unused clock "dpll3_m3x2_ck" Disabling unused clock "dpll3_m3x2_ck" <6>Disabling unused clock "sys_clkout1" Disabling unused clock "sys_clkout1" The PC is at the WFI statement. Tried other combinations as well: 1) only CPUidle enabled - okay. 2) only CPUfreq enabled - not okay. Best regards, Sanjeev > > 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 > > -- 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
find_task_by_vpid() not protected
Hi Hari, I found out that bridge_open() function is calling find_task_by_vpid() without taking rcu_read_lock() or with tasklist_lock read-held. Should we introduce proper read locking with following functions? read_lock(&tasklist_lock); read_unlock(&tasklist_lock); Cheers, Ameya. -- 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/4] ARM: OMAP3: Add support for 3430 SDP, v3
> > * Tony Lindgren [090316 11:14]: > > > * Russell King - ARM Linux [090315 08:48]: > > > > On Sun, Mar 15, 2009 at 03:47:01PM +, Russell King - ARM Linux > > > > wrote: > > > > > On Fri, Mar 13, 2009 at 03:47:26PM -0700, Tony Lindgren wrote: > > > > > > +#include > > > > > > +#include > > > > > > > > > > Shouldn't this be linux/gpio.h ? > > > > > > > > Note that Syed Mohammed Khasim address is not valid. > > > > > > Thanks, updated patch below. > > > > Oops, forgot to run stg refresh before sending out this, v3 below > > > > Tony > > > > Tony, Russell, > > Sorry for not catching this before it got merged. > > I could not run the 3430 SDP defconfig from mainline. The image hangs at > "Starting kernel ...". Enabling CONFIG_DEBUG_LL does not help. > > The omap_3430sdp_defconfig seems to have too many differences from the > defconfigs for other OMAP3 boards. In fact, it's not even similar to the > file present in the linux-omap tree. > > So I took the SDP defconfig from the l-o tree and replaced the one on > mainline with it. And we have a compile break in a display file. Removing > CONFIG_FB_OMAP works around the compile break. > > Please consider merging this patch (l-o SDP defconfig minus CONFIG_FB_OMAP) > so that we can finally use an SDP with mainline. > Oops. Now, this doesn't work for me either. Sorry for the noise. Confused, 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] regulator: twl4030 VAUX3 supports 3.0V
On Thu, 2009-03-26 at 16:21 +0200, Adrian Hunter wrote: > >From 51f946af56a5de9c25b2eb6e6a33660283f84195 Mon Sep 17 00:00:00 2001 > From: Adrian Hunter > Date: Fri, 6 Mar 2009 14:51:30 +0200 > Subject: [PATCH] regulator: twl4030 VAUX3 supports 3.0V > > TWL4030 and TWL5030 support 3.0V on VAUX3. > > Signed-off-by: Adrian Hunter > --- > drivers/regulator/twl4030-regulator.c |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) Applied. Thanks Liam -- 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath > > > > APPROACH 3 - > > -- > > > > . > > > > (Any other approach which I could not think of would be > appreciated) > > > > > > I would prefer second approach, since this will provide standard > > interface to applications independent on underneath hardware. > > > > There may be many number of such configuration parameters required > for > > different such devices, we need to work on this and come up with > some > > standard capability fields covering most of available devices. > > > > Does anybody have some other opinions on this? > > Any suggestions will be helpful here, > > FYI: I have very little time to look at this for the next 2-3 weeks. > As you > know I'm working on the last pieces of the v4l2_subdev conversion > for 2.6.30 > that should be finished this week. After that I'm attending the > Embedded > Linux Conference in San Francisco. > > But I always thought that something like this would be just a > regular video > device that can do both 'output' and 'capture'. For a resizer I > would > expect that you set the 'output' size (the size of your source > image) and > the 'capture' size (the size of the resized image), then just send > the > frames to the device (== resizer) and get them back on the capture > side. > [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using "priv" field for custom configuration. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v3] ARM: OMAP: board-ldp: add regulator info to get the microSD slot working again
The ldp board was left behind when other boards got updated. The ldp info was
copied from the beagleboard board file and s/beagle/ldp/g
Changes since v2:
* fixed email address
Changes since v1:
* dropped vsim portion since only 4 pins are hooked up
Signed-off-by: Koen Kooi
---
arch/arm/mach-omap2/board-ldp.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 30926b0..19a5c15 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -450,7 +451,16 @@ static struct twl4030_script *twl4030_scripts[] __initdata
= {
&wrst_script,
};
+static const struct twl4030_resconfig ldp_resconfig[] = {
+ /* disable regulators that u-boot left enabled; the
+* devices' drivers should be managing these.
+*/
+ { .resource = RES_VMMC1, },
+ { 0, },
+};
+
static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
+ .resource_config= ldp_resconfig,
.scripts= twl4030_scripts,
.size = ARRAY_SIZE(twl4030_scripts),
};
@@ -474,6 +484,25 @@ static struct twl4030_madc_platform_data ldp_madc_data = {
.irq_line = 1,
};
+static struct regulator_consumer_supply ldp_vmmc1_supply = {
+ .supply = "vmmc",
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+static struct regulator_init_data ldp_vmmc1 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &ldp_vmmc1_supply,
+};
+
static struct twl4030_platform_data ldp_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -483,6 +512,7 @@ static struct twl4030_platform_data ldp_twldata = {
.madc = &ldp_madc_data,
.usb= &ldp_usb_data,
.power = &sdp3430_t2scripts_data,
+ .vmmc1 = &ldp_vmmc1,
.gpio = &ldp_gpio_data,
.keypad = &ldp_kp_twl4030_data,
};
@@ -530,6 +560,8 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init();
twl4030_mmc_init(mmc);
+ /* link regulators to MMC adapters */
+ ldp_vmmc1_supply.dev = mmc[0].dev;
}
static void __init omap_ldp_map_io(void)
--
1.6.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
[PATCH v2] ARM: OMAP: board-ldp: add regulator info to get the microSD slot working again
From: Koen Kooi
The ldp board was left behind when other boards got updated. The ldp info was
copied from the beagleboard board file and s/beagle/ldp/g
Changes since v1:
* dropped vsim portion since only 4 pins are hooked up
Signed-off-by: Koen Kooi
---
arch/arm/mach-omap2/board-ldp.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 30926b0..19a5c15 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -450,7 +451,16 @@ static struct twl4030_script *twl4030_scripts[] __initdata
= {
&wrst_script,
};
+static const struct twl4030_resconfig ldp_resconfig[] = {
+ /* disable regulators that u-boot left enabled; the
+* devices' drivers should be managing these.
+*/
+ { .resource = RES_VMMC1, },
+ { 0, },
+};
+
static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
+ .resource_config= ldp_resconfig,
.scripts= twl4030_scripts,
.size = ARRAY_SIZE(twl4030_scripts),
};
@@ -474,6 +484,25 @@ static struct twl4030_madc_platform_data ldp_madc_data = {
.irq_line = 1,
};
+static struct regulator_consumer_supply ldp_vmmc1_supply = {
+ .supply = "vmmc",
+};
+
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
+static struct regulator_init_data ldp_vmmc1 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &ldp_vmmc1_supply,
+};
+
static struct twl4030_platform_data ldp_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -483,6 +512,7 @@ static struct twl4030_platform_data ldp_twldata = {
.madc = &ldp_madc_data,
.usb= &ldp_usb_data,
.power = &sdp3430_t2scripts_data,
+ .vmmc1 = &ldp_vmmc1,
.gpio = &ldp_gpio_data,
.keypad = &ldp_kp_twl4030_data,
};
@@ -530,6 +560,8 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init();
twl4030_mmc_init(mmc);
+ /* link regulators to MMC adapters */
+ ldp_vmmc1_supply.dev = mmc[0].dev;
}
static void __init omap_ldp_map_io(void)
--
1.6.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: PM branch rebased to 2.6.29
BTW, the 9 clocks active on per are:
gpio{2-6}_ick
per_l4_ick
uart3_ick
uart3_fck
per_48m_fck
During sleep, I get (for the per_clkdm only):
clockdomain: clkdm per_clkdm: removing clk uart3_ick
clockdomain: clkdm per_clkdm: removing clk per_48m_fck
clockdomain: clkdm per_clkdm: removing clk uart3_fck
clockdomain: clkdm per_clkdm: adding clk uart3_ick
clockdomain: clkdm per_clkdm: adding clk uart3_fck
clockdomain: clkdm per_clkdm: adding clk per_48m_fck
So it looks like to me that the per_clkdm isn't shutting down because
of per_l4_ick and the gpio interface clocks.
On Mon, Mar 30, 2009 at 4:01 PM, Russ Dill wrote:
> On Mon, Mar 30, 2009 at 11:43 AM, Kevin Hilman
> wrote:
>> Russ Dill writes:
>>
>>> On Mon, Mar 30, 2009 at 3:08 AM, Premi, Sanjeev wrote:
>> [...]
I had found that two drivers that could prevent clocks_off are
USB and DSS because of the way they use clk_enable().
Can you try building without theses drivers just for verification?
>>>
>>> Building without dss makes things worse:
>>>
>>> Powerdomain (dss_pwrdm) didn't enter target state 0
>>>
>>> Maybe by looking at what the dss driver is doing I can get core and
>>> per to turn off.
>>
>> Russ,
>>
>> Can you try with the latest HEAD of PM branch. After suspend/resume,
>> do
>>
>> # cat /debug/pm_debug/registers/1
>>
>> and post results to list. We can then see the exact state of PM
>> registers before going into WFI.
>
> r...@beagleboard:/sys# cat /debug/pm_debug/registers/1
> MOD: CM_IVA2 (48014000)
> 04 => 0037 20 => 0001 34 => 0001 40 => 0009680c
> 44 => 0001 48 => 0003
> MOD: CM_OCP (48004800)
> 00 => 0010 10 => 0001
> MOD: CM_MPU (48004900)
> 04 => 0037 24 => 0001 34 => 0001 40 => 0011f40c
> 44 => 0001 48 => 0003 4c => 0001
> MOD: CM_CORE (48004a00)
> 10 => 0042 20 => ffbd 24 => 001f 28 => 000d
> 30 => fed9 34 => 001f 38 => 000c 40 => 030a
> 48 => 003f 4c => 0003
> MOD: CM_SGX (48004b00)
> 20 => 0001 48 => 0003
> MOD: CM_WKUP (48004c00)
> 10 => 000e 20 => 02f1 30 => 003f 40 => 0015
> MOD: CM_CCR (48004d00)
> 00 => f8311037 04 => 0017 20 => 0201 30 => 0009
> 34 => 0001 40 => 094c0c00 44 => 0001b00c 48 => 0009
> 50 => 0001 70 => 0003
> MOD: CM_DSS (48004e00)
> 20 => 0003 30 => 0001 40 => 1006 48 => 0003
> MOD: CM_CAM (48004f00)
> 20 => 0001 30 => 0001 40 => 0004 48 => 0003
> MOD: CM_PER (48005000)
> 10 => 0003e000 20 => 1fff 30 => 0003 40 => 00ff
> 44 => 0006 48 => 0003 4c => 0001
> MOD: CM_EMU (48005100)
> 40 => 03020a50 48 => 0002 4c => 0001
> MOD: CM_NEON (48005300)
> 48 => 0003
> MOD: CM_USB (48005400)
> 20 => 0003 30 => 0001 48 => 0003
> MOD: PRM_IVA2 (48316000)
> 50 => 0007 e0 => 00ff0f04 f8 => 0007
> MOD: PRM_OCP (48306800)
> 04 => 0010 14 => 0001 1c => 0201
> MOD: PRM_MPU (48306900)
> 58 => 0005 d4 => 0012 e0 => 00030104 e4 => 00c7
> e8 => 00c7
> MOD: PRM_CORE (48306a00)
> 58 => 0301 a0 => c33ffe18 a4 => c33ffe18 a8 => c33ffe18
> e0 => 000f0304 e4 => 00f7 e8 => 00f7 f0 => 0004
> f4 => 0004 f8 => 0004
> MOD: PRM_SGX (48306b00)
> e0 => 00030104
> MOD: PRM_WKUP (48306c00)
> a0 => 010b a4 => 010b
> MOD: PRM_CCR (48306d00)
> 40 => 0003
> MOD: PRM_DSS (48306e00)
> 58 => 0005 a0 => 0001 e0 => 00030104
> MOD: PRM_CAM (48306f00)
> 58 => 0001 e0 => 00030104
> MOD: PRM_PER (48307000)
> 58 => 0001 a0 => 0003efff a4 => 0003efff a8 => 0003efff
> c8 => 0007 e0 => 00030104 e4 => 0007 e8 => 0007
> MOD: PRM_EMU (48307100)
> 58 => 0005 e4 => 0103
> MOD: PRM_GLBL (48307200)
> 20 => 00120012 24 => 0001 2c => 301e1e30 30 => 2c1e1e2c
> 34 => 0012 38 => 0018 54 => 1006 58 => 0001
> 60 => 000e 64 => 0050 70 => 0088 90 => 0fff0fff
> 94 => 00ff 98 => 00ff 9c => 0002 a0 => 00ff
> c4 => 0001 e4 => 0001
> MOD: PRM_NEON (48307300)
> 58 => 0005 c8 => 0002 e0 => 0004 e4 => 0003
> e8 => 0003
> MOD: PRM_USB (48307400)
> 58 => 0001 a0 => 0001 a4 => 0001 a8 => 0001
> e0 => 00030104
>
>
>> Also, post dump of
>>
>
> r...@beagleboard:/sys# cat /debug/pm_debug/count
> usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1
> per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1
> dss_pwrdm (ON),OFF:2,RET:0,INA:0,ON:3
> cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1
> neon_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103
> mpu_pwrdm (ON),OFF:2,RET:0,INA:14100,ON:14103
> iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:1
> per_clkdm->per_pwrdm (9)
> usbhost_clkdm->usbhost_pwrdm (0)
> cam_clkdm->cam_pwrdm (0)
> dss_clkdm->dss_pwrdm (2)
> core_l4_clkdm->core_pwrdm (8)
