Re: [PATCH v2 00/11] PM QoS: add a per-device wake-up latency constraint class

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux