MUSB oopses when changing mode on Beagle
Hi, echo'ing 'host' to the musb_hdrc/mode sysfs file triggers an oops on BeagleBoard rev B4 with linux-omap HEAD. Passing along the trace with a little extra debug to see if anyone happens to know what the problem is. - Paul r...@beagleboard:/sys# echo host > ./devices/platform/musb_hdrc/mode musb: musb=c78280d8 musb: musb->xceiv=c78281b4 musb: musb->xceiv.host=c78281c4 musb: musb->xceiv->set_host=c78281d0 Unable to handle kernel NULL pointer dereference at virtual address pgd = c7028000 [] *pgd=87bb7031, *pte=, *ppte= Internal error: Oops: 0 [#1] Modules linked in: CPU: 0Not tainted (2.6.29-omap1-05523-g4530004-dirty #375) PC is at 0x0 LR is at musb_platform_set_mode+0x80/0xbc pc : [<>]lr : []psr: 6093 sp : c7b81ed0 ip : c7b81e00 fp : c7b81ee4 r10: c7b81f70 r9 : c79bebb8 r8 : c03705c8 r7 : 0005 r6 : a013 r5 : c78280d8 r4 : c78281b4 r3 : 6093 r2 : c035995c r1 : c7828000 r0 : c78281b4 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 87028019 DAC: 0015 Process echo (pid: 1286, stack limit = 0xc7b802e0) Stack: (0xc7b81ed0 to 0xc7b82000) 1ec0: c7bb6000 c78280d8 c7b81f04 c7b81ee8 1ee0: c01eef34 c01ef1d0 c793d278 0005 c79beba0 c035868c c7b81f14 c7b81f08 1f00: c01b3354 c01eeec0 c7b81f44 c7b81f18 c00dedf4 c01b333c c7b81f70 c7831340 1f20: 4001d000 c7b81f70 0005 4001d000 c7b8 c7b81f6c c7b81f48 1f40: c009b404 c00decf0 c7831340 0005 1f60: c7b81fa4 c7b81f70 c009b8c4 c009b354 c002ff88 1f80: 0005 4001d000 401c1600 0004 c0029f08 c7b81fa8 1fa0: c0029d60 c009b88c 0005 4001d000 0001 4001d000 0005 1fc0: 0005 4001d000 401c1600 0004 0005 001f 0006e02d 0006c67c 1fe0: bee46c28 4010a78c 4015799c 6010 0001 Backtrace: [] (musb_platform_set_mode+0x0/0xbc) from [] (musb_mode_store+0x80/0x9c) r5:c78280d8 r4:c7bb6000 [] (musb_mode_store+0x0/0x9c) from [] (dev_attr_store+0x24/0x28) r7:c035868c r6:c79beba0 r5:0005 r4:c793d278 [] (dev_attr_store+0x0/0x28) from [] (sysfs_write_file+0x110/0x144) [] (sysfs_write_file+0x0/0x144) from [] (vfs_write+0xbc/0x14c) [] (vfs_write+0x0/0x14c) from [] (sys_write+0x44/0x70) r7:0005 r6:c7831340 r5: r4: [] (sys_write+0x0/0x70) from [] (ret_fast_syscall+0x0/0x2c) r8:c0029f08 r7:0004 r6:401c1600 r5:4001d000 r4:0005 Code: bad PC value. ---[ end trace 1dc402be61e486ba ]--- Segmentation fault -- 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
[APPLIED] [PATCH] SDRC: prevent null pointer dereference if sdrc_init_params
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: c4df5a4d436bc3aea65cc665025d5ce62c8dfe09 PatchWorks http://patchwork.kernel.org/patch/13863/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=c4df5a4d436bc3aea65cc665025d5ce62c8dfe09 -- 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
[APPLIED] [PATCH] RX51: connect VAUX3 to MMC2
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: ac709382c70b02f84ba51b987fddafe3464a751b PatchWorks http://patchwork.kernel.org/patch/13959/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ac709382c70b02f84ba51b987fddafe3464a751b -- 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
[APPLIED] [PATCH] OMAP3: MMC needs CONFIG_REGULATOR{,_TWL4030} now in
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 7b2a455b3167755686e048c193911591c9966418 PatchWorks http://patchwork.kernel.org/patch/14147/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7b2a455b3167755686e048c193911591c9966418 -- 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: MMC needs CONFIG_REGULATOR{,_TWL4030} now in defconfigs
On Tuesday 24 March 2009, Paul Walmsley wrote: > MMC doesn't work after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf unless > CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 are present in the .config. > Add those in for all OMAP3 defconfigs. Tested on BeagleBoard, but this is > presumably needed for anything with MMC and TWL4030. > > Signed-off-by: Paul Walmsley > Cc: David Brownell Acked-by: David Brownell I seem to have given up on updating defconfigs, but that doesn't mean it's not a good thing to do! Same thing with twl4030 GPIO support, on most of those platforms. -- 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
[APPLIED] [PATCH] OMAP: mmc_twl4030 nicely disable vmmc_aux
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 0268abf95f935c2fe45f778b2a223685e68c7823 PatchWorks http://patchwork.kernel.org/patch/13958/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0268abf95f935c2fe45f778b2a223685e68c7823 -- 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: tidspbridge git repository
On Mon, Mar 23, 2009 at 9:47 PM, Tony Lindgren wrote: > * ameya.pala...@nokia.com [090323 00:42]: >> Hi Tony, >> >> I have collected latest patches for tidspbridge at: >> git://gitorious.org/tidspbridge/mainline.git >> >> Branch is: tidspbridge >> >> It is based on your pm branch. >> Can you pull it to your tidspbridge branch? > > What dependencies are there to the PM branch? > > To me it sounds like you should rebase your tidspbridge branch > against the mainline kernel as the drivers should be arch > independent. > > If something is missing from the mainline kernel to rebase and > compile tidspbridge against the mainline, we need to fix those > issues. Last time I tried it worked fine, with one minor issue: http://github.com/felipec/linux-omap/commit/1ae534c0ab22e57dd986c50adddc83e2ec42f970 Btw, it seems the 2.6.28-omap1 tag didn't have the defconfig updated. -- 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
[PATCH] OMAP3: MMC needs CONFIG_REGULATOR{,_TWL4030} now in defconfigs
MMC doesn't work after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf unless CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 are present in the .config. Add those in for all OMAP3 defconfigs. Tested on BeagleBoard, but this is presumably needed for anything with MMC and TWL4030. Signed-off-by: Paul Walmsley Cc: David Brownell --- arch/arm/configs/omap3_beagle_defconfig |3 ++- arch/arm/configs/omap3_evm_defconfig |3 ++- arch/arm/configs/omap3_pandora_defconfig |3 ++- arch/arm/configs/omap_3430sdp_defconfig |3 ++- arch/arm/configs/omap_ldp_defconfig |3 ++- arch/arm/configs/overo_defconfig |2 ++ 6 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/arm/configs/omap3_beagle_defconfig b/arch/arm/configs/omap3_beagle_defconfig index 194eafa..aeeac33 100644 --- a/arch/arm/configs/omap3_beagle_defconfig +++ b/arch/arm/configs/omap3_beagle_defconfig @@ -1040,10 +1040,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig index f276c3a..018c9e1 100644 --- a/arch/arm/configs/omap3_evm_defconfig +++ b/arch/arm/configs/omap3_evm_defconfig @@ -1098,10 +1098,11 @@ CONFIG_RTC_LIB=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap3_pandora_defconfig b/arch/arm/configs/omap3_pandora_defconfig index 1c2b7a2..3c467fc 100644 --- a/arch/arm/configs/omap3_pandora_defconfig +++ b/arch/arm/configs/omap3_pandora_defconfig @@ -1156,10 +1156,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index f7b1bd6..b686f34 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -1165,10 +1165,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index d88e6d7..a41b844 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -1104,10 +1104,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/overo_defconfig b/arch/arm/configs/overo_defconfig index 3bdbf94..dcca647 100644 --- a/arch/arm/configs/overo_defconfig +++ b/arch/arm/configs/overo_defconfig @@ -1601,9 +1601,11 @@ CONFIG_RTC_DRV_TWL4030=y # Voltage and Current regulators # # CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # -- 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: Beagle can't mount rootfs from MMC after regulator updates
Hi, On Tue, 24 Mar 2009, Paul Walmsley wrote: > The BeagleBoard rev B4 here can't mount its root filesystem from MMC after > 3fe326511c66ab842ef0a09a1f4c564b1a8beecf, "mmc-twl4030 uses regulator > framework". This is with omap3_beagle_defconfig and rootwait in the > kernel command line. Kernel hangs after: > > Waiting for root device /dev/mmcblk0p2... Turns out this is due to missing CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 in the defconfigs; patch coming shortly. - 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
Beagle can't mount rootfs from MMC after regulator updates
Hi, The BeagleBoard rev B4 here can't mount its root filesystem from MMC after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf, "mmc-twl4030 uses regulator framework". This is with omap3_beagle_defconfig and rootwait in the kernel command line. Kernel hangs after: Waiting for root device /dev/mmcblk0p2... Will look at this in a few hours unless Dave beats me to it ;-) - 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: PM branch rebased to 2.6.29
On Tue, 2009-03-24 at 13:21 -0700, Kevin Hilman wrote: > Peter Barada wrote: > > On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: > >> Peter Barada writes: > >> > >>> On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > FYI... > > The PM branch has now been rebased to today's linux-omap HEAD which is > based on v2.6.29-rc8. The previous PM branch has been renamed to > pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > (yet) have the latest PM branch. If not, you can use my PM tree[1] > directly. Also, pm-2.6.28 will only be available on my tree. > > Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > suspend and in PM idle with minimal kernel. No testing yet done for > CPUidle or DVFS. Please test on your hardware and submit results to > the list. Thanks. > >>> Kevin, did you build/test with > >>> the /arc/arm/config/omap3_beagle_defconfig, and > >>> arc/arm/configs/rx51_defconfig or some other config(could you send it to > >>> me if it isn't in the PM tree)? > >> I started with the ones in the tree, but I disable most of the drivers > >> and turn on some debugging features. Attached is the one I used for > >> beagle. > >> [...] > > > > Hmm, I modified your config to add smc911x support so I can have an > > nfsroot, added selector/code for my board(based on omap3beagle.c) and > > brought it up on my hardware, but I'm not sure if its working correctly. > > It does look to pause in the suspend sate, and comes out when I hit a > > key on the console, but the messages don't look quite right as > > core_pwrdm and per_pwrdm state they didn't go into state 1 (full log > > attached): > > > > omap3530# echo mem > /sys/power/state > > PM: Syncing filesystems ... done. > > PM: Preparing system for mem sleep > > Freezing user space processes ... (elapsed 0.00 seconds) done. > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > > PM: Entering mem sleep > > Powerdomain (core_pwrdm) didn't enter target state 1 > > Powerdomain (per_pwrdm) didn't enter target state 1 > > Could not enter target state in pm_suspend > > eth0: smc911x_reset timeout waiting for PM restore > > > > eth0: link down > > PM: Finishing wakeup. > > Restarting tasks ... done. > > omap3530# > > omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > > > > > > Is this expected? > > > > Yes, you haven't allowed the UART clocks to go off during idle/suspend > and there are UARTs in both CORE and PER. > > Try this before going into suspend: > >echo 1 > /sys/power/clocks_off_while_idle > > This will allow UART clocks to be disabled on suspend, and also allow > them to be disabled after 5 seconds of UART inactivity allowing > retention in idle as well. that Fixed PER, but CORE still says it couldn't go into state 1: omap3530# echo 1 > /sys/power/clocks_off_while_idle omap3530# echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > > Kevin -- 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: PM branch rebased to 2.6.29
Peter Barada wrote: On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: Peter Barada writes: On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. [...] Hmm, I modified your config to add smc911x support so I can have an nfsroot, added selector/code for my board(based on omap3beagle.c) and brought it up on my hardware, but I'm not sure if its working correctly. It does look to pause in the suspend sate, and comes out when I hit a key on the console, but the messages don't look quite right as core_pwrdm and per_pwrdm state they didn't go into state 1 (full log attached): omap3530# echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Is this expected? Yes, you haven't allowed the UART clocks to go off during idle/suspend and there are UARTs in both CORE and PER. Try this before going into suspend: echo 1 > /sys/power/clocks_off_while_idle This will allow UART clocks to be disabled on suspend, and also allow them to be disabled after 5 seconds of UART inactivity allowing retention in idle as well. 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, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: > Peter Barada writes: > > > On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > >> FYI... > >> > >> The PM branch has now been rebased to today's linux-omap HEAD which is > >> based on v2.6.29-rc8. The previous PM branch has been renamed to > >> pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > >> (yet) have the latest PM branch. If not, you can use my PM tree[1] > >> directly. Also, pm-2.6.28 will only be available on my tree. > >> > >> Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > >> suspend and in PM idle with minimal kernel. No testing yet done for > >> CPUidle or DVFS. Please test on your hardware and submit results to > >> the list. Thanks. > > > > Kevin, did you build/test with > > the /arc/arm/config/omap3_beagle_defconfig, and > > arc/arm/configs/rx51_defconfig or some other config(could you send it to > > me if it isn't in the PM tree)? > > I started with the ones in the tree, but I disable most of the drivers > and turn on some debugging features. Attached is the one I used for > beagle. > [...] Hmm, I modified your config to add smc911x support so I can have an nfsroot, added selector/code for my board(based on omap3beagle.c) and brought it up on my hardware, but I'm not sure if its working correctly. It does look to pause in the suspend sate, and comes out when I hit a key on the console, but the messages don't look quite right as core_pwrdm and per_pwrdm state they didn't go into state 1 (full log attached): omap3530# echo mem > /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Is this expected? -- Peter Barada NoLo Version : 2.4.6-OMAP3503 0001 NoLo Build : LPD386 Tue Nov 25 15:00:19 CST 2008 NoLo Compiler: gcc version 4.2.1 Image type : Elf Boot Device : NAND * LogicLoader (c) Copyright 2002-2008, Logic Product Development, Inc. All Rights Reserved. Version 2.4.6-OMAP3503 0001 * losh> ifconfig sm0 /dev/config losh> load elf /tftp/192.168.3.5:u-boot loading from /tftp/192.168.3.5:u-boot: . ELF section 0: download address: 0x80208000 load address: 0x80e8 loaded 140108 @ 0x80e8 Ram ...done file loaded losh> exec U-Boot 1.1.4 (Mar 13 2009 - 16:32:42) OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz OMAP3430LV_SOM 0.1 Version + mDDR (Boot NAND) DRAM: 128 MB FLASH: initialize in sync mode NAND: 256 MiB Read production data: done Part Number : 1010194 Model Name : SOMOMAP3530-10-1672IFCR-A Serial Number: 3408M03305 In:serial Out: serial Err: serial Hit any key to stop autoboot: 6 0 => boot DRIVER_VERSION : 101, DATECODE : 092706 LAN9x18 (0x9211) detected. start Auto negotiation... (take ~2sec) Auto negotiation complete, 100BaseTX, full duplex TFTP from server 192.168.3.5; our IP address is 192.168.3.11 Filename 'uImage'. Load address: 0x8100 Loading: *# # # # # done Bytes transferred = 1806408 (1b9048 hex) ## Booting image at 8100 ... Image Name: Linux-2.6.29-rc8-omap1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1806344 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux done, booting the kernel. Linux version 2.6.29-rc8-omap1 (pe...@blackhole) (gcc version 4.1.2) #5 PREEMPT Tue Mar 24 15:49:34 EDT 2009 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP OMAP3530LV_SOM board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c038f5dc, node_mem_map c03b9000 Normal zone: 256 pages used for memmap Normal zone: 0 pages
[APPLIED] [PATCH 2/5] omap mmc: Add better MMC low-level init
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: ed39a47fbc83f2c0d82aaadca7dec9fe8f061f83 PatchWorks http://patchwork.kernel.org/patch/13766/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ed39a47fbc83f2c0d82aaadca7dec9fe8f061f83 -- 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: mmc_twl4030 nicely disable vmmc_aux
On Tuesday 24 March 2009, Adrian Hunter wrote:
> >From 1a3f939d95122d8e58a3750cf5bce09247357203 Mon Sep 17 00:00:00 2001
> From: Adrian Hunter
>
> The MMC driver turns the power off before it turns it
> on. To avoid regulator warnings, vmmc_aux must only be
> disabled if it has previously been enabled.
>
> Signed-off-by: Adrian Hunter
Acked-by: David Brownell
good catch.
> ---
> arch/arm/mach-omap2/mmc-twl4030.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
> b/arch/arm/mach-omap2/mmc-twl4030.c
> index 2ff50f0..cb56fe2 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.c
> +++ b/arch/arm/mach-omap2/mmc-twl4030.c
> @@ -305,7 +305,7 @@ static int twl_mmc23_set_power(struct device *dev, int
> slot, int power_on, int v
> ret = mmc_regulator_set_ocr(c->vcc, 0);
> }
> } else {
> - if (c->vcc_aux)
> + if (c->vcc_aux && (ret = regulator_is_enabled(c->vcc_aux)) > 0)
> ret = regulator_disable(c->vcc_aux);
> if (ret == 0)
> ret = mmc_regulator_set_ocr(c->vcc, 0);
> --
> 1.5.6.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
Peter Barada writes: > On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: >> FYI... >> >> The PM branch has now been rebased to today's linux-omap HEAD which is >> based on v2.6.29-rc8. The previous PM branch has been renamed to >> pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not >> (yet) have the latest PM branch. If not, you can use my PM tree[1] >> directly. Also, pm-2.6.28 will only be available on my tree. >> >> Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in >> suspend and in PM idle with minimal kernel. No testing yet done for >> CPUidle or DVFS. Please test on your hardware and submit results to >> the list. Thanks. > > Kevin, did you build/test with > the /arc/arm/config/omap3_beagle_defconfig, and > arc/arm/configs/rx51_defconfig or some other config(could you send it to > me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. Kevin > I'm trying to bring up your PM branch > on my OMAP3530_LV_SOM, using LDP as a starting point, and it goes into > retention but doesn't come back out, and rather than thrash on the LDP > defconfig, start with a config/code that is known to work. I'm also > resnapping to commit c3127068... to jump to the latest from your tree > and start my port over. I have to get suspend/resume working first > before I start working in all the drivers, and check that suspend/resume > works for each functional addition... > > Thanks in advance! > [...] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28-omap1 # Tue Mar 24 09:07:57 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y CONFIG_FREEZER=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_AR
Re: PM branch rebased to 2.6.29
On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: > FYI... > > The PM branch has now been rebased to today's linux-omap HEAD which is > based on v2.6.29-rc8. The previous PM branch has been renamed to > pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not > (yet) have the latest PM branch. If not, you can use my PM tree[1] > directly. Also, pm-2.6.28 will only be available on my tree. > > Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in > suspend and in PM idle with minimal kernel. No testing yet done for > CPUidle or DVFS. Please test on your hardware and submit results to > the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I'm trying to bring up your PM branch on my OMAP3530_LV_SOM, using LDP as a starting point, and it goes into retention but doesn't come back out, and rather than thrash on the LDP defconfig, start with a config/code that is known to work. I'm also resnapping to commit c3127068... to jump to the latest from your tree and start my port over. I have to get suspend/resume working first before I start working in all the drivers, and check that suspend/resume works for each functional addition... Thanks in advance! > Kevin > > -- > > Misc. conflicts/issues resolved after rebase: > > - no longer safe to use getnstimeofday() in suspend path since timekeeping > subsystem is also suspended in the suspend path. PM debug timing has > been converted to use sched_clock() which is 32k sync-timer based. > > - Update board-rx51.c to use common OMAP3 OPPs > > Known issues: > > - Beagle: MMC: off-mode needs work in MMC driver, so if you hit off > and have a rootfs on MMC, you're dead. > > - Beagle: MMC regulator: unbalanced disables. This happens on boot > and during suspend/resume. I don't think this is related to the PM > branch, but is probably in linux-omap HEAD also, but didn't test. > > Linux version 2.6.29-rc8-omap1-arm-omap3beagle-default-05653-gd803372-dirty > (khil...@vence) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #4 PREEMPT > Tue Mar 17 21:38:09 PDT 2009 > [...] > 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:303 > twl4030_mmc_init:318 > 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 <--> 0 mV normal standby > regulator: VSIM: 1800 <--> 3000 mV normal standby > [...] > mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock > [ cut here ] > WARNING: at > /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 > regulator_disable+0x64/0x90() > unbalanced disables for supply mmci-omap-hs.0-vmmc > Modules linked in: > [] (dump_stack+0x0/0x14) from [] (warn_slowpath+0x6c/0x88) > [] (warn_slowpath+0x0/0x88) from [] > (regulator_disable+0x64/0x90) > r3:c79dc2a0 r2:c03390cb > r7:c78e8c20 r6:c78aac38 r5:c78e8c20 r4:fffb > [] (regulator_disable+0x0/0x90) from [] > (mmc_regulator_set_ocr+0xb0/0xcc) > r7:c78e8c20 r6:0001 r5: r4: > [] (mmc_regulator_set_ocr+0x0/0xcc) from [] > (twl_mmc1_set_power+0xc0/0xec) > r7:c784f538 r6: r5: r4:c039185c > [] (twl_mmc1_set_power+0x0/0xec) from [] > (omap_mmc_set_ios+0x54/0x2b0) > r7:c784f538 r6:c784f5c0 r5:c784f400 r4:c7844380 > [] (omap_mmc_set_ios+0x0/0x2b0) from [] > (mmc_power_off+0x54/0x58) > r7:c784f400 r6:c7910400 r5: r4:c784f400 > [] (mmc_power_off+0x0/0x58) from [] > (mmc_start_host+0x14/0x24) > [] (mmc_start_host+0x0/0x24) from [] > (mmc_add_host+0x58/0x64) > r5: r4:c784f400 > [] (mmc_add_host+0x0/0x64) from [] > (omap_mmc_probe+0x3d0/0x548) > r5:c784f5c0 r4: > [] (omap_mmc_probe+0x0/0x548) from [] > (platform_drv_probe+0x20/0x24) > [] (platform_drv_probe+0x0/0x24) from [] > (driver_probe_device+0xd4/0x180) > [] (driver_probe_device+0x0/0x180) from [] > (__driver_attach+0x68/0x8c) > r7:c789d140 r6:c038ada4 r5:c7910490 r4:c7910408 > [] (__driver_attach+0x0/0x8c) from [] > (bus_for_each_dev+0x4c/0x80) > r7:c789d140 r6:c038ada4 r5:c01dc7ec r4: > [] (bus_for_each_dev+0x0/0x80) from [] > (driver_attach+0x20/0x28) > r6:c038ada4 r5: r4: > [] (driver_attach+0x0/0x28) from [] > (bus_add_driver+0xa8/0x210) > [] (bus_add_driver+0x0/0x210) from [] > (driver_register+0x98/0x120) > r8:0001 r7:c001e814 r6:c038ada4 r5: r4:c0024a44 > [] (driver_register+0x0/0x120) from [] > (platform_driver_register+0x6c/0x88) > r9: r8:0001 r7:c001e814 r6: r5: > r4:c0024a44 > [] (platform_driver_reg
Re: [PATCH 00/08] OMAP3: SR: Fixes in Smartreflex driver - Resending
"Reddy, Teerth" writes:
> Resending the patches sent by Rajendra after fixing Kevin's comments and
> cleanup.
>
> This series fixes a set of defects/issues in Smartreflex driver. SR
> autocompensation is now functional and is validated with these patches on a
> ES3.1 based SDP with the N values in Efuse.
>
> Patches apply on top of the pm-2.6.28 branch from Kevin's pm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
>
This series doesn't compile unless SRF is enabled which after a little
more digging makes me see that SmartReflex is not pretty tightly
coupled to SRF.
I don't think SmartReflex support need to be dependent on SRF? It
seems like the resource_get_level() calls should be replaced by OMAP
PM layer calls. In particular, resource_get_level("vdd_opp1") could
be replaced by omap_pm_dsp_get_opp() etc.
Also, one more nitpick about cleanup while we're at it:
Can you convert all the bit defines (0x1 << n) into BIT(n)
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: How to test regulator driver?
On Tue, Mar 24, 2009 at 05:14:58PM +0530, Aggarwal, Anuj wrote: > I am seriously confused on how to fetch the struct device * in my > consumer driver, for an already registered regulator. I am planning to > use this consumer driver as a part of my CPU freq/CPU idle framework > but I don't know what to pass in regulator_get. Your consumer driver should not be using the struct device for the regulator when calling regulator_get(). They should never need to know anything about the struct device of the regulator that is providing a supply to them. The consumer should use a fixed device name and the struct device for itself, these will then be resolved to an actual regulator by the core based on the machine constraints. In the specific case of cpufreq where there is no struct device for the consumer use NULL when calling regulator_get(). -- 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] RX51: connect VAUX3 to MMC2
From 6d7a4c9322e70e83bdcf66d151c1ce56ba2f949f Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 29 +++--
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 6e23587..41bb392 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -30,6 +30,8 @@
#include "mmc-twl4030.h"
+#define SYSTEM_REV_B_USES_VAUX3 0x1699
+#define SYSTEM_REV_S_USES_VAUX3 0x8
#define SMC91X_CS 1
#define SMC91X_GPIO_IRQ 54
@@ -306,7 +308,7 @@ static struct regulator_init_data rx51_vaux2 = {
};
/* VAUX3 - adds more power to VIO_18 rail */
-static struct regulator_init_data rx51_vaux3 = {
+static struct regulator_init_data rx51_vaux3_cam = {
.constraints = {
.name = "VCAM_DIG_18",
.min_uV = 180,
@@ -319,6 +321,22 @@ static struct regulator_init_data rx51_vaux3 = {
},
};
+static struct regulator_init_data rx51_vaux3_mmc = {
+ .constraints = {
+ .name = "VMMC2_30",
+ .min_uV = 280,
+ .max_uV = 300,
+ .apply_uV = true,
+ .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 = &rx51_vmmc2_supply,
+};
+
static struct regulator_init_data rx51_vaux4 = {
.constraints = {
.name = "VCAM_ANA_28",
@@ -429,10 +447,8 @@ static struct twl4030_platform_data rx51_twldata = {
.vaux1 = &rx51_vaux1,
.vaux2 = &rx51_vaux2,
- .vaux3 = &rx51_vaux3,
.vaux4 = &rx51_vaux4,
.vmmc1 = &rx51_vmmc1,
- .vmmc2 = &rx51_vmmc2,
.vsim = &rx51_vsim,
.vdac = &rx51_vdac,
};
@@ -448,6 +464,13 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
static int __init rx51_i2c_init(void)
{
+ if ((system_rev >= SYSTEM_REV_S_USES_VAUX3 && system_rev < 0x100) ||
+ system_rev >= SYSTEM_REV_B_USES_VAUX3)
+ rx51_twldata.vaux3 = &rx51_vaux3_mmc;
+ else {
+ rx51_twldata.vaux3 = &rx51_vaux3_cam;
+ rx51_twldata.vmmc2 = &rx51_vmmc2;
+ }
omap_register_i2c_bus(1, 2600, rx51_peripherals_i2c_board_info_1,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
omap_register_i2c_bus(2, 100, NULL, 0);
--
1.5.6.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
[PATCH] OMAP: mmc_twl4030 nicely disable vmmc_aux
From 1a3f939d95122d8e58a3750cf5bce09247357203 Mon Sep 17 00:00:00 2001
From: Adrian Hunter
The MMC driver turns the power off before it turns it
on. To avoid regulator warnings, vmmc_aux must only be
disabled if it has previously been enabled.
Signed-off-by: Adrian Hunter
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 2ff50f0..cb56fe2 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -305,7 +305,7 @@ static int twl_mmc23_set_power(struct device *dev, int
slot, int power_on, int v
ret = mmc_regulator_set_ocr(c->vcc, 0);
}
} else {
- if (c->vcc_aux)
+ if (c->vcc_aux && (ret = regulator_is_enabled(c->vcc_aux)) > 0)
ret = regulator_disable(c->vcc_aux);
if (ret == 0)
ret = mmc_regulator_set_ocr(c->vcc, 0);
--
1.5.6.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: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Ameya, > Is there any need to pass "HANDLE hPCtxt" to DRV_RemoveProcContext() > function? > -- It should work even if you don't pass the hPCtxt. This function requires some rework to avoid this confusion. Thanks for bringing up this question. Thank you, Best regards, Hari > -Original Message- > From: Ameya Palande [mailto:ameya.pala...@nokia.com] > Sent: Tuesday, March 24, 2009 6:56 AM > To: Kanigeri, Hari > Cc: Ameya Palande; linux-omap@vger.kernel.org > Subject: Re: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup > > Hi Hari, > > ext Kanigeri, Hari wrote: > > Hi Amey, > > > >> I am trying to understand this patch. > >> I see that pCtxtclosed is passed to DRV_RemoveProcContext() function > >> but it is not used anywhere inside it. I was expecting to see a > >> statement there which should free its memory. > > > > This pointer is getting freed indirectly through the pCtxt2 pointer. The > call to the function "DRV_GetProcContext((u32)hProcess, hDRVObject, > &pCtxt2, NULL, 0)" returns pCtxt2, which is same as pCtxtclosed that is > passed to this function. > > In a way, the call to DRV_GetProcContext is kind of redundant, but I > think it is present here to provide the support to extract the Process > Context when only the PID is passed in. > > Thanks for the explanation :) > Is there any need to pass "HANDLE hPCtxt" to DRV_RemoveProcContext() > function? > > 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] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Hi Hari, ext Kanigeri, Hari wrote: > Hi Amey, > >> I am trying to understand this patch. >> I see that pCtxtclosed is passed to DRV_RemoveProcContext() function >> but it is not used anywhere inside it. I was expecting to see a >> statement there which should free its memory. > > This pointer is getting freed indirectly through the pCtxt2 pointer. The call > to the function "DRV_GetProcContext((u32)hProcess, hDRVObject, &pCtxt2, NULL, > 0)" returns pCtxt2, which is same as pCtxtclosed that is passed to this > function. > In a way, the call to DRV_GetProcContext is kind of redundant, but I think it > is present here to provide the support to extract the Process Context when > only the PID is passed in. Thanks for the explanation :) Is there any need to pass "HANDLE hPCtxt" to DRV_RemoveProcContext() function? 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] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Hi Amey, > I am trying to understand this patch. > I see that pCtxtclosed is passed to DRV_RemoveProcContext() function > but it is not used anywhere inside it. I was expecting to see a > statement there which should free its memory. This pointer is getting freed indirectly through the pCtxt2 pointer. The call to the function "DRV_GetProcContext((u32)hProcess, hDRVObject, &pCtxt2, NULL, 0)" returns pCtxt2, which is same as pCtxtclosed that is passed to this function. In a way, the call to DRV_GetProcContext is kind of redundant, but I think it is present here to provide the support to extract the Process Context when only the PID is passed in. Thank you, Best regards, Hari > -Original Message- > From: Ameya Palande [mailto:2am...@gmail.com] > Sent: Tuesday, March 24, 2009 5:05 AM > To: Kanigeri, Hari > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup > > Hi Hari, > > On Mon, Mar 23, 2009 at 8:49 PM, Kanigeri, Hari > wrote: > > DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject, > > pCtxtclosed, (void *)pCtxtclosed- > >pid); > > I am trying to understand this patch. > I see that pCtxtclosed is passed to DRV_RemoveProcContext() function > but it is not used anywhere inside it. I was expecting to see a > statement there which should free its memory. > > Any pointers? > > 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: How to test regulator driver?
I am seriously confused on how to fetch the struct device * in my consumer driver, for an already registered regulator. I am planning to use this consumer driver as a part of my CPU freq/CPU idle framework but I don't know what to pass in regulator_get. Should I register my regulator device as a platform_device as against an i2c_client device what I am having now? Other regulator drivers (drivers/regulator/twl4030-regulator.c, wm8400.c etc) are doing the same thing in their code. Using the current approach, I am facing difficulty in getting the struct device * for invoking the regulator_get()? Otherwise, can I expose one function in my regulator driver which will return the appropriate struct device * when user calls it with a supply name string? This device pointer then will be used in my consumer driver while calling the regulator_get API? Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Inc Ph: +91-80-2509-9542 TI IP Ph: 509-9542 PSP Products RSS Feed PSP Product Announcements > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Mark Brown > Sent: Monday, March 09, 2009 9:03 PM > To: Anuj Aggarwal > Cc: Linux OMAP List > Subject: Re: How to test regulator driver? > > On Mon, Mar 09, 2009 at 08:32:55PM +0530, Anuj Aggarwal wrote: > > > I want to test my regulator driver by writing a small kernel module. > > But I am a little confused as what should be passed as the first > > argument of regulator_get(). How would the kernel module know about > > the device pointer that needs to be passed to the _get function? > > regulator_get() takes the struct device for the consumer as an argument > so it depends on what your consumer is. For test purposes there's an > existing virtual consumer driver in the tree which should hopefully save > you having to write your own - it allows you to poke the settings from > sysfs. drivers/regulator/virtual.c > > Questions like this that aren't OMAP-specific should really be asked on > the relevant general list (in this case linux-kernel). > -- > 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 08/08] OMAP3: SR: Replace SR_PASS/FAIL,SR_TRUE/FALSE with standard kernel values
From: Teerth Reddy
This patch has some cleanup , replacing SR_PASS/FAIL,SR_TRUE/FALSE
with standard kernel values.
Signed-off-by: Teerth Reddy
---
arch/arm/mach-omap2/smartreflex.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:42:33.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:45:59.336965640 +0530
@@ -411,7 +411,7 @@
if (retries_cnt > 10) {
pr_info("Loop count exceeded in check SR I2C"
"write\n");
- return SR_FAIL;
+ return 1;
}
if (loop_cnt > 50) {
retries_cnt++;
@@ -421,7 +421,7 @@
vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
}
- return SR_PASS;
+ return 0;
}
static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
@@ -476,7 +476,7 @@
if (nvalue_reciprocal == 0) {
pr_notice("OPP%d doesn't support SmartReflex\n",
target_opp_no);
- return SR_FALSE;
+ return false;
}
sr_write_reg(sr, NVALUERECIPROCAL, nvalue_reciprocal);
@@ -526,7 +526,7 @@
/* SRCONFIG - enable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, SRCONFIG_SRENABLE);
- return SR_TRUE;
+ return true;
}
static void sr_disable(struct omap_sr *sr)
@@ -591,11 +591,11 @@
sr->is_autocomp_active = 0;
/* Reset the volatage for current OPP */
sr_reset_voltage(srid);
- return SR_TRUE;
+ return true;
} else {
pr_warning("SR%d: VDD autocomp is not active\n",
srid);
- return SR_FALSE;
+ return false;
}
}
@@ -711,7 +711,7 @@
if (retries_cnt > 10) {
pr_info("Loop count exceeded in check SR I2C"
"write\n");
- return SR_FAIL;
+ return 1;
}
if (loop_cnt > 50) {
retries_cnt++;
@@ -731,7 +731,7 @@
sr_start_vddautocomap(SR2, target_opp_no);
}
- return SR_PASS;
+ return 0;
}
/* Sysfs interface to select SR VDD1 auto compensation */
--
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/08] OMAP3: SR: Remove redundunt defines
From: Rajendra Nayak
This patch removes the local defines (PRCM_VDD1/2) in smartreflex
driver and uses the already existing global definitions (VDD1_OPP/VDD2_OPP)
from omap34xx.h file.
Signed-off-by: Rajendra Nayak
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/resource34xx.c |6 +++---
arch/arm/mach-omap2/smartreflex.c |8
arch/arm/mach-omap2/smartreflex.h |3 ---
3 files changed, 7 insertions(+), 10 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c 2009-03-24
14:25:28.045987206 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c2009-03-24
14:41:36.122985549 +0530
@@ -217,7 +217,7 @@
/* Send pre notification to CPUFreq */
cpufreq_notify_transition(&freqs_notify, CPUFREQ_PRECHANGE);
#endif
- t_opp = ID_VDD(PRCM_VDD1) |
+ t_opp = ID_VDD(VDD1_OPP) |
ID_OPP_NO(mpu_opps[target_level].opp_id);
/* For VDD1 OPP3 and above, make sure the interconnect
@@ -257,7 +257,7 @@
return 0;
l3_freq = get_freq(l3_opps + MAX_VDD2_OPP,
target_level);
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[target_level].opp_id);
if (resp->curr_level > target_level) {
/* Scale Frequency and then voltage */
@@ -278,7 +278,7 @@
if (ret) {
#ifdef CONFIG_OMAP_SMARTREFLEX
/* Setting clock failed, revert voltage */
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[resp->curr_level].
opp_id);
sr_voltagescale_vcbypass(t_opp,
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:21.798416209 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:36.123985519 +0530
@@ -677,7 +677,7 @@
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
- if (vdd == PRCM_VDD1) {
+ if (vdd == VDD1_OPP) {
sr_status = sr_stop_vddautocomap(SR1);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -686,7 +686,7 @@
OMAP3_PRM_VC_CMD_VAL_0_OFFSET);
reg_addr = R_VDD1_SR_CONTROL;
- } else if (vdd == PRCM_VDD2) {
+ } else if (vdd == VDD2_OPP) {
sr_status = sr_stop_vddautocomap(SR2);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -725,9 +725,9 @@
udelay(T2_SMPS_UPDATE_DELAY);
if (sr_status) {
- if (vdd == PRCM_VDD1)
+ if (vdd == VDD1_OPP)
sr_start_vddautocomap(SR1, target_opp_no);
- else if (vdd == PRCM_VDD2)
+ else if (vdd == VDD2_OPP)
sr_start_vddautocomap(SR2, target_opp_no);
}
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.h
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.h2009-03-24
14:25:28.046987177 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.h 2009-03-24
14:41:36.123985519 +0530
@@ -171,9 +171,6 @@
/* R_DCDC_GLOBAL_CFG register, SMARTREFLEX_ENABLE values */
#define DCDC_GLOBAL_CFG_ENABLE_SRFLX 0x08
-/* VDDs*/
-#define PRCM_VDD1 1
-#define PRCM_VDD2 2
#define PRCM_MAX_SYSC_REGS 30
/*
--
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 06/08] OMAP3: SR: Replace printk's with pr_* calls
From: Rajendra Nayak
This patch replaces all the printk(KERN_* with pr_* calls.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/smartreflex.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:06.054889481 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:21.798416209 +0530
@@ -78,7 +78,7 @@
static int sr_clk_enable(struct omap_sr *sr)
{
if (clk_enable(sr->clk) != 0) {
- printk(KERN_ERR "Could not enable %s\n", sr->clk->name);
+ pr_err("Could not enable %s\n", sr->clk->name);
return -1;
}
@@ -170,7 +170,7 @@
sr->clk_length = SRCLKLENGTH_38MHZ_SYSCLK;
break;
default :
- printk(KERN_ERR "Invalid sysclk value: %d\n", sys_clk_speed);
+ pr_err("Invalid sysclk value: %d\n", sys_clk_speed);
break;
}
}
@@ -409,7 +409,7 @@
while ((vc_bypass_value & OMAP3430_VALID) != 0x0) {
loop_cnt++;
if (retries_cnt > 10) {
- printk(KERN_INFO "Loop count exceeded in check SR I2C"
+ pr_info("Loop count exceeded in check SR I2C"
"write\n");
return SR_FAIL;
}
@@ -474,7 +474,7 @@
}
if (nvalue_reciprocal == 0) {
- printk(KERN_NOTICE "OPP%d doesn't support SmartReflex\n",
+ pr_notice("OPP%d doesn't support SmartReflex\n",
target_opp_no);
return SR_FALSE;
}
@@ -563,12 +563,12 @@
}
if (sr->is_autocomp_active == 1)
- printk(KERN_WARNING "SR%d: VDD autocomp is already active\n",
+ pr_warning("SR%d: VDD autocomp is already active\n",
srid);
sr->is_autocomp_active = 1;
if (!sr_enable(sr, target_opp_no)) {
- printk(KERN_WARNING "SR%d: VDD autocomp not activated\n", srid);
+ pr_warning("SR%d: VDD autocomp not activated\n", srid);
sr->is_autocomp_active = 0;
if (sr->is_sr_reset == 1)
sr_clk_disable(sr);
@@ -593,7 +593,7 @@
sr_reset_voltage(srid);
return SR_TRUE;
} else {
- printk(KERN_WARNING "SR%d: VDD autocomp is not active\n",
+ pr_warning("SR%d: VDD autocomp is not active\n",
srid);
return SR_FALSE;
}
@@ -709,7 +709,7 @@
while ((vc_bypass_value & OMAP3430_VALID) != 0x0) {
loop_cnt++;
if (retries_cnt > 10) {
- printk(KERN_INFO "Loop count exceeded in check SR I2C"
+ pr_info("Loop count exceeded in check SR I2C"
"write\n");
return SR_FAIL;
}
@@ -749,7 +749,7 @@
unsigned short value;
if (sscanf(buf, "%hu", &value) != 1 || (value > 1)) {
- printk(KERN_ERR "sr_vdd1_autocomp: Invalid value\n");
+ pr_err("sr_vdd1_autocomp: Invalid value\n");
return -EINVAL;
}
@@ -787,7 +787,7 @@
unsigned short value;
if (sscanf(buf, "%hu", &value) != 1 || (value > 1)) {
- printk(KERN_ERR "sr_vdd2_autocomp: Invalid value\n");
+ pr_err("sr_vdd2_autocomp: Invalid value\n");
return -EINVAL;
}
@@ -839,15 +839,15 @@
sr_set_nvalues(&sr2);
sr_configure_vp(SR2);
- printk(KERN_INFO "SmartReflex driver initialized\n");
+ pr_info("SmartReflex driver initialized\n");
ret = sysfs_create_file(power_kobj, &sr_vdd1_autocomp.attr);
if (ret)
- printk(KERN_ERR "sysfs_create_file failed: %d\n", ret);
+ pr_err("sysfs_create_file failed: %d\n", ret);
ret = sysfs_create_file(power_kobj, &sr_vdd2_autocomp.attr);
if (ret)
- printk(KERN_ERR "sysfs_create_file failed: %d\n", ret);
+ pr_err("sysfs_create_file failed: %d\n", ret);
return 0;
}
--
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 05/08] OMAP3: SR: Reset voltage level on SR disable
From: Rajendra Nayak
This patch resets the voltage level for each OPP on SR disable.
Signed-off-by: Rajendra Nayak
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/smartreflex.c | 49 ++
1 files changed, 49 insertions(+)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:00.471057326 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:06.054889481 +0530
@@ -379,6 +379,51 @@
sr->is_sr_reset = 0;
}
+static int sr_reset_voltage(int srid)
+{
+ u32 target_opp_no, vsel = 0;
+ u32 reg_addr = 0;
+ u32 loop_cnt = 0, retries_cnt = 0;
+ u32 vc_bypass_value;
+
+ if (srid == SR1) {
+ target_opp_no = resource_get_level("vdd1_opp");
+ vsel = mpu_opps[target_opp_no].vsel;
+ reg_addr = R_VDD1_SR_CONTROL;
+ } else if (srid == SR2) {
+ target_opp_no = resource_get_level("vdd2_opp");
+ vsel = l3_opps[target_opp_no].vsel;
+ reg_addr = R_VDD2_SR_CONTROL;
+ }
+
+ vc_bypass_value = (vsel << OMAP3430_DATA_SHIFT) |
+ (reg_addr << OMAP3430_REGADDR_SHIFT) |
+ (R_SRI2C_SLAVE_ADDR << OMAP3430_SLAVEADDR_SHIFT);
+
+ prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ while ((vc_bypass_value & OMAP3430_VALID) != 0x0) {
+ loop_cnt++;
+ if (retries_cnt > 10) {
+ printk(KERN_INFO "Loop count exceeded in check SR I2C"
+ "write\n");
+ return SR_FAIL;
+ }
+ if (loop_cnt > 50) {
+ retries_cnt++;
+ loop_cnt = 0;
+ udelay(10);
+ }
+ vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+ }
+ return SR_PASS;
+}
+
static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
{
u32 nvalue_reciprocal, v;
@@ -544,6 +589,8 @@
sr_disable(sr);
sr_clk_disable(sr);
sr->is_autocomp_active = 0;
+ /* Reset the volatage for current OPP */
+ sr_reset_voltage(srid);
return SR_TRUE;
} else {
printk(KERN_WARNING "SR%d: VDD autocomp is not active\n",
@@ -612,6 +659,8 @@
OMAP3430_GR_MOD,
OMAP3_PRM_VP2_CONFIG_OFFSET);
}
+ /* Reset the volatage for current OPP */
+ sr_reset_voltage(srid);
}
}
}
--
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/08] OMAP3: SR: Disable SR autocomp only for CORE trans
From: Rajendra Nayak
This patch disables the Smartreflex auto compensation for
both VDD1 and VDD2 only during CORE transitions in idle path.
Signed-off-by: Rajendra Nayak
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/pm34xx.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c 2009-03-20
10:45:58.505627611 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2009-03-20 10:46:11.362231683
+0530
@@ -321,9 +321,6 @@ void omap_sram_idle(void)
printk(KERN_ERR "Invalid mpu state in sram_idle\n");
return;
}
- /* Disable smartreflex before entering WFI */
- disable_smartreflex(SR1);
- disable_smartreflex(SR2);
pwrdm_pre_transition();
@@ -352,6 +349,9 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state < PWRDM_POWER_ON) {
+ /* Disable smartreflex before entering WFI */
+ disable_smartreflex(SR1);
+ disable_smartreflex(SR2);
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
@@ -412,6 +412,9 @@ void omap_sram_idle(void)
prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
+ /* Enable smartreflex after WFI */
+ enable_smartreflex(SR1);
+ enable_smartreflex(SR2);
}
/* PER */
@@ -432,9 +435,6 @@ void omap_sram_idle(void)
if (core_next_state < PWRDM_POWER_ON)
prm_clear_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
- /* Enable smartreflex after WFI */
- enable_smartreflex(SR1);
- enable_smartreflex(SR2);
pwrdm_post_transition();
--
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/08] OMAP3: SR: Use sysclk for SR CLKLENGTH calc
From: Rajendra Nayak
This patch uses the sysclk to set the SR CLKLENGTH instead
of the OSC clock speed used earlier.
Signed-off-by: Rajendra Nayak
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/smartreflex.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-20
10:49:30.773100978 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-20
10:49:56.473312008 +0530
@@ -146,14 +146,14 @@ static u32 cal_test_nvalue(u32 sennval,
static void sr_set_clk_length(struct omap_sr *sr)
{
- struct clk *osc_sys_ck;
- u32 sys_clk = 0;
+ struct clk *sys_ck;
+ u32 sys_clk_speed;
- osc_sys_ck = clk_get(NULL, "osc_sys_ck");
- sys_clk = clk_get_rate(osc_sys_ck);
- clk_put(osc_sys_ck);
+ sys_ck = clk_get(NULL, "sys_ck");
+ sys_clk_speed = clk_get_rate(sys_ck);
+ clk_put(sys_ck);
- switch (sys_clk) {
+ switch (sys_clk_speed) {
case 1200:
sr->clk_length = SRCLKLENGTH_12MHZ_SYSCLK;
break;
@@ -170,7 +170,7 @@ static void sr_set_clk_length(struct oma
sr->clk_length = SRCLKLENGTH_38MHZ_SYSCLK;
break;
default :
- printk(KERN_ERR "Invalid sysclk value: %d\n", sys_clk);
+ printk(KERN_ERR "Invalid sysclk value: %d\n", sys_clk_speed);
break;
}
}
--
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 02/08] OMAP3: SR: Update VDD1/2 voltages at boot
From: Rajendra Nayak
Currently vdd1 and vdd2 voltages are updated only after OMAP wakes up
from RET/OFF. This patch forces update according to boot OPP on boot.
Signed-off-by: Rajendra Nayak
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/smartreflex.c | 82 +-
1 files changed, 46 insertions(+), 36 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:40:25.024122683 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:40:42.652592893 +0530
@@ -31,15 +31,12 @@
#include
#include
#include
+#include
#include "prm.h"
#include "smartreflex.h"
#include "prm-regbits-34xx.h"
-/* XXX: These should be relocated where-ever the OPP implementation will be */
-u32 current_vdd1_opp;
-u32 current_vdd2_opp;
-
struct omap_sr {
int srid;
int is_sr_reset;
@@ -253,9 +250,11 @@
u32 vpconfig;
if (srid == SR1) {
- vpconfig = PRM_VP1_CONFIG_ERROROFFSET | PRM_VP1_CONFIG_ERRORGAIN
- | PRM_VP1_CONFIG_INITVOLTAGE
- | PRM_VP1_CONFIG_TIMEOUTEN;
+ vpconfig = PRM_VP1_CONFIG_ERROROFFSET |
+ PRM_VP1_CONFIG_ERRORGAIN |
+ PRM_VP1_CONFIG_TIMEOUTEN |
+ mpu_opps[resource_get_level("vdd1_opp")].vsel <<
+ OMAP3430_INITVOLTAGE_SHIFT;
prm_write_mod_reg(vpconfig, OMAP3430_GR_MOD,
OMAP3_PRM_VP1_CONFIG_OFFSET);
@@ -277,15 +276,25 @@
/* Trigger initVDD value copy to voltage processor */
prm_set_mod_reg_bits(PRM_VP1_CONFIG_INITVDD, OMAP3430_GR_MOD,
- OMAP3_PRM_VP1_CONFIG_OFFSET);
+OMAP3_PRM_VP1_CONFIG_OFFSET);
+
/* Clear initVDD copy trigger bit */
prm_clear_mod_reg_bits(PRM_VP1_CONFIG_INITVDD, OMAP3430_GR_MOD,
- OMAP3_PRM_VP1_CONFIG_OFFSET);
+ OMAP3_PRM_VP1_CONFIG_OFFSET);
+
+ /* Force update of voltage */
+ prm_set_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD,
+OMAP3_PRM_VP1_CONFIG_OFFSET);
+ /* Clear force bit */
+ prm_clear_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP1_CONFIG_OFFSET);
} else if (srid == SR2) {
- vpconfig = PRM_VP2_CONFIG_ERROROFFSET | PRM_VP2_CONFIG_ERRORGAIN
- | PRM_VP2_CONFIG_INITVOLTAGE
- | PRM_VP2_CONFIG_TIMEOUTEN;
+ vpconfig = PRM_VP2_CONFIG_ERROROFFSET |
+ PRM_VP2_CONFIG_ERRORGAIN |
+ PRM_VP2_CONFIG_TIMEOUTEN |
+ l3_opps[resource_get_level("vdd2_opp")].vsel <<
+ OMAP3430_INITVOLTAGE_SHIFT;
prm_write_mod_reg(vpconfig, OMAP3430_GR_MOD,
OMAP3_PRM_VP2_CONFIG_OFFSET);
@@ -306,11 +315,19 @@
OMAP3_PRM_VP2_VLIMITTO_OFFSET);
/* Trigger initVDD value copy to voltage processor */
- prm_set_mod_reg_bits(PRM_VP2_CONFIG_INITVDD, OMAP3430_GR_MOD,
- OMAP3_PRM_VP2_CONFIG_OFFSET);
- /* Reset initVDD copy trigger bit */
- prm_clear_mod_reg_bits(PRM_VP2_CONFIG_INITVDD, OMAP3430_GR_MOD,
- OMAP3_PRM_VP2_CONFIG_OFFSET);
+ prm_set_mod_reg_bits(PRM_VP1_CONFIG_INITVDD, OMAP3430_GR_MOD,
+OMAP3_PRM_VP2_CONFIG_OFFSET);
+
+ /* Clear initVDD copy trigger bit */
+ prm_clear_mod_reg_bits(PRM_VP1_CONFIG_INITVDD, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP2_CONFIG_OFFSET);
+
+ /* Force update of voltage */
+ prm_set_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD,
+OMAP3_PRM_VP2_CONFIG_OFFSET);
+ /* Clear force bit */
+ prm_clear_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP2_CONFIG_OFFSET);
}
}
@@ -553,9 +570,9 @@
sr_clk_enable(sr);
if (srid == SR1)
- target_opp_no = get_opp_no(current_vdd1_opp);
+ target_opp_no = resource_get_level("vdd1_opp");
else if (srid == SR2)
- target_opp_no = get_opp_no(cu
[PATCH 01/08] OMAP3: SR: Fix init voltage on OPP change
From: Rajendra Nayak
This patch fixes a bug wherein the inital voltage was not set
correctly on a OPP change
Signed-off-by: Rajendra Nayak
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/smartreflex.c | 42 ++
1 files changed, 38 insertions(+), 4 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:25:28.133984580 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:40:25.024122683 +0530
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "prm.h"
#include "smartreflex.h"
@@ -183,7 +184,6 @@
sr->senn_mod = (omap_ctrl_readl(OMAP343X_CONTROL_FUSE_SR) &
OMAP343X_SR1_SENNENABLE_MASK) >>
OMAP343X_SR1_SENNENABLE_SHIFT;
-
sr->senp_mod = (omap_ctrl_readl(OMAP343X_CONTROL_FUSE_SR) &
OMAP343X_SR1_SENPENABLE_MASK) >>
OMAP343X_SR1_SENPENABLE_SHIFT;
@@ -364,7 +364,12 @@
static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
{
- u32 nvalue_reciprocal;
+ u32 nvalue_reciprocal, v;
+
+ if (!(mpu_opps && l3_opps)) {
+ pr_notice("VSEL values not found\n");
+ return false;
+ }
sr->req_opp_no = target_opp_no;
@@ -418,14 +423,43 @@
sr_modify_reg(sr, ERRCONFIG,
(ERRCONFIG_VPBOUNDINTEN | ERRCONFIG_VPBOUNDINTST),
(ERRCONFIG_VPBOUNDINTEN | ERRCONFIG_VPBOUNDINTST));
+
if (sr->srid == SR1) {
+ /* set/latch init voltage */
+ v = prm_read_mod_reg(OMAP3430_GR_MOD,
+OMAP3_PRM_VP1_CONFIG_OFFSET);
+ v &= ~(OMAP3430_INITVOLTAGE_MASK | OMAP3430_INITVDD);
+ v |= mpu_opps[target_opp_no].vsel <<
+ OMAP3430_INITVOLTAGE_SHIFT;
+ prm_write_mod_reg(v, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP1_CONFIG_OFFSET);
+ /* write1 to latch */
+ prm_set_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+OMAP3_PRM_VP1_CONFIG_OFFSET);
+ /* write2 clear */
+ prm_clear_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP1_CONFIG_OFFSET);
/* Enable VP1 */
prm_set_mod_reg_bits(PRM_VP1_CONFIG_VPENABLE, OMAP3430_GR_MOD,
- OMAP3_PRM_VP1_CONFIG_OFFSET);
+OMAP3_PRM_VP1_CONFIG_OFFSET);
} else if (sr->srid == SR2) {
+ /* set/latch init voltage */
+ v = prm_read_mod_reg(OMAP3430_GR_MOD,
+OMAP3_PRM_VP2_CONFIG_OFFSET);
+ v &= ~(OMAP3430_INITVOLTAGE_MASK | OMAP3430_INITVDD);
+ v |= l3_opps[target_opp_no].vsel <<
+ OMAP3430_INITVOLTAGE_SHIFT;
+ prm_write_mod_reg(v, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP2_CONFIG_OFFSET);
+ /* write1 to latch */
+ prm_set_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+OMAP3_PRM_VP2_CONFIG_OFFSET);
+ /* write2 clear */
+ prm_clear_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP2_CONFIG_OFFSET);
/* Enable VP2 */
prm_set_mod_reg_bits(PRM_VP2_CONFIG_VPENABLE, OMAP3430_GR_MOD,
- OMAP3_PRM_VP2_CONFIG_OFFSET);
+OMAP3_PRM_VP2_CONFIG_OFFSET);
}
/* SRCONFIG - enable SR */
--
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/08] OMAP3: SR: Fixes in Smartreflex driver - Resending
Hi, Resending the patches sent by Rajendra after fixing Kevin's comments and cleanup. This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. Patches apply on top of the pm-2.6.28 branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git regards, Rajendra-- -- 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/08] OMAP3: SR: Remove redundunt defines
From: Rajendra Nayak
This patch removes the local defines (PRCM_VDD1/2) in smartreflex
driver and uses the already existing global definitions (VDD1_OPP/VDD2_OPP)
from omap34xx.h file.
Signed-off-by: Rajendra Nayak
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/resource34xx.c |6 +++---
arch/arm/mach-omap2/smartreflex.c |8
arch/arm/mach-omap2/smartreflex.h |3 ---
3 files changed, 7 insertions(+), 10 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c 2009-03-24
14:25:28.045987206 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c2009-03-24
14:41:36.122985549 +0530
@@ -217,7 +217,7 @@
/* Send pre notification to CPUFreq */
cpufreq_notify_transition(&freqs_notify, CPUFREQ_PRECHANGE);
#endif
- t_opp = ID_VDD(PRCM_VDD1) |
+ t_opp = ID_VDD(VDD1_OPP) |
ID_OPP_NO(mpu_opps[target_level].opp_id);
/* For VDD1 OPP3 and above, make sure the interconnect
@@ -257,7 +257,7 @@
return 0;
l3_freq = get_freq(l3_opps + MAX_VDD2_OPP,
target_level);
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[target_level].opp_id);
if (resp->curr_level > target_level) {
/* Scale Frequency and then voltage */
@@ -278,7 +278,7 @@
if (ret) {
#ifdef CONFIG_OMAP_SMARTREFLEX
/* Setting clock failed, revert voltage */
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[resp->curr_level].
opp_id);
sr_voltagescale_vcbypass(t_opp,
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:21.798416209 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:36.123985519 +0530
@@ -677,7 +677,7 @@
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
- if (vdd == PRCM_VDD1) {
+ if (vdd == VDD1_OPP) {
sr_status = sr_stop_vddautocomap(SR1);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -686,7 +686,7 @@
OMAP3_PRM_VC_CMD_VAL_0_OFFSET);
reg_addr = R_VDD1_SR_CONTROL;
- } else if (vdd == PRCM_VDD2) {
+ } else if (vdd == VDD2_OPP) {
sr_status = sr_stop_vddautocomap(SR2);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -725,9 +725,9 @@
udelay(T2_SMPS_UPDATE_DELAY);
if (sr_status) {
- if (vdd == PRCM_VDD1)
+ if (vdd == VDD1_OPP)
sr_start_vddautocomap(SR1, target_opp_no);
- else if (vdd == PRCM_VDD2)
+ else if (vdd == VDD2_OPP)
sr_start_vddautocomap(SR2, target_opp_no);
}
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.h
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.h2009-03-24
14:25:28.046987177 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.h 2009-03-24
14:41:36.123985519 +0530
@@ -171,9 +171,6 @@
/* R_DCDC_GLOBAL_CFG register, SMARTREFLEX_ENABLE values */
#define DCDC_GLOBAL_CFG_ENABLE_SRFLX 0x08
-/* VDDs*/
-#define PRCM_VDD1 1
-#define PRCM_VDD2 2
#define PRCM_MAX_SYSC_REGS 30
/*
--
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: McBSP: Fix legacy interrupts to clear their status
From: Eero Nurkkala
If XSYNCERR or RSYNCERR interrupts are enabled, they are never
cleared causing the IRQ handler to be continuously called.
This patch clears the IRQs in question in the event they are
enabled and taken.
Signed-off-by: Eero Nurkkala
---
arch/arm/plat-omap/mcbsp.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e2e8b76..6a10f65 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -91,11 +91,20 @@ static void omap_mcbsp_dump_reg(u8 id)
static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_tx = dev_id;
+ u16 irqst_spcr2;
- dev_dbg(mcbsp_tx->dev, "TX IRQ callback : 0x%x\n",
- OMAP_MCBSP_READ(mcbsp_tx->io_base, SPCR2));
+ irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx->io_base, SPCR2);
+ dev_dbg(mcbsp_tx->dev, "TX IRQ callback : 0x%x\n", irqst_spcr2);
- complete(&mcbsp_tx->tx_irq_completion);
+ if (irqst_spcr2 & XSYNC_ERR) {
+ dev_err(mcbsp_tx->dev, "TX Frame Sync Error! : 0x%x\n",
+ irqst_spcr2);
+ /* Writing zero to XSYNC_ERR clears the IRQ */
+ OMAP_MCBSP_WRITE(mcbsp_tx->io_base, SPCR2,
+ irqst_spcr2 & ~(XSYNC_ERR));
+ } else {
+ complete(&mcbsp_tx->tx_irq_completion);
+ }
return IRQ_HANDLED;
}
@@ -103,11 +112,20 @@ static irqreturn_t omap_mcbsp_tx_irq_handler(int irq,
void *dev_id)
static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_rx = dev_id;
+ u16 irqst_spcr1;
- dev_dbg(mcbsp_rx->dev, "RX IRQ callback : 0x%x\n",
- OMAP_MCBSP_READ(mcbsp_rx->io_base, SPCR2));
+ irqst_spcr1 = OMAP_MCBSP_READ(mcbsp_rx->io_base, SPCR1);
+ dev_dbg(mcbsp_rx->dev, "RX IRQ callback : 0x%x\n", irqst_spcr1);
- complete(&mcbsp_rx->rx_irq_completion);
+ if (irqst_spcr1 & RSYNC_ERR) {
+ dev_err(mcbsp_rx->dev, "RX Frame Sync Error! : 0x%x\n",
+ irqst_spcr1);
+ /* Writing zero to RSYNC_ERR clears the IRQ */
+ OMAP_MCBSP_WRITE(mcbsp_rx->io_base, SPCR1,
+ irqst_spcr1 & ~(RSYNC_ERR));
+ } else {
+ complete(&mcbsp_rx->tx_irq_completion);
+ }
return IRQ_HANDLED;
}
--
1.5.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] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Hi Hari, On Mon, Mar 23, 2009 at 8:49 PM, Kanigeri, Hari wrote: > DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject, > pCtxtclosed, (void *)pCtxtclosed->pid); I am trying to understand this patch. I see that pCtxtclosed is passed to DRV_RemoveProcContext() function but it is not used anywhere inside it. I was expecting to see a statement there which should free its memory. Any pointers? 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 1/1] Export notifier register functions for kernel module building
On Tue, 24 Mar 2009, Gupta, Ramesh wrote:
> > -Original Message-
> > From: Paul Walmsley [mailto:p...@pwsan.com]
> >
> > DSPBridge and
> > other drivers needing clock notifiers should pass function pointers to
> > clk_notifier_{register,unregister}() in their struct
> > platform_data, rather than exporting those symbols. This
> > will keep the drivers platform-agnostic, since system-wide
> > clock notifiers are not yet upstream.
>
> I agree on this, I think the latest patch set from Rajendra Naik([1])
> removes the EXPORT_SYMBOL for the clk notifier functions.
>
> We will send a patch to dspbridge sources to adopt these changes.
>
> Please let me know your comments.
Sounds good to me.
regards,
- 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 1/1] Export notifier register functions for kernel module building
Paul,
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Tuesday, March 24, 2009 2:58 PM
> To: Kevin Hilman
> Cc: Gupta, Ramesh; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 1/1] Export notifier register functions
> for kernel module building
>
> Hello Kevin, Ramesh,
>
> On Thu, 12 Feb 2009, Kevin Hilman wrote:
>
> > "Gupta, Ramesh" writes:
> >
> > > This Patch exports symbols
> clk_notifier_register/unregister function
> > > for other kernel modules usage.
> > >
> > > Signed-off-by: Ramesh Gupta G
> >
> > Thanks, pushed to PM branch.
>
> As an aside, this patch should be reverted. DSPBridge and
> other drivers needing clock notifiers should pass function pointers to
> clk_notifier_{register,unregister}() in their struct
> platform_data, rather than exporting those symbols. This
> will keep the drivers platform-agnostic, since system-wide
> clock notifiers are not yet upstream.
I agree on this, I think the latest patch set from Rajendra Naik([1]) removes
the EXPORT_SYMBOL for the clk notifier functions.
Ref[1]: http://marc.info/?l=linux-omap&m=123755561914202&w=2
Ref[2]: http://marc.info/?l=linux-omap&m=123755561914205&w=2
We will send a patch to dspbridge sources to adopt these changes.
Please let me know your comments.
Thanks
Ramesh Gupta G--
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/1] Export notifier register functions for kernel module building
Hello Kevin, Ramesh,
On Thu, 12 Feb 2009, Kevin Hilman wrote:
> "Gupta, Ramesh" writes:
>
> > This Patch exports symbols clk_notifier_register/unregister
> > function for other kernel modules usage.
> >
> > Signed-off-by: Ramesh Gupta G
>
> Thanks, pushed to PM branch.
As an aside, this patch should be reverted. DSPBridge and other drivers
needing clock notifiers should pass function pointers to
clk_notifier_{register,unregister}() in their struct platform_data, rather
than exporting those symbols. This will keep the drivers
platform-agnostic, since system-wide clock notifiers are not yet upstream.
regards,
- Paul
> > ---
> > arch/arm/plat-omap/clock.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> > index e0940a1..c8d9e96 100644
> > --- a/arch/arm/plat-omap/clock.c
> > +++ b/arch/arm/plat-omap/clock.c
> > @@ -680,6 +680,7 @@ int clk_notifier_register(struct clk *clk, struct
> > notifier_block *nb)
> >
> > return r;
> > }
> > +EXPORT_SYMBOL(clk_notifier_register);
> >
> > /**
> > * clk_notifier_unregister - remove a clock change notifier
> > @@ -735,6 +736,7 @@ int clk_notifier_unregister(struct clk *clk, struct
> > notifier_block *nb)
> >
> > return r;
> > }
> > +EXPORT_SYMBOL(clk_notifier_unregister);
> >
> >
> >
> > --
> > 1.5.3.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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/09] OMAP3 clock: Clock rate change notifiers
On Mon, 23 Mar 2009, Paul Walmsley wrote: > On Fri, 20 Mar 2009, Nayak, Rajendra wrote: > > > This patch set reverts some patches from Paul Walmsley to add the clock > > notification infrastucture for OMAP3, and adds new patches from him on top, > > which > > have only been circulating internally. > > These patches are posted as they are needed for the patch set to remove > > virtual > > clock nodes that will follow. > > > > These patches are based on the pm-2.6.28 branch from Kevin's pm tree. > > Thanks for posting these. These aren't ready for merging yet since > they don't contain some of the fixes discussed over the past few weeks. > I'll repost an updated version of these later today. Will take another shot at this later today; I'd like to do some more testing on the parent change case before I post these. - 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
