| Message ID | b6c02a5d75a20bbbf8c3370ccee615d269620117.1741849323.git.mazziesaccount@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Support ROHM BD79124 ADC | expand |
On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: > The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports > an automatic measurement mode, with an alarm interrupt for out-of-window > measurements. The window is configurable for each channel. > > The I2C protocol for manual start of the measurement and data reading is > somewhat peculiar. It requires the master to do clock stretching after > sending the I2C slave-address until the slave has captured the data. > Needless to say this is not well suopported by the I2C controllers. > > Thus the driver does not support the BD79124's manual measurement mode > but implements the measurements using automatic measurement mode relying > on the BD79124's ability of storing latest measurements into register. > > The driver does also support configuring the threshold events for > detecting the out-of-window events. > > The BD79124 keeps asserting IRQ for as long as the measured voltage is > out of the configured window. Thus the driver masks the received event > for a fixed duration (1 second) when an event is handled. This prevents > the user-space from choking on the events > > The ADC input pins can be also configured as general purpose outputs. > Those pins which don't have corresponding ADC channel node in the > device-tree will be controllable as GPO. ... > +#define BD79124_REG_SYSTEM_STATUS 0x0 I would expect to see 0x00 > +#define BD79124_REG_GEN_CFG 0x01 > +#define BD79124_REG_OPMODE_CFG 0x04 > +#define BD79124_REG_PINCFG 0x05 > +#define BD79124_REG_GPO_VAL 0x0B > +#define BD79124_REG_SEQUENCE_CFG 0x10 > +#define BD79124_REG_MANUAL_CHANNELS 0x11 > +#define BD79124_REG_AUTO_CHANNELS 0x12 > +#define BD79124_REG_ALERT_CH_SEL 0x14 > +#define BD79124_REG_EVENT_FLAG 0x18 > +#define BD79124_REG_EVENT_FLAG_HI 0x1a > +#define BD79124_REG_EVENT_FLAG_LO 0x1c > +#define BD79124_REG_HYSTERESIS_CH0 0x20 > +#define BD79124_REG_EVENTCOUNT_CH0 0x22 > +#define BD79124_REG_RECENT_CH0_LSB 0xa0 > +#define BD79124_REG_RECENT_CH7_MSB 0xaf ... Wouldn't be better... > +#define BD79124_MASK_CONV_MODE GENMASK(6, 5) > +#define BD79124_MASK_AUTO_INTERVAL GENMASK(1, 0) > +#define BD79124_CONV_MODE_MANSEQ 0 > +#define BD79124_CONV_MODE_AUTO 1 > +#define BD79124_INTERVAL_750_US 0 To group masks and values of the same bitfields? #define BD79124_MASK_CONV_MODE GENMASK(6, 5) #define BD79124_CONV_MODE_MANSEQ 0 #define BD79124_CONV_MODE_AUTO 1 #define BD79124_MASK_AUTO_INTERVAL GENMASK(1, 0) #define BD79124_INTERVAL_750_US 0 > +#define BD79124_MASK_DWC_EN BIT(4) > +#define BD79124_MASK_STATS_EN BIT(5) > +#define BD79124_MASK_SEQ_START BIT(4) > +#define BD79124_MASK_SEQ_MODE GENMASK(1, 0) > +#define BD79124_MASK_SEQ_MANUAL 0 > +#define BD79124_MASK_SEQ_SEQ 1 > + > +#define BD79124_MASK_HYSTERESIS GENMASK(3, 0) > +#define BD79124_LOW_LIMIT_MIN 0 > +#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0) These masks are not named after registers (or I don't see it clearly), it's hard to understand which one relates to which register. Also, why not using bitfield.h? ... > + * These macros return the address of the 1.st reg for the given channel first (and missing period at the end). > +#define BD79124_GET_HIGH_LIMIT_REG(ch) (BD79124_REG_HYSTERESIS_CH0 + (ch) * 4) > +#define BD79124_GET_LOW_LIMIT_REG(ch) (BD79124_REG_EVENTCOUNT_CH0 + (ch) * 4) > +#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ? \ > + BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch)) > +#define BD79124_GET_RECENT_RES_REG(ch) (BD79124_REG_RECENT_CH0_LSB + (ch) * 2) Don't we want to have something in bitfield.h for arrays in the register, i.e. when register(s) is(are) split to 2+ bits per an element in an array of the same semantics. Would be nice to eliminate such a boilerplate here and in many other drivers. > +/* > + * The hysteresis for a channel is stored in the same register where the > + * 4 bits of high limit reside. > + */ > +#define BD79124_GET_HYSTERESIS_REG(ch) BD79124_GET_HIGH_LIMIT_REG(ch) > + > +#define BD79124_MAX_NUM_CHANNELS 8 > + > +struct bd79124_data { > + s64 timestamp; > + struct regmap *map; > + struct device *dev; > + int vmax; > + /* > + * Keep measurement status so read_raw() knows if the measurement needs > + * to be started. > + */ > + int alarm_monitored[BD79124_MAX_NUM_CHANNELS]; > + /* > + * The BD79124 does not allow disabling/enabling limit separately for > + * one direction only. Hence, we do the disabling by changing the limit > + * to maximum/minimum measurable value. This means we need to cache > + * the limit in order to maintain it over the time limit is disabled. > + */ > + u16 alarm_r_limit[BD79124_MAX_NUM_CHANNELS]; > + u16 alarm_f_limit[BD79124_MAX_NUM_CHANNELS]; > + /* Bitmask of disabled events (for rate limiting) for each channel. */ > + int alarm_suppressed[BD79124_MAX_NUM_CHANNELS]; > + /* > + * The BD79124 is configured to run the measurements in the background. > + * This is done for the event monitoring as well as for the read_raw(). > + * Protect the measurement starting/stopping using a mutex. > + */ > + struct mutex mutex; > + struct delayed_work alm_enable_work; > + struct gpio_chip gc; > + u8 gpio_valid_mask; > +}; ... > +static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value) You should use .set_rv() ... > +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask, > + unsigned long *bits) Ditto, .set_multiple_rv(). > +{ > + int ret, val; Here and everywhere else, the returned value by regmap is unsigned int. > + struct bd79124_data *data = gpiochip_get_data(gc); > + > + /* Ensure all GPIOs in 'mask' are set to be GPIOs */ > + ret = regmap_read(data->map, BD79124_REG_PINCFG, &val); > + if (ret) > + return; > + > + if ((val & *mask) != *mask) { > + dev_dbg(data->dev, "Invalid mux config. Can't set value.\n"); > + /* Do not set value for pins configured as ADC inputs */ > + *mask &= val; > + } > + > + regmap_update_bits(data->map, BD79124_REG_GPO_VAL, *mask, *bits); > +} ... > +struct bd79124_raw { > + u8 bit0_3; /* Is set in high bits of the byte */ > + u8 bit4_11; > +}; > +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4)) And how this is different from treating it as __le16? Needs a good comment about bit layout. ... > +static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg, > + unsigned int val) > +{ > + struct bd79124_raw raw; > + int ret, tmp; > + raw.bit4_11 = (u8)(val >> 4); > + raw.bit0_3 = (u8)(val << 4); Why casting? Make sense to have a symmetrical macro instead of hiding it in the code. > + ret = regmap_read(data->map, reg, &tmp); > + if (ret) > + return ret; > + > + raw.bit0_3 |= (0xf & tmp); GENMASK() ? > + return regmap_bulk_write(data->map, reg, &raw, sizeof(raw)); > +} ... > + /* > + * The data-sheet says the hysteresis register value needs to be > + * sifted left by 3 Missing period. > + */ ... > + return (data->alarm_monitored[chan->channel] & BIT(dir)); Unneeded parentheses. ... > + case IIO_EV_INFO_HYSTERESIS: > + reg = BD79124_GET_HYSTERESIS_REG(chan->channel); > + val >>= 3; Second time I see this. Perhaps you need a macro to explain this right shift? > + return regmap_update_bits(data->map, reg, BD79124_MASK_HYSTERESIS, > + val); Can be one line. ... > +static irqreturn_t bd79124_event_handler(int irq, void *priv) > +{ > + int ret, i_hi, i_lo, i; > + struct iio_dev *iio_dev = priv; > + struct bd79124_data *data = iio_priv(iio_dev); > + > + /* > + * Return IRQ_NONE if bailing-out without acking. This allows the IRQ > + * subsystem to disable the offending IRQ line if we get a hardware > + * problem. This behaviour has saved my poor bottom a few times in the > + * past as, instead of getting unusably unresponsive, the system has > + * spilled out the magic words "...nobody cared". > + */ > + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_HI, &i_hi); > + if (ret) > + return IRQ_NONE; > + > + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_LO, &i_lo); > + if (ret) > + return IRQ_NONE; Only I don't get why you can't use bulk read here. The registers seem to be sequential. > + if (!i_lo && !i_hi) > + return IRQ_NONE; > + > + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { > + u64 ecode; > + > + if (BIT(i) & i_hi) { > + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, > + IIO_EV_TYPE_THRESH, > + IIO_EV_DIR_RISING); > + > + iio_push_event(iio_dev, ecode, data->timestamp); > + /* > + * The BD79124 keeps the IRQ asserted for as long as > + * the voltage exceeds the threshold. It causes the IRQ > + * to keep firing. > + * > + * Disable the event for the channel and schedule the > + * re-enabling the event later to prevent storm of > + * events. > + */ > + ret = bd79124_event_ratelimit_hi(data, i); > + if (ret) > + return IRQ_NONE; > + } > + if (BIT(i) & i_lo) { > + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, > + IIO_EV_TYPE_THRESH, > + IIO_EV_DIR_FALLING); > + > + iio_push_event(iio_dev, ecode, data->timestamp); > + ret = bd79124_event_ratelimit_lo(data, i); > + if (ret) > + return IRQ_NONE; > + } > + } > + > + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_HI, i_hi); > + if (ret) > + return IRQ_NONE; > + > + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_LO, i_lo); > + if (ret) > + return IRQ_NONE; In the similar way bulk write. > + return IRQ_HANDLED; > +} ... > +static int bd79124_chan_init(struct bd79124_data *data, int channel) > +{ > + int ret; > + > + ret = regmap_write(data->map, BD79124_GET_HIGH_LIMIT_REG(channel), 4095); BD79124_HIGH_LIMIT_MAX ? > + if (ret) > + return ret; > + > + return regmap_write(data->map, BD79124_GET_LOW_LIMIT_REG(channel), 0); BD79124_HIGH_LIMIT_MIN ? > +} ... > + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { > + ret = bd79124_chan_init(data, i); > + if (ret) > + return ret; > + data->alarm_r_limit[i] = 4095; As per above? > + } ... > + gpio_pins = bd79124_get_gpio_pins(iio_dev->channels, > + iio_dev->num_channels); It may be a single line (84 characters). ... > +static const struct i2c_device_id bd79124_id[] = { > + { "bd79124", }, Redundant inner comma. > + { } > +};
On 13/03/2025 15:19, Andy Shevchenko wrote: > On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: >> The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports >> an automatic measurement mode, with an alarm interrupt for out-of-window >> measurements. The window is configurable for each channel. >> >> The I2C protocol for manual start of the measurement and data reading is >> somewhat peculiar. It requires the master to do clock stretching after >> sending the I2C slave-address until the slave has captured the data. >> Needless to say this is not well suopported by the I2C controllers. >> >> Thus the driver does not support the BD79124's manual measurement mode >> but implements the measurements using automatic measurement mode relying >> on the BD79124's ability of storing latest measurements into register. >> >> The driver does also support configuring the threshold events for >> detecting the out-of-window events. >> >> The BD79124 keeps asserting IRQ for as long as the measured voltage is >> out of the configured window. Thus the driver masks the received event >> for a fixed duration (1 second) when an event is handled. This prevents >> the user-space from choking on the events >> >> The ADC input pins can be also configured as general purpose outputs. >> Those pins which don't have corresponding ADC channel node in the >> device-tree will be controllable as GPO. > > ... > >> +#define BD79124_REG_SYSTEM_STATUS 0x0 > > I would expect to see 0x00 ok. > >> +#define BD79124_REG_GEN_CFG 0x01 >> +#define BD79124_REG_OPMODE_CFG 0x04 >> +#define BD79124_REG_PINCFG 0x05 >> +#define BD79124_REG_GPO_VAL 0x0B >> +#define BD79124_REG_SEQUENCE_CFG 0x10 >> +#define BD79124_REG_MANUAL_CHANNELS 0x11 >> +#define BD79124_REG_AUTO_CHANNELS 0x12 >> +#define BD79124_REG_ALERT_CH_SEL 0x14 >> +#define BD79124_REG_EVENT_FLAG 0x18 >> +#define BD79124_REG_EVENT_FLAG_HI 0x1a >> +#define BD79124_REG_EVENT_FLAG_LO 0x1c >> +#define BD79124_REG_HYSTERESIS_CH0 0x20 >> +#define BD79124_REG_EVENTCOUNT_CH0 0x22 >> +#define BD79124_REG_RECENT_CH0_LSB 0xa0 >> +#define BD79124_REG_RECENT_CH7_MSB 0xaf > > ... > > Wouldn't be better... > >> +#define BD79124_MASK_CONV_MODE GENMASK(6, 5) >> +#define BD79124_MASK_AUTO_INTERVAL GENMASK(1, 0) >> +#define BD79124_CONV_MODE_MANSEQ 0 >> +#define BD79124_CONV_MODE_AUTO 1 >> +#define BD79124_INTERVAL_750_US 0 > > To group masks and values of the same bitfields? > > #define BD79124_MASK_CONV_MODE GENMASK(6, 5) > #define BD79124_CONV_MODE_MANSEQ 0 > #define BD79124_CONV_MODE_AUTO 1 > #define BD79124_MASK_AUTO_INTERVAL GENMASK(1, 0) > #define BD79124_INTERVAL_750_US 0 ok. > >> +#define BD79124_MASK_DWC_EN BIT(4) >> +#define BD79124_MASK_STATS_EN BIT(5) >> +#define BD79124_MASK_SEQ_START BIT(4) >> +#define BD79124_MASK_SEQ_MODE GENMASK(1, 0) >> +#define BD79124_MASK_SEQ_MANUAL 0 >> +#define BD79124_MASK_SEQ_SEQ 1 >> + >> +#define BD79124_MASK_HYSTERESIS GENMASK(3, 0) >> +#define BD79124_LOW_LIMIT_MIN 0 >> +#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0) > > These masks are not named after registers (or I don't see it clearly), Naming is hard. I usually try to make a balance between: 1) using names which explain the purpose when seen in the code (at call site) 2) keeping names short enough 3) following the naming convention in the data sheet 4) maintain relation to the register. I put most emphasis to the 1, while 2 is important to me as well. 3 is _very_ nice to have, but it is often somehow contradicting with 1 and 2. 4 is IMO just nice to have. The register is usually clearly visible at call site, and if someone adds new functionality (or checks the correctness of the masks/registers), then 3 is way more important. I am open to any concrete suggestions though. > it's > hard to understand which one relates to which register. Also, why not using > bitfield.h? I saw no need for it? > ... > >> + * These macros return the address of the 1.st reg for the given channel > > first Huh? > (and missing period at the end). Ok. >> +#define BD79124_GET_HIGH_LIMIT_REG(ch) (BD79124_REG_HYSTERESIS_CH0 + (ch) * 4) >> +#define BD79124_GET_LOW_LIMIT_REG(ch) (BD79124_REG_EVENTCOUNT_CH0 + (ch) * 4) >> +#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ? \ >> + BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch)) >> +#define BD79124_GET_RECENT_RES_REG(ch) (BD79124_REG_RECENT_CH0_LSB + (ch) * 2) > > Don't we want to have something in bitfield.h for arrays in the register, i.e. > when register(s) is(are) split to 2+ bits per an element in an array of the > same semantics. Would be nice to eliminate such a boilerplate here and in many > other drivers. Not necessarily a bad idea. Still, I am not willing to expand this series any more - currently there is 10 patches, 2 of which are directly related to the BD79124. I don't want to delay this driver for another cycle due to added helpers. >> +/* >> + * The hysteresis for a channel is stored in the same register where the >> + * 4 bits of high limit reside. >> + */ >> +#define BD79124_GET_HYSTERESIS_REG(ch) BD79124_GET_HIGH_LIMIT_REG(ch) >> + >> +#define BD79124_MAX_NUM_CHANNELS 8 >> + >> +struct bd79124_data { >> + s64 timestamp; >> + struct regmap *map; >> + struct device *dev; >> + int vmax; >> + /* >> + * Keep measurement status so read_raw() knows if the measurement needs >> + * to be started. >> + */ >> + int alarm_monitored[BD79124_MAX_NUM_CHANNELS]; >> + /* >> + * The BD79124 does not allow disabling/enabling limit separately for >> + * one direction only. Hence, we do the disabling by changing the limit >> + * to maximum/minimum measurable value. This means we need to cache >> + * the limit in order to maintain it over the time limit is disabled. >> + */ >> + u16 alarm_r_limit[BD79124_MAX_NUM_CHANNELS]; >> + u16 alarm_f_limit[BD79124_MAX_NUM_CHANNELS]; >> + /* Bitmask of disabled events (for rate limiting) for each channel. */ >> + int alarm_suppressed[BD79124_MAX_NUM_CHANNELS]; >> + /* >> + * The BD79124 is configured to run the measurements in the background. >> + * This is done for the event monitoring as well as for the read_raw(). >> + * Protect the measurement starting/stopping using a mutex. >> + */ >> + struct mutex mutex; >> + struct delayed_work alm_enable_work; >> + struct gpio_chip gc; >> + u8 gpio_valid_mask; >> +}; > > ... > >> +static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value) > > You should use .set_rv() > > ... > >> +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask, >> + unsigned long *bits) > > Ditto, .set_multiple_rv(). As you know, this started at v6.14 cycle which is still ongoing. I don't think .set_rv() and .set_multiple_rv() are available? > >> +{ >> + int ret, val; > > Here and everywhere else, the returned value by regmap is unsigned int. Ack. > >> + struct bd79124_data *data = gpiochip_get_data(gc); >> + >> + /* Ensure all GPIOs in 'mask' are set to be GPIOs */ >> + ret = regmap_read(data->map, BD79124_REG_PINCFG, &val); >> + if (ret) >> + return; >> + >> + if ((val & *mask) != *mask) { >> + dev_dbg(data->dev, "Invalid mux config. Can't set value.\n"); >> + /* Do not set value for pins configured as ADC inputs */ >> + *mask &= val; >> + } >> + >> + regmap_update_bits(data->map, BD79124_REG_GPO_VAL, *mask, *bits); >> +} > > ... > >> +struct bd79124_raw { >> + u8 bit0_3; /* Is set in high bits of the byte */ >> + u8 bit4_11; >> +}; >> +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4)) > > And how this is different from treating it as __le16? Needs a good comment > about bit layout. You don't think: >> +struct bd79124_raw { >> + u8 bit0_3; /* Is set in high bits of the byte */ >> + u8 bit4_11; >> +}; suffices? It's hard for me to think how to explain bit layout more explicitly. This was discussed during the RFC review. I explained the rationale why I rather represent this as two 8 bit variables than le16 with (mysterious to me) shift. As a result, Jonathan told me he's not feeling (too) strong about this (but also warned we may see follow-up patches converting this to le and shift - which, by the way, is harder for me to understand). > > ... > >> +static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg, >> + unsigned int val) >> +{ >> + struct bd79124_raw raw; >> + int ret, tmp; > >> + raw.bit4_11 = (u8)(val >> 4); >> + raw.bit0_3 = (u8)(val << 4); > > Why casting? To make it clear storing unsigned int to u8 is considered to be Ok. I can drop it though if you feel strong about it. > > Make sense to have a symmetrical macro instead of hiding it in the code. Ok. >> + ret = regmap_read(data->map, reg, &tmp); >> + if (ret) >> + return ret; >> + >> + raw.bit0_3 |= (0xf & tmp); > > GENMASK() ? For me 0xf is both shorter and clearer. (For me 0xf - or, 0x0f if you like, 0xf0 and 0xff are clear by a glance). I can go for GENMASK() if it is absolutely required, but for me it is in this case just making this harder to read. I like GENMASK() for something like 0xe or 0x60 though. >> + return regmap_bulk_write(data->map, reg, &raw, sizeof(raw)); >> +} > > ... > >> + return (data->alarm_monitored[chan->channel] & BIT(dir)); > > Unneeded parentheses. ok > ... > >> + case IIO_EV_INFO_HYSTERESIS: >> + reg = BD79124_GET_HYSTERESIS_REG(chan->channel); >> + val >>= 3; > > Second time I see this. Perhaps you need a macro to explain this right shift? Not really sure about this. I think it's kind of obvious why this is shifted - and in case it's not, there is a comment explaining it. I could have a macro like REGVAL2HYSTERESIS() - but I don't think it is a great idea, because then anyone interested in understanding the value read from register would need to dig out the macro to find how value needs to be converted. Doing the shift here shows the register format to a reader right away - and honestly, it should be pretty obvious to the reader that this shift converts register value to proper format. > >> + return regmap_update_bits(data->map, reg, BD79124_MASK_HYSTERESIS, >> + val); > > Can be one line. I still prefer to have lines < 80 to make them fit my terminal. I think we have discussed this before. I don't think we will agree on this as I have a very real reason for short lines. It does directly impact on my daily work. I don't think you're going to like it no matter how I explain this. > ... > >> +static irqreturn_t bd79124_event_handler(int irq, void *priv) >> +{ >> + int ret, i_hi, i_lo, i; >> + struct iio_dev *iio_dev = priv; >> + struct bd79124_data *data = iio_priv(iio_dev); >> + >> + /* >> + * Return IRQ_NONE if bailing-out without acking. This allows the IRQ >> + * subsystem to disable the offending IRQ line if we get a hardware >> + * problem. This behaviour has saved my poor bottom a few times in the >> + * past as, instead of getting unusably unresponsive, the system has >> + * spilled out the magic words "...nobody cared". >> + */ >> + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_HI, &i_hi); >> + if (ret) >> + return IRQ_NONE; >> + >> + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_LO, &i_lo); >> + if (ret) >> + return IRQ_NONE; > > Only I don't get why you can't use bulk read here. > The registers seem to be sequential. I think using bulk_read is a good idea. Thanks. > >> + if (!i_lo && !i_hi) >> + return IRQ_NONE; >> + >> + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { >> + u64 ecode; >> + >> + if (BIT(i) & i_hi) { >> + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, >> + IIO_EV_TYPE_THRESH, >> + IIO_EV_DIR_RISING); >> + >> + iio_push_event(iio_dev, ecode, data->timestamp); >> + /* >> + * The BD79124 keeps the IRQ asserted for as long as >> + * the voltage exceeds the threshold. It causes the IRQ >> + * to keep firing. >> + * >> + * Disable the event for the channel and schedule the >> + * re-enabling the event later to prevent storm of >> + * events. >> + */ >> + ret = bd79124_event_ratelimit_hi(data, i); >> + if (ret) >> + return IRQ_NONE; >> + } >> + if (BIT(i) & i_lo) { >> + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, >> + IIO_EV_TYPE_THRESH, >> + IIO_EV_DIR_FALLING); >> + >> + iio_push_event(iio_dev, ecode, data->timestamp); >> + ret = bd79124_event_ratelimit_lo(data, i); >> + if (ret) >> + return IRQ_NONE; >> + } >> + } >> + >> + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_HI, i_hi); >> + if (ret) >> + return IRQ_NONE; >> + >> + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_LO, i_lo); >> + if (ret) >> + return IRQ_NONE; > > In the similar way bulk write. agree. > >> + return IRQ_HANDLED; >> +} > > ... > >> +static int bd79124_chan_init(struct bd79124_data *data, int channel) >> +{ >> + int ret; >> + >> + ret = regmap_write(data->map, BD79124_GET_HIGH_LIMIT_REG(channel), 4095); > > BD79124_HIGH_LIMIT_MAX ? > >> + if (ret) >> + return ret; >> + >> + return regmap_write(data->map, BD79124_GET_LOW_LIMIT_REG(channel), 0); > > BD79124_HIGH_LIMIT_MIN ? I think I originally had these defines but I was probably asked to drop the defines and use raw values instead. >> +} > ... > >> +static const struct i2c_device_id bd79124_id[] = { >> + { "bd79124", }, > > Redundant inner comma. ok.
On 14/03/2025 09:31, Matti Vaittinen wrote: > On 13/03/2025 15:19, Andy Shevchenko wrote: >> On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: >>> +static int bd79124_chan_init(struct bd79124_data *data, int channel) >>> +{ >>> + int ret; >>> + >>> + ret = regmap_write(data->map, >>> BD79124_GET_HIGH_LIMIT_REG(channel), 4095); >> >> BD79124_HIGH_LIMIT_MAX ? >> >>> + if (ret) >>> + return ret; >>> + >>> + return regmap_write(data->map, >>> BD79124_GET_LOW_LIMIT_REG(channel), 0); >> >> BD79124_HIGH_LIMIT_MIN ? > > I think I originally had these defines but I was probably asked to drop > the defines and use raw values instead. Please ignore my reply here! It seems I still have the defines in other places of the code so they haven't been dropped after all. I'll replace the raw values as you suggested. Thanks. Yours, -- Matti
On 13/03/2025 15:19, Andy Shevchenko wrote: > On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: >> + /* >> + * Return IRQ_NONE if bailing-out without acking. This allows the IRQ >> + * subsystem to disable the offending IRQ line if we get a hardware >> + * problem. This behaviour has saved my poor bottom a few times in the >> + * past as, instead of getting unusably unresponsive, the system has >> + * spilled out the magic words "...nobody cared". >> + */ >> + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_HI, &i_hi); >> + if (ret) >> + return IRQ_NONE; >> + >> + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_LO, &i_lo); >> + if (ret) >> + return IRQ_NONE; > > Only I don't get why you can't use bulk read here. > The registers seem to be sequential. After taking another look - there seems to be undocumented register (0x1b) between the BD79124_REG_EVENT_FLAG_HI (0x1a) and the BD79124_REG_EVENT_FLAG_LO (0x1c). I won't touch it unless there is a real verified performance problem. > >> + if (!i_lo && !i_hi) >> + return IRQ_NONE; >> + >> + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { >> + u64 ecode; >> + >> + if (BIT(i) & i_hi) { >> + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, >> + IIO_EV_TYPE_THRESH, >> + IIO_EV_DIR_RISING); >> + >> + iio_push_event(iio_dev, ecode, data->timestamp); >> + /* >> + * The BD79124 keeps the IRQ asserted for as long as >> + * the voltage exceeds the threshold. It causes the IRQ >> + * to keep firing. >> + * >> + * Disable the event for the channel and schedule the >> + * re-enabling the event later to prevent storm of >> + * events. >> + */ >> + ret = bd79124_event_ratelimit_hi(data, i); >> + if (ret) >> + return IRQ_NONE; >> + } >> + if (BIT(i) & i_lo) { >> + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, >> + IIO_EV_TYPE_THRESH, >> + IIO_EV_DIR_FALLING); >> + >> + iio_push_event(iio_dev, ecode, data->timestamp); >> + ret = bd79124_event_ratelimit_lo(data, i); >> + if (ret) >> + return IRQ_NONE; >> + } >> + } >> + >> + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_HI, i_hi); >> + if (ret) >> + return IRQ_NONE; >> + >> + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_LO, i_lo); >> + if (ret) >> + return IRQ_NONE; > > In the similar way bulk write. definitely not due to the 0x1b. >> + return IRQ_HANDLED; >> +}
On Fri, Mar 14, 2025 at 09:31:58AM +0200, Matti Vaittinen wrote: > On 13/03/2025 15:19, Andy Shevchenko wrote: > > On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: ... > > > +#define BD79124_MASK_HYSTERESIS GENMASK(3, 0) > > > +#define BD79124_LOW_LIMIT_MIN 0 > > > +#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0) > > > > These masks are not named after registers (or I don't see it clearly), > > Naming is hard. I usually try to make a balance between: > > 1) using names which explain the purpose when seen in the code (at call > site) > 2) keeping names short enough > 3) following the naming convention in the data sheet > 4) maintain relation to the register. > > I put most emphasis to the 1, while 2 is important to me as well. 3 is > _very_ nice to have, but it is often somehow contradicting with 1 and 2. 4 > is IMO just nice to have. The register is usually clearly visible at call > site, and if someone adds new functionality (or checks the correctness of > the masks/registers), then 3 is way more important. > > I am open to any concrete suggestions though. From my point of view the starting point is 3, then one may apply 2 and 4, the 1 may mangle the name so much that register data field name becomes quite abstract. > > it's > > hard to understand which one relates to which register. Also, why not using > > bitfield.h? > > I saw no need for it? Hmm... Okay, I think Jonathan will ask that if really needed. ... > > > + * These macros return the address of the 1.st reg for the given channel > > > > first > > Huh? Replace "1.st" (which seems not a standard representation of it) by "first". > > (and missing period at the end). > > Ok. ... > > > +#define BD79124_GET_HIGH_LIMIT_REG(ch) (BD79124_REG_HYSTERESIS_CH0 + (ch) * 4) > > > +#define BD79124_GET_LOW_LIMIT_REG(ch) (BD79124_REG_EVENTCOUNT_CH0 + (ch) * 4) > > > +#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ? \ > > > + BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch)) > > > +#define BD79124_GET_RECENT_RES_REG(ch) (BD79124_REG_RECENT_CH0_LSB + (ch) * 2) > > > > Don't we want to have something in bitfield.h for arrays in the register, i.e. > > when register(s) is(are) split to 2+ bits per an element in an array of the > > same semantics. Would be nice to eliminate such a boilerplate here and in many > > other drivers. > > Not necessarily a bad idea. Still, I am not willing to expand this series > any more - currently there is 10 patches, 2 of which are directly related to > the BD79124. I don't want to delay this driver for another cycle due to > added helpers. It was just a side note. Consider as a poll for opinions. ... > > > +static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value) > > > > You should use .set_rv() ... > > > +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask, > > > + unsigned long *bits) > > > > Ditto, .set_multiple_rv(). > > As you know, this started at v6.14 cycle which is still ongoing. I don't > think .set_rv() and .set_multiple_rv() are available? You mean that you are still hope to have this series to be squeezed for v6.15-rc1? That's not me who decides, but if not, those APIs will be part of the v6.15-rc1 (at least they are pending in GPIO subsystem). ... > > > +struct bd79124_raw { > > > + u8 bit0_3; /* Is set in high bits of the byte */ > > > + u8 bit4_11; > > > +}; > > > +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4)) > > > > And how this is different from treating it as __le16? Needs a good comment > > about bit layout. > > You don't think: > >> +struct bd79124_raw { > >> + u8 bit0_3; /* Is set in high bits of the byte */ > >> + u8 bit4_11; > >> +}; > suffices? It's hard for me to think how to explain bit layout more > explicitly. I do not think it suffices. It's hard to decode what you meant by the naming and the comment. Actually it even confuses me. > This was discussed during the RFC review. I explained the rationale why I > rather represent this as two 8 bit variables than le16 with (mysterious to > me) shift. As a result, Jonathan told me he's not feeling (too) strong about > this (but also warned we may see follow-up patches converting this to le and > shift - which, by the way, is harder for me to understand). If you want to leave them, the good comment needs to be added for both 1) explaining bit layouts; 2) why __le16 is not being used. ... > > > +static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg, > > > + unsigned int val) > > > +{ > > > + struct bd79124_raw raw; > > > + int ret, tmp; > > > > > + raw.bit4_11 = (u8)(val >> 4); > > > + raw.bit0_3 = (u8)(val << 4); > > > > Why casting? > > To make it clear storing unsigned int to u8 is considered to be Ok. I can > drop it though if you feel strong about it. In C (not C++) explicit casting is a point to stumble over and check if there is any problems or call for asking the question "Whu?!" ... > > > + ret = regmap_read(data->map, reg, &tmp); > > > + if (ret) > > > + return ret; > > > + > > > + raw.bit0_3 |= (0xf & tmp); > > > > GENMASK() ? > > For me 0xf is both shorter and clearer. (For me 0xf - or, 0x0f if you like, > 0xf0 and 0xff are clear by a glance). > > I can go for GENMASK() if it is absolutely required, but for me it is in > this case just making this harder to read. I like GENMASK() for something > like 0xe or 0x60 though. It makes code inconsistent and one letter is not so visible. Ideally it should be a definition with self-explanatory name. > > > + return regmap_bulk_write(data->map, reg, &raw, sizeof(raw)); > > > +} ... > > > + case IIO_EV_INFO_HYSTERESIS: > > > + reg = BD79124_GET_HYSTERESIS_REG(chan->channel); > > > + val >>= 3; > > > > Second time I see this. Perhaps you need a macro to explain this right shift? > > Not really sure about this. I think it's kind of obvious why this is shifted > - and in case it's not, there is a comment explaining it. > > I could have a macro like REGVAL2HYSTERESIS() - but I don't think it is a > great idea, because then anyone interested in understanding the value read > from register would need to dig out the macro to find how value needs to be > converted. Doing the shift here shows the register format to a reader right > away - and honestly, it should be pretty obvious to the reader that this > shift converts register value to proper format. These shifts are not a big issue, so whatever you choose / chose. > > > + return regmap_update_bits(data->map, reg, BD79124_MASK_HYSTERESIS, > > > + val); > > > > Can be one line. > > I still prefer to have lines < 80 to make them fit my terminal. > I think we have discussed this before. I don't think we will agree on this > as I have a very real reason for short lines. It does directly impact on my > daily work. I don't think you're going to like it no matter how I explain > this. IIRC this takes 82 characters. Yes, we discussed and I see no issues to avoid uglifying / adding unnecessary lines to the code. We can continue arguing, but this what I think and I don't know what argument may change my opinion. Apparently this is on maintainer's field now to decide.
On Fri, Mar 14, 2025 at 11:22:37AM +0200, Matti Vaittinen wrote: > On 13/03/2025 15:19, Andy Shevchenko wrote: > > On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: ... > > > + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_HI, &i_hi); > > > + if (ret) > > > + return IRQ_NONE; > > > + > > > + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_LO, &i_lo); > > > + if (ret) > > > + return IRQ_NONE; > > > > Only I don't get why you can't use bulk read here. > > The registers seem to be sequential. > > After taking another look - there seems to be undocumented register (0x1b) > between the BD79124_REG_EVENT_FLAG_HI (0x1a) and the > BD79124_REG_EVENT_FLAG_LO (0x1c). > > I won't touch it unless there is a real verified performance problem. ... > > In the similar way bulk write. > > definitely not due to the 0x1b. Okay, it seems I misinterpreted the values you have in regmap configuration, I was under the impression that regmap is 16-bit data, but it is about address. So, we need to know why the heck HW has sparse registers for what is supposed to be sequential. This needs a good comment.
On Fri, 14 Mar 2025 16:33:13 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Fri, Mar 14, 2025 at 09:31:58AM +0200, Matti Vaittinen wrote: > > On 13/03/2025 15:19, Andy Shevchenko wrote: > > > On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: > > ... Picking out a few things to comment on... > > > > > +#define BD79124_MASK_HYSTERESIS GENMASK(3, 0) > > > > +#define BD79124_LOW_LIMIT_MIN 0 > > > > +#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0) > > > > > > These masks are not named after registers (or I don't see it clearly), > > > > Naming is hard. I usually try to make a balance between: > > > > 1) using names which explain the purpose when seen in the code (at call > > site) > > 2) keeping names short enough > > 3) following the naming convention in the data sheet > > 4) maintain relation to the register. > > > > I put most emphasis to the 1, while 2 is important to me as well. 3 is > > _very_ nice to have, but it is often somehow contradicting with 1 and 2. 4 > > is IMO just nice to have. The register is usually clearly visible at call > > site, and if someone adds new functionality (or checks the correctness of > > the masks/registers), then 3 is way more important. > > > > I am open to any concrete suggestions though. > > From my point of view the starting point is 3, then one may apply 2 and 4, > the 1 may mangle the name so much that register data field name becomes quite > abstract. > > > > it's > > > hard to understand which one relates to which register. Also, why not using > > > bitfield.h? > > > > I saw no need for it? > > Hmm... Okay, I think Jonathan will ask that if really needed. > I won't as I'm not a huge fan of bitfield.h. In many cases they bloat the code and increase the writes that go over the bus. Don't get me wrong, there are good usecases, but it's not a universal thing (unlike PREP_FIELD() etc which I love :) I do favour burning a few characters to make field / register relationship clear though. A few things can help I think. Structuring defines and naming: I like using whitespace in subtle ways for this. #define PREFIX_REGNAME_REG 0x00 #define PREFIX_REGNAME_FIELDNAME_MSK GENMASK(X, Y) #define PREFIX_REGNAME_FIELDNAME_FILEVALNAME 0x3 etc Makes it easy to see if we have a mismatch going on However, I don't insist on this in all cases as it is one of those "don't let perfect be the enemy of good" cases I think. So Matti, good to have one last look at the defines and see if they can be wrangled into a slightly better form. . > ... > > > > > +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask, > > > > + unsigned long *bits) > > > > > > Ditto, .set_multiple_rv(). > > > > As you know, this started at v6.14 cycle which is still ongoing. I don't > > think .set_rv() and .set_multiple_rv() are available? > > You mean that you are still hope to have this series to be squeezed for > v6.15-rc1? That's not me who decides, but if not, those APIs will be part of > the v6.15-rc1 (at least they are pending in GPIO subsystem). > I'd vote for a rebase on rc1 that should be really easy to for me to pick up. I'd accept a follow up series though. Ultimately won't affect when this series lands as very unlikely Linus will delay the release long enough for me to do another pull request this cycle, Jonathan
On Sun, 16 Mar 2025 09:52:33 +0000 Jonathan Cameron <jic23@kernel.org> wrote: > On Fri, 14 Mar 2025 16:33:13 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > On Fri, Mar 14, 2025 at 09:31:58AM +0200, Matti Vaittinen wrote: > > > On 13/03/2025 15:19, Andy Shevchenko wrote: > > > > On Thu, Mar 13, 2025 at 09:19:03AM +0200, Matti Vaittinen wrote: > > > > ... > Picking out a few things to comment on... > > > > > > > +#define BD79124_MASK_HYSTERESIS GENMASK(3, 0) > > > > > +#define BD79124_LOW_LIMIT_MIN 0 > > > > > +#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0) > > > > > > > > These masks are not named after registers (or I don't see it clearly), > > > > > > Naming is hard. I usually try to make a balance between: > > > > > > 1) using names which explain the purpose when seen in the code (at call > > > site) > > > 2) keeping names short enough > > > 3) following the naming convention in the data sheet > > > 4) maintain relation to the register. > > > > > > I put most emphasis to the 1, while 2 is important to me as well. 3 is > > > _very_ nice to have, but it is often somehow contradicting with 1 and 2. 4 > > > is IMO just nice to have. The register is usually clearly visible at call > > > site, and if someone adds new functionality (or checks the correctness of > > > the masks/registers), then 3 is way more important. > > > > > > I am open to any concrete suggestions though. > > > > From my point of view the starting point is 3, then one may apply 2 and 4, > > the 1 may mangle the name so much that register data field name becomes quite > > abstract. > > > > > > it's > > > > hard to understand which one relates to which register. Also, why not using > > > > bitfield.h? > > > > > > I saw no need for it? > > > > Hmm... Okay, I think Jonathan will ask that if really needed. > > > > I won't as I'm not a huge fan of bitfield.h. In many cases they bloat the code Oops. You weren't talking about the regmap bitfields. Ignore this. This driver is using FIELD_PREP / FIELD_GET. Maybe should be more extensive? > and increase the writes that go over the bus. Don't get me wrong, there > are good usecases, but it's not a universal thing (unlike PREP_FIELD() > etc which I love :) > > I do favour burning a few characters to make field / register relationship > clear though. A few things can help I think. > > Structuring defines and naming: > I like using whitespace in subtle ways for this. > > #define PREFIX_REGNAME_REG 0x00 > #define PREFIX_REGNAME_FIELDNAME_MSK GENMASK(X, Y) > #define PREFIX_REGNAME_FIELDNAME_FILEVALNAME 0x3 > etc > > Makes it easy to see if we have a mismatch going on > > However, I don't insist on this in all cases as it is one of those > "don't let perfect be the enemy of good" cases I think. > > So Matti, good to have one last look at the defines and see if they > can be wrangled into a slightly better form. > > > . > > ... > > > > > > > +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask, > > > > > + unsigned long *bits) > > > > > > > > Ditto, .set_multiple_rv(). > > > > > > As you know, this started at v6.14 cycle which is still ongoing. I don't > > > think .set_rv() and .set_multiple_rv() are available? > > > > You mean that you are still hope to have this series to be squeezed for > > v6.15-rc1? That's not me who decides, but if not, those APIs will be part of > > the v6.15-rc1 (at least they are pending in GPIO subsystem). > > > I'd vote for a rebase on rc1 that should be really easy to for me to pick > up. I'd accept a follow up series though. Ultimately won't affect > when this series lands as very unlikely Linus will delay the release > long enough for me to do another pull request this cycle, > > Jonathan
On Thu, 13 Mar 2025 09:19:03 +0200 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports > an automatic measurement mode, with an alarm interrupt for out-of-window > measurements. The window is configurable for each channel. > > The I2C protocol for manual start of the measurement and data reading is > somewhat peculiar. It requires the master to do clock stretching after > sending the I2C slave-address until the slave has captured the data. > Needless to say this is not well suopported by the I2C controllers. > > Thus the driver does not support the BD79124's manual measurement mode Given you are going to be doing a v8 and I'm bored on a train, so utterly trivial comments that you get as a frequent contributor as things to consider for future patches. (I'm sure it's just what you always wanted :) In theory should be imperative though I don't care as much as some. Hence, do not support the.... > but implements the measurements using automatic measurement mode relying > on the BD79124's ability of storing latest measurements into register. > > The driver does also support configuring the threshold events for > detecting the out-of-window events. Trivial editorial comment: that 'does' is not providing anything use in modern English (might have done in the past, no idea!) "Also support configure the threshold..." > > The BD79124 keeps asserting IRQ for as long as the measured voltage is > out of the configured window. Thus the driver masks the received event > for a fixed duration (1 second) when an event is handled. This prevents > the user-space from choking on the events > > The ADC input pins can be also configured as general purpose outputs. > Those pins which don't have corresponding ADC channel node in the > device-tree will be controllable as GPO. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> A few trivial things inline. Jonathan > +/* > + * The high and low limits as well as the recent result values are stored in > + * the same way in 2 consequent registers. The first register contains 4 bits > + * of the value. These bits are stored in the high bits [7:4] of register, but > + * they represent the low bits [3:0] of the value. > + * The value bits [11:4] are stored in the next regoster. > + * > + * Conver the integer to register format and write it using rmw cycle. Convert? > + */ > +static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg, > + unsigned int val) .. > +static int bd79124_read_event_config(struct iio_dev *iio_dev, > + const struct iio_chan_spec *chan, > + enum iio_event_type type, > + enum iio_event_direction dir) > +{ > + struct bd79124_data *data = iio_priv(iio_dev); > + > + if (chan->channel >= BD79124_MAX_NUM_CHANNELS) > + return -EINVAL; > + > + return (data->alarm_monitored[chan->channel] & BIT(dir)); Drop the outer brackets as not adding anything. > +} > +static int bd79124_probe(struct i2c_client *i2c) > +{ ... > + data->gpio_valid_mask = gpio_pins; > + data->gc = bd79124gpo_chip; > + data->gc.parent = dev; > + devm_mutex_init(dev, &data->mutex); ret = devm_mutex_init(dev, &data->mutex); if (ret) return ret; It is very unlikely to fail so no point in papering over failing to register the cleanup. > + > + ret = devm_gpiochip_add_data(dev, &data->gc, data); > + if (ret) > + return dev_err_probe(dev, ret, "gpio init Failed\n"); > + > + if (i2c->irq > 0) { > + ret = devm_request_threaded_irq(dev, i2c->irq, > + bd79124_irq_handler, &bd79124_event_handler, > + IRQF_ONESHOT, "adc-thresh-alert", iio_dev); > + if (ret) > + return dev_err_probe(data->dev, ret, > + "Failed to register IRQ\n"); > + } > + > + return devm_iio_device_register(data->dev, iio_dev); > +}
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 0993008a1586..74d749c0cd8f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -1191,6 +1191,18 @@ config RN5T618_ADC This driver can also be built as a module. If so, the module will be called rn5t618-adc. +config ROHM_BD79124 + tristate "Rohm BD79124 ADC driver" + depends on I2C + select REGMAP_I2C + select IIO_ADC_HELPER + help + Say yes here to build support for the ROHM BD79124 ADC. The + ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports + also an automatic measurement mode, with an alarm interrupt for + out-of-window measurements. The window is configurable for each + channel. + config ROCKCHIP_SARADC tristate "Rockchip SARADC driver" depends on ARCH_ROCKCHIP || COMPILE_TEST diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 1c410f483029..3e10af9ec4c4 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -109,6 +109,7 @@ obj-$(CONFIG_QCOM_VADC_COMMON) += qcom-vadc-common.o obj-$(CONFIG_RCAR_GYRO_ADC) += rcar-gyroadc.o obj-$(CONFIG_RICHTEK_RTQ6056) += rtq6056.o obj-$(CONFIG_RN5T618_ADC) += rn5t618-adc.o +obj-$(CONFIG_ROHM_BD79124) += rohm-bd79124.o obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o obj-$(CONFIG_RZG2L_ADC) += rzg2l_adc.o obj-$(CONFIG_SC27XX_ADC) += sc27xx_adc.o diff --git a/drivers/iio/adc/rohm-bd79124.c b/drivers/iio/adc/rohm-bd79124.c new file mode 100644 index 000000000000..100605ed2497 --- /dev/null +++ b/drivers/iio/adc/rohm-bd79124.c @@ -0,0 +1,1107 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ROHM ADC driver for BD79124 ADC/GPO device + * https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bd79124muf-c-e.pdf + * + * Copyright (c) 2025, ROHM Semiconductor. + */ + +#include <linux/bitfield.h> +#include <linux/bitmap.h> +#include <linux/bits.h> +#include <linux/byteorder/generic.h> +#include <linux/device.h> +#include <linux/delay.h> +#include <linux/devm-helpers.h> +#include <linux/err.h> +#include <linux/gpio/driver.h> +#include <linux/i2c.h> +#include <linux/interrupt.h> +#include <linux/irqreturn.h> +#include <linux/module.h> +#include <linux/mod_devicetable.h> +#include <linux/regmap.h> +#include <linux/types.h> + +#include <linux/iio/events.h> +#include <linux/iio/iio.h> +#include <linux/iio/adc-helpers.h> + +#define BD79124_I2C_MULTI_READ 0x30 +#define BD79124_I2C_MULTI_WRITE 0x28 +#define BD79124_REG_MAX 0xaf + +#define BD79124_REG_SYSTEM_STATUS 0x0 +#define BD79124_REG_GEN_CFG 0x01 +#define BD79124_REG_OPMODE_CFG 0x04 +#define BD79124_REG_PINCFG 0x05 +#define BD79124_REG_GPO_VAL 0x0B +#define BD79124_REG_SEQUENCE_CFG 0x10 +#define BD79124_REG_MANUAL_CHANNELS 0x11 +#define BD79124_REG_AUTO_CHANNELS 0x12 +#define BD79124_REG_ALERT_CH_SEL 0x14 +#define BD79124_REG_EVENT_FLAG 0x18 +#define BD79124_REG_EVENT_FLAG_HI 0x1a +#define BD79124_REG_EVENT_FLAG_LO 0x1c +#define BD79124_REG_HYSTERESIS_CH0 0x20 +#define BD79124_REG_EVENTCOUNT_CH0 0x22 +#define BD79124_REG_RECENT_CH0_LSB 0xa0 +#define BD79124_REG_RECENT_CH7_MSB 0xaf + +#define BD79124_ADC_BITS 12 +#define BD79124_MASK_CONV_MODE GENMASK(6, 5) +#define BD79124_MASK_AUTO_INTERVAL GENMASK(1, 0) +#define BD79124_CONV_MODE_MANSEQ 0 +#define BD79124_CONV_MODE_AUTO 1 +#define BD79124_INTERVAL_750_US 0 + +#define BD79124_MASK_DWC_EN BIT(4) +#define BD79124_MASK_STATS_EN BIT(5) +#define BD79124_MASK_SEQ_START BIT(4) +#define BD79124_MASK_SEQ_MODE GENMASK(1, 0) +#define BD79124_MASK_SEQ_MANUAL 0 +#define BD79124_MASK_SEQ_SEQ 1 + +#define BD79124_MASK_HYSTERESIS GENMASK(3, 0) +#define BD79124_LOW_LIMIT_MIN 0 +#define BD79124_HIGH_LIMIT_MAX GENMASK(11, 0) + +/* + * The high limit, low limit and last measurement result are each stored in + * 2 consequtive registers. 4 bits are in the high bits of the 1.st register + * and 8 bits in the next register. + * + * These macros return the address of the 1.st reg for the given channel + */ +#define BD79124_GET_HIGH_LIMIT_REG(ch) (BD79124_REG_HYSTERESIS_CH0 + (ch) * 4) +#define BD79124_GET_LOW_LIMIT_REG(ch) (BD79124_REG_EVENTCOUNT_CH0 + (ch) * 4) +#define BD79124_GET_LIMIT_REG(ch, dir) ((dir) == IIO_EV_DIR_RISING ? \ + BD79124_GET_HIGH_LIMIT_REG(ch) : BD79124_GET_LOW_LIMIT_REG(ch)) +#define BD79124_GET_RECENT_RES_REG(ch) (BD79124_REG_RECENT_CH0_LSB + (ch) * 2) + +/* + * The hysteresis for a channel is stored in the same register where the + * 4 bits of high limit reside. + */ +#define BD79124_GET_HYSTERESIS_REG(ch) BD79124_GET_HIGH_LIMIT_REG(ch) + +#define BD79124_MAX_NUM_CHANNELS 8 + +struct bd79124_data { + s64 timestamp; + struct regmap *map; + struct device *dev; + int vmax; + /* + * Keep measurement status so read_raw() knows if the measurement needs + * to be started. + */ + int alarm_monitored[BD79124_MAX_NUM_CHANNELS]; + /* + * The BD79124 does not allow disabling/enabling limit separately for + * one direction only. Hence, we do the disabling by changing the limit + * to maximum/minimum measurable value. This means we need to cache + * the limit in order to maintain it over the time limit is disabled. + */ + u16 alarm_r_limit[BD79124_MAX_NUM_CHANNELS]; + u16 alarm_f_limit[BD79124_MAX_NUM_CHANNELS]; + /* Bitmask of disabled events (for rate limiting) for each channel. */ + int alarm_suppressed[BD79124_MAX_NUM_CHANNELS]; + /* + * The BD79124 is configured to run the measurements in the background. + * This is done for the event monitoring as well as for the read_raw(). + * Protect the measurement starting/stopping using a mutex. + */ + struct mutex mutex; + struct delayed_work alm_enable_work; + struct gpio_chip gc; + u8 gpio_valid_mask; +}; + +static const struct regmap_range bd79124_ro_ranges[] = { + { + .range_min = BD79124_REG_EVENT_FLAG, + .range_max = BD79124_REG_EVENT_FLAG, + }, { + .range_min = BD79124_REG_RECENT_CH0_LSB, + .range_max = BD79124_REG_RECENT_CH7_MSB, + }, +}; + +static const struct regmap_access_table bd79124_ro_regs = { + .no_ranges = &bd79124_ro_ranges[0], + .n_no_ranges = ARRAY_SIZE(bd79124_ro_ranges), +}; + +static const struct regmap_range bd79124_volatile_ranges[] = { + { + .range_min = BD79124_REG_RECENT_CH0_LSB, + .range_max = BD79124_REG_RECENT_CH7_MSB, + }, { + .range_min = BD79124_REG_EVENT_FLAG, + .range_max = BD79124_REG_EVENT_FLAG, + }, { + .range_min = BD79124_REG_EVENT_FLAG_HI, + .range_max = BD79124_REG_EVENT_FLAG_HI, + }, { + .range_min = BD79124_REG_EVENT_FLAG_LO, + .range_max = BD79124_REG_EVENT_FLAG_LO, + }, { + .range_min = BD79124_REG_SYSTEM_STATUS, + .range_max = BD79124_REG_SYSTEM_STATUS, + }, +}; + +static const struct regmap_access_table bd79124_volatile_regs = { + .yes_ranges = &bd79124_volatile_ranges[0], + .n_yes_ranges = ARRAY_SIZE(bd79124_volatile_ranges), +}; + +static const struct regmap_range bd79124_precious_ranges[] = { + { + .range_min = BD79124_REG_EVENT_FLAG_HI, + .range_max = BD79124_REG_EVENT_FLAG_HI, + }, { + .range_min = BD79124_REG_EVENT_FLAG_LO, + .range_max = BD79124_REG_EVENT_FLAG_LO, + }, +}; + +static const struct regmap_access_table bd79124_precious_regs = { + .yes_ranges = &bd79124_precious_ranges[0], + .n_yes_ranges = ARRAY_SIZE(bd79124_precious_ranges), +}; + +static const struct regmap_config bd79124_regmap = { + .reg_bits = 16, + .val_bits = 8, + .read_flag_mask = BD79124_I2C_MULTI_READ, + .write_flag_mask = BD79124_I2C_MULTI_WRITE, + .max_register = BD79124_REG_MAX, + .cache_type = REGCACHE_MAPLE, + .volatile_table = &bd79124_volatile_regs, + .wr_table = &bd79124_ro_regs, + .precious_table = &bd79124_precious_regs, +}; + +static int bd79124gpo_direction_get(struct gpio_chip *gc, unsigned int offset) +{ + return GPIO_LINE_DIRECTION_OUT; +} + +static void bd79124gpo_set(struct gpio_chip *gc, unsigned int offset, int value) +{ + struct bd79124_data *data = gpiochip_get_data(gc); + + if (value) + regmap_set_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset)); + else + regmap_clear_bits(data->map, BD79124_REG_GPO_VAL, BIT(offset)); +} + +static void bd79124gpo_set_multiple(struct gpio_chip *gc, unsigned long *mask, + unsigned long *bits) +{ + int ret, val; + struct bd79124_data *data = gpiochip_get_data(gc); + + /* Ensure all GPIOs in 'mask' are set to be GPIOs */ + ret = regmap_read(data->map, BD79124_REG_PINCFG, &val); + if (ret) + return; + + if ((val & *mask) != *mask) { + dev_dbg(data->dev, "Invalid mux config. Can't set value.\n"); + /* Do not set value for pins configured as ADC inputs */ + *mask &= val; + } + + regmap_update_bits(data->map, BD79124_REG_GPO_VAL, *mask, *bits); +} + +static int bd79124_init_valid_mask(struct gpio_chip *gc, + unsigned long *valid_mask, + unsigned int ngpios) +{ + struct bd79124_data *data = gpiochip_get_data(gc); + + *valid_mask = data->gpio_valid_mask; + + return 0; +} + +/* Template for GPIO chip */ +static const struct gpio_chip bd79124gpo_chip = { + .label = "bd79124-gpo", + .get_direction = bd79124gpo_direction_get, + .set = bd79124gpo_set, + .set_multiple = bd79124gpo_set_multiple, + .init_valid_mask = bd79124_init_valid_mask, + .can_sleep = true, + .ngpio = 8, + .base = -1, +}; + +struct bd79124_raw { + u8 bit0_3; /* Is set in high bits of the byte */ + u8 bit4_11; +}; +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4)) + +/* + * The high and low limits as well as the recent result values are stored in + * the same way in 2 consequent registers. The first register contains 4 bits + * of the value. These bits are stored in the high bits [7:4] of register, but + * they represent the low bits [3:0] of the value. + * The value bits [11:4] are stored in the next register. + * + * Read data from register and convert to integer. + */ +static int bd79124_read_reg_to_int(struct bd79124_data *data, int reg, + unsigned int *val) +{ + int ret; + struct bd79124_raw raw; + + ret = regmap_bulk_read(data->map, reg, &raw, sizeof(raw)); + if (ret) { + dev_dbg(data->dev, "bulk_read failed %d\n", ret); + + return ret; + } + + *val = BD79124_RAW_TO_INT(raw); + + return 0; +} + +/* + * The high and low limits as well as the recent result values are stored in + * the same way in 2 consequent registers. The first register contains 4 bits + * of the value. These bits are stored in the high bits [7:4] of register, but + * they represent the low bits [3:0] of the value. + * The value bits [11:4] are stored in the next regoster. + * + * Conver the integer to register format and write it using rmw cycle. + */ +static int bd79124_write_int_to_reg(struct bd79124_data *data, int reg, + unsigned int val) +{ + struct bd79124_raw raw; + int ret, tmp; + + raw.bit4_11 = (u8)(val >> 4); + raw.bit0_3 = (u8)(val << 4); + + ret = regmap_read(data->map, reg, &tmp); + if (ret) + return ret; + + raw.bit0_3 |= (0xf & tmp); + + return regmap_bulk_write(data->map, reg, &raw, sizeof(raw)); +} + +static const struct iio_event_spec bd79124_events[] = { + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_RISING, + .mask_separate = BIT(IIO_EV_INFO_VALUE) | + BIT(IIO_EV_INFO_ENABLE), + }, + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_FALLING, + .mask_separate = BIT(IIO_EV_INFO_VALUE) | + BIT(IIO_EV_INFO_ENABLE), + }, + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_EITHER, + .mask_separate = BIT(IIO_EV_INFO_HYSTERESIS), + }, +}; + +static const struct iio_chan_spec bd79124_chan_template_noirq = { + .type = IIO_VOLTAGE, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), + .indexed = 1, +}; + +static const struct iio_chan_spec bd79124_chan_template = { + .type = IIO_VOLTAGE, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), + .indexed = 1, + .event_spec = bd79124_events, + .num_event_specs = ARRAY_SIZE(bd79124_events), +}; + +static int bd79124_read_event_value(struct iio_dev *iio_dev, + const struct iio_chan_spec *chan, + enum iio_event_type type, + enum iio_event_direction dir, + enum iio_event_info info, int *val, + int *val2) +{ + struct bd79124_data *data = iio_priv(iio_dev); + int ret, reg; + + if (chan->channel >= BD79124_MAX_NUM_CHANNELS) + return -EINVAL; + + switch (info) { + case IIO_EV_INFO_VALUE: + if (dir == IIO_EV_DIR_RISING) + *val = data->alarm_r_limit[chan->channel]; + else if (dir == IIO_EV_DIR_FALLING) + *val = data->alarm_f_limit[chan->channel]; + else + return -EINVAL; + + return IIO_VAL_INT; + + case IIO_EV_INFO_HYSTERESIS: + reg = BD79124_GET_HYSTERESIS_REG(chan->channel); + ret = regmap_read(data->map, reg, val); + if (ret) + return ret; + + *val &= BD79124_MASK_HYSTERESIS; + /* + * The data-sheet says the hysteresis register value needs to be + * sifted left by 3 + */ + *val <<= 3; + + return IIO_VAL_INT; + default: + return -EINVAL; + } +} + +static int bd79124_start_measurement(struct bd79124_data *data, int chan) +{ + int val, ret, regval; + + /* See if already started */ + ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, &val); + if (val & BIT(chan)) + return 0; + + /* + * The sequencer must be stopped when channels are added/removed from + * the list of the measured channels to ensure the new channel + * configuration is used. + */ + ret = regmap_clear_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); + if (ret) + return ret; + + ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, val | BIT(chan)); + if (ret) + return ret; + + ret = regmap_set_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); + if (ret) + return ret; + + /* + * Start the measurement at the background. Don't bother checking if + * it was started, regmap has cache. + */ + regval = FIELD_PREP(BD79124_MASK_CONV_MODE, BD79124_CONV_MODE_AUTO); + + return regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG, + BD79124_MASK_CONV_MODE, regval); +} + +static int bd79124_stop_measurement(struct bd79124_data *data, int chan) +{ + int val, ret; + + /* See if already stopped */ + ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, &val); + if (!(val & BIT(chan))) + return 0; + + ret = regmap_clear_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); + + /* Clear the channel from the measured channels */ + ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, + ~BIT(chan) & val); + if (ret) + return ret; + + /* + * Stop background conversion for power saving if it was the last + * channel + */ + if (!(~BIT(chan) & val)) { + int regval = FIELD_PREP(BD79124_MASK_CONV_MODE, + BD79124_CONV_MODE_MANSEQ); + + ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG, + BD79124_MASK_CONV_MODE, regval); + if (ret) + return ret; + } + + return regmap_set_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); +} + +static int bd79124_read_event_config(struct iio_dev *iio_dev, + const struct iio_chan_spec *chan, + enum iio_event_type type, + enum iio_event_direction dir) +{ + struct bd79124_data *data = iio_priv(iio_dev); + + if (chan->channel >= BD79124_MAX_NUM_CHANNELS) + return -EINVAL; + + return (data->alarm_monitored[chan->channel] & BIT(dir)); +} + +static int bd79124_disable_event(struct bd79124_data *data, + enum iio_event_direction dir, int channel) +{ + int dir_bit = BIT(dir); + int reg; + unsigned int limit; + + guard(mutex)(&data->mutex); + /* + * Set thresholds either to 0 or to 2^12 - 1 as appropriate to prevent + * alerts and thus disable event generation. + */ + if (dir == IIO_EV_DIR_RISING) { + reg = BD79124_GET_HIGH_LIMIT_REG(channel); + limit = BD79124_HIGH_LIMIT_MAX; + } else if (dir == IIO_EV_DIR_FALLING) { + reg = BD79124_GET_LOW_LIMIT_REG(channel); + limit = BD79124_LOW_LIMIT_MIN; + } else { + return -EINVAL; + } + + data->alarm_monitored[channel] &= ~dir_bit; + /* + * Stop measurement if there is no more events to monitor. + * We don't bother checking the retval because the limit + * setting should in any case effectively disable the alarm. + */ + if (!data->alarm_monitored[channel]) { + bd79124_stop_measurement(data, channel); + regmap_clear_bits(data->map, BD79124_REG_ALERT_CH_SEL, + BIT(channel)); + } + + return bd79124_write_int_to_reg(data, reg, limit); +} + +static int bd79124_enable_event(struct bd79124_data *data, + enum iio_event_direction dir, + unsigned int channel) +{ + int dir_bit = BIT(dir); + int reg, ret; + u16 *limit; + + guard(mutex)(&data->mutex); + ret = bd79124_start_measurement(data, channel); + if (ret) + return ret; + + data->alarm_monitored[channel] |= dir_bit; + + /* Add the channel to the list of monitored channels */ + ret = regmap_set_bits(data->map, BD79124_REG_ALERT_CH_SEL, + BIT(channel)); + if (ret) + return ret; + + if (dir == IIO_EV_DIR_RISING) { + limit = &data->alarm_f_limit[channel]; + reg = BD79124_GET_HIGH_LIMIT_REG(channel); + } else { + limit = &data->alarm_f_limit[channel]; + reg = BD79124_GET_LOW_LIMIT_REG(channel); + } + /* + * Don't write the new limit to the hardware if we are in the + * rate-limit period. The timer which re-enables the event will set + * the limit. + */ + if (!(data->alarm_suppressed[channel] & dir_bit)) { + ret = bd79124_write_int_to_reg(data, reg, *limit); + if (ret) + return ret; + } + + /* + * Enable comparator. Trust the regmap cache, no need to check + * if it was already enabled. + * + * We could do this in the hw-init, but there may be users who + * never enable alarms and for them it makes sense to not + * enable the comparator at probe. + */ + return regmap_set_bits(data->map, BD79124_REG_GEN_CFG, + BD79124_MASK_DWC_EN); +} + +static int bd79124_write_event_config(struct iio_dev *iio_dev, + const struct iio_chan_spec *chan, + enum iio_event_type type, + enum iio_event_direction dir, bool state) +{ + struct bd79124_data *data = iio_priv(iio_dev); + + if (chan->channel >= BD79124_MAX_NUM_CHANNELS) + return -EINVAL; + + if (state) + return bd79124_enable_event(data, dir, chan->channel); + + return bd79124_disable_event(data, dir, chan->channel); +} + +static int bd79124_write_event_value(struct iio_dev *iio_dev, + const struct iio_chan_spec *chan, + enum iio_event_type type, + enum iio_event_direction dir, + enum iio_event_info info, int val, + int val2) +{ + struct bd79124_data *data = iio_priv(iio_dev); + int reg; + + if (chan->channel >= BD79124_MAX_NUM_CHANNELS) + return -EINVAL; + + switch (info) { + case IIO_EV_INFO_VALUE: + if (dir == IIO_EV_DIR_RISING) { + guard(mutex)(&data->mutex); + + data->alarm_r_limit[chan->channel] = val; + reg = BD79124_GET_HIGH_LIMIT_REG(chan->channel); + } else if (dir == IIO_EV_DIR_FALLING) { + guard(mutex)(&data->mutex); + + data->alarm_f_limit[chan->channel] = val; + reg = BD79124_GET_LOW_LIMIT_REG(chan->channel); + } else { + return -EINVAL; + } + /* + * We don't want to enable the alarm if it is not enabled or + * if it is suppressed. In that case skip writing to the + * register. + */ + if (!(data->alarm_monitored[chan->channel] & BIT(dir)) || + data->alarm_suppressed[chan->channel] & BIT(dir)) + return 0; + + return bd79124_write_int_to_reg(data, reg, val); + + case IIO_EV_INFO_HYSTERESIS: + reg = BD79124_GET_HYSTERESIS_REG(chan->channel); + val >>= 3; + + return regmap_update_bits(data->map, reg, BD79124_MASK_HYSTERESIS, + val); + default: + return -EINVAL; + } +} + +static int bd79124_single_chan_seq(struct bd79124_data *data, int chan, int *old) +{ + int ret; + + ret = regmap_clear_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); + if (ret) + return ret; + + /* + * It may be we have some channels monitored for alarms so we want to + * cache the old config and return it when the single channel + * measurement has been completed. + */ + ret = regmap_read(data->map, BD79124_REG_AUTO_CHANNELS, old); + if (ret) + return ret; + + ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, BIT(chan)); + if (ret) + return ret; + + /* Restart the sequencer */ + return regmap_set_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); +} + +static int bd79124_single_chan_seq_end(struct bd79124_data *data, int old) +{ + int ret; + + ret = regmap_clear_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); + if (ret) + return ret; + + ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, old); + if (ret) + return ret; + + return regmap_set_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); +} + +static int bd79124_read_raw(struct iio_dev *iio_dev, + struct iio_chan_spec const *chan, + int *val, int *val2, long m) +{ + struct bd79124_data *data = iio_priv(iio_dev); + int ret; + + if (chan->channel >= BD79124_MAX_NUM_CHANNELS) + return -EINVAL; + + switch (m) { + case IIO_CHAN_INFO_RAW: + { + int old_chan_cfg, tmp; + int regval; + + guard(mutex)(&data->mutex); + + /* + * Start the automatic conversion. This is needed here if no + * events have been enabled. + */ + regval = FIELD_PREP(BD79124_MASK_CONV_MODE, + BD79124_CONV_MODE_AUTO); + ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG, + BD79124_MASK_CONV_MODE, regval); + if (ret) + return ret; + + ret = bd79124_single_chan_seq(data, chan->channel, &old_chan_cfg); + if (ret) + return ret; + + /* The maximum conversion time is 6 uS. */ + udelay(6); + + ret = bd79124_read_reg_to_int(data, + BD79124_GET_RECENT_RES_REG(chan->channel), val); + /* + * Return the old chan config even if data reading failed in + * order to re-enable the event monitoring. + */ + tmp = bd79124_single_chan_seq_end(data, old_chan_cfg); + if (tmp) + dev_err(data->dev, + "Failed to return config. Alarms may be disabled\n"); + + if (ret) + return ret; + + return IIO_VAL_INT; + } + case IIO_CHAN_INFO_SCALE: + *val = data->vmax / 1000; + *val2 = BD79124_ADC_BITS; + return IIO_VAL_FRACTIONAL_LOG2; + default: + return -EINVAL; + } +} + +static const struct iio_info bd79124_info = { + .read_raw = bd79124_read_raw, + .read_event_config = &bd79124_read_event_config, + .write_event_config = &bd79124_write_event_config, + .read_event_value = &bd79124_read_event_value, + .write_event_value = &bd79124_write_event_value, +}; + +static void bd79124_re_enable_lo(struct bd79124_data *data, unsigned int channel) +{ + int ret, evbit = BIT(IIO_EV_DIR_FALLING); + + /* + * We should not re-enable the event if user has disabled it while + * rate-limiting was enabled. + */ + if (!(data->alarm_suppressed[channel] & evbit)) + return; + + data->alarm_suppressed[channel] &= ~evbit; + + if (!(data->alarm_monitored[channel] & evbit)) + return; + + ret = bd79124_write_int_to_reg(data, BD79124_GET_LOW_LIMIT_REG(channel), + data->alarm_f_limit[channel]); + if (ret) + dev_warn(data->dev, "Low limit enabling failed for channel%d\n", + channel); +} + +static void bd79124_re_enable_hi(struct bd79124_data *data, unsigned int channel) +{ + int ret, evbit = BIT(IIO_EV_DIR_RISING); + + /* + * We should not re-enable the event if user has disabled it while + * rate-limiting was enabled. + */ + if (!(data->alarm_suppressed[channel] & evbit)) + return; + + data->alarm_suppressed[channel] &= ~evbit; + + if (!(data->alarm_monitored[channel] & evbit)) + return; + + ret = bd79124_write_int_to_reg(data, BD79124_GET_HIGH_LIMIT_REG(channel), + data->alarm_r_limit[channel]); + if (ret) + dev_warn(data->dev, "High limit enabling failed for channel%d\n", + channel); +} + +static void bd79124_alm_enable_worker(struct work_struct *work) +{ + int i; + struct bd79124_data *data = container_of(work, struct bd79124_data, + alm_enable_work.work); + + /* Take the mutex so there is no race with user disabling the alarm */ + guard(mutex)(&data->mutex); + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { + bd79124_re_enable_hi(data, i); + bd79124_re_enable_lo(data, i); + } +} + +static int __bd79124_event_ratelimit(struct bd79124_data *data, int reg, + unsigned int limit) +{ + int ret; + + if (limit > BD79124_HIGH_LIMIT_MAX) + return -EINVAL; + + ret = bd79124_write_int_to_reg(data, reg, limit); + if (ret) + return ret; + + /* + * We use 1 sec 'grace period'. At the moment I see no reason to make + * this user configurable. We need an ABI for this if configuration is + * needed. + */ + schedule_delayed_work(&data->alm_enable_work, + msecs_to_jiffies(1000)); + + return 0; +} + +static int bd79124_event_ratelimit_hi(struct bd79124_data *data, + unsigned int channel) +{ + guard(mutex)(&data->mutex); + data->alarm_suppressed[channel] |= BIT(IIO_EV_DIR_RISING); + + return __bd79124_event_ratelimit(data, + BD79124_GET_HIGH_LIMIT_REG(channel), + BD79124_HIGH_LIMIT_MAX); +} + +static int bd79124_event_ratelimit_lo(struct bd79124_data *data, + unsigned int channel) +{ + guard(mutex)(&data->mutex); + data->alarm_suppressed[channel] |= BIT(IIO_EV_DIR_FALLING); + + return __bd79124_event_ratelimit(data, + BD79124_GET_LOW_LIMIT_REG(channel), + BD79124_LOW_LIMIT_MIN); +} + +static irqreturn_t bd79124_event_handler(int irq, void *priv) +{ + int ret, i_hi, i_lo, i; + struct iio_dev *iio_dev = priv; + struct bd79124_data *data = iio_priv(iio_dev); + + /* + * Return IRQ_NONE if bailing-out without acking. This allows the IRQ + * subsystem to disable the offending IRQ line if we get a hardware + * problem. This behaviour has saved my poor bottom a few times in the + * past as, instead of getting unusably unresponsive, the system has + * spilled out the magic words "...nobody cared". + */ + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_HI, &i_hi); + if (ret) + return IRQ_NONE; + + ret = regmap_read(data->map, BD79124_REG_EVENT_FLAG_LO, &i_lo); + if (ret) + return IRQ_NONE; + + if (!i_lo && !i_hi) + return IRQ_NONE; + + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { + u64 ecode; + + if (BIT(i) & i_hi) { + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, + IIO_EV_TYPE_THRESH, + IIO_EV_DIR_RISING); + + iio_push_event(iio_dev, ecode, data->timestamp); + /* + * The BD79124 keeps the IRQ asserted for as long as + * the voltage exceeds the threshold. It causes the IRQ + * to keep firing. + * + * Disable the event for the channel and schedule the + * re-enabling the event later to prevent storm of + * events. + */ + ret = bd79124_event_ratelimit_hi(data, i); + if (ret) + return IRQ_NONE; + } + if (BIT(i) & i_lo) { + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i, + IIO_EV_TYPE_THRESH, + IIO_EV_DIR_FALLING); + + iio_push_event(iio_dev, ecode, data->timestamp); + ret = bd79124_event_ratelimit_lo(data, i); + if (ret) + return IRQ_NONE; + } + } + + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_HI, i_hi); + if (ret) + return IRQ_NONE; + + ret = regmap_write(data->map, BD79124_REG_EVENT_FLAG_LO, i_lo); + if (ret) + return IRQ_NONE; + + return IRQ_HANDLED; +} + +static irqreturn_t bd79124_irq_handler(int irq, void *priv) +{ + struct iio_dev *iio_dev = priv; + struct bd79124_data *data = iio_priv(iio_dev); + + data->timestamp = iio_get_time_ns(iio_dev); + + return IRQ_WAKE_THREAD; +} + +static int bd79124_chan_init(struct bd79124_data *data, int channel) +{ + int ret; + + ret = regmap_write(data->map, BD79124_GET_HIGH_LIMIT_REG(channel), 4095); + if (ret) + return ret; + + return regmap_write(data->map, BD79124_GET_LOW_LIMIT_REG(channel), 0); +} + +static int bd79124_get_gpio_pins(const struct iio_chan_spec *cs, int num_channels) +{ + int i, gpio_channels; + + /* + * Let's initialize the mux config to say that all 8 channels are + * GPIOs. Then we can just loop through the iio_chan_spec and clear the + * bits for found ADC channels. + */ + gpio_channels = GENMASK(7, 0); + for (i = 0; i < num_channels; i++) + gpio_channels &= ~BIT(cs[i].channel); + + return gpio_channels; +} + +static int bd79124_hw_init(struct bd79124_data *data, int gpio_pins) +{ + int ret, regval, i; + + ret = regmap_write(data->map, BD79124_REG_PINCFG, gpio_pins); + if (ret) + return ret; + + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) { + ret = bd79124_chan_init(data, i); + if (ret) + return ret; + data->alarm_r_limit[i] = 4095; + } + /* Stop auto sequencer */ + ret = regmap_clear_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_START); + if (ret) + return ret; + + /* Enable writing the measured values to the regsters */ + ret = regmap_set_bits(data->map, BD79124_REG_GEN_CFG, + BD79124_MASK_STATS_EN); + if (ret) + return ret; + + /* Set no channels to be auto-measured */ + ret = regmap_write(data->map, BD79124_REG_AUTO_CHANNELS, 0x0); + if (ret) + return ret; + + /* Set no channels to be manually measured */ + ret = regmap_write(data->map, BD79124_REG_MANUAL_CHANNELS, 0x0); + if (ret) + return ret; + + regval = FIELD_PREP(BD79124_MASK_AUTO_INTERVAL, BD79124_INTERVAL_750_US); + ret = regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG, + BD79124_MASK_AUTO_INTERVAL, regval); + if (ret) + return ret; + + /* Sequencer mode to auto */ + ret = regmap_set_bits(data->map, BD79124_REG_SEQUENCE_CFG, + BD79124_MASK_SEQ_SEQ); + if (ret) + return ret; + + /* Don't start the measurement */ + regval = FIELD_PREP(BD79124_MASK_CONV_MODE, BD79124_CONV_MODE_MANSEQ); + return regmap_update_bits(data->map, BD79124_REG_OPMODE_CFG, + BD79124_MASK_CONV_MODE, regval); +} + +static int bd79124_probe(struct i2c_client *i2c) +{ + struct bd79124_data *data; + struct iio_dev *iio_dev; + const struct iio_chan_spec *template; + struct iio_chan_spec *cs; + struct device *dev = &i2c->dev; + int gpio_pins, ret; + + iio_dev = devm_iio_device_alloc(dev, sizeof(*data)); + if (!iio_dev) + return -ENOMEM; + + data = iio_priv(iio_dev); + data->dev = dev; + data->map = devm_regmap_init_i2c(i2c, &bd79124_regmap); + if (IS_ERR(data->map)) + return dev_err_probe(dev, PTR_ERR(data->map), + "Failed to initialize Regmap\n"); + + ret = devm_regulator_get_enable_read_voltage(dev, "vdd"); + if (ret < 0) + return dev_err_probe(dev, ret, "Failed to get the Vdd\n"); + + data->vmax = ret; + + ret = devm_regulator_get_enable(dev, "iovdd"); + if (ret < 0) + return dev_err_probe(dev, ret, "Failed to enable I/O voltage\n"); + + ret = devm_delayed_work_autocancel(dev, &data->alm_enable_work, + bd79124_alm_enable_worker); + if (ret) + return ret; + + if (i2c->irq) { + template = &bd79124_chan_template; + } else { + template = &bd79124_chan_template_noirq; + dev_dbg(dev, "No IRQ found, events disabled\n"); + } + ret = devm_iio_adc_device_alloc_chaninfo_se(dev, template, + BD79124_MAX_NUM_CHANNELS - 1, &cs); + if (ret < 0) + return ret; + + iio_dev->channels = cs; + iio_dev->num_channels = ret; + iio_dev->info = &bd79124_info; + iio_dev->name = "bd79124"; + iio_dev->modes = INDIO_DIRECT_MODE; + + gpio_pins = bd79124_get_gpio_pins(iio_dev->channels, + iio_dev->num_channels); + ret = bd79124_hw_init(data, gpio_pins); + if (ret) + return ret; + + data->gpio_valid_mask = gpio_pins; + data->gc = bd79124gpo_chip; + data->gc.parent = dev; + devm_mutex_init(dev, &data->mutex); + + ret = devm_gpiochip_add_data(dev, &data->gc, data); + if (ret) + return dev_err_probe(dev, ret, "gpio init Failed\n"); + + if (i2c->irq > 0) { + ret = devm_request_threaded_irq(dev, i2c->irq, + bd79124_irq_handler, &bd79124_event_handler, + IRQF_ONESHOT, "adc-thresh-alert", iio_dev); + if (ret) + return dev_err_probe(data->dev, ret, + "Failed to register IRQ\n"); + } + + return devm_iio_device_register(data->dev, iio_dev); +} + +static const struct of_device_id bd79124_of_match[] = { + { .compatible = "rohm,bd79124" }, + { } +}; +MODULE_DEVICE_TABLE(of, bd79124_of_match); + +static const struct i2c_device_id bd79124_id[] = { + { "bd79124", }, + { } +}; +MODULE_DEVICE_TABLE(i2c, bd79124_id); + +static struct i2c_driver bd79124_driver = { + .driver = { + .name = "bd79124", + .of_match_table = bd79124_of_match, + }, + .probe = bd79124_probe, + .id_table = bd79124_id, +}; +module_i2c_driver(bd79124_driver); + +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>"); +MODULE_DESCRIPTION("Driver for ROHM BD79124 ADC"); +MODULE_LICENSE("GPL"); +MODULE_IMPORT_NS("IIO_DRIVER");
The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports an automatic measurement mode, with an alarm interrupt for out-of-window measurements. The window is configurable for each channel. The I2C protocol for manual start of the measurement and data reading is somewhat peculiar. It requires the master to do clock stretching after sending the I2C slave-address until the slave has captured the data. Needless to say this is not well suopported by the I2C controllers. Thus the driver does not support the BD79124's manual measurement mode but implements the measurements using automatic measurement mode relying on the BD79124's ability of storing latest measurements into register. The driver does also support configuring the threshold events for detecting the out-of-window events. The BD79124 keeps asserting IRQ for as long as the measured voltage is out of the configured window. Thus the driver masks the received event for a fixed duration (1 second) when an event is handled. This prevents the user-space from choking on the events The ADC input pins can be also configured as general purpose outputs. Those pins which don't have corresponding ADC channel node in the device-tree will be controllable as GPO. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> --- Revision history: v6 => v7: - Styling v5 => v6: - Styling as suggested by Jonathan v4 => v5: - Drop unused interval defines - Append unit to interval define and drop a comment - Drop parenthesis around bitwise negation operation ~ - Use proper block comment style - Improve the documentation of the re-enabling the events by moving comment explaining early return to the point of the return, and by adding own comment for the reason of locking before calling the re-enabling - Indenting - Drop unused struct bd79124_reg_init - Drop bd79124_init_mux() wrapper and call the regmap_write() directly v3 => v4: - Adapt to 'drop diff-channel support' changes to ADC-helpers - Don't parse fwnode in GPIO valid-mask callback but use pin config cached at probe() - Drop use of iio_adc_device_channels_by_property() - Open code the bd79124_reg_init loop (as suggested by Jonathan) - Use devm variant of mutex_init() - Styling v2 => v3: - Fix uninitialized return value reported by the kernel test robot - Fix indent - Adapt to adc-helper changes supporting also single-ended and differential channels RFC v1 => v2: - Add event throttling (constant delay of 1 sec) - rename variable 'd' to 'data' - Use ADC helpers to detect pins used for ADC - bd79124 drop MFD and pinmux && handle GPO in this driver - Drop adc suffix from the IIO file name drivers/iio/adc/rohm-bd79124.c styling --- drivers/iio/adc/Kconfig | 12 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/rohm-bd79124.c | 1107 ++++++++++++++++++++++++++++++++ 3 files changed, 1120 insertions(+) create mode 100644 drivers/iio/adc/rohm-bd79124.c