On Wednesday 19 August 2009 14:39:40 Dominik Brodowski wrote: > Dave, > > On Tue, Aug 18, 2009 at 04:08:11PM -0400, Dave Jones wrote: > > I recently had a hard disk crash we took with it most of my mail > > from the last few weeks. If there's anything you sent me that > > isn't merged in the next branch of cpufreq.git, please resend it, > > as I've probably lost it. > > ouch -- hope there wasn't more damage to your data. Besides the patch I > re-sent a few seconds ago, the patch > > [CPUFREQ] Cleanup governor struct, remove userspace specific set_speed functions > > needs to be reverted, for it re-introduces the deadlock which was fixed by > commit 9e76988e9390a4ff4d171f690586d0c58186b47e (Eliminate cpufreq_userspace > scaling_setspeed deadlock). Yep. > > Also, I'm not that sure that the three most recent patches by Thomas > (one-governor-per-system) are ready to go. Thomas? commit 15fe1c0411f557a90d8e2eafe6889170a932c699 (cpufreq-next) [CPUFREQ] Only allow machine wide governor switching should not go anywhere upstream yet (maybe for linux-next, but not into an official release. Better revert this one if this causes trouble). The global sysfs dirs for ondemand/conservative governors should be fine: [CPUFREQ] ondemand - Use global sysfs dir for tuning settings [CPUFREQ] Introduce global, not per core: /sys/devices/system/cpu/cpufreq I also sent the needed changes for conservative governor: [PATCH 1/3] CPUFREQ: Use global sysfs cpufreq structure for conservative governor tunings I can resend it. Also I wonder why: commit 5141022ced0ae12f2c8828785c92d29909d7bd17 [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site) .. Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx> .. was pushed? I thought with Venki's mutex changes calling .governor(CPUFREQ_GOV_STOP) could be called with rwsem held and it was considered to be much cleaner. Hmm, there are so much mails floating around, it's hard to extract the right info related to this. I also think this change will causes real trouble. I could verify that commit above modifies cpufreq core in a way that .governor(START) could be called twice without .governor(STOP) being called in between on the same cpu -> bad. I experienced that with creating scaling_set_speed in userspace .governor(START) path and I got "already exists" messages rather quickly (Reverting it fixed that). Not sure what consequences it would have when set_speed is created in cpufreq.c again, but if possible this one should also get reverted. Thomas > > Best, > Dominik > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
