All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	linux-pm@vger.kernel.org, Sameer Nanda <snanda@chromium.org>,
	bleung@chromium.org, rjw@rjwysocki.net, gwendal@chromium.org,
	linux-kernel@vger.kernel.org, Len Brown <len.brown@intel.com>,
	groeck@chromium.org, Adam.Thomson.Opensource@diasemi.com,
	kernel@collabora.com
Subject: Re: [RESEND PATCH v3 1/2] power: supply: add input voltage limit property
Date: Thu, 2 May 2019 23:12:52 +0200	[thread overview]
Message-ID: <20190502211252.GA19144@amd> (raw)
In-Reply-To: <20190502210138.ekrjvg4jex5x2tbo@earth.universe>

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

Hi!

> On Tue, Apr 16, 2019 at 10:42:30AM +0200, Enric Balletbo i Serra wrote:
> > On 16/4/19 9:19, Pavel Machek wrote:
> > >> 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.
> > > 
> > > Well, and I suspect it should expose input power limit, not input
> > > voltage limit.
> > 
> > Oh, ok, I thought we were agree that input voltage had sense after had some
> > discussion in v3. Seems that no, let me try to give you another example...
> > 
> > > DC-DC convertor efficiency normally does not much depend on input
> > > voltage....
> > 
> > As we said we have a heat "problem" due the internal voltage conversions.
> > 
> > Lets assume you have a linear regulator instead with a Vin range from 5V to 9V
> > and we want an output of 3.3V/1A
> >
> > For 9V:
> >  Input power : P(in) = 9V x 1A = 9W
> >  Output power: P(out) = 3.3V x 1A = 3.3W
> >  Regulator power dissipated: P(reg) = P(in) - P(out) = 9W - 3.3W = 5.7W
> > 
> > For 5V:
> >  Input power : P(in) = 5V x 1A = 5W
> >  Output power: P(out) = 3.3V x 1A = 3.3W
> >  Regulator power dissipated: P(reg) = P(in) - P(out) = 5W - 3.3W = 1,7W
> > 
> > In the first case the regulator needs to dissipate more power, hence the
> > temperature is greater than the second case.
> 
> I would be surprised, if a linear regulator is being used in this
> place :) That would basically render functionality of higher voltage
> completley useless and a good reason to always limit to 5V. For the
> generic case I agree with Pavel, that control over the power (voltage
> * current) is the better choice. Still I believe it makes sense to
> have a control knob for the voltage available, since some hardware
> designs suck.
> 
> For example the bad hardware design might be the remote side,
> that has issues providing some voltages and this would make it
> possible to debug that.

Ok, I agree it might be useful _somewhere_, mostly for hardware
debugging. But before if we add voltage_limit, lets add power_limit,
too; and for problems that can be solved using power_limit, lets use
power_limit...

Best regards,
									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 --]

      reply	other threads:[~2019-05-02 21:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15 22:00 [RESEND PATCH v3 1/2] power: supply: add input voltage limit property Enric Balletbo i Serra
2019-04-15 22:00 ` [RESEND PATCH v3 2/2] power: supply: cros: allow to set input voltage and current limit Enric Balletbo i Serra
2019-04-16  7:19 ` [RESEND PATCH v3 1/2] power: supply: add input voltage limit property Pavel Machek
2019-04-16  8:42   ` Enric Balletbo i Serra
2019-05-02 21:01     ` Sebastian Reichel
2019-05-02 21:12       ` 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=20190502211252.GA19144@amd \
    --to=pavel@ucw.cz \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=bleung@chromium.org \
    --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=sebastian.reichel@collabora.com \
    --cc=snanda@chromium.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.