[PATCH v3] iio: bmp280: fix compensation of humidity
Limit the output of humidity compensation to the range between 0 and 100 percent. Depending on the calibration parameters of the individual sensor it happens, that a humidity above 100 percent or below 0 percent is calculated, which don't make sense in terms of relative humidity. Add a clamp to the compensation formula as described in the datasheet of the sensor in chapter 4.2.3. Although this clamp is documented, it was never in the driver of the kernel. It depends on the circumstances (calibration parameters, temperature, humidity) if one can see a value above 100 percent without the clamp. The writer of this patch was working with this type of sensor without noting this error. So it seems to be a rare event when this bug occures. Signed-off-by: Andreas Klinger --- Change to v2: Thanks to the review of Jonathan a more descriptive commit message is added. Change to v1: Thanks to Tomasz for suggesting the easier to use function clamp_val() which is now used. drivers/iio/pressure/bmp280-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c index 29c209cc1108..297ee2205bf6 100644 --- a/drivers/iio/pressure/bmp280-core.c +++ b/drivers/iio/pressure/bmp280-core.c @@ -271,6 +271,8 @@ static u32 bmp280_compensate_humidity(struct bmp280_data *data, + (s32)2097152) * calib->H2 + 8192) >> 14); var -= var >> 15) * (var >> 15)) >> 7) * (s32)calib->H1) >> 4; + var = clamp_val(var, 0, 419430400); + return var >> 12; }; -- 2.20.1
[PATCH v2] iio: bmp280: fix compensation of humidity
Output of humidity compensation is limited to the range between 0 and 100 percent. Add this to the compensation formula as described in the datasheet chapter 4.2.3. Change to v1: Thanks to Tomasz for suggesting the easier to use function clamp_val() which is now used. Signed-off-by: Andreas Klinger --- drivers/iio/pressure/bmp280-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c index 29c209cc1108..297ee2205bf6 100644 --- a/drivers/iio/pressure/bmp280-core.c +++ b/drivers/iio/pressure/bmp280-core.c @@ -271,6 +271,8 @@ static u32 bmp280_compensate_humidity(struct bmp280_data *data, + (s32)2097152) * calib->H2 + 8192) >> 14); var -= var >> 15) * (var >> 15)) >> 7) * (s32)calib->H1) >> 4; + var = clamp_val(var, 0, 419430400); + return var >> 12; }; -- 2.20.1
[PATCH v3] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
transform existing documentation of maxbotix,mb1232 ultrasonic ranger
from text documentation format into yaml.
Changes in v3:
- add a i2c node around device node to set up #address-cells and
#size-cells for omitting error during make dt_binding_check
Changes in v2:
- removed description of reg property
- added a line:
additionalProperties: false
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
.../bindings/iio/proximity/maxbotix,mb1232.yaml| 60 ++
2 files changed, 60 insertions(+), 29 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
deleted file mode 100644
index dd1058fbe9c3..
--- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
- mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
- for ranging
-
-Required properties:
- - compatible: "maxbotix,mb1202",
- "maxbotix,mb1212",
- "maxbotix,mb1222",
- "maxbotix,mb1232",
- "maxbotix,mb1242",
- "maxbotix,mb7040" or
- "maxbotix,mb7137"
-
- - reg:i2c address of the device, see also i2c/i2c.txt
-
-Optional properties:
- - interrupts: Interrupt used to announce the preceding reading
- request has finished and that data is available.
- If no interrupt is specified the device driver
- falls back to wait a fixed amount of time until
- data can be retrieved.
-
-Example:
-proximity@70 {
- compatible = "maxbotix,mb1232";
- reg = <0x70>;
- interrupt-parent = <>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
new file mode 100644
index ..3eac248f291d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
+ mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
+ for ranging
+
+ Specifications about the devices can be found at:
+ https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+
+properties:
+ compatible:
+enum:
+ - maxbotix,mb1202
+ - maxbotix,mb1212
+ - maxbotix,mb1222
+ - maxbotix,mb1232
+ - maxbotix,mb1242
+ - maxbotix,mb7040
+ - maxbotix,mb7137
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description:
+ Interrupt used to announce the preceding reading request has finished
+ and that data is available. If no interrupt is specified the device
+ driver falls back to wait a fixed amount of time until data can be
+ retrieved.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ proximity@70 {
+compatible = "maxbotix,mb1232";
+reg = <0x70>;
+interrupt-parent = <>;
+interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
--
2.11.0
Re: [PATCH v2] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
Hi Rob,
i don't get this error. Is there anything i'm doing wrong here?
ak@arbad:/project/opt-sw/linux-robh$ make O=../build-wega-robh/ dt_binding_check
make[1]: Verzeichnis „/project/opt-sw/build-wega-robh“ wird betreten
SCHEMA Documentation/devicetree/bindings/processed-schema.yaml
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/net/adi,adin.yaml:
ignoring, error in schema 'adi,fifo-depth-bits'
warning: no schema found in file:
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/net/adi,adin.yaml
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml:
ignoring, error in schema '0'
warning: no schema found in file:
/project/opt-sw/linux-robh/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
CHKDT Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
CHKDT [...]
But anyway i've fixed and send it out again.
Andreas
Rob Herring schrieb am Mo, 07. Okt 07:42:
> On Sun, Oct 6, 2019 at 9:27 AM Andreas Klinger wrote:
> >
> > transform existing documentation of maxbotix,mb1232 ultrasonic ranger
> > from text documentation format into yaml.
> >
> > Changes in v2:
> > - removed description of reg property
> > - added a line:
> > additionalProperties: false
> >
> > Signed-off-by: Andreas Klinger
> > ---
> > .../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
> > .../bindings/iio/proximity/maxbotix,mb1232.yaml| 56
> > ++
> > 2 files changed, 56 insertions(+), 29 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > create mode 100644
> > Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > deleted file mode 100644
> > index dd1058fbe9c3..
> > --- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
> > +++ /dev/null
> > @@ -1,29 +0,0 @@
> > -* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
> > - mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
> > - for ranging
> > -
> > -Required properties:
> > - - compatible: "maxbotix,mb1202",
> > - "maxbotix,mb1212",
> > - "maxbotix,mb1222",
> > - "maxbotix,mb1232",
> > - "maxbotix,mb1242",
> > - "maxbotix,mb7040" or
> > - "maxbotix,mb7137"
> > -
> > - - reg:i2c address of the device, see also
> > i2c/i2c.txt
> > -
> > -Optional properties:
> > - - interrupts: Interrupt used to announce the preceding reading
> > - request has finished and that data is available.
> > - If no interrupt is specified the device driver
> > - falls back to wait a fixed amount of time until
> > - data can be retrieved.
> > -
> > -Example:
> > -proximity@70 {
> > - compatible = "maxbotix,mb1232";
> > - reg = <0x70>;
> > - interrupt-parent = <>;
> > - interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> > -};
> > diff --git
> > a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> > b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> > new file mode 100644
> > index ..e2fb1f6d4dbe
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
> > +
> > +maintainers:
> > + - Andreas Klinger
> > +
> > +description: |
> > + MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
> > + mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
> > + for ranging
> > +
> > + Specifications about the devices can be found at:
> > + https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
> > +
> > +properties:
> &g
[PATCH v2] iio: srf04: fix wrong limitation in distance measuring
The measured time value in the driver is limited to the maximum distance
which can be read by the sensor. This limitation was wrong and is fixed
by this patch.
It also takes into account that we are supporting a variety of sensors
today and that the recently added sensors have a higher maximum
distance range.
Changes in v2:
- Added a Tested-by
Suggested-by: Zbyněk Kocur
Tested-by: Zbyněk Kocur
Signed-off-by: Andreas Klinger
---
drivers/iio/proximity/srf04.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c
index 8b50d56b0a03..01eb8cc63076 100644
--- a/drivers/iio/proximity/srf04.c
+++ b/drivers/iio/proximity/srf04.c
@@ -110,7 +110,7 @@ static int srf04_read(struct srf04_data *data)
udelay(data->cfg->trigger_pulse_us);
gpiod_set_value(data->gpiod_trig, 0);
- /* it cannot take more than 20 ms */
+ /* it should not take more than 20 ms until echo is rising */
ret = wait_for_completion_killable_timeout(>rising, HZ/50);
if (ret < 0) {
mutex_unlock(>lock);
@@ -120,7 +120,8 @@ static int srf04_read(struct srf04_data *data)
return -ETIMEDOUT;
}
- ret = wait_for_completion_killable_timeout(>falling, HZ/50);
+ /* it cannot take more than 50 ms until echo is falling */
+ ret = wait_for_completion_killable_timeout(>falling, HZ/20);
if (ret < 0) {
mutex_unlock(>lock);
return ret;
@@ -135,19 +136,19 @@ static int srf04_read(struct srf04_data *data)
dt_ns = ktime_to_ns(ktime_dt);
/*
-* measuring more than 3 meters is beyond the capabilities of
-* the sensor
+* measuring more than 6,45 meters is beyond the capabilities of
+* the supported sensors
* ==> filter out invalid results for not measuring echos of
* another us sensor
*
* formula:
-* distance 3 m
-* time = -- = - = 9404389 ns
-* speed 319 m/s
+* distance 6,45 * 2 m
+* time = -- = = 40438871 ns
+* speed 319 m/s
*
* using a minimum speed at -20 °C of 319 m/s
*/
- if (dt_ns > 9404389)
+ if (dt_ns > 40438871)
return -EIO;
time_ns = dt_ns;
@@ -159,20 +160,20 @@ static int srf04_read(struct srf04_data *data)
* with Temp in °C
* and speed in m/s
*
-* use 343 m/s as ultrasonic speed at 20 °C here in absence of the
+* use 343,5 m/s as ultrasonic speed at 20 °C here in absence of the
* temperature
*
* therefore:
-* time 343
-* distance = -- * -
-* 10^6 2
+* time 343,5 time * 106
+* distance = -- * --- =
+* 10^6 2 617176
* with time in ns
* and distance in mm (one way)
*
-* because we limit to 3 meters the multiplication with 343 just
+* because we limit to 6,45 meters the multiplication with 106 just
* fits into 32 bit
*/
- distance_mm = time_ns * 343 / 200;
+ distance_mm = time_ns * 106 / 617176;
return distance_mm;
}
--
2.11.0
[PATCH v2] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
transform existing documentation of maxbotix,mb1232 ultrasonic ranger
from text documentation format into yaml.
Changes in v2:
- removed description of reg property
- added a line:
additionalProperties: false
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
.../bindings/iio/proximity/maxbotix,mb1232.yaml| 56 ++
2 files changed, 56 insertions(+), 29 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
deleted file mode 100644
index dd1058fbe9c3..
--- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
- mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
- for ranging
-
-Required properties:
- - compatible: "maxbotix,mb1202",
- "maxbotix,mb1212",
- "maxbotix,mb1222",
- "maxbotix,mb1232",
- "maxbotix,mb1242",
- "maxbotix,mb7040" or
- "maxbotix,mb7137"
-
- - reg:i2c address of the device, see also i2c/i2c.txt
-
-Optional properties:
- - interrupts: Interrupt used to announce the preceding reading
- request has finished and that data is available.
- If no interrupt is specified the device driver
- falls back to wait a fixed amount of time until
- data can be retrieved.
-
-Example:
-proximity@70 {
- compatible = "maxbotix,mb1232";
- reg = <0x70>;
- interrupt-parent = <>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
new file mode 100644
index ..e2fb1f6d4dbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
+ mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
+ for ranging
+
+ Specifications about the devices can be found at:
+ https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+
+properties:
+ compatible:
+enum:
+ - maxbotix,mb1202
+ - maxbotix,mb1212
+ - maxbotix,mb1222
+ - maxbotix,mb1232
+ - maxbotix,mb1242
+ - maxbotix,mb7040
+ - maxbotix,mb7137
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description:
+ Interrupt used to announce the preceding reading request has finished
+ and that data is available. If no interrupt is specified the device
+ driver falls back to wait a fixed amount of time until data can be
+ retrieved.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+proximity@70 {
+ compatible = "maxbotix,mb1232";
+ reg = <0x70>;
+ interrupt-parent = <>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.11.0
[PATCH] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
transform existing documentation of maxbotix,mb1232 ultrasonic ranger
from text documentation format into yaml.
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
.../bindings/iio/proximity/maxbotix,mb1232.yaml| 56 ++
2 files changed, 56 insertions(+), 29 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
deleted file mode 100644
index dd1058fbe9c3..
--- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
- mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
- for ranging
-
-Required properties:
- - compatible: "maxbotix,mb1202",
- "maxbotix,mb1212",
- "maxbotix,mb1222",
- "maxbotix,mb1232",
- "maxbotix,mb1242",
- "maxbotix,mb7040" or
- "maxbotix,mb7137"
-
- - reg:i2c address of the device, see also i2c/i2c.txt
-
-Optional properties:
- - interrupts: Interrupt used to announce the preceding reading
- request has finished and that data is available.
- If no interrupt is specified the device driver
- falls back to wait a fixed amount of time until
- data can be retrieved.
-
-Example:
-proximity@70 {
- compatible = "maxbotix,mb1232";
- reg = <0x70>;
- interrupt-parent = <>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
new file mode 100644
index ..8301a1ad2a47
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
+ mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
+ for ranging
+
+ Specifications about the devices can be found at:
+ https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+
+properties:
+ compatible:
+enum:
+ - maxbotix,mb1202
+ - maxbotix,mb1212
+ - maxbotix,mb1222
+ - maxbotix,mb1232
+ - maxbotix,mb1242
+ - maxbotix,mb7040
+ - maxbotix,mb7137
+
+ reg:
+description:
+ i2c address of the device, see also i2c/i2c.txt
+maxItems: 1
+
+ interrupts:
+description:
+ Interrupt used to announce the preceding reading request has finished
+ and that data is available. If no interrupt is specified the device
+ driver falls back to wait a fixed amount of time until data can be
+ retrieved.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+proximity@70 {
+ compatible = "maxbotix,mb1232";
+ reg = <0x70>;
+ interrupt-parent = <>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.11.0
Re: [PATCH] iio: srf04: fix wrong limitation in distance measuring
Hi Zbyněk, thanks a lot for testing and sharing your results with us. > I do not know how to do this in the development of drivers, whether it makes > sense to put a filter directly into the driver or at least pull the maximum > distance parameter as a variable? In this case one should read several times, remove spikes and calculate the average. This sounds to me as task for the userspace not for the driver. Regards, Andreas Zbyněk Kocur schrieb am Mo, 09. Sep 08:53: > Hi Andreas, > > I'm so sorry for the delay. I was working on another project now, and I > wasn't entirely devoted to this. I looked at it at the weekend and the > modified code is working. I have only tested OpenWRT in build - > r10204-38b22b1, kernel 4.14.125. I do not expect complications on other > platforms. > > I tried it on several sensors. I was primarily interested in JSN-SR04T > (https://www.makerguides.com/jsn-sr04t-arduino-tutorial/). I have also > verified other designs > (https://randomnerdtutorials.com/complete-guide-for-ultrasonic-sensor-hc-sr04/). > > It generally works. Relatively accurate for the area up to 2.5 m. However, if > the distance is longer, it starts to fizz, depending on the sensor design. It > is a property of used HW and its construction. > > I do not know how to do this in the development of drivers, whether it makes > sense to put a filter directly into the driver or at least pull the maximum > distance parameter as a variable? > > Anyway, the change made works. > > Zbynek > --- > email: zbynek.ko...@fel.cvut.cz > phone: +420 224 354 054 > web: http://www.fel.cvut.cz > Department of Telecommunications Engineering > Faculty of Electrical Engineering > > > On 7 Sep 2019, at 11:46, Andreas Klinger wrote: > > > > Hi Zbynek, > > > > do you have any feedback for us? > > > > Thank you, > > > > Andreas > > > > > > Zbyněk Kocur schrieb am Mi, 26. Jun 21:50: > >> Thank you, i will write a feedback after testing. > >> > >> > >> Zbynek > >> --- > >> email: zbynek.ko...@fel.cvut.cz > >> phone: +420 224 354 054 > >> web: http://www.fel.cvut.cz > >> Department of Telecommunications Engineering > >> Faculty of Electrical Engineering > >> > >>> On 26 Jun 2019, at 21:49, Jonathan Cameron wrote: > >>> > >>> No rush, it's a clear fix anyway so we can queue this up > >>> in the rc phase of the next kernel cycle! > >> > > > > -- > > Andreas Klinger > > Grabenreith 27 > > 84508 Burgkirchen > > +49 8623 919966 > > a...@it-klinger.de > > www.it-klinger.de > > www.grabenreith.de > -- Andreas Klinger Grabenreith 27 84508 Burgkirchen +49 8623 919966 a...@it-klinger.de www.it-klinger.de www.grabenreith.de
[PATCH v2 3/3] iio: adc: hx711: remove unnecessary returns
Optimize use of return in hx711_set_gain_for_channel().
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index c8686558429b..20c249f502c0 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -213,7 +213,7 @@ static int hx711_reset(struct hx711_data *hx711_data)
static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
{
- int ret;
+ int ret = 0;
if (chan == 0) {
if (hx711_data->gain_set == 32) {
@@ -224,8 +224,6 @@ static int hx711_set_gain_for_channel(struct hx711_data
*hx711_data, int chan)
return ret;
ret = hx711_wait_for_ready(hx711_data);
- if (ret)
- return ret;
}
} else {
if (hx711_data->gain_set != 32) {
@@ -236,12 +234,10 @@ static int hx711_set_gain_for_channel(struct hx711_data
*hx711_data, int chan)
return ret;
ret = hx711_wait_for_ready(hx711_data);
- if (ret)
- return ret;
}
}
- return 0;
+ return ret;
}
static int hx711_reset_read(struct hx711_data *hx711_data, int chan)
--
2.11.0
[PATCH v2 2/3] iio: adc: hx711: optimize performance in read cycle
Set gain in hx711_reset() to its default value after a reset cycle. This
omits one precautionary read cycle, because the read is performed in
hx711_set_gain_for_channel() anyway if gain has changed.
Check for DOUT low and if its high wait some time if it goes down
instead of doing a blind reset cycle when DOUT is not down.
This is a performance optimization which allows to query the sensor with
a higher frequency.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 0678964dbd21..c8686558429b 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -23,6 +23,7 @@
/* gain to pulse and scale conversion */
#define HX711_GAIN_MAX 3
+#define HX711_RESET_GAIN 128
struct hx711_gain_to_scale {
int gain;
@@ -100,7 +101,6 @@ struct hx711_data {
static int hx711_cycle(struct hx711_data *hx711_data)
{
- int val;
unsigned long flags;
/*
@@ -186,8 +186,7 @@ static int hx711_wait_for_ready(struct hx711_data
*hx711_data)
static int hx711_reset(struct hx711_data *hx711_data)
{
- int ret;
- int val = gpiod_get_value(hx711_data->gpiod_dout);
+ int val = hx711_wait_for_ready(hx711_data);
if (val) {
/*
@@ -203,22 +202,10 @@ static int hx711_reset(struct hx711_data *hx711_data)
msleep(10);
gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
- ret = hx711_wait_for_ready(hx711_data);
- if (ret)
- return ret;
- /*
-* after a reset the gain is 128 so we do a dummy read
-* to set the gain for the next read
-*/
- ret = hx711_read(hx711_data);
- if (ret < 0)
- return ret;
-
- /*
-* after a dummy read we need to wait vor readiness
-* for not mixing gain pulses with the clock
-*/
val = hx711_wait_for_ready(hx711_data);
+
+ /* after a reset the gain is 128 */
+ hx711_data->gain_set = HX711_RESET_GAIN;
}
return val;
--
2.11.0
[PATCH v2 1/3] iio: adc: hx711: fix bug in sampling of data
Fix bug in sampling function hx711_cycle() when interrupt occures while
PD_SCK is high. If PD_SCK is high for at least 60 us power down mode of
the sensor is entered which in turn leads to a wrong measurement.
Switch off interrupts during a PD_SCK high period and move query of DOUT
to the latest point of time which is at the end of PD_SCK low period.
This bug exists in the driver since it's initial addition. The more
interrupts on the system the higher is the probability that it happens.
Fixes: c3b2fdd0ea7e ("iio: adc: hx711: Add IIO driver for AVIA HX711")
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 88c7fe15003b..0678964dbd21 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -101,13 +101,14 @@ struct hx711_data {
static int hx711_cycle(struct hx711_data *hx711_data)
{
int val;
+ unsigned long flags;
/*
* if preempted for more then 60us while PD_SCK is high:
* hx711 is going in reset
* ==> measuring is false
*/
- preempt_disable();
+ local_irq_save(flags);
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
/*
@@ -117,7 +118,6 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
ndelay(hx711_data->data_ready_delay_ns);
- val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
* because the oscilloscope showed in a test scenario
@@ -125,7 +125,7 @@ static int hx711_cycle(struct hx711_data *hx711_data)
* and 0.56 us for PD_SCK low on TI Sitara with 800 MHz
*/
gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
- preempt_enable();
+ local_irq_restore(flags);
/*
* make it a square wave for addressing cases with capacitance on
@@ -133,7 +133,8 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
ndelay(hx711_data->data_ready_delay_ns);
- return val;
+ /* sample as late as possible */
+ return gpiod_get_value(hx711_data->gpiod_dout);
}
static int hx711_read(struct hx711_data *hx711_data)
--
2.11.0
[PATCH v2 0/3] iio: adc: hx711: fix and optimize sampling of data
This patch set fixes problems in the sampling of data and optimizes driver performance. It was partly suggested privately to me and i got the allowance to use it further. But because the person is not answering my emails related to the question of mentioning the name for a long time i submit it without a Suggested-By or something similar. Changes in v2: - Clarify which part of the patch queue fixes a certain bug and which one is an optimization of the driver without an underlying bug. Andreas Klinger (3): iio: adc: hx711: fix bug in sampling of data iio: adc: hx711: optimize performance in read cycle iio: adc: hx711: remove unnecessary returns drivers/iio/adc/hx711.c | 40 1 file changed, 12 insertions(+), 28 deletions(-) -- 2.11.0
Re: [PATCH 1/3] iio: adc: hx711: optimize sampling of data
Hi Jonathan,
only patch 1 fixes a bug which is occurring on systems. In my test it happened
every one of about 10 - 15.000 measurements. But this depends on the interrupt
load of the system. With a high interrupt load there might be much more wrong
measurements.
Patch 2 is a performance optimization which prevents unneded reads. There is no
bug which is fixed by it.
I'll send out the patch set with more detailed commit messages.
Thanks,
Andreas
Jonathan Cameron schrieb am So, 08. Sep 14:49:
> On Sat, 7 Sep 2019 12:18:00 +0200
> Andreas Klinger wrote:
>
> > Fix bug in sampling function hx711_cycle() when interrupt occures while
> > PD_SCK is high. If PD_SCK is high for at least 60 us power down mode of
> > the sensor is entered which in turn leads to a wrong measurement.
> >
> > Move query of DOUT at the latest point of time which is at the end of
> > PD_SCK low period.
> >
> > Signed-off-by: Andreas Klinger
>
> Hi Andreas,
>
> One thing I'm not clear on from these is how much a 'fix' they
> are. That just effects whether we mark them for stable / push them
> out as quickly as possible or not. So has this been seen in
> normal operation?
>
> + please add fixes tags to the two fixes.
>
> For patch 3, it's in the very low importance category so it may
> well get forgotten if these two go through the fixes tree
> (up to you to remind me!)
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/hx711.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> > index 88c7fe15003b..0678964dbd21 100644
> > --- a/drivers/iio/adc/hx711.c
> > +++ b/drivers/iio/adc/hx711.c
> > @@ -101,13 +101,14 @@ struct hx711_data {
> > static int hx711_cycle(struct hx711_data *hx711_data)
> > {
> > int val;
> > + unsigned long flags;
> >
> > /*
> > * if preempted for more then 60us while PD_SCK is high:
> > * hx711 is going in reset
> > * ==> measuring is false
> > */
> > - preempt_disable();
> > + local_irq_save(flags);
> > gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
> >
> > /*
> > @@ -117,7 +118,6 @@ static int hx711_cycle(struct hx711_data *hx711_data)
> > */
> > ndelay(hx711_data->data_ready_delay_ns);
> >
> > - val = gpiod_get_value(hx711_data->gpiod_dout);
> > /*
> > * here we are not waiting for 0.2 us as suggested by the datasheet,
> > * because the oscilloscope showed in a test scenario
> > @@ -125,7 +125,7 @@ static int hx711_cycle(struct hx711_data *hx711_data)
> > * and 0.56 us for PD_SCK low on TI Sitara with 800 MHz
> > */
> > gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
> > - preempt_enable();
> > + local_irq_restore(flags);
> >
> > /*
> > * make it a square wave for addressing cases with capacitance on
> > @@ -133,7 +133,8 @@ static int hx711_cycle(struct hx711_data *hx711_data)
> > */
> > ndelay(hx711_data->data_ready_delay_ns);
> >
> > - return val;
> > + /* sample as late as possible */
> > + return gpiod_get_value(hx711_data->gpiod_dout);
> > }
> >
> > static int hx711_read(struct hx711_data *hx711_data)
>
--
Andreas Klinger
Grabenreith 27
84508 Burgkirchen
+49 8623 919966
a...@it-klinger.de
www.it-klinger.de
www.grabenreith.de
[PATCH 3/3] iio: adc: hx711: remove unnecessary returns
Optimize use of return in hx711_set_gain_for_channel().
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index c8686558429b..20c249f502c0 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -213,7 +213,7 @@ static int hx711_reset(struct hx711_data *hx711_data)
static int hx711_set_gain_for_channel(struct hx711_data *hx711_data, int chan)
{
- int ret;
+ int ret = 0;
if (chan == 0) {
if (hx711_data->gain_set == 32) {
@@ -224,8 +224,6 @@ static int hx711_set_gain_for_channel(struct hx711_data
*hx711_data, int chan)
return ret;
ret = hx711_wait_for_ready(hx711_data);
- if (ret)
- return ret;
}
} else {
if (hx711_data->gain_set != 32) {
@@ -236,12 +234,10 @@ static int hx711_set_gain_for_channel(struct hx711_data
*hx711_data, int chan)
return ret;
ret = hx711_wait_for_ready(hx711_data);
- if (ret)
- return ret;
}
}
- return 0;
+ return ret;
}
static int hx711_reset_read(struct hx711_data *hx711_data, int chan)
--
2.13.3
[PATCH 2/3] iio: adc: hx711: remove unnecessary read cycle
Set gain in hx711_reset() to its default value after a reset cycle. This
omits one precautionary read cycle, because the read is performed in
hx711_set_gain_for_channel() anyway if gain has changed.
Check for DOUT low and wait some time if it goes down instead of doing a
blind reset cycle when DOUT is not down.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 0678964dbd21..c8686558429b 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -23,6 +23,7 @@
/* gain to pulse and scale conversion */
#define HX711_GAIN_MAX 3
+#define HX711_RESET_GAIN 128
struct hx711_gain_to_scale {
int gain;
@@ -100,7 +101,6 @@ struct hx711_data {
static int hx711_cycle(struct hx711_data *hx711_data)
{
- int val;
unsigned long flags;
/*
@@ -186,8 +186,7 @@ static int hx711_wait_for_ready(struct hx711_data
*hx711_data)
static int hx711_reset(struct hx711_data *hx711_data)
{
- int ret;
- int val = gpiod_get_value(hx711_data->gpiod_dout);
+ int val = hx711_wait_for_ready(hx711_data);
if (val) {
/*
@@ -203,22 +202,10 @@ static int hx711_reset(struct hx711_data *hx711_data)
msleep(10);
gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
- ret = hx711_wait_for_ready(hx711_data);
- if (ret)
- return ret;
- /*
-* after a reset the gain is 128 so we do a dummy read
-* to set the gain for the next read
-*/
- ret = hx711_read(hx711_data);
- if (ret < 0)
- return ret;
-
- /*
-* after a dummy read we need to wait vor readiness
-* for not mixing gain pulses with the clock
-*/
val = hx711_wait_for_ready(hx711_data);
+
+ /* after a reset the gain is 128 */
+ hx711_data->gain_set = HX711_RESET_GAIN;
}
return val;
--
2.13.3
[PATCH 1/3] iio: adc: hx711: optimize sampling of data
Fix bug in sampling function hx711_cycle() when interrupt occures while
PD_SCK is high. If PD_SCK is high for at least 60 us power down mode of
the sensor is entered which in turn leads to a wrong measurement.
Move query of DOUT at the latest point of time which is at the end of
PD_SCK low period.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 88c7fe15003b..0678964dbd21 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -101,13 +101,14 @@ struct hx711_data {
static int hx711_cycle(struct hx711_data *hx711_data)
{
int val;
+ unsigned long flags;
/*
* if preempted for more then 60us while PD_SCK is high:
* hx711 is going in reset
* ==> measuring is false
*/
- preempt_disable();
+ local_irq_save(flags);
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
/*
@@ -117,7 +118,6 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
ndelay(hx711_data->data_ready_delay_ns);
- val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
* because the oscilloscope showed in a test scenario
@@ -125,7 +125,7 @@ static int hx711_cycle(struct hx711_data *hx711_data)
* and 0.56 us for PD_SCK low on TI Sitara with 800 MHz
*/
gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
- preempt_enable();
+ local_irq_restore(flags);
/*
* make it a square wave for addressing cases with capacitance on
@@ -133,7 +133,8 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
ndelay(hx711_data->data_ready_delay_ns);
- return val;
+ /* sample as late as possible */
+ return gpiod_get_value(hx711_data->gpiod_dout);
}
static int hx711_read(struct hx711_data *hx711_data)
--
2.13.3
[PATCH 0/3] iio: adc: hx711: fix and optimize sampling of data
This patch set fixes problems in the sampling of data and optimizes driver performance. It was partly suggested privately to me and i got the allowance to use it further. But because the person is not answering my emails related to the question of mentioning the name for a long time i submit it without a Suggested-By or something similar. Andreas Klinger (3): iio: adc: hx711: optimize sampling of data iio: adc: hx711: remove unnecessary read cycle iio: adc: hx711: remove unnecessary returns drivers/iio/adc/hx711.c | 40 1 file changed, 12 insertions(+), 28 deletions(-) -- 2.13.3
Re: [PATCH] iio: srf04: fix wrong limitation in distance measuring
Hi Zbynek, do you have any feedback for us? Thank you, Andreas Zbyněk Kocur schrieb am Mi, 26. Jun 21:50: > Thank you, i will write a feedback after testing. > > > Zbynek > --- > email: zbynek.ko...@fel.cvut.cz > phone: +420 224 354 054 > web: http://www.fel.cvut.cz > Department of Telecommunications Engineering > Faculty of Electrical Engineering > > > On 26 Jun 2019, at 21:49, Jonathan Cameron wrote: > > > > No rush, it's a clear fix anyway so we can queue this up > > in the rc phase of the next kernel cycle! > -- Andreas Klinger Grabenreith 27 84508 Burgkirchen +49 8623 919966 a...@it-klinger.de www.it-klinger.de www.grabenreith.de
[PATCH] ARM: dts: am335x-wega.dtsi: fix wrong card detect pin level
mmc cards on mmc1 are not detected because of wrong card detect (cd) level.
Change cd from GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW.
This is necessary because of commit e63201f19438 ("mmc: omap_hsmmc:
Delete platform data GPIO CD and WP")
Signed-off-by: Andreas Klinger
---
arch/arm/boot/dts/am335x-wega.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi
b/arch/arm/boot/dts/am335x-wega.dtsi
index b7d28a20341f..84581fed3d06 100644
--- a/arch/arm/boot/dts/am335x-wega.dtsi
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -157,7 +157,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
- cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+ cd-gpios = < 6 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.11.0
--
[PATCH] iio: srf04: fix wrong limitation in distance measuring
The measured time value in the driver is limited to the maximum distance
which can be read by the sensor. This limitation was wrong and is fixed
by this patch.
It also takes into account that we are supporting a variety of sensors
today and that the recently added sensors have a higher maximum
distance range.
Suggested-by: Zbyněk Kocur
Signed-off-by: Andreas Klinger
---
drivers/iio/proximity/srf04.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c
index 8b50d56b0a03..01eb8cc63076 100644
--- a/drivers/iio/proximity/srf04.c
+++ b/drivers/iio/proximity/srf04.c
@@ -110,7 +110,7 @@ static int srf04_read(struct srf04_data *data)
udelay(data->cfg->trigger_pulse_us);
gpiod_set_value(data->gpiod_trig, 0);
- /* it cannot take more than 20 ms */
+ /* it should not take more than 20 ms until echo is rising */
ret = wait_for_completion_killable_timeout(>rising, HZ/50);
if (ret < 0) {
mutex_unlock(>lock);
@@ -120,7 +120,8 @@ static int srf04_read(struct srf04_data *data)
return -ETIMEDOUT;
}
- ret = wait_for_completion_killable_timeout(>falling, HZ/50);
+ /* it cannot take more than 50 ms until echo is falling */
+ ret = wait_for_completion_killable_timeout(>falling, HZ/20);
if (ret < 0) {
mutex_unlock(>lock);
return ret;
@@ -135,19 +136,19 @@ static int srf04_read(struct srf04_data *data)
dt_ns = ktime_to_ns(ktime_dt);
/*
-* measuring more than 3 meters is beyond the capabilities of
-* the sensor
+* measuring more than 6,45 meters is beyond the capabilities of
+* the supported sensors
* ==> filter out invalid results for not measuring echos of
* another us sensor
*
* formula:
-* distance 3 m
-* time = -- = - = 9404389 ns
-* speed 319 m/s
+* distance 6,45 * 2 m
+* time = -- = = 40438871 ns
+* speed 319 m/s
*
* using a minimum speed at -20 °C of 319 m/s
*/
- if (dt_ns > 9404389)
+ if (dt_ns > 40438871)
return -EIO;
time_ns = dt_ns;
@@ -159,20 +160,20 @@ static int srf04_read(struct srf04_data *data)
* with Temp in °C
* and speed in m/s
*
-* use 343 m/s as ultrasonic speed at 20 °C here in absence of the
+* use 343,5 m/s as ultrasonic speed at 20 °C here in absence of the
* temperature
*
* therefore:
-* time 343
-* distance = -- * -
-* 10^6 2
+* time 343,5 time * 106
+* distance = -- * --- =
+* 10^6 2 617176
* with time in ns
* and distance in mm (one way)
*
-* because we limit to 3 meters the multiplication with 343 just
+* because we limit to 6,45 meters the multiplication with 106 just
* fits into 32 bit
*/
- distance_mm = time_ns * 343 / 200;
+ distance_mm = time_ns * 106 / 617176;
return distance_mm;
}
--
2.11.0
[PATCH 3/3] Kconfig: change configuration of srf04 ultrasonic iio sensor
reword configuration option for SRF04 list supported types in help text Signed-off-by: Andreas Klinger --- drivers/iio/proximity/Kconfig | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig index 12a3d3d40a91..e9f254ae3892 100644 --- a/drivers/iio/proximity/Kconfig +++ b/drivers/iio/proximity/Kconfig @@ -68,12 +68,19 @@ config RFD77402 module will be called rfd77402. config SRF04 - tristate "Devantech SRF04 ultrasonic ranger sensor" + tristate "GPIO bitbanged ultrasonic ranger sensor (SRF04, MB1000)" depends on GPIOLIB help - Say Y here to build a driver for Devantech SRF04 ultrasonic + Say Y here to build a driver for GPIO bitbanged ultrasonic ranger sensor. This driver can be used to measure the distance of objects. It is using two GPIOs. + Actually Supported types are: + - Devantech SRF04 + - Maxbotix mb1000 + - Maxbotix mb1010 + - Maxbotix mb1020 + - Maxbotix mb1030 + - Maxbotix mb1040 To compile this driver as a module, choose M here: the module will be called srf04. -- 2.11.0
[PATCH 2/3] devantech-srf04.yaml: add Maxbotix ultrasonic iio proximity sensors
add compatibles for Maxbotix ultrasonic iio sensor types to yaml documentation Signed-off-by: Andreas Klinger --- .../bindings/iio/proximity/devantech-srf04.yaml| 25 ++ 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml index e7aab785c97d..4e80ea7c1475 100644 --- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/proximity/devantech-srf04.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Devantech SRF04 ultrasonic range finder +title: Devantech SRF04 and Maxbotix mb1000 ultrasonic range finder maintainers: - Andreas Klinger @@ -16,19 +16,28 @@ description: | - echo-gpio is held high by the sensor after sending ultrasonic burst until it is received once again - Specifications about the driver can be found at: + Specifications about the devices can be found at: http://www.robot-electronics.co.uk/htm/srf04tech.htm + http://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf + properties: compatible: -items: - - const: devantech,srf04 +enum: + - devantech,srf04 + - maxbotix,mb1000 + - maxbotix,mb1010 + - maxbotix,mb1020 + - maxbotix,mb1030 + - maxbotix,mb1040 trig-gpios: description: - Definition of the GPIO for the triggering (output) This GPIO is set - for about 10 us by the driver to tell the device it should initiate - the measurement cycle. + Definition of the GPIO for the triggering (output) + This GPIO is set for about 10 us by the driver to tell the device it + should initiate the measurement cycle. + See Documentation/devicetree/bindings/gpio/gpio.txt for information + on how to specify a consumer gpio. maxItems: 1 echo-gpios: @@ -40,8 +49,6 @@ properties: trip. It needs to be an GPIO which is able to deliver an interrupt because the time between two interrupts is measured in the driver. - See Documentation/devicetree/bindings/gpio/gpio.txt for information - on how to specify a consumer gpio. maxItems: 1 required: -- 2.11.0
[PATCH 1/3] srf04.c: add maxbotix ultrasonic sensors
add Maxbotix LV ultrasonic sensor types mb1000, mb1010, mb1020, mb1030
and mb1040
add a configuration struct with the different trigger pulse lengths
Signed-off-by: Andreas Klinger
---
drivers/iio/proximity/srf04.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c
index 09c7b9c095b0..1bad4018d1aa 100644
--- a/drivers/iio/proximity/srf04.c
+++ b/drivers/iio/proximity/srf04.c
@@ -23,7 +23,7 @@
* trig: --+ +--
* ^ ^
* |<->|
- * udelay(10)
+ * udelay(trigger_pulse_us)
*
* ultra +-+ +-+ +-+
* sonic | | | | | |
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -56,6 +57,10 @@
#include
#include
+struct srf04_cfg {
+ unsigned long trigger_pulse_us;
+};
+
struct srf04_data {
struct device *dev;
struct gpio_desc*gpiod_trig;
@@ -66,6 +71,15 @@ struct srf04_data {
ktime_t ts_falling;
struct completion rising;
struct completion falling;
+ const struct srf04_cfg *cfg;
+};
+
+static const struct srf04_cfg srf04_cfg = {
+ .trigger_pulse_us = 10,
+};
+
+static const struct srf04_cfg mb_lv_cfg = {
+ .trigger_pulse_us = 20,
};
static irqreturn_t srf04_handle_irq(int irq, void *dev_id)
@@ -102,7 +116,7 @@ static int srf04_read(struct srf04_data *data)
reinit_completion(>falling);
gpiod_set_value(data->gpiod_trig, 1);
- udelay(10);
+ udelay(data->cfg->trigger_pulse_us);
gpiod_set_value(data->gpiod_trig, 0);
/* it cannot take more than 20 ms */
@@ -215,6 +229,18 @@ static const struct iio_chan_spec srf04_chan_spec[] = {
},
};
+static const struct of_device_id of_srf04_match[] = {
+ { .compatible = "devantech,srf04", .data = _cfg},
+ { .compatible = "maxbotix,mb1000", .data = _lv_cfg},
+ { .compatible = "maxbotix,mb1010", .data = _lv_cfg},
+ { .compatible = "maxbotix,mb1020", .data = _lv_cfg},
+ { .compatible = "maxbotix,mb1030", .data = _lv_cfg},
+ { .compatible = "maxbotix,mb1040", .data = _lv_cfg},
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, of_srf04_match);
+
static int srf04_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -230,6 +256,7 @@ static int srf04_probe(struct platform_device *pdev)
data = iio_priv(indio_dev);
data->dev = dev;
+ data->cfg = of_match_device(of_srf04_match, dev)->data;
mutex_init(>lock);
init_completion(>rising);
@@ -280,13 +307,6 @@ static int srf04_probe(struct platform_device *pdev)
return devm_iio_device_register(dev, indio_dev);
}
-static const struct of_device_id of_srf04_match[] = {
- { .compatible = "devantech,srf04", },
- {},
-};
-
-MODULE_DEVICE_TABLE(of, of_srf04_match);
-
static struct platform_driver srf04_driver = {
.probe = srf04_probe,
.driver = {
--
2.11.0
[PATCH 0/3] add Maxbotix ultrasonic iio sensors with gpio bitbanging
This patch series adds support for Maxbotix ultrasonic iio sensors with gpio bitbanging protocol. These sensors are quite similiar to the existing srf04. This is why the existing one was changed to support a driver specific configuration containing the differences between the different types. This patch series needs the formerly submitted "[PATCH v2] devantech-srf04.yaml: transform DT binding to YAML" because it relies on the yaml documentation of devantech-srf04.yaml Andreas Klinger (3): srf04.c: add maxbotix ultrasonic sensors devantech-srf04.yaml: add Maxbotix ultrasonic iio proximity sensors Kconfig: change configuration of srf04 ultrasonic iio sensor .../bindings/iio/proximity/devantech-srf04.yaml| 25 +- drivers/iio/proximity/Kconfig | 11 +-- drivers/iio/proximity/srf04.c | 38 +- 3 files changed, 54 insertions(+), 20 deletions(-) -- 2.11.0
[PATCH v2] bmp085.yaml: transform DT documentation of iio sensor into YAML
use bmp085.txt and change it into yaml format
fix links to datasheets in replaced documentation
Signed-off-by: Andreas Klinger
---
.../devicetree/bindings/iio/pressure/bmp085.txt| 27 -
.../devicetree/bindings/iio/pressure/bmp085.yaml | 70 ++
2 files changed, 70 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.txt
create mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
b/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
deleted file mode 100644
index 61c72e63c584..
--- a/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-BMP085/BMP18x/BMP28x digital pressure sensors
-
-Required properties:
-- compatible: must be one of:
- "bosch,bmp085"
- "bosch,bmp180"
- "bosch,bmp280"
- "bosch,bme280"
-
-Optional properties:
-- interrupts: interrupt mapping for IRQ
-- reset-gpios: a GPIO line handling reset of the sensor: as the line is
- active low, it should be marked GPIO_ACTIVE_LOW (see gpio/gpio.txt)
-- vddd-supply: digital voltage regulator (see regulator/regulator.txt)
-- vdda-supply: analog voltage regulator (see regulator/regulator.txt)
-
-Example:
-
-pressure@77 {
- compatible = "bosch,bmp085";
- reg = <0x77>;
- interrupt-parent = <>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- reset-gpios = < 26 GPIO_ACTIVE_LOW>;
- vddd-supply = <>;
- vdda-supply = <>;
-};
diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
new file mode 100644
index ..c6721a7e8938
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/bmp085.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BMP085/BMP180/BMP280/BME280 pressure iio sensors
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Pressure, temperature and humidity iio sensors with i2c and spi interfaces
+
+ Specifications about the sensor can be found at:
+https://www.bosch-sensortec.com/bst/products/all_products/bmp180
+https://www.bosch-sensortec.com/bst/products/all_products/bmp280
+https://www.bosch-sensortec.com/bst/products/all_products/bme280
+
+properties:
+ compatible:
+enum:
+ - bosch,bmp085
+ - bosch,bmp180
+ - bosch,bmp280
+ - bosch,bme280
+
+ vddd-supply:
+description:
+ digital voltage regulator (see regulator/regulator.txt)
+maxItems: 1
+
+ vdda-supply:
+description:
+ analog voltage regulator (see regulator/regulator.txt)
+maxItems: 1
+
+ reset-gpios:
+description:
+ A GPIO line handling reset of the sensor. As the line is active low,
+ it should be marked GPIO_ACTIVE_LOW (see gpio/gpio.txt)
+maxItems: 1
+
+ interrupts:
+description:
+ interrupt mapping for IRQ (BMP085 only)
+maxItems: 1
+
+required:
+ - compatible
+ - vddd-supply
+ - vdda-supply
+
+examples:
+ - |
+#include
+#include
+i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@77 {
+ compatible = "bosch,bmp085";
+ reg = <0x77>;
+ interrupt-parent = <>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = < 26 GPIO_ACTIVE_LOW>;
+ vddd-supply = <>;
+ vdda-supply = <>;
+ };
+};
--
2.11.0
[PATCH v2] avia-hx711.yaml: transform DT binding to YAML
replace avia-hx711.txt by avia-hx711.yaml as yaml devicetree
documentation for avia hx711 iio adc sensor
Signed-off-by: Andreas Klinger
---
.../devicetree/bindings/iio/adc/avia-hx711.txt | 24
.../devicetree/bindings/iio/adc/avia-hx711.yaml| 66 ++
2 files changed, 66 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
deleted file mode 100644
index 7222328a3d0d..
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* AVIA HX711 ADC chip for weight cells
- Bit-banging driver
-
-Required properties:
- - compatible: Should be "avia,hx711"
- - sck-gpios: Definition of the GPIO for the clock
- - dout-gpios: Definition of the GPIO for data-out
- See Documentation/devicetree/bindings/gpio/gpio.txt
- - avdd-supply:Definition of the regulator used as analog supply
-
-Optional properties:
- - clock-frequency:Frequency of PD_SCK in Hz
- Minimum value allowed is 10 kHz because of maximum
- high time of 50 microseconds.
-
-Example:
-weight {
- compatible = "avia,hx711";
- sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
- dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
- avdd-suppy = <>;
- clock-frequency = <10>;
-};
-
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
new file mode 100644
index ..8a4100ceeaf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: AVIA HX711 ADC chip for weight cells
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Bit-banging driver using two GPIOs:
+ - sck-gpio gives a clock to the sensor with 24 cycles for data retrieval
+and up to 3 cycles for selection of the input channel and gain for the
+next measurement
+ - dout-gpio is the sensor data the sensor responds to the clock
+
+ Specifications about the driver can be found at:
+ http://www.aviaic.com/ENProducts.aspx
+
+properties:
+ compatible:
+enum:
+ - avia,hx711
+
+ sck-gpios:
+description:
+ Definition of the GPIO for the clock (output). In the datasheet it is
+ named PD_SCK
+maxItems: 1
+
+ dout-gpios:
+description:
+ Definition of the GPIO for the data-out sent by the sensor in
+ response to the clock (input).
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+maxItems: 1
+
+ avdd-supply:
+description:
+ Definition of the regulator used as analog supply
+maxItems: 1
+
+ clock-frequency:
+minimum: 2
+maximum: 250
+default: 40
+
+required:
+ - compatible
+ - sck-gpios
+ - dout-gpios
+ - avdd-supply
+
+examples:
+ - |
+#include
+weight {
+compatible = "avia,hx711";
+sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
+dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
+avdd-suppy = <>;
+clock-frequency = <10>;
+};
--
2.11.0
[PATCH] bmp085.yaml: transform DT documentation of iio sensor into YAML
use bmp085.txt and change it into yaml format
fix links to datasheets in replaced documentation
Signed-off-by: Andreas Klinger
---
.../devicetree/bindings/iio/pressure/bmp085.txt| 27
.../devicetree/bindings/iio/pressure/bmp085.yaml | 71 ++
2 files changed, 71 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.txt
create mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
b/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
deleted file mode 100644
index 61c72e63c584..
--- a/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-BMP085/BMP18x/BMP28x digital pressure sensors
-
-Required properties:
-- compatible: must be one of:
- "bosch,bmp085"
- "bosch,bmp180"
- "bosch,bmp280"
- "bosch,bme280"
-
-Optional properties:
-- interrupts: interrupt mapping for IRQ
-- reset-gpios: a GPIO line handling reset of the sensor: as the line is
- active low, it should be marked GPIO_ACTIVE_LOW (see gpio/gpio.txt)
-- vddd-supply: digital voltage regulator (see regulator/regulator.txt)
-- vdda-supply: analog voltage regulator (see regulator/regulator.txt)
-
-Example:
-
-pressure@77 {
- compatible = "bosch,bmp085";
- reg = <0x77>;
- interrupt-parent = <>;
- interrupts = <25 IRQ_TYPE_EDGE_RISING>;
- reset-gpios = < 26 GPIO_ACTIVE_LOW>;
- vddd-supply = <>;
- vdda-supply = <>;
-};
diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
new file mode 100644
index ..884f889c1ca5
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/pressure/bmp085.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BMP085/BMP180/BMP280/BME280 pressure iio sensors
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Pressure, temperature and humidity iio sensors with i2c and spi interfaces
+
+ Specifications about the sensor can be found at:
+https://www.bosch-sensortec.com/bst/products/all_products/bmp180
+https://www.bosch-sensortec.com/bst/products/all_products/bmp280
+https://www.bosch-sensortec.com/bst/products/all_products/bme280
+
+properties:
+ compatible:
+oneOf:
+ - items:
+- enum:
+ - bosch,bmp085
+ - bosch,bmp180
+ - bosch,bmp280
+ - bosch,bme280
+
+ vddd-supply:
+description:
+ digital voltage regulator (see regulator/regulator.txt)
+maxItems: 1
+
+ vdda-supply:
+description:
+ analog voltage regulator (see regulator/regulator.txt)
+maxItems: 1
+
+ reset-gpios:
+description:
+ A GPIO line handling reset of the sensor. As the line is active low,
+ it should be marked GPIO_ACTIVE_LOW (see gpio/gpio.txt)
+maxItems: 1
+
+ interrupts:
+description:
+ interrupt mapping for IRQ (BMP085 only)
+
+required:
+ - compatible
+ - vddd-supply
+ - vdda-supply
+
+examples:
+ - |
+#include
+#include
+i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pressure@77 {
+ compatible = "bosch,bmp085";
+ reg = <0x77>;
+ interrupt-parent = <>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = < 26 GPIO_ACTIVE_LOW>;
+ vddd-supply = <>;
+ vdda-supply = <>;
+ };
+};
--
2.11.0
[PATCH] avia-hx711.yaml: transform DT binding to YAML
replace avia-hx711.txt by avia-hx711.yaml as yaml devicetree documentation
for avia hx711 iio adc sensor
Signed-off-by: Andreas Klinger
---
.../devicetree/bindings/iio/adc/avia-hx711.txt | 24
.../devicetree/bindings/iio/adc/avia-hx711.yaml| 67 ++
2 files changed, 67 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
deleted file mode 100644
index 7222328a3d0d..
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-* AVIA HX711 ADC chip for weight cells
- Bit-banging driver
-
-Required properties:
- - compatible: Should be "avia,hx711"
- - sck-gpios: Definition of the GPIO for the clock
- - dout-gpios: Definition of the GPIO for data-out
- See Documentation/devicetree/bindings/gpio/gpio.txt
- - avdd-supply:Definition of the regulator used as analog supply
-
-Optional properties:
- - clock-frequency:Frequency of PD_SCK in Hz
- Minimum value allowed is 10 kHz because of maximum
- high time of 50 microseconds.
-
-Example:
-weight {
- compatible = "avia,hx711";
- sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
- dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
- avdd-suppy = <>;
- clock-frequency = <10>;
-};
-
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
new file mode 100644
index ..e4fee0f877ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/iio/adc/avia-hx711.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: AVIA HX711 ADC chip for weight cells
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Bit-banging driver using two GPIOs:
+ - sck-gpio gives a clock to the sensor with 24 cycles for data retrieval
+and up to 3 cycles for selection of the input channel and gain for the
+next measurement
+ - dout-gpio is the sensor data the sensor responds to the clock
+
+ Specifications about the driver can be found at:
+ http://www.aviaic.com/ENProducts.aspx
+
+properties:
+ compatible:
+oneOf:
+ - items:
+- const: avia,hx711
+
+ sck-gpios:
+description:
+ Definition of the GPIO for the clock (output). In the datasheet it is
+ named PD_SCK
+maxItems: 1
+
+ dout-gpios:
+description:
+ Definition of the GPIO for the data-out sent by the sensor in
+ response to the clock (input).
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+maxItems: 1
+
+ avdd-supply:
+description:
+ Definition of the regulator used as analog supply
+maxItems: 1
+
+ clock-frequency:
+minimum: 2
+maximum: 250
+default: 40
+
+required:
+ - compatible
+ - sck-gpios
+ - dout-gpios
+ - avdd-supply
+
+examples:
+ - |
+#include
+weight {
+compatible = "avia,hx711";
+sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
+dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
+avdd-suppy = <>;
+clock-frequency = <10>;
+};
--
2.11.0
[PATCH v2] devantech-srf04.yaml: transform DT binding to YAML
devantech-srf04.yaml: yaml devicetree binding for iio ultrasonic
proximity driver of devantech srf04
use devantech-srf04.txt, transform binding into yaml and remove the
outdated DT documentation
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/devantech-srf04.txt | 28 --
.../bindings/iio/proximity/devantech-srf04.yaml| 59 ++
2 files changed, 59 insertions(+), 28 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
deleted file mode 100644
index d4dc7a227e2e..
--- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Devantech SRF04 ultrasonic range finder
- Bit-banging driver using two GPIOs
-
-Required properties:
- - compatible: Should be "devantech,srf04"
-
- - trig-gpios: Definition of the GPIO for the triggering (output)
- This GPIO is set for about 10 us by the driver to tell the
- device it should initiate the measurement cycle.
-
- - echo-gpios: Definition of the GPIO for the echo (input)
- This GPIO is set by the device as soon as an ultrasonic
- burst is sent out and reset when the first echo is
- received.
- Thus this GPIO is set while the ultrasonic waves are doing
- one round trip.
- It needs to be an GPIO which is able to deliver an
- interrupt because the time between two interrupts is
- measured in the driver.
- See Documentation/devicetree/bindings/gpio/gpio.txt for
- information on how to specify a consumer gpio.
-
-Example:
-srf04@0 {
- compatible = "devantech,srf04";
- trig-gpios = < 15 GPIO_ACTIVE_HIGH>;
- echo-gpios = < 6 GPIO_ACTIVE_HIGH>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
new file mode 100644
index ..e7aab785c97d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/devantech-srf04.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devantech SRF04 ultrasonic range finder
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Bit-banging driver using two GPIOs:
+ - trigger-gpio is raised by the driver to start sending out an ultrasonic
+burst
+ - echo-gpio is held high by the sensor after sending ultrasonic burst
+until it is received once again
+
+ Specifications about the driver can be found at:
+ http://www.robot-electronics.co.uk/htm/srf04tech.htm
+
+properties:
+ compatible:
+items:
+ - const: devantech,srf04
+
+ trig-gpios:
+description:
+ Definition of the GPIO for the triggering (output) This GPIO is set
+ for about 10 us by the driver to tell the device it should initiate
+ the measurement cycle.
+maxItems: 1
+
+ echo-gpios:
+description:
+ Definition of the GPIO for the echo (input)
+ This GPIO is set by the device as soon as an ultrasonic burst is sent
+ out and reset when the first echo is received.
+ Thus this GPIO is set while the ultrasonic waves are doing one round
+ trip.
+ It needs to be an GPIO which is able to deliver an interrupt because
+ the time between two interrupts is measured in the driver.
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+maxItems: 1
+
+required:
+ - compatible
+ - trig-gpios
+ - echo-gpios
+
+examples:
+ - |
+#include
+proximity {
+compatible = "devantech,srf04";
+trig-gpios = < 15 GPIO_ACTIVE_HIGH>;
+echo-gpios = < 6 GPIO_ACTIVE_HIGH>;
+};
--
2.11.0
[PATCH 2/2] devantech-srf04.txt: remove old DT documentation
remove the outdated DT documentation of devantech srf04 iio driver which
is replaced by devantech-srf04.yaml
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/devantech-srf04.txt | 28 --
1 file changed, 28 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
deleted file mode 100644
index d4dc7a227e2e..
--- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* Devantech SRF04 ultrasonic range finder
- Bit-banging driver using two GPIOs
-
-Required properties:
- - compatible: Should be "devantech,srf04"
-
- - trig-gpios: Definition of the GPIO for the triggering (output)
- This GPIO is set for about 10 us by the driver to tell the
- device it should initiate the measurement cycle.
-
- - echo-gpios: Definition of the GPIO for the echo (input)
- This GPIO is set by the device as soon as an ultrasonic
- burst is sent out and reset when the first echo is
- received.
- Thus this GPIO is set while the ultrasonic waves are doing
- one round trip.
- It needs to be an GPIO which is able to deliver an
- interrupt because the time between two interrupts is
- measured in the driver.
- See Documentation/devicetree/bindings/gpio/gpio.txt for
- information on how to specify a consumer gpio.
-
-Example:
-srf04@0 {
- compatible = "devantech,srf04";
- trig-gpios = < 15 GPIO_ACTIVE_HIGH>;
- echo-gpios = < 6 GPIO_ACTIVE_HIGH>;
-};
--
2.11.0
[PATCH 1/2] devantech-srf04.yaml: transform DT binding to YAML
use devantech-srf04.txt and transform binding into yaml
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/devantech-srf04.yaml| 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
new file mode 100644
index ..cd065393b062
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/devantech-srf04.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Devantech SRF04 ultrasonic range finder
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ Bit-banging driver using two GPIOs:
+ - trigger-gpio is raised by the driver to start sending out an ultrasonic
+burst
+ - echo-gpio is held high by the sensor after sending ultrasonic burst
+until it is received once again
+
+ Specifications about the driver can be found at:
+ http://www.robot-electronics.co.uk/htm/srf04tech.htm
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+items:
+ - const: devantech,srf04
+
+ trig-gpios:
+description:
+ Definition of the GPIO for the triggering (output) This GPIO is set
+ for about 10 us by the driver to tell the device it should initiate
+ the measurement cycle.
+maxItems: 1
+
+ echo-gpios:
+description:
+ Definition of the GPIO for the echo (input)
+ This GPIO is set by the device as soon as an ultrasonic burst is sent
+ out and reset when the first echo is received.
+ Thus this GPIO is set while the ultrasonic waves are doing one round
+ trip.
+ It needs to be an GPIO which is able to deliver an interrupt because
+ the time between two interrupts is measured in the driver.
+ See Documentation/devicetree/bindings/gpio/gpio.txt for information
+ on how to specify a consumer gpio.
+maxItems: 1
+
+required:
+ - compatible
+ - trig-gpios
+ - echo-gpios
+
+examples:
+ - |
+#include
+proximity {
+compatible = "devantech,srf04";
+trig-gpios = < 15 GPIO_ACTIVE_HIGH>;
+echo-gpios = < 6 GPIO_ACTIVE_HIGH>;
+};
--
2.11.0
[PATCH 0/2] transform devantech-srf04.txt into yaml format
use yaml description language to document Devantech SRF04 ultrasonic iio proximity driver Andreas Klinger (2): devantech-srf04.yaml: transform DT binding to YAML devantech-srf04.txt: remove old DT documentation .../bindings/iio/proximity/devantech-srf04.txt | 28 -- .../bindings/iio/proximity/devantech-srf04.yaml| 62 ++ 2 files changed, 62 insertions(+), 28 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/proximity/devantech-srf04.txt create mode 100644 Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml -- 2.11.0 -- Andreas Klinger Grabenreith 27 84508 Burgkirchen +49 8623 919966 a...@it-klinger.de www.it-klinger.de www.grabenreith.de
[PATCH v3 4/4] MAINTAINERS: add maintainer for maxbotix ultrasonic driver
add a maintainer for the newly created ultrasonic driver family of maxbotix Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index dce5c099f43c..fa054f8cc7fb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9234,6 +9234,13 @@ S: Maintained F: Documentation/devicetree/bindings/sound/max9860.txt F: sound/soc/codecs/max9860.* +MAXBOTIX ULTRASONIC RANGER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt +F: drivers/iio/proximity/mb1232.c + MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER M: Javier Martinez Canillas L: linux-kernel@vger.kernel.org -- 2.11.0
[PATCH v3 3/4] mb1232.c: add distance iio sensor with i2c
Add I2CXL-MaxSonar ultrasonic distance sensors of types mb1202, mb1212,
mb1222, mb1232, mb1242, mb7040, mb7137 using an i2c interface
Implemented functionality:
- reading the distance via in_distance_raw
- buffered mode with trigger
- make use of interrupt to announce completion of ranging
Add mb1232 driver to Kconfig and Makefile
Signed-off-by: Andreas Klinger
---
drivers/iio/proximity/Kconfig | 12 ++
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/mb1232.c | 274 +
3 files changed, 287 insertions(+)
create mode 100644 drivers/iio/proximity/mb1232.c
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index b99367a89f81..12a3d3d40a91 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -45,6 +45,18 @@ config LIDAR_LITE_V2
To compile this driver as a module, choose M here: the
module will be called pulsedlight-lite-v2
+config MB1232
+ tristate "MaxSonar I2CXL family ultrasonic sensors"
+ depends on I2C
+ help
+ Say Y to build a driver for the ultrasonic sensors I2CXL of
+ MaxBotix which have an i2c interface. It can be used to measure
+ the distance of objects. Supported types are mb1202, mb1212,
+ mb1222, mb1232, mb1242, mb7040, mb7137
+
+ To compile this driver as a module, choose M here: the
+ module will be called mb1232.
+
config RFD77402
tristate "RFD77402 ToF sensor"
depends on I2C
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 6d031f903c4c..0bb5f9de13d6 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_AS3935) += as3935.o
obj-$(CONFIG_ISL29501) += isl29501.o
obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
+obj-$(CONFIG_MB1232) += mb1232.o
obj-$(CONFIG_RFD77402) += rfd77402.o
obj-$(CONFIG_SRF04)+= srf04.o
obj-$(CONFIG_SRF08)+= srf08.o
diff --git a/drivers/iio/proximity/mb1232.c b/drivers/iio/proximity/mb1232.c
new file mode 100644
index ..d061cb16da93
--- /dev/null
+++ b/drivers/iio/proximity/mb1232.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * mb1232.c - Support for MaxBotix I2CXL-MaxSonar-EZ series ultrasonic
+ * ranger with i2c interface
+ * actually tested with mb1232 type
+ *
+ * Copyright (c) 2019 Andreas Klinger
+ *
+ * For details about the device see:
+ * https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* registers of MaxSonar device */
+#define MB1232_RANGE_COMMAND 0x51/* Command for reading range */
+#define MB1232_ADDR_UNLOCK_1 0xAA/* Command 1 for changing address */
+#define MB1232_ADDR_UNLOCK_2 0xA5/* Command 2 for changing address */
+
+struct mb1232_data {
+ struct i2c_client *client;
+
+ struct mutexlock;
+
+ /*
+* optionally a gpio can be used to announce when ranging has
+* finished
+* since we are just using the falling trigger of it we request
+* only the interrupt for announcing when data is ready to be read
+*/
+ struct completion ranging;
+ int irqnr;
+};
+
+static irqreturn_t mb1232_handle_irq(int irq, void *dev_id)
+{
+ struct iio_dev *indio_dev = dev_id;
+ struct mb1232_data *data = iio_priv(indio_dev);
+
+ complete(>ranging);
+
+ return IRQ_HANDLED;
+}
+
+static s16 mb1232_read_distance(struct mb1232_data *data)
+{
+ struct i2c_client *client = data->client;
+ int ret;
+ s16 distance;
+ __be16 buf;
+
+ mutex_lock(>lock);
+
+ reinit_completion(>ranging);
+
+ ret = i2c_smbus_write_byte(client, MB1232_RANGE_COMMAND);
+ if (ret < 0) {
+ dev_err(>dev, "write command - err: %d\n", ret);
+ goto error_unlock;
+ }
+
+ if (data->irqnr >= 0) {
+ /* it cannot take more than 100 ms */
+ ret = wait_for_completion_killable_timeout(>ranging,
+ HZ/10);
+ if (ret < 0)
+ goto error_unlock;
+ else if (ret == 0) {
+ ret = -ETIMEDOUT;
+ goto error_unlock;
+ }
+ } else {
+ /* use simple sleep if announce irq is not connected */
+ msleep(15);
+ }
+
+ ret = i2c_master_recv(client, (char *), sizeof(buf));
+ if (ret < 0) {
+ dev_err(>dev, "i2c_master_recv: ret=%d\n", ret);
+ goto error_unlock;
+ }
+
+ distance = _
[PATCH v3 2/4] dt-bindings: maxbotix,mb1232: Add MaxBotix i2c ultrasonic rangers
Add doc for dt binding maxbotix,mb1232. This binding is for MaxBotix
I2CXL-MaxSonar ultrasonic rangers which share a common i2c interface.
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb1232.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
new file mode 100644
index ..0e9df87eca1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
@@ -0,0 +1,31 @@
+* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
+ mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
+ for ranging
+
+Required properties:
+ - compatible: "maxbotix,mb1202",
+ "maxbotix,mb1212",
+ "maxbotix,mb1222",
+ "maxbotix,mb1232",
+ "maxbotix,mb1242",
+ "maxbotix,mb7040" or
+ "maxbotix,mb7137"
+
+ - reg:i2c address of the device, see also i2c/i2c.txt
+
+Optional properties:
+ - interrupt-parent: Interrupt controller to use
+
+ - interrupts: Interrupt used to announce the preceding reading
+ request has finished and that data is available.
+ If no interrupt is specified the device driver
+ falls back to wait a fixed amount of time until
+ data can be retrieved.
+
+Example:
+proximity@70 {
+ compatible = "maxbotix,mb1232";
+ reg = <0x70>;
+ interrupt-parent = <>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.11.0
[PATCH v3 1/4] dt-bindings: Add vendor prefix for MaxBotix
Add MaxBotix, which is a vendor of ultrasonic rangers in different varieties and interfaces. Signed-off-by: Andreas Klinger Reviewed-by: Andreas Färber Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389508584f48..added54a1108 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -225,6 +225,7 @@ lsi LSI Corp. (LSI Logic) lwnLiebherr-Werk Nenzing GmbH macnicaMacnica Americas marvellMarvell Technology Group Ltd. +maxbotix MaxBotix Inc. maxim Maxim Integrated Products mbvl Mobiveil Inc. mcube mCube -- 2.11.0
[PATCH v3 0/4] add MaxBotix I2CXL ultrasonic iio driver
This patch series adds support for I2CXL-MaxSonar ultrasonic distance
sensors with i2c interface of vendor MaxBotix
Supported types are:
mb1202, mb1212, mb1222, mb1232, mb1242, mb7040, mb7137
Implemented and tested functionality:
- reading the distance via in_distance_raw
- buffered mode with trigger
- make use of irq to announce completion of ranging
Changes in v3:
Thanks to the review of Julia, Jonathan, Rob and Peter there are some
changes:
- fix missing mutex_unlock() in mb1232_read_distance()
- change file and function names to the tested type mb1232
- list all supported types in {of,i2c}_device_id as well as in Kconfig
- reduce former status gpio to pure interrupt for announcement of finished
read cycle
Changes in v2:
Thanks to the review of Andreas and Peter there are a couple of changes:
- rename type wildcard mb12x2 to i2cxl in dt binding
- split changes in vendor list and dt doc into two patches
- merge driver source and Kconfig/Makefile change into one patch
- reword dt documentation
- use directly __be16 datatype to read directly from i2c
- use s16 as return value from mb12x2_read_distance()
Andreas Klinger (4):
dt-bindings: Add vendor prefix for MaxBotix
dt-bindings: maxbotix,mb1232: Add MaxBotix i2c ultrasonic rangers
mb1232.c: add distance iio sensor with i2c
MAINTAINERS: add maintainer for maxbotix ultrasonic driver
.../bindings/iio/proximity/maxbotix,mb1232.txt | 31 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS| 7 +
drivers/iio/proximity/Kconfig | 12 +
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/mb1232.c | 274 +
6 files changed, 326 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
create mode 100644 drivers/iio/proximity/mb1232.c
--
2.11.0
[PATCH v2 4/4] MAINTAINERS: add maintainer for maxbotix ultrasonic driver
add a maintainer for the newly created ultrasonic driver family of maxbotix Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9919840d54cd..0807d9239e1a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9226,6 +9226,13 @@ S: Maintained F: Documentation/devicetree/bindings/sound/max9860.txt F: sound/soc/codecs/max9860.* +MAXBOTIX ULTRASONIC RANGER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/proximity/maxbotix,i2cxl.txt +F: drivers/iio/proximity/mb12x2.c + MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER M: Javier Martinez Canillas L: linux-kernel@vger.kernel.org -- 2.11.0
[PATCH v2 2/4] dt-bindings: maxbotix,i2cxl: Add MaxBotix i2c ultrasonic rangers
Add doc for dt binding maxbotix,i2cxl. This binding is for MaxBotix
I2CXL-MaxSonar ultrasonic rangers which share a common i2c interface.
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,i2cxl.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,i2cxl.txt
diff --git a/Documentation/devicetree/bindings/iio/proximity/maxbotix,i2cxl.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,i2cxl.txt
new file mode 100644
index ..528f428fc583
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,i2cxl.txt
@@ -0,0 +1,21 @@
+* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb12x2 using
+ the i2c interface for ranging
+
+Required properties:
+ - compatible: Should be "maxbotix,i2cxl"
+
+ - reg:i2c address of the device
+
+Optional properties:
+ - status-gpios: Status gpio (input) used to announce the preceding
+ reading request has finished and that data is
+ available. If no status gpio is specified the
+ device driver falls back to wait until data can be
+ retrieved.
+
+Example:
+proximity@70 {
+ compatible = "maxbotix,i2cxl";
+ reg = <0x70>;
+ status-gpios = < 2 GPIO_ACTIVE_HIGH>;
+};
--
2.11.0
[PATCH v2 3/4] mb12x2.c: add distance iio sensor with i2c
Add I2CXL-MaxSonar ultrasonic distance sensors of type family mb12x2 using
an i2c interface
Implemented functionality:
- reading the distance via in_distance_raw
- buffered mode with trigger
- make use of status gpio to announce completion of ranging
Add mb12x2 driver to Kconfig and Makefile
Signed-off-by: Andreas Klinger
---
drivers/iio/proximity/Kconfig | 11 ++
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/mb12x2.c | 283 +
3 files changed, 295 insertions(+)
create mode 100644 drivers/iio/proximity/mb12x2.c
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index b99367a89f81..a420f2cb314b 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -45,6 +45,17 @@ config LIDAR_LITE_V2
To compile this driver as a module, choose M here: the
module will be called pulsedlight-lite-v2
+config MB12X2
+ tristate "MaxSonar MB12X2 family ultrasonic sensors"
+ depends on I2C
+ help
+ Say Y to build a driver for the ultrasonic sensors I2CXL of
+ MaxBotix which have an i2c interface. It can be used to measure
+ the distance of objects.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mb12x2.
+
config RFD77402
tristate "RFD77402 ToF sensor"
depends on I2C
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 6d031f903c4c..be9a14db77e7 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_AS3935) += as3935.o
obj-$(CONFIG_ISL29501) += isl29501.o
obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
+obj-$(CONFIG_MB12X2) += mb12x2.o
obj-$(CONFIG_RFD77402) += rfd77402.o
obj-$(CONFIG_SRF04)+= srf04.o
obj-$(CONFIG_SRF08)+= srf08.o
diff --git a/drivers/iio/proximity/mb12x2.c b/drivers/iio/proximity/mb12x2.c
new file mode 100644
index ..8b1ac901c253
--- /dev/null
+++ b/drivers/iio/proximity/mb12x2.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * mb12x2.c - Support for MaxBotix I2CXL-MaxSonar-EZ series ultrasonic
+ * ranger with i2c interface
+ * actually supported are mb12x2 types
+ *
+ * Copyright (c) 2019 Andreas Klinger
+ *
+ * For details about the device see:
+ * https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* registers of MaxSonar device */
+#define MB12X2_RANGE_COMMAND 0x51/* Command for reading range */
+#define MB12X2_ADDR_UNLOCK_1 0xAA/* Command 1 for changing address */
+#define MB12X2_ADDR_UNLOCK_2 0xA5/* Command 2 for changing address */
+
+struct mb12x2_data {
+ struct i2c_client *client;
+
+ struct mutexlock;
+
+ /*
+* optionally a gpio can be used to announce when ranging has
+* finished
+*/
+ struct completion ranging;
+ struct gpio_desc*gpiod_status;
+ int irqnr;
+
+ /*
+* triggered buffer
+* 1x16-bit channel + 3x16 padding + 4x16 timestamp
+*/
+ s16 buffer[8];
+};
+
+static irqreturn_t mb12x2_handle_irq(int irq, void *dev_id)
+{
+ struct iio_dev *indio_dev = dev_id;
+ struct mb12x2_data *data = iio_priv(indio_dev);
+
+ /* double check to make sure data is now available */
+ if (!gpiod_get_value(data->gpiod_status))
+ complete(>ranging);
+
+ return IRQ_HANDLED;
+}
+
+static s16 mb12x2_read_distance(struct mb12x2_data *data)
+{
+ struct i2c_client *client = data->client;
+ int ret;
+ s16 distance;
+ __be16 buf;
+
+ mutex_lock(>lock);
+
+ reinit_completion(>ranging);
+
+ ret = i2c_smbus_write_byte(client, MB12X2_RANGE_COMMAND);
+ if (ret < 0) {
+ dev_err(>dev, "write command - err: %d\n", ret);
+ mutex_unlock(>lock);
+ return ret;
+ }
+
+ if (data->gpiod_status) {
+ /* it cannot take more than 100 ms */
+ ret = wait_for_completion_killable_timeout(>ranging,
+ HZ/10);
+ if (ret < 0) {
+ mutex_unlock(>lock);
+ return ret;
+ } else if (ret == 0) {
+ mutex_unlock(>lock);
+ return -ETIMEDOUT;
+ }
+ } else {
+ /*
+* use simple sleep if gpio announce pin is not connected
+*/
+ msleep(15);
+ }
+
+ ret = i2c_master_recv(client, (char
[PATCH v2 1/4] dt-bindings: Add vendor prefix for MaxBotix
Add MaxBotix, which is a vendor of ultrasonic rangers in different varieties and interfaces. Signed-off-by: Andreas Klinger --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389508584f48..added54a1108 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -225,6 +225,7 @@ lsi LSI Corp. (LSI Logic) lwnLiebherr-Werk Nenzing GmbH macnicaMacnica Americas marvellMarvell Technology Group Ltd. +maxbotix MaxBotix Inc. maxim Maxim Integrated Products mbvl Mobiveil Inc. mcube mCube -- 2.11.0
[PATCH v2 0/4] add MaxBotix I2CXL ultrasonic iio driver
This patch series adds support for I2CXL-MaxSonar ultrasonic distance sensors of family mb12x2 using the i2c interface of vendor MaxBotix Implemented and tested functionality: - reading the distance via in_distance_raw - buffered mode with trigger - make use of status gpio to announce completion of ranging Changes in v2: Thanks to the review of Andreas and Peter there are a couple of changes: - rename type wildcard mb12x2 to i2cxl in dt binding - split changes in vendor list and dt doc into two patches - merge driver source and Kconfig/Makefile change into one patch - reword dt documentation - use directly __be16 datatype to read directly from i2c - use s16 as return value from mb12x2_read_distance() Andreas Klinger (4): dt-bindings: Add vendor prefix for MaxBotix dt-bindings: maxbotix,i2cxl: Add MaxBotix i2c ultrasonic rangers mb12x2.c: add distance iio sensor with i2c MAINTAINERS: add maintainer for maxbotix ultrasonic driver .../bindings/iio/proximity/maxbotix,i2cxl.txt | 21 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + MAINTAINERS| 7 + drivers/iio/proximity/Kconfig | 11 + drivers/iio/proximity/Makefile | 1 + drivers/iio/proximity/mb12x2.c | 283 + 6 files changed, 324 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/proximity/maxbotix,i2cxl.txt create mode 100644 drivers/iio/proximity/mb12x2.c -- 2.11.0
[PATCH 4/4] MAINTAINERS: add maintainer for maxbotix ultrasonic driver
add a maintainer for the newly created ultrasonic driver familiy of maxbotix Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9919840d54cd..bbf1860d4227 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9226,6 +9226,13 @@ S: Maintained F: Documentation/devicetree/bindings/sound/max9860.txt F: sound/soc/codecs/max9860.* +MAXBOTIX ULTRASONIC RANGER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/proximity/maxbotix,mb12x2.txt +F: drivers/iio/proximity/mb12x2.c + MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER M: Javier Martinez Canillas L: linux-kernel@vger.kernel.org -- 2.11.0
[PATCH 3/4] mb12x2.c: add mb12x2 ultrasonic distance iio sensor
Add MaxSonar-I2CXL ultrasonic distance sensors of type family mb12x2
using the i2c interface
Implemented functionality:
- reading the distance via in_distance_raw
- buffered mode with trigger
- make use of status gpio to announce completion of ranging
Signed-off-by: Andreas Klinger
---
drivers/iio/proximity/mb12x2.c | 283 +
1 file changed, 283 insertions(+)
create mode 100644 drivers/iio/proximity/mb12x2.c
diff --git a/drivers/iio/proximity/mb12x2.c b/drivers/iio/proximity/mb12x2.c
new file mode 100644
index ..0c052fde94b4
--- /dev/null
+++ b/drivers/iio/proximity/mb12x2.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * mb12x2.c - Support for I2CXL-MaxSonar-EZ series ultrasonic ranger with
+ * i2c interface
+ * actually supported are mb12x2 types
+ *
+ * Copyright (c) 2019 Andreas Klinger
+ *
+ * For details about the device see:
+ * https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* registers of MaxSonar device */
+#define MB12X2_RANGE_COMMAND 0x51/* Command for reading range */
+#define MB12X2_ADDR_UNLOCK_1 0xAA/* Command 1 for changing address */
+#define MB12X2_ADDR_UNLOCK_2 0xA5/* Command 2 for changing address */
+
+struct mb12x2_data {
+ struct i2c_client *client;
+
+ struct mutexlock;
+
+ /*
+* optionally a gpio can be used to announce when ranging has
+* finished
+*/
+ struct completion ranging;
+ struct gpio_desc*gpiod_status;
+ int irqnr;
+
+ /*
+* triggered buffer
+* 1x16-bit channel + 3x16 padding + 4x16 timestamp
+*/
+ s16 buffer[8];
+};
+
+static irqreturn_t mb12x2_handle_irq(int irq, void *dev_id)
+{
+ struct iio_dev *indio_dev = dev_id;
+ struct mb12x2_data *data = iio_priv(indio_dev);
+
+ /* double check to make sure data is now available */
+ if (!gpiod_get_value(data->gpiod_status))
+ complete(>ranging);
+
+ return IRQ_HANDLED;
+}
+
+static int mb12x2_read_distance(struct mb12x2_data *data)
+{
+ struct i2c_client *client = data->client;
+ int ret;
+ int distance;
+ unsigned char buf[2];
+
+ mutex_lock(>lock);
+
+ reinit_completion(>ranging);
+
+ ret = i2c_smbus_write_byte(client, MB12X2_RANGE_COMMAND);
+ if (ret < 0) {
+ dev_err(>dev, "write command - err: %d\n", ret);
+ mutex_unlock(>lock);
+ return ret;
+ }
+
+ if (data->gpiod_status) {
+ /* it cannot take more than 100 ms */
+ ret = wait_for_completion_killable_timeout(>ranging,
+ HZ/10);
+ if (ret < 0) {
+ mutex_unlock(>lock);
+ return ret;
+ } else if (ret == 0) {
+ mutex_unlock(>lock);
+ return -ETIMEDOUT;
+ }
+ } else {
+ /*
+* use simple sleep if gpio announce pin is not connected
+*/
+ msleep(15);
+ }
+
+
+ ret = i2c_master_recv(client, buf, sizeof(buf));
+ if (ret < 0) {
+ dev_err(>dev, "i2c_master_recv: ret=%d\n", ret);
+ mutex_unlock(>lock);
+ return ret;
+ }
+
+ distance = buf[0]<<8 | buf[1];
+
+ mutex_unlock(>lock);
+
+ return distance;
+}
+
+static irqreturn_t mb12x2_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct mb12x2_data *data = iio_priv(indio_dev);
+ s16 sensor_data;
+
+ sensor_data = mb12x2_read_distance(data);
+ if (sensor_data < 0)
+ goto err;
+
+ mutex_lock(>lock);
+
+ data->buffer[0] = sensor_data;
+ iio_push_to_buffers_with_timestamp(indio_dev,
+ data->buffer, pf->timestamp);
+
+ mutex_unlock(>lock);
+err:
+ iio_trigger_notify_done(indio_dev->trig);
+ return IRQ_HANDLED;
+}
+
+static int mb12x2_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *channel, int *val,
+ int *val2, long mask)
+{
+ struct mb12x2_data *data = iio_priv(indio_dev);
+ int ret;
+
+ if (channel->type != IIO_DISTANCE)
+ return -EINVAL;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = mb12x2_read_distance(data);
+ if (ret < 0)
+ return ret;
+
[PATCH 1/4] maxbotix,mb12x2.txt: add dt doc for maxbotix,mb12x2
add dt doc for maxbotix,mb12x2 and also a new vendor prefix maxbotix
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb12x2.txt | 22 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb12x2.txt
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb12x2.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb12x2.txt
new file mode 100644
index ..29f7fc09cfdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb12x2.txt
@@ -0,0 +1,22 @@
+* MaxSonar-I2CXL ultrasonic distance sensor of type mb12x2 using the i2c
+ interface for ranging
+
+Required properties:
+ - compatible: Should be "maxbotix,mb12x2"
+
+ - reg:i2c address of the device
+
+Optional properties:
+ - status-gpios: Definition of the status gpio (input) which is used
+ to announce the preceding reading request has
+ finished and that data is available. If no status
+ gpio is specified the device driver falls back to
+ wait a certain amount of time (15 ms) until data
+ can be retrieved.
+
+Example:
+mb@70 {
+ compatible = "maxbotix,mb12x2";
+ reg = <0x70>;
+ status-gpios = < 2 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389508584f48..added54a1108 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -225,6 +225,7 @@ lsi LSI Corp. (LSI Logic)
lwnLiebherr-Werk Nenzing GmbH
macnicaMacnica Americas
marvellMarvell Technology Group Ltd.
+maxbotix MaxBotix Inc.
maxim Maxim Integrated Products
mbvl Mobiveil Inc.
mcube mCube
--
2.11.0
[PATCH 2/4] iio/proximity: add mb12x2 driver to Kconfig and Makefile
Makefile and Kconfig: add configuration for mb12x2 ultrasonic proximity driver Signed-off-by: Andreas Klinger --- drivers/iio/proximity/Kconfig | 11 +++ drivers/iio/proximity/Makefile | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig index b99367a89f81..5d57ca44e30d 100644 --- a/drivers/iio/proximity/Kconfig +++ b/drivers/iio/proximity/Kconfig @@ -45,6 +45,17 @@ config LIDAR_LITE_V2 To compile this driver as a module, choose M here: the module will be called pulsedlight-lite-v2 +config MB12X2 + tristate "MaxSonar MB12X2 family ultrasonic sensors" + depends on I2C + help + Say Y to build a driver for the ultrasonic sensors of MaxSonar + with i2c interface. It can be used to measure the distance of + objects. + + To compile this driver as a module, choose M here: the + module will be called mb12x2. + config RFD77402 tristate "RFD77402 ToF sensor" depends on I2C diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile index 6d031f903c4c..c56b72a8be87 100644 --- a/drivers/iio/proximity/Makefile +++ b/drivers/iio/proximity/Makefile @@ -6,6 +6,7 @@ # When adding new entries keep the list in alphabetical order obj-$(CONFIG_AS3935) += as3935.o obj-$(CONFIG_ISL29501) += isl29501.o +obj-$(CONFIG_MB12X2) += mb12x2.o obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o obj-$(CONFIG_RFD77402) += rfd77402.o obj-$(CONFIG_SRF04)+= srf04.o -- 2.11.0
[PATCH 0/4] add maxbotix ultrasonic iio driver
This patch series adds support for MaxSonar-I2CXL ultrasonic distance sensors of family mb12x2 using the i2c interface of vendor maxbotix Implemented and tested functionality: - reading the distance via in_distance_raw - buffered mode with trigger - make use of status gpio to announce completion of ranging Andreas Klinger (4): maxbotix,mb12x2.txt: add dt doc for maxbotix,mb12x2 iio/proximity: add mb12x2 driver to Kconfig and Makefile mb12x2.c: add mb12x2 ultrasonic distance iio sensor MAINTAINERS: add maintainer for maxbotix ultrasonic driver .../bindings/iio/proximity/maxbotix,mb12x2.txt | 22 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + MAINTAINERS| 7 + drivers/iio/proximity/Kconfig | 11 + drivers/iio/proximity/Makefile | 1 + drivers/iio/proximity/mb12x2.c | 283 + 6 files changed, 325 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/proximity/maxbotix,mb12x2.txt create mode 100644 drivers/iio/proximity/mb12x2.c -- 2.11.0
[PATCH] gpio-omap.txt: add reg and interrupts properties
Document properties reg and interrupts for OMAP GPIO controller bindings
Also add unit address in node name of the example
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/gpio/gpio-omap.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index 8d950522e7fa..e57b2cb28f6c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,6 +5,8 @@ Required properties:
- "ti,omap2-gpio" for OMAP2 controllers
- "ti,omap3-gpio" for OMAP3 controllers
- "ti,omap4-gpio" for OMAP4 controllers
+- reg : Physical base address of the controller and length of memory mapped
+ region.
- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
@@ -18,6 +20,8 @@ Required properties:
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
+- interrupts : The interrupt the controller is rising as output when an
+ interrupt occures
OMAP specific properties:
- ti,hwmods: Name of the hwmod associated to the GPIO:
@@ -29,11 +33,13 @@ OMAP specific properties:
Example:
-gpio4: gpio4 {
+gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
-ti,hwmods = "gpio4";
+reg = <0x44e07000 0x1000>;
+ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+interrupts = <96>;
};
--
2.11.0
--
[PATCH v5 3/3] iio: hx711: fix spurious unit-address in example
Device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
Fix the example in the documentation of avia,hx711 to conform to dtc
behavior.
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index 2c1b67d33c49..7222328a3d0d 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -14,7 +14,7 @@ Optional properties:
high time of 50 microseconds.
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v5 3/3] iio: hx711: fix spurious unit-address in example
Device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
Fix the example in the documentation of avia,hx711 to conform to dtc
behavior.
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index 2c1b67d33c49..7222328a3d0d 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -14,7 +14,7 @@ Optional properties:
high time of 50 microseconds.
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v5 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacitance it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..36b59d8957fb 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,14 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
+ u32 clock_frequency;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +118,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -120,6 +136,12 @@ static int hx711_cycle(struct hx711_data *hx711_data)
gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
preempt_enable();
+ /*
+* make it a square wave for addressing cases with capacitance on
+* PC_SCK
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
return val;
}
@@ -458,6 +480,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +553,22 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ hx711_data->clock_frequency = 40;
+ ret = of_property_read_u32(np, "clock-frequency",
+ _data->clock_frequency);
+
+ /*
+* datasheet says the high level of PD_SCK has a maximum duration
+* of 50 microseconds
+*/
+ if (hx711_data->clock_frequency < 2) {
+ dev_warn(dev, "clock-frequency too low - assuming 400 kHz\n");
+ hx711_data->clock_frequency = 40;
+ }
+
+ hx711_data->data_ready_delay_ns =
+ 10 / hx711_data->clock_frequency;
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v5 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacitance it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..36b59d8957fb 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,14 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
+ u32 clock_frequency;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +118,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -120,6 +136,12 @@ static int hx711_cycle(struct hx711_data *hx711_data)
gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
preempt_enable();
+ /*
+* make it a square wave for addressing cases with capacitance on
+* PC_SCK
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
return val;
}
@@ -458,6 +480,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +553,22 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ hx711_data->clock_frequency = 40;
+ ret = of_property_read_u32(np, "clock-frequency",
+ _data->clock_frequency);
+
+ /*
+* datasheet says the high level of PD_SCK has a maximum duration
+* of 50 microseconds
+*/
+ if (hx711_data->clock_frequency < 2) {
+ dev_warn(dev, "clock-frequency too low - assuming 400 kHz\n");
+ hx711_data->clock_frequency = 40;
+ }
+
+ hx711_data->data_ready_delay_ns =
+ 10 / hx711_data->clock_frequency;
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v5 0/3] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacitance on different systems. In the last patch there is a fix of dtc warning if someone is using the given example. Changes against v4: - Thanks to Rob for giving me explanations - make square wave with clock PD_SCK and change documentation for it Changes against v3: - added suggestion of Rob to rename the new attribute to clock-frequency Changes against v2: - added suggestion of Jonathan to add vendor prefix in device tree setting Andreas Klinger (3): iio: hx711: add clock-frequency property in DT iio: hx711: add delay until DOUT is ready iio: hx711: fix spurious unit-address in example .../devicetree/bindings/iio/adc/avia-hx711.txt | 8 - drivers/iio/adc/hx711.c| 39 ++ 2 files changed, 46 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH v5 0/3] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacitance on different systems. In the last patch there is a fix of dtc warning if someone is using the given example. Changes against v4: - Thanks to Rob for giving me explanations - make square wave with clock PD_SCK and change documentation for it Changes against v3: - added suggestion of Rob to rename the new attribute to clock-frequency Changes against v2: - added suggestion of Jonathan to add vendor prefix in device tree setting Andreas Klinger (3): iio: hx711: add clock-frequency property in DT iio: hx711: add delay until DOUT is ready iio: hx711: fix spurious unit-address in example .../devicetree/bindings/iio/adc/avia-hx711.txt | 8 - drivers/iio/adc/hx711.c| 39 ++ 2 files changed, 46 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH v5 1/3] iio: hx711: add clock-frequency property in DT
Add clock-frequency property for hx711 ADC. This is the frequency of
PD_SCK.
After PD_SCK goes high DOUT is read just before PD_SCK goes down again.
This is necessary because of parasitic capacitance on the wiring.
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..2c1b67d33c49 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,17 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - clock-frequency:Frequency of PD_SCK in Hz
+ Minimum value allowed is 10 kHz because of maximum
+ high time of 50 microseconds.
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ clock-frequency = <10>;
};
--
2.1.4
[PATCH v5 1/3] iio: hx711: add clock-frequency property in DT
Add clock-frequency property for hx711 ADC. This is the frequency of
PD_SCK.
After PD_SCK goes high DOUT is read just before PD_SCK goes down again.
This is necessary because of parasitic capacitance on the wiring.
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..2c1b67d33c49 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,17 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - clock-frequency:Frequency of PD_SCK in Hz
+ Minimum value allowed is 10 kHz because of maximum
+ high time of 50 microseconds.
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ clock-frequency = <10>;
};
--
2.1.4
Re: [PATCH v4 1/3] iio: hx711: add clock-frequency property in DT
Hi Rob,
please see explanation below. Thanks.
Rob Herring schrieb am Thu, 05. Jul 15:30:
> On Wed, Jul 04, 2018 at 02:36:38PM +0200, Andreas Klinger wrote:
> > Add clock-frequency property for hx711 ADC
> >
> > This is the frequency of PD_SCK. It affects only the high value duration
> > since low value duration is not relevant and we are not able to switch
> > faster than the minimum duration specified.
> >
> > After PD_SCK goes high DOUT is read just before PD_SCK goes down again.
> > This is necessary because of parasitic capacities on the wiring.
>
> s/capacities/capacitance/
I'll change.
>
> >
> > Signed-off-by: Andreas Klinger
> > ---
> > Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > index b3629405f568..4bee51d536e1 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > @@ -8,11 +8,21 @@ Required properties:
> > See Documentation/devicetree/bindings/gpio/gpio.txt
> > - avdd-supply:Definition of the regulator used as analog supply
> >
> > +Optional properties:
> > + - clock-frequency:Frequency of PD_SCK
> > + This setting affects the duration of the high value
> > + phase of the clock (PD_SCK). The low value phase is
> > + not affected since it is not relevant for the
> > + measurement.
>
> That's not how frequency works. The high time should be equal to the low
> time. If you have parasitic capacitance affecting the rise time, then it
> is going to affect the fall time too.
>
> Perhaps there could be some reason not to have a square wave, but I
> didn't see one in the datasheet.
When PD_SCK goes high the ADC sets DOUT to the corresponding value. Only after a
rising edge DOUT is set. The falling edge doesn't matter.
The parasitic capacitance is occuring only on DOUT line, but not on PD_SCK. The
difference is that PD_SCK is driven by the microcontroller, and DOUT by the
ADC.
So after i set the rising edge on PD_SCK i have to wait until DOUT reaches its
value. Datasheet says this can take at maximum 0.1 us. This might be true, but
without wiring between ADC and microcontroller. With wiring of a 10 m cable i
saw 1 us on the oscilloscope.
If required i can post a screenshot of the oscilloscope.
The code which is executed in the driver on PD_SCK during low value takes much
more than the requested 0.2 us (measured 0.56 us). Of course i can make it a
square wave with equal low and high time, but i don't see it's needed and it'll
slow down the communication speed.
Out of my frequency generator i can get a rectangular waveform with different
low and high times and it's still called frequency. A don't have another
expression for it.
Do you have a suggestion how to call this attribute in the DT if frequency is
not suitable?
>
> > + Minimum value allowed is 20 kHz because of maximum
> > + high time of 50 microseconds.
>
> So 10kHz should be minimum.
>
Because the low time is very short (0.5 us) in comparison to the high time
(50 us) in the actual waveform i neglected it.
Andreas
> > +
> > Example:
> > weight@0 {
> > compatible = "avia,hx711";
> > sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
> > dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
> > avdd-suppy = <>;
> > + clock-frequency = <10>;
> > };
> >
> > --
> > 2.1.4
--
Re: [PATCH v4 1/3] iio: hx711: add clock-frequency property in DT
Hi Rob,
please see explanation below. Thanks.
Rob Herring schrieb am Thu, 05. Jul 15:30:
> On Wed, Jul 04, 2018 at 02:36:38PM +0200, Andreas Klinger wrote:
> > Add clock-frequency property for hx711 ADC
> >
> > This is the frequency of PD_SCK. It affects only the high value duration
> > since low value duration is not relevant and we are not able to switch
> > faster than the minimum duration specified.
> >
> > After PD_SCK goes high DOUT is read just before PD_SCK goes down again.
> > This is necessary because of parasitic capacities on the wiring.
>
> s/capacities/capacitance/
I'll change.
>
> >
> > Signed-off-by: Andreas Klinger
> > ---
> > Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > index b3629405f568..4bee51d536e1 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > @@ -8,11 +8,21 @@ Required properties:
> > See Documentation/devicetree/bindings/gpio/gpio.txt
> > - avdd-supply:Definition of the regulator used as analog supply
> >
> > +Optional properties:
> > + - clock-frequency:Frequency of PD_SCK
> > + This setting affects the duration of the high value
> > + phase of the clock (PD_SCK). The low value phase is
> > + not affected since it is not relevant for the
> > + measurement.
>
> That's not how frequency works. The high time should be equal to the low
> time. If you have parasitic capacitance affecting the rise time, then it
> is going to affect the fall time too.
>
> Perhaps there could be some reason not to have a square wave, but I
> didn't see one in the datasheet.
When PD_SCK goes high the ADC sets DOUT to the corresponding value. Only after a
rising edge DOUT is set. The falling edge doesn't matter.
The parasitic capacitance is occuring only on DOUT line, but not on PD_SCK. The
difference is that PD_SCK is driven by the microcontroller, and DOUT by the
ADC.
So after i set the rising edge on PD_SCK i have to wait until DOUT reaches its
value. Datasheet says this can take at maximum 0.1 us. This might be true, but
without wiring between ADC and microcontroller. With wiring of a 10 m cable i
saw 1 us on the oscilloscope.
If required i can post a screenshot of the oscilloscope.
The code which is executed in the driver on PD_SCK during low value takes much
more than the requested 0.2 us (measured 0.56 us). Of course i can make it a
square wave with equal low and high time, but i don't see it's needed and it'll
slow down the communication speed.
Out of my frequency generator i can get a rectangular waveform with different
low and high times and it's still called frequency. A don't have another
expression for it.
Do you have a suggestion how to call this attribute in the DT if frequency is
not suitable?
>
> > + Minimum value allowed is 20 kHz because of maximum
> > + high time of 50 microseconds.
>
> So 10kHz should be minimum.
>
Because the low time is very short (0.5 us) in comparison to the high time
(50 us) in the actual waveform i neglected it.
Andreas
> > +
> > Example:
> > weight@0 {
> > compatible = "avia,hx711";
> > sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
> > dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
> > avdd-suppy = <>;
> > + clock-frequency = <10>;
> > };
> >
> > --
> > 2.1.4
--
[PATCH v4 3/3] iio: hx711: warning in dt binding example doc
device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
fix the example in the documentation of avia,hx711 to conform to dtc
behavior
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index 4bee51d536e1..b218e093b55a 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -18,7 +18,7 @@ Optional properties:
high time of 50 microseconds.
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v4 3/3] iio: hx711: warning in dt binding example doc
device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
fix the example in the documentation of avia,hx711 to conform to dtc
behavior
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index 4bee51d536e1..b218e093b55a 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -18,7 +18,7 @@ Optional properties:
high time of 50 microseconds.
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v4 1/3] iio: hx711: add clock-frequency property in DT
Add clock-frequency property for hx711 ADC
This is the frequency of PD_SCK. It affects only the high value duration
since low value duration is not relevant and we are not able to switch
faster than the minimum duration specified.
After PD_SCK goes high DOUT is read just before PD_SCK goes down again.
This is necessary because of parasitic capacities on the wiring.
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..4bee51d536e1 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,21 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - clock-frequency:Frequency of PD_SCK
+ This setting affects the duration of the high value
+ phase of the clock (PD_SCK). The low value phase is
+ not affected since it is not relevant for the
+ measurement.
+ Minimum value allowed is 20 kHz because of maximum
+ high time of 50 microseconds.
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ clock-frequency = <10>;
};
--
2.1.4
[PATCH v4 1/3] iio: hx711: add clock-frequency property in DT
Add clock-frequency property for hx711 ADC
This is the frequency of PD_SCK. It affects only the high value duration
since low value duration is not relevant and we are not able to switch
faster than the minimum duration specified.
After PD_SCK goes high DOUT is read just before PD_SCK goes down again.
This is necessary because of parasitic capacities on the wiring.
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..4bee51d536e1 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,21 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - clock-frequency:Frequency of PD_SCK
+ This setting affects the duration of the high value
+ phase of the clock (PD_SCK). The low value phase is
+ not affected since it is not relevant for the
+ measurement.
+ Minimum value allowed is 20 kHz because of maximum
+ high time of 50 microseconds.
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ clock-frequency = <10>;
};
--
2.1.4
[PATCH v4 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..c914c36f9cdf 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,14 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
+ u32 clock_frequency;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +118,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +474,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +547,22 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ hx711_data->clock_frequency = 40;
+ ret = of_property_read_u32(np, "clock-frequency",
+ _data->clock_frequency);
+
+ /*
+* datasheet says the high level of PD_SCK has a maximum duration
+* of 50 microseconds
+*/
+ if (hx711_data->clock_frequency < 2) {
+ dev_warn(dev, "clock-frequency too low - assuming 400 kHz\n");
+ hx711_data->clock_frequency = 40;
+ }
+
+ hx711_data->data_ready_delay_ns =
+ 10 / hx711_data->clock_frequency;
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v4 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..c914c36f9cdf 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,14 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
+ u32 clock_frequency;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +118,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +474,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +547,22 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ hx711_data->clock_frequency = 40;
+ ret = of_property_read_u32(np, "clock-frequency",
+ _data->clock_frequency);
+
+ /*
+* datasheet says the high level of PD_SCK has a maximum duration
+* of 50 microseconds
+*/
+ if (hx711_data->clock_frequency < 2) {
+ dev_warn(dev, "clock-frequency too low - assuming 400 kHz\n");
+ hx711_data->clock_frequency = 40;
+ }
+
+ hx711_data->data_ready_delay_ns =
+ 10 / hx711_data->clock_frequency;
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v4 0/3] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacities on different systems. In the last patch there is a fix of dtc warning if someone is using the given example Changes against v3: - added suggestion of Rob to rename the new attribute to clock-frequency Changes against v2: - added suggestion of Jonathan to add vendor prefix in device tree setting Andreas Klinger (3): iio: hx711: add clock-frequency property in DT iio: hx711: add delay until DOUT is ready iio: hx711: warning in dt binding example doc .../devicetree/bindings/iio/adc/avia-hx711.txt | 12 +++- drivers/iio/adc/hx711.c| 33 ++ 2 files changed, 44 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH v4 0/3] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacities on different systems. In the last patch there is a fix of dtc warning if someone is using the given example Changes against v3: - added suggestion of Rob to rename the new attribute to clock-frequency Changes against v2: - added suggestion of Jonathan to add vendor prefix in device tree setting Andreas Klinger (3): iio: hx711: add clock-frequency property in DT iio: hx711: add delay until DOUT is ready iio: hx711: warning in dt binding example doc .../devicetree/bindings/iio/adc/avia-hx711.txt | 12 +++- drivers/iio/adc/hx711.c| 33 ++ 2 files changed, 44 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH v2] leds: ledtrig-morse: send out morse code
Send out a morse code by using LEDs.
This is useful especially on embedded systems without displays to tell the
user about error conditions and status information.
The trigger will be called "morse"
The string to be send is written into the file morse_string and sent out
with a workqueue. Supported are letters and digits.
With the file dot_unit the minimal time unit can be adjusted in
milliseconds.
Also add documentation for the morse led trigger
Thanks to Greg and Geert for suggesting improvements
Signed-off-by: Andreas Klinger
---
.../ABI/testing/sysfs-class-led-trigger-morse | 16 ++
drivers/leds/trigger/Kconfig | 10 +
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-morse.c | 298 +
4 files changed, 325 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-morse
create mode 100644 drivers/leds/trigger/ledtrig-morse.c
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-morse
b/Documentation/ABI/testing/sysfs-class-led-trigger-morse
new file mode 100644
index ..dd858e18aef5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-morse
@@ -0,0 +1,16 @@
+What: /sys/class/leds//morse_string
+Date: Jul 2018
+KernelVersion: 4.19
+Contact: linux-l...@vger.kernel.org
+Description:
+ A string containing alphanumeric characters written to this
+ file is send out as morse code through a LED
+
+What: /sys/class/leds//dot_unit
+Date: Jul 2018
+KernelVersion: 4.19
+Contact: linux-l...@vger.kernel.org
+Description:
+ Specifies the smallest amount of time in milliseconds of
+ the morse code sent out.
+ Default is 500 ms
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index a2559b4fdfff..ea706ef2354c 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -142,4 +142,14 @@ config LEDS_TRIGGER_NETDEV
This allows LEDs to be controlled by network device activity.
If unsure, say Y.
+config LEDS_TRIGGER_MORSE
+ tristate "LED Morse Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows to send a morse code through LEDs.
+ It is useful especially in embedded systems when there is only
+ little interface to tell the user error or status codes. Sending
+ a morse code can be an alternative here.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index f3cfe1950538..5735381cc3d3 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
+obj-$(CONFIG_LEDS_TRIGGER_MORSE) += ledtrig-morse.o
diff --git a/drivers/leds/trigger/ledtrig-morse.c
b/drivers/leds/trigger/ledtrig-morse.c
new file mode 100644
index ..46f1b9d38310
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-morse.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ledtrig-morse: LED Morse Trigger
+ *
+ * send a string as morse code out through LEDs
+ *
+ * can be used to send error codes or messages
+ *
+ * string to be send is written into morse_string
+ * supported are letters and digits
+ *
+ * Author: Andreas Klinger
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define MORSE_DOT_UNIT_DEFAULT 500
+#define MORSE_TELEGRAM_SIZE100
+
+struct morse_data {
+ unsigned intdot_unit;
+ struct led_classdev *led_cdev;
+ struct work_struct work;
+ chartelegram[MORSE_TELEGRAM_SIZE];
+ unsigned inttelegram_size;
+ struct mutexlock;
+};
+
+struct morse_char {
+ charc;
+ char*z;
+};
+
+static struct morse_char morse_table[] = {
+ {'a', ".-"},
+ {'b', "-..."},
+ {'c', "-.-."},
+ {'d', "-.."},
+ {'e', "."},
+ {'f', "..-."},
+ {'g', "--."},
+ {'h', ""},
+ {'i', ".."},
+ {'j', ".---"},
+ {'k', "-.-"},
+ {'l', ".-.."},
+ {'m', "--"},
+ {'n', "-."},
+ {'o', "---"},
+ {'p', ".--."},
+ {'q', "--.-"},
+ {'r', ".-."},
+ {'s', "..."},
+ {'t', "-"},
+ {'u', "..-"},
+ {'v', "...-"},
+ {'w', ".--"},
+ {'x', "-.
[PATCH v2] leds: ledtrig-morse: send out morse code
Send out a morse code by using LEDs.
This is useful especially on embedded systems without displays to tell the
user about error conditions and status information.
The trigger will be called "morse"
The string to be send is written into the file morse_string and sent out
with a workqueue. Supported are letters and digits.
With the file dot_unit the minimal time unit can be adjusted in
milliseconds.
Also add documentation for the morse led trigger
Thanks to Greg and Geert for suggesting improvements
Signed-off-by: Andreas Klinger
---
.../ABI/testing/sysfs-class-led-trigger-morse | 16 ++
drivers/leds/trigger/Kconfig | 10 +
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-morse.c | 298 +
4 files changed, 325 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-morse
create mode 100644 drivers/leds/trigger/ledtrig-morse.c
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-morse
b/Documentation/ABI/testing/sysfs-class-led-trigger-morse
new file mode 100644
index ..dd858e18aef5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-morse
@@ -0,0 +1,16 @@
+What: /sys/class/leds//morse_string
+Date: Jul 2018
+KernelVersion: 4.19
+Contact: linux-l...@vger.kernel.org
+Description:
+ A string containing alphanumeric characters written to this
+ file is send out as morse code through a LED
+
+What: /sys/class/leds//dot_unit
+Date: Jul 2018
+KernelVersion: 4.19
+Contact: linux-l...@vger.kernel.org
+Description:
+ Specifies the smallest amount of time in milliseconds of
+ the morse code sent out.
+ Default is 500 ms
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index a2559b4fdfff..ea706ef2354c 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -142,4 +142,14 @@ config LEDS_TRIGGER_NETDEV
This allows LEDs to be controlled by network device activity.
If unsure, say Y.
+config LEDS_TRIGGER_MORSE
+ tristate "LED Morse Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows to send a morse code through LEDs.
+ It is useful especially in embedded systems when there is only
+ little interface to tell the user error or status codes. Sending
+ a morse code can be an alternative here.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index f3cfe1950538..5735381cc3d3 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
+obj-$(CONFIG_LEDS_TRIGGER_MORSE) += ledtrig-morse.o
diff --git a/drivers/leds/trigger/ledtrig-morse.c
b/drivers/leds/trigger/ledtrig-morse.c
new file mode 100644
index ..46f1b9d38310
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-morse.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ledtrig-morse: LED Morse Trigger
+ *
+ * send a string as morse code out through LEDs
+ *
+ * can be used to send error codes or messages
+ *
+ * string to be send is written into morse_string
+ * supported are letters and digits
+ *
+ * Author: Andreas Klinger
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define MORSE_DOT_UNIT_DEFAULT 500
+#define MORSE_TELEGRAM_SIZE100
+
+struct morse_data {
+ unsigned intdot_unit;
+ struct led_classdev *led_cdev;
+ struct work_struct work;
+ chartelegram[MORSE_TELEGRAM_SIZE];
+ unsigned inttelegram_size;
+ struct mutexlock;
+};
+
+struct morse_char {
+ charc;
+ char*z;
+};
+
+static struct morse_char morse_table[] = {
+ {'a', ".-"},
+ {'b', "-..."},
+ {'c', "-.-."},
+ {'d', "-.."},
+ {'e', "."},
+ {'f', "..-."},
+ {'g', "--."},
+ {'h', ""},
+ {'i', ".."},
+ {'j', ".---"},
+ {'k', "-.-"},
+ {'l', ".-.."},
+ {'m', "--"},
+ {'n', "-."},
+ {'o', "---"},
+ {'p', ".--."},
+ {'q', "--.-"},
+ {'r', ".-."},
+ {'s', "..."},
+ {'t', "-"},
+ {'u', "..-"},
+ {'v', "...-"},
+ {'w', ".--"},
+ {'x', "-.
[PATCH v3 3/3] iio: hx711: warning in dt binding example doc
device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
fix the example in the documentation of avia,hx711 to conform to dtc
behavior
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index 669d213e2964..73676eef8f08 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -15,7 +15,7 @@ Optional properties:
time which is 5 in the datasheet
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v3 3/3] iio: hx711: warning in dt binding example doc
device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
fix the example in the documentation of avia,hx711 to conform to dtc
behavior
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index 669d213e2964..73676eef8f08 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -15,7 +15,7 @@ Optional properties:
time which is 5 in the datasheet
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v3 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..d944d1abedac 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,13 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ ret = of_property_read_u32(np, "avia,data-ready-delay-ns",
+ _data->data_ready_delay_ns);
+ if (ret < 0) {
+ dev_warn(dev, "avia,data-ready-delay-ns not set - assuming 0
ns\n");
+ hx711_data->data_ready_delay_ns = 0;
+ }
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v3 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..d944d1abedac 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,13 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ ret = of_property_read_u32(np, "avia,data-ready-delay-ns",
+ _data->data_ready_delay_ns);
+ if (ret < 0) {
+ dev_warn(dev, "avia,data-ready-delay-ns not set - assuming 0
ns\n");
+ hx711_data->data_ready_delay_ns = 0;
+ }
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v3 1/3] iio: hx711: add avia,data-ready-delay-ns property in DT
add avia,data-ready-delay-ns property for hx711 ADC
this is the delay after rising PD_SCK until DOUT is read and assumed to be
ready
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..669d213e2964 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,18 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - avia,data-ready-delay-ns: additional delay in nanoseconds between
+ rising of PD_SCK until DOUT is ready
+ should be less then maximum PD_SCK high
+ time which is 5 in the datasheet
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ avia,data-ready-delay-ns = <1000>;
};
--
2.1.4
[PATCH v3 1/3] iio: hx711: add avia,data-ready-delay-ns property in DT
add avia,data-ready-delay-ns property for hx711 ADC
this is the delay after rising PD_SCK until DOUT is read and assumed to be
ready
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..669d213e2964 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,18 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - avia,data-ready-delay-ns: additional delay in nanoseconds between
+ rising of PD_SCK until DOUT is ready
+ should be less then maximum PD_SCK high
+ time which is 5 in the datasheet
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ avia,data-ready-delay-ns = <1000>;
};
--
2.1.4
[PATCH v3 0/3] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacities on different systems. In the last patch there is a fix of dtc warning if someone is using the given example Changes against v2: - added suggestion of Jonathan to add vendor prefix in device tree setting Andreas Klinger (3): iio: hx711: add data-ready-delay-ns property in DT iio: hx711: add delay until DOUT is ready iio: hx711: warning in dt binding example doc .../devicetree/bindings/iio/adc/avia-hx711.txt | 9 - drivers/iio/adc/hx711.c| 23 ++ 2 files changed, 31 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH v3 0/3] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacities on different systems. In the last patch there is a fix of dtc warning if someone is using the given example Changes against v2: - added suggestion of Jonathan to add vendor prefix in device tree setting Andreas Klinger (3): iio: hx711: add data-ready-delay-ns property in DT iio: hx711: add delay until DOUT is ready iio: hx711: warning in dt binding example doc .../devicetree/bindings/iio/adc/avia-hx711.txt | 9 - drivers/iio/adc/hx711.c| 23 ++ 2 files changed, 31 insertions(+), 1 deletion(-) -- 2.1.4
Re: [PATCH] leds: ledtrig-morse: send out morse code
Hi, Pavel Machek schrieb am Thu, 28. Jun 22:45: > On Thu 2018-06-28 22:29:57, Andreas Klinger wrote: > > Hi Pavel, > > > > Pavel Machek schrieb am Thu, 28. Jun 20:56: > > > Hi! > > > > > > > Send out a morse code by using LEDs. > > > > > > > > This is useful especially on embedded systems without displays to tell > > > > the > > > > user about error conditions and status information. > > > > > > > > The trigger will be called "morse" > > > > > > > > The string to be send is written into the file morse_string and sent out > > > > with a workqueue. Supported are letters and digits. > > > > > > > > With the file dot_unit the minimal time unit can be adjusted in > > > > milliseconds. > > > > > > > > Signed-off-by: Andreas Klinger > > > > > > Can we get more general "pattern" trigger? Some LEDs can do that in > > > hardware, and it is more general than plain morse. > > > > > > Ouch and it already was implemented :-). Patch is in attachment. > > > > The idea of the morse trigger is so be able so send out a short error > > code or if needed also a complete sentence. The morse code don't need > > extra explanation to the user. Decoding can be found everywhere. > > Yeah, well... I don't think decoding sentences in morse code is going > to be much fun. > > And we don't really want encoder in kernel. Just do encoding in > userspace, and use pattern trigger to display it. > > For many uses, morse code is "too geeky", and other patterns will be > used. > > Like " X" for error 1, " X X " for error 2, " .xX .xX " for > charging, " .xXx. " for everything okay... > The hardware i'm using is not able to adjust brightness. It can just switch the LED on or off. That's it. If anybody is interested i can submit a version 2 of the morse trigger with the improvements suggested by Greg and Geert. Please let me know. Andreas > > With the pattern trigger one need a translation of the letters and > > numbers into morse code. This is what the morse trigger is doing. > > > > So from my perspective the pattern trigger is something different than > > the morse one. > > Well, pattern trigger is more generic, and can do everything morse > trigger can do. Lets do that instead. > > > Another question: > > The pattern trigger is not in mainline. Do you know why? > > Needs to be resubmitted, I'd say. > > Pavel > > > > +++ b/Documentation/leds/ledtrig-pattern.txt > > > @@ -0,0 +1,86 @@ > > > +LED Pattern Trigger > > > +=== > > > + > > > +This is a LED trigger allowing arbitrary pattern execution. It can do > > > gradual > > > +dimming. This trigger can be configured to repeat the pattern a number of > > > +times or indefinitely. This is intended as a way of communication for > > > embedded > > > +systems with no screen. > > > + > > > +The trigger can be activated from user space on LED class devices as > > > shown > > > +below: > > > + > > > + echo pattern > trigger > > > + > > > +This adds the following sysfs attributes to the LED: > > > + > > > + pattern - specifies the pattern. See syntax below. > > > + > > > + repeat - number of times the pattern must be repeated. > > > + writing -1 to this file will make the pattern > > > + repeat indefinitely. > > > + > > > +The pattern will be restarted each time a new value is written to > > > +the pattern or repeat attribute. When dimming, the LED brightness > > > +is set every 50 ms. > > > + > > > +pattern syntax: > > > +The pattern is specified in the pattern attribute with an array of comma- > > > +separated "brightness/length in miliseconds" values. The two components > > > +of each value are to be separated by a space. > > > + > > > +For example, assuming the driven LED supports > > > +intensity value from 0 to 255: > > > + > > > + echo 0 1000, 255 2000 > pattern > > > + > > > +Or: > > > + > > > + echo 0 1000, 255 2000, > pattern > > > +
Re: [PATCH] leds: ledtrig-morse: send out morse code
Hi, Pavel Machek schrieb am Thu, 28. Jun 22:45: > On Thu 2018-06-28 22:29:57, Andreas Klinger wrote: > > Hi Pavel, > > > > Pavel Machek schrieb am Thu, 28. Jun 20:56: > > > Hi! > > > > > > > Send out a morse code by using LEDs. > > > > > > > > This is useful especially on embedded systems without displays to tell > > > > the > > > > user about error conditions and status information. > > > > > > > > The trigger will be called "morse" > > > > > > > > The string to be send is written into the file morse_string and sent out > > > > with a workqueue. Supported are letters and digits. > > > > > > > > With the file dot_unit the minimal time unit can be adjusted in > > > > milliseconds. > > > > > > > > Signed-off-by: Andreas Klinger > > > > > > Can we get more general "pattern" trigger? Some LEDs can do that in > > > hardware, and it is more general than plain morse. > > > > > > Ouch and it already was implemented :-). Patch is in attachment. > > > > The idea of the morse trigger is so be able so send out a short error > > code or if needed also a complete sentence. The morse code don't need > > extra explanation to the user. Decoding can be found everywhere. > > Yeah, well... I don't think decoding sentences in morse code is going > to be much fun. > > And we don't really want encoder in kernel. Just do encoding in > userspace, and use pattern trigger to display it. > > For many uses, morse code is "too geeky", and other patterns will be > used. > > Like " X" for error 1, " X X " for error 2, " .xX .xX " for > charging, " .xXx. " for everything okay... > The hardware i'm using is not able to adjust brightness. It can just switch the LED on or off. That's it. If anybody is interested i can submit a version 2 of the morse trigger with the improvements suggested by Greg and Geert. Please let me know. Andreas > > With the pattern trigger one need a translation of the letters and > > numbers into morse code. This is what the morse trigger is doing. > > > > So from my perspective the pattern trigger is something different than > > the morse one. > > Well, pattern trigger is more generic, and can do everything morse > trigger can do. Lets do that instead. > > > Another question: > > The pattern trigger is not in mainline. Do you know why? > > Needs to be resubmitted, I'd say. > > Pavel > > > > +++ b/Documentation/leds/ledtrig-pattern.txt > > > @@ -0,0 +1,86 @@ > > > +LED Pattern Trigger > > > +=== > > > + > > > +This is a LED trigger allowing arbitrary pattern execution. It can do > > > gradual > > > +dimming. This trigger can be configured to repeat the pattern a number of > > > +times or indefinitely. This is intended as a way of communication for > > > embedded > > > +systems with no screen. > > > + > > > +The trigger can be activated from user space on LED class devices as > > > shown > > > +below: > > > + > > > + echo pattern > trigger > > > + > > > +This adds the following sysfs attributes to the LED: > > > + > > > + pattern - specifies the pattern. See syntax below. > > > + > > > + repeat - number of times the pattern must be repeated. > > > + writing -1 to this file will make the pattern > > > + repeat indefinitely. > > > + > > > +The pattern will be restarted each time a new value is written to > > > +the pattern or repeat attribute. When dimming, the LED brightness > > > +is set every 50 ms. > > > + > > > +pattern syntax: > > > +The pattern is specified in the pattern attribute with an array of comma- > > > +separated "brightness/length in miliseconds" values. The two components > > > +of each value are to be separated by a space. > > > + > > > +For example, assuming the driven LED supports > > > +intensity value from 0 to 255: > > > + > > > + echo 0 1000, 255 2000 > pattern > > > + > > > +Or: > > > + > > > + echo 0 1000, 255 2000, > pattern > > > +
Re: [PATCH] leds: ledtrig-morse: send out morse code
Hi Pavel, > Hi! > > > Send out a morse code by using LEDs. > > > > This is useful especially on embedded systems without displays to tell the > > user about error conditions and status information. > > > > The trigger will be called "morse" > > > > The string to be send is written into the file morse_string and sent out > > with a workqueue. Supported are letters and digits. > > > > With the file dot_unit the minimal time unit can be adjusted in > > milliseconds. > > > > Signed-off-by: Andreas Klinger > > Can we get more general "pattern" trigger? Some LEDs can do that in > hardware, and it is more general than plain morse. > > Ouch and it already was implemented :-). Patch is in attachment. > > Pavel The idea of the morse trigger is so be able so send out a short error code or if needed also a complete sentence. The morse code don't need extra explanation to the user. Decoding can be found everywhere. With the pattern trigger one need a translation of the letters and numbers into morse code. This is what the morse trigger is doing. So from my perspective the pattern trigger is something different than the morse one. Another question: The pattern trigger is not in mainline. Do you know why? Andreas > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > From rteysse...@gmail.com Fri Mar 20 15:40:22 2015 > Return-Path: > X-Original-To: pa...@atrey.karlin.mff.cuni.cz > Delivered-To: pa...@atrey.karlin.mff.cuni.cz > Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) > by atrey.karlin.mff.cuni.cz (Postfix) with ESMTP id 3275281ECB > for ; Fri, 20 Mar 2015 15:40:22 +0100 > (CET) > Received: by jabberwock.ucw.cz (Postfix) > id 3053A1C00FF; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Delivered-To: pa...@jabberwock.ucw.cz > Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com > [74.125.82.46]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not > verified)) > by jabberwock.ucw.cz (Postfix) with ESMTPS id 18EB61C00F9 > for ; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Received: by wgbcc7 with SMTP id cc7so91022009wgb.0 > for ; Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; > h=subject:from:to:cc:content-type:date:message-id:mime-version > :content-transfer-encoding; > bh=UdT+u6nHVkpFGm2AqZ0XFePjLX83mCQTkcoTCraWWvc=; > b=b9VbjaS+0McMAtdeSJv1Lhb6RDg/noWghgIsbIZD/DpMnIXJ05Dyi160Jx28uS0YzT > zyPmtmEv3IrnmkcCp7g6S6f04ATgi9q3tI+5qooaQS65V7bRtlpcTMoB8KEA38SsBtap > 8Ng+65MHchSpmGyR/h0WxVg934ieNpySSLCQ/vSUu2lOxi0SLmyr93KqfZXQ6Yk5FCA3 > QOcCuiXpcLfmGbLwR2YT0uu3/60LOmWL6xt+J/bkWjo38qwqtH5phoa5ydjcUy5MZJSZ > tn4qM8mQ8YH9EUJ+VjcxQX4nYdY+Mf3tsnSOieHNzUVt+2z1GmLcDi1Jfe8MtyPh8+9m > dp+w== > X-Received: by 10.194.108.137 with SMTP id > hk9mr118158926wjb.112.1426862421666; > Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > Received: from [192.168.244.132] (fs-141-0-203-237.fullsave.info. > [141.0.203.237]) > by mx.google.com with ESMTPSA id > ha10sm6624401wjc.37.2015.03.20.07.40.20 > (version=SSLv3 cipher=RC4-SHA bits=128/128); > Fri, 20 Mar 2015 07:40:20 -0700 (PDT) > Subject: [PATCH v2] leds: Add arbitrary pattern trigger > From: =?ISO-8859-1?Q?Rapha=EBl?= Teysseyre > To: Pavel Machek > Cc: Joe Xue , Bryan Wu , > "rpur...@rpsys.net" , Linux LED Subsystem > , lkml > Content-Type: text/plain; charset="UTF-8" > Date: Fri, 20 Mar 2015 15:42:02 +0100 > Message-ID: <1426862522.48232.3.camel@localhost> > Mime-Version: 1.0 > X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) > Content-Transfer-Encoding: 8bit > X-CRM114-Status: Good ( pR: 191.7191 ) > Status: RO > Content-Length: 17146 > > Hi all, > > Following your comments about [PATCH] leds: Add arbitrary pattern trigger, > here is a revised version of this patch. > > This is intended for embedded systems without screen or network access > to show a status (or error) code to a human. > > It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, > which CPU is a dual ARM Cortex-A9), with a non-mainline > kernel (xilinx-v2014.4, based of a 3.17.0 kernel). > Unfortunately, I don't have other hardware to test it on. > It compiles fine in a 3.19.0-rc1 so
Re: [PATCH] leds: ledtrig-morse: send out morse code
Hi Pavel, > Hi! > > > Send out a morse code by using LEDs. > > > > This is useful especially on embedded systems without displays to tell the > > user about error conditions and status information. > > > > The trigger will be called "morse" > > > > The string to be send is written into the file morse_string and sent out > > with a workqueue. Supported are letters and digits. > > > > With the file dot_unit the minimal time unit can be adjusted in > > milliseconds. > > > > Signed-off-by: Andreas Klinger > > Can we get more general "pattern" trigger? Some LEDs can do that in > hardware, and it is more general than plain morse. > > Ouch and it already was implemented :-). Patch is in attachment. > > Pavel The idea of the morse trigger is so be able so send out a short error code or if needed also a complete sentence. The morse code don't need extra explanation to the user. Decoding can be found everywhere. With the pattern trigger one need a translation of the letters and numbers into morse code. This is what the morse trigger is doing. So from my perspective the pattern trigger is something different than the morse one. Another question: The pattern trigger is not in mainline. Do you know why? Andreas > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > From rteysse...@gmail.com Fri Mar 20 15:40:22 2015 > Return-Path: > X-Original-To: pa...@atrey.karlin.mff.cuni.cz > Delivered-To: pa...@atrey.karlin.mff.cuni.cz > Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) > by atrey.karlin.mff.cuni.cz (Postfix) with ESMTP id 3275281ECB > for ; Fri, 20 Mar 2015 15:40:22 +0100 > (CET) > Received: by jabberwock.ucw.cz (Postfix) > id 3053A1C00FF; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Delivered-To: pa...@jabberwock.ucw.cz > Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com > [74.125.82.46]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not > verified)) > by jabberwock.ucw.cz (Postfix) with ESMTPS id 18EB61C00F9 > for ; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Received: by wgbcc7 with SMTP id cc7so91022009wgb.0 > for ; Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; > h=subject:from:to:cc:content-type:date:message-id:mime-version > :content-transfer-encoding; > bh=UdT+u6nHVkpFGm2AqZ0XFePjLX83mCQTkcoTCraWWvc=; > b=b9VbjaS+0McMAtdeSJv1Lhb6RDg/noWghgIsbIZD/DpMnIXJ05Dyi160Jx28uS0YzT > zyPmtmEv3IrnmkcCp7g6S6f04ATgi9q3tI+5qooaQS65V7bRtlpcTMoB8KEA38SsBtap > 8Ng+65MHchSpmGyR/h0WxVg934ieNpySSLCQ/vSUu2lOxi0SLmyr93KqfZXQ6Yk5FCA3 > QOcCuiXpcLfmGbLwR2YT0uu3/60LOmWL6xt+J/bkWjo38qwqtH5phoa5ydjcUy5MZJSZ > tn4qM8mQ8YH9EUJ+VjcxQX4nYdY+Mf3tsnSOieHNzUVt+2z1GmLcDi1Jfe8MtyPh8+9m > dp+w== > X-Received: by 10.194.108.137 with SMTP id > hk9mr118158926wjb.112.1426862421666; > Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > Received: from [192.168.244.132] (fs-141-0-203-237.fullsave.info. > [141.0.203.237]) > by mx.google.com with ESMTPSA id > ha10sm6624401wjc.37.2015.03.20.07.40.20 > (version=SSLv3 cipher=RC4-SHA bits=128/128); > Fri, 20 Mar 2015 07:40:20 -0700 (PDT) > Subject: [PATCH v2] leds: Add arbitrary pattern trigger > From: =?ISO-8859-1?Q?Rapha=EBl?= Teysseyre > To: Pavel Machek > Cc: Joe Xue , Bryan Wu , > "rpur...@rpsys.net" , Linux LED Subsystem > , lkml > Content-Type: text/plain; charset="UTF-8" > Date: Fri, 20 Mar 2015 15:42:02 +0100 > Message-ID: <1426862522.48232.3.camel@localhost> > Mime-Version: 1.0 > X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) > Content-Transfer-Encoding: 8bit > X-CRM114-Status: Good ( pR: 191.7191 ) > Status: RO > Content-Length: 17146 > > Hi all, > > Following your comments about [PATCH] leds: Add arbitrary pattern trigger, > here is a revised version of this patch. > > This is intended for embedded systems without screen or network access > to show a status (or error) code to a human. > > It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, > which CPU is a dual ARM Cortex-A9), with a non-mainline > kernel (xilinx-v2014.4, based of a 3.17.0 kernel). > Unfortunately, I don't have other hardware to test it on. > It compiles fine in a 3.19.0-rc1 so
Re: [PATCH] leds: ledtrig-morse: send out morse code
Hi Pavel, Pavel Machek schrieb am Thu, 28. Jun 20:56: > Hi! > > > Send out a morse code by using LEDs. > > > > This is useful especially on embedded systems without displays to tell the > > user about error conditions and status information. > > > > The trigger will be called "morse" > > > > The string to be send is written into the file morse_string and sent out > > with a workqueue. Supported are letters and digits. > > > > With the file dot_unit the minimal time unit can be adjusted in > > milliseconds. > > > > Signed-off-by: Andreas Klinger > > Can we get more general "pattern" trigger? Some LEDs can do that in > hardware, and it is more general than plain morse. > > Ouch and it already was implemented :-). Patch is in attachment. > > Pavel The idea of the morse trigger is so be able so send out a short error code or if needed also a complete sentence. The morse code don't need extra explanation to the user. Decoding can be found everywhere. With the pattern trigger one need a translation of the letters and numbers into morse code. This is what the morse trigger is doing. So from my perspective the pattern trigger is something different than the morse one. Another question: The pattern trigger is not in mainline. Do you know why? Andreas > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > From rteysse...@gmail.com Fri Mar 20 15:40:22 2015 > Return-Path: > X-Original-To: pa...@atrey.karlin.mff.cuni.cz > Delivered-To: pa...@atrey.karlin.mff.cuni.cz > Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) > by atrey.karlin.mff.cuni.cz (Postfix) with ESMTP id 3275281ECB > for ; Fri, 20 Mar 2015 15:40:22 +0100 > (CET) > Received: by jabberwock.ucw.cz (Postfix) > id 3053A1C00FF; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Delivered-To: pa...@jabberwock.ucw.cz > Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com > [74.125.82.46]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not > verified)) > by jabberwock.ucw.cz (Postfix) with ESMTPS id 18EB61C00F9 > for ; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Received: by wgbcc7 with SMTP id cc7so91022009wgb.0 > for ; Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; > h=subject:from:to:cc:content-type:date:message-id:mime-version > :content-transfer-encoding; > bh=UdT+u6nHVkpFGm2AqZ0XFePjLX83mCQTkcoTCraWWvc=; > b=b9VbjaS+0McMAtdeSJv1Lhb6RDg/noWghgIsbIZD/DpMnIXJ05Dyi160Jx28uS0YzT > zyPmtmEv3IrnmkcCp7g6S6f04ATgi9q3tI+5qooaQS65V7bRtlpcTMoB8KEA38SsBtap > 8Ng+65MHchSpmGyR/h0WxVg934ieNpySSLCQ/vSUu2lOxi0SLmyr93KqfZXQ6Yk5FCA3 > QOcCuiXpcLfmGbLwR2YT0uu3/60LOmWL6xt+J/bkWjo38qwqtH5phoa5ydjcUy5MZJSZ > tn4qM8mQ8YH9EUJ+VjcxQX4nYdY+Mf3tsnSOieHNzUVt+2z1GmLcDi1Jfe8MtyPh8+9m > dp+w== > X-Received: by 10.194.108.137 with SMTP id > hk9mr118158926wjb.112.1426862421666; > Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > Received: from [192.168.244.132] (fs-141-0-203-237.fullsave.info. > [141.0.203.237]) > by mx.google.com with ESMTPSA id > ha10sm6624401wjc.37.2015.03.20.07.40.20 > (version=SSLv3 cipher=RC4-SHA bits=128/128); > Fri, 20 Mar 2015 07:40:20 -0700 (PDT) > Subject: [PATCH v2] leds: Add arbitrary pattern trigger > From: =?ISO-8859-1?Q?Rapha=EBl?= Teysseyre > To: Pavel Machek > Cc: Joe Xue , Bryan Wu , > "rpur...@rpsys.net" , Linux LED Subsystem > , lkml > Content-Type: text/plain; charset="UTF-8" > Date: Fri, 20 Mar 2015 15:42:02 +0100 > Message-ID: <1426862522.48232.3.camel@localhost> > Mime-Version: 1.0 > X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) > Content-Transfer-Encoding: 8bit > X-CRM114-Status: Good ( pR: 191.7191 ) > Status: RO > Content-Length: 17146 > > Hi all, > > Following your comments about [PATCH] leds: Add arbitrary pattern trigger, > here is a revised version of this patch. > > This is intended for embedded systems without screen or network access > to show a status (or error) code to a human. > > It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, > which CPU is a dual ARM Cortex-A9), with a non-mainline > kernel (xilinx-v2014.4, based of a 3.17.0 kernel). > Unfortunately, I don't have other hardware to test it on. &
Re: [PATCH] leds: ledtrig-morse: send out morse code
Hi Pavel, Pavel Machek schrieb am Thu, 28. Jun 20:56: > Hi! > > > Send out a morse code by using LEDs. > > > > This is useful especially on embedded systems without displays to tell the > > user about error conditions and status information. > > > > The trigger will be called "morse" > > > > The string to be send is written into the file morse_string and sent out > > with a workqueue. Supported are letters and digits. > > > > With the file dot_unit the minimal time unit can be adjusted in > > milliseconds. > > > > Signed-off-by: Andreas Klinger > > Can we get more general "pattern" trigger? Some LEDs can do that in > hardware, and it is more general than plain morse. > > Ouch and it already was implemented :-). Patch is in attachment. > > Pavel The idea of the morse trigger is so be able so send out a short error code or if needed also a complete sentence. The morse code don't need extra explanation to the user. Decoding can be found everywhere. With the pattern trigger one need a translation of the letters and numbers into morse code. This is what the morse trigger is doing. So from my perspective the pattern trigger is something different than the morse one. Another question: The pattern trigger is not in mainline. Do you know why? Andreas > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > From rteysse...@gmail.com Fri Mar 20 15:40:22 2015 > Return-Path: > X-Original-To: pa...@atrey.karlin.mff.cuni.cz > Delivered-To: pa...@atrey.karlin.mff.cuni.cz > Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) > by atrey.karlin.mff.cuni.cz (Postfix) with ESMTP id 3275281ECB > for ; Fri, 20 Mar 2015 15:40:22 +0100 > (CET) > Received: by jabberwock.ucw.cz (Postfix) > id 3053A1C00FF; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Delivered-To: pa...@jabberwock.ucw.cz > Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com > [74.125.82.46]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not > verified)) > by jabberwock.ucw.cz (Postfix) with ESMTPS id 18EB61C00F9 > for ; Fri, 20 Mar 2015 15:40:22 +0100 (CET) > Received: by wgbcc7 with SMTP id cc7so91022009wgb.0 > for ; Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20120113; > h=subject:from:to:cc:content-type:date:message-id:mime-version > :content-transfer-encoding; > bh=UdT+u6nHVkpFGm2AqZ0XFePjLX83mCQTkcoTCraWWvc=; > b=b9VbjaS+0McMAtdeSJv1Lhb6RDg/noWghgIsbIZD/DpMnIXJ05Dyi160Jx28uS0YzT > zyPmtmEv3IrnmkcCp7g6S6f04ATgi9q3tI+5qooaQS65V7bRtlpcTMoB8KEA38SsBtap > 8Ng+65MHchSpmGyR/h0WxVg934ieNpySSLCQ/vSUu2lOxi0SLmyr93KqfZXQ6Yk5FCA3 > QOcCuiXpcLfmGbLwR2YT0uu3/60LOmWL6xt+J/bkWjo38qwqtH5phoa5ydjcUy5MZJSZ > tn4qM8mQ8YH9EUJ+VjcxQX4nYdY+Mf3tsnSOieHNzUVt+2z1GmLcDi1Jfe8MtyPh8+9m > dp+w== > X-Received: by 10.194.108.137 with SMTP id > hk9mr118158926wjb.112.1426862421666; > Fri, 20 Mar 2015 07:40:21 -0700 (PDT) > Received: from [192.168.244.132] (fs-141-0-203-237.fullsave.info. > [141.0.203.237]) > by mx.google.com with ESMTPSA id > ha10sm6624401wjc.37.2015.03.20.07.40.20 > (version=SSLv3 cipher=RC4-SHA bits=128/128); > Fri, 20 Mar 2015 07:40:20 -0700 (PDT) > Subject: [PATCH v2] leds: Add arbitrary pattern trigger > From: =?ISO-8859-1?Q?Rapha=EBl?= Teysseyre > To: Pavel Machek > Cc: Joe Xue , Bryan Wu , > "rpur...@rpsys.net" , Linux LED Subsystem > , lkml > Content-Type: text/plain; charset="UTF-8" > Date: Fri, 20 Mar 2015 15:42:02 +0100 > Message-ID: <1426862522.48232.3.camel@localhost> > Mime-Version: 1.0 > X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) > Content-Transfer-Encoding: 8bit > X-CRM114-Status: Good ( pR: 191.7191 ) > Status: RO > Content-Length: 17146 > > Hi all, > > Following your comments about [PATCH] leds: Add arbitrary pattern trigger, > here is a revised version of this patch. > > This is intended for embedded systems without screen or network access > to show a status (or error) code to a human. > > It's been tested on an ARM architecture (Xilinx Zynq 7010 SoC, > which CPU is a dual ARM Cortex-A9), with a non-mainline > kernel (xilinx-v2014.4, based of a 3.17.0 kernel). > Unfortunately, I don't have other hardware to test it on. &
[PATCH] leds: ledtrig-morse: send out morse code
Send out a morse code by using LEDs.
This is useful especially on embedded systems without displays to tell the
user about error conditions and status information.
The trigger will be called "morse"
The string to be send is written into the file morse_string and sent out
with a workqueue. Supported are letters and digits.
With the file dot_unit the minimal time unit can be adjusted in
milliseconds.
Signed-off-by: Andreas Klinger
---
drivers/leds/trigger/Kconfig | 10 ++
drivers/leds/trigger/Makefile| 1 +
drivers/leds/trigger/ledtrig-morse.c | 298 +++
3 files changed, 309 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-morse.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index a2559b4fdfff..ea706ef2354c 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -142,4 +142,14 @@ config LEDS_TRIGGER_NETDEV
This allows LEDs to be controlled by network device activity.
If unsure, say Y.
+config LEDS_TRIGGER_MORSE
+ tristate "LED Morse Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows to send a morse code through LEDs.
+ It is useful especially in embedded systems when there is only
+ little interface to tell the user error or status codes. Sending
+ a morse code can be an alternative here.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index f3cfe1950538..5735381cc3d3 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
+obj-$(CONFIG_LEDS_TRIGGER_MORSE) += ledtrig-morse.o
diff --git a/drivers/leds/trigger/ledtrig-morse.c
b/drivers/leds/trigger/ledtrig-morse.c
new file mode 100644
index ..77f6ee502ebe
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-morse.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ledtrig-morse: LED Morse Trigger
+ *
+ * send a string as morse code out through LEDs
+ *
+ * can be used to send error codes or messages
+ *
+ * string to be send is written into morse_string
+ * supported are letters and digits
+ *
+ * Author: Andreas Klinger
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define MORSE_DOT_UNIT_DEFAULT 500
+#define MORSE_TELEGRAM_SIZE100
+
+struct morse_data {
+ unsigned intdot_unit;
+ struct led_classdev *led_cdev;
+ struct work_struct work;
+ chartelegram[MORSE_TELEGRAM_SIZE];
+ unsigned inttelegram_size;
+ struct mutexlock;
+};
+
+struct morse_char {
+ charc;
+ char*z;
+};
+
+static struct morse_char morse_table[] = {
+ {'a', ".-S"},
+ {'b', "-...S"},
+ {'c', "-.-.S"},
+ {'d', "-..S"},
+ {'e', ".S"},
+ {'f', "..-.S"},
+ {'g', "--.S"},
+ {'h', "S"},
+ {'i', "..S"},
+ {'j', ".---S"},
+ {'k', "-.-S"},
+ {'l', ".-..S"},
+ {'m', "--S"},
+ {'n', "-.S"},
+ {'o', "---S"},
+ {'p', ".--.S"},
+ {'q', "--.-S"},
+ {'r', ".-.S"},
+ {'s', "...S"},
+ {'t', "-S"},
+ {'u', "..-S"},
+ {'v', "...-S"},
+ {'w', ".--S"},
+ {'x', "-..-S"},
+ {'y', "-.--S"},
+ {'z', "--..S"},
+ {'1', ".S"},
+ {'2', "..---S"},
+ {'3', "...--S"},
+ {'4', "-S"},
+ {'5', ".S"},
+ {'6', "-S"},
+ {'7', "--...S"},
+ {'8', "---..S"},
+ {'9', ".S"},
+ {'0', "-S"},
+ {0, NULL},
+};
+
+static void morse_long(struct led_classdev *led_cdev)
+{
+ struct morse_data *data = led_cdev->trigger_data;
+
+ led_set_brightness(led_cdev, LED_ON);
+ msleep(3 * data->dot_unit);
+ led_set_brightness(led_cdev, LED_OFF);
+ msleep(data->dot_unit);
+}
+
+static void morse_short(struct led_classdev *led_cdev)
+{
+ struct morse_data *data = led_cdev->trigger_data;
+
+ led_set_brightness(led_cdev, LED_ON);
+ msleep(data->dot_unit);
+ led_set_brightness(led_cdev, LED_OFF);
+ msleep(data->dot_unit);
+}
+
+static void morse_letter_space(struct led_classdev *led_cdev)
+{
[PATCH] leds: ledtrig-morse: send out morse code
Send out a morse code by using LEDs.
This is useful especially on embedded systems without displays to tell the
user about error conditions and status information.
The trigger will be called "morse"
The string to be send is written into the file morse_string and sent out
with a workqueue. Supported are letters and digits.
With the file dot_unit the minimal time unit can be adjusted in
milliseconds.
Signed-off-by: Andreas Klinger
---
drivers/leds/trigger/Kconfig | 10 ++
drivers/leds/trigger/Makefile| 1 +
drivers/leds/trigger/ledtrig-morse.c | 298 +++
3 files changed, 309 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-morse.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index a2559b4fdfff..ea706ef2354c 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -142,4 +142,14 @@ config LEDS_TRIGGER_NETDEV
This allows LEDs to be controlled by network device activity.
If unsure, say Y.
+config LEDS_TRIGGER_MORSE
+ tristate "LED Morse Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows to send a morse code through LEDs.
+ It is useful especially in embedded systems when there is only
+ little interface to tell the user error or status codes. Sending
+ a morse code can be an alternative here.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index f3cfe1950538..5735381cc3d3 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
obj-$(CONFIG_LEDS_TRIGGER_NETDEV) += ledtrig-netdev.o
+obj-$(CONFIG_LEDS_TRIGGER_MORSE) += ledtrig-morse.o
diff --git a/drivers/leds/trigger/ledtrig-morse.c
b/drivers/leds/trigger/ledtrig-morse.c
new file mode 100644
index ..77f6ee502ebe
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-morse.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ledtrig-morse: LED Morse Trigger
+ *
+ * send a string as morse code out through LEDs
+ *
+ * can be used to send error codes or messages
+ *
+ * string to be send is written into morse_string
+ * supported are letters and digits
+ *
+ * Author: Andreas Klinger
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define MORSE_DOT_UNIT_DEFAULT 500
+#define MORSE_TELEGRAM_SIZE100
+
+struct morse_data {
+ unsigned intdot_unit;
+ struct led_classdev *led_cdev;
+ struct work_struct work;
+ chartelegram[MORSE_TELEGRAM_SIZE];
+ unsigned inttelegram_size;
+ struct mutexlock;
+};
+
+struct morse_char {
+ charc;
+ char*z;
+};
+
+static struct morse_char morse_table[] = {
+ {'a', ".-S"},
+ {'b', "-...S"},
+ {'c', "-.-.S"},
+ {'d', "-..S"},
+ {'e', ".S"},
+ {'f', "..-.S"},
+ {'g', "--.S"},
+ {'h', "S"},
+ {'i', "..S"},
+ {'j', ".---S"},
+ {'k', "-.-S"},
+ {'l', ".-..S"},
+ {'m', "--S"},
+ {'n', "-.S"},
+ {'o', "---S"},
+ {'p', ".--.S"},
+ {'q', "--.-S"},
+ {'r', ".-.S"},
+ {'s', "...S"},
+ {'t', "-S"},
+ {'u', "..-S"},
+ {'v', "...-S"},
+ {'w', ".--S"},
+ {'x', "-..-S"},
+ {'y', "-.--S"},
+ {'z', "--..S"},
+ {'1', ".S"},
+ {'2', "..---S"},
+ {'3', "...--S"},
+ {'4', "-S"},
+ {'5', ".S"},
+ {'6', "-S"},
+ {'7', "--...S"},
+ {'8', "---..S"},
+ {'9', ".S"},
+ {'0', "-S"},
+ {0, NULL},
+};
+
+static void morse_long(struct led_classdev *led_cdev)
+{
+ struct morse_data *data = led_cdev->trigger_data;
+
+ led_set_brightness(led_cdev, LED_ON);
+ msleep(3 * data->dot_unit);
+ led_set_brightness(led_cdev, LED_OFF);
+ msleep(data->dot_unit);
+}
+
+static void morse_short(struct led_classdev *led_cdev)
+{
+ struct morse_data *data = led_cdev->trigger_data;
+
+ led_set_brightness(led_cdev, LED_ON);
+ msleep(data->dot_unit);
+ led_set_brightness(led_cdev, LED_OFF);
+ msleep(data->dot_unit);
+}
+
+static void morse_letter_space(struct led_classdev *led_cdev)
+{
[PATCH v2 4/4] iio: hx711: warning in dt binding example doc
device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
fix the example in the documentation of avia,hx711 to conform to dtc
behavior
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index d0c066e3df69..8c9bcaa4d750 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -15,7 +15,7 @@ Optional properties:
is 5 in the datasheet
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v2 4/4] iio: hx711: warning in dt binding example doc
device tree compiler (dtc) gives a warning if a device node has "@" with a
following number as it's name but no reg property.
fix the example in the documentation of avia,hx711 to conform to dtc
behavior
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index d0c066e3df69..8c9bcaa4d750 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -15,7 +15,7 @@ Optional properties:
is 5 in the datasheet
Example:
-weight@0 {
+weight {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
--
2.1.4
[PATCH v2 3/4] iio: hx711: add maintainer for driver
add a maintainer for driver hx711 Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b65225d443a..cfb8a08777ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2535,6 +2535,13 @@ S: Maintained F: drivers/auxdisplay/ F: include/linux/cfag12864b.h +AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/adc/avia-hx711.txt +F: drivers/iio/adc/hx711.c + AX.25 NETWORK LAYER M: Ralf Baechle L: linux-h...@vger.kernel.org -- 2.1.4
[PATCH v2 3/4] iio: hx711: add maintainer for driver
add a maintainer for driver hx711 Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b65225d443a..cfb8a08777ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2535,6 +2535,13 @@ S: Maintained F: drivers/auxdisplay/ F: include/linux/cfag12864b.h +AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/adc/avia-hx711.txt +F: drivers/iio/adc/hx711.c + AX.25 NETWORK LAYER M: Ralf Baechle L: linux-h...@vger.kernel.org -- 2.1.4
[PATCH v2 2/4] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..41e26ef324ee 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,13 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ ret = of_property_read_u32(np, "data-ready-delay-ns",
+ _data->data_ready_delay_ns);
+ if (ret < 0) {
+ dev_warn(dev, "data-ready-delay-ns not set - assuming 0 ns\n");
+ hx711_data->data_ready_delay_ns = 0;
+ }
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v2 2/4] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..41e26ef324ee 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,13 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ ret = of_property_read_u32(np, "data-ready-delay-ns",
+ _data->data_ready_delay_ns);
+ if (ret < 0) {
+ dev_warn(dev, "data-ready-delay-ns not set - assuming 0 ns\n");
+ hx711_data->data_ready_delay_ns = 0;
+ }
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH v2 1/4] iio: hx711: add data-ready-delay-ns property in DT
add data-ready-delay-ns property for hx711 ADC
this is the delay after rising PD_SCK until DOUT is read and assumed to be
ready
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..d0c066e3df69 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,18 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - data-ready-delay-ns:additional delay in nanoseconds between rising
of
+ PD_SCK until DOUT is ready
+ should be less then maximum PD_SCK high time which
+ is 5 in the datasheet
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ data-ready-delay-ns = <1000>;
};
--
2.1.4
[PATCH v2 1/4] iio: hx711: add data-ready-delay-ns property in DT
add data-ready-delay-ns property for hx711 ADC
this is the delay after rising PD_SCK until DOUT is read and assumed to be
ready
Signed-off-by: Andreas Klinger
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
index b3629405f568..d0c066e3df69 100644
--- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -8,11 +8,18 @@ Required properties:
See Documentation/devicetree/bindings/gpio/gpio.txt
- avdd-supply:Definition of the regulator used as analog supply
+Optional properties:
+ - data-ready-delay-ns:additional delay in nanoseconds between rising
of
+ PD_SCK until DOUT is ready
+ should be less then maximum PD_SCK high time which
+ is 5 in the datasheet
+
Example:
weight@0 {
compatible = "avia,hx711";
sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
avdd-suppy = <>;
+ data-ready-delay-ns = <1000>;
};
--
2.1.4
[PATCH v2 0/4] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacities on different systems. Furthermore a maintainer for this driver is added. In the last patch there is a fix of dtc warning if someone is using the given example Andreas Klinger (4): iio: hx711: add data-ready-delay-ns property in DT iio: hx711: add delay until DOUT is ready iio: hx711: add maintainer for driver iio: hx711: warning in dt binding example doc .../devicetree/bindings/iio/adc/avia-hx711.txt | 9 - MAINTAINERS| 7 +++ drivers/iio/adc/hx711.c| 23 ++ 3 files changed, 38 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH v2 0/4] iio: hx711: add data-ready-delay
This patch adds an additional property in the device tree for adjusting the delay between a rising edge on PD_SCK until data is ready on DOUT. This is necessary because of parasitic capacities on different systems. Furthermore a maintainer for this driver is added. In the last patch there is a fix of dtc warning if someone is using the given example Andreas Klinger (4): iio: hx711: add data-ready-delay-ns property in DT iio: hx711: add delay until DOUT is ready iio: hx711: add maintainer for driver iio: hx711: warning in dt binding example doc .../devicetree/bindings/iio/adc/avia-hx711.txt | 9 - MAINTAINERS| 7 +++ drivers/iio/adc/hx711.c| 23 ++ 3 files changed, 38 insertions(+), 1 deletion(-) -- 2.1.4
Re: [PATCH 1/3] iio: hx711: add data-ready-delay-ns property in DT
Hi Jonathan,
Jonathan Cameron schrieb am Sun, 24. Jun 14:10:
> On Sat, 23 Jun 2018 20:54:21 +0200
> Andreas Klinger wrote:
>
> > add data-ready-delay-ns property for hx711 ADC
> > this is the delay after rising PD_SCK until DOUT is read and assumed to be
> > ready
> >
> > Signed-off-by: Andreas Klinger
>
> One unconnected change. I'm not sure it's wrong as such but it should not
> be in this patch.
>
> > ---
> > Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > index b3629405f568..8c9bcaa4d750 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > @@ -8,11 +8,18 @@ Required properties:
> > See Documentation/devicetree/bindings/gpio/gpio.txt
> > - avdd-supply:Definition of the regulator used as analog supply
> >
> > +Optional properties:
> > + - data-ready-delay-ns:additional delay in nanoseconds between rising
> > of
> > + PD_SCK until DOUT is ready
> > + should be less then maximum PD_SCK high time which
> > + is 5 in the datasheet
> > +
> > Example:
> > -weight@0 {
> > +weight {
The device tree compiler (dtc) gives a warning if there is no reg = <...>
setting. That's why i changed it to be without @0.
Should i create an individual patch for this change in this series or
create another patch which is unrelated to this series?
Andreas
>
> Change has nothing to do with this patch...
>
> > compatible = "avia,hx711";
> > sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
> > dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
> > avdd-suppy = <>;
> > + data-ready-delay-ns = <1000>;
> > };
> >
>
--
Re: [PATCH 1/3] iio: hx711: add data-ready-delay-ns property in DT
Hi Jonathan,
Jonathan Cameron schrieb am Sun, 24. Jun 14:10:
> On Sat, 23 Jun 2018 20:54:21 +0200
> Andreas Klinger wrote:
>
> > add data-ready-delay-ns property for hx711 ADC
> > this is the delay after rising PD_SCK until DOUT is read and assumed to be
> > ready
> >
> > Signed-off-by: Andreas Klinger
>
> One unconnected change. I'm not sure it's wrong as such but it should not
> be in this patch.
>
> > ---
> > Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > index b3629405f568..8c9bcaa4d750 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> > @@ -8,11 +8,18 @@ Required properties:
> > See Documentation/devicetree/bindings/gpio/gpio.txt
> > - avdd-supply:Definition of the regulator used as analog supply
> >
> > +Optional properties:
> > + - data-ready-delay-ns:additional delay in nanoseconds between rising
> > of
> > + PD_SCK until DOUT is ready
> > + should be less then maximum PD_SCK high time which
> > + is 5 in the datasheet
> > +
> > Example:
> > -weight@0 {
> > +weight {
The device tree compiler (dtc) gives a warning if there is no reg = <...>
setting. That's why i changed it to be without @0.
Should i create an individual patch for this change in this series or
create another patch which is unrelated to this series?
Andreas
>
> Change has nothing to do with this patch...
>
> > compatible = "avia,hx711";
> > sck-gpios = < 10 GPIO_ACTIVE_HIGH>;
> > dout-gpios = < 7 GPIO_ACTIVE_HIGH>;
> > avdd-suppy = <>;
> > + data-ready-delay-ns = <1000>;
> > };
> >
>
--
[PATCH 3/3] iio: hx711: add maintainer for driver
add a maintainer for driver hx711 Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b65225d443a..cfb8a08777ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2535,6 +2535,13 @@ S: Maintained F: drivers/auxdisplay/ F: include/linux/cfag12864b.h +AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/adc/avia-hx711.txt +F: drivers/iio/adc/hx711.c + AX.25 NETWORK LAYER M: Ralf Baechle L: linux-h...@vger.kernel.org -- 2.1.4
[PATCH 3/3] iio: hx711: add maintainer for driver
add a maintainer for driver hx711 Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b65225d443a..cfb8a08777ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2535,6 +2535,13 @@ S: Maintained F: drivers/auxdisplay/ F: include/linux/cfag12864b.h +AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER +M: Andreas Klinger +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/adc/avia-hx711.txt +F: drivers/iio/adc/hx711.c + AX.25 NETWORK LAYER M: Ralf Baechle L: linux-h...@vger.kernel.org -- 2.1.4
[PATCH 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..41e26ef324ee 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,13 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ ret = of_property_read_u32(np, "data-ready-delay-ns",
+ _data->data_ready_delay_ns);
+ if (ret < 0) {
+ dev_warn(dev, "data-ready-delay-ns not set - assuming 0 ns\n");
+ hx711_data->data_ready_delay_ns = 0;
+ }
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
[PATCH 2/3] iio: hx711: add delay until DOUT is ready
On a system with parasitic capacities it turned out that DOUT is not ready
after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
until DOUT has reached its correct value.
With this patch its now possible to wait until data is ready.
The wait time should not be higher than the maximum PD_SCK high time which
is corresponding to the datasheet 5 ns.
Signed-off-by: Andreas Klinger
---
drivers/iio/adc/hx711.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
index 9430b54121e0..41e26ef324ee 100644
--- a/drivers/iio/adc/hx711.c
+++ b/drivers/iio/adc/hx711.c
@@ -97,6 +97,13 @@ struct hx711_data {
* 2x32-bit channel + 64-bit timestamp
*/
u32 buffer[4];
+ /*
+* delay after a rising edge on SCK until the data is ready DOUT
+* this is dependent on the hx711 where the datasheet tells a
+* maximum value of 100 ns
+* but also on potential parasitic capacities on the wiring
+*/
+ u32 data_ready_delay_ns;
};
static int hx711_cycle(struct hx711_data *hx711_data)
@@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
*/
preempt_disable();
gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+* wait until DOUT is ready
+* it turned out that parasitic capacities are extending the time
+* until DOUT has reached it's value
+*/
+ ndelay(hx711_data->data_ready_delay_ns);
+
val = gpiod_get_value(hx711_data->gpiod_dout);
/*
* here we are not waiting for 0.2 us as suggested by the datasheet,
@@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
static int hx711_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct device_node *np = dev->of_node;
struct hx711_data *hx711_data;
struct iio_dev *indio_dev;
int ret;
@@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev)
hx711_data->gain_set = 128;
hx711_data->gain_chan_a = 128;
+ ret = of_property_read_u32(np, "data-ready-delay-ns",
+ _data->data_ready_delay_ns);
+ if (ret < 0) {
+ dev_warn(dev, "data-ready-delay-ns not set - assuming 0 ns\n");
+ hx711_data->data_ready_delay_ns = 0;
+ }
+
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = "hx711";
--
2.1.4
