All of lore.kernel.org
 help / color / mirror / Atom feed
* [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
@ 2009-08-11  8:13 Kalhan Trisal
  2009-08-11 13:29 ` Cory T. Tusar
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: Kalhan Trisal @ 2009-08-11  8:13 UTC (permalink / raw)
  To: lm-sensors

From 2d11a9f666b7477cc8faca0f055f4477f328516f Mon Sep 17 00:00:00 2001
From: Kalhan Trisal <kalhan.trisal@intel.com>
Date: Tue, 11 Aug 2009 14:28:32 -0400
Subject: [PATCH] Intersil ISL29020 ALS driver
ALS driver will read the latest Lux measurement based on the light brightness and will report the LUX output through sysfs interface.

Signed-off-by: Kalhan Trisal <kalhan.trisal@intel.com>

---
 drivers/hwmon/Kconfig    |   11 ++
 drivers/hwmon/Makefile   |    1 +
 drivers/hwmon/isl29020.c |  237 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 249 insertions(+), 0 deletions(-)
 create mode 100755 drivers/hwmon/isl29020.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 2d50166..c89f1f6 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1017,6 +1017,17 @@ config SENSORS_APPLESMC
 	  Say Y here if you have an applicable laptop and want to experience
 	  the awesome power of applesmc.
 
+config SENSORS_ISL29020
+	tristate "Intersil ISL29020 ALS"
+	depends on I2C_MRST
+	default n
+	help
+	  If you say yes here you get support for the ALS Devices
+	  Ambient Light Sensor monitoring chip.
+	  Range values can be configured using sysfs.
+	  Lux Data are  accessible via sysfs.
+
+
 config HWMON_DEBUG_CHIP
 	bool "Hardware Monitoring Chip debugging messages"
 	default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index b793dce..3b1e424 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_SENSORS_VT8231)	+= vt8231.o
 obj-$(CONFIG_SENSORS_W83627EHF)	+= w83627ehf.o
 obj-$(CONFIG_SENSORS_W83L785TS)	+= w83l785ts.o
 obj-$(CONFIG_SENSORS_W83L786NG)	+= w83l786ng.o
+obj-$(CONFIG_SENSORS_LIS331DL)	+= lis331dl.o
 
 ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
 EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/hwmon/isl29020.c b/drivers/hwmon/isl29020.c
new file mode 100755
index 0000000..162dcb1
--- /dev/null
+++ b/drivers/hwmon/isl29020.c
@@ -0,0 +1,237 @@
+/*
+ * isl29020.c - Intersil  ALS Driver
+ *
+ * Copyright (C) 2008 Intel Corp
+ *
+ *  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/hwmon-vid.h>
+#include <linux/err.h>
+#include <linux/delay.h>
+#include <linux/mutex.h>
+#include <linux/sysfs.h>
+
+MODULE_AUTHOR("Kalhan Trisal <kalhan.trisal@intel.com");
+MODULE_DESCRIPTION("intersil isl29020 ALS Driver");
+MODULE_LICENSE("GPL v2");
+
+#define ALS_MIN_RANGE_VAL 0
+#define ALS_MAX_RANGE_VAL 5
+#define POWER_STA_ENABLE 1
+#define POWER_STA_DISABLE 0
+
+struct als_data {
+	struct device *hwmon_dev;
+};
+
+static unsigned int i2c_write_current_data(struct i2c_client *client,
+					unsigned int reg, unsigned int value)
+{
+	int ret_val;
+
+	ret_val = i2c_smbus_write_byte_data(client, reg, value);
+	return ret_val;
+}
+
+static ssize_t als_sensing_range_show(struct device *dev,
+			struct device_attribute *attr,  char *buf)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	int  val;
+
+	val = i2c_smbus_read_byte_data(client, 0x00);
+	return sprintf(buf, "%d000\n", 1 << (2 * (val & 3)));
+
+}
+
+static ssize_t als_lux_output_data_show(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	unsigned int ret_val, val;
+	unsigned long int lux, max_count;
+	int tempv1, tempv2;
+
+	max_count = 65535;
+	tempv1 = i2c_smbus_read_byte_data(client, 0x02); /* MSB data */
+	tempv2 = i2c_smbus_read_byte_data(client, 0x01); /* LSB data */
+	ret_val = tempv1;
+	ret_val = (ret_val << 8 | tempv2);
+	val = i2c_smbus_read_byte_data(client, 0x00);
+	lux = ((((1 << (2 * (val & 3))))*1000) * ret_val) / max_count;
+	return sprintf(buf, "%ld\n", lux);
+}
+
+static ssize_t als_sensing_range_store(struct device *dev,
+		struct device_attribute *attr, const  char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	unsigned int ret_val;
+	unsigned long val;
+
+	if (strict_strtoul(buf, 10, &val))
+		return -EINVAL;
+	ret_val = i2c_smbus_read_byte_data(client, 0x00);
+	ret_val = ret_val & 0xFC; /*reset the bit before setting them */
+	if (val < 1 || val > 4)
+		return -EINVAL;
+	i2c_write_current_data(client, 0x00, ret_val | (val - 1));
+	return count;
+}
+
+static ssize_t als_power_status_show(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	int ret_val;
+
+	ret_val = i2c_smbus_read_byte_data(client, 0x00);
+	ret_val = ret_val & 0x80;
+	if (ret_val = 0x80)
+		ret_val = 1;
+	return sprintf(buf, "%x", ret_val);
+}
+
+static ssize_t als_power_status_store(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	unsigned long val = 0;
+	char curr_val;
+
+	if (strict_strtoul(buf, 10, &val))
+		return -EINVAL;
+
+	curr_val = i2c_smbus_read_byte_data(client, 0x00);
+	if (val = POWER_STA_ENABLE)
+		curr_val = curr_val | 0x80;
+	else if (val = POWER_STA_DISABLE)
+		curr_val = curr_val & 0x7F;
+	else
+		return -EINVAL;
+	i2c_write_current_data(client, 0x00, curr_val);
+	return count;
+}
+
+static DEVICE_ATTR(sensing_range, S_IRUGO | S_IWUSR,
+	als_sensing_range_show, als_sensing_range_store);
+static DEVICE_ATTR(lux_output, S_IRUGO, als_lux_output_data_show, NULL);
+static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR,
+	als_power_status_show, als_power_status_store);
+
+static struct attribute *mid_att_als[] = {
+	&dev_attr_sensing_range.attr,
+	&dev_attr_lux_output.attr,
+	&dev_attr_power_state.attr,
+	NULL
+};
+
+static struct attribute_group m_als_gr = {
+	.name = "isl29020",
+	.attrs = mid_att_als
+};
+
+static void als_set_default_config(struct i2c_client *client)
+{
+	i2c_write_current_data(client, 0x00, 0xc0);
+}
+
+static int  isl29020_probe(struct i2c_client *client,
+					const struct i2c_device_id *id)
+{
+	int res;
+	struct als_data *data;
+
+	data = kzalloc(sizeof(struct als_data), GFP_KERNEL);
+	if (data = NULL) {
+		printk(KERN_WARNING " isl29020: Memory initialization failed");
+		return -ENOMEM;
+	}
+	i2c_set_clientdata(client, data);
+
+	res = sysfs_create_group(&client->dev.kobj, &m_als_gr);
+	if (res) {
+		printk(KERN_WARNING "isl29020: device create file failed!!\n");
+		goto als_error1;
+	}
+	data->hwmon_dev = hwmon_device_register(&client->dev);
+	if (IS_ERR(data->hwmon_dev)) {
+		res = PTR_ERR(data->hwmon_dev);
+		data->hwmon_dev = NULL;
+		sysfs_remove_group(&client->dev.kobj, &m_als_gr);
+		printk(KERN_ALERT "isl29020:unable to register hwmon device\n");
+		goto als_error1;
+	}
+	dev_info(&client->dev, "%s isl29020: ALS chip found \n", client->name);
+	als_set_default_config(client);
+	return res;
+
+als_error1:
+	i2c_set_clientdata(client, NULL);
+	kfree(data);
+	return res;
+}
+
+static int isl29020_remove(struct i2c_client *client)
+{
+	struct als_data *data = i2c_get_clientdata(client);
+
+	hwmon_device_unregister(data->hwmon_dev);
+	sysfs_remove_group(&client->dev.kobj, &m_als_gr);
+	kfree(data);
+	return 0;
+}
+
+static struct i2c_device_id isl29020_id[] = {
+	{ "i2c_als", 0 },
+	{ }
+};
+
+MODULE_DEVICE_TABLE(i2c, isl29020_id);
+
+static struct i2c_driver isl29020_driver = {
+	.driver = {
+	.name = "isl29020",
+	},
+	.probe = isl29020_probe,
+	.remove = isl29020_remove,
+	.id_table = isl29020_id,
+};
+
+static int __init sensor_isl29020_init(void)
+{
+	int res;
+
+	res = i2c_add_driver(&isl29020_driver);
+	return res;
+}
+
+static void  __exit sensor_isl29020_exit(void)
+{
+	i2c_del_driver(&isl29020_driver);
+}
+
+module_init(sensor_isl29020_init);
+module_exit(sensor_isl29020_exit);
-- 
1.6.0.6


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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
@ 2009-08-11 13:29 ` Cory T. Tusar
  2009-08-13 10:56 ` Trisal, Kalhan
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Cory T. Tusar @ 2009-08-11 13:29 UTC (permalink / raw)
  To: lm-sensors

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kalhan Trisal wrote:
>>From 2d11a9f666b7477cc8faca0f055f4477f328516f Mon Sep 17 00:00:00 2001
> From: Kalhan Trisal <kalhan.trisal@intel.com>
> Date: Tue, 11 Aug 2009 14:28:32 -0400
> Subject: [PATCH] Intersil ISL29020 ALS driver
> ALS driver will read the latest Lux measurement based on the light brightness and will report the LUX output through sysfs interface.
> 
> Signed-off-by: Kalhan Trisal <kalhan.trisal@intel.com>
> 
> ---
>  drivers/hwmon/Kconfig    |   11 ++
>  drivers/hwmon/Makefile   |    1 +
>  drivers/hwmon/isl29020.c |  237 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 249 insertions(+), 0 deletions(-)
>  create mode 100755 drivers/hwmon/isl29020.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 2d50166..c89f1f6 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1017,6 +1017,17 @@ config SENSORS_APPLESMC
>           Say Y here if you have an applicable laptop and want to experience
>           the awesome power of applesmc.
> 
> +config SENSORS_ISL29020
> +       tristate "Intersil ISL29020 ALS"
> +       depends on I2C_MRST

Is there a reason you're hardcoding a Moorestown dependency here?

> +       default n
> +       help
> +         If you say yes here you get support for the ALS Devices
> +         Ambient Light Sensor monitoring chip.
> +         Range values can be configured using sysfs.
> +         Lux Data are  accessible via sysfs.
> +
> +
>  config HWMON_DEBUG_CHIP
>         bool "Hardware Monitoring Chip debugging messages"
>         default n
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index b793dce..3b1e424 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -89,6 +89,7 @@ obj-$(CONFIG_SENSORS_VT8231)  += vt8231.o
>  obj-$(CONFIG_SENSORS_W83627EHF)        += w83627ehf.o
>  obj-$(CONFIG_SENSORS_W83L785TS)        += w83l785ts.o
>  obj-$(CONFIG_SENSORS_W83L786NG)        += w83l786ng.o
> +obj-$(CONFIG_SENSORS_LIS331DL) += lis331dl.o

This appears to be incorrect.

> 
>  ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
>  EXTRA_CFLAGS += -DDEBUG
> diff --git a/drivers/hwmon/isl29020.c b/drivers/hwmon/isl29020.c
> new file mode 100755
> index 0000000..162dcb1
> --- /dev/null
> +++ b/drivers/hwmon/isl29020.c

Would this driver be better placed in drivers/misc, alongside the
similar ils29003 driver?

- -Cory


- -- 
Cory T. Tusar
Senior Software Engineer
Videon Central, Inc.
2171 Sandy Drive
State College, PA 16803
(814) 235-1111 x316
(814) 235-1118 fax


"There are two ways of constructing a software design.  One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies."  --Sir Charles Anthony Richard Hoare

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqBckwACgkQHT1tsfGwHJ/68QCfY9RgbwotuijyABAFacG9ogQi
NvwAoJl2u9cunjoBEJBST4GqKpHiID9a
=ldQN
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
  2009-08-11 13:29 ` Cory T. Tusar
@ 2009-08-13 10:56 ` Trisal, Kalhan
  2009-09-02 12:51 ` Jean Delvare
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Trisal, Kalhan @ 2009-08-13 10:56 UTC (permalink / raw)
  To: lm-sensors

This driver used Hwmon interface , I don't find the ils29003 registering with hwmon. I still believe this should be part of hwmon group.

Thanks 
Kalhan 

-----Original Message-----
From: Cory T. Tusar [mailto:ctusar@videon-central.com] 
Sent: Tuesday, August 11, 2009 7:00 PM
To: Trisal, Kalhan
Cc: lm-sensors@lm-sensors.org; alan@linux.intel.com
Subject: Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kalhan Trisal wrote:
>>From 2d11a9f666b7477cc8faca0f055f4477f328516f Mon Sep 17 00:00:00 2001
> From: Kalhan Trisal <kalhan.trisal@intel.com>
> Date: Tue, 11 Aug 2009 14:28:32 -0400
> Subject: [PATCH] Intersil ISL29020 ALS driver
> ALS driver will read the latest Lux measurement based on the light brightness and will report the LUX output through sysfs interface.
> 
> Signed-off-by: Kalhan Trisal <kalhan.trisal@intel.com>
> 
> ---
>  drivers/hwmon/Kconfig    |   11 ++
>  drivers/hwmon/Makefile   |    1 +
>  drivers/hwmon/isl29020.c |  237 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 249 insertions(+), 0 deletions(-)
>  create mode 100755 drivers/hwmon/isl29020.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 2d50166..c89f1f6 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1017,6 +1017,17 @@ config SENSORS_APPLESMC
>           Say Y here if you have an applicable laptop and want to experience
>           the awesome power of applesmc.
> 
> +config SENSORS_ISL29020
> +       tristate "Intersil ISL29020 ALS"
> +       depends on I2C_MRST

Is there a reason you're hardcoding a Moorestown dependency here?

> +       default n
> +       help
> +         If you say yes here you get support for the ALS Devices
> +         Ambient Light Sensor monitoring chip.
> +         Range values can be configured using sysfs.
> +         Lux Data are  accessible via sysfs.
> +
> +
>  config HWMON_DEBUG_CHIP
>         bool "Hardware Monitoring Chip debugging messages"
>         default n
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index b793dce..3b1e424 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -89,6 +89,7 @@ obj-$(CONFIG_SENSORS_VT8231)  += vt8231.o
>  obj-$(CONFIG_SENSORS_W83627EHF)        += w83627ehf.o
>  obj-$(CONFIG_SENSORS_W83L785TS)        += w83l785ts.o
>  obj-$(CONFIG_SENSORS_W83L786NG)        += w83l786ng.o
> +obj-$(CONFIG_SENSORS_LIS331DL) += lis331dl.o

This appears to be incorrect.

> 
>  ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
>  EXTRA_CFLAGS += -DDEBUG
> diff --git a/drivers/hwmon/isl29020.c b/drivers/hwmon/isl29020.c
> new file mode 100755
> index 0000000..162dcb1
> --- /dev/null
> +++ b/drivers/hwmon/isl29020.c

Would this driver be better placed in drivers/misc, alongside the
similar ils29003 driver?

- -Cory


- -- 
Cory T. Tusar
Senior Software Engineer
Videon Central, Inc.
2171 Sandy Drive
State College, PA 16803
(814) 235-1111 x316
(814) 235-1118 fax


"There are two ways of constructing a software design.  One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies."  --Sir Charles Anthony Richard Hoare

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqBckwACgkQHT1tsfGwHJ/68QCfY9RgbwotuijyABAFacG9ogQi
NvwAoJl2u9cunjoBEJBST4GqKpHiID9a
=ldQN
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
  2009-08-11 13:29 ` Cory T. Tusar
  2009-08-13 10:56 ` Trisal, Kalhan
@ 2009-09-02 12:51 ` Jean Delvare
  2009-09-02 15:26 ` Jonathan Cameron
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Jean Delvare @ 2009-09-02 12:51 UTC (permalink / raw)
  To: lm-sensors

On Thu, 13 Aug 2009 16:22:29 +0530, Trisal, Kalhan wrote:
> This driver used Hwmon interface ,

No, it doesn't. It registers as a hwmon device but it doesn't implement
_any_ feature listed in Documentation/hwmon/sysfs-interface. Which can
be easily explained: your device is not a hardware monitoring device.

> I don't find the ils29003 registering with hwmon. I still believe
> this should be part of hwmon group.

No, it shouldn't. hwmon is for hardware monitoring. Other sensor types
must find a different home.

-- 
Jean Delvare

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
                   ` (2 preceding siblings ...)
  2009-09-02 12:51 ` Jean Delvare
@ 2009-09-02 15:26 ` Jonathan Cameron
  2009-09-02 20:07 ` Pavel Machek
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Jonathan Cameron @ 2009-09-02 15:26 UTC (permalink / raw)
  To: lm-sensors

Jean Delvare wrote:
> On Thu, 13 Aug 2009 16:22:29 +0530, Trisal, Kalhan wrote:
>> This driver used Hwmon interface ,
> 
> No, it doesn't. It registers as a hwmon device but it doesn't implement
> _any_ feature listed in Documentation/hwmon/sysfs-interface. Which can
> be easily explained: your device is not a hardware monitoring device.
> 
>> I don't find the ils29003 registering with hwmon. I still believe
>> this should be part of hwmon group.
> 
> No, it shouldn't. hwmon is for hardware monitoring. Other sensor types
> must find a different home.
For info current options I know of:

1) drivers/misc (where the isl290003 is, previously intention was to possibly
move this to iio when / if that gets merged)

2) drivers/staging/iio/light (tsl2561) I'm happy with more light sensors
in there, though the interface might need some hammering out.  Currently none
of them are using any iio specific features so can certainly go elsewhere
if people would prefer. In my personal view a lot of the processing currently
in the various drivers ought not to be in the kernel, but that's a different
matter)  IIO is currently in Greg KH's tree.

3) drivers/als (acpi ambient light sensor - latest version posted to lkml a couple
of days ago - now in acpi-testing I think)  This one is a bit different, but perhaps
a conversation needs to be opened with them to see if the requirements overlap
sufficiently to use a shared framework.) I've copied in those most active in the
discussion on that. (sorry all if you aren't interested!)

Places that aren't an option.

drivers/i2c/chips as thats going aways shortly. tsl2550 driver will have to
move out of there.
Hwmon for the reasons Jean just stated.

Any others out there?

Worth starting a more detailed discussion on a unified framework / location
for these sort of sensors?  (lkml probably)

Cheers,

Jonathan





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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
                   ` (3 preceding siblings ...)
  2009-09-02 15:26 ` Jonathan Cameron
@ 2009-09-02 20:07 ` Pavel Machek
  2009-09-03  3:35 ` Zhang Rui
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Pavel Machek @ 2009-09-02 20:07 UTC (permalink / raw)
  To: lm-sensors

Hi!

> > No, it shouldn't. hwmon is for hardware monitoring. Other sensor types
> > must find a different home.
> For info current options I know of:
> 
> 1) drivers/misc (where the isl290003 is, previously intention was to possibly
> move this to iio when / if that gets merged)
> 
> 2) drivers/staging/iio/light (tsl2561) I'm happy with more light sensors
> in there, though the interface might need some hammering out.  Currently none
> of them are using any iio specific features so can certainly go elsewhere
> if people would prefer. In my personal view a lot of the processing currently
> in the various drivers ought not to be in the kernel, but that's a different
> matter)  IIO is currently in Greg KH's tree.
> 
> 3) drivers/als (acpi ambient light sensor - latest version posted to lkml a couple
> of days ago - now in acpi-testing I think)  This one is a bit different, but perhaps
> a conversation needs to be opened with them to see if the requirements overlap
> sufficiently to use a shared framework.) I've copied in those most active in the
> discussion on that. (sorry all if you aren't interested!)

How is acpi als different from issue at hand? We certainly want
generic enough als class to handle acpi and common devices...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
                   ` (4 preceding siblings ...)
  2009-09-02 20:07 ` Pavel Machek
@ 2009-09-03  3:35 ` Zhang Rui
  2009-09-03 10:51 ` Jean Delvare
  2009-09-03 12:50 ` Jonathan Cameron
  7 siblings, 0 replies; 9+ messages in thread
From: Zhang Rui @ 2009-09-03  3:35 UTC (permalink / raw)
  To: lm-sensors

On Wed, 2009-09-02 at 23:26 +0800, Jonathan Cameron wrote:
> Jean Delvare wrote:
> > On Thu, 13 Aug 2009 16:22:29 +0530, Trisal, Kalhan wrote:
> >> This driver used Hwmon interface ,
> > 
> > No, it doesn't. It registers as a hwmon device but it doesn't implement
> > _any_ feature listed in Documentation/hwmon/sysfs-interface. Which can
> > be easily explained: your device is not a hardware monitoring device.
> > 
I tried to bind the ACPI ALS device driver with the hwmon sysfs I/F at
the beginning, then stopped for the same reason.
that's why the generic ALS sysfs class is introduced.

> >> I don't find the ils29003 registering with hwmon. I still believe
> >> this should be part of hwmon group.
> > 
> > No, it shouldn't. hwmon is for hardware monitoring. Other sensor types
> > must find a different home.
> For info current options I know of:
> 
> 1) drivers/misc (where the isl290003 is, previously intention was to possibly
> move this to iio when / if that gets merged)
> 
> 2) drivers/staging/iio/light (tsl2561) I'm happy with more light sensors
> in there, though the interface might need some hammering out.  Currently none
> of them are using any iio specific features so can certainly go elsewhere
> if people would prefer. In my personal view a lot of the processing currently
> in the various drivers ought not to be in the kernel, but that's a different
> matter)  IIO is currently in Greg KH's tree.
> 
> 3) drivers/als (acpi ambient light sensor - latest version posted to lkml a couple
> of days ago - now in acpi-testing I think) 

it's not ACPI ambient light sensor.
drivers/als/als.c is a new sysfs class (als_class) which provides a
generic sysfs I/F for all the ALS devices.
ACPI ALS device driver is just the first user of this class.

>  This one is a bit different, but perhaps
> a conversation needs to be opened with them to see if the requirements overlap
> sufficiently to use a shared framework.)

right.
As I'm not familiar with other ALS devices, I just introduced two sysfs
I/F which IMO are needed for all the ALS devices.
We can add any attributes which are generic and useful. :)

thanks,
rui



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
                   ` (5 preceding siblings ...)
  2009-09-03  3:35 ` Zhang Rui
@ 2009-09-03 10:51 ` Jean Delvare
  2009-09-03 12:50 ` Jonathan Cameron
  7 siblings, 0 replies; 9+ messages in thread
From: Jean Delvare @ 2009-09-03 10:51 UTC (permalink / raw)
  To: lm-sensors

Hi Rui,

On Thu, 03 Sep 2009 11:35:39 +0800, Zhang Rui wrote:
> On Wed, 2009-09-02 at 23:26 +0800, Jonathan Cameron wrote:
> > 3) drivers/als (acpi ambient light sensor - latest version posted to lkml a couple
> > of days ago - now in acpi-testing I think) 
> 
> it's not ACPI ambient light sensor.
> drivers/als/als.c is a new sysfs class (als_class) which provides a
> generic sysfs I/F for all the ALS devices.
> ACPI ALS device driver is just the first user of this class.

Excellent. Thanks a lot for doing this! The old tls2550 driver should
probably be moved to this directory and interface. If the interface
documented somewhere?

-- 
Jean Delvare

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device
  2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
                   ` (6 preceding siblings ...)
  2009-09-03 10:51 ` Jean Delvare
@ 2009-09-03 12:50 ` Jonathan Cameron
  7 siblings, 0 replies; 9+ messages in thread
From: Jonathan Cameron @ 2009-09-03 12:50 UTC (permalink / raw)
  To: lm-sensors

Zhang Rui wrote:
> On Wed, 2009-09-02 at 23:26 +0800, Jonathan Cameron wrote:
>> Jean Delvare wrote:
>>> On Thu, 13 Aug 2009 16:22:29 +0530, Trisal, Kalhan wrote:
>>>> This driver used Hwmon interface ,
>>> No, it doesn't. It registers as a hwmon device but it doesn't implement
>>> _any_ feature listed in Documentation/hwmon/sysfs-interface. Which can
>>> be easily explained: your device is not a hardware monitoring device.
>>>
> I tried to bind the ACPI ALS device driver with the hwmon sysfs I/F at
> the beginning, then stopped for the same reason.
> that's why the generic ALS sysfs class is introduced.
> 
>>>> I don't find the ils29003 registering with hwmon. I still believe
>>>> this should be part of hwmon group.
>>> No, it shouldn't. hwmon is for hardware monitoring. Other sensor types
>>> must find a different home.
>> For info current options I know of:
>>
>> 1) drivers/misc (where the isl290003 is, previously intention was to possibly
>> move this to iio when / if that gets merged)
>>
>> 2) drivers/staging/iio/light (tsl2561) I'm happy with more light sensors
>> in there, though the interface might need some hammering out.  Currently none
>> of them are using any iio specific features so can certainly go elsewhere
>> if people would prefer. In my personal view a lot of the processing currently
>> in the various drivers ought not to be in the kernel, but that's a different
>> matter)  IIO is currently in Greg KH's tree.
>>
>> 3) drivers/als (acpi ambient light sensor - latest version posted to lkml a couple
>> of days ago - now in acpi-testing I think) 
> 
> it's not ACPI ambient light sensor.
> drivers/als/als.c is a new sysfs class (als_class) which provides a
> generic sysfs I/F for all the ALS devices.
> ACPI ALS device driver is just the first user of this class.
> 
>>  This one is a bit different, but perhaps
>> a conversation needs to be opened with them to see if the requirements overlap
>> sufficiently to use a shared framework.)
> 
> right.
> As I'm not familiar with other ALS devices, I just introduced two sysfs
> I/F which IMO are needed for all the ALS devices.
Unfortunately things aren't that simple, I'll give more details in initial lkml
posting.

> We can add any attributes which are generic and useful. :)
> 
> thanks,
> rui
Lets move this discussion to a new thread on LKML to pick up anyone else who is
interested in the discussion. I'll try and draw up a summary of previous discussions
and will cc everyone in this thread (yell if you'd rather I didn't!)

Jonathan

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2009-09-03 12:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-11  8:13 [lm-sensors] Ambient Light sensor for Intersil-ISL29020 device Kalhan Trisal
2009-08-11 13:29 ` Cory T. Tusar
2009-08-13 10:56 ` Trisal, Kalhan
2009-09-02 12:51 ` Jean Delvare
2009-09-02 15:26 ` Jonathan Cameron
2009-09-02 20:07 ` Pavel Machek
2009-09-03  3:35 ` Zhang Rui
2009-09-03 10:51 ` Jean Delvare
2009-09-03 12:50 ` Jonathan Cameron

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.