"Rafael J. Wysocki" <rjw@xxxxxxx> writes: > On Friday, July 15, 2011, MyungJoo Ham wrote: >> For a usage example, please look at >> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/devfreq >> >> In the above git tree, DVFS (dynamic voltage and frequency scaling) mechanism >> is applied to the memory bus of Exynos4210 for Exynos4210-NURI boards. >> In the example, the LPDDR2 DRAM frequency changes between 133, 266, and 400MHz >> and other related clocks simply follow the determined DDR RAM clock. >> >> The DEVFREQ driver for Exynos4210 memory bus is at >> /arch/arm/mach-exynos4/devfreq_bus.c in the git tree. >> >> MyungJoo Ham (3): >> PM: Introduce DEVFREQ: generic DVFS framework with device-specific >> OPPs >> PM / DEVFREQ: add example governors >> PM / DEVFREQ: add sysfs interface (including user tickling) > > OK, I'm going to take the patches for 3.2. Sorry for being late to the discussion, but personally I don't think this should be merged for v3.2. First, I think the governor part of this series is basically fine, and can see some cases where it would be useful, but as Mike has pointed out, there is still a majority of devices for which a governor like this would be overkill. My main problem is with the QoS aspects. There is significant overlap between this approach and the per-device PM QoS approach currently being proposed by Jean Pihet, and I think any sort of per-device DVFS should be built on top of a more generic per-device QoS layer (such as Jean's.) This series currently provides a *very* basic QoS mechanism (e.g. fixed duration frequency constraint) in the form of "tickle", which BTW I seem to having a hard time understanding (more on that below...) More importantly though, this series also introduces a sysfs layer for doing its QoS-like stuff, so adding this and then adding a more generic per-device QoS is asking for confusion about how userspace is to do QoS. And adding a sysfs interface may be turn out to be difficult to remove. Basically, without a more general constraints mechanism in place, I don't see how this can be generally useful since there are too many assumptions made with the current "tickle" approach, and as Mike has pointed out, it cannot cleanly handle cases where there might be multiple DVFS-related constraints on a given device. OK, back to "tickle"... I haven't yet fully understood how that interface is intended to be used, or who the potential users might be and it is not documented in the code or changelog. I also didn't see any users of that API (except the sysfs code.) IIUC, tickle is just basically a way to set a frequency constraint on a device for a fixed duration. However, if tickle has been requested, any OPP change will also force a change to the highest performance OPP temporarily before changing to the target OPP. Maybe I'm not understanding the usage of it fully, but that seems like hard-coding policy into the framework that might not be appropriate. For example, what if there are other devices with constraints such that they cannot currently scale frequency/voltage? Mabye MyungJoo can explain in more detail the usecases for tickle? Thanks, Kevin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
