All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mudit Sharma <muditsharma.info@gmail.com>
To: Matti Vaittinen <mazziesaccount@gmail.com>,
	jic23@kernel.org, lars@metafoo.de, krzk+dt@kernel.org,
	conor+dt@kernel.org, robh@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, Ivan Orlov <ivan.orlov0322@gmail.com>,
	Javier Carrasco <javier.carrasco.cruz@gmail.com>
Subject: Re: [PATCH v6 2/2] iio: light: ROHM BH1745 colour sensor
Date: Mon, 1 Jul 2024 22:32:55 +0100	[thread overview]
Message-ID: <3ececd1c-8331-4007-8e75-a000425ccd3c@gmail.com> (raw)
In-Reply-To: <98c87420-e88a-43ca-a8af-2fa751b85d4f@gmail.com>

On 01/07/2024 12:32, Matti Vaittinen wrote:
>> +
>> +// From 16x max HW gain and 32x max integration time
>> +#define BH1745_MAX_GAIN 512
>> +
>> +static const int bh1745_int_time[][2] = {
>> +    { 0, 160000 }, /* 160 ms */
>> +    { 0, 320000 }, /* 320 ms */
>> +    { 0, 640000 }, /* 640 ms */
>> +    { 1, 280000 }, /* 1280 ms */
>> +    { 2, 560000 }, /* 2560 ms */
>> +    { 5, 120000 }, /* 5120 ms */
>> +};
>> +
>> +static const u8 bh1745_gain_factor[] = { 1, 2, 16 };
>> +
>> +static const int bh1745_int_time_us[] = { 160000,  320000,  640000,
>> +                      1280000, 2560000, 5120000 };
> 
> I am not sure why you need these tables above? Can't the iio_gts do all 
> the conversions from register-value to int time/gain and int-time/gain 
> to register value, as well as the checks for supported values? Ideally, 
> you would not need anything else but the bh1745_itimes and the 
> bh1745_gain tables below - they should contain all the same information.
> 

Hi Matti,

Thank you for reviewing this.

Just had a look again at GTS helpers and found the appropriate 
functions. Will drop these for v7.

>> +};
>> +
>> +static const struct regmap_range bh1745_volatile_ranges[] = {
>> +    regmap_reg_range(BH1745_MODE_CTRL_2, BH1745_MODE_CTRL_2), /* 
>> VALID */
>> +    regmap_reg_range(BH1745_RED_LSB, BH1745_CLEAR_MSB), /* Data */
>> +    regmap_reg_range(BH1745_INTR, BH1745_INTR), /* Interrupt */
>> +};
>> +
>> +static const struct regmap_access_table bh1745_volatile_regs = {
>> +    .yes_ranges = bh1745_volatile_ranges,
>> +    .n_yes_ranges = ARRAY_SIZE(bh1745_volatile_ranges),
>> +};
>> +
>> +static const struct regmap_range bh1745_read_ranges[] = {
>> +    regmap_reg_range(BH1745_SYS_CTRL, BH1745_MODE_CTRL_2),
>> +    regmap_reg_range(BH1745_RED_LSB, BH1745_CLEAR_MSB),
>> +    regmap_reg_range(BH1745_INTR, BH1745_INTR),
>> +    regmap_reg_range(BH1745_PERSISTENCE, BH1745_TL_MSB),
>> +    regmap_reg_range(BH1745_MANU_ID, BH1745_MANU_ID),
>> +};
>> +
>> +static const struct regmap_access_table bh1745_ro_regs = {
>> +    .yes_ranges = bh1745_read_ranges,
>> +    .n_yes_ranges = ARRAY_SIZE(bh1745_read_ranges),
>> +};
>> +
>> +static const struct regmap_range bh1745_writable_ranges[] = {
>> +    regmap_reg_range(BH1745_SYS_CTRL, BH1745_MODE_CTRL_2),
>> +    regmap_reg_range(BH1745_INTR, BH1745_INTR),
>> +    regmap_reg_range(BH1745_PERSISTENCE, BH1745_TL_MSB),
>> +};
>> +
>> +static const struct regmap_access_table bh1745_wr_regs = {
>> +    .yes_ranges = bh1745_writable_ranges,
>> +    .n_yes_ranges = ARRAY_SIZE(bh1745_writable_ranges),
>> +};
>> +
>> +static const struct regmap_config bh1745_regmap = {
>> +    .reg_bits = 8,
>> +    .val_bits = 8,
>> +    .max_register = BH1745_MANU_ID,
>> +    .cache_type = REGCACHE_RBTREE,
>> +    .volatile_table = &bh1745_volatile_regs,
>> +    .wr_table = &bh1745_wr_regs,
>> +    .rd_table = &bh1745_ro_regs,
> 
> I am not 100% sure what this does. (Let's say it is just my ignorance 
> :)). Does the 'ro' in 'bh1745_ro_regs' stand for read-only?
> 
> If so, shouldn't the read-inly registers be marked as "not writable", 
> which would be adding them in .wr_table in 'no_ranges'? Also, what is 
> the idea of the 'wr_regs'?
> 
There are some read-only (Manufacturer ID and Data registers) and some 
readable and writable registers. I will rename these to 
'bh1745_readable_regs' and 'bh1745_writable_regs' in v7 to avoid confusion.

>> +};
>> +
>> +static const struct iio_event_spec bh1745_event_spec[] = {
>> +    {
>> +        .type = IIO_EV_TYPE_THRESH,
>> +        .dir = IIO_EV_DIR_RISING,
>> +        .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE),
>> +    },
>> +    {
>> +        .type = IIO_EV_TYPE_THRESH,
>> +        .dir = IIO_EV_DIR_FALLING,
>> +        .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE),
>> +    },
>> +    {
>> +        .type = IIO_EV_TYPE_THRESH,
>> +        .dir = IIO_EV_DIR_EITHER,
>> +        .mask_shared_by_type = BIT(IIO_EV_INFO_PERIOD),
>> +        .mask_separate = BIT(IIO_EV_INFO_ENABLE),
>> +    },
>> +};
>> +
>> +#define BH1745_CHANNEL(_colour, _si, 
>> _addr)                             \
>> +    {                                                               \
>> +        .type = IIO_INTENSITY, .modified = 1,                   \
>> +        .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),           \
>> +        .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE) |   \
>> +                       BIT(IIO_CHAN_INFO_INT_TIME), \
>> +        .info_mask_shared_by_all_available =                    \
>> +            BIT(IIO_CHAN_INFO_SCALE) |                      \
>> +            BIT(IIO_CHAN_INFO_INT_TIME),                    \
>> +        .event_spec = bh1745_event_spec,                        \
>> +        .num_event_specs = ARRAY_SIZE(bh1745_event_spec),       \
>> +        .channel2 = IIO_MOD_LIGHT_##_colour, .address = _addr,  \
>> +        .scan_index = _si,                                      \
>> +        .scan_type = {                                          \
>> +            .sign = 'u',                                    \
>> +            .realbits = 16,                                 \
>> +            .storagebits = 16,                              \
>> +            .endianness = IIO_CPU,                          \
>> +        },                                                      \
>> +    }
>> +
>> +static const struct iio_chan_spec bh1745_channels[] = {
>> +    BH1745_CHANNEL(RED, 0, BH1745_RED_LSB),
>> +    BH1745_CHANNEL(GREEN, 1, BH1745_GREEN_LSB),
>> +    BH1745_CHANNEL(BLUE, 2, BH1745_BLUE_LSB),
>> +    BH1745_CHANNEL(CLEAR, 3, BH1745_CLEAR_LSB),
>> +    IIO_CHAN_SOFT_TIMESTAMP(4),
>> +};
>> +
>> +static int bh1745_reset(struct bh1745_data *data)
>> +{
>> +    int ret;
>> +    int value;
>> +
>> +    ret = regmap_read(data->regmap, BH1745_SYS_CTRL, &value);
>> +    if (ret)
>> +        return ret;
>> +
>> +    value |= (BH1745_SW_RESET | BH1745_INT_RESET);
>> +
>> +    return regmap_write(data->regmap, BH1745_SYS_CTRL, value);
> 
> Would it work if you used regmap_write_bits() instead?

Yes, it should work. Jonathan suggested 'regmap_set_bits()' for this and 
it looks like a good fit for this as well.

I will look through the regmap API once again and update similar cases.

> 
> ... Sorry, my reviewing time is out :/ I may continue later but no need 
> to wait for my comments if I am not responding. I've too much stuff 
> piling on :(
> 
> 
> Yours,
>      -- Matti
> 

Best regards,
Mudit Sharma

      reply	other threads:[~2024-07-01 21:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-25 22:03 [PATCH v6 1/2] dt-bindings: iio: light: ROHM BH1745 Mudit Sharma
2024-06-25 22:03 ` [PATCH v6 2/2] iio: light: ROHM BH1745 colour sensor Mudit Sharma
2024-06-28 19:37   ` Jonathan Cameron
2024-06-29  9:10     ` Mudit Sharma
2024-06-29 17:50       ` Jonathan Cameron
2024-07-01 19:34         ` Mudit Sharma
2024-07-01 11:32   ` Matti Vaittinen
2024-07-01 21:32     ` Mudit Sharma [this message]

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=3ececd1c-8331-4007-8e75-a000425ccd3c@gmail.com \
    --to=muditsharma.info@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ivan.orlov0322@gmail.com \
    --cc=javier.carrasco.cruz@gmail.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=robh@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 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.