From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
Date: Thu, 16 Sep 2010 09:01:43 -0500 [thread overview]
Message-ID: <4C922347.7050509@ti.com> (raw)
In-Reply-To: <4C9221AF.9000804@nokia.com>
Roger Quadros had written, on 09/16/2010 08:54 AM, the following:
> Since you are anyways re-sending this you might as well fix these nits.
thanks for reviewing..
>
[..]
>> diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
>> new file mode 100644
>> index 0000000..17f93b2
>> --- /dev/null
>> +++ b/arch/arm/plat-omap/opp.c
>> @@ -0,0 +1,461 @@
>> +/*
>> + * OMAP OPP Interface
>> + *
>> + * Copyright (C) 2009-2010 Texas Instruments Incorporated.
>> + * Nishanth Menon
>> + * Romit Dasgupta<romit@ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>
>> +/**
>> + * opp_get_voltage() - Gets the voltage corresponding to an opp
>> + * @opp: opp for which voltage has to be returned for
>> + *
>> + * Return voltage in micro volt corresponding to the opp, else
>> + * return 0
>> + */
>> +unsigned long opp_get_voltage(const struct omap_opp *opp)
>> +{
>> + if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
>
> If !opp->enabled, then is it really an invalid parameter being passed?
>
> I'm not user if people need to know the voltage of a disabled OPP, but
> do we need to limit it?
>
>> + pr_err("%s: Invalid parameters being passed\n", __func__);
>> + return 0;
>> + }
>> +
>> + return opp->u_volt;
>> +}
>> +
>> +/**
>> + * opp_get_freq() - Gets the frequency corresponding to an opp
>> + * @opp: opp for which frequency has to be returned for
>> + *
>> + * Return frequency in hertz corresponding to the opp, else
>> + * return 0
>> + */
>> +unsigned long opp_get_freq(const struct omap_opp *opp)
>> +{
>> + if (unlikely(!opp || IS_ERR(opp)) || !opp->enabled) {
>
> ditto.
Yes, the intent here was for opp operational apis to function ONLY on
the enabled opps - this helps to pull out any bugs in the users
who might be unintentionally using bad params.
do you have any usecase you can think of where we might want to use
these on a disabled opp?
>
>> + pr_err("%s: Invalid parameters being passed\n", __func__);
>> + return 0;
>> + }
>> +
>> + return opp->rate;
>> +}
>> +
>> +/**
>> + * opp_get_opp_count() - Get number of opps enabled in the opp list
>> + * @opp_type: OPP type we want to count
>> + *
>> + * This functions returns the number of opps if there are any OPPs enabled,
>> + * else returns corresponding error value.
>> + */
>> +int opp_get_opp_count(struct device *dev)
>> +{
>> + struct device_opp *dev_opp;
>> +
>> + dev_opp = find_device_opp(dev);
>> + if (IS_ERR(dev_opp))
>> + return -ENODEV;
>> +
>> + return dev_opp->enabled_opp_count;
>> +}
>> +
>> +/**
>> + * opp_find_freq_exact() - search for an exact frequency
>> + * @opp_type: OPP type we want to search in.
>> + * @freq: frequency to search for
>> + * @enabled: enabled/disabled OPP to search for
>> + *
>> + * Searches for exact match in the opp list and returns handle to the matching
>> + * opp if found, else returns ERR_PTR in case of error and should be handled
>> + * using IS_ERR.
>> + *
>> + * Note enabled is a modifier for the search. if enabled=true, then the match is
>
> Good to add some punctuation after 'Note'.
Thanks will do
>
>> + * for exact matching frequency and is enabled. if false, the match is for exact
>> + * frequency which is disabled.
>> + */
>
> cheers,
> -roger
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-09-16 14:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 21:56 [PATCH 0/4] OMAP OPP layer for 2.6.37 Kevin Hilman
2010-09-15 21:56 ` [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs Kevin Hilman
2010-09-16 10:25 ` Gopinath, Thara
2010-09-16 10:32 ` Menon, Nishanth
2010-09-16 10:33 ` Gopinath, Thara
2010-09-16 12:19 ` Linus Walleij
2010-09-16 12:40 ` Nishanth Menon
2010-09-16 13:24 ` Linus Walleij
2010-09-16 15:08 ` Kevin Hilman
2010-09-16 15:31 ` Nishanth Menon
2010-09-16 15:48 ` Kevin Hilman
2010-09-16 17:07 ` Linus Walleij
2010-09-16 17:10 ` Nishanth Menon
2010-09-16 17:13 ` Shilimkar, Santosh
2010-09-16 18:01 ` Kevin Hilman
2010-09-16 13:54 ` Roger Quadros
2010-09-16 14:01 ` Nishanth Menon [this message]
2010-09-16 14:20 ` Roger Quadros
2010-09-16 14:43 ` Nishanth Menon
2010-09-15 21:56 ` [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Kevin Hilman
2010-09-16 10:40 ` Gopinath, Thara
2010-09-16 12:15 ` Nishanth Menon
2010-09-16 13:51 ` Gopinath, Thara
2010-09-16 14:06 ` Nishanth Menon
2010-09-17 14:57 ` Gopinath, Thara
2010-09-17 15:03 ` Nishanth Menon
2010-09-16 17:16 ` Kevin Hilman
2010-09-17 15:11 ` Gopinath, Thara
2010-09-15 21:56 ` [PATCH 3/4] OMAP3: remove OPP interfaces from OMAP PM layer Kevin Hilman
2010-09-15 21:56 ` [PATCH 4/4] OMAP3: OPP: add OPP table data and initialization 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=4C922347.7050509@ti.com \
--to=nm@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).