Re: [PATCH] misc devices: HC-SRO4 ultrasonic distance driver
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
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
From 56e8f71c990b92c28a8cb03d859880eab8d06a3d Mon Sep 17 00:00:00 2001 From: Johannes ThomaDate: 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
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 Bergmannand 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
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 Bergmannand 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
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 Bergmannand 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