From: Pavel Machek <pavel@ucw.cz>
To: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Linux PM list <linux-pm@vger.kernel.org>,
Sebastian Reichel <sre@kernel.org>,
Sameer Nanda <snanda@chromium.org>,
Benson Leung <bleung@chromium.org>,
Gwendal Grignou <gwendal@chromium.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Guenter Roeck <groeck@chromium.org>,
Adam.Thomson.Opensource@diasemi.com, kernel@collabora.com,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>
Subject: Re: [PATCH v3 1/2] power: supply: add input voltage limit property
Date: Tue, 8 Jan 2019 19:47:14 +0100 [thread overview]
Message-ID: <20190108184714.GA11289@amd> (raw)
In-Reply-To: <CAFqH_53E1ori_b69XkpAafaAZKZE3GzbN5eFvU9FbUTgjHbi+g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]
Hi!
> > >> 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.
> > >>
> > >> This patch exposes a new property, similar to input current limit, to
> > >> re-configure the maximum voltage from the external supply at runtime
> > >> based on system-level knowledge or user input.
> > >
> > > Could we get power input limit, instead?
> > >
> >
> > I'm open but I have some concerns, so lets discuss a bit about it :)
> >
> > According to the USB PD 2.0 specs if we limit the source at 15W we can get 5V/3A
> > or 9V/1.67A, if I am not mistaken the higher voltage caused problem since the
> > conversion to lower internal voltages generated more heat, so in this case
> > 9V/1.67A is not a valid value for us (maybe someone from ChromeOS can confirm
> > this?).
> Around Xmas are bad dates to start a discussion. I don't want this
> patch will be forgotten, so a gentle ping on your thoughts on this :)
> (just in case)
If someone can indeed confirm it is _voltage_ that is problematic,
then approach is ok with me. [But I'd not expect buck convertor
efficiency to differ greatly based on input voltage.]
Best regards,
Pavel
> > >> +What: /sys/class/power_supply/<supply_name>/input_voltage_limit
> > >> +Date: Nov 2018
> > >> +Contact: linux-pm@vger.kernel.org
> > >> +Description:
> > >> + This entry configures the incoming VBUS voltage limit currently
> > >> + set in the supply. Normally this is configured based on
> > >> + system-level knowledge or user input (e.g. This is part of the
> > >> + Pixel C's thermal management strategy to effectively limit the
> > >> + input power to 5V when the screen is on to meet Google's skin
> > >> + temperature targets). Note that this feature should not be
> > >> + used for safety critical things.
--
(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 --]
prev parent reply other threads:[~2019-01-08 18:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 12:09 [PATCH v3 1/2] power: supply: add input voltage limit property Enric Balletbo i Serra
2018-12-13 12:09 ` [PATCH v3 2/2] power: supply: cros: allow to set input voltage and current limit Enric Balletbo i Serra
2018-12-13 14:39 ` Guenter Roeck
2018-12-13 14:13 ` [PATCH v3 1/2] power: supply: add input voltage limit property Adam Thomson
2018-12-13 22:20 ` Pavel Machek
2018-12-18 16:31 ` Enric Balletbo i Serra
2019-01-08 17:19 ` Enric Balletbo Serra
2019-01-08 17:39 ` Guenter Roeck
2019-01-08 18:47 ` 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=20190108184714.GA11289@amd \
--to=pavel@ucw.cz \
--cc=Adam.Thomson.Opensource@diasemi.com \
--cc=bleung@chromium.org \
--cc=eballetbo@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.