Re: [PATCH v2 2/6] hwmon: (sht3x)remove blocking_io property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jun 17, 2023 at 12:00:13AM +0800, JuenKit Yip wrote:
> Due to no support on clock-strench, blocking mode was removed and
> now single-shot mode only uses non-blocking mode.
> 
> Signed-off-by: JuenKit Yip <JuenKit_Yip@xxxxxxxxxxx>

Applied to hwmon-next.

Thanks,
Guenter

> ---
>  Documentation/hwmon/sht3x.rst | 14 ++++++--------
>  drivers/hwmon/sht3x.c         | 33 +++++++++++----------------------
>  2 files changed, 17 insertions(+), 30 deletions(-)
> 
> diff --git a/Documentation/hwmon/sht3x.rst b/Documentation/hwmon/sht3x.rst
> index 31fd36b14..be70e2543 100644
> --- a/Documentation/hwmon/sht3x.rst
> +++ b/Documentation/hwmon/sht3x.rst
> @@ -28,16 +28,14 @@ The device communicates with the I2C protocol. Sensors can have the I2C
>  addresses 0x44 or 0x45, depending on the wiring. See
>  Documentation/i2c/instantiating-devices.rst for methods to instantiate the device.
>  
> -There are two options configurable by means of sht3x_data:
> -
> -1. blocking (pull the I2C clock line down while performing the measurement) or
> -   non-blocking mode. Blocking mode will guarantee the fastest result but
> -   the I2C bus will be busy during that time. By default, non-blocking mode
> -   is used. Make sure clock-stretching works properly on your device if you
> -   want to use blocking mode.
> -2. high or low accuracy. High accuracy is used by default and using it is
> +There is only one option configurable by means of sht3x_data:
> +
> +   high or low accuracy. High accuracy is used by default and using it is
>     strongly recommended.
>  
> +Even if sht3x sensor supports clock-strech(blocking mode) and non-strench
> +(non-blocking mode) in single-shot mode, this driver only supports the latter.
> +
>  The sht3x sensor supports a single shot mode as well as 5 periodic measure
>  modes, which can be controlled with the update_interval sysfs interface.
>  The allowed update_interval in milliseconds are as follows:
> diff --git a/drivers/hwmon/sht3x.c b/drivers/hwmon/sht3x.c
> index 580704d93..bbe556f44 100644
> --- a/drivers/hwmon/sht3x.c
> +++ b/drivers/hwmon/sht3x.c
> @@ -22,12 +22,10 @@
>  #include <linux/jiffies.h>
>  
>  /* commands (high precision mode) */
> -static const unsigned char sht3x_cmd_measure_blocking_hpm[]    = { 0x2c, 0x06 };
> -static const unsigned char sht3x_cmd_measure_nonblocking_hpm[] = { 0x24, 0x00 };
> +static const unsigned char sht3x_cmd_measure_single_hpm[] = { 0x24, 0x00 };
>  
>  /* commands (low power mode) */
> -static const unsigned char sht3x_cmd_measure_blocking_lpm[]    = { 0x2c, 0x10 };
> -static const unsigned char sht3x_cmd_measure_nonblocking_lpm[] = { 0x24, 0x16 };
> +static const unsigned char sht3x_cmd_measure_single_lpm[] = { 0x24, 0x16 };
>  
>  /* commands for periodic mode */
>  static const unsigned char sht3x_cmd_measure_periodic_mode[]   = { 0xe0, 0x00 };
> @@ -41,9 +39,9 @@ static const unsigned char sht3x_cmd_heater_off[]              = { 0x30, 0x66 };
>  static const unsigned char sht3x_cmd_read_status_reg[]         = { 0xf3, 0x2d };
>  static const unsigned char sht3x_cmd_clear_status_reg[]        = { 0x30, 0x41 };
>  
> -/* delays for non-blocking i2c commands, both in us */
> -#define SHT3X_NONBLOCKING_WAIT_TIME_HPM  15000
> -#define SHT3X_NONBLOCKING_WAIT_TIME_LPM   4000
> +/* delays for single-shot mode i2c commands, both in us */
> +#define SHT3X_SINGLE_WAIT_TIME_HPM  15000
> +#define SHT3X_SINGLE_WAIT_TIME_LPM   4000
>  
>  #define SHT3X_WORD_LEN         2
>  #define SHT3X_CMD_LENGTH       2
> @@ -134,7 +132,6 @@ struct sht3x_data {
>  	const unsigned char *command;
>  	u32 wait_time;			/* in us*/
>  	unsigned long last_update;	/* last update in periodic mode*/
> -	bool blocking_io;
>  	bool high_precision;
>  
>  	/*
> @@ -432,26 +429,19 @@ static ssize_t humidity1_limit_store(struct device *dev,
>  static void sht3x_select_command(struct sht3x_data *data)
>  {
>  	/*
> -	 * In blocking mode (clock stretching mode) the I2C bus
> -	 * is blocked for other traffic, thus the call to i2c_master_recv()
> -	 * will wait until the data is ready. For non blocking mode, we
> -	 * have to wait ourselves.
> +	 * For single-shot mode, only non blocking mode is support,
> +	 * we have to wait ourselves for result.
>  	 */
>  	if (data->mode > 0) {
>  		data->command = sht3x_cmd_measure_periodic_mode;
>  		data->wait_time = 0;
> -	} else if (data->blocking_io) {
> -		data->command = data->high_precision ?
> -				sht3x_cmd_measure_blocking_hpm :
> -				sht3x_cmd_measure_blocking_lpm;
> -		data->wait_time = 0;
>  	} else {
>  		if (data->high_precision) {
> -			data->command = sht3x_cmd_measure_nonblocking_hpm;
> -			data->wait_time = SHT3X_NONBLOCKING_WAIT_TIME_HPM;
> +			data->command = sht3x_cmd_measure_single_hpm;
> +			data->wait_time = SHT3X_SINGLE_WAIT_TIME_HPM;
>  		} else {
> -			data->command = sht3x_cmd_measure_nonblocking_lpm;
> -			data->wait_time = SHT3X_NONBLOCKING_WAIT_TIME_LPM;
> +			data->command = sht3x_cmd_measure_single_lpm;
> +			data->wait_time = SHT3X_SINGLE_WAIT_TIME_LPM;
>  		}
>  	}
>  }
> @@ -689,7 +679,6 @@ static int sht3x_probe(struct i2c_client *client)
>  	if (!data)
>  		return -ENOMEM;
>  
> -	data->blocking_io = false;
>  	data->high_precision = true;
>  	data->mode = 0;
>  	data->last_update = jiffies - msecs_to_jiffies(3000);



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux