Re: Question about pressure sensor driver data processing

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Tue, 18 Feb 2020 15:59:26 +0000
Jean-Baptiste Maneyrol <JManeyrol@invensense.com> wrote:

> Hello,
> 
> I have a question concerning a pressure sensor driver I am currently
> writing.
> 
> The formula to get the real pressure in Pa for this sensor is quite
> complex. It depends on the measured temperature and would be far
> better done in floats rather than in integers.
> 
> The formula is too complex to be expressed with only scale and offset
> factors. And the factors are not fixed since it depends on the
> temperature.
> 
> Would it be acceptable to have a driver than returns the raw data
> without processing? Meaning data that have no unit and require a
> processing done in userspace? That would be much more efficient for
> sure, but it would not output really useful data without the
> processing.

Whilst it isn't nice, we have examples where this is already the case.
The heart rate sensors are similar in that they have very complex
conversions.

It is certainly better than being unable to support the driver at all,
but it does mean you won't ever be able to use it with generic code.

Generic code tends to assume the scale is constant as well, so probably
wouldn't work anyway :)

> 
> Or a driver that return an input processed data and a raw data that
> have no unit and requires the processing? If we can return raw data,
> we should be able also to add buffer/trigger support to the driver.
> Otherwise that would be quite tricky to return the processed data in
> the buffer.

Hmm. It is messy so if you actually expect to add buffered support, then
we will need special code in userspace for this device anyway.
We do have devices that jump through a complex conversion then pack
it into a buffer, but that is also somewhat of a hack.

For now at least, go with the raw output only.  It may be one of those
exceptions where we do support both processed and raw outputs in the
longer term if there is clear need for generic code with this device.

Jonathan
> 
> Thanks for your feedback.
> JB