From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751442Ab2EDFFs (ORCPT ); Fri, 4 May 2012 01:05:48 -0400 Received: from na3sys009aog117.obsmtp.com ([74.125.149.242]:60164 "EHLO na3sys009aog117.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751169Ab2EDFFr convert rfc822-to-8bit (ORCPT ); Fri, 4 May 2012 01:05:47 -0400 MIME-Version: 1.0 In-Reply-To: References: <1335462041-4949-1-git-send-email-j-keerthy@ti.com> <20120426191159.GA9415@sirena.org.uk> <20120427175657.GP18260@opensource.wolfsonmicro.com> <87397o3n4y.fsf@ti.com> <20120430095429.GB3170@opensource.wolfsonmicro.com> <87wr4wriq3.fsf@ti.com> Date: Fri, 4 May 2012 10:35:45 +0530 Message-ID: Subject: Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) From: "J, KEERTHY" To: Kevin Hilman Cc: Mark Brown , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, rjw@sisk.pl, linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org, j-pihet@ti.com, durgadoss.r@intel.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY wrote: > On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman wrote: >> Mark Brown writes: >> >>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: >>>> Mark Brown writes: >>> >>>> > But presumably these things should integrate somehow - for example, >>>> > should devfreq and cpufreq be providing inputs into what AVS is doing, >>>> > and if so how? >>> >>>> The way it is currently designed, cpufreq/devfreq/regulator layers don't >>>> need to know about AVS. >>> >>> Yes, and that was a part of my concern, but see below. >>> >>>> The higher-level layers only know about the "nominal" voltage.  AVS >>>> hardware does automatic, adaptive, micro-adjustments around that nominal >>>> voltage, and these micro-adjustments are managed by the AVS hardware >>>> sending commands to the PMIC.  (specifically, on OMAP, the AVS sensors >>>> provide inputs to the voltage processor (VP) which provide inputs to the >>>> voltage controller (VC) which sends commands to the PMIC[1].) >>> >>> Right, that's what I'd understood it to be. >>> >>>> The driver proposed here is primarily for initializing the various >>>> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage >>>> adjustments are done in hardware by VC/VP. >>> >>> It's not just a driver, though - it's also creating this power/avs >>> thing, though now I look at the code rather than just its shape there's >>> not actually an abstraction being added here, it's mostly just straight >>> code motion of the arch/arm code that's there already.  The changelog >>> and the shape of the code make it sound like this is intended to be >>> somewhat generic when really it's providing some OMAP specific tuning >>> for the device which is much less of a concern. >>> >>> I guess for now it's probably OK to just clarify in the documentation >>> and say that whoever adds the second driver has to work on making this >>> generic :) >> >> Agreed. >> >> In a different thread (which I can't seem to find now) we discussed this >> as well, so it just sounds like the changelog should clarify this a bit >> better. > > Kevin/Mark, > > Thanks for the feedback. I will add more documentation > to clarify this aspect. Please let me know if there are any more > things to be taken care of in this patch set. Hello Kevin, A gentle ping on this series. Any comments on this? > >> >> Kevin >> >>> This does also sound rather like it's in a similar area to the current >>> management work which Durgadoss R (CCed) was working on, though with a >>> slightly different application and in the OMAP case it's pretty much all >>> hidden in the external processor. >> > > > > -- > Regards and Thanks, > Keerthy -- Regards and Thanks, Keerthy From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J, KEERTHY" Subject: Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) Date: Fri, 4 May 2012 10:35:45 +0530 Message-ID: References: <1335462041-4949-1-git-send-email-j-keerthy@ti.com> <20120426191159.GA9415@sirena.org.uk> <20120427175657.GP18260@opensource.wolfsonmicro.com> <87397o3n4y.fsf@ti.com> <20120430095429.GB3170@opensource.wolfsonmicro.com> <87wr4wriq3.fsf@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-omap-owner@vger.kernel.org To: Kevin Hilman Cc: Mark Brown , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, rjw@sisk.pl, linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org, j-pihet@ti.com, durgadoss.r@intel.com List-Id: linux-pm@vger.kernel.org On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY wrote: > On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman wrote: >> Mark Brown writes: >> >>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: >>>> Mark Brown writes: >>> >>>> > But presumably these things should integrate somehow - for examp= le, >>>> > should devfreq and cpufreq be providing inputs into what AVS is = doing, >>>> > and if so how? >>> >>>> The way it is currently designed, cpufreq/devfreq/regulator layers= don't >>>> need to know about AVS. >>> >>> Yes, and that was a part of my concern, but see below. >>> >>>> The higher-level layers only know about the "nominal" voltage. =A0= AVS >>>> hardware does automatic, adaptive, micro-adjustments around that n= ominal >>>> voltage, and these micro-adjustments are managed by the AVS hardwa= re >>>> sending commands to the PMIC. =A0(specifically, on OMAP, the AVS s= ensors >>>> provide inputs to the voltage processor (VP) which provide inputs = to the >>>> voltage controller (VC) which sends commands to the PMIC[1].) >>> >>> Right, that's what I'd understood it to be. >>> >>>> The driver proposed here is primarily for initializing the various >>>> parameters/sensitivity/etc. of the AVS hardware, but the actual vo= ltage >>>> adjustments are done in hardware by VC/VP. >>> >>> It's not just a driver, though - it's also creating this power/avs >>> thing, though now I look at the code rather than just its shape the= re's >>> not actually an abstraction being added here, it's mostly just stra= ight >>> code motion of the arch/arm code that's there already. =A0The chang= elog >>> and the shape of the code make it sound like this is intended to be >>> somewhat generic when really it's providing some OMAP specific tuni= ng >>> for the device which is much less of a concern. >>> >>> I guess for now it's probably OK to just clarify in the documentati= on >>> and say that whoever adds the second driver has to work on making t= his >>> generic :) >> >> Agreed. >> >> In a different thread (which I can't seem to find now) we discussed = this >> as well, so it just sounds like the changelog should clarify this a = bit >> better. > > Kevin/Mark, > > Thanks for the feedback. I will add more documentation > to clarify this aspect. Please let me know if there are any more > things to be taken care of in this patch set. Hello Kevin, A gentle ping on this series. Any comments on this? > >> >> Kevin >> >>> This does also sound rather like it's in a similar area to the curr= ent >>> management work which Durgadoss R (CCed) was working on, though wit= h a >>> slightly different application and in the OMAP case it's pretty muc= h all >>> hidden in the external processor. >> > > > > -- > Regards and Thanks, > Keerthy --=20 Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: j-keerthy@ti.com (J, KEERTHY) Date: Fri, 4 May 2012 10:35:45 +0530 Subject: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) In-Reply-To: References: <1335462041-4949-1-git-send-email-j-keerthy@ti.com> <20120426191159.GA9415@sirena.org.uk> <20120427175657.GP18260@opensource.wolfsonmicro.com> <87397o3n4y.fsf@ti.com> <20120430095429.GB3170@opensource.wolfsonmicro.com> <87wr4wriq3.fsf@ti.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY wrote: > On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman wrote: >> Mark Brown writes: >> >>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: >>>> Mark Brown writes: >>> >>>> > But presumably these things should integrate somehow - for example, >>>> > should devfreq and cpufreq be providing inputs into what AVS is doing, >>>> > and if so how? >>> >>>> The way it is currently designed, cpufreq/devfreq/regulator layers don't >>>> need to know about AVS. >>> >>> Yes, and that was a part of my concern, but see below. >>> >>>> The higher-level layers only know about the "nominal" voltage. ?AVS >>>> hardware does automatic, adaptive, micro-adjustments around that nominal >>>> voltage, and these micro-adjustments are managed by the AVS hardware >>>> sending commands to the PMIC. ?(specifically, on OMAP, the AVS sensors >>>> provide inputs to the voltage processor (VP) which provide inputs to the >>>> voltage controller (VC) which sends commands to the PMIC[1].) >>> >>> Right, that's what I'd understood it to be. >>> >>>> The driver proposed here is primarily for initializing the various >>>> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage >>>> adjustments are done in hardware by VC/VP. >>> >>> It's not just a driver, though - it's also creating this power/avs >>> thing, though now I look at the code rather than just its shape there's >>> not actually an abstraction being added here, it's mostly just straight >>> code motion of the arch/arm code that's there already. ?The changelog >>> and the shape of the code make it sound like this is intended to be >>> somewhat generic when really it's providing some OMAP specific tuning >>> for the device which is much less of a concern. >>> >>> I guess for now it's probably OK to just clarify in the documentation >>> and say that whoever adds the second driver has to work on making this >>> generic :) >> >> Agreed. >> >> In a different thread (which I can't seem to find now) we discussed this >> as well, so it just sounds like the changelog should clarify this a bit >> better. > > Kevin/Mark, > > Thanks for the feedback. I will add more documentation > to clarify this aspect. Please let me know if there are any more > things to be taken care of in this patch set. Hello Kevin, A gentle ping on this series. Any comments on this? > >> >> Kevin >> >>> This does also sound rather like it's in a similar area to the current >>> management work which Durgadoss R (CCed) was working on, though with a >>> slightly different application and in the OMAP case it's pretty much all >>> hidden in the external processor. >> > > > > -- > Regards and Thanks, > Keerthy -- Regards and Thanks, Keerthy