From: Nishanth Menon <nm@ti.com>
To: Thara Gopinath <thara@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"khilman@deeprootsystems.com" <khilman@deeprootsystems.com>,
"paul@pwsan.com" <paul@pwsan.com>,
"tony@atomide.com" <tony@atomide.com>,
"Cousson, Benoit" <b-cousson@ti.com>,
"Sawant, Anand" <sawant@ti.com>,
"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
"Premi, Sanjeev" <premi@ti.com>
Subject: Re: [PM-OPP][PATCH 0/4] OMAP: Clean up series for generic opp layer.
Date: Tue, 13 Jul 2010 10:53:12 -0500 [thread overview]
Message-ID: <4C3C8BE8.30108@ti.com> (raw)
In-Reply-To: <1279000026-24042-1-git-send-email-thara@ti.com>
Thara Gopinath had written, on 07/13/2010 12:47 AM, the following:
> This patch series does some clean up of the opp layer
> including removal of compilation warnings, avoiding wrong inclusioin
> of header files, correcting some srror checks and removing the dependency
> of opp layer on cpu freq layer.
>
> Apart from all these there is still one more concern i have in this generic
> opp layer. This is regarding the separate PMIC opp file opp_twl_tps.c which
> today caters to only twl4030 and twl5030 pmic. What is the approach to be
> taken if the PMIC changes? I am already facing this issue with OMAP4 where
> the PMIC is twl6030 and the formulas for converting vsel into voltage and
> vice versa are different. I am against adding another file for twl6030. The
> approach is not scalable. We need to keep these vsel to uV and vice versa
> convertion in one place or make them functions pointers.
why is opp_twl_tps.c unable to decide the vsel conversion routines based
on twl version? it seems to me (only watching l-o - not dug inside
twl6030 datamanual), that rest of 6030 code seem to share 5030 codebase
mostly..
on a side note - this is a bigger problem for voltage.c which seem to
have some ingrained idea that each step is 12.5mV and delays are coded
in.. but not related to opp layer at all.
>
> Thara Gopinath (4):
> OMAP: Fix the compilation warning in the opp layer
> OMAP: Correct the return value check after call into find_device_opp
> OMAP: Remove inclusion of PMIC specific header file in generic opp
> layer.
> OMAP: Remove dependency of generic opp layer on cpufreq.
This specific series once the minor comment provided is looking good to me.
>
> arch/arm/plat-omap/Makefile | 4 ++--
> arch/arm/plat-omap/include/plat/opp.h | 4 ++--
> arch/arm/plat-omap/opp.c | 7 +++----
> 3 files changed, 7 insertions(+), 8 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-07-13 15:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-13 5:47 [PM-OPP][PATCH 0/4] OMAP: Clean up series for generic opp layer Thara Gopinath
2010-07-13 5:47 ` [PM-OPP][PATCH 1/4] OMAP: Fix the compilation warning in the " Thara Gopinath
2010-07-13 5:47 ` [PM-OPP][PATCH 2/4] OMAP: Correct the return value check after call into find_device_opp Thara Gopinath
2010-07-13 5:47 ` [PM-OPP][PATCH 3/4] OMAP: Remove inclusion of PMIC specific header file in generic opp layer Thara Gopinath
2010-07-13 5:47 ` [PM-OPP][PATCH 4/4] OMAP: Remove dependency of generic opp layer on cpufreq Thara Gopinath
2010-07-13 12:23 ` [PM-OPP][PATCH 2/4] OMAP: Correct the return value check after call into find_device_opp Nishanth Menon
2010-07-13 14:32 ` Gopinath, Thara
2010-07-13 14:42 ` Nishanth Menon
2010-07-13 15:53 ` Nishanth Menon [this message]
2010-07-14 0:39 ` [PM-OPP][PATCH 0/4] OMAP: Clean up series for generic opp layer Gopinath, Thara
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=4C3C8BE8.30108@ti.com \
--to=nm@ti.com \
--cc=b-cousson@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=premi@ti.com \
--cc=sawant@ti.com \
--cc=thara@ti.com \
--cc=tony@atomide.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.