[lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Jean Delvare]

Most LM75-compatible chips can either sample much faster or with a
much better resolution than the original LM75 chip. So far the lm75
driver did not let the user take benefit of these improvements. Do it
now.

I decided to almost always configure the chip to use the best
resolution possible, which also means the longest sample time. The
only chips for which I didn't are the DS75, DS1775 and STDS75, because
they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
so I went for 11-bit mode as a more reasonable tradeoff. This choice is
dictated by the fact that the hwmon subsystem is meant for system
monitoring, it has never been supposed to be ultra-fast, and as a
matter of fact we do cache the sampled values in almost all drivers.

If anyone isn't pleased with these default settings, they can always
introduce a platform data structure or DT support for the lm75. That
being said, it seems nobody ever complained that the driver wouldn't
refresh the value faster than every 1.5 second, and the change made
it faster for all chips even in 12-bit mode, so I don't expect any
complaint.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 Documentation/hwmon/lm75 |    7 ++++---
 drivers/hwmon/lm75.c     |   42 ++++++++++++++++++++++++++++++++++++------
 2 files changed, 40 insertions(+), 9 deletions(-)

--- linux-3.9-rc2.orig/drivers/hwmon/lm75.c	2013-03-12 15:46:05.343493393 +0100
+++ linux-3.9-rc2/drivers/hwmon/lm75.c	2013-03-12 15:46:06.388517515 +0100
@@ -169,6 +169,7 @@ lm75_probe(struct i2c_client *client, co
 	int status;
 	u8 set_mask, clr_mask;
 	int new;
+	enum lm75_type kind = id->driver_data;
 
 	if (!i2c_check_functionality(client->adapter,
 			I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA))
@@ -187,30 +188,59 @@ lm75_probe(struct i2c_client *client, co
 	set_mask = 0;
 	clr_mask = LM75_SHUTDOWN;		/* continuous conversions */
 
-	switch (id->driver_data) {
+	switch (kind) {
 	case adt75:
 		clr_mask |= 1 << 5;		/* not one-shot mode */
+		data->resolution = 12;
+		data->sample_time = HZ / 8;
 		break;
 	case ds1775:
 	case ds75:
 	case stds75:
-		clr_mask |= 3 << 5;		/* 9-bit mode */
+		clr_mask |= 3 << 5;
+		set_mask |= 2 << 5;		/* 11-bit mode */
+		data->resolution = 11;
+		data->sample_time = HZ;
+		break;
+	case lm75:
+	case lm75a:
+		data->resolution = 9;
+		data->sample_time = HZ / 2;
+		break;
+	case max6625:
+		data->resolution = 9;
+		data->sample_time = HZ / 4;
+		break;
+	case max6626:
+		data->resolution = 12;
+		data->resolution_limits = 9;
+		data->sample_time = HZ / 4;
+		break;
+	case tcn75:
+		data->resolution = 9;
+		data->sample_time = HZ / 8;
 		break;
 	case mcp980x:
+		data->resolution_limits = 9;
+		/* fall through */
 	case tmp100:
 	case tmp101:
+		set_mask |= 3 << 5;		/* 12-bit mode */
+		data->resolution = 12;
+		data->sample_time = HZ;
+		clr_mask |= 1 << 7;		/* not one-shot mode */
+		break;
 	case tmp105:
 	case tmp175:
 	case tmp275:
 	case tmp75:
-		clr_mask |= 3 << 5;		/* 9-bit mode */
+		set_mask |= 3 << 5;		/* 12-bit mode */
 		clr_mask |= 1 << 7;		/* not one-shot mode */
+		data->resolution = 12;
+		data->sample_time = HZ / 2;
 		break;
 	}
 
-	data->resolution = 9;
-	data->sample_time = HZ + HZ / 2;
-
 	/* configure as specified */
 	status = lm75_read_value(client, LM75_REG_CONF);
 	if (status < 0) {
--- linux-3.9-rc2.orig/Documentation/hwmon/lm75	2013-03-12 15:09:42.543176379 +0100
+++ linux-3.9-rc2/Documentation/hwmon/lm75	2013-03-12 15:49:08.893730398 +0100
@@ -67,7 +67,8 @@ the temperature falls below the Hysteres
 All temperatures are in degrees Celsius, and are guaranteed within a
 range of -55 to +125 degrees.
 
-The LM75 only updates its values each 1.5 seconds; reading it more often
+The driver caches the values for a period varying between 1 second for the
+slowest chips and 125 ms for the fastest chips; reading it more often
 will do no harm, but will return 'old' values.
 
 The original LM75 was typically used in combination with LM78-like chips
@@ -78,8 +79,8 @@ The LM75 is essentially an industry stan
 LM75 clones not listed here, with or without various enhancements,
 that are supported. The clones are not detected by the driver, unless
 they reproduce the exact register tricks of the original LM75, and must
-therefore be instantiated explicitly. The specific enhancements (such as
-higher resolution) are not currently supported by the driver.
+therefore be instantiated explicitly. Higher resolution up to 12-bit
+is supported by this driver, other specific enhancements are not.
 
 The LM77 is not supported, contrary to what we pretended for a long time.
 Both chips are simply not compatible, value encoding differs.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Guenter Roeck]

On Tue, Mar 12, 2013 at 03:51:08PM +0100, Jean Delvare wrote:
> Most LM75-compatible chips can either sample much faster or with a
> much better resolution than the original LM75 chip. So far the lm75
> driver did not let the user take benefit of these improvements. Do it
> now.
> 
> I decided to almost always configure the chip to use the best
> resolution possible, which also means the longest sample time. The
> only chips for which I didn't are the DS75, DS1775 and STDS75, because
> they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
> so I went for 11-bit mode as a more reasonable tradeoff. This choice is
> dictated by the fact that the hwmon subsystem is meant for system
> monitoring, it has never been supposed to be ultra-fast, and as a
> matter of fact we do cache the sampled values in almost all drivers.
> 
> If anyone isn't pleased with these default settings, they can always
> introduce a platform data structure or DT support for the lm75. That
> being said, it seems nobody ever complained that the driver wouldn't
> refresh the value faster than every 1.5 second, and the change made
> it faster for all chips even in 12-bit mode, so I don't expect any
> complaint.
> 
I have been using update-interval to make it configurable.
Good example is the LM90 driver.

> Signed-off-by: Jean Delvare <khali@linux-fr.org>

Acked-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  Documentation/hwmon/lm75 |    7 ++++---
>  drivers/hwmon/lm75.c     |   42 ++++++++++++++++++++++++++++++++++++------
>  2 files changed, 40 insertions(+), 9 deletions(-)
> 
> --- linux-3.9-rc2.orig/drivers/hwmon/lm75.c	2013-03-12 15:46:05.343493393 +0100
> +++ linux-3.9-rc2/drivers/hwmon/lm75.c	2013-03-12 15:46:06.388517515 +0100
> @@ -169,6 +169,7 @@ lm75_probe(struct i2c_client *client, co
>  	int status;
>  	u8 set_mask, clr_mask;
>  	int new;
> +	enum lm75_type kind = id->driver_data;
>  
>  	if (!i2c_check_functionality(client->adapter,
>  			I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA))
> @@ -187,30 +188,59 @@ lm75_probe(struct i2c_client *client, co
>  	set_mask = 0;
>  	clr_mask = LM75_SHUTDOWN;		/* continuous conversions */
>  
> -	switch (id->driver_data) {
> +	switch (kind) {
>  	case adt75:
>  		clr_mask |= 1 << 5;		/* not one-shot mode */
> +		data->resolution = 12;
> +		data->sample_time = HZ / 8;
>  		break;
>  	case ds1775:
>  	case ds75:
>  	case stds75:
> -		clr_mask |= 3 << 5;		/* 9-bit mode */
> +		clr_mask |= 3 << 5;
> +		set_mask |= 2 << 5;		/* 11-bit mode */
> +		data->resolution = 11;
> +		data->sample_time = HZ;
> +		break;
> +	case lm75:
> +	case lm75a:
> +		data->resolution = 9;
> +		data->sample_time = HZ / 2;
> +		break;
> +	case max6625:
> +		data->resolution = 9;
> +		data->sample_time = HZ / 4;
> +		break;
> +	case max6626:
> +		data->resolution = 12;
> +		data->resolution_limits = 9;
> +		data->sample_time = HZ / 4;
> +		break;
> +	case tcn75:
> +		data->resolution = 9;
> +		data->sample_time = HZ / 8;
>  		break;
>  	case mcp980x:
> +		data->resolution_limits = 9;
> +		/* fall through */
>  	case tmp100:
>  	case tmp101:
> +		set_mask |= 3 << 5;		/* 12-bit mode */
> +		data->resolution = 12;
> +		data->sample_time = HZ;
> +		clr_mask |= 1 << 7;		/* not one-shot mode */
> +		break;
>  	case tmp105:
>  	case tmp175:
>  	case tmp275:
>  	case tmp75:
> -		clr_mask |= 3 << 5;		/* 9-bit mode */
> +		set_mask |= 3 << 5;		/* 12-bit mode */
>  		clr_mask |= 1 << 7;		/* not one-shot mode */
> +		data->resolution = 12;
> +		data->sample_time = HZ / 2;
>  		break;
>  	}
>  
> -	data->resolution = 9;
> -	data->sample_time = HZ + HZ / 2;
> -
>  	/* configure as specified */
>  	status = lm75_read_value(client, LM75_REG_CONF);
>  	if (status < 0) {
> --- linux-3.9-rc2.orig/Documentation/hwmon/lm75	2013-03-12 15:09:42.543176379 +0100
> +++ linux-3.9-rc2/Documentation/hwmon/lm75	2013-03-12 15:49:08.893730398 +0100
> @@ -67,7 +67,8 @@ the temperature falls below the Hysteres
>  All temperatures are in degrees Celsius, and are guaranteed within a
>  range of -55 to +125 degrees.
>  
> -The LM75 only updates its values each 1.5 seconds; reading it more often
> +The driver caches the values for a period varying between 1 second for the
> +slowest chips and 125 ms for the fastest chips; reading it more often
>  will do no harm, but will return 'old' values.
>  
>  The original LM75 was typically used in combination with LM78-like chips
> @@ -78,8 +79,8 @@ The LM75 is essentially an industry stan
>  LM75 clones not listed here, with or without various enhancements,
>  that are supported. The clones are not detected by the driver, unless
>  they reproduce the exact register tricks of the original LM75, and must
> -therefore be instantiated explicitly. The specific enhancements (such as
> -higher resolution) are not currently supported by the driver.
> +therefore be instantiated explicitly. Higher resolution up to 12-bit
> +is supported by this driver, other specific enhancements are not.
>  
>  The LM77 is not supported, contrary to what we pretended for a long time.
>  Both chips are simply not compatible, value encoding differs.
> 
> -- 
> Jean Delvare
> 
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Jean Delvare]

On Tue, 12 Mar 2013 08:55:16 -0700, Guenter Roeck wrote:
> On Tue, Mar 12, 2013 at 03:51:08PM +0100, Jean Delvare wrote:
> > Most LM75-compatible chips can either sample much faster or with a
> > much better resolution than the original LM75 chip. So far the lm75
> > driver did not let the user take benefit of these improvements. Do it
> > now.
> > 
> > I decided to almost always configure the chip to use the best
> > resolution possible, which also means the longest sample time. The
> > only chips for which I didn't are the DS75, DS1775 and STDS75, because
> > they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
> > so I went for 11-bit mode as a more reasonable tradeoff. This choice is
> > dictated by the fact that the hwmon subsystem is meant for system
> > monitoring, it has never been supposed to be ultra-fast, and as a
> > matter of fact we do cache the sampled values in almost all drivers.
> > 
> > If anyone isn't pleased with these default settings, they can always
> > introduce a platform data structure or DT support for the lm75. That
> > being said, it seems nobody ever complained that the driver wouldn't
> > refresh the value faster than every 1.5 second, and the change made
> > it faster for all chips even in 12-bit mode, so I don't expect any
> > complaint.
> > 
> I have been using update-interval to make it configurable.
> Good example is the LM90 driver.

Indeed. The LM90 case is a little different though, as the update rate
has an effect primarily on power consumption, and for extreme values on
accuracy if I remember correctly (due to less/no averaging.) While in
the LM75 case it has no effect on power consumption but on resolution.

Are you suggesting that I should rename lm75_data.sample_time to
update_interval, and change it from jiffies to ms, for consistency?

That I should add a read-only update_interval to report the update
interval to user-space?

That I should make the update_interval attribute writable and change
the resolution on the fly accordingly, on a per-chip basis? This
would be non-trivial, as each chip have their own conversion times for
each supported resolution.

> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> 
> Acked-by: Guenter Roeck <linux@roeck-us.net>

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Guenter Roeck]

On Tue, Mar 12, 2013 at 05:34:11PM +0100, Jean Delvare wrote:
> On Tue, 12 Mar 2013 08:55:16 -0700, Guenter Roeck wrote:
> > On Tue, Mar 12, 2013 at 03:51:08PM +0100, Jean Delvare wrote:
> > > Most LM75-compatible chips can either sample much faster or with a
> > > much better resolution than the original LM75 chip. So far the lm75
> > > driver did not let the user take benefit of these improvements. Do it
> > > now.
> > > 
> > > I decided to almost always configure the chip to use the best
> > > resolution possible, which also means the longest sample time. The
> > > only chips for which I didn't are the DS75, DS1775 and STDS75, because
> > > they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
> > > so I went for 11-bit mode as a more reasonable tradeoff. This choice is
> > > dictated by the fact that the hwmon subsystem is meant for system
> > > monitoring, it has never been supposed to be ultra-fast, and as a
> > > matter of fact we do cache the sampled values in almost all drivers.
> > > 
> > > If anyone isn't pleased with these default settings, they can always
> > > introduce a platform data structure or DT support for the lm75. That
> > > being said, it seems nobody ever complained that the driver wouldn't
> > > refresh the value faster than every 1.5 second, and the change made
> > > it faster for all chips even in 12-bit mode, so I don't expect any
> > > complaint.
> > > 
> > I have been using update-interval to make it configurable.
> > Good example is the LM90 driver.
> 
> Indeed. The LM90 case is a little different though, as the update rate
> has an effect primarily on power consumption, and for extreme values on
> accuracy if I remember correctly (due to less/no averaging.) While in
> the LM75 case it has no effect on power consumption but on resolution.
> 
Hi Jean,

There are always multiple dimensions. Sample time, resolution, accuracy,
and power consumption all interact with each other. I have been using
update_interval so far to report/configure it all. "resolution" (or possibly
tempX_resolution) was suggested as possible additional sysfs attribute
at some point.

> Are you suggesting that I should rename lm75_data.sample_time to
> update_interval, and change it from jiffies to ms, for consistency?
> 
Would be a start.

> That I should add a read-only update_interval to report the update
> interval to user-space?
> 
> That I should make the update_interval attribute writable and change
> the resolution on the fly accordingly, on a per-chip basis? This
> would be non-trivial, as each chip have their own conversion times for
> each supported resolution.
> 
Actually that was the idea, though I did not think about complexity.
If it is too complex it might not be worth the effort.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Jean Delvare]

Hi Guenter,

On Tue, 12 Mar 2013 10:26:51 -0700, Guenter Roeck wrote:
> On Tue, Mar 12, 2013 at 05:34:11PM +0100, Jean Delvare wrote:
> > Indeed. The LM90 case is a little different though, as the update rate
> > has an effect primarily on power consumption, and for extreme values on
> > accuracy if I remember correctly (due to less/no averaging.) While in
> > the LM75 case it has no effect on power consumption but on resolution.
>
> There are always multiple dimensions. Sample time, resolution, accuracy,
> and power consumption all interact with each other. I have been using
> update_interval so far to report/configure it all. "resolution" (or possibly
> tempX_resolution) was suggested as possible additional sysfs attribute
> at some point.
> 
> > Are you suggesting that I should rename lm75_data.sample_time to
> > update_interval, and change it from jiffies to ms, for consistency?
>
> Would be a start.

I slept over it and I don't think I'll do that change. lm90's
update_interval refers to how frequently the chip starts a new
measurement. The chips supported by this driver don't do continuous
sampling, they sleep between measurements. The conversion time is
constant.

lm75's sample_time is for how long the driver can cache the values. I
ensured that it was always larger than the maximum possible conversion
time, but for some of the supported chips this maximum is a lot more
than the typical conversion time. LM75-like chips do continuous
sampling, and we don't know the exact conversion time, so we simply
don't know the update_interval value. All we can do is estimate its
maximum.

So it's not as simple as renaming a variable, changing its unit and
exporting it to sysfs. Some more thinking and care is required, which I
have no time for ATM.

> > That I should add a read-only update_interval to report the update
> > interval to user-space?
> > 
> > That I should make the update_interval attribute writable and change
> > the resolution on the fly accordingly, on a per-chip basis? This
> > would be non-trivial, as each chip have their own conversion times for
> > each supported resolution.
>
> Actually that was the idea, though I did not think about complexity.
> If it is too complex it might not be worth the effort.

For me it's not worth it. I think my patches already represent a
significant improvement to the lm75 driver, it will make readings
faster and more accurate out of the box. I don't want to spend more
time on this, I'd rather spend time reviewing pending patches ;)

Of course if someone else steps up later to work on this, I have no
objection.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Guenter Roeck]

On Wed, Mar 13, 2013 at 12:15:16PM +0100, Jean Delvare wrote:
> Hi Guenter,
> 
Hi Jean,

> > If it is too complex it might not be worth the effort.
> 
> For me it's not worth it. I think my patches already represent a
> significant improvement to the lm75 driver, it will make readings
> faster and more accurate out of the box. I don't want to spend more

Makes sense.

> time on this, I'd rather spend time reviewing pending patches ;)
> 
Does that mean I can now submit the 20-something patches I didn't bother
to submit due to lack of reviewers ? Just asking :-)

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Jean Delvare]

On Wed, 13 Mar 2013 14:50:40 -0700, Guenter Roeck wrote:
> Does that mean I can now submit the 20-something patches I didn't bother
> to submit due to lack of reviewers ? Just asking :-)

Nah, I'd rather review the patches you've already sent... starting with
ltc2978 and coretemp.

Which doesn't prevent you from posting patches anyway. And even pushing
them upstream if nobody has time to review them and you're confident
they'll do more good than harm.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Guenter Roeck]

On Wed, Mar 13, 2013 at 10:56:12PM +0100, Jean Delvare wrote:
> On Wed, 13 Mar 2013 14:50:40 -0700, Guenter Roeck wrote:
> > Does that mean I can now submit the 20-something patches I didn't bother
> > to submit due to lack of reviewers ? Just asking :-)
> 
> Nah, I'd rather review the patches you've already sent... starting with
> ltc2978 and coretemp.
> 
> Which doesn't prevent you from posting patches anyway. And even pushing
> them upstream if nobody has time to review them and you're confident
> they'll do more good than harm.
> 
I might actually do that at some point.

Key question right now though is what to do with the nct6775 driver ...
I would really like to get it off my back. It just seems impossible
to get anyone to review it. Not really surprising given its size.
On the other side there is real demand for it, to the point that
at least archlinux already provides it. I wonder if I should just
push it into 3.10 and wait for any fallout. Do you have an opinion ?

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Jean Delvare]

On Wed, 13 Mar 2013 16:16:36 -0700, Guenter Roeck wrote:
> Key question right now though is what to do with the nct6775 driver ...
> I would really like to get it off my back. It just seems impossible
> to get anyone to review it. Not really surprising given its size.
> On the other side there is real demand for it, to the point that
> at least archlinux already provides it. I wonder if I should just
> push it into 3.10 and wait for any fallout. Do you have an opinion ?

Yes, please push it into 3.10. It's a new driver, so you're not going
to cause any regression. Worst case, driver doesn't work properly for
some users, or some feature is broken, this can't really be worse than
having no driver at all.

And if this ultimately lets us remove support for some chips from the
w83627ehf driver and make it look sane again, I'm all for it.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Guenter Roeck]

On Thu, Mar 14, 2013 at 08:28:57AM +0100, Jean Delvare wrote:
> On Wed, 13 Mar 2013 16:16:36 -0700, Guenter Roeck wrote:
> > Key question right now though is what to do with the nct6775 driver ...
> > I would really like to get it off my back. It just seems impossible
> > to get anyone to review it. Not really surprising given its size.
> > On the other side there is real demand for it, to the point that
> > at least archlinux already provides it. I wonder if I should just
> > push it into 3.10 and wait for any fallout. Do you have an opinion ?
> 
> Yes, please push it into 3.10. It's a new driver, so you're not going
> to cause any regression. Worst case, driver doesn't work properly for
> some users, or some feature is broken, this can't really be worse than
> having no driver at all.
> 
Ok, I'll do that.

> And if this ultimately lets us remove support for some chips from the
> w83627ehf driver and make it look sane again, I'm all for it.
> 
Makes sense. This also makes one of the patches I submitted for w83627ehf
unnecessary, as it affects nct6775/nct6776 support.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Jean Delvare]

On Thu, 14 Mar 2013 08:16:28 -0700, Guenter Roeck wrote:
> On Thu, Mar 14, 2013 at 08:28:57AM +0100, Jean Delvare wrote:
> > And if this ultimately lets us remove support for some chips from the
> > w83627ehf driver and make it look sane again, I'm all for it.
> 
> Makes sense. This also makes one of the patches I submitted for w83627ehf
> unnecessary, as it affects nct6775/nct6776 support.

Not necessarily an issue, having both drivers overlap for a period of
time is desirable for smooth transition.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [PATCH 4/5] hwmon: (lm75) Tune resolution and sample time per chip

[Guenter Roeck]

On Thu, Mar 14, 2013 at 04:22:05PM +0100, Jean Delvare wrote:
> On Thu, 14 Mar 2013 08:16:28 -0700, Guenter Roeck wrote:
> > On Thu, Mar 14, 2013 at 08:28:57AM +0100, Jean Delvare wrote:
> > > And if this ultimately lets us remove support for some chips from the
> > > w83627ehf driver and make it look sane again, I'm all for it.
> > 
> > Makes sense. This also makes one of the patches I submitted for w83627ehf
> > unnecessary, as it affects nct6775/nct6776 support.
> 
> Not necessarily an issue, having both drivers overlap for a period of
> time is desirable for smooth transition.
> 
Agreed. More a matter of time needed for the code review. I'll let you decide.

Dropping nct6775/nct6776 from the w83627ehf driver will reduce its size
by more than 500 LOC, and its size by more than 7k (49k -> 41.5k) on x86_64.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors