lkml.org 
[lkml]   [2018]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 10/11] dt-bindings: misc: add bindings for cros_ec_throttler
    Hi Rob,

    On Tue, Jun 12, 2018 at 01:10:11PM -0600, Rob Herring wrote:
    > On Thu, Jun 07, 2018 at 11:12:13AM -0700, Matthias Kaehlcke wrote:
    > > The cros_ec_throttler monitors events from the Chrome OS Embedded
    > > Controller to throttle the system if needed, using the mechanisms
    > > provided by the throttler core.
    > >
    > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
    > > ---
    > > Changes in v2:
    > > - patch added to series
    > >
    > > Documentation/devicetree/bindings/misc/cros_ec_throttler.txt | 4 ++++
    > > 1 file changed, 4 insertions(+)
    > > create mode 100644 Documentation/devicetree/bindings/misc/cros_ec_throttler.txt
    > >
    > > diff --git a/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt b/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt
    > > new file mode 100644
    > > index 000000000000..7316dcc0ef75
    > > --- /dev/null
    > > +++ b/Documentation/devicetree/bindings/misc/cros_ec_throttler.txt
    > > @@ -0,0 +1,4 @@
    > > +* cros_ec_throttler driver
    >
    > Bindings are for h/w, not drivers.

    (OK, sure, don't call this "driver". And maybe this could use some more
    description about what kind of events are emitted by this sort of
    device.)

    > I continue to fail to see why this needs to be in DT. There are other
    > ways to instantiate drivers.

    This is mostly relevant to:
    [PATCH v2 08/11] dt-bindings: PM / OPP: add opp-throttlers property

    so it's probably good to take a look at that one too.

    The primary purpose is to have a target to point at when determining who
    is the source of throttling. This is similar to other CrOS EC subdevices
    (e.g., PWM) where we technically don't require a subnode (the EC
    firmware can its own PWM hardware without DT), but it is important that,
    e.g., a backlight device has something to point at when it's using a PWM
    attached to the EC. So we have a PWM subnode.

    In this case, we're a little vague about what exactly the hardware is
    here, but there *is* hardware that's emitting "throttle" events (hint:
    here, it's related to sensing too high of system current). This is all
    abstracted by firmware, which simply tells us we need to scale back our
    power usage.

    So, what do you think of patch 8? Should OPPs have phandles to such a
    throttler? If so, should the phandle just point at the main EC device
    (see mfd/cros-ec.txt), or is it reasonable to have a subnode to
    represent something more specific?

    Or maybe this is entirely on the wrong track. But this is the resulting
    proposal after your comments on v1, so it's probably best we have a
    clearer overall review of what makes sense here, so we don't just go in
    cycles on new proposals that get rejected.

    Brian

    > > +
    > > +Required properties:
    > > +- compatible: "google,cros-ec-throttler"
    > > --
    > > 2.18.0.rc1.242.g61856ae69a-goog
    > >

    \
     
     \ /
      Last update: 2018-06-12 22:41    [W:3.966 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site