Message-ID: <AANLkTimK7vD6mrPXyRdx331mCnRNLnajCRONT=MzQHwW@mail.gmail.com>
Date:	Mon, 24 Jan 2011 13:24:58 -0800
From:	Colin Cross <ccross@...roid.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-tegra@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	konkers@...roid.com, linux-kernel@...r.kernel.org, olof@...om.net,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend

On Mon, Jan 24, 2011 at 1:08 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Mon, Jan 24, 2011 at 12:52:51PM -0800, Colin Cross wrote:
>> On Mon, Jan 24, 2011 at 12:26 PM, Mark Brown
>
>> > Normally that's handled by the same transition logic - the core PMIC
>> > will usually sequence a bunch of voltage and power status changes when
>> > entering its own low power mode and have a similar transition on resume
>> > which will ensure that the regulators power back up with a sane setup
>> > regardless of the state they were in beforehand.
>
>> I believe Tegra supports this mode, where the Tegra PMC can master the
>> I2C bus to control an external PMIC during resume, but I've never seen
>> it used.
>
> In almost all cases it's implemented in the PMIC rather than the CPU -
> it's essentially the same logic as implements the initial power on of
> the system and the PMIC needs to be capable of starting the system boot
> without external assistance anyway, including sequencing the power up of
> the CPU.
>
> With most PMICs the settings will be hard coded into the silicon so
> you really need to get a PMIC specifically designed for whatever CPU
> you're using (this is one of the reasons you always see the same
> CPU/PMIC combinations, people are terrified of changing a known good
> pairing in case they build something that won't power on).  Some more
> modern PMICs make this configurable which gives system designers a lot
> more flexibility.

I'm seeing the opposite problem - changing CPUs, and keeping the PMIC.

> The PMC stuff is newer and in the designs I've seen is more focused on
> runtime management than this stuff.
>
>> > It sounds like for your systems what's happening is that the resume is
>> > restoring the previously configured voltages for the core rails rather
>> > than going to a known good state.  Is my understanding correct here?
>> > While your fix is good and I don't see any reason not to do it this does
>> > sound like something we should have a solution for in common code as I'd
>> > not be surprised if there were other hardware out there which did a
>> > similar thing.
>
>> Yes - the core can be connected to a dumb I2C regulator, which the
>> core can turn on and off with a request line, but can't control the
>> voltage without a regulator driver controlling the I2C bus.
>
> AIUI generally they end up working because whatever puts them into
> suspend actually resets them so when you release reset during resume
> they just recover whatever the default voltage they have is and normally
> the boot and resume conditions for the CPU are identical.  I could be
> off base there, most of the regulator API stuff has been done with
> integrated PMICs.

Resetting during suspend would be the sane thing to do, but that's not
what the hardware does.  The regulator also gets turned off during
idle, so it can't just be reset every time it turns off.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists