Re: GSoC Proposal 2022

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

On Tue, 12 Apr 2022 14:06:21 +0200
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Tue, 2022-04-12 at 11:48 +0300, Andy Shevchenko wrote:
> > On Tue, Apr 12, 2022 at 10:43 AM Maíra Canal <maira.canal@usp.br>
> > wrote:  
> > > On 04/11, Jonathan Cameron wrote:  
> > 
> > ...
> >   
> > > I took another look at the Analog Devices Inc. catalog and choose
> > > another
> > > couple of options:
> > > 
> > >     - ADPD188BI and ADPD410x: are optical devices based on SPI/I2C.
> > > I guess they
> > >     might be too bold for a GSoC project.
> > >     - MAX31875: is a Temperature Sensor based on I2C. Different
> > > than the optical
> > >     devices, this one might be too simple.  
> >   
> > >     - LTC2499: is a multiplexed ADC sensor. For now, it is my best
> > > option.  
> > 
> > Have you checked if it has similarities to 2496 and 2497 variants? We
> > already have drivers for those, it makes sense to double check.
> >   
> 
> Yeah, after a quick look on the datasheet, they look very similar...
> 
> The MAX31875 looks to be a fairly simple one (maybe a good candidate
> for a first driver) but, IMO, having it in IIO boils down to have
> support for continuos mode which would mean triggered buffer support.
> 
> And this brings me to something that already crossed my mind...
> Jonathan, would it make sense to be able to change the trigger
> "sampling frequency" depending on some device configuration? In this
> case, if we want to have continous mode, I guess a hrtimer trigger
> would be, for example, one good candidate of a trigger to attach.
> And, as we can have different SPS, we would want to have the trigger
> fireing depending on that... This could also be an additional "task"
> for you (if it makes sense of course).

In this case what defines the SPS? 
Various things that sort of fit this description have come up.
* sensor self clocking but not providing an interrupt or similar, for these
  it is odd enough that you normally need a dedicated kernel thread to try
  and get the timing right.
* characteristic of configuration filters etc.  In theory you can
  grab readings from the device quicker than the filter supports, but
  you will run into issues with quality of the output.  For these
  we've traditionally made it a userspace problem...
* Sensor that has a 'specified' sample rate (perhaps due to some filtering
  or need for downtime between readings?)  For this I'd be tempted to
  provide the info to userspace and let that be responsible for not
  running a trigger faster.
* Sensor that runs flat out and we just want to trigger it repeatedly so
  we start a new capture after last one finishes.  For these we have the
  horibble hack which is the loop trigger (it's my hack ;)



> 
> All the above said, if we do not support continuous mode, this device
> also falls nicely in the hwmon domain (with all the hyst and over
> temperature stuff).

Agreed. It's fairly slow so can't really argue pushing the data through
a buffer is worthwhile and it's a low precision sensor.
So this one belongs in hwmon. Without reading datasheet I'm not
sure but I'd look at whether it's easy to bolt into the lm75 driver.


> 
> The ADPD188BI looks to be more complicated which might be too much for
> GSOC? Not sure here... That said, it looks like you can have some fun
> with it.
> 
> - Nuno Sá
>