Date: Wed, 9 Dec 2015 20:10:07 +0000
From: Mark Brown <broonie@kernel.org>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: Arnd Bergmann <arnd@arndb.de>, linux-pm@vger.kernel.org,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Stephen Warren <swarren@wwwdotorg.org>,
        Thierry Reding <thierry.reding@gmail.com>,
        Alexandre Courbot <gnurou@gmail.com>, linux-tegra@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Liam Girdwood <lgirdwood@gmail.com>
Message-ID: <20151209201007.GG5727@sirena.org.uk>
References: <2194927.eV2s2QmZs0@wuerfel>
 <5668188F.2080202@nvidia.com>
 <20151209144734.GB5727@sirena.org.uk>
 <566865ED.3020106@nvidia.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="BWpbUxt7sU2t3mXs"
Content-Disposition: inline
In-Reply-To: <566865ED.3020106@nvidia.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [PATCH] cpufreq: tegra: add regulator dependency for T124
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3082
Lines: 73


--BWpbUxt7sU2t3mXs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 09, 2015 at 05:33:33PM +0000, Jon Hunter wrote:
> On 09/12/15 14:47, Mark Brown wrote:

> > If changes implemented by the clock driver are trashing the regulator
> > settings I would expect the clock driver to be responsible for fixing
> > things up rather than another driver that happens to use the clock.  I'd
> > also expect some kind of internal documentation explaining what's going
> > on, and possibly=20

> Yes, the DFLL clock driver could restore the voltage, however, that
> does not guarantee that the voltage is still sufficient for the other
> clock source.

But the code we've got won't do that either - it'l just set the voltage
to whatever the last thing the regulator API had that might have been
within its constraints.

> > Setting the voltage you've read back sounds broken, if the hardware
> > might randomly change things how do you know the settings we read were
> > sane?  Shouldn't we know what voltage range the device requires in a
> > given mode and set that - that's much more normal?

> The hardware will not randomly change the voltage until the DFLL is
> enabled and so you would have to do this before.

I'm not clear that there's even a guarantee that the kernel will ever
have seen this configuration, consider for example what happens if
someone uses kexec?

> Yes, setting the frequency and voltage as defined by a given operating
> mode would make sense. However, I am not sure we have those defined in
> the kernel for this PLL and would have to be added.

I think given how you're describing the hardware that this will be
required in order to provide something robust (and also to get the best
power savings from the hardware).

> I was thinking that during boot we could read the default voltage and
> frequency set by the bootloader and use this as it should not be
> changing dynamically at this point because the cpufreq driver has not
> been activated yet.

I'm a bit confused here, we're talking about a change to the cpufreq
driver here aren't we?  Or alternatively why are we manipulating the
clock tree like this if we don't yet have support for the hardware?

--BWpbUxt7sU2t3mXs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWaIqfAAoJECTWi3JdVIfQgK0H/jzMENro5B0FAKbaLm5ilXMU
acF/SqGyuIC/vOyAs2kQzigGXADCY2BbAbuIWsy2g0WeOma1n33dDU+4mMVX0r0t
zvVqVJK617YhwErwg3BihJWOCukTl07nE+8l2Nu6uL94NzdYJvDH6yaG+emwlnS/
dsGmzrAmYHZsK0tjzw5d6HyU5uAxseNjzcapm8u0xLu+PRCGcTG8WKA7RW8mJ3R2
CeGaS2P701pOc9X/30Atx2+7ge8QwxD0oGLGebFcg5nnwOO78fmyrZbt+jWCDDko
UC6QG72hiZNrAgbJDo9jKsdeEUnzvzzY1a0/A3UrXfZjDpfwI8Jg4D9HZV+naH0=
=cNCo
-----END PGP SIGNATURE-----

--BWpbUxt7sU2t3mXs--
--
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/