On Wed, Feb 19, 2020 at 10:38 AM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > 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. Don't forget the chemicals sensors that depend on temperature as well. Although to be fair most of those take input into the 'sensor hub' to do the calculations in their black box. - Matt > > 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 >
