Hi Jonathan, I will send first a generic driver returning processed pressure data and raw temperature data and without any buffer/trigger support. I think this is the most valuable features for this driver. Afterward, I am interested to add buffer support using hrtimer trigger. Thanks for your feedback. JB From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> Sent: Wednesday, February 19, 2020 19:38 To: Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx> Cc: linux-iio <linux-iio@xxxxxxxxxxxxxxx> Subject: Re: Question about pressure sensor driver data processing CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, 18 Feb 2020 15:59:26 +0000 Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx> 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
