On Mon, 06 Jan 2025 17:23:01 -0500 Mikael Gonella-Bolduc via B4 Relay <devnull+mgonellabolduc.dimonoff.com@xxxxxxxxxx> wrote: > From: Mikael Gonella-Bolduc <mgonellabolduc@xxxxxxxxxxxx> > > Add device tree bindings for APDS9160 > Note: Using alternate email for maintainer > > Signed-off-by: Mikael Gonella-Bolduc <mgonellabolduc@xxxxxxxxxxxx> > --- > .../bindings/iio/light/brcm,apds9160.yaml | 86 ++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml b/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml > new file mode 100644 > index 0000000000000000000000000000000000000000..756d46c2edb171da840ee49a7339cb781fe84ad2 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml > @@ -0,0 +1,86 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/iio/light/brcm,apds9160.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Broadcom Combined Proximity & Ambient light sensor > + > +maintainers: > + - Mikael Gonella-Bolduc <m.gonella.bolduc@xxxxxxxxx> > + > +description: | > + Datasheet: https://docs.broadcom.com/docs/APDS-9160-003-DS > + > +properties: > + compatible: > + enum: > + - brcm,apds9160 > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + vdd-supply: true > + > + ps-cancellation-duration: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: | > + Proximity sensor cancellation pulse duration in half clock cycles. > + This parameter determines a cancellation pulse duration. > + The cancellation is applied in the integration phase to cancel out > + unwanted reflected light from very near objects such as tempered glass > + in front of the sensor. > + minimum: 0 > + maximum: 63 > + default: 0 > + > + ps-cancellation-current-coarse: I've lost track on what we've discussed previously but I'm curious as to whether we can end up with a cleaner binding for this. We may well see other identical controls in future, so nice to have something more 'generic'. I'm not suggesting we don't keep it vendor specific though as not sure it will generalize beyond different broadcomm parts. It is a multiple of nA, so can we just express the combination of this and ps-cancellation-current-fine as a single parameter, probably in pA The tricky bit being there seem to be holes, so the allowed list would be complex. Even if we can't do that can we express it as two nA values rather than indexes? > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: | > + Proximity sensor crosstalk cancellation current coarse value. > + This parameter adjust the current in steps of 60 nA up to 240 nA. > + This parameter is used in conjunction with the cancellation duration. > + minimum: 0 > + maximum: 4 > + default: 0 > + > + ps-cancellation-current-fine: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: | > + Proximity sensor crosstalk cancellation current fine value. > + This parameter adjust the current in steps of 2.4 nA up to 36 nA. > + This parameter is used in conjunction with the cancellation duration. > + minimum: 0 > + maximum: 15 > + default: 0 > + > +required: > + - compatible > + - reg > + - vdd-supply > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/irq.h> > + > + i2c { > + #address-cells = <1>; > + #size-cells = <0>; > + > + light-sensor@53 { > + compatible = "brcm,apds9160"; > + reg = <0x53>; > + vdd-supply = <&vdd_reg>; > + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; > + interrupt-parent = <&pinctrl>; > + ps-cancellation-duration = <10>; > + ps-cancellation-current-coarse = <2>; > + ps-cancellation-current-fine = <10>; > + }; > + }; > +... >
