devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: marius.cristea@microchip.com, jic23@kernel.org, lars@metafoo.de,
	robh+dt@kernel.org, jdelvare@suse.com, linux@roeck-us.net,
	linux-hwmon@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org,
	conor+dt@kernel.org, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: iio: adc: adding support for PAC193X
Date: Thu, 16 Nov 2023 18:21:33 +0000	[thread overview]
Message-ID: <20231116-channel-variety-cc7c262924ad@squawk> (raw)
In-Reply-To: <fedd4bcf-7892-4096-bcca-7ea72d39576f@linaro.org>

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

On Thu, Nov 16, 2023 at 04:01:43PM +0100, Krzysztof Kozlowski wrote:
> On 15/11/2023 14:44, marius.cristea@microchip.com wrote:
> > From: Marius Cristea <marius.cristea@microchip.com>
> > 
> > This is the device tree schema for iio driver for
> > Microchip PAC193X series of Power Monitors with Accumulator.
> > 
> > Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
> > ---
> >  .../bindings/iio/adc/microchip,pac1934.yaml   | 137 ++++++++++++++++++
> >  1 file changed, 137 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml
> > new file mode 100644
> > index 000000000000..2609cb19c377
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/microchip,pac1934.yaml
> > @@ -0,0 +1,137 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/adc/microchip,pac1934.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Microchip PAC1934 Power Monitors with Accumulator
> > +
> > +maintainers:
> > +  - Marius Cristea <marius.cristea@microchip.com>
> > +
> > +description: |
> > +  This device is part of the Microchip family of Power Monitors with Accumulator.
> > +  The datasheet for PAC1931, PAC1932, PAC1933 and PAC1934 can be found here:
> > +    https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/PAC1931-Family-Data-Sheet-DS20005850E.pdf
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - microchip,pac1931
> > +      - microchip,pac1932
> > +      - microchip,pac1933
> > +      - microchip,pac1934
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  "#address-cells":
> > +    const: 1
> > +
> > +  "#size-cells":
> > +    const: 0
> > +
> > +  interrupts:
> > +    maxItems: 1
> > +
> > +  microchip,slow-io:
> > +    type: boolean
> > +    description: |
> > +      A GPIO used to trigger a change is sampling rate (lowering the chip power consumption).
> 
> Use Linux coding style wrapping (as described in Linux Coding style). I
> am not going to tell you numbers because I want you to read the document
> first.
> 
> This is boolean, not GPIO. I don't understand. "A GPIO", so any GPIO or
> some specific? How is this property related to GPIO?
> 
> 
> > +      If configured in SLOW mode, if this pin is forced high, sampling rate is forced to eight
> 
> This pin? This is boolean, not a GPIO. GPIOs are phandles.

I said it on the previous version, but this really seems like it should
be something like "slow-io-gpios". I know Jonathan expressed some
concerns about having to deal with it on the operating system side (as
the pin is either an input & used for this slow-io control, or an output
and used as an interrupt) but that is, in my opinion, a problem for the
operating system & the binding should describe how the hardware works,
even if that is not convenient. With this sort of property, a GPIO hog
would be required to be set up (and the driver for that gpio controller
bound etc before the pac driver loads) for correction functionality if
this property was in the non-default state.

> > +      samples/second. When it is forced low, the sampling rate is 1024 samples/second unless
> > +      a different sample rate has been programmed.
> > +
> > +patternProperties:
> > +  "^channel@[1-4]+$":
> > +    type: object
> > +    $ref: adc.yaml
> > +    description: Represents the external channels which are connected to the ADC.
> > +
> > +    properties:
> > +      reg:
> > +        items:
> > +          minimum: 1
> > +          maximum: 4
> > +
> > +      shunt-resistor-micro-ohms:
> > +        description: |
> > +          Value in micro Ohms of the shunt resistor connected between
> > +          the SENSE+ and SENSE- inputs, across which the current is measured. Value
> > +          is needed to compute the scaling of the measured current.
> > +
> > +    required:
> > +      - reg
> > +      - shunt-resistor-micro-ohms
> > +
> > +    unevaluatedProperties: false
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - "#address-cells"
> > +  - "#size-cells"
> > +
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: interrupts
> 
> 
> I don't understand what do you want to say here. I am also 100% sure you
> did not test it on a real case (maybe example passes but nothing more).

As far as I understand, the same pin on the device is used for both an
output or an input depending on the configuration. As an input, it is
the "slow-io" control, and as an output it is an interrupt.
I think Marius is trying to convey that either this pin can be in
exclusively one state or another.

_However_ I am not sure that that is really the right thing to do - they
might well be mutually exclusive modes, but I think the decision can be
made at runtime, rather than at devicetree creation time. Say for
example the GPIO controller this is connected to is capable of acting as
an interrupt controller. Unless I am misunderstanding the runtime
configurability of this hardware, I think it is possible to actually
provide a "slow-io-gpios" and an interrupt property & let the operating
system decide at runtime which mode it wants to work in.

I'm off travelling at the moment Marius, but I should be back in work on
Monday if you want to have a chat about it & explain a bit more to me?

Cheers,
Conor.

> 
> > +    then:
> > +      properties:
> > +        microchip,slow-io: false
> > +    else:
> > +      if:
> > +        properties:
> > +          compatible:
> > +            contains:
> > +              const: microchip,slow-io
> > +      then:
> > +        properties:
> > +          interrupts: false
> 
> Best regards,
> Krzysztof
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-11-16 18:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-15 13:44 [PATCH v3 0/2] adding support for Microchip PAC193X Power Monitor marius.cristea
2023-11-15 13:44 ` [PATCH v3 1/2] dt-bindings: iio: adc: adding support for PAC193X marius.cristea
2023-11-16 15:01   ` Krzysztof Kozlowski
2023-11-16 18:21     ` Conor Dooley [this message]
2023-11-16 20:00       ` Krzysztof Kozlowski
2023-11-16 21:31         ` Conor Dooley
2023-11-25 19:47       ` Jonathan Cameron
2023-11-26 11:24         ` Conor Dooley
2023-11-26 16:04           ` Jonathan Cameron
2023-11-30 15:53             ` Conor Dooley
2023-11-15 13:44 ` [PATCH v3 2/2] iio: adc: adding support for PAC193x marius.cristea
2023-11-21 15:56   ` kernel test robot
2023-11-25 20:37   ` Jonathan Cameron
2023-11-15 19:38 ` [PATCH v3 0/2] adding support for Microchip PAC193X Power Monitor Guenter Roeck

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=20231116-channel-variety-cc7c262924ad@squawk \
    --to=conor@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=jic23@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=marius.cristea@microchip.com \
    --cc=robh+dt@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).