From: Jonathan Cameron <jic23@kernel.org>
To: <Marius.Cristea@microchip.com>
Cc: <conor@kernel.org>, <robh+dt@kernel.org>, <conor+dt@kernel.org>,
<devicetree@vger.kernel.org>, <lars@metafoo.de>,
<linux-iio@vger.kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: adc: adding dt-bindings for PAC193X
Date: Mon, 4 Dec 2023 09:41:57 +0000 [thread overview]
Message-ID: <20231204094157.775f604e@jic23-huawei> (raw)
In-Reply-To: <1fb7d32772cb5e76a5f1fd6b8f3b32754f8a9395.camel@microchip.com>
On Tue, 7 Nov 2023 08:55:48 +0000
<Marius.Cristea@microchip.com> wrote:
> Hi
>
> On Fri, 2023-10-27 at 15:26 +0100, Jonathan Cameron wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > On Thu, 26 Oct 2023 17:08:07 +0100
> > Conor Dooley <conor@kernel.org> wrote:
> >
> > > On Thu, Oct 26, 2023 at 03:23:46PM +0000,
> > > Marius.Cristea@microchip.com wrote:
> > > > Hi Conor,
> > > >
> > > > On Wed, 2023-10-25 at 16:08 +0100, Conor Dooley wrote:
> > > > > Hey Marius,
> > > > >
> > > > > On Wed, Oct 25, 2023 at 04:44:03PM +0300,
> > > > > 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.
> > > > > >
> > > > > >
> ......
> > > > > > +
> > > > > > + reg:
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + "#address-cells":
> > > > > > + const: 1
> > > > > > +
> > > > > > + "#size-cells":
> > > > > > + const: 0
> > > > > > +
> > > > > > + interrupts:
> > > > > > + description: IRQ line of the ADC
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + drive-open-drain:
> > > > > > + description: The IRQ signal is configured as open-drain.
> > > > > > + type: boolean
> > > > > > + maxItems: 1
> > > > > > +
> > > > > > + microchip,slow-io:
> > > > > > + type: boolean
> > > > > > + description: |
> > > > > > + A GPIO used to trigger a change is sampling rate
> > > > > > (lowering
> > > > > > the chip power consumption).
> > > > > > + In default mode, if this pin is forced high, sampling
> > > > > > rate
> > > > > > is forced to eight
> > > > > > + samples/second. When it is forced low, the sampling
> > > > > > rate is
> > > > > > 1024 samples/second unless
> > > > > > + a different sample rate has been programmed.
> > > > >
> > > > > This description doesn't really make sense to me - if a GPIO is
> > > > > used
> > > > > to
> > > > > drive the pin low or high, why do we need a property? A DT
> > > > > property
> > > > > implies that this is a static configuration depending on the
> > > > > board,
> > > > > but
> > > > > reading the description this seems to be something that can be
> > > > > toggled
> > > > > at runtime.
> > > > > I do note though, that this GPIO is not documented in the
> > > > > binding, so
> > > > > I
> > > > > suppose what really needs to happen here is document the gpio
> > > > > so that
> > > > > the driver can determine at runtime what state this pin is in?
> > > > >
> > > > > Also, you say "In default mode", but don't mention what the
> > > > > non-
> > > > > default
> > > > > mode is. What happens in the other mode?
> > >
> > > > This is a "double function" pin. On the PAC193x there is the
> > > > SLOW/ALERT
> > > > pin. At runtime this pin could be configured as an input to the
> > > > PAC and
> > > > the functionality will be "SLOW" that means if it is forced high,
> > > > the
> > > > PAC will work in low power mode by changing the sample rate to 8
> > > > SPS.
> > > > If it's forced low the PAC will work at it's full sample rate.
> > >
> > > Since this is a runtime thing, it doesn't make sense to have a
> > > property
> > > that is set at dts creation time that decides what mode the pin is
> > > in.
> > >
> > > > "SLOW" is the default function of the pin but it may be
> > > > programmed to
> > > > function as ALERT pin (Open Collector when functioning as ALERT,
> > > > requires pull-up resistor to VDD I/O). This time the pin will be
> > > > set as
> > > > output from PAC (ALERT functionality) to trigger an interrupt to
> > > > the
> > > > system (this is covered by the interrupts and drive-open-drain).
> > >
> > > Hmm, at the risk of getting out of my depth with what the GPIO
> > > subsystem
> > > is capable of doing, I would expect to see something like
> > >
> > > sampling-rate-gpios:
> > > description:
> > > <what you have above>
> > > maxItems: 1
> > >
> > > Which would allow the driver to either drive this pin via the gpio
> > > subsystem, or to use the interrupt property to use it as an
> > > interrupt
> > > instead.
> > >
> > > Perhaps Jonathan etc knows better for these sort of dual mode pins.
> >
> > Beyond them being a pain? The fun is they may get wired to interrupt
> > controllers that are also GPIOs or they may not (and the other way
> > around
> > with them wired to GPIO pins that aren't interrupt pins).
> >
> > I don't understand the usecase for the SLOW control.
> > Given it seems software can override the use for SLOW I'd be tempted
> > to
> > always do that.
> > Thus making this pin useable only as an optional interrupt.
> >
> > If someone hard wires it to high or low that is harmless if we aren't
> > letting it control anything.
> >
>
> Here I was trying to define/describe 3 possible situations:
> - 1) the pin is not used at all, so it doesn't matter if it's connected
> somewhere
>
> - 2) the pin is user configured as "interrupt" and it's connected to
> the interrupt controller (this case is not supported in the driver
> right now)
>
> - 3) the pin is user configured as "SLOW" (this case is not supported
> in the driver right now). That means it should be connected to a GPIO
> pin. This function (SLOW control) will automatically change the PAC
> internal sampling frequency to lower the PAC internal power
> consumption. For example, the PAC could be configured to a sample rate
> of 1024 samples/s (it will consume maximum current). Using the SLOW
> control, the chip will internally change to 8 samples/s but the math
> internally will "behave" as the 1024 samples/s but at a much lower
> power consumption. It's very useful in case the system wants to lower
> power consumption (we still need to measure battery power consumption
> even if the system is put into a low power state). PAC internal power
> consumption is proportional to the number of channels used and also the
> sampling frequency.
So far so good, but how does 3 differ from just setting the chip to sample
at 8 samples/s, which I believe we can do from software?
Anyhow, for a DT binding, provide both gpio and interrupt as optional
and the driver can make up it's mind on what to do if both are provided.
Jonathan
>
>
>
> > >
> > > > The system could work fine without this pin. The driver doesn't
> > > > use
> > > > interrupt at this time, but it could be extended.
> > >
> > > Cheers,
> > > Conor.
> >
>
> Thanks,
> Marius
next prev parent reply other threads:[~2023-12-04 9:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 13:44 [PATCH v2 0/2] adding support for Microchip PAC193X Power Monitor marius.cristea
2023-10-25 13:44 ` [PATCH v2 1/2] dt-bindings: iio: adc: adding dt-bindings for PAC193X marius.cristea
2023-10-25 15:08 ` Conor Dooley
2023-10-26 15:23 ` Marius.Cristea
2023-10-26 16:08 ` Conor Dooley
[not found] ` <20231027152625.44b26d80@jic23-huawei>
2023-11-07 8:55 ` Marius.Cristea
2023-12-04 9:41 ` Jonathan Cameron [this message]
2023-11-10 16:27 ` Marius.Cristea
2023-12-04 9:43 ` Jonathan Cameron
2023-10-27 12:13 ` Krzysztof Kozlowski
2023-10-25 13:44 ` [PATCH v2 2/2] iio: adc: adding support for pac193x marius.cristea
2023-10-25 14:38 ` Nuno Sá
2023-10-26 15:03 ` Marius.Cristea
2023-10-27 8:40 ` Nuno Sá
2023-10-25 17:23 ` kernel test robot
2023-10-27 12:20 ` Krzysztof Kozlowski
[not found] ` <20231027161813.7bff8866@jic23-huawei>
2023-11-02 14:28 ` Robin Getz
2023-11-07 12:55 ` Marius.Cristea
2023-11-07 15:39 ` Robin Getz
2023-10-27 12:10 ` [PATCH v2 0/2] adding support for Microchip PAC193X Power Monitor Krzysztof Kozlowski
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=20231204094157.775f604e@jic23-huawei \
--to=jic23@kernel.org \
--cc=Marius.Cristea@microchip.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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