On Fri, Jul 29, 2011 at 2:10 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Friday, July 29, 2011, Turquette, Mike wrote: >> On Thu, Jul 28, 2011 at 3:10 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: >> > 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. >> >> Have any other platforms signed up to use this mechanism to manage >> their peripheral DVFS? > > Not that I know of, but one initial user is sufficient for me. > So if you have anything _against_ the patches, please speak up. I do have some concerns. Let me start by saying that I'm defining a "governor" as some active piece of executing code, probably a looping workqueue that inspects activity/idleness of a device and then makes a determination regarding clock frequency. devfreq seems to be good framework for creating DVFS governors. However I think that most scalable devices on an SoC do *not* need a governor, and many scalable devices won't have performance counters or any other way to implement such introspection. Some examples include a MMC controller, which might change its clock rate depending on the class of card that the user has inserted. Or even a "smartish" device like a GPU lacking performance counters; it's driver will ramp up frequency when there is work to be done and kick off a timeout. If no new work comes in before the timeout then the driver will drop the frequency. A governor is not required in these cases (as they are event driven) and devfreq is quite heavyweight for such applications. What is needed is a QoS-style software layer that allows throughput requests to be made from an initiator device towards a target device. This layer should aggregate requests since many initator devices may make requests to the same target device. This layer I'm describing, which does not exist today, should be where the actual DVFS transition takes place. That could take the form of a clk_set_rate call in the clock framework (as described by Colin in V1 of this series), or some other not-yet-realized dvfs_set_opp ,or something like Jean Pihet's per-device PM QoS patches or whatever. For the purposes of this email I don't really care which framework implements the QoS request aggregation. The point of describing this non-existant API is that devfreq should really be just another input into it. A governor that can measure bus saturation is really cool, but it may not yield optimal results compared to several drivers which make QoS-style requests and insure that performance is guaranteed for their particular needs during their transactions. The good news is that we don't have to choose between performance counter introspection and software QoS requests: both the driver requests and the governor should all feed as inputs into the QoS-style DVFS mechanism. Taking that logic to its inevitable conclusion, tickle doesn't belong inside the governor at all. If some device X wants to ramp up the frequency of device Y, it should just make a QoS-style throughput request towards device Y, possibly with a timeout (keeping the original idea of tickle intact). This is entirely a separate idea from a governor's introspective workqueue loop. For userspace, a sysfs entry for tickle would also not feed into the governor, but some dummy struct device *user would probably be the initiator device and it would simply call the QoS-style throughput API. In summary my objections to this series are: 1) devfreq should not be the *final* software layer to invoke a DVFS transition as it has not taken all constraints into account. 2) a devfreq governor represents just one constraint out of many to be considered for any given scalable device. My objection to these patches getting merged is that I think they are a bit ahead of their time. We need to know what the real DVFS API looks like underneath devfreq first, since devfreq should really be built on top of it. Regards, Mike > Thanks, > Rafael > _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
