Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Kindly let me know if you can merge these patches for .38 linaro kernel.
Regards Vishwa
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Kindly let me know if you can merge these patches for .38 linaro kernel.
Merged.
BTW, I don't have an intimate knowledge about the things those patches touch. So in the future that would be helpful if you can gather some review acknowledgements in the form of Acked-by or Reviewed-by tags from some other people. Thanks.
Nicolas
On Mon, 28 Feb 2011, Nicolas Pitre wrote:
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Kindly let me know if you can merge these patches for .38 linaro kernel.
Merged.
BTW, I don't have an intimate knowledge about the things those patches touch. So in the future that would be helpful if you can gather some review acknowledgements in the form of Acked-by or Reviewed-by tags from some other people. Thanks.
Also, I got the following build breakage report:
LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap_target': /opt/git/ubuntu/roc/natty/arch/arm/mach-omap2/omap2plus-cpufreq.c:118: undefined reference to `omap_device_scale' arch/arm/plat-omap/built-in.o: In function `omap_device_build_ss': /opt/git/ubuntu/roc/natty/arch/arm/plat-omap/omap_device.c:490: undefined reference to `omap_dvfs_register_device' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/opt/git/ubuntu/roc/natty' make: *** [/opt/git/ubuntu/roc/natty/debian/stamps/stamp-build-omap4] Error 2
I fixed it like this:
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 86a54ca..898fffe 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -65,7 +65,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o voltage.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \ cpuidle34xx.o pm_bus.o dvfs.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o dvfs.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o Please confirm this is OK, or provide an additional patch.
Nicolas
On Wed, Mar 2, 2011 at 4:35 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 28 Feb 2011, Nicolas Pitre wrote:
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Kindly let me know if you can merge these patches for .38 linaro kernel.
Merged.
BTW, I don't have an intimate knowledge about the things those patches touch. So in the future that would be helpful if you can gather some review acknowledgements in the form of Acked-by or Reviewed-by tags from some other people. Thanks.
Also, I got the following build breakage report:
LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap_target': /opt/git/ubuntu/roc/natty/arch/arm/mach-omap2/omap2plus-cpufreq.c:118: undefined reference to `omap_device_scale' arch/arm/plat-omap/built-in.o: In function `omap_device_build_ss': /opt/git/ubuntu/roc/natty/arch/arm/plat-omap/omap_device.c:490: undefined reference to `omap_dvfs_register_device' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/opt/git/ubuntu/roc/natty' make: *** [/opt/git/ubuntu/roc/natty/debian/stamps/stamp-build-omap4] Error 2
I fixed it like this:
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 86a54ca..898fffe 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -65,7 +65,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o voltage.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \ cpuidle34xx.o pm_bus.o dvfs.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o dvfs.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o Please confirm this is OK, or provide an additional patch.
This looks fine to me. Thanks for the fix. btw which defconfig threw up this error? I had built omap2plus_defconfig and it went all fine.
Vishwa
Nicolas
On Thu, Mar 3, 2011 at 8:03 AM, Vishwanath Sripathy vishwanath.sripathy@linaro.org wrote:
On Wed, Mar 2, 2011 at 4:35 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 28 Feb 2011, Nicolas Pitre wrote:
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Kindly let me know if you can merge these patches for .38 linaro kernel.
Merged.
BTW, I don't have an intimate knowledge about the things those patches touch. So in the future that would be helpful if you can gather some review acknowledgements in the form of Acked-by or Reviewed-by tags from some other people. Thanks.
Also, I got the following build breakage report:
LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap_target': /opt/git/ubuntu/roc/natty/arch/arm/mach-omap2/omap2plus-cpufreq.c:118: undefined reference to `omap_device_scale' arch/arm/plat-omap/built-in.o: In function `omap_device_build_ss': /opt/git/ubuntu/roc/natty/arch/arm/plat-omap/omap_device.c:490: undefined reference to `omap_dvfs_register_device' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/opt/git/ubuntu/roc/natty' make: *** [/opt/git/ubuntu/roc/natty/debian/stamps/stamp-build-omap4] Error 2
I fixed it like this:
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 86a54ca..898fffe 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -65,7 +65,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o voltage.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \ cpuidle34xx.o pm_bus.o dvfs.o -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o dvfs.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o Please confirm this is OK, or provide an additional patch.
This looks fine to me. Thanks for the fix. btw which defconfig threw up this error? I had built omap2plus_defconfig and it went all fine.
Vishwa
Vishwa,
Linaro uses its own (rather heavy-weight) configuration that includes almost everything in as modules so that a variety of USB devices, protocols and other features work.
/Amit
On Thu, 3 Mar 2011, Vishwanath Sripathy wrote:
On Wed, Mar 2, 2011 at 4:35 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap_target': /opt/git/ubuntu/roc/natty/arch/arm/mach-omap2/omap2plus-cpufreq.c:118: undefined reference to `omap_device_scale' arch/arm/plat-omap/built-in.o: In function `omap_device_build_ss': /opt/git/ubuntu/roc/natty/arch/arm/plat-omap/omap_device.c:490: undefined reference to `omap_dvfs_register_device' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/opt/git/ubuntu/roc/natty' make: *** [/opt/git/ubuntu/roc/natty/debian/stamps/stamp-build-omap4] Error 2
btw which defconfig threw up this error? I had built omap2plus_defconfig and it went all fine.
This was presumably with the Ubuntu kernel config from this tree:
http://kernel.ubuntu.com/git?p=roc/ubuntu-natty.git%3Ba=shortlog%3Bh=refs/he...
Adding Bryan in CC in case he has more info.
Nicolas
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Hello Vishwanath,
Given that I performed some drastic changes in the linaro-2.6.38 kernel tree lately [1] I had to drop your DVFS patches in order to bring the OMAP support up to date without conflicts.
Is it possible for you to rebase your patches again on top of the current linaro-2.6.38 tree, or if those patches are available in some upstream branch then point me to it?
[1] http://lists.linaro.org/pipermail/linaro-kernel/2011-March/000138.html
Nicolas
On Tue, Mar 29, 2011 at 3:43 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Hello Vishwanath,
Given that I performed some drastic changes in the linaro-2.6.38 kernel tree lately [1] I had to drop your DVFS patches in order to bring the OMAP support up to date without conflicts.
Is it possible for you to rebase your patches again on top of the current linaro-2.6.38 tree, or if those patches are available in some upstream branch then point me to it?
Nicolas,
DVFS is not yet upstreamed. I will rebase DVFS patches against latest Linaro kernel and provide you the rebased patches by tomorrow. Is that fine with you?
Regards Vishwa
[1] http://lists.linaro.org/pipermail/linaro-kernel/2011-March/000138.html
Nicolas
On Tue, 29 Mar 2011, Vishwanath Sripathy wrote:
On Tue, Mar 29, 2011 at 3:43 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Hello Vishwanath,
Given that I performed some drastic changes in the linaro-2.6.38 kernel tree lately [1] I had to drop your DVFS patches in order to bring the OMAP support up to date without conflicts.
Is it possible for you to rebase your patches again on top of the current linaro-2.6.38 tree, or if those patches are available in some upstream branch then point me to it?
Nicolas,
DVFS is not yet upstreamed. I will rebase DVFS patches against latest Linaro kernel and provide you the rebased patches by tomorrow. Is that fine with you?
Yes, thanks.
Nicolas
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
Regards Vishwa
On Tue, Mar 29, 2011 at 10:45 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 29 Mar 2011, Vishwanath Sripathy wrote:
On Tue, Mar 29, 2011 at 3:43 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and these are rebased against latest .38 linaro kernel. omap cpufreq driver changes are already posted to lo (https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer changes will be upstreamed once Basic DVFS framework is accepted.
Hello Vishwanath,
Given that I performed some drastic changes in the linaro-2.6.38 kernel tree lately [1] I had to drop your DVFS patches in order to bring the OMAP support up to date without conflicts.
Is it possible for you to rebase your patches again on top of the current linaro-2.6.38 tree, or if those patches are available in some upstream branch then point me to it?
Nicolas,
DVFS is not yet upstreamed. I will rebase DVFS patches against latest Linaro kernel and provide you the rebased patches by tomorrow. Is that fine with you?
Yes, thanks.
Nicolas
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
/Amit
Yes, Following options have to be enabled in the defconfig to enable cpufreq.
CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y
Vishwa
On Mon, Apr 4, 2011 at 1:52 PM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
/Amit
On Tue, Apr 5, 2011 at 12:26 AM, Vishwanath Sripathy vishwanath.sripathy@linaro.org wrote:
Yes, Following options have to be enabled in the defconfig to enable cpufreq.
CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_CLASS3=y
Done
Vishwa
On Mon, Apr 4, 2011 at 1:52 PM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
/Amit
Amit Kucheria amit.kucheria@linaro.org writes:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
Just for the record...
Not that it makes a difference for current Linaro releases, but this DVFS series has been rejected and will not be going upstream. A replacement implementation is underway.
Kevin
On Wed, 6 Apr 2011, Kevin Hilman wrote:
Amit Kucheria amit.kucheria@linaro.org writes:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
Just for the record...
Not that it makes a difference for current Linaro releases, but this DVFS series has been rejected and will not be going upstream. A replacement implementation is underway.
OK... If the replacement is still work in progress, I don't think we may count on it for this cycle. What I care most about is the difference in user space visible interfaces if any. What can you tell me on that point?
Nicolas
Nicolas Pitre nicolas.pitre@linaro.org writes:
On Wed, 6 Apr 2011, Kevin Hilman wrote:
Amit Kucheria amit.kucheria@linaro.org writes:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
Just for the record...
Not that it makes a difference for current Linaro releases, but this DVFS series has been rejected and will not be going upstream. A replacement implementation is underway.
OK... If the replacement is still work in progress, I don't think we may count on it for this cycle. What I care most about is the difference in user space visible interfaces if any. What can you tell me on that point?
No differences to userspace interface, since CPUfreq is still the userspace (and kernel) interface to DVFS.
Kevin
On Wed, Apr 6, 2011 at 10:33 PM, Kevin Hilman khilman@ti.com wrote:
Nicolas Pitre nicolas.pitre@linaro.org writes:
On Wed, 6 Apr 2011, Kevin Hilman wrote:
Amit Kucheria amit.kucheria@linaro.org writes:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
Just for the record...
Not that it makes a difference for current Linaro releases, but this DVFS series has been rejected and will not be going upstream. A replacement implementation is underway.
OK... If the replacement is still work in progress, I don't think we may count on it for this cycle. What I care most about is the difference in user space visible interfaces if any. What can you tell me on that point?
No differences to userspace interface, since CPUfreq is still the userspace (and kernel) interface to DVFS.
Kevin
Kevin,
Yes we're aware that the patches aren't in mainline yet. We'll update to the next version of the patchset when available.
While not trying to speak for Nico, in the Linaro kernel we're trying to increase testing of under-development features (e.g. device tree, DVFS, etc.) after they've had a few review rounds upstream. Since Nico recreates his tree every once in a while, old versions of patchsets get dropped and newer ones are applied.
Regards, Amit
Amit Kucheria amit.kucheria@linaro.org writes:
On Wed, Apr 6, 2011 at 10:33 PM, Kevin Hilman khilman@ti.com wrote:
Nicolas Pitre nicolas.pitre@linaro.org writes:
On Wed, 6 Apr 2011, Kevin Hilman wrote:
Amit Kucheria amit.kucheria@linaro.org writes:
On Sat, Apr 2, 2011 at 6:21 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
> Hi Nicolas, > > Pls find rebased OMAP DVFS patches attached. Apologies for the delay > as I had to rework some of the patches because of kernel migration.
No problem.
Merged, thanks.
Vishwa,
Could you also make sure that that DVFS config options are enabled in the Linaro configs? If you could state the config options, John (cc'ed) could help you with enabling them. Linaro does not use the omap2plug_defconfig
Just for the record...
Not that it makes a difference for current Linaro releases, but this DVFS series has been rejected and will not be going upstream. A replacement implementation is underway.
OK... If the replacement is still work in progress, I don't think we may count on it for this cycle. What I care most about is the difference in user space visible interfaces if any. What can you tell me on that point?
No differences to userspace interface, since CPUfreq is still the userspace (and kernel) interface to DVFS.
Kevin
Kevin,
Yes we're aware that the patches aren't in mainline yet. We'll update to the next version of the patchset when available.
Sure, I understand.
It was just a heads up becasue in this case, it's not only an updated version of the feature, it's a throw away and rewrite.
While not trying to speak for Nico, in the Linaro kernel we're trying to increase testing of under-development features (e.g. device tree, DVFS, etc.) after they've had a few review rounds upstream. Since Nico recreates his tree every once in a while, old versions of patchsets get dropped and newer ones are applied.
Understood.
Again, I just wanted the Linaro kernel maintainers to know that a this implementation of DVFS will not be getting anywhere near upstream. Whether you choose to include it into your tree is entirely up to you.
Kevin
On Fri, 2011-04-01 at 21:03 +0530, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
I think something in the DVFS patch set broke usb on Pandaboard.
Building 7c4bc9c2662c6d9840afed0e29eb01314af9bb78 I'm seeing a hang at boot: [ 3.810821] oprofile: using timer interrupt. [ 3.815612] TCP cubic registered [ 3.819030] Initializing XFRM netlink socket [ 3.823577] NET: Registered protocol family 17 [ 3.828369] NET: Registered protocol family 15 [ 3.833038] lib80211: common routines for IEEE802.11 drivers [ 3.839050] VFP support v0.3: implementor 41 architecture 3 part 30 variant 1 [ 3.847564] Registering SWP/SWPB emulation handler [ 3.858673] omap2_set_init_voltage: Invalid parameters! [ 3.864196] omap2_set_init_voltage: Unable to put vdd_iva to its init voltage [ 3.864196] [ 3.873291] Power Management for TI OMAP4. [ 3.894714] clock: disabling unused clocks to save power [ 3.908966] mmc0: host does not support reading read-only switch. assuming w. [ 3.935028] mmc0: new high speed SDHC card at address 0007 [ 3.942138] mmcblk0: mmc0:0007 SD4GB 3.68 GiB [ 3.950225] mmcblk0: p1 p2 [ 4.020874] usb 1-1: new high speed USB device number 2 using ehci-omap
<and nothing ever happens from there>
Backing up to f90b5bc964fb1965a75ba3b8a70a5418b4d58059 seems to resolve the issue
Any clues on what went wrong?
thanks -john
On Mon, 2011-04-04 at 17:49 -0700, john stultz wrote:
On Fri, 2011-04-01 at 21:03 +0530, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
I think something in the DVFS patch set broke usb on Pandaboard.
Bah. Maybe not. Trying to reproduce it doesn't seem to work. Might be some sort of transient .config settings issue, but I didn't save off the problematic .config. So I'll try to reproduce this some tomorrow, but until then I'd not worry about it.
thanks -john
I have the same problem. If I turn off the display then the board boots.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/752900
Thanks to John Stultz for making the connection that the hang was just as the display gets set up on a successful boot.
Kernel config and boot logs are attached to the bug.
On Tue, Apr 5, 2011 at 12:12 AM, john stultz johnstul@us.ibm.com wrote:
On Mon, 2011-04-04 at 17:49 -0700, john stultz wrote:
On Fri, 2011-04-01 at 21:03 +0530, Vishwanath Sripathy wrote:
Hi Nicolas,
Pls find rebased OMAP DVFS patches attached. Apologies for the delay as I had to rework some of the patches because of kernel migration.
I think something in the DVFS patch set broke usb on Pandaboard.
Bah. Maybe not. Trying to reproduce it doesn't seem to work. Might be some sort of transient .config settings issue, but I didn't save off the problematic .config. So I'll try to reproduce this some tomorrow, but until then I'd not worry about it.
thanks -john
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 04/06/2011 09:24 PM, Somebody in the thread at some point said:
I have the same problem. If I turn off the display then the board boots.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/752900
Thanks to John Stultz for making the connection that the hang was just as the display gets set up on a successful boot.
Kernel config and boot logs are attached to the bug.
There are a couple of config options at least that deceptively offer things which only break boot.
Since there's no relationship between configs people are using and the one Panda stuff is getting heavily tested on (arch/arm/configs/omap4_defconfig on Seb's and my tree), I am thinking we should maybe take an assertive approach about it -->
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B... http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B...
-Andy
Andy Green andy@warmcat.com writes:
On 04/06/2011 09:24 PM, Somebody in the thread at some point said:
I have the same problem. If I turn off the display then the board boots.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/752900
Thanks to John Stultz for making the connection that the hang was just as the display gets set up on a successful boot.
Kernel config and boot logs are attached to the bug.
There are a couple of config options at least that deceptively offer things which only break boot.
Since there's no relationship between configs people are using and the one Panda stuff is getting heavily tested on (arch/arm/configs/omap4_defconfig on Seb's and my tree), I am thinking we should maybe take an assertive approach about it -->
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B...
If CONFIG_OMAP_RESET_CLOCKS=y is breaking boot, it's because there is a broken driver someplace that is not requesting its clock(s). That driver should be found and fixed.
Disabling this option is only hiding a broken driver, and as an additional side effect, will almost surely prevent the device from hitting low power states in idle and suspend.
Kevin
On Thu, Apr 7, 2011 at 12:59 AM, Andy Green andy@warmcat.com wrote:
On 04/06/2011 09:24 PM, Somebody in the thread at some point said:
I have the same problem. If I turn off the display then the board boots.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/752900
Thanks to John Stultz for making the connection that the hang was just as the display gets set up on a successful boot.
Kernel config and boot logs are attached to the bug.
There are a couple of config options at least that deceptively offer things which only break boot.
Since there's no relationship between configs people are using and the one Panda stuff is getting heavily tested on (arch/arm/configs/omap4_defconfig on Seb's and my tree), I am thinking we should maybe take an assertive approach about it -->
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B... http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B...
Thanks Andy. This fixes the problem. These will be in the next packaged kernel. I added these two links to the bug as well.
On Thu, 2011-04-07 at 07:59 +0100, Andy Green wrote:
On 04/06/2011 09:24 PM, Somebody in the thread at some point said:
I have the same problem. If I turn off the display then the board boots.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/752900
Thanks to John Stultz for making the connection that the hang was just as the display gets set up on a successful boot.
Kernel config and boot logs are attached to the bug.
There are a couple of config options at least that deceptively offer things which only break boot.
Since there's no relationship between configs people are using and the one Panda stuff is getting heavily tested on (arch/arm/configs/omap4_defconfig on Seb's and my tree), I am thinking we should maybe take an assertive approach about it -->
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B... http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B...
I think that would be a good idea, although "depends on BROKEN" might be less aggressive.
thanks -john
On Thu, 7 Apr 2011, john stultz wrote:
On Thu, 2011-04-07 at 07:59 +0100, Andy Green wrote:
On 04/06/2011 09:24 PM, Somebody in the thread at some point said:
I have the same problem. If I turn off the display then the board boots.
https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/752900
Thanks to John Stultz for making the connection that the hang was just as the display gets set up on a successful boot.
Kernel config and boot logs are attached to the bug.
There are a couple of config options at least that deceptively offer things which only break boot.
Since there's no relationship between configs people are using and the one Panda stuff is getting heavily tested on (arch/arm/configs/omap4_defconfig on Seb's and my tree), I am thinking we should maybe take an assertive approach about it -->
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B... http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B...
I think that would be a good idea, although "depends on BROKEN" might be less aggressive.
Indeed.
Nicolas
On 04/07/2011 06:21 PM, Somebody in the thread at some point said:
Hi -
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B... http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=patch%3B...
I think that would be a good idea, although "depends on BROKEN" might be less aggressive.
You're right; I didn't realize CONFIG_BROKEN was actually codified for this. Grepping the kernel there are many things that 'depend' on it.
I changed my tree to use CONFIG_BROKEN for these two and the end result is the same. If I spot any more config options that are guaranteed kills I will treat them likewise.
-Andy
-
Amit Kucheria -
Andy Green -
John Rigby -
john stultz -
Kevin Hilman -
Nicolas Pitre -
Vishwanath Sripathy