From: Kevin Hilman <khilman@ti.com>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
paul@pwsan.com, Jean Pihet <j-pihet@ti.com>
Subject: Re: [PATCH v2 4/7] OMAP: PM CONSTRAINTS: implement the constraints management code
Date: Fri, 18 Mar 2011 08:06:47 -0700 [thread overview]
Message-ID: <87ipvgo4c8.fsf@ti.com> (raw)
In-Reply-To: <AANLkTin4T1Tk88Ud-TSQ1SOEWuZnv-XXwm8V2wUSUvr_@mail.gmail.com> (Jean Pihet's message of "Fri, 18 Mar 2011 12:33:22 +0100")
Jean Pihet <jean.pihet@newoldbits.com> writes:
[...]
>>> +exit_ok:
>>> + /* Find the strongest constraint for the given target */
>>> + ret = 0;
>>> + if (ascending) {
>>> + list_for_each_entry(user, &(constraints_list)->node_list,
>>> + node.plist.node_list) {
>>> + /* Find the lowest (i.e. first) value for the target */
>>> + if (user->target == target) {
>>> + ret = user->constraint_value;
>>> + break;
>>> + }
>>> + }
>>> + } else {
>>> + list_for_each_entry_reverse(user,
>>> + &(constraints_list)->node_list,
>>> + node.plist.node_list) {
>>> + /* Find the highest (i.e. last) value for the target */
>>> + if (user->target == target) {
>>> + ret = user->constraint_value;
>>> + break;
>>> + }
>>> + }
>>> + }
>>
>> Hmm, why can't you use plist_first() and plist_last() here?
> Because the plist is sorted by the 'prio' field (which is 'value' in
> this code) and this function searches for the strongest constraint for
> a given target. So it is needed to iterate through the list in order
> to find the first (or last) constraint with the right target.
Hmm, still confusing.
The main thing I don't get is why you need the 'target' field in the
first place. You should just keep a list of constraints per target
omap_device. IOW, currently your _wkup_lat_constraints_list is a global
list, but instead it should be connected to the omap_device, and each
omap_device would have a plist for each class.
>>
>>> +exit_error:
>>> + mutex_unlock(&_constraints_mutex);
>>> +
>>> + return ret;
>>> +}
>>>
>>> /* Public functions for use by core code */
>>>
>>> /**
>>> + * omap_device_set_dev_constraint - set/release a device constraint
>>> + * @class: constraint class
>>> + * @req_dev: constraint requester, used for tracking the constraints
>>> + * @dev: device to apply the constraint to. Must have an associated omap_device
>>> + * @t: constraint value. A value of -1 removes the constraint.
>>> + *
>>> + * Using the primary hwmod, set/release a device constraint for the dev
>>> + * device, requested by the req_dev device. Depending of the constraint class
>>> + * this code calls the appropriate low level code, e.g. power domain for
>>> + * the wake-up latency constraints.
>>> + *
>>> + * If any hwmods exist for the omap_device assoiated with @dev,
>>> + * set/release the constraint for the corresponding hwmods, otherwise return
>>> + * -EINVAL.
>>> + */
>>> +int omap_device_set_dev_constraint(enum omap_pm_constraint_class class,
>>> + struct device *req_dev,
>>> + struct device *dev, long t)
>>> +{
>>> + struct omap_device *od;
>>> + struct omap_hwmod *oh;
>>> + struct platform_device *pdev;
>>> + struct powerdomain *pwrdm = NULL;
>>> + u32 ret = -EINVAL;
>>> +
>>> + /* Look for the platform device for dev */
>>> + pdev = to_platform_device(dev);
>>> +
>>> + /* Try to catch non platform devices. */
>>> + if (pdev->name == NULL) {
>>
>> This should check for a valid omap_device, not platform_device.
> This check remains but the check below is changed, see below.
What I mean is this should check for omap_device_parent to see if the
struct device is an omap_device. IOW, you care whether or not it's an
omap_device, not whether or not it's a valid platform_device.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/7] OMAP: PM CONSTRAINTS: implement the constraints management code
Date: Fri, 18 Mar 2011 08:06:47 -0700 [thread overview]
Message-ID: <87ipvgo4c8.fsf@ti.com> (raw)
In-Reply-To: <AANLkTin4T1Tk88Ud-TSQ1SOEWuZnv-XXwm8V2wUSUvr_@mail.gmail.com> (Jean Pihet's message of "Fri, 18 Mar 2011 12:33:22 +0100")
Jean Pihet <jean.pihet@newoldbits.com> writes:
[...]
>>> +exit_ok:
>>> + ? ? /* Find the strongest constraint for the given target */
>>> + ? ? ret = 0;
>>> + ? ? if (ascending) {
>>> + ? ? ? ? ? ? list_for_each_entry(user, &(constraints_list)->node_list,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? node.plist.node_list) {
>>> + ? ? ? ? ? ? ? ? ? ? /* Find the lowest (i.e. first) value for the target */
>>> + ? ? ? ? ? ? ? ? ? ? if (user->target == target) {
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ret = user->constraint_value;
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
>>> + ? ? ? ? ? ? ? ? ? ? }
>>> + ? ? ? ? ? ? }
>>> + ? ? } else {
>>> + ? ? ? ? ? ? list_for_each_entry_reverse(user,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &(constraints_list)->node_list,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? node.plist.node_list) {
>>> + ? ? ? ? ? ? ? ? ? ? /* Find the highest (i.e. last) value for the target */
>>> + ? ? ? ? ? ? ? ? ? ? if (user->target == target) {
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ret = user->constraint_value;
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
>>> + ? ? ? ? ? ? ? ? ? ? }
>>> + ? ? ? ? ? ? }
>>> + ? ? }
>>
>> Hmm, why can't you use plist_first() and plist_last() here?
> Because the plist is sorted by the 'prio' field (which is 'value' in
> this code) and this function searches for the strongest constraint for
> a given target. So it is needed to iterate through the list in order
> to find the first (or last) constraint with the right target.
Hmm, still confusing.
The main thing I don't get is why you need the 'target' field in the
first place. You should just keep a list of constraints per target
omap_device. IOW, currently your _wkup_lat_constraints_list is a global
list, but instead it should be connected to the omap_device, and each
omap_device would have a plist for each class.
>>
>>> +exit_error:
>>> + ? ? mutex_unlock(&_constraints_mutex);
>>> +
>>> + ? ? return ret;
>>> +}
>>>
>>> ?/* Public functions for use by core code */
>>>
>>> ?/**
>>> + * omap_device_set_dev_constraint - set/release a device constraint
>>> + * @class: constraint class
>>> + * @req_dev: constraint requester, used for tracking the constraints
>>> + * @dev: device to apply the constraint to. Must have an associated omap_device
>>> + * @t: constraint value. A value of -1 removes the constraint.
>>> + *
>>> + * Using the primary hwmod, set/release a device constraint for the dev
>>> + * device, requested by the req_dev device. Depending of the constraint class
>>> + * this code calls the appropriate low level code, e.g. power domain for
>>> + * the wake-up latency constraints.
>>> + *
>>> + * If any hwmods exist for the omap_device assoiated with @dev,
>>> + * set/release the constraint for the corresponding hwmods, otherwise return
>>> + * -EINVAL.
>>> + */
>>> +int omap_device_set_dev_constraint(enum omap_pm_constraint_class class,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *req_dev,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *dev, long t)
>>> +{
>>> + ? ? struct omap_device *od;
>>> + ? ? struct omap_hwmod *oh;
>>> + ? ? struct platform_device *pdev;
>>> + ? ? struct powerdomain *pwrdm = NULL;
>>> + ? ? u32 ret = -EINVAL;
>>> +
>>> + ? ? /* Look for the platform device for dev */
>>> + ? ? pdev = to_platform_device(dev);
>>> +
>>> + ? ? /* Try to catch non platform devices. */
>>> + ? ? if (pdev->name == NULL) {
>>
>> This should check for a valid omap_device, not platform_device.
> This check remains but the check below is changed, see below.
What I mean is this should check for omap_device_parent to see if the
struct device is an omap_device. IOW, you care whether or not it's an
omap_device, not whether or not it's a valid platform_device.
Kevin
next prev parent reply other threads:[~2011-03-18 15:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 17:47 [PATCH v2 0/7] OMAP: add PM CONSTRAINTS framework Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-10 17:47 ` [PATCH v2 1/7] OMAP PM: create a PM layer plugin for per-device constraints Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-10 17:47 ` [PATCH v2 2/7] OMAP: PM CONSTRAINTS: add an enum for the classes of constraint Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-10 17:47 ` [PATCH v2 3/7] OMAP: PM CONSTRAINTS: implement wake-up latency constraints Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-17 20:18 ` Kevin Hilman
2011-03-17 20:18 ` Kevin Hilman
2011-03-10 17:47 ` [PATCH v2 4/7] OMAP: PM CONSTRAINTS: implement the constraints management code Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-17 20:36 ` Kevin Hilman
2011-03-17 20:36 ` Kevin Hilman
2011-03-18 11:33 ` Jean Pihet
2011-03-18 11:33 ` Jean Pihet
2011-03-18 15:06 ` Kevin Hilman [this message]
2011-03-18 15:06 ` Kevin Hilman
2011-03-10 17:47 ` [PATCH v2 5/7] OMAP: PM CONSTRAINTS: add a power domains state update function in hwmod Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-17 20:42 ` Kevin Hilman
2011-03-17 20:42 ` Kevin Hilman
2011-03-10 17:47 ` [PATCH v2 6/7] OMAP: PM CONSTRAINTS: control power domains next state Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-17 20:58 ` Kevin Hilman
2011-03-17 20:58 ` Kevin Hilman
2011-03-10 17:47 ` [PATCH v2 7/7] OMAP: PM CONSTRAINTS: add power domains wake-up latency figures Jean Pihet
2011-03-10 17:47 ` Jean Pihet
2011-03-17 20:59 ` Kevin Hilman
2011-03-17 20:59 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ipvgo4c8.fsf@ti.com \
--to=khilman@ti.com \
--cc=j-pihet@ti.com \
--cc=jean.pihet@newoldbits.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.