Re: [PATCH] misc devices: HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

Dear Greg, dear Daniel,

Thank you for your suggestions,  I will port the driver to IIO layer as
you suggested and then get back (may take some days).  I will also use 
git-send-mail, since that seems to be the best way to do it.

Am 24.03.16 um 16:52 schrieb Daniel Baluta:
> On Thu, Mar 24, 2016 at 5:02 PM, Johannes Thoma
>  wrote:
>>   From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001
>> From: Johannes Thoma 
>> Date: Mon, 21 Mar 2016 22:11:01 +0100
>> Subject: [PATCH] HC-SRO4 ultrasonic distance sensor driver
>>
>> The HC-SRO4 is an ultrasonic distance sensor attached to two GPIO
>> pins. The driver is controlled via sysfs and supports an (in theory)
>> unlimited number of HC-SRO4 devices.
>>
>> Unlike user land solutions this driver produces precise results
>> even when there is high load on the system. It uses a non-blocking
>> interrupt triggered mechanism to record the length of the echo
>> signal.
>
> Add link to datasheet.

One location is:

http://www.micropik.com/PDF/HCSR04.pdf

>>
>> This patch is against the raspberry pi kernel from
>> https://github.com/raspberrypi/linux.git hash
>> e481b5ceae6c94c7e60f8bb8591cbb362806246e
>>
>> Note that this patch isn't meant for lkml (yet) see:
>> TODO's:
>>
>> .) Patch against mainline (or whatever kernel it belongs to)
>> .) Use IIO layer instead of creating random sysfs entries.
>
> So, why aren't you directly using IIO? :)
>
I will but I just got the hint from greg that I should do
so (didn't know about it ;).

all the best,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] misc devices: HC-SRO4 ultrasonic distance driver

[Greg KH]

On Thu, Mar 24, 2016 at 04:02:03PM +0100, Johannes Thoma wrote:
>  From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001
> From: Johannes Thoma 
> Date: Mon, 21 Mar 2016 22:11:01 +0100
> Subject: [PATCH] HC-SRO4 ultrasonic distance sensor driver
> 
> The HC-SRO4 is an ultrasonic distance sensor attached to two GPIO
> pins. The driver is controlled via sysfs and supports an (in theory)
> unlimited number of HC-SRO4 devices.
> 
> Unlike user land solutions this driver produces precise results
> even when there is high load on the system. It uses a non-blocking
> interrupt triggered mechanism to record the length of the echo
> signal.
> 
> This patch is against the raspberry pi kernel from
> https://github.com/raspberrypi/linux.git hash
> e481b5ceae6c94c7e60f8bb8591cbb362806246e
> 
> Note that this patch isn't meant for lkml (yet) see:
> TODO's:
> 
> .) Patch against mainline (or whatever kernel it belongs to)
> .) Use IIO layer instead of creating random sysfs entries.
> .) Fill in GPIO device as parent to device_create_with_groups().
> .) Test it with two or more HC-SRO4 devices.
> .) Test it on other hardware than raspberry pi.
> .) Test it with kernel debugging enabled.
> 
> Anyway, comments are highly appreciated.
> 
> Signed-off-by: Johannes Thoma 
> ---
>   MAINTAINERS|   5 +
>   drivers/misc/Kconfig   |  11 ++
>   drivers/misc/Makefile  |   1 +
>   drivers/misc/hc-sro4.c | 360
> +

Basic comment, your email client corrupted the patch, wrapping the lines
and putting odd spaces at the front of the patch, making it impossible
to apply.  Try using 'git send-email' to fix this up, or fix up your
email client.

Also, your patch should not have the email header up there in it, that's
the sign that something went wrong.

try it again?

thanks

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[PATCH] misc devices: HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

 From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001
From: Johannes Thoma 
Date: Mon, 21 Mar 2016 22:11:01 +0100
Subject: [PATCH] HC-SRO4 ultrasonic distance sensor driver

The HC-SRO4 is an ultrasonic distance sensor attached to two GPIO
pins. The driver is controlled via sysfs and supports an (in theory)
unlimited number of HC-SRO4 devices.

Unlike user land solutions this driver produces precise results
even when there is high load on the system. It uses a non-blocking
interrupt triggered mechanism to record the length of the echo
signal.

This patch is against the raspberry pi kernel from
https://github.com/raspberrypi/linux.git hash
e481b5ceae6c94c7e60f8bb8591cbb362806246e

Note that this patch isn't meant for lkml (yet) see:
TODO's:

.) Patch against mainline (or whatever kernel it belongs to)
.) Use IIO layer instead of creating random sysfs entries.
.) Fill in GPIO device as parent to device_create_with_groups().
.) Test it with two or more HC-SRO4 devices.
.) Test it on other hardware than raspberry pi.
.) Test it with kernel debugging enabled.

Anyway, comments are highly appreciated.

Signed-off-by: Johannes Thoma 
---
  MAINTAINERS|   5 +
  drivers/misc/Kconfig   |  11 ++
  drivers/misc/Makefile  |   1 +
  drivers/misc/hc-sro4.c | 360
+
  4 files changed, 377 insertions(+)
  create mode 100644 drivers/misc/hc-sro4.c

diff --git a/MAINTAINERS b/MAINTAINERS
index da3e4d8..f819d66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4910,6 +4910,11 @@ W:
http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
  S:Maintained
  F:drivers/platform/x86/hdaps.c

+HC-SRO4 ULTRASONIC DISTANCE SENSOR DRIVER
+M: Johannes Thoma 
+S: Maintained
+F: drivers/misc/hc-sro4.c
+
  HDPVR USB VIDEO ENCODER DRIVER
  M:Hans Verkuil 
  L:linux-me...@vger.kernel.org
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4c499de..1be88ad 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -475,6 +475,17 @@ config BMP085_SPI
  To compile this driver as a module, choose M here: the
  module will be called bmp085-spi.

+config SENSORS_HC_SRO4
+   tristate "HC-SRO4 ultrasonic distance sensor on GPIO"
+   depends on GPIOLIB && SYSFS
+   help
+ Say Y here if you want to support the HC-SRO4
+ ultrasonic distance sensor to be hooked on two runtime-configurable
+ GPIO pins.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hc-sro4.
+
  config PCH_PHUB
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
select GENERIC_NET_UTILS
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 1acff5b..9a8e508 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_QCOM_COINCELL)   += qcom-coincell.o
  obj-$(CONFIG_SENSORS_BH1780)  += bh1780gli.o
  obj-$(CONFIG_SENSORS_BH1770)  += bh1770glc.o
  obj-$(CONFIG_SENSORS_APDS990X)+= apds990x.o
+obj-$(CONFIG_SENSORS_HC_SRO4)  += hc-sro4.o
  obj-$(CONFIG_SGI_IOC4)+= ioc4.o
  obj-$(CONFIG_ENCLOSURE_SERVICES) += enclosure.o
  obj-$(CONFIG_KGDB_TESTS)  += kgdbts.o
diff --git a/drivers/misc/hc-sro4.c b/drivers/misc/hc-sro4.c
new file mode 100644
index 000..9925b7e
--- /dev/null
+++ b/drivers/misc/hc-sro4.c
@@ -0,0 +1,360 @@
+/* Precise measurements of time delta between sending a trigger signal
+ * to the HC-SRO4 distance sensor and receiving the echo signal from
+ * the sensor back. This has to be precise in the usecs range. We
+ * use trigger interrupts to measure the signal, so no busy wait :)
+ *
+ * This supports an (in theory) unlimited number of HC-SRO4 devices.
+ * To add a device, do a (as root):
+ *
+ * # echo 23 24 1000 > /sys/class/distance-sensor/configure
+ *
+ * (23 is the trigger GPIO, 24 is the echo GPIO and 1000 is a timeout in
+ *  milliseconds)
+ *
+ * Then a directory appears with a file measure in it. To measure, do a
+ *
+ * # cat /sys/class/distance-sensor/distance_23_24/measure
+ *
+ * You'll receive the length of the echo signal in usecs. To convert
(roughly)
+ * to centimeters multiply by 17150 and divide by 1e6.
+ *
+ * To deconfigure the device, do a
+ *
+ * # echo -23 24 > /sys/class/distance-sensor/configure
+ *
+ * (normally not needed).
+ *
+ * DO NOT attach your HC-SRO4's echo pin directly to the raspberry, since
+ * it runs with 5V while raspberry expects 3V on the GPIO inputs.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct hc_sro4 {
+   int gpio_trig;
+   int gpio_echo;
+   struct gpio_desc *trig_desc;
+   struct gpio_desc *echo_desc;
+   struct timeval time_triggered;
+   

Re: HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

Am 24.03.16 um 15:07 schrieb Greg KH:
> On Thu, Mar 24, 2016 at 11:38:45AM +0100, Johannes Thoma wrote:
>> Hi all,
>>
>> I wrote a driver for the popular HC-SRO4 ultrasonic distance sensor. It
>> is beta and has been tested
>> on the Raspberry PI by me and my brother: here is the stand-alone repo:
>>
>> https://github.com/johannesthoma/linux-hc-sro4
>>
>> I would like to contribute it to the linux kernel, however I am a little
>> bit nervous reading through
>> the Documentation/Submitting[Patches][Drivers] documentation (in
>> particular the How to piss off
>> a kernel developer sections ;)
> Don't be scared, we don't bite :)
Good to know ;)
>> , so I wanted to ask if I could post the
>> patch (it will be against the
>> char/mics device kernel tree at
>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
>> , I think this is the correct location) on this list first, maybe
>> someone can tell me if the formatting
>> and the driver are correct..
> Formatting of the code itself, or the patch?
The patch. I will do it with git-format-patch and then it should work ..
>> I also have some driver specific questions:
>>
>> *) First, does it really belong to drivers/misc ? There are other
>> sensors there as well, so I suppose
>> this location is right.
> Probably not, if this is a sensor, it should be interacting with the IIO
> layer, and not just using "random" sysfs files.
Oh that is a good hint, didn't know that..
>> *) As of now, I've created a new device class "distance" where the sysfs
>> control files live in (so the configuration file is
>> /sys/class/distance/configure ), it works for me (tm) but I don't know
>> if code that creates new device classes would be accepted. Is there
>> another solution to put the control files in? Maybe under
>> /sys/class/gpio?
> Look into the IIO api, it should fit into there somewhere.  And if not,
> that api can easily be extended to do so.
I will do so.
>> *) I've filled out the parent device field in
>> device_create_with_groups() to NULL, I'm not sure if this
>> is right.
> You are correct, it isn't :)
>
>> If I put a parent, should it be the GPIO device (the HC_SRO4 is
>> attached to two GPIO pins)?
> Yes, you want your device to show up properly in the device heiarachy
> for all of the suspend/resume and other good things that the driver core
> gives you for free.
So I will choose one of the GPIO pins as parent..
>> *) When I submit the patch, I've read that one should cc the maintainers
>> (that would be Arnd Bergmann  and Greg Kroah-Hartman
>> ) but on what list should
>> I post the patch at all? Is it lkml.org?
> Use scripts/get_maintainer.pl on your patch to determine this, it
> figures it out for you automagically.
>
>> Please let me know if it ok to post the patch to this list first.
> Sure, feel free to, it's always good to see code on this list :)
>
> Hope this helps,
Indeed it does. Thank you for your quick reply. I will post to this list
what I have now, with the promise to fix it it the next few days.
> greg k-h
- johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: HC-SRO4 ultrasonic distance driver

[Greg KH]

On Thu, Mar 24, 2016 at 11:38:45AM +0100, Johannes Thoma wrote:
> Hi all,
> 
> I wrote a driver for the popular HC-SRO4 ultrasonic distance sensor. It 
> is beta and has been tested
> on the Raspberry PI by me and my brother: here is the stand-alone repo:
> 
> https://github.com/johannesthoma/linux-hc-sro4
> 
> I would like to contribute it to the linux kernel, however I am a little 
> bit nervous reading through
> the Documentation/Submitting[Patches][Drivers] documentation (in 
> particular the How to piss off
> a kernel developer sections ;)

Don't be scared, we don't bite :)

> , so I wanted to ask if I could post the 
> patch (it will be against the
> char/mics device kernel tree at 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> , I think this is the correct location) on this list first, maybe 
> someone can tell me if the formatting
> and the driver are correct..

Formatting of the code itself, or the patch?

> I also have some driver specific questions:
> 
> *) First, does it really belong to drivers/misc ? There are other 
> sensors there as well, so I suppose
> this location is right.

Probably not, if this is a sensor, it should be interacting with the IIO
layer, and not just using "random" sysfs files.

> *) As of now, I've created a new device class "distance" where the sysfs 
> control files live in (so the configuration file is
> /sys/class/distance/configure ), it works for me (tm) but I don't know
> if code that creates new device classes would be accepted. Is there
> another solution to put the control files in? Maybe under
> /sys/class/gpio?

Look into the IIO api, it should fit into there somewhere.  And if not,
that api can easily be extended to do so.

> *) I've filled out the parent device field in 
> device_create_with_groups() to NULL, I'm not sure if this
> is right.

You are correct, it isn't :)

> If I put a parent, should it be the GPIO device (the HC_SRO4 is
> attached to two GPIO pins)?

Yes, you want your device to show up properly in the device heiarachy
for all of the suspend/resume and other good things that the driver core
gives you for free.

> *) When I submit the patch, I've read that one should cc the maintainers 
> (that would be Arnd Bergmann  and Greg Kroah-Hartman 
> ) but on what list should
> I post the patch at all? Is it lkml.org?

Use scripts/get_maintainer.pl on your patch to determine this, it
figures it out for you automagically.

> Please let me know if it ok to post the patch to this list first.

Sure, feel free to, it's always good to see code on this list :)

Hope this helps,

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

HC-SRO4 ultrasonic distance driver

[Johannes Thoma]

Hi all,

I wrote a driver for the popular HC-SRO4 ultrasonic distance sensor. It 
is beta and has been tested
on the Raspberry PI by me and my brother: here is the stand-alone repo:

https://github.com/johannesthoma/linux-hc-sro4

I would like to contribute it to the linux kernel, however I am a little 
bit nervous reading through
the Documentation/Submitting[Patches][Drivers] documentation (in 
particular the How to piss off
a kernel developer sections ;), so I wanted to ask if I could post the 
patch (it will be against the
char/mics device kernel tree at 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
, I think this is the correct location) on this list first, maybe 
someone can tell me if the formatting
and the driver are correct..

I also have some driver specific questions:

*) First, does it really belong to drivers/misc ? There are other 
sensors there as well, so I suppose
this location is right.

*) As of now, I've created a new device class "distance" where the sysfs 
control files live in (so
the configuration file is /sys/class/distance/configure ), it works for 
me (tm) but I don't know
if code that creates new device classes would be accepted. Is there 
another solution to put
the control files in? Maybe under /sys/class/gpio?

*) I've filled out the parent device field in 
device_create_with_groups() to NULL, I'm not sure if this
is right. If I put a parent, should it be the GPIO device (the HC_SRO4 
is attached to two GPIO pins)?

*) When I submit the patch, I've read that one should cc the maintainers 
(that would be Arnd Bergmann  and Greg Kroah-Hartman 
) but on what list should
I post the patch at all? Is it lkml.org?

Please let me know if it ok to post the patch to this list first.

Thanks a lot,

- Johannes

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies