All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Thara Gopinath <thara@ti.com>
Cc: linux-omap@vger.kernel.org, paul@pwsan.com, b-cousson@ti.com,
	vishwanath.bs@ti.com, sawant@ti.com
Subject: Re: [PATCH v2 01/14] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Date: Thu, 11 Nov 2010 15:53:25 -0800	[thread overview]
Message-ID: <87oc9vs9hm.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1288366708-32302-2-git-send-email-thara@ti.com> (Thara Gopinath's message of "Fri, 29 Oct 2010 21:08:15 +0530")

Thara Gopinath <thara@ti.com> writes:

> This patch introduces a user list of devices associated with each
> voltage domain instance. The user list is implemented using plist
> structure with priority node populated with the voltage values.
> This patch also adds an API which will take in a device and
> requested voltage as parameters, adds the info to the user list
> and returns back the maximum voltage requested by all the user
> devices. This can be used anytime to get the voltage that the
> voltage domain instance can be transitioned into.
>
> Signed-off-by: Thara Gopinath <thara@ti.com>

[...]

> +/**
> + * omap_voltage_add_request() - API to keep track of various requests to
> + *				scale the VDD and returns the best possible
> + *				voltage the VDD can be put to.
> + * @volt_domain:	pointer to the voltage domain.
> + * @dev:		the device pointer.
> + * @volt:		the voltage which is requested by the device.
> + *
> + * This API is to be called before the actual voltage scaling is
> + * done to determine what is the best possible voltage the VDD can
> + * be put to. This API adds the device <dev> in the user list of the
> + * vdd <volt_domain> with <volt> as the requested voltage. The user list
> + * is a plist with the priority element absolute voltage values.
> + * The API then finds the maximum of all the requested voltages for
> + * the VDD and returns it back through <volt> pointer itself.
> + * Returns error value in case of any errors.
> + */
> +int omap_voltage_add_request(struct voltagedomain *voltdm, struct device *dev,
> +		unsigned long *volt)
> +{
> +	struct omap_vdd_info *vdd;
> +	struct omap_vdd_user_list *user;
> +	struct plist_node *node;
> +	int found = 0;
> +
> +	if (!voltdm || IS_ERR(voltdm)) {
> +		pr_warning("%s: VDD specified does not exist!\n", __func__);
> +		return -EINVAL;
> +	}
> +
> +	vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
> +
> +	mutex_lock(&vdd->scaling_mutex);
> +
> +	plist_for_each_entry(user, &vdd->user_list, node) {
> +		if (user->dev == dev) {
> +			found = 1;

please drop the use of 'found' here.  This can be solved using
a tmp iterator instead:

	struct omap_vdd_user_list *tmp_user, *user = NULL;

	plist_for_each_entry(tmp_user, &vdd->user_list, node)
		if (tmp_user->dev == dev) {
			user = tmp_user;
			break;
		}

> +			break;
> +		}
> +	}
> +
> +	if (!found) {

        if (!user) {

> +		user = kzalloc(sizeof(struct omap_vdd_user_list), GFP_KERNEL);
> +		if (!user) {
> +			pr_err("%s: Unable to creat a new user for vdd_%s\n",
> +				__func__, voltdm->name);
> +			mutex_unlock(&vdd->scaling_mutex);
> +			return -ENOMEM;
> +		}
> +		user->dev = dev;
> +	} else {
> +		plist_del(&user->node, &vdd->user_list);
> +	}
> +
> +	plist_node_init(&user->node, *volt);
> +	plist_add(&user->node, &vdd->user_list);
> +	node = plist_last(&vdd->user_list);

The use of plist_last() doesn't seem right here. Won't plist_last()
return the node with the lowest voltage?, but this function is meant to
return the highest requested voltage.

I guess it currently works because it's only been tested with a single
requested voltage, so first and last are the same thing, but if I
understand the intent of the code correctly, I think it is broken if
ever there is more than one requester.

In [PATCH v2 07/14] OMAP: Introduce dependent voltage domain support, 
plist_first() is used to get the currently requesting node, so that is
what caused the confusion.   One side is using plist_first(), the other
plist_last() so one of them must be wrong.

> +	*volt = user->volt = node->prio;
> +
> +	mutex_unlock(&vdd->scaling_mutex);
> +
> +	return 0;
> +}

The above problems make me think that the 'request' and the 'get' part
of the above function should actually be separated out into two separate
functions.  One to add the request voltage, and another to query the
current max request.

The query function could then be used in patch 07/14 instead of using
plist directly.  That would clear up some of the confusion.

Kevin


  reply	other threads:[~2010-11-11 23:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29 15:38 [PATCH v2 00/14] OMAP: Basic DVFS framework Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 01/14] OMAP: Introduce a user list for each voltage domain instance in the voltage driver Thara Gopinath
2010-11-11 23:53   ` Kevin Hilman [this message]
2010-11-12  0:07   ` Kevin Hilman
2010-10-29 15:38 ` [PATCH v2 02/14] OMAP: Introduce API in the OPP layer to find the opp entry corresponding to a voltage Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 03/14] OMAP: Introduce voltage domain information in the hwmod structures Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 04/14] OMAP: Introduce API to register a device with a voltagedomain Thara Gopinath
2010-11-11  0:49   ` Kevin Hilman
2010-11-15 11:09     ` Gopinath, Thara
2010-10-29 15:38 ` [PATCH v2 05/14] OMAP: Introduce device specific set rate and get rate in omap_device structure Thara Gopinath
2010-11-11 22:59   ` Kevin Hilman
2010-11-15 11:14     ` Gopinath, Thara
2010-10-29 15:38 ` [PATCH v2 06/14] OMAP: Voltage layer changes to support DVFS Thara Gopinath
2010-11-11 23:34   ` Kevin Hilman
2010-11-15 14:12     ` Gopinath, Thara
2010-10-29 15:38 ` [PATCH v2 07/14] OMAP: Introduce dependent voltage domain support Thara Gopinath
2010-11-11 17:06   ` Kevin Hilman
2010-10-29 15:38 ` [PATCH v2 08/14] OMAP: Introduce device scale Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 09/14] OMAP: Disable smartreflex across DVFS Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 10/14] OMAP3: Introduce custom set rate and get rate APIs for scalable devices Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 11/14] OMAP3: Update cpufreq driver to use the new set_rate API Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 12/14] OMAP3: Introduce voltage domain info in the hwmod structures Thara Gopinath
2010-10-29 15:38 ` [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1 Thara Gopinath
2010-12-01 15:31   ` Vishwanath Sripathy
2010-12-01 15:32     ` Gopinath, Thara
2010-12-01 15:32   ` Vishwanath Sripathy
2010-10-29 15:38 ` [PATCH v2 14/14] OMAP2PLUS: Enable various options in defconfig Thara Gopinath
2010-11-08 19:24   ` Tony Lindgren

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=87oc9vs9hm.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=sawant@ti.com \
    --cc=thara@ti.com \
    --cc=vishwanath.bs@ti.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.