* [PATCH v3 1/2] iio: temperature: Add support for LTC2983
@ 2019-10-04 13:55 Nuno Sá
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Nuno Sá @ 2019-10-04 13:55 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland
The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
Measurement System. It measures a wide variety of temperature sensors and
digitally outputs the result, in °C or °F, with 0.1°C accuracy and
0.001°C resolution. It can measure the temperature of all standard
thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire RTDs,
thermistors and diodes.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
Changes in v2:
* Added some needed blank lines (for readability);
* Allocate iio_chan in the setup() function;
* Rename reset to sleep;
* Remove unneeded dev_dbg calls;
* Remove unneeded line wrapping;
* Remove unneeded comments;
* Remove extend_names. Use the standard ABI;
* Adapt the scales to report in millivolt and milli degrees;
* Adapt the of_property readings to the renaming of the properties;
* For custom thermistors, excitation-current cannot be set to Auto range.
Changes in v3:
* Use normal `devm_request_irq`;
* Handle and decode the new devicetree properties for sensor configuration.
MAINTAINERS | 7 +
drivers/iio/temperature/Kconfig | 10 +
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/ltc2983.c | 1554 +++++++++++++++++++++++++++++
4 files changed, 1572 insertions(+)
create mode 100644 drivers/iio/temperature/ltc2983.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f0c03740b9fb..14a256e785ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9491,6 +9491,13 @@ S: Maintained
F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt
F: drivers/iio/dac/ltc1660.c
+LTC2983 IIO TEMPERATURE DRIVER
+M: Nuno Sá <nuno.sa@analog.com>
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-iio@vger.kernel.org
+S: Supported
+F: drivers/iio/temperature/ltc2983.c
+
LTC4261 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
L: linux-hwmon@vger.kernel.org
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 737faa0901fe..04b5a67b593c 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -4,6 +4,16 @@
#
menu "Temperature sensors"
+config LTC2983
+ tristate "Analog Devices Multi-Sensor Digital Temperature Measurement System"
+ depends on SPI
+ help
+ Say yes here to build support for the LTC2983 Multi-Sensor
+ high accuracy digital temperature measurement system.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ltc2983.
+
config MAXIM_THERMOCOUPLE
tristate "Maxim thermocouple sensors"
depends on SPI
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index baca4776ca0d..d6b850b0cf63 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -3,6 +3,7 @@
# Makefile for industrial I/O temperature drivers
#
+obj-$(CONFIG_LTC2983) += ltc2983.o
obj-$(CONFIG_HID_SENSOR_TEMP) += hid-sensor-temperature.o
obj-$(CONFIG_MAXIM_THERMOCOUPLE) += maxim_thermocouple.o
obj-$(CONFIG_MAX31856) += max31856.o
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
new file mode 100644
index 000000000000..f899c1d75f8a
--- /dev/null
+++ b/drivers/iio/temperature/ltc2983.c
@@ -0,0 +1,1554 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Analog Devices LTC2983 Multi-Sensor Digital Temperature Measurement System
+ * driver
+ *
+ * Copyright 2019 Analog Devices Inc.
+ */
+#include <linux/bitfield.h>
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/iio/iio.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/regmap.h>
+#include <linux/spi/spi.h>
+
+/* register map */
+#define LTC2983_STATUS_REG 0x0000
+#define LTC2983_TEMP_RES_START_REG 0x0010
+#define LTC2983_TEMP_RES_END_REG 0x005F
+#define LTC2983_GLOBAL_CONFIG_REG 0x00F0
+#define LTC2983_MULT_CHANNEL_START_REG 0x00F4
+#define LTC2983_MULT_CHANNEL_END_REG 0x00F7
+#define LTC2983_MUX_CONFIG_REG 0x00FF
+#define LTC2983_CHAN_ASSIGN_START_REG 0x0200
+#define LTC2983_CHAN_ASSIGN_END_REG 0x024F
+#define LTC2983_CUST_SENS_TBL_START_REG 0x0250
+#define LTC2983_CUST_SENS_TBL_END_REG 0x03CF
+
+#define LTC2983_DIFFERENTIAL_CHAN_MIN 2
+#define LTC2983_MAX_CHANNELS_NR 20
+#define LTC2983_MIN_CHANNELS_NR 1
+#define LTC2983_SLEEP 0x97
+#define LTC2983_CUSTOM_STEINHART_SIZE 24
+#define LTC2983_CUSTOM_SENSOR_ENTRY_SZ 6
+#define LTC2983_CUSTOM_STEINHART_ENTRY_SZ 4
+
+#define LTC2983_CHAN_START_ADDR(chan) \
+ (((chan - 1) * 4) + LTC2983_CHAN_ASSIGN_START_REG)
+#define LTC2983_CHAN_RES_ADDR(chan) \
+ (((chan - 1) * 4) + LTC2983_TEMP_RES_START_REG)
+#define LTC2983_THERMOCOUPLE_DIFF_MASK BIT(3)
+#define LTC2983_THERMOCOUPLE_SGL(x) \
+ FIELD_PREP(LTC2983_THERMOCOUPLE_DIFF_MASK, x)
+#define LTC2983_THERMOCOUPLE_OC_CURR_MASK GENMASK(1, 0)
+#define LTC2983_THERMOCOUPLE_OC_CURR(x) \
+ FIELD_PREP(LTC2983_THERMOCOUPLE_OC_CURR_MASK, x)
+#define LTC2983_THERMOCOUPLE_OC_CHECK_MASK BIT(2)
+#define LTC2983_THERMOCOUPLE_OC_CHECK(x) \
+ FIELD_PREP(LTC2983_THERMOCOUPLE_OC_CHECK_MASK, x)
+
+#define LTC2983_THERMISTOR_DIFF_MASK BIT(2)
+#define LTC2983_THERMISTOR_SGL(x) \
+ FIELD_PREP(LTC2983_THERMISTOR_DIFF_MASK, x)
+#define LTC2983_THERMISTOR_R_SHARE_MASK BIT(1)
+#define LTC2983_THERMISTOR_R_SHARE(x) \
+ FIELD_PREP(LTC2983_THERMISTOR_R_SHARE_MASK, x)
+#define LTC2983_THERMISTOR_C_ROTATE_MASK BIT(0)
+#define LTC2983_THERMISTOR_C_ROTATE(x) \
+ FIELD_PREP(LTC2983_THERMISTOR_C_ROTATE_MASK, x)
+
+#define LTC2983_DIODE_DIFF_MASK BIT(2)
+#define LTC2983_DIODE_SGL(x) \
+ FIELD_PREP(LTC2983_DIODE_DIFF_MASK, x)
+#define LTC2983_DIODE_3_CONV_CYCLE_MASK BIT(1)
+#define LTC2983_DIODE_3_CONV_CYCLE(x) \
+ FIELD_PREP(LTC2983_DIODE_3_CONV_CYCLE_MASK, x)
+#define LTC2983_DIODE_AVERAGE_ON_MASK BIT(0)
+#define LTC2983_DIODE_AVERAGE_ON(x) \
+ FIELD_PREP(LTC2983_DIODE_AVERAGE_ON_MASK, x)
+
+#define LTC2983_RTD_4_WIRE_MASK BIT(3)
+#define LTC2983_RTD_ROTATION_MASK BIT(1)
+#define LTC2983_RTD_C_ROTATE(x) \
+ FIELD_PREP(LTC2983_RTD_ROTATION_MASK, x)
+#define LTC2983_RTD_KELVIN_R_SENSE_MASK GENMASK(3, 2)
+#define LTC2983_RTD_N_WIRES_MASK GENMASK(3, 2)
+#define LTC2983_RTD_N_WIRES(x) \
+ FIELD_PREP(LTC2983_RTD_N_WIRES_MASK, x)
+#define LTC2983_RTD_R_SHARE_MASK BIT(0)
+#define LTC2983_RTD_R_SHARE(x) \
+ FIELD_PREP(LTC2983_RTD_R_SHARE_MASK, 1)
+
+#define LTC2983_COMMON_HARD_FAULT_MASK GENMASK(31, 30)
+#define LTC2983_COMMON_SOFT_FAULT_MASK GENMASK(27, 25)
+
+#define LTC2983_STATUS_START_MASK BIT(7)
+#define LTC2983_STATUS_START(x) FIELD_PREP(LTC2983_STATUS_START_MASK, x)
+
+#define LTC2983_STATUS_CHAN_SEL_MASK GENMASK(4, 0)
+#define LTC2983_STATUS_CHAN_SEL(x) \
+ FIELD_PREP(LTC2983_STATUS_CHAN_SEL_MASK, x)
+
+#define LTC2983_TEMP_UNITS_MASK BIT(2)
+#define LTC2983_TEMP_UNITS(x) FIELD_PREP(LTC2983_TEMP_UNITS_MASK, x)
+
+#define LTC2983_NOTCH_FREQ_MASK GENMASK(1, 0)
+#define LTC2983_NOTCH_FREQ(x) FIELD_PREP(LTC2983_NOTCH_FREQ_MASK, x)
+
+#define LTC2983_RES_VALID_MASK BIT(24)
+#define LTC2983_DATA_MASK GENMASK(23, 0)
+#define LTC2983_DATA_SIGN_BIT 23
+
+#define LTC2983_CHAN_TYPE_MASK GENMASK(31, 27)
+#define LTC2983_CHAN_TYPE(x) FIELD_PREP(LTC2983_CHAN_TYPE_MASK, x)
+
+/* cold junction for thermocouples and rsense for rtd's and thermistor's */
+#define LTC2983_CHAN_ASSIGN_MASK GENMASK(26, 22)
+#define LTC2983_CHAN_ASSIGN(x) FIELD_PREP(LTC2983_CHAN_ASSIGN_MASK, x)
+
+#define LTC2983_CUSTOM_LEN_MASK GENMASK(5, 0)
+#define LTC2983_CUSTOM_LEN(x) FIELD_PREP(LTC2983_CUSTOM_LEN_MASK, x)
+
+#define LTC2983_CUSTOM_ADDR_MASK GENMASK(11, 6)
+#define LTC2983_CUSTOM_ADDR(x) FIELD_PREP(LTC2983_CUSTOM_ADDR_MASK, x)
+
+#define LTC2983_THERMOCOUPLE_CFG_MASK GENMASK(21, 18)
+#define LTC2983_THERMOCOUPLE_CFG(x) \
+ FIELD_PREP(LTC2983_THERMOCOUPLE_CFG_MASK, x)
+#define LTC2983_THERMOCOUPLE_HARD_FAULT_MASK GENMASK(31, 29)
+#define LTC2983_THERMOCOUPLE_SOFT_FAULT_MASK GENMASK(28, 25)
+
+#define LTC2983_RTD_CFG_MASK GENMASK(21, 18)
+#define LTC2983_RTD_CFG(x) FIELD_PREP(LTC2983_RTD_CFG_MASK, x)
+#define LTC2983_RTD_EXC_CURRENT_MASK GENMASK(17, 14)
+#define LTC2983_RTD_EXC_CURRENT(x) \
+ FIELD_PREP(LTC2983_RTD_EXC_CURRENT_MASK, x)
+#define LTC2983_RTD_CURVE_MASK GENMASK(13, 12)
+#define LTC2983_RTD_CURVE(x) FIELD_PREP(LTC2983_RTD_CURVE_MASK, x)
+
+#define LTC2983_THERMISTOR_CFG_MASK GENMASK(21, 19)
+#define LTC2983_THERMISTOR_CFG(x) \
+ FIELD_PREP(LTC2983_THERMISTOR_CFG_MASK, x)
+#define LTC2983_THERMISTOR_EXC_CURRENT_MASK GENMASK(18, 15)
+#define LTC2983_THERMISTOR_EXC_CURRENT(x) \
+ FIELD_PREP(LTC2983_THERMISTOR_EXC_CURRENT_MASK, x)
+
+#define LTC2983_DIODE_CFG_MASK GENMASK(26, 24)
+#define LTC2983_DIODE_CFG(x) FIELD_PREP(LTC2983_DIODE_CFG_MASK, x)
+#define LTC2983_DIODE_EXC_CURRENT_MASK GENMASK(23, 22)
+#define LTC2983_DIODE_EXC_CURRENT(x) \
+ FIELD_PREP(LTC2983_DIODE_EXC_CURRENT_MASK, x)
+#define LTC2983_DIODE_IDEAL_FACTOR_MASK GENMASK(21, 0)
+#define LTC2983_DIODE_IDEAL_FACTOR(x) \
+ FIELD_PREP(LTC2983_DIODE_IDEAL_FACTOR_MASK, x)
+
+#define LTC2983_R_SENSE_VAL_MASK GENMASK(26, 0)
+#define LTC2983_R_SENSE_VAL(x) FIELD_PREP(LTC2983_R_SENSE_VAL_MASK, x)
+
+#define LTC2983_ADC_SINGLE_ENDED_MASK BIT(26)
+#define LTC2983_ADC_SINGLE_ENDED(x) \
+ FIELD_PREP(LTC2983_ADC_SINGLE_ENDED_MASK, x)
+
+enum {
+ LTC2983_SENSOR_THERMOCOUPLE = 1,
+ LTC2983_SENSOR_THERMOCOUPLE_CUSTOM = 9,
+ LTC2983_SENSOR_RTD = 10,
+ LTC2983_SENSOR_RTD_CUSTOM = 18,
+ LTC2983_SENSOR_THERMISTOR = 19,
+ LTC2983_SENSOR_THERMISTOR_STEINHART = 26,
+ LTC2983_SENSOR_THERMISTOR_CUSTOM = 27,
+ LTC2983_SENSOR_DIODE = 28,
+ LTC2983_SENSOR_SENSE_RESISTOR = 29,
+ LTC2983_SENSOR_DIRECT_ADC = 30,
+};
+
+#define to_thermocouple(_sensor) \
+ container_of(_sensor, struct ltc2983_thermocouple, sensor)
+
+#define to_rtd(_sensor) \
+ container_of(_sensor, struct ltc2983_rtd, sensor)
+
+#define to_thermistor(_sensor) \
+ container_of(_sensor, struct ltc2983_thermistor, sensor)
+
+#define to_diode(_sensor) \
+ container_of(_sensor, struct ltc2983_diode, sensor)
+
+#define to_rsense(_sensor) \
+ container_of(_sensor, struct ltc2983_rsense, sensor)
+
+#define to_adc(_sensor) \
+ container_of(_sensor, struct ltc2983_adc, sensor)
+
+struct ltc2983_data {
+ struct regmap *regmap;
+ struct spi_device *spi;
+ struct mutex lock;
+ struct completion completion;
+ struct iio_chan_spec *iio_chan;
+ struct ltc2983_sensor **sensors;
+ u32 mux_delay_config;
+ u32 filter_notch_freq;
+ u16 custom_table_size;
+ u8 num_channels;
+ u8 iio_channels;
+ bool temp_farenheit;
+ bool sleep;
+};
+
+struct ltc2983_sensor {
+ int (*fault_handler)(const struct ltc2983_data *st, const u32 result);
+ int (*assign_chan)(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor);
+ /* specifies the sensor channel */
+ u32 chan;
+ /* sensor type */
+ u32 type;
+};
+
+struct ltc2983_custom_sensor {
+ /* raw table sensor data */
+ u8 *table;
+ size_t size;
+ /* address offset */
+ s8 offset;
+ bool is_steinhart;
+};
+
+struct ltc2983_thermocouple {
+ struct ltc2983_sensor sensor;
+ struct ltc2983_custom_sensor *custom;
+ u32 sensor_config;
+ u32 cold_junction_chan;
+};
+
+struct ltc2983_rtd {
+ struct ltc2983_sensor sensor;
+ struct ltc2983_custom_sensor *custom;
+ u32 sensor_config;
+ u32 r_sense_chan;
+ u32 excitation_current;
+ u32 rtd_curve;
+};
+
+struct ltc2983_thermistor {
+ struct ltc2983_sensor sensor;
+ struct ltc2983_custom_sensor *custom;
+ u32 sensor_config;
+ u32 r_sense_chan;
+ u32 excitation_current;
+};
+
+struct ltc2983_diode {
+ struct ltc2983_sensor sensor;
+ u32 sensor_config;
+ u32 excitation_current;
+ u32 ideal_factor_value;
+};
+
+struct ltc2983_rsense {
+ struct ltc2983_sensor sensor;
+ u32 r_sense_val;
+};
+
+struct ltc2983_adc {
+ struct ltc2983_sensor sensor;
+ bool single_ended;
+};
+
+/*
+ * Convert to Q format numbers. These number's are integers where
+ * the number of integer and fractional bits are specified. The resolution
+ * is given by 1/@resolution and tell us the number of fractional bits. For
+ * instance a resolution of 2^-10 means we have 10 fractional bits.
+ */
+static u32 __convert_to_raw(const u64 val, const u32 resolution)
+{
+ u64 __res = val * resolution;
+
+ /* all values are multiplied by 1000000 to remove the fraction */
+ do_div(__res, 1000000);
+
+ return __res;
+}
+
+static u32 __convert_to_raw_sign(const u64 val, const u32 resolution)
+{
+ s64 __res = -(s32)val;
+
+ __res = __convert_to_raw(__res, resolution);
+
+ return (u32)-__res;
+}
+
+static int __ltc2983_fault_handler(const struct ltc2983_data *st,
+ const u32 result, const u32 hard_mask,
+ const u32 soft_mask)
+{
+ const struct device *dev = &st->spi->dev;
+
+ if (result & hard_mask) {
+ dev_err(dev, "Invalid conversion: Sensor HARD fault\n");
+ return -EIO;
+ } else if (result & soft_mask) {
+ /* just print a warning */
+ dev_warn(dev, "Suspicious conversion: Sensor SOFT fault\n");
+ }
+
+ return 0;
+}
+
+static int __ltc2983_chan_assign_common(const struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor,
+ u32 chan_val)
+{
+ u32 reg = LTC2983_CHAN_START_ADDR(sensor->chan);
+ __be32 __chan_val;
+
+ chan_val |= LTC2983_CHAN_TYPE(sensor->type);
+ dev_dbg(&st->spi->dev, "Assign reg:0x%04X, val:0x%08X\n", reg,
+ chan_val);
+ __chan_val = cpu_to_be32(chan_val);
+ return regmap_bulk_write(st->regmap, reg, &__chan_val,
+ sizeof(__chan_val));
+}
+
+static int __ltc2983_chan_custom_sensor_assign(struct ltc2983_data *st,
+ struct ltc2983_custom_sensor *custom,
+ u32 *chan_val)
+{
+ u32 reg;
+ u8 mult = custom->is_steinhart ? LTC2983_CUSTOM_STEINHART_ENTRY_SZ :
+ LTC2983_CUSTOM_SENSOR_ENTRY_SZ;
+ const struct device *dev = &st->spi->dev;
+ /*
+ * custom->size holds the raw size of the table. However, when
+ * configuring the sensor channel, we must write the number of
+ * entries of the table minus 1. For steinhart sensors 0 is written
+ * since the size is constant!
+ */
+ const u8 len = custom->is_steinhart ? 0 :
+ (custom->size / LTC2983_CUSTOM_SENSOR_ENTRY_SZ) - 1;
+ /*
+ * Check if the offset was assigned already. It should be for steinhart
+ * sensors. When coming from sleep, it should be assigned for all.
+ */
+ if (custom->offset < 0) {
+ /*
+ * This needs to be done again here because, from the moment
+ * when this test was done (successfully) for this custom
+ * sensor, a steinhart sensor might have been added changing
+ * custom_table_size...
+ */
+ if (st->custom_table_size + custom->size >
+ (LTC2983_CUST_SENS_TBL_END_REG -
+ LTC2983_CUST_SENS_TBL_START_REG) + 1) {
+ dev_err(dev,
+ "Not space left(%d) for new custom sensor(%zu)",
+ st->custom_table_size,
+ custom->size);
+ return -EINVAL;
+ }
+
+ custom->offset = st->custom_table_size /
+ LTC2983_CUSTOM_SENSOR_ENTRY_SZ;
+ st->custom_table_size += custom->size;
+ }
+
+ reg = (custom->offset * mult) + LTC2983_CUST_SENS_TBL_START_REG;
+
+ *chan_val |= LTC2983_CUSTOM_LEN(len);
+ *chan_val |= LTC2983_CUSTOM_ADDR(custom->offset);
+ dev_dbg(dev, "Assign custom sensor, reg:0x%04X, off:%d, sz:%zu",
+ reg, custom->offset,
+ custom->size);
+ /* write custom sensor table */
+ return regmap_bulk_write(st->regmap, reg, custom->table, custom->size);
+}
+
+static struct ltc2983_custom_sensor *__ltc2983_custom_sensor_new(
+ struct ltc2983_data *st,
+ const struct device_node *np,
+ const bool is_steinhart,
+ const u32 resolution,
+ const bool has_signed)
+{
+ struct ltc2983_custom_sensor *new_custom;
+ u8 index, n_entries, tbl = 0;
+ struct device *dev = &st->spi->dev;
+ /*
+ * For custom steinhart, the full u32 is taken. For all the others
+ * the MSB is discarded.
+ */
+ const u8 n_size = (is_steinhart == true) ? 4 : 3;
+
+ n_entries = of_property_count_elems_of_size(np, "adi,custom-sensor",
+ sizeof(u64));
+ /* n_entries must be an even number */
+ if (!n_entries || (n_entries % 2) != 0) {
+ dev_err(dev, "Number of entries either 0 or not even\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ new_custom = devm_kzalloc(dev, sizeof(*new_custom), GFP_KERNEL);
+ if (!new_custom)
+ return ERR_PTR(-ENOMEM);
+
+ new_custom->size = n_entries * n_size;
+ /* check Steinhart size */
+ if (is_steinhart && new_custom->size != LTC2983_CUSTOM_STEINHART_SIZE) {
+ dev_err(dev, "Steinhart sensors size(%zu) must be 24",
+ new_custom->size);
+ return ERR_PTR(-EINVAL);
+ }
+ /* Check space on the table. */
+ if (st->custom_table_size + new_custom->size >
+ (LTC2983_CUST_SENS_TBL_END_REG -
+ LTC2983_CUST_SENS_TBL_START_REG) + 1) {
+ dev_err(dev, "No space left(%d) for new custom sensor(%zu)",
+ st->custom_table_size, new_custom->size);
+ return ERR_PTR(-EINVAL);
+ }
+
+ /* allocate the table */
+ new_custom->table = devm_kzalloc(dev, new_custom->size, GFP_KERNEL);
+ if (!new_custom->table)
+ return ERR_PTR(-ENOMEM);
+
+ for (index = 0; index < n_entries; index++) {
+ u64 temp = 0, j;
+
+ of_property_read_u64_index(np, "adi,custom-sensor", index,
+ &temp);
+ /*
+ * Steinhart sensors are configured with raw values in the
+ * devicetree. For the other sensors we must convert the
+ * value to raw. The odd index's correspond to temperarures
+ * and always have 1/1024 of resolution. Temperatures also
+ * come in kelvin, so signed values is not possible
+ */
+ if (!is_steinhart) {
+ if ((index % 2) != 0)
+ temp = __convert_to_raw(temp, 1024);
+ else if (has_signed && (s64)temp < 0)
+ temp = __convert_to_raw_sign(temp, resolution);
+ else
+ temp = __convert_to_raw(temp, resolution);
+ }
+
+ for (j = 0; j < n_size; j++)
+ new_custom->table[tbl++] =
+ temp >> (8 * (n_size - j - 1));
+ }
+
+ new_custom->is_steinhart = is_steinhart;
+ /*
+ * This is done to first add all the steinhart sensors to the table,
+ * in order to maximize the table usage. If we mix adding steinhart
+ * with the other sensors, we might have to do some roundup to make
+ * sure that sensor_addr - 0x250(start address) is a multiple of 4
+ * (for steinhart), and a multiple of 6 for all the other sensors.
+ * Since we have const 24 bytes for steinhart sensors and 24 is
+ * also a multiple of 6, we guarantee that the first non-steinhart
+ * sensor will sit in a correct address without the need of filling
+ * addresses.
+ */
+ if (is_steinhart) {
+ new_custom->offset = st->custom_table_size /
+ LTC2983_CUSTOM_STEINHART_ENTRY_SZ;
+ st->custom_table_size += new_custom->size;
+ } else {
+ /* mark as unset. This is checked later on the assign phase */
+ new_custom->offset = -1;
+ }
+
+ return new_custom;
+}
+
+static int ltc2983_thermocouple_fault_handler(const struct ltc2983_data *st,
+ const u32 result)
+{
+ return __ltc2983_fault_handler(st, result,
+ LTC2983_THERMOCOUPLE_HARD_FAULT_MASK,
+ LTC2983_THERMOCOUPLE_SOFT_FAULT_MASK);
+}
+
+static int ltc2983_common_fault_handler(const struct ltc2983_data *st,
+ const u32 result)
+{
+ return __ltc2983_fault_handler(st, result,
+ LTC2983_COMMON_HARD_FAULT_MASK,
+ LTC2983_COMMON_SOFT_FAULT_MASK);
+}
+
+static int ltc2983_thermocouple_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_thermocouple *thermo = to_thermocouple(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_CHAN_ASSIGN(thermo->cold_junction_chan);
+ chan_val |= LTC2983_THERMOCOUPLE_CFG(thermo->sensor_config);
+
+ if (thermo->custom) {
+ int ret;
+
+ ret = __ltc2983_chan_custom_sensor_assign(st, thermo->custom,
+ &chan_val);
+ if (ret)
+ return ret;
+ }
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
+static int ltc2983_rtd_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_rtd *rtd = to_rtd(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_CHAN_ASSIGN(rtd->r_sense_chan);
+ chan_val |= LTC2983_RTD_CFG(rtd->sensor_config);
+ chan_val |= LTC2983_RTD_EXC_CURRENT(rtd->excitation_current);
+ chan_val |= LTC2983_RTD_CURVE(rtd->rtd_curve);
+
+ if (rtd->custom) {
+ int ret;
+
+ ret = __ltc2983_chan_custom_sensor_assign(st, rtd->custom,
+ &chan_val);
+ if (ret)
+ return ret;
+ }
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
+static int ltc2983_thermistor_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_thermistor *thermistor = to_thermistor(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_CHAN_ASSIGN(thermistor->r_sense_chan);
+ chan_val |= LTC2983_THERMISTOR_CFG(thermistor->sensor_config);
+ chan_val |=
+ LTC2983_THERMISTOR_EXC_CURRENT(thermistor->excitation_current);
+
+ if (thermistor->custom) {
+ int ret;
+
+ ret = __ltc2983_chan_custom_sensor_assign(st,
+ thermistor->custom,
+ &chan_val);
+ if (ret)
+ return ret;
+ }
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
+static int ltc2983_diode_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_diode *diode = to_diode(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_DIODE_CFG(diode->sensor_config);
+ chan_val |= LTC2983_DIODE_EXC_CURRENT(diode->excitation_current);
+ chan_val |= LTC2983_DIODE_IDEAL_FACTOR(diode->ideal_factor_value);
+
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
+static int ltc2983_r_sense_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_rsense *rsense = to_rsense(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_R_SENSE_VAL(rsense->r_sense_val);
+
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
+static int ltc2983_adc_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_adc *adc = to_adc(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_ADC_SINGLE_ENDED(adc->single_ended);
+
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
+static struct ltc2983_sensor *ltc2983_thermocouple_new(
+ const struct device_node *child,
+ struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_thermocouple *thermo;
+ struct device_node *phandle;
+ u32 oc_current;
+ int ret;
+
+ thermo = devm_kzalloc(&st->spi->dev, sizeof(*thermo), GFP_KERNEL);
+ if (!thermo)
+ return ERR_PTR(-ENOMEM);
+
+ if (of_property_read_bool(child, "adi,single-ended"))
+ thermo->sensor_config = LTC2983_THERMOCOUPLE_SGL(1);
+
+ ret = of_property_read_u32(child, "adi,sensor-oc-current-microamp",
+ &oc_current);
+ if (!ret) {
+ switch (oc_current) {
+ case 10:
+ thermo->sensor_config |=
+ LTC2983_THERMOCOUPLE_OC_CURR(0);
+ break;
+ case 100:
+ thermo->sensor_config |=
+ LTC2983_THERMOCOUPLE_OC_CURR(1);
+ break;
+ case 500:
+ thermo->sensor_config |=
+ LTC2983_THERMOCOUPLE_OC_CURR(2);
+ break;
+ case 1000:
+ thermo->sensor_config |=
+ LTC2983_THERMOCOUPLE_OC_CURR(3);
+ break;
+ default:
+ dev_err(&st->spi->dev,
+ "Invalid open circuit current:%u", oc_current);
+ return ERR_PTR(-EINVAL);
+ }
+
+ thermo->sensor_config |= LTC2983_THERMOCOUPLE_OC_CHECK(1);
+ }
+ /* validate channel index */
+ if (!(thermo->sensor_config & LTC2983_THERMOCOUPLE_DIFF_MASK) &&
+ sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
+ dev_err(&st->spi->dev,
+ "Invalid chann:%d for differential thermocouple",
+ sensor->chan);
+ return ERR_PTR(-EINVAL);
+ }
+
+ phandle = of_parse_phandle(child, "adi,cold-junction-handle", 0);
+ if (phandle) {
+ int ret;
+
+ ret = of_property_read_u32(phandle, "reg",
+ &thermo->cold_junction_chan);
+ if (ret) {
+ /*
+ * This would be catched later but we can just return
+ * the error right away.
+ */
+ dev_err(&st->spi->dev, "Property reg must be given\n");
+ of_node_put(phandle);
+ return ERR_PTR(-EINVAL);
+ }
+ }
+
+ /* check custom sensor */
+ if (sensor->type == LTC2983_SENSOR_THERMOCOUPLE_CUSTOM) {
+ thermo->custom = __ltc2983_custom_sensor_new(st, child, false,
+ 16384, true);
+ if (IS_ERR(thermo->custom)) {
+ of_node_put(phandle);
+ return ERR_CAST(thermo->custom);
+ }
+ }
+
+ /* set common parameters */
+ thermo->sensor.fault_handler = ltc2983_thermocouple_fault_handler;
+ thermo->sensor.assign_chan = ltc2983_thermocouple_assign_chan;
+
+ of_node_put(phandle);
+ return &thermo->sensor;
+}
+
+static struct ltc2983_sensor *ltc2983_rtd_new(const struct device_node *child,
+ struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_rtd *rtd;
+ int ret = 0;
+ struct device *dev = &st->spi->dev;
+ struct device_node *phandle;
+ u32 excitation_current = 0, n_wires = 0;
+
+ rtd = devm_kzalloc(dev, sizeof(*rtd), GFP_KERNEL);
+ if (!rtd)
+ return ERR_PTR(-ENOMEM);
+
+ phandle = of_parse_phandle(child, "adi,rsense-handle", 0);
+ if (!phandle) {
+ dev_err(dev, "Property adi,rsense-handle missing or invalid");
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = of_property_read_u32(phandle, "reg", &rtd->r_sense_chan);
+ if (ret) {
+ dev_err(dev, "Property reg must be given\n");
+ goto fail;
+ }
+
+ ret = of_property_read_u32(child, "adi,number-of-wires", &n_wires);
+ if (!ret) {
+ switch (n_wires) {
+ case 2:
+ rtd->sensor_config = LTC2983_RTD_N_WIRES(0);
+ break;
+ case 3:
+ rtd->sensor_config = LTC2983_RTD_N_WIRES(1);
+ break;
+ case 4:
+ rtd->sensor_config = LTC2983_RTD_N_WIRES(2);
+ break;
+ case 5:
+ /* 4 wires, Kelvin Rsense */
+ rtd->sensor_config = LTC2983_RTD_N_WIRES(3);
+ break;
+ default:
+ dev_err(dev, "Invalid number of wires:%u\n", n_wires);
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ if (of_property_read_bool(child, "adi,rsense-share")) {
+ /* Current rotation is only available with rsense sharing */
+ if (of_property_read_bool(child, "adi,current-rotate")) {
+ if (n_wires == 2 || n_wires == 3) {
+ dev_err(dev,
+ "Rotation not allowed for 2/3 Wire RTDs");
+ ret = -EINVAL;
+ goto fail;
+ }
+ rtd->sensor_config |= LTC2983_RTD_C_ROTATE(1);
+ } else {
+ rtd->sensor_config |= LTC2983_RTD_R_SHARE(1);
+ }
+ }
+ /*
+ * rtd channel indexes are a bit more complicated to validate.
+ * For 4wire RTD with rotation, the channel selection cannot be
+ * >=19 since the chann + 1 is used in this configuration.
+ * For 4wire RTDs with kelvin rsense, the rsense channel cannot be
+ * <=1 since chanel - 1 and channel - 2 are used.
+ */
+ if (rtd->sensor_config & LTC2983_RTD_4_WIRE_MASK) {
+ /* 4-wire */
+ u8 min = LTC2983_DIFFERENTIAL_CHAN_MIN,
+ max = LTC2983_MAX_CHANNELS_NR;
+
+ if (rtd->sensor_config & LTC2983_RTD_ROTATION_MASK)
+ max = LTC2983_MAX_CHANNELS_NR - 1;
+
+ if (((rtd->sensor_config & LTC2983_RTD_KELVIN_R_SENSE_MASK)
+ == LTC2983_RTD_KELVIN_R_SENSE_MASK) &&
+ (rtd->r_sense_chan <= min)) {
+ /* kelvin rsense*/
+ dev_err(dev,
+ "Invalid rsense chann:%d to use in kelvin rsense",
+ rtd->r_sense_chan);
+
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ if (sensor->chan < min || sensor->chan > max) {
+ dev_err(dev, "Invalid chann:%d for the rtd config",
+ sensor->chan);
+
+ ret = -EINVAL;
+ goto fail;
+ }
+ } else {
+ /* same as differential case */
+ if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
+ dev_err(&st->spi->dev,
+ "Invalid chann:%d for RTD", sensor->chan);
+
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ /* check custom sensor */
+ if (sensor->type == LTC2983_SENSOR_RTD_CUSTOM) {
+ rtd->custom = __ltc2983_custom_sensor_new(st, child, false,
+ 2048, false);
+ if (IS_ERR(rtd->custom)) {
+ of_node_put(phandle);
+ return ERR_CAST(rtd->custom);
+ }
+ }
+
+ /* set common parameters */
+ rtd->sensor.fault_handler = ltc2983_common_fault_handler;
+ rtd->sensor.assign_chan = ltc2983_rtd_assign_chan;
+
+ ret = of_property_read_u32(child, "adi,excitation-current-microamp",
+ &excitation_current);
+ if (ret) {
+ /* default to 5uA */
+ rtd->excitation_current = 1;
+ } else {
+ switch (excitation_current) {
+ case 5:
+ rtd->excitation_current = 0x01;
+ break;
+ case 10:
+ rtd->excitation_current = 0x02;
+ break;
+ case 25:
+ rtd->excitation_current = 0x03;
+ break;
+ case 50:
+ rtd->excitation_current = 0x04;
+ break;
+ case 100:
+ rtd->excitation_current = 0x05;
+ break;
+ case 250:
+ rtd->excitation_current = 0x06;
+ break;
+ case 500:
+ rtd->excitation_current = 0x07;
+ break;
+ case 1000:
+ rtd->excitation_current = 0x08;
+ break;
+ default:
+ dev_err(&st->spi->dev,
+ "Invalid value for excitation current(%u)",
+ excitation_current);
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ of_property_read_u32(child, "adi,rtd-curve", &rtd->rtd_curve);
+
+ of_node_put(phandle);
+ return &rtd->sensor;
+fail:
+ of_node_put(phandle);
+ return ERR_PTR(ret);
+}
+
+static struct ltc2983_sensor *ltc2983_thermistor_new(
+ const struct device_node *child,
+ struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_thermistor *thermistor;
+ struct device *dev = &st->spi->dev;
+ struct device_node *phandle;
+ u32 excitation_current = 0;
+ int ret = 0;
+
+ thermistor = devm_kzalloc(dev, sizeof(*thermistor), GFP_KERNEL);
+ if (!thermistor)
+ return ERR_PTR(-ENOMEM);
+
+ phandle = of_parse_phandle(child, "adi,rsense-handle", 0);
+ if (!phandle) {
+ dev_err(dev, "Property adi,rsense-handle missing or invalid");
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = of_property_read_u32(phandle, "reg", &thermistor->r_sense_chan);
+ if (ret) {
+ dev_err(dev, "rsense channel must be configured...\n");
+ goto fail;
+ }
+
+ if (of_property_read_bool(child, "adi,single-ended")) {
+ thermistor->sensor_config = LTC2983_THERMISTOR_SGL(1);
+ } else if (of_property_read_bool(child, "adi,rsense-share")) {
+ /* rotation is only possible if sharing rsense */
+ if (of_property_read_bool(child, "adi,current-rotate"))
+ thermistor->sensor_config =
+ LTC2983_THERMISTOR_C_ROTATE(1);
+ else
+ thermistor->sensor_config =
+ LTC2983_THERMISTOR_R_SHARE(1);
+ }
+ /* validate channel index */
+ if (!(thermistor->sensor_config & LTC2983_THERMISTOR_DIFF_MASK) &&
+ sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
+ dev_err(&st->spi->dev,
+ "Invalid chann:%d for differential thermistor",
+ sensor->chan);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ /* check custom sensor */
+ if (sensor->type >= LTC2983_SENSOR_THERMISTOR_STEINHART) {
+ thermistor->custom = __ltc2983_custom_sensor_new(st, child,
+ sensor->type == LTC2983_SENSOR_THERMISTOR_STEINHART ?
+ true : false, 64,
+ false);
+ if (IS_ERR(thermistor->custom)) {
+ of_node_put(phandle);
+ return ERR_CAST(thermistor->custom);
+ }
+ }
+ /* set common parameters */
+ thermistor->sensor.fault_handler = ltc2983_common_fault_handler;
+ thermistor->sensor.assign_chan = ltc2983_thermistor_assign_chan;
+
+ ret = of_property_read_u32(child, "adi,excitation-current-nanoamp",
+ &excitation_current);
+ if (ret) {
+ /* Auto range is not allowed for custom sensors */
+ if (sensor->type >= LTC2983_SENSOR_THERMISTOR_STEINHART)
+ /* default to 1uA */
+ thermistor->excitation_current = 0x03;
+ else
+ /* default to auto-range */
+ thermistor->excitation_current = 0x0c;
+ } else {
+ switch (excitation_current) {
+ case 0:
+ /* auto range */
+ if (sensor->type >=
+ LTC2983_SENSOR_THERMISTOR_STEINHART) {
+ dev_err(&st->spi->dev,
+ "Auto Range not allowed for custom sensors\n");
+ ret = -EINVAL;
+ goto fail;
+ }
+ thermistor->excitation_current = 0x0c;
+ break;
+ case 250:
+ thermistor->excitation_current = 0x01;
+ break;
+ case 500:
+ thermistor->excitation_current = 0x02;
+ break;
+ case 1000:
+ thermistor->excitation_current = 0x03;
+ break;
+ case 5000:
+ thermistor->excitation_current = 0x04;
+ break;
+ case 10000:
+ thermistor->excitation_current = 0x05;
+ break;
+ case 25000:
+ thermistor->excitation_current = 0x06;
+ break;
+ case 50000:
+ thermistor->excitation_current = 0x07;
+ break;
+ case 100000:
+ thermistor->excitation_current = 0x08;
+ break;
+ case 250000:
+ thermistor->excitation_current = 0x09;
+ break;
+ case 500000:
+ thermistor->excitation_current = 0x0a;
+ break;
+ case 1000000:
+ thermistor->excitation_current = 0x0b;
+ break;
+ default:
+ dev_err(&st->spi->dev,
+ "Invalid value for excitation current(%u)",
+ excitation_current);
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ of_node_put(phandle);
+ return &thermistor->sensor;
+fail:
+ of_node_put(phandle);
+ return ERR_PTR(ret);
+}
+
+static struct ltc2983_sensor *ltc2983_diode_new(
+ const struct device_node *child,
+ const struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_diode *diode;
+ u32 temp = 0, excitation_current = 0;
+ int ret;
+
+ diode = devm_kzalloc(&st->spi->dev, sizeof(*diode), GFP_KERNEL);
+ if (!diode)
+ return ERR_PTR(-ENOMEM);
+
+ if (of_property_read_bool(child, "adi,single-ended"))
+ diode->sensor_config = LTC2983_DIODE_SGL(1);
+
+ if (of_property_read_bool(child, "adi,three-conversion-cycles"))
+ diode->sensor_config |= LTC2983_DIODE_3_CONV_CYCLE(1);
+
+ if (of_property_read_bool(child, "adi,average-on"))
+ diode->sensor_config |= LTC2983_DIODE_AVERAGE_ON(1);
+
+ /* validate channel index */
+ if (!(diode->sensor_config & LTC2983_DIODE_DIFF_MASK) &&
+ sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
+ dev_err(&st->spi->dev,
+ "Invalid chann:%d for differential thermistor",
+ sensor->chan);
+ return ERR_PTR(-EINVAL);
+ }
+ /* set common parameters */
+ diode->sensor.fault_handler = ltc2983_common_fault_handler;
+ diode->sensor.assign_chan = ltc2983_diode_assign_chan;
+
+ ret = of_property_read_u32(child, "adi,excitation-current-microamp",
+ &excitation_current);
+ if (!ret) {
+ switch (excitation_current) {
+ case 10:
+ diode->excitation_current = 0x00;
+ break;
+ case 20:
+ diode->excitation_current = 0x01;
+ break;
+ case 40:
+ diode->excitation_current = 0x02;
+ break;
+ case 80:
+ diode->excitation_current = 0x03;
+ break;
+ default:
+ dev_err(&st->spi->dev,
+ "Invalid value for excitation current(%u)",
+ excitation_current);
+ return ERR_PTR(-EINVAL);
+ }
+ }
+
+ of_property_read_u32(child, "adi,ideal-factor-value", &temp);
+
+ /* 2^20 resolution */
+ diode->ideal_factor_value = __convert_to_raw(temp, 1048576);
+
+ return &diode->sensor;
+}
+
+static struct ltc2983_sensor *ltc2983_r_sense_new(struct device_node *child,
+ struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_rsense *rsense;
+ int ret;
+ u64 temp;
+
+ rsense = devm_kzalloc(&st->spi->dev, sizeof(*rsense), GFP_KERNEL);
+ if (!rsense)
+ return ERR_PTR(-ENOMEM);
+
+ /* validate channel index */
+ if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
+ dev_err(&st->spi->dev, "Invalid chann:%d for r_sense",
+ sensor->chan);
+ return ERR_PTR(-EINVAL);
+ }
+ /* get raw value */
+ ret = of_property_read_u64(child, "adi,rsense-val-micro-ohms", &temp);
+ if (ret) {
+ dev_err(&st->spi->dev, "Property adi,rsense-val-micro-ohms missing\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ /* 2^10 resolution */
+ rsense->r_sense_val = __convert_to_raw(temp, 1024);
+
+ /* set common parameters */
+ rsense->sensor.assign_chan = ltc2983_r_sense_assign_chan;
+
+ return &rsense->sensor;
+}
+
+static struct ltc2983_sensor *ltc2983_adc_new(struct device_node *child,
+ struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_adc *adc;
+
+ adc = devm_kzalloc(&st->spi->dev, sizeof(*adc), GFP_KERNEL);
+ if (!adc)
+ return ERR_PTR(-ENOMEM);
+
+ if (of_property_read_bool(child, "adi,single-ended"))
+ adc->single_ended = true;
+
+ if (!adc->single_ended &&
+ sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
+ dev_err(&st->spi->dev, "Invalid chan:%d for differential adc\n",
+ sensor->chan);
+ return ERR_PTR(-EINVAL);
+ }
+ /* set common parameters */
+ adc->sensor.assign_chan = ltc2983_adc_assign_chan;
+ adc->sensor.fault_handler = ltc2983_common_fault_handler;
+
+ return &adc->sensor;
+}
+
+static int ltc2983_chan_read(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor, int *val)
+{
+ u32 start_conversion = 0;
+ int ret;
+ unsigned long time;
+ __be32 temp;
+
+ /*
+ * Do not allow channel readings if device is in sleep state.
+ * A read/write on the spi bus would bring the device prematurely
+ * out of sleep.
+ */
+ if (st->sleep)
+ return -EPERM;
+
+ start_conversion = LTC2983_STATUS_START(true);
+ start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
+ dev_dbg(&st->spi->dev, "Start conversion on chan:%d, status:%02X\n",
+ sensor->chan, start_conversion);
+ /* start conversion */
+ ret = regmap_write(st->regmap, LTC2983_STATUS_REG, start_conversion);
+ if (ret)
+ return ret;
+
+ reinit_completion(&st->completion);
+ /*
+ * wait for conversion to complete.
+ * 300 ms should be more than enough to complete the conversion.
+ * Depending on the sensor configuration, there are 2/3 conversions
+ * cycles of 82ms.
+ */
+ time = wait_for_completion_timeout(&st->completion,
+ msecs_to_jiffies(300));
+ if (!time) {
+ dev_warn(&st->spi->dev, "Conversion timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ /* read the converted data */
+ ret = regmap_bulk_read(st->regmap, LTC2983_CHAN_RES_ADDR(sensor->chan),
+ &temp, sizeof(temp));
+ if (ret)
+ return ret;
+
+ *val = __be32_to_cpu(temp);
+
+ if (!(LTC2983_RES_VALID_MASK & *val)) {
+ dev_err(&st->spi->dev, "Invalid conversion detected\n");
+ return -EIO;
+ }
+
+ ret = sensor->fault_handler(st, *val);
+ if (ret)
+ return ret;
+
+ *val = sign_extend32((*val) & LTC2983_DATA_MASK, LTC2983_DATA_SIGN_BIT);
+ return 0;
+}
+
+static int ltc2983_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct ltc2983_data *st = iio_priv(indio_dev);
+ int ret;
+
+ /* sanity check */
+ if (chan->address >= st->num_channels) {
+ dev_err(&st->spi->dev, "Invalid chan address:%ld",
+ chan->address);
+ return -EINVAL;
+ }
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ mutex_lock(&st->lock);
+ ret = ltc2983_chan_read(st, st->sensors[chan->address], val);
+ mutex_unlock(&st->lock);
+ return ret ?: IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->type) {
+ case IIO_TEMP:
+ /* value in milli degrees */
+ *val = 1000;
+ /* 2^10 */
+ *val2 = 1024;
+ return IIO_VAL_FRACTIONAL;
+ case IIO_VOLTAGE:
+ /* value in millivolt */
+ *val = 1000;
+ /* 2^21 */
+ *val2 = 2097152;
+ return IIO_VAL_FRACTIONAL;
+ default:
+ return -EINVAL;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static int ltc2983_reg_access(struct iio_dev *indio_dev,
+ unsigned int reg,
+ unsigned int writeval,
+ unsigned int *readval)
+{
+ struct ltc2983_data *st = iio_priv(indio_dev);
+
+ /* check comment in ltc2983_chan_read() */
+ if (st->sleep)
+ return -EPERM;
+
+ if (readval)
+ return regmap_read(st->regmap, reg, readval);
+ else
+ return regmap_write(st->regmap, reg, writeval);
+}
+
+static irqreturn_t ltc2983_irq_handler(int irq, void *data)
+{
+ struct ltc2983_data *st = data;
+
+ complete(&st->completion);
+ return IRQ_HANDLED;
+}
+
+#define LTC2983_CHAN(__type, index, __address) ({ \
+ struct iio_chan_spec __chan = { \
+ .type = __type, \
+ .indexed = 1, \
+ .channel = index, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .address = __address, \
+ }; \
+ __chan; \
+})
+
+static int ltc2983_parse_dt(struct ltc2983_data *st)
+{
+ struct device_node *child;
+ struct device *dev = &st->spi->dev;
+ int ret = 0, chan = 0, channel_avail_mask = 0;
+
+ if (!of_property_read_bool(dev->of_node, "adi,temperature-celcius"))
+ st->temp_farenheit = true;
+
+ of_property_read_u32(dev->of_node, "adi,mux-delay-config-us",
+ &st->mux_delay_config);
+
+ of_property_read_u32(dev->of_node, "adi,filter-notch-freq",
+ &st->filter_notch_freq);
+
+ st->num_channels = of_get_available_child_count(dev->of_node);
+ st->sensors = devm_kcalloc(dev, st->num_channels, sizeof(*st->sensors),
+ GFP_KERNEL);
+ if (!st->sensors)
+ return -ENOMEM;
+
+ st->iio_channels = st->num_channels;
+ for_each_available_child_of_node(dev->of_node, child) {
+ struct ltc2983_sensor sensor;
+
+ ret = of_property_read_u32(child, "reg", &sensor.chan);
+ if (ret) {
+ dev_err(dev, "reg property must given for child nodes\n");
+ return ret;
+ }
+
+ /* check if we have a valid channel */
+ if (sensor.chan < LTC2983_MIN_CHANNELS_NR ||
+ sensor.chan > LTC2983_MAX_CHANNELS_NR) {
+ dev_err(dev,
+ "chan:%d must be from 1 to 20\n", sensor.chan);
+ return -EINVAL;
+ } else if (channel_avail_mask & BIT(sensor.chan)) {
+ dev_err(dev, "chan:%d already in use\n", sensor.chan);
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(child, "adi,sensor-type",
+ &sensor.type);
+ if (ret) {
+ dev_err(dev,
+ "adi,sensor-type property must given for child nodes\n");
+ return ret;
+ }
+
+ dev_dbg(dev, "Create new sensor, type %u, chann %u",
+ sensor.type,
+ sensor.chan);
+
+ if (sensor.type >= LTC2983_SENSOR_THERMOCOUPLE &&
+ sensor.type <= LTC2983_SENSOR_THERMOCOUPLE_CUSTOM) {
+ st->sensors[chan] = ltc2983_thermocouple_new(child, st,
+ &sensor);
+ } else if (sensor.type >= LTC2983_SENSOR_RTD &&
+ sensor.type <= LTC2983_SENSOR_RTD_CUSTOM) {
+ st->sensors[chan] = ltc2983_rtd_new(child, st, &sensor);
+ } else if (sensor.type >= LTC2983_SENSOR_THERMISTOR &&
+ sensor.type <= LTC2983_SENSOR_THERMISTOR_CUSTOM) {
+ st->sensors[chan] = ltc2983_thermistor_new(child, st,
+ &sensor);
+ } else if (sensor.type == LTC2983_SENSOR_DIODE) {
+ st->sensors[chan] = ltc2983_diode_new(child, st,
+ &sensor);
+ } else if (sensor.type == LTC2983_SENSOR_SENSE_RESISTOR) {
+ st->sensors[chan] = ltc2983_r_sense_new(child, st,
+ &sensor);
+ /* don't add rsense to iio */
+ st->iio_channels--;
+ } else if (sensor.type == LTC2983_SENSOR_DIRECT_ADC) {
+ st->sensors[chan] = ltc2983_adc_new(child, st, &sensor);
+ } else {
+ dev_err(dev, "Unknown sensor type %d\n", sensor.type);
+ return -EINVAL;
+ }
+
+ if (IS_ERR(st->sensors[chan])) {
+ dev_err(dev, "Failed to create sensor %ld",
+ PTR_ERR(st->sensors[chan]));
+ return PTR_ERR(st->sensors[chan]);
+ }
+ /* set generic sensor parameters */
+ st->sensors[chan]->chan = sensor.chan;
+ st->sensors[chan]->type = sensor.type;
+
+ channel_avail_mask |= BIT(sensor.chan);
+ chan++;
+ }
+
+ return 0;
+}
+
+static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
+{
+ u32 iio_chan_t = 0, iio_chan_v = 0, chan, iio_idx = 0;
+ u32 global_cfg = 0;
+ int ret;
+ unsigned long time;
+
+ /* make sure the device is up */
+ time = wait_for_completion_timeout(&st->completion,
+ msecs_to_jiffies(250));
+
+ if (!time) {
+ dev_err(&st->spi->dev, "Device startup timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ st->iio_chan = devm_kzalloc(&st->spi->dev,
+ st->iio_channels * sizeof(*st->iio_chan),
+ GFP_KERNEL);
+
+ if (!st->iio_chan)
+ return -ENOMEM;
+
+ global_cfg = LTC2983_NOTCH_FREQ(st->filter_notch_freq);
+ global_cfg |= LTC2983_TEMP_UNITS(st->temp_farenheit);
+ regmap_write(st->regmap, LTC2983_GLOBAL_CONFIG_REG, global_cfg);
+ regmap_write(st->regmap, LTC2983_MUX_CONFIG_REG, st->mux_delay_config);
+
+ for (chan = 0; chan < st->num_channels; chan++) {
+ u32 chan_type = 0, *iio_chan;
+
+ ret = st->sensors[chan]->assign_chan(st, st->sensors[chan]);
+ if (ret)
+ return ret;
+ /*
+ * The assign_iio flag is necessary for when the device is
+ * coming out of sleep. In that case, we just need to
+ * re-configure the device channels.
+ * We also don't assign iio channels for rsense.
+ */
+ if (st->sensors[chan]->type == LTC2983_SENSOR_SENSE_RESISTOR ||
+ !assign_iio)
+ continue;
+
+ /* assign iio channel */
+ if (st->sensors[chan]->type != LTC2983_SENSOR_DIRECT_ADC) {
+ chan_type = IIO_TEMP;
+ iio_chan = &iio_chan_t;
+ } else {
+ chan_type = IIO_VOLTAGE;
+ iio_chan = &iio_chan_v;
+ }
+
+ /*
+ * add chan as the iio .address so that, we can directly
+ * reference the sensor given the iio_chan_spec
+ */
+ st->iio_chan[iio_idx++] = LTC2983_CHAN(chan_type, (*iio_chan)++,
+ chan);
+ }
+
+ return 0;
+}
+
+static const struct regmap_range ltc2983_reg_ranges[] = {
+ regmap_reg_range(LTC2983_STATUS_REG, LTC2983_STATUS_REG),
+ regmap_reg_range(LTC2983_TEMP_RES_START_REG, LTC2983_TEMP_RES_END_REG),
+ regmap_reg_range(LTC2983_GLOBAL_CONFIG_REG, LTC2983_GLOBAL_CONFIG_REG),
+ regmap_reg_range(LTC2983_MULT_CHANNEL_START_REG,
+ LTC2983_MULT_CHANNEL_END_REG),
+ regmap_reg_range(LTC2983_MUX_CONFIG_REG, LTC2983_MUX_CONFIG_REG),
+ regmap_reg_range(LTC2983_CHAN_ASSIGN_START_REG,
+ LTC2983_CHAN_ASSIGN_END_REG),
+ regmap_reg_range(LTC2983_CUST_SENS_TBL_START_REG,
+ LTC2983_CUST_SENS_TBL_END_REG),
+};
+
+static const struct regmap_access_table ltc2983_reg_table = {
+ .yes_ranges = ltc2983_reg_ranges,
+ .n_yes_ranges = ARRAY_SIZE(ltc2983_reg_ranges),
+};
+
+/*
+ * The reg_bits are actually 12 but the device needs the first *complete*
+ * byte for the command (R/W).
+ */
+static const struct regmap_config ltc2983_regmap_config = {
+ .reg_bits = 24,
+ .val_bits = 8,
+ .wr_table = <c2983_reg_table,
+ .rd_table = <c2983_reg_table,
+ .read_flag_mask = GENMASK(1, 0),
+ .write_flag_mask = BIT(1),
+};
+
+static const struct iio_info ltc2983_iio_info = {
+ .read_raw = ltc2983_read_raw,
+ .debugfs_reg_access = ltc2983_reg_access,
+};
+
+static int ltc2983_probe(struct spi_device *spi)
+{
+ struct ltc2983_data *st;
+ struct iio_dev *indio_dev;
+ const char *name = spi_get_device_id(spi)->name;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+
+ st->regmap = devm_regmap_init_spi(spi, <c2983_regmap_config);
+ if (IS_ERR(st->regmap)) {
+ dev_err(&spi->dev, "Failed to initialize regmap\n");
+ return PTR_ERR(st->regmap);
+ }
+
+ mutex_init(&st->lock);
+ init_completion(&st->completion);
+ st->spi = spi;
+ spi_set_drvdata(spi, st);
+
+ ret = ltc2983_parse_dt(st);
+ if (ret)
+ return ret;
+ /*
+ * let's request the irq now so it is used to sync the device
+ * startup in ltc2983_setup()
+ */
+ ret = devm_request_irq(&spi->dev, spi->irq, ltc2983_irq_handler,
+ IRQF_TRIGGER_RISING, name, st);
+ if (ret) {
+ dev_err(&spi->dev, "failed to request an irq, %d", ret);
+ return ret;
+ }
+
+ ret = ltc2983_setup(st, true);
+ if (ret)
+ return ret;
+
+ indio_dev->dev.parent = &spi->dev;
+ indio_dev->name = name;
+ indio_dev->num_channels = st->iio_channels;
+ indio_dev->channels = st->iio_chan;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->info = <c2983_iio_info;
+
+ return devm_iio_device_register(&spi->dev, indio_dev);
+}
+
+static int __maybe_unused ltc2983_resume(struct device *dev)
+{
+ struct ltc2983_data *st = spi_get_drvdata(to_spi_device(dev));
+ int ret;
+
+ mutex_lock(&st->lock);
+ /* dummy read to bring the device out of sleep */
+ regmap_read(st->regmap, LTC2983_STATUS_REG, &ret);
+ /* we need to re-assign the channels */
+ ret = ltc2983_setup(st, false);
+ st->sleep = false;
+ mutex_unlock(&st->lock);
+
+ return ret;
+}
+
+static int __maybe_unused ltc2983_suspend(struct device *dev)
+{
+ struct ltc2983_data *st = spi_get_drvdata(to_spi_device(dev));
+ int ret;
+
+ mutex_lock(&st->lock);
+ ret = regmap_write(st->regmap, LTC2983_STATUS_REG, LTC2983_SLEEP);
+ st->sleep = true;
+ mutex_unlock(&st->lock);
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(ltc2983_pm_ops, ltc2983_suspend, ltc2983_resume);
+
+static const struct spi_device_id ltc2983_id_table[] = {
+ { "ltc2983" },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, ltc2983_id_table);
+
+static const struct of_device_id ltc2983_of_match[] = {
+ { .compatible = "adi,ltc2983" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ltc2983_id_table);
+
+static struct spi_driver ltc2983_driver = {
+ .driver = {
+ .name = "ltc2983",
+ .of_match_table = ltc2983_of_match,
+ .pm = <c2983_pm_ops,
+ },
+ .probe = ltc2983_probe,
+ .id_table = ltc2983_id_table,
+};
+
+module_spi_driver(ltc2983_driver);
+
+MODULE_AUTHOR("Nuno Sa <nuno.sa@analog.com>");
+MODULE_DESCRIPTION("Analog Devices LTC2983 SPI Temperature sensors");
+MODULE_LICENSE("GPL");
--
2.23.0
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-04 13:55 [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Nuno Sá
@ 2019-10-04 13:55 ` Nuno Sá
2019-10-06 10:29 ` Jonathan Cameron
2019-10-07 14:45 ` Rob Herring
2019-10-06 10:37 ` [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Jonathan Cameron
2019-10-08 10:55 ` Sa, Nuno
2 siblings, 2 replies; 15+ messages in thread
From: Nuno Sá @ 2019-10-04 13:55 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland
Document the LTC2983 temperature sensor devicetree bindings.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
Changes in v2:
* Drop maxItems in non-array elements;
* Set adi,mux-delay-config-us instead of adi,mux-delay-config;
* Wrapped lines at 80 char;
* Added comas to enum elements;
* Use real units in adi,excitation-current;
* Moved some enums to minimum and maximum;
* Grouped patternProperties and moved reg property as a generic property.
Changes in v3:
* Add meaning to adi,sensor-type values which are not const;
* Add meaning to adi,filter-notch-freq values;
* Break up adi,sensor-config into human readable elements;
* Set maxItems/minItems at the same identation as allOf in adi,custom-sensor;
* Fixed the maximum value for adi,sensor-type for sensors with custom support;
* Changed license to GPL-2.0-only as it should be for new bindings;
* Changed spi0 to spi in the dts example;
* Updated the dts example to the new properties.
.../bindings/iio/temperature/adi,ltc2983.yaml | 479 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 480 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
new file mode 100644
index 000000000000..b7101a0e84db
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
@@ -0,0 +1,479 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC2983 Multi-sensor Temperature system
+
+maintainers:
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ Analog Devices LTC2983 Multi-Sensor Digital Temperature Measurement System
+ https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc2983
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ adi,temperature-celcius:
+ description:
+ If this property is present, the temperature is reported in Celsius.
+ type: boolean
+
+ adi,mux-delay-config-us:
+ description:
+ The LTC2983 performs 2 or 3 internal conversion cycles per temperature
+ result. Each conversion cycle is performed with different excitation and
+ input multiplexer configurations. Prior to each conversion, these
+ excitation circuits and input switch configurations are changed and an
+ internal 1ms delay ensures settling prior to the conversion cycle in most
+ cases. An extra delay can be configured using this property. The value is
+ rounded to nearest 100us.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - maximum: 255
+
+ adi,filter-notch-freq:
+ description:
+ Set's the default setting of the digital filter. The default is
+ simultaneous 50/60Hz rejection.
+ 0 - 50/60Hz rejection
+ 1 - 60Hz rejection
+ 2 - 50Hz rejection
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ - maximum: 2
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+patternProperties:
+ ".*@([1-9]|1[0-9]|20)$":
+ type: object
+
+ properties:
+ reg:
+ description: |
+ The channel number. It can be connected to one of the 20 channels of
+ the device.
+ minimum: 1
+ maximum: 20
+
+ required:
+ - reg
+
+ patternProperties:
+ "^thermocouple@.*":
+ type: object
+ description: |
+ Represents a thermocouple sensor which is connected to one of the device
+ channels.
+
+ properties:
+ adi,sensor-type:
+ description: |
+ Identifies the type of thermocouple connected to the device.
+ 1 - Type J Thermocouple
+ 2 - Type K Thermocouple
+ 3 - Type E Thermocouple
+ 4 - Type N Thermocouple
+ 5 - Type R Thermocouple
+ 6 - Type S Thermocouple
+ 7 - Type T Thermocouple
+ 8 - Type B Thermocouple
+ 9 - Custom Thermocouple
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 1
+ - maximum: 9
+
+ adi,single-ended:
+ description: |
+ Boolean property which set's the thermocouple as single-ended.
+ type: boolean
+
+ adi,sensor-oc-current-microamp:
+ description: |
+ This property set's the pulsed current value applied during
+ open-circuit detect.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [10, 100, 500, 1000]
+
+ adi,cold-junction-handle:
+ description: |
+ Phandle which points to a sensor object responsible for measuring
+ the thermocouple cold junction temperature.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ adi,custom-sensor:
+ description: |
+ This is a table, where each entry should be a pair of
+ voltage(mv)-temperature(K). The entries must be given in nv and uK
+ so that, the original values must be multiplied by 1000000. For
+ more details look at table 69 and 70.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/int64-array
+ minItems: 6
+ maxItems: 128
+
+ required:
+ - adi,sensor-type
+
+ "^diode@.*":
+ type: object
+ description: |
+ Represents a diode sensor which is connected to one of the device
+ channels.
+
+ properties:
+ adi,sensor-type:
+ description: Identifies the sensor as a diode.
+ const: 28
+
+ adi,single-ended:
+ description: Boolean property which set's the diode as single-ended.
+ type: boolean
+
+ adi,three-conversion-cycles:
+ description: |
+ Boolean property which set's three conversion cycles removing
+ parasitic resistance effects between the LTC2983 and the diode.
+ type: boolean
+
+ adi,average-on:
+ description: |
+ Boolean property which enables a running average of the diode
+ temperature reading. This reduces the noise when the diode is used
+ as a cold junction temperature element on an isothermal block
+ where temperatures change slowly.
+ type: boolean
+
+ adi,excitation-current-microamp:
+ description: |
+ This property controls the magnitude of the excitation current
+ applied to the diode. Depending on the number of conversions
+ cycles, this property will assume different predefined values on
+ each cycle. Just set the value of the first cycle (1l).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [10, 20, 40, 80]
+
+ adi,ideal-factor-value:
+ description: |
+ This property sets the diode ideality factor. The real value must
+ be multiplied by 1000000 to remove the fractional part. For more
+ information look at table 20 of the datasheet.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - adi,sensor-type
+
+ "^rtd@.*":
+ type: object
+ description: |
+ Represents a rtd sensor which is connected to one of the device channels.
+
+ properties:
+ reg:
+ minimum: 2
+
+ adi,sensor-type:
+ description: |
+ Identifies the type of RTD connected to the device.
+ 10 - RTD PT-10
+ 11 - RTD PT-50
+ 12 - RTD PT-100
+ 13 - RTD PT-200
+ 14 - RTD PT-500
+ 15 - RTD PT-1000
+ 16 - RTD PT-1000 (0.00375)
+ 17 - RTD NI-120
+ 18 - RTD Custom
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 10
+ - maximum: 18
+
+ adi,rsense-handle:
+ description: |
+ Phandle pointing to a rsense object associated with this RTD.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ adi,number-of-wires:
+ description: |
+ Identifies the number of wires used by the RTD. Setting this
+ property to 5 means 4 wires with Kelvin Rsense.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [2, 3, 4, 5]
+
+ adi,rsense-share:
+ description: |
+ Boolean property which enables Rsense sharing, where one sense
+ resistor is used for multiple 2-, 3-, and/or 4-wire RTDs.
+ type: boolean
+
+ adi,current-rotate:
+ description: |
+ Boolean property which enables excitation current rotation to
+ automatically remove parasitic thermocouple effects. Note that
+ this property is not allowed for 2- and 3-wire RTDs.
+ type: boolean
+
+ adi,excitation-current-microamp:
+ description: |
+ This property controls the magnitude of the excitation current
+ applied to the RTD.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
+
+ adi,rtd-curve:
+ description: |
+ This property set the RTD curve used and the corresponding
+ Callendar-VanDusen constants. Look at table 30 of the datasheet.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ - maximum: 3
+
+ adi,custom-sensor:
+ description: |
+ This is a table, where each entry should be a pair of
+ resistance(ohm)-temperature(K). The entries added here are in uohm
+ and uK. For more details values look at table 74 and 75.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 6
+ maxItems: 128
+
+ required:
+ - adi,sensor-type
+ - adi,rsense-handle
+
+ dependencies:
+ adi,current-rotate: [ adi,rsense-share ]
+
+ "^thermistor@.*":
+ type: object
+ description: |
+ Represents a thermistor sensor which is connected to one of the device
+ channels.
+
+ properties:
+ adi,sensor-type:
+ description: |
+ Identifies the type of thermistor connected to the
+ device.
+ 19 - Thermistor 44004/44033 2.252kohm at 25°C
+ 20 - Thermistor 44005/44030 3kohm at 25°C
+ 21 - Thermistor 44007/44034 5kohm at 25°C
+ 22 - Thermistor 44006/44031 10kohm at 25°C
+ 23 - Thermistor 44008/44032 30kohm at 25°C
+ 24 - Thermistor YSI 400 2.252kohm at 25°C
+ 25 - Thermistor Spectrum 1003k 1kohm
+ 26 - Thermistor Custom Steinhart-Hart
+ 27 - Custom Thermistor
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 19
+ - maximum: 27
+
+ adi,rsense-handle:
+ description: |
+ Phandle pointing to a rsense object associated with this
+ thermistor.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ adi,single-ended:
+ description: |
+ Boolean property which set's the thermistor as single-ended.
+ type: boolean
+
+ adi,rsense-share:
+ description: |
+ Boolean property which enables Rsense sharing, where one sense
+ resistor is used for multiple thermistors. Note that this property
+ is ignored if adi,single-ended is set.
+ type: boolean
+
+ adi,current-rotate:
+ description: |
+ Boolean property which enables excitation current rotation to
+ automatically remove parasitic thermocouple effects.
+ type: boolean
+
+ adi,excitation-current-nanoamp:
+ description: |
+ This property controls the magnitude of the excitation current
+ applied to the thermistor. Value 0 set's the sensor in auto-range
+ mode.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - enum: [0, 250, 500, 1000, 5000, 10000, 25000, 50000, 100000,
+ 250000, 500000, 1000000]
+
+ adi,custom-sensor:
+ description: |
+ This is a table, where each entry should be a pair of
+ resistance(ohm)-temperature(K). The entries added here are in uohm
+ and uK only for custom thermistors. For more details look at table
+ 78 and 79. Steinhart-Hart coefficients are also supported and can
+ be programmed into the device memory using this property. For
+ Steinhart sensors, this table has a constant size of 6 entries
+ (defining the coefficients) and the values are given in the raw
+ format. Look at table 82 for more information.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 6
+ maxItems: 128
+
+ required:
+ - adi,sensor-type
+ - adi,rsense-handle
+
+ dependencies:
+ adi,current-rotate: [ adi,rsense-share ]
+
+ "^adc@.*":
+ type: object
+ description: Represents a channel which is being used as a direct adc.
+
+ properties:
+ adi,sensor-type:
+ description: Identifies the sensor as a direct adc.
+ const: 30
+
+ adi,single-ended:
+ description: Boolean property which set's the adc as single-ended.
+ type: boolean
+
+ required:
+ - adi,sensor-type
+
+ "^rsense@.*":
+ type: object
+ description: |
+ Represents a rsense which is connected to one of the device channels.
+ Rsense are used by thermistors and RTD's.
+
+ properties:
+ reg:
+ minimum: 2
+
+ adi,sensor-type:
+ description: Identifies the sensor as a rsense.
+ const: 29
+
+ adi,rsense-val-micro-ohms:
+ description: |
+ Sets the value of the sense resistor. Look at table 20 of the
+ datasheet for information.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint64
+
+ required:
+ - adi,sensor-type
+ - adi, rsense-val
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor_ltc2983: ltc2983@0 {
+ compatible = "adi,ltc2983";
+ reg = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adi,temperature-celcius;
+ interrupts = <20 IRQ_TYPE_EDGE_RISING>;
+ interrupt-parent = <&gpio>;
+
+ thermocouple@18 {
+ reg = <18>;
+ adi,sensor-type = <8>; //Type B
+ adi,sensor-oc-current-microamp = <10>;
+ adi,cold-junction-handle = <&diode5>;
+ };
+
+ diode5: diode@5 {
+ reg = <5>;
+ adi,sensor-type = <28>;
+ };
+
+ rsense2: rsense@2 {
+ reg = <2>;
+ adi,sensor-type = <29>;
+ adi,rsense-val-micro-ohms = /bits/ 64 <1200000000>; //1.2Kohms
+ };
+
+ rtd@14 {
+ reg = <14>;
+ adi,sensor-type = <15>; //PT1000
+ /*2-wire, internal gnd, no current rotation*/
+ adi,number-of-wires = <2>;
+ adi,rsense-share;
+ adi,excitation-current-microamp = <500>;
+ adi,rsense-handle = <&rsense2>;
+ };
+
+ adc@10 {
+ reg = <10>;
+ adi,sensor-type = <30>;
+ adi,single-ended;
+ };
+
+ thermistor@12 {
+ reg = <12>;
+ adi,sensor-type = <26>; //Steinhart
+ adi,rsense-handle = <&rsense2>;
+ adi,custom-sensor = /bits/ 64 <0x00F371EC 0x12345678
+ 0x2C0F8733 0x10018C66 0xA0FEACCD
+ 0x90021D99>; //6 entries
+ };
+
+ thermocouple@20 {
+ reg = <20>;
+ adi,sensor-type = <9>; //custom thermocouple
+ adi,single-ended;
+ adi,custom-sensor = /bits/ 64
+ <(-50220000) 0
+ (-30200000) 99100000
+ (-5300000) 135400000
+ 0 273150000
+ 40200000 361200000
+ 55300000 522100000
+ 88300000 720300000
+ 132200000 811200000
+ 188700000 922500000
+ 460400000 1000000000>; //10 pairs
+ };
+
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 14a256e785ca..f747a9dc27f5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9497,6 +9497,7 @@ W: http://ez.analog.com/community/linux-device-drivers
L: linux-iio@vger.kernel.org
S: Supported
F: drivers/iio/temperature/ltc2983.c
+F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
LTC4261 HARDWARE MONITOR DRIVER
M: Guenter Roeck <linux@roeck-us.net>
--
2.23.0
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
@ 2019-10-06 10:29 ` Jonathan Cameron
2019-10-07 14:45 ` Rob Herring
1 sibling, 0 replies; 15+ messages in thread
From: Jonathan Cameron @ 2019-10-06 10:29 UTC (permalink / raw)
To: Nuno Sá
Cc: linux-iio, devicetree, knaack.h, lars, pmeerw, robh+dt, mark.rutland
On Fri, 4 Oct 2019 15:55:19 +0200
Nuno Sá <nuno.sa@analog.com> wrote:
> Document the LTC2983 temperature sensor devicetree bindings.
>
> Signed-off-by: Nuno Sá <nuno.sa@analog.com>
I'm out of my depth on this one so will be relying on Rob or Mark to take
a look.
Thanks,
Jonathan
> ---
> Changes in v2:
> * Drop maxItems in non-array elements;
> * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> * Wrapped lines at 80 char;
> * Added comas to enum elements;
> * Use real units in adi,excitation-current;
> * Moved some enums to minimum and maximum;
> * Grouped patternProperties and moved reg property as a generic property.
>
> Changes in v3:
> * Add meaning to adi,sensor-type values which are not const;
> * Add meaning to adi,filter-notch-freq values;
> * Break up adi,sensor-config into human readable elements;
> * Set maxItems/minItems at the same identation as allOf in adi,custom-sensor;
> * Fixed the maximum value for adi,sensor-type for sensors with custom support;
> * Changed license to GPL-2.0-only as it should be for new bindings;
> * Changed spi0 to spi in the dts example;
> * Updated the dts example to the new properties.
>
> .../bindings/iio/temperature/adi,ltc2983.yaml | 479 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 480 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> new file mode 100644
> index 000000000000..b7101a0e84db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> @@ -0,0 +1,479 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices LTC2983 Multi-sensor Temperature system
> +
> +maintainers:
> + - Nuno Sá <nuno.sa@analog.com>
> +
> +description: |
> + Analog Devices LTC2983 Multi-Sensor Digital Temperature Measurement System
> + https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> +
> +properties:
> + compatible:
> + enum:
> + - adi,ltc2983
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + adi,temperature-celcius:
> + description:
> + If this property is present, the temperature is reported in Celsius.
> + type: boolean
> +
> + adi,mux-delay-config-us:
> + description:
> + The LTC2983 performs 2 or 3 internal conversion cycles per temperature
> + result. Each conversion cycle is performed with different excitation and
> + input multiplexer configurations. Prior to each conversion, these
> + excitation circuits and input switch configurations are changed and an
> + internal 1ms delay ensures settling prior to the conversion cycle in most
> + cases. An extra delay can be configured using this property. The value is
> + rounded to nearest 100us.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - maximum: 255
> +
> + adi,filter-notch-freq:
> + description:
> + Set's the default setting of the digital filter. The default is
> + simultaneous 50/60Hz rejection.
> + 0 - 50/60Hz rejection
> + 1 - 60Hz rejection
> + 2 - 50Hz rejection
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 0
> + - maximum: 2
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + ".*@([1-9]|1[0-9]|20)$":
> + type: object
> +
> + properties:
> + reg:
> + description: |
> + The channel number. It can be connected to one of the 20 channels of
> + the device.
> + minimum: 1
> + maximum: 20
> +
> + required:
> + - reg
> +
> + patternProperties:
> + "^thermocouple@.*":
> + type: object
> + description: |
> + Represents a thermocouple sensor which is connected to one of the device
> + channels.
> +
> + properties:
> + adi,sensor-type:
> + description: |
> + Identifies the type of thermocouple connected to the device.
> + 1 - Type J Thermocouple
> + 2 - Type K Thermocouple
> + 3 - Type E Thermocouple
> + 4 - Type N Thermocouple
> + 5 - Type R Thermocouple
> + 6 - Type S Thermocouple
> + 7 - Type T Thermocouple
> + 8 - Type B Thermocouple
> + 9 - Custom Thermocouple
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 1
> + - maximum: 9
> +
> + adi,single-ended:
> + description: |
> + Boolean property which set's the thermocouple as single-ended.
> + type: boolean
> +
> + adi,sensor-oc-current-microamp:
> + description: |
> + This property set's the pulsed current value applied during
> + open-circuit detect.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [10, 100, 500, 1000]
> +
> + adi,cold-junction-handle:
> + description: |
> + Phandle which points to a sensor object responsible for measuring
> + the thermocouple cold junction temperature.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + adi,custom-sensor:
> + description: |
> + This is a table, where each entry should be a pair of
> + voltage(mv)-temperature(K). The entries must be given in nv and uK
> + so that, the original values must be multiplied by 1000000. For
> + more details look at table 69 and 70.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/int64-array
> + minItems: 6
> + maxItems: 128
> +
> + required:
> + - adi,sensor-type
> +
> + "^diode@.*":
> + type: object
> + description: |
> + Represents a diode sensor which is connected to one of the device
> + channels.
> +
> + properties:
> + adi,sensor-type:
> + description: Identifies the sensor as a diode.
> + const: 28
> +
> + adi,single-ended:
> + description: Boolean property which set's the diode as single-ended.
> + type: boolean
> +
> + adi,three-conversion-cycles:
> + description: |
> + Boolean property which set's three conversion cycles removing
> + parasitic resistance effects between the LTC2983 and the diode.
> + type: boolean
> +
> + adi,average-on:
> + description: |
> + Boolean property which enables a running average of the diode
> + temperature reading. This reduces the noise when the diode is used
> + as a cold junction temperature element on an isothermal block
> + where temperatures change slowly.
> + type: boolean
> +
> + adi,excitation-current-microamp:
> + description: |
> + This property controls the magnitude of the excitation current
> + applied to the diode. Depending on the number of conversions
> + cycles, this property will assume different predefined values on
> + each cycle. Just set the value of the first cycle (1l).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [10, 20, 40, 80]
> +
> + adi,ideal-factor-value:
> + description: |
> + This property sets the diode ideality factor. The real value must
> + be multiplied by 1000000 to remove the fractional part. For more
> + information look at table 20 of the datasheet.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> +
> + required:
> + - adi,sensor-type
> +
> + "^rtd@.*":
> + type: object
> + description: |
> + Represents a rtd sensor which is connected to one of the device channels.
> +
> + properties:
> + reg:
> + minimum: 2
> +
> + adi,sensor-type:
> + description: |
> + Identifies the type of RTD connected to the device.
> + 10 - RTD PT-10
> + 11 - RTD PT-50
> + 12 - RTD PT-100
> + 13 - RTD PT-200
> + 14 - RTD PT-500
> + 15 - RTD PT-1000
> + 16 - RTD PT-1000 (0.00375)
> + 17 - RTD NI-120
> + 18 - RTD Custom
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 10
> + - maximum: 18
> +
> + adi,rsense-handle:
> + description: |
> + Phandle pointing to a rsense object associated with this RTD.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + adi,number-of-wires:
> + description: |
> + Identifies the number of wires used by the RTD. Setting this
> + property to 5 means 4 wires with Kelvin Rsense.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [2, 3, 4, 5]
> +
> + adi,rsense-share:
> + description: |
> + Boolean property which enables Rsense sharing, where one sense
> + resistor is used for multiple 2-, 3-, and/or 4-wire RTDs.
> + type: boolean
> +
> + adi,current-rotate:
> + description: |
> + Boolean property which enables excitation current rotation to
> + automatically remove parasitic thermocouple effects. Note that
> + this property is not allowed for 2- and 3-wire RTDs.
> + type: boolean
> +
> + adi,excitation-current-microamp:
> + description: |
> + This property controls the magnitude of the excitation current
> + applied to the RTD.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> +
> + adi,rtd-curve:
> + description: |
> + This property set the RTD curve used and the corresponding
> + Callendar-VanDusen constants. Look at table 30 of the datasheet.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 0
> + - maximum: 3
> +
> + adi,custom-sensor:
> + description: |
> + This is a table, where each entry should be a pair of
> + resistance(ohm)-temperature(K). The entries added here are in uohm
> + and uK. For more details values look at table 74 and 75.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint64-array
> + minItems: 6
> + maxItems: 128
> +
> + required:
> + - adi,sensor-type
> + - adi,rsense-handle
> +
> + dependencies:
> + adi,current-rotate: [ adi,rsense-share ]
> +
> + "^thermistor@.*":
> + type: object
> + description: |
> + Represents a thermistor sensor which is connected to one of the device
> + channels.
> +
> + properties:
> + adi,sensor-type:
> + description: |
> + Identifies the type of thermistor connected to the
> + device.
> + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> + 20 - Thermistor 44005/44030 3kohm at 25°C
> + 21 - Thermistor 44007/44034 5kohm at 25°C
> + 22 - Thermistor 44006/44031 10kohm at 25°C
> + 23 - Thermistor 44008/44032 30kohm at 25°C
> + 24 - Thermistor YSI 400 2.252kohm at 25°C
> + 25 - Thermistor Spectrum 1003k 1kohm
> + 26 - Thermistor Custom Steinhart-Hart
> + 27 - Custom Thermistor
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 19
> + - maximum: 27
> +
> + adi,rsense-handle:
> + description: |
> + Phandle pointing to a rsense object associated with this
> + thermistor.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + adi,single-ended:
> + description: |
> + Boolean property which set's the thermistor as single-ended.
> + type: boolean
> +
> + adi,rsense-share:
> + description: |
> + Boolean property which enables Rsense sharing, where one sense
> + resistor is used for multiple thermistors. Note that this property
> + is ignored if adi,single-ended is set.
> + type: boolean
> +
> + adi,current-rotate:
> + description: |
> + Boolean property which enables excitation current rotation to
> + automatically remove parasitic thermocouple effects.
> + type: boolean
> +
> + adi,excitation-current-nanoamp:
> + description: |
> + This property controls the magnitude of the excitation current
> + applied to the thermistor. Value 0 set's the sensor in auto-range
> + mode.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [0, 250, 500, 1000, 5000, 10000, 25000, 50000, 100000,
> + 250000, 500000, 1000000]
> +
> + adi,custom-sensor:
> + description: |
> + This is a table, where each entry should be a pair of
> + resistance(ohm)-temperature(K). The entries added here are in uohm
> + and uK only for custom thermistors. For more details look at table
> + 78 and 79. Steinhart-Hart coefficients are also supported and can
> + be programmed into the device memory using this property. For
> + Steinhart sensors, this table has a constant size of 6 entries
> + (defining the coefficients) and the values are given in the raw
> + format. Look at table 82 for more information.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint64-array
> + minItems: 6
> + maxItems: 128
> +
> + required:
> + - adi,sensor-type
> + - adi,rsense-handle
> +
> + dependencies:
> + adi,current-rotate: [ adi,rsense-share ]
> +
> + "^adc@.*":
> + type: object
> + description: Represents a channel which is being used as a direct adc.
> +
> + properties:
> + adi,sensor-type:
> + description: Identifies the sensor as a direct adc.
> + const: 30
> +
> + adi,single-ended:
> + description: Boolean property which set's the adc as single-ended.
> + type: boolean
> +
> + required:
> + - adi,sensor-type
> +
> + "^rsense@.*":
> + type: object
> + description: |
> + Represents a rsense which is connected to one of the device channels.
> + Rsense are used by thermistors and RTD's.
> +
> + properties:
> + reg:
> + minimum: 2
> +
> + adi,sensor-type:
> + description: Identifies the sensor as a rsense.
> + const: 29
> +
> + adi,rsense-val-micro-ohms:
> + description: |
> + Sets the value of the sense resistor. Look at table 20 of the
> + datasheet for information.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint64
> +
> + required:
> + - adi,sensor-type
> + - adi, rsense-val
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sensor_ltc2983: ltc2983@0 {
> + compatible = "adi,ltc2983";
> + reg = <0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adi,temperature-celcius;
> + interrupts = <20 IRQ_TYPE_EDGE_RISING>;
> + interrupt-parent = <&gpio>;
> +
> + thermocouple@18 {
> + reg = <18>;
> + adi,sensor-type = <8>; //Type B
> + adi,sensor-oc-current-microamp = <10>;
> + adi,cold-junction-handle = <&diode5>;
> + };
> +
> + diode5: diode@5 {
> + reg = <5>;
> + adi,sensor-type = <28>;
> + };
> +
> + rsense2: rsense@2 {
> + reg = <2>;
> + adi,sensor-type = <29>;
> + adi,rsense-val-micro-ohms = /bits/ 64 <1200000000>; //1.2Kohms
> + };
> +
> + rtd@14 {
> + reg = <14>;
> + adi,sensor-type = <15>; //PT1000
> + /*2-wire, internal gnd, no current rotation*/
> + adi,number-of-wires = <2>;
> + adi,rsense-share;
> + adi,excitation-current-microamp = <500>;
> + adi,rsense-handle = <&rsense2>;
> + };
> +
> + adc@10 {
> + reg = <10>;
> + adi,sensor-type = <30>;
> + adi,single-ended;
> + };
> +
> + thermistor@12 {
> + reg = <12>;
> + adi,sensor-type = <26>; //Steinhart
> + adi,rsense-handle = <&rsense2>;
> + adi,custom-sensor = /bits/ 64 <0x00F371EC 0x12345678
> + 0x2C0F8733 0x10018C66 0xA0FEACCD
> + 0x90021D99>; //6 entries
> + };
> +
> + thermocouple@20 {
> + reg = <20>;
> + adi,sensor-type = <9>; //custom thermocouple
> + adi,single-ended;
> + adi,custom-sensor = /bits/ 64
> + <(-50220000) 0
> + (-30200000) 99100000
> + (-5300000) 135400000
> + 0 273150000
> + 40200000 361200000
> + 55300000 522100000
> + 88300000 720300000
> + 132200000 811200000
> + 188700000 922500000
> + 460400000 1000000000>; //10 pairs
> + };
> +
> + };
> + };
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 14a256e785ca..f747a9dc27f5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9497,6 +9497,7 @@ W: http://ez.analog.com/community/linux-device-drivers
> L: linux-iio@vger.kernel.org
> S: Supported
> F: drivers/iio/temperature/ltc2983.c
> +F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
>
> LTC4261 HARDWARE MONITOR DRIVER
> M: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
2019-10-06 10:29 ` Jonathan Cameron
@ 2019-10-07 14:45 ` Rob Herring
2019-10-07 16:17 ` Sa, Nuno
1 sibling, 1 reply; 15+ messages in thread
From: Rob Herring @ 2019-10-07 14:45 UTC (permalink / raw)
To: Nuno Sá
Cc: open list:IIO SUBSYSTEM AND DRIVERS, devicetree,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, Mark Rutland
On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com> wrote:
>
> Document the LTC2983 temperature sensor devicetree bindings.
>
> Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> ---
> Changes in v2:
> * Drop maxItems in non-array elements;
> * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> * Wrapped lines at 80 char;
> * Added comas to enum elements;
> * Use real units in adi,excitation-current;
> * Moved some enums to minimum and maximum;
> * Grouped patternProperties and moved reg property as a generic property.
>
> Changes in v3:
> * Add meaning to adi,sensor-type values which are not const;
> * Add meaning to adi,filter-notch-freq values;
> * Break up adi,sensor-config into human readable elements;
> * Set maxItems/minItems at the same identation as allOf in adi,custom-sensor;
> * Fixed the maximum value for adi,sensor-type for sensors with custom support;
> * Changed license to GPL-2.0-only as it should be for new bindings;
> * Changed spi0 to spi in the dts example;
> * Updated the dts example to the new properties.
>
> .../bindings/iio/temperature/adi,ltc2983.yaml | 479 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 480 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> new file mode 100644
> index 000000000000..b7101a0e84db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> @@ -0,0 +1,479 @@
> +# SPDX-License-Identifier: GPL-2.0-only
(GPL-2.0-only OR BSD-2-Clause) for new bindings please.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices LTC2983 Multi-sensor Temperature system
> +
> +maintainers:
> + - Nuno Sá <nuno.sa@analog.com>
> +
> +description: |
> + Analog Devices LTC2983 Multi-Sensor Digital Temperature Measurement System
> + https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> +
> +properties:
> + compatible:
> + enum:
> + - adi,ltc2983
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + adi,temperature-celcius:
-celsius. However, that suffix is reserved for properties whose value
is in Celsius, so you'll have to come up with something else.
How does one decide how to set this? Seems like the driver should just
decide based on what it needs to present to the user.
> + description:
> + If this property is present, the temperature is reported in Celsius.
> + type: boolean
> +
> + adi,mux-delay-config-us:
> + description:
> + The LTC2983 performs 2 or 3 internal conversion cycles per temperature
> + result. Each conversion cycle is performed with different excitation and
> + input multiplexer configurations. Prior to each conversion, these
> + excitation circuits and input switch configurations are changed and an
> + internal 1ms delay ensures settling prior to the conversion cycle in most
> + cases. An extra delay can be configured using this property. The value is
> + rounded to nearest 100us.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - maximum: 255
Standard unit suffixes already have a type, so just:
maximum: 255
> +
> + adi,filter-notch-freq:
> + description:
> + Set's the default setting of the digital filter. The default is
> + simultaneous 50/60Hz rejection.
> + 0 - 50/60Hz rejection
> + 1 - 60Hz rejection
> + 2 - 50Hz rejection
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 0
> + - maximum: 2
Drop the '-' on the last entry (making the min/max a single schema).
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + ".*@([1-9]|1[0-9]|20)$":
'.*' can be dropped.
> + type: object
> +
> + properties:
> + reg:
> + description: |
> + The channel number. It can be connected to one of the 20 channels of
> + the device.
> + minimum: 1
> + maximum: 20
> +
> + required:
> + - reg
> +
> + patternProperties:
> + "^thermocouple@.*":
You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This needs
to be at the same level.
> + type: object
> + description: |
You can drop the '|' where you don't need any formatting.
> + Represents a thermocouple sensor which is connected to one of the device
> + channels.
> +
> + properties:
> + adi,sensor-type:
> + description: |
> + Identifies the type of thermocouple connected to the device.
> + 1 - Type J Thermocouple
> + 2 - Type K Thermocouple
> + 3 - Type E Thermocouple
> + 4 - Type N Thermocouple
> + 5 - Type R Thermocouple
> + 6 - Type S Thermocouple
> + 7 - Type T Thermocouple
> + 8 - Type B Thermocouple
> + 9 - Custom Thermocouple
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
You can move the type definition under ".*@([1-9]|1[0-9]|20)$" and
then just have the min/max here.
> + - minimum: 1
> + - maximum: 9
> +
> + adi,single-ended:
> + description: |
> + Boolean property which set's the thermocouple as single-ended.
> + type: boolean
> +
> + adi,sensor-oc-current-microamp:
> + description: |
> + This property set's the pulsed current value applied during
> + open-circuit detect.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [10, 100, 500, 1000]
> +
> + adi,cold-junction-handle:
> + description: |
> + Phandle which points to a sensor object responsible for measuring
> + the thermocouple cold junction temperature.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + adi,custom-sensor:
> + description: |
> + This is a table, where each entry should be a pair of
> + voltage(mv)-temperature(K). The entries must be given in nv and uK
> + so that, the original values must be multiplied by 1000000. For
We normally do things in microVolts. It seems strange to need 64-bits
of range for voltage and temperature.
> + more details look at table 69 and 70.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/int64-array
Fails on 'make dt_binding_check':
Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml:
Unresolvable JSON pointer: 'definitions/int64-array'
If this is pairs of values, it should really be defined as a matrix:
minItems: 3
maxItems: 64
items:
minItems: 2
maxItems: 2
Though I'll need to add uint64-matrix as a type (assuming this really
needs to be 64-bit).
> + minItems: 6
> + maxItems: 128
> +
> + required:
> + - adi,sensor-type
> +
> + "^diode@.*":
> + type: object
> + description: |
> + Represents a diode sensor which is connected to one of the device
> + channels.
> +
> + properties:
> + adi,sensor-type:
> + description: Identifies the sensor as a diode.
> + const: 28
> +
> + adi,single-ended:
> + description: Boolean property which set's the diode as single-ended.
> + type: boolean
> +
> + adi,three-conversion-cycles:
> + description: |
> + Boolean property which set's three conversion cycles removing
> + parasitic resistance effects between the LTC2983 and the diode.
> + type: boolean
> +
> + adi,average-on:
> + description: |
> + Boolean property which enables a running average of the diode
> + temperature reading. This reduces the noise when the diode is used
> + as a cold junction temperature element on an isothermal block
> + where temperatures change slowly.
> + type: boolean
> +
> + adi,excitation-current-microamp:
> + description: |
> + This property controls the magnitude of the excitation current
> + applied to the diode. Depending on the number of conversions
> + cycles, this property will assume different predefined values on
> + each cycle. Just set the value of the first cycle (1l).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [10, 20, 40, 80]
> +
> + adi,ideal-factor-value:
> + description: |
> + This property sets the diode ideality factor. The real value must
> + be multiplied by 1000000 to remove the fractional part. For more
> + information look at table 20 of the datasheet.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> +
> + required:
> + - adi,sensor-type
> +
> + "^rtd@.*":
> + type: object
> + description: |
> + Represents a rtd sensor which is connected to one of the device channels.
> +
> + properties:
> + reg:
> + minimum: 2
> +
> + adi,sensor-type:
> + description: |
> + Identifies the type of RTD connected to the device.
> + 10 - RTD PT-10
> + 11 - RTD PT-50
> + 12 - RTD PT-100
> + 13 - RTD PT-200
> + 14 - RTD PT-500
> + 15 - RTD PT-1000
> + 16 - RTD PT-1000 (0.00375)
> + 17 - RTD NI-120
> + 18 - RTD Custom
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 10
> + - maximum: 18
> +
> + adi,rsense-handle:
> + description: |
> + Phandle pointing to a rsense object associated with this RTD.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + adi,number-of-wires:
> + description: |
> + Identifies the number of wires used by the RTD. Setting this
> + property to 5 means 4 wires with Kelvin Rsense.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [2, 3, 4, 5]
> +
> + adi,rsense-share:
> + description: |
> + Boolean property which enables Rsense sharing, where one sense
> + resistor is used for multiple 2-, 3-, and/or 4-wire RTDs.
> + type: boolean
> +
> + adi,current-rotate:
> + description: |
> + Boolean property which enables excitation current rotation to
> + automatically remove parasitic thermocouple effects. Note that
> + this property is not allowed for 2- and 3-wire RTDs.
> + type: boolean
> +
> + adi,excitation-current-microamp:
> + description: |
> + This property controls the magnitude of the excitation current
> + applied to the RTD.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
You can drop the type here too.
> + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> +
> + adi,rtd-curve:
> + description: |
> + This property set the RTD curve used and the corresponding
> + Callendar-VanDusen constants. Look at table 30 of the datasheet.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 0
> + - maximum: 3
> +
> + adi,custom-sensor:
> + description: |
> + This is a table, where each entry should be a pair of
> + resistance(ohm)-temperature(K). The entries added here are in uohm
> + and uK. For more details values look at table 74 and 75.
It's not great to make one property name have different meanings.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint64-array
> + minItems: 6
> + maxItems: 128
> +
> + required:
> + - adi,sensor-type
> + - adi,rsense-handle
> +
> + dependencies:
> + adi,current-rotate: [ adi,rsense-share ]
> +
> + "^thermistor@.*":
> + type: object
> + description: |
> + Represents a thermistor sensor which is connected to one of the device
> + channels.
> +
> + properties:
> + adi,sensor-type:
> + description: |
> + Identifies the type of thermistor connected to the
> + device.
> + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> + 20 - Thermistor 44005/44030 3kohm at 25°C
> + 21 - Thermistor 44007/44034 5kohm at 25°C
> + 22 - Thermistor 44006/44031 10kohm at 25°C
> + 23 - Thermistor 44008/44032 30kohm at 25°C
> + 24 - Thermistor YSI 400 2.252kohm at 25°C
> + 25 - Thermistor Spectrum 1003k 1kohm
> + 26 - Thermistor Custom Steinhart-Hart
> + 27 - Custom Thermistor
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 19
> + - maximum: 27
> +
> + adi,rsense-handle:
> + description: |
> + Phandle pointing to a rsense object associated with this
> + thermistor.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + adi,single-ended:
> + description: |
> + Boolean property which set's the thermistor as single-ended.
> + type: boolean
> +
> + adi,rsense-share:
> + description: |
> + Boolean property which enables Rsense sharing, where one sense
> + resistor is used for multiple thermistors. Note that this property
> + is ignored if adi,single-ended is set.
> + type: boolean
> +
> + adi,current-rotate:
> + description: |
> + Boolean property which enables excitation current rotation to
> + automatically remove parasitic thermocouple effects.
> + type: boolean
> +
> + adi,excitation-current-nanoamp:
> + description: |
> + This property controls the magnitude of the excitation current
> + applied to the thermistor. Value 0 set's the sensor in auto-range
> + mode.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [0, 250, 500, 1000, 5000, 10000, 25000, 50000, 100000,
> + 250000, 500000, 1000000]
> +
> + adi,custom-sensor:
> + description: |
> + This is a table, where each entry should be a pair of
> + resistance(ohm)-temperature(K). The entries added here are in uohm
> + and uK only for custom thermistors. For more details look at table
> + 78 and 79. Steinhart-Hart coefficients are also supported and can
> + be programmed into the device memory using this property. For
> + Steinhart sensors, this table has a constant size of 6 entries
> + (defining the coefficients) and the values are given in the raw
> + format. Look at table 82 for more information.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint64-array
> + minItems: 6
> + maxItems: 128
> +
> + required:
> + - adi,sensor-type
> + - adi,rsense-handle
> +
> + dependencies:
> + adi,current-rotate: [ adi,rsense-share ]
> +
> + "^adc@.*":
> + type: object
> + description: Represents a channel which is being used as a direct adc.
> +
> + properties:
> + adi,sensor-type:
> + description: Identifies the sensor as a direct adc.
> + const: 30
> +
> + adi,single-ended:
> + description: Boolean property which set's the adc as single-ended.
> + type: boolean
> +
> + required:
> + - adi,sensor-type
> +
> + "^rsense@.*":
> + type: object
> + description: |
> + Represents a rsense which is connected to one of the device channels.
> + Rsense are used by thermistors and RTD's.
> +
> + properties:
> + reg:
> + minimum: 2
> +
> + adi,sensor-type:
> + description: Identifies the sensor as a rsense.
> + const: 29
> +
> + adi,rsense-val-micro-ohms:
> + description: |
> + Sets the value of the sense resistor. Look at table 20 of the
> + datasheet for information.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint64
-micro-ohms is already defined to be 32-bit.
> +
> + required:
> + - adi,sensor-type
> + - adi, rsense-val
spurious space.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sensor_ltc2983: ltc2983@0 {
> + compatible = "adi,ltc2983";
> + reg = <0>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adi,temperature-celcius;
> + interrupts = <20 IRQ_TYPE_EDGE_RISING>;
> + interrupt-parent = <&gpio>;
> +
> + thermocouple@18 {
> + reg = <18>;
> + adi,sensor-type = <8>; //Type B
> + adi,sensor-oc-current-microamp = <10>;
> + adi,cold-junction-handle = <&diode5>;
> + };
> +
> + diode5: diode@5 {
> + reg = <5>;
> + adi,sensor-type = <28>;
> + };
> +
> + rsense2: rsense@2 {
> + reg = <2>;
> + adi,sensor-type = <29>;
> + adi,rsense-val-micro-ohms = /bits/ 64 <1200000000>; //1.2Kohms
> + };
> +
> + rtd@14 {
> + reg = <14>;
> + adi,sensor-type = <15>; //PT1000
> + /*2-wire, internal gnd, no current rotation*/
> + adi,number-of-wires = <2>;
> + adi,rsense-share;
> + adi,excitation-current-microamp = <500>;
> + adi,rsense-handle = <&rsense2>;
> + };
> +
> + adc@10 {
> + reg = <10>;
> + adi,sensor-type = <30>;
> + adi,single-ended;
> + };
> +
> + thermistor@12 {
> + reg = <12>;
> + adi,sensor-type = <26>; //Steinhart
> + adi,rsense-handle = <&rsense2>;
> + adi,custom-sensor = /bits/ 64 <0x00F371EC 0x12345678
> + 0x2C0F8733 0x10018C66 0xA0FEACCD
> + 0x90021D99>; //6 entries
> + };
> +
> + thermocouple@20 {
> + reg = <20>;
> + adi,sensor-type = <9>; //custom thermocouple
> + adi,single-ended;
> + adi,custom-sensor = /bits/ 64
> + <(-50220000) 0
> + (-30200000) 99100000
> + (-5300000) 135400000
> + 0 273150000
> + 40200000 361200000
> + 55300000 522100000
> + 88300000 720300000
> + 132200000 811200000
> + 188700000 922500000
> + 460400000 1000000000>; //10 pairs
> + };
> +
> + };
> + };
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 14a256e785ca..f747a9dc27f5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9497,6 +9497,7 @@ W: http://ez.analog.com/community/linux-device-drivers
> L: linux-iio@vger.kernel.org
> S: Supported
> F: drivers/iio/temperature/ltc2983.c
> +F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
>
> LTC4261 HARDWARE MONITOR DRIVER
> M: Guenter Roeck <linux@roeck-us.net>
> --
> 2.23.0
>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-07 14:45 ` Rob Herring
@ 2019-10-07 16:17 ` Sa, Nuno
2019-10-07 17:46 ` Rob Herring
2019-10-12 10:41 ` Jonathan Cameron
0 siblings, 2 replies; 15+ messages in thread
From: Sa, Nuno @ 2019-10-07 16:17 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, jic23, devicetree, knaack.h, linux-iio, pmeerw, lars
On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com> wrote:
> > Document the LTC2983 temperature sensor devicetree bindings.
> >
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > ---
> > Changes in v2:
> > * Drop maxItems in non-array elements;
> > * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> > * Wrapped lines at 80 char;
> > * Added comas to enum elements;
> > * Use real units in adi,excitation-current;
> > * Moved some enums to minimum and maximum;
> > * Grouped patternProperties and moved reg property as a generic
> > property.
> >
> > Changes in v3:
> > * Add meaning to adi,sensor-type values which are not const;
> > * Add meaning to adi,filter-notch-freq values;
> > * Break up adi,sensor-config into human readable elements;
> > * Set maxItems/minItems at the same identation as allOf in
> > adi,custom-sensor;
> > * Fixed the maximum value for adi,sensor-type for sensors with
> > custom support;
> > * Changed license to GPL-2.0-only as it should be for new
> > bindings;
> > * Changed spi0 to spi in the dts example;
> > * Updated the dts example to the new properties.
> >
> > .../bindings/iio/temperature/adi,ltc2983.yaml | 479
> > ++++++++++++++++++
> > MAINTAINERS | 1 +
> > 2 files changed, 480 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > l
> > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > l
> > new file mode 100644
> > index 000000000000..b7101a0e84db
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > l
> > @@ -0,0 +1,479 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
>
> (GPL-2.0-only OR BSD-2-Clause) for new bindings please.
ack.
> > +%YAML 1.2
> > +---
> > +$id:
> > http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices LTC2983 Multi-sensor Temperature system
> > +
> > +maintainers:
> > + - Nuno Sá <nuno.sa@analog.com>
> > +
> > +description: |
> > + Analog Devices LTC2983 Multi-Sensor Digital Temperature
> > Measurement System
> > +
> > https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - adi,ltc2983
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + adi,temperature-celcius:
>
> -celsius. However, that suffix is reserved for properties whose value
> is in Celsius, so you'll have to come up with something else.
>
> How does one decide how to set this? Seems like the driver should
> just
> decide based on what it needs to present to the user.
The device can report temperature in Celsius or Fahrenheit and that
should be decided once. Hmm but now that I think about this, the iio
standard attributes expect the value to be reported in milli degrees
Celsius so I guess I should just drop this and don't report in
Fahrenheit. Would this be ok Jonathan?
> > + description:
> > + If this property is present, the temperature is reported in
> > Celsius.
> > + type: boolean
> > +
> > + adi,mux-delay-config-us:
> > + description:
> > + The LTC2983 performs 2 or 3 internal conversion cycles per
> > temperature
> > + result. Each conversion cycle is performed with different
> > excitation and
> > + input multiplexer configurations. Prior to each conversion,
> > these
> > + excitation circuits and input switch configurations are
> > changed and an
> > + internal 1ms delay ensures settling prior to the conversion
> > cycle in most
> > + cases. An extra delay can be configured using this property.
> > The value is
> > + rounded to nearest 100us.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - maximum: 255
>
> Standard unit suffixes already have a type, so just:
>
> maximum: 255
got it.
> > +
> > + adi,filter-notch-freq:
> > + description:
> > + Set's the default setting of the digital filter. The default
> > is
> > + simultaneous 50/60Hz rejection.
> > + 0 - 50/60Hz rejection
> > + 1 - 60Hz rejection
> > + 2 - 50Hz rejection
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - minimum: 0
> > + - maximum: 2
>
> Drop the '-' on the last entry (making the min/max a single schema).
got it.
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > +patternProperties:
> > + ".*@([1-9]|1[0-9]|20)$":
>
> '.*' can be dropped.
>
> > + type: object
> > +
> > + properties:
> > + reg:
> > + description: |
> > + The channel number. It can be connected to one of the 20
> > channels of
> > + the device.
> > + minimum: 1
> > + maximum: 20
> > +
> > + required:
> > + - reg
> > +
> > + patternProperties:
> > + "^thermocouple@.*":
>
> You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This needs
> to be at the same level.
You mean dropping "patternProperties" and having "^thermocouple@.*": on
the same indent as ".*@([1-9]|1[0-9]|20)$":? It seems to be only one
working. I understood and tried something like:
patternProperties:
"@([1-9]|1[0-9]|20)$":
(...)
patternProperties:
"^thermocouple@.*"
description: "..."
type: object
properties:
(...)
But this throws "'^thermocouple@' is not one of ['$ref',
'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const',
'contains', 'default', 'dependencies', 'deprecated', 'description',
'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems',
'maximum', 'not', 'oneOf', 'pattern', 'patternProperties',
'properties', 'required', 'then', 'type', 'typeSize']"
Also, should I also drop the ".*" in "^thermocouple@.*"?
> > + type: object
> > + description: |
>
> You can drop the '|' where you don't need any formatting.
got it.
> > + Represents a thermocouple sensor which is connected to
> > one of the device
> > + channels.
> > +
> > + properties:
> > + adi,sensor-type:
> > + description: |
> > + Identifies the type of thermocouple connected to the
> > device.
> > + 1 - Type J Thermocouple
> > + 2 - Type K Thermocouple
> > + 3 - Type E Thermocouple
> > + 4 - Type N Thermocouple
> > + 5 - Type R Thermocouple
> > + 6 - Type S Thermocouple
> > + 7 - Type T Thermocouple
> > + 8 - Type B Thermocouple
> > + 9 - Custom Thermocouple
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
>
> You can move the type definition under ".*@([1-9]|1[0-9]|20)$" and
> then just have the min/max here.
And how could I add meaning to the values. Could I add all in the
"parent" node?
> > + - minimum: 1
> > + - maximum: 9
> > +
> > + adi,single-ended:
> > + description: |
> > + Boolean property which set's the thermocouple as
> > single-ended.
> > + type: boolean
> > +
> > + adi,sensor-oc-current-microamp:
> > + description: |
> > + This property set's the pulsed current value applied
> > during
> > + open-circuit detect.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - enum: [10, 100, 500, 1000]
> > +
> > + adi,cold-junction-handle:
> > + description: |
> > + Phandle which points to a sensor object responsible
> > for measuring
> > + the thermocouple cold junction temperature.
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + adi,custom-sensor:
> > + description: |
> > + This is a table, where each entry should be a pair
> > of
> > + voltage(mv)-temperature(K). The entries must be
> > given in nv and uK
> > + so that, the original values must be multiplied by
> > 1000000. For
>
> We normally do things in microVolts. It seems strange to need 64-bits
> of range for voltage and temperature.
This device support very high resolutions (so we have fractional
values). That is why I'm multiplying by 1000000 and using nV. And even
so, I already loose some bits. The 64bits are needed mainly because of
the Temperature and again the resolution I want to maximize. Doing
int(max(temp)) * 1000000, we need 64bits.
>
> > + more details look at table 69 and 70.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/int64-array
>
> Fails on 'make dt_binding_check':
>
> Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml:
> Unresolvable JSON pointer: 'definitions/int64-array'
I was aware of this but I do not know how to proceed so I was waiting
for your comment. I do have negative values, so uint does not apply.
What can I use here?
> If this is pairs of values, it should really be defined as a matrix:
>
> minItems: 3
> maxItems: 64
> items:
> minItems: 2
> maxItems: 2
>
> Though I'll need to add uint64-matrix as a type (assuming this really
> needs to be 64-bit).
I reinforce that I do need signed values here.
>
> > + minItems: 6
> > + maxItems: 128
> > +
> > + required:
> > + - adi,sensor-type
> > +
> > + "^diode@.*":
> > + type: object
> > + description: |
> > + Represents a diode sensor which is connected to one of
> > the device
> > + channels.
> > +
> > + properties:
> > + adi,sensor-type:
> > + description: Identifies the sensor as a diode.
> > + const: 28
> > +
> > + adi,single-ended:
> > + description: Boolean property which set's the diode as
> > single-ended.
> > + type: boolean
> > +
> > + adi,three-conversion-cycles:
> > + description: |
> > + Boolean property which set's three conversion cycles
> > removing
> > + parasitic resistance effects between the LTC2983 and
> > the diode.
> > + type: boolean
> > +
> > + adi,average-on:
> > + description: |
> > + Boolean property which enables a running average of
> > the diode
> > + temperature reading. This reduces the noise when the
> > diode is used
> > + as a cold junction temperature element on an
> > isothermal block
> > + where temperatures change slowly.
> > + type: boolean
> > +
> > + adi,excitation-current-microamp:
> > + description: |
> > + This property controls the magnitude of the
> > excitation current
> > + applied to the diode. Depending on the number of
> > conversions
> > + cycles, this property will assume different
> > predefined values on
> > + each cycle. Just set the value of the first cycle
> > (1l).
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - enum: [10, 20, 40, 80]
> > +
> > + adi,ideal-factor-value:
> > + description: |
> > + This property sets the diode ideality factor. The
> > real value must
> > + be multiplied by 1000000 to remove the fractional
> > part. For more
> > + information look at table 20 of the datasheet.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > + required:
> > + - adi,sensor-type
> > +
> > + "^rtd@.*":
> > + type: object
> > + description: |
> > + Represents a rtd sensor which is connected to one of the
> > device channels.
> > +
> > + properties:
> > + reg:
> > + minimum: 2
> > +
> > + adi,sensor-type:
> > + description: |
> > + Identifies the type of RTD connected to the device.
> > + 10 - RTD PT-10
> > + 11 - RTD PT-50
> > + 12 - RTD PT-100
> > + 13 - RTD PT-200
> > + 14 - RTD PT-500
> > + 15 - RTD PT-1000
> > + 16 - RTD PT-1000 (0.00375)
> > + 17 - RTD NI-120
> > + 18 - RTD Custom
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - minimum: 10
> > + - maximum: 18
> > +
> > + adi,rsense-handle:
> > + description: |
> > + Phandle pointing to a rsense object associated with
> > this RTD.
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + adi,number-of-wires:
> > + description: |
> > + Identifies the number of wires used by the RTD.
> > Setting this
> > + property to 5 means 4 wires with Kelvin Rsense.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - enum: [2, 3, 4, 5]
> > +
> > + adi,rsense-share:
> > + description: |
> > + Boolean property which enables Rsense sharing, where
> > one sense
> > + resistor is used for multiple 2-, 3-, and/or 4-wire
> > RTDs.
> > + type: boolean
> > +
> > + adi,current-rotate:
> > + description: |
> > + Boolean property which enables excitation current
> > rotation to
> > + automatically remove parasitic thermocouple effects.
> > Note that
> > + this property is not allowed for 2- and 3-wire RTDs.
> > + type: boolean
> > +
> > + adi,excitation-current-microamp:
> > + description: |
> > + This property controls the magnitude of the
> > excitation current
> > + applied to the RTD.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
>
> You can drop the type here too.
got it.
> > + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> > +
> > + adi,rtd-curve:
> > + description: |
> > + This property set the RTD curve used and the
> > corresponding
> > + Callendar-VanDusen constants. Look at table 30 of
> > the datasheet.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - minimum: 0
> > + - maximum: 3
> > +
> > + adi,custom-sensor:
> > + description: |
> > + This is a table, where each entry should be a pair
> > of
> > + resistance(ohm)-temperature(K). The entries added
> > here are in uohm
> > + and uK. For more details values look at table 74 and
> > 75.
>
> It's not great to make one property name have different meanings.
Would you prefer to have something like "custom-rtd", "custom-
thermoucouple" and so on? I would have to adapt the code but I don't
think it would need to much of a change.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > array
> > + minItems: 6
> > + maxItems: 128
> > +
> > + required:
> > + - adi,sensor-type
> > + - adi,rsense-handle
> > +
> > + dependencies:
> > + adi,current-rotate: [ adi,rsense-share ]
> > +
> > + "^thermistor@.*":
> > + type: object
> > + description: |
> > + Represents a thermistor sensor which is connected to one
> > of the device
> > + channels.
> > +
> > + properties:
> > + adi,sensor-type:
> > + description: |
> > + Identifies the type of thermistor connected to the
> > + device.
> > + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> > + 20 - Thermistor 44005/44030 3kohm at 25°C
> > + 21 - Thermistor 44007/44034 5kohm at 25°C
> > + 22 - Thermistor 44006/44031 10kohm at 25°C
> > + 23 - Thermistor 44008/44032 30kohm at 25°C
> > + 24 - Thermistor YSI 400 2.252kohm at 25°C
> > + 25 - Thermistor Spectrum 1003k 1kohm
> > + 26 - Thermistor Custom Steinhart-Hart
> > + 27 - Custom Thermistor
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - minimum: 19
> > + - maximum: 27
> > +
> > + adi,rsense-handle:
> > + description: |
> > + Phandle pointing to a rsense object associated with
> > this
> > + thermistor.
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + adi,single-ended:
> > + description: |
> > + Boolean property which set's the thermistor as
> > single-ended.
> > + type: boolean
> > +
> > + adi,rsense-share:
> > + description: |
> > + Boolean property which enables Rsense sharing, where
> > one sense
> > + resistor is used for multiple thermistors. Note that
> > this property
> > + is ignored if adi,single-ended is set.
> > + type: boolean
> > +
> > + adi,current-rotate:
> > + description: |
> > + Boolean property which enables excitation current
> > rotation to
> > + automatically remove parasitic thermocouple effects.
> > + type: boolean
> > +
> > + adi,excitation-current-nanoamp:
> > + description: |
> > + This property controls the magnitude of the
> > excitation current
> > + applied to the thermistor. Value 0 set's the sensor
> > in auto-range
> > + mode.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - enum: [0, 250, 500, 1000, 5000, 10000, 25000,
> > 50000, 100000,
> > + 250000, 500000, 1000000]
> > +
> > + adi,custom-sensor:
> > + description: |
> > + This is a table, where each entry should be a pair
> > of
> > + resistance(ohm)-temperature(K). The entries added
> > here are in uohm
> > + and uK only for custom thermistors. For more details
> > look at table
> > + 78 and 79. Steinhart-Hart coefficients are also
> > supported and can
> > + be programmed into the device memory using this
> > property. For
> > + Steinhart sensors, this table has a constant size of
> > 6 entries
> > + (defining the coefficients) and the values are given
> > in the raw
> > + format. Look at table 82 for more information.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > array
> > + minItems: 6
> > + maxItems: 128
> > +
If I'm to replace this property as proposed before, would it make sense
also to split this in custom-thermistor and custom-steinhart or just
steinhart?
> > + required:
> > + - adi,sensor-type
> > + - adi,rsense-handle
> > +
> > + dependencies:
> > + adi,current-rotate: [ adi,rsense-share ]
> > +
> > + "^adc@.*":
> > + type: object
> > + description: Represents a channel which is being used as a
> > direct adc.
> > +
> > + properties:
> > + adi,sensor-type:
> > + description: Identifies the sensor as a direct adc.
> > + const: 30
> > +
> > + adi,single-ended:
> > + description: Boolean property which set's the adc as
> > single-ended.
> > + type: boolean
> > +
> > + required:
> > + - adi,sensor-type
> > +
> > + "^rsense@.*":
> > + type: object
> > + description: |
> > + Represents a rsense which is connected to one of the
> > device channels.
> > + Rsense are used by thermistors and RTD's.
> > +
> > + properties:
> > + reg:
> > + minimum: 2
> > +
> > + adi,sensor-type:
> > + description: Identifies the sensor as a rsense.
> > + const: 29
> > +
> > + adi,rsense-val-micro-ohms:
> > + description: |
> > + Sets the value of the sense resistor. Look at table
> > 20 of the
> > + datasheet for information.
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint64
>
> -micro-ohms is already defined to be 32-bit.
I do need a 64-bit variable here. Should I still remove the $ref or how
can I proceed?
> > +
> > + required:
> > + - adi,sensor-type
> > + - adi, rsense-val
>
> spurious space.
got it.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + spi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sensor_ltc2983: ltc2983@0 {
> > + compatible = "adi,ltc2983";
> > + reg = <0>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + adi,temperature-celcius;
> > + interrupts = <20 IRQ_TYPE_EDGE_RISING>;
> > + interrupt-parent = <&gpio>;
> > +
> > + thermocouple@18 {
> > + reg = <18>;
> > + adi,sensor-type = <8>; //Type B
> > + adi,sensor-oc-current-microamp = <10>;
> > + adi,cold-junction-handle = <&diode5>;
> > + };
> > +
> > + diode5: diode@5 {
> > + reg = <5>;
> > + adi,sensor-type = <28>;
> > + };
> > +
> > + rsense2: rsense@2 {
> > + reg = <2>;
> > + adi,sensor-type = <29>;
> > + adi,rsense-val-micro-ohms = /bits/ 64
> > <1200000000>; //1.2Kohms
> > + };
> > +
> > + rtd@14 {
> > + reg = <14>;
> > + adi,sensor-type = <15>; //PT1000
> > + /*2-wire, internal gnd, no current
> > rotation*/
> > + adi,number-of-wires = <2>;
> > + adi,rsense-share;
> > + adi,excitation-current-microamp = <500>;
> > + adi,rsense-handle = <&rsense2>;
> > + };
> > +
> > + adc@10 {
> > + reg = <10>;
> > + adi,sensor-type = <30>;
> > + adi,single-ended;
> > + };
> > +
> > + thermistor@12 {
> > + reg = <12>;
> > + adi,sensor-type = <26>; //Steinhart
> > + adi,rsense-handle = <&rsense2>;
> > + adi,custom-sensor = /bits/ 64 <0x00F371EC
> > 0x12345678
> > + 0x2C0F8733 0x10018C66
> > 0xA0FEACCD
> > + 0x90021D99>; //6 entries
> > + };
> > +
> > + thermocouple@20 {
> > + reg = <20>;
> > + adi,sensor-type = <9>; //custom
> > thermocouple
> > + adi,single-ended;
> > + adi,custom-sensor = /bits/ 64
> > + <(-50220000) 0
> > + (-30200000) 99100000
> > + (-5300000) 135400000
> > + 0 273150000
> > + 40200000 361200000
> > + 55300000 522100000
> > + 88300000 720300000
> > + 132200000 811200000
> > + 188700000 922500000
> > + 460400000 1000000000>; //10
> > pairs
> > + };
> > +
> > + };
> > + };
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 14a256e785ca..f747a9dc27f5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9497,6 +9497,7 @@ W:
> > http://ez.analog.com/community/linux-device-drivers
> > L: linux-iio@vger.kernel.org
> > S: Supported
> > F: drivers/iio/temperature/ltc2983.c
> > +F: Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > 83.yaml
> >
> > LTC4261 HARDWARE MONITOR DRIVER
> > M: Guenter Roeck <linux@roeck-us.net>
> > --
> > 2.23.0
> >
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-07 16:17 ` Sa, Nuno
@ 2019-10-07 17:46 ` Rob Herring
2019-10-08 7:45 ` Sa, Nuno
2019-10-12 10:41 ` Jonathan Cameron
1 sibling, 1 reply; 15+ messages in thread
From: Rob Herring @ 2019-10-07 17:46 UTC (permalink / raw)
To: Sa, Nuno
Cc: mark.rutland, jic23, devicetree, knaack.h, linux-iio, pmeerw, lars
On Mon, Oct 7, 2019 at 11:17 AM Sa, Nuno <Nuno.Sa@analog.com> wrote:
>
> On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> > On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com> wrote:
> > > Document the LTC2983 temperature sensor devicetree bindings.
> > >
> > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > ---
> > > Changes in v2:
> > > * Drop maxItems in non-array elements;
> > > * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> > > * Wrapped lines at 80 char;
> > > * Added comas to enum elements;
> > > * Use real units in adi,excitation-current;
> > > * Moved some enums to minimum and maximum;
> > > * Grouped patternProperties and moved reg property as a generic
> > > property.
> > >
> > > Changes in v3:
> > > * Add meaning to adi,sensor-type values which are not const;
> > > * Add meaning to adi,filter-notch-freq values;
> > > * Break up adi,sensor-config into human readable elements;
> > > * Set maxItems/minItems at the same identation as allOf in
> > > adi,custom-sensor;
> > > * Fixed the maximum value for adi,sensor-type for sensors with
> > > custom support;
> > > * Changed license to GPL-2.0-only as it should be for new
> > > bindings;
> > > * Changed spi0 to spi in the dts example;
> > > * Updated the dts example to the new properties.
> > >
> > > .../bindings/iio/temperature/adi,ltc2983.yaml | 479
> > > ++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 2 files changed, 480 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l
> > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l
> > > new file mode 100644
> > > index 000000000000..b7101a0e84db
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l
> > > @@ -0,0 +1,479 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only
> >
> > (GPL-2.0-only OR BSD-2-Clause) for new bindings please.
>
> ack.
>
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Analog Devices LTC2983 Multi-sensor Temperature system
> > > +
> > > +maintainers:
> > > + - Nuno Sá <nuno.sa@analog.com>
> > > +
> > > +description: |
> > > + Analog Devices LTC2983 Multi-Sensor Digital Temperature
> > > Measurement System
> > > +
> > > https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - adi,ltc2983
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + adi,temperature-celcius:
> >
> > -celsius. However, that suffix is reserved for properties whose value
> > is in Celsius, so you'll have to come up with something else.
> >
> > How does one decide how to set this? Seems like the driver should
> > just
> > decide based on what it needs to present to the user.
>
> The device can report temperature in Celsius or Fahrenheit and that
> should be decided once. Hmm but now that I think about this, the iio
> standard attributes expect the value to be reported in milli degrees
> Celsius so I guess I should just drop this and don't report in
> Fahrenheit. Would this be ok Jonathan?
>
> > > + description:
> > > + If this property is present, the temperature is reported in
> > > Celsius.
> > > + type: boolean
> > > +
> > > + adi,mux-delay-config-us:
> > > + description:
> > > + The LTC2983 performs 2 or 3 internal conversion cycles per
> > > temperature
> > > + result. Each conversion cycle is performed with different
> > > excitation and
> > > + input multiplexer configurations. Prior to each conversion,
> > > these
> > > + excitation circuits and input switch configurations are
> > > changed and an
> > > + internal 1ms delay ensures settling prior to the conversion
> > > cycle in most
> > > + cases. An extra delay can be configured using this property.
> > > The value is
> > > + rounded to nearest 100us.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - maximum: 255
> >
> > Standard unit suffixes already have a type, so just:
> >
> > maximum: 255
>
> got it.
>
> > > +
> > > + adi,filter-notch-freq:
> > > + description:
> > > + Set's the default setting of the digital filter. The default
> > > is
> > > + simultaneous 50/60Hz rejection.
> > > + 0 - 50/60Hz rejection
> > > + 1 - 60Hz rejection
> > > + 2 - 50Hz rejection
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 0
> > > + - maximum: 2
> >
> > Drop the '-' on the last entry (making the min/max a single schema).
>
> got it.
>
> > > +
> > > + '#address-cells':
> > > + const: 1
> > > +
> > > + '#size-cells':
> > > + const: 0
> > > +
> > > +patternProperties:
> > > + ".*@([1-9]|1[0-9]|20)$":
> >
> > '.*' can be dropped.
> >
> > > + type: object
> > > +
> > > + properties:
> > > + reg:
> > > + description: |
> > > + The channel number. It can be connected to one of the 20
> > > channels of
> > > + the device.
> > > + minimum: 1
> > > + maximum: 20
> > > +
> > > + required:
> > > + - reg
> > > +
> > > + patternProperties:
> > > + "^thermocouple@.*":
> >
> > You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This needs
> > to be at the same level.
>
> You mean dropping "patternProperties" and having "^thermocouple@.*": on
> the same indent as ".*@([1-9]|1[0-9]|20)$":? It seems to be only one
Yes.
> working. I understood and tried something like:
>
> patternProperties:
> "@([1-9]|1[0-9]|20)$":
> (...)
>
> patternProperties:
What you are saying here is you have a patternProperty called 'patternProperty'.
> "^thermocouple@.*"
And then this is not a valid json-schema keyword for the property's schema.
> description: "..."
> type: object
> properties:
> (...)
>
> But this throws "'^thermocouple@' is not one of ['$ref',
> 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const',
> 'contains', 'default', 'dependencies', 'deprecated', 'description',
> 'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems',
> 'maximum', 'not', 'oneOf', 'pattern', 'patternProperties',
> 'properties', 'required', 'then', 'type', 'typeSize']"
>
> Also, should I also drop the ".*" in "^thermocouple@.*"?
Yes.
> > > + type: object
> > > + description: |
> >
> > You can drop the '|' where you don't need any formatting.
>
> got it.
>
> > > + Represents a thermocouple sensor which is connected to
> > > one of the device
> > > + channels.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: |
> > > + Identifies the type of thermocouple connected to the
> > > device.
> > > + 1 - Type J Thermocouple
> > > + 2 - Type K Thermocouple
> > > + 3 - Type E Thermocouple
> > > + 4 - Type N Thermocouple
> > > + 5 - Type R Thermocouple
> > > + 6 - Type S Thermocouple
> > > + 7 - Type T Thermocouple
> > > + 8 - Type B Thermocouple
> > > + 9 - Custom Thermocouple
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> >
> > You can move the type definition under ".*@([1-9]|1[0-9]|20)$" and
> > then just have the min/max here.
>
> And how could I add meaning to the values. Could I add all in the
> "parent" node?
No, they have to be at the correct level. You can keep the
descriptions here. Just do:
adi,sensor-type:
description: ...
$ref: /schemas/types.yaml#/definitions/uint32
under ".*@([1-9]|1[0-9]|20)$" and drop the 'allOf: [ $ref: ...]' part.
>
> > > + - minimum: 1
> > > + - maximum: 9
> > > +
> > > + adi,single-ended:
> > > + description: |
> > > + Boolean property which set's the thermocouple as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + adi,sensor-oc-current-microamp:
> > > + description: |
> > > + This property set's the pulsed current value applied
> > > during
> > > + open-circuit detect.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [10, 100, 500, 1000]
> > > +
> > > + adi,cold-junction-handle:
> > > + description: |
> > > + Phandle which points to a sensor object responsible
> > > for measuring
> > > + the thermocouple cold junction temperature.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + adi,custom-sensor:
> > > + description: |
> > > + This is a table, where each entry should be a pair
> > > of
> > > + voltage(mv)-temperature(K). The entries must be
> > > given in nv and uK
> > > + so that, the original values must be multiplied by
> > > 1000000. For
> >
> > We normally do things in microVolts. It seems strange to need 64-bits
> > of range for voltage and temperature.
>
> This device support very high resolutions (so we have fractional
> values). That is why I'm multiplying by 1000000 and using nV. And even
> so, I already loose some bits. The 64bits are needed mainly because of
> the Temperature and again the resolution I want to maximize. Doing
> int(max(temp)) * 1000000, we need 64bits.
>
> >
> > > + more details look at table 69 and 70.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/int64-array
> >
> > Fails on 'make dt_binding_check':
> >
> > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml:
> > Unresolvable JSON pointer: 'definitions/int64-array'
>
> I was aware of this but I do not know how to proceed so I was waiting
> for your comment. I do have negative values, so uint does not apply.
> What can I use here?
>
> > If this is pairs of values, it should really be defined as a matrix:
> >
> > minItems: 3
> > maxItems: 64
> > items:
> > minItems: 2
> > maxItems: 2
> >
> > Though I'll need to add uint64-matrix as a type (assuming this really
> > needs to be 64-bit).
>
> I reinforce that I do need signed values here.
I can add those as well. At least for now, they are going to end up
being the exact same definition because IIRC while dtc takes signed
input, that's lost by the time we emit the output.
>
> >
> > > + minItems: 6
> > > + maxItems: 128
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > +
> > > + "^diode@.*":
> > > + type: object
> > > + description: |
> > > + Represents a diode sensor which is connected to one of
> > > the device
> > > + channels.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: Identifies the sensor as a diode.
> > > + const: 28
> > > +
> > > + adi,single-ended:
> > > + description: Boolean property which set's the diode as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + adi,three-conversion-cycles:
> > > + description: |
> > > + Boolean property which set's three conversion cycles
> > > removing
> > > + parasitic resistance effects between the LTC2983 and
> > > the diode.
> > > + type: boolean
> > > +
> > > + adi,average-on:
> > > + description: |
> > > + Boolean property which enables a running average of
> > > the diode
> > > + temperature reading. This reduces the noise when the
> > > diode is used
> > > + as a cold junction temperature element on an
> > > isothermal block
> > > + where temperatures change slowly.
> > > + type: boolean
> > > +
> > > + adi,excitation-current-microamp:
> > > + description: |
> > > + This property controls the magnitude of the
> > > excitation current
> > > + applied to the diode. Depending on the number of
> > > conversions
> > > + cycles, this property will assume different
> > > predefined values on
> > > + each cycle. Just set the value of the first cycle
> > > (1l).
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [10, 20, 40, 80]
> > > +
> > > + adi,ideal-factor-value:
> > > + description: |
> > > + This property sets the diode ideality factor. The
> > > real value must
> > > + be multiplied by 1000000 to remove the fractional
> > > part. For more
> > > + information look at table 20 of the datasheet.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > +
> > > + "^rtd@.*":
> > > + type: object
> > > + description: |
> > > + Represents a rtd sensor which is connected to one of the
> > > device channels.
> > > +
> > > + properties:
> > > + reg:
> > > + minimum: 2
> > > +
> > > + adi,sensor-type:
> > > + description: |
> > > + Identifies the type of RTD connected to the device.
> > > + 10 - RTD PT-10
> > > + 11 - RTD PT-50
> > > + 12 - RTD PT-100
> > > + 13 - RTD PT-200
> > > + 14 - RTD PT-500
> > > + 15 - RTD PT-1000
> > > + 16 - RTD PT-1000 (0.00375)
> > > + 17 - RTD NI-120
> > > + 18 - RTD Custom
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 10
> > > + - maximum: 18
> > > +
> > > + adi,rsense-handle:
> > > + description: |
> > > + Phandle pointing to a rsense object associated with
> > > this RTD.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + adi,number-of-wires:
> > > + description: |
> > > + Identifies the number of wires used by the RTD.
> > > Setting this
> > > + property to 5 means 4 wires with Kelvin Rsense.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [2, 3, 4, 5]
> > > +
> > > + adi,rsense-share:
> > > + description: |
> > > + Boolean property which enables Rsense sharing, where
> > > one sense
> > > + resistor is used for multiple 2-, 3-, and/or 4-wire
> > > RTDs.
> > > + type: boolean
> > > +
> > > + adi,current-rotate:
> > > + description: |
> > > + Boolean property which enables excitation current
> > > rotation to
> > > + automatically remove parasitic thermocouple effects.
> > > Note that
> > > + this property is not allowed for 2- and 3-wire RTDs.
> > > + type: boolean
> > > +
> > > + adi,excitation-current-microamp:
> > > + description: |
> > > + This property controls the magnitude of the
> > > excitation current
> > > + applied to the RTD.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> >
> > You can drop the type here too.
>
> got it.
>
> > > + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> > > +
> > > + adi,rtd-curve:
> > > + description: |
> > > + This property set the RTD curve used and the
> > > corresponding
> > > + Callendar-VanDusen constants. Look at table 30 of
> > > the datasheet.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 0
> > > + - maximum: 3
> > > +
> > > + adi,custom-sensor:
> > > + description: |
> > > + This is a table, where each entry should be a pair
> > > of
> > > + resistance(ohm)-temperature(K). The entries added
> > > here are in uohm
> > > + and uK. For more details values look at table 74 and
> > > 75.
> >
> > It's not great to make one property name have different meanings.
>
> Would you prefer to have something like "custom-rtd", "custom-
> thermoucouple" and so on? I would have to adapt the code but I don't
> think it would need to much of a change.
I don't really know enough about this device to say... What does
'custom' mean here?
>
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > > array
> > > + minItems: 6
> > > + maxItems: 128
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > + - adi,rsense-handle
> > > +
> > > + dependencies:
> > > + adi,current-rotate: [ adi,rsense-share ]
> > > +
> > > + "^thermistor@.*":
> > > + type: object
> > > + description: |
> > > + Represents a thermistor sensor which is connected to one
> > > of the device
> > > + channels.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: |
> > > + Identifies the type of thermistor connected to the
> > > + device.
> > > + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> > > + 20 - Thermistor 44005/44030 3kohm at 25°C
> > > + 21 - Thermistor 44007/44034 5kohm at 25°C
> > > + 22 - Thermistor 44006/44031 10kohm at 25°C
> > > + 23 - Thermistor 44008/44032 30kohm at 25°C
> > > + 24 - Thermistor YSI 400 2.252kohm at 25°C
> > > + 25 - Thermistor Spectrum 1003k 1kohm
> > > + 26 - Thermistor Custom Steinhart-Hart
> > > + 27 - Custom Thermistor
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 19
> > > + - maximum: 27
> > > +
> > > + adi,rsense-handle:
> > > + description: |
> > > + Phandle pointing to a rsense object associated with
> > > this
> > > + thermistor.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + adi,single-ended:
> > > + description: |
> > > + Boolean property which set's the thermistor as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + adi,rsense-share:
> > > + description: |
> > > + Boolean property which enables Rsense sharing, where
> > > one sense
> > > + resistor is used for multiple thermistors. Note that
> > > this property
> > > + is ignored if adi,single-ended is set.
> > > + type: boolean
> > > +
> > > + adi,current-rotate:
> > > + description: |
> > > + Boolean property which enables excitation current
> > > rotation to
> > > + automatically remove parasitic thermocouple effects.
> > > + type: boolean
> > > +
> > > + adi,excitation-current-nanoamp:
> > > + description: |
> > > + This property controls the magnitude of the
> > > excitation current
> > > + applied to the thermistor. Value 0 set's the sensor
> > > in auto-range
> > > + mode.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [0, 250, 500, 1000, 5000, 10000, 25000,
> > > 50000, 100000,
> > > + 250000, 500000, 1000000]
> > > +
> > > + adi,custom-sensor:
> > > + description: |
> > > + This is a table, where each entry should be a pair
> > > of
> > > + resistance(ohm)-temperature(K). The entries added
> > > here are in uohm
> > > + and uK only for custom thermistors. For more details
> > > look at table
> > > + 78 and 79. Steinhart-Hart coefficients are also
> > > supported and can
> > > + be programmed into the device memory using this
> > > property. For
> > > + Steinhart sensors, this table has a constant size of
> > > 6 entries
> > > + (defining the coefficients) and the values are given
> > > in the raw
> > > + format. Look at table 82 for more information.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > > array
> > > + minItems: 6
> > > + maxItems: 128
> > > +
>
> If I'm to replace this property as proposed before, would it make sense
> also to split this in custom-thermistor and custom-steinhart or just
> steinhart?
Seems like it as the data is completely different.
>
> > > + required:
> > > + - adi,sensor-type
> > > + - adi,rsense-handle
> > > +
> > > + dependencies:
> > > + adi,current-rotate: [ adi,rsense-share ]
> > > +
> > > + "^adc@.*":
> > > + type: object
> > > + description: Represents a channel which is being used as a
> > > direct adc.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: Identifies the sensor as a direct adc.
> > > + const: 30
> > > +
> > > + adi,single-ended:
> > > + description: Boolean property which set's the adc as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > +
> > > + "^rsense@.*":
> > > + type: object
> > > + description: |
> > > + Represents a rsense which is connected to one of the
> > > device channels.
> > > + Rsense are used by thermistors and RTD's.
> > > +
> > > + properties:
> > > + reg:
> > > + minimum: 2
> > > +
> > > + adi,sensor-type:
> > > + description: Identifies the sensor as a rsense.
> > > + const: 29
> > > +
> > > + adi,rsense-val-micro-ohms:
> > > + description: |
> > > + Sets the value of the sense resistor. Look at table
> > > 20 of the
> > > + datasheet for information.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint64
> >
> > -micro-ohms is already defined to be 32-bit.
>
> I do need a 64-bit variable here. Should I still remove the $ref or how
> can I proceed?
We could add -milli-ohms. According to the datasheet, it's 0-131kohms
in 1/1024ohm steps.
Rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-07 17:46 ` Rob Herring
@ 2019-10-08 7:45 ` Sa, Nuno
2019-10-08 10:22 ` Sa, Nuno
0 siblings, 1 reply; 15+ messages in thread
From: Sa, Nuno @ 2019-10-08 7:45 UTC (permalink / raw)
To: robh+dt
Cc: pmeerw, jic23, devicetree, mark.rutland, knaack.h, linux-iio, lars
On Mon, 2019-10-07 at 12:46 -0500, Rob Herring wrote:
>
> On Mon, Oct 7, 2019 at 11:17 AM Sa, Nuno <Nuno.Sa@analog.com> wrote:
> > On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> > > On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com>
> > > wrote:
> > > > Document the LTC2983 temperature sensor devicetree bindings.
> > > >
> > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > > ---
> > > > Changes in v2:
> > > > * Drop maxItems in non-array elements;
> > > > * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> > > > * Wrapped lines at 80 char;
> > > > * Added comas to enum elements;
> > > > * Use real units in adi,excitation-current;
> > > > * Moved some enums to minimum and maximum;
> > > > * Grouped patternProperties and moved reg property as a
> > > > generic
> > > > property.
> > > >
> > > > Changes in v3:
> > > > * Add meaning to adi,sensor-type values which are not const;
> > > > * Add meaning to adi,filter-notch-freq values;
> > > > * Break up adi,sensor-config into human readable elements;
> > > > * Set maxItems/minItems at the same identation as allOf in
> > > > adi,custom-sensor;
> > > > * Fixed the maximum value for adi,sensor-type for sensors with
> > > > custom support;
> > > > * Changed license to GPL-2.0-only as it should be for new
> > > > bindings;
> > > > * Changed spi0 to spi in the dts example;
> > > > * Updated the dts example to the new properties.
> > > >
> > > > .../bindings/iio/temperature/adi,ltc2983.yaml | 479
> > > > ++++++++++++++++++
> > > > MAINTAINERS | 1 +
> > > > 2 files changed, 480 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.y
> > > > aml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983
> > > > .yam
> > > > l
> > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983
> > > > .yam
> > > > l
> > > > new file mode 100644
> > > > index 000000000000..b7101a0e84db
> > > > --- /dev/null
> > > > +++
> > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983
> > > > .yam
> > > > l
> > > > @@ -0,0 +1,479 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-only
> > >
> > > (GPL-2.0-only OR BSD-2-Clause) for new bindings please.
> >
> > ack.
> >
> > > > +%YAML 1.2
> > > > +---
> > > > +$id:
> > > > http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Analog Devices LTC2983 Multi-sensor Temperature system
> > > > +
> > > > +maintainers:
> > > > + - Nuno Sá <nuno.sa@analog.com>
> > > > +
> > > > +description: |
> > > > + Analog Devices LTC2983 Multi-Sensor Digital Temperature
> > > > Measurement System
> > > > +
> > > > https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - adi,ltc2983
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + interrupts:
> > > > + maxItems: 1
> > > > +
> > > > + adi,temperature-celcius:
> > >
> > > -celsius. However, that suffix is reserved for properties whose
> > > value
> > > is in Celsius, so you'll have to come up with something else.
> > >
> > > How does one decide how to set this? Seems like the driver should
> > > just
> > > decide based on what it needs to present to the user.
> >
> > The device can report temperature in Celsius or Fahrenheit and that
> > should be decided once. Hmm but now that I think about this, the
> > iio
> > standard attributes expect the value to be reported in milli
> > degrees
> > Celsius so I guess I should just drop this and don't report in
> > Fahrenheit. Would this be ok Jonathan?
> >
> > > > + description:
> > > > + If this property is present, the temperature is reported
> > > > in
> > > > Celsius.
> > > > + type: boolean
> > > > +
> > > > + adi,mux-delay-config-us:
> > > > + description:
> > > > + The LTC2983 performs 2 or 3 internal conversion cycles
> > > > per
> > > > temperature
> > > > + result. Each conversion cycle is performed with
> > > > different
> > > > excitation and
> > > > + input multiplexer configurations. Prior to each
> > > > conversion,
> > > > these
> > > > + excitation circuits and input switch configurations are
> > > > changed and an
> > > > + internal 1ms delay ensures settling prior to the
> > > > conversion
> > > > cycle in most
> > > > + cases. An extra delay can be configured using this
> > > > property.
> > > > The value is
> > > > + rounded to nearest 100us.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - maximum: 255
> > >
> > > Standard unit suffixes already have a type, so just:
> > >
> > > maximum: 255
> >
> > got it.
> >
> > > > +
> > > > + adi,filter-notch-freq:
> > > > + description:
> > > > + Set's the default setting of the digital filter. The
> > > > default
> > > > is
> > > > + simultaneous 50/60Hz rejection.
> > > > + 0 - 50/60Hz rejection
> > > > + 1 - 60Hz rejection
> > > > + 2 - 50Hz rejection
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - minimum: 0
> > > > + - maximum: 2
> > >
> > > Drop the '-' on the last entry (making the min/max a single
> > > schema).
> >
> > got it.
> >
> > > > +
> > > > + '#address-cells':
> > > > + const: 1
> > > > +
> > > > + '#size-cells':
> > > > + const: 0
> > > > +
> > > > +patternProperties:
> > > > + ".*@([1-9]|1[0-9]|20)$":
> > >
> > > '.*' can be dropped.
> > >
> > > > + type: object
> > > > +
> > > > + properties:
> > > > + reg:
> > > > + description: |
> > > > + The channel number. It can be connected to one of
> > > > the 20
> > > > channels of
> > > > + the device.
> > > > + minimum: 1
> > > > + maximum: 20
> > > > +
> > > > + required:
> > > > + - reg
> > > > +
> > > > + patternProperties:
> > > > + "^thermocouple@.*":
> > >
> > > You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This
> > > needs
> > > to be at the same level.
> >
> > You mean dropping "patternProperties" and having
> > "^thermocouple@.*": on
> > the same indent as ".*@([1-9]|1[0-9]|20)$":? It seems to be only
> > one
>
> Yes.
>
> > working. I understood and tried something like:
> >
> > patternProperties:
> > "@([1-9]|1[0-9]|20)$":
> > (...)
> >
> > patternProperties:
>
> What you are saying here is you have a patternProperty called
> 'patternProperty'.
>
> > "^thermocouple@.*"
>
> And then this is not a valid json-schema keyword for the property's
> schema.
>
> > description: "..."
> > type: object
> > properties:
> > (...)
> >
> > But this throws "'^thermocouple@' is not one of ['$ref',
> > 'additionalItems', 'additionalProperties', 'allOf', 'anyOf',
> > 'const',
> > 'contains', 'default', 'dependencies', 'deprecated', 'description',
> > 'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems',
> > 'maximum', 'not', 'oneOf', 'pattern', 'patternProperties',
> > 'properties', 'required', 'then', 'type', 'typeSize']"
> >
> > Also, should I also drop the ".*" in "^thermocouple@.*"?
>
> Yes.
>
> > > > + type: object
> > > > + description: |
> > >
> > > You can drop the '|' where you don't need any formatting.
> >
> > got it.
> >
> > > > + Represents a thermocouple sensor which is connected
> > > > to
> > > > one of the device
> > > > + channels.
> > > > +
> > > > + properties:
> > > > + adi,sensor-type:
> > > > + description: |
> > > > + Identifies the type of thermocouple connected to
> > > > the
> > > > device.
> > > > + 1 - Type J Thermocouple
> > > > + 2 - Type K Thermocouple
> > > > + 3 - Type E Thermocouple
> > > > + 4 - Type N Thermocouple
> > > > + 5 - Type R Thermocouple
> > > > + 6 - Type S Thermocouple
> > > > + 7 - Type T Thermocouple
> > > > + 8 - Type B Thermocouple
> > > > + 9 - Custom Thermocouple
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > You can move the type definition under ".*@([1-9]|1[0-9]|20)$"
> > > and
> > > then just have the min/max here.
> >
> > And how could I add meaning to the values. Could I add all in the
> > "parent" node?
>
> No, they have to be at the correct level. You can keep the
> descriptions here. Just do:
>
> adi,sensor-type:
> description: ...
> $ref: /schemas/types.yaml#/definitions/uint32
>
> under ".*@([1-9]|1[0-9]|20)$" and drop the 'allOf: [ $ref: ...]'
> part.
>
> > > > + - minimum: 1
> > > > + - maximum: 9
> > > > +
> > > > + adi,single-ended:
> > > > + description: |
> > > > + Boolean property which set's the thermocouple as
> > > > single-ended.
> > > > + type: boolean
> > > > +
> > > > + adi,sensor-oc-current-microamp:
> > > > + description: |
> > > > + This property set's the pulsed current value
> > > > applied
> > > > during
> > > > + open-circuit detect.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [10, 100, 500, 1000]
> > > > +
> > > > + adi,cold-junction-handle:
> > > > + description: |
> > > > + Phandle which points to a sensor object
> > > > responsible
> > > > for measuring
> > > > + the thermocouple cold junction temperature.
> > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +
> > > > + adi,custom-sensor:
> > > > + description: |
> > > > + This is a table, where each entry should be a
> > > > pair
> > > > of
> > > > + voltage(mv)-temperature(K). The entries must be
> > > > given in nv and uK
> > > > + so that, the original values must be multiplied
> > > > by
> > > > 1000000. For
> > >
> > > We normally do things in microVolts. It seems strange to need 64-
> > > bits
> > > of range for voltage and temperature.
> >
> > This device support very high resolutions (so we have fractional
> > values). That is why I'm multiplying by 1000000 and using nV. And
> > even
> > so, I already loose some bits. The 64bits are needed mainly because
> > of
> > the Temperature and again the resolution I want to maximize. Doing
> > int(max(temp)) * 1000000, we need 64bits.
> >
> > > > + more details look at table 69 and 70.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/int64-
> > > > array
> > >
> > > Fails on 'make dt_binding_check':
> > >
> > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l:
> > > Unresolvable JSON pointer: 'definitions/int64-array'
> >
> > I was aware of this but I do not know how to proceed so I was
> > waiting
> > for your comment. I do have negative values, so uint does not
> > apply.
> > What can I use here?
> >
> > > If this is pairs of values, it should really be defined as a
> > > matrix:
> > >
> > > minItems: 3
> > > maxItems: 64
> > > items:
> > > minItems: 2
> > > maxItems: 2
> > >
> > > Though I'll need to add uint64-matrix as a type (assuming this
> > > really
> > > needs to be 64-bit).
> >
> > I reinforce that I do need signed values here.
>
> I can add those as well. At least for now, they are going to end up
> being the exact same definition because IIRC while dtc takes signed
> input, that's lost by the time we emit the output.
So, can I just add something like int64-matrix?
> > > > + minItems: 6
> > > > + maxItems: 128
> > > > +
> > > > + required:
> > > > + - adi,sensor-type
> > > > +
> > > > + "^diode@.*":
> > > > + type: object
> > > > + description: |
> > > > + Represents a diode sensor which is connected to one
> > > > of
> > > > the device
> > > > + channels.
> > > > +
> > > > + properties:
> > > > + adi,sensor-type:
> > > > + description: Identifies the sensor as a diode.
> > > > + const: 28
> > > > +
> > > > + adi,single-ended:
> > > > + description: Boolean property which set's the
> > > > diode as
> > > > single-ended.
> > > > + type: boolean
> > > > +
> > > > + adi,three-conversion-cycles:
> > > > + description: |
> > > > + Boolean property which set's three conversion
> > > > cycles
> > > > removing
> > > > + parasitic resistance effects between the LTC2983
> > > > and
> > > > the diode.
> > > > + type: boolean
> > > > +
> > > > + adi,average-on:
> > > > + description: |
> > > > + Boolean property which enables a running average
> > > > of
> > > > the diode
> > > > + temperature reading. This reduces the noise when
> > > > the
> > > > diode is used
> > > > + as a cold junction temperature element on an
> > > > isothermal block
> > > > + where temperatures change slowly.
> > > > + type: boolean
> > > > +
> > > > + adi,excitation-current-microamp:
> > > > + description: |
> > > > + This property controls the magnitude of the
> > > > excitation current
> > > > + applied to the diode. Depending on the number of
> > > > conversions
> > > > + cycles, this property will assume different
> > > > predefined values on
> > > > + each cycle. Just set the value of the first
> > > > cycle
> > > > (1l).
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [10, 20, 40, 80]
> > > > +
> > > > + adi,ideal-factor-value:
> > > > + description: |
> > > > + This property sets the diode ideality factor.
> > > > The
> > > > real value must
> > > > + be multiplied by 1000000 to remove the
> > > > fractional
> > > > part. For more
> > > > + information look at table 20 of the datasheet.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > +
> > > > + required:
> > > > + - adi,sensor-type
> > > > +
> > > > + "^rtd@.*":
> > > > + type: object
> > > > + description: |
> > > > + Represents a rtd sensor which is connected to one of
> > > > the
> > > > device channels.
> > > > +
> > > > + properties:
> > > > + reg:
> > > > + minimum: 2
> > > > +
> > > > + adi,sensor-type:
> > > > + description: |
> > > > + Identifies the type of RTD connected to the
> > > > device.
> > > > + 10 - RTD PT-10
> > > > + 11 - RTD PT-50
> > > > + 12 - RTD PT-100
> > > > + 13 - RTD PT-200
> > > > + 14 - RTD PT-500
> > > > + 15 - RTD PT-1000
> > > > + 16 - RTD PT-1000 (0.00375)
> > > > + 17 - RTD NI-120
> > > > + 18 - RTD Custom
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - minimum: 10
> > > > + - maximum: 18
> > > > +
> > > > + adi,rsense-handle:
> > > > + description: |
> > > > + Phandle pointing to a rsense object associated
> > > > with
> > > > this RTD.
> > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +
> > > > + adi,number-of-wires:
> > > > + description: |
> > > > + Identifies the number of wires used by the RTD.
> > > > Setting this
> > > > + property to 5 means 4 wires with Kelvin Rsense.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [2, 3, 4, 5]
> > > > +
> > > > + adi,rsense-share:
> > > > + description: |
> > > > + Boolean property which enables Rsense sharing,
> > > > where
> > > > one sense
> > > > + resistor is used for multiple 2-, 3-, and/or 4-
> > > > wire
> > > > RTDs.
> > > > + type: boolean
> > > > +
> > > > + adi,current-rotate:
> > > > + description: |
> > > > + Boolean property which enables excitation
> > > > current
> > > > rotation to
> > > > + automatically remove parasitic thermocouple
> > > > effects.
> > > > Note that
> > > > + this property is not allowed for 2- and 3-wire
> > > > RTDs.
> > > > + type: boolean
> > > > +
> > > > + adi,excitation-current-microamp:
> > > > + description: |
> > > > + This property controls the magnitude of the
> > > > excitation current
> > > > + applied to the RTD.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > You can drop the type here too.
> >
> > got it.
> >
> > > > + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> > > > +
> > > > + adi,rtd-curve:
> > > > + description: |
> > > > + This property set the RTD curve used and the
> > > > corresponding
> > > > + Callendar-VanDusen constants. Look at table 30
> > > > of
> > > > the datasheet.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - minimum: 0
> > > > + - maximum: 3
> > > > +
> > > > + adi,custom-sensor:
> > > > + description: |
> > > > + This is a table, where each entry should be a
> > > > pair
> > > > of
> > > > + resistance(ohm)-temperature(K). The entries
> > > > added
> > > > here are in uohm
> > > > + and uK. For more details values look at table 74
> > > > and
> > > > 75.
> > >
> > > It's not great to make one property name have different meanings.
> >
> > Would you prefer to have something like "custom-rtd", "custom-
> > thermoucouple" and so on? I would have to adapt the code but I
> > don't
> > think it would need to much of a change.
>
> I don't really know enough about this device to say... What does
> 'custom' mean here?
Custom, is really if a user wants to provide a custom sensor, which is
only supported for thermocouples, thermistors and RTDs. In those cases,
the user provides a table of points describing the sensor response,
which for example, on a thermocouple is voltage-temperature.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > > > array
> > > > + minItems: 6
> > > > + maxItems: 128
> > > > +
> > > > + required:
> > > > + - adi,sensor-type
> > > > + - adi,rsense-handle
> > > > +
> > > > + dependencies:
> > > > + adi,current-rotate: [ adi,rsense-share ]
> > > > +
> > > > + "^thermistor@.*":
> > > > + type: object
> > > > + description: |
> > > > + Represents a thermistor sensor which is connected to
> > > > one
> > > > of the device
> > > > + channels.
> > > > +
> > > > + properties:
> > > > + adi,sensor-type:
> > > > + description: |
> > > > + Identifies the type of thermistor connected to
> > > > the
> > > > + device.
> > > > + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> > > > + 20 - Thermistor 44005/44030 3kohm at 25°C
> > > > + 21 - Thermistor 44007/44034 5kohm at 25°C
> > > > + 22 - Thermistor 44006/44031 10kohm at 25°C
> > > > + 23 - Thermistor 44008/44032 30kohm at 25°C
> > > > + 24 - Thermistor YSI 400 2.252kohm at 25°C
> > > > + 25 - Thermistor Spectrum 1003k 1kohm
> > > > + 26 - Thermistor Custom Steinhart-Hart
> > > > + 27 - Custom Thermistor
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - minimum: 19
> > > > + - maximum: 27
> > > > +
> > > > + adi,rsense-handle:
> > > > + description: |
> > > > + Phandle pointing to a rsense object associated
> > > > with
> > > > this
> > > > + thermistor.
> > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +
> > > > + adi,single-ended:
> > > > + description: |
> > > > + Boolean property which set's the thermistor as
> > > > single-ended.
> > > > + type: boolean
> > > > +
> > > > + adi,rsense-share:
> > > > + description: |
> > > > + Boolean property which enables Rsense sharing,
> > > > where
> > > > one sense
> > > > + resistor is used for multiple thermistors. Note
> > > > that
> > > > this property
> > > > + is ignored if adi,single-ended is set.
> > > > + type: boolean
> > > > +
> > > > + adi,current-rotate:
> > > > + description: |
> > > > + Boolean property which enables excitation
> > > > current
> > > > rotation to
> > > > + automatically remove parasitic thermocouple
> > > > effects.
> > > > + type: boolean
> > > > +
> > > > + adi,excitation-current-nanoamp:
> > > > + description: |
> > > > + This property controls the magnitude of the
> > > > excitation current
> > > > + applied to the thermistor. Value 0 set's the
> > > > sensor
> > > > in auto-range
> > > > + mode.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [0, 250, 500, 1000, 5000, 10000, 25000,
> > > > 50000, 100000,
> > > > + 250000, 500000, 1000000]
> > > > +
> > > > + adi,custom-sensor:
> > > > + description: |
> > > > + This is a table, where each entry should be a
> > > > pair
> > > > of
> > > > + resistance(ohm)-temperature(K). The entries
> > > > added
> > > > here are in uohm
> > > > + and uK only for custom thermistors. For more
> > > > details
> > > > look at table
> > > > + 78 and 79. Steinhart-Hart coefficients are also
> > > > supported and can
> > > > + be programmed into the device memory using this
> > > > property. For
> > > > + Steinhart sensors, this table has a constant
> > > > size of
> > > > 6 entries
> > > > + (defining the coefficients) and the values are
> > > > given
> > > > in the raw
> > > > + format. Look at table 82 for more information.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > > > array
> > > > + minItems: 6
> > > > + maxItems: 128
> > > > +
> >
> > If I'm to replace this property as proposed before, would it make
> > sense
> > also to split this in custom-thermistor and custom-steinhart or
> > just
> > steinhart?
>
> Seems like it as the data is completely different.
I'm also feeling like I should have this property split in 2.
> > > > + required:
> > > > + - adi,sensor-type
> > > > + - adi,rsense-handle
> > > > +
> > > > + dependencies:
> > > > + adi,current-rotate: [ adi,rsense-share ]
> > > > +
> > > > + "^adc@.*":
> > > > + type: object
> > > > + description: Represents a channel which is being used
> > > > as a
> > > > direct adc.
> > > > +
> > > > + properties:
> > > > + adi,sensor-type:
> > > > + description: Identifies the sensor as a direct
> > > > adc.
> > > > + const: 30
> > > > +
> > > > + adi,single-ended:
> > > > + description: Boolean property which set's the adc
> > > > as
> > > > single-ended.
> > > > + type: boolean
> > > > +
> > > > + required:
> > > > + - adi,sensor-type
> > > > +
> > > > + "^rsense@.*":
> > > > + type: object
> > > > + description: |
> > > > + Represents a rsense which is connected to one of the
> > > > device channels.
> > > > + Rsense are used by thermistors and RTD's.
> > > > +
> > > > + properties:
> > > > + reg:
> > > > + minimum: 2
> > > > +
> > > > + adi,sensor-type:
> > > > + description: Identifies the sensor as a rsense.
> > > > + const: 29
> > > > +
> > > > + adi,rsense-val-micro-ohms:
> > > > + description: |
> > > > + Sets the value of the sense resistor. Look at
> > > > table
> > > > 20 of the
> > > > + datasheet for information.
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint64
> > >
> > > -micro-ohms is already defined to be 32-bit.
> >
> > I do need a 64-bit variable here. Should I still remove the $ref or
> > how
> > can I proceed?
>
> We could add -milli-ohms. According to the datasheet, it's 0-131kohms
> in 1/1024ohm steps.
We will loose a bit of resolution, but I guess milli-ohms is more than
sufficient for practical/real usage.
> Rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-08 7:45 ` Sa, Nuno
@ 2019-10-08 10:22 ` Sa, Nuno
2019-10-10 20:03 ` Rob Herring
0 siblings, 1 reply; 15+ messages in thread
From: Sa, Nuno @ 2019-10-08 10:22 UTC (permalink / raw)
To: robh+dt
Cc: lars, jic23, devicetree, mark.rutland, pmeerw, linux-iio, knaack.h
Hi Rob,
Somethings that I would like to clarify before sending a v4 since I'm
having errors and I'm not really sure about the fix I'm using.
On Tue, 2019-10-08 at 07:45 +0000, Sa, Nuno wrote:
>
> On Mon, 2019-10-07 at 12:46 -0500, Rob Herring wrote:
> > On Mon, Oct 7, 2019 at 11:17 AM Sa, Nuno <Nuno.Sa@analog.com>
> > wrote:
> > > On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> > > > On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com>
> > > > wrote:
> > > > > Document the LTC2983 temperature sensor devicetree bindings.
> > > > >
> > > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > > > ---
> > > > > Changes in v2:
> > > > > * Drop maxItems in non-array elements;
> > > > > * Set adi,mux-delay-config-us instead of adi,mux-delay-
> > > > > config;
> > > > > * Wrapped lines at 80 char;
> > > > > * Added comas to enum elements;
> > > > > * Use real units in adi,excitation-current;
> > > > > * Moved some enums to minimum and maximum;
> > > > > * Grouped patternProperties and moved reg property as a
> > > > > generic
> > > > > property.
> > > > >
> > > > > Changes in v3:
> > > > > * Add meaning to adi,sensor-type values which are not const;
> > > > > * Add meaning to adi,filter-notch-freq values;
> > > > > * Break up adi,sensor-config into human readable elements;
> > > > > * Set maxItems/minItems at the same identation as allOf in
> > > > > adi,custom-sensor;
> > > > > * Fixed the maximum value for adi,sensor-type for sensors
> > > > > with
> > > > > custom support;
> > > > > * Changed license to GPL-2.0-only as it should be for new
> > > > > bindings;
> > > > > * Changed spi0 to spi in the dts example;
> > > > > * Updated the dts example to the new properties.
> > > > >
> > > > > .../bindings/iio/temperature/adi,ltc2983.yaml | 479
> > > > > ++++++++++++++++++
> > > > > MAINTAINERS | 1 +
> > > > > 2 files changed, 480 insertions(+)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983
> > > > > .y
> > > > > aml
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > > > 83
> > > > > .yam
> > > > > l
> > > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > > > 83
> > > > > .yam
> > > > > l
> > > > > new file mode 100644
> > > > > index 000000000000..b7101a0e84db
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > > > 83
> > > > > .yam
> > > > > l
> > > > > @@ -0,0 +1,479 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0-only
> > > >
> > > > (GPL-2.0-only OR BSD-2-Clause) for new bindings please.
> > >
> > > ack.
> > >
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id:
> > > > > http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Analog Devices LTC2983 Multi-sensor Temperature
> > > > > system
> > > > > +
> > > > > +maintainers:
> > > > > + - Nuno Sá <nuno.sa@analog.com>
> > > > > +
> > > > > +description: |
> > > > > + Analog Devices LTC2983 Multi-Sensor Digital Temperature
> > > > > Measurement System
> > > > > +
> > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + enum:
> > > > > + - adi,ltc2983
> > > > > +
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + interrupts:
> > > > > + maxItems: 1
> > > > > +
> > > > > + adi,temperature-celcius:
> > > >
> > > > -celsius. However, that suffix is reserved for properties whose
> > > > value
> > > > is in Celsius, so you'll have to come up with something else.
> > > >
> > > > How does one decide how to set this? Seems like the driver
> > > > should
> > > > just
> > > > decide based on what it needs to present to the user.
> > >
> > > The device can report temperature in Celsius or Fahrenheit and
> > > that
> > > should be decided once. Hmm but now that I think about this, the
> > > iio
> > > standard attributes expect the value to be reported in milli
> > > degrees
> > > Celsius so I guess I should just drop this and don't report in
> > > Fahrenheit. Would this be ok Jonathan?
> > >
> > > > > + description:
> > > > > + If this property is present, the temperature is
> > > > > reported
> > > > > in
> > > > > Celsius.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,mux-delay-config-us:
> > > > > + description:
> > > > > + The LTC2983 performs 2 or 3 internal conversion cycles
> > > > > per
> > > > > temperature
> > > > > + result. Each conversion cycle is performed with
> > > > > different
> > > > > excitation and
> > > > > + input multiplexer configurations. Prior to each
> > > > > conversion,
> > > > > these
> > > > > + excitation circuits and input switch configurations
> > > > > are
> > > > > changed and an
> > > > > + internal 1ms delay ensures settling prior to the
> > > > > conversion
> > > > > cycle in most
> > > > > + cases. An extra delay can be configured using this
> > > > > property.
> > > > > The value is
> > > > > + rounded to nearest 100us.
> > > > > + allOf:
> > > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > > + - maximum: 255
> > > >
> > > > Standard unit suffixes already have a type, so just:
> > > >
> > > > maximum: 255
> > >
> > > got it.
> > >
> > > > > +
> > > > > + adi,filter-notch-freq:
> > > > > + description:
> > > > > + Set's the default setting of the digital filter. The
> > > > > default
> > > > > is
> > > > > + simultaneous 50/60Hz rejection.
> > > > > + 0 - 50/60Hz rejection
> > > > > + 1 - 60Hz rejection
> > > > > + 2 - 50Hz rejection
> > > > > + allOf:
> > > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > > + - minimum: 0
> > > > > + - maximum: 2
> > > >
> > > > Drop the '-' on the last entry (making the min/max a single
> > > > schema).
> > >
> > > got it.
> > >
> > > > > +
> > > > > + '#address-cells':
> > > > > + const: 1
> > > > > +
> > > > > + '#size-cells':
> > > > > + const: 0
> > > > > +
> > > > > +patternProperties:
> > > > > + ".*@([1-9]|1[0-9]|20)$":
> > > >
> > > > '.*' can be dropped.
> > > >
> > > > > + type: object
> > > > > +
> > > > > + properties:
> > > > > + reg:
> > > > > + description: |
> > > > > + The channel number. It can be connected to one of
> > > > > the 20
> > > > > channels of
> > > > > + the device.
> > > > > + minimum: 1
> > > > > + maximum: 20
> > > > > +
> > > > > + required:
> > > > > + - reg
> > > > > +
> > > > > + patternProperties:
> > > > > + "^thermocouple@.*":
> > > >
> > > > You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This
> > > > needs
> > > > to be at the same level.
> > >
> > > You mean dropping "patternProperties" and having
> > > "^thermocouple@.*": on
> > > the same indent as ".*@([1-9]|1[0-9]|20)$":? It seems to be only
> > > one
> >
> > Yes.
> >
> > > working. I understood and tried something like:
> > >
> > > patternProperties:
> > > "@([1-9]|1[0-9]|20)$":
> > > (...)
> > >
> > > patternProperties:
> >
> > What you are saying here is you have a patternProperty called
> > 'patternProperty'.
> >
> > > "^thermocouple@.*"
> >
> > And then this is not a valid json-schema keyword for the property's
> > schema.
> >
> > > description: "..."
> > > type: object
> > > properties:
> > > (...)
> > >
> > > But this throws "'^thermocouple@' is not one of ['$ref',
> > > 'additionalItems', 'additionalProperties', 'allOf', 'anyOf',
> > > 'const',
> > > 'contains', 'default', 'dependencies', 'deprecated',
> > > 'description',
> > > 'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems',
> > > 'maximum', 'not', 'oneOf', 'pattern', 'patternProperties',
> > > 'properties', 'required', 'then', 'type', 'typeSize']"
> > >
> > > Also, should I also drop the ".*" in "^thermocouple@.*"?
> >
> > Yes.
> >
> > > > > + type: object
> > > > > + description: |
> > > >
> > > > You can drop the '|' where you don't need any formatting.
> > >
> > > got it.
> > >
> > > > > + Represents a thermocouple sensor which is
> > > > > connected
> > > > > to
> > > > > one of the device
> > > > > + channels.
> > > > > +
> > > > > + properties:
> > > > > + adi,sensor-type:
> > > > > + description: |
> > > > > + Identifies the type of thermocouple connected
> > > > > to
> > > > > the
> > > > > device.
> > > > > + 1 - Type J Thermocouple
> > > > > + 2 - Type K Thermocouple
> > > > > + 3 - Type E Thermocouple
> > > > > + 4 - Type N Thermocouple
> > > > > + 5 - Type R Thermocouple
> > > > > + 6 - Type S Thermocouple
> > > > > + 7 - Type T Thermocouple
> > > > > + 8 - Type B Thermocouple
> > > > > + 9 - Custom Thermocouple
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > >
> > > > You can move the type definition under ".*@([1-9]|1[0-9]|20)$"
> > > > and
> > > > then just have the min/max here.
> > >
> > > And how could I add meaning to the values. Could I add all in the
> > > "parent" node?
> >
> > No, they have to be at the correct level. You can keep the
> > descriptions here. Just do:
> >
> > adi,sensor-type:
> > description: ...
> > $ref: /schemas/types.yaml#/definitions/uint32
> >
> > under ".*@([1-9]|1[0-9]|20)$" and drop the 'allOf: [ $ref: ...]'
> > part.
> >
So, Im doing like:
".*@([1-9]|1[0-9]|20)$":
type: object
properties:
reg:
description: ...
minimum: 1
maximum: 20
adi,sensor-type:
description: ...
$ref: /schemas/types.yaml#/definitions/uint32
required:
- reg
- adi,sensor-type
Then in:
"^thermocouple@":
type: object
description: ...
properties:
adi,sensor-type:
description: ...
minimum: 1
maximum: 9
This gives me that adi,sensor-type is not a valid schema. Adding allOf
before min/max fixes it. The same error comes in:
"^diode@":
type: object
description: ...
properties:
adi,sensor-type:
description: ...
const: 28 #adding allOf here also fixes it...
One last issue that I was not seeing before is with the reg property.
If you recall, you also suggested to have it under ".*@([1-9]|1[0-
9]|20)$": and then add the 'minimum: 2' where needed. Doing that now
also gives me invalid schema:
"^rtd@":
type: object
description: ...
properties:
reg:
minimum: 2
Changing to
reg:
items:
minimum: 2
fixes it but it feels that the first one should work?
The other issue I have is with int64-matrix which for now i guess it's
expected...
I updated the dtschema with `pip3 install --upgrade git+
https://github.com/devicetree-org/dt-schema.git@master`
Thanks for your help!
Nuno Sá
> > > > > + - minimum: 1
> > > > > + - maximum: 9
> > > > > +
> > > > > + adi,single-ended:
> > > > > + description: |
> > > > > + Boolean property which set's the thermocouple
> > > > > as
> > > > > single-ended.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,sensor-oc-current-microamp:
> > > > > + description: |
> > > > > + This property set's the pulsed current value
> > > > > applied
> > > > > during
> > > > > + open-circuit detect.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - enum: [10, 100, 500, 1000]
> > > > > +
> > > > > + adi,cold-junction-handle:
> > > > > + description: |
> > > > > + Phandle which points to a sensor object
> > > > > responsible
> > > > > for measuring
> > > > > + the thermocouple cold junction temperature.
> > > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > > +
> > > > > + adi,custom-sensor:
> > > > > + description: |
> > > > > + This is a table, where each entry should be a
> > > > > pair
> > > > > of
> > > > > + voltage(mv)-temperature(K). The entries must
> > > > > be
> > > > > given in nv and uK
> > > > > + so that, the original values must be
> > > > > multiplied
> > > > > by
> > > > > 1000000. For
> > > >
> > > > We normally do things in microVolts. It seems strange to need
> > > > 64-
> > > > bits
> > > > of range for voltage and temperature.
> > >
> > > This device support very high resolutions (so we have fractional
> > > values). That is why I'm multiplying by 1000000 and using nV. And
> > > even
> > > so, I already loose some bits. The 64bits are needed mainly
> > > because
> > > of
> > > the Temperature and again the resolution I want to maximize.
> > > Doing
> > > int(max(temp)) * 1000000, we need 64bits.
> > >
> > > > > + more details look at table 69 and 70.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/int64-
> > > > > array
> > > >
> > > > Fails on 'make dt_binding_check':
> > > >
> > > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.y
> > > > am
> > > > l:
> > > > Unresolvable JSON pointer: 'definitions/int64-array'
> > >
> > > I was aware of this but I do not know how to proceed so I was
> > > waiting
> > > for your comment. I do have negative values, so uint does not
> > > apply.
> > > What can I use here?
> > >
> > > > If this is pairs of values, it should really be defined as a
> > > > matrix:
> > > >
> > > > minItems: 3
> > > > maxItems: 64
> > > > items:
> > > > minItems: 2
> > > > maxItems: 2
> > > >
> > > > Though I'll need to add uint64-matrix as a type (assuming this
> > > > really
> > > > needs to be 64-bit).
> > >
> > > I reinforce that I do need signed values here.
> >
> > I can add those as well. At least for now, they are going to end up
> > being the exact same definition because IIRC while dtc takes signed
> > input, that's lost by the time we emit the output.
>
> So, can I just add something like int64-matrix?
>
> > > > > + minItems: 6
> > > > > + maxItems: 128
> > > > > +
> > > > > + required:
> > > > > + - adi,sensor-type
> > > > > +
> > > > > + "^diode@.*":
> > > > > + type: object
> > > > > + description: |
> > > > > + Represents a diode sensor which is connected to
> > > > > one
> > > > > of
> > > > > the device
> > > > > + channels.
> > > > > +
> > > > > + properties:
> > > > > + adi,sensor-type:
> > > > > + description: Identifies the sensor as a diode.
> > > > > + const: 28
> > > > > +
> > > > > + adi,single-ended:
> > > > > + description: Boolean property which set's the
> > > > > diode as
> > > > > single-ended.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,three-conversion-cycles:
> > > > > + description: |
> > > > > + Boolean property which set's three conversion
> > > > > cycles
> > > > > removing
> > > > > + parasitic resistance effects between the
> > > > > LTC2983
> > > > > and
> > > > > the diode.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,average-on:
> > > > > + description: |
> > > > > + Boolean property which enables a running
> > > > > average
> > > > > of
> > > > > the diode
> > > > > + temperature reading. This reduces the noise
> > > > > when
> > > > > the
> > > > > diode is used
> > > > > + as a cold junction temperature element on an
> > > > > isothermal block
> > > > > + where temperatures change slowly.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,excitation-current-microamp:
> > > > > + description: |
> > > > > + This property controls the magnitude of the
> > > > > excitation current
> > > > > + applied to the diode. Depending on the number
> > > > > of
> > > > > conversions
> > > > > + cycles, this property will assume different
> > > > > predefined values on
> > > > > + each cycle. Just set the value of the first
> > > > > cycle
> > > > > (1l).
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - enum: [10, 20, 40, 80]
> > > > > +
> > > > > + adi,ideal-factor-value:
> > > > > + description: |
> > > > > + This property sets the diode ideality factor.
> > > > > The
> > > > > real value must
> > > > > + be multiplied by 1000000 to remove the
> > > > > fractional
> > > > > part. For more
> > > > > + information look at table 20 of the datasheet.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > +
> > > > > + required:
> > > > > + - adi,sensor-type
> > > > > +
> > > > > + "^rtd@.*":
> > > > > + type: object
> > > > > + description: |
> > > > > + Represents a rtd sensor which is connected to one
> > > > > of
> > > > > the
> > > > > device channels.
> > > > > +
> > > > > + properties:
> > > > > + reg:
> > > > > + minimum: 2
> > > > > +
> > > > > + adi,sensor-type:
> > > > > + description: |
> > > > > + Identifies the type of RTD connected to the
> > > > > device.
> > > > > + 10 - RTD PT-10
> > > > > + 11 - RTD PT-50
> > > > > + 12 - RTD PT-100
> > > > > + 13 - RTD PT-200
> > > > > + 14 - RTD PT-500
> > > > > + 15 - RTD PT-1000
> > > > > + 16 - RTD PT-1000 (0.00375)
> > > > > + 17 - RTD NI-120
> > > > > + 18 - RTD Custom
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - minimum: 10
> > > > > + - maximum: 18
> > > > > +
> > > > > + adi,rsense-handle:
> > > > > + description: |
> > > > > + Phandle pointing to a rsense object associated
> > > > > with
> > > > > this RTD.
> > > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > > +
> > > > > + adi,number-of-wires:
> > > > > + description: |
> > > > > + Identifies the number of wires used by the
> > > > > RTD.
> > > > > Setting this
> > > > > + property to 5 means 4 wires with Kelvin
> > > > > Rsense.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - enum: [2, 3, 4, 5]
> > > > > +
> > > > > + adi,rsense-share:
> > > > > + description: |
> > > > > + Boolean property which enables Rsense sharing,
> > > > > where
> > > > > one sense
> > > > > + resistor is used for multiple 2-, 3-, and/or
> > > > > 4-
> > > > > wire
> > > > > RTDs.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,current-rotate:
> > > > > + description: |
> > > > > + Boolean property which enables excitation
> > > > > current
> > > > > rotation to
> > > > > + automatically remove parasitic thermocouple
> > > > > effects.
> > > > > Note that
> > > > > + this property is not allowed for 2- and 3-wire
> > > > > RTDs.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,excitation-current-microamp:
> > > > > + description: |
> > > > > + This property controls the magnitude of the
> > > > > excitation current
> > > > > + applied to the RTD.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > >
> > > > You can drop the type here too.
> > >
> > > got it.
> > >
> > > > > + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> > > > > +
> > > > > + adi,rtd-curve:
> > > > > + description: |
> > > > > + This property set the RTD curve used and the
> > > > > corresponding
> > > > > + Callendar-VanDusen constants. Look at table 30
> > > > > of
> > > > > the datasheet.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - minimum: 0
> > > > > + - maximum: 3
> > > > > +
> > > > > + adi,custom-sensor:
> > > > > + description: |
> > > > > + This is a table, where each entry should be a
> > > > > pair
> > > > > of
> > > > > + resistance(ohm)-temperature(K). The entries
> > > > > added
> > > > > here are in uohm
> > > > > + and uK. For more details values look at table
> > > > > 74
> > > > > and
> > > > > 75.
> > > >
> > > > It's not great to make one property name have different
> > > > meanings.
> > >
> > > Would you prefer to have something like "custom-rtd", "custom-
> > > thermoucouple" and so on? I would have to adapt the code but I
> > > don't
> > > think it would need to much of a change.
> >
> > I don't really know enough about this device to say... What does
> > 'custom' mean here?
>
> Custom, is really if a user wants to provide a custom sensor, which
> is
> only supported for thermocouples, thermistors and RTDs. In those
> cases,
> the user provides a table of points describing the sensor response,
> which for example, on a thermocouple is voltage-temperature.
>
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint64-
> > > > > array
> > > > > + minItems: 6
> > > > > + maxItems: 128
> > > > > +
> > > > > + required:
> > > > > + - adi,sensor-type
> > > > > + - adi,rsense-handle
> > > > > +
> > > > > + dependencies:
> > > > > + adi,current-rotate: [ adi,rsense-share ]
> > > > > +
> > > > > + "^thermistor@.*":
> > > > > + type: object
> > > > > + description: |
> > > > > + Represents a thermistor sensor which is connected
> > > > > to
> > > > > one
> > > > > of the device
> > > > > + channels.
> > > > > +
> > > > > + properties:
> > > > > + adi,sensor-type:
> > > > > + description: |
> > > > > + Identifies the type of thermistor connected to
> > > > > the
> > > > > + device.
> > > > > + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> > > > > + 20 - Thermistor 44005/44030 3kohm at 25°C
> > > > > + 21 - Thermistor 44007/44034 5kohm at 25°C
> > > > > + 22 - Thermistor 44006/44031 10kohm at 25°C
> > > > > + 23 - Thermistor 44008/44032 30kohm at 25°C
> > > > > + 24 - Thermistor YSI 400 2.252kohm at 25°C
> > > > > + 25 - Thermistor Spectrum 1003k 1kohm
> > > > > + 26 - Thermistor Custom Steinhart-Hart
> > > > > + 27 - Custom Thermistor
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - minimum: 19
> > > > > + - maximum: 27
> > > > > +
> > > > > + adi,rsense-handle:
> > > > > + description: |
> > > > > + Phandle pointing to a rsense object associated
> > > > > with
> > > > > this
> > > > > + thermistor.
> > > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > > +
> > > > > + adi,single-ended:
> > > > > + description: |
> > > > > + Boolean property which set's the thermistor as
> > > > > single-ended.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,rsense-share:
> > > > > + description: |
> > > > > + Boolean property which enables Rsense sharing,
> > > > > where
> > > > > one sense
> > > > > + resistor is used for multiple thermistors.
> > > > > Note
> > > > > that
> > > > > this property
> > > > > + is ignored if adi,single-ended is set.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,current-rotate:
> > > > > + description: |
> > > > > + Boolean property which enables excitation
> > > > > current
> > > > > rotation to
> > > > > + automatically remove parasitic thermocouple
> > > > > effects.
> > > > > + type: boolean
> > > > > +
> > > > > + adi,excitation-current-nanoamp:
> > > > > + description: |
> > > > > + This property controls the magnitude of the
> > > > > excitation current
> > > > > + applied to the thermistor. Value 0 set's the
> > > > > sensor
> > > > > in auto-range
> > > > > + mode.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint32
> > > > > + - enum: [0, 250, 500, 1000, 5000, 10000,
> > > > > 25000,
> > > > > 50000, 100000,
> > > > > + 250000, 500000, 1000000]
> > > > > +
> > > > > + adi,custom-sensor:
> > > > > + description: |
> > > > > + This is a table, where each entry should be a
> > > > > pair
> > > > > of
> > > > > + resistance(ohm)-temperature(K). The entries
> > > > > added
> > > > > here are in uohm
> > > > > + and uK only for custom thermistors. For more
> > > > > details
> > > > > look at table
> > > > > + 78 and 79. Steinhart-Hart coefficients are
> > > > > also
> > > > > supported and can
> > > > > + be programmed into the device memory using
> > > > > this
> > > > > property. For
> > > > > + Steinhart sensors, this table has a constant
> > > > > size of
> > > > > 6 entries
> > > > > + (defining the coefficients) and the values are
> > > > > given
> > > > > in the raw
> > > > > + format. Look at table 82 for more information.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint64-
> > > > > array
> > > > > + minItems: 6
> > > > > + maxItems: 128
> > > > > +
> > >
> > > If I'm to replace this property as proposed before, would it make
> > > sense
> > > also to split this in custom-thermistor and custom-steinhart or
> > > just
> > > steinhart?
> >
> > Seems like it as the data is completely different.
>
> I'm also feeling like I should have this property split in 2.
>
> > > > > + required:
> > > > > + - adi,sensor-type
> > > > > + - adi,rsense-handle
> > > > > +
> > > > > + dependencies:
> > > > > + adi,current-rotate: [ adi,rsense-share ]
> > > > > +
> > > > > + "^adc@.*":
> > > > > + type: object
> > > > > + description: Represents a channel which is being
> > > > > used
> > > > > as a
> > > > > direct adc.
> > > > > +
> > > > > + properties:
> > > > > + adi,sensor-type:
> > > > > + description: Identifies the sensor as a direct
> > > > > adc.
> > > > > + const: 30
> > > > > +
> > > > > + adi,single-ended:
> > > > > + description: Boolean property which set's the
> > > > > adc
> > > > > as
> > > > > single-ended.
> > > > > + type: boolean
> > > > > +
> > > > > + required:
> > > > > + - adi,sensor-type
> > > > > +
> > > > > + "^rsense@.*":
> > > > > + type: object
> > > > > + description: |
> > > > > + Represents a rsense which is connected to one of
> > > > > the
> > > > > device channels.
> > > > > + Rsense are used by thermistors and RTD's.
> > > > > +
> > > > > + properties:
> > > > > + reg:
> > > > > + minimum: 2
> > > > > +
> > > > > + adi,sensor-type:
> > > > > + description: Identifies the sensor as a rsense.
> > > > > + const: 29
> > > > > +
> > > > > + adi,rsense-val-micro-ohms:
> > > > > + description: |
> > > > > + Sets the value of the sense resistor. Look at
> > > > > table
> > > > > 20 of the
> > > > > + datasheet for information.
> > > > > + allOf:
> > > > > + - $ref:
> > > > > /schemas/types.yaml#/definitions/uint64
> > > >
> > > > -micro-ohms is already defined to be 32-bit.
> > >
> > > I do need a 64-bit variable here. Should I still remove the $ref
> > > or
> > > how
> > > can I proceed?
> >
> > We could add -milli-ohms. According to the datasheet, it's 0-
> > 131kohms
> > in 1/1024ohm steps.
>
> We will loose a bit of resolution, but I guess milli-ohms is more
> than
> sufficient for practical/real usage.
>
> > Rob
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Stefan Steyerl, Thomas Edward Cribben, Michael Paul
Sondel
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-08 10:22 ` Sa, Nuno
@ 2019-10-10 20:03 ` Rob Herring
0 siblings, 0 replies; 15+ messages in thread
From: Rob Herring @ 2019-10-10 20:03 UTC (permalink / raw)
To: Sa, Nuno
Cc: lars, jic23, devicetree, mark.rutland, pmeerw, linux-iio, knaack.h
On Tue, Oct 08, 2019 at 10:22:04AM +0000, Sa, Nuno wrote:
> Hi Rob,
>
> Somethings that I would like to clarify before sending a v4 since I'm
> having errors and I'm not really sure about the fix I'm using.
>
> On Tue, 2019-10-08 at 07:45 +0000, Sa, Nuno wrote:
> >
> > On Mon, 2019-10-07 at 12:46 -0500, Rob Herring wrote:
> > > On Mon, Oct 7, 2019 at 11:17 AM Sa, Nuno <Nuno.Sa@analog.com>
> > > wrote:
> > > > On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> > > > > On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com>
> > > > > wrote:
> > > > > > Document the LTC2983 temperature sensor devicetree bindings.
> > > > > >
> > > > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > > > > + Represents a thermocouple sensor which is
> > > > > > connected
> > > > > > to
> > > > > > one of the device
> > > > > > + channels.
> > > > > > +
> > > > > > + properties:
> > > > > > + adi,sensor-type:
> > > > > > + description: |
> > > > > > + Identifies the type of thermocouple connected
> > > > > > to
> > > > > > the
> > > > > > device.
> > > > > > + 1 - Type J Thermocouple
> > > > > > + 2 - Type K Thermocouple
> > > > > > + 3 - Type E Thermocouple
> > > > > > + 4 - Type N Thermocouple
> > > > > > + 5 - Type R Thermocouple
> > > > > > + 6 - Type S Thermocouple
> > > > > > + 7 - Type T Thermocouple
> > > > > > + 8 - Type B Thermocouple
> > > > > > + 9 - Custom Thermocouple
> > > > > > + allOf:
> > > > > > + - $ref:
> > > > > > /schemas/types.yaml#/definitions/uint32
> > > > >
> > > > > You can move the type definition under ".*@([1-9]|1[0-9]|20)$"
> > > > > and
> > > > > then just have the min/max here.
> > > >
> > > > And how could I add meaning to the values. Could I add all in the
> > > > "parent" node?
> > >
> > > No, they have to be at the correct level. You can keep the
> > > descriptions here. Just do:
> > >
> > > adi,sensor-type:
> > > description: ...
> > > $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > under ".*@([1-9]|1[0-9]|20)$" and drop the 'allOf: [ $ref: ...]'
> > > part.
> > >
>
> So, Im doing like:
>
> ".*@([1-9]|1[0-9]|20)$":
> type: object
>
> properties:
> reg:
> description: ...
> minimum: 1
> maximum: 20
>
> adi,sensor-type:
> description: ...
> $ref: /schemas/types.yaml#/definitions/uint32
>
> required:
> - reg
> - adi,sensor-type
>
> Then in:
>
> "^thermocouple@":
> type: object
> description: ...
>
> properties:
> adi,sensor-type:
> description: ...
> minimum: 1
> maximum: 9
>
> This gives me that adi,sensor-type is not a valid schema. Adding allOf
> before min/max fixes it. The same error comes in:
Forget what I said, you're going to need to keep '$ref:
/schemas/types.yaml#/definitions/uint32' here.
The problem is the meta-schema enforces that a vendor specific property
(one with a comma) have a type defined and there's not really any way to
say it already does elsewhere. I don't want to loosen that up globally
either.
>
> "^diode@":
> type: object
> description: ...
>
> properties:
> adi,sensor-type:
> description: ...
> const: 28 #adding allOf here also fixes it...
I need to fix the meta-schema to check what's under 'allOf'. :)
>
> One last issue that I was not seeing before is with the reg property.
> If you recall, you also suggested to have it under ".*@([1-9]|1[0-
> 9]|20)$": and then add the 'minimum: 2' where needed. Doing that now
> also gives me invalid schema:
>
> "^rtd@":
> type: object
> description: ...
>
> properties:
> reg:
> minimum: 2
>
> Changing to
> reg:
> items:
> minimum: 2
>
> fixes it but it feels that the first one should work?
The problem is we require both minimum and maximum to be defined. So
really the second one should fail too. Or we should loosen this
requirement.
Rob
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
2019-10-07 16:17 ` Sa, Nuno
2019-10-07 17:46 ` Rob Herring
@ 2019-10-12 10:41 ` Jonathan Cameron
1 sibling, 0 replies; 15+ messages in thread
From: Jonathan Cameron @ 2019-10-12 10:41 UTC (permalink / raw)
To: Sa, Nuno
Cc: robh+dt, mark.rutland, devicetree, knaack.h, linux-iio, pmeerw, lars
On Mon, 7 Oct 2019 16:17:02 +0000
"Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> > On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com> wrote:
> > > Document the LTC2983 temperature sensor devicetree bindings.
> > >
> > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > ---
> > > Changes in v2:
> > > * Drop maxItems in non-array elements;
> > > * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> > > * Wrapped lines at 80 char;
> > > * Added comas to enum elements;
> > > * Use real units in adi,excitation-current;
> > > * Moved some enums to minimum and maximum;
> > > * Grouped patternProperties and moved reg property as a generic
> > > property.
> > >
> > > Changes in v3:
> > > * Add meaning to adi,sensor-type values which are not const;
> > > * Add meaning to adi,filter-notch-freq values;
> > > * Break up adi,sensor-config into human readable elements;
> > > * Set maxItems/minItems at the same identation as allOf in
> > > adi,custom-sensor;
> > > * Fixed the maximum value for adi,sensor-type for sensors with
> > > custom support;
> > > * Changed license to GPL-2.0-only as it should be for new
> > > bindings;
> > > * Changed spi0 to spi in the dts example;
> > > * Updated the dts example to the new properties.
> > >
> > > .../bindings/iio/temperature/adi,ltc2983.yaml | 479
> > > ++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 2 files changed, 480 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l
> > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l
> > > new file mode 100644
> > > index 000000000000..b7101a0e84db
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > l
> > > @@ -0,0 +1,479 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only
> >
> > (GPL-2.0-only OR BSD-2-Clause) for new bindings please.
>
> ack.
>
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Analog Devices LTC2983 Multi-sensor Temperature system
> > > +
> > > +maintainers:
> > > + - Nuno Sá <nuno.sa@analog.com>
> > > +
> > > +description: |
> > > + Analog Devices LTC2983 Multi-Sensor Digital Temperature
> > > Measurement System
> > > +
> > > https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - adi,ltc2983
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + adi,temperature-celcius:
> >
> > -celsius. However, that suffix is reserved for properties whose value
> > is in Celsius, so you'll have to come up with something else.
> >
> > How does one decide how to set this? Seems like the driver should
> > just
> > decide based on what it needs to present to the user.
>
> The device can report temperature in Celsius or Fahrenheit and that
> should be decided once. Hmm but now that I think about this, the iio
> standard attributes expect the value to be reported in milli degrees
> Celsius so I guess I should just drop this and don't report in
> Fahrenheit. Would this be ok Jonathan?
Guessing you've already done this, but yes I'm fine with just not
supporting Fahrenheit at all.
>
> > > + description:
> > > + If this property is present, the temperature is reported in
> > > Celsius.
> > > + type: boolean
> > > +
> > > + adi,mux-delay-config-us:
> > > + description:
> > > + The LTC2983 performs 2 or 3 internal conversion cycles per
> > > temperature
> > > + result. Each conversion cycle is performed with different
> > > excitation and
> > > + input multiplexer configurations. Prior to each conversion,
> > > these
> > > + excitation circuits and input switch configurations are
> > > changed and an
> > > + internal 1ms delay ensures settling prior to the conversion
> > > cycle in most
> > > + cases. An extra delay can be configured using this property.
> > > The value is
> > > + rounded to nearest 100us.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - maximum: 255
> >
> > Standard unit suffixes already have a type, so just:
> >
> > maximum: 255
>
> got it.
>
> > > +
> > > + adi,filter-notch-freq:
> > > + description:
> > > + Set's the default setting of the digital filter. The default
> > > is
> > > + simultaneous 50/60Hz rejection.
> > > + 0 - 50/60Hz rejection
> > > + 1 - 60Hz rejection
> > > + 2 - 50Hz rejection
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 0
> > > + - maximum: 2
> >
> > Drop the '-' on the last entry (making the min/max a single schema).
>
> got it.
>
> > > +
> > > + '#address-cells':
> > > + const: 1
> > > +
> > > + '#size-cells':
> > > + const: 0
> > > +
> > > +patternProperties:
> > > + ".*@([1-9]|1[0-9]|20)$":
> >
> > '.*' can be dropped.
> >
> > > + type: object
> > > +
> > > + properties:
> > > + reg:
> > > + description: |
> > > + The channel number. It can be connected to one of the 20
> > > channels of
> > > + the device.
> > > + minimum: 1
> > > + maximum: 20
> > > +
> > > + required:
> > > + - reg
> > > +
> > > + patternProperties:
> > > + "^thermocouple@.*":
> >
> > You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This needs
> > to be at the same level.
>
> You mean dropping "patternProperties" and having "^thermocouple@.*": on
> the same indent as ".*@([1-9]|1[0-9]|20)$":? It seems to be only one
> working. I understood and tried something like:
>
> patternProperties:
> "@([1-9]|1[0-9]|20)$":
> (...)
>
> patternProperties:
> "^thermocouple@.*"
> description: "..."
> type: object
> properties:
> (...)
>
> But this throws "'^thermocouple@' is not one of ['$ref',
> 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const',
> 'contains', 'default', 'dependencies', 'deprecated', 'description',
> 'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems',
> 'maximum', 'not', 'oneOf', 'pattern', 'patternProperties',
> 'properties', 'required', 'then', 'type', 'typeSize']"
>
> Also, should I also drop the ".*" in "^thermocouple@.*"?
> > > + type: object
> > > + description: |
> >
> > You can drop the '|' where you don't need any formatting.
>
> got it.
>
> > > + Represents a thermocouple sensor which is connected to
> > > one of the device
> > > + channels.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: |
> > > + Identifies the type of thermocouple connected to the
> > > device.
> > > + 1 - Type J Thermocouple
> > > + 2 - Type K Thermocouple
> > > + 3 - Type E Thermocouple
> > > + 4 - Type N Thermocouple
> > > + 5 - Type R Thermocouple
> > > + 6 - Type S Thermocouple
> > > + 7 - Type T Thermocouple
> > > + 8 - Type B Thermocouple
> > > + 9 - Custom Thermocouple
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> >
> > You can move the type definition under ".*@([1-9]|1[0-9]|20)$" and
> > then just have the min/max here.
>
> And how could I add meaning to the values. Could I add all in the
> "parent" node?
>
> > > + - minimum: 1
> > > + - maximum: 9
> > > +
> > > + adi,single-ended:
> > > + description: |
> > > + Boolean property which set's the thermocouple as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + adi,sensor-oc-current-microamp:
> > > + description: |
> > > + This property set's the pulsed current value applied
> > > during
> > > + open-circuit detect.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [10, 100, 500, 1000]
> > > +
> > > + adi,cold-junction-handle:
> > > + description: |
> > > + Phandle which points to a sensor object responsible
> > > for measuring
> > > + the thermocouple cold junction temperature.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + adi,custom-sensor:
> > > + description: |
> > > + This is a table, where each entry should be a pair
> > > of
> > > + voltage(mv)-temperature(K). The entries must be
> > > given in nv and uK
> > > + so that, the original values must be multiplied by
> > > 1000000. For
> >
> > We normally do things in microVolts. It seems strange to need 64-bits
> > of range for voltage and temperature.
>
> This device support very high resolutions (so we have fractional
> values). That is why I'm multiplying by 1000000 and using nV. And even
> so, I already loose some bits. The 64bits are needed mainly because of
> the Temperature and again the resolution I want to maximize. Doing
> int(max(temp)) * 1000000, we need 64bits.
>
> >
> > > + more details look at table 69 and 70.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/int64-array
> >
> > Fails on 'make dt_binding_check':
> >
> > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml:
> > Unresolvable JSON pointer: 'definitions/int64-array'
>
> I was aware of this but I do not know how to proceed so I was waiting
> for your comment. I do have negative values, so uint does not apply.
> What can I use here?
>
> > If this is pairs of values, it should really be defined as a matrix:
> >
> > minItems: 3
> > maxItems: 64
> > items:
> > minItems: 2
> > maxItems: 2
> >
> > Though I'll need to add uint64-matrix as a type (assuming this really
> > needs to be 64-bit).
>
> I reinforce that I do need signed values here.
>
> >
> > > + minItems: 6
> > > + maxItems: 128
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > +
> > > + "^diode@.*":
> > > + type: object
> > > + description: |
> > > + Represents a diode sensor which is connected to one of
> > > the device
> > > + channels.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: Identifies the sensor as a diode.
> > > + const: 28
> > > +
> > > + adi,single-ended:
> > > + description: Boolean property which set's the diode as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + adi,three-conversion-cycles:
> > > + description: |
> > > + Boolean property which set's three conversion cycles
> > > removing
> > > + parasitic resistance effects between the LTC2983 and
> > > the diode.
> > > + type: boolean
> > > +
> > > + adi,average-on:
> > > + description: |
> > > + Boolean property which enables a running average of
> > > the diode
> > > + temperature reading. This reduces the noise when the
> > > diode is used
> > > + as a cold junction temperature element on an
> > > isothermal block
> > > + where temperatures change slowly.
> > > + type: boolean
> > > +
> > > + adi,excitation-current-microamp:
> > > + description: |
> > > + This property controls the magnitude of the
> > > excitation current
> > > + applied to the diode. Depending on the number of
> > > conversions
> > > + cycles, this property will assume different
> > > predefined values on
> > > + each cycle. Just set the value of the first cycle
> > > (1l).
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [10, 20, 40, 80]
> > > +
> > > + adi,ideal-factor-value:
> > > + description: |
> > > + This property sets the diode ideality factor. The
> > > real value must
> > > + be multiplied by 1000000 to remove the fractional
> > > part. For more
> > > + information look at table 20 of the datasheet.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > +
> > > + "^rtd@.*":
> > > + type: object
> > > + description: |
> > > + Represents a rtd sensor which is connected to one of the
> > > device channels.
> > > +
> > > + properties:
> > > + reg:
> > > + minimum: 2
> > > +
> > > + adi,sensor-type:
> > > + description: |
> > > + Identifies the type of RTD connected to the device.
> > > + 10 - RTD PT-10
> > > + 11 - RTD PT-50
> > > + 12 - RTD PT-100
> > > + 13 - RTD PT-200
> > > + 14 - RTD PT-500
> > > + 15 - RTD PT-1000
> > > + 16 - RTD PT-1000 (0.00375)
> > > + 17 - RTD NI-120
> > > + 18 - RTD Custom
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 10
> > > + - maximum: 18
> > > +
> > > + adi,rsense-handle:
> > > + description: |
> > > + Phandle pointing to a rsense object associated with
> > > this RTD.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + adi,number-of-wires:
> > > + description: |
> > > + Identifies the number of wires used by the RTD.
> > > Setting this
> > > + property to 5 means 4 wires with Kelvin Rsense.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [2, 3, 4, 5]
> > > +
> > > + adi,rsense-share:
> > > + description: |
> > > + Boolean property which enables Rsense sharing, where
> > > one sense
> > > + resistor is used for multiple 2-, 3-, and/or 4-wire
> > > RTDs.
> > > + type: boolean
> > > +
> > > + adi,current-rotate:
> > > + description: |
> > > + Boolean property which enables excitation current
> > > rotation to
> > > + automatically remove parasitic thermocouple effects.
> > > Note that
> > > + this property is not allowed for 2- and 3-wire RTDs.
> > > + type: boolean
> > > +
> > > + adi,excitation-current-microamp:
> > > + description: |
> > > + This property controls the magnitude of the
> > > excitation current
> > > + applied to the RTD.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> >
> > You can drop the type here too.
>
> got it.
>
> > > + - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> > > +
> > > + adi,rtd-curve:
> > > + description: |
> > > + This property set the RTD curve used and the
> > > corresponding
> > > + Callendar-VanDusen constants. Look at table 30 of
> > > the datasheet.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 0
> > > + - maximum: 3
> > > +
> > > + adi,custom-sensor:
> > > + description: |
> > > + This is a table, where each entry should be a pair
> > > of
> > > + resistance(ohm)-temperature(K). The entries added
> > > here are in uohm
> > > + and uK. For more details values look at table 74 and
> > > 75.
> >
> > It's not great to make one property name have different meanings.
>
> Would you prefer to have something like "custom-rtd", "custom-
> thermoucouple" and so on? I would have to adapt the code but I don't
> think it would need to much of a change.
>
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > > array
> > > + minItems: 6
> > > + maxItems: 128
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > + - adi,rsense-handle
> > > +
> > > + dependencies:
> > > + adi,current-rotate: [ adi,rsense-share ]
> > > +
> > > + "^thermistor@.*":
> > > + type: object
> > > + description: |
> > > + Represents a thermistor sensor which is connected to one
> > > of the device
> > > + channels.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: |
> > > + Identifies the type of thermistor connected to the
> > > + device.
> > > + 19 - Thermistor 44004/44033 2.252kohm at 25°C
> > > + 20 - Thermistor 44005/44030 3kohm at 25°C
> > > + 21 - Thermistor 44007/44034 5kohm at 25°C
> > > + 22 - Thermistor 44006/44031 10kohm at 25°C
> > > + 23 - Thermistor 44008/44032 30kohm at 25°C
> > > + 24 - Thermistor YSI 400 2.252kohm at 25°C
> > > + 25 - Thermistor Spectrum 1003k 1kohm
> > > + 26 - Thermistor Custom Steinhart-Hart
> > > + 27 - Custom Thermistor
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - minimum: 19
> > > + - maximum: 27
> > > +
> > > + adi,rsense-handle:
> > > + description: |
> > > + Phandle pointing to a rsense object associated with
> > > this
> > > + thermistor.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + adi,single-ended:
> > > + description: |
> > > + Boolean property which set's the thermistor as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + adi,rsense-share:
> > > + description: |
> > > + Boolean property which enables Rsense sharing, where
> > > one sense
> > > + resistor is used for multiple thermistors. Note that
> > > this property
> > > + is ignored if adi,single-ended is set.
> > > + type: boolean
> > > +
> > > + adi,current-rotate:
> > > + description: |
> > > + Boolean property which enables excitation current
> > > rotation to
> > > + automatically remove parasitic thermocouple effects.
> > > + type: boolean
> > > +
> > > + adi,excitation-current-nanoamp:
> > > + description: |
> > > + This property controls the magnitude of the
> > > excitation current
> > > + applied to the thermistor. Value 0 set's the sensor
> > > in auto-range
> > > + mode.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [0, 250, 500, 1000, 5000, 10000, 25000,
> > > 50000, 100000,
> > > + 250000, 500000, 1000000]
> > > +
> > > + adi,custom-sensor:
> > > + description: |
> > > + This is a table, where each entry should be a pair
> > > of
> > > + resistance(ohm)-temperature(K). The entries added
> > > here are in uohm
> > > + and uK only for custom thermistors. For more details
> > > look at table
> > > + 78 and 79. Steinhart-Hart coefficients are also
> > > supported and can
> > > + be programmed into the device memory using this
> > > property. For
> > > + Steinhart sensors, this table has a constant size of
> > > 6 entries
> > > + (defining the coefficients) and the values are given
> > > in the raw
> > > + format. Look at table 82 for more information.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint64-
> > > array
> > > + minItems: 6
> > > + maxItems: 128
> > > +
>
> If I'm to replace this property as proposed before, would it make sense
> also to split this in custom-thermistor and custom-steinhart or just
> steinhart?
>
> > > + required:
> > > + - adi,sensor-type
> > > + - adi,rsense-handle
> > > +
> > > + dependencies:
> > > + adi,current-rotate: [ adi,rsense-share ]
> > > +
> > > + "^adc@.*":
> > > + type: object
> > > + description: Represents a channel which is being used as a
> > > direct adc.
> > > +
> > > + properties:
> > > + adi,sensor-type:
> > > + description: Identifies the sensor as a direct adc.
> > > + const: 30
> > > +
> > > + adi,single-ended:
> > > + description: Boolean property which set's the adc as
> > > single-ended.
> > > + type: boolean
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > +
> > > + "^rsense@.*":
> > > + type: object
> > > + description: |
> > > + Represents a rsense which is connected to one of the
> > > device channels.
> > > + Rsense are used by thermistors and RTD's.
> > > +
> > > + properties:
> > > + reg:
> > > + minimum: 2
> > > +
> > > + adi,sensor-type:
> > > + description: Identifies the sensor as a rsense.
> > > + const: 29
> > > +
> > > + adi,rsense-val-micro-ohms:
> > > + description: |
> > > + Sets the value of the sense resistor. Look at table
> > > 20 of the
> > > + datasheet for information.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint64
> >
> > -micro-ohms is already defined to be 32-bit.
>
> I do need a 64-bit variable here. Should I still remove the $ref or how
> can I proceed?
>
> > > +
> > > + required:
> > > + - adi,sensor-type
> > > + - adi, rsense-val
> >
> > spurious space.
>
> got it.
>
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - interrupts
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + spi {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + sensor_ltc2983: ltc2983@0 {
> > > + compatible = "adi,ltc2983";
> > > + reg = <0>;
> > > +
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + adi,temperature-celcius;
> > > + interrupts = <20 IRQ_TYPE_EDGE_RISING>;
> > > + interrupt-parent = <&gpio>;
> > > +
> > > + thermocouple@18 {
> > > + reg = <18>;
> > > + adi,sensor-type = <8>; //Type B
> > > + adi,sensor-oc-current-microamp = <10>;
> > > + adi,cold-junction-handle = <&diode5>;
> > > + };
> > > +
> > > + diode5: diode@5 {
> > > + reg = <5>;
> > > + adi,sensor-type = <28>;
> > > + };
> > > +
> > > + rsense2: rsense@2 {
> > > + reg = <2>;
> > > + adi,sensor-type = <29>;
> > > + adi,rsense-val-micro-ohms = /bits/ 64
> > > <1200000000>; //1.2Kohms
> > > + };
> > > +
> > > + rtd@14 {
> > > + reg = <14>;
> > > + adi,sensor-type = <15>; //PT1000
> > > + /*2-wire, internal gnd, no current
> > > rotation*/
> > > + adi,number-of-wires = <2>;
> > > + adi,rsense-share;
> > > + adi,excitation-current-microamp = <500>;
> > > + adi,rsense-handle = <&rsense2>;
> > > + };
> > > +
> > > + adc@10 {
> > > + reg = <10>;
> > > + adi,sensor-type = <30>;
> > > + adi,single-ended;
> > > + };
> > > +
> > > + thermistor@12 {
> > > + reg = <12>;
> > > + adi,sensor-type = <26>; //Steinhart
> > > + adi,rsense-handle = <&rsense2>;
> > > + adi,custom-sensor = /bits/ 64 <0x00F371EC
> > > 0x12345678
> > > + 0x2C0F8733 0x10018C66
> > > 0xA0FEACCD
> > > + 0x90021D99>; //6 entries
> > > + };
> > > +
> > > + thermocouple@20 {
> > > + reg = <20>;
> > > + adi,sensor-type = <9>; //custom
> > > thermocouple
> > > + adi,single-ended;
> > > + adi,custom-sensor = /bits/ 64
> > > + <(-50220000) 0
> > > + (-30200000) 99100000
> > > + (-5300000) 135400000
> > > + 0 273150000
> > > + 40200000 361200000
> > > + 55300000 522100000
> > > + 88300000 720300000
> > > + 132200000 811200000
> > > + 188700000 922500000
> > > + 460400000 1000000000>; //10
> > > pairs
> > > + };
> > > +
> > > + };
> > > + };
> > > +...
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 14a256e785ca..f747a9dc27f5 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -9497,6 +9497,7 @@ W:
> > > http://ez.analog.com/community/linux-device-drivers
> > > L: linux-iio@vger.kernel.org
> > > S: Supported
> > > F: drivers/iio/temperature/ltc2983.c
> > > +F: Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > 83.yaml
> > >
> > > LTC4261 HARDWARE MONITOR DRIVER
> > > M: Guenter Roeck <linux@roeck-us.net>
> > > --
> > > 2.23.0
> > >
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] iio: temperature: Add support for LTC2983
2019-10-04 13:55 [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Nuno Sá
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
@ 2019-10-06 10:37 ` Jonathan Cameron
2019-10-07 9:10 ` Sa, Nuno
2019-10-08 10:55 ` Sa, Nuno
2 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron @ 2019-10-06 10:37 UTC (permalink / raw)
To: Nuno Sá
Cc: linux-iio, devicetree, knaack.h, lars, pmeerw, robh+dt, mark.rutland
On Fri, 4 Oct 2019 15:55:18 +0200
Nuno Sá <nuno.sa@analog.com> wrote:
> The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
> Measurement System. It measures a wide variety of temperature sensors and
> digitally outputs the result, in °C or °F, with 0.1°C accuracy and
> 0.001°C resolution. It can measure the temperature of all standard
> thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire RTDs,
> thermistors and diodes.
>
> Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Two things inline that I'd missed before. Otherwise looks good.
Thanks,
Jonathan
> ---
> Changes in v2:
> * Added some needed blank lines (for readability);
> * Allocate iio_chan in the setup() function;
> * Rename reset to sleep;
> * Remove unneeded dev_dbg calls;
> * Remove unneeded line wrapping;
> * Remove unneeded comments;
> * Remove extend_names. Use the standard ABI;
> * Adapt the scales to report in millivolt and milli degrees;
> * Adapt the of_property readings to the renaming of the properties;
> * For custom thermistors, excitation-current cannot be set to Auto range.
>
> Changes in v3:
> * Use normal `devm_request_irq`;
> * Handle and decode the new devicetree properties for sensor configuration.
>
> MAINTAINERS | 7 +
> drivers/iio/temperature/Kconfig | 10 +
> drivers/iio/temperature/Makefile | 1 +
> drivers/iio/temperature/ltc2983.c | 1554 +++++++++++++++++++++++++++++
> 4 files changed, 1572 insertions(+)
> create mode 100644 drivers/iio/temperature/ltc2983.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0c03740b9fb..14a256e785ca 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9491,6 +9491,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> F: drivers/iio/dac/ltc1660.c
>
> +LTC2983 IIO TEMPERATURE DRIVER
> +M: Nuno Sá <nuno.sa@analog.com>
> +W: http://ez.analog.com/community/linux-device-drivers
> +L: linux-iio@vger.kernel.org
> +S: Supported
> +F: drivers/iio/temperature/ltc2983.c
> +
> LTC4261 HARDWARE MONITOR DRIVER
> M: Guenter Roeck <linux@roeck-us.net>
> L: linux-hwmon@vger.kernel.org
> diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
> index 737faa0901fe..04b5a67b593c 100644
> --- a/drivers/iio/temperature/Kconfig
> +++ b/drivers/iio/temperature/Kconfig
> @@ -4,6 +4,16 @@
> #
> menu "Temperature sensors"
>
> +config LTC2983
> + tristate "Analog Devices Multi-Sensor Digital Temperature Measurement System"
> + depends on SPI
Select REGMAP_SPI needed I think.
> + help
> + Say yes here to build support for the LTC2983 Multi-Sensor
> + high accuracy digital temperature measurement system.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called ltc2983.
> +
> config MAXIM_THERMOCOUPLE
> tristate "Maxim thermocouple sensors"
> depends on SPI
> diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
> index baca4776ca0d..d6b850b0cf63 100644
> --- a/drivers/iio/temperature/Makefile
> +++ b/drivers/iio/temperature/Makefile
> @@ -3,6 +3,7 @@
> # Makefile for industrial I/O temperature drivers
> #
>
> +obj-$(CONFIG_LTC2983) += ltc2983.o
> obj-$(CONFIG_HID_SENSOR_TEMP) += hid-sensor-temperature.o
> obj-$(CONFIG_MAXIM_THERMOCOUPLE) += maxim_thermocouple.o
> obj-$(CONFIG_MAX31856) += max31856.o
> diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
> new file mode 100644
> index 000000000000..f899c1d75f8a
> --- /dev/null
> +++ b/drivers/iio/temperature/ltc2983.c
> @@ -0,0 +1,1554 @@
...
> +static int ltc2983_chan_read(struct ltc2983_data *st,
> + const struct ltc2983_sensor *sensor, int *val)
> +{
> + u32 start_conversion = 0;
> + int ret;
> + unsigned long time;
> + __be32 temp;
> +
> + /*
> + * Do not allow channel readings if device is in sleep state.
> + * A read/write on the spi bus would bring the device prematurely
> + * out of sleep.
> + */
> + if (st->sleep)
> + return -EPERM;
> +
> + start_conversion = LTC2983_STATUS_START(true);
> + start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
> + dev_dbg(&st->spi->dev, "Start conversion on chan:%d, status:%02X\n",
> + sensor->chan, start_conversion);
> + /* start conversion */
> + ret = regmap_write(st->regmap, LTC2983_STATUS_REG, start_conversion);
> + if (ret)
> + return ret;
> +
> + reinit_completion(&st->completion);
> + /*
> + * wait for conversion to complete.
> + * 300 ms should be more than enough to complete the conversion.
> + * Depending on the sensor configuration, there are 2/3 conversions
> + * cycles of 82ms.
> + */
> + time = wait_for_completion_timeout(&st->completion,
> + msecs_to_jiffies(300));
> + if (!time) {
> + dev_warn(&st->spi->dev, "Conversion timed out\n");
> + return -ETIMEDOUT;
> + }
> +
> + /* read the converted data */
> + ret = regmap_bulk_read(st->regmap, LTC2983_CHAN_RES_ADDR(sensor->chan),
> + &temp, sizeof(temp));
I'd missed this before. regmap_bulk_read can directly use the supplied buffer
for dma. Hence it needs to be dma safe. That means you have to have it
in it's own cacheline. There is no way of enforcing that on the stack so
either allocate it locally from the heap, or put it at the end of the
data structure and mark it __cacheline_aligned (we make sure those structures
are also cacheline aligned and on the heap specifically to allow us to do that
trick).
> + if (ret)
> + return ret;
> +
> + *val = __be32_to_cpu(temp);
> +
> + if (!(LTC2983_RES_VALID_MASK & *val)) {
> + dev_err(&st->spi->dev, "Invalid conversion detected\n");
> + return -EIO;
> + }
> +
> + ret = sensor->fault_handler(st, *val);
> + if (ret)
> + return ret;
> +
> + *val = sign_extend32((*val) & LTC2983_DATA_MASK, LTC2983_DATA_SIGN_BIT);
> + return 0;
> +}
> +
...
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 1/2] iio: temperature: Add support for LTC2983
2019-10-06 10:37 ` [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Jonathan Cameron
@ 2019-10-07 9:10 ` Sa, Nuno
2019-10-07 11:52 ` Jonathan Cameron
0 siblings, 1 reply; 15+ messages in thread
From: Sa, Nuno @ 2019-10-07 9:10 UTC (permalink / raw)
To: jic23
Cc: robh+dt, mark.rutland, devicetree, knaack.h, linux-iio, pmeerw, lars
On Sun, 2019-10-06 at 11:37 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 4 Oct 2019 15:55:18 +0200
> Nuno Sá <nuno.sa@analog.com> wrote:
>
> > The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
> > Measurement System. It measures a wide variety of temperature
> > sensors and
> > digitally outputs the result, in °C or °F, with 0.1°C accuracy and
> > 0.001°C resolution. It can measure the temperature of all standard
> > thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire RTDs,
> > thermistors and diodes.
> >
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
>
> Two things inline that I'd missed before. Otherwise looks good.
>
> Thanks,
>
> Jonathan
>
> > ---
> > Changes in v2:
> > * Added some needed blank lines (for readability);
> > * Allocate iio_chan in the setup() function;
> > * Rename reset to sleep;
> > * Remove unneeded dev_dbg calls;
> > * Remove unneeded line wrapping;
> > * Remove unneeded comments;
> > * Remove extend_names. Use the standard ABI;
> > * Adapt the scales to report in millivolt and milli degrees;
> > * Adapt the of_property readings to the renaming of the
> > properties;
> > * For custom thermistors, excitation-current cannot be set to Auto
> > range.
> >
> > Changes in v3:
> > * Use normal `devm_request_irq`;
> > * Handle and decode the new devicetree properties for sensor
> > configuration.
> >
> > MAINTAINERS | 7 +
> > drivers/iio/temperature/Kconfig | 10 +
> > drivers/iio/temperature/Makefile | 1 +
> > drivers/iio/temperature/ltc2983.c | 1554
> > +++++++++++++++++++++++++++++
> > 4 files changed, 1572 insertions(+)
> > create mode 100644 drivers/iio/temperature/ltc2983.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index f0c03740b9fb..14a256e785ca 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9491,6 +9491,13 @@ S: Maintained
> > F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > F: drivers/iio/dac/ltc1660.c
> >
> > +LTC2983 IIO TEMPERATURE DRIVER
> > +M: Nuno Sá <nuno.sa@analog.com>
> > +W: http://ez.analog.com/community/linux-device-drivers
> > +L: linux-iio@vger.kernel.org
> > +S: Supported
> > +F: drivers/iio/temperature/ltc2983.c
> > +
> > LTC4261 HARDWARE MONITOR DRIVER
> > M: Guenter Roeck <linux@roeck-us.net>
> > L: linux-hwmon@vger.kernel.org
> > diff --git a/drivers/iio/temperature/Kconfig
> > b/drivers/iio/temperature/Kconfig
> > index 737faa0901fe..04b5a67b593c 100644
> > --- a/drivers/iio/temperature/Kconfig
> > +++ b/drivers/iio/temperature/Kconfig
> > @@ -4,6 +4,16 @@
> > #
> > menu "Temperature sensors"
> >
> > +config LTC2983
> > + tristate "Analog Devices Multi-Sensor Digital Temperature
> > Measurement System"
> > + depends on SPI
>
> Select REGMAP_SPI needed I think.
ack.
> > + help
> > + Say yes here to build support for the LTC2983 Multi-Sensor
> > + high accuracy digital temperature measurement system.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called ltc2983.
> > +
> > config MAXIM_THERMOCOUPLE
> > tristate "Maxim thermocouple sensors"
> > depends on SPI
> > diff --git a/drivers/iio/temperature/Makefile
> > b/drivers/iio/temperature/Makefile
> > index baca4776ca0d..d6b850b0cf63 100644
> > --- a/drivers/iio/temperature/Makefile
> > +++ b/drivers/iio/temperature/Makefile
> > @@ -3,6 +3,7 @@
> > # Makefile for industrial I/O temperature drivers
> > #
> >
> > +obj-$(CONFIG_LTC2983) += ltc2983.o
> > obj-$(CONFIG_HID_SENSOR_TEMP) += hid-sensor-temperature.o
> > obj-$(CONFIG_MAXIM_THERMOCOUPLE) += maxim_thermocouple.o
> > obj-$(CONFIG_MAX31856) += max31856.o
> > diff --git a/drivers/iio/temperature/ltc2983.c
> > b/drivers/iio/temperature/ltc2983.c
> > new file mode 100644
> > index 000000000000..f899c1d75f8a
> > --- /dev/null
> > +++ b/drivers/iio/temperature/ltc2983.c
> > @@ -0,0 +1,1554 @@
> ...
>
> > +static int ltc2983_chan_read(struct ltc2983_data *st,
> > + const struct ltc2983_sensor *sensor, int *val)
> > +{
> > + u32 start_conversion = 0;
> > + int ret;
> > + unsigned long time;
> > + __be32 temp;
> > +
> > + /*
> > + * Do not allow channel readings if device is in sleep state.
> > + * A read/write on the spi bus would bring the device
> > prematurely
> > + * out of sleep.
> > + */
> > + if (st->sleep)
> > + return -EPERM;
> > +
> > + start_conversion = LTC2983_STATUS_START(true);
> > + start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
> > + dev_dbg(&st->spi->dev, "Start conversion on chan:%d,
> > status:%02X\n",
> > + sensor->chan, start_conversion);
> > + /* start conversion */
> > + ret = regmap_write(st->regmap, LTC2983_STATUS_REG,
> > start_conversion);
> > + if (ret)
> > + return ret;
> > +
> > + reinit_completion(&st->completion);
> > + /*
> > + * wait for conversion to complete.
> > + * 300 ms should be more than enough to complete the
> > conversion.
> > + * Depending on the sensor configuration, there are 2/3
> > conversions
> > + * cycles of 82ms.
> > + */
> > + time = wait_for_completion_timeout(&st->completion,
> > + msecs_to_jiffies(300));
> > + if (!time) {
> > + dev_warn(&st->spi->dev, "Conversion timed out\n");
> > + return -ETIMEDOUT;
> > + }
> > +
> > + /* read the converted data */
> > + ret = regmap_bulk_read(st->regmap,
> > LTC2983_CHAN_RES_ADDR(sensor->chan),
> > + &temp, sizeof(temp));
>
> I'd missed this before. regmap_bulk_read can directly use the
> supplied buffer
> for dma. Hence it needs to be dma safe. That means you have to have
> it
> in it's own cacheline. There is no way of enforcing that on the
> stack so
> either allocate it locally from the heap, or put it at the end of the
> data structure and mark it __cacheline_aligned (we make sure those
> structures
> are also cacheline aligned and on the heap specifically to allow us
> to do that
> trick).
Just for my understanding. I do see the the need of using
__cacheline_aligned on the struct parameter we want to align. I was now
trying to understand your comment on parenthesis. Why do we need that
trick? Wouldn't be sufficient to have the struct element marked with
__cacheline_aligned?
>
> > + if (ret)
> > + return ret;
> > +
> > + *val = __be32_to_cpu(temp);
> > +
> > + if (!(LTC2983_RES_VALID_MASK & *val)) {
> > + dev_err(&st->spi->dev, "Invalid conversion
> > detected\n");
> > + return -EIO;
> > + }
> > +
> > + ret = sensor->fault_handler(st, *val);
> > + if (ret)
> > + return ret;
> > +
> > + *val = sign_extend32((*val) & LTC2983_DATA_MASK,
> > LTC2983_DATA_SIGN_BIT);
> > + return 0;
> > +}
> > +
> ...
Thanks!
Nuno Sá
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 1/2] iio: temperature: Add support for LTC2983
2019-10-07 9:10 ` Sa, Nuno
@ 2019-10-07 11:52 ` Jonathan Cameron
2019-10-07 12:33 ` Sa, Nuno
0 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron @ 2019-10-07 11:52 UTC (permalink / raw)
To: Sa, Nuno
Cc: jic23, robh+dt, mark.rutland, devicetree, knaack.h, linux-iio,
pmeerw, lars
On Mon, 7 Oct 2019 09:10:06 +0000
"Sa, Nuno" <Nuno.Sa@analog.com> wrote:
> On Sun, 2019-10-06 at 11:37 +0100, Jonathan Cameron wrote:
> > [External]
> >
> > On Fri, 4 Oct 2019 15:55:18 +0200
> > Nuno Sá <nuno.sa@analog.com> wrote:
> >
> > > The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
> > > Measurement System. It measures a wide variety of temperature
> > > sensors and
> > > digitally outputs the result, in °C or °F, with 0.1°C accuracy and
> > > 0.001°C resolution. It can measure the temperature of all standard
> > > thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire RTDs,
> > > thermistors and diodes.
> > >
> > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> >
> > Two things inline that I'd missed before. Otherwise looks good.
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > Changes in v2:
> > > * Added some needed blank lines (for readability);
> > > * Allocate iio_chan in the setup() function;
> > > * Rename reset to sleep;
> > > * Remove unneeded dev_dbg calls;
> > > * Remove unneeded line wrapping;
> > > * Remove unneeded comments;
> > > * Remove extend_names. Use the standard ABI;
> > > * Adapt the scales to report in millivolt and milli degrees;
> > > * Adapt the of_property readings to the renaming of the
> > > properties;
> > > * For custom thermistors, excitation-current cannot be set to Auto
> > > range.
> > >
> > > Changes in v3:
> > > * Use normal `devm_request_irq`;
> > > * Handle and decode the new devicetree properties for sensor
> > > configuration.
> > >
> > > MAINTAINERS | 7 +
> > > drivers/iio/temperature/Kconfig | 10 +
> > > drivers/iio/temperature/Makefile | 1 +
> > > drivers/iio/temperature/ltc2983.c | 1554
> > > +++++++++++++++++++++++++++++
> > > 4 files changed, 1572 insertions(+)
> > > create mode 100644 drivers/iio/temperature/ltc2983.c
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index f0c03740b9fb..14a256e785ca 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -9491,6 +9491,13 @@ S: Maintained
> > > F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > > F: drivers/iio/dac/ltc1660.c
> > >
> > > +LTC2983 IIO TEMPERATURE DRIVER
> > > +M: Nuno Sá <nuno.sa@analog.com>
> > > +W: http://ez.analog.com/community/linux-device-drivers
> > > +L: linux-iio@vger.kernel.org
> > > +S: Supported
> > > +F: drivers/iio/temperature/ltc2983.c
> > > +
> > > LTC4261 HARDWARE MONITOR DRIVER
> > > M: Guenter Roeck <linux@roeck-us.net>
> > > L: linux-hwmon@vger.kernel.org
> > > diff --git a/drivers/iio/temperature/Kconfig
> > > b/drivers/iio/temperature/Kconfig
> > > index 737faa0901fe..04b5a67b593c 100644
> > > --- a/drivers/iio/temperature/Kconfig
> > > +++ b/drivers/iio/temperature/Kconfig
> > > @@ -4,6 +4,16 @@
> > > #
> > > menu "Temperature sensors"
> > >
> > > +config LTC2983
> > > + tristate "Analog Devices Multi-Sensor Digital Temperature
> > > Measurement System"
> > > + depends on SPI
> >
> > Select REGMAP_SPI needed I think.
>
> ack.
>
> > > + help
> > > + Say yes here to build support for the LTC2983 Multi-Sensor
> > > + high accuracy digital temperature measurement system.
> > > +
> > > + To compile this driver as a module, choose M here: the module
> > > + will be called ltc2983.
> > > +
> > > config MAXIM_THERMOCOUPLE
> > > tristate "Maxim thermocouple sensors"
> > > depends on SPI
> > > diff --git a/drivers/iio/temperature/Makefile
> > > b/drivers/iio/temperature/Makefile
> > > index baca4776ca0d..d6b850b0cf63 100644
> > > --- a/drivers/iio/temperature/Makefile
> > > +++ b/drivers/iio/temperature/Makefile
> > > @@ -3,6 +3,7 @@
> > > # Makefile for industrial I/O temperature drivers
> > > #
> > >
> > > +obj-$(CONFIG_LTC2983) += ltc2983.o
> > > obj-$(CONFIG_HID_SENSOR_TEMP) += hid-sensor-temperature.o
> > > obj-$(CONFIG_MAXIM_THERMOCOUPLE) += maxim_thermocouple.o
> > > obj-$(CONFIG_MAX31856) += max31856.o
> > > diff --git a/drivers/iio/temperature/ltc2983.c
> > > b/drivers/iio/temperature/ltc2983.c
> > > new file mode 100644
> > > index 000000000000..f899c1d75f8a
> > > --- /dev/null
> > > +++ b/drivers/iio/temperature/ltc2983.c
> > > @@ -0,0 +1,1554 @@
> > ...
> >
> > > +static int ltc2983_chan_read(struct ltc2983_data *st,
> > > + const struct ltc2983_sensor *sensor, int *val)
> > > +{
> > > + u32 start_conversion = 0;
> > > + int ret;
> > > + unsigned long time;
> > > + __be32 temp;
> > > +
> > > + /*
> > > + * Do not allow channel readings if device is in sleep state.
> > > + * A read/write on the spi bus would bring the device
> > > prematurely
> > > + * out of sleep.
> > > + */
> > > + if (st->sleep)
> > > + return -EPERM;
> > > +
> > > + start_conversion = LTC2983_STATUS_START(true);
> > > + start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
> > > + dev_dbg(&st->spi->dev, "Start conversion on chan:%d,
> > > status:%02X\n",
> > > + sensor->chan, start_conversion);
> > > + /* start conversion */
> > > + ret = regmap_write(st->regmap, LTC2983_STATUS_REG,
> > > start_conversion);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + reinit_completion(&st->completion);
> > > + /*
> > > + * wait for conversion to complete.
> > > + * 300 ms should be more than enough to complete the
> > > conversion.
> > > + * Depending on the sensor configuration, there are 2/3
> > > conversions
> > > + * cycles of 82ms.
> > > + */
> > > + time = wait_for_completion_timeout(&st->completion,
> > > + msecs_to_jiffies(300));
> > > + if (!time) {
> > > + dev_warn(&st->spi->dev, "Conversion timed out\n");
> > > + return -ETIMEDOUT;
> > > + }
> > > +
> > > + /* read the converted data */
> > > + ret = regmap_bulk_read(st->regmap,
> > > LTC2983_CHAN_RES_ADDR(sensor->chan),
> > > + &temp, sizeof(temp));
> >
> > I'd missed this before. regmap_bulk_read can directly use the
> > supplied buffer
> > for dma. Hence it needs to be dma safe. That means you have to have
> > it
> > in it's own cacheline. There is no way of enforcing that on the
> > stack so
> > either allocate it locally from the heap, or put it at the end of the
> > data structure and mark it __cacheline_aligned (we make sure those
> > structures
> > are also cacheline aligned and on the heap specifically to allow us
> > to do that
> > trick).
>
> Just for my understanding. I do see the the need of using
> __cacheline_aligned on the struct parameter we want to align. I was now
> trying to understand your comment on parenthesis. Why do we need that
> trick? Wouldn't be sufficient to have the struct element marked with
> __cacheline_aligned?
>
Ah. That is down to what __cacheline_aligned actually does and
how we create the region accessed by iio_priv()
If we have a stand alone structure allocated with kmalloc with an
element marked __cacheline_aligned it will indeed have the correct
alignment.
iio_priv is done by increasing the size of the memory allocation
done in iio_device_alloc, the iio_priv() pointer then gives us
the address of a region beyond the end of the iio_dev structure.
That region has to also be cacheline aligned so that when we find
the location of the __cacheline_aligned element of the structure
we are putting there (basically an offset from iio_priv) it will
also have the right alignment.
The compiler has no way of knowing we are doing this stuff so it
just adds padding to the private structure on the assumption
the structure itself is aligned.
Jonathan
> >
> > > + if (ret)
> > > + return ret;
> > > +
> > > + *val = __be32_to_cpu(temp);
> > > +
> > > + if (!(LTC2983_RES_VALID_MASK & *val)) {
> > > + dev_err(&st->spi->dev, "Invalid conversion
> > > detected\n");
> > > + return -EIO;
> > > + }
> > > +
> > > + ret = sensor->fault_handler(st, *val);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + *val = sign_extend32((*val) & LTC2983_DATA_MASK,
> > > LTC2983_DATA_SIGN_BIT);
> > > + return 0;
> > > +}
> > > +
> > ...
>
> Thanks!
> Nuno Sá
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH v3 1/2] iio: temperature: Add support for LTC2983
2019-10-07 11:52 ` Jonathan Cameron
@ 2019-10-07 12:33 ` Sa, Nuno
0 siblings, 0 replies; 15+ messages in thread
From: Sa, Nuno @ 2019-10-07 12:33 UTC (permalink / raw)
To: jonathan.cameron
Cc: linux-iio, mark.rutland, devicetree, lars, knaack.h, pmeerw,
robh+dt, jic23
On Mon, 2019-10-07 at 12:52 +0100, Jonathan Cameron wrote:
>
> On Mon, 7 Oct 2019 09:10:06 +0000
> "Sa, Nuno" <Nuno.Sa@analog.com> wrote:
>
> > On Sun, 2019-10-06 at 11:37 +0100, Jonathan Cameron wrote:
> > > [External]
> > >
> > > On Fri, 4 Oct 2019 15:55:18 +0200
> > > Nuno Sá <nuno.sa@analog.com> wrote:
> > >
> > > > The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
> > > > Measurement System. It measures a wide variety of temperature
> > > > sensors and
> > > > digitally outputs the result, in °C or °F, with 0.1°C accuracy
> > > > and
> > > > 0.001°C resolution. It can measure the temperature of all
> > > > standard
> > > > thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire
> > > > RTDs,
> > > > thermistors and diodes.
> > > >
> > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > >
> > > Two things inline that I'd missed before. Otherwise looks good.
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > > > ---
> > > > Changes in v2:
> > > > * Added some needed blank lines (for readability);
> > > > * Allocate iio_chan in the setup() function;
> > > > * Rename reset to sleep;
> > > > * Remove unneeded dev_dbg calls;
> > > > * Remove unneeded line wrapping;
> > > > * Remove unneeded comments;
> > > > * Remove extend_names. Use the standard ABI;
> > > > * Adapt the scales to report in millivolt and milli degrees;
> > > > * Adapt the of_property readings to the renaming of the
> > > > properties;
> > > > * For custom thermistors, excitation-current cannot be set to
> > > > Auto
> > > > range.
> > > >
> > > > Changes in v3:
> > > > * Use normal `devm_request_irq`;
> > > > * Handle and decode the new devicetree properties for sensor
> > > > configuration.
> > > >
> > > > MAINTAINERS | 7 +
> > > > drivers/iio/temperature/Kconfig | 10 +
> > > > drivers/iio/temperature/Makefile | 1 +
> > > > drivers/iio/temperature/ltc2983.c | 1554
> > > > +++++++++++++++++++++++++++++
> > > > 4 files changed, 1572 insertions(+)
> > > > create mode 100644 drivers/iio/temperature/ltc2983.c
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index f0c03740b9fb..14a256e785ca 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -9491,6 +9491,13 @@ S: Maintained
> > > > F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> > > > F: drivers/iio/dac/ltc1660.c
> > > >
> > > > +LTC2983 IIO TEMPERATURE DRIVER
> > > > +M: Nuno Sá <nuno.sa@analog.com>
> > > > +W: http://ez.analog.com/community/linux-device-drivers
> > > > +L: linux-iio@vger.kernel.org
> > > > +S: Supported
> > > > +F: drivers/iio/temperature/ltc2983.c
> > > > +
> > > > LTC4261 HARDWARE MONITOR DRIVER
> > > > M: Guenter Roeck <linux@roeck-us.net>
> > > > L: linux-hwmon@vger.kernel.org
> > > > diff --git a/drivers/iio/temperature/Kconfig
> > > > b/drivers/iio/temperature/Kconfig
> > > > index 737faa0901fe..04b5a67b593c 100644
> > > > --- a/drivers/iio/temperature/Kconfig
> > > > +++ b/drivers/iio/temperature/Kconfig
> > > > @@ -4,6 +4,16 @@
> > > > #
> > > > menu "Temperature sensors"
> > > >
> > > > +config LTC2983
> > > > + tristate "Analog Devices Multi-Sensor Digital
> > > > Temperature
> > > > Measurement System"
> > > > + depends on SPI
> > >
> > > Select REGMAP_SPI needed I think.
> >
> > ack.
> >
> > > > + help
> > > > + Say yes here to build support for the LTC2983 Multi-
> > > > Sensor
> > > > + high accuracy digital temperature measurement system.
> > > > +
> > > > + To compile this driver as a module, choose M here:
> > > > the module
> > > > + will be called ltc2983.
> > > > +
> > > > config MAXIM_THERMOCOUPLE
> > > > tristate "Maxim thermocouple sensors"
> > > > depends on SPI
> > > > diff --git a/drivers/iio/temperature/Makefile
> > > > b/drivers/iio/temperature/Makefile
> > > > index baca4776ca0d..d6b850b0cf63 100644
> > > > --- a/drivers/iio/temperature/Makefile
> > > > +++ b/drivers/iio/temperature/Makefile
> > > > @@ -3,6 +3,7 @@
> > > > # Makefile for industrial I/O temperature drivers
> > > > #
> > > >
> > > > +obj-$(CONFIG_LTC2983) += ltc2983.o
> > > > obj-$(CONFIG_HID_SENSOR_TEMP) += hid-sensor-temperature.o
> > > > obj-$(CONFIG_MAXIM_THERMOCOUPLE) += maxim_thermocouple.o
> > > > obj-$(CONFIG_MAX31856) += max31856.o
> > > > diff --git a/drivers/iio/temperature/ltc2983.c
> > > > b/drivers/iio/temperature/ltc2983.c
> > > > new file mode 100644
> > > > index 000000000000..f899c1d75f8a
> > > > --- /dev/null
> > > > +++ b/drivers/iio/temperature/ltc2983.c
> > > > @@ -0,0 +1,1554 @@
> > > ...
> > >
> > > > +static int ltc2983_chan_read(struct ltc2983_data *st,
> > > > + const struct ltc2983_sensor *sensor,
> > > > int *val)
> > > > +{
> > > > + u32 start_conversion = 0;
> > > > + int ret;
> > > > + unsigned long time;
> > > > + __be32 temp;
> > > > +
> > > > + /*
> > > > + * Do not allow channel readings if device is in sleep
> > > > state.
> > > > + * A read/write on the spi bus would bring the device
> > > > prematurely
> > > > + * out of sleep.
> > > > + */
> > > > + if (st->sleep)
> > > > + return -EPERM;
> > > > +
> > > > + start_conversion = LTC2983_STATUS_START(true);
> > > > + start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor-
> > > > >chan);
> > > > + dev_dbg(&st->spi->dev, "Start conversion on chan:%d,
> > > > status:%02X\n",
> > > > + sensor->chan, start_conversion);
> > > > + /* start conversion */
> > > > + ret = regmap_write(st->regmap, LTC2983_STATUS_REG,
> > > > start_conversion);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + reinit_completion(&st->completion);
> > > > + /*
> > > > + * wait for conversion to complete.
> > > > + * 300 ms should be more than enough to complete the
> > > > conversion.
> > > > + * Depending on the sensor configuration, there are 2/3
> > > > conversions
> > > > + * cycles of 82ms.
> > > > + */
> > > > + time = wait_for_completion_timeout(&st->completion,
> > > > + msecs_to_jiffies(300
> > > > ));
> > > > + if (!time) {
> > > > + dev_warn(&st->spi->dev, "Conversion timed
> > > > out\n");
> > > > + return -ETIMEDOUT;
> > > > + }
> > > > +
> > > > + /* read the converted data */
> > > > + ret = regmap_bulk_read(st->regmap,
> > > > LTC2983_CHAN_RES_ADDR(sensor->chan),
> > > > + &temp, sizeof(temp));
> > >
> > > I'd missed this before. regmap_bulk_read can directly use the
> > > supplied buffer
> > > for dma. Hence it needs to be dma safe. That means you have to
> > > have
> > > it
> > > in it's own cacheline. There is no way of enforcing that on the
> > > stack so
> > > either allocate it locally from the heap, or put it at the end of
> > > the
> > > data structure and mark it __cacheline_aligned (we make sure
> > > those
> > > structures
> > > are also cacheline aligned and on the heap specifically to allow
> > > us
> > > to do that
> > > trick).
> >
> > Just for my understanding. I do see the the need of using
> > __cacheline_aligned on the struct parameter we want to align. I was
> > now
> > trying to understand your comment on parenthesis. Why do we need
> > that
> > trick? Wouldn't be sufficient to have the struct element marked
> > with
> > __cacheline_aligned?
> >
>
> Ah. That is down to what __cacheline_aligned actually does and
> how we create the region accessed by iio_priv()
>
> If we have a stand alone structure allocated with kmalloc with an
> element marked __cacheline_aligned it will indeed have the correct
> alignment.
>
> iio_priv is done by increasing the size of the memory allocation
> done in iio_device_alloc, the iio_priv() pointer then gives us
> the address of a region beyond the end of the iio_dev structure.
Got it.
> That region has to also be cacheline aligned so that when we find
> the location of the __cacheline_aligned element of the structure
> we are putting there (basically an offset from iio_priv) it will
> also have the right alignment.
Understood. Then, the only thing I'm still wondering is that we need to
have the guarantee that kmalloc also returns a pointer which is at
least __cacheline_aligned for our iio_dev struct so that, our private
struct has the correct alignment (and thus the element). Is this
correct?
> The compiler has no way of knowing we are doing this stuff so it
> just adds padding to the private structure on the assumption
> the structure itself is aligned.
>
> Jonathan
>
>
Thanks for your help and explanation!
Nuno Sá
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] iio: temperature: Add support for LTC2983
2019-10-04 13:55 [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Nuno Sá
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
2019-10-06 10:37 ` [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Jonathan Cameron
@ 2019-10-08 10:55 ` Sa, Nuno
2 siblings, 0 replies; 15+ messages in thread
From: Sa, Nuno @ 2019-10-08 10:55 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: jic23, mark.rutland, knaack.h, lars, pmeerw, robh+dt
Ho Jonathan,
Something that came up in another device review and I'm doing the same
mistake here.
On Fri, 2019-10-04 at 15:55 +0200, Nuno Sá wrote:
>
> The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
> Measurement System. It measures a wide variety of temperature sensors
> and
> digitally outputs the result, in °C or °F, with 0.1°C accuracy and
> 0.001°C resolution. It can measure the temperature of all standard
> thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire RTDs,
> thermistors and diodes.
>
> Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> ---
> Changes in v2:
> * Added some needed blank lines (for readability);
> * Allocate iio_chan in the setup() function;
> * Rename reset to sleep;
> * Remove unneeded dev_dbg calls;
> * Remove unneeded line wrapping;
> * Remove unneeded comments;
> * Remove extend_names. Use the standard ABI;
> * Adapt the scales to report in millivolt and milli degrees;
> * Adapt the of_property readings to the renaming of the properties;
> * For custom thermistors, excitation-current cannot be set to Auto
> range.
>
> Changes in v3:
> * Use normal `devm_request_irq`;
> * Handle and decode the new devicetree properties for sensor
> configuration.
>
> MAINTAINERS | 7 +
> drivers/iio/temperature/Kconfig | 10 +
> drivers/iio/temperature/Makefile | 1 +
> drivers/iio/temperature/ltc2983.c | 1554
> +++++++++++++++++++++++++++++
> 4 files changed, 1572 insertions(+)
> create mode 100644 drivers/iio/temperature/ltc2983.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0c03740b9fb..14a256e785ca 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9491,6 +9491,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/dac/ltc1660.txt
> F: drivers/iio/dac/ltc1660.c
>
> +LTC2983 IIO TEMPERATURE DRIVER
> +M: Nuno Sá <nuno.sa@analog.com>
> +W: http://ez.analog.com/community/linux-device-drivers
> +L: linux-iio@vger.kernel.org
> +S: Supported
> +F: drivers/iio/temperature/ltc2983.c
> +
> LTC4261 HARDWARE MONITOR DRIVER
> M: Guenter Roeck <linux@roeck-us.net>
> L: linux-hwmon@vger.kernel.org
> diff --git a/drivers/iio/temperature/Kconfig
> b/drivers/iio/temperature/Kconfig
> index 737faa0901fe..04b5a67b593c 100644
> --- a/drivers/iio/temperature/Kconfig
> +++ b/drivers/iio/temperature/Kconfig
> @@ -4,6 +4,16 @@
> #
> menu "Temperature sensors"
>
> +config LTC2983
> + tristate "Analog Devices Multi-Sensor Digital Temperature
> Measurement System"
> + depends on SPI
> + help
> + Say yes here to build support for the LTC2983 Multi-Sensor
> + high accuracy digital temperature measurement system.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called ltc2983.
> +
> config MAXIM_THERMOCOUPLE
> tristate "Maxim thermocouple sensors"
> depends on SPI
> diff --git a/drivers/iio/temperature/Makefile
> b/drivers/iio/temperature/Makefile
> index baca4776ca0d..d6b850b0cf63 100644
> --- a/drivers/iio/temperature/Makefile
> +++ b/drivers/iio/temperature/Makefile
> @@ -3,6 +3,7 @@
> # Makefile for industrial I/O temperature drivers
> #
>
> +obj-$(CONFIG_LTC2983) += ltc2983.o
> obj-$(CONFIG_HID_SENSOR_TEMP) += hid-sensor-temperature.o
> obj-$(CONFIG_MAXIM_THERMOCOUPLE) += maxim_thermocouple.o
> obj-$(CONFIG_MAX31856) += max31856.o
> diff --git a/drivers/iio/temperature/ltc2983.c
> b/drivers/iio/temperature/ltc2983.c
> new file mode 100644
> index 000000000000..f899c1d75f8a
> --- /dev/null
> +++ b/drivers/iio/temperature/ltc2983.c
> @@ -0,0 +1,1554 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Analog Devices LTC2983 Multi-Sensor Digital Temperature
> Measurement System
> + * driver
> + *
> + * Copyright 2019 Analog Devices Inc.
> + */
> +#include <linux/bitfield.h>
> +#include <linux/completion.h>
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/iio/iio.h>
> +#include <linux/interrupt.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/regmap.h>
> +#include <linux/spi/spi.h>
> +
> +/* register map */
> +#define LTC2983_STATUS_REG 0x0000
> +#define LTC2983_TEMP_RES_START_REG 0x0010
> +#define LTC2983_TEMP_RES_END_REG 0x005F
> +#define LTC2983_GLOBAL_CONFIG_REG 0x00F0
> +#define LTC2983_MULT_CHANNEL_START_REG 0x00F4
> +#define LTC2983_MULT_CHANNEL_END_REG 0x00F7
> +#define LTC2983_MUX_CONFIG_REG 0x00FF
> +#define LTC2983_CHAN_ASSIGN_START_REG 0x0200
> +#define LTC2983_CHAN_ASSIGN_END_REG 0x024F
> +#define LTC2983_CUST_SENS_TBL_START_REG 0x0250
> +#define LTC2983_CUST_SENS_TBL_END_REG 0x03CF
> +
> +#define LTC2983_DIFFERENTIAL_CHAN_MIN 2
> +#define LTC2983_MAX_CHANNELS_NR 20
> +#define LTC2983_MIN_CHANNELS_NR 1
> +#define LTC2983_SLEEP 0x97
> +#define LTC2983_CUSTOM_STEINHART_SIZE 24
> +#define LTC2983_CUSTOM_SENSOR_ENTRY_SZ 6
> +#define LTC2983_CUSTOM_STEINHART_ENTRY_SZ 4
> +
> +#define LTC2983_CHAN_START_ADDR(chan) \
> + (((chan - 1) * 4) +
> LTC2983_CHAN_ASSIGN_START_REG)
> +#define LTC2983_CHAN_RES_ADDR(chan) \
> + (((chan - 1) * 4) + LTC2983_TEMP_RES_START_REG)
> +#define LTC2983_THERMOCOUPLE_DIFF_MASK BIT(3)
> +#define LTC2983_THERMOCOUPLE_SGL(x) \
> + FIELD_PREP(LTC2983_THERMOCOUPLE_DIFF_MA
> SK, x)
> +#define LTC2983_THERMOCOUPLE_OC_CURR_MASK GENMASK(1, 0)
> +#define LTC2983_THERMOCOUPLE_OC_CURR(x) \
> + FIELD_PREP(LTC2983_THERMOCOUPLE_OC_CURR
> _MASK, x)
> +#define LTC2983_THERMOCOUPLE_OC_CHECK_MASK BIT(2)
> +#define LTC2983_THERMOCOUPLE_OC_CHECK(x) \
> + FIELD_PREP(LTC2983_THERMOCOUPLE_OC_CHECK_MASK,
> x)
> +
> +#define LTC2983_THERMISTOR_DIFF_MASK BIT(2)
> +#define LTC2983_THERMISTOR_SGL(x) \
> + FIELD_PREP(LTC2983_THERMISTOR_DIFF_MASK
> , x)
> +#define LTC2983_THERMISTOR_R_SHARE_MASK BIT(1)
> +#define LTC2983_THERMISTOR_R_SHARE(x) \
> + FIELD_PREP(LTC2983_THERMISTOR_R_SHARE_M
> ASK, x)
> +#define LTC2983_THERMISTOR_C_ROTATE_MASK BIT(0)
> +#define LTC2983_THERMISTOR_C_ROTATE(x) \
> + FIELD_PREP(LTC2983_THERMISTOR_C_ROTATE_
> MASK, x)
> +
> +#define LTC2983_DIODE_DIFF_MASK BIT(2)
> +#define LTC2983_DIODE_SGL(x) \
> + FIELD_PREP(LTC2983_DIODE_DIFF_MASK, x)
> +#define LTC2983_DIODE_3_CONV_CYCLE_MASK BIT(1)
> +#define LTC2983_DIODE_3_CONV_CYCLE(x) \
> + FIELD_PREP(LTC2983_DIODE_3_CONV_CYCLE_M
> ASK, x)
> +#define LTC2983_DIODE_AVERAGE_ON_MASK BIT(0)
> +#define LTC2983_DIODE_AVERAGE_ON(x) \
> + FIELD_PREP(LTC2983_DIODE_AVERAGE_ON_MAS
> K, x)
> +
> +#define LTC2983_RTD_4_WIRE_MASK BIT(3)
> +#define LTC2983_RTD_ROTATION_MASK BIT(1)
> +#define LTC2983_RTD_C_ROTATE(x) \
> + FIELD_PREP(LTC2983_RTD_ROTATION_MASK, x)
> +#define LTC2983_RTD_KELVIN_R_SENSE_MASK GENMASK(3, 2)
> +#define LTC2983_RTD_N_WIRES_MASK GENMASK(3, 2)
> +#define LTC2983_RTD_N_WIRES(x) \
> + FIELD_PREP(LTC2983_RTD_N_WIRES_MASK, x)
> +#define LTC2983_RTD_R_SHARE_MASK BIT(0)
> +#define LTC2983_RTD_R_SHARE(x) \
> + FIELD_PREP(LTC2983_RTD_R_SHARE_MASK, 1)
> +
> +#define LTC2983_COMMON_HARD_FAULT_MASK GENMASK(31, 30)
> +#define LTC2983_COMMON_SOFT_FAULT_MASK GENMASK(27, 25)
> +
> +#define LTC2983_STATUS_START_MASK BIT(7)
> +#define LTC2983_STATUS_START(x) FIELD_PREP(LTC2983_ST
> ATUS_START_MASK, x)
> +
> +#define LTC2983_STATUS_CHAN_SEL_MASK GENMASK(4, 0)
> +#define LTC2983_STATUS_CHAN_SEL(x) \
> + FIELD_PREP(LTC2983_STATUS_CHAN_SEL_MASK
> , x)
> +
> +#define LTC2983_TEMP_UNITS_MASK BIT(2)
> +#define LTC2983_TEMP_UNITS(x) FIELD_PREP(LTC2983_TEMP
> _UNITS_MASK, x)
> +
> +#define LTC2983_NOTCH_FREQ_MASK GENMASK(1, 0)
> +#define LTC2983_NOTCH_FREQ(x) FIELD_PREP(LTC2983_NOTC
> H_FREQ_MASK, x)
> +
> +#define LTC2983_RES_VALID_MASK BIT(24)
> +#define LTC2983_DATA_MASK GENMASK(23, 0)
> +#define LTC2983_DATA_SIGN_BIT 23
> +
> +#define LTC2983_CHAN_TYPE_MASK GENMASK(31, 27)
> +#define LTC2983_CHAN_TYPE(x) FIELD_PREP(LTC2983_CHAN_TYPE_MA
> SK, x)
> +
> +/* cold junction for thermocouples and rsense for rtd's and
> thermistor's */
> +#define LTC2983_CHAN_ASSIGN_MASK GENMASK(26, 22)
> +#define LTC2983_CHAN_ASSIGN(x) FIELD_PREP(LTC2983_CHAN
> _ASSIGN_MASK, x)
> +
> +#define LTC2983_CUSTOM_LEN_MASK GENMASK(5, 0)
> +#define LTC2983_CUSTOM_LEN(x) FIELD_PREP(LTC2983_CUST
> OM_LEN_MASK, x)
> +
> +#define LTC2983_CUSTOM_ADDR_MASK GENMASK(11, 6)
> +#define LTC2983_CUSTOM_ADDR(x) FIELD_PREP(LTC2983_CUST
> OM_ADDR_MASK, x)
> +
> +#define LTC2983_THERMOCOUPLE_CFG_MASK GENMASK(21, 18)
> +#define LTC2983_THERMOCOUPLE_CFG(x) \
> + FIELD_PREP(LTC2983_THERMOCOUPLE_CFG_MAS
> K, x)
> +#define LTC2983_THERMOCOUPLE_HARD_FAULT_MASK GENMASK(31, 29)
> +#define LTC2983_THERMOCOUPLE_SOFT_FAULT_MASK GENMASK(28, 25)
> +
> +#define LTC2983_RTD_CFG_MASK GENMASK(21, 18)
> +#define LTC2983_RTD_CFG(x) FIELD_PREP(LTC2983_RTD_CFG_MASK
> , x)
> +#define LTC2983_RTD_EXC_CURRENT_MASK GENMASK(17, 14)
> +#define LTC2983_RTD_EXC_CURRENT(x) \
> + FIELD_PREP(LTC2983_RTD_EXC_CURRENT_MASK
> , x)
> +#define LTC2983_RTD_CURVE_MASK GENMASK(13, 12)
> +#define LTC2983_RTD_CURVE(x) FIELD_PREP(LTC2983_RTD_CURVE_MA
> SK, x)
> +
> +#define LTC2983_THERMISTOR_CFG_MASK GENMASK(21, 19)
> +#define LTC2983_THERMISTOR_CFG(x) \
> + FIELD_PREP(LTC2983_THERMISTOR_CFG_MASK,
> x)
> +#define LTC2983_THERMISTOR_EXC_CURRENT_MASK GENMASK(18, 15)
> +#define LTC2983_THERMISTOR_EXC_CURRENT(x) \
> + FIELD_PREP(LTC2983_THERMISTOR_EXC_CURRENT_MASK,
> x)
> +
> +#define LTC2983_DIODE_CFG_MASK GENMASK(26, 24)
> +#define LTC2983_DIODE_CFG(x) FIELD_PREP(LTC2983_DIODE_CFG_MA
> SK, x)
> +#define LTC2983_DIODE_EXC_CURRENT_MASK GENMASK(23, 22)
> +#define LTC2983_DIODE_EXC_CURRENT(x) \
> + FIELD_PREP(LTC2983_DIODE_EXC_CURRENT_MA
> SK, x)
> +#define LTC2983_DIODE_IDEAL_FACTOR_MASK GENMASK(21, 0)
> +#define LTC2983_DIODE_IDEAL_FACTOR(x) \
> + FIELD_PREP(LTC2983_DIODE_IDEAL_FACTOR_M
> ASK, x)
> +
> +#define LTC2983_R_SENSE_VAL_MASK GENMASK(26, 0)
> +#define LTC2983_R_SENSE_VAL(x) FIELD_PREP(LTC2983_R_SE
> NSE_VAL_MASK, x)
> +
> +#define LTC2983_ADC_SINGLE_ENDED_MASK BIT(26)
> +#define LTC2983_ADC_SINGLE_ENDED(x) \
> + FIELD_PREP(LTC2983_ADC_SINGLE_ENDED_MAS
> K, x)
> +
> +enum {
> + LTC2983_SENSOR_THERMOCOUPLE = 1,
> + LTC2983_SENSOR_THERMOCOUPLE_CUSTOM = 9,
> + LTC2983_SENSOR_RTD = 10,
> + LTC2983_SENSOR_RTD_CUSTOM = 18,
> + LTC2983_SENSOR_THERMISTOR = 19,
> + LTC2983_SENSOR_THERMISTOR_STEINHART = 26,
> + LTC2983_SENSOR_THERMISTOR_CUSTOM = 27,
> + LTC2983_SENSOR_DIODE = 28,
> + LTC2983_SENSOR_SENSE_RESISTOR = 29,
> + LTC2983_SENSOR_DIRECT_ADC = 30,
> +};
> +
> +#define to_thermocouple(_sensor) \
> + container_of(_sensor, struct ltc2983_thermocouple,
> sensor)
> +
> +#define to_rtd(_sensor) \
> + container_of(_sensor, struct ltc2983_rtd, sensor)
> +
> +#define to_thermistor(_sensor) \
> + container_of(_sensor, struct ltc2983_thermistor,
> sensor)
> +
> +#define to_diode(_sensor) \
> + container_of(_sensor, struct ltc2983_diode, sensor)
> +
> +#define to_rsense(_sensor) \
> + container_of(_sensor, struct ltc2983_rsense, sensor)
> +
> +#define to_adc(_sensor) \
> + container_of(_sensor, struct ltc2983_adc, sensor)
> +
> +struct ltc2983_data {
> + struct regmap *regmap;
> + struct spi_device *spi;
> + struct mutex lock;
> + struct completion completion;
> + struct iio_chan_spec *iio_chan;
> + struct ltc2983_sensor **sensors;
> + u32 mux_delay_config;
> + u32 filter_notch_freq;
> + u16 custom_table_size;
> + u8 num_channels;
> + u8 iio_channels;
> + bool temp_farenheit;
> + bool sleep;
> +};
> +
> +struct ltc2983_sensor {
> + int (*fault_handler)(const struct ltc2983_data *st, const u32
> result);
> + int (*assign_chan)(struct ltc2983_data *st,
> + const struct ltc2983_sensor *sensor);
> + /* specifies the sensor channel */
> + u32 chan;
> + /* sensor type */
> + u32 type;
> +};
> +
> +struct ltc2983_custom_sensor {
> + /* raw table sensor data */
> + u8 *table;
> + size_t size;
> + /* address offset */
> + s8 offset;
> + bool is_steinhart;
> +};
> +
> +struct ltc2983_thermocouple {
> + struct ltc2983_sensor sensor;
> + struct ltc2983_custom_sensor *custom;
> + u32 sensor_config;
> + u32 cold_junction_chan;
> +};
> +
> +struct ltc2983_rtd {
> + struct ltc2983_sensor sensor;
> + struct ltc2983_custom_sensor *custom;
> + u32 sensor_config;
> + u32 r_sense_chan;
> + u32 excitation_current;
> + u32 rtd_curve;
> +};
> +
> +struct ltc2983_thermistor {
> + struct ltc2983_sensor sensor;
> + struct ltc2983_custom_sensor *custom;
> + u32 sensor_config;
> + u32 r_sense_chan;
> + u32 excitation_current;
> +};
> +
> +struct ltc2983_diode {
> + struct ltc2983_sensor sensor;
> + u32 sensor_config;
> + u32 excitation_current;
> + u32 ideal_factor_value;
> +};
> +
> +struct ltc2983_rsense {
> + struct ltc2983_sensor sensor;
> + u32 r_sense_val;
> +};
> +
> +struct ltc2983_adc {
> + struct ltc2983_sensor sensor;
> + bool single_ended;
> +};
> +
> +/*
> + * Convert to Q format numbers. These number's are integers where
> + * the number of integer and fractional bits are specified. The
> resolution
> + * is given by 1/@resolution and tell us the number of fractional
> bits. For
> + * instance a resolution of 2^-10 means we have 10 fractional bits.
> + */
> +static u32 __convert_to_raw(const u64 val, const u32 resolution)
> +{
> + u64 __res = val * resolution;
> +
> + /* all values are multiplied by 1000000 to remove the fraction
> */
> + do_div(__res, 1000000);
> +
> + return __res;
> +}
> +
> +static u32 __convert_to_raw_sign(const u64 val, const u32
> resolution)
> +{
> + s64 __res = -(s32)val;
> +
> + __res = __convert_to_raw(__res, resolution);
> +
> + return (u32)-__res;
> +}
> +
> +static int __ltc2983_fault_handler(const struct ltc2983_data *st,
> + const u32 result, const u32
> hard_mask,
> + const u32 soft_mask)
> +{
> + const struct device *dev = &st->spi->dev;
> +
> + if (result & hard_mask) {
> + dev_err(dev, "Invalid conversion: Sensor HARD
> fault\n");
> + return -EIO;
> + } else if (result & soft_mask) {
> + /* just print a warning */
> + dev_warn(dev, "Suspicious conversion: Sensor SOFT
> fault\n");
> + }
> +
> + return 0;
> +}
> +
> +static int __ltc2983_chan_assign_common(const struct ltc2983_data
> *st,
> + const struct ltc2983_sensor
> *sensor,
> + u32 chan_val)
> +{
> + u32 reg = LTC2983_CHAN_START_ADDR(sensor->chan);
> + __be32 __chan_val;
> +
> + chan_val |= LTC2983_CHAN_TYPE(sensor->type);
> + dev_dbg(&st->spi->dev, "Assign reg:0x%04X, val:0x%08X\n", reg,
> + chan_va
> l);
> + __chan_val = cpu_to_be32(chan_val);
> + return regmap_bulk_write(st->regmap, reg, &__chan_val,
> + sizeof(__chan_val));
> +}
> +
> +static int __ltc2983_chan_custom_sensor_assign(struct ltc2983_data
> *st,
> + struct ltc2983_custom_sensor
> *custom,
> + u32 *chan_val)
> +{
> + u32 reg;
> + u8 mult = custom->is_steinhart ?
> LTC2983_CUSTOM_STEINHART_ENTRY_SZ :
> + LTC2983_CUSTOM_SENSOR_ENTRY_SZ;
> + const struct device *dev = &st->spi->dev;
> + /*
> + * custom->size holds the raw size of the table. However, when
> + * configuring the sensor channel, we must write the number of
> + * entries of the table minus 1. For steinhart sensors 0 is
> written
> + * since the size is constant!
> + */
> + const u8 len = custom->is_steinhart ? 0 :
> + (custom->size / LTC2983_CUSTOM_SENSOR_ENTRY_SZ) - 1;
> + /*
> + * Check if the offset was assigned already. It should be for
> steinhart
> + * sensors. When coming from sleep, it should be assigned for
> all.
> + */
> + if (custom->offset < 0) {
> + /*
> + * This needs to be done again here because, from the
> moment
> + * when this test was done (successfully) for this
> custom
> + * sensor, a steinhart sensor might have been added
> changing
> + * custom_table_size...
> + */
> + if (st->custom_table_size + custom->size >
> + (LTC2983_CUST_SENS_TBL_END_REG -
> + LTC2983_CUST_SENS_TBL_START_REG) + 1) {
> + dev_err(dev,
> + "Not space left(%d) for new custom
> sensor(%zu)",
> + st-
> >custom_table_size,
> + custom->size);
> + return -EINVAL;
> + }
> +
> + custom->offset = st->custom_table_size /
> + LTC2983_CUSTOM_SENSOR_ENTRY_SZ;
> + st->custom_table_size += custom->size;
> + }
> +
> + reg = (custom->offset * mult) +
> LTC2983_CUST_SENS_TBL_START_REG;
> +
> + *chan_val |= LTC2983_CUSTOM_LEN(len);
> + *chan_val |= LTC2983_CUSTOM_ADDR(custom->offset);
> + dev_dbg(dev, "Assign custom sensor, reg:0x%04X, off:%d,
> sz:%zu",
> + reg, custom-
> >offset,
> + custom->size);
> + /* write custom sensor table */
> + return regmap_bulk_write(st->regmap, reg, custom->table,
> custom->size);
> +}
> +
> +static struct ltc2983_custom_sensor *__ltc2983_custom_sensor_new(
> + struct ltc2983_data
> *st,
> + const struct
> device_node *np,
> + const bool
> is_steinhart,
> + const u32 resolution,
> + const bool has_signed)
> +{
> + struct ltc2983_custom_sensor *new_custom;
> + u8 index, n_entries, tbl = 0;
> + struct device *dev = &st->spi->dev;
> + /*
> + * For custom steinhart, the full u32 is taken. For all the
> others
> + * the MSB is discarded.
> + */
> + const u8 n_size = (is_steinhart == true) ? 4 : 3;
> +
> + n_entries = of_property_count_elems_of_size(np, "adi,custom-
> sensor",
> + sizeof(u64));
> + /* n_entries must be an even number */
> + if (!n_entries || (n_entries % 2) != 0) {
> + dev_err(dev, "Number of entries either 0 or not
> even\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + new_custom = devm_kzalloc(dev, sizeof(*new_custom),
> GFP_KERNEL);
> + if (!new_custom)
> + return ERR_PTR(-ENOMEM);
> +
> + new_custom->size = n_entries * n_size;
> + /* check Steinhart size */
> + if (is_steinhart && new_custom->size !=
> LTC2983_CUSTOM_STEINHART_SIZE) {
> + dev_err(dev, "Steinhart sensors size(%zu) must be 24",
> + new_custom-
> >size);
> + return ERR_PTR(-EINVAL);
> + }
> + /* Check space on the table. */
> + if (st->custom_table_size + new_custom->size >
> + (LTC2983_CUST_SENS_TBL_END_REG -
> + LTC2983_CUST_SENS_TBL_START_REG) + 1) {
> + dev_err(dev, "No space left(%d) for new custom
> sensor(%zu)",
> + st->custom_table_size, new_custom-
> >size);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* allocate the table */
> + new_custom->table = devm_kzalloc(dev, new_custom->size,
> GFP_KERNEL);
> + if (!new_custom->table)
> + return ERR_PTR(-ENOMEM);
> +
> + for (index = 0; index < n_entries; index++) {
> + u64 temp = 0, j;
> +
> + of_property_read_u64_index(np, "adi,custom-sensor",
> index,
> + &temp);
> + /*
> + * Steinhart sensors are configured with raw values in
> the
> + * devicetree. For the other sensors we must convert
> the
> + * value to raw. The odd index's correspond to
> temperarures
> + * and always have 1/1024 of resolution. Temperatures
> also
> + * come in kelvin, so signed values is not possible
> + */
> + if (!is_steinhart) {
> + if ((index % 2) != 0)
> + temp = __convert_to_raw(temp, 1024);
> + else if (has_signed && (s64)temp < 0)
> + temp = __convert_to_raw_sign(temp,
> resolution);
> + else
> + temp = __convert_to_raw(temp,
> resolution);
> + }
> +
> + for (j = 0; j < n_size; j++)
> + new_custom->table[tbl++] =
> + temp >> (8 * (n_size - j - 1));
> + }
> +
> + new_custom->is_steinhart = is_steinhart;
> + /*
> + * This is done to first add all the steinhart sensors to the
> table,
> + * in order to maximize the table usage. If we mix adding
> steinhart
> + * with the other sensors, we might have to do some roundup to
> make
> + * sure that sensor_addr - 0x250(start address) is a multiple
> of 4
> + * (for steinhart), and a multiple of 6 for all the other
> sensors.
> + * Since we have const 24 bytes for steinhart sensors and 24 is
> + * also a multiple of 6, we guarantee that the first non-
> steinhart
> + * sensor will sit in a correct address without the need of
> filling
> + * addresses.
> + */
> + if (is_steinhart) {
> + new_custom->offset = st->custom_table_size /
> + LTC2983_CUSTOM_STEINHART_ENTRY_
> SZ;
> + st->custom_table_size += new_custom->size;
> + } else {
> + /* mark as unset. This is checked later on the assign
> phase */
> + new_custom->offset = -1;
> + }
> +
> + return new_custom;
> +}
> +
> +static int ltc2983_thermocouple_fault_handler(const struct
> ltc2983_data *st,
> + const u32 result)
> +{
> + return __ltc2983_fault_handler(st, result,
> + LTC2983_THERMOCOUPLE_HARD_FAULT_
> MASK,
> + LTC2983_THERMOCOUPLE_SOFT_FAULT_
> MASK);
> +}
> +
> +static int ltc2983_common_fault_handler(const struct ltc2983_data
> *st,
> + const u32 result)
> +{
> + return __ltc2983_fault_handler(st, result,
> + LTC2983_COMMON_HARD_FAULT_MASK,
> + LTC2983_COMMON_SOFT_FAULT_MASK);
> +}
> +
> +static int ltc2983_thermocouple_assign_chan(struct ltc2983_data *st,
> + const struct ltc2983_sensor *sensor)
> +{
> + struct ltc2983_thermocouple *thermo = to_thermocouple(sensor);
> + u32 chan_val;
> +
> + chan_val = LTC2983_CHAN_ASSIGN(thermo->cold_junction_chan);
> + chan_val |= LTC2983_THERMOCOUPLE_CFG(thermo->sensor_config);
> +
> + if (thermo->custom) {
> + int ret;
> +
> + ret = __ltc2983_chan_custom_sensor_assign(st, thermo-
> >custom,
> + &chan_val);
> + if (ret)
> + return ret;
> + }
> + return __ltc2983_chan_assign_common(st, sensor, chan_val);
> +}
> +
> +static int ltc2983_rtd_assign_chan(struct ltc2983_data *st,
> + const struct ltc2983_sensor *sensor)
> +{
> + struct ltc2983_rtd *rtd = to_rtd(sensor);
> + u32 chan_val;
> +
> + chan_val = LTC2983_CHAN_ASSIGN(rtd->r_sense_chan);
> + chan_val |= LTC2983_RTD_CFG(rtd->sensor_config);
> + chan_val |= LTC2983_RTD_EXC_CURRENT(rtd->excitation_current);
> + chan_val |= LTC2983_RTD_CURVE(rtd->rtd_curve);
> +
> + if (rtd->custom) {
> + int ret;
> +
> + ret = __ltc2983_chan_custom_sensor_assign(st, rtd-
> >custom,
> + &chan_val);
> + if (ret)
> + return ret;
> + }
> + return __ltc2983_chan_assign_common(st, sensor, chan_val);
> +}
> +
> +static int ltc2983_thermistor_assign_chan(struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_thermistor *thermistor = to_thermistor(sensor);
> + u32 chan_val;
> +
> + chan_val = LTC2983_CHAN_ASSIGN(thermistor->r_sense_chan);
> + chan_val |= LTC2983_THERMISTOR_CFG(thermistor->sensor_config);
> + chan_val |=
> + LTC2983_THERMISTOR_EXC_CURRENT(thermistor-
> >excitation_current);
> +
> + if (thermistor->custom) {
> + int ret;
> +
> + ret = __ltc2983_chan_custom_sensor_assign(st,
> + thermistor-
> >custom,
> + &chan_val);
> + if (ret)
> + return ret;
> + }
> + return __ltc2983_chan_assign_common(st, sensor, chan_val);
> +}
> +
> +static int ltc2983_diode_assign_chan(struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_diode *diode = to_diode(sensor);
> + u32 chan_val;
> +
> + chan_val = LTC2983_DIODE_CFG(diode->sensor_config);
> + chan_val |= LTC2983_DIODE_EXC_CURRENT(diode-
> >excitation_current);
> + chan_val |= LTC2983_DIODE_IDEAL_FACTOR(diode-
> >ideal_factor_value);
> +
> + return __ltc2983_chan_assign_common(st, sensor, chan_val);
> +}
> +
> +static int ltc2983_r_sense_assign_chan(struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_rsense *rsense = to_rsense(sensor);
> + u32 chan_val;
> +
> + chan_val = LTC2983_R_SENSE_VAL(rsense->r_sense_val);
> +
> + return __ltc2983_chan_assign_common(st, sensor, chan_val);
> +}
> +
> +static int ltc2983_adc_assign_chan(struct ltc2983_data *st,
> + const struct ltc2983_sensor *sensor)
> +{
> + struct ltc2983_adc *adc = to_adc(sensor);
> + u32 chan_val;
> +
> + chan_val = LTC2983_ADC_SINGLE_ENDED(adc->single_ended);
> +
> + return __ltc2983_chan_assign_common(st, sensor, chan_val);
> +}
> +
> +static struct ltc2983_sensor *ltc2983_thermocouple_new(
> + const struct device_node
> *child,
> + struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_thermocouple *thermo;
> + struct device_node *phandle;
> + u32 oc_current;
> + int ret;
> +
> + thermo = devm_kzalloc(&st->spi->dev, sizeof(*thermo),
> GFP_KERNEL);
> + if (!thermo)
> + return ERR_PTR(-ENOMEM);
> +
> + if (of_property_read_bool(child, "adi,single-ended"))
> + thermo->sensor_config = LTC2983_THERMOCOUPLE_SGL(1);
> +
> + ret = of_property_read_u32(child, "adi,sensor-oc-current-
> microamp",
> + &oc_current);
> + if (!ret) {
> + switch (oc_current) {
> + case 10:
> + thermo->sensor_config |=
> + LTC2983_THERMOCOUPLE_OC_CURR(0)
> ;
> + break;
> + case 100:
> + thermo->sensor_config |=
> + LTC2983_THERMOCOUPLE_OC_CURR(1)
> ;
> + break;
> + case 500:
> + thermo->sensor_config |=
> + LTC2983_THERMOCOUPLE_OC_CURR(2)
> ;
> + break;
> + case 1000:
> + thermo->sensor_config |=
> + LTC2983_THERMOCOUPLE_OC_CURR(3)
> ;
> + break;
> + default:
> + dev_err(&st->spi->dev,
> + "Invalid open circuit current:%u",
> oc_current);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + thermo->sensor_config |=
> LTC2983_THERMOCOUPLE_OC_CHECK(1);
> + }
> + /* validate channel index */
> + if (!(thermo->sensor_config & LTC2983_THERMOCOUPLE_DIFF_MASK)
> &&
> + sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
> + dev_err(&st->spi->dev,
> + "Invalid chann:%d for differential
> thermocouple",
> + sensor-
> >chan);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + phandle = of_parse_phandle(child, "adi,cold-junction-handle",
> 0);
> + if (phandle) {
> + int ret;
> +
> + ret = of_property_read_u32(phandle, "reg",
> + &thermo-
> >cold_junction_chan);
> + if (ret) {
> + /*
> + * This would be catched later but we can just
> return
> + * the error right away.
> + */
> + dev_err(&st->spi->dev, "Property reg must be
> given\n");
> + of_node_put(phandle);
> + return ERR_PTR(-EINVAL);
> + }
> + }
> +
> + /* check custom sensor */
> + if (sensor->type == LTC2983_SENSOR_THERMOCOUPLE_CUSTOM) {
> + thermo->custom = __ltc2983_custom_sensor_new(st, child,
> false,
> + 16384,
> true);
> + if (IS_ERR(thermo->custom)) {
> + of_node_put(phandle);
> + return ERR_CAST(thermo->custom);
> + }
> + }
> +
> + /* set common parameters */
> + thermo->sensor.fault_handler =
> ltc2983_thermocouple_fault_handler;
> + thermo->sensor.assign_chan = ltc2983_thermocouple_assign_chan;
> +
> + of_node_put(phandle);
> + return &thermo->sensor;
> +}
> +
> +static struct ltc2983_sensor *ltc2983_rtd_new(const struct
> device_node *child,
> + struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_rtd *rtd;
> + int ret = 0;
> + struct device *dev = &st->spi->dev;
> + struct device_node *phandle;
> + u32 excitation_current = 0, n_wires = 0;
> +
> + rtd = devm_kzalloc(dev, sizeof(*rtd), GFP_KERNEL);
> + if (!rtd)
> + return ERR_PTR(-ENOMEM);
> +
> + phandle = of_parse_phandle(child, "adi,rsense-handle", 0);
> + if (!phandle) {
> + dev_err(dev, "Property adi,rsense-handle missing or
> invalid");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + ret = of_property_read_u32(phandle, "reg", &rtd->r_sense_chan);
> + if (ret) {
> + dev_err(dev, "Property reg must be given\n");
> + goto fail;
> + }
> +
> + ret = of_property_read_u32(child, "adi,number-of-wires",
> &n_wires);
> + if (!ret) {
> + switch (n_wires) {
> + case 2:
> + rtd->sensor_config = LTC2983_RTD_N_WIRES(0);
> + break;
> + case 3:
> + rtd->sensor_config = LTC2983_RTD_N_WIRES(1);
> + break;
> + case 4:
> + rtd->sensor_config = LTC2983_RTD_N_WIRES(2);
> + break;
> + case 5:
> + /* 4 wires, Kelvin Rsense */
> + rtd->sensor_config = LTC2983_RTD_N_WIRES(3);
> + break;
> + default:
> + dev_err(dev, "Invalid number of wires:%u\n",
> n_wires);
> + ret = -EINVAL;
> + goto fail;
> + }
> + }
> +
> + if (of_property_read_bool(child, "adi,rsense-share")) {
> + /* Current rotation is only available with rsense
> sharing */
> + if (of_property_read_bool(child, "adi,current-rotate"))
> {
> + if (n_wires == 2 || n_wires == 3) {
> + dev_err(dev,
> + "Rotation not allowed for 2/3
> Wire RTDs");
> + ret = -EINVAL;
> + goto fail;
> + }
> + rtd->sensor_config |= LTC2983_RTD_C_ROTATE(1);
> + } else {
> + rtd->sensor_config |= LTC2983_RTD_R_SHARE(1);
> + }
> + }
> + /*
> + * rtd channel indexes are a bit more complicated to validate.
> + * For 4wire RTD with rotation, the channel selection cannot be
> + * >=19 since the chann + 1 is used in this configuration.
> + * For 4wire RTDs with kelvin rsense, the rsense channel cannot
> be
> + * <=1 since chanel - 1 and channel - 2 are used.
> + */
> + if (rtd->sensor_config & LTC2983_RTD_4_WIRE_MASK) {
> + /* 4-wire */
> + u8 min = LTC2983_DIFFERENTIAL_CHAN_MIN,
> + max = LTC2983_MAX_CHANNELS_NR;
> +
> + if (rtd->sensor_config & LTC2983_RTD_ROTATION_MASK)
> + max = LTC2983_MAX_CHANNELS_NR - 1;
> +
> + if (((rtd->sensor_config &
> LTC2983_RTD_KELVIN_R_SENSE_MASK)
> + == LTC2983_RTD_KELVIN_R_SENSE_MASK) &&
> + (rtd->r_sense_chan <= min)) {
> + /* kelvin rsense*/
> + dev_err(dev,
> + "Invalid rsense chann:%d to use in
> kelvin rsense",
> + rtd-
> >r_sense_chan);
> +
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + if (sensor->chan < min || sensor->chan > max) {
> + dev_err(dev, "Invalid chann:%d for the rtd
> config",
> + sensor-
> >chan);
> +
> + ret = -EINVAL;
> + goto fail;
> + }
> + } else {
> + /* same as differential case */
> + if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
> + dev_err(&st->spi->dev,
> + "Invalid chann:%d for RTD", sensor-
> >chan);
> +
> + ret = -EINVAL;
> + goto fail;
> + }
> + }
> +
> + /* check custom sensor */
> + if (sensor->type == LTC2983_SENSOR_RTD_CUSTOM) {
> + rtd->custom = __ltc2983_custom_sensor_new(st, child,
> false,
> + 2048, false);
> + if (IS_ERR(rtd->custom)) {
> + of_node_put(phandle);
> + return ERR_CAST(rtd->custom);
> + }
> + }
> +
> + /* set common parameters */
> + rtd->sensor.fault_handler = ltc2983_common_fault_handler;
> + rtd->sensor.assign_chan = ltc2983_rtd_assign_chan;
> +
> + ret = of_property_read_u32(child, "adi,excitation-current-
> microamp",
> + &excitation_current);
> + if (ret) {
> + /* default to 5uA */
> + rtd->excitation_current = 1;
> + } else {
> + switch (excitation_current) {
> + case 5:
> + rtd->excitation_current = 0x01;
> + break;
> + case 10:
> + rtd->excitation_current = 0x02;
> + break;
> + case 25:
> + rtd->excitation_current = 0x03;
> + break;
> + case 50:
> + rtd->excitation_current = 0x04;
> + break;
> + case 100:
> + rtd->excitation_current = 0x05;
> + break;
> + case 250:
> + rtd->excitation_current = 0x06;
> + break;
> + case 500:
> + rtd->excitation_current = 0x07;
> + break;
> + case 1000:
> + rtd->excitation_current = 0x08;
> + break;
> + default:
> + dev_err(&st->spi->dev,
> + "Invalid value for excitation
> current(%u)",
> + excitation_curr
> ent);
> + ret = -EINVAL;
> + goto fail;
> + }
> + }
> +
> + of_property_read_u32(child, "adi,rtd-curve", &rtd->rtd_curve);
> +
> + of_node_put(phandle);
> + return &rtd->sensor;
> +fail:
> + of_node_put(phandle);
> + return ERR_PTR(ret);
> +}
> +
> +static struct ltc2983_sensor *ltc2983_thermistor_new(
> + const struct device_node
> *child,
> + struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_thermistor *thermistor;
> + struct device *dev = &st->spi->dev;
> + struct device_node *phandle;
> + u32 excitation_current = 0;
> + int ret = 0;
> +
> + thermistor = devm_kzalloc(dev, sizeof(*thermistor),
> GFP_KERNEL);
> + if (!thermistor)
> + return ERR_PTR(-ENOMEM);
> +
> + phandle = of_parse_phandle(child, "adi,rsense-handle", 0);
> + if (!phandle) {
> + dev_err(dev, "Property adi,rsense-handle missing or
> invalid");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + ret = of_property_read_u32(phandle, "reg", &thermistor-
> >r_sense_chan);
> + if (ret) {
> + dev_err(dev, "rsense channel must be configured...\n");
> + goto fail;
> + }
> +
> + if (of_property_read_bool(child, "adi,single-ended")) {
> + thermistor->sensor_config = LTC2983_THERMISTOR_SGL(1);
> + } else if (of_property_read_bool(child, "adi,rsense-share")) {
> + /* rotation is only possible if sharing rsense */
> + if (of_property_read_bool(child, "adi,current-rotate"))
> + thermistor->sensor_config =
> + LTC2983_THERMISTOR_C_RO
> TATE(1);
> + else
> + thermistor->sensor_config =
> + LTC2983_THERMISTOR_R_SH
> ARE(1);
> + }
> + /* validate channel index */
> + if (!(thermistor->sensor_config & LTC2983_THERMISTOR_DIFF_MASK)
> &&
> + sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
> + dev_err(&st->spi->dev,
> + "Invalid chann:%d for differential thermistor",
> + sensor-
> >chan);
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + /* check custom sensor */
> + if (sensor->type >= LTC2983_SENSOR_THERMISTOR_STEINHART) {
> + thermistor->custom = __ltc2983_custom_sensor_new(st,
> child,
> + sensor->type ==
> LTC2983_SENSOR_THERMISTOR_STEINHART ?
> + true : false,
> 64,
> + false);
> + if (IS_ERR(thermistor->custom)) {
> + of_node_put(phandle);
> + return ERR_CAST(thermistor->custom);
> + }
> + }
> + /* set common parameters */
> + thermistor->sensor.fault_handler =
> ltc2983_common_fault_handler;
> + thermistor->sensor.assign_chan =
> ltc2983_thermistor_assign_chan;
> +
> + ret = of_property_read_u32(child, "adi,excitation-current-
> nanoamp",
> + &excitation_current);
> + if (ret) {
> + /* Auto range is not allowed for custom sensors */
> + if (sensor->type >=
> LTC2983_SENSOR_THERMISTOR_STEINHART)
> + /* default to 1uA */
> + thermistor->excitation_current = 0x03;
> + else
> + /* default to auto-range */
> + thermistor->excitation_current = 0x0c;
> + } else {
> + switch (excitation_current) {
> + case 0:
> + /* auto range */
> + if (sensor->type >=
> + LTC2983_SENSOR_THERMISTOR_STEINHART) {
> + dev_err(&st->spi->dev,
> + "Auto Range not allowed for
> custom sensors\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> + thermistor->excitation_current = 0x0c;
> + break;
> + case 250:
> + thermistor->excitation_current = 0x01;
> + break;
> + case 500:
> + thermistor->excitation_current = 0x02;
> + break;
> + case 1000:
> + thermistor->excitation_current = 0x03;
> + break;
> + case 5000:
> + thermistor->excitation_current = 0x04;
> + break;
> + case 10000:
> + thermistor->excitation_current = 0x05;
> + break;
> + case 25000:
> + thermistor->excitation_current = 0x06;
> + break;
> + case 50000:
> + thermistor->excitation_current = 0x07;
> + break;
> + case 100000:
> + thermistor->excitation_current = 0x08;
> + break;
> + case 250000:
> + thermistor->excitation_current = 0x09;
> + break;
> + case 500000:
> + thermistor->excitation_current = 0x0a;
> + break;
> + case 1000000:
> + thermistor->excitation_current = 0x0b;
> + break;
> + default:
> + dev_err(&st->spi->dev,
> + "Invalid value for excitation
> current(%u)",
> + excitation_curr
> ent);
> + ret = -EINVAL;
> + goto fail;
> + }
> + }
> +
> + of_node_put(phandle);
> + return &thermistor->sensor;
> +fail:
> + of_node_put(phandle);
> + return ERR_PTR(ret);
> +}
> +
> +static struct ltc2983_sensor *ltc2983_diode_new(
> + const struct device_node
> *child,
> + const struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_diode *diode;
> + u32 temp = 0, excitation_current = 0;
> + int ret;
> +
> + diode = devm_kzalloc(&st->spi->dev, sizeof(*diode),
> GFP_KERNEL);
> + if (!diode)
> + return ERR_PTR(-ENOMEM);
> +
> + if (of_property_read_bool(child, "adi,single-ended"))
> + diode->sensor_config = LTC2983_DIODE_SGL(1);
> +
> + if (of_property_read_bool(child, "adi,three-conversion-
> cycles"))
> + diode->sensor_config |= LTC2983_DIODE_3_CONV_CYCLE(1);
> +
> + if (of_property_read_bool(child, "adi,average-on"))
> + diode->sensor_config |= LTC2983_DIODE_AVERAGE_ON(1);
> +
> + /* validate channel index */
> + if (!(diode->sensor_config & LTC2983_DIODE_DIFF_MASK) &&
> + sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
> + dev_err(&st->spi->dev,
> + "Invalid chann:%d for differential thermistor",
> + sensor-
> >chan);
> + return ERR_PTR(-EINVAL);
> + }
> + /* set common parameters */
> + diode->sensor.fault_handler = ltc2983_common_fault_handler;
> + diode->sensor.assign_chan = ltc2983_diode_assign_chan;
> +
> + ret = of_property_read_u32(child, "adi,excitation-current-
> microamp",
> + &excitation_current);
> + if (!ret) {
> + switch (excitation_current) {
> + case 10:
> + diode->excitation_current = 0x00;
> + break;
> + case 20:
> + diode->excitation_current = 0x01;
> + break;
> + case 40:
> + diode->excitation_current = 0x02;
> + break;
> + case 80:
> + diode->excitation_current = 0x03;
> + break;
> + default:
> + dev_err(&st->spi->dev,
> + "Invalid value for excitation
> current(%u)",
> + excitation_curr
> ent);
> + return ERR_PTR(-EINVAL);
> + }
> + }
> +
> + of_property_read_u32(child, "adi,ideal-factor-value", &temp);
> +
> + /* 2^20 resolution */
> + diode->ideal_factor_value = __convert_to_raw(temp, 1048576);
> +
> + return &diode->sensor;
> +}
> +
> +static struct ltc2983_sensor *ltc2983_r_sense_new(struct device_node
> *child,
> + struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_rsense *rsense;
> + int ret;
> + u64 temp;
> +
> + rsense = devm_kzalloc(&st->spi->dev, sizeof(*rsense),
> GFP_KERNEL);
> + if (!rsense)
> + return ERR_PTR(-ENOMEM);
> +
> + /* validate channel index */
> + if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
> + dev_err(&st->spi->dev, "Invalid chann:%d for r_sense",
> + sensor->chan);
> + return ERR_PTR(-EINVAL);
> + }
> + /* get raw value */
> + ret = of_property_read_u64(child, "adi,rsense-val-micro-ohms",
> &temp);
> + if (ret) {
> + dev_err(&st->spi->dev, "Property adi,rsense-val-micro-
> ohms missing\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* 2^10 resolution */
> + rsense->r_sense_val = __convert_to_raw(temp, 1024);
> +
> + /* set common parameters */
> + rsense->sensor.assign_chan = ltc2983_r_sense_assign_chan;
> +
> + return &rsense->sensor;
> +}
> +
> +static struct ltc2983_sensor *ltc2983_adc_new(struct device_node
> *child,
> + struct ltc2983_data *st,
> + const struct ltc2983_sensor
> *sensor)
> +{
> + struct ltc2983_adc *adc;
> +
> + adc = devm_kzalloc(&st->spi->dev, sizeof(*adc), GFP_KERNEL);
> + if (!adc)
> + return ERR_PTR(-ENOMEM);
> +
> + if (of_property_read_bool(child, "adi,single-ended"))
> + adc->single_ended = true;
> +
> + if (!adc->single_ended &&
> + sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN) {
> + dev_err(&st->spi->dev, "Invalid chan:%d for
> differential adc\n",
> + sensor-
> >chan);
> + return ERR_PTR(-EINVAL);
> + }
> + /* set common parameters */
> + adc->sensor.assign_chan = ltc2983_adc_assign_chan;
> + adc->sensor.fault_handler = ltc2983_common_fault_handler;
> +
> + return &adc->sensor;
> +}
> +
> +static int ltc2983_chan_read(struct ltc2983_data *st,
> + const struct ltc2983_sensor *sensor, int *val)
> +{
> + u32 start_conversion = 0;
> + int ret;
> + unsigned long time;
> + __be32 temp;
> +
> + /*
> + * Do not allow channel readings if device is in sleep state.
> + * A read/write on the spi bus would bring the device
> prematurely
> + * out of sleep.
> + */
> + if (st->sleep)
> + return -EPERM;
> +
> + start_conversion = LTC2983_STATUS_START(true);
> + start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
> + dev_dbg(&st->spi->dev, "Start conversion on chan:%d,
> status:%02X\n",
> + sensor->chan, start_conversion);
> + /* start conversion */
> + ret = regmap_write(st->regmap, LTC2983_STATUS_REG,
> start_conversion);
> + if (ret)
> + return ret;
> +
> + reinit_completion(&st->completion);
> + /*
> + * wait for conversion to complete.
> + * 300 ms should be more than enough to complete the
> conversion.
> + * Depending on the sensor configuration, there are 2/3
> conversions
> + * cycles of 82ms.
> + */
> + time = wait_for_completion_timeout(&st->completion,
> + msecs_to_jiffies(300));
> + if (!time) {
> + dev_warn(&st->spi->dev, "Conversion timed out\n");
> + return -ETIMEDOUT;
> + }
> +
> + /* read the converted data */
> + ret = regmap_bulk_read(st->regmap,
> LTC2983_CHAN_RES_ADDR(sensor->chan),
> + &temp, sizeof(temp));
> + if (ret)
> + return ret;
> +
> + *val = __be32_to_cpu(temp);
> +
> + if (!(LTC2983_RES_VALID_MASK & *val)) {
> + dev_err(&st->spi->dev, "Invalid conversion
> detected\n");
> + return -EIO;
> + }
> +
> + ret = sensor->fault_handler(st, *val);
> + if (ret)
> + return ret;
> +
> + *val = sign_extend32((*val) & LTC2983_DATA_MASK,
> LTC2983_DATA_SIGN_BIT);
> + return 0;
> +}
> +
> +static int ltc2983_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct ltc2983_data *st = iio_priv(indio_dev);
> + int ret;
> +
> + /* sanity check */
> + if (chan->address >= st->num_channels) {
> + dev_err(&st->spi->dev, "Invalid chan address:%ld",
> + chan->address);
> + return -EINVAL;
> + }
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + mutex_lock(&st->lock);
> + ret = ltc2983_chan_read(st, st->sensors[chan->address],
> val);
> + mutex_unlock(&st->lock);
> + return ret ?: IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->type) {
> + case IIO_TEMP:
> + /* value in milli degrees */
> + *val = 1000;
> + /* 2^10 */
> + *val2 = 1024;
> + return IIO_VAL_FRACTIONAL;
> + case IIO_VOLTAGE:
> + /* value in millivolt */
> + *val = 1000;
> + /* 2^21 */
> + *val2 = 2097152;
> + return IIO_VAL_FRACTIONAL;
> + default:
> + return -EINVAL;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int ltc2983_reg_access(struct iio_dev *indio_dev,
> + unsigned int reg,
> + unsigned int writeval,
> + unsigned int *readval)
> +{
> + struct ltc2983_data *st = iio_priv(indio_dev);
> +
> + /* check comment in ltc2983_chan_read() */
> + if (st->sleep)
> + return -EPERM;
> +
> + if (readval)
> + return regmap_read(st->regmap, reg, readval);
> + else
> + return regmap_write(st->regmap, reg, writeval);
> +}
> +
> +static irqreturn_t ltc2983_irq_handler(int irq, void *data)
> +{
> + struct ltc2983_data *st = data;
> +
> + complete(&st->completion);
> + return IRQ_HANDLED;
> +}
> +
> +#define LTC2983_CHAN(__type, index, __address) ({ \
> + struct iio_chan_spec __chan = { \
> + .type = __type, \
> + .indexed = 1, \
> + .channel = index, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .address = __address, \
> + }; \
> + __chan; \
> +})
> +
> +static int ltc2983_parse_dt(struct ltc2983_data *st)
> +{
> + struct device_node *child;
> + struct device *dev = &st->spi->dev;
> + int ret = 0, chan = 0, channel_avail_mask = 0;
> +
> + if (!of_property_read_bool(dev->of_node, "adi,temperature-
> celcius"))
> + st->temp_farenheit = true;
> +
> + of_property_read_u32(dev->of_node, "adi,mux-delay-config-us",
> + &st->mux_delay_config);
> +
> + of_property_read_u32(dev->of_node, "adi,filter-notch-freq",
> + &st->filter_notch_freq);
> +
> + st->num_channels = of_get_available_child_count(dev->of_node);
> + st->sensors = devm_kcalloc(dev, st->num_channels, sizeof(*st-
> >sensors),
> + GFP_KERNEL);
> + if (!st->sensors)
> + return -ENOMEM;
> +
> + st->iio_channels = st->num_channels;
> + for_each_available_child_of_node(dev->of_node, child) {
> + struct ltc2983_sensor sensor;
> +
> + ret = of_property_read_u32(child, "reg", &sensor.chan);
> + if (ret) {
> + dev_err(dev, "reg property must given for child
> nodes\n");
> + return ret;
> + }
> +
> + /* check if we have a valid channel */
> + if (sensor.chan < LTC2983_MIN_CHANNELS_NR ||
> + sensor.chan > LTC2983_MAX_CHANNELS_NR) {
> + dev_err(dev,
> + "chan:%d must be from 1 to 20\n",
> sensor.chan);
> + return -EINVAL;
> + } else if (channel_avail_mask & BIT(sensor.chan)) {
> + dev_err(dev, "chan:%d already in use\n",
> sensor.chan);
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32(child, "adi,sensor-type",
> + &sensor.type);
> + if (ret) {
> + dev_err(dev,
> + "adi,sensor-type property must given
> for child nodes\n");
> + return ret;
> + }
> +
> + dev_dbg(dev, "Create new sensor, type %u, chann %u",
> + sensor.
> type,
> + sensor.
> chan);
> +
> + if (sensor.type >= LTC2983_SENSOR_THERMOCOUPLE &&
> + sensor.type <= LTC2983_SENSOR_THERMOCOUPLE_CUSTOM)
> {
> + st->sensors[chan] =
> ltc2983_thermocouple_new(child, st,
> + &s
> ensor);
> + } else if (sensor.type >= LTC2983_SENSOR_RTD &&
> + sensor.type <= LTC2983_SENSOR_RTD_CUSTOM) {
> + st->sensors[chan] = ltc2983_rtd_new(child, st,
> &sensor);
> + } else if (sensor.type >= LTC2983_SENSOR_THERMISTOR &&
> + sensor.type <=
> LTC2983_SENSOR_THERMISTOR_CUSTOM) {
> + st->sensors[chan] =
> ltc2983_thermistor_new(child, st,
> + &sen
> sor);
> + } else if (sensor.type == LTC2983_SENSOR_DIODE) {
> + st->sensors[chan] = ltc2983_diode_new(child,
> st,
> + &sensor);
> + } else if (sensor.type ==
> LTC2983_SENSOR_SENSE_RESISTOR) {
> + st->sensors[chan] = ltc2983_r_sense_new(child,
> st,
> + &sensor
> );
> + /* don't add rsense to iio */
> + st->iio_channels--;
> + } else if (sensor.type == LTC2983_SENSOR_DIRECT_ADC) {
> + st->sensors[chan] = ltc2983_adc_new(child, st,
> &sensor);
> + } else {
> + dev_err(dev, "Unknown sensor type %d\n",
> sensor.type);
> + return -EINVAL;
> + }
> +
> + if (IS_ERR(st->sensors[chan])) {
> + dev_err(dev, "Failed to create sensor %ld",
> + PTR_ERR(st-
> >sensors[chan]));
> + return PTR_ERR(st->sensors[chan]);
> + }
> + /* set generic sensor parameters */
> + st->sensors[chan]->chan = sensor.chan;
> + st->sensors[chan]->type = sensor.type;
> +
> + channel_avail_mask |= BIT(sensor.chan);
> + chan++;
> + }
> +
> + return 0;
> +}
> +
> +static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
> +{
> + u32 iio_chan_t = 0, iio_chan_v = 0, chan, iio_idx = 0;
> + u32 global_cfg = 0;
> + int ret;
> + unsigned long time;
> +
> + /* make sure the device is up */
> + time = wait_for_completion_timeout(&st->completion,
> + msecs_to_jiffies(250));
> +
> + if (!time) {
> + dev_err(&st->spi->dev, "Device startup timed out\n");
> + return -ETIMEDOUT;
> + }
> +
> + st->iio_chan = devm_kzalloc(&st->spi->dev,
> + st->iio_channels * sizeof(*st-
> >iio_chan),
> + GFP_KERNEL);
> +
> + if (!st->iio_chan)
> + return -ENOMEM;
> +
> + global_cfg = LTC2983_NOTCH_FREQ(st->filter_notch_freq);
> + global_cfg |= LTC2983_TEMP_UNITS(st->temp_farenheit);
> + regmap_write(st->regmap, LTC2983_GLOBAL_CONFIG_REG,
> global_cfg);
> + regmap_write(st->regmap, LTC2983_MUX_CONFIG_REG, st-
> >mux_delay_config);
> +
> + for (chan = 0; chan < st->num_channels; chan++) {
> + u32 chan_type = 0, *iio_chan;
> +
> + ret = st->sensors[chan]->assign_chan(st, st-
> >sensors[chan]);
> + if (ret)
> + return ret;
> + /*
> + * The assign_iio flag is necessary for when the device
> is
> + * coming out of sleep. In that case, we just need to
> + * re-configure the device channels.
> + * We also don't assign iio channels for rsense.
> + */
> + if (st->sensors[chan]->type ==
> LTC2983_SENSOR_SENSE_RESISTOR ||
> + !assign_iio)
> + continue;
> +
> + /* assign iio channel */
> + if (st->sensors[chan]->type !=
> LTC2983_SENSOR_DIRECT_ADC) {
> + chan_type = IIO_TEMP;
> + iio_chan = &iio_chan_t;
> + } else {
> + chan_type = IIO_VOLTAGE;
> + iio_chan = &iio_chan_v;
> + }
> +
> + /*
> + * add chan as the iio .address so that, we can
> directly
> + * reference the sensor given the iio_chan_spec
> + */
> + st->iio_chan[iio_idx++] = LTC2983_CHAN(chan_type,
> (*iio_chan)++,
> + chan);
> + }
> +
> + return 0;
> +}
> +
> +static const struct regmap_range ltc2983_reg_ranges[] = {
> + regmap_reg_range(LTC2983_STATUS_REG, LTC2983_STATUS_REG),
> + regmap_reg_range(LTC2983_TEMP_RES_START_REG,
> LTC2983_TEMP_RES_END_REG),
> + regmap_reg_range(LTC2983_GLOBAL_CONFIG_REG,
> LTC2983_GLOBAL_CONFIG_REG),
> + regmap_reg_range(LTC2983_MULT_CHANNEL_START_REG,
> + LTC2983_MULT_CHANNEL_END_REG),
> + regmap_reg_range(LTC2983_MUX_CONFIG_REG,
> LTC2983_MUX_CONFIG_REG),
> + regmap_reg_range(LTC2983_CHAN_ASSIGN_START_REG,
> + LTC2983_CHAN_ASSIGN_END_REG),
> + regmap_reg_range(LTC2983_CUST_SENS_TBL_START_REG,
> + LTC2983_CUST_SENS_TBL_END_REG),
> +};
> +
> +static const struct regmap_access_table ltc2983_reg_table = {
> + .yes_ranges = ltc2983_reg_ranges,
> + .n_yes_ranges = ARRAY_SIZE(ltc2983_reg_ranges),
> +};
> +
> +/*
> + * The reg_bits are actually 12 but the device needs the first
> *complete*
> + * byte for the command (R/W).
> + */
> +static const struct regmap_config ltc2983_regmap_config = {
> + .reg_bits = 24,
> + .val_bits = 8,
> + .wr_table = <c2983_reg_table,
> + .rd_table = <c2983_reg_table,
> + .read_flag_mask = GENMASK(1, 0),
> + .write_flag_mask = BIT(1),
> +};
> +
> +static const struct iio_info ltc2983_iio_info = {
> + .read_raw = ltc2983_read_raw,
> + .debugfs_reg_access = ltc2983_reg_access,
> +};
> +
> +static int ltc2983_probe(struct spi_device *spi)
> +{
> + struct ltc2983_data *st;
> + struct iio_dev *indio_dev;
> + const char *name = spi_get_device_id(spi)->name;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + st = iio_priv(indio_dev);
> +
> + st->regmap = devm_regmap_init_spi(spi, <c2983_regmap_config);
> + if (IS_ERR(st->regmap)) {
> + dev_err(&spi->dev, "Failed to initialize regmap\n");
> + return PTR_ERR(st->regmap);
> + }
> +
> + mutex_init(&st->lock);
> + init_completion(&st->completion);
> + st->spi = spi;
> + spi_set_drvdata(spi, st);
> +
> + ret = ltc2983_parse_dt(st);
> + if (ret)
> + return ret;
> + /*
> + * let's request the irq now so it is used to sync the device
> + * startup in ltc2983_setup()
> + */
> + ret = devm_request_irq(&spi->dev, spi->irq,
> ltc2983_irq_handler,
> + IRQF_TRIGGER_RISING, name, st);
> + if (ret) {
> + dev_err(&spi->dev, "failed to request an irq, %d",
> ret);
> + return ret;
> + }
> +
> + ret = ltc2983_setup(st, true);
> + if (ret)
> + return ret;
> +
> + indio_dev->dev.parent = &spi->dev;
> + indio_dev->name = name;
> + indio_dev->num_channels = st->iio_channels;
> + indio_dev->channels = st->iio_chan;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->info = <c2983_iio_info;
> +
> + return devm_iio_device_register(&spi->dev, indio_dev);
> +}
> +
> +static int __maybe_unused ltc2983_resume(struct device *dev)
> +{
> + struct ltc2983_data *st = spi_get_drvdata(to_spi_device(dev));
> + int ret;
> +
> + mutex_lock(&st->lock);
> + /* dummy read to bring the device out of sleep */
> + regmap_read(st->regmap, LTC2983_STATUS_REG, &ret);
> + /* we need to re-assign the channels */
> + ret = ltc2983_setup(st, false);
> + st->sleep = false;
> + mutex_unlock(&st->lock);
> +
> + return ret;
> +}
> +
> +static int __maybe_unused ltc2983_suspend(struct device *dev)
> +{
> + struct ltc2983_data *st = spi_get_drvdata(to_spi_device(dev));
> + int ret;
> +
> + mutex_lock(&st->lock);
> + ret = regmap_write(st->regmap, LTC2983_STATUS_REG,
> LTC2983_SLEEP);
> + st->sleep = true;
This flag is unneeded since all userland tasks are frozen before the hw
suspend()/resume() callbacks are called. When coming out of sleep,
things go in the reverse order so I do not have to care about code
trying to read the attributes. Furthermore, doing `mutex_lock()` here
is dangerous since some frozen task can held it... At very least I
think it should be trylock. But I don't really think the mutex_* calls
are needed here so I'm thinking in dropping this and the sleep flag in
v4.
> + mutex_unlock(&st->lock);
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(ltc2983_pm_ops, ltc2983_suspend,
> ltc2983_resume);
> +
> +static const struct spi_device_id ltc2983_id_table[] = {
> + { "ltc2983" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(spi, ltc2983_id_table);
> +
> +static const struct of_device_id ltc2983_of_match[] = {
> + { .compatible = "adi,ltc2983" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ltc2983_id_table);
> +
> +static struct spi_driver ltc2983_driver = {
> + .driver = {
> + .name = "ltc2983",
> + .of_match_table = ltc2983_of_match,
> + .pm = <c2983_pm_ops,
> + },
> + .probe = ltc2983_probe,
> + .id_table = ltc2983_id_table,
> +};
> +
> +module_spi_driver(ltc2983_driver);
> +
> +MODULE_AUTHOR("Nuno Sa <nuno.sa@analog.com>");
> +MODULE_DESCRIPTION("Analog Devices LTC2983 SPI Temperature
> sensors");
> +MODULE_LICENSE("GPL");
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Stefan Steyerl, Thomas Edward Cribben, Michael Paul
Sondel
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-10-12 10:44 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-04 13:55 [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Nuno Sá
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
2019-10-06 10:29 ` Jonathan Cameron
2019-10-07 14:45 ` Rob Herring
2019-10-07 16:17 ` Sa, Nuno
2019-10-07 17:46 ` Rob Herring
2019-10-08 7:45 ` Sa, Nuno
2019-10-08 10:22 ` Sa, Nuno
2019-10-10 20:03 ` Rob Herring
2019-10-12 10:41 ` Jonathan Cameron
2019-10-06 10:37 ` [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Jonathan Cameron
2019-10-07 9:10 ` Sa, Nuno
2019-10-07 11:52 ` Jonathan Cameron
2019-10-07 12:33 ` Sa, Nuno
2019-10-08 10:55 ` Sa, Nuno
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.