From: Song Qiang <songqiang1304521@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
robh+dt@kernel.org, mark.rutland@arm.com,
preid@electromag.com.au, himanshujha199640@gmail.com,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] iio: magnetometer: Add driver support for PNI RM3100
Date: Thu, 18 Oct 2018 16:24:15 +0800 [thread overview]
Message-ID: <e1715942-8fd8-152f-49c8-2a9e081d8a2a@gmail.com> (raw)
In-Reply-To: <20181013111935.00a2e1af@archlinux>
On 2018/10/13 下午6:19, Jonathan Cameron wrote:
> On Fri, 12 Oct 2018 15:35:36 +0800
> Song Qiang<songqiang1304521@gmail.com> wrote:
>
>> PNI RM3100 is a high resolution, large signal immunity magnetometer,
>> composed of 3 single sensors and a processing chip with a MagI2C
>> interface.
>>
>> Following functions are available:
>> - Single-shot measurement from
>> /sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
>> - Triggerd buffer measurement.
>> - DRDY pin for data ready trigger.
>> - Both i2c and spi interface are supported.
>> - Both interrupt and polling measurement is supported, depends on if
>> the 'interrupts' in DT is declared.
>>
>> Signed-off-by: Song Qiang<songqiang1304521@gmail.com>
> A few questions for you (getting very close to being good to go btw!)
>
> Why do we have the 3second additional wait for conversions? I know we
> rarely wait that long, but still seems excessive.
>
> Few more comments inline.
>
> Thanks,
>
> Jonathan
Hi Jonathan,
The measurement time of this device varies from 1.7ms to 13 seconds, 3 seconds
is just a number in the middle between them. This may be worth discussing,
hoping to get a better solution from the community.
>> ---
>> MAINTAINERS | 7 +
>> drivers/iio/magnetometer/Kconfig | 29 ++
>> drivers/iio/magnetometer/Makefile | 4 +
>> drivers/iio/magnetometer/rm3100-core.c | 627 +++++++++++++++++++++++++
>> drivers/iio/magnetometer/rm3100-i2c.c | 58 +++
>> drivers/iio/magnetometer/rm3100-spi.c | 64 +++
>> drivers/iio/magnetometer/rm3100.h | 17 +
>> 7 files changed, 806 insertions(+)
>> create mode 100644 drivers/iio/magnetometer/rm3100-core.c
>> create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
>> create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
>> create mode 100644 drivers/iio/magnetometer/rm3100.h
>>
...
>
>> +static irqreturn_t rm3100_trigger_handler(int irq, void *p)
>> +{
>> + struct iio_poll_func *pf = p;
>> + struct iio_dev *indio_dev = pf->indio_dev;
>> + unsigned long scan_mask = *indio_dev->active_scan_mask;
>> + unsigned int mask_len = indio_dev->masklength;
>> + struct rm3100_data *data = iio_priv(indio_dev);
>> + struct regmap *regmap = data->regmap;
>> + int ret, i, bit;
>> +
>> + mutex_lock(&data->lock);
>> + switch (scan_mask) {
>> + case BIT(0) | BIT(1) | BIT(2):
>> + ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 9);
>> + mutex_unlock(&data->lock);
>> + if (ret < 0)
>> + goto done;
>> + break;
>> + case BIT(0) | BIT(1):
>> + ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 6);
>> + mutex_unlock(&data->lock);
>> + if (ret < 0)
>> + goto done;
>> + break;
>> + case BIT(1) | BIT(2):
>> + ret = regmap_bulk_read(regmap, RM3100_REG_MY2, data->buffer, 6);
>> + mutex_unlock(&data->lock);
>> + if (ret < 0)
>> + goto done;
>> + break;
> What about BIT(0) | BIT(2)?
>
> Now you can do it like you have here and on that one corner case let the iio core
> demux code take care of it, but then you will need to provide available_scan_masks
> so the core knows it needs to handle this case.
>
This confused me a little. The available_scan_masks I was using is {BIT(0) |
BIT(1) | BIT(2), 0x0}. Apparently in this version of patch I would like it to
handle every circumstances like BIT(0), BIT(0) | BIT(2), BIT(1) | BIT(2), etc.
Since Phil mentioned he would like this to reduce bus usage as much as we can
and I want it, too, I think these three circumstances can be read consecutively
while others can be read one axis at a time. So I plan to let BIT(0) | BIT(2)
fall into the 'default' section, which reads axis one by one.
My question is, since this handles every possible combination, do I still need
to list every available scan masks in available_scan_masks?
All other problems will be fixed in the next patch.
yours,
Song Qiang
...
next prev parent reply other threads:[~2018-10-18 8:24 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 3:17 [PATCH 1/2] iio: magnetometer: Add DT support for PNI RM3100 Song Qiang
2018-09-25 3:17 ` [PATCH 2/2] iio: magnetometer: Add driver " Song Qiang
2018-09-25 13:30 ` Jonathan Cameron
2018-09-25 14:36 ` Phil Reid
2018-09-26 1:49 ` Song Qiang
2018-09-26 2:30 ` Phil Reid
2018-09-26 8:09 ` Song Qiang
2018-09-27 1:57 ` Phil Reid
2018-09-29 11:37 ` Jonathan Cameron
2018-09-26 1:33 ` Song Qiang
2018-09-29 11:45 ` Jonathan Cameron
2018-09-25 17:50 ` Himanshu Jha
2018-09-26 2:24 ` Song Qiang
2018-09-25 13:05 ` [PATCH 1/2] iio: magnetometer: Add DT " Jonathan Cameron
2018-10-02 14:38 ` [PATCH v3 0/3] Add support for PNI RM3100 magnetometer Song Qiang
2018-10-02 14:38 ` [PATCH v3 1/3] dt-bindings: Add PNI to the vendor prefixes Song Qiang
2018-10-02 14:38 ` [PATCH v3 2/3] dt-bindings: Add PNI RM3100 device tree binding Song Qiang
2018-10-07 15:18 ` Jonathan Cameron
2018-10-07 15:20 ` Jonathan Cameron
2018-10-02 14:38 ` [PATCH v3 3/3] iio: magnetometer: Add driver support for PNI RM3100 Song Qiang
2018-10-03 1:42 ` Phil Reid
2018-10-07 15:07 ` Jonathan Cameron
2018-10-07 15:44 ` Jonathan Cameron
2018-10-11 4:35 ` Song Qiang
2018-10-13 9:24 ` Jonathan Cameron
2018-10-12 7:35 ` [PATCH v4 0/3] Add support for PNI RM3100 magnetometer Song Qiang
2018-10-12 7:35 ` [PATCH v4 1/3] dt-bindings: Add PNI to the vendor prefixes Song Qiang
2018-10-12 11:36 ` Rob Herring
2018-10-12 7:35 ` [PATCH v4 2/3] iio: magnetometer: Add DT support for PNI RM3100 Song Qiang
2018-10-12 11:37 ` Rob Herring
2018-10-12 7:35 ` [PATCH v4 3/3] iio: magnetometer: Add driver " Song Qiang
2018-10-12 8:36 ` Song Qiang
2018-10-12 12:53 ` Himanshu Jha
2018-10-17 8:00 ` Song Qiang
2018-10-21 14:08 ` Jonathan Cameron
2018-10-13 10:19 ` Jonathan Cameron
2018-10-18 8:24 ` Song Qiang [this message]
2018-10-21 14:14 ` Jonathan Cameron
2018-11-02 7:55 ` Song Qiang
2018-11-02 9:24 ` Jonathan Cameron
2018-11-05 0:39 ` Song Qiang
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=e1715942-8fd8-152f-49c8-2a9e081d8a2a@gmail.com \
--to=songqiang1304521@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=himanshujha199640@gmail.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pmeerw@pmeerw.net \
--cc=preid@electromag.com.au \
--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).