Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1287811

Re: [PATCH] cpufreq: tegra: add regulator dependency for T124

From Mark Brown <broonie@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] cpufreq: tegra: add regulator dependency for T124
Date 2015-12-09 21:20 +0100
Message-ID <qDTnr-4C7-9@gated-at.bofh.it> (permalink)
References <qDysI-7MA-27@gated-at.bofh.it> <qDLJh-8df-33@gated-at.bofh.it> <qDOe5-1dO-11@gated-at.bofh.it> <qDQSC-2X5-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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 

> 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?

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] cpufreq: tegra: add regulator dependency for T124 Arnd Bergmann <arnd@arndb.de> - 2015-12-08 23:00 +0100
  Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Viresh Kumar <viresh.kumar@linaro.org> - 2015-12-09 03:20 +0100
  Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Jon Hunter <jonathanh@nvidia.com> - 2015-12-09 13:10 +0100
    Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Mark Brown <broonie@kernel.org> - 2015-12-09 15:50 +0100
      Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Jon Hunter <jonathanh@nvidia.com> - 2015-12-09 18:40 +0100
        Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Mark Brown <broonie@kernel.org> - 2015-12-09 21:20 +0100
          Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Jon Hunter <jonathanh@nvidia.com> - 2015-12-10 11:10 +0100
            Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Mark Brown <broonie@kernel.org> - 2015-12-10 12:40 +0100
              Re: [PATCH] cpufreq: tegra: add regulator dependency for T124 Jon Hunter <jonathanh@nvidia.com> - 2015-12-10 13:20 +0100

csiph-web