On Wed, Aug 3, 2011 at 12:03 AM, MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> wrote: > On Wed, Aug 3, 2011 at 7:02 AM, Kevin Hilman <khilman@xxxxxx> wrote: >> "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.) > > Then, what about adding a governor? Besides, DEVFREQ is designed to No one is saying that you can't have a governor to control DVFS transitions for your device. The point is that the governor should make a call to the per-device PM QoS DVFS API in it's ->target() function. The fundamental difference is this: you want devfreq to be the final place where DVFS transitions actually occur (meaning clocks and voltage rails get scaled). Kevin and I are both arguing for devfreq to be policy built on top of a dedicated DVFS API for managing those transitions. (Kevin, let me know if I'm putting words in your mouth) > allow each device to create its own governors. The governors in the > devfreq.c are meant to be used commonly by "many" devices. > > For PM QoS, we may have several approaches: > 1. Adding a governor aware of PM QoS taking PM QoS parameters. > 2. Modifying OPP to be aware of PM QoS so that only OPPs meeting the > requirement are enabled if the PM QoS requirement specifies frequency > or voltage conditions explicitly. > 3. Modifying DEVFREQ to be aware of PM QoS and let DEVFREQ ignore > frequencies that do not satisfy the PM QoS requirement. As in approach > 2, the requirement also needs to be explicit about frequency / voltage > conditions or we need to interpret devfreq_dev_status result in terms > of PM QoS. > >> >> 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? > > Tickle is not for QoS between devices. It is for faster reaction to > (human) user inputs at DVFS side where waiting for DVFS's reaction > takes too much time and reducing polling interval costs too much. In > fact, this tickling method was quite effective with CPUFREQ's ondemand > governor (not upstreamed). We may tune DVFS constants to let it react > faster with lower threshold; however, this results in higher power > consumption with small load. Do you think that your "tickle" method would go upstream for CPUfreq? devfreq is analogous to CPUfreq is almost every way, so if that solution would not be accepted for CPUfreq, then it should not be accepted for devfreq either. > Here goes more detailed description about the issue intended to be > tackled by tickling, the response time of GUI. With DVFS (CPUFREQ), we > have been suffering from slower user response time (e.g., dragging > touch screen of mobile devices at "application drawer" or "web > browsers"). Let's assume a system with a CPU that runs at the range of > 100MHz ~ 2GHz and a GUI that requires at least1.5GHz for smooth > transitions. If we are going to use 60Hz based display and 20ms > CPUFREQ polling interval, a sudden user input requires 30ms of delay > in average to get CPU to work at high speed, which loses 2 frames > (often, it takes more time/frames for CPUFREQ to react; I don't know > why). If a user repeatedly drags and stops the touch screen, such > delay and lost frames become very noticeable and the screen follows > user's finger retarded. With CPUFREQ-ondemand, tickling has been made > such test to have almost same result with that of "performance" > governor. This can be achieved entirely with a DVFS framework that devices can use to scale the CPU's frequency. It requires no changes to CPUfreq core or to the ondemand governor. The CPUfreq driver makes a call to the DVFS scaling API in it's ->target function, as do any other devices which needs to hold a constraint against the CPU's clock speed (in your case it sounds like the touchscreen driver would hold this constraint). Again, the "tickle" concept here is made redundant. Regards, Mike > For the sysfs interface... we actually do not need sysfs interface for > tickling if we are going to allow tickle function to the interrupt > handler of HCI devices (touch screen, keyboards, mice, ...). However, > it seems that many people don't like that idea; thus, I thought I need > to allow userspace user-input handlers to tickle. > >> >> Thanks, >> >> Kevin >> _______________________________________________ >> linux-pm mailing list >> linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx >> https://lists.linux-foundation.org/mailman/listinfo/linux-pm >> > > > > -- > MyungJoo Ham (함명주), Ph.D. > Mobile Software Platform Lab, > Digital Media and Communications (DMC) Business > Samsung Electronics > cell: 82-10-6714-2858 > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
