linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Vlad Dogaru <vlad.dogaru@intel.com>,
	knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
	linux-iio@vger.kernel.org
Cc: andrey_utkin@fastmail.com
Subject: Re: [RFC PATCH] iio: imu: add driver for Bosch Sensortec BNO055
Date: Sun, 26 Jun 2016 19:03:14 +0100	[thread overview]
Message-ID: <bc97ba4f-128a-b220-9f42-87e5a4ee90f3@kernel.org> (raw)
In-Reply-To: <0fb507e2-e936-9c0c-9148-e4e329ba9dcb@kernel.org>

On 26/06/16 18:56, Jonathan Cameron wrote:
> On 24/06/16 12:15, Vlad Dogaru wrote:
>> Hi everyone,
>>
>> This is a minimal implementation of a driver for the Bosch Sensortec
>> BNO055, a very interesting accel-gyro-magneto combo.  The datasheet is
>> available at https://www.bosch-sensortec.com/bst/products/all_products/bno055
> 'interesting' device indeed.
>>
>> The driver in its present state works, but this is a RFC for a few
>> reasons detailed below:
>>
>> (1) The device has a few possible operating modes.  The most simple
>> ones employ a single sensor and power down the other two; the most
>> complex use all 3 for sensor fusion.  Changing the mode at runtime would
>> require changing the channels and I'm not sure IIO allows that.
> It allows a much greater set of channels than can run at one time though..
> Would that work here?  Lots of fun with available_scan_masks and
> friends, but from your description here sounds fine (will look at
> the code in a minute).
>>  So I've
>> opted to choose the mode at probe time, based on a DeviceTree property.
>> Hope that's ok.
> Would rather it was runtime controllable I think...
Hmm. I can see this is complex because obviously the fusion has to start
at some point and if we flipped to reading a single axis it would get
turned off.

Hideous though it is, perhaps an 'enable_fusion_engine' attribute would
be the way to do it with channels returning EBUSY if they are not available
in a given mode.

There are some precedents for this as there are parts that cannot
do both events and raw data reading at the same time. e.g. the Max1363
(well technically that part can, but it was so nasty to implement I never
did it an no one has ever cared since).

We could only enable the fusion engine once the buffer is enabled, but
that seems a bit clunky given the fused data is in someways the most
useful stuff to get via polled reads.  'What orientation am I at now?'

I'm definitely looking for other opinions on this one!  

Jonathan
>>
>> (2) Fusion modes provide orientation data.  This is either relative to
>> the initial position of the sensor, or to magnetic North.
> Something new :)
>>  There is a
>> modifier, IIO_MOD_NORTH_MAGN,
> I'm trying to remember why we have that...  Ah, just checked docs, it
> was for devices that offered planar rotation angles from north.
>> but it occupies the same field as
>> IIO_MOD_QUATERNION 
> With hindsight we should probably have made that a new channel type
> rather than trying to mash it into the rotation type.  Perhaps doing
> that now is the way to go and adding the interface to the hid sensor
> device driver that is the only user (keeping the old option as well
> for compatibility reasons).
> 
>> and IIO_MOD_{X,Y,Z}, so we can't use both.
> This is kind of related to mounting matrix, be it a 'world mounting matrix'.
> I wonder if we want to support it in a vaguely similar way...
> 
>   Therefore
>> there is currently no means of telling from user space whether the
>> orientation is relative to North or to the initial position;  one could
>> look at the DeviceTree description to deduce the operating mode, but
>> that's hardly ideal.
> Absolutely, this one needs to be exposed in userspace.
> 
> Is there a means of resetting the initial position at runtime?
> Providing an attribute to do that might be the cleanest option if
> so. Not sure if there are any benefits to picking the initial value
> against the north one otherwise...
>>
>> (3) In fusion modes, the device also exposes linear and gravitational
>> accelerations, but IIO doesn't seem to support this.  I can add these
>> channel types if you believe they are useful.
> 
> They will indeed have to be new channel types as you suggest, though
> 'linear' is a rather unclear name to my mind.
> 
>>
>>
>> Vlad Dogaru (1):
>>   iio: imu: add driver for Bosch Sensortec BNO055
>>
>>  drivers/iio/imu/Kconfig  |  11 +
>>  drivers/iio/imu/Makefile |   1 +
>>  drivers/iio/imu/bno055.c | 569 +++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 581 insertions(+)
>>  create mode 100644 drivers/iio/imu/bno055.c
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2016-06-26 18:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 11:15 [RFC PATCH] iio: imu: add driver for Bosch Sensortec BNO055 Vlad Dogaru
2016-06-24 11:15 ` Vlad Dogaru
2016-06-26 18:09   ` Jonathan Cameron
2016-06-26 17:56 ` Jonathan Cameron
2016-06-26 18:03   ` Jonathan Cameron [this message]
2016-06-27  9:14     ` Vlad Dogaru
2016-06-27 18:53       ` Jonathan Cameron
2016-06-27 13:31   ` Vlad Dogaru
2016-07-03  9:35     ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc97ba4f-128a-b220-9f42-87e5a4ee90f3@kernel.org \
    --to=jic23@kernel.org \
    --cc=andrey_utkin@fastmail.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=vlad.dogaru@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).