From: Johan Hovold <hidden> Date: 2012-04-20 15:30:59
These patches (against v3.4-rc3) add support for the National Semiconductor /
Texas Instruments LM3533 lighting-power chip.
This multi-function device has four LEDs, two backlights and an ambient-light
sensor.
The LEDs and backlights can be controlled directly, through PWM input,
or by the on-chip ambient light sensor. Hardware-accelerated blinking is
provided for the LEDs.
ALS control is done through defining five light zones and three sets of
corresponding brightness target levels. The ALS driver presents a character
device (/dev/lm3533-als) which can be used to retrieve the current light zone
or to poll for zone changes.
Further details and specifications will soon be available from
http://www.ti.com/product/lm3533
This work has been done on behalf of National Semiconductor / Texas
Instruments.
Thanks,
Johan
Johan Hovold (4):
mfd: add LM3533 lighting-power core driver
misc: add LM3533 ambient light sensor driver
leds: add LM3533 LED driver
backlight: add LM3533 backlight driver
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3533.c | 713 +++++++++++++++++++++++++++++++++
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile | 3 +
drivers/mfd/lm3533-core.c | 738 +++++++++++++++++++++++++++++++++++
drivers/mfd/lm3533-ctrlbank.c | 134 +++++++
drivers/mfd/lm3533-i2c.c | 115 ++++++
drivers/misc/Kconfig | 13 +
drivers/misc/Makefile | 1 +
drivers/misc/lm3533-als.c | 662 +++++++++++++++++++++++++++++++
drivers/video/backlight/Kconfig | 12 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/lm3533_bl.c | 432 ++++++++++++++++++++
include/linux/mfd/lm3533.h | 106 +++++
15 files changed, 2956 insertions(+), 0 deletions(-)
create mode 100644 drivers/leds/leds-lm3533.c
create mode 100644 drivers/mfd/lm3533-core.c
create mode 100644 drivers/mfd/lm3533-ctrlbank.c
create mode 100644 drivers/mfd/lm3533-i2c.c
create mode 100644 drivers/misc/lm3533-als.c
create mode 100644 drivers/video/backlight/lm3533_bl.c
create mode 100644 include/linux/mfd/lm3533.h
--
1.7.8.5
From: Johan Hovold <hidden> Date: 2012-04-20 15:31:03
Add sub-driver for the LEDs in National Semiconductor / TI LM3533
lighting power chips.
The chip provides 256 brightness levels, hardware accelerated blinking
as well as ambient-light-sensor and pwm input control.
Signed-off-by: Johan Hovold <redacted>
---
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3533.c | 713 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 727 insertions(+), 0 deletions(-)
create mode 100644 drivers/leds/leds-lm3533.c
@@ -50,6 +50,19 @@ config LEDS_LM3530controlledmanuallyorusingPWMinputorusingambientlightautomatically.+configLEDS_LM3533+tristate"LED support for LM3533"+depends onLEDS_CLASS+depends onMFD_LM3533+help+ThisoptionenablessupportfortheLEDsonNationalSemiconductor/+TILM3533LightingPowerchips.++TheLEDscanbecontrolleddirectly,throughPWMinput,orbythe+on-chipambientlightsensor.Thechipsupportshardware-accelerated+blinkingwithmaximumonandoffperiodsof9.8and77seconds+respectively.+configLEDS_LOCOMOtristate"LED Support for Locomo device"depends onLEDS_CLASS
From: Johan Hovold <hidden> Date: 2012-04-20 15:31:43
Add sub-driver for the ambient light sensor in National Semiconductor /
TI LM3533 lighting power chips.
Raw ADC values as well as current ALS zone can be retrieved through
sysfs. The ALS zone can also be read using a character device
(/dev/lm3533-als) which is updated on zone changes (interrupt driven or
polled).
The driver provides a configuration interface through sysfs.
Signed-off-by: Johan Hovold <redacted>
---
drivers/misc/Kconfig | 13 +
drivers/misc/Makefile | 1 +
drivers/misc/lm3533-als.c | 662 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 676 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/lm3533-als.c
On Fri, Apr 20, 2012 at 05:30:24PM +0200, Johan Hovold wrote:
Add sub-driver for the ambient light sensor in National Semiconductor /
TI LM3533 lighting power chips.
Raw ADC values as well as current ALS zone can be retrieved through
sysfs. The ALS zone can also be read using a character device
(/dev/lm3533-als) which is updated on zone changes (interrupt driven or
polled).
The driver provides a configuration interface through sysfs.
Which seems to not be documented at all :(
What about using the iio interface for this instead? Doesn't that
already provide this standard interface you are looking for?
thanks,
greg k-h
Add sub-driver for the LEDs in National Semiconductor / TI LM3533
lighting power chips.
The chip provides 256 brightness levels, hardware accelerated blinking
as well as ambient-light-sensor and pwm input control.
Signed-off-by: Johan Hovold <redacted>
I notice that there is already driver for lm3530, which sounds related.
Is there an opportunity to share code between these, or are they completely
different devices?
IMHO this macro adds more in terms of complexity than it saves in terms
of lines of code, and it would be better to open-code the two instances.
If you need more than two or three instances, I would recommend creating
keying the number off of the attribute pointer, either by comparing the
pointer or by adding a data structure derived from device_attribute and
using container_of to get at the other data.
Arnd
From: Johan Hovold <hidden> Date: 2012-04-20 16:45:58
On Fri, Apr 20, 2012 at 04:10:15PM +0000, Arnd Bergmann wrote:
On Friday 20 April 2012, Johan Hovold wrote:
quoted
Add sub-driver for the LEDs in National Semiconductor / TI LM3533
lighting power chips.
The chip provides 256 brightness levels, hardware accelerated blinking
as well as ambient-light-sensor and pwm input control.
Signed-off-by: Johan Hovold <redacted>
I notice that there is already driver for lm3530, which sounds related.
Is there an opportunity to share code between these, or are they completely
different devices?
Unfortunately not. They are really very different devices despite
similar naming and terminology.
IMHO this macro adds more in terms of complexity than it saves in terms
of lines of code, and it would be better to open-code the two instances.
If you need more than two or three instances, I would recommend creating
keying the number off of the attribute pointer, either by comparing the
pointer or by adding a data structure derived from device_attribute and
using container_of to get at the other data.
Agreed. I'll simply open-code them for now, and do the same with the
equivalent instances in the backlight driver.
Thanks,
Johan
From: Johan Hovold <hidden> Date: 2012-04-20 17:28:54
On Fri, Apr 20, 2012 at 08:57:34AM -0700, Greg Kroah-Hartman wrote:
On Fri, Apr 20, 2012 at 05:30:24PM +0200, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor in National Semiconductor /
TI LM3533 lighting power chips.
Raw ADC values as well as current ALS zone can be retrieved through
sysfs. The ALS zone can also be read using a character device
(/dev/lm3533-als) which is updated on zone changes (interrupt driven or
polled).
The driver provides a configuration interface through sysfs.
Which seems to not be documented at all :(
There are the following sysfs entries for configuring ALS control:
boundary0_high
boundary0_low
boundary1_high
boundary1_low
boundary2_high
boundary2_low
boundary3_high
boundary3_low
gain
target1_0
target1_1
target1_2
target1_3
target1_4
target2_0
target2_1
target2_2
target2_3
target2_4
target3_0
target3_1
target3_2
target3_3
target3_4
These define the "five light zones and three sets of corresponding
brightness target levels" mentioned in the Kconfig entry and provides a
gain setting.
Each entry also corresponds to an 8-bit register, which is documented
along with the overall ALS functionality in the datasheets (which will
be published on the TI web page soon). So I think anyone integrating
this IC (or anyone who has access to the datasheets) will have no
problem with this interface, but I'd be happy to write something to put
under Documentation as well.
The end-customer insisted on sysfs configurability, but I'll probably
add these settings to the platform data later as well.
What about using the iio interface for this instead? Doesn't that
already provide this standard interface you are looking for?
I had a look at iio last fall and decided not to use it at the time. I
can't remember exactly what the reasons were right now, so I'll have
to get back to you on this.
Thanks,
Johan
On Fri, Apr 20, 2012 at 07:28:49PM +0200, Johan Hovold wrote:
On Fri, Apr 20, 2012 at 08:57:34AM -0700, Greg Kroah-Hartman wrote:
quoted
On Fri, Apr 20, 2012 at 05:30:24PM +0200, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor in National Semiconductor /
TI LM3533 lighting power chips.
Raw ADC values as well as current ALS zone can be retrieved through
sysfs. The ALS zone can also be read using a character device
(/dev/lm3533-als) which is updated on zone changes (interrupt driven or
polled).
The driver provides a configuration interface through sysfs.
Which seems to not be documented at all :(
There are the following sysfs entries for configuring ALS control:
<snip>
That's fine, but you need a Documentation/ABI entry for any new sysfs
file you create.
quoted
What about using the iio interface for this instead? Doesn't that
already provide this standard interface you are looking for?
I had a look at iio last fall and decided not to use it at the time. I
can't remember exactly what the reasons were right now, so I'll have
to get back to you on this.
Please look into this, the iio framework is about to move out of the
staging tree for 3.5, so there should not be any reason for you to
create yet-another user api for this type of thing.
thanks,
greg k-h
From: Johan Hovold <hidden> Date: 2012-04-26 11:52:08
On Fri, Apr 20, 2012 at 10:37:54AM -0700, Greg Kroah-Hartman wrote:
On Fri, Apr 20, 2012 at 07:28:49PM +0200, Johan Hovold wrote:
quoted
On Fri, Apr 20, 2012 at 08:57:34AM -0700, Greg Kroah-Hartman wrote:
quoted
On Fri, Apr 20, 2012 at 05:30:24PM +0200, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor in National Semiconductor /
TI LM3533 lighting power chips.
Raw ADC values as well as current ALS zone can be retrieved through
sysfs. The ALS zone can also be read using a character device
(/dev/lm3533-als) which is updated on zone changes (interrupt driven or
polled).
The driver provides a configuration interface through sysfs.
Which seems to not be documented at all :(
There are the following sysfs entries for configuring ALS control:
<snip>
That's fine, but you need a Documentation/ABI entry for any new sysfs
file you create.
quoted
quoted
What about using the iio interface for this instead? Doesn't that
already provide this standard interface you are looking for?
I had a look at iio last fall and decided not to use it at the time. I
can't remember exactly what the reasons were right now, so I'll have
to get back to you on this.
Please look into this, the iio framework is about to move out of the
staging tree for 3.5, so there should not be any reason for you to
create yet-another user api for this type of thing.
We had an initial requirement to support fairly old kernels, but this
have since been relaxed (and has of course never in itself been a valid
reason to not use iio for upstream). As iio is moving out of staging, I
see no problems using it, and the required changes appear quite small.
I'll submit a v2 against iio and make sure to document the sysfs-entries.
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-04-26 12:41:34
On Fri, Apr 20, 2012 at 05:30:23PM +0200, Johan Hovold wrote:
quoted hunk
+static int __lm3533_read(struct lm3533 *lm3533, u8 reg, u8 *val)+{+ int ret;++ ret = lm3533->read(lm3533, reg, val);+ if (ret < 0) {
Looks like you could save a bunch of code by using regmap for the
register I/O. This would also give you access to the cache and
diagnostic infrastructure it has.
From: Johan Hovold <hidden> Date: 2012-05-03 10:22:55
[ Sorry for the resend -- Android/gmail apparently added HTML to my previous
attempt. ]
On Apr 26, 2012 2:41 PM, "Mark Brown" [off-list ref]
wrote:
On Fri, Apr 20, 2012 at 05:30:23PM +0200, Johan Hovold wrote:
quoted
+static int __lm3533_read(struct lm3533 *lm3533, u8 reg, u8 *val)+{+ int ret;++ ret = lm3533->read(lm3533, reg, val);+ if (ret < 0) {
Looks like you could save a bunch of code by using regmap for the
register I/O. This would also give you access to the cache and
diagnostic infrastructure it has.
Using regmap only saves about ten lines for the actual io implementation,
but it does allow me to get rid of the custom debugfs interface. I'm not
enabling caching at this point but it'll probably come in handy later.
Thanks,
Johan
From: Johan Hovold <hidden> Date: 2012-05-03 10:27:01
These patches (against v3.4-rc5) add support for the National Semiconductor /
Texas Instruments LM3533 lighting-power chip.
This multi-function device has four LEDs, two backlights and an
ambient-light-sensor interface.
The LEDs and backlights can be controlled directly, through PWM input,
or by the ambient-light-sensor interface. Hardware-accelerated blinking is
provided for the LEDs.
ALS control is done through defining five light zones and three sets of
corresponding brightness target levels. The ALS iio-driver provides raw and
mean adc readings along with the current light zone through sysfs. A threshold
event can be generated on zone changes.
Further details and specifications are now available from:
http://www.ti.com/product/lm3533
Changes since v1 includes a rewrite of the ambient-light-sensor driver against
iio, the addition of sysfs-ABI documentation, and a switch to regmap for
register io.
This work has been done on behalf of National Semiconductor / Texas
Instruments.
Thanks,
Johan
Johan Hovold (4):
mfd: add LM3533 lighting-power core driver
iio: add LM3533 ambient light sensor driver
leds: add LM3533 LED driver
backlight: add LM3533 backlight driver
.../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
.../testing/sysfs-class-backlight-driver-lm3533 | 50 ++
.../ABI/testing/sysfs-class-led-driver-lm3533 | 67 ++
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3533.c | 741 ++++++++++++++++++++
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/lm3533-core.c | 717 +++++++++++++++++++
drivers/mfd/lm3533-ctrlbank.c | 134 ++++
.../Documentation/sysfs-bus-iio-light-lm3533-als | 62 ++
drivers/staging/iio/light/Kconfig | 16 +
drivers/staging/iio/light/Makefile | 1 +
drivers/staging/iio/light/lm3533-als.c | 617 ++++++++++++++++
drivers/video/backlight/Kconfig | 12 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/lm3533_bl.c | 458 ++++++++++++
include/linux/mfd/lm3533.h | 89 +++
18 files changed, 3031 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-lm3533
create mode 100644 drivers/leds/leds-lm3533.c
create mode 100644 drivers/mfd/lm3533-core.c
create mode 100644 drivers/mfd/lm3533-ctrlbank.c
create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als
create mode 100644 drivers/staging/iio/light/lm3533-als.c
create mode 100644 drivers/video/backlight/lm3533_bl.c
create mode 100644 include/linux/mfd/lm3533.h
--
1.7.8.5
@@ -0,0 +1,50 @@+What: /sys/class/backlight/<backlight>/als+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the ALS-control mode (0,..2), where++ 0 - disabled+ 1 - ALS-mapper 1 (backlight 0)+ 2 - ALS-mapper 2 (backlight 1)++What: /sys/class/backlight/<backlight>/id+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the id of this backlight (0, 1).++What: /sys/class/backlight/<backlight>/linear+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the brightness-mapping mode (0, 1), where++ 0 - exponential mode+ 1 - linear mode++What: /sys/class/backlight/<backlight>/max_current+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the full-scale current I_{LED_FULLSCALE} (0..31), where++ I_{LED_FULLSCALE} = 5mA + max_current * 0.8mA++What: /sys/class/backlight/<backlight>/pwm+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the PWM-input control mask (5 bits), where++ bit 5 - PWM-input enabled in Zone 4+ bit 4 - PWM-input enabled in Zone 3+ bit 3 - PWM-input enabled in Zone 2+ bit 2 - PWM-input enabled in Zone 1+ bit 1 - PWM-input enabled in Zone 0+ bit 0 - PWM-input enabled
@@ -0,0 +1,67 @@+What: /sys/class/leds/<led>/als+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the ALS-control mode (0, 2, 3), where++ 0 - disabled+ 2 - ALS-mapper 2+ 3 - ALS-mapper 3++What: /sys/class/leds/<led>/falltime+What: /sys/class/leds/<led>/risetime+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the pattern generator fall and rise times (0..7), where++ 0 - 2048 us+ 1 - 262 ms+ 2 - 524 ms+ 3 - 1.049 s+ 4 - 2.097 s+ 5 - 4.194 s+ 6 - 8.389 s+ 7 - 16.78 s++What: /sys/class/leds/<led>/id+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the id of this led (0..3).++What: /sys/class/leds/<led>/linear+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the brightness-mapping mode (0, 1), where++ 0 - exponential mode+ 1 - linear mode++What: /sys/class/leds/<led>/max_current+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the full-scale current I_{LED_FULLSCALE} (0..31), where++ I_{LED_FULLSCALE} = 5mA + max_current * 0.8mA++What: /sys/class/leds/<led>/pwm+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the PWM-input control mask (5 bits), where++ bit 5 - PWM-input enabled in Zone 4+ bit 4 - PWM-input enabled in Zone 3+ bit 3 - PWM-input enabled in Zone 2+ bit 2 - PWM-input enabled in Zone 1+ bit 1 - PWM-input enabled in Zone 0+ bit 0 - PWM-input enabled
@@ -50,6 +50,19 @@ config LEDS_LM3530controlledmanuallyorusingPWMinputorusingambientlightautomatically.+configLEDS_LM3533+tristate"LED support for LM3533"+depends onLEDS_CLASS+depends onMFD_LM3533+help+ThisoptionenablessupportfortheLEDsonNationalSemiconductor/+TILM3533LightingPowerchips.++TheLEDscanbecontrolleddirectly,throughPWMinput,orbythe+ambient-light-sensorinterface.Thechipsupports+hardware-acceleratedblinkingwithmaximumonandoffperiodsof9.8+and77secondsrespectively.+configLEDS_LOCOMOtristate"LED Support for Locomo device"depends onLEDS_CLASS
@@ -0,0 +1,38 @@+What: /sys/bus/i2c/devices/.../boost_freq+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the boost converter switching frequency (0, 1), where++ 0 - 500Hz+ 1 - 1000Hz++What: /sys/bus/i2c/devices/.../boost_ovp+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the boost converter over-voltage protection threshold+ (0..3), where++ 0 - 16V+ 1 - 24V+ 2 - 32V+ 3 - 40V++What: /sys/bus/i2c/devices/.../output_hvled[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the controlling backlight device for high-voltage current+ sink HVLED[n] (n = 1, 2) (0, 1).++What: /sys/bus/i2c/devices/.../output_lvled[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the controlling led device for low-voltage current sink+ LVLED[n] (n = 1..5) (0..3).
From: Johan Hovold <hidden> Date: 2012-05-03 10:27:24
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Signed-off-by: Johan Hovold <redacted>
---
v2:
- reimplement using iio
- add sysfs-ABI documentation
.../Documentation/sysfs-bus-iio-light-lm3533-als | 62 ++
drivers/staging/iio/light/Kconfig | 16 +
drivers/staging/iio/light/Makefile | 1 +
drivers/staging/iio/light/lm3533-als.c | 617 ++++++++++++++++++++
4 files changed, 696 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light-lm3533-als
create mode 100644 drivers/staging/iio/light/lm3533-als.c
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain > 0)++What: /sys/bus/iio/devices/iio:deviceX/illuminance_zone+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the current light zone (0..4) as defined by the+ in_illuminance_thresh[n]_{falling,rising} thresholds.++What: /sys/.../events/in_illuminance_thresh_either_en+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Event generated when channel passes one of the four threshold+ in either direction (rising|falling) and a zone change occurs.+ The corresponding light zone can be read from+ illuminance_zone.++What: /sys/.../events/illuminance_thresh0_falling_value+What: /sys/.../events/illuminance_thresh0_raising_value+What: /sys/.../events/illuminance_thresh1_falling_value+What: /sys/.../events/illuminance_thresh1_raising_value+What: /sys/.../events/illuminance_thresh2_falling_value+What: /sys/.../events/illuminance_thresh2_raising_value+What: /sys/.../events/illuminance_thresh3_falling_value+What: /sys/.../events/illuminance_thresh3_raising_value+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Specifies the value of threshold that the device is comparing+ against for the events enabled by+ in_illuminance_thresh_either_en, and defines the+ the five light zones.++ These thresholds correspond to the eight zone-boundary+ registers (boundary[n]_{low,high}).++What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
From: Johan Hovold <hidden> Date: 2012-05-03 10:34:46
[ Sorry for the resend -- Android/gmail apparently added HTML to my previous
attempt. ]
On Apr 26, 2012 2:41 PM, "Mark Brown" [off-list ref]
wrote:
On Fri, Apr 20, 2012 at 05:30:23PM +0200, Johan Hovold wrote:
quoted
+static int __lm3533_read(struct lm3533 *lm3533, u8 reg, u8 *val)+{+ int ret;++ ret = lm3533->read(lm3533, reg, val);+ if (ret < 0) {
Looks like you could save a bunch of code by using regmap for the
register I/O. This would also give you access to the cache and
diagnostic infrastructure it has.
Using regmap only saves about ten lines for the actual io implementation,
but it does allow me to get rid of the custom debugfs interface. I'm not
enabling caching at this point but it'll probably come in handy later.
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-05-03 10:38:55
On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
Add support for National Semiconductor / TI LM3533 lighting power chips.
This is the core driver which provides register access over I2C and
registers the ambient-light-sensor, LED and backlight sub-drivers.
I'd expect you can drop these log messages, if there's stuff like this
missing we should add it to regmap. At the minute the regmap logging is
via trace points rather than debug logs as you can leave them enabled
all the time.
Might also be worth moving some of the sysfs stuff to live with the
relevant drivers.
From: Mark Brown <hidden> Date: 2012-05-03 10:43:49
On Thu, May 03, 2012 at 12:26:38PM +0200, Johan Hovold wrote:
quoted hunk
+What: /sys/class/leds/<led>/risetime+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the pattern generator fall and rise times (0..7), where++ 0 - 2048 us+ 1 - 262 ms+ 2 - 524 ms+ 3 - 1.049 s+ 4 - 2.097 s+ 5 - 4.194 s+ 6 - 8.389 s+ 7 - 16.78 s+
Shouldn't these be controlled by led_blink_set() rather than a custom
ABI?
quoted hunk
+What: /sys/class/leds/<led>/id+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the id of this led (0..3).+
This should just be a generic LED subsystem thing?
quoted hunk
+What: /sys/class/leds/<led>/max_current+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the full-scale current I_{LED_FULLSCALE} (0..31), where++ I_{LED_FULLSCALE} = 5mA + max_current * 0.8mA+
Shouldn't this be set by platform data, the maximum current you can push
through the LEDs seems like a board dependant thing which won't change
dynamically at runtime. The brightness can already be varied.
It'd also be nicer if the kernel did the calculation for the user.
From: Johan Hovold <hidden> Date: 2012-05-03 11:28:10
On Thu, May 03, 2012 at 11:38:48AM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
quoted
Add support for National Semiconductor / TI LM3533 lighting power chips.
This is the core driver which provides register access over I2C and
registers the ambient-light-sensor, LED and backlight sub-drivers.
I'd expect you can drop these log messages, if there's stuff like this
missing we should add it to regmap. At the minute the regmap logging is
via trace points rather than debug logs as you can leave them enabled
all the time.
If such debugging is added to regmap we still need a way to enable them
per driver (or rather regmap) to not clutter the logs.
These three dev_dbg statements are extremely useful during debugging /
development especially in combination with the other dynamic printks in
these drivers.
I'd actually prefer just keeping them for now.
Might also be worth moving some of the sysfs stuff to live with the
relevant drivers.
Which attributes do you have in mind?
The boost_freq and boost_ovp affect both backlight devices (i.e. cannot
be set separately) and as such belong in the parent driver IMO.
Same with the output_hvled{1..2}, output_lvled{1..5} attributes. The
chip has four logical LEDs ("control banks") but five low-voltage output
sinks. The five output_lvled attributes determine the mapping and as
such belong in the parent driver. The two logical backlight devices can
likewise be used to control either or both high-voltage outputs and
belong in the parent driver for the same reasons.
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-05-03 11:38:11
On Thu, May 03, 2012 at 01:28:03PM +0200, Johan Hovold wrote:
On Thu, May 03, 2012 at 11:38:48AM +0100, Mark Brown wrote:
quoted
I'd expect you can drop these log messages, if there's stuff like this
missing we should add it to regmap. At the minute the regmap logging is
via trace points rather than debug logs as you can leave them enabled
all the time.
If such debugging is added to regmap we still need a way to enable them
per driver (or rather regmap) to not clutter the logs.
This is one of the reasons why we currently use tracepoints (they just
don't have this issue as they're trivial to filter), though
adding some sort of infrastructure for it ought not to be too difficult
even if it's just at the regmap level.
These three dev_dbg statements are extremely useful during debugging /
development especially in combination with the other dynamic printks in
these drivers.
I'd actually prefer just keeping them for now.
OTOH the whole point in having stuff like this is to factor out repeated
code like this so if the infrastructure isn't working we should fix
that.
quoted
Might also be worth moving some of the sysfs stuff to live with the
relevant drivers.
Which attributes do you have in mind?
Pretty much all of those on the MFD.
The boost_freq and boost_ovp affect both backlight devices (i.e. cannot
be set separately) and as such belong in the parent driver IMO.
Same with the output_hvled{1..2}, output_lvled{1..5} attributes. The
chip has four logical LEDs ("control banks") but five low-voltage output
sinks. The five output_lvled attributes determine the mapping and as
such belong in the parent driver. The two logical backlight devices can
likewise be used to control either or both high-voltage outputs and
belong in the parent driver for the same reasons.
Actually, the other question I had but forgot to ask (or I think punted
on for your response) was why these are in sysfs at all - things like
which things are connected to the backlight are going to be a property
of the board design so should be defined by the machine not tweaked from
userspace.
From: Jonathan Cameron <hidden> Date: 2012-05-03 11:40:22
On 5/3/2012 11:26 AM, Johan Hovold wrote:
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic. Secondly see
in_illuminance0_scale for a suitable existing attribute.
quoted hunk
++What: /sys/bus/iio/devices/iio:deviceX/illuminance_zone+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Get the current light zone (0..4) as defined by the+ in_illuminance_thresh[n]_{falling,rising} thresholds.
Hmm.. definitely have an in prefix, beyond that I'm not sure what the
cleanest
interface will be for this. Could extend the event codes to deal with the
zone index. Slightly tricky as the channel could already be modified so
chan2 isn't necesarily available.
quoted hunk
++What: /sys/.../events/in_illuminance_thresh_either_en+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Event generated when channel passes one of the four threshold+ in either direction (rising|falling) and a zone change occurs.+ The corresponding light zone can be read from+ illuminance_zone.++What: /sys/.../events/illuminance_thresh0_falling_value
hmm.. every time you think you are making progress a new and exciting
device comes
along requiring the abi to be extended.
in_illuminanceX_threshY_rising_value
in_illuminanceX_threshY_falling_value
should do with appropriate description.
quoted hunk
+What: /sys/.../events/illuminance_thresh0_raising_value+What: /sys/.../events/illuminance_thresh1_falling_value+What: /sys/.../events/illuminance_thresh1_raising_value+What: /sys/.../events/illuminance_thresh2_falling_value+What: /sys/.../events/illuminance_thresh2_raising_value+What: /sys/.../events/illuminance_thresh3_falling_value+What: /sys/.../events/illuminance_thresh3_raising_value+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Specifies the value of threshold that the device is comparing+ against for the events enabled by+ in_illuminance_thresh_either_en, and defines the+ the five light zones.++ These thresholds correspond to the eight zone-boundary+ registers (boundary[n]_{low,high}).+
This interface is going to take some thought. We have
in_illuminance0_target at the
moment, so I guess we can add a zoning concept to that...
quoted hunk
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are and
why there
are 3 ALS-mappers? I'm not getting terribly far on a quick look at the
datasheet!
From: Johan Hovold <hidden> Date: 2012-05-03 11:51:06
On Thu, May 03, 2012 at 11:43:44AM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 12:26:38PM +0200, Johan Hovold wrote:
quoted
+What: /sys/class/leds/<led>/risetime+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the pattern generator fall and rise times (0..7), where++ 0 - 2048 us+ 1 - 262 ms+ 2 - 524 ms+ 3 - 1.049 s+ 4 - 2.097 s+ 5 - 4.194 s+ 6 - 8.389 s+ 7 - 16.78 s+
Shouldn't these be controlled by led_blink_set() rather than a custom
ABI?
led_blink_set controls the on/off times, but the LM3533 has the two
additional rise and fall-time settings which determine the transition
time between these states.
quoted
+What: /sys/class/leds/<led>/id+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the id of this led (0..3).+
This should just be a generic LED subsystem thing?
It's related to the output mapping discussed in my previous mail. The
four logical LEDs (0..3) can be used to control either (or all) of the
five low-voltage output. This attribute provides the identity of the
class devices (logical LEDs) which can then be used in the output
mapping (done in the parent device). These id's have been chosen to
correspond to the MFD-id's, but are really device specific.
quoted
+What: /sys/class/leds/<led>/max_current+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the full-scale current I_{LED_FULLSCALE} (0..31), where++ I_{LED_FULLSCALE} = 5mA + max_current * 0.8mA+
Shouldn't this be set by platform data, the maximum current you can push
through the LEDs seems like a board dependant thing which won't change
dynamically at runtime. The brightness can already be varied.
I fully agree and it is possible to set via the platform data for that
reason. The end-customer, however, insisted that even this setting be
available through sysfs to facilitate their integration and testing.
I'd be willing drop this attribute if requested, as it would only be used
during integration and could easily be added back by the end-customer if
needed.
It'd also be nicer if the kernel did the calculation for the user.
If it was something that was going to be changed a lot, then yes,
perhaps. But as you point out above, this is generally a fixed setting
set using platform data once by integrators that will have access to
the datasheet and it's current table.
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-05-03 14:51:15
On Thu, May 03, 2012 at 01:50:59PM +0200, Johan Hovold wrote:
On Thu, May 03, 2012 at 11:43:44AM +0100, Mark Brown wrote:
quoted
quoted
+ 5 - 4.194 s+ 6 - 8.389 s+ 7 - 16.78 s
quoted
Shouldn't these be controlled by led_blink_set() rather than a custom
ABI?
led_blink_set controls the on/off times, but the LM3533 has the two
additional rise and fall-time settings which determine the transition
time between these states.
Hrm. In that case these rise times are very large - I'd expect them to
cause issues with led_set_blink() users? Though actually I suspect the
solution here is to pull these out into the framework later; we can
probably simulate reasonably in software with a lot of brightness
variable LEDs.
quoted
quoted
+What: /sys/class/leds/<led>/max_current
quoted
Shouldn't this be set by platform data, the maximum current you can push
through the LEDs seems like a board dependant thing which won't change
dynamically at runtime. The brightness can already be varied.
I fully agree and it is possible to set via the platform data for that
reason. The end-customer, however, insisted that even this setting be
available through sysfs to facilitate their integration and testing.
I'd be willing drop this attribute if requested, as it would only be used
during integration and could easily be added back by the end-customer if
needed.
I'd strongly suggest removing this for mainline. If it's present it
should at least be limited to the maximum specified in platform data
(just for safety if nothing else).
From: Johan Hovold <hidden> Date: 2012-05-03 15:00:46
On Thu, May 03, 2012 at 12:38:02PM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 01:28:03PM +0200, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 11:38:48AM +0100, Mark Brown wrote:
quoted
quoted
I'd expect you can drop these log messages, if there's stuff like this
missing we should add it to regmap. At the minute the regmap logging is
via trace points rather than debug logs as you can leave them enabled
all the time.
quoted
If such debugging is added to regmap we still need a way to enable them
per driver (or rather regmap) to not clutter the logs.
This is one of the reasons why we currently use tracepoints (they just
don't have this issue as they're trivial to filter), though
adding some sort of infrastructure for it ought not to be too difficult
even if it's just at the regmap level.
So a /sys/kernel/debug/regmap/<device>/io_printk attribute (with a
better name) to enable debug printks in io paths
(regmap*{read,write,update} outside of mutex) in regmap.c would be
acceptable?
quoted
These three dev_dbg statements are extremely useful during debugging /
development especially in combination with the other dynamic printks in
these drivers.
quoted
I'd actually prefer just keeping them for now.
OTOH the whole point in having stuff like this is to factor out repeated
code like this so if the infrastructure isn't working we should fix
that.
Ok, I'll drop them if you will consider a regmap patch to enable debug
printks to trace reg/val/mask.
quoted
quoted
Might also be worth moving some of the sysfs stuff to live with the
relevant drivers.
quoted
Which attributes do you have in mind?
Pretty much all of those on the MFD.
quoted
The boost_freq and boost_ovp affect both backlight devices (i.e. cannot
be set separately) and as such belong in the parent driver IMO.
quoted
Same with the output_hvled{1..2}, output_lvled{1..5} attributes. The
chip has four logical LEDs ("control banks") but five low-voltage output
sinks. The five output_lvled attributes determine the mapping and as
such belong in the parent driver. The two logical backlight devices can
likewise be used to control either or both high-voltage outputs and
belong in the parent driver for the same reasons.
Actually, the other question I had but forgot to ask (or I think punted
on for your response) was why these are in sysfs at all - things like
which things are connected to the backlight are going to be a property
of the board design so should be defined by the machine not tweaked from
userspace.
I agree with you and the reason is the same as for the max_current
attribute (discussed in the other thread) -- it was an explicit request
from the end customer.
I could replace the boost attributes with a platform_data entry where it
really belongs.
Regarding the output configuration, the chip defaults are probably what
will be used in most cases (i.e. one-one map of logical backlights/leds
and hvled/lvled outputs except for the last led which controls two
outputs). The plan was to add this to the platform data later.
There is a use case (beyond testing/integration) for keeping the (lvled)
outputs configurable from userspace, in that it provides a way to
synchronise LED activity such as blinking. So I still want to keep those,
at least for the lvleds.
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-05-03 15:24:15
On Thu, May 03, 2012 at 05:00:40PM +0200, Johan Hovold wrote:
On Thu, May 03, 2012 at 12:38:02PM +0100, Mark Brown wrote:
quoted
This is one of the reasons why we currently use tracepoints (they just
don't have this issue as they're trivial to filter), though
adding some sort of infrastructure for it ought not to be too difficult
even if it's just at the regmap level.
So a /sys/kernel/debug/regmap/<device>/io_printk attribute (with a
better name) to enable debug printks in io paths
(regmap*{read,write,update} outside of mutex) in regmap.c would be
acceptable?
Yes, that'd be totally fine for me - it's debugfs so we can always drop
it later if someone comes up with a better idea or something.
quoted
Actually, the other question I had but forgot to ask (or I think punted
on for your response) was why these are in sysfs at all - things like
which things are connected to the backlight are going to be a property
of the board design so should be defined by the machine not tweaked from
userspace.
I agree with you and the reason is the same as for the max_current
attribute (discussed in the other thread) -- it was an explicit request
from the end customer.
I could replace the boost attributes with a platform_data entry where it
really belongs.
I really think this is much better for mainline.
There is a use case (beyond testing/integration) for keeping the (lvled)
outputs configurable from userspace, in that it provides a way to
synchronise LED activity such as blinking. So I still want to keep those,
at least for the lvleds.
From: Johan Hovold <hidden> Date: 2012-05-03 16:36:28
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
Secondly see
in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
"If known for a device, scale to be applied to <type>Y[_name]_raw post
addition of <type>[Y][_name]_offset in order to obtain the measured
value in <type> units as specified in <type>[Y][_name]_raw
documentation."
That is, the gain setting has nothing to do with scaling the raw adc
reading to SI-units or such, it's simply a setup dependent gain setting
(which affects the raw readings as well). [And as such, should probably
go into to the platform data eventually as well.]
quoted
++What: /sys/bus/iio/devices/iio:deviceX/illuminance_zone+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Get the current light zone (0..4) as defined by the+ in_illuminance_thresh[n]_{falling,rising} thresholds.
Hmm.. definitely have an in prefix, beyond that I'm not sure what the
cleanest
Thanks for catching this, it's a typo in the sysfs document -- the in_
prefix is in the code.
interface will be for this. Could extend the event codes to deal with the
zone index. Slightly tricky as the channel could already be modified so
chan2 isn't necesarily available.
quoted
++What: /sys/.../events/in_illuminance_thresh_either_en+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Event generated when channel passes one of the four threshold+ in either direction (rising|falling) and a zone change occurs.+ The corresponding light zone can be read from+ illuminance_zone.++What: /sys/.../events/illuminance_thresh0_falling_value
hmm.. every time you think you are making progress a new and exciting
device comes
along requiring the abi to be extended.
Exciting isn't it. :)
in_illuminanceX_threshY_rising_value
in_illuminanceX_threshY_falling_value
should do with appropriate description.
Ok.
quoted
+What: /sys/.../events/illuminance_thresh0_raising_value+What: /sys/.../events/illuminance_thresh1_falling_value+What: /sys/.../events/illuminance_thresh1_raising_value+What: /sys/.../events/illuminance_thresh2_falling_value+What: /sys/.../events/illuminance_thresh2_raising_value+What: /sys/.../events/illuminance_thresh3_falling_value+What: /sys/.../events/illuminance_thresh3_raising_value+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Specifies the value of threshold that the device is comparing+ against for the events enabled by+ in_illuminance_thresh_either_en, and defines the+ the five light zones.++ These thresholds correspond to the eight zone-boundary+ registers (boundary[n]_{low,high}).+
This interface is going to take some thought. We have
in_illuminance0_target at the
moment, so I guess we can add a zoning concept to that...
But target isn't really related, as far as I understand. That's another
calibration setting right? While zone is derived from the average adc
readings. (More below.)
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are and
why there
are 3 ALS-mappers? I'm not getting terribly far on a quick look at the
datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
To simplify somewhat (by ignoring some of the rules): If the average
adc input drops below boundary0_low, the zone register reads 0; if it
drops below boundary1_low, it reads 1, and so on. If the input it
increases over boundary3_high, the zone register return 4; if it
increases passed boundary2_high, it returns zone 3, etc.
That is, roughly something like (we get 8-bits of input from the ADC):
zone 0
boundary0_low 51
boundary0_high 53
zone 1
boundary1_low 102
boundary1_high 106
zone 2
boundary2_low 153
boundary2_high 161
zone 3
boundary3_low 204
boundary3_high 220
zone 4
[ Figure 6 on page 20 in the datasheets should make it clear. ]
The ALS interface and it's zone concept can then be used to control the
LEDs and backlights of the chip, by determining the target brightness for
each zone, e.g., set brightness to 52 when in zone 0.
To complicate things further (and it is complicated), there are three
such sets of target brightness values: ALSM1, ALSM2, ALSM3.
So for each LED or backlight you can set ALS-input control mode, by
saying that the device should get it's brightness levels from target set
1, 2, or 3.
[ And it gets even more complicated, as ALSM1 can only control
backlight0, where as ALSM2 and ALSM3 can control any of the remaining
devices, but that's irrelevant here. ]
Initially, I thought this interface to be too esoteric to be worth
generalising, but it sort of fits with event thresholds so I gave it a
try. The biggest conceptual problem, I think, is that the zone
boundaries can be used to control the other devices, even when the event
is not enabled (or even an irq line not configured). That is, I find it
a bit awkward that the event thresholds also defines the zones (a sort of
discrete scaling factor).
Perhaps simply keeping the attributes outside of events (e.g. named
boundary[n]_{low,high}) and having a custom event enabled (e.g.
in_illuminance_zone_change_en) is the best solution?
[...]
channel doesn't get used unless you also set indexed = 1.
So, you mean I could drop channel as well? Or should I add indexed, as I
use channel 0 when reporting the event?
[...]
quoted
+static int lm3533_als_set_int_mode(struct iio_dev *indio_dev, int enable)+{+ struct lm3533_als *als = iio_priv(indio_dev);+ u8 mask = LM3533_ALS_INT_ENABLE_MASK;+ u8 val;+ int ret;++ if (enable)+ val = mask;+ else+ val = 0;++ ret = lm3533_update(als->lm3533, LM3533_REG_ALS_ZONE_INFO, val, mask);+ if (ret) {+ dev_err(&indio_dev->dev, "failed to set int mode %d\n",+ enable);
extra brackets.
I prefer the brackets for multi-line (single) statements even though
they are not required. (Especially if the single statement spans
several lines -- but I try to be consistent.) If you have a strong
opinion about this, I'll drop them.
From: Johan Hovold <hidden> Date: 2012-05-03 16:46:48
On Thu, May 03, 2012 at 03:51:08PM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 01:50:59PM +0200, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 11:43:44AM +0100, Mark Brown wrote:
quoted
quoted
quoted
+ 5 - 4.194 s+ 6 - 8.389 s+ 7 - 16.78 s
quoted
quoted
Shouldn't these be controlled by led_blink_set() rather than a custom
ABI?
quoted
led_blink_set controls the on/off times, but the LM3533 has the two
additional rise and fall-time settings which determine the transition
time between these states.
Hrm. In that case these rise times are very large - I'd expect them to
cause issues with led_set_blink() users?
They are. The default settings (as fast a transition as possible) will
probably what most people use, and if they start fiddling with the
transition times they probably know what they're doing.
Though actually I suspect the
solution here is to pull these out into the framework later; we can
probably simulate reasonably in software with a lot of brightness
variable LEDs.
Ok.
quoted
quoted
quoted
+What: /sys/class/leds/<led>/max_current
quoted
quoted
Shouldn't this be set by platform data, the maximum current you can push
through the LEDs seems like a board dependant thing which won't change
dynamically at runtime. The brightness can already be varied.
quoted
I fully agree and it is possible to set via the platform data for that
reason. The end-customer, however, insisted that even this setting be
available through sysfs to facilitate their integration and testing.
quoted
I'd be willing drop this attribute if requested, as it would only be used
during integration and could easily be added back by the end-customer if
needed.
I'd strongly suggest removing this for mainline. If it's present it
should at least be limited to the maximum specified in platform data
(just for safety if nothing else).
From: Johan Hovold <hidden> Date: 2012-05-03 16:54:43
On Thu, May 03, 2012 at 04:24:07PM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 05:00:40PM +0200, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:38:02PM +0100, Mark Brown wrote:
quoted
quoted
This is one of the reasons why we currently use tracepoints (they just
don't have this issue as they're trivial to filter), though
adding some sort of infrastructure for it ought not to be too difficult
even if it's just at the regmap level.
quoted
So a /sys/kernel/debug/regmap/<device>/io_printk attribute (with a
better name) to enable debug printks in io paths
(regmap*{read,write,update} outside of mutex) in regmap.c would be
acceptable?
Yes, that'd be totally fine for me - it's debugfs so we can always drop
it later if someone comes up with a better idea or something.
Ok. I'll have a look at this next week (will be on the road for a few
days), and drop the dev_dbg from the lm3533 io-functions for now.
quoted
quoted
Actually, the other question I had but forgot to ask (or I think punted
on for your response) was why these are in sysfs at all - things like
which things are connected to the backlight are going to be a property
of the board design so should be defined by the machine not tweaked from
userspace.
quoted
I agree with you and the reason is the same as for the max_current
attribute (discussed in the other thread) -- it was an explicit request
from the end customer.
quoted
I could replace the boost attributes with a platform_data entry where it
really belongs.
I really think this is much better for mainline.
Agreed.
quoted
There is a use case (beyond testing/integration) for keeping the (lvled)
outputs configurable from userspace, in that it provides a way to
synchronise LED activity such as blinking. So I still want to keep those,
at least for the lvleds.
I'm not sure exactly which control that is?
That would be the output_lvled[n] (n = 1..5) attributes. For example, to
have all five low-voltage sinks blink synchronously, you could assign 0
to all these five attributes, and set a timer trigger for the led device
which has id 0.
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-05-03 16:57:55
On Thu, May 03, 2012 at 06:54:37PM +0200, Johan Hovold wrote:
On Thu, May 03, 2012 at 04:24:07PM +0100, Mark Brown wrote:
quoted
I'm not sure exactly which control that is?
That would be the output_lvled[n] (n = 1..5) attributes. For example, to
have all five low-voltage sinks blink synchronously, you could assign 0
to all these five attributes, and set a timer trigger for the led device
which has id 0.
Sorry, I meant "what exactly does this do in hardware".
From: Johan Hovold <hidden> Date: 2012-05-03 17:14:12
On Thu, May 03, 2012 at 05:57:49PM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 06:54:37PM +0200, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 04:24:07PM +0100, Mark Brown wrote:
quoted
quoted
I'm not sure exactly which control that is?
quoted
That would be the output_lvled[n] (n = 1..5) attributes. For example, to
have all five low-voltage sinks blink synchronously, you could assign 0
to all these five attributes, and set a timer trigger for the led device
which has id 0.
Sorry, I meant "what exactly does this do in hardware".
From the datasheet (page 14):
"CONTROL BANK MAPPING
Control of the LM3533's current sinks is not done directly, but
through the programming of Control Banks. The current sinks are
then assigned to the programmed Control Bank. This allows for
a wide variety of current control possibilities where LEDs can
be grouped and controlled via specific Control Banks (see
Figure 3)."
It is the control banks that has a brightness settings or can be
programmed to blink, that is, they correspond to the logical LEDs and
backlights.
Assigning a current sink to a control bank corresponds, then, to
setting, for example, output_lvled3 to (led) 1.
[ Figure 3 on page 16 of the data sheet may be instructive. In the
figure, BANK A and B corresponds to the two backlight devices, and
BANK C through F corresponds to the four led devices. Note that there
are more outputs (current sinks) than control banks. ]
Thanks,
Johan
From: Mark Brown <hidden> Date: 2012-05-03 17:23:16
On Thu, May 03, 2012 at 07:14:02PM +0200, Johan Hovold wrote:
Assigning a current sink to a control bank corresponds, then, to
setting, for example, output_lvled3 to (led) 1.
This seems sensible enough, though it does feel like what we're offering
up to the LED subsystem is relly the LED control banks rather than the
LEDs themselves - or some mix of this and other stuff.
From: Johan Hovold <hidden> Date: 2012-05-03 17:32:07
On Thu, May 03, 2012 at 06:23:10PM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 07:14:02PM +0200, Johan Hovold wrote:
quoted
Assigning a current sink to a control bank corresponds, then, to
setting, for example, output_lvled3 to (led) 1.
This seems sensible enough, though it does feel like what we're offering
up to the LED subsystem is relly the LED control banks rather than the
LEDs themselves - or some mix of this and other stuff.
Exactly. That's why I've tried to refer to the led devices as "logical
leds" as they may be connected to more than one output (the physical
leds).
Johan
From: Jonathan Cameron <hidden> Date: 2012-05-08 13:47:34
On 5/3/2012 5:36 PM, Johan Hovold wrote:
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
Secondly see
in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently
wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling
before the raw reading is generated (so in hardware).
"If known for a device, scale to be applied to<type>Y[_name]_raw post
addition of<type>[Y][_name]_offset in order to obtain the measured
value in<type> units as specified in<type>[Y][_name]_raw
documentation."
That is, the gain setting has nothing to do with scaling the raw adc
reading to SI-units or such, it's simply a setup dependent gain setting
(which affects the raw readings as well). [And as such, should probably
go into to the platform data eventually as well.]
quoted
quoted
++What: /sys/bus/iio/devices/iio:deviceX/illuminance_zone+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Get the current light zone (0..4) as defined by the+ in_illuminance_thresh[n]_{falling,rising} thresholds.
Hmm.. definitely have an in prefix, beyond that I'm not sure what the
cleanest
Thanks for catching this, it's a typo in the sysfs document -- the in_
prefix is in the code.
quoted
interface will be for this. Could extend the event codes to deal with the
zone index. Slightly tricky as the channel could already be modified so
chan2 isn't necesarily available.
quoted
++What: /sys/.../events/in_illuminance_thresh_either_en+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Event generated when channel passes one of the four threshold+ in either direction (rising|falling) and a zone change occurs.+ The corresponding light zone can be read from+ illuminance_zone.++What: /sys/.../events/illuminance_thresh0_falling_value
hmm.. every time you think you are making progress a new and exciting
device comes
along requiring the abi to be extended.
Exciting isn't it. :)
humph.
quoted
in_illuminanceX_threshY_rising_value
in_illuminanceX_threshY_falling_value
should do with appropriate description.
Ok.
quoted
quoted
+What: /sys/.../events/illuminance_thresh0_raising_value+What: /sys/.../events/illuminance_thresh1_falling_value+What: /sys/.../events/illuminance_thresh1_raising_value+What: /sys/.../events/illuminance_thresh2_falling_value+What: /sys/.../events/illuminance_thresh2_raising_value+What: /sys/.../events/illuminance_thresh3_falling_value+What: /sys/.../events/illuminance_thresh3_raising_value+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Specifies the value of threshold that the device is comparing+ against for the events enabled by+ in_illuminance_thresh_either_en, and defines the+ the five light zones.++ These thresholds correspond to the eight zone-boundary+ registers (boundary[n]_{low,high}).+
This interface is going to take some thought. We have
in_illuminance0_target at the
moment, so I guess we can add a zoning concept to that...
But target isn't really related, as far as I understand. That's another
calibration setting right? While zone is derived from the average adc
readings. (More below.)
True enough. I'd missunderstood this.
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are and
why there
are 3 ALS-mappers? I'm not getting terribly far on a quick look at the
datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes
to fully specify these (nothing would indicate that hysterisis is
involved otherwise).
To simplify somewhat (by ignoring some of the rules): If the average
adc input drops below boundary0_low, the zone register reads 0; if it
drops below boundary1_low, it reads 1, and so on. If the input it
increases over boundary3_high, the zone register return 4; if it
increases passed boundary2_high, it returns zone 3, etc.
That is, roughly something like (we get 8-bits of input from the ADC):
zone 0
boundary0_low 51
boundary0_high 53
zone 1
boundary1_low 102
boundary1_high 106
zone 2
boundary2_low 153
boundary2_high 161
zone 3
boundary3_low 204
boundary3_high 220
zone 4
[ Figure 6 on page 20 in the datasheets should make it clear. ]
The ALS interface and it's zone concept can then be used to control the
LEDs and backlights of the chip, by determining the target brightness for
each zone, e.g., set brightness to 52 when in zone 0.
To complicate things further (and it is complicated), there are three
such sets of target brightness values: ALSM1, ALSM2, ALSM3.
So for each LED or backlight you can set ALS-input control mode, by
saying that the device should get it's brightness levels from target set
1, 2, or 3.
[ And it gets even more complicated, as ALSM1 can only control
backlight0, where as ALSM2 and ALSM3 can control any of the remaining
devices, but that's irrelevant here. ]
Initially, I thought this interface to be too esoteric to be worth
generalising, but it sort of fits with event thresholds so I gave it a
try.
Glad you did and it pretty much fits, be it with a few extensions being
necessary.
The biggest conceptual problem, I think, is that the zone
boundaries can be used to control the other devices, even when the event
is not enabled (or even an irq line not configured). That is, I find it
a bit awkward that the event thresholds also defines the zones (a sort of
discrete scaling factor).
That is indeed awkward. I'm not sure how we handle this either. If we
need to control
these from the other devices (e.g. the back light driver) then we'll
have to get them
into chan_spec and use the inkernel interfaces to do it. Not infeasible but
I was hoping to avoid that until we have had a few months to see what
similar
devices show up (on basis nothing in this world is a one off for long ;)
Perhaps simply keeping the attributes outside of events (e.g. named
boundary[n]_{low,high}) and having a custom event enabled (e.g.
in_illuminance_zone_change_en) is the best solution?
Maybe, but it's ugly and as you have said, they do correspond pretty well to
thresholds so I'd rather you went with that.
The core stuff for registering events clearly needs a rethink.... For
now doing
it as you describe above (with the addition fo hysteresis attributes) should
be fine. Just document the 'quirks'.
channel doesn't get used unless you also set indexed = 1.
So, you mean I could drop channel as well? Or should I add indexed, as I
use channel 0 when reporting the event?
Either option is valid. I personally tend to set indexed = 1 but we
decided that
it didn't matter either way. Userspace code that uses the abi right
should allow
for either.
[...]
quoted
quoted
+static int lm3533_als_set_int_mode(struct iio_dev *indio_dev, int enable)+{+ struct lm3533_als *als = iio_priv(indio_dev);+ u8 mask = LM3533_ALS_INT_ENABLE_MASK;+ u8 val;+ int ret;++ if (enable)+ val = mask;+ else+ val = 0;++ ret = lm3533_update(als->lm3533, LM3533_REG_ALS_ZONE_INFO, val, mask);+ if (ret) {+ dev_err(&indio_dev->dev, "failed to set int mode %d\n",+ enable);
extra brackets.
I prefer the brackets for multi-line (single) statements even though
they are not required. (Especially if the single statement spans
several lines -- but I try to be consistent.) If you have a strong
opinion about this, I'll drop them.
From: Johan Hovold <hidden> Date: 2012-05-10 12:07:53
On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
Hi Johan
On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
quoted
Add support for National Semiconductor / TI LM3533 lighting power chips.
This is the core driver which provides register access over I2C and
registers the ambient-light-sensor, LED and backlight sub-drivers.
Signed-off-by: Johan Hovold <redacted>
---
v2:
- add sysfs-ABI documentation
- merge i2c implementation with core
- use regmap and kill custom debugfs interface
.../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
drivers/mfd/lm3533-ctrlbank.c | 134 ++++
include/linux/mfd/lm3533.h | 89 +++
6 files changed, 992 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
create mode 100644 drivers/mfd/lm3533-core.c
create mode 100644 drivers/mfd/lm3533-ctrlbank.c
create mode 100644 include/linux/mfd/lm3533.h
Patch applied to my for-next branch, thanks.
I've been travelling for a few days and didn't have time to submit a
discussed change to move two attributes to the platform data before I
left.
Could you please apply the following two patches on top of this one?
mfd: lm3533: add boost frequency and ovp to platform data
mfd: lm3533: remove boost attributes
Thanks,
Johan
@@ -0,0 +1,41 @@+What: /sys/class/backlight/<backlight>/als+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the ALS-control mode (0,..2), where++ 0 - disabled+ 1 - ALS-mapper 1 (backlight 0)+ 2 - ALS-mapper 2 (backlight 1)++What: /sys/class/backlight/<backlight>/id+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the id of this backlight (0, 1).++What: /sys/class/backlight/<backlight>/linear+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the brightness-mapping mode (0, 1), where++ 0 - exponential mode+ 1 - linear mode++What: /sys/class/backlight/<backlight>/pwm+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the PWM-input control mask (5 bits), where++ bit 5 - PWM-input enabled in Zone 4+ bit 4 - PWM-input enabled in Zone 3+ bit 3 - PWM-input enabled in Zone 2+ bit 2 - PWM-input enabled in Zone 1+ bit 1 - PWM-input enabled in Zone 0+ bit 0 - PWM-input enabled
From: Samuel Ortiz <hidden> Date: 2012-05-11 13:23:15
Hi Johan,
On Thu, May 10, 2012 at 02:07:42PM +0200, Johan Hovold wrote:
On Wed, May 09, 2012 at 04:42:18PM +0200, Samuel Ortiz wrote:
quoted
Hi Johan
On Thu, May 03, 2012 at 12:26:36PM +0200, Johan Hovold wrote:
quoted
Add support for National Semiconductor / TI LM3533 lighting power chips.
This is the core driver which provides register access over I2C and
registers the ambient-light-sensor, LED and backlight sub-drivers.
Signed-off-by: Johan Hovold <redacted>
---
v2:
- add sysfs-ABI documentation
- merge i2c implementation with core
- use regmap and kill custom debugfs interface
.../ABI/testing/sysfs-bus-i2c-devices-lm3533 | 38 +
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/lm3533-core.c | 717 ++++++++++++++++++++
drivers/mfd/lm3533-ctrlbank.c | 134 ++++
include/linux/mfd/lm3533.h | 89 +++
6 files changed, 992 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
create mode 100644 drivers/mfd/lm3533-core.c
create mode 100644 drivers/mfd/lm3533-ctrlbank.c
create mode 100644 include/linux/mfd/lm3533.h
Patch applied to my for-next branch, thanks.
I've been travelling for a few days and didn't have time to submit a
discussed change to move two attributes to the platform data before I
left.
Could you please apply the following two patches on top of this one?
All of your 4 pending patches have been applied, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
From: Johan Hovold <hidden> Date: 2012-05-15 16:45:08
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
On 5/3/2012 5:36 PM, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
quoted
Secondly see in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
[...]
quoted
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are
and why there are 3 ALS-mappers? I'm not getting terribly far on a
quick look at the datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes to fully specify these (nothing would indicate
that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
quoted
To simplify somewhat (by ignoring some of the rules): If the average
adc input drops below boundary0_low, the zone register reads 0; if it
drops below boundary1_low, it reads 1, and so on. If the input it
increases over boundary3_high, the zone register return 4; if it
increases passed boundary2_high, it returns zone 3, etc.
That is, roughly something like (we get 8-bits of input from the ADC):
zone 0
boundary0_low 51
boundary0_high 53
zone 1
boundary1_low 102
boundary1_high 106
zone 2
boundary2_low 153
boundary2_high 161
zone 3
boundary3_low 204
boundary3_high 220
zone 4
[ Figure 6 on page 20 in the datasheets should make it clear. ]
The ALS interface and it's zone concept can then be used to control the
LEDs and backlights of the chip, by determining the target brightness for
each zone, e.g., set brightness to 52 when in zone 0.
To complicate things further (and it is complicated), there are three
such sets of target brightness values: ALSM1, ALSM2, ALSM3.
So for each LED or backlight you can set ALS-input control mode, by
saying that the device should get it's brightness levels from target set
1, 2, or 3.
[ And it gets even more complicated, as ALSM1 can only control
backlight0, where as ALSM2 and ALSM3 can control any of the remaining
devices, but that's irrelevant here. ]
Initially, I thought this interface to be too esoteric to be worth
generalising, but it sort of fits with event thresholds so I gave it a
try.
Glad you did and it pretty much fits, be it with a few extensions being
necessary.
quoted
The biggest conceptual problem, I think, is that the zone
boundaries can be used to control the other devices, even when the event
is not enabled (or even an irq line not configured). That is, I find it
a bit awkward that the event thresholds also defines the zones (a sort of
discrete scaling factor).
That is indeed awkward. I'm not sure how we handle this either. If we
need to control these from the other devices (e.g. the back light
driver) then we'll have to get them into chan_spec and use the
inkernel interfaces to do it. Not infeasible but I was hoping to
avoid that until we have had a few months to see what similar devices
show up (on basis nothing in this world is a one off for long ;)
I don't think the control bits can or should be generalised at this
point. The same ALS-target values may be used to control more than one
device, so they need to be set from the als rather from the controlled
device (otherwise, changing the target value of led1 could change that
of the other three leds without the user realising that this can be a
side effect).
quoted
Perhaps simply keeping the attributes outside of events (e.g. named
boundary[n]_{low,high}) and having a custom event enabled (e.g.
in_illuminance_zone_change_en) is the best solution?
Maybe, but it's ugly and as you have said, they do correspond pretty well to
thresholds so I'd rather you went with that.
The core stuff for registering events clearly needs a rethink.... For
now doing it as you describe above (with the addition fo hysteresis
attributes) should be fine. Just document the 'quirks'.
Ok, I'll keep the event/zone interface as it stands for now and we'll
see if it can be generalised later. [ See my comment on the hysteresis
above: there are only the rising/falling thresholds (low/high
boundaries) and no boundary or hysteresis settings. ]
Thanks,
Johan
@@ -0,0 +1,41 @@+What: /sys/class/backlight/<backlight>/als+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the ALS-control mode (0..2), where++ 0 - disabled+ 1 - ALS-mapper 1 (backlight 0)+ 2 - ALS-mapper 2 (backlight 1)++What: /sys/class/backlight/<backlight>/id+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Get the id of this backlight (0, 1).++What: /sys/class/backlight/<backlight>/linear+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the brightness-mapping mode (0, 1), where++ 0 - exponential mode+ 1 - linear mode++What: /sys/class/backlight/<backlight>/pwm+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold <jhovold@gmail.com>+Description:+ Set the PWM-input control mask (5 bits), where++ bit 5 - PWM-input enabled in Zone 4+ bit 4 - PWM-input enabled in Zone 3+ bit 3 - PWM-input enabled in Zone 2+ bit 2 - PWM-input enabled in Zone 1+ bit 1 - PWM-input enabled in Zone 0+ bit 0 - PWM-input enabled
From: Jonathan Cameron <jic23@kernel.org> Date: 2012-05-15 20:01:00
On 05/15/2012 05:44 PM, Johan Hovold wrote:
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 5:36 PM, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
quoted
Secondly see in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
This is a generic element that really ought to just fit in with the
equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
be unit free for starters.
[...]
quoted
quoted
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are
and why there are 3 ALS-mappers? I'm not getting terribly far on a
quick look at the datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes to fully specify these (nothing would indicate
that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
Nope, because they don't tell a general userspace application what is
going on. Without hysterisis attributes it has no way of knowing there
is hysterisis present. Feel free to make them read only though.
quoted
quoted
To simplify somewhat (by ignoring some of the rules): If the average
adc input drops below boundary0_low, the zone register reads 0; if it
drops below boundary1_low, it reads 1, and so on. If the input it
increases over boundary3_high, the zone register return 4; if it
increases passed boundary2_high, it returns zone 3, etc.
That is, roughly something like (we get 8-bits of input from the ADC):
zone 0
boundary0_low 51
boundary0_high 53
zone 1
boundary1_low 102
boundary1_high 106
zone 2
boundary2_low 153
boundary2_high 161
zone 3
boundary3_low 204
boundary3_high 220
zone 4
[ Figure 6 on page 20 in the datasheets should make it clear. ]
The ALS interface and it's zone concept can then be used to control the
LEDs and backlights of the chip, by determining the target brightness for
each zone, e.g., set brightness to 52 when in zone 0.
To complicate things further (and it is complicated), there are three
such sets of target brightness values: ALSM1, ALSM2, ALSM3.
So for each LED or backlight you can set ALS-input control mode, by
saying that the device should get it's brightness levels from target set
1, 2, or 3.
[ And it gets even more complicated, as ALSM1 can only control
backlight0, where as ALSM2 and ALSM3 can control any of the remaining
devices, but that's irrelevant here. ]
Initially, I thought this interface to be too esoteric to be worth
generalising, but it sort of fits with event thresholds so I gave it a
try.
Glad you did and it pretty much fits, be it with a few extensions being
necessary.
quoted
The biggest conceptual problem, I think, is that the zone
boundaries can be used to control the other devices, even when the event
is not enabled (or even an irq line not configured). That is, I find it
a bit awkward that the event thresholds also defines the zones (a sort of
discrete scaling factor).
That is indeed awkward. I'm not sure how we handle this either. If we
need to control these from the other devices (e.g. the back light
driver) then we'll have to get them into chan_spec and use the
inkernel interfaces to do it. Not infeasible but I was hoping to
avoid that until we have had a few months to see what similar devices
show up (on basis nothing in this world is a one off for long ;)
I don't think the control bits can or should be generalised at this
point. The same ALS-target values may be used to control more than one
device, so they need to be set from the als rather from the controlled
device (otherwise, changing the target value of led1 could change that
of the other three leds without the user realising that this can be a
side effect).
Good point. Nasty little device to write an interface for :)
quoted
quoted
Perhaps simply keeping the attributes outside of events (e.g. named
boundary[n]_{low,high}) and having a custom event enabled (e.g.
in_illuminance_zone_change_en) is the best solution?
Maybe, but it's ugly and as you have said, they do correspond pretty well to
thresholds so I'd rather you went with that.
The core stuff for registering events clearly needs a rethink.... For
now doing it as you describe above (with the addition fo hysteresis
attributes) should be fine. Just document the 'quirks'.
Ok, I'll keep the event/zone interface as it stands for now and we'll
see if it can be generalised later. [ See my comment on the hysteresis
above: there are only the rising/falling thresholds (low/high
boundaries) and no boundary or hysteresis settings. ]
On that, just to reiterate, to have anything generalizable, userspace
needs to know that hysterisis exists on the individual thresholds
(though it is clearly a function of the neighbouring one).
From: Johan Hovold <hidden> Date: 2012-05-16 13:05:18
On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
On 05/15/2012 05:44 PM, Johan Hovold wrote:
quoted
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 5:36 PM, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
quoted
Secondly see in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
This is a generic element that really ought to just fit in with the
equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
be unit free for starters.
I'm starting to doubt that calibscale is really appropriate in this case.
For starters, the description in sysfs-bus-iio doesn't really apply:
"Hardware applied calibration scale factor. (assumed to fix
production inaccuracies)."
The resistor setting of the lm3533 is about fitting an external analog
light sensor to the lm3533 als interface (which is basically just an adc
with some extra logic), that is, it is used to match the output current
of the chosen sensor so that the ADC measures 2V at full LUX.
It's not a setting to calibrate "inaccuracies", but rather an
integration parameter that is set once when the characteristics of the
light sensor is known. (Sure, it could be used later to increase
sensitivity as well, but the main purpose is to fit a new light sensor
to a generic input interface.)
quoted
[...]
quoted
quoted
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are
and why there are 3 ALS-mappers? I'm not getting terribly far on a
quick look at the datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes to fully specify these (nothing would indicate
that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
Nope, because they don't tell a general userspace application what is
going on. Without hysterisis attributes it has no way of knowing there
is hysterisis present.
Well an application could simply look at the difference between raising
and falling to determine the hysteresis?
It gets more complicated as the lm3533 allow the raising threshold to
be lower than the falling. It appears the device is using whichever
register is lower for the falling threshold. I guess I should compensate
for this in the driver.
Furthermore, you can define threshold 1 to be lower than threshold 0,
effectively preventing zone 1 to be reached. In this case, dropping
below thres1_falling gives zone 0, and raising above thres1_raising gives
zone 2. In particular, no threshold event is generated when
thres0_{falling/raising} is passed in either direction. But perhaps this
should just be documented as a feature/quirk of the device.
Feel free to make them read only though.
So you're suggesting something like:
events/in_illuminance0_threshY_falling_value
events/in_illuminance0_threshY_raising_value
events/in_illuminance0_threshY_hysteresis
where hysteresis is a read-only attribute whose value is
threshY_raising_value - threshY_falling_value
quoted
quoted
quoted
To simplify somewhat (by ignoring some of the rules): If the average
adc input drops below boundary0_low, the zone register reads 0; if it
drops below boundary1_low, it reads 1, and so on. If the input it
increases over boundary3_high, the zone register return 4; if it
increases passed boundary2_high, it returns zone 3, etc.
That is, roughly something like (we get 8-bits of input from the ADC):
zone 0
boundary0_low 51
boundary0_high 53
zone 1
boundary1_low 102
boundary1_high 106
zone 2
boundary2_low 153
boundary2_high 161
zone 3
boundary3_low 204
boundary3_high 220
zone 4
[ Figure 6 on page 20 in the datasheets should make it clear. ]
The ALS interface and it's zone concept can then be used to control the
LEDs and backlights of the chip, by determining the target brightness for
each zone, e.g., set brightness to 52 when in zone 0.
To complicate things further (and it is complicated), there are three
such sets of target brightness values: ALSM1, ALSM2, ALSM3.
So for each LED or backlight you can set ALS-input control mode, by
saying that the device should get it's brightness levels from target set
1, 2, or 3.
[ And it gets even more complicated, as ALSM1 can only control
backlight0, where as ALSM2 and ALSM3 can control any of the remaining
devices, but that's irrelevant here. ]
Initially, I thought this interface to be too esoteric to be worth
generalising, but it sort of fits with event thresholds so I gave it a
try.
Glad you did and it pretty much fits, be it with a few extensions being
necessary.
quoted
The biggest conceptual problem, I think, is that the zone
boundaries can be used to control the other devices, even when the event
is not enabled (or even an irq line not configured). That is, I find it
a bit awkward that the event thresholds also defines the zones (a sort of
discrete scaling factor).
That is indeed awkward. I'm not sure how we handle this either. If we
need to control these from the other devices (e.g. the back light
driver) then we'll have to get them into chan_spec and use the
inkernel interfaces to do it. Not infeasible but I was hoping to
avoid that until we have had a few months to see what similar devices
show up (on basis nothing in this world is a one off for long ;)
I don't think the control bits can or should be generalised at this
point. The same ALS-target values may be used to control more than one
device, so they need to be set from the als rather from the controlled
device (otherwise, changing the target value of led1 could change that
of the other three leds without the user realising that this can be a
side effect).
Good point. Nasty little device to write an interface for :)
Indeed. Thanks for appreciating that. ;)
quoted
quoted
quoted
Perhaps simply keeping the attributes outside of events (e.g. named
boundary[n]_{low,high}) and having a custom event enabled (e.g.
in_illuminance_zone_change_en) is the best solution?
Maybe, but it's ugly and as you have said, they do correspond pretty well to
thresholds so I'd rather you went with that.
The core stuff for registering events clearly needs a rethink.... For
now doing it as you describe above (with the addition fo hysteresis
attributes) should be fine. Just document the 'quirks'.
Ok, I'll keep the event/zone interface as it stands for now and we'll
see if it can be generalised later. [ See my comment on the hysteresis
above: there are only the rising/falling thresholds (low/high
boundaries) and no boundary or hysteresis settings. ]
On that, just to reiterate, to have anything generalizable, userspace
needs to know that hysterisis exists on the individual thresholds
(though it is clearly a function of the neighbouring one).
From: Jonathan Cameron <hidden> Date: 2012-05-16 14:21:29
On 5/16/2012 2:05 PM, Johan Hovold wrote:
On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
quoted
On 05/15/2012 05:44 PM, Johan Hovold wrote:
quoted
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 5:36 PM, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
quoted
Secondly see in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
This is a generic element that really ought to just fit in with the
equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
be unit free for starters.
I'm starting to doubt that calibscale is really appropriate in this case.
For starters, the description in sysfs-bus-iio doesn't really apply:
"Hardware applied calibration scale factor. (assumed to fix
production inaccuracies)."
Hmm.. if you really don't like this, Michael Hennerich had a case
where this made even less sense, so we now have hardwaregain.
Use that if you like...
The resistor setting of the lm3533 is about fitting an external analog
light sensor to the lm3533 als interface (which is basically just an adc
with some extra logic), that is, it is used to match the output current
of the chosen sensor so that the ADC measures 2V at full LUX.
It's not a setting to calibrate "inaccuracies", but rather an
integration parameter that is set once when the characteristics of the
light sensor is known. (Sure, it could be used later to increase
sensitivity as well, but the main purpose is to fit a new light sensor
to a generic input interface.)
quoted
quoted
[...]
quoted
quoted
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are
and why there are 3 ALS-mappers? I'm not getting terribly far on a
quick look at the datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes to fully specify these (nothing would indicate
that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
Nope, because they don't tell a general userspace application what is
going on. Without hysterisis attributes it has no way of knowing there
is hysterisis present.
Well an application could simply look at the difference between raising
and falling to determine the hysteresis?
Only if it knows it has your sensor. For other sensors it could be
completely separate or not present. If the parameter is missing
assumption is that there is no hysterisis.
It gets more complicated as the lm3533 allow the raising threshold to
be lower than the falling. It appears the device is using whichever
register is lower for the falling threshold. I guess I should compensate
for this in the driver.
That's nasty.
Furthermore, you can define threshold 1 to be lower than threshold 0,
effectively preventing zone 1 to be reached. In this case, dropping
below thres1_falling gives zone 0, and raising above thres1_raising gives
zone 2. In particular, no threshold event is generated when
thres0_{falling/raising} is passed in either direction. But perhaps this
should just be documented as a feature/quirk of the device.
Seems sensible...
quoted
Feel free to make them read only though.
So you're suggesting something like:
events/in_illuminance0_threshY_falling_value
events/in_illuminance0_threshY_raising_value
events/in_illuminance0_threshY_hysteresis
where hysteresis is a read-only attribute whose value is
threshY_raising_value - threshY_falling_value
yes. Annoying it may be but it matches existing interface.
quoted
quoted
quoted
quoted
To simplify somewhat (by ignoring some of the rules): If the average
adc input drops below boundary0_low, the zone register reads 0; if it
drops below boundary1_low, it reads 1, and so on. If the input it
increases over boundary3_high, the zone register return 4; if it
increases passed boundary2_high, it returns zone 3, etc.
That is, roughly something like (we get 8-bits of input from the ADC):
zone 0
boundary0_low 51
boundary0_high 53
zone 1
boundary1_low 102
boundary1_high 106
zone 2
boundary2_low 153
boundary2_high 161
zone 3
boundary3_low 204
boundary3_high 220
zone 4
[ Figure 6 on page 20 in the datasheets should make it clear. ]
The ALS interface and it's zone concept can then be used to control the
LEDs and backlights of the chip, by determining the target brightness for
each zone, e.g., set brightness to 52 when in zone 0.
To complicate things further (and it is complicated), there are three
such sets of target brightness values: ALSM1, ALSM2, ALSM3.
So for each LED or backlight you can set ALS-input control mode, by
saying that the device should get it's brightness levels from target set
1, 2, or 3.
[ And it gets even more complicated, as ALSM1 can only control
backlight0, where as ALSM2 and ALSM3 can control any of the remaining
devices, but that's irrelevant here. ]
Initially, I thought this interface to be too esoteric to be worth
generalising, but it sort of fits with event thresholds so I gave it a
try.
Glad you did and it pretty much fits, be it with a few extensions being
necessary.
quoted
The biggest conceptual problem, I think, is that the zone
boundaries can be used to control the other devices, even when the event
is not enabled (or even an irq line not configured). That is, I find it
a bit awkward that the event thresholds also defines the zones (a sort of
discrete scaling factor).
That is indeed awkward. I'm not sure how we handle this either. If we
need to control these from the other devices (e.g. the back light
driver) then we'll have to get them into chan_spec and use the
inkernel interfaces to do it. Not infeasible but I was hoping to
avoid that until we have had a few months to see what similar devices
show up (on basis nothing in this world is a one off for long ;)
I don't think the control bits can or should be generalised at this
point. The same ALS-target values may be used to control more than one
device, so they need to be set from the als rather from the controlled
device (otherwise, changing the target value of led1 could change that
of the other three leds without the user realising that this can be a
side effect).
Good point. Nasty little device to write an interface for :)
Indeed. Thanks for appreciating that. ;)
quoted
quoted
quoted
quoted
Perhaps simply keeping the attributes outside of events (e.g. named
boundary[n]_{low,high}) and having a custom event enabled (e.g.
in_illuminance_zone_change_en) is the best solution?
Maybe, but it's ugly and as you have said, they do correspond pretty well to
thresholds so I'd rather you went with that.
The core stuff for registering events clearly needs a rethink.... For
now doing it as you describe above (with the addition fo hysteresis
attributes) should be fine. Just document the 'quirks'.
Ok, I'll keep the event/zone interface as it stands for now and we'll
see if it can be generalised later. [ See my comment on the hysteresis
above: there are only the rising/falling thresholds (low/high
boundaries) and no boundary or hysteresis settings. ]
On that, just to reiterate, to have anything generalizable, userspace
needs to know that hysterisis exists on the individual thresholds
(though it is clearly a function of the neighbouring one).
From: Johan Hovold <hidden> Date: 2012-05-18 12:27:34
On Wed, May 16, 2012 at 03:21:14PM +0100, Jonathan Cameron wrote:
On 5/16/2012 2:05 PM, Johan Hovold wrote:
quoted
On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
quoted
On 05/15/2012 05:44 PM, Johan Hovold wrote:
quoted
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 5:36 PM, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
quoted
Secondly see in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
This is a generic element that really ought to just fit in with the
equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
be unit free for starters.
I'm starting to doubt that calibscale is really appropriate in this case.
For starters, the description in sysfs-bus-iio doesn't really apply:
"Hardware applied calibration scale factor. (assumed to fix
production inaccuracies)."
Hmm.. if you really don't like this, Michael Hennerich had a case
where this made even less sense, so we now have hardwaregain.
Use that if you like...
I really think that this should remain a device specific attribute as I
originally suggested. It's an integration parameter that needs to be set
precisely depending on the actual hardware setup (which analog light
sensor and other external components).
The lm3533 also supports two types of light sensors: pwm- and analog-
output ones. The resistor select settings only applies when in analog
mode as the input is always high impedance otherwise. Thus a generic
attribute (such as calibscale or hardware gain) shouldn't be used as it
will have no effect whatsoever in PWM-mode.
I'm thus back at my original proposal, albeit with a different name (I
think a lot of this discussion could have been avoided had I not
misnamed the parameter "gain"):
What: /sys/bus/iio/devices/iio:deviceX/r_select
Description:
Set the ALS internal pull-down resistor for analog input mode
(1..127), such that,
R_als = 200000 / r_select (ohm)
This setting is ignored in PWM-mode (input is always high
impedance in PWM-mode).
I don't think much is gained from using ohm as the unit: it just adds
complexity and the selected resistor setting will likely not match the
input value anyway. It's better that the chip integrators have full
control over which resistor setting is actually used so that it matches
external components.
quoted
The resistor setting of the lm3533 is about fitting an external analog
light sensor to the lm3533 als interface (which is basically just an adc
with some extra logic), that is, it is used to match the output current
of the chosen sensor so that the ADC measures 2V at full LUX.
It's not a setting to calibrate "inaccuracies", but rather an
integration parameter that is set once when the characteristics of the
light sensor is known. (Sure, it could be used later to increase
sensitivity as well, but the main purpose is to fit a new light sensor
to a generic input interface.)
quoted
quoted
[...]
quoted
quoted
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are
and why there are 3 ALS-mappers? I'm not getting terribly far on a
quick look at the datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes to fully specify these (nothing would indicate
that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
Nope, because they don't tell a general userspace application what is
going on. Without hysterisis attributes it has no way of knowing there
is hysterisis present.
Well an application could simply look at the difference between raising
and falling to determine the hysteresis?
Only if it knows it has your sensor. For other sensors it could be
completely separate or not present. If the parameter is missing
assumption is that there is no hysterisis.
quoted
It gets more complicated as the lm3533 allow the raising threshold to
be lower than the falling. It appears the device is using whichever
register is lower for the falling threshold. I guess I should compensate
for this in the driver.
That's nasty.
quoted
Furthermore, you can define threshold 1 to be lower than threshold 0,
effectively preventing zone 1 to be reached. In this case, dropping
below thres1_falling gives zone 0, and raising above thres1_raising gives
zone 2. In particular, no threshold event is generated when
thres0_{falling/raising} is passed in either direction. But perhaps this
should just be documented as a feature/quirk of the device.
Seems sensible...
quoted
quoted
Feel free to make them read only though.
So you're suggesting something like:
events/in_illuminance0_threshY_falling_value
events/in_illuminance0_threshY_raising_value
events/in_illuminance0_threshY_hysteresis
where hysteresis is a read-only attribute whose value is
threshY_raising_value - threshY_falling_value
yes. Annoying it may be but it matches existing interface.
I'm posting a v4 which includes the above proposal for resistor select.
I've also added the hysteresis attributes as requested and fixed the
device threshold quirkiness mentioned above (the device is using
whichever register value is smaller as the falling threshold).
Thanks,
Johan
From: Jonathan Cameron <jic23@kernel.org> Date: 2012-05-18 17:34:07
On 05/18/2012 01:27 PM, Johan Hovold wrote:
On Wed, May 16, 2012 at 03:21:14PM +0100, Jonathan Cameron wrote:
quoted
On 5/16/2012 2:05 PM, Johan Hovold wrote:
quoted
On Tue, May 15, 2012 at 09:00:46PM +0100, Jonathan Cameron wrote:
quoted
On 05/15/2012 05:44 PM, Johan Hovold wrote:
quoted
On Tue, May 08, 2012 at 02:47:19PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 5:36 PM, Johan Hovold wrote:
quoted
On Thu, May 03, 2012 at 12:40:10PM +0100, Jonathan Cameron wrote:
quoted
On 5/3/2012 11:26 AM, Johan Hovold wrote:
quoted
Add sub-driver for the ambient light sensor interface on National
Semiconductor / TI LM3533 lighting power chips.
The sensor interface can be used to control the LEDs and backlights of
the chip through defining five light zones and three sets of
corresponding brightness target levels.
The driver provides raw and mean adc readings along with the current
light zone through sysfs. A threshold event can be generated on zone
changes.
Code is fine. Pretty much all my comments are to do with the interface.
@@ -0,0 +1,62 @@+What: /sys/bus/iio/devices/iio:deviceX/gain+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the ALS gain-resistor setting (0..127) for analog input+ mode, where++ 0000000 - ALS input is high impedance+ 0000001 - 200kOhm (10uA at 2V full-scale)+ 0000010 - 100kOhm (20uA at 2V full-scale)+ ...+ 1111110 - 1.587kOhm (1.26mA at 2V full-scale)+ 1111111 - 1.575kOhm (1.27mA at 2V full-scale)++ R_als = 2V / (10uA * gain) (gain> 0)
Firstly, no magic numbers. These are definitely magic.
Not that magic as they're clearly documented (in code and public
datasheets), right? What would you prefer instead?
The numbers on the right of the - look good to me though then this isn't
a gain. (200kohm) and the infinite element is annoying. Why not
compute the actual gains?
Gain = (Rals*10e-6)/2 and use those values? Yes you will have to do
a bit of fixed point maths in the driver but the advantage is you'll
have real values that are standardizable across multiple devices
and hence allow your device to be operated by generic userspace
code. Welcome to standardising interfaces - my favourite occupation ;)
quoted
quoted
Secondly see in_illuminance0_scale for a suitable existing attribute.
I didn't consider scale to be appropriate given the following
documentation (e.g, for in_voltageY_scale):
sorry I just did this to someone else in another review (so I'm
consistently wrong!)
in_voltageY_calibscale is what I should have said. That one applies a
scaling before the raw reading is generated (so in hardware).
Ok, then calibscale is the appropriate attribute for the resistor
setting. But as this is a device-specific hardware-calibration setting
I would suggest using the following interface:
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
Description:
Set the ALS calibration scale (internal resistors) for
analog input mode, where the scale factor is the current in uA
at 2V full-scale (10..1270, 10uA step), that is,
R_als = 2V / in_illuminance_calibscale
This setting is ignored in PWM mode.
This is a generic element that really ought to just fit in with the
equivalent in sysfs-bus-iio for calibscan. It's a ratio, so it should
be unit free for starters.
I'm starting to doubt that calibscale is really appropriate in this case.
For starters, the description in sysfs-bus-iio doesn't really apply:
"Hardware applied calibration scale factor. (assumed to fix
production inaccuracies)."
Hmm.. if you really don't like this, Michael Hennerich had a case
where this made even less sense, so we now have hardwaregain.
Use that if you like...
I really think that this should remain a device specific attribute as I
originally suggested. It's an integration parameter that needs to be set
precisely depending on the actual hardware setup (which analog light
sensor and other external components).
Then it shouldn't be exposed to userspace. If there is reason to vary
it from userspace then it is a calibration parameter and should be
treated like the other ones we have, if not it should be done from
dt or platform data.
The lm3533 also supports two types of light sensors: pwm- and analog-
output ones. The resistor select settings only applies when in analog
mode as the input is always high impedance otherwise. Thus a generic
attribute (such as calibscale or hardware gain) shouldn't be used as it
will have no effect whatsoever in PWM-mode.
I'm thus back at my original proposal, albeit with a different name (I
think a lot of this discussion could have been avoided had I not
misnamed the parameter "gain"):
What: /sys/bus/iio/devices/iio:deviceX/r_select
Description:
Set the ALS internal pull-down resistor for analog input mode
(1..127), such that,
R_als = 200000 / r_select (ohm)
This setting is ignored in PWM-mode (input is always high
impedance in PWM-mode).
I don't think much is gained from using ohm as the unit: it just adds
complexity and the selected resistor setting will likely not match the
input value anyway. It's better that the chip integrators have full
control over which resistor setting is actually used so that it matches
external components.
This smacks of something that should never be exposed to users.
I'd hide it away in platform data.
quoted
quoted
The resistor setting of the lm3533 is about fitting an external analog
light sensor to the lm3533 als interface (which is basically just an adc
with some extra logic), that is, it is used to match the output current
of the chosen sensor so that the ADC measures 2V at full LUX.
It's not a setting to calibrate "inaccuracies", but rather an
integration parameter that is set once when the characteristics of the
light sensor is known. (Sure, it could be used later to increase
sensitivity as well, but the main purpose is to fit a new light sensor
to a generic input interface.)
quoted
quoted
[...]
quoted
quoted
quoted
quoted
+What: /sys/bus/iio/devices/iio:deviceX/target[m]_[n]+Date: April 2012+KernelVersion: 3.5+Contact: Johan Hovold<jhovold@gmail.com>+Description:+ Set the target brightness for ALS-mapper m in light zone n+ (0..255), where m in 1..3 and n in 0..4.
Don't suppose you could do a quick summary of what these zones are
and why there are 3 ALS-mappers? I'm not getting terribly far on a
quick look at the datasheet!
Of course. The average adc readings are mapped to five light zones using
eight zone boundary registers (4 boundaries with hysteresis) and a set
of rules.
This is going to be fun. We'll need the boundaries and attached
hysteresis attributes to fully specify these (nothing would indicate
that hysterisis is involved otherwise).
You can't define the hysteresis explicitly with the lm3533 register
interface, rather it's is defined implicitly in case threshY_falling is
less than threshY_rasising.
So the raising/falling attributes should be enough, right?
Nope, because they don't tell a general userspace application what is
going on. Without hysterisis attributes it has no way of knowing there
is hysterisis present.
Well an application could simply look at the difference between raising
and falling to determine the hysteresis?
Only if it knows it has your sensor. For other sensors it could be
completely separate or not present. If the parameter is missing
assumption is that there is no hysterisis.
quoted
It gets more complicated as the lm3533 allow the raising threshold to
be lower than the falling. It appears the device is using whichever
register is lower for the falling threshold. I guess I should compensate
for this in the driver.
That's nasty.
quoted
Furthermore, you can define threshold 1 to be lower than threshold 0,
effectively preventing zone 1 to be reached. In this case, dropping
below thres1_falling gives zone 0, and raising above thres1_raising gives
zone 2. In particular, no threshold event is generated when
thres0_{falling/raising} is passed in either direction. But perhaps this
should just be documented as a feature/quirk of the device.
Seems sensible...
quoted
quoted
Feel free to make them read only though.
So you're suggesting something like:
events/in_illuminance0_threshY_falling_value
events/in_illuminance0_threshY_raising_value
events/in_illuminance0_threshY_hysteresis
where hysteresis is a read-only attribute whose value is
threshY_raising_value - threshY_falling_value
yes. Annoying it may be but it matches existing interface.
I'm posting a v4 which includes the above proposal for resistor select.
I've also added the hysteresis attributes as requested and fixed the
device threshold quirkiness mentioned above (the device is using
whichever register value is smaller as the falling threshold).
From: Johan Hovold <hidden> Date: 2012-05-18 17:57:49
On Fri, May 18, 2012 at 06:34:01PM +0100, Jonathan Cameron wrote:
On 05/18/2012 01:27 PM, Johan Hovold wrote:
[...]
quoted
I really think that this should remain a device specific attribute as I
originally suggested. It's an integration parameter that needs to be set
precisely depending on the actual hardware setup (which analog light
sensor and other external components).
Then it shouldn't be exposed to userspace. If there is reason to vary
it from userspace then it is a calibration parameter and should be
treated like the other ones we have, if not it should be done from
dt or platform data.
quoted
The lm3533 also supports two types of light sensors: pwm- and analog-
output ones. The resistor select settings only applies when in analog
mode as the input is always high impedance otherwise. Thus a generic
attribute (such as calibscale or hardware gain) shouldn't be used as it
will have no effect whatsoever in PWM-mode.
I'm thus back at my original proposal, albeit with a different name (I
think a lot of this discussion could have been avoided had I not
misnamed the parameter "gain"):
What: /sys/bus/iio/devices/iio:deviceX/r_select
Description:
Set the ALS internal pull-down resistor for analog input mode
(1..127), such that,
R_als = 200000 / r_select (ohm)
This setting is ignored in PWM-mode (input is always high
impedance in PWM-mode).
I don't think much is gained from using ohm as the unit: it just adds
complexity and the selected resistor setting will likely not match the
input value anyway. It's better that the chip integrators have full
control over which resistor setting is actually used so that it matches
external components.
This smacks of something that should never be exposed to users.
I'd hide it away in platform data.
Fair enough. I'll drop the sysfs param and submit a patch for mfd-next
which adds r_select to the platform data.
Thanks,
Johan
From: Jonathan Cameron <jic23@kernel.org> Date: 2012-05-19 08:04:18
On 05/18/2012 06:57 PM, Johan Hovold wrote:
On Fri, May 18, 2012 at 06:34:01PM +0100, Jonathan Cameron wrote:
quoted
On 05/18/2012 01:27 PM, Johan Hovold wrote:
[...]
quoted
quoted
I really think that this should remain a device specific attribute as I
originally suggested. It's an integration parameter that needs to be set
precisely depending on the actual hardware setup (which analog light
sensor and other external components).
Then it shouldn't be exposed to userspace. If there is reason to vary
it from userspace then it is a calibration parameter and should be
treated like the other ones we have, if not it should be done from
dt or platform data.
quoted
The lm3533 also supports two types of light sensors: pwm- and analog-
output ones. The resistor select settings only applies when in analog
mode as the input is always high impedance otherwise. Thus a generic
attribute (such as calibscale or hardware gain) shouldn't be used as it
will have no effect whatsoever in PWM-mode.
I'm thus back at my original proposal, albeit with a different name (I
think a lot of this discussion could have been avoided had I not
misnamed the parameter "gain"):
What: /sys/bus/iio/devices/iio:deviceX/r_select
Description:
Set the ALS internal pull-down resistor for analog input mode
(1..127), such that,
R_als = 200000 / r_select (ohm)
This setting is ignored in PWM-mode (input is always high
impedance in PWM-mode).
I don't think much is gained from using ohm as the unit: it just adds
complexity and the selected resistor setting will likely not match the
input value anyway. It's better that the chip integrators have full
control over which resistor setting is actually used so that it matches
external components.
This smacks of something that should never be exposed to users.
I'd hide it away in platform data.
Fair enough. I'll drop the sysfs param and submit a patch for mfd-next
which adds r_select to the platform data.
cool. I'll review the rest of the patch with the assumption you'll do this.
Jonathan