Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: "Andres Heinloo" <andres@gfz-potsdam.de>
Cc: "Jonathan Cameron" <Jonathan.Cameron@Huawei.com>,
	"Eddie James" <eajames@linux.ibm.com>,
	linux-iio@vger.kernel.org
Subject: Re: Bugs in dps310 Linux driver
Date: Sat, 4 Mar 2023 17:06:20 +0000	[thread overview]
Message-ID: <20230304170620.795f4d99@jic23-huawei> (raw)
In-Reply-To: <web-1200302@cgp-be2-mgmt.gfz-potsdam.de>

On Fri, 03 Mar 2023 12:10:00 +0100
"Andres Heinloo" <andres@gfz-potsdam.de> wrote:

> Hello,
> 
> I've been struggling with the dps310 driver, which gives incorrect 
> pressure values and in particular different values than manufacturers 
> code (https://github.com/Infineon/RaspberryPi_DPS).
> 
> I think I've found where the problem is. Firstly, there is a mistake 
> in bit numbering at 
> https://github.com/torvalds/linux/blob/857f1268a591147f7be7509f249dbb3aba6fc65c/drivers/iio/pressure/dps310.c#L51
> 
> According to datasheet, correct is:
> 
> #define  DPS310_INT_HL          BIT(7)
> #define  DPS310_TMP_SHIFT_EN    BIT(3)
> #define  DPS310_PRS_SHIFT_EN    BIT(2)
> #define  DPS310_FIFO_EN         BIT(1)
> #define  DPS310_SPI_EN          BIT(0)
> 
> Eg., the current code is using wrong bit (4) for DPS310_PRS_SHIFT_EN, 
> which means that pressure shift is never enabled.

Checking the datasheet, seems like you are right.
https://www.infineon.com/dgdl/Infineon-DPS310-DataSheet-v01_02-EN.pdf?fileId=5546d462576f34750157750826c42242
Section 7: 

Though that's not the only bit that is wrong.  Looks like FIFO enable is as well.
So any fix should deal with that as well.

The differences between the register map and the datasheet I'm looking at make
me think that perhaps the driver was developed against a prototype part.
The registers are in a different order for starters with the B0, B1 and B2
sets in reverse order.  Any fix patch should tidy that up as well.


> 
> Secondly, there is a problem with overflows starting at 
> https://github.com/torvalds/linux/blob/857f1268a591147f7be7509f249dbb3aba6fc65c/drivers/iio/pressure/dps310.c#L654
> 
> Since p is a 24-bit value,
> 
> nums[3] = p * p * p * (s64)data->c30;
> 
> can and does overflow.

Makes sense, though I can't immediately see a good solution as we need
to maintain the remainder part.

> 
> Second overflow problem is at 
> https://github.com/torvalds/linux/blob/857f1268a591147f7be7509f249dbb3aba6fc65c/drivers/iio/pressure/dps310.c#L684
> 
> In fact, I don't understand why 1000000000LL is needed. Since only 7 
> values are summed, using 10LL should give the same precision.
Whilst the existing  value seems large - I'm not great with precision calcs so could
you lay out why 10LL is sufficient?


> 
> Best regards,
> Andres


  reply	other threads:[~2023-03-04 17:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 11:10 Bugs in dps310 Linux driver Andres Heinloo
2023-03-04 17:06 ` Jonathan Cameron [this message]
2023-03-05  2:05   ` Andres Heinloo
2023-03-06 21:15     ` Andres Heinloo
2023-03-12 15:43       ` Jonathan Cameron
2023-03-13 16:36         ` Andres Heinloo
2023-03-18 17:09           ` Jonathan Cameron
2023-03-19 14:24             ` Andres Heinloo
2023-03-12 15:46     ` 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=20230304170620.795f4d99@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=andres@gfz-potsdam.de \
    --cc=eajames@linux.ibm.com \
    --cc=linux-iio@vger.kernel.org \
    /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