This series adds support and documentation for the Amphenol ChipCap 2
humidity and temperature sensor in its digital version.
This I2C device provides 14-bit humidity and temperature measurements as
well as low (minimum) and high (maximum) humidity alarms. A ready signal
is also available to reduce delays while fetching data.
The proposed driver implements the logic to perform measurements with
and without the ready signal, EEPROM configuration and alarm signaling.
The features this driver does not support (I2C address and command
window length modification) have been documented in the "Known Issues"
section.
The complete supported functionality has been tested with a CC2D33S
sensor connected to a Raspberry Pi Zero 2 w.
Different device tree node definitions (with and without ready and/or
alarm signals) have been positively tested.
Signed-off-by: Javier Carrasco <[email protected]>
---
Changes in v5:
- dt-bindings: add "amphenol,cc2d23" to "compatible" in the example.
- Link to v4: https://lore.kernel.org/r/[email protected]
Changes in v4:
- chipcap2.c: require exclusive regulator to trigger command mode.
- chipcap2.c: keep the device off until a measurement is required.
Because the device makes an automatic measurement after the power-up
sequence, no differentiation between sleep and non-sleep modes is
required anymore.
- chipcap2.c: retrieve alarm settings from the device instead of storing
them locally.
- dt-bindings: add vdd-supply to required properties.
- dt-bindings: default to 'amphenol,cc2d23' compatible (same
functionality for all compatibles).
- Link to v3: https://lore.kernel.org/r/[email protected]
Changes in v3:
- ABI: sysfs-class-hwmon: documented humidity min/max alarms.
- General: reorder patches (bindings first to remove checkpatch
warnings).
- General: remove part number wildcards and use real part numbers.
- chipcap2.c: improve error path in probe function.
- chipcap2.c: fix error handling if regulator could not be registered.
- chipcap2.c: use absolute values for hysteresis (for both ABI
compatibility and simplicity).
- chipcap2.c: minor code-style fixes and variable renaming.
- Link to v2: https://lore.kernel.org/r/[email protected]
Changes in v2:
- vendor-prefixes: full company name in the vendor description (Krzystof
Kozlowski)
- chipcap2.c: proper i2c_device_id table, coding style fixes, cleaner
error path in the probe function (Krzystof Kozlowski)
- dt-bindings: per-item description and lowercase names (Krzystof
Kozlowski)
- MAINTAINERS: fix manufacturer name (Krzystof Kozlowski)
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Javier Carrasco (5):
dt-bindings: vendor-prefixes: add Amphenol
hwmon: (core) Add support for humidity min/max alarm
ABI: sysfs-class-hwmon: add descriptions for humidity min/max alarms
dt-bindings: hwmon: Add Amphenol ChipCap 2
hwmon: Add support for Amphenol ChipCap 2
Documentation/ABI/testing/sysfs-class-hwmon | 18 +
.../bindings/hwmon/amphenol,chipcap2.yaml | 77 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
Documentation/hwmon/chipcap2.rst | 73 ++
Documentation/hwmon/index.rst | 1 +
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/chipcap2.c | 835 +++++++++++++++++++++
drivers/hwmon/hwmon.c | 2 +
include/linux/hwmon.h | 4 +
11 files changed, 1031 insertions(+)
---
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
change-id: 20231020-topic-chipcap2-e2d8985430c2
Best regards,
--
Javier Carrasco <[email protected]>
Add vendor prefix for Amphenol (https://www.amphenol-sensors.com)
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Javier Carrasco <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..4a49f24b906b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -105,6 +105,8 @@ patternProperties:
description: Amlogic, Inc.
"^ampere,.*":
description: Ampere Computing LLC
+ "^amphenol,.*":
+ description: Amphenol Advanced Sensors
"^ampire,.*":
description: Ampire Co., Ltd.
"^ams,.*":
--
2.39.2
Add min_alarm and max_alarm attributes for humidityX to support devices
that can generate these alarms.
Such attributes already exist for other magnitudes such as tempX.
Tested with a ChipCap 2 temperature-humidity sensor.
Signed-off-by: Javier Carrasco <[email protected]>
---
drivers/hwmon/hwmon.c | 2 ++
include/linux/hwmon.h | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index c7dd3f5b2bd5..7f92984c37d9 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -579,8 +579,10 @@ static const char * const hwmon_humidity_attr_templates[] = {
[hwmon_humidity_input] = "humidity%d_input",
[hwmon_humidity_label] = "humidity%d_label",
[hwmon_humidity_min] = "humidity%d_min",
+ [hwmon_humidity_min_alarm] = "humidity%d_min_alarm",
[hwmon_humidity_min_hyst] = "humidity%d_min_hyst",
[hwmon_humidity_max] = "humidity%d_max",
+ [hwmon_humidity_max_alarm] = "humidity%d_max_alarm",
[hwmon_humidity_max_hyst] = "humidity%d_max_hyst",
[hwmon_humidity_alarm] = "humidity%d_alarm",
[hwmon_humidity_fault] = "humidity%d_fault",
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 8cd6a6b33593..154de35e34ac 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -286,8 +286,10 @@ enum hwmon_humidity_attributes {
hwmon_humidity_input,
hwmon_humidity_label,
hwmon_humidity_min,
+ hwmon_humidity_min_alarm,
hwmon_humidity_min_hyst,
hwmon_humidity_max,
+ hwmon_humidity_max_alarm,
hwmon_humidity_max_hyst,
hwmon_humidity_alarm,
hwmon_humidity_fault,
@@ -299,8 +301,10 @@ enum hwmon_humidity_attributes {
#define HWMON_H_INPUT BIT(hwmon_humidity_input)
#define HWMON_H_LABEL BIT(hwmon_humidity_label)
#define HWMON_H_MIN BIT(hwmon_humidity_min)
+#define HWMON_H_MIN_ALARM BIT(hwmon_humidity_min_alarm)
#define HWMON_H_MIN_HYST BIT(hwmon_humidity_min_hyst)
#define HWMON_H_MAX BIT(hwmon_humidity_max)
+#define HWMON_H_MAX_ALARM BIT(hwmon_humidity_max_alarm)
#define HWMON_H_MAX_HYST BIT(hwmon_humidity_max_hyst)
#define HWMON_H_ALARM BIT(hwmon_humidity_alarm)
#define HWMON_H_FAULT BIT(hwmon_humidity_fault)
--
2.39.2
This attributes have been recently introduced and require the
corresponding ABI documentation.
Signed-off-by: Javier Carrasco <[email protected]>
---
Documentation/ABI/testing/sysfs-class-hwmon | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon
index 638f4c6d4ec7..af94c1f373de 100644
--- a/Documentation/ABI/testing/sysfs-class-hwmon
+++ b/Documentation/ABI/testing/sysfs-class-hwmon
@@ -908,6 +908,24 @@ Description:
RW
+What: /sys/class/hwmon/hwmonX/humidityY_min_alarm
+Description:
+ Minimum humidity detection
+
+ - 0: OK
+ - 1: Minimum humidity detected
+
+ RO
+
+What: /sys/class/hwmon/hwmonX/humidityY_max_alarm
+Description:
+ Maximum humidity detection
+
+ - 0: OK
+ - 1: Maximum humidity detected
+
+ RO
+
What: /sys/class/hwmon/hwmonX/humidityY_rated_min
Description:
Minimum rated humidity.
--
2.39.2
Add device tree bindings and an example for the ChipCap 2 humidity
and temperature sensor.
Reviewed-by: Conor Dooley <[email protected]>
Signed-off-by: Javier Carrasco <[email protected]>
---
.../bindings/hwmon/amphenol,chipcap2.yaml | 77 ++++++++++++++++++++++
1 file changed, 77 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
new file mode 100644
index 000000000000..17351fdbefce
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amphenol,chipcap2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChipCap 2 humidity and temperature iio sensor
+
+maintainers:
+ - Javier Carrasco <[email protected]>
+
+description: |
+ Relative humidity and temperature sensor on I2C bus.
+
+ Datasheets:
+ https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+
+properties:
+ compatible:
+ oneOf:
+ - const: amphenol,cc2d23
+ - items:
+ - enum:
+ - amphenol,cc2d23s
+ - amphenol,cc2d25
+ - amphenol,cc2d25s
+ - amphenol,cc2d33
+ - amphenol,cc2d33s
+ - amphenol,cc2d35
+ - amphenol,cc2d35s
+ - const: amphenol,cc2d23
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: measurement ready indicator
+ - description: low humidity alarm
+ - description: high humidity alarm
+
+ interrupt-names:
+ items:
+ - const: ready
+ - const: low
+ - const: high
+
+ vdd-supply:
+ description:
+ Dedicated, controllable supply-regulator to reset the device and
+ enter in command mode.
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ humidity@28 {
+ compatible = "amphenol,cc2d23s", "amphenol,cc2d23";
+ reg = <0x28>;
+ interrupt-parent = <&gpio>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>,
+ <5 IRQ_TYPE_EDGE_RISING>,
+ <6 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ready", "low", "high";
+ vdd-supply = <®_vdd>;
+ };
+ };
--
2.39.2
The Amphenol ChipCap 2 is a capacitive polymer humidity and temperature
sensor with an integrated EEPROM and minimum/maximum humidity alarms.
All device variants offer an I2C interface and depending on the part
number, two different output modes:
- CC2D: digital output
- CC2A: analog (PDM) output
This driver adds support for the digital variant (CC2D part numbers),
which includes the following part numbers:
- non-sleep measurement mode (CC2D23, CC2D25, CC2D33, CC2D35)
- sleep measurement mode (CC2D23S, CC2D25S, CC2D33S, CC2D35S)
The Chipcap 2 EEPROM can be accessed to configure a series of parameters
like the minimum/maximum humidity alarm threshold and hysteresis. The
EEPROM is only accessible in the command window after a power-on reset.
The default window lasts 10 ms if no Start_CM command is sent. After the
command window is finished (either after the mentioned timeout of after
a Start_NOM command is sent), the device enters the normal operation
mode and makes a first measurement automatically.
Unfortunately, the device does not provide any hardware or software
reset and therefore the driver must trigger power cycles to enter the
command mode. A dedicated, external regulator is required for that.
This driver keeps the device off until a measurement is required, making
use of the first automatic measurement to avoid different code paths for
sleep and non-sleep devices.
The minimum and maximum humidity alarms are configured with two
registers per alarm: one stores the alarm threshold and the other one
keeps the value that turns off the alarm. Note that the second register
stores an absolute value and not the hysteresis. The hysteresis is
therefore obtained as a subtraction of the two registers.
The alarm signals are only updated when a measurement is carried out.
Signed-off-by: Javier Carrasco <[email protected]>
---
Documentation/hwmon/chipcap2.rst | 73 ++++
Documentation/hwmon/index.rst | 1 +
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/chipcap2.c | 835 +++++++++++++++++++++++++++++++++++++++
6 files changed, 928 insertions(+)
diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
new file mode 100644
index 000000000000..dc165becc64c
--- /dev/null
+++ b/Documentation/hwmon/chipcap2.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver ChipCap2
+======================
+
+Supported chips:
+
+ * Amphenol CC2D23, CC2D23S, CC2D25, CC2D25S, CC2D33, CC2D33S, CC2D35, CC2D35S
+
+ Prefix: 'chipcap2'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+
+Author:
+
+ - Javier Carrasco <[email protected]>
+
+Description
+-----------
+
+This driver implements support for the Amphenol ChipCap 2, a humidity and
+temperature chip family. Temperature is measured in milli degrees celsius,
+relative humidity is expressed as a per cent mille. The measurement ranges
+are the following:
+
+ - Relative humidity: 0 to 100000 pcm (14-bit resolution)
+ - Temperature: -40000 to +125000 m°C (14-bit resolution)
+
+The device communicates with the I2C protocol and uses the I2C address 0x28
+by default.
+
+Depending on the hardware configuration, up to two humidity alarms to control
+minimum and maximum values are provided. Their thresholds and hystersis can be
+configured via sysfs.
+
+Thresholds and hysteris must be provided as a per cent mille. These values
+might be truncated to match the 14-bit device resolution (6.1 pcm/LSB)
+
+Known Issues
+------------
+
+The driver does not support I2C address and command window length modification.
+
+sysfs-Interface
+---------------
+
+The following list includes the sysfs attributes that the driver always provides,
+their permissions and a short description:
+
+=============================== ======= ========================================
+Name Perm Description
+=============================== ======= ========================================
+temp1_input: RO temperature input
+humidity1_input: RO humidity input
+=============================== ======= ========================================
+
+The following list includes the sysfs attributes that the driver may provide
+depending on the hardware configuration:
+
+=============================== ======= ========================================
+Name Perm Description
+=============================== ======= ========================================
+humidity1_min: RW humidity low limit. Measurements under
+ this limit trigger a humidity low alarm
+humidity1_max: RW humidity high limit. Measurements above
+ this limit trigger a humidity high alarm
+humidity1_min_hyst: RW humidity low hystersis
+humidity1_max_hyst: RW humidity high hystersis
+humidity1_min_alarm: RO humidity low alarm indicator
+humidity1_max_alarm: RO humidity high alarm indicator
+=============================== ======= ========================================
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 72f4e6065bae..35f7573b4822 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -51,6 +51,7 @@ Hardware Monitoring Kernel Drivers
bel-pfe
bpa-rs600
bt1-pvt
+ chipcap2
coretemp
corsair-cpro
corsair-psu
diff --git a/MAINTAINERS b/MAINTAINERS
index a7c4cf8201e0..e2df8b0d8424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1074,6 +1074,14 @@ F: Documentation/devicetree/bindings/perf/amlogic,g12-ddr-pmu.yaml
F: drivers/perf/amlogic/
F: include/soc/amlogic/
+AMPHENOL CHIPCAP 2 HUMIDITY-TEMPERATURE IIO DRIVER
+M: Javier Carrasco <[email protected]>
+L: [email protected]
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
+F: Documentation/hwmon/chipcap2.rst
+F: drivers/hwmon/chipcap2.c
+
AMPHION VPU CODEC V4L2 DRIVER
M: Ming Qian <[email protected]>
M: Zhou Peng <[email protected]>
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index cf27523eed5a..11b133ef2384 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -452,6 +452,16 @@ config SENSORS_BT1_PVT_ALARMS
the data conversion will be periodically performed and the data will be
saved in the internal driver cache.
+config SENSORS_CHIPCAP2
+ tristate "Amphenol ChipCap 2 relative humidity and temperature sensor"
+ depends on I2C
+ help
+ Say yes here to build support for the Amphenol ChipCap 2
+ relative humidity and temperature sensor.
+
+ To compile this driver as a module, choose M here: the module
+ will be called chipcap2.
+
config SENSORS_CORSAIR_CPRO
tristate "Corsair Commander Pro controller"
depends on HID
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index e84bd9685b5c..daf0acef1482 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o
obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o
obj-$(CONFIG_SENSORS_BT1_PVT) += bt1-pvt.o
+obj-$(CONFIG_SENSORS_CHIPCAP2) += chipcap2.o
obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
obj-$(CONFIG_SENSORS_CORSAIR_CPRO) += corsair-cpro.o
obj-$(CONFIG_SENSORS_CORSAIR_PSU) += corsair-psu.o
diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
new file mode 100644
index 000000000000..024d68485898
--- /dev/null
+++ b/drivers/hwmon/chipcap2.c
@@ -0,0 +1,835 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * cc2.c - Support for the Amphenol ChipCap 2 relative humidity, temperature sensor
+ *
+ * Part numbers supported:
+ * CC2D23, CC2D23S, CC2D25, CC2D25S, CC2D33, CC2D33S, CC2D35, CC2D35S
+ *
+ * Author: Javier Carrasco <[email protected]>
+ *
+ * Datasheet and application notes:
+ * https://www.amphenol-sensors.com/en/telaire/humidity/527-humidity-sensors/3095-chipcap-2
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/regulator/consumer.h>
+
+#define CC2_START_CM 0xA0
+#define CC2_START_NOM 0x80
+#define CC2_R_ALARM_H_ON 0x18
+#define CC2_R_ALARM_H_OFF 0x19
+#define CC2_R_ALARM_L_ON 0x1A
+#define CC2_R_ALARM_L_OFF 0x1B
+#define CC2_RW_OFFSET 0x40
+#define CC2_W_ALARM_H_ON (CC2_R_ALARM_H_ON + CC2_RW_OFFSET)
+#define CC2_W_ALARM_H_OFF (CC2_R_ALARM_H_OFF + CC2_RW_OFFSET)
+#define CC2_W_ALARM_L_ON (CC2_R_ALARM_L_ON + CC2_RW_OFFSET)
+#define CC2_W_ALARM_L_OFF (CC2_R_ALARM_L_OFF + CC2_RW_OFFSET)
+
+#define CC2_STATUS_FIELD GENMASK(7, 6)
+#define CC2_STATUS_VALID_DATA 0x00
+#define CC2_STATUS_STALE_DATA 0x01
+#define CC2_STATUS_CMD_MODE 0x02
+
+#define CC2_RESPONSE_FIELD GENMASK(1, 0)
+#define CC2_RESPONSE_BUSY 0x00
+#define CC2_RESPONSE_ACK 0x01
+#define CC2_RESPONSE_NACK 0x02
+
+#define CC2_ERR_CORR_EEPROM BIT(2)
+#define CC2_ERR_UNCORR_EEPROM BIT(3)
+#define CC2_ERR_RAM_PARITY BIT(4)
+#define CC2_ERR_CONFIG_LOAD BIT(5)
+
+#define CC2_EEPROM_SIZE 10
+#define CC2_EEPROM_DATA_LEN 3
+#define CC2_MEASUREMENT_DATA_LEN 4
+
+#define CC2_RH_DATA_FIELD GENMASK(13, 0)
+
+/* ensure clean off -> on transitions */
+#define CC2_POWER_CYCLE_MS 80
+
+#define CC2_STARTUP_TO_DATA_MS 55
+#define CC2_RESP_START_CM_US 100
+#define CC2_RESP_EEPROM_R_US 100
+#define CC2_RESP_EEPROM_W_MS 12
+#define CC2_STARTUP_TIME_US 1250
+
+#define CC2_RH_MAX (100 * 1000U)
+
+#define CC2_CM_RETRIES 5
+
+struct cc2_rh_alarm_info {
+ bool low_alarm;
+ bool high_alarm;
+ bool low_alarm_visible;
+ bool high_alarm_visible;
+};
+
+struct cc2_data {
+ struct cc2_rh_alarm_info rh_alarm;
+ struct mutex alarm_lock; /* alarm status lock */
+ struct completion complete;
+ struct device *hwmon;
+ struct i2c_client *client;
+ struct mutex dev_access_lock; /* device access lock */
+ struct regulator *regulator;
+ const char *name;
+ int irq_ready;
+ int irq_low;
+ int irq_high;
+ bool ignore_irqs;
+};
+
+enum cc2_chan_addr {
+ CC2_CHAN_TEMP = 0,
+ CC2_CHAN_HUMIDITY,
+};
+
+/* %RH as a per cent mille from a register value */
+static long cc2_rh_convert(u16 data)
+{
+ unsigned long tmp = (data & CC2_RH_DATA_FIELD) * CC2_RH_MAX;
+
+ return tmp / ((1 << 14) - 1);
+}
+
+/* convert %RH to a register value */
+static u16 cc2_rh_to_reg(long data)
+{
+ return data * ((1 << 14) - 1) / CC2_RH_MAX;
+}
+
+/* temperature in milli degrees celsius from a register value */
+static long cc2_temp_convert(u16 data)
+{
+ unsigned long tmp = ((data >> 2) * 165 * 1000U) / ((1 << 14) - 1);
+
+ return tmp - 40 * 1000U;
+}
+
+static int cc2_enable(struct cc2_data *data)
+{
+ int ret;
+
+ if (regulator_is_enabled(data->regulator))
+ return 0;
+
+ /* ignore alarms triggered by voltage toggling when powering up */
+ mutex_lock(&data->alarm_lock);
+ data->ignore_irqs = true;
+ mutex_unlock(&data->alarm_lock);
+
+ /* clear any pending completion */
+ try_wait_for_completion(&data->complete);
+
+ ret = regulator_enable(data->regulator);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * TODO: the startup-delay-us property of the regulator might be
+ * added to the delay (if provided).
+ * Currently there is no interface to read its value apart from
+ * a direct access to regulator->rdev->constraints->enable_time,
+ * which is discouraged like any direct access to the regulator_dev
+ * structure. This would be relevant in cases where the startup delay
+ * is in the range of milliseconds.
+ */
+ usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);
+
+ mutex_lock(&data->alarm_lock);
+ data->ignore_irqs = false;
+ mutex_unlock(&data->alarm_lock);
+
+ return 0;
+}
+
+static void cc2_disable(struct cc2_data *data)
+{
+ int err;
+
+ if (regulator_is_enabled(data->regulator)) {
+ err = regulator_disable(data->regulator);
+ if (err)
+ dev_dbg(&data->client->dev, "Failed to disable device");
+ }
+}
+
+static int cc2_cmd_response_diagnostic(struct device *dev, u8 status)
+{
+ int resp;
+
+ if (FIELD_GET(CC2_STATUS_FIELD, status) != CC2_STATUS_CMD_MODE) {
+ dev_dbg(dev, "Command sent out of command window\n");
+ return -ETIMEDOUT;
+ }
+
+ resp = FIELD_GET(CC2_RESPONSE_FIELD, status);
+ switch (resp) {
+ case CC2_RESPONSE_ACK:
+ return 0;
+ case CC2_RESPONSE_BUSY:
+ return -EBUSY;
+ case CC2_RESPONSE_NACK:
+ if (resp & CC2_ERR_CORR_EEPROM)
+ dev_dbg(dev, "Command failed: corrected EEPROM\n");
+ if (resp & CC2_ERR_UNCORR_EEPROM)
+ dev_dbg(dev, "Command failed: uncorrected EEPROM\n");
+ if (resp & CC2_ERR_RAM_PARITY)
+ dev_dbg(dev, "Command failed: RAM parity\n");
+ if (resp & CC2_ERR_RAM_PARITY)
+ dev_dbg(dev, "Command failed: configuration error\n");
+ return -ENODATA;
+ default:
+ dev_dbg(dev, "Unknown command reply\n");
+ return -EINVAL;
+ }
+}
+
+static int cc2_read_command_status(struct i2c_client *client)
+{
+ u8 status;
+ int ret;
+
+ ret = i2c_master_recv(client, &status, 1);
+ if (ret != 1) {
+ ret = ret < 0 ? ret : -EIO;
+ return ret;
+ }
+
+ return cc2_cmd_response_diagnostic(&client->dev, status);
+}
+
+/*
+ * The command mode is only accessible after sending the START_CM command in the
+ * first 10 ms after power-up. Only in case the command window is missed,
+ * CC2_CM_RETRIES retries are attempted before giving up and returning an error.
+ */
+static int cc2_command_mode_start(struct cc2_data *data)
+{
+ unsigned long timeout;
+ int i, ret;
+
+ for (i = 0; i < CC2_CM_RETRIES; i++) {
+ ret = cc2_enable(data);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_word_data(data->client, CC2_START_CM, 0);
+ if (ret < 0)
+ return ret;
+
+ if (data->irq_ready > 0) {
+ timeout = usecs_to_jiffies(2 * CC2_RESP_START_CM_US);
+ ret = wait_for_completion_timeout(&data->complete,
+ timeout);
+ if (!ret)
+ return -ETIMEDOUT;
+ } else {
+ usleep_range(CC2_RESP_START_CM_US,
+ 2 * CC2_RESP_START_CM_US);
+ }
+ ret = cc2_read_command_status(data->client);
+ if (ret != -ETIMEDOUT || i == CC2_CM_RETRIES)
+ break;
+
+ /* command window missed, prepare for a retry */
+ cc2_disable(data);
+ msleep(CC2_POWER_CYCLE_MS);
+ }
+
+ return ret;
+}
+
+/* Sending a Start_NOM command finishes the command mode immediately with no
+ * reply and the device enters normal operation mode
+ */
+static int cc2_command_mode_finish(struct cc2_data *data)
+{
+ int ret;
+
+ ret = i2c_smbus_write_word_data(data->client, CC2_START_NOM, 0);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int cc2_write_reg(struct cc2_data *data, u8 reg, u16 val)
+{
+ unsigned long timeout;
+ int ret;
+
+ ret = cc2_command_mode_start(data);
+ if (ret < 0)
+ goto disable;
+
+ cpu_to_be16s(&val);
+ ret = i2c_smbus_write_word_data(data->client, reg, val);
+ if (ret < 0)
+ goto disable;
+
+ if (data->irq_ready > 0) {
+ timeout = msecs_to_jiffies(2 * CC2_RESP_EEPROM_W_MS);
+ ret = wait_for_completion_timeout(&data->complete, timeout);
+ if (!ret) {
+ ret = -ETIMEDOUT;
+ goto disable;
+ }
+ } else {
+ msleep(CC2_RESP_EEPROM_W_MS);
+ }
+
+ ret = cc2_read_command_status(data->client);
+
+disable:
+ cc2_disable(data);
+
+ return ret;
+}
+
+static int cc2_read_reg(struct cc2_data *data, u8 reg, u16 *val)
+{
+ u8 buf[CC2_EEPROM_DATA_LEN];
+ unsigned long timeout;
+ int ret;
+
+ ret = cc2_command_mode_start(data);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_write_word_data(data->client, reg, 0);
+ if (ret < 0)
+ return ret;
+
+ if (data->irq_ready > 0) {
+ timeout = usecs_to_jiffies(2 * CC2_RESP_EEPROM_R_US);
+ ret = wait_for_completion_timeout(&data->complete, timeout);
+ if (!ret)
+ return -ETIMEDOUT;
+
+ } else {
+ usleep_range(CC2_RESP_EEPROM_R_US, CC2_RESP_EEPROM_R_US + 10);
+ }
+ ret = i2c_master_recv(data->client, buf, CC2_EEPROM_DATA_LEN);
+ if (ret != CC2_EEPROM_DATA_LEN)
+ return ret < 0 ? ret : -EIO;
+
+ *val = be16_to_cpup((__be16 *)&buf[1]);
+
+ return cc2_read_command_status(data->client);
+}
+
+static int cc2_get_reg_val(struct cc2_data *data, u8 reg, long *val)
+{
+ u16 reg_val;
+ int ret;
+
+ ret = cc2_read_reg(data, reg, ®_val);
+ *val = cc2_rh_convert(reg_val);
+ cc2_disable(data);
+
+ return ret;
+}
+
+static int cc2_data_fetch(struct i2c_client *client,
+ enum hwmon_sensor_types type, long *val)
+{
+ u8 data[CC2_MEASUREMENT_DATA_LEN];
+ u8 status;
+ int ret;
+
+ ret = i2c_master_recv(client, data, CC2_MEASUREMENT_DATA_LEN);
+ if (ret != CC2_MEASUREMENT_DATA_LEN) {
+ ret = ret < 0 ? ret : -EIO;
+ return ret;
+ }
+ status = FIELD_GET(CC2_STATUS_FIELD, data[0]);
+ if (status == CC2_STATUS_STALE_DATA)
+ return -EBUSY;
+
+ if (status != CC2_STATUS_VALID_DATA)
+ return -EIO;
+
+ switch (type) {
+ case hwmon_humidity:
+ *val = cc2_rh_convert(be16_to_cpup((__be16 *)&data[0]));
+ break;
+ case hwmon_temp:
+ *val = cc2_temp_convert(be16_to_cpup((__be16 *)&data[2]));
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int cc2_read_measurement(struct cc2_data *data,
+ enum hwmon_sensor_types type, long *val)
+{
+ unsigned long timeout;
+ int ret;
+
+ if (data->irq_ready > 0) {
+ timeout = msecs_to_jiffies(CC2_STARTUP_TO_DATA_MS * 2);
+ ret = wait_for_completion_timeout(&data->complete, timeout);
+ if (!ret)
+ return -ETIMEDOUT;
+
+ } else {
+ msleep(CC2_STARTUP_TO_DATA_MS);
+ }
+
+ ret = cc2_data_fetch(data->client, type, val);
+
+ return ret;
+}
+
+/*
+ * A measurement requires enabling the device, waiting for the automatic
+ * measurement to finish, reading the measurement data and disabling the device
+ * again.
+ */
+static int cc2_measurement(struct cc2_data *data, enum hwmon_sensor_types type,
+ long *val)
+{
+ int ret;
+
+ ret = cc2_enable(data);
+ if (ret)
+ return ret;
+
+ ret = cc2_read_measurement(data, type, val);
+
+ cc2_disable(data);
+
+ return ret;
+}
+
+/*
+ * In order to check alarm status, the corresponding ALARM_OFF (hysteresis)
+ * register must be read and a new measurement must be carried out to trigger
+ * the alarm signals. Given that the device carries out a measurement after
+ * exiting the command mode, there is no need to force two power-up sequences.
+ * Instead, a NOM command is sent and the device is disabled after the
+ * measurement is read.
+ */
+static int cc2_read_hyst_and_measure(struct cc2_data *data, u8 reg,
+ long *hyst, long *measurement)
+{
+ u16 reg_val;
+ int ret;
+
+ ret = cc2_read_reg(data, reg, ®_val);
+ if (ret)
+ goto disable;
+
+ *hyst = cc2_rh_convert(reg_val);
+
+ ret = cc2_command_mode_finish(data);
+ if (ret)
+ goto disable;
+
+ ret = cc2_read_measurement(data, hwmon_humidity, measurement);
+
+disable:
+ cc2_disable(data);
+
+ return ret;
+}
+
+static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct cc2_data *cc2 = data;
+
+ switch (type) {
+ case hwmon_humidity:
+ switch (attr) {
+ case hwmon_humidity_input:
+ return 0444;
+ case hwmon_humidity_min_alarm:
+ return cc2->rh_alarm.low_alarm_visible ? 0444 : 0;
+ case hwmon_humidity_max_alarm:
+ return cc2->rh_alarm.high_alarm_visible ? 0444 : 0;
+ case hwmon_humidity_min:
+ case hwmon_humidity_min_hyst:
+ return cc2->rh_alarm.low_alarm_visible ? 0644 : 0;
+ case hwmon_humidity_max:
+ case hwmon_humidity_max_hyst:
+ return cc2->rh_alarm.high_alarm_visible ? 0644 : 0;
+ default:
+ return 0;
+ }
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_input:
+ return 0444;
+ default:
+ return 0;
+ }
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static irqreturn_t cc2_ready_interrupt(int irq, void *data)
+{
+ struct cc2_data *cc2 = data;
+
+ mutex_lock(&cc2->alarm_lock);
+ if (!cc2->ignore_irqs)
+ complete(&cc2->complete);
+ mutex_unlock(&cc2->alarm_lock);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t cc2_low_interrupt(int irq, void *data)
+{
+ struct cc2_data *cc2 = data;
+
+ mutex_lock(&cc2->alarm_lock);
+ if (!cc2->ignore_irqs) {
+ hwmon_notify_event(cc2->hwmon, hwmon_humidity,
+ hwmon_humidity_min_alarm, CC2_CHAN_HUMIDITY);
+ cc2->rh_alarm.low_alarm = true;
+ }
+ mutex_unlock(&cc2->alarm_lock);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t cc2_high_interrupt(int irq, void *data)
+{
+ struct cc2_data *cc2 = data;
+
+ mutex_lock(&cc2->alarm_lock);
+ if (!cc2->ignore_irqs) {
+ hwmon_notify_event(cc2->hwmon, hwmon_humidity,
+ hwmon_humidity_max_alarm, CC2_CHAN_HUMIDITY);
+ cc2->rh_alarm.high_alarm = true;
+ }
+ mutex_unlock(&cc2->alarm_lock);
+
+ return IRQ_HANDLED;
+}
+
+static int cc2_humidity_min_alarm_status(struct cc2_data *data, long *val)
+{
+ long measurement, min_hyst;
+ int ret;
+
+ ret = cc2_read_hyst_and_measure(data, CC2_R_ALARM_L_OFF, &min_hyst,
+ &measurement);
+ if (ret < 0)
+ return ret;
+
+ if (data->rh_alarm.low_alarm) {
+ *val = (measurement < min_hyst) ? 1 : 0;
+ data->rh_alarm.low_alarm = *val;
+ } else {
+ *val = 0;
+ }
+
+ return 0;
+}
+
+static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
+{
+ long measurement, max_hyst;
+ int ret;
+
+ ret = cc2_read_hyst_and_measure(data, CC2_R_ALARM_H_OFF, &max_hyst,
+ &measurement);
+ if (ret < 0)
+ return ret;
+
+ if (data->rh_alarm.high_alarm) {
+ *val = (measurement > max_hyst) ? 1 : 0;
+ data->rh_alarm.high_alarm = *val;
+ } else {
+ *val = 0;
+ }
+
+ return 0;
+}
+
+static int cc2_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+ struct cc2_data *data = dev_get_drvdata(dev);
+ int ret = 0;
+
+ mutex_lock(&data->dev_access_lock);
+
+ switch (type) {
+ case hwmon_temp:
+ ret = cc2_measurement(data, type, val);
+ break;
+ case hwmon_humidity:
+ switch (attr) {
+ case hwmon_humidity_input:
+ ret = cc2_measurement(data, type, val);
+ break;
+ case hwmon_humidity_min:
+ ret = cc2_get_reg_val(data, CC2_R_ALARM_L_ON, val);
+ break;
+ case hwmon_humidity_min_hyst:
+ ret = cc2_get_reg_val(data, CC2_R_ALARM_L_OFF, val);
+ break;
+ case hwmon_humidity_max:
+ ret = cc2_get_reg_val(data, CC2_R_ALARM_H_ON, val);
+ break;
+ case hwmon_humidity_max_hyst:
+ ret = cc2_get_reg_val(data, CC2_R_ALARM_H_OFF, val);
+ break;
+ case hwmon_humidity_min_alarm:
+ ret = cc2_humidity_min_alarm_status(data, val);
+ break;
+ case hwmon_humidity_max_alarm:
+ ret = cc2_humidity_max_alarm_status(data, val);
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ }
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ }
+
+ mutex_unlock(&data->dev_access_lock);
+
+ return ret;
+}
+
+static int cc2_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ struct cc2_data *data = dev_get_drvdata(dev);
+ int ret;
+ u16 arg;
+ u8 cmd;
+
+ if (type != hwmon_humidity)
+ return -EOPNOTSUPP;
+
+ if (val < 0 || val > CC2_RH_MAX)
+ return -EINVAL;
+
+ mutex_lock(&data->dev_access_lock);
+
+ switch (attr) {
+ case hwmon_humidity_min:
+ cmd = CC2_W_ALARM_L_ON;
+ arg = cc2_rh_to_reg(val);
+ ret = cc2_write_reg(data, cmd, arg);
+ break;
+
+ case hwmon_humidity_min_hyst:
+ cmd = CC2_W_ALARM_L_OFF;
+ arg = cc2_rh_to_reg(val);
+ ret = cc2_write_reg(data, cmd, arg);
+ break;
+
+ case hwmon_humidity_max:
+ cmd = CC2_W_ALARM_H_ON;
+ arg = cc2_rh_to_reg(val);
+ ret = cc2_write_reg(data, cmd, arg);
+ break;
+
+ case hwmon_humidity_max_hyst:
+ cmd = CC2_W_ALARM_H_OFF;
+ arg = cc2_rh_to_reg(val);
+ ret = cc2_write_reg(data, cmd, arg);
+ break;
+
+ default:
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
+ mutex_unlock(&data->dev_access_lock);
+
+ return ret;
+}
+
+static int cc2_request_ready_irq(struct cc2_data *data, struct device *dev)
+{
+ int ret = 0;
+
+ data->irq_ready = fwnode_irq_get_byname(dev_fwnode(dev), "ready");
+ if (data->irq_ready > 0) {
+ init_completion(&data->complete);
+ ret = devm_request_threaded_irq(dev, data->irq_ready, NULL,
+ cc2_ready_interrupt,
+ IRQF_ONESHOT |
+ IRQF_TRIGGER_RISING,
+ dev_name(dev), data);
+ }
+
+ return ret;
+}
+
+static int cc2_request_alarm_irqs(struct cc2_data *data, struct device *dev)
+{
+ int ret;
+
+ data->irq_low = fwnode_irq_get_byname(dev_fwnode(dev), "low");
+ if (data->irq_low > 0) {
+ ret = devm_request_threaded_irq(dev, data->irq_low, NULL,
+ cc2_low_interrupt,
+ IRQF_ONESHOT |
+ IRQF_TRIGGER_RISING,
+ dev_name(dev), data);
+ if (!ret)
+ data->rh_alarm.low_alarm_visible = true;
+ }
+
+ data->irq_high = fwnode_irq_get_byname(dev_fwnode(dev), "high");
+ if (data->irq_high > 0) {
+ ret = devm_request_threaded_irq(dev, data->irq_high, NULL,
+ cc2_high_interrupt,
+ IRQF_ONESHOT |
+ IRQF_TRIGGER_RISING,
+ dev_name(dev), data);
+ if (!ret)
+ data->rh_alarm.high_alarm_visible = true;
+ }
+
+ return ret;
+}
+
+static const struct hwmon_channel_info *cc2_info[] = {
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
+ HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_MIN | HWMON_H_MAX |
+ HWMON_H_MIN_HYST | HWMON_H_MAX_HYST |
+ HWMON_H_MIN_ALARM | HWMON_H_MAX_ALARM),
+ NULL
+};
+
+static const struct hwmon_ops cc2_hwmon_ops = {
+ .is_visible = cc2_is_visible,
+ .read = cc2_read,
+ .write = cc2_write,
+};
+
+static const struct hwmon_chip_info cc2_chip_info = {
+ .ops = &cc2_hwmon_ops,
+ .info = cc2_info,
+};
+
+static int cc2_probe(struct i2c_client *client)
+{
+ struct cc2_data *data;
+ struct device *dev = &client->dev;
+ int ret;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
+ return -EOPNOTSUPP;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, data);
+
+ mutex_init(&data->dev_access_lock);
+ mutex_init(&data->alarm_lock);
+
+ data->client = client;
+
+ data->regulator = devm_regulator_get_exclusive(dev, "vdd");
+ if (IS_ERR(data->regulator)) {
+ dev_err_probe(dev, PTR_ERR(data->regulator),
+ "Failed to get regulator\n");
+ return PTR_ERR(data->regulator);
+ }
+
+ ret = cc2_request_ready_irq(data, dev);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to request ready irq\n");
+ return ret;
+ }
+
+ ret = cc2_request_alarm_irqs(data, dev);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to request alarm irqs\n");
+ goto disable;
+ }
+
+ data->hwmon = devm_hwmon_device_register_with_info(dev, client->name,
+ data, &cc2_chip_info,
+ NULL);
+ if (IS_ERR(data->hwmon)) {
+ dev_err_probe(dev, PTR_ERR(data->hwmon),
+ "Failed to register hwmon device\n");
+ ret = PTR_ERR(data->hwmon);
+ }
+
+disable:
+ cc2_disable(data);
+
+ return ret;
+}
+
+static void cc2_remove(struct i2c_client *client)
+{
+ struct cc2_data *data = i2c_get_clientdata(client);
+
+ cc2_disable(data);
+}
+
+static const struct i2c_device_id cc2_id[] = {
+ { "cc2d23" },
+ { "cc2d23s" },
+ { "cc2d25" },
+ { "cc2d25s" },
+ { "cc2d33" },
+ { "cc2d33s" },
+ { "cc2d35" },
+ { "cc2d35s" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, cc2_id);
+
+static const struct of_device_id cc2_of_match[] = {
+ { .compatible = "amphenol,cc2d23" },
+ { .compatible = "amphenol,cc2d23s" },
+ { .compatible = "amphenol,cc2d25" },
+ { .compatible = "amphenol,cc2d25s" },
+ { .compatible = "amphenol,cc2d33" },
+ { .compatible = "amphenol,cc2d33s" },
+ { .compatible = "amphenol,cc2d35" },
+ { .compatible = "amphenol,cc2d35s" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, cc2_of_match);
+
+static struct i2c_driver cc2_driver = {
+ .driver = {
+ .name = "cc2d23",
+ .of_match_table = cc2_of_match,
+ },
+ .probe = cc2_probe,
+ .remove = cc2_remove,
+ .id_table = cc2_id,
+};
+module_i2c_driver(cc2_driver);
+
+MODULE_AUTHOR("Javier Carrasco <[email protected]>");
+MODULE_DESCRIPTION("Amphenol ChipCap 2 humidity and temperature sensor driver");
+MODULE_LICENSE("GPL");
--
2.39.2
On Mon, Jan 15, 2024 at 09:02:25PM +0100, Javier Carrasco wrote:
> +static int cc2_enable(struct cc2_data *data)
> +{
> + int ret;
> +
> + if (regulator_is_enabled(data->regulator))
> + return 0;
This is generally a sign that the regulator API usage is not good, the
driver should not rely on references to the regulator held by anything
else since whatever else is holding the regulator on could turn it off
at any time. If the driver did the enable itself then it should know
that it did so and not need to query.
> + ret = regulator_enable(data->regulator);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * TODO: the startup-delay-us property of the regulator might be
> + * added to the delay (if provided).
> + * Currently there is no interface to read its value apart from
> + * a direct access to regulator->rdev->constraints->enable_time,
> + * which is discouraged like any direct access to the regulator_dev
> + * structure. This would be relevant in cases where the startup delay
> + * is in the range of milliseconds.
> + */
> + usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);
Note that the regulator startup delay is the time taken for the
regulator to power up so if the device needs additional delay then that
will always need to be in addition to whatever the regulator is doing.
Hello Mark,
On 18.01.24 14:49, Mark Brown wrote:
> On Mon, Jan 15, 2024 at 09:02:25PM +0100, Javier Carrasco wrote:
>
>> +static int cc2_enable(struct cc2_data *data)
>> +{
>> + int ret;
>> +
>> + if (regulator_is_enabled(data->regulator))
>> + return 0;
>
> This is generally a sign that the regulator API usage is not good, the
> driver should not rely on references to the regulator held by anything
> else since whatever else is holding the regulator on could turn it off
> at any time. If the driver did the enable itself then it should know
> that it did so and not need to query.
>
The driver handles a dedicated regulator, but I wanted to account for
the cases where the attempts to enable and disable the regulator fail
and keep parity. If the disabling attempt fails, will the regulator not
stay enabled? In that case, an additional call to regulator_enable would
not be required, right?
That is the only reason I am using regulator_is_enabled(), but maybe
things don't work like that.
>> + ret = regulator_enable(data->regulator);
>> + if (ret < 0)
>> + return ret;
>> +
>> + /*
>> + * TODO: the startup-delay-us property of the regulator might be
>> + * added to the delay (if provided).
>> + * Currently there is no interface to read its value apart from
>> + * a direct access to regulator->rdev->constraints->enable_time,
>> + * which is discouraged like any direct access to the regulator_dev
>> + * structure. This would be relevant in cases where the startup delay
>> + * is in the range of milliseconds.
>> + */
>> + usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);
>
> Note that the regulator startup delay is the time taken for the
> regulator to power up so if the device needs additional delay then that
> will always need to be in addition to whatever the regulator is doing.
What I mean by that is that the device cannot be ready until the
regulator powers it up (obvious) plus the start up time of the device
itself once it gets powered up. So if a regulator takes for example 1 ms
to power up, the sleep function could (and should) wait for 1 ms longer.
I could define a longer start up time to account for "slow" regulators
while still staying in the command window range. Retries have already
been taken into account for longer sleeps.
Thank you for your feedback.
Best regards,
Javier Carrasco
On Thu, Jan 18, 2024 at 04:30:37PM +0100, Javier Carrasco wrote:
> On 18.01.24 14:49, Mark Brown wrote:
> > On Mon, Jan 15, 2024 at 09:02:25PM +0100, Javier Carrasco wrote:
> >> +static int cc2_enable(struct cc2_data *data)
> >> +{
> >> + int ret;
> >> + if (regulator_is_enabled(data->regulator))
> >> + return 0;
> > This is generally a sign that the regulator API usage is not good, the
> > driver should not rely on references to the regulator held by anything
> > else since whatever else is holding the regulator on could turn it off
> > at any time. If the driver did the enable itself then it should know
> > that it did so and not need to query.
> The driver handles a dedicated regulator, but I wanted to account for
> the cases where the attempts to enable and disable the regulator fail
> and keep parity. If the disabling attempt fails, will the regulator not
> stay enabled? In that case, an additional call to regulator_enable would
> not be required, right?
> That is the only reason I am using regulator_is_enabled(), but maybe
> things don't work like that.
With exclusive use you can get away with this, you should have a comment
for that case though.
> >> + ret = regulator_enable(data->regulator);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + /*
> >> + * TODO: the startup-delay-us property of the regulator might be
> >> + * added to the delay (if provided).
> >> + * Currently there is no interface to read its value apart from
> >> + * a direct access to regulator->rdev->constraints->enable_time,
> >> + * which is discouraged like any direct access to the regulator_dev
> >> + * structure. This would be relevant in cases where the startup delay
> >> + * is in the range of milliseconds.
> >> + */
> >> + usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);
> > Note that the regulator startup delay is the time taken for the
> > regulator to power up so if the device needs additional delay then that
> > will always need to be in addition to whatever the regulator is doing.
> What I mean by that is that the device cannot be ready until the
> regulator powers it up (obvious) plus the start up time of the device
> itself once it gets powered up. So if a regulator takes for example 1 ms
> to power up, the sleep function could (and should) wait for 1 ms longer.
No, the sleep function should do nothing of the sort - if any delay is
neeeded for the regulator it will be handled as part of enabling the
regulator. This is not exposed to client drivers because it is
transparent to them.
On 18.01.24 17:04, Mark Brown wrote:
> On Thu, Jan 18, 2024 at 04:30:37PM +0100, Javier Carrasco wrote:
>> On 18.01.24 14:49, Mark Brown wrote:
>>> On Mon, Jan 15, 2024 at 09:02:25PM +0100, Javier Carrasco wrote:
>
>>>> +static int cc2_enable(struct cc2_data *data)
>>>> +{
>>>> + int ret;
>
>>>> + if (regulator_is_enabled(data->regulator))
>>>> + return 0;
>
>>> This is generally a sign that the regulator API usage is not good, the
>>> driver should not rely on references to the regulator held by anything
>>> else since whatever else is holding the regulator on could turn it off
>>> at any time. If the driver did the enable itself then it should know
>>> that it did so and not need to query.
>
>> The driver handles a dedicated regulator, but I wanted to account for
>> the cases where the attempts to enable and disable the regulator fail
>> and keep parity. If the disabling attempt fails, will the regulator not
>> stay enabled? In that case, an additional call to regulator_enable would
>> not be required, right?
>> That is the only reason I am using regulator_is_enabled(), but maybe
>> things don't work like that.
>
> With exclusive use you can get away with this, you should have a comment
> for that case though.
>
I will add a comment to clarify it.
>>>> + ret = regulator_enable(data->regulator);
>>>> + if (ret < 0)
>>>> + return ret;
>>>> +
>>>> + /*
>>>> + * TODO: the startup-delay-us property of the regulator might be
>>>> + * added to the delay (if provided).
>>>> + * Currently there is no interface to read its value apart from
>>>> + * a direct access to regulator->rdev->constraints->enable_time,
>>>> + * which is discouraged like any direct access to the regulator_dev
>>>> + * structure. This would be relevant in cases where the startup delay
>>>> + * is in the range of milliseconds.
>>>> + */
>>>> + usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);
>
>>> Note that the regulator startup delay is the time taken for the
>>> regulator to power up so if the device needs additional delay then that
>>> will always need to be in addition to whatever the regulator is doing.
>
>> What I mean by that is that the device cannot be ready until the
>> regulator powers it up (obvious) plus the start up time of the device
>> itself once it gets powered up. So if a regulator takes for example 1 ms
>> to power up, the sleep function could (and should) wait for 1 ms longer.
>
> No, the sleep function should do nothing of the sort - if any delay is
> neeeded for the regulator it will be handled as part of enabling the
> regulator. This is not exposed to client drivers because it is
> transparent to them.
That sounds great. Then there is no need for the comment altogether and
the TODO will go away.
Thank you again and best regards,
Javier Carrrasco