| Message ID | 08f7085ba1af2fae21c942f6c20a94c237df53ba.1694001462.git.mazziesaccount@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Support ROHM BM1390 pressure sensor | expand |
On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: > Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure > pressures ranging from 300 hPa to 1300 hPa with configurable measurement > averaging and internal FIFO. The sensor does also provide temperature > measurements. > > Sensor does also contain IIR filter implemented in HW. The data-sheet > says the IIR filter can be configured to be "weak", "middle" or > "strong". Some RMS noise figures are provided in data sheet but no > accurate maths for the filter configurations is provided. Hence, the IIR > filter configuration is not supported by this driver and the filter is > configured to the "middle" setting (at least not for now). > > The FIFO measurement mode is only measuring the pressure and not the > temperature. The driver measures temperature when FIFO is flushed and > simply uses the same measured temperature value to all reported > temperatures. This should not be a problem when temperature is not > changing very rapidly (several degrees C / second) but allows users to > get the temperature measurements from sensor without any additional logic. ... > +struct bm1390_data_buf { > + u32 pressure; > + __be16 temp; > + s64 ts __aligned(8); Would like to see aligned_s64, but it will depend on my series, so not your problem and not right now :-) > +}; ... > +struct bm1390_data { > + int64_t timestamp, old_timestamp; Out of a sudden int64_t instead of u64? > + struct iio_trigger *trig; > + struct regmap *regmap; > + struct device *dev; > + struct bm1390_data_buf buf; > + int irq; > + unsigned int state; > + bool trigger_enabled; > + u8 watermark; Or u8 instead of uint8_t? > + /* Prevent accessing sensor during FIFO read sequence */ > + struct mutex mutex; > +}; ... > +static int bm1390_read_temp(struct bm1390_data *data, int *temp) > +{ > + u8 temp_reg[2] __aligned(2); Why?! Just use proper bitwise type. > + __be16 *temp_raw; > + int ret; > + s16 val; > + bool negative; > + > + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, > + sizeof(temp_reg)); > + if (ret) > + return ret; > + > + if (temp_reg[0] & 0x80) > + negative = true; > + else > + negative = false; > + temp_raw = (__be16 *)&temp_reg[0]; Heck no. Make temp_reg be properly typed. > + val = be16_to_cpu(*temp_raw); > + > + if (negative) { > + /* > + * Two's complement. I am not sure if all supported > + * architectures actually use 2's complement represantation of > + * signed ints. If yes, then we could just do the endianes > + * conversion and say this is the s16 value. However, as I > + * don't know, and as the conversion is pretty simple. let's > + * just convert the signed 2's complement to absolute value and > + * multiply by -1. > + */ > + val = ~val + 1; > + val *= -1; > + } > + > + *temp = val; > + > + return 0; > +} > +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) > +{ > + int ret; > + u8 raw[3]; > + > + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, > + &raw[0], sizeof(raw)); > + if (ret < 0) > + return ret; > + > + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); > + > + return 0; > +} ... > + /* The enum values map directly to register bits */ In this case assign _all_ values explicitly. Currently it's prone to errors if somebody squeezed a value in between. > +enum bm1390_meas_mode { > + BM1390_MEAS_MODE_STOP = 0x0, > + BM1390_MEAS_MODE_1SHOT, > + BM1390_MEAS_MODE_CONTINUOUS, > +}; ... > + mutex_lock(&data->mutex); Wouldn't you like to start using cleanup.h? ... > + /* > + * We use 'continuous mode' even for raw read because according to the > + * data-sheet an one-shot mode can't be used with IIR filter Missing period at the end. > + */ ... > + goto unlock_out; cleanup.h makes these goto:s unneeded. ... > + case IIO_CHAN_INFO_SCALE: > + if (chan->type == IIO_TEMP) { > + *val = 31; > + *val2 = 250000; > + > + return IIO_VAL_INT_PLUS_MICRO; > + } else if (chan->type == IIO_PRESSURE) { > + *val = 0; > + /* > + * pressure in hPa is register value divided by 2048. > + * This means kPa is 1/20480 times the register value, > + * which equals to 48828.125 * 10 ^ -9 > + * This is 48828.125 nano kPa. > + * > + * When we scale this using IIO_VAL_INT_PLUS_NANO we > + * get 48828 - which means we lose some accuracy. Well, > + * let's try to live with that. > + */ > + *val2 = 48828; > + > + return IIO_VAL_INT_PLUS_NANO; > + } > + > + return -EINVAL; Why not switch-case like other drivers do? > + case IIO_CHAN_INFO_RAW: > + ret = iio_device_claim_direct_mode(idev); > + if (ret) > + return ret; > + > + ret = bm1390_read_data(data, chan, val, val2); > + iio_device_release_direct_mode(idev); > + if (!ret) > + return IIO_VAL_INT; > + > + return ret; Why not usual pattern? if (ret) return ret; > + default: > + return -EINVAL; > + } ... > + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); > + Unneeded blank line. > + if (smp_lvl > 4) { > + /* > + * Valid values should be 0, 1, 2, 3, 4 - rest are probably > + * bit errors in I2C line. Don't overflow if this happens. > + */ > + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); > + smp_lvl = 4; > + } > + if (!smp_lvl) > + return ret; This can be checked first as it's and error condition and previous branch has no side effects on this. Also, wouldn't be better to use error code explicitly? ... > +static int bm1390_write_raw(struct iio_dev *idev, > + struct iio_chan_spec const *chan, > + int val, int val2, long mask) > +{ > + int ret; > + > + ret = iio_device_claim_direct_mode(idev); > + if (ret) > + return ret; > + switch (mask) { > + default: > + ret = -EINVAL; > + } This needs a comment: Why we have a dead code. > + iio_device_release_direct_mode(idev); > + > + return ret; > +} ... > + /* > + * Default to use IIR filter in "middle" mode. Also the AVE_NUM must > + * be fixed when IIR is in use Missing period. > + */ ... > + ret = regmap_read(data->regmap, BM1390_REG_STATUS, > + &dummy); This is perfectly one line even for fanatics of 80 characters limitation. > + if (ret || !dummy) > + return IRQ_NONE; ... > + if (state) { > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); This ret is never used, what's going on here? > + } else { > + int dummy; > + > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); > + > + /* > + * We need to read the status register in order to ACK the > + * data-ready which may have been generated just before we > + * disabled the measurement. > + */ > + if (!ret) > + ret = regmap_read(data->regmap, BM1390_REG_STATUS, > + &dummy); > + } > + > + ret = bm1390_set_drdy_irq(data, state); > + if (ret) > + goto unlock_out; > + > + One blank line is enough. > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > + We do not put blank lines at the end of functions. > +} ... > + ret = devm_iio_triggered_buffer_setup(data->dev, idev, > + &iio_pollfunc_store_time, > + &bm1390_trigger_handler, > + &bm1390_buffer_ops); > + Yet another redundant blank line. I dunno how you manage to almost in every second attempt to randomly place blank lines here and there... I feel like a conspiracy theory against myself :-) > + if (ret) > + return dev_err_probe(data->dev, ret, > + "iio_triggered_buffer_setup FAIL\n"); ... > + > + Ditto. > + ret = devm_iio_trigger_register(data->dev, itrig); > + if (ret) > + return dev_err_probe(data->dev, ret, > + "Trigger registration failed\n"); > + > + Ditto. > + return ret; ... > + ret = devm_iio_device_register(dev, idev); > + if (ret < 0) > + return dev_err_probe(dev, ret, > + "Unable to register iio device\n"); > + > + return ret; Do you expect anything than 0 here?
Morning Andy, Thanks for the review. On 9/6/23 18:48, Andy Shevchenko wrote: > On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: >> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure >> pressures ranging from 300 hPa to 1300 hPa with configurable measurement >> averaging and internal FIFO. The sensor does also provide temperature >> measurements. >> >> Sensor does also contain IIR filter implemented in HW. The data-sheet >> says the IIR filter can be configured to be "weak", "middle" or >> "strong". Some RMS noise figures are provided in data sheet but no >> accurate maths for the filter configurations is provided. Hence, the IIR >> filter configuration is not supported by this driver and the filter is >> configured to the "middle" setting (at least not for now). >> >> The FIFO measurement mode is only measuring the pressure and not the >> temperature. The driver measures temperature when FIFO is flushed and >> simply uses the same measured temperature value to all reported >> temperatures. This should not be a problem when temperature is not >> changing very rapidly (several degrees C / second) but allows users to >> get the temperature measurements from sensor without any additional logic. > > ... > > >> +struct bm1390_data { >> + int64_t timestamp, old_timestamp; > > Out of a sudden int64_t instead of u64? Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), IIO operates with signed timestamps. One being s64, the other int64_t. >> + struct iio_trigger *trig; >> + struct regmap *regmap; >> + struct device *dev; >> + struct bm1390_data_buf buf; >> + int irq; >> + unsigned int state; >> + bool trigger_enabled; > >> + u8 watermark; > > Or u8 instead of uint8_t? So, uint8_t is preferred? I don't really care all that much which of these to use - which may even show up as a lack of consistency... I think I did use uint8_t when I learned about it - but at some point someone somewhere asked me to use u8 instead.. This somewhere might have been u-boot though... So, are you Suggesting I should replace u8 with uint8_t? Can do if it matters. > >> + /* Prevent accessing sensor during FIFO read sequence */ >> + struct mutex mutex; >> +}; > > ... > >> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) >> +{ >> + u8 temp_reg[2] __aligned(2); > > Why?! Just use proper bitwise type. What is the proper bitwise type in this case? I'll explain my reasoning: What we really have in hardware (BM1390) and read from it is 8bit registers. This is u8 to me. And as we read two consecutive registers, we use u8 arr[2]. In my eyes it describes the data perfectly well, right? > >> + __be16 *temp_raw; >> + int ret; >> + s16 val; >> + bool negative; >> + >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, >> + sizeof(temp_reg)); >> + if (ret) >> + return ret; >> + >> + if (temp_reg[0] & 0x80) >> + negative = true; >> + else >> + negative = false; > >> + temp_raw = (__be16 *)&temp_reg[0]; > > Heck no. Make temp_reg be properly typed. As I explained above, to me it seems ur arr[2} is _the_ proper type to represent data we read from the device. What we need to do is to convert the 16bits of data to an integer we can give to the rest of the system. And, we happen to know how to 'manipulate' the data to get it in format of understandable integer. As we have these 16 bits in memory, aligned to 2 byte boundary - why shouldn't we just 'manipulate' the data and say - here we have your integer, please be my guest and use it? Well, I am keen to learn the 'correct bitwise type' you talk about - can you please explain me what this correct type for two 8bit integers is? Maybe I can improve. > >> + val = be16_to_cpu(*temp_raw); >> + >> + if (negative) { >> + /* >> + * Two's complement. I am not sure if all supported >> + * architectures actually use 2's complement represantation of >> + * signed ints. If yes, then we could just do the endianes >> + * conversion and say this is the s16 value. However, as I >> + * don't know, and as the conversion is pretty simple. let's >> + * just convert the signed 2's complement to absolute value and >> + * multiply by -1. >> + */ >> + val = ~val + 1; >> + val *= -1; >> + } >> + >> + *temp = val; >> + >> + return 0; >> +} > >> +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) >> +{ >> + int ret; >> + u8 raw[3]; >> + >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, >> + &raw[0], sizeof(raw)); >> + if (ret < 0) >> + return ret; >> + >> + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); >> + >> + return 0; >> +} > > ... > >> + /* The enum values map directly to register bits */ > > In this case assign _all_ values explicitly. Currently it's prone to errors > if somebody squeezed a value in between. Agree. This is a good practice. Thanks. (although, it shouldn't really matter here as nobody really should squeeze a value in between as enum is short and we have this just comment above). >> +enum bm1390_meas_mode { >> + BM1390_MEAS_MODE_STOP = 0x0, >> + BM1390_MEAS_MODE_1SHOT, >> + BM1390_MEAS_MODE_CONTINUOUS, >> +}; > > ... > >> + mutex_lock(&data->mutex); > > Wouldn't you like to start using cleanup.h? The new macro "thingee" for C++ destructor like constructs? TBH, I am not really in a rush with it for two reasons. 1) The syntax looks very alien to me. I would like to get some time to get used to it before voluntarily ending up maintaining a code using it. (I don't like practicing things upstream as practicing tends to include making more errors). 2. Related to 1). I am not (yet) convinced incorporating changes in stuff using these cleanups is easy. I'm a bit reserved and would like to see how things play out. 3. I expect I will get a few requests to backport the code to some older kernels used by some big customers. (I've been doing plenty of extra work when backporting my kernel improvements like regmap_irq stuff, linear ranges, regulator pickable ranges, gts-helpers to customer kernels to get my drivers working - or working around the lack of thiose features. I have been willing to pay this prize to get those helpers upstream for everyone to use. The cleanup.h however is there so it does not _need_ new users. I don't think _all_ existing drivers will be converted to use it so one more should probably not hurt. I think that in a year at least some customers will be using kernel containing the cleanup.h - so by latest then it is time for me to jump on that train. I hope I am used to reading those macros by then). > > ... > >> + /* >> + * We use 'continuous mode' even for raw read because according to the >> + * data-sheet an one-shot mode can't be used with IIR filter > > Missing period at the end. > >> + */ > > ... > >> + goto unlock_out; > > cleanup.h makes these goto:s unneeded. > > ... > >> + case IIO_CHAN_INFO_SCALE: >> + if (chan->type == IIO_TEMP) { >> + *val = 31; >> + *val2 = 250000; >> + >> + return IIO_VAL_INT_PLUS_MICRO; >> + } else if (chan->type == IIO_PRESSURE) { >> + *val = 0; >> + /* >> + * pressure in hPa is register value divided by 2048. >> + * This means kPa is 1/20480 times the register value, >> + * which equals to 48828.125 * 10 ^ -9 >> + * This is 48828.125 nano kPa. >> + * >> + * When we scale this using IIO_VAL_INT_PLUS_NANO we >> + * get 48828 - which means we lose some accuracy. Well, >> + * let's try to live with that. >> + */ >> + *val2 = 48828; >> + >> + return IIO_VAL_INT_PLUS_NANO; >> + } >> + >> + return -EINVAL; > > Why not switch-case like other drivers do? In my eyes avoiding the very simple if - else if does not warrant nested switches which look ugly to me. > >> + case IIO_CHAN_INFO_RAW: >> + ret = iio_device_claim_direct_mode(idev); >> + if (ret) >> + return ret; >> + >> + ret = bm1390_read_data(data, chan, val, val2); >> + iio_device_release_direct_mode(idev); > >> + if (!ret) >> + return IIO_VAL_INT; >> + >> + return ret; > > Why not usual pattern? > > if (ret) > return ret; I see your point, ok. > >> + default: >> + return -EINVAL; >> + } > > ... > >> + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); > >> + > > Unneeded blank line. > >> + if (smp_lvl > 4) { >> + /* >> + * Valid values should be 0, 1, 2, 3, 4 - rest are probably >> + * bit errors in I2C line. Don't overflow if this happens. >> + */ >> + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); >> + smp_lvl = 4; >> + } > >> + if (!smp_lvl) >> + return ret; > > This can be checked first as it's and error condition I wouldn't say it is an error condition. It just means there was no samples collected in buffer. and previous branch has > no side effects on this. Also, wouldn't be better to use error code explicitly? Yes. For the clarity we definitely should explicitly do "return 0" here. Thanks. > > ... > >> +static int bm1390_write_raw(struct iio_dev *idev, >> + struct iio_chan_spec const *chan, >> + int val, int val2, long mask) >> +{ >> + int ret; >> + >> + ret = iio_device_claim_direct_mode(idev); >> + if (ret) >> + return ret; > >> + switch (mask) { >> + default: >> + ret = -EINVAL; >> + } > > This needs a comment: Why we have a dead code. Oh, thanks! This really, rather requires a clean-up. It looks like a left over from the version where I supported setting the number of samples to average. > >> + iio_device_release_direct_mode(idev); >> + >> + return ret; >> +} > > ... > >> + /* >> + * Default to use IIR filter in "middle" mode. Also the AVE_NUM must >> + * be fixed when IIR is in use > > Missing period. > >> + */ > > ... > >> + ret = regmap_read(data->regmap, BM1390_REG_STATUS, >> + &dummy); > > This is perfectly one line even for fanatics of 80 characters limitation. > >> + if (ret || !dummy) >> + return IRQ_NONE; > > ... > >> + if (state) { >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); > > This ret is never used, what's going on here? Thanks. I need to revise this :) > >> + } else { >> + int dummy; >> + >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); >> + >> + /* >> + * We need to read the status register in order to ACK the >> + * data-ready which may have been generated just before we >> + * disabled the measurement. >> + */ >> + if (!ret) >> + ret = regmap_read(data->regmap, BM1390_REG_STATUS, >> + &dummy); >> + } >> + >> + ret = bm1390_set_drdy_irq(data, state); >> + if (ret) >> + goto unlock_out; > >> + >> + > > One blank line is enough. > >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; > >> + > > We do not put blank lines at the end of functions. > >> +} > > ... > >> + ret = devm_iio_triggered_buffer_setup(data->dev, idev, >> + &iio_pollfunc_store_time, >> + &bm1390_trigger_handler, >> + &bm1390_buffer_ops); > >> + > > Yet another redundant blank line. I dunno how you manage to almost in every > second attempt to randomly place blank lines here and there... I feel like > a conspiracy theory against myself :-) Oh, dang. My plot is revealed :) > >> + if (ret) >> + return dev_err_probe(data->dev, ret, >> + "iio_triggered_buffer_setup FAIL\n"); > > ... > >> + >> + > > Ditto. > >> + ret = devm_iio_trigger_register(data->dev, itrig); >> + if (ret) >> + return dev_err_probe(data->dev, ret, >> + "Trigger registration failed\n"); > >> + >> + > > Ditto. > >> + return ret; > > ... > >> + ret = devm_iio_device_register(dev, idev); >> + if (ret < 0) >> + return dev_err_probe(dev, ret, >> + "Unable to register iio device\n"); >> + > >> + return ret; > > Do you expect anything than 0 here? No, not really. Thanks! Yours, -- Matti
On Thu, Sep 07, 2023 at 08:57:17AM +0300, Matti Vaittinen wrote: > On 9/6/23 18:48, Andy Shevchenko wrote: > > On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: ... > > > +struct bm1390_data { > > > + int64_t timestamp, old_timestamp; > > > > Out of a sudden int64_t instead of u64? > > Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), IIO > operates with signed timestamps. One being s64, the other int64_t. > > > > + struct iio_trigger *trig; > > > + struct regmap *regmap; > > > + struct device *dev; > > > + struct bm1390_data_buf buf; > > > + int irq; > > > + unsigned int state; > > > + bool trigger_enabled; > > > > > + u8 watermark; > > > > Or u8 instead of uint8_t? > > So, uint8_t is preferred? I don't really care all that much which of these > to use - which may even show up as a lack of consistency... I think I did > use uint8_t when I learned about it - but at some point someone somewhere > asked me to use u8 instead.. This somewhere might have been u-boot though... > > So, are you Suggesting I should replace u8 with uint8_t? Can do if it > matters. Consistency matters, since I do not know the intention behind, I suggest use either, but be consistent in the entire code. However, uXX are specific Linux kernel internal types and some maintainers prefer them. Also you may grep for the frequency of intXX_t vs. sXX or their unsigned counterparts. > > > + /* Prevent accessing sensor during FIFO read sequence */ > > > + struct mutex mutex; > > > +}; ... > > > +static int bm1390_read_temp(struct bm1390_data *data, int *temp) > > > +{ > > > + u8 temp_reg[2] __aligned(2); > > > > Why?! Just use proper bitwise type. > > What is the proper bitwise type in this case? > > I'll explain my reasoning: > What we really have in hardware (BM1390) and read from it is 8bit registers. > This is u8 to me. And as we read two consecutive registers, we use u8 > arr[2]. In my eyes it describes the data perfectly well, right? Two different registers?! Why bulk is used in that case? To me looks like you are reading 16-bit (or one that fits in 16-bit) register in BE notation. > > > + __be16 *temp_raw; > > > + int ret; > > > + s16 val; > > > + bool negative; > > > + > > > + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, > > > + sizeof(temp_reg)); > > > + if (ret) > > > + return ret; > > > + > > > + if (temp_reg[0] & 0x80) > > > + negative = true; > > > + else > > > + negative = false; > > > > > + temp_raw = (__be16 *)&temp_reg[0]; > > > > Heck no. Make temp_reg be properly typed. > > As I explained above, to me it seems ur arr[2} is _the_ proper type to > represent data we read from the device. > > What we need to do is to convert the 16bits of data to an integer we can > give to the rest of the system. And, we happen to know how to 'manipulate' > the data to get it in format of understandable integer. As we have these 16 > bits in memory, aligned to 2 byte boundary - why shouldn't we just > 'manipulate' the data and say - here we have your integer, please be my > guest and use it? Because it smell like a hack and is a hack here. Either it's a single BE16 register, or it's two different registers that by very unknown reason you are reading in a bulk. The code in this form is no go. > Well, I am keen to learn the 'correct bitwise type' you talk about - can you > please explain me what this correct type for two 8bit integers is? Maybe I > can improve. If the registers are not of the same nature the bulk access is wrong. Use one by one reads. > > > + val = be16_to_cpu(*temp_raw); > > > + > > > + if (negative) { > > > + /* > > > + * Two's complement. I am not sure if all supported > > > + * architectures actually use 2's complement represantation of > > > + * signed ints. If yes, then we could just do the endianes > > > + * conversion and say this is the s16 value. However, as I > > > + * don't know, and as the conversion is pretty simple. let's > > > + * just convert the signed 2's complement to absolute value and > > > + * multiply by -1. > > > + */ > > > + val = ~val + 1; > > > + val *= -1; > > > + } > > > + > > > + *temp = val; > > > + > > > + return 0; > > > +} ... > > > +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) > > > +{ > > > + int ret; > > > + u8 raw[3]; > > > + > > > + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, > > > + &raw[0], sizeof(raw)); &raw[0] --> raw > > > + if (ret < 0) > > > + return ret; > > > + > > > + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); This, btw, looks like le24, but I'm puzzled with right shift. I need to read datasheet carefully to understand this. > > > + return 0; > > > +} ... > > > + /* The enum values map directly to register bits */ > > > > In this case assign _all_ values explicitly. Currently it's prone to errors > > if somebody squeezed a value in between. > > Agree. This is a good practice. Thanks. (although, it shouldn't really > matter here as nobody really should squeeze a value in between as enum is > short and we have this just comment above). Right, but code can be done more robust against these. I do not see any argument against this. It's cheap and correct to add assignments and then we do not care about the sequence, even if somebody messes it up. > > > +enum bm1390_meas_mode { > > > + BM1390_MEAS_MODE_STOP = 0x0, > > > + BM1390_MEAS_MODE_1SHOT, > > > + BM1390_MEAS_MODE_CONTINUOUS, > > > +}; ... > > > + mutex_lock(&data->mutex); > > > > Wouldn't you like to start using cleanup.h? > > The new macro "thingee" for C++ destructor like constructs? I was talking about these: guard() / scoped_guard(). > TBH, I am not really in a rush with it for two reasons. > 1) The syntax looks very alien to me. I would like to get some time to get > used to it before voluntarily ending up maintaining a code using it. (I > don't like practicing things upstream as practicing tends to include making > more errors). > > 2. Related to 1). I am not (yet) convinced incorporating changes in stuff > using these cleanups is easy. I'm a bit reserved and would like to see how > things play out. > > 3. I expect I will get a few requests to backport the code to some older > kernels used by some big customers. (I've been doing plenty of extra work > when backporting my kernel improvements like regmap_irq stuff, linear > ranges, regulator pickable ranges, gts-helpers to customer kernels to get my > drivers working - or working around the lack of thiose features. I have been > willing to pay this prize to get those helpers upstream for everyone to use. > The cleanup.h however is there so it does not _need_ new users. I don't > think _all_ existing drivers will be converted to use it so one more should > probably not hurt. I think that in a year at least some customers will be > using kernel containing the cleanup.h - so by latest then it is time for me > to jump on that train. I hope I am used to reading those macros by then). OK. ... > > > + case IIO_CHAN_INFO_SCALE: > > > + if (chan->type == IIO_TEMP) { > > > + *val = 31; > > > + *val2 = 250000; > > > + > > > + return IIO_VAL_INT_PLUS_MICRO; > > > + } else if (chan->type == IIO_PRESSURE) { > > > + *val = 0; > > > + /* > > > + * pressure in hPa is register value divided by 2048. > > > + * This means kPa is 1/20480 times the register value, > > > + * which equals to 48828.125 * 10 ^ -9 > > > + * This is 48828.125 nano kPa. > > > + * > > > + * When we scale this using IIO_VAL_INT_PLUS_NANO we > > > + * get 48828 - which means we lose some accuracy. Well, > > > + * let's try to live with that. > > > + */ > > > + *val2 = 48828; > > > + > > > + return IIO_VAL_INT_PLUS_NANO; > > > + } > > > + > > > + return -EINVAL; > > > > Why not switch-case like other drivers do? > > In my eyes avoiding the very simple if - else if does not warrant nested > switches which look ugly to me. Okay, yet another disagreement. > > > + case IIO_CHAN_INFO_RAW: > > > + ret = iio_device_claim_direct_mode(idev); > > > + if (ret) > > > + return ret; > > > + > > > + ret = bm1390_read_data(data, chan, val, val2); > > > + iio_device_release_direct_mode(idev); > > > > > + if (!ret) > > > + return IIO_VAL_INT; > > > + > > > + return ret; > > > > Why not usual pattern? > > > > if (ret) > > return ret; > > I see your point, ok. > > > > + default: > > > + return -EINVAL; > > > + } ... > > > + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); > > > > > + > > > > Unneeded blank line. > > > > > + if (smp_lvl > 4) { > > > + /* > > > + * Valid values should be 0, 1, 2, 3, 4 - rest are probably > > > + * bit errors in I2C line. Don't overflow if this happens. > > > + */ > > > + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); > > > + smp_lvl = 4; > > > + } > > > > > + if (!smp_lvl) > > > + return ret; > > > > This can be checked first as it's and error condition > > I wouldn't say it is an error condition. Returning ret suggests otherwise. > It just means there was no samples > collected in buffer. But as you explained below, the code is actually 0 there. In any case bailing out conditionals are better to be first. > and previous branch has > > no side effects on this. Also, wouldn't be better to use error code explicitly? > > Yes. For the clarity we definitely should explicitly do "return 0" here. > Thanks.
On 9/7/23 16:57, Andy Shevchenko wrote: > On Thu, Sep 07, 2023 at 08:57:17AM +0300, Matti Vaittinen wrote: >> On 9/6/23 18:48, Andy Shevchenko wrote: >>> On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: > > ... > >>>> +struct bm1390_data { >>>> + int64_t timestamp, old_timestamp; >>> >>> Out of a sudden int64_t instead of u64? >> >> Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), IIO >> operates with signed timestamps. One being s64, the other int64_t. >> >>>> + struct iio_trigger *trig; >>>> + struct regmap *regmap; >>>> + struct device *dev; >>>> + struct bm1390_data_buf buf; >>>> + int irq; >>>> + unsigned int state; >>>> + bool trigger_enabled; >>> >>>> + u8 watermark; >>> >>> Or u8 instead of uint8_t? >> >> So, uint8_t is preferred? I don't really care all that much which of these >> to use - which may even show up as a lack of consistency... I think I did >> use uint8_t when I learned about it - but at some point someone somewhere >> asked me to use u8 instead.. This somewhere might have been u-boot though... >> >> So, are you Suggesting I should replace u8 with uint8_t? Can do if it >> matters. > > Consistency matters, since I do not know the intention behind, I suggest use > either, but be consistent in the entire code. However, uXX are specific Linux > kernel internal types and some maintainers prefer them. Also you may grep for > the frequency of intXX_t vs. sXX or their unsigned counterparts. > >>>> + /* Prevent accessing sensor during FIFO read sequence */ >>>> + struct mutex mutex; >>>> +}; > > ... > >>>> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) >>>> +{ >>>> + u8 temp_reg[2] __aligned(2); >>> >>> Why?! Just use proper bitwise type. >> >> What is the proper bitwise type in this case? >> >> I'll explain my reasoning: >> What we really have in hardware (BM1390) and read from it is 8bit registers. >> This is u8 to me. And as we read two consecutive registers, we use u8 >> arr[2]. In my eyes it describes the data perfectly well, right? > > Two different registers?! Why bulk is used in that case? > To me looks like you are reading 16-bit (or one that fits in 16-bit) register > in BE notation. As I wrote, it is two 8 bit registers at consecutive addresses. And this is what u8 arr[2]; also says. Bulk read is mandatory as HW has a special feature of preventing the update of these registers when a read is ongoing. If we do two reads we risk of getting one of the registers updated between the accesses - resulting incorrect value. > >>>> + __be16 *temp_raw; >>>> + int ret; >>>> + s16 val; >>>> + bool negative; >>>> + >>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, >>>> + sizeof(temp_reg)); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + if (temp_reg[0] & 0x80) >>>> + negative = true; >>>> + else >>>> + negative = false; >>> >>>> + temp_raw = (__be16 *)&temp_reg[0]; >>> >>> Heck no. Make temp_reg be properly typed. >> >> As I explained above, to me it seems ur arr[2} is _the_ proper type to >> represent data we read from the device. >> >> What we need to do is to convert the 16bits of data to an integer we can >> give to the rest of the system. And, we happen to know how to 'manipulate' >> the data to get it in format of understandable integer. As we have these 16 >> bits in memory, aligned to 2 byte boundary - why shouldn't we just >> 'manipulate' the data and say - here we have your integer, please be my >> guest and use it? > > Because it smell like a hack and is a hack here. > Either it's a single BE16 register, or it's two different registers that by > very unknown reason you are reading in a bulk. It is two registers. The bulk read might warrant a comment - although I believe this is nothing unusual. If it is a hack or not is an opinion. To me it looks like a code that explicitly shows what data is and how it is being handled. It does what it is supposed to do and shows it in all dirty details. Still, I am open to suggestions but I'd prefer seeing a real improvement instead of claiming that the hardware is something it is not (eg, having 16bit registers or should be read by individual accesses). The code in this form is no > go. > >> Well, I am keen to learn the 'correct bitwise type' you talk about - can you >> please explain me what this correct type for two 8bit integers is? Maybe I >> can improve. > > If the registers are not of the same nature the bulk access is wrong. > Use one by one reads. Of same nature? As I said, there is 2 8bit registers at consecutive addresses. They have no other 'nature' as far as I can tell. Data in these registers in not in standard format - it needs to be manipulated to make it an ordinary integer. The code shows this very clearly by not reading it in any standard integer. > ... > >>>> +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) >>>> +{ >>>> + int ret; >>>> + u8 raw[3]; >>>> + >>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, >>>> + &raw[0], sizeof(raw)); > > &raw[0] --> raw > >>>> + if (ret < 0) >>>> + return ret; >>>> + >>>> + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); > > This, btw, looks like le24, but I'm puzzled with right shift. > I need to read datasheet carefully to understand this. It's not just le24. We, again, have data placed in registers so that it needs some suffling. The data-sheet does decent job explaining it though. AFAIR, there was a 'gap' in bits so it needed some more suffling to sift the bits so that they're consecutive. I think this indeed is something that needs to be looked up from data-sheet to understand why this play with bits is done. > ... > >>>> + mutex_lock(&data->mutex); >>> >>> Wouldn't you like to start using cleanup.h? >> >> The new macro "thingee" for C++ destructor like constructs? > > I was talking about these: guard() / scoped_guard(). Right, this was a bit more precise than "The new macro thingee", thanks :) This, however is what I was referring to so what I wrote below still applies :) > >> TBH, I am not really in a rush with it for two reasons. >> 1) The syntax looks very alien to me. I would like to get some time to get >> used to it before voluntarily ending up maintaining a code using it. (I >> don't like practicing things upstream as practicing tends to include making >> more errors). >> >> 2. Related to 1). I am not (yet) convinced incorporating changes in stuff >> using these cleanups is easy. I'm a bit reserved and would like to see how >> things play out. >> >> 3. I expect I will get a few requests to backport the code to some older >> kernels used by some big customers. (I've been doing plenty of extra work >> when backporting my kernel improvements like regmap_irq stuff, linear >> ranges, regulator pickable ranges, gts-helpers to customer kernels to get my >> drivers working - or working around the lack of thiose features. I have been >> willing to pay this prize to get those helpers upstream for everyone to use. >> The cleanup.h however is there so it does not _need_ new users. I don't >> think _all_ existing drivers will be converted to use it so one more should >> probably not hurt. I think that in a year at least some customers will be >> using kernel containing the cleanup.h - so by latest then it is time for me >> to jump on that train. I hope I am used to reading those macros by then). > > OK. > > ... > >>>> + case IIO_CHAN_INFO_SCALE: >>>> + if (chan->type == IIO_TEMP) { >>>> + *val = 31; >>>> + *val2 = 250000; >>>> + >>>> + return IIO_VAL_INT_PLUS_MICRO; >>>> + } else if (chan->type == IIO_PRESSURE) { >>>> + *val = 0; >>>> + /* >>>> + * pressure in hPa is register value divided by 2048. >>>> + * This means kPa is 1/20480 times the register value, >>>> + * which equals to 48828.125 * 10 ^ -9 >>>> + * This is 48828.125 nano kPa. >>>> + * >>>> + * When we scale this using IIO_VAL_INT_PLUS_NANO we >>>> + * get 48828 - which means we lose some accuracy. Well, >>>> + * let's try to live with that. >>>> + */ >>>> + *val2 = 48828; >>>> + >>>> + return IIO_VAL_INT_PLUS_NANO; >>>> + } >>>> + >>>> + return -EINVAL; >>> >>> Why not switch-case like other drivers do? >> >> In my eyes avoiding the very simple if - else if does not warrant nested >> switches which look ugly to me. > > Okay, yet another disagreement. > Yes, we have a few :) Luckily most are more on a styling side of things. I do still appreciate you reviewing the patches as I think I do agree with most of your suggestions - and having an extra pair of eyes looking at the code never hurts :) > ... > >>>> + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); >>> >>>> + >>> >>> Unneeded blank line. >>> >>>> + if (smp_lvl > 4) { >>>> + /* >>>> + * Valid values should be 0, 1, 2, 3, 4 - rest are probably >>>> + * bit errors in I2C line. Don't overflow if this happens. >>>> + */ >>>> + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); >>>> + smp_lvl = 4; >>>> + } >>> >>>> + if (!smp_lvl) >>>> + return ret; >>> >>> This can be checked first as it's and error condition >> >> I wouldn't say it is an error condition. > > Returning ret suggests otherwise. Yes. I agree. > >> It just means there was no samples >> collected in buffer. > > But as you explained below, the code is actually 0 there. > In any case bailing out conditionals are better to be first. Kind of agree. Or by very least it should be else if. But as you said, early return is probably better here, thanks. > >> and previous branch has >>> no side effects on this. Also, wouldn't be better to use error code explicitly? >> >> Yes. For the clarity we definitely should explicitly do "return 0" here. >> Thanks. >
On 9/7/23 16:57, Andy Shevchenko wrote: > On Thu, Sep 07, 2023 at 08:57:17AM +0300, Matti Vaittinen wrote: >> On 9/6/23 18:48, Andy Shevchenko wrote: >>> On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: > > ... > >>>> +struct bm1390_data { >>>> + int64_t timestamp, old_timestamp; >>> >>> Out of a sudden int64_t instead of u64? >> >> Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), IIO >> operates with signed timestamps. One being s64, the other int64_t. >> >>>> + struct iio_trigger *trig; >>>> + struct regmap *regmap; >>>> + struct device *dev; >>>> + struct bm1390_data_buf buf; >>>> + int irq; >>>> + unsigned int state; >>>> + bool trigger_enabled; >>> >>>> + u8 watermark; >>> >>> Or u8 instead of uint8_t? >> >> So, uint8_t is preferred? I don't really care all that much which of these >> to use - which may even show up as a lack of consistency... I think I did >> use uint8_t when I learned about it - but at some point someone somewhere >> asked me to use u8 instead.. This somewhere might have been u-boot though... >> >> So, are you Suggesting I should replace u8 with uint8_t? Can do if it >> matters. > > Consistency matters, since I do not know the intention behind, I suggest use > either, but be consistent in the entire code. However, uXX are specific Linux > kernel internal types and some maintainers prefer them. Also you may grep for > the frequency of intXX_t vs. sXX or their unsigned counterparts. > >>>> + /* Prevent accessing sensor during FIFO read sequence */ >>>> + struct mutex mutex; >>>> +}; > > ... > >>>> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) >>>> +{ >>>> + u8 temp_reg[2] __aligned(2); >>> >>> Why?! Just use proper bitwise type. >> >> What is the proper bitwise type in this case? >> >> I'll explain my reasoning: >> What we really have in hardware (BM1390) and read from it is 8bit registers. >> This is u8 to me. And as we read two consecutive registers, we use u8 >> arr[2]. In my eyes it describes the data perfectly well, right? > > Two different registers?! Why bulk is used in that case? > To me looks like you are reading 16-bit (or one that fits in 16-bit) register > in BE notation. As I wrote, it is two 8 bit registers at consecutive addresses. And this is what u8 arr[2]; also says. Bulk read is mandatory as HW has a special feature of preventing the update of these registers when a read is ongoing. If we do two reads we risk of getting one of the registers updated between the accesses - resulting incorrect value. > >>>> + __be16 *temp_raw; >>>> + int ret; >>>> + s16 val; >>>> + bool negative; >>>> + >>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, >>>> + sizeof(temp_reg)); >>>> + if (ret) >>>> + return ret; >>>> + >>>> + if (temp_reg[0] & 0x80) >>>> + negative = true; >>>> + else >>>> + negative = false; >>> >>>> + temp_raw = (__be16 *)&temp_reg[0]; >>> >>> Heck no. Make temp_reg be properly typed. >> >> As I explained above, to me it seems ur arr[2} is _the_ proper type to >> represent data we read from the device. >> >> What we need to do is to convert the 16bits of data to an integer we can >> give to the rest of the system. And, we happen to know how to 'manipulate' >> the data to get it in format of understandable integer. As we have these 16 >> bits in memory, aligned to 2 byte boundary - why shouldn't we just >> 'manipulate' the data and say - here we have your integer, please be my >> guest and use it? > > Because it smell like a hack and is a hack here. > Either it's a single BE16 register, or it's two different registers that by > very unknown reason you are reading in a bulk. It is two registers. The bulk read might warrant a comment - although I believe this is nothing unusual. If it is a hack or not is an opinion. To me it looks like a code that explicitly shows what data is and how it is being handled. It does what it is supposed to do and shows it in all dirty details. Still, I am open to suggestions but I'd prefer seeing a real improvement instead of claiming that the hardware is something it is not (eg, having 16bit registers or should be read by individual accesses). The code in this form is no > go. > >> Well, I am keen to learn the 'correct bitwise type' you talk about - can you >> please explain me what this correct type for two 8bit integers is? Maybe I >> can improve. > > If the registers are not of the same nature the bulk access is wrong. > Use one by one reads. Of same nature? As I said, there is 2 8bit registers at consecutive addresses. They have no other 'nature' as far as I can tell. Data in these registers in not in standard format - it needs to be manipulated to make it an ordinary integer. The code shows this very clearly by not reading it in any standard integer. > ... > >>>> +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) >>>> +{ >>>> + int ret; >>>> + u8 raw[3]; >>>> + >>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, >>>> + &raw[0], sizeof(raw)); > > &raw[0] --> raw > >>>> + if (ret < 0) >>>> + return ret; >>>> + >>>> + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); > > This, btw, looks like le24, but I'm puzzled with right shift. > I need to read datasheet carefully to understand this. It's not just le24. We, again, have data placed in registers so that it needs some suffling. The data-sheet does decent job explaining it though. AFAIR, there was a 'gap' in bits so it needed some more suffling to sift the bits so that they're consecutive. I think this indeed is something that needs to be looked up from data-sheet to understand why this play with bits is done. > ... > >>>> + mutex_lock(&data->mutex); >>> >>> Wouldn't you like to start using cleanup.h? >> >> The new macro "thingee" for C++ destructor like constructs? > > I was talking about these: guard() / scoped_guard(). Right, this was a bit more precise than "The new macro thingee", thanks :) This, however is what I was referring to so what I wrote below still applies :) > >> TBH, I am not really in a rush with it for two reasons. >> 1) The syntax looks very alien to me. I would like to get some time to get >> used to it before voluntarily ending up maintaining a code using it. (I >> don't like practicing things upstream as practicing tends to include making >> more errors). >> >> 2. Related to 1). I am not (yet) convinced incorporating changes in stuff >> using these cleanups is easy. I'm a bit reserved and would like to see how >> things play out. >> >> 3. I expect I will get a few requests to backport the code to some older >> kernels used by some big customers. (I've been doing plenty of extra work >> when backporting my kernel improvements like regmap_irq stuff, linear >> ranges, regulator pickable ranges, gts-helpers to customer kernels to get my >> drivers working - or working around the lack of thiose features. I have been >> willing to pay this prize to get those helpers upstream for everyone to use. >> The cleanup.h however is there so it does not _need_ new users. I don't >> think _all_ existing drivers will be converted to use it so one more should >> probably not hurt. I think that in a year at least some customers will be >> using kernel containing the cleanup.h - so by latest then it is time for me >> to jump on that train. I hope I am used to reading those macros by then). > > OK. > > ... > >>>> + case IIO_CHAN_INFO_SCALE: >>>> + if (chan->type == IIO_TEMP) { >>>> + *val = 31; >>>> + *val2 = 250000; >>>> + >>>> + return IIO_VAL_INT_PLUS_MICRO; >>>> + } else if (chan->type == IIO_PRESSURE) { >>>> + *val = 0; >>>> + /* >>>> + * pressure in hPa is register value divided by 2048. >>>> + * This means kPa is 1/20480 times the register value, >>>> + * which equals to 48828.125 * 10 ^ -9 >>>> + * This is 48828.125 nano kPa. >>>> + * >>>> + * When we scale this using IIO_VAL_INT_PLUS_NANO we >>>> + * get 48828 - which means we lose some accuracy. Well, >>>> + * let's try to live with that. >>>> + */ >>>> + *val2 = 48828; >>>> + >>>> + return IIO_VAL_INT_PLUS_NANO; >>>> + } >>>> + >>>> + return -EINVAL; >>> >>> Why not switch-case like other drivers do? >> >> In my eyes avoiding the very simple if - else if does not warrant nested >> switches which look ugly to me. > > Okay, yet another disagreement. > Yes, we have a few :) Luckily most are more on a styling side of things. I do still appreciate you reviewing the patches as I think I do agree with most of your suggestions - and having an extra pair of eyes looking at the code never hurts :) > ... > >>>> + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); >>> >>>> + >>> >>> Unneeded blank line. >>> >>>> + if (smp_lvl > 4) { >>>> + /* >>>> + * Valid values should be 0, 1, 2, 3, 4 - rest are probably >>>> + * bit errors in I2C line. Don't overflow if this happens. >>>> + */ >>>> + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); >>>> + smp_lvl = 4; >>>> + } >>> >>>> + if (!smp_lvl) >>>> + return ret; >>> >>> This can be checked first as it's and error condition >> >> I wouldn't say it is an error condition. > > Returning ret suggests otherwise. Yes. I agree. > >> It just means there was no samples >> collected in buffer. > > But as you explained below, the code is actually 0 there. > In any case bailing out conditionals are better to be first. Kind of agree. Or by very least it should be else if. But as you said, early return is probably better here, thanks. > >> and previous branch has >>> no side effects on this. Also, wouldn't be better to use error code explicitly? >> >> Yes. For the clarity we definitely should explicitly do "return 0" here. >> Thanks. >
On Thu, 7 Sep 2023 08:57:17 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > Morning Andy, > > Thanks for the review. > > On 9/6/23 18:48, Andy Shevchenko wrote: > > On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: > >> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure > >> pressures ranging from 300 hPa to 1300 hPa with configurable measurement > >> averaging and internal FIFO. The sensor does also provide temperature > >> measurements. > >> > >> Sensor does also contain IIR filter implemented in HW. The data-sheet > >> says the IIR filter can be configured to be "weak", "middle" or > >> "strong". Some RMS noise figures are provided in data sheet but no > >> accurate maths for the filter configurations is provided. Hence, the IIR > >> filter configuration is not supported by this driver and the filter is > >> configured to the "middle" setting (at least not for now). > >> > >> The FIFO measurement mode is only measuring the pressure and not the > >> temperature. The driver measures temperature when FIFO is flushed and > >> simply uses the same measured temperature value to all reported > >> temperatures. This should not be a problem when temperature is not > >> changing very rapidly (several degrees C / second) but allows users to > >> get the temperature measurements from sensor without any additional logic. > > > > ... > > > > > >> +struct bm1390_data { > >> + int64_t timestamp, old_timestamp; > > > > Out of a sudden int64_t instead of u64? > > Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), > IIO operates with signed timestamps. One being s64, the other int64_t. That's odd. Ah well. Should both be s64 as internal to the kernel only. > > >> + struct iio_trigger *trig; > >> + struct regmap *regmap; > >> + struct device *dev; > >> + struct bm1390_data_buf buf; > >> + int irq; > >> + unsigned int state; > >> + bool trigger_enabled; > > > >> + u8 watermark; > > > > Or u8 instead of uint8_t? > > So, uint8_t is preferred? I don't really care all that much which of > these to use - which may even show up as a lack of consistency... I > think I did use uint8_t when I learned about it - but at some point > someone somewhere asked me to use u8 instead.. This somewhere might have > been u-boot though... > > So, are you Suggesting I should replace u8 with uint8_t? Can do if it > matters. u8 preferred for internal to kernel stuff, uint8_t if a userspace header.
On Fri, 8 Sep 2023 09:12:51 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 9/7/23 16:57, Andy Shevchenko wrote: > > On Thu, Sep 07, 2023 at 08:57:17AM +0300, Matti Vaittinen wrote: > >> On 9/6/23 18:48, Andy Shevchenko wrote: > >>> On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: > > > > ... > > > >>>> +struct bm1390_data { > >>>> + int64_t timestamp, old_timestamp; > >>> > >>> Out of a sudden int64_t instead of u64? > >> > >> Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), IIO > >> operates with signed timestamps. One being s64, the other int64_t. > >> > >>>> + struct iio_trigger *trig; > >>>> + struct regmap *regmap; > >>>> + struct device *dev; > >>>> + struct bm1390_data_buf buf; > >>>> + int irq; > >>>> + unsigned int state; > >>>> + bool trigger_enabled; > >>> > >>>> + u8 watermark; > >>> > >>> Or u8 instead of uint8_t? > >> > >> So, uint8_t is preferred? I don't really care all that much which of these > >> to use - which may even show up as a lack of consistency... I think I did > >> use uint8_t when I learned about it - but at some point someone somewhere > >> asked me to use u8 instead.. This somewhere might have been u-boot though... > >> > >> So, are you Suggesting I should replace u8 with uint8_t? Can do if it > >> matters. > > > > Consistency matters, since I do not know the intention behind, I suggest use > > either, but be consistent in the entire code. However, uXX are specific Linux > > kernel internal types and some maintainers prefer them. Also you may grep for > > the frequency of intXX_t vs. sXX or their unsigned counterparts. > > > >>>> + /* Prevent accessing sensor during FIFO read sequence */ > >>>> + struct mutex mutex; > >>>> +}; > > > > ... > > > >>>> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) > >>>> +{ > >>>> + u8 temp_reg[2] __aligned(2); > >>> > >>> Why?! Just use proper bitwise type. > >> > >> What is the proper bitwise type in this case? > >> > >> I'll explain my reasoning: > >> What we really have in hardware (BM1390) and read from it is 8bit registers. > >> This is u8 to me. And as we read two consecutive registers, we use u8 > >> arr[2]. In my eyes it describes the data perfectly well, right? > > > > Two different registers?! Why bulk is used in that case? > > To me looks like you are reading 16-bit (or one that fits in 16-bit) register > > in BE notation. > > As I wrote, it is two 8 bit registers at consecutive addresses. And this > is what u8 arr[2]; also says. > > Bulk read is mandatory as HW has a special feature of preventing the > update of these registers when a read is ongoing. If we do two reads we > risk of getting one of the registers updated between the accesses - > resulting incorrect value. Far as the kernel is concerned this is a __be16 and we use a bulk read to fill it from two registers. If the use showed them having unrelated uses then it would be fair to handle it as an array of u8. > > > > >>>> + __be16 *temp_raw; > >>>> + int ret; > >>>> + s16 val; > >>>> + bool negative; > >>>> + > >>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, > >>>> + sizeof(temp_reg)); > >>>> + if (ret) > >>>> + return ret; > >>>> + > >>>> + if (temp_reg[0] & 0x80) > >>>> + negative = true; > >>>> + else > >>>> + negative = false; > >>> > >>>> + temp_raw = (__be16 *)&temp_reg[0]; > >>> > >>> Heck no. Make temp_reg be properly typed. > >> > >> As I explained above, to me it seems ur arr[2} is _the_ proper type to > >> represent data we read from the device. > >> > >> What we need to do is to convert the 16bits of data to an integer we can > >> give to the rest of the system. And, we happen to know how to 'manipulate' > >> the data to get it in format of understandable integer. As we have these 16 > >> bits in memory, aligned to 2 byte boundary - why shouldn't we just > >> 'manipulate' the data and say - here we have your integer, please be my > >> guest and use it? > > > > Because it smell like a hack and is a hack here. > > Either it's a single BE16 register, or it's two different registers that by > > very unknown reason you are reading in a bulk. > > It is two registers. The bulk read might warrant a comment - although I > believe this is nothing unusual. If it is a hack or not is an opinion. > To me it looks like a code that explicitly shows what data is and how it > is being handled. It does what it is supposed to do and shows it in all > dirty details. Read it directly into a __be16 > > Still, I am open to suggestions but I'd prefer seeing a real improvement > instead of claiming that the hardware is something it is not (eg, having > 16bit registers or should be read by individual accesses). > > The code in this form is no > > go. > > > >> Well, I am keen to learn the 'correct bitwise type' you talk about - can you > >> please explain me what this correct type for two 8bit integers is? Maybe I > >> can improve. > > > > If the registers are not of the same nature the bulk access is wrong. > > Use one by one reads. > > Of same nature? As I said, there is 2 8bit registers at consecutive > addresses. They have no other 'nature' as far as I can tell. > > Data in these registers in not in standard format - it needs to be > manipulated to make it an ordinary integer. The code shows this very > clearly by not reading it in any standard integer. I'm not convinced it does. All support arch are 2s complement. be16_to_cpu() is fine for what you have unless I'm missing something. If it weren't we would have signed versions of those macros. > > > ... > > > >>>> +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) > >>>> +{ > >>>> + int ret; > >>>> + u8 raw[3]; > >>>> + > >>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, > >>>> + &raw[0], sizeof(raw)); > > > > &raw[0] --> raw > > > >>>> + if (ret < 0) > >>>> + return ret; > >>>> + > >>>> + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); > > > > This, btw, looks like le24, but I'm puzzled with right shift. > > I need to read datasheet carefully to understand this. > > It's not just le24. We, again, have data placed in registers so that it > needs some suffling. The data-sheet does decent job explaining it > though. AFAIR, there was a 'gap' in bits so it needed some more suffling > to sift the bits so that they're consecutive. I think this indeed is > something that needs to be looked up from data-sheet to understand why > this play with bits is done. These cases are harder to argue. I'm fine with either approach for this one as a get_unaligned_le24() >> 2 would give same answer unless I'm also missing something but it isn't that obvious. Jonathan
> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) > +{ > + u8 temp_reg[2] __aligned(2); > + __be16 *temp_raw; > + int ret; > + s16 val; > + bool negative; > + > + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, > + sizeof(temp_reg)); > + if (ret) > + return ret; > + > + if (temp_reg[0] & 0x80) > + negative = true; > + else > + negative = false; > + > + temp_raw = (__be16 *)&temp_reg[0]; > + val = be16_to_cpu(*temp_raw); > + > + if (negative) { > + /* > + * Two's complement. I am not sure if all supported > + * architectures actually use 2's complement represantation of AFAIK they do. Many IIO drivers would be broken if not.. > + * signed ints. If yes, then we could just do the endianes > + * conversion and say this is the s16 value. However, as I > + * don't know, and as the conversion is pretty simple. let's > + * just convert the signed 2's complement to absolute value and > + * multiply by -1. > + */ > + val = ~val + 1; > + val *= -1; > + } > + > + *temp = val; > + > + return 0; > +}
On Wed, 6 Sep 2023 15:37:48 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure > pressures ranging from 300 hPa to 1300 hPa with configurable measurement > averaging and internal FIFO. The sensor does also provide temperature > measurements. > > Sensor does also contain IIR filter implemented in HW. The data-sheet > says the IIR filter can be configured to be "weak", "middle" or > "strong". Some RMS noise figures are provided in data sheet but no > accurate maths for the filter configurations is provided. Hence, the IIR > filter configuration is not supported by this driver and the filter is > configured to the "middle" setting (at least not for now). *sigh* We all love fuzzily described filters... > > The FIFO measurement mode is only measuring the pressure and not the > temperature. The driver measures temperature when FIFO is flushed and > simply uses the same measured temperature value to all reported > temperatures. This should not be a problem when temperature is not > changing very rapidly (several degrees C / second) but allows users to > get the temperature measurements from sensor without any additional logic. IIRC this is a bit different from what we've typically done in the past where we just take the view that a slow moving thing like temperature can be read from sysfs or that enabling it disables the watermark. However, what you have seems like valid use of the ABI to me so I'm fine with this approach if it makes sense for your expected users (which you get to guess at ;) Given there are multiple ways of handling combination of FIFO hardware and triggers, it's good to add a little bit of info on that in this patch description (I misunderstood what you were doing initially) > diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c > new file mode 100644 > index 000000000000..2d51a99a58fc > --- /dev/null > +++ b/drivers/iio/pressure/rohm-bm1390.c > @@ -0,0 +1,944 @@ ... > + > +enum { > + BM1390_CHAN_PRESSURE, > + BM1390_CHAN_TEMP, > +}; > +static int bm1390_read_data(struct bm1390_data *data, > + struct iio_chan_spec const *chan, int *val, int *val2) > +{ > + int ret; > + > + *val2 = 0; Why? No need to pass val2 in or zero it if going to return IIO_VAL_INT to the IIO core. It's never used. > + > + mutex_lock(&data->mutex); > + /* > + * We use 'continuous mode' even for raw read because according to the > + * data-sheet an one-shot mode can't be used with IIR filter > + */ > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); > + if (ret) > + goto unlock_out; > + > + switch (chan->type) { > + case IIO_PRESSURE: > + msleep(BM1390_MAX_MEAS_TIME_MS); > + ret = bm1390_pressure_read(data, val); > + break; > + case IIO_TEMP: > + msleep(BM1390_MAX_MEAS_TIME_MS); > + ret = bm1390_read_temp(data, val); > + break; > + default: > + ret = -EINVAL; > + } > + bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > +} > + > +static int __bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples, > + bool irq) > +{ > + /* The fifo holds maximum of 4 samples */ Whilst useful info - why have comment here? > + struct bm1390_data *data = iio_priv(idev); > + struct bm1390_data_buf buffer; > + int smp_lvl, ret, i; > + u64 sample_period; > + __be16 temp = 0; > + > + /* > + * If the IC is accessed during FIFO read samples can be dropped. > + * Prevent access until FIFO_LVL is read > + */ > + if (test_bit(BM1390_CHAN_TEMP, idev->active_scan_mask)) { > + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp, > + sizeof(temp)); > + if (ret) > + return ret; > + } > + > + ret = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); > + if (ret) > + return ret; > + > + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); > + > + if (smp_lvl > 4) { > + /* > + * Valid values should be 0, 1, 2, 3, 4 - rest are probably > + * bit errors in I2C line. Don't overflow if this happens. > + */ > + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); > + smp_lvl = 4; > + } > + > + if (!smp_lvl) > + return ret; > + > + sample_period = data->timestamp - data->old_timestamp; > + do_div(sample_period, smp_lvl); > + > + if (samples && smp_lvl > samples) > + smp_lvl = samples; > + > + for (i = 0; i < smp_lvl; i++) { > + ret = bm1390_pressure_read(data, &buffer.pressure); > + if (ret) > + break; > + > + buffer.temp = temp; > + /* > + * Old timestamp is either the previous sample IRQ time, > + * previous flush-time or, if this was first sample, the enable > + * time. When we add a sample period to that we should get the > + * best approximation of the time-stamp we are handling. > + * > + * Idea is to always keep the "old_timestamp" matching the > + * timestamp which we are currently handling. > + */ > + data->old_timestamp += sample_period; > + > + iio_push_to_buffers_with_timestamp(idev, &buffer, > + data->old_timestamp); > + } > + /* Reading the FIFO_LVL closes the FIFO access sequence */ > + regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); ret = > + > + if (!ret) > + return ret; > + > + return smp_lvl; > +} ... > +static int bm1390_write_raw(struct iio_dev *idev, > + struct iio_chan_spec const *chan, > + int val, int val2, long mask) > +{ > + int ret; > + > + ret = iio_device_claim_direct_mode(idev); > + if (ret) > + return ret; > + > + switch (mask) { > + default: > + ret = -EINVAL; ? > + } > + iio_device_release_direct_mode(idev); > + > + return ret; > +} > + > +static int bm1390_set_watermark(struct iio_dev *idev, unsigned int val) > +{ > + struct bm1390_data *data = iio_priv(idev); > + > + if (val < BM1390_WMI_MIN || val > BM1390_WMI_MAX) > + return -EINVAL; It's definitely possible to argue a watermark of 1 is also supported - just run in bypass mode with data ready interrupt. Not sure we care enough to make that supported in this interface though. Driver doesn't need to support everything possible. > + > + mutex_lock(&data->mutex); > + data->watermark = val; > + mutex_unlock(&data->mutex); > + > + return 0; > +} > + > +static const struct iio_info bm1390_info = { > + .read_raw = &bm1390_read_raw, > + .write_raw = &bm1390_write_raw, > + .validate_trigger = iio_validate_own_trigger, > + .hwfifo_set_watermark = bm1390_set_watermark, > + .hwfifo_flush_to_buffer = bm1390_fifo_flush, > +}; > + > +static int bm1390_chip_init(struct bm1390_data *data) > +{ > + int ret; > + > + ret = regmap_write_bits(data->regmap, BM1390_REG_POWER, > + BM1390_MASK_POWER, BM1390_POWER_ON); > + if (ret) > + return ret; > + > + msleep(1); > + > + ret = regmap_write_bits(data->regmap, BM1390_REG_RESET, > + BM1390_MASK_RESET, BM1390_RESET); > + if (ret) > + return ret; > + > + msleep(1); > + > + ret = regmap_write_bits(data->regmap, BM1390_REG_RESET, > + BM1390_MASK_RESET, BM1390_RESET_RELEASE); > + if (ret) > + return ret; > + > + msleep(1); > + > + ret = regmap_reinit_cache(data->regmap, &bm1390_regmap); > + if (ret) { > + dev_err(data->dev, "Failed to reinit reg cache\n"); > + return ret; > + } > + > + /* > + * Default to use IIR filter in "middle" mode. Also the AVE_NUM must > + * be fixed when IIR is in use > + */ > + ret = regmap_update_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_AVE_NUM, BM1390_IIR_AVE_NUM); > + if (ret) > + return ret; > + > + ret = regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_IIR_MODE, BM1390_IIR_MODE_MID); > + > + return ret; return regmap... > +} > + > +static int bm1390_fifo_set_wmi(struct bm1390_data *data) > +{ > + u8 regval; > + > + regval = data->watermark - BM1390_WMI_MIN; > + regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, regval); > + > + return regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_FIFO_LEN, regval); > +} > + > +static int bm1390_fifo_enable(struct iio_dev *idev) > +{ > + struct bm1390_data *data = iio_priv(idev); > + int ret; > + > + mutex_lock(&data->mutex); > + > + /* Update watermark to HW */ > + ret = bm1390_fifo_set_wmi(data); > + if (ret) > + goto unlock_out; > + > + /* Enable WMI_IRQ */ > + ret = regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_WMI_EN); check ret. > + /* Enable FIFO */ > + ret = regmap_set_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_FIFO_EN); > + if (ret) > + goto unlock_out; > + > + data->state = BM1390_STATE_FIFO; > + > + data->old_timestamp = iio_get_time_ns(idev); > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); > + > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > +} > + > +static int bm1390_fifo_disable(struct iio_dev *idev) > +{ > + struct bm1390_data *data = iio_priv(idev); > + int ret; > + > + msleep(1); > + > + mutex_lock(&data->mutex); > + /* Disable FIFO */ > + ret = regmap_clear_bits(data->regmap, BM1390_REG_FIFO_CTRL, > + BM1390_MASK_FIFO_EN); > + if (ret) > + goto unlock_out; > + > + data->state = BM1390_STATE_SAMPLE; > + > + /* Disable WMI_IRQ */ > + ret = regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_WMI_EN); > + if (ret) > + goto unlock_out; > + > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); > + > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > +} > + > +static int bm1390_buffer_postenable(struct iio_dev *idev) > +{ > + /* > + * If we use data-ready trigger, then the IRQ masks should be handled by > + * trigger enable and the hardware buffer is not used but we just update > + * results to the IIO fifo when data-ready triggers. FIFO > + */ > + if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) > + return 0; > + > + return bm1390_fifo_enable(idev); > +} > + > +static int bm1390_buffer_predisable(struct iio_dev *idev) > +{ > + if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) > + return 0; > + > + return bm1390_fifo_disable(idev); > +} > + > +static const struct iio_buffer_setup_ops bm1390_buffer_ops = { > + .postenable = bm1390_buffer_postenable, > + .predisable = bm1390_buffer_predisable, > +}; > + > +static irqreturn_t bm1390_trigger_handler(int irq, void *p) > +{ > + struct iio_poll_func *pf = p; > + struct iio_dev *idev = pf->indio_dev; > + struct bm1390_data *data = iio_priv(idev); > + int ret, dummy; > + > + /* DRDY is acked by reading status reg */ > + ret = regmap_read(data->regmap, BM1390_REG_STATUS, > + &dummy); I'd expect 'dummy' to be irrelevant data. Perhaps give it a better name if you are going to use the value like this. > + if (ret || !dummy) > + return IRQ_NONE; > + > + dev_dbg(data->dev, "DRDY trig status 0x%x\n", dummy); > + > + ret = bm1390_pressure_read(data, &data->buf.pressure); > + if (ret) { > + dev_warn(data->dev, "sample read failed %d\n", ret); > + return IRQ_NONE; As below. Still our interrupt even if we couldn't read the data As such, IRQ_HANDLED; is current reutrn value. > + } > + > + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, > + &data->buf.temp, BM1390_TEMP_SIZE); > + ret not checked. > + iio_push_to_buffers_with_timestamp(idev, &data->buf, data->timestamp); > + iio_trigger_notify_done(idev->trig); > + > + return IRQ_HANDLED; > +} > + > +/* Get timestamps and wake the thread if we need to read data */ > +static irqreturn_t bm1390_irq_handler(int irq, void *private) > +{ > + struct iio_dev *idev = private; > + struct bm1390_data *data = iio_priv(idev); > + > + data->timestamp = iio_get_time_ns(idev); > + > + if (data->state == BM1390_STATE_FIFO || data->trigger_enabled) > + return IRQ_WAKE_THREAD; > + > + return IRQ_NONE; > +} > + > +static irqreturn_t bm1390_irq_thread_handler(int irq, void *private) > +{ > + struct iio_dev *idev = private; > + struct bm1390_data *data = iio_priv(idev); > + int ret = IRQ_NONE; > + > + mutex_lock(&data->mutex); > + > + if (data->trigger_enabled) { > + iio_trigger_poll_nested(data->trig); > + ret = IRQ_HANDLED; > + } > + > + if (data->state == BM1390_STATE_FIFO) { Can this and trigger_enabled be true? > + int ok; > + > + ok = __bm1390_fifo_flush(idev, BM1390_TEMP_SIZE, true); > + if (ok > 0) > + ret = IRQ_HANDLED; An error should not result in IRQ_NONE. At most we tend to print an error message and return IRQ_HANDLED anyway to avoid the interrupt being treated as spurious. > + } > + > + mutex_unlock(&data->mutex); > + > + return ret; > +} > + > +static int bm1390_set_drdy_irq(struct bm1390_data *data, bool en) > +{ > + if (en) > + return regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_DRDY_EN); > + return regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, > + BM1390_MASK_DRDY_EN); > +} > + > +static int bm1390_trigger_set_state(struct iio_trigger *trig, > + bool state) > +{ > + struct bm1390_data *data = iio_trigger_get_drvdata(trig); > + int ret = 0; > + > + mutex_lock(&data->mutex); > + > + if (data->trigger_enabled == state) > + goto unlock_out; > + > + if (data->state == BM1390_STATE_FIFO) { > + dev_warn(data->dev, "Can't set trigger when FIFO enabled\n"); Why not? Spec reference ideally. I haven't gotten my head around this but I'd expect an attempt to set the trigger state to indicate that we don't want to use the fifo and as such it should be disabled in this path. > + ret = -EBUSY; > + goto unlock_out; > + } > + > + data->trigger_enabled = state; > + > + if (state) { > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); Is this a trigger characteristic? Feels more like a feature of enabling buffering. Ah well. That's always a blurry boundary so it is probably fine here. ret set but not checked... > + } else { > + int dummy; > + > + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); > + > + /* > + * We need to read the status register in order to ACK the > + * data-ready which may have been generated just before we > + * disabled the measurement. > + */ > + if (!ret) > + ret = regmap_read(data->regmap, BM1390_REG_STATUS, > + &dummy); Should check for errors in ret. > + } > + > + ret = bm1390_set_drdy_irq(data, state); > + if (ret) > + goto unlock_out; Not a lot of point in that :) > + > + > +unlock_out: > + mutex_unlock(&data->mutex); > + > + return ret; > + > +} > + > +static const struct iio_trigger_ops bm1390_trigger_ops = { > + .set_trigger_state = bm1390_trigger_set_state, > +}; > + > +static int bm1390_setup_trigger(struct bm1390_data *data, struct iio_dev *idev, > + int irq) > +{ > + struct iio_trigger *itrig; > + char *name; > + int ret; > + > + if (irq < 0) { > + dev_warn(data->dev, "No IRQ - skipping buffering\n"); I don't see that as deserving a warning. Device should be fine with out it. Maybe dev_info could be justified (just). > + return 0; > + } > + > + ret = devm_iio_triggered_buffer_setup(data->dev, idev, > + &iio_pollfunc_store_time, > + &bm1390_trigger_handler, > + &bm1390_buffer_ops); > + > + if (ret) > + return dev_err_probe(data->dev, ret, > + "iio_triggered_buffer_setup FAIL\n"); > + > + itrig = devm_iio_trigger_alloc(data->dev, "%sdata-rdy-dev%d", idev->name, > + iio_device_id(idev)); > + if (!itrig) > + return -ENOMEM; > + > + data->trig = itrig; > + idev->available_scan_masks = bm1390_scan_masks; > + > + itrig->ops = &bm1390_trigger_ops; > + iio_trigger_set_drvdata(itrig, data); > + > + /* > + * No need to check for NULL. request_threaded_irq() defaults to > + * dev_name() should the alloc fail. > + */ > + name = devm_kasprintf(data->dev, GFP_KERNEL, "%s-bm1390", > + dev_name(data->dev)); Whist true, checking for it is less code than not doing so and adding the comment. So I'd just check for it! > + > + ret = devm_request_threaded_irq(data->dev, irq, bm1390_irq_handler, > + &bm1390_irq_thread_handler, > + IRQF_ONESHOT, name, idev); > + if (ret) > + return dev_err_probe(data->dev, ret, "Could not request IRQ\n"); > + > + > + ret = devm_iio_trigger_register(data->dev, itrig); > + if (ret) > + return dev_err_probe(data->dev, ret, > + "Trigger registration failed\n"); > + > + > + return ret; return 0 as that's the only value and it's good to make it clear that was the intention in this path. > +} > + > +static int bm1390_probe(struct i2c_client *i2c) > +{ > + struct bm1390_data *data; > + struct regmap *regmap; > + struct iio_dev *idev; > + struct device *dev; > + unsigned int part_id; > + int ret; > + > + dev = &i2c->dev; > + > + regmap = devm_regmap_init_i2c(i2c, &bm1390_regmap); > + if (IS_ERR(regmap)) > + return dev_err_probe(dev, PTR_ERR(regmap), > + "Failed to initialize Regmap\n"); > + > + idev = devm_iio_device_alloc(dev, sizeof(*data)); > + if (!idev) > + return -ENOMEM; > + > + ret = devm_regulator_get_enable(dev, "vdd"); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to get regulator\n"); > + > + data = iio_priv(idev); > + > + ret = regmap_read(regmap, BM1390_REG_PART_ID, &part_id); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to access sensor\n"); > + > + if (part_id != BM1390_ID) > + dev_warn(dev, "unknown device 0x%x\n", part_id); > + > + data->regmap = regmap; > + data->dev = dev; > + data->irq = i2c->irq; > + /* > + * Default watermark to WMI_MAX. We could also allow setting WMI to 0, > + * and interpret that as "WMI is disabled, use FIFO_FULL" but I've > + * no idea what is assumed if watermark is 0. Does it mean each sample > + * should trigger IRQ, or no samples should do that? In my head at least, if we are using fifo_full it is still a watermark but one that matches size of buffer. I think for previous drivers we've had 0 and 1 both meaning it's a dataready interrupt (i.e. one entry in the fifo). That would be fine here as well and would correspond to putting the device in bypass mode. > + * > + * Well, for now we just allow BM1390_WMI_MIN to BM1390_WMI_MAX and > + * discard every other configuration when triggered mode is not used. > + */ > + data->watermark = BM1390_WMI_MAX; > + mutex_init(&data->mutex); > + > + idev->channels = bm1390_channels; > + idev->num_channels = ARRAY_SIZE(bm1390_channels); > + idev->name = "bm1390"; > + idev->info = &bm1390_info; > + idev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_SOFTWARE; The triggered buffer setup should set the second of these inside the IIO core code (as it always needs to be set if that code is called). > + > + ret = bm1390_chip_init(data); > + if (ret) > + return dev_err_probe(dev, ret, "sensor init failed\n"); > + > + ret = bm1390_setup_trigger(data, idev, i2c->irq); > + if (ret) > + return ret; > + > + ret = devm_iio_device_register(dev, idev); > + if (ret < 0) > + return dev_err_probe(dev, ret, > + "Unable to register iio device\n"); > + > + return ret; > +} > + > +static const struct of_device_id bm1390_of_match[] = { > + { .compatible = "rohm,bm1390glv-z" }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, bm1390_of_match); > + > +static const struct i2c_device_id bm1390_id[] = { > + { "bm1390glv-z", }, > + {} > +}; > +MODULE_DEVICE_TABLE(i2c, bm1390_id); > + > +static struct i2c_driver bm1390_driver = { > + .driver = { > + .name = "bm1390", > + .of_match_table = bm1390_of_match, > + .probe_type = PROBE_PREFER_ASYNCHRONOUS, I don't mind seeing this but I do want it to have a comment saying 'why'. I assume there is something really slow involved in probing this? > + }, > + .probe = bm1390_probe, > + .id_table = bm1390_id, > +}; > +module_i2c_driver(bm1390_driver); > + > +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>"); > +MODULE_DESCRIPTION("Driver for ROHM BM1390 pressure sensor"); > +MODULE_LICENSE("GPL");
On 9/8/23 21:45, Jonathan Cameron wrote: > >> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) >> +{ >> + u8 temp_reg[2] __aligned(2); >> + __be16 *temp_raw; >> + int ret; >> + s16 val; >> + bool negative; >> + >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, >> + sizeof(temp_reg)); >> + if (ret) >> + return ret; >> + >> + if (temp_reg[0] & 0x80) >> + negative = true; >> + else >> + negative = false; >> + >> + temp_raw = (__be16 *)&temp_reg[0]; >> + val = be16_to_cpu(*temp_raw); >> + >> + if (negative) { >> + /* >> + * Two's complement. I am not sure if all supported >> + * architectures actually use 2's complement represantation of > > AFAIK they do. Many IIO drivers would be broken if not.. Great. Then I think it means we really can treat the combined value of the registers as s16 BE. Should make this much simpler :) > >> + * signed ints. If yes, then we could just do the endianes >> + * conversion and say this is the s16 value. However, as I >> + * don't know, and as the conversion is pretty simple. let's >> + * just convert the signed 2's complement to absolute value and >> + * multiply by -1. >> + */ >> + val = ~val + 1; >> + val *= -1; >> + } >> + >> + *temp = val; >> + >> + return 0; >> +}
On 9/8/23 21:44, Jonathan Cameron wrote: > On Fri, 8 Sep 2023 09:12:51 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> On 9/7/23 16:57, Andy Shevchenko wrote: >>> On Thu, Sep 07, 2023 at 08:57:17AM +0300, Matti Vaittinen wrote: >>>> On 9/6/23 18:48, Andy Shevchenko wrote: >>>>> On Wed, Sep 06, 2023 at 03:37:48PM +0300, Matti Vaittinen wrote: >>> >>> ... >>> >>>>>> +struct bm1390_data { >>>>>> + int64_t timestamp, old_timestamp; >>>>> >>>>> Out of a sudden int64_t instead of u64? >>>> >>>> Judging the iio_push_to_buffers_with_timestamp() and iio_get_time_ns(), IIO >>>> operates with signed timestamps. One being s64, the other int64_t. >>>> >>>>>> + struct iio_trigger *trig; >>>>>> + struct regmap *regmap; >>>>>> + struct device *dev; >>>>>> + struct bm1390_data_buf buf; >>>>>> + int irq; >>>>>> + unsigned int state; >>>>>> + bool trigger_enabled; >>>>> >>>>>> + u8 watermark; >>>>> >>>>> Or u8 instead of uint8_t? >>>> >>>> So, uint8_t is preferred? I don't really care all that much which of these >>>> to use - which may even show up as a lack of consistency... I think I did >>>> use uint8_t when I learned about it - but at some point someone somewhere >>>> asked me to use u8 instead.. This somewhere might have been u-boot though... >>>> >>>> So, are you Suggesting I should replace u8 with uint8_t? Can do if it >>>> matters. >>> >>> Consistency matters, since I do not know the intention behind, I suggest use >>> either, but be consistent in the entire code. However, uXX are specific Linux >>> kernel internal types and some maintainers prefer them. Also you may grep for >>> the frequency of intXX_t vs. sXX or their unsigned counterparts. >>> >>>>>> + /* Prevent accessing sensor during FIFO read sequence */ >>>>>> + struct mutex mutex; >>>>>> +}; >>> >>> ... >>> >>>>>> +static int bm1390_read_temp(struct bm1390_data *data, int *temp) >>>>>> +{ >>>>>> + u8 temp_reg[2] __aligned(2); >>>>> >>>>> Why?! Just use proper bitwise type. >>>> >>>> What is the proper bitwise type in this case? >>>> >>>> I'll explain my reasoning: >>>> What we really have in hardware (BM1390) and read from it is 8bit registers. >>>> This is u8 to me. And as we read two consecutive registers, we use u8 >>>> arr[2]. In my eyes it describes the data perfectly well, right? >>> >>> Two different registers?! Why bulk is used in that case? >>> To me looks like you are reading 16-bit (or one that fits in 16-bit) register >>> in BE notation. >> >> As I wrote, it is two 8 bit registers at consecutive addresses. And this >> is what u8 arr[2]; also says. >> >> Bulk read is mandatory as HW has a special feature of preventing the >> update of these registers when a read is ongoing. If we do two reads we >> risk of getting one of the registers updated between the accesses - >> resulting incorrect value. > > Far as the kernel is concerned this is a __be16 and we use a bulk read to > fill it from two registers. If the use showed them having unrelated uses > then it would be fair to handle it as an array of u8. After you explained me that we don't need the extra hassle with the negative values (specific two's complement handling) - I do agree. If we needed to check the high bit in reg X to detect if special handling is required (as I thought) - then I would have still thought that checking the high bit from u8 which matches the spec would be much clearer. But yes - in this case, after your explanation - I do agree. Thanks :) > >> >>> >>>>>> + __be16 *temp_raw; >>>>>> + int ret; >>>>>> + s16 val; >>>>>> + bool negative; >>>>>> + >>>>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, >>>>>> + sizeof(temp_reg)); >>>>>> + if (ret) >>>>>> + return ret; >>>>>> + >>>>>> + if (temp_reg[0] & 0x80) >>>>>> + negative = true; >>>>>> + else >>>>>> + negative = false; >>>>> >>>>>> + temp_raw = (__be16 *)&temp_reg[0]; >>>>> >>>>> Heck no. Make temp_reg be properly typed. >>>> >>>> As I explained above, to me it seems ur arr[2} is _the_ proper type to >>>> represent data we read from the device. >>>> >>>> What we need to do is to convert the 16bits of data to an integer we can >>>> give to the rest of the system. And, we happen to know how to 'manipulate' >>>> the data to get it in format of understandable integer. As we have these 16 >>>> bits in memory, aligned to 2 byte boundary - why shouldn't we just >>>> 'manipulate' the data and say - here we have your integer, please be my >>>> guest and use it? >>> >>> Because it smell like a hack and is a hack here. >>> Either it's a single BE16 register, or it's two different registers that by >>> very unknown reason you are reading in a bulk. >> >> It is two registers. The bulk read might warrant a comment - although I >> believe this is nothing unusual. If it is a hack or not is an opinion. >> To me it looks like a code that explicitly shows what data is and how it >> is being handled. It does what it is supposed to do and shows it in all >> dirty details. > > Read it directly into a __be16 Yes. This makes sense also to me now that we don't really need the: >>>>>> + if (temp_reg[0] & 0x80) >>>>>> + negative = true; >>>>>> + else >>>>>> + negative = false; shown above. > >> >> Still, I am open to suggestions but I'd prefer seeing a real improvement >> instead of claiming that the hardware is something it is not (eg, having >> 16bit registers or should be read by individual accesses). >> >> The code in this form is no >>> go. >>> >>>> Well, I am keen to learn the 'correct bitwise type' you talk about - can you >>>> please explain me what this correct type for two 8bit integers is? Maybe I >>>> can improve. >>> >>> If the registers are not of the same nature the bulk access is wrong. >>> Use one by one reads. >> >> Of same nature? As I said, there is 2 8bit registers at consecutive >> addresses. They have no other 'nature' as far as I can tell. >> >> Data in these registers in not in standard format - it needs to be >> manipulated to make it an ordinary integer. The code shows this very >> clearly by not reading it in any standard integer. > > I'm not convinced it does. All support arch are 2s complement. > be16_to_cpu() is fine for what you have unless I'm missing something. > If it weren't we would have signed versions of those macros. No. You don't miss a thing. I didn't know if it's ok to treat i6bit two's complement just as a native 16bit signed integer. >>> ... >>> >>>>>> +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) >>>>>> +{ >>>>>> + int ret; >>>>>> + u8 raw[3]; >>>>>> + >>>>>> + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, >>>>>> + &raw[0], sizeof(raw)); >>> >>> &raw[0] --> raw >>> >>>>>> + if (ret < 0) >>>>>> + return ret; >>>>>> + >>>>>> + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); >>> >>> This, btw, looks like le24, but I'm puzzled with right shift. >>> I need to read datasheet carefully to understand this. >> >> It's not just le24. We, again, have data placed in registers so that it >> needs some suffling. The data-sheet does decent job explaining it >> though. AFAIR, there was a 'gap' in bits so it needed some more suffling >> to sift the bits so that they're consecutive. I think this indeed is >> something that needs to be looked up from data-sheet to understand why >> this play with bits is done. > > > These cases are harder to argue. I'm fine with either approach for this one > as a get_unaligned_le24() >> 2 would give same answer unless I'm also missing > something but it isn't that obvious. I need to look at the spec and the get_unaligned_le24() to be able to say something :) I wrote this code before my summer holidays but didn't have the time to test and send the patches until now. Will get back to this IC later this week. Thanks for the feedback guys! Yours, -- Matti
On 9/10/23 16:22, Jonathan Cameron wrote: > On Wed, 6 Sep 2023 15:37:48 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure >> pressures ranging from 300 hPa to 1300 hPa with configurable measurement >> averaging and internal FIFO. The sensor does also provide temperature >> measurements. >> >> Sensor does also contain IIR filter implemented in HW. The data-sheet >> says the IIR filter can be configured to be "weak", "middle" or >> "strong". Some RMS noise figures are provided in data sheet but no >> accurate maths for the filter configurations is provided. Hence, the IIR >> filter configuration is not supported by this driver and the filter is >> configured to the "middle" setting (at least not for now). > > *sigh* We all love fuzzily described filters... > >> >> The FIFO measurement mode is only measuring the pressure and not the >> temperature. The driver measures temperature when FIFO is flushed and >> simply uses the same measured temperature value to all reported >> temperatures. This should not be a problem when temperature is not >> changing very rapidly (several degrees C / second) but allows users to >> get the temperature measurements from sensor without any additional logic. > > IIRC this is a bit different from what we've typically done in the past > where we just take the view that a slow moving thing like temperature > can be read from sysfs or that enabling it disables the watermark. > > However, what you have seems like valid use of the ABI to me so I'm > fine with this approach if it makes sense for your expected users > (which you get to guess at ;) > > Given there are multiple ways of handling combination of FIFO hardware > and triggers, it's good to add a little bit of info on that in this > patch description (I misunderstood what you were doing initially) > My idea is that the sensor can either be used in two ways, 1. With trigger (data-ready IRQ). In this case the FIFO is not used as we get data ready for each collected sample. Instead, for each data-ready IRQ we read the sample from sensor and push it to the IIO buffer. 2. With hardware FIFO and watermark IRQ. In this case the data-ready is not used but we enable watermark IRQ. At each watermark IRQ we go and read all samples in FIFO and push them to the IIO buffer. Do you mean the commit message should explain this? >> diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c >> new file mode 100644 >> index 000000000000..2d51a99a58fc >> --- /dev/null >> +++ b/drivers/iio/pressure/rohm-bm1390.c >> @@ -0,0 +1,944 @@ > > ... > >> + >> +enum { >> + BM1390_CHAN_PRESSURE, >> + BM1390_CHAN_TEMP, >> +}; > >> +static int bm1390_read_data(struct bm1390_data *data, >> + struct iio_chan_spec const *chan, int *val, int *val2) >> +{ >> + int ret; >> + >> + *val2 = 0; > > Why? No need to pass val2 in or zero it if going to return IIO_VAL_INT to the > IIO core. It's never used. Ok > >> + >> + mutex_lock(&data->mutex); >> + /* >> + * We use 'continuous mode' even for raw read because according to the >> + * data-sheet an one-shot mode can't be used with IIR filter >> + */ >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); >> + if (ret) >> + goto unlock_out; >> + >> + switch (chan->type) { >> + case IIO_PRESSURE: >> + msleep(BM1390_MAX_MEAS_TIME_MS); >> + ret = bm1390_pressure_read(data, val); >> + break; >> + case IIO_TEMP: >> + msleep(BM1390_MAX_MEAS_TIME_MS); >> + ret = bm1390_read_temp(data, val); >> + break; >> + default: >> + ret = -EINVAL; >> + } >> + bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} > >> + >> +static int __bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples, >> + bool irq) >> +{ >> + /* The fifo holds maximum of 4 samples */ > > Whilst useful info - why have comment here? It really looks like it's missplaced. I may have suffled some code to other place without moving the comment. I'll drop or move it - thanks! > >> + struct bm1390_data *data = iio_priv(idev); >> + struct bm1390_data_buf buffer; >> + int smp_lvl, ret, i; >> + u64 sample_period; >> + __be16 temp = 0; >> + >> + /* >> + * If the IC is accessed during FIFO read samples can be dropped. >> + * Prevent access until FIFO_LVL is read >> + */ >> + if (test_bit(BM1390_CHAN_TEMP, idev->active_scan_mask)) { >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp, >> + sizeof(temp)); >> + if (ret) >> + return ret; >> + } >> + >> + ret = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); >> + if (ret) >> + return ret; >> + >> + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); >> + >> + if (smp_lvl > 4) { >> + /* >> + * Valid values should be 0, 1, 2, 3, 4 - rest are probably >> + * bit errors in I2C line. Don't overflow if this happens. >> + */ >> + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); >> + smp_lvl = 4; >> + } >> + >> + if (!smp_lvl) >> + return ret; >> + >> + sample_period = data->timestamp - data->old_timestamp; >> + do_div(sample_period, smp_lvl); >> + >> + if (samples && smp_lvl > samples) >> + smp_lvl = samples; >> + >> + for (i = 0; i < smp_lvl; i++) { >> + ret = bm1390_pressure_read(data, &buffer.pressure); >> + if (ret) >> + break; >> + >> + buffer.temp = temp; >> + /* >> + * Old timestamp is either the previous sample IRQ time, >> + * previous flush-time or, if this was first sample, the enable >> + * time. When we add a sample period to that we should get the >> + * best approximation of the time-stamp we are handling. >> + * >> + * Idea is to always keep the "old_timestamp" matching the >> + * timestamp which we are currently handling. >> + */ >> + data->old_timestamp += sample_period; >> + >> + iio_push_to_buffers_with_timestamp(idev, &buffer, >> + data->old_timestamp); >> + } >> + /* Reading the FIFO_LVL closes the FIFO access sequence */ >> + regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); > > ret = I didn't want to determine success of getting the data by success of this read. Instead, I wanted to ret to contain the success of reading the pressure in the for-loop. We might spill out a warning if this reads fails though. > >> + >> + if (!ret) >> + return ret; >> + >> + return smp_lvl; >> +} > > ... > >> +static int bm1390_write_raw(struct iio_dev *idev, >> + struct iio_chan_spec const *chan, >> + int val, int val2, long mask) >> +{ >> + int ret; >> + >> + ret = iio_device_claim_direct_mode(idev); >> + if (ret) >> + return ret; >> + >> + switch (mask) { >> + default: >> + ret = -EINVAL; > > ? Yeah :) This was forgotten when I dropped the OVERSAMPLING setting. Need to drop thw whole raw_write. > >> + } >> + iio_device_release_direct_mode(idev); >> + >> + return ret; >> +} >> + >> +static int bm1390_set_watermark(struct iio_dev *idev, unsigned int val) >> +{ >> + struct bm1390_data *data = iio_priv(idev); >> + >> + if (val < BM1390_WMI_MIN || val > BM1390_WMI_MAX) >> + return -EINVAL; > > It's definitely possible to argue a watermark of 1 is also supported - just > run in bypass mode with data ready interrupt. Not sure we care enough to > make that supported in this interface though. Driver doesn't need to > support everything possible. True. I'm not sure this is worth the complexity though. It'd mean we had to support DRDY when in FIFO mode - iff watermark is 1. Currently we don't need to bother the DRDY or FIFO disabling when in FIFO mode. >> + >> + mutex_lock(&data->mutex); >> + data->watermark = val; >> + mutex_unlock(&data->mutex); >> + >> + return 0; >> +} >> + >> +static const struct iio_info bm1390_info = { >> + .read_raw = &bm1390_read_raw, >> + .write_raw = &bm1390_write_raw, >> + .validate_trigger = iio_validate_own_trigger, >> + .hwfifo_set_watermark = bm1390_set_watermark, >> + .hwfifo_flush_to_buffer = bm1390_fifo_flush, >> +}; >> + >> +static int bm1390_chip_init(struct bm1390_data *data) >> +{ >> + int ret; >> + >> + ret = regmap_write_bits(data->regmap, BM1390_REG_POWER, >> + BM1390_MASK_POWER, BM1390_POWER_ON); >> + if (ret) >> + return ret; >> + >> + msleep(1); >> + >> + ret = regmap_write_bits(data->regmap, BM1390_REG_RESET, >> + BM1390_MASK_RESET, BM1390_RESET); >> + if (ret) >> + return ret; >> + >> + msleep(1); >> + >> + ret = regmap_write_bits(data->regmap, BM1390_REG_RESET, >> + BM1390_MASK_RESET, BM1390_RESET_RELEASE); >> + if (ret) >> + return ret; >> + >> + msleep(1); >> + >> + ret = regmap_reinit_cache(data->regmap, &bm1390_regmap); >> + if (ret) { >> + dev_err(data->dev, "Failed to reinit reg cache\n"); >> + return ret; >> + } >> + >> + /* >> + * Default to use IIR filter in "middle" mode. Also the AVE_NUM must >> + * be fixed when IIR is in use >> + */ >> + ret = regmap_update_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_AVE_NUM, BM1390_IIR_AVE_NUM); >> + if (ret) >> + return ret; >> + >> + ret = regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_IIR_MODE, BM1390_IIR_MODE_MID); >> + >> + return ret; > > return regmap... Ok. > >> +} >> + >> +static int bm1390_fifo_set_wmi(struct bm1390_data *data) >> +{ >> + u8 regval; >> + >> + regval = data->watermark - BM1390_WMI_MIN; >> + regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, regval); >> + >> + return regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_FIFO_LEN, regval); >> +} >> + >> +static int bm1390_fifo_enable(struct iio_dev *idev) >> +{ >> + struct bm1390_data *data = iio_priv(idev); >> + int ret; >> + >> + mutex_lock(&data->mutex); >> + >> + /* Update watermark to HW */ >> + ret = bm1390_fifo_set_wmi(data); >> + if (ret) >> + goto unlock_out; >> + >> + /* Enable WMI_IRQ */ >> + ret = regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_WMI_EN); > > check ret. > Yes. >> + /* Enable FIFO */ >> + ret = regmap_set_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_FIFO_EN); >> + if (ret) >> + goto unlock_out; >> + >> + data->state = BM1390_STATE_FIFO; >> + >> + data->old_timestamp = iio_get_time_ns(idev); >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); >> + >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} >> + >> +static int bm1390_fifo_disable(struct iio_dev *idev) >> +{ >> + struct bm1390_data *data = iio_priv(idev); >> + int ret; >> + >> + msleep(1); >> + >> + mutex_lock(&data->mutex); >> + /* Disable FIFO */ >> + ret = regmap_clear_bits(data->regmap, BM1390_REG_FIFO_CTRL, >> + BM1390_MASK_FIFO_EN); >> + if (ret) >> + goto unlock_out; >> + >> + data->state = BM1390_STATE_SAMPLE; >> + >> + /* Disable WMI_IRQ */ >> + ret = regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_WMI_EN); >> + if (ret) >> + goto unlock_out; >> + >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); >> + >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} >> + >> +static int bm1390_buffer_postenable(struct iio_dev *idev) >> +{ >> + /* >> + * If we use data-ready trigger, then the IRQ masks should be handled by >> + * trigger enable and the hardware buffer is not used but we just update >> + * results to the IIO fifo when data-ready triggers. > > FIFO > Ok >> + */ >> + if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) >> + return 0; >> + >> + return bm1390_fifo_enable(idev); >> +} >> + >> +static int bm1390_buffer_predisable(struct iio_dev *idev) >> +{ >> + if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) >> + return 0; >> + >> + return bm1390_fifo_disable(idev); >> +} >> + >> +static const struct iio_buffer_setup_ops bm1390_buffer_ops = { >> + .postenable = bm1390_buffer_postenable, >> + .predisable = bm1390_buffer_predisable, >> +}; >> + >> +static irqreturn_t bm1390_trigger_handler(int irq, void *p) >> +{ >> + struct iio_poll_func *pf = p; >> + struct iio_dev *idev = pf->indio_dev; >> + struct bm1390_data *data = iio_priv(idev); >> + int ret, dummy; >> + >> + /* DRDY is acked by reading status reg */ >> + ret = regmap_read(data->regmap, BM1390_REG_STATUS, >> + &dummy); > > I'd expect 'dummy' to be irrelevant data. Perhaps give it > a better name if you are going to use the value like this. > Ok. >> + if (ret || !dummy) >> + return IRQ_NONE; >> + >> + dev_dbg(data->dev, "DRDY trig status 0x%x\n", dummy); >> + >> + ret = bm1390_pressure_read(data, &data->buf.pressure); >> + if (ret) { >> + dev_warn(data->dev, "sample read failed %d\n", ret); >> + return IRQ_NONE; > As below. Still our interrupt even if we couldn't read the data > As such, IRQ_HANDLED; is current reutrn value. I've learned a hard way that it can be a very good idea to return IRQ_NONE if HW access fails in IRQ handling. If we don't (can't) ack the IRQ line, we'll be sitting in IRQ handler. The feature which disables local IRQ after <N> unhandled IRQs has made a huge difference when I've received bug reports from people. Being able to access the device when the 'wild' IRQ gets disabled and being able to retrieve the logs is priceless. Also, seeing the 'nobody cares, disabling IRQ' in the log is a really valuable hint :) >> + } >> + >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, >> + &data->buf.temp, BM1390_TEMP_SIZE); >> + > ret not checked. Ok. >> + iio_push_to_buffers_with_timestamp(idev, &data->buf, data->timestamp); >> + iio_trigger_notify_done(idev->trig); >> + >> + return IRQ_HANDLED; >> +} >> + >> +/* Get timestamps and wake the thread if we need to read data */ >> +static irqreturn_t bm1390_irq_handler(int irq, void *private) >> +{ >> + struct iio_dev *idev = private; >> + struct bm1390_data *data = iio_priv(idev); >> + >> + data->timestamp = iio_get_time_ns(idev); >> + >> + if (data->state == BM1390_STATE_FIFO || data->trigger_enabled) >> + return IRQ_WAKE_THREAD; >> + >> + return IRQ_NONE; >> +} >> + >> +static irqreturn_t bm1390_irq_thread_handler(int irq, void *private) >> +{ >> + struct iio_dev *idev = private; >> + struct bm1390_data *data = iio_priv(idev); >> + int ret = IRQ_NONE; >> + >> + mutex_lock(&data->mutex); >> + >> + if (data->trigger_enabled) { >> + iio_trigger_poll_nested(data->trig); >> + ret = IRQ_HANDLED; >> + } >> + >> + if (data->state == BM1390_STATE_FIFO) { > > Can this and trigger_enabled be true? No, it shouldn't be possible. > >> + int ok; >> + >> + ok = __bm1390_fifo_flush(idev, BM1390_TEMP_SIZE, true); >> + if (ok > 0) >> + ret = IRQ_HANDLED; > > An error should not result in IRQ_NONE. At most we tend to print > an error message and return IRQ_HANDLED anyway to avoid the interrupt > being treated as spurious. The same story here. If we can't read the samples from the FIFO, we'll end up having new watermark IRQ immediately when the oneshot thread exits. Returning the IRQ none allows genirq core to disable the host side of the IRQ, allowing us to see the 'nobody cared' and go get the logs even with single core system. > >> + } >> + >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> +} >> + >> +static int bm1390_set_drdy_irq(struct bm1390_data *data, bool en) >> +{ >> + if (en) >> + return regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_DRDY_EN); >> + return regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, >> + BM1390_MASK_DRDY_EN); >> +} >> + >> +static int bm1390_trigger_set_state(struct iio_trigger *trig, >> + bool state) >> +{ >> + struct bm1390_data *data = iio_trigger_get_drvdata(trig); >> + int ret = 0; >> + >> + mutex_lock(&data->mutex); >> + >> + if (data->trigger_enabled == state) >> + goto unlock_out; >> + >> + if (data->state == BM1390_STATE_FIFO) { >> + dev_warn(data->dev, "Can't set trigger when FIFO enabled\n"); > > Why not? Spec reference ideally. I haven't gotten my head around this > but I'd expect an attempt to set the trigger state to indicate that we don't > want to use the fifo and as such it should be disabled in this path. This may be my limited understanding of how IIO is typically used. To me it sounded a bit strange that someone setting trigger could abort an ongoing buffered measurement. I would have expected the buffering to be explicitly disabled by user before allowing the trigger to be used. Especially because the trigger and FIFO are pretty much exclusive features (as with data-ready trigger you'll get each individual sample read). My assumption was that an attempt to enable data-ready when FIFO was in use is a misconfiguration. > >> + ret = -EBUSY; >> + goto unlock_out; >> + } >> + >> + data->trigger_enabled = state; >> + >> + if (state) { >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); > > Is this a trigger characteristic? Feels more like a feature of enabling buffering. > Ah well. That's always a blurry boundary so it is probably fine here. Well, the mode needs to be set to continuous even for a single shot measurement when IIR filter is used. Furthermore, if we use the single-shot mode, then the mode must be re-written to register after every colleted sample. Hence we set the continuous mode also when trigger is used. It might be we could set this mode already at probe and forget it then. Well, maybe it has some impact to power consumption (?) so perhaps we just leave the continuous mode to be enabled for all, triggered, FIFO and raw sample collections. > ret set but not checked... Thanks for pointing this out - I need to check (what / if) I have been thinking :) > >> + } else { >> + int dummy; >> + >> + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); >> + >> + /* >> + * We need to read the status register in order to ACK the >> + * data-ready which may have been generated just before we >> + * disabled the measurement. >> + */ >> + if (!ret) >> + ret = regmap_read(data->regmap, BM1390_REG_STATUS, >> + &dummy); > > Should check for errors in ret. > >> + } >> + >> + ret = bm1390_set_drdy_irq(data, state); >> + if (ret) >> + goto unlock_out; > > Not a lot of point in that :) I like the way you put it :) Better to clean this too. > >> + >> + >> +unlock_out: >> + mutex_unlock(&data->mutex); >> + >> + return ret; >> + >> +} >> + >> +static const struct iio_trigger_ops bm1390_trigger_ops = { >> + .set_trigger_state = bm1390_trigger_set_state, >> +}; >> + >> +static int bm1390_setup_trigger(struct bm1390_data *data, struct iio_dev *idev, >> + int irq) >> +{ >> + struct iio_trigger *itrig; >> + char *name; >> + int ret; >> + >> + if (irq < 0) { >> + dev_warn(data->dev, "No IRQ - skipping buffering\n"); > > I don't see that as deserving a warning. Device should be fine with out it. > Maybe dev_info could be justified (just). Ok. > >> + return 0; >> + } >> + >> + ret = devm_iio_triggered_buffer_setup(data->dev, idev, >> + &iio_pollfunc_store_time, >> + &bm1390_trigger_handler, >> + &bm1390_buffer_ops); >> + >> + if (ret) >> + return dev_err_probe(data->dev, ret, >> + "iio_triggered_buffer_setup FAIL\n"); >> + >> + itrig = devm_iio_trigger_alloc(data->dev, "%sdata-rdy-dev%d", idev->name, >> + iio_device_id(idev)); >> + if (!itrig) >> + return -ENOMEM; >> + >> + data->trig = itrig; >> + idev->available_scan_masks = bm1390_scan_masks; >> + >> + itrig->ops = &bm1390_trigger_ops; >> + iio_trigger_set_drvdata(itrig, data); > > > >> + >> + /* >> + * No need to check for NULL. request_threaded_irq() defaults to >> + * dev_name() should the alloc fail. >> + */ >> + name = devm_kasprintf(data->dev, GFP_KERNEL, "%s-bm1390", >> + dev_name(data->dev)); > > Whist true, checking for it is less code than not doing so and > adding the comment. So I'd just check for it! comment does not eat cycles :) Well, I know everyone is saying this does not matter as we're far from a hot path... Sigh, I guess you're right while I also know why we need such powerful computers while we do same basic things we did 10 years ago... > >> + >> + ret = devm_request_threaded_irq(data->dev, irq, bm1390_irq_handler, >> + &bm1390_irq_thread_handler, >> + IRQF_ONESHOT, name, idev); >> + if (ret) >> + return dev_err_probe(data->dev, ret, "Could not request IRQ\n"); >> + >> + >> + ret = devm_iio_trigger_register(data->dev, itrig); >> + if (ret) >> + return dev_err_probe(data->dev, ret, >> + "Trigger registration failed\n"); >> + >> + >> + return ret; > > return 0 as that's the only value and it's good to make it clear that > was the intention in this path. Ok > > >> +} >> + >> +static int bm1390_probe(struct i2c_client *i2c) >> +{ >> + struct bm1390_data *data; >> + struct regmap *regmap; >> + struct iio_dev *idev; >> + struct device *dev; >> + unsigned int part_id; >> + int ret; >> + >> + dev = &i2c->dev; >> + >> + regmap = devm_regmap_init_i2c(i2c, &bm1390_regmap); >> + if (IS_ERR(regmap)) >> + return dev_err_probe(dev, PTR_ERR(regmap), >> + "Failed to initialize Regmap\n"); >> + >> + idev = devm_iio_device_alloc(dev, sizeof(*data)); >> + if (!idev) >> + return -ENOMEM; >> + >> + ret = devm_regulator_get_enable(dev, "vdd"); >> + if (ret) >> + return dev_err_probe(dev, ret, "Failed to get regulator\n"); >> + >> + data = iio_priv(idev); >> + >> + ret = regmap_read(regmap, BM1390_REG_PART_ID, &part_id); >> + if (ret) >> + return dev_err_probe(dev, ret, "Failed to access sensor\n"); >> + >> + if (part_id != BM1390_ID) >> + dev_warn(dev, "unknown device 0x%x\n", part_id); >> + >> + data->regmap = regmap; >> + data->dev = dev; >> + data->irq = i2c->irq; >> + /* >> + * Default watermark to WMI_MAX. We could also allow setting WMI to 0, >> + * and interpret that as "WMI is disabled, use FIFO_FULL" but I've >> + * no idea what is assumed if watermark is 0. Does it mean each sample >> + * should trigger IRQ, or no samples should do that? > > In my head at least, if we are using fifo_full it is still a watermark but one > that matches size of buffer. > I think for previous drivers we've had 0 and 1 both meaning it's a dataready > interrupt (i.e. one entry in the fifo). That would be fine here as well > and would correspond to putting the device in bypass mode. Thanks for the explanation. It makes sense. Meanwhile I was reading the spec and I think the FIFO_FULL usage with this IC is like asking for a nose-bleed. FIFO_FULL IRQ is acked by reading the status - and if data is not read from the FIFO, then the status will remain cleared (and I assume also the IRQ line will stay low). I assume it's easy enough to write a code that acks the IRQ while leaving the buffer full - and effectively killing the FIFO_FULL IRQ. No more samples for you then. > >> + * >> + * Well, for now we just allow BM1390_WMI_MIN to BM1390_WMI_MAX and >> + * discard every other configuration when triggered mode is not used. >> + */ >> + data->watermark = BM1390_WMI_MAX; >> + mutex_init(&data->mutex); >> + >> + idev->channels = bm1390_channels; >> + idev->num_channels = ARRAY_SIZE(bm1390_channels); >> + idev->name = "bm1390"; >> + idev->info = &bm1390_info; >> + idev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_SOFTWARE; > > The triggered buffer setup should set the second of these inside > the IIO core code (as it always needs to be set if that code is called). Right. Thanks. > > >> + >> + ret = bm1390_chip_init(data); >> + if (ret) >> + return dev_err_probe(dev, ret, "sensor init failed\n"); >> + >> + ret = bm1390_setup_trigger(data, idev, i2c->irq); >> + if (ret) >> + return ret; >> + >> + ret = devm_iio_device_register(dev, idev); >> + if (ret < 0) >> + return dev_err_probe(dev, ret, >> + "Unable to register iio device\n"); >> + >> + return ret; >> +} >> + >> +static const struct of_device_id bm1390_of_match[] = { >> + { .compatible = "rohm,bm1390glv-z" }, >> + {} >> +}; >> +MODULE_DEVICE_TABLE(of, bm1390_of_match); >> + >> +static const struct i2c_device_id bm1390_id[] = { >> + { "bm1390glv-z", }, >> + {} >> +}; >> +MODULE_DEVICE_TABLE(i2c, bm1390_id); >> + >> +static struct i2c_driver bm1390_driver = { >> + .driver = { >> + .name = "bm1390", >> + .of_match_table = bm1390_of_match, >> + .probe_type = PROBE_PREFER_ASYNCHRONOUS, > > I don't mind seeing this but I do want it to have a comment saying 'why'. > I assume there is something really slow involved in probing this? I wouldn't say there is anything really slow. What I have gathered is: 1) The grand idea is that at the end of the day (week, month, year) async probing should be the default when it causes no problems. 2) Problems are rare (although they may exist). 3) All regulator drivers were changes (or suggested to be changed) to do async probing because for example the ramp-rates may be slow. 4) This driver enables the VDD supply - with potentially slow ramp-rate (well, the I need to guess user's setups statement holds again) so it may potentially take a while (probably not long though). 5) We have a few msleeps() in bm1390_chip_init() - which are likely to result a sleep tens of milliseconds. So there is some delay. From those 5 things I derived assumption that async probe would be the right thing to start with. We can drop it if it causes a problem in an actual setup :) > >> + }, >> + .probe = bm1390_probe, >> + .id_table = bm1390_id, >> +}; >> +module_i2c_driver(bm1390_driver); >> + >> +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>"); >> +MODULE_DESCRIPTION("Driver for ROHM BM1390 pressure sensor"); >> +MODULE_LICENSE("GPL"); > Thanks again for all the help! Yours, -- Matti
> >> The FIFO measurement mode is only measuring the pressure and not the > >> temperature. The driver measures temperature when FIFO is flushed and > >> simply uses the same measured temperature value to all reported > >> temperatures. This should not be a problem when temperature is not > >> changing very rapidly (several degrees C / second) but allows users to > >> get the temperature measurements from sensor without any additional logic. > > > > IIRC this is a bit different from what we've typically done in the past > > where we just take the view that a slow moving thing like temperature > > can be read from sysfs or that enabling it disables the watermark. > > > > However, what you have seems like valid use of the ABI to me so I'm > > fine with this approach if it makes sense for your expected users > > (which you get to guess at ;) > > > > Given there are multiple ways of handling combination of FIFO hardware > > and triggers, it's good to add a little bit of info on that in this > > patch description (I misunderstood what you were doing initially) > > > My idea is that the sensor can either be used in two ways, > > 1. With trigger (data-ready IRQ). In this case the FIFO is not used as > we get data ready for each collected sample. Instead, for each > data-ready IRQ we read the sample from sensor and push it to the IIO buffer. > > 2. With hardware FIFO and watermark IRQ. In this case the data-ready is > not used but we enable watermark IRQ. At each watermark IRQ we go and > read all samples in FIFO and push them to the IIO buffer. > > Do you mean the commit message should explain this? yes > >> + > >> +static int __bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples, > >> + bool irq) > >> +{ > >> + /* The fifo holds maximum of 4 samples */ > > > > Whilst useful info - why have comment here? > > It really looks like it's missplaced. I may have suffled some code to > other place without moving the comment. I'll drop or move it - thanks! > > > > >> + struct bm1390_data *data = iio_priv(idev); > >> + struct bm1390_data_buf buffer; > >> + int smp_lvl, ret, i; > >> + u64 sample_period; > >> + __be16 temp = 0; > >> + > >> + /* > >> + * If the IC is accessed during FIFO read samples can be dropped. > >> + * Prevent access until FIFO_LVL is read > >> + */ > >> + if (test_bit(BM1390_CHAN_TEMP, idev->active_scan_mask)) { > >> + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp, > >> + sizeof(temp)); > >> + if (ret) > >> + return ret; > >> + } > >> + > >> + ret = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); > >> + if (ret) > >> + return ret; > >> + > >> + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); > >> + > >> + if (smp_lvl > 4) { > >> + /* > >> + * Valid values should be 0, 1, 2, 3, 4 - rest are probably > >> + * bit errors in I2C line. Don't overflow if this happens. > >> + */ > >> + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); > >> + smp_lvl = 4; > >> + } > >> + > >> + if (!smp_lvl) > >> + return ret; > >> + > >> + sample_period = data->timestamp - data->old_timestamp; > >> + do_div(sample_period, smp_lvl); > >> + > >> + if (samples && smp_lvl > samples) > >> + smp_lvl = samples; > >> + > >> + for (i = 0; i < smp_lvl; i++) { > >> + ret = bm1390_pressure_read(data, &buffer.pressure); > >> + if (ret) > >> + break; > >> + > >> + buffer.temp = temp; > >> + /* > >> + * Old timestamp is either the previous sample IRQ time, > >> + * previous flush-time or, if this was first sample, the enable > >> + * time. When we add a sample period to that we should get the > >> + * best approximation of the time-stamp we are handling. > >> + * > >> + * Idea is to always keep the "old_timestamp" matching the > >> + * timestamp which we are currently handling. > >> + */ > >> + data->old_timestamp += sample_period; > >> + > >> + iio_push_to_buffers_with_timestamp(idev, &buffer, > >> + data->old_timestamp); > >> + } > >> + /* Reading the FIFO_LVL closes the FIFO access sequence */ > >> + regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); > > > > ret = > > I didn't want to determine success of getting the data by success of > this read. Instead, I wanted to ret to contain the success of reading > the pressure in the for-loop. We might spill out a warning if this reads > fails though. Does it mean the next read is going to fail? I'm too lazy to look at datasheet to see what you mean by FIFO access sequence. If it does I'd rather we reported error as early as possible. Mind you I can't remember if errors in here result in anything useful anyway. > >> +static int bm1390_set_watermark(struct iio_dev *idev, unsigned int val) > >> +{ > >> + struct bm1390_data *data = iio_priv(idev); > >> + > >> + if (val < BM1390_WMI_MIN || val > BM1390_WMI_MAX) > >> + return -EINVAL; > > > > It's definitely possible to argue a watermark of 1 is also supported - just > > run in bypass mode with data ready interrupt. Not sure we care enough to > > make that supported in this interface though. Driver doesn't need to > > support everything possible. > > True. I'm not sure this is worth the complexity though. It'd mean we had > to support DRDY when in FIFO mode - iff watermark is 1. Currently we > don't need to bother the DRDY or FIFO disabling when in FIFO mode. Ok. > > >> + if (ret || !dummy) > >> + return IRQ_NONE; > >> + > >> + dev_dbg(data->dev, "DRDY trig status 0x%x\n", dummy); > >> + > >> + ret = bm1390_pressure_read(data, &data->buf.pressure); > >> + if (ret) { > >> + dev_warn(data->dev, "sample read failed %d\n", ret); > >> + return IRQ_NONE; > > As below. Still our interrupt even if we couldn't read the data > > As such, IRQ_HANDLED; is current reutrn value. > > I've learned a hard way that it can be a very good idea to return > IRQ_NONE if HW access fails in IRQ handling. If we don't (can't) ack the > IRQ line, we'll be sitting in IRQ handler. The feature which disables > local IRQ after <N> unhandled IRQs has made a huge difference when I've > received bug reports from people. Being able to access the device when > the 'wild' IRQ gets disabled and being able to retrieve the logs is > priceless. Also, seeing the 'nobody cares, disabling IRQ' in the log is > a really valuable hint :) Hmm. Usually the warn splat works out as enough to provide a hint. Kind of depends on whether the particular failure blocks correct handling or not. Some devices don't care if you successfully read the buffer or not. Its always annoyed me that there is no IRQ_ERROR return. > > > > >> + } > >> + > >> + mutex_unlock(&data->mutex); > >> + > >> + return ret; > >> +} > >> + > >> +static int bm1390_set_drdy_irq(struct bm1390_data *data, bool en) > >> +{ > >> + if (en) > >> + return regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, > >> + BM1390_MASK_DRDY_EN); > >> + return regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, > >> + BM1390_MASK_DRDY_EN); > >> +} > >> + > >> +static int bm1390_trigger_set_state(struct iio_trigger *trig, > >> + bool state) > >> +{ > >> + struct bm1390_data *data = iio_trigger_get_drvdata(trig); > >> + int ret = 0; > >> + > >> + mutex_lock(&data->mutex); > >> + > >> + if (data->trigger_enabled == state) > >> + goto unlock_out; > >> + > >> + if (data->state == BM1390_STATE_FIFO) { > >> + dev_warn(data->dev, "Can't set trigger when FIFO enabled\n"); > > > > Why not? Spec reference ideally. I haven't gotten my head around this > > but I'd expect an attempt to set the trigger state to indicate that we don't > > want to use the fifo and as such it should be disabled in this path. > > This may be my limited understanding of how IIO is typically used. To me > it sounded a bit strange that someone setting trigger could abort an > ongoing buffered measurement. I would have expected the buffering to be > explicitly disabled by user before allowing the trigger to be used. We mostly try to enable as many userspace paths as possible. If they ask for something and we can easily do it (even if it stops something else) then we are fine with it. > Especially because the trigger and FIFO are pretty much exclusive > features (as with data-ready trigger you'll get each individual sample > read). My assumption was that an attempt to enable data-ready when FIFO > was in use is a misconfiguration. I agree, but doesn't mean we aren't nice to them anyway :) Expectation is they should go back to a sensible state before setting up something new and complex. Now if it's tricky to handle in code then we can indeed use an error. I have better understood how you are are handing fifo vs data ready now hence I'm not that bothered by this spitting out an error. It's the same as changing a trigger when a buffer is running which makes little sense, though it only applies in INDIO_BUFFER_TRIGGERED mode. Perhaps we should broaden that and then we'll block much earlier. ... > > > > > >> +} > >> + > >> +static int bm1390_probe(struct i2c_client *i2c) > >> +{ > >> + struct bm1390_data *data; > >> + struct regmap *regmap; > >> + struct iio_dev *idev; > >> + struct device *dev; > >> + unsigned int part_id; > >> + int ret; > >> + > >> + dev = &i2c->dev; > >> + > >> + regmap = devm_regmap_init_i2c(i2c, &bm1390_regmap); > >> + if (IS_ERR(regmap)) > >> + return dev_err_probe(dev, PTR_ERR(regmap), > >> + "Failed to initialize Regmap\n"); > >> + > >> + idev = devm_iio_device_alloc(dev, sizeof(*data)); > >> + if (!idev) > >> + return -ENOMEM; > >> + > >> + ret = devm_regulator_get_enable(dev, "vdd"); > >> + if (ret) > >> + return dev_err_probe(dev, ret, "Failed to get regulator\n"); > >> + > >> + data = iio_priv(idev); > >> + > >> + ret = regmap_read(regmap, BM1390_REG_PART_ID, &part_id); > >> + if (ret) > >> + return dev_err_probe(dev, ret, "Failed to access sensor\n"); > >> + > >> + if (part_id != BM1390_ID) > >> + dev_warn(dev, "unknown device 0x%x\n", part_id); > >> + > >> + data->regmap = regmap; > >> + data->dev = dev; > >> + data->irq = i2c->irq; > >> + /* > >> + * Default watermark to WMI_MAX. We could also allow setting WMI to 0, > >> + * and interpret that as "WMI is disabled, use FIFO_FULL" but I've > >> + * no idea what is assumed if watermark is 0. Does it mean each sample > >> + * should trigger IRQ, or no samples should do that? > > > > In my head at least, if we are using fifo_full it is still a watermark but one > > that matches size of buffer. > > I think for previous drivers we've had 0 and 1 both meaning it's a dataready > > interrupt (i.e. one entry in the fifo). That would be fine here as well > > and would correspond to putting the device in bypass mode. > > Thanks for the explanation. It makes sense. > Meanwhile I was reading the spec and I think the FIFO_FULL usage with > this IC is like asking for a nose-bleed. FIFO_FULL IRQ is acked by > reading the status - and if data is not read from the FIFO, then the > status will remain cleared (and I assume also the IRQ line will stay > low). I assume it's easy enough to write a code that acks the IRQ while > leaving the buffer full - and effectively killing the FIFO_FULL IRQ. No > more samples for you then. Its not a level IRQ? What fun. Indeed silly corner case. > > > > >> + * > >> + * Well, for now we just allow BM1390_WMI_MIN to BM1390_WMI_MAX and > >> + * discard every other configuration when triggered mode is not used. > >> + */ > >> + data->watermark = BM1390_WMI_MAX; > >> + mutex_init(&data->mutex); > >> + > >> + idev->channels = bm1390_channels; > >> + idev->num_channels = ARRAY_SIZE(bm1390_channels); > >> + idev->name = "bm1390"; > >> + idev->info = &bm1390_info; > >> + idev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_SOFTWARE; > > > > The triggered buffer setup should set the second of these inside > > the IIO core code (as it always needs to be set if that code is called). > > Right. Thanks. Oops. I'm wrong in this. I'd forgotten the distinction between INDIO_BUFFER_TRIGGERED and INDIO_BUFFER_SOFTWARE. You should set this as you have done. ... > >> +static struct i2c_driver bm1390_driver = { > >> + .driver = { > >> + .name = "bm1390", > >> + .of_match_table = bm1390_of_match, > >> + .probe_type = PROBE_PREFER_ASYNCHRONOUS, > > > > I don't mind seeing this but I do want it to have a comment saying 'why'. > > I assume there is something really slow involved in probing this? > > I wouldn't say there is anything really slow. What I have gathered is: > > 1) The grand idea is that at the end of the day (week, month, year) > async probing should be the default when it causes no problems. Agreed. > > 2) Problems are rare (although they may exist). > > 3) All regulator drivers were changes (or suggested to be changed) to do > async probing because for example the ramp-rates may be slow. > > 4) This driver enables the VDD supply - with potentially slow ramp-rate > (well, the I need to guess user's setups statement holds again) so it > may potentially take a while (probably not long though). > > 5) We have a few msleeps() in bm1390_chip_init() - which are likely to > result a sleep tens of milliseconds. So there is some delay. > > From those 5 things I derived assumption that async probe would be the > right thing to start with. We can drop it if it causes a problem in an > actual setup :) > I don't mind having it - I'd just like a little comment including what minimum sleep time is and that a VDD supply enable may add time to it. So set the bounds. Jonathan
On 9/10/23 16:22, Jonathan Cameron wrote: > On Wed, 6 Sep 2023 15:37:48 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure >> pressures ranging from 300 hPa to 1300 hPa with configurable measurement >> averaging and internal FIFO. The sensor does also provide temperature >> measurements. >> >> Sensor does also contain IIR filter implemented in HW. The data-sheet >> says the IIR filter can be configured to be "weak", "middle" or >> "strong". Some RMS noise figures are provided in data sheet but no >> accurate maths for the filter configurations is provided. Hence, the IIR >> filter configuration is not supported by this driver and the filter is >> configured to the "middle" setting (at least not for now). >> + >> +static irqreturn_t bm1390_irq_thread_handler(int irq, void *private) >> +{ >> + struct iio_dev *idev = private; >> + struct bm1390_data *data = iio_priv(idev); >> + int ret = IRQ_NONE; >> + >> + mutex_lock(&data->mutex); >> + >> + if (data->trigger_enabled) { >> + iio_trigger_poll_nested(data->trig); >> + ret = IRQ_HANDLED; >> + } >> + >> + if (data->state == BM1390_STATE_FIFO) { > > Can this and trigger_enabled be true? Thanks for asking this question. Intention was that these are mutually exclusive. However, I think that the check if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) in bm1390_buffer_postenable(), before calling the bm1390_fifo_enable() is not 100% race free. I, however, like the idea of having this check in the buffer-enable function - I think it makes the design much more obvious. What I will do is adding another check for: if (data->trigger_enable) { ret = -EBUSY; goto unlock_out; } inside the bm1390_fifo_enable() to the section which holds the mutex. Yours, -- Matti
On Thu, 14 Sep 2023 14:47:44 +0300 Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 9/10/23 16:22, Jonathan Cameron wrote: > > On Wed, 6 Sep 2023 15:37:48 +0300 > > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > > > >> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure > >> pressures ranging from 300 hPa to 1300 hPa with configurable measurement > >> averaging and internal FIFO. The sensor does also provide temperature > >> measurements. > >> > >> Sensor does also contain IIR filter implemented in HW. The data-sheet > >> says the IIR filter can be configured to be "weak", "middle" or > >> "strong". Some RMS noise figures are provided in data sheet but no > >> accurate maths for the filter configurations is provided. Hence, the IIR > >> filter configuration is not supported by this driver and the filter is > >> configured to the "middle" setting (at least not for now). > > >> + > >> +static irqreturn_t bm1390_irq_thread_handler(int irq, void *private) > >> +{ > >> + struct iio_dev *idev = private; > >> + struct bm1390_data *data = iio_priv(idev); > >> + int ret = IRQ_NONE; > >> + > >> + mutex_lock(&data->mutex); > >> + > >> + if (data->trigger_enabled) { > >> + iio_trigger_poll_nested(data->trig); > >> + ret = IRQ_HANDLED; > >> + } > >> + > >> + if (data->state == BM1390_STATE_FIFO) { > > > > Can this and trigger_enabled be true? > > Thanks for asking this question. Intention was that these are mutually > exclusive. However, I think that the check > if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) > in bm1390_buffer_postenable(), before calling the bm1390_fifo_enable() > is not 100% race free. > > I, however, like the idea of having this check in the buffer-enable > function - I think it makes the design much more obvious. What I will do > is adding another check for: > if (data->trigger_enable) { > ret = -EBUSY; > goto unlock_out; > } > > inside the bm1390_fifo_enable() to the section which holds the mutex. You could make the exclusive nature obvious in the thread_handler by using an else if () above. > > > Yours, > -- Matti > > >
On 9/17/23 12:26, Jonathan Cameron wrote: > On Thu, 14 Sep 2023 14:47:44 +0300 > Matti Vaittinen <mazziesaccount@gmail.com> wrote: > >> On 9/10/23 16:22, Jonathan Cameron wrote: >>> On Wed, 6 Sep 2023 15:37:48 +0300 >>> Matti Vaittinen <mazziesaccount@gmail.com> wrote: >>> >>>> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure >>>> pressures ranging from 300 hPa to 1300 hPa with configurable measurement >>>> averaging and internal FIFO. The sensor does also provide temperature >>>> measurements. >>>> >>>> Sensor does also contain IIR filter implemented in HW. The data-sheet >>>> says the IIR filter can be configured to be "weak", "middle" or >>>> "strong". Some RMS noise figures are provided in data sheet but no >>>> accurate maths for the filter configurations is provided. Hence, the IIR >>>> filter configuration is not supported by this driver and the filter is >>>> configured to the "middle" setting (at least not for now). >> >>>> + >>>> +static irqreturn_t bm1390_irq_thread_handler(int irq, void *private) >>>> +{ >>>> + struct iio_dev *idev = private; >>>> + struct bm1390_data *data = iio_priv(idev); >>>> + int ret = IRQ_NONE; >>>> + >>>> + mutex_lock(&data->mutex); >>>> + >>>> + if (data->trigger_enabled) { >>>> + iio_trigger_poll_nested(data->trig); >>>> + ret = IRQ_HANDLED; >>>> + } >>>> + >>>> + if (data->state == BM1390_STATE_FIFO) { >>> >>> Can this and trigger_enabled be true? >> >> Thanks for asking this question. Intention was that these are mutually >> exclusive. However, I think that the check >> if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) >> in bm1390_buffer_postenable(), before calling the bm1390_fifo_enable() >> is not 100% race free. >> >> I, however, like the idea of having this check in the buffer-enable >> function - I think it makes the design much more obvious. What I will do >> is adding another check for: >> if (data->trigger_enable) { >> ret = -EBUSY; >> goto unlock_out; >> } >> >> inside the bm1390_fifo_enable() to the section which holds the mutex. > > You could make the exclusive nature obvious in the thread_handler by using an > else if () above. Right. Thanks. > >> >> >> Yours, >> -- Matti >> >> >> >
diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig index 7b4c2af32852..95efa32e4289 100644 --- a/drivers/iio/pressure/Kconfig +++ b/drivers/iio/pressure/Kconfig @@ -16,6 +16,15 @@ config ABP060MG To compile this driver as a module, choose M here: the module will be called abp060mg. +config ROHM_BM1390 + tristate "ROHM BM1390GLV-Z pressure sensor driver" + depends on I2C + help + Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z + can measure pressures ranging from 300 hPa to 1300 hPa with + configurable measurement averaging and internal FIFO. The + sensor does also provide temperature measurements. + config BMP280 tristate "Bosch Sensortec BMP180/BMP280/BMP380/BMP580 pressure sensor driver" depends on (I2C || SPI_MASTER) diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile index c90f77210e94..436aec7e65f3 100644 --- a/drivers/iio/pressure/Makefile +++ b/drivers/iio/pressure/Makefile @@ -5,6 +5,7 @@ # When adding new entries keep the list in alphabetical order obj-$(CONFIG_ABP060MG) += abp060mg.o +obj-$(CONFIG_ROHM_BM1390) += rohm-bm1390.o obj-$(CONFIG_BMP280) += bmp280.o bmp280-objs := bmp280-core.o bmp280-regmap.o obj-$(CONFIG_BMP280_I2C) += bmp280-i2c.o diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c new file mode 100644 index 000000000000..2d51a99a58fc --- /dev/null +++ b/drivers/iio/pressure/rohm-bm1390.c @@ -0,0 +1,944 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * BM1390 ROHM pressure sensor + * + * Copyright (c) 2023, ROHM Semiconductor. + * https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/pressure/bm1390glv-z-e.pdf + */ + +#include <linux/bitfield.h> +#include <linux/bits.h> +#include <linux/device.h> +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/regmap.h> +#include <linux/regulator/consumer.h> + +#include <linux/iio/iio.h> +#include <linux/iio/trigger.h> +#include <linux/iio/trigger_consumer.h> +#include <linux/iio/triggered_buffer.h> + +#define BM1390_REG_MANUFACT_ID 0x0f +#define BM1390_REG_PART_ID 0x10 +#define BM1390_REG_POWER 0x12 +#define BM1390_MASK_POWER BIT(0) +#define BM1390_POWER_ON BM1390_MASK_POWER +#define BM1390_POWER_OFF 0x00 +#define BM1390_REG_RESET 0x13 +#define BM1390_MASK_RESET BIT(0) +#define BM1390_RESET_RELEASE BM1390_MASK_RESET +#define BM1390_RESET 0x00 +#define BM1390_REG_MODE_CTRL 0x14 +#define BM1390_MASK_MEAS_MODE GENMASK(1, 0) +#define BM1390_MASK_DRDY_EN BIT(4) +#define BM1390_MASK_WMI_EN BIT(2) +#define BM1390_MASK_AVE_NUM GENMASK(7, 5) + +/* + * Data-sheet states that when the IIR is used, the AVE_NUM must be set to + * value 110b + */ +#define BM1390_IIR_AVE_NUM 0x06 +#define BM1390_REG_FIFO_CTRL 0x15 +#define BM1390_MASK_IIR_MODE GENMASK(1, 0) +#define BM1390_IIR_MODE_OFF 0x0 +#define BM1390_IIR_MODE_WEAK 0x1 +#define BM1390_IIR_MODE_MID 0x2 +#define BM1390_IIR_MODE_STRONG 0x3 + +#define BM1390_MASK_FIFO_LEN BIT(6) +#define BM1390_MASK_FIFO_EN BIT(7) +#define BM1390_WMI_MIN 2 +#define BM1390_WMI_MAX 3 + +#define BM1390_REG_FIFO_LVL 0x18 +#define BM1390_MASK_FIFO_LVL GENMASK(2, 0) +#define BM1390_REG_STATUS 0x19 +#define BM1390_REG_PRESSURE_BASE 0x1a +#define BM1390_REG_TEMP_HI 0x1d +#define BM1390_REG_TEMP_LO 0x1e +#define BM1390_MAX_REGISTER BM1390_REG_TEMP_LO + +#define BM1390_ID 0x34 + +/* Regmap configs */ +static const struct regmap_range bm1390_volatile_ranges[] = { + { + .range_min = BM1390_REG_STATUS, + .range_max = BM1390_REG_STATUS, + }, + { + .range_min = BM1390_REG_FIFO_LVL, + .range_max = BM1390_REG_TEMP_LO, + }, +}; + +static const struct regmap_access_table bm1390_volatile_regs = { + .yes_ranges = &bm1390_volatile_ranges[0], + .n_yes_ranges = ARRAY_SIZE(bm1390_volatile_ranges), +}; + +static const struct regmap_range bm1390_precious_ranges[] = { + { + .range_min = BM1390_REG_STATUS, + .range_max = BM1390_REG_STATUS, + }, +}; + +static const struct regmap_access_table bm1390_precious_regs = { + .yes_ranges = &bm1390_precious_ranges[0], + .n_yes_ranges = ARRAY_SIZE(bm1390_precious_ranges), +}; + +static const struct regmap_range bm1390_read_only_ranges[] = { + { + .range_min = BM1390_REG_MANUFACT_ID, + .range_max = BM1390_REG_PART_ID, + }, { + .range_min = BM1390_REG_FIFO_LVL, + .range_max = BM1390_REG_TEMP_LO, + }, +}; + +static const struct regmap_access_table bm1390_ro_regs = { + .no_ranges = &bm1390_read_only_ranges[0], + .n_no_ranges = ARRAY_SIZE(bm1390_read_only_ranges), +}; + +static const struct regmap_range bm1390_noinc_read_ranges[] = { + { + .range_min = BM1390_REG_PRESSURE_BASE, + .range_max = BM1390_REG_TEMP_LO, + }, +}; + +static const struct regmap_access_table bm1390_nir_regs = { + .yes_ranges = &bm1390_noinc_read_ranges[0], + .n_yes_ranges = ARRAY_SIZE(bm1390_noinc_read_ranges), +}; + +static const struct regmap_config bm1390_regmap = { + .reg_bits = 8, + .val_bits = 8, + .volatile_table = &bm1390_volatile_regs, + .wr_table = &bm1390_ro_regs, + .rd_noinc_table = &bm1390_nir_regs, + .precious_table = &bm1390_precious_regs, + .max_register = BM1390_MAX_REGISTER, + .cache_type = REGCACHE_RBTREE, + .disable_locking = true, +}; + +enum { + BM1390_STATE_SAMPLE, + BM1390_STATE_FIFO, +}; + +struct bm1390_data_buf { + u32 pressure; + __be16 temp; + s64 ts __aligned(8); +}; + +/* Pressure data is in 3 8-bit registers */ +#define BM1390_PRESSURE_SIZE 3 + +/* BM1390 has FIFO for 4 pressure samples */ +#define BM1390_FIFO_LENGTH 4 + +/* Temperature data is in 2 8-bit registers */ +#define BM1390_TEMP_SIZE 2 + +struct bm1390_data { + int64_t timestamp, old_timestamp; + struct iio_trigger *trig; + struct regmap *regmap; + struct device *dev; + struct bm1390_data_buf buf; + int irq; + unsigned int state; + bool trigger_enabled; + u8 watermark; + + /* Prevent accessing sensor during FIFO read sequence */ + struct mutex mutex; +}; + +enum { + BM1390_CHAN_PRESSURE, + BM1390_CHAN_TEMP, +}; + +static const struct iio_chan_spec bm1390_channels[] = { + { + .type = IIO_PRESSURE, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), + /* + * When IIR is used, we must fix amount of averaged samples. + * Thus we don't allow setting oversampling ratio. + */ + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), + .scan_index = BM1390_CHAN_PRESSURE, + .scan_type = { + .sign = 'u', + .realbits = 22, + .storagebits = 32, + .endianness = IIO_LE, + }, + }, + { + .type = IIO_TEMP, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), + .scan_index = BM1390_CHAN_TEMP, + .scan_type = { + .sign = 's', + .realbits = 16, + .storagebits = 16, + .endianness = IIO_BE, + }, + }, + IIO_CHAN_SOFT_TIMESTAMP(2), +}; + +static const unsigned long bm1390_scan_masks[] = { + BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0 +}; + +static int bm1390_read_temp(struct bm1390_data *data, int *temp) +{ + u8 temp_reg[2] __aligned(2); + __be16 *temp_raw; + int ret; + s16 val; + bool negative; + + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp_reg, + sizeof(temp_reg)); + if (ret) + return ret; + + if (temp_reg[0] & 0x80) + negative = true; + else + negative = false; + + temp_raw = (__be16 *)&temp_reg[0]; + val = be16_to_cpu(*temp_raw); + + if (negative) { + /* + * Two's complement. I am not sure if all supported + * architectures actually use 2's complement represantation of + * signed ints. If yes, then we could just do the endianes + * conversion and say this is the s16 value. However, as I + * don't know, and as the conversion is pretty simple. let's + * just convert the signed 2's complement to absolute value and + * multiply by -1. + */ + val = ~val + 1; + val *= -1; + } + + *temp = val; + + return 0; +} + +static int bm1390_pressure_read(struct bm1390_data *data, u32 *pressure) +{ + int ret; + u8 raw[3]; + + ret = regmap_bulk_read(data->regmap, BM1390_REG_PRESSURE_BASE, + &raw[0], sizeof(raw)); + if (ret < 0) + return ret; + + *pressure = (u32)(raw[2] >> 2 | raw[1] << 6 | raw[0] << 14); + + return 0; +} + + /* The enum values map directly to register bits */ +enum bm1390_meas_mode { + BM1390_MEAS_MODE_STOP = 0x0, + BM1390_MEAS_MODE_1SHOT, + BM1390_MEAS_MODE_CONTINUOUS, +}; + +static int bm1390_meas_set(struct bm1390_data *data, enum bm1390_meas_mode mode) +{ + return regmap_update_bits(data->regmap, BM1390_REG_MODE_CTRL, + BM1390_MASK_MEAS_MODE, mode); +} + +/* + * If the trigger is not used we just wait until the measurement has + * completed. The data-sheet says maximum measurement cycle (regardless + * the AVE_NUM) is 200 mS so let's just sleep at least that long. If speed + * is needed the trigger should be used. + */ +#define BM1390_MAX_MEAS_TIME_MS 205 + +static int bm1390_read_data(struct bm1390_data *data, + struct iio_chan_spec const *chan, int *val, int *val2) +{ + int ret; + + *val2 = 0; + + mutex_lock(&data->mutex); + /* + * We use 'continuous mode' even for raw read because according to the + * data-sheet an one-shot mode can't be used with IIR filter + */ + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); + if (ret) + goto unlock_out; + + switch (chan->type) { + case IIO_PRESSURE: + msleep(BM1390_MAX_MEAS_TIME_MS); + ret = bm1390_pressure_read(data, val); + break; + case IIO_TEMP: + msleep(BM1390_MAX_MEAS_TIME_MS); + ret = bm1390_read_temp(data, val); + break; + default: + ret = -EINVAL; + } + bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); +unlock_out: + mutex_unlock(&data->mutex); + + return ret; +} + +static int bm1390_read_raw(struct iio_dev *idev, + struct iio_chan_spec const *chan, + int *val, int *val2, long mask) +{ + struct bm1390_data *data = iio_priv(idev); + int ret; + + switch (mask) { + case IIO_CHAN_INFO_SCALE: + if (chan->type == IIO_TEMP) { + *val = 31; + *val2 = 250000; + + return IIO_VAL_INT_PLUS_MICRO; + } else if (chan->type == IIO_PRESSURE) { + *val = 0; + /* + * pressure in hPa is register value divided by 2048. + * This means kPa is 1/20480 times the register value, + * which equals to 48828.125 * 10 ^ -9 + * This is 48828.125 nano kPa. + * + * When we scale this using IIO_VAL_INT_PLUS_NANO we + * get 48828 - which means we lose some accuracy. Well, + * let's try to live with that. + */ + *val2 = 48828; + + return IIO_VAL_INT_PLUS_NANO; + } + + return -EINVAL; + case IIO_CHAN_INFO_RAW: + ret = iio_device_claim_direct_mode(idev); + if (ret) + return ret; + + ret = bm1390_read_data(data, chan, val, val2); + iio_device_release_direct_mode(idev); + if (!ret) + return IIO_VAL_INT; + + return ret; + + default: + return -EINVAL; + } + + return ret; +} + +static int __bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples, + bool irq) +{ + /* The fifo holds maximum of 4 samples */ + struct bm1390_data *data = iio_priv(idev); + struct bm1390_data_buf buffer; + int smp_lvl, ret, i; + u64 sample_period; + __be16 temp = 0; + + /* + * If the IC is accessed during FIFO read samples can be dropped. + * Prevent access until FIFO_LVL is read + */ + if (test_bit(BM1390_CHAN_TEMP, idev->active_scan_mask)) { + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, &temp, + sizeof(temp)); + if (ret) + return ret; + } + + ret = regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); + if (ret) + return ret; + + smp_lvl = FIELD_GET(BM1390_MASK_FIFO_LVL, smp_lvl); + + if (smp_lvl > 4) { + /* + * Valid values should be 0, 1, 2, 3, 4 - rest are probably + * bit errors in I2C line. Don't overflow if this happens. + */ + dev_err(data->dev, "bad FIFO level %d\n", smp_lvl); + smp_lvl = 4; + } + + if (!smp_lvl) + return ret; + + sample_period = data->timestamp - data->old_timestamp; + do_div(sample_period, smp_lvl); + + if (samples && smp_lvl > samples) + smp_lvl = samples; + + for (i = 0; i < smp_lvl; i++) { + ret = bm1390_pressure_read(data, &buffer.pressure); + if (ret) + break; + + buffer.temp = temp; + /* + * Old timestamp is either the previous sample IRQ time, + * previous flush-time or, if this was first sample, the enable + * time. When we add a sample period to that we should get the + * best approximation of the time-stamp we are handling. + * + * Idea is to always keep the "old_timestamp" matching the + * timestamp which we are currently handling. + */ + data->old_timestamp += sample_period; + + iio_push_to_buffers_with_timestamp(idev, &buffer, + data->old_timestamp); + } + /* Reading the FIFO_LVL closes the FIFO access sequence */ + regmap_read(data->regmap, BM1390_REG_FIFO_LVL, &smp_lvl); + + if (!ret) + return ret; + + return smp_lvl; +} + +static int bm1390_fifo_flush(struct iio_dev *idev, unsigned int samples) +{ + struct bm1390_data *data = iio_priv(idev); + int ret; + + /* + * If fifo_flush is being called from IRQ handler we know the stored timestamp + * is fairly accurate for the last stored sample. If we are + * called as a result of a read operation from userspace and hence + * before the watermark interrupt was triggered, take a timestamp + * now. We can fall anywhere in between two samples so the error in this + * case is at most one sample period. + * We need to have the IRQ disabled or we risk of messing-up + * the timestamps. If we are ran from IRQ, then the + * IRQF_ONESHOT has us covered - but if we are ran by the + * user-space read we need to disable the IRQ to be on a safe + * side. We do this usng synchronous disable so that if the + * IRQ thread is being ran on other CPU we wait for it to be + * finished. + */ + disable_irq(data->irq); + data->timestamp = iio_get_time_ns(idev); + + mutex_lock(&data->mutex); + ret = __bm1390_fifo_flush(idev, samples, false); + mutex_unlock(&data->mutex); + + enable_irq(data->irq); + + return ret; +} + +static int bm1390_write_raw(struct iio_dev *idev, + struct iio_chan_spec const *chan, + int val, int val2, long mask) +{ + int ret; + + ret = iio_device_claim_direct_mode(idev); + if (ret) + return ret; + + switch (mask) { + default: + ret = -EINVAL; + } + iio_device_release_direct_mode(idev); + + return ret; +} + +static int bm1390_set_watermark(struct iio_dev *idev, unsigned int val) +{ + struct bm1390_data *data = iio_priv(idev); + + if (val < BM1390_WMI_MIN || val > BM1390_WMI_MAX) + return -EINVAL; + + mutex_lock(&data->mutex); + data->watermark = val; + mutex_unlock(&data->mutex); + + return 0; +} + +static const struct iio_info bm1390_info = { + .read_raw = &bm1390_read_raw, + .write_raw = &bm1390_write_raw, + .validate_trigger = iio_validate_own_trigger, + .hwfifo_set_watermark = bm1390_set_watermark, + .hwfifo_flush_to_buffer = bm1390_fifo_flush, +}; + +static int bm1390_chip_init(struct bm1390_data *data) +{ + int ret; + + ret = regmap_write_bits(data->regmap, BM1390_REG_POWER, + BM1390_MASK_POWER, BM1390_POWER_ON); + if (ret) + return ret; + + msleep(1); + + ret = regmap_write_bits(data->regmap, BM1390_REG_RESET, + BM1390_MASK_RESET, BM1390_RESET); + if (ret) + return ret; + + msleep(1); + + ret = regmap_write_bits(data->regmap, BM1390_REG_RESET, + BM1390_MASK_RESET, BM1390_RESET_RELEASE); + if (ret) + return ret; + + msleep(1); + + ret = regmap_reinit_cache(data->regmap, &bm1390_regmap); + if (ret) { + dev_err(data->dev, "Failed to reinit reg cache\n"); + return ret; + } + + /* + * Default to use IIR filter in "middle" mode. Also the AVE_NUM must + * be fixed when IIR is in use + */ + ret = regmap_update_bits(data->regmap, BM1390_REG_MODE_CTRL, + BM1390_MASK_AVE_NUM, BM1390_IIR_AVE_NUM); + if (ret) + return ret; + + ret = regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, + BM1390_MASK_IIR_MODE, BM1390_IIR_MODE_MID); + + return ret; +} + +static int bm1390_fifo_set_wmi(struct bm1390_data *data) +{ + u8 regval; + + regval = data->watermark - BM1390_WMI_MIN; + regval = FIELD_PREP(BM1390_MASK_FIFO_LEN, regval); + + return regmap_update_bits(data->regmap, BM1390_REG_FIFO_CTRL, + BM1390_MASK_FIFO_LEN, regval); +} + +static int bm1390_fifo_enable(struct iio_dev *idev) +{ + struct bm1390_data *data = iio_priv(idev); + int ret; + + mutex_lock(&data->mutex); + + /* Update watermark to HW */ + ret = bm1390_fifo_set_wmi(data); + if (ret) + goto unlock_out; + + /* Enable WMI_IRQ */ + ret = regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, + BM1390_MASK_WMI_EN); + /* Enable FIFO */ + ret = regmap_set_bits(data->regmap, BM1390_REG_FIFO_CTRL, + BM1390_MASK_FIFO_EN); + if (ret) + goto unlock_out; + + data->state = BM1390_STATE_FIFO; + + data->old_timestamp = iio_get_time_ns(idev); + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); + +unlock_out: + mutex_unlock(&data->mutex); + + return ret; +} + +static int bm1390_fifo_disable(struct iio_dev *idev) +{ + struct bm1390_data *data = iio_priv(idev); + int ret; + + msleep(1); + + mutex_lock(&data->mutex); + /* Disable FIFO */ + ret = regmap_clear_bits(data->regmap, BM1390_REG_FIFO_CTRL, + BM1390_MASK_FIFO_EN); + if (ret) + goto unlock_out; + + data->state = BM1390_STATE_SAMPLE; + + /* Disable WMI_IRQ */ + ret = regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, + BM1390_MASK_WMI_EN); + if (ret) + goto unlock_out; + + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); + +unlock_out: + mutex_unlock(&data->mutex); + + return ret; +} + +static int bm1390_buffer_postenable(struct iio_dev *idev) +{ + /* + * If we use data-ready trigger, then the IRQ masks should be handled by + * trigger enable and the hardware buffer is not used but we just update + * results to the IIO fifo when data-ready triggers. + */ + if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) + return 0; + + return bm1390_fifo_enable(idev); +} + +static int bm1390_buffer_predisable(struct iio_dev *idev) +{ + if (iio_device_get_current_mode(idev) == INDIO_BUFFER_TRIGGERED) + return 0; + + return bm1390_fifo_disable(idev); +} + +static const struct iio_buffer_setup_ops bm1390_buffer_ops = { + .postenable = bm1390_buffer_postenable, + .predisable = bm1390_buffer_predisable, +}; + +static irqreturn_t bm1390_trigger_handler(int irq, void *p) +{ + struct iio_poll_func *pf = p; + struct iio_dev *idev = pf->indio_dev; + struct bm1390_data *data = iio_priv(idev); + int ret, dummy; + + /* DRDY is acked by reading status reg */ + ret = regmap_read(data->regmap, BM1390_REG_STATUS, + &dummy); + if (ret || !dummy) + return IRQ_NONE; + + dev_dbg(data->dev, "DRDY trig status 0x%x\n", dummy); + + ret = bm1390_pressure_read(data, &data->buf.pressure); + if (ret) { + dev_warn(data->dev, "sample read failed %d\n", ret); + return IRQ_NONE; + } + + ret = regmap_bulk_read(data->regmap, BM1390_REG_TEMP_HI, + &data->buf.temp, BM1390_TEMP_SIZE); + + iio_push_to_buffers_with_timestamp(idev, &data->buf, data->timestamp); + iio_trigger_notify_done(idev->trig); + + return IRQ_HANDLED; +} + +/* Get timestamps and wake the thread if we need to read data */ +static irqreturn_t bm1390_irq_handler(int irq, void *private) +{ + struct iio_dev *idev = private; + struct bm1390_data *data = iio_priv(idev); + + data->timestamp = iio_get_time_ns(idev); + + if (data->state == BM1390_STATE_FIFO || data->trigger_enabled) + return IRQ_WAKE_THREAD; + + return IRQ_NONE; +} + +static irqreturn_t bm1390_irq_thread_handler(int irq, void *private) +{ + struct iio_dev *idev = private; + struct bm1390_data *data = iio_priv(idev); + int ret = IRQ_NONE; + + mutex_lock(&data->mutex); + + if (data->trigger_enabled) { + iio_trigger_poll_nested(data->trig); + ret = IRQ_HANDLED; + } + + if (data->state == BM1390_STATE_FIFO) { + int ok; + + ok = __bm1390_fifo_flush(idev, BM1390_TEMP_SIZE, true); + if (ok > 0) + ret = IRQ_HANDLED; + } + + mutex_unlock(&data->mutex); + + return ret; +} + +static int bm1390_set_drdy_irq(struct bm1390_data *data, bool en) +{ + if (en) + return regmap_set_bits(data->regmap, BM1390_REG_MODE_CTRL, + BM1390_MASK_DRDY_EN); + return regmap_clear_bits(data->regmap, BM1390_REG_MODE_CTRL, + BM1390_MASK_DRDY_EN); +} + +static int bm1390_trigger_set_state(struct iio_trigger *trig, + bool state) +{ + struct bm1390_data *data = iio_trigger_get_drvdata(trig); + int ret = 0; + + mutex_lock(&data->mutex); + + if (data->trigger_enabled == state) + goto unlock_out; + + if (data->state == BM1390_STATE_FIFO) { + dev_warn(data->dev, "Can't set trigger when FIFO enabled\n"); + ret = -EBUSY; + goto unlock_out; + } + + data->trigger_enabled = state; + + if (state) { + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_CONTINUOUS); + } else { + int dummy; + + ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP); + + /* + * We need to read the status register in order to ACK the + * data-ready which may have been generated just before we + * disabled the measurement. + */ + if (!ret) + ret = regmap_read(data->regmap, BM1390_REG_STATUS, + &dummy); + } + + ret = bm1390_set_drdy_irq(data, state); + if (ret) + goto unlock_out; + + +unlock_out: + mutex_unlock(&data->mutex); + + return ret; + +} + +static const struct iio_trigger_ops bm1390_trigger_ops = { + .set_trigger_state = bm1390_trigger_set_state, +}; + +static int bm1390_setup_trigger(struct bm1390_data *data, struct iio_dev *idev, + int irq) +{ + struct iio_trigger *itrig; + char *name; + int ret; + + if (irq < 0) { + dev_warn(data->dev, "No IRQ - skipping buffering\n"); + return 0; + } + + ret = devm_iio_triggered_buffer_setup(data->dev, idev, + &iio_pollfunc_store_time, + &bm1390_trigger_handler, + &bm1390_buffer_ops); + + if (ret) + return dev_err_probe(data->dev, ret, + "iio_triggered_buffer_setup FAIL\n"); + + itrig = devm_iio_trigger_alloc(data->dev, "%sdata-rdy-dev%d", idev->name, + iio_device_id(idev)); + if (!itrig) + return -ENOMEM; + + data->trig = itrig; + idev->available_scan_masks = bm1390_scan_masks; + + itrig->ops = &bm1390_trigger_ops; + iio_trigger_set_drvdata(itrig, data); + + /* + * No need to check for NULL. request_threaded_irq() defaults to + * dev_name() should the alloc fail. + */ + name = devm_kasprintf(data->dev, GFP_KERNEL, "%s-bm1390", + dev_name(data->dev)); + + ret = devm_request_threaded_irq(data->dev, irq, bm1390_irq_handler, + &bm1390_irq_thread_handler, + IRQF_ONESHOT, name, idev); + if (ret) + return dev_err_probe(data->dev, ret, "Could not request IRQ\n"); + + + ret = devm_iio_trigger_register(data->dev, itrig); + if (ret) + return dev_err_probe(data->dev, ret, + "Trigger registration failed\n"); + + + return ret; +} + +static int bm1390_probe(struct i2c_client *i2c) +{ + struct bm1390_data *data; + struct regmap *regmap; + struct iio_dev *idev; + struct device *dev; + unsigned int part_id; + int ret; + + dev = &i2c->dev; + + regmap = devm_regmap_init_i2c(i2c, &bm1390_regmap); + if (IS_ERR(regmap)) + return dev_err_probe(dev, PTR_ERR(regmap), + "Failed to initialize Regmap\n"); + + idev = devm_iio_device_alloc(dev, sizeof(*data)); + if (!idev) + return -ENOMEM; + + ret = devm_regulator_get_enable(dev, "vdd"); + if (ret) + return dev_err_probe(dev, ret, "Failed to get regulator\n"); + + data = iio_priv(idev); + + ret = regmap_read(regmap, BM1390_REG_PART_ID, &part_id); + if (ret) + return dev_err_probe(dev, ret, "Failed to access sensor\n"); + + if (part_id != BM1390_ID) + dev_warn(dev, "unknown device 0x%x\n", part_id); + + data->regmap = regmap; + data->dev = dev; + data->irq = i2c->irq; + /* + * Default watermark to WMI_MAX. We could also allow setting WMI to 0, + * and interpret that as "WMI is disabled, use FIFO_FULL" but I've + * no idea what is assumed if watermark is 0. Does it mean each sample + * should trigger IRQ, or no samples should do that? + * + * Well, for now we just allow BM1390_WMI_MIN to BM1390_WMI_MAX and + * discard every other configuration when triggered mode is not used. + */ + data->watermark = BM1390_WMI_MAX; + mutex_init(&data->mutex); + + idev->channels = bm1390_channels; + idev->num_channels = ARRAY_SIZE(bm1390_channels); + idev->name = "bm1390"; + idev->info = &bm1390_info; + idev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_SOFTWARE; + + ret = bm1390_chip_init(data); + if (ret) + return dev_err_probe(dev, ret, "sensor init failed\n"); + + ret = bm1390_setup_trigger(data, idev, i2c->irq); + if (ret) + return ret; + + ret = devm_iio_device_register(dev, idev); + if (ret < 0) + return dev_err_probe(dev, ret, + "Unable to register iio device\n"); + + return ret; +} + +static const struct of_device_id bm1390_of_match[] = { + { .compatible = "rohm,bm1390glv-z" }, + {} +}; +MODULE_DEVICE_TABLE(of, bm1390_of_match); + +static const struct i2c_device_id bm1390_id[] = { + { "bm1390glv-z", }, + {} +}; +MODULE_DEVICE_TABLE(i2c, bm1390_id); + +static struct i2c_driver bm1390_driver = { + .driver = { + .name = "bm1390", + .of_match_table = bm1390_of_match, + .probe_type = PROBE_PREFER_ASYNCHRONOUS, + }, + .probe = bm1390_probe, + .id_table = bm1390_id, +}; +module_i2c_driver(bm1390_driver); + +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>"); +MODULE_DESCRIPTION("Driver for ROHM BM1390 pressure sensor"); +MODULE_LICENSE("GPL");
Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure pressures ranging from 300 hPa to 1300 hPa with configurable measurement averaging and internal FIFO. The sensor does also provide temperature measurements. Sensor does also contain IIR filter implemented in HW. The data-sheet says the IIR filter can be configured to be "weak", "middle" or "strong". Some RMS noise figures are provided in data sheet but no accurate maths for the filter configurations is provided. Hence, the IIR filter configuration is not supported by this driver and the filter is configured to the "middle" setting (at least not for now). The FIFO measurement mode is only measuring the pressure and not the temperature. The driver measures temperature when FIFO is flushed and simply uses the same measured temperature value to all reported temperatures. This should not be a problem when temperature is not changing very rapidly (several degrees C / second) but allows users to get the temperature measurements from sensor without any additional logic. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> --- drivers/iio/pressure/Kconfig | 9 + drivers/iio/pressure/Makefile | 1 + drivers/iio/pressure/rohm-bm1390.c | 944 +++++++++++++++++++++++++++++ 3 files changed, 954 insertions(+) create mode 100644 drivers/iio/pressure/rohm-bm1390.c