Hi,
Vlad Dogaru has posted submission "[RFC PATCH] iio: imu: add driver for Bosch Sensortec BNO055"
to linux-iio ML. Great thanks to him.
Am 24.06.2016 um 13:51 schrieb Andrey Utkin andrey_utkin@fastmail.com:
Hi,
Vlad Dogaru has posted submission "[RFC PATCH] iio: imu: add driver for Bosch Sensortec BNO055"
to linux-iio ML. Great thanks to him.
Great news!
Is there some easy way to find these patches for download? The ML isn't found on patchwork.kernel.org and people don't copy to LKML.
And/or is there a git repo to pull his patches?
BR and thanks for the notice, Nikolaus
On Fri, Jun 24, 2016 at 11:28:24PM +0200, H. Nikolaus Schaller wrote:
Great news!
Is there some easy way to find these patches for download? The ML isn't found on patchwork.kernel.org and people don't copy to LKML.
And/or is there a git repo to pull his patches?
I have forwarded the patch emails to you personally. I hope it haven't got garbled.
Also this happens to work even though it wasn't posted to the LKML:
https://lkml.kernel.org/ https://lkml.kernel.org/r/1466766936-20561-2-git-send-email-vlad.dogaru@inte... https://lkml.kernel.org/g/1466766936-20561-2-git-send-email-vlad.dogaru@inte...
Hi Andrey and Vlad,
Am 25.06.2016 um 13:22 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Fri, Jun 24, 2016 at 11:28:24PM +0200, H. Nikolaus Schaller wrote:
Great news!
Is there some easy way to find these patches for download? The ML isn't found on patchwork.kernel.org and people don't copy to LKML.
And/or is there a git repo to pull his patches?
I have forwarded the patch emails to you personally. I hope it haven't got garbled.
Oh, great! Did work :) And compiles :) :)
First observation: DT support seems to be incomplete (table with .compatible strings is missing). Here is a patch:
http://git.goldelico.com/?p=gta04-kernel.git;a=patch;h=f71d03191d21a93d9be45... http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f71d03191d21a93d9be4...
And here is my first test result on real hardware:
root@letux:~# dmesg|fgrep bno [ 6.990535] driver_register 'bno055' [ 6.995824] bno055 2-0029: failed to read operation mode, falling back to accel+gyro [ 7.022921] bno055 2-0029: software revision id 0308
root@letux:~# ./findiio -a bme280 bno055 palmas-gpadc bmg160 tsc2007 root@letux:~# ./findiio bno055 /sys/bus/iio/devices/iio:device1 root@letux:~# ls -l /sys/bus/iio/devices/iio:device1/ total 0 -r--r--r-- 1 root root 4096 Jan 1 00:01 dev -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_scale -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_x_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_x_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_y_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_y_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_z_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_z_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_scale -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_x_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_x_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_y_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_y_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_z_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_z_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_temp_input -r--r--r-- 1 root root 4096 Jan 1 00:01 name lrwxrwxrwx 1 root root 0 Jan 1 00:01 of_node -> ../../../../../../../firmware/devicetree/base/ocp/i2c@48060000/bno055@29 drwxr-xr-x 2 root root 0 Jan 1 00:01 power lrwxrwxrwx 1 root root 0 Jan 1 00:01 subsystem -> ../../../../../../../bus/iio -rw-r--r-- 1 root root 4096 Jan 1 00:01 uevent root@letux:~# root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw -68 117 966 root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw -66 116 968
again, after rotating PCB by 90 degrees:
root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw 946 0 -105 root@letux:~#
So the driver (and the BNO chip) is doing something useful :)
Also this happens to work even though it wasn't posted to the LKML:
https://lkml.kernel.org/ https://lkml.kernel.org/r/1466766936-20561-2-git-send-email-vlad.dogaru@inte... https://lkml.kernel.org/g/1466766936-20561-2-git-send-email-vlad.dogaru@inte...
Well, I had found similar pages, but it is very difficult to convert such web content into a correct .patch file :(
Only patchwork.kernel.org has a nice "download mbox / patch", but it needs to be listed there...
Anyways it did work and I hope this driver will appear in linux-next soon.
BR and thanks, Nikolaus
Hi Nikolaus, Andrey,
On Sat, Jun 25, 2016 at 06:50:44PM +0200, H.Nikolaus Schaller wrote:
Hi Andrey and Vlad,
Am 25.06.2016 um 13:22 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Fri, Jun 24, 2016 at 11:28:24PM +0200, H. Nikolaus Schaller wrote:
Great news!
Is there some easy way to find these patches for download? The ML isn't found on patchwork.kernel.org and people don't copy to LKML.
And/or is there a git repo to pull his patches?
Gmane has a useful download-as-mbox interface. When I need an mbox from a patch I browse the web interface, in this case http://news.gmane.org/gmane.linux.kernel.iio, grab the patch number, then head over to http://download.gmane.org.
In this case, you can get the patch at http://download.gmane.org/gmane.linux.kernel.iio/24644/24645 and use git am to apply it.
I have forwarded the patch emails to you personally. I hope it haven't got garbled.
Oh, great! Did work :) And compiles :) :)
First observation: DT support seems to be incomplete (table with .compatible strings is missing). Here is a patch:
http://git.goldelico.com/?p=gta04-kernel.git;a=patch;h=f71d03191d21a93d9be45... http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f71d03191d21a93d9be4...
My setup (which admittedly is not a real board, just an I2C-USB bridge and the sensor) works fine without the explicit DT bindings because i2c enumeration probes the device. But if you need this, I will add it in the next iteration of the patches, thanks for pointing it out.
And here is my first test result on real hardware:
root@letux:~# dmesg|fgrep bno [ 6.990535] driver_register 'bno055' [ 6.995824] bno055 2-0029: failed to read operation mode, falling back to accel+gyro [ 7.022921] bno055 2-0029: software revision id 0308
root@letux:~# ./findiio -a bme280 bno055 palmas-gpadc bmg160 tsc2007 root@letux:~# ./findiio bno055 /sys/bus/iio/devices/iio:device1 root@letux:~# ls -l /sys/bus/iio/devices/iio:device1/ total 0 -r--r--r-- 1 root root 4096 Jan 1 00:01 dev -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_scale -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_x_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_x_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_y_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_y_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_z_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_z_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_scale -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_x_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_x_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_y_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_y_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_z_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_z_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_temp_input -r--r--r-- 1 root root 4096 Jan 1 00:01 name lrwxrwxrwx 1 root root 0 Jan 1 00:01 of_node -> ../../../../../../../firmware/devicetree/base/ocp/i2c@48060000/bno055@29 drwxr-xr-x 2 root root 0 Jan 1 00:01 power lrwxrwxrwx 1 root root 0 Jan 1 00:01 subsystem -> ../../../../../../../bus/iio -rw-r--r-- 1 root root 4096 Jan 1 00:01 uevent root@letux:~# root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw -68 117 966 root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw -66 116 968
again, after rotating PCB by 90 degrees:
root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw 946 0 -105 root@letux:~#
So the driver (and the BNO chip) is doing something useful :)
That's good to know :)
Also this happens to work even though it wasn't posted to the LKML:
https://lkml.kernel.org/ https://lkml.kernel.org/r/1466766936-20561-2-git-send-email-vlad.dogaru@inte... https://lkml.kernel.org/g/1466766936-20561-2-git-send-email-vlad.dogaru@inte...
Well, I had found similar pages, but it is very difficult to convert such web content into a correct .patch file :(
Only patchwork.kernel.org has a nice "download mbox / patch", but it needs to be listed there...
Anyways it did work and I hope this driver will appear in linux-next soon.
It looks like merging this won't be straightforward because of the different operation modes that the device supports. You might want to follow the discussion on the mailing list.
Thanks, Vlad
Hi Vlad,
Am 27.06.2016 um 10:49 schrieb Vlad Dogaru vlad.dogaru@intel.com:
Hi Nikolaus, Andrey,
On Sat, Jun 25, 2016 at 06:50:44PM +0200, H.Nikolaus Schaller wrote:
Hi Andrey and Vlad,
Am 25.06.2016 um 13:22 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Fri, Jun 24, 2016 at 11:28:24PM +0200, H. Nikolaus Schaller wrote:
Great news!
Is there some easy way to find these patches for download? The ML isn't found on patchwork.kernel.org and people don't copy to LKML.
And/or is there a git repo to pull his patches?
Gmane has a useful download-as-mbox interface. When I need an mbox from a patch I browse the web interface, in this case http://news.gmane.org/gmane.linux.kernel.iio, grab the patch number, then head over to http://download.gmane.org.
In this case, you can get the patch at http://download.gmane.org/gmane.linux.kernel.iio/24644/24645 and use git am to apply it.
Ah, that is a nice trick. Quite hidden but helpful!
I have forwarded the patch emails to you personally. I hope it haven't got garbled.
Oh, great! Did work :) And compiles :) :)
First observation: DT support seems to be incomplete (table with .compatible strings is missing). Here is a patch:
http://git.goldelico.com/?p=gta04-kernel.git;a=patch;h=f71d03191d21a93d9be45... http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f71d03191d21a93d9be4...
My setup (which admittedly is not a real board, just an I2C-USB bridge and the sensor) works fine without the explicit DT bindings because i2c enumeration probes the device. But if you need this, I will add it in the next iteration of the patches, thanks for pointing it out.
Yes, would be nice to have since we have the bno055 connected to some SoC I2C bus.
And here is my first test result on real hardware:
root@letux:~# dmesg|fgrep bno [ 6.990535] driver_register 'bno055' [ 6.995824] bno055 2-0029: failed to read operation mode, falling back to accel+gyro [ 7.022921] bno055 2-0029: software revision id 0308
root@letux:~# ./findiio -a bme280 bno055 palmas-gpadc bmg160 tsc2007 root@letux:~# ./findiio bno055 /sys/bus/iio/devices/iio:device1 root@letux:~# ls -l /sys/bus/iio/devices/iio:device1/ total 0 -r--r--r-- 1 root root 4096 Jan 1 00:01 dev -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_scale -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_x_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_x_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_y_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_y_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_z_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_accel_z_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_scale -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_x_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_x_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_y_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_y_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_z_offset -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_anglvel_z_raw -rw-r--r-- 1 root root 4096 Jan 1 00:01 in_temp_input -r--r--r-- 1 root root 4096 Jan 1 00:01 name lrwxrwxrwx 1 root root 0 Jan 1 00:01 of_node -> ../../../../../../../firmware/devicetree/base/ocp/i2c@48060000/bno055@29 drwxr-xr-x 2 root root 0 Jan 1 00:01 power lrwxrwxrwx 1 root root 0 Jan 1 00:01 subsystem -> ../../../../../../../bus/iio -rw-r--r-- 1 root root 4096 Jan 1 00:01 uevent root@letux:~# root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw -68 117 966 root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw -66 116 968
again, after rotating PCB by 90 degrees:
root@letux:~# cat /sys/bus/iio/devices/iio:device1/in_accel_*_raw 946 0 -105 root@letux:~#
So the driver (and the BNO chip) is doing something useful :)
That's good to know :)
Also this happens to work even though it wasn't posted to the LKML:
https://lkml.kernel.org/ https://lkml.kernel.org/r/1466766936-20561-2-git-send-email-vlad.dogaru@inte... https://lkml.kernel.org/g/1466766936-20561-2-git-send-email-vlad.dogaru@inte...
Well, I had found similar pages, but it is very difficult to convert such web content into a correct .patch file :(
Only patchwork.kernel.org has a nice "download mbox / patch", but it needs to be listed there...
Anyways it did work and I hope this driver will appear in linux-next soon.
It looks like merging this won't be straightforward because of the different operation modes that the device supports. You might want to follow the discussion on the mailing list.
Well, for my part (as hardware developer) I am happy with any mode since I have only to prove that the chip is working and responds.
But user space developers might want to do fancy things and need different modes.
Perhaps it could be wise to merge it anyways as a basis and after some experience it may become more clear what a better and more general setup could be. So step back from a "do it right the first time" approach towards and evolution.
BR and thanks, Nikolaus
PS: there is a user-space driver provided by Bosch: https://github.com/BoschSensortec/BNO055_driver