linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Benson Leung <bleung@google.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	linux-pm@vger.kernel.org, sre@kernel.org,
	Sameer Nanda <snanda@chromium.org>,
	gwendal@chromium.org, linux-kernel@vger.kernel.org,
	groeck@chromium.org, Adam.Thomson.Opensource@diasemi.com,
	kernel@collabora.com, bleung@chromium.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>
Subject: Re: [PATCH v2 1/2] power: supply: add input voltage limit property.
Date: Sun, 9 Dec 2018 09:44:58 +0100	[thread overview]
Message-ID: <20181209084458.GC7561@amd> (raw)
In-Reply-To: <20181203195845.GA120704@google.com>

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

Hi!

> On Sat, Dec 01, 2018 at 04:09:34PM +0100, Pavel Machek wrote:
> > > I think that handle this via dt / ACPI is not possible for our use case. It can
> > > be a hardware bug or a hardware/user constrain, let me try to explain better
> > > with an example.
> > > 
> > > On Pixel C's devices, userspace uses this to set a USB input limit of 5V when
> > > the screen is on for thermal reasons, but those go away when the screen is
> > > off/system is sleeping, so we allow 9V and 12V levels when sleeping.
> > 
> > So, on pixel C, what happens if userland ignores the constraint, keeps
> > display on and sets charger to 12V?
> 
> I was the software tech lead for the Google Pixel C and was involved in this
> particular code change in 2015 before the release of the product.
> 
> So there's nothing fundamentally broken about the hardware that would cause
> the Pixel C to malfunction if we were charging at 9V or 12V instead of 5V
> when the screen is on, ie if userspace doesn't change this.
> 
> This is part of the Pixel C's thermal management strategy to effectively
> limit the input power to 5V 3A when the screen is on. When the screen is on,
> the display, the CPU, and the GPU all contribute more heat to the system
> than while the screen is off, and we made a tradeoff to throttle the charger
> in order to give more of the thermal budget to those other components.
> 
> What would happen is that you wouldn't meet Google's skin temperature targets
> on the system if the charger was allowed to run at 9V or 12V with the screen
> on.

So... the system is still guaranteed to work. It may be hot but not
dangerously so, and lifetime of internal components is not going to be
decreased by heat...?

Ok, I guess in such case we can do it from userspace.

> For folks hacking on Pixel Cs (which is now outside of Google's official support
> window for Android) and customizing their own kernel and userspace
> this would be acceptable, but we wanted to expose this feature in the power
> supply properties because the feature does exist in the Emedded Controller
> firmware of the Pixel C and all of Google's Chromebooks with USB-C made since
> 2015 in case someone running an up to date kernel wanted to limit the charging
> power for thermal or other reasons.

Few concerns:

1) You are basically using voltage limit to limit power. We already
have current limits, but what both you and existing user really want
are power limits. Should we have power limit instead? Would be way
more logical.

(If your charger can do 5V 1A, 5V 2.5A, 5V 3A, 9V 1A, you may want to
limit to first two, not first three).

2) Should the policy be based not on "screen is on or off" but on real
temperatures? We already have a thermal framework, and other machines
have "limit charging power when hot" constraints IIRC...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

      parent reply	other threads:[~2018-12-09  8:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 10:11 [PATCH v2 1/2] power: supply: add input voltage limit property Enric Balletbo i Serra
2018-11-22 10:11 ` [PATCH v2 2/2] power: supply: cros: allow to set input voltage and current limit Enric Balletbo i Serra
2018-11-22 15:24   ` Guenter Roeck
2018-11-22 16:54 ` [PATCH v2 1/2] power: supply: add input voltage limit property Adam Thomson
2018-11-23 23:22 ` Pavel Machek
2018-11-30 12:19   ` Enric Balletbo i Serra
2018-12-01 15:09     ` Pavel Machek
2018-12-03 19:58       ` Benson Leung
2018-12-05 15:47         ` Sebastian Reichel
2018-12-09  8:44         ` Pavel Machek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181209084458.GC7561@amd \
    --to=pavel@ucw.cz \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=bleung@chromium.org \
    --cc=bleung@google.com \
    --cc=enric.balletbo@collabora.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=kernel@collabora.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=snanda@chromium.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).