From: Song Qiang <songqiang1304521@gmail.com>
To: Himanshu Jha <himanshujha199640@gmail.com>
Cc: jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de,
pmeerw@pmeerw.net, robh+dt@kernel.org, mark.rutland@arm.com,
preid@electromag.com.au, rtresidd@electromag.com.au,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100
Date: Wed, 26 Sep 2018 10:24:27 +0800 [thread overview]
Message-ID: <20180926022427.GA7447@Eros> (raw)
In-Reply-To: <20180925175018.GA5643@himanshu-Vostro-3559>
On Tue, Sep 25, 2018 at 11:20:18PM +0530, Himanshu Jha wrote:
> On Tue, Sep 25, 2018 at 11:17:24AM +0800, Song Qiang wrote:
> > PNI RM3100 is a high resolution, large signal immunity magnetometer,
> > composed of 3 single sensors and a processing chip with MagI2C Interface.
> >
> > Following functions are available:
> > - Single-shot measurement from
> > /sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
> > - Triggerd buffer measurement.
> > - Both i2c and spi interface are supported.
> > - Both interrupt and polling measurement is supported, depands on if
> depends
>
...
> +
> > +static int rm3100_wait_measurement(struct rm3100_data *data)
> > +{
> > + struct regmap *regmap = data->regmap;
> > + unsigned int val;
> > + int tries = 20;
> > + int ret;
> > +
> > + /*
> > + * A read cycle of 400kbits i2c; bus is about 20us, plus the time
> ; was mistakenly added ?
>
Hi Himanshu,
Oops, it shouldn't be there.
> > + * used for scheduling, a read cycle of fast mode of this device
> > + * can reach 1.7ms, it may be possible for data to arrive just
> > + * after we check the RM3100_REG_STATUS. In this case, irq_handler is
> > + * called before measuring_done is reinitialized, it will wait
> > + * forever for data that has already been ready.
> > + * Reinitialize measuring_done before looking up makes sure we
> > + * will always capture interrupt no matter when it happened.
> > + */
> > + if (data->use_interrupt)
> > + reinit_completion(&data->measuring_done);
> > +
...
> > +static const struct attribute_group rm3100_attribute_group = {
> > + .attrs = rm3100_attributes,
> > +};
> > +
> > +#define RM3100_SAMP_NUM 14
>
> Move this to top or .h header file.
>
I could have move it to the top, but the only related section is
here. It only changes if a new frequency is supported, which seems
not possible from now. Just here to tell the readers how many
frequencies are in the array. So if one day a new frequency is
supported, we can change it easily.
> > +/*
> > + * Frequency : rm3100_samp_rates[][0].rm3100_samp_rates[][1]Hz.
> > + * Time between reading: rm3100_sam_rates[][2]ms.
> > + * The first one is actually 1.7ms.
> > + */
> > +static const int rm3100_samp_rates[RM3100_SAMP_NUM][3] = {
> > + {600, 0, 2}, {300, 0, 3}, {150, 0, 7}, {75, 0, 13}, {37, 0, 27},
> > + {18, 0, 55}, {9, 0, 110}, {4, 500000, 220}, {2, 300000, 440},
> > + {1, 200000, 800}, {0, 600000, 1600}, {0, 300000, 3300},
> > + {0, 15000, 6700}, {0, 75000, 13000}
> > +};
> > +
> > +static int rm3100_get_samp_freq(struct rm3100_data *data, int *val, int *val2)
> > +{
> > + int ret;
> > + int tmp;
> > +
> > + mutex_lock(&data->lock);
> > + ret = regmap_read(data->regmap, RM3100_REG_TMRC, &tmp);
>
> use (unsigned int *) throughly as 3rd argument of
> regmap_read() everywhere.
>
> > + mutex_unlock(&data->lock);
> > + if (ret < 0)
> > + return ret;
> > + *val = rm3100_samp_rates[tmp - RM3100_TMRC_OFFSET][0];
> > + *val2 = rm3100_samp_rates[tmp - RM3100_TMRC_OFFSET][1];
> > +
> > + return IIO_VAL_INT_PLUS_MICRO;
> > +}
> > +
> > +static int rm3100_set_cycle_count(struct rm3100_data *data, int val)
> > +{
> > + int ret;
> > + u8 i;
> > +
> > + for (i = 0; i < 3; i++) {
> > + ret = regmap_write(data->regmap, RM3100_REG_CC_X + 2 * i, 100);
>
> Would be better to use a descriptive macro for 100 instead ?
>
This was a mistake, my fault.
> > + if (ret < 0)
> > + return ret;
> > + }
> > + if (val == 50)
> > + data->cycle_count_index = 0;
> > + else if (val == 100)
> > + data->cycle_count_index = 1;
> > + else
> > + data->cycle_count_index = 2;
...
> > +static const struct regmap_config rm3100_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > +
> > + .rd_table = &rm3100_readable_table,
> > + .wr_table = &rm3100_writable_table,
> > + .volatile_table = &rm3100_volatile_table,
> > +
> > + .cache_type = REGCACHE_RBTREE,
>
> I wonder when do we use other types of `.cache_type` ?
>
Interesting question...
> > +static int rm3100_probe(struct i2c_client *client)
> > +{
> > + struct regmap *regmap;
> > +
...
> > +
> > +#ifndef RM3100_CORE_H
> > +#define RM3100_CORE_H
> > +
> > +#include <linux/regmap.h>
> > +
> > +#define RM3100_REG_REV_ID 0x36
>
> Does this ID needs to be checked and validated during
> intialisation with default state ID val ?
>
No, should remove it.
> > +
> > +/* Cycle Count Registers. */
> > +#define RM3100_REG_CC_X 0x05
> > +#define RM3100_REG_CC_Y 0x07
> > +#define RM3100_REG_CC_Z 0x09
> > +
> > +/* Continues Measurement Mode register. */
>
> Is it continuous ?
>
> > +#define RM3100_REG_CMM 0x01
> > +#define RM3100_CMM_START BIT(0)
> > +#define RM3100_CMM_X BIT(4)
> > +#define RM3100_CMM_Y BIT(5)
> > +#define RM3100_CMM_Z BIT(6)
> > +
> > +/* TiMe Rate Configuration register. */
>
> Time!
>
These uppercase letters are explaining why the register is called TMRC,
T(i)M(e) R(ate) C(onfiguration). :)
Though my bad english do carry a lot spell mistakes here...
> > +#define RM3100_REG_TMRC 0x0B
> > +#define RM3100_TMRC_OFFSET 0x92
> > +
> > +/* Result Status register. */
> > +#define RM3100_REG_STATUS 0x34
> > +#define RM3100_STATUS_DRDY BIT(7)
>
> If this status bit is a field of status register then
> align this as:
>
> #define RM3100_REG_STATUS 0x34
> #define RM3100_STATUS_DRDY BIT(7)
>
>
>
> > +/* Measurement result registers. */
> > +#define RM3100_REG_MX2 0x24
> > +#define RM3100_REG_MY2 0x27
> > +#define RM3100_REG_MZ2 0x2a
> > +
> > +#define RM3100_W_REG_START RM3100_REG_CMM
> > +#define RM3100_W_REG_END RM3100_REG_REV_ID
> > +#define RM3100_R_REG_START RM3100_REG_CMM
> > +#define RM3100_R_REG_END RM3100_REG_STATUS
> > +#define RM3100_V_REG_START RM3100_REG_MX2
> > +#define RM3100_V_REG_END RM3100_REG_STATUS
> > +
> > +#define RM3100_SCAN_BYTES 24
> > +
> > +struct rm3100_data {
> > + struct device *dev;
>
> Better remove this ?
>
All applied in the next patch. :)
>
> --
> Himanshu Jha
> Undergraduate Student
> Department of Electronics & Communication
> Guru Tegh Bahadur Institute of Technology
yours,
Song Qiang
next prev parent reply other threads:[~2018-09-26 2: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 [this message]
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
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=20180926022427.GA7447@Eros \
--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 \
--cc=rtresidd@electromag.com.au \
/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).