From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Quentin Schulz <quentin.schulz@free-electrons.com>
Cc: Jonathan Cameron <jic23@kernel.org>, <sre@kernel.org>,
<robh+dt@kernel.org>, <mark.rutland@arm.com>, <wens@csie.org>,
<linux@armlinux.org.uk>, <maxime.ripard@free-electrons.com>,
<lee.jones@linaro.org>, <knaack.h@gmx.de>, <lars@metafoo.de>,
<pmeerw@pmeerw.net>, <linux-pm@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-iio@vger.kernel.org>, <icenowy@aosc.io>,
<linux-sunxi@googlegroups.com>,
<thomas.petazzoni@free-electrons.com>
Subject: Re: [PATCH 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC
Date: Tue, 12 Dec 2017 15:12:32 +0000 [thread overview]
Message-ID: <20171212151232.00006fd0@huawei.com> (raw)
In-Reply-To: <b2cdd796-5c22-c114-bc74-41b900a05464@free-electrons.com>
On Mon, 11 Dec 2017 09:18:55 +0100
Quentin Schulz <quentin.schulz@free-electrons.com> wrote:
> Hi Jonathan,
>
> On 10/12/2017 17:36, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:48 +0100
> > Quentin Schulz <quentin.schulz@free-electrons.com> wrote:
> >
> >> The X-Powers AXP813 PMIC is really close to what is already done for
> >> AXP20X/AXP22X.
> >>
> >> There are two pairs of bits to set the rate (one for Voltage and Current
> >> measurements and one for TS/GPIO0 voltage measurements) instead of one.
> >
> > This would normally imply we need to split the device into two logical
> > IIO devices. However, that only becomes relevant if we are using
> > buffered output which this driver doesn't support.
> > > It'll be nasty to deal with this if we add that support down the line
> > though. Up to you though as it's more likely to be your problem than
> > anyone else's :)
> >
>
> I have no plans for supporting buffered output for the AXPs at the
> moment. But that's an interesting (and important) limitation to raise.
> Wouldn't be more of a hack to have two IIO devices representing the
> actual same IP?
We have thought about allowing multiple buffers from a single IIO device
but that makes for some horrible changes to the ABI - so as things stand
the only option is two devices for one IP. Ultimately they aren't really
two devices - in the same way we have triggers separating registered on
the IIO bus (often many of them). Just two different elements of the same IP.
>
> > For now you could elect to support the different sampling frequencies
> > if you wanted to but just providing controls for each channel.
> >
>
> I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in
> info_mask_separate for each channel?
Yes
>
> > Given the driver doesn't currently expose these at all (I think)
> > this is all rather immaterial ;)
>
> I'm not giving the user the option to chose the sampling frequency for
> now. I have no plans to do it either, but I think it would be rather
> simple to later add support for setting frequency sampling since we only
> need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not
> exist yet. Don't you think? Am I missing something?
No should be straight forward as long as we keep clear of the buffered
interfaces with their limitations.
>
> Thanks,
> Quentin
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
wens-jdAy2FN1RRM@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
knaack.h-Mmb7MZpHnFY@public.gmane.org,
lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org,
pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
icenowy-h8G6r0blFSE@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org
Subject: Re: [PATCH 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC
Date: Tue, 12 Dec 2017 15:12:32 +0000 [thread overview]
Message-ID: <20171212151232.00006fd0@huawei.com> (raw)
In-Reply-To: <b2cdd796-5c22-c114-bc74-41b900a05464-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 11 Dec 2017 09:18:55 +0100
Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Jonathan,
>
> On 10/12/2017 17:36, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:48 +0100
> > Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >
> >> The X-Powers AXP813 PMIC is really close to what is already done for
> >> AXP20X/AXP22X.
> >>
> >> There are two pairs of bits to set the rate (one for Voltage and Current
> >> measurements and one for TS/GPIO0 voltage measurements) instead of one.
> >
> > This would normally imply we need to split the device into two logical
> > IIO devices. However, that only becomes relevant if we are using
> > buffered output which this driver doesn't support.
> > > It'll be nasty to deal with this if we add that support down the line
> > though. Up to you though as it's more likely to be your problem than
> > anyone else's :)
> >
>
> I have no plans for supporting buffered output for the AXPs at the
> moment. But that's an interesting (and important) limitation to raise.
> Wouldn't be more of a hack to have two IIO devices representing the
> actual same IP?
We have thought about allowing multiple buffers from a single IIO device
but that makes for some horrible changes to the ABI - so as things stand
the only option is two devices for one IP. Ultimately they aren't really
two devices - in the same way we have triggers separating registered on
the IIO bus (often many of them). Just two different elements of the same IP.
>
> > For now you could elect to support the different sampling frequencies
> > if you wanted to but just providing controls for each channel.
> >
>
> I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in
> info_mask_separate for each channel?
Yes
>
> > Given the driver doesn't currently expose these at all (I think)
> > this is all rather immaterial ;)
>
> I'm not giving the user the option to chose the sampling frequency for
> now. I have no plans to do it either, but I think it would be rather
> simple to later add support for setting frequency sampling since we only
> need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not
> exist yet. Don't you think? Am I missing something?
No should be straight forward as long as we keep clear of the buffered
interfaces with their limitations.
>
> Thanks,
> Quentin
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan.Cameron@huawei.com (Jonathan Cameron)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC
Date: Tue, 12 Dec 2017 15:12:32 +0000 [thread overview]
Message-ID: <20171212151232.00006fd0@huawei.com> (raw)
In-Reply-To: <b2cdd796-5c22-c114-bc74-41b900a05464@free-electrons.com>
On Mon, 11 Dec 2017 09:18:55 +0100
Quentin Schulz <quentin.schulz@free-electrons.com> wrote:
> Hi Jonathan,
>
> On 10/12/2017 17:36, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:48 +0100
> > Quentin Schulz <quentin.schulz@free-electrons.com> wrote:
> >
> >> The X-Powers AXP813 PMIC is really close to what is already done for
> >> AXP20X/AXP22X.
> >>
> >> There are two pairs of bits to set the rate (one for Voltage and Current
> >> measurements and one for TS/GPIO0 voltage measurements) instead of one.
> >
> > This would normally imply we need to split the device into two logical
> > IIO devices. However, that only becomes relevant if we are using
> > buffered output which this driver doesn't support.
> > > It'll be nasty to deal with this if we add that support down the line
> > though. Up to you though as it's more likely to be your problem than
> > anyone else's :)
> >
>
> I have no plans for supporting buffered output for the AXPs at the
> moment. But that's an interesting (and important) limitation to raise.
> Wouldn't be more of a hack to have two IIO devices representing the
> actual same IP?
We have thought about allowing multiple buffers from a single IIO device
but that makes for some horrible changes to the ABI - so as things stand
the only option is two devices for one IP. Ultimately they aren't really
two devices - in the same way we have triggers separating registered on
the IIO bus (often many of them). Just two different elements of the same IP.
>
> > For now you could elect to support the different sampling frequencies
> > if you wanted to but just providing controls for each channel.
> >
>
> I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in
> info_mask_separate for each channel?
Yes
>
> > Given the driver doesn't currently expose these at all (I think)
> > this is all rather immaterial ;)
>
> I'm not giving the user the option to chose the sampling frequency for
> now. I have no plans to do it either, but I think it would be rather
> simple to later add support for setting frequency sampling since we only
> need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not
> exist yet. Don't you think? Am I missing something?
No should be straight forward as long as we keep clear of the buffered
interfaces with their limitations.
>
> Thanks,
> Quentin
next prev parent reply other threads:[~2017-12-12 15:12 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 14:12 [PATCH 0/8] add support for AXP813 ADC and battery power supply Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` [PATCH 1/8] iio: adc: axp20x_adc: put ADC rate setting in a per-variant function Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-05 3:35 ` [linux-sunxi] " Chen-Yu Tsai
2017-12-05 3:35 ` Chen-Yu Tsai
2017-12-10 16:37 ` Jonathan Cameron
2017-12-10 16:37 ` Jonathan Cameron
2017-12-10 16:37 ` Jonathan Cameron
2017-12-04 14:12 ` [PATCH 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-10 16:36 ` Jonathan Cameron
2017-12-10 16:36 ` Jonathan Cameron
2017-12-10 16:36 ` Jonathan Cameron
2017-12-11 8:18 ` Quentin Schulz
2017-12-11 8:18 ` Quentin Schulz
2017-12-11 8:18 ` Quentin Schulz
2017-12-12 15:12 ` Jonathan Cameron [this message]
2017-12-12 15:12 ` Jonathan Cameron
2017-12-12 15:12 ` Jonathan Cameron
2017-12-04 14:12 ` [PATCH 3/8] mfd: axp20x: probe axp20x_adc driver for AXP813 Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-05 8:08 ` Maxime Ripard
2017-12-05 8:08 ` Maxime Ripard
2017-12-05 8:08 ` Maxime Ripard
2017-12-07 8:51 ` Quentin Schulz
2017-12-07 8:51 ` Quentin Schulz
2017-12-07 8:51 ` Quentin Schulz
2017-12-07 8:54 ` Chen-Yu Tsai
2017-12-07 8:54 ` Chen-Yu Tsai
2017-12-07 8:54 ` Chen-Yu Tsai
2017-12-07 9:03 ` Quentin Schulz
2017-12-07 9:03 ` Quentin Schulz
2017-12-07 9:03 ` Quentin Schulz
2017-12-07 9:14 ` Chen-Yu Tsai
2017-12-07 9:14 ` Chen-Yu Tsai
2017-12-07 9:14 ` Chen-Yu Tsai
2017-12-10 16:40 ` Jonathan Cameron
2017-12-10 16:40 ` Jonathan Cameron
2017-12-04 14:12 ` [PATCH 4/8] dt-bindings: power: supply: axp20x: add AXP813 battery DT binding Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-06 21:16 ` Rob Herring
2017-12-06 21:16 ` Rob Herring
2017-12-06 21:16 ` Rob Herring
2017-12-10 16:44 ` Jonathan Cameron
2017-12-10 16:44 ` Jonathan Cameron
2017-12-10 16:44 ` Jonathan Cameron
2017-12-04 14:12 ` [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813 Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-10 16:49 ` Jonathan Cameron
2017-12-10 16:49 ` Jonathan Cameron
2017-12-10 16:49 ` Jonathan Cameron
2017-12-11 8:35 ` Quentin Schulz
2017-12-11 8:35 ` Quentin Schulz
2017-12-11 8:35 ` Quentin Schulz
2017-12-12 19:55 ` Jonathan Cameron
2017-12-12 19:55 ` Jonathan Cameron
2017-12-12 19:55 ` Jonathan Cameron
2017-12-04 14:12 ` [PATCH 6/8] mfd: axp20x: add battery power supply cell " Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-05 8:24 ` Lee Jones
2017-12-05 8:24 ` Lee Jones
2017-12-05 8:24 ` Lee Jones
2017-12-04 14:12 ` [PATCH 7/8] ARM: dtsi: axp81x: add battery power supply subnode Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` [PATCH 8/8] ARM: dtsi: sun8i: a711: enable " Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
2017-12-04 14:12 ` Quentin Schulz
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=20171212151232.00006fd0@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=devicetree@vger.kernel.org \
--cc=icenowy@aosc.io \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@free-electrons.com \
--cc=pmeerw@pmeerw.net \
--cc=quentin.schulz@free-electrons.com \
--cc=robh+dt@kernel.org \
--cc=sre@kernel.org \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wens@csie.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.