[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75Ve4ZjOsi_MYru_fDB+dsGie6RxXVSuYPQmW_YHLjgA10A@mail.gmail.com>
Date: Mon, 13 Jun 2022 18:52:33 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Andrea Merello <andrea.merello@....it>
Cc: Jonathan Cameron <jic23@...nel.org>,
Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
linux-iio <linux-iio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Rob Herring <robh+dt@...nel.org>,
Matt Ranostay <matt.ranostay@...sulko.com>,
Alexandru Ardelean <ardeleanalex@...il.com>,
jmondi <jacopo@...ndi.org>
Subject: Re: [v6 12/14] iio: imu: add BNO055 serdev driver
On Mon, Jun 13, 2022 at 2:05 PM <andrea.merello@....it> wrote:
>
> From: Andrea Merello <andrea.merello@....it>
>
> Add a serdev driver for communicating to a BNO055 IMU via serial bus, and
> enable the BNO055 core driver to work in this scenario.
...
> + * This driver is besed on
based
> + * Plantower PMS7003 particulate matter sensor driver
> + * Which is
> + * Copyright (c) Tomasz Duszynski <tduszyns@...il.com>
...
> +/*
> + * Read operation overhead:
> + * 4 bytes req + 2byte resp hdr.
> + * 6 bytes = 60 bit (considering 1start + 1stop bits).
> + * 60/115200 = ~520uS + about 2500mS dealay -> ~3mS
delay
> + * In 3mS we could read back about 34 bytes that means 17 samples, this means
> + * that in case of scattered read in which the gap is 17 samples or less it is
reads
> + * still convenient to go for a burst.
> + * We have to take into account also IMU response time - IMU seems to be often
> + * reasonably quick to respond, but sometimes it seems to be in some "critical
> + * section" in which it delays handling of serial protocol. Because of this we
> + * round-up to 22, which is the max number of samples, always bursting indeed.
> + */
...
> +/*
> + * Sends a read or write command.
Send
...
> +/*
> + * Handler for received data; this is called from the reicever callback whenever
receiver
> + * it got some packet from the serial bus. The status tell us whether the
tells
> + * packet is valid (i.e. header ok && received payload len consistent wrt the
> + * header). It's now our responsability to check whether this is what we
responsibility
> + * expected, of whether we got some unexpected, yet valid, packet.
> + */
...
> + /*
> + * New packet.
> + * Check for its 1st byte, that identifies the pkt type.
byte that
> + */
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists