AL3000a is a simple I2C-based ambient light sensor, which is
closely related to AL3010 and AL3320a, but has significantly
different way of processing data generated by the sensor.
Tested-by: Robert Eckelmann <longnoserob@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/al3000a.c | 221 ++++++++++++++++++++++++++++++++++++
3 files changed, 232 insertions(+)
create mode 100644 drivers/iio/light/al3000a.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index e34e551eef3e..142f7f7ef0ec 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -43,6 +43,16 @@ config ADUX1020
To compile this driver as a module, choose M here: the
module will be called adux1020.
+config AL3000A
+ tristate "AL3000a ambient light sensor"
+ depends on I2C
+ help
+ Say Y here if you want to build a driver for the Dyna Image AL3000a
+ ambient light sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called al3000a.
+
config AL3010
tristate "AL3010 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 11a4041b918a..17030a4cc340 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_ACPI_ALS) += acpi-als.o
obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_ADUX1020) += adux1020.o
+obj-$(CONFIG_AL3000A) += al3000a.o
obj-$(CONFIG_AL3010) += al3010.o
obj-$(CONFIG_AL3320A) += al3320a.o
obj-$(CONFIG_APDS9300) += apds9300.o
diff --git a/drivers/iio/light/al3000a.c b/drivers/iio/light/al3000a.c
new file mode 100644
index 000000000000..58d4336dd081
--- /dev/null
+++ b/drivers/iio/light/al3000a.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/pm.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define AL3000A_DRV_NAME "al3000a"
+#define AL3000A_REG_SYSTEM 0x00
+#define AL3000A_REG_DATA 0x05
+
+#define AL3000A_CONFIG_ENABLE 0x00
+#define AL3000A_CONFIG_DISABLE 0x0b
+#define AL3000A_CONFIG_RESET 0x0f
+#define AL3000A_GAIN_MASK GENMASK(5, 0)
+
+/*
+ * This are pre-calculated lux values based on possible output of sensor
+ * (range 0x00 - 0x3F)
+ */
+static const u32 lux_table[] = {
+ 1, 1, 1, 2, 2, 2, 3, 4, /* 0 - 7 */
+ 4, 5, 6, 7, 9, 11, 13, 16, /* 8 - 15 */
+ 19, 22, 27, 32, 39, 46, 56, 67, /* 16 - 23 */
+ 80, 96, 116, 139, 167, 200, 240, 289, /* 24 - 31 */
+ 347, 416, 499, 600, 720, 864, 1037, 1245, /* 32 - 39 */
+ 1495, 1795, 2155, 2587, 3105, 3728, 4475, 5373, /* 40 - 47 */
+ 6450, 7743, 9296, 11160, 13397, 16084, 19309, 23180, /* 48 - 55 */
+ 27828, 33408, 40107, 48148, 57803, 69393, 83306, 100000 /* 56 - 63 */
+};
+
+static const struct regmap_config al3000a_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = AL3000A_REG_DATA,
+};
+
+struct al3000a_data {
+ struct regmap *regmap;
+ struct regulator *vdd_supply;
+};
+
+static const struct iio_chan_spec al3000a_channels[] = {
+ {
+ .type = IIO_LIGHT,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int al3000a_set_pwr(struct al3000a_data *data, bool pwr)
+{
+ struct device *dev = regmap_get_device(data->regmap);
+ u8 val = pwr ? AL3000A_CONFIG_ENABLE : AL3000A_CONFIG_DISABLE;
+ int ret;
+
+ if (pwr) {
+ ret = regulator_enable(data->vdd_supply);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable vdd power supply\n");
+ return ret;
+ }
+ }
+
+ ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, val);
+ if (ret < 0) {
+ dev_err(dev, "failed to write system register\n");
+ return ret;
+ }
+
+ if (!pwr) {
+ ret = regulator_disable(data->vdd_supply);
+ if (ret < 0) {
+ dev_err(dev, "failed to disable vdd power supply\n");
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static void al3000a_set_pwr_off(void *_data)
+{
+ struct al3000a_data *data = _data;
+
+ al3000a_set_pwr(data, false);
+}
+
+static int al3000a_init(struct al3000a_data *data)
+{
+ int ret;
+
+ ret = al3000a_set_pwr(data, true);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_RESET);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_ENABLE);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int al3000a_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ struct al3000a_data *data = iio_priv(indio_dev);
+ int ret, gain;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
+ if (ret < 0)
+ return ret;
+
+ *val = lux_table[gain & AL3000A_GAIN_MASK];
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = 1;
+
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info al3000a_info = {
+ .read_raw = al3000a_read_raw,
+};
+
+static int al3000a_probe(struct i2c_client *client)
+{
+ struct al3000a_data *data;
+ struct device *dev = &client->dev;
+ struct iio_dev *indio_dev;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ data = iio_priv(indio_dev);
+ i2c_set_clientdata(client, indio_dev);
+
+ data->regmap = devm_regmap_init_i2c(client, &al3000a_regmap_config);
+ if (IS_ERR(data->regmap))
+ return dev_err_probe(dev, PTR_ERR(data->regmap),
+ "cannot allocate regmap\n");
+
+ data->vdd_supply = devm_regulator_get(dev, "vdd");
+ if (IS_ERR(data->vdd_supply))
+ return dev_err_probe(dev, PTR_ERR(data->vdd_supply),
+ "failed to get vdd regulator\n");
+
+ indio_dev->info = &al3000a_info;
+ indio_dev->name = AL3000A_DRV_NAME;
+ indio_dev->channels = al3000a_channels;
+ indio_dev->num_channels = ARRAY_SIZE(al3000a_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ ret = al3000a_init(data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to init ALS\n");
+
+ ret = devm_add_action_or_reset(dev, al3000a_set_pwr_off, data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to add action\n");
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static int al3000a_suspend(struct device *dev)
+{
+ struct al3000a_data *data = iio_priv(dev_get_drvdata(dev));
+
+ return al3000a_set_pwr(data, false);
+}
+
+static int al3000a_resume(struct device *dev)
+{
+ struct al3000a_data *data = iio_priv(dev_get_drvdata(dev));
+
+ return al3000a_set_pwr(data, true);
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(al3000a_pm_ops, al3000a_suspend, al3000a_resume);
+
+static const struct of_device_id al3000a_of_match[] = {
+ { .compatible = "dynaimage,al3000a" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, al3000a_of_match);
+
+static struct i2c_driver al3000a_driver = {
+ .driver = {
+ .name = AL3000A_DRV_NAME,
+ .of_match_table = al3000a_of_match,
+ .pm = pm_sleep_ptr(&al3000a_pm_ops),
+ },
+ .probe = al3000a_probe,
+};
+module_i2c_driver(al3000a_driver);
+
+MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
+MODULE_DESCRIPTION("al3000a Ambient Light Sensor driver");
+MODULE_LICENSE("GPL");
--
2.43.0On Sat, 15 Feb 2025 12:31:58 +0200
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> AL3000a is a simple I2C-based ambient light sensor, which is
> closely related to AL3010 and AL3320a, but has significantly
> different way of processing data generated by the sensor.
>
> Tested-by: Robert Eckelmann <longnoserob@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Hi,
A few really minor comments inline. A nice small driver :)
Jonathan
> diff --git a/drivers/iio/light/al3000a.c b/drivers/iio/light/al3000a.c
> new file mode 100644
> index 000000000000..58d4336dd081
> --- /dev/null
> +++ b/drivers/iio/light/al3000a.c
> @@ -0,0 +1,221 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/array_size.h>
> +#include <linux/bitfield.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/pm.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/types.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
The iio/sysfs.h header is a bit of a legacy thing. Ideally we will
eventually get rid of it. In this driver, you are correctly not using
anything it provides so drop this include.
> +
> +static const struct iio_chan_spec al3000a_channels[] = {
> + {
> + .type = IIO_LIGHT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
As below. I'm a little confused on units, but this may want to just
be BIT(IIO_CHAN_INFO_PROCESSED)
> + },
> +};
> +
> +static int al3000a_set_pwr(struct al3000a_data *data, bool pwr)
> +{
> + struct device *dev = regmap_get_device(data->regmap);
> + u8 val = pwr ? AL3000A_CONFIG_ENABLE : AL3000A_CONFIG_DISABLE;
> + int ret;
> +
> + if (pwr) {
The two flows are different enough I'd split this into power on and power
off functions. Will be a few lines longer but slightly easier to read.
> + ret = regulator_enable(data->vdd_supply);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable vdd power supply\n");
> + return ret;
> + }
> + }
> +
> + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, val);
> + if (ret < 0) {
> + dev_err(dev, "failed to write system register\n");
> + return ret;
> + }
> +
> + if (!pwr) {
> + ret = regulator_disable(data->vdd_supply);
> + if (ret < 0) {
> + dev_err(dev, "failed to disable vdd power supply\n");
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void al3000a_set_pwr_off(void *_data)
> +{
> + struct al3000a_data *data = _data;
> +
> + al3000a_set_pwr(data, false);
> +}
> +
> +static int al3000a_init(struct al3000a_data *data)
> +{
> + int ret;
> +
> + ret = al3000a_set_pwr(data, true);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_RESET);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_ENABLE);
regmap functions return <= 0 in all cases. So you can just do if (ret)
or in cases like this save a few lines with
return regmap_write();
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int al3000a_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + struct al3000a_data *data = iio_priv(indio_dev);
> + int ret, gain;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> + if (ret < 0)
> + return ret;
> +
> + *val = lux_table[gain & AL3000A_GAIN_MASK];
I may have misinterpreted the other thread. IS this value in lux?
If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
> +
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = 1;
Either way, default scale is 1 so this should not be expressed at all.
> +
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static const struct iio_info al3000a_info = {
> + .read_raw = al3000a_read_raw,
I'd not put a tab in the middle. Single space is fine.
This sort of alignment is a pain for long term maintenance anyway
as we get very noisy patches realigning things.
It makes even less sense with only one item!
> +};
> +
> +static int al3000a_probe(struct i2c_client *client)
> +{
> + struct al3000a_data *data;
> + struct device *dev = &client->dev;
> + struct iio_dev *indio_dev;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> + i2c_set_clientdata(client, indio_dev);
> +
> + data->regmap = devm_regmap_init_i2c(client, &al3000a_regmap_config);
> + if (IS_ERR(data->regmap))
> + return dev_err_probe(dev, PTR_ERR(data->regmap),
> + "cannot allocate regmap\n");
> +
> + data->vdd_supply = devm_regulator_get(dev, "vdd");
> + if (IS_ERR(data->vdd_supply))
> + return dev_err_probe(dev, PTR_ERR(data->vdd_supply),
> + "failed to get vdd regulator\n");
> +
> + indio_dev->info = &al3000a_info;
> + indio_dev->name = AL3000A_DRV_NAME;
As there is no actual reason why this name should necessarily match the
name of the driver I'd prefer to see the string expressed directly in both
places. That avoids giving the wrong impression as the driver gains support
for additional devices and generally makes things slightly easier to review.
> + indio_dev->channels = al3000a_channels;
> + indio_dev->num_channels = ARRAY_SIZE(al3000a_channels);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = al3000a_init(data);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to init ALS\n");
> +
> + ret = devm_add_action_or_reset(dev, al3000a_set_pwr_off, data);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to add action\n");
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(al3000a_pm_ops, al3000a_suspend, al3000a_resume);
> +
> +static const struct of_device_id al3000a_of_match[] = {
> + { .compatible = "dynaimage,al3000a" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, al3000a_of_match);
Also provide the i2c_device_id table as it's used for autoprobing of the
driver (long story for why we still need that!)
> +
> +static struct i2c_driver al3000a_driver = {
> + .driver = {
> + .name = AL3000A_DRV_NAME,
> + .of_match_table = al3000a_of_match,
> + .pm = pm_sleep_ptr(&al3000a_pm_ops),
> + },
> + .probe = al3000a_probe,
> +};
> +module_i2c_driver(al3000a_driver);
> +
> +MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
> +MODULE_DESCRIPTION("al3000a Ambient Light Sensor driver");
> +MODULE_LICENSE("GPL");
нд, 16 лют. 2025 р. о 16:54 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sat, 15 Feb 2025 12:31:58 +0200
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > AL3000a is a simple I2C-based ambient light sensor, which is
> > closely related to AL3010 and AL3320a, but has significantly
> > different way of processing data generated by the sensor.
> >
> > Tested-by: Robert Eckelmann <longnoserob@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>
> Hi,
>
> A few really minor comments inline. A nice small driver :)
>
> Jonathan
>
>
> > diff --git a/drivers/iio/light/al3000a.c b/drivers/iio/light/al3000a.c
> > new file mode 100644
> > index 000000000000..58d4336dd081
> > --- /dev/null
> > +++ b/drivers/iio/light/al3000a.c
> > @@ -0,0 +1,221 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +#include <linux/array_size.h>
> > +#include <linux/bitfield.h>
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/i2c.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/pm.h>
> > +#include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/types.h>
> > +
> > +#include <linux/iio/iio.h>
> > +#include <linux/iio/sysfs.h>
> The iio/sysfs.h header is a bit of a legacy thing. Ideally we will
> eventually get rid of it. In this driver, you are correctly not using
> anything it provides so drop this include.
>
> > +
> > +static const struct iio_chan_spec al3000a_channels[] = {
> > + {
> > + .type = IIO_LIGHT,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > + BIT(IIO_CHAN_INFO_SCALE),
> As below. I'm a little confused on units, but this may want to just
> be BIT(IIO_CHAN_INFO_PROCESSED)
> > + },
> > +};
> > +
> > +static int al3000a_set_pwr(struct al3000a_data *data, bool pwr)
> > +{
> > + struct device *dev = regmap_get_device(data->regmap);
> > + u8 val = pwr ? AL3000A_CONFIG_ENABLE : AL3000A_CONFIG_DISABLE;
> > + int ret;
> > +
> > + if (pwr) {
>
> The two flows are different enough I'd split this into power on and power
> off functions. Will be a few lines longer but slightly easier to read.
>
> > + ret = regulator_enable(data->vdd_supply);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to enable vdd power supply\n");
> > + return ret;
> > + }
> > + }
> > +
> > + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, val);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to write system register\n");
> > + return ret;
> > + }
> > +
> > + if (!pwr) {
> > + ret = regulator_disable(data->vdd_supply);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to disable vdd power supply\n");
> > + return ret;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void al3000a_set_pwr_off(void *_data)
> > +{
> > + struct al3000a_data *data = _data;
> > +
> > + al3000a_set_pwr(data, false);
> > +}
> > +
> > +static int al3000a_init(struct al3000a_data *data)
> > +{
> > + int ret;
> > +
> > + ret = al3000a_set_pwr(data, true);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_RESET);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_ENABLE);
>
> regmap functions return <= 0 in all cases. So you can just do if (ret)
> or in cases like this save a few lines with
>
> return regmap_write();
>
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int *val,
> > + int *val2, long mask)
> > +{
> > + struct al3000a_data *data = iio_priv(indio_dev);
> > + int ret, gain;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val = lux_table[gain & AL3000A_GAIN_MASK];
>
> I may have misinterpreted the other thread. IS this value in lux?
> If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
>
This is actually a really good hint, I will check if this works out
and if yes, then definitely will use it. Thank you.
> > +
> > + return IIO_VAL_INT;
> > + case IIO_CHAN_INFO_SCALE:
> > + *val = 1;
>
> Either way, default scale is 1 so this should not be expressed at all.
>
> > +
> > + return IIO_VAL_INT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static const struct iio_info al3000a_info = {
> > + .read_raw = al3000a_read_raw,
>
> I'd not put a tab in the middle. Single space is fine.
> This sort of alignment is a pain for long term maintenance anyway
> as we get very noisy patches realigning things.
> It makes even less sense with only one item!
>
> > +};
> > +
> > +static int al3000a_probe(struct i2c_client *client)
> > +{
> > + struct al3000a_data *data;
> > + struct device *dev = &client->dev;
> > + struct iio_dev *indio_dev;
> > + int ret;
> > +
> > + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> > + if (!indio_dev)
> > + return -ENOMEM;
> > +
> > + data = iio_priv(indio_dev);
> > + i2c_set_clientdata(client, indio_dev);
> > +
> > + data->regmap = devm_regmap_init_i2c(client, &al3000a_regmap_config);
> > + if (IS_ERR(data->regmap))
> > + return dev_err_probe(dev, PTR_ERR(data->regmap),
> > + "cannot allocate regmap\n");
> > +
> > + data->vdd_supply = devm_regulator_get(dev, "vdd");
> > + if (IS_ERR(data->vdd_supply))
> > + return dev_err_probe(dev, PTR_ERR(data->vdd_supply),
> > + "failed to get vdd regulator\n");
> > +
> > + indio_dev->info = &al3000a_info;
> > + indio_dev->name = AL3000A_DRV_NAME;
>
> As there is no actual reason why this name should necessarily match the
> name of the driver I'd prefer to see the string expressed directly in both
> places. That avoids giving the wrong impression as the driver gains support
> for additional devices and generally makes things slightly easier to review.
>
> > + indio_dev->channels = al3000a_channels;
> > + indio_dev->num_channels = ARRAY_SIZE(al3000a_channels);
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > +
> > + ret = al3000a_init(data);
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "failed to init ALS\n");
> > +
> > + ret = devm_add_action_or_reset(dev, al3000a_set_pwr_off, data);
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "failed to add action\n");
> > +
> > + return devm_iio_device_register(dev, indio_dev);
> > +}
>
> > +
> > +static DEFINE_SIMPLE_DEV_PM_OPS(al3000a_pm_ops, al3000a_suspend, al3000a_resume);
> > +
> > +static const struct of_device_id al3000a_of_match[] = {
> > + { .compatible = "dynaimage,al3000a" },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, al3000a_of_match);
>
> Also provide the i2c_device_id table as it's used for autoprobing of the
> driver (long story for why we still need that!)
>
> > +
> > +static struct i2c_driver al3000a_driver = {
> > + .driver = {
> > + .name = AL3000A_DRV_NAME,
> > + .of_match_table = al3000a_of_match,
> > + .pm = pm_sleep_ptr(&al3000a_pm_ops),
> > + },
> > + .probe = al3000a_probe,
> > +};
> > +module_i2c_driver(al3000a_driver);
> > +
> > +MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
> > +MODULE_DESCRIPTION("al3000a Ambient Light Sensor driver");
> > +MODULE_LICENSE("GPL");
>
Everything else, acknowledged and accepted. Thank you.
Hi,
> > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan, int *val,
> > > + int *val2, long mask)
> > > +{
> > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > + int ret, gain;
> > > +
> > > + switch (mask) {
> > > + case IIO_CHAN_INFO_RAW:
> > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> >
> > I may have misinterpreted the other thread. IS this value in lux?
> > If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
> >
>
> This is actually a really good hint, I will check if this works out
> and if yes, then definitely will use it. Thank you.
From your other reply it seems we have no idea of the correct scaling.
If that is the case, then channel type should be IIO_INTENSITY as
I assume we also have no idea if the light sensitivity curve is
matched to that required for illuminance (which approximates the
sensitivity of the human eye). Various datasheets provide completely
garbage conversion formulas btw so even if we have data this can
be problematic. One recent sensor was using a green filter and
saying illuminance in lux was 1.2 * green which was assuming their
own definition of white light.
Jonathan
пн, 17 лют. 2025 р. о 16:24 Jonathan Cameron <jic23@kernel.org> пише:
>
>
> Hi,
>
> > > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > > + struct iio_chan_spec const *chan, int *val,
> > > > + int *val2, long mask)
> > > > +{
> > > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > > + int ret, gain;
> > > > +
> > > > + switch (mask) {
> > > > + case IIO_CHAN_INFO_RAW:
> > > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> > >
> > > I may have misinterpreted the other thread. IS this value in lux?
> > > If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
> > >
> >
> > This is actually a really good hint, I will check if this works out
> > and if yes, then definitely will use it. Thank you.
>
> From your other reply it seems we have no idea of the correct scaling.
> If that is the case, then channel type should be IIO_INTENSITY as
> I assume we also have no idea if the light sensitivity curve is
> matched to that required for illuminance (which approximates the
> sensitivity of the human eye). Various datasheets provide completely
> garbage conversion formulas btw so even if we have data this can
> be problematic. One recent sensor was using a green filter and
> saying illuminance in lux was 1.2 * green which was assuming their
> own definition of white light.
>
> Jonathan
>
Then why IIO_LIGHT exists at all? If you state that datasheets provide
garbage formulas and sensors cannot be trusted and all is around human
eye, then why IIO_LIGHT is still the case? I did not recall any
drivers for human eyes (thank god). Please be more consistent. Thank
you
On Mon, 17 Feb 2025 16:32:33 +0200
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> пн, 17 лют. 2025 р. о 16:24 Jonathan Cameron <jic23@kernel.org> пише:
> >
> >
> > Hi,
> >
> > > > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > > > + struct iio_chan_spec const *chan, int *val,
> > > > > + int *val2, long mask)
> > > > > +{
> > > > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > > > + int ret, gain;
> > > > > +
> > > > > + switch (mask) {
> > > > > + case IIO_CHAN_INFO_RAW:
> > > > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> > > >
> > > > I may have misinterpreted the other thread. IS this value in lux?
> > > > If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
> > > >
> > >
> > > This is actually a really good hint, I will check if this works out
> > > and if yes, then definitely will use it. Thank you.
> >
> > From your other reply it seems we have no idea of the correct scaling.
> > If that is the case, then channel type should be IIO_INTENSITY as
> > I assume we also have no idea if the light sensitivity curve is
> > matched to that required for illuminance (which approximates the
> > sensitivity of the human eye). Various datasheets provide completely
> > garbage conversion formulas btw so even if we have data this can
> > be problematic. One recent sensor was using a green filter and
> > saying illuminance in lux was 1.2 * green which was assuming their
> > own definition of white light.
> >
> > Jonathan
> >
>
> Then why IIO_LIGHT exists at all? If you state that datasheets provide
> garbage formulas and sensors cannot be trusted and all is around human
> eye, then why IIO_LIGHT is still the case? I did not recall any
> drivers for human eyes (thank god). Please be more consistent. Thank
It exists because some sensors do this correctly, or at least a good
approximation to the standard sensitivity curves. This is done two
ways.
1. Good light frequency filtering in front of the sensor to compensate
for the difference in sensitivity between the measuring element
and that the standard curves. CIE1931 (there are a few other standards
but they are close enough that we don't care).
https://en.wikipedia.org/wiki/Illuminance
2. Multiple sensing elements. A common reason for this is to remove
bit of infrared that we don't want. Often the calculation is a
non linear combination of the various sensor outputs. Such a driver
usually presents several IIO_INTENSITY channels and a calculated
IIO_LIGHT channel.
In both cases the datasheet tends to include a comparison the the
CIE1931 etc standards. There will be small differences but that is
very different from taking a sensor that is only sensitive to green
and weighting it which is the example I gave above.
These sensors will compensate for the different sensivity
of the human eye to different wavelengths. E.g. if you
think blue and green light LEDs have the same brightness then
the sensor will give close to the same output.
Anyhow, light sensors are a hole I have gone far too deep in over
the years. Key is some manufacturers provide insufficient information
or take the view it is a problem for the integrator of the sensor
to deal with. For those we do not pretend to know the answer and
use intensity channels instead.
Jonathan
> you
>
сб, 22 лют. 2025 р. о 14:05 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Mon, 17 Feb 2025 16:32:33 +0200
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > пн, 17 лют. 2025 р. о 16:24 Jonathan Cameron <jic23@kernel.org> пише:
> > >
> > >
> > > Hi,
> > >
> > > > > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > > > > + struct iio_chan_spec const *chan, int *val,
> > > > > > + int *val2, long mask)
> > > > > > +{
> > > > > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > > > > + int ret, gain;
> > > > > > +
> > > > > > + switch (mask) {
> > > > > > + case IIO_CHAN_INFO_RAW:
> > > > > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> > > > >
> > > > > I may have misinterpreted the other thread. IS this value in lux?
> > > > > If it is make this channel IIO_CHAN_INFO_PROCESSED instead.
> > > > >
> > > >
> > > > This is actually a really good hint, I will check if this works out
> > > > and if yes, then definitely will use it. Thank you.
> > >
> > > From your other reply it seems we have no idea of the correct scaling.
> > > If that is the case, then channel type should be IIO_INTENSITY as
> > > I assume we also have no idea if the light sensitivity curve is
> > > matched to that required for illuminance (which approximates the
> > > sensitivity of the human eye). Various datasheets provide completely
> > > garbage conversion formulas btw so even if we have data this can
> > > be problematic. One recent sensor was using a green filter and
> > > saying illuminance in lux was 1.2 * green which was assuming their
> > > own definition of white light.
> > >
> > > Jonathan
> > >
> >
> > Then why IIO_LIGHT exists at all? If you state that datasheets provide
> > garbage formulas and sensors cannot be trusted and all is around human
> > eye, then why IIO_LIGHT is still the case? I did not recall any
> > drivers for human eyes (thank god). Please be more consistent. Thank
>
> It exists because some sensors do this correctly, or at least a good
> approximation to the standard sensitivity curves. This is done two
> ways.
>
> 1. Good light frequency filtering in front of the sensor to compensate
> for the difference in sensitivity between the measuring element
> and that the standard curves. CIE1931 (there are a few other standards
> but they are close enough that we don't care).
> https://en.wikipedia.org/wiki/Illuminance
> 2. Multiple sensing elements. A common reason for this is to remove
> bit of infrared that we don't want. Often the calculation is a
> non linear combination of the various sensor outputs. Such a driver
> usually presents several IIO_INTENSITY channels and a calculated
> IIO_LIGHT channel.
>
> In both cases the datasheet tends to include a comparison the the
> CIE1931 etc standards. There will be small differences but that is
> very different from taking a sensor that is only sensitive to green
> and weighting it which is the example I gave above.
>
> These sensors will compensate for the different sensivity
> of the human eye to different wavelengths. E.g. if you
> think blue and green light LEDs have the same brightness then
> the sensor will give close to the same output.
>
> Anyhow, light sensors are a hole I have gone far too deep in over
> the years. Key is some manufacturers provide insufficient information
> or take the view it is a problem for the integrator of the sensor
> to deal with. For those we do not pretend to know the answer and
> use intensity channels instead.
>
This is quite an explicit explanation. Thank you.
> Jonathan
>
>
> > you
> >
>
On 15/02/2025 11:31, Svyatoslav Ryhel wrote:
> AL3000a is a simple I2C-based ambient light sensor, which is
> closely related to AL3010 and AL3320a, but has significantly
> different way of processing data generated by the sensor.
>
> Tested-by: Robert Eckelmann <longnoserob@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/iio/light/Kconfig | 10 ++
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/al3000a.c | 221 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 232 insertions(+)
> create mode 100644 drivers/iio/light/al3000a.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index e34e551eef3e..142f7f7ef0ec 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -43,6 +43,16 @@ config ADUX1020
> To compile this driver as a module, choose M here: the
> module will be called adux1020.
>
> +config AL3000A
> + tristate "AL3000a ambient light sensor"
> + depends on I2C
> + help
> + Say Y here if you want to build a driver for the Dyna Image AL3000a
> + ambient light sensor.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called al3000a.
> +
> config AL3010
> tristate "AL3010 ambient light sensor"
> depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index 11a4041b918a..17030a4cc340 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -7,6 +7,7 @@
> obj-$(CONFIG_ACPI_ALS) += acpi-als.o
> obj-$(CONFIG_ADJD_S311) += adjd_s311.o
> obj-$(CONFIG_ADUX1020) += adux1020.o
> +obj-$(CONFIG_AL3000A) += al3000a.o
> obj-$(CONFIG_AL3010) += al3010.o
> obj-$(CONFIG_AL3320A) += al3320a.o
> obj-$(CONFIG_APDS9300) += apds9300.o
> diff --git a/drivers/iio/light/al3000a.c b/drivers/iio/light/al3000a.c
> new file mode 100644
> index 000000000000..58d4336dd081
> --- /dev/null
> +++ b/drivers/iio/light/al3000a.c
> @@ -0,0 +1,221 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/array_size.h>
> +#include <linux/bitfield.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/pm.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/types.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define AL3000A_DRV_NAME "al3000a"
> +#define AL3000A_REG_SYSTEM 0x00
> +#define AL3000A_REG_DATA 0x05
> +
> +#define AL3000A_CONFIG_ENABLE 0x00
> +#define AL3000A_CONFIG_DISABLE 0x0b
> +#define AL3000A_CONFIG_RESET 0x0f
> +#define AL3000A_GAIN_MASK GENMASK(5, 0)
> +
> +/*
> + * This are pre-calculated lux values based on possible output of sensor
> + * (range 0x00 - 0x3F)
> + */
> +static const u32 lux_table[] = {
> + 1, 1, 1, 2, 2, 2, 3, 4, /* 0 - 7 */
> + 4, 5, 6, 7, 9, 11, 13, 16, /* 8 - 15 */
> + 19, 22, 27, 32, 39, 46, 56, 67, /* 16 - 23 */
> + 80, 96, 116, 139, 167, 200, 240, 289, /* 24 - 31 */
> + 347, 416, 499, 600, 720, 864, 1037, 1245, /* 32 - 39 */
> + 1495, 1795, 2155, 2587, 3105, 3728, 4475, 5373, /* 40 - 47 */
> + 6450, 7743, 9296, 11160, 13397, 16084, 19309, 23180, /* 48 - 55 */
> + 27828, 33408, 40107, 48148, 57803, 69393, 83306, 100000 /* 56 - 63 */
> +};
> +
> +static const struct regmap_config al3000a_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = AL3000A_REG_DATA,
> +};
> +
> +struct al3000a_data {
> + struct regmap *regmap;
> + struct regulator *vdd_supply;
> +};
> +
> +static const struct iio_chan_spec al3000a_channels[] = {
> + {
> + .type = IIO_LIGHT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
> + },
> +};
> +
> +static int al3000a_set_pwr(struct al3000a_data *data, bool pwr)
> +{
> + struct device *dev = regmap_get_device(data->regmap);
> + u8 val = pwr ? AL3000A_CONFIG_ENABLE : AL3000A_CONFIG_DISABLE;
> + int ret;
> +
> + if (pwr) {
> + ret = regulator_enable(data->vdd_supply);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable vdd power supply\n");
> + return ret;
> + }
> + }
> +
> + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, val);
> + if (ret < 0) {
> + dev_err(dev, "failed to write system register\n");
> + return ret;
> + }
> +
> + if (!pwr) {
> + ret = regulator_disable(data->vdd_supply);
> + if (ret < 0) {
> + dev_err(dev, "failed to disable vdd power supply\n");
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void al3000a_set_pwr_off(void *_data)
> +{
> + struct al3000a_data *data = _data;
> +
> + al3000a_set_pwr(data, false);
> +}
> +
> +static int al3000a_init(struct al3000a_data *data)
> +{
> + int ret;
> +
> + ret = al3000a_set_pwr(data, true);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_RESET);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_ENABLE);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int al3000a_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + struct al3000a_data *data = iio_priv(indio_dev);
> + int ret, gain;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> + if (ret < 0)
> + return ret;
> +
> + *val = lux_table[gain & AL3000A_GAIN_MASK];
Why did you chosen to do post-processing in the RAW channel instead
doing it in INFO_SCALE (same as al3010 does)?
Except this, LGTM.
Documentation and DT patch:
Reviewed-by: David Heidelberg <david@ixit.cz>
> +
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = 1;
> +
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static const struct iio_info al3000a_info = {
> + .read_raw = al3000a_read_raw,
> +};
> +
> +static int al3000a_probe(struct i2c_client *client)
> +{
> + struct al3000a_data *data;
> + struct device *dev = &client->dev;
> + struct iio_dev *indio_dev;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> + i2c_set_clientdata(client, indio_dev);
> +
> + data->regmap = devm_regmap_init_i2c(client, &al3000a_regmap_config);
> + if (IS_ERR(data->regmap))
> + return dev_err_probe(dev, PTR_ERR(data->regmap),
> + "cannot allocate regmap\n");
> +
> + data->vdd_supply = devm_regulator_get(dev, "vdd");
> + if (IS_ERR(data->vdd_supply))
> + return dev_err_probe(dev, PTR_ERR(data->vdd_supply),
> + "failed to get vdd regulator\n");
> +
> + indio_dev->info = &al3000a_info;
> + indio_dev->name = AL3000A_DRV_NAME;
> + indio_dev->channels = al3000a_channels;
> + indio_dev->num_channels = ARRAY_SIZE(al3000a_channels);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = al3000a_init(data);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to init ALS\n");
> +
> + ret = devm_add_action_or_reset(dev, al3000a_set_pwr_off, data);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to add action\n");
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static int al3000a_suspend(struct device *dev)
> +{
> + struct al3000a_data *data = iio_priv(dev_get_drvdata(dev));
> +
> + return al3000a_set_pwr(data, false);
> +}
> +
> +static int al3000a_resume(struct device *dev)
> +{
> + struct al3000a_data *data = iio_priv(dev_get_drvdata(dev));
> +
> + return al3000a_set_pwr(data, true);
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(al3000a_pm_ops, al3000a_suspend, al3000a_resume);
> +
> +static const struct of_device_id al3000a_of_match[] = {
> + { .compatible = "dynaimage,al3000a" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, al3000a_of_match);
> +
> +static struct i2c_driver al3000a_driver = {
> + .driver = {
> + .name = AL3000A_DRV_NAME,
> + .of_match_table = al3000a_of_match,
> + .pm = pm_sleep_ptr(&al3000a_pm_ops),
> + },
> + .probe = al3000a_probe,
> +};
> +module_i2c_driver(al3000a_driver);
> +
> +MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
> +MODULE_DESCRIPTION("al3000a Ambient Light Sensor driver");
> +MODULE_LICENSE("GPL");
--
David Heidelberg
сб, 15 лют. 2025 р. о 16:12 David Heidelberg <david@ixit.cz> пише:
>
>
>
> On 15/02/2025 11:31, Svyatoslav Ryhel wrote:
> > AL3000a is a simple I2C-based ambient light sensor, which is
> > closely related to AL3010 and AL3320a, but has significantly
> > different way of processing data generated by the sensor.
> >
> > Tested-by: Robert Eckelmann <longnoserob@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/iio/light/Kconfig | 10 ++
> > drivers/iio/light/Makefile | 1 +
> > drivers/iio/light/al3000a.c | 221 ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 232 insertions(+)
> > create mode 100644 drivers/iio/light/al3000a.c
> >
> > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> > index e34e551eef3e..142f7f7ef0ec 100644
> > --- a/drivers/iio/light/Kconfig
> > +++ b/drivers/iio/light/Kconfig
> > @@ -43,6 +43,16 @@ config ADUX1020
> > To compile this driver as a module, choose M here: the
> > module will be called adux1020.
> >
> > +config AL3000A
> > + tristate "AL3000a ambient light sensor"
> > + depends on I2C
> > + help
> > + Say Y here if you want to build a driver for the Dyna Image AL3000a
> > + ambient light sensor.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called al3000a.
> > +
> > config AL3010
> > tristate "AL3010 ambient light sensor"
> > depends on I2C
> > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> > index 11a4041b918a..17030a4cc340 100644
> > --- a/drivers/iio/light/Makefile
> > +++ b/drivers/iio/light/Makefile
> > @@ -7,6 +7,7 @@
> > obj-$(CONFIG_ACPI_ALS) += acpi-als.o
> > obj-$(CONFIG_ADJD_S311) += adjd_s311.o
> > obj-$(CONFIG_ADUX1020) += adux1020.o
> > +obj-$(CONFIG_AL3000A) += al3000a.o
> > obj-$(CONFIG_AL3010) += al3010.o
> > obj-$(CONFIG_AL3320A) += al3320a.o
> > obj-$(CONFIG_APDS9300) += apds9300.o
> > diff --git a/drivers/iio/light/al3000a.c b/drivers/iio/light/al3000a.c
> > new file mode 100644
> > index 000000000000..58d4336dd081
> > --- /dev/null
> > +++ b/drivers/iio/light/al3000a.c
> > @@ -0,0 +1,221 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +#include <linux/array_size.h>
> > +#include <linux/bitfield.h>
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/i2c.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/pm.h>
> > +#include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/types.h>
> > +
> > +#include <linux/iio/iio.h>
> > +#include <linux/iio/sysfs.h>
> > +
> > +#define AL3000A_DRV_NAME "al3000a"
> > +#define AL3000A_REG_SYSTEM 0x00
> > +#define AL3000A_REG_DATA 0x05
> > +
> > +#define AL3000A_CONFIG_ENABLE 0x00
> > +#define AL3000A_CONFIG_DISABLE 0x0b
> > +#define AL3000A_CONFIG_RESET 0x0f
> > +#define AL3000A_GAIN_MASK GENMASK(5, 0)
> > +
> > +/*
> > + * This are pre-calculated lux values based on possible output of sensor
> > + * (range 0x00 - 0x3F)
> > + */
> > +static const u32 lux_table[] = {
> > + 1, 1, 1, 2, 2, 2, 3, 4, /* 0 - 7 */
> > + 4, 5, 6, 7, 9, 11, 13, 16, /* 8 - 15 */
> > + 19, 22, 27, 32, 39, 46, 56, 67, /* 16 - 23 */
> > + 80, 96, 116, 139, 167, 200, 240, 289, /* 24 - 31 */
> > + 347, 416, 499, 600, 720, 864, 1037, 1245, /* 32 - 39 */
> > + 1495, 1795, 2155, 2587, 3105, 3728, 4475, 5373, /* 40 - 47 */
> > + 6450, 7743, 9296, 11160, 13397, 16084, 19309, 23180, /* 48 - 55 */
> > + 27828, 33408, 40107, 48148, 57803, 69393, 83306, 100000 /* 56 - 63 */
> > +};
> > +
> > +static const struct regmap_config al3000a_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = AL3000A_REG_DATA,
> > +};
> > +
> > +struct al3000a_data {
> > + struct regmap *regmap;
> > + struct regulator *vdd_supply;
> > +};
> > +
> > +static const struct iio_chan_spec al3000a_channels[] = {
> > + {
> > + .type = IIO_LIGHT,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > + BIT(IIO_CHAN_INFO_SCALE),
> > + },
> > +};
> > +
> > +static int al3000a_set_pwr(struct al3000a_data *data, bool pwr)
> > +{
> > + struct device *dev = regmap_get_device(data->regmap);
> > + u8 val = pwr ? AL3000A_CONFIG_ENABLE : AL3000A_CONFIG_DISABLE;
> > + int ret;
> > +
> > + if (pwr) {
> > + ret = regulator_enable(data->vdd_supply);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to enable vdd power supply\n");
> > + return ret;
> > + }
> > + }
> > +
> > + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, val);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to write system register\n");
> > + return ret;
> > + }
> > +
> > + if (!pwr) {
> > + ret = regulator_disable(data->vdd_supply);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to disable vdd power supply\n");
> > + return ret;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void al3000a_set_pwr_off(void *_data)
> > +{
> > + struct al3000a_data *data = _data;
> > +
> > + al3000a_set_pwr(data, false);
> > +}
> > +
> > +static int al3000a_init(struct al3000a_data *data)
> > +{
> > + int ret;
> > +
> > + ret = al3000a_set_pwr(data, true);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_RESET);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = regmap_write(data->regmap, AL3000A_REG_SYSTEM, AL3000A_CONFIG_ENABLE);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int *val,
> > + int *val2, long mask)
> > +{
> > + struct al3000a_data *data = iio_priv(indio_dev);
> > + int ret, gain;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val = lux_table[gain & AL3000A_GAIN_MASK];
>
> Why did you chosen to do post-processing in the RAW channel instead
> doing it in INFO_SCALE (same as al3010 does)?
>
From my observation INFO_SCALE will just perform multiplication of RAW
to SCALE. In this case values which are read are not actual raw values
of illumination. Next is my assumption (since there is no datasheet),
but values obtained from register are similar to values from adc
thermal sensors, they need be converted via reference table to get
actual data.
> Except this, LGTM.
>
> Documentation and DT patch:
>
> Reviewed-by: David Heidelberg <david@ixit.cz>
> > +
> > + return IIO_VAL_INT;
> > + case IIO_CHAN_INFO_SCALE:
> > + *val = 1;
> > +
> > + return IIO_VAL_INT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static const struct iio_info al3000a_info = {
> > + .read_raw = al3000a_read_raw,
> > +};
> > +
> > +static int al3000a_probe(struct i2c_client *client)
> > +{
> > + struct al3000a_data *data;
> > + struct device *dev = &client->dev;
> > + struct iio_dev *indio_dev;
> > + int ret;
> > +
> > + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> > + if (!indio_dev)
> > + return -ENOMEM;
> > +
> > + data = iio_priv(indio_dev);
> > + i2c_set_clientdata(client, indio_dev);
> > +
> > + data->regmap = devm_regmap_init_i2c(client, &al3000a_regmap_config);
> > + if (IS_ERR(data->regmap))
> > + return dev_err_probe(dev, PTR_ERR(data->regmap),
> > + "cannot allocate regmap\n");
> > +
> > + data->vdd_supply = devm_regulator_get(dev, "vdd");
> > + if (IS_ERR(data->vdd_supply))
> > + return dev_err_probe(dev, PTR_ERR(data->vdd_supply),
> > + "failed to get vdd regulator\n");
> > +
> > + indio_dev->info = &al3000a_info;
> > + indio_dev->name = AL3000A_DRV_NAME;
> > + indio_dev->channels = al3000a_channels;
> > + indio_dev->num_channels = ARRAY_SIZE(al3000a_channels);
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > +
> > + ret = al3000a_init(data);
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "failed to init ALS\n");
> > +
> > + ret = devm_add_action_or_reset(dev, al3000a_set_pwr_off, data);
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "failed to add action\n");
> > +
> > + return devm_iio_device_register(dev, indio_dev);
> > +}
> > +
> > +static int al3000a_suspend(struct device *dev)
> > +{
> > + struct al3000a_data *data = iio_priv(dev_get_drvdata(dev));
> > +
> > + return al3000a_set_pwr(data, false);
> > +}
> > +
> > +static int al3000a_resume(struct device *dev)
> > +{
> > + struct al3000a_data *data = iio_priv(dev_get_drvdata(dev));
> > +
> > + return al3000a_set_pwr(data, true);
> > +}
> > +
> > +static DEFINE_SIMPLE_DEV_PM_OPS(al3000a_pm_ops, al3000a_suspend, al3000a_resume);
> > +
> > +static const struct of_device_id al3000a_of_match[] = {
> > + { .compatible = "dynaimage,al3000a" },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, al3000a_of_match);
> > +
> > +static struct i2c_driver al3000a_driver = {
> > + .driver = {
> > + .name = AL3000A_DRV_NAME,
> > + .of_match_table = al3000a_of_match,
> > + .pm = pm_sleep_ptr(&al3000a_pm_ops),
> > + },
> > + .probe = al3000a_probe,
> > +};
> > +module_i2c_driver(al3000a_driver);
> > +
> > +MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
> > +MODULE_DESCRIPTION("al3000a Ambient Light Sensor driver");
> > +MODULE_LICENSE("GPL");
>
> --
> David Heidelberg
>
> > > +
> > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan, int *val,
> > > + int *val2, long mask)
> > > +{
> > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > + int ret, gain;
> > > +
> > > + switch (mask) {
> > > + case IIO_CHAN_INFO_RAW:
> > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> >
> > Why did you chosen to do post-processing in the RAW channel instead
> > doing it in INFO_SCALE (same as al3010 does)?
> >
>
> From my observation INFO_SCALE will just perform multiplication of RAW
> to SCALE. In this case values which are read are not actual raw values
> of illumination. Next is my assumption (since there is no datasheet),
> but values obtained from register are similar to values from adc
> thermal sensors, they need be converted via reference table to get
> actual data.
Please add a comment somewhere here to say that we don't know the
relationship of these values to illuminance hence providing
_RAW and _SCALE would not be helpful.
>
> > Except this, LGTM.
> >
> > Documentation and DT patch:
> >
> > Reviewed-by: David Heidelberg <david@ixit.cz>
> > > +
> > > + return IIO_VAL_INT;
> > > + case IIO_CHAN_INFO_SCALE:
> > > + *val = 1;
> > > +
Don't do this. The above lack of known relationship has to be
expressed by not providing the _scale attribute.
> > > + return IIO_VAL_INT;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +}
> > > +
> > > +static const struct iio_info al3000a_info = {
> > > + .read_raw = al3000a_read_raw,
> > > +};
нд, 16 лют. 2025 р. о 16:44 Jonathan Cameron <jic23@kernel.org> пише:
>
>
> > > > +
> > > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > > + struct iio_chan_spec const *chan, int *val,
> > > > + int *val2, long mask)
> > > > +{
> > > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > > + int ret, gain;
> > > > +
> > > > + switch (mask) {
> > > > + case IIO_CHAN_INFO_RAW:
> > > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> > >
> > > Why did you chosen to do post-processing in the RAW channel instead
> > > doing it in INFO_SCALE (same as al3010 does)?
> > >
> >
> > From my observation INFO_SCALE will just perform multiplication of RAW
> > to SCALE. In this case values which are read are not actual raw values
> > of illumination. Next is my assumption (since there is no datasheet),
> > but values obtained from register are similar to values from adc
> > thermal sensors, they need be converted via reference table to get
> > actual data.
>
> Please add a comment somewhere here to say that we don't know the
> relationship of these values to illuminance hence providing
> _RAW and _SCALE would not be helpful.
>
We do know relationship of these values to illuminance thanks to
conversion table provided.
> >
> > > Except this, LGTM.
> > >
> > > Documentation and DT patch:
> > >
> > > Reviewed-by: David Heidelberg <david@ixit.cz>
> > > > +
> > > > + return IIO_VAL_INT;
> > > > + case IIO_CHAN_INFO_SCALE:
> > > > + *val = 1;
> > > > +
>
> Don't do this. The above lack of known relationship has to be
> expressed by not providing the _scale attribute.
>
> > > > + return IIO_VAL_INT;
> > > > + default:
> > > > + return -EINVAL;
> > > > + }
> > > > +}
> > > > +
> > > > +static const struct iio_info al3000a_info = {
> > > > + .read_raw = al3000a_read_raw,
> > > > +};
>
>
On Sun, 16 Feb 2025 16:47:52 +0200
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 16 лют. 2025 р. о 16:44 Jonathan Cameron <jic23@kernel.org> пише:
> >
> >
> > > > > +
> > > > > +static int al3000a_read_raw(struct iio_dev *indio_dev,
> > > > > + struct iio_chan_spec const *chan, int *val,
> > > > > + int *val2, long mask)
> > > > > +{
> > > > > + struct al3000a_data *data = iio_priv(indio_dev);
> > > > > + int ret, gain;
> > > > > +
> > > > > + switch (mask) {
> > > > > + case IIO_CHAN_INFO_RAW:
> > > > > + ret = regmap_read(data->regmap, AL3000A_REG_DATA, &gain);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + *val = lux_table[gain & AL3000A_GAIN_MASK];
> > > >
> > > > Why did you chosen to do post-processing in the RAW channel instead
> > > > doing it in INFO_SCALE (same as al3010 does)?
> > > >
> > >
> > > From my observation INFO_SCALE will just perform multiplication of RAW
> > > to SCALE. In this case values which are read are not actual raw values
> > > of illumination. Next is my assumption (since there is no datasheet),
> > > but values obtained from register are similar to values from adc
> > > thermal sensors, they need be converted via reference table to get
> > > actual data.
> >
> > Please add a comment somewhere here to say that we don't know the
> > relationship of these values to illuminance hence providing
> > _RAW and _SCALE would not be helpful.
> >
>
> We do know relationship of these values to illuminance thanks to
> conversion table provided.
Then convention is treat them not as IIO_LIGHT but as IIO_INTENSITY
which is unit free. IIO_LIGHT is only for when we know the value
we are providing to userspace is illuminance and measured in Lux.
Jonathan
>
> > >
> > > > Except this, LGTM.
> > > >
> > > > Documentation and DT patch:
> > > >
> > > > Reviewed-by: David Heidelberg <david@ixit.cz>
> > > > > +
> > > > > + return IIO_VAL_INT;
> > > > > + case IIO_CHAN_INFO_SCALE:
> > > > > + *val = 1;
> > > > > +
> >
> > Don't do this. The above lack of known relationship has to be
> > expressed by not providing the _scale attribute.
> >
> > > > > + return IIO_VAL_INT;
> > > > > + default:
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +}
> > > > > +
> > > > > +static const struct iio_info al3000a_info = {
> > > > > + .read_raw = al3000a_read_raw,
> > > > > +};
> >
> >
© 2016 - 2025 Red Hat, Inc.