[lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Samu Onkalo]

Report output values as 1/1000 of earth gravity.

Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com>
---
 drivers/hwmon/lis3lv02d.c |   31 ++++++++++++++++++++++++++++---
 drivers/hwmon/lis3lv02d.h |    4 ++++
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/lis3lv02d.c b/drivers/hwmon/lis3lv02d.c
index be2eb97..7e72836 100644
--- a/drivers/hwmon/lis3lv02d.c
+++ b/drivers/hwmon/lis3lv02d.c
@@ -53,6 +53,19 @@
 #define LIS3_PWRON_DELAY_WAI_12B	(5000)
 #define LIS3_PWRON_DELAY_WAI_8B		(3000)
 
+/*
+ * LIS3LV02D spec says 1024 LSBs corresponds 1 G -> 1LSB is 1000/1024 mG
+ * LIS302D spec says: 18 mG / digit
+ * SCALING_ACCURACY is used to increase accuracy of the intermediate
+ * calculation results.
+ */
+#define LIS3_SCALING_ACCURACY           1024
+#define LIS3_2G2G_SENSITIVITY_WAI_12B	((LIS3_SCALING_ACCURACY * 1000) / 1024)
+#define LIS3_2G2G_SENSITIVITY_WAI_8B	(18 * LIS3_SCALING_ACCURACY)
+
+#define LIS3_DEFAULT_FUZZ		3
+#define LIS3_DEFAULT_FLAT		3
+
 struct lis3lv02d lis3_dev = {
 	.misc_wait   = __WAIT_QUEUE_HEAD_INITIALIZER(lis3_dev.misc_wait),
 };
@@ -105,11 +118,16 @@ static inline int lis3lv02d_get_axis(s8 axis, int hw_values[3])
 static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, int *x, int *y, int *z)
 {
 	int position[3];
+	int i;
 
 	position[0] = lis3->read_data(lis3, OUTX);
 	position[1] = lis3->read_data(lis3, OUTY);
 	position[2] = lis3->read_data(lis3, OUTZ);
 
+	for (i = 0; i < 3; i++)
+		position[i] = (position[i] * lis3->scale) /
+			LIS3_SCALING_ACCURACY;
+
 	*x = lis3lv02d_get_axis(lis3->ac.x, position);
 	*y = lis3lv02d_get_axis(lis3->ac.y, position);
 	*z = lis3lv02d_get_axis(lis3->ac.z, position);
@@ -385,6 +403,7 @@ int lis3lv02d_joystick_enable(void)
 {
 	struct input_dev *input_dev;
 	int err;
+	int max_val, fuzz, flat;
 
 	if (lis3_dev.idev)
 		return -EINVAL;
@@ -404,9 +423,13 @@ int lis3lv02d_joystick_enable(void)
 	input_dev->dev.parent = &lis3_dev.pdev->dev;
 
 	set_bit(EV_ABS, input_dev->evbit);
-	input_set_abs_params(input_dev, ABS_X, -lis3_dev.mdps_max_val, lis3_dev.mdps_max_val, 3, 3);
-	input_set_abs_params(input_dev, ABS_Y, -lis3_dev.mdps_max_val, lis3_dev.mdps_max_val, 3, 3);
-	input_set_abs_params(input_dev, ABS_Z, -lis3_dev.mdps_max_val, lis3_dev.mdps_max_val, 3, 3);
+	max_val = (lis3_dev.mdps_max_val * lis3_dev.scale)
+		/ LIS3_SCALING_ACCURACY;
+	fuzz = (LIS3_DEFAULT_FUZZ * lis3_dev.scale)  / LIS3_SCALING_ACCURACY;
+	flat = (LIS3_DEFAULT_FLAT * lis3_dev.scale) / LIS3_SCALING_ACCURACY;
+	input_set_abs_params(input_dev, ABS_X, -max_val, max_val, fuzz, flat);
+	input_set_abs_params(input_dev, ABS_Y, -max_val, max_val, fuzz, flat);
+	input_set_abs_params(input_dev, ABS_Z, -max_val, max_val, fuzz, flat);
 
 	err = input_register_polled_device(lis3_dev.idev);
 	if (err) {
@@ -521,12 +544,14 @@ int lis3lv02d_init_device(struct lis3lv02d *dev)
 		dev->read_data = lis3lv02d_read_12;
 		dev->mdps_max_val = 2048;
 		dev->pwron_delay = LIS3_PWRON_DELAY_WAI_12B;
+		dev->scale = LIS3_2G2G_SENSITIVITY_WAI_12B;
 		break;
 	case WAI_8B:
 		printk(KERN_INFO DRIVER_NAME ": 8 bits sensor found\n");
 		dev->read_data = lis3lv02d_read_8;
 		dev->mdps_max_val = 128;
 		dev->pwron_delay = LIS3_PWRON_DELAY_WAI_8B;
+		dev->scale = LIS3_2G2G_SENSITIVITY_WAI_8B;
 		break;
 	default:
 		printk(KERN_ERR DRIVER_NAME
diff --git a/drivers/hwmon/lis3lv02d.h b/drivers/hwmon/lis3lv02d.h
index a692116..42618b8 100644
--- a/drivers/hwmon/lis3lv02d.h
+++ b/drivers/hwmon/lis3lv02d.h
@@ -212,6 +212,10 @@ struct lis3lv02d {
 	s16 (*read_data) (struct lis3lv02d *lis3, int reg);
 	int			mdps_max_val;
 	int			pwron_delay;
+	int                     scale; /*
+					* relationship between 1 LBS and mG
+					* (1/1000th of earth gravity)
+					*/
 
 	struct input_polled_dev	*idev;     /* input device */
 	struct platform_device	*pdev;     /* platform device */
-- 
1.5.6.3


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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Daniel Mack]

On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
> Report output values as 1/1000 of earth gravity.

Without having tried that, I assume that changes the values for all
events reported? That would break all userspace clients of this device,
right?

Daniel


> Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com>
> ---
>  drivers/hwmon/lis3lv02d.c |   31 ++++++++++++++++++++++++++++---
>  drivers/hwmon/lis3lv02d.h |    4 ++++
>  2 files changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hwmon/lis3lv02d.c b/drivers/hwmon/lis3lv02d.c
> index be2eb97..7e72836 100644
> --- a/drivers/hwmon/lis3lv02d.c
> +++ b/drivers/hwmon/lis3lv02d.c
> @@ -53,6 +53,19 @@
>  #define LIS3_PWRON_DELAY_WAI_12B	(5000)
>  #define LIS3_PWRON_DELAY_WAI_8B		(3000)
>  
> +/*
> + * LIS3LV02D spec says 1024 LSBs corresponds 1 G -> 1LSB is 1000/1024 mG
> + * LIS302D spec says: 18 mG / digit
> + * SCALING_ACCURACY is used to increase accuracy of the intermediate
> + * calculation results.
> + */
> +#define LIS3_SCALING_ACCURACY           1024
> +#define LIS3_2G2G_SENSITIVITY_WAI_12B	((LIS3_SCALING_ACCURACY * 1000) / 1024)
> +#define LIS3_2G2G_SENSITIVITY_WAI_8B	(18 * LIS3_SCALING_ACCURACY)
> +
> +#define LIS3_DEFAULT_FUZZ		3
> +#define LIS3_DEFAULT_FLAT		3
> +
>  struct lis3lv02d lis3_dev = {
>  	.misc_wait   = __WAIT_QUEUE_HEAD_INITIALIZER(lis3_dev.misc_wait),
>  };
> @@ -105,11 +118,16 @@ static inline int lis3lv02d_get_axis(s8 axis, int hw_values[3])
>  static void lis3lv02d_get_xyz(struct lis3lv02d *lis3, int *x, int *y, int *z)
>  {
>  	int position[3];
> +	int i;
>  
>  	position[0] = lis3->read_data(lis3, OUTX);
>  	position[1] = lis3->read_data(lis3, OUTY);
>  	position[2] = lis3->read_data(lis3, OUTZ);
>  
> +	for (i = 0; i < 3; i++)
> +		position[i] = (position[i] * lis3->scale) /
> +			LIS3_SCALING_ACCURACY;
> +
>  	*x = lis3lv02d_get_axis(lis3->ac.x, position);
>  	*y = lis3lv02d_get_axis(lis3->ac.y, position);
>  	*z = lis3lv02d_get_axis(lis3->ac.z, position);
> @@ -385,6 +403,7 @@ int lis3lv02d_joystick_enable(void)
>  {
>  	struct input_dev *input_dev;
>  	int err;
> +	int max_val, fuzz, flat;
>  
>  	if (lis3_dev.idev)
>  		return -EINVAL;
> @@ -404,9 +423,13 @@ int lis3lv02d_joystick_enable(void)
>  	input_dev->dev.parent = &lis3_dev.pdev->dev;
>  
>  	set_bit(EV_ABS, input_dev->evbit);
> -	input_set_abs_params(input_dev, ABS_X, -lis3_dev.mdps_max_val, lis3_dev.mdps_max_val, 3, 3);
> -	input_set_abs_params(input_dev, ABS_Y, -lis3_dev.mdps_max_val, lis3_dev.mdps_max_val, 3, 3);
> -	input_set_abs_params(input_dev, ABS_Z, -lis3_dev.mdps_max_val, lis3_dev.mdps_max_val, 3, 3);
> +	max_val = (lis3_dev.mdps_max_val * lis3_dev.scale)
> +		/ LIS3_SCALING_ACCURACY;
> +	fuzz = (LIS3_DEFAULT_FUZZ * lis3_dev.scale)  / LIS3_SCALING_ACCURACY;
> +	flat = (LIS3_DEFAULT_FLAT * lis3_dev.scale) / LIS3_SCALING_ACCURACY;
> +	input_set_abs_params(input_dev, ABS_X, -max_val, max_val, fuzz, flat);
> +	input_set_abs_params(input_dev, ABS_Y, -max_val, max_val, fuzz, flat);
> +	input_set_abs_params(input_dev, ABS_Z, -max_val, max_val, fuzz, flat);
>  
>  	err = input_register_polled_device(lis3_dev.idev);
>  	if (err) {
> @@ -521,12 +544,14 @@ int lis3lv02d_init_device(struct lis3lv02d *dev)
>  		dev->read_data = lis3lv02d_read_12;
>  		dev->mdps_max_val = 2048;
>  		dev->pwron_delay = LIS3_PWRON_DELAY_WAI_12B;
> +		dev->scale = LIS3_2G2G_SENSITIVITY_WAI_12B;
>  		break;
>  	case WAI_8B:
>  		printk(KERN_INFO DRIVER_NAME ": 8 bits sensor found\n");
>  		dev->read_data = lis3lv02d_read_8;
>  		dev->mdps_max_val = 128;
>  		dev->pwron_delay = LIS3_PWRON_DELAY_WAI_8B;
> +		dev->scale = LIS3_2G2G_SENSITIVITY_WAI_8B;
>  		break;
>  	default:
>  		printk(KERN_ERR DRIVER_NAME
> diff --git a/drivers/hwmon/lis3lv02d.h b/drivers/hwmon/lis3lv02d.h
> index a692116..42618b8 100644
> --- a/drivers/hwmon/lis3lv02d.h
> +++ b/drivers/hwmon/lis3lv02d.h
> @@ -212,6 +212,10 @@ struct lis3lv02d {
>  	s16 (*read_data) (struct lis3lv02d *lis3, int reg);
>  	int			mdps_max_val;
>  	int			pwron_delay;
> +	int                     scale; /*
> +					* relationship between 1 LBS and mG
> +					* (1/1000th of earth gravity)
> +					*/
>  
>  	struct input_polled_dev	*idev;     /* input device */
>  	struct platform_device	*pdev;     /* platform device */
> -- 
> 1.5.6.3
> 

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[samu.p.onkalo]

 

>-----Original Message-----
>From: ext Daniel Mack [mailto:daniel@caiaq.de] 
>Sent: 03 November, 2009 14:17
>To: Onkalo Samu.P (Nokia-D/Tampere)
>Cc: eric.piel@tremplin-utc.net; kalhan.trisal@intel.com; 
>lm-sensors@lm-sensors.org
>Subject: Re: [RFC PATCH 09/10] lis3: Scale output values to mg
>
>On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
>> Report output values as 1/1000 of earth gravity.
>
>Without having tried that, I assume that changes the values 
>for all events reported? That would break all userspace 
>clients of this device, right?
>

Yes. That is one thing which need to agreed here. One possibility is to
implement this as a configurable feature for example using platform data.
In that kind of solution default value must be the old way.

-Samu

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Daniel Mack]

On Tue, Nov 03, 2009 at 01:30:07PM +0100, samu.p.onkalo@nokia.com wrote:
> >On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
> >> Report output values as 1/1000 of earth gravity.
> >
> >Without having tried that, I assume that changes the values 
> >for all events reported? That would break all userspace 
> >clients of this device, right?
> >
> 
> Yes. That is one thing which need to agreed here. One possibility is to
> implement this as a configurable feature for example using platform data.
> In that kind of solution default value must be the old way.

Yes please :)

Daniel


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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Éric Piel]

Op 03-11-09 13:32, Daniel Mack schreef:
> On Tue, Nov 03, 2009 at 01:30:07PM +0100, samu.p.onkalo@nokia.com wrote:
>>> On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
>>>> Report output values as 1/1000 of earth gravity.
>>> Without having tried that, I assume that changes the values 
>>> for all events reported? That would break all userspace 
>>> clients of this device, right?
>>>
>> Yes. That is one thing which need to agreed here. One possibility is to
>> implement this as a configurable feature for example using platform data.
>> In that kind of solution default value must be the old way.
> 
> Yes please :)
> 
Hello,
Actually we had already briefly discussed this with Samu. And I had
given my green light because:
 * I don't know any userspace program which would be affected by this
change (they only rely on the relative difference). Arguably, I know
only few programs.
 * Eventually, we should converge to a userspace API compatible with any
accelerometer device and exposed by all the accelerometer drivers. So
for now I consider the userspace interface of the lis3 driver quite
"soft", and any move toward this goal good.
 * Having platform data to select between old unit/new unit will add
complexity to the driver, which should be avoided whenever possible.

Of course, if you come and tell me that you know some userspace programs
which will be affected by this change, this blows away the first point.
Then I'd be much more willing to have a configurable option. But be
aware that these programs would then blow away themselves if, for
example, they expect a LIS302DL and the actual sensor is a LIS3LV02DL.
So simply fixing these programs and moving to mG might be a better option.

See you,
Eric

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[samu.p.onkalo]

 

>-----Original Message-----
>From: ext Éric Piel [mailto:eric.piel@tremplin-utc.net] 
>Sent: 03 November, 2009 15:25
>To: Daniel Mack
>Cc: Onkalo Samu.P (Nokia-D/Tampere); kalhan.trisal@intel.com; 
>lm-sensors@lm-sensors.org
>Subject: Re: [RFC PATCH 09/10] lis3: Scale output values to mg
>
>Op 03-11-09 13:32, Daniel Mack schreef:
>> On Tue, Nov 03, 2009 at 01:30:07PM +0100, 
>samu.p.onkalo@nokia.com wrote:
>>>> On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
>>>>> Report output values as 1/1000 of earth gravity.
>>>> Without having tried that, I assume that changes the 
>values for all 
>>>> events reported? That would break all userspace clients of this 
>>>> device, right?
>>>>
>>> Yes. That is one thing which need to agreed here. One 
>possibility is 
>>> to implement this as a configurable feature for example 
>using platform data.
>>> In that kind of solution default value must be the old way.
>> 
>> Yes please :)
>> 
>Hello,
>Actually we had already briefly discussed this with Samu. And 
>I had given my green light because:
> * I don't know any userspace program which would be affected 
>by this change (they only rely on the relative difference). 
>Arguably, I know only few programs.
> * Eventually, we should converge to a userspace API 
>compatible with any accelerometer device and exposed by all 
>the accelerometer drivers. So for now I consider the userspace 
>interface of the lis3 driver quite "soft", and any move toward 
>this goal good.
> * Having platform data to select between old unit/new unit 
>will add complexity to the driver, which should be avoided 
>whenever possible.
>
>Of course, if you come and tell me that you know some 
>userspace programs which will be affected by this change, this 
>blows away the first point.
>Then I'd be much more willing to have a configurable option. 
>But be aware that these programs would then blow away 
>themselves if, for example, they expect a LIS302DL and the 
>actual sensor is a LIS3LV02DL.
>So simply fixing these programs and moving to mG might be a 
>better option.
>

It is relatively simple to keep also non-scaled output. Scaling factor just need to
be set to a neutral value. Selection could be done via platform data.
Question is that what do we want to do? 

-Samu



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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Daniel Mack]

Hi,

sorry for the late catch-up on this.

On Tue, Nov 03, 2009 at 02:25:18PM +0100, Éric Piel wrote:
> >> Yes. That is one thing which need to agreed here. One possibility is to
> >> implement this as a configurable feature for example using platform data.
> >> In that kind of solution default value must be the old way.
> > 
> > Yes please :)
> > 
> Hello,
> Actually we had already briefly discussed this with Samu. And I had
> given my green light because:
>  * I don't know any userspace program which would be affected by this
> change (they only rely on the relative difference). Arguably, I know
> only few programs.

Hmm. Maybe I don't understand the change then. I thought the patch will
alter the _scale_ of the values to something more standard? If that's
the case, also applications that take relative changes will be affected,
right?

>  * Eventually, we should converge to a userspace API compatible with any
> accelerometer device and exposed by all the accelerometer drivers. So
> for now I consider the userspace interface of the lis3 driver quite
> "soft", and any move toward this goal good.
>  * Having platform data to select between old unit/new unit will add
> complexity to the driver, which should be avoided whenever possible.

True, and I'm not against dropping legacy. However, if it affects every
user space application, we cannot simply change it. I happen to be
copied in this thread, so I can react on it, but all other users are
not.

Anyway, mabye I just didn't fully understand the impact :)

Daniel

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Éric Piel]

Op 10-11-09 13:47, Daniel Mack schreef:
> Hi,
Hi
> On Tue, Nov 03, 2009 at 02:25:18PM +0100, Éric Piel wrote:
>>  * I don't know any userspace program which would be affected by this
>> change (they only rely on the relative difference). Arguably, I know
>> only few programs.
> 
> Hmm. Maybe I don't understand the change then. I thought the patch will
> alter the _scale_ of the values to something more standard? If that's
> the case, also applications that take relative changes will be affected,
> right?
Ah, yes, you are right, my mistake. Scale do change the relative
difference as well! But what I actually meant was that the programs
either look if "it's getting smaller/bigger" (aka neverball), or "it's
positive/negative" (aka rotate screen).


>>  * Eventually, we should converge to a userspace API compatible with any
>> accelerometer device and exposed by all the accelerometer drivers. So
>> for now I consider the userspace interface of the lis3 driver quite
>> "soft", and any move toward this goal good.
>>  * Having platform data to select between old unit/new unit will add
>> complexity to the driver, which should be avoided whenever possible.
> 
> True, and I'm not against dropping legacy. However, if it affects every
> user space application, we cannot simply change it. I happen to be
> copied in this thread, so I can react on it, but all other users are
> not.
Yes in general I completely agree with you: if we define some interface
that userspace is supposed to use, "we shall never change it". However,
in this specific case I'm willing to accept the possibility of breakage.
Because in the little chance that a program depends on this specific
metric it is making too much assumption on the hardware anyway: so far,
depending on the type of sensor (8b/12b, hdaps...) the values could be
very different.

Eric

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Daniel Mack]

On Tue, Nov 10, 2009 at 02:23:20PM +0100, Éric Piel wrote:
> Op 10-11-09 13:47, Daniel Mack schreef:
> > True, and I'm not against dropping legacy. However, if it affects every
> > user space application, we cannot simply change it. I happen to be
> > copied in this thread, so I can react on it, but all other users are
> > not.
> Yes in general I completely agree with you: if we define some interface
> that userspace is supposed to use, "we shall never change it". However,
> in this specific case I'm willing to accept the possibility of breakage.
> Because in the little chance that a program depends on this specific
> metric it is making too much assumption on the hardware anyway: so far,
> depending on the type of sensor (8b/12b, hdaps...) the values could be
> very different.

Does the change to the min/max parameters to input_set_abs_params()
also reflect the factor in which the multiplication factor alters?

In other words: If I scale the read value to the full range reported by
the input device - will I still get the same value before and after the
change? If that's the case, I guess the 'breakage' would be acceptable.

Daniel


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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Éric Piel]

Op 10-11-09 14:31, Daniel Mack schreef:
> Does the change to the min/max parameters to input_set_abs_params()
> also reflect the factor in which the multiplication factor alters?
> 
> In other words: If I scale the read value to the full range reported by
> the input device - will I still get the same value before and after the
> change? If that's the case, I guess the 'breakage' would be acceptable.
So your question is whether this changes the values of the joystick
interface, right? I haven't tested the patch, so Samu could probably
better answer, but looking at the code and with what I know about the
joystick subsystem, it shouldn't as the values are always scaled between
-32000 and 32000 (approximately).

[thinking further....]

So not only this means it's not going to break applications using only
the joystick interface, it also means that the whole business of scaling
the raw values for the joystick subsystem in the patch is completely
useless. Scaling to mG should be done only for the sysfs interface.

Samu, could you confirm my understanding, and fix the patch if necessary?

Eric

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Onkalo Samu]

On Tue, 2009-11-10 at 14:42 +0100, ext Éric Piel wrote:
> Op 10-11-09 14:31, Daniel Mack schreef:
> > Does the change to the min/max parameters to input_set_abs_params()
> > also reflect the factor in which the multiplication factor alters?
> > 
> > In other words: If I scale the read value to the full range reported by
> > the input device - will I still get the same value before and after the
> > change? If that's the case, I guess the 'breakage' would be acceptable.
> So your question is whether this changes the values of the joystick
> interface, right? I haven't tested the patch, so Samu could probably
> better answer, but looking at the code and with what I know about the
> joystick subsystem, it shouldn't as the values are always scaled between
> -32000 and 32000 (approximately).
> 

I test this on hw. When the values are read via /dev/input/jsx it
doesn't matter if the scaling is on or off. 
If the js_corr.type is set to JS_CORR_NONE, raw values are passed via
jstick interface and then the scaling naturally changes the scale.

This can be invisible change depending on the joystick interface
configuration. 

> [thinking further....]
> 
> So not only this means it's not going to break applications using only
> the joystick interface, it also means that the whole business of scaling
> the raw values for the joystick subsystem in the patch is completely
> useless. Scaling to mG should be done only for the sysfs interface.
> 
> Samu, could you confirm my understanding, and fix the patch if necessary?

Well, raw input values can be read also from /dev/input/eventx. In that
interface, scaling matter similarly as in sysfs. By scaling the values, 
sysfs and "raw" values from eventx would mean same thing for all the
different variants of the chip. Also if there will be a need to use full
scale is some cases (+- 8G for 8 bit and and +-6G for 12bit), meaning of
the output values are not changed if the scaling is in use.

From that point of view, scaling is not breaking joystick interface and
other users would get similar values regardless of the chip.

Br,
Samu



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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[Daniel Mack]

Hi Samu,

On Tue, Nov 03, 2009 at 01:30:07PM +0100, samu.p.onkalo@nokia.com wrote:
> Date: Tue, 3 Nov 2009 13:30:07 +0100
> From: samu.p.onkalo@nokia.com
> To: daniel@caiaq.de
> CC: eric.piel@tremplin-utc.net, kalhan.trisal@intel.com,
> 	lm-sensors@lm-sensors.org
> Subject: RE: [RFC PATCH 09/10] lis3: Scale output values to mg
> Message-ID: <62697B07E9803846BC582181BD6FB6B8256DACE233@NOK-EUMSG-02.mgdnok.nokia.com>
> 
> >On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
> >> Report output values as 1/1000 of earth gravity.
> >
> >Without having tried that, I assume that changes the values 
> >for all events reported? That would break all userspace 
> >clients of this device, right?
> >
> 
> Yes. That is one thing which need to agreed here. One possibility is to
> implement this as a configurable feature for example using platform data.
> In that kind of solution default value must be the old way.

This hits us now in user space applictions. No big deal, we will just
change our parsers. But I wonder whether you have a fix factor at hand
to apply here for calculation? I'm too lazy to reverse all the thinking
behind the conversion in order to get that number ;)

Thanks,
Daniel

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

Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg

[samu.p.onkalo]

>-----Original Message-----
>From: ext Daniel Mack [mailto:daniel@caiaq.de]
>Sent: 21 April, 2010 15:10
>To: Onkalo Samu.P (Nokia-D/Tampere)
>Cc: eric.piel@tremplin-utc.net; kalhan.trisal@intel.com; lm-sensors@lm-
>sensors.org
>Subject: Re: [RFC PATCH 09/10] lis3: Scale output values to mg
>
>Hi Samu,
>
>On Tue, Nov 03, 2009 at 01:30:07PM +0100, samu.p.onkalo@nokia.com wrote:
>> Date: Tue, 3 Nov 2009 13:30:07 +0100
>> From: samu.p.onkalo@nokia.com
>> To: daniel@caiaq.de
>> CC: eric.piel@tremplin-utc.net, kalhan.trisal@intel.com,
>> 	lm-sensors@lm-sensors.org
>> Subject: RE: [RFC PATCH 09/10] lis3: Scale output values to mg
>> Message-ID: <62697B07E9803846BC582181BD6FB6B8256DACE233@NOK-EUMSG-
>02.mgdnok.nokia.com>
>>
>> >On Tue, Nov 03, 2009 at 02:09:44PM +0200, Samu Onkalo wrote:
>> >> Report output values as 1/1000 of earth gravity.
>> >
>> >Without having tried that, I assume that changes the values
>> >for all events reported? That would break all userspace
>> >clients of this device, right?
>> >
>>
>> Yes. That is one thing which need to agreed here. One possibility is
>to
>> implement this as a configurable feature for example using platform
>data.
>> In that kind of solution default value must be the old way.
>
>This hits us now in user space applictions. No big deal, we will just
>change our parsers. But I wonder whether you have a fix factor at hand
>to apply here for calculation? I'm too lazy to reverse all the thinking
>behind the conversion in order to get that number ;)
>


For 8 bit devices:
unscaled_value * 18 = scaled_to_mg_value

For 12 bit devices:
unscaled_value * 0.977 = scaled_to_mg_value



-Samu


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