On Monday, July 04, 2011, Vishwanath Sripathy wrote: > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Rafael J. Wysocki > > Sent: Sunday, July 03, 2011 12:51 AM > > To: jean.pihet@xxxxxxxxxxxxxx > > Cc: Paul Walmsley; Kevin Hilman; Magnus Damm; Linux PM mailing list; > > linux-omap@xxxxxxxxxxxxxxx; markgross@xxxxxxxxxxx; Jean Pihet > > Subject: Re: [PATCH v2 00/11] PM QoS: add a per-device wake-up > > latency constraint class > > > > Hi, > > > > On Thursday, June 30, 2011, jean.pihet@xxxxxxxxxxxxxx wrote: > > > From: Jean Pihet <j-pihet@xxxxxx> > > > > > > This patch set is in an RFC state, for review and comments. > > > > First off, I'm sorry I couldn't review the patchset earlier. > > > > > In order to implement the new class in PM QoS the following > > changes have been > > > made: > > > > > > 1. Add a new PM QoS class for device wake-up constraints > > > (PM_QOS_DEV_WAKEUP_LATENCY). > > > Due to the per-device nature of the new class the constraints > > lists are stored > > > inside the device dev_pm_info struct instead of the internal per- > > class > > > constraints lists. > > > The new class is only available from kernel drivers and so is not > > exported to > > > user space. > > > > Have you considered a design in which multiple devices may use the > > same > > list of constraints? It seems plausible that the constraints will > > be the > > same, for example, for all Ethernet adapters in the system, in which > > case it > > will be wasteful to duplicate the list of constraints for each of > > them. > > > > > 2. Added a notification of device insertion/removal from the > > device PM framework > > > to PM QoS. > > > This allows to init/de-init the per-device constraints list upon > > device insertion > > > and removal. > > > RFC state for comments and review, barely tested > > > > I need to have a look at the details, but in principle this means > > that the > > per-device lists will be usable only after the devices have been > > registered. > > In particular, this means that it will only be possible to add new > > constraints > > after registering the device, which may be too late for some use > > cases. > > > > > 3. Make the pm_qos_add_request API more generic by using a > > > struct pm_qos_parameters parameter. This allows easy extension in > > the future. > > > > > > 4. Upon a change of the strongest constraint in the > > PM_QOS_DEV_WAKEUP_LATENCY > > > class a notification chain mechanism is used to take action on the > > system. > > > This is the proposed way to have PM QoS and the platform dependant > > code to > > > interact with each other, cf. 4 below. > > > > I guess you mean 5.? > > > > I think we will need something in addition to the notifier here. > > For example, > > I wouldn't like any core code, like runtime PM or cpuidle, to have > > to register > > a notifier with PM QoS. > > > > > The notification mechanism now passes the constraint request > > struct ptr in > > > order for the notifier callback to have access to the full set of > > constraint > > > data, e.g. the struct device ptr. > > > > > > 5. cpuidle interaction with the OMAP3 cpuidle handler > > > Since cpuidle is a CPU centric framework it decides the MPU next > > power state > > > based on the MPU exit_latency and target_residency figures. > > > > > > The rest of the power domains get their next power state > > programmed from > > > the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS framework, via > > the device > > > wake-up latency constraints. > > > > > > Note: the exit_latency and target_residency figures of the MPU > > include the MPU > > > itself and the peripherals needed for the MPU to execute > > instructions (e.g. > > > main memory, caches, IRQ controller, MMU etc). > > > Some of those peripherals can belong to other power domains than > > the MPU > > > subsystem and so the corresponding latencies must be included in > > those figures. > > > > > > 6. Update the pm_qos_add_request callers to the generic API > > > > > > 7. Minor clean-ups and rename of struct fields > > > > > > Questions: > > > 1. How to retrieve the device ptr from a given device driver in > > order to add > > > a constraint on it? > > > 2. The device struct has recently been extended with the power > > domain > > > information. Can this be used to apply the constraints on power > > domains? > > > > Yes, it can in principle, but that will require some work. > > > > > On-going developments, patches in preparation: > > > 1. write Documentation for the new PM QoS class > > > > I'd wait with that until the code has settled. > > > > > 2. validate the constraints framework on OMAP4 HW (done on OMAP3) > > > 3. refine the power domains wake-up latency and the cpuidle > > figures > > > > > > Based on the master branch of the linux-omap git tree (3.0.0-rc3). > > Compile > > > tested using OMAP and x86 generic defconfigs. > > > Tested on OMAP3 Beagleboard (ES2.x) with full RETention and OFF > > modes. > > > > More detailed comments will follow. > Thanks Rafael for reviewing the patches. Jean is currently on summer > vacation for 2 weeks and will take this discussion forward once he is back > to work on July 18. OK, thanks for letting me know. Regards, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
