Re: [PATCH v2 10/11] dt-bindings: misc: add bindings for cros_ec_throttler

[Matthias Kaehlcke]

On Tue, Jun 12, 2018 at 01:40:22PM -0700, Brian Norris wrote:
> 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@xxxxxxxxxxxx>
> > > ---
> > > 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.

I also think we need to clarify if this is the right direction. Since
Rob proposed the OPP hints and didn't object when I replied with the
opp-throttlers example I assumed he was ok with it.