Date: Tue, 26 May 2015 16:45:15 +0100
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>, linux-kernel@vger.kernel.org,
        patches@opensource.wolfsonmicro.com
Subject: Re: [PATCH v6 1/1] mfd: arizona: Export functions to control
	subsystem DVFS
Message-ID: <20150526154515.GB26432@opensource.wolfsonmicro.com>
References: <1432047462-31860-1-git-send-email-rf@opensource.wolfsonmicro.com> <1432047462-31860-2-git-send-email-rf@opensource.wolfsonmicro.com> <20150526135205.GL11677@x1> <20150526152942.GU21577@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150526152942.GU21577@sirena.org.uk>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1129
Lines: 22

On Tue, May 26, 2015 at 04:29:42PM +0100, Mark Brown wrote:
> On Tue, May 26, 2015 at 02:52:05PM +0100, Lee Jones wrote:
> 
> > Shouldn't this DVFS dump live in drivers/cpufreq?
> 
> cpufreq is specifically for CPUs (with the governors and everything) and
> has its own problems here.  There is devfreq which was crated for this
> sort of thing (though more on a SoC level) though, not sure if it's a
> good fit or not.

The only codecs that have DVFS are WM8997, WM8998 and WM5102. No newer
codecs have it so it feels like unnecessary effort to create a whole
new driver for these three codecs. In any case, all we're really doing
here is setting the state of a single bit which tells the codec whether
we're feeding it enough DCVDD for it to do its internal DVFS. Most of
the additional complexity here is around co-operating with the
runtime_suspend/resume code in the MFD driver,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/