All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Vishwanath BS <vishwanath.bs@ti.com>
Cc: linux-omap@vger.kernel.org, patches@linaro.org,
	Thara Gopinath <thara@ti.com>
Subject: Re: [PATCH 05/13] OMAP: Introduce device scale implementation
Date: Fri, 04 Feb 2011 08:04:31 -0800	[thread overview]
Message-ID: <87d3n7u6pc.fsf@ti.com> (raw)
In-Reply-To: <1295618465-15234-6-git-send-email-vishwanath.bs@ti.com> (Vishwanath BS's message of "Fri, 21 Jan 2011 19:30:57 +0530")

Vishwanath BS <vishwanath.bs@ti.com> writes:

> This patch adds omap_device_scale API  which can be used to generic
> device rate scaling.

I would've expected a new omap_device_* API to be part of the
omap_device layer, not added here.

> Based on original patch from Thara.
>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> Cc: Thara Gopinath <thara@ti.com>
> ---
>  arch/arm/mach-omap2/dvfs.c             |  116 ++++++++++++++++++++++++++++++++
>  arch/arm/plat-omap/include/plat/dvfs.h |    7 ++
>  2 files changed, 123 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-omap2/dvfs.c
> index c9d3894..05a9ce3 100755
> --- a/arch/arm/mach-omap2/dvfs.c
> +++ b/arch/arm/mach-omap2/dvfs.c
> @@ -19,6 +19,7 @@
>  #include <plat/common.h>
>  #include <plat/voltage.h>
>  #include <plat/omap_device.h>
> +#include <plat/smartreflex.h>
>  
>  /**
>   * struct omap_dev_user_list - Structure maitain userlist per device
> @@ -585,6 +586,121 @@ static int omap_dvfs_voltage_scale(struct omap_vdd_dvfs_info *dvfs_info)
>  }
>  
>  /**
> + * omap_device_scale() - Set a new rate at which the device is to operate
> + * @req_dev:	pointer to the device requesting the scaling.
> + * @target_dev:	pointer to the device that is to be scaled
> + * @rate:	the rnew rate for the device.
> + *
> + * This API gets the device opp table associated with this device and
> + * tries putting the device to the requested rate and the voltage domain
> + * associated with the device to the voltage corresponding to the
> + * requested rate. Since multiple devices can be assocciated with a
> + * voltage domain this API finds out the possible voltage the
> + * voltage domain can enter and then decides on the final device
> + * rate. Return 0 on success else the error value
> + */

Here would be a good place to describe why both the requesting device
and the target device need to be tracked.

> +int omap_device_scale(struct device *req_dev, struct device *target_dev,
> +			unsigned long rate)
> +{
> +	struct opp *opp;
> +	unsigned long volt, freq, min_freq, max_freq;
> +	struct omap_vdd_dvfs_info *dvfs_info;
> +	struct platform_device *pdev;
> +	struct omap_device *od;
> +	int ret = 0;
> +
> +	pdev = container_of(target_dev, struct platform_device, dev);
> +	od = container_of(pdev, struct omap_device, pdev);
> +
> +	/*
> +	 * Figure out if the desired frquency lies between the
> +	 * maximum and minimum possible for the particular device
> +	 */
> +	min_freq = 0;
> +	if (IS_ERR(opp_find_freq_ceil(target_dev, &min_freq))) {
> +		dev_err(target_dev, "%s: Unable to find lowest opp\n",
> +						__func__);
> +		return -ENODEV;
> +	}
> +
> +	max_freq = ULONG_MAX;
> +	if (IS_ERR(opp_find_freq_floor(target_dev, &max_freq))) {
> +		dev_err(target_dev, "%s: Unable to find highest opp\n",
> +						__func__);
> +		return -ENODEV;
> +	}
> +
> +	if (rate < min_freq)
> +		freq = min_freq;
> +	else if (rate > max_freq)
> +		freq = max_freq;
> +	else
> +		freq = rate;
> +

OK, frome here on, I would expect the adjusted value 'freq' to be used
instead of 'rate', but that is not the case below.

> +	opp = opp_find_freq_ceil(target_dev, &freq);
> +	if (IS_ERR(opp)) {
> +		dev_err(target_dev, "%s: Unable to find OPP for freq%ld\n",
> +			__func__, rate);
> +		return -ENODEV;
> +	}
> +
> +	/* Get the voltage corresponding to the requested frequency */
> +	volt = opp_get_voltage(opp);
> +
> +	/*
> +	 * Call into the voltage layer to get the final voltage possible
> +	 * for the voltage domain associated with the device.
> +	 */

This comment doesn't match the following code.

> +	if (rate) {

Why is rate used here, and not freq?

> +		dvfs_info = get_dvfs_info(od->hwmods[0]->voltdm);
> +
> +		ret = omap_dvfs_add_freq_request(dvfs_info, req_dev,
> +						target_dev, freq);
> +		if (ret) {
> +			dev_err(target_dev, "%s: Unable to add frequency request\n",
> +				__func__);
> +			return ret;
> +		}
> +
> +		ret = omap_dvfs_add_vdd_user(dvfs_info, req_dev, volt);
> +		if (ret) {
> +			dev_err(target_dev, "%s: Unable to add voltage request\n",
> +				__func__);
> +			omap_dvfs_remove_freq_request(dvfs_info, req_dev,
> +				target_dev);
> +			return ret;
> +		}
> +	} else {

The function comments don't describe this case.  Namely, that if you
pass in rate = 0, it removes any previous requests for the requesting
device.

> +		dvfs_info = get_dvfs_info(od->hwmods[0]->voltdm);
> +
> +		ret = omap_dvfs_remove_freq_request(dvfs_info, req_dev,
> +				target_dev);
> +		if (ret) {
> +			dev_err(target_dev, "%s: Unable to remove frequency request\n",
> +				__func__);
> +			return ret;
> +		}
> +
> +		ret = omap_dvfs_remove_vdd_user(dvfs_info, req_dev);
> +		if (ret) {
> +			dev_err(target_dev, "%s: Unable to remove voltage request\n",
> +				__func__);
> +			return ret;
> +		}
> +	}
> +
> +	/* Do the actual scaling */
> +	ret = omap_dvfs_voltage_scale(dvfs_info);

ok

> +	if (!ret)
> +		if (omap_device_get_rate(target_dev) >= rate)
> +			return 0;
> +

but this bit needs some explanation.  IIUC: if the _voltage_scale()
fails (which also scales the frequency) but the frequency was
sucessfully changed, then return success.

Also 'rate' is used here where 'freq' would be expected.

> +	return ret;
> +}
> +EXPORT_SYMBOL(omap_device_scale);
> +
> +/**
>   * omap_dvfs_init() - Initialize omap dvfs layer
>   *
>   * Initalizes omap dvfs layer. It basically allocates memory for
> diff --git a/arch/arm/plat-omap/include/plat/dvfs.h b/arch/arm/plat-omap/include/plat/dvfs.h
> index 1302990..1be2b9d 100644
> --- a/arch/arm/plat-omap/include/plat/dvfs.h
> +++ b/arch/arm/plat-omap/include/plat/dvfs.h
> @@ -17,11 +17,18 @@
>  
>  #ifdef CONFIG_PM
>  int omap_dvfs_register_device(struct voltagedomain *voltdm, struct device *dev);
> +int omap_device_scale(struct device *req_dev, struct device *dev,
> +			unsigned long rate);
>  #else
>  static inline int omap_dvfs_register_device(struct voltagedomain *voltdm,
>  		struct device *dev)
>  {
>  	return -EINVAL;
>  }
> +static inline int omap_device_scale(struct device *req_dev, struct devices
> +			*target_dev, unsigned long rate);
> +{
> +	return -EINVAL;
> +}
>  #endif
>  #endif

Kevin

  reply	other threads:[~2011-02-04 16:04 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21 14:00 [PATCH 00/13] OMAP: Basic DVFS Framework Vishwanath BS
2011-01-21 14:00 ` [PATCH 01/13] OMAP: Introduce accessory APIs for DVFS Vishwanath BS
2011-02-03  1:07   ` Kevin Hilman
2011-02-08 11:22     ` Vishwanath Sripathy
2011-02-09 15:35       ` Kevin Hilman
2011-01-21 14:00 ` [PATCH 02/13] OMAP: Introduce device specific set rate and get rate in omap_device structure Vishwanath BS
2011-02-03 23:46   ` Kevin Hilman
2011-02-07 13:36     ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 03/13] OMAP: Implement Basic DVFS Vishwanath BS
2011-02-04  1:14   ` Kevin Hilman
2011-02-07 14:18     ` Vishwanath Sripathy
2011-02-09 15:59       ` Kevin Hilman
2011-02-09 16:24         ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 04/13] OMAP: Introduce dependent voltage domain support Vishwanath BS
2011-02-04 15:37   ` Kevin Hilman
2011-02-07 14:34     ` Vishwanath Sripathy
2011-02-10 16:36       ` Kevin Hilman
2011-02-11  4:41         ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 05/13] OMAP: Introduce device scale implementation Vishwanath BS
2011-02-04 16:04   ` Kevin Hilman [this message]
2011-02-07 14:56     ` Vishwanath Sripathy
2011-02-10 16:37       ` Kevin Hilman
2011-01-21 14:00 ` [PATCH 06/13] OMAP: Disable Smartreflex across DVFS Vishwanath BS
2011-02-04 16:06   ` Kevin Hilman
2011-02-07 14:58     ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 07/13] OMAP3: Introduce custom set rate and get rate APIs for scalable devices Vishwanath BS
2011-02-04 16:08   ` Kevin Hilman
2011-01-21 14:01 ` [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS support Vishwanath BS
2011-02-04 16:09   ` Kevin Hilman
2011-02-14  9:34   ` Kahn, Gery
2011-02-14 12:49     ` Vishwanath Sripathy
2011-02-14 13:03       ` Menon, Nishanth
2011-02-14 13:42         ` Vishwanath Sripathy
2011-02-14 15:35       ` Kahn, Gery
2011-04-13 14:13   ` Jarkko Nikula
2011-04-13 17:57     ` Vishwanath Sripathy
2011-04-14 12:28       ` Jarkko Nikula
2011-01-21 14:01 ` [PATCH 09/13] OMAP3: Introduce voltage domain info in the hwmod structures Vishwanath BS
2011-02-04 16:10   ` Kevin Hilman
2011-01-21 14:01 ` [PATCH 10/13] OMAP3: Add voltage dependency table for VDD1 Vishwanath BS
2011-01-29  0:31   ` Kevin Hilman
2011-01-30 12:59     ` Vishwanath Sripathy
2011-01-31 15:38       ` Kevin Hilman
2011-02-28 11:48     ` Jarkko Nikula
2011-01-21 14:01 ` [PATCH 11/13] OMAP2PLUS: Replace voltage values with Macros Vishwanath BS
2011-02-04 16:44   ` Kevin Hilman
2011-01-21 14:01 ` [PATCH 12/13] OMAP2PLUS: Enable various options in defconfig Vishwanath BS
2011-01-21 14:01 ` [PATCH 13/13] OMAP: Add DVFS Documentation Vishwanath BS
2011-02-04  1:38   ` Kevin Hilman
2011-01-22 17:18 ` [PATCH 00/13] OMAP: Basic DVFS Framework Felipe Balbi
2011-01-24  6:01   ` Vishwanath Sripathy
2011-01-24  6:18     ` Felipe Balbi
2011-01-24 14:25       ` Vishwanath Sripathy
2011-01-24 15:25         ` Laurent Pinchart
2011-01-24 15:29         ` Felipe Balbi
2011-01-24 20:00   ` Kevin Hilman
2011-01-25  3:53     ` Felipe Balbi
2011-02-01 12:27 ` Vishwanath Sripathy

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=87d3n7u6pc.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=patches@linaro.org \
    --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.