GSoC Proposal 2022

GSoC Proposal 2022

[Maíra Canal]

Hi everyone, I am Maíra Canal an undergrad student at the University
of São Paulo, Brazil, pursuing
computer engineering. I wish to participate in the GSoC 2021 as a part
of the Linux Foundation, IIO Project.

I have been contributing to the Linux kernel for a couple of months
and have more than 20
accepted patches in a couple of subsystems.

I started looking through the catalog of Analog Devices Inc. and I'm
pretty interested in writing a driver for gyroscopes, inertial
measurement units (IMUs), magnetometers, pressure sensors, proximity
sensors, or temperature sensors. But, while looking through the
catalog, I could not figure out a sensor that would be relevant to
Linux Kernel. I mean, I would like to work on a sensor that would be
relevant to the community and to Analog Devices Inc.

In that sense, I would like to know if anyone in the IIO community
could recommend a sensor that would make sense for the company and the
IIO community. Any suggestion is appreciated!

Sincerely,
Maíra Canal

Re: GSoC Proposal 2022

[Jonathan Cameron]

On Thu, 7 Apr 2022 00:23:29 -0300
Maíra Canal <maira.canal@usp.br> wrote:

> Hi everyone, I am Maíra Canal an undergrad student at the University
> of São Paulo, Brazil, pursuing
> computer engineering. I wish to participate in the GSoC 2021 as a part
> of the Linux Foundation, IIO Project.

Hi Maíra,

Nice to 'meet' you ;)

> 
> I have been contributing to the Linux kernel for a couple of months
> and have more than 20
> accepted patches in a couple of subsystems.
> 
> I started looking through the catalog of Analog Devices Inc. and I'm
> pretty interested in writing a driver for gyroscopes, inertial
> measurement units (IMUs), magnetometers, pressure sensors, proximity
> sensors, or temperature sensors. But, while looking through the
> catalog, I could not figure out a sensor that would be relevant to
> Linux Kernel. I mean, I would like to work on a sensor that would be
> relevant to the community and to Analog Devices Inc.
> 
> In that sense, I would like to know if anyone in the IIO community
> could recommend a sensor that would make sense for the company and the
> IIO community. Any suggestion is appreciated!

I'm not going to recommend a particular sensor, but more offer some general
tips on what 'sort' of device makes a good target for a GSOC.
Finding a sensor means trawling datasheets and I'm tight on time today
+ I've no real insight into what the ADI folk might like to see
supported!

The nature of a GSOC driver submission is often a little different to
how an experienced driver author might go about things, simply because you
will / should be looking for feedback at more stages of development and
hopefully to upstream things in multiple stages.  An old hand at IIO
drivers will often just jump directly to a driver supporting all the
features they wish to target.  As such, the 'perfect' device to target
should meet a few requirements that may not be true for the approach of jumping
straight to the end goal.  Note this is equally true for other people
starting out writing drivers - though they can often do very simple
devices first and that is not a good plan for a GSOC project where
you need to have a progression during the project.

Try to find something that offers some advanced features to provide
stretch goals but make sure the basic functionality will work with
a much simpler driver. So devices that provide straight forward
registers to access the latest channel value are great, whereas
those that only offer a streaming interfaces / fifo may be less suitable.
However if they offer both that is perfect as the fifo make a good
later feature for a GSOC project if things are going particularly
well!  For a real stretch goal, find a device with features that
we don't support at all today (perhaps new sensor types, or some
other new feature) as they'll give you the experience of defining
new ABI + possibly modifying the IIO core to meet some requirements.

Another thing to look at it is whether the part is sufficiently
different from those supported by existing drivers to justify a
separate driver. If not, you may find your GSOC project becomes
simply adding an ID! (then rapidly choosing a second device to
work on).

Hope that provides a few hints on what to look at.  Probably the best
way around is to suggest one or more parts you think look interesting
then we can give feedback on whether we think they'd be a good choice
or not.

Good luck!

Jonathan



> 
> Sincerely,
> Maíra Canal

Re: GSoC Proposal 2022

[Maíra Canal]

On 04/10, Jonathan Cameron wrote:
> On Thu, 7 Apr 2022 00:23:29 -0300
> Maíra Canal <maira.canal@usp.br> wrote:
> 
> > Hi everyone, I am Maíra Canal an undergrad student at the University
> > of São Paulo, Brazil, pursuing
> > computer engineering. I wish to participate in the GSoC 2021 as a part
> > of the Linux Foundation, IIO Project.
> 
> Hi Maíra,
> 
> Nice to 'meet' you ;)
> 
> > 
> > I have been contributing to the Linux kernel for a couple of months
> > and have more than 20
> > accepted patches in a couple of subsystems.
> > 
> > I started looking through the catalog of Analog Devices Inc. and I'm
> > pretty interested in writing a driver for gyroscopes, inertial
> > measurement units (IMUs), magnetometers, pressure sensors, proximity
> > sensors, or temperature sensors. But, while looking through the
> > catalog, I could not figure out a sensor that would be relevant to
> > Linux Kernel. I mean, I would like to work on a sensor that would be
> > relevant to the community and to Analog Devices Inc.
> > 
> > In that sense, I would like to know if anyone in the IIO community
> > could recommend a sensor that would make sense for the company and the
> > IIO community. Any suggestion is appreciated!
> 
> I'm not going to recommend a particular sensor, but more offer some general
> tips on what 'sort' of device makes a good target for a GSOC.
> Finding a sensor means trawling datasheets and I'm tight on time today
> + I've no real insight into what the ADI folk might like to see
> supported!
> 
> The nature of a GSOC driver submission is often a little different to
> how an experienced driver author might go about things, simply because you
> will / should be looking for feedback at more stages of development and
> hopefully to upstream things in multiple stages.  An old hand at IIO
> drivers will often just jump directly to a driver supporting all the
> features they wish to target.  As such, the 'perfect' device to target
> should meet a few requirements that may not be true for the approach of jumping
> straight to the end goal.  Note this is equally true for other people
> starting out writing drivers - though they can often do very simple
> devices first and that is not a good plan for a GSOC project where
> you need to have a progression during the project.
> 
> Try to find something that offers some advanced features to provide
> stretch goals but make sure the basic functionality will work with
> a much simpler driver. So devices that provide straight forward
> registers to access the latest channel value are great, whereas
> those that only offer a streaming interfaces / fifo may be less suitable.
> However if they offer both that is perfect as the fifo make a good
> later feature for a GSOC project if things are going particularly
> well!  For a real stretch goal, find a device with features that
> we don't support at all today (perhaps new sensor types, or some
> other new feature) as they'll give you the experience of defining
> new ABI + possibly modifying the IIO core to meet some requirements.
> 
> Another thing to look at it is whether the part is sufficiently
> different from those supported by existing drivers to justify a
> separate driver. If not, you may find your GSOC project becomes
> simply adding an ID! (then rapidly choosing a second device to
> work on).
> 
> Hope that provides a few hints on what to look at.  Probably the best
> way around is to suggest one or more parts you think look interesting
> then we can give feedback on whether we think they'd be a good choice
> or not.

Hi Jonathan,

I really appreciate the answer. Thank you for your attention and time!

During the week, I ended up picking the ADXL375 accelerometer (although I am
open to any change proposed by ADI or the IIO community). Based on that device,
I wrote a proposal and I would appreciate if you provide some feedback on the
device choice and proposal: https://pt.overleaf.com/read/xsmmdpvzqrhd.

Regards,
Maíra

> 
> Good luck!
> 
> Jonathan
> 
> 
> 
> > 
> > Sincerely,
> > Maíra Canal
> 

Re: GSoC Proposal 2022

[Jonathan Cameron]

On Sun, 10 Apr 2022 19:37:52 -0300
Maíra Canal <maira.canal@usp.br> wrote:

> On 04/10, Jonathan Cameron wrote:
> > On Thu, 7 Apr 2022 00:23:29 -0300
> > Maíra Canal <maira.canal@usp.br> wrote:
> >   
> > > Hi everyone, I am Maíra Canal an undergrad student at the University
> > > of São Paulo, Brazil, pursuing
> > > computer engineering. I wish to participate in the GSoC 2021 as a part
> > > of the Linux Foundation, IIO Project.  
> > 
> > Hi Maíra,
> > 
> > Nice to 'meet' you ;)
> >   
> > > 
> > > I have been contributing to the Linux kernel for a couple of months
> > > and have more than 20
> > > accepted patches in a couple of subsystems.
> > > 
> > > I started looking through the catalog of Analog Devices Inc. and I'm
> > > pretty interested in writing a driver for gyroscopes, inertial
> > > measurement units (IMUs), magnetometers, pressure sensors, proximity
> > > sensors, or temperature sensors. But, while looking through the
> > > catalog, I could not figure out a sensor that would be relevant to
> > > Linux Kernel. I mean, I would like to work on a sensor that would be
> > > relevant to the community and to Analog Devices Inc.
> > > 
> > > In that sense, I would like to know if anyone in the IIO community
> > > could recommend a sensor that would make sense for the company and the
> > > IIO community. Any suggestion is appreciated!  
> > 
> > I'm not going to recommend a particular sensor, but more offer some general
> > tips on what 'sort' of device makes a good target for a GSOC.
> > Finding a sensor means trawling datasheets and I'm tight on time today
> > + I've no real insight into what the ADI folk might like to see
> > supported!
> > 
> > The nature of a GSOC driver submission is often a little different to
> > how an experienced driver author might go about things, simply because you
> > will / should be looking for feedback at more stages of development and
> > hopefully to upstream things in multiple stages.  An old hand at IIO
> > drivers will often just jump directly to a driver supporting all the
> > features they wish to target.  As such, the 'perfect' device to target
> > should meet a few requirements that may not be true for the approach of jumping
> > straight to the end goal.  Note this is equally true for other people
> > starting out writing drivers - though they can often do very simple
> > devices first and that is not a good plan for a GSOC project where
> > you need to have a progression during the project.
> > 
> > Try to find something that offers some advanced features to provide
> > stretch goals but make sure the basic functionality will work with
> > a much simpler driver. So devices that provide straight forward
> > registers to access the latest channel value are great, whereas
> > those that only offer a streaming interfaces / fifo may be less suitable.
> > However if they offer both that is perfect as the fifo make a good
> > later feature for a GSOC project if things are going particularly
> > well!  For a real stretch goal, find a device with features that
> > we don't support at all today (perhaps new sensor types, or some
> > other new feature) as they'll give you the experience of defining
> > new ABI + possibly modifying the IIO core to meet some requirements.
> > 
> > Another thing to look at it is whether the part is sufficiently
> > different from those supported by existing drivers to justify a
> > separate driver. If not, you may find your GSOC project becomes
> > simply adding an ID! (then rapidly choosing a second device to
> > work on).
> > 
> > Hope that provides a few hints on what to look at.  Probably the best
> > way around is to suggest one or more parts you think look interesting
> > then we can give feedback on whether we think they'd be a good choice
> > or not.  
> 
> Hi Jonathan,
> 
> I really appreciate the answer. Thank you for your attention and time!
> 
> During the week, I ended up picking the ADXL375 accelerometer (although I am
> open to any change proposed by ADI or the IIO community). Based on that device,
> I wrote a proposal and I would appreciate if you provide some feedback on the
> device choice and proposal: https://pt.overleaf.com/read/xsmmdpvzqrhd.

Unfortunately that part hits the second to last paragraph above.

It's so nearly compatible with the ADXL345 that the driver already supports it:
https://elixir.bootlin.com/linux/v5.18-rc1/source/drivers/iio/accel/adxl345_i2c.c#L42
This is very common for these types of devices as there are often many similar
variants, usually with different ranges or with small additional features, or numbers
of interrupt pins etc.  Another fun one is parts with ratings for different applications
but identical software interfaces being given different part numbers.
I think in this case the two parts have different scaling, but are otherwise
identical.

So probably need to find another part.

Jonathan

> 
> Regards,
> Maíra
> 
> > 
> > Good luck!
> > 
> > Jonathan
> > 
> > 
> >   
> > > 
> > > Sincerely,
> > > Maíra Canal  
> >   

Re: GSoC Proposal 2022

[Jonathan Cameron]

On Mon, 11 Apr 2022 09:52:19 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Sun, 10 Apr 2022 19:37:52 -0300
> Maíra Canal <maira.canal@usp.br> wrote:
> 
> > On 04/10, Jonathan Cameron wrote:  
> > > On Thu, 7 Apr 2022 00:23:29 -0300
> > > Maíra Canal <maira.canal@usp.br> wrote:
> > >     
> > > > Hi everyone, I am Maíra Canal an undergrad student at the University
> > > > of São Paulo, Brazil, pursuing
> > > > computer engineering. I wish to participate in the GSoC 2021 as a part
> > > > of the Linux Foundation, IIO Project.    
> > > 
> > > Hi Maíra,
> > > 
> > > Nice to 'meet' you ;)
> > >     
> > > > 
> > > > I have been contributing to the Linux kernel for a couple of months
> > > > and have more than 20
> > > > accepted patches in a couple of subsystems.
> > > > 
> > > > I started looking through the catalog of Analog Devices Inc. and I'm
> > > > pretty interested in writing a driver for gyroscopes, inertial
> > > > measurement units (IMUs), magnetometers, pressure sensors, proximity
> > > > sensors, or temperature sensors. But, while looking through the
> > > > catalog, I could not figure out a sensor that would be relevant to
> > > > Linux Kernel. I mean, I would like to work on a sensor that would be
> > > > relevant to the community and to Analog Devices Inc.
> > > > 
> > > > In that sense, I would like to know if anyone in the IIO community
> > > > could recommend a sensor that would make sense for the company and the
> > > > IIO community. Any suggestion is appreciated!    
> > > 
> > > I'm not going to recommend a particular sensor, but more offer some general
> > > tips on what 'sort' of device makes a good target for a GSOC.
> > > Finding a sensor means trawling datasheets and I'm tight on time today
> > > + I've no real insight into what the ADI folk might like to see
> > > supported!
> > > 
> > > The nature of a GSOC driver submission is often a little different to
> > > how an experienced driver author might go about things, simply because you
> > > will / should be looking for feedback at more stages of development and
> > > hopefully to upstream things in multiple stages.  An old hand at IIO
> > > drivers will often just jump directly to a driver supporting all the
> > > features they wish to target.  As such, the 'perfect' device to target
> > > should meet a few requirements that may not be true for the approach of jumping
> > > straight to the end goal.  Note this is equally true for other people
> > > starting out writing drivers - though they can often do very simple
> > > devices first and that is not a good plan for a GSOC project where
> > > you need to have a progression during the project.
> > > 
> > > Try to find something that offers some advanced features to provide
> > > stretch goals but make sure the basic functionality will work with
> > > a much simpler driver. So devices that provide straight forward
> > > registers to access the latest channel value are great, whereas
> > > those that only offer a streaming interfaces / fifo may be less suitable.
> > > However if they offer both that is perfect as the fifo make a good
> > > later feature for a GSOC project if things are going particularly
> > > well!  For a real stretch goal, find a device with features that
> > > we don't support at all today (perhaps new sensor types, or some
> > > other new feature) as they'll give you the experience of defining
> > > new ABI + possibly modifying the IIO core to meet some requirements.
> > > 
> > > Another thing to look at it is whether the part is sufficiently
> > > different from those supported by existing drivers to justify a
> > > separate driver. If not, you may find your GSOC project becomes
> > > simply adding an ID! (then rapidly choosing a second device to
> > > work on).
> > > 
> > > Hope that provides a few hints on what to look at.  Probably the best
> > > way around is to suggest one or more parts you think look interesting
> > > then we can give feedback on whether we think they'd be a good choice
> > > or not.    
> > 
> > Hi Jonathan,
> > 
> > I really appreciate the answer. Thank you for your attention and time!
> > 
> > During the week, I ended up picking the ADXL375 accelerometer (although I am
> > open to any change proposed by ADI or the IIO community). Based on that device,
> > I wrote a proposal and I would appreciate if you provide some feedback on the
> > device choice and proposal: https://pt.overleaf.com/read/xsmmdpvzqrhd.  
> 
> Unfortunately that part hits the second to last paragraph above.
> 
> It's so nearly compatible with the ADXL345 that the driver already supports it:
> https://elixir.bootlin.com/linux/v5.18-rc1/source/drivers/iio/accel/adxl345_i2c.c#L42
> This is very common for these types of devices as there are often many similar
> variants, usually with different ranges or with small additional features, or numbers
> of interrupt pins etc.  Another fun one is parts with ratings for different applications
> but identical software interfaces being given different part numbers.
> I think in this case the two parts have different scaling, but are otherwise
> identical.
> 
> So probably need to find another part.
> 

I took a quick look at your proposal.  Main feedback is look to do more steps in
submission for upstream.  I'd look to post basic read / write via sysfs first
without the buffers or events.  Key here is that it can take several weeks
to get review (particularly during the summer as people can be on vacation)
so you want to have something available for review as early as possible.
It's absolutely fine to post a v2 with additional features even though v1 hasn't
gotten review yet. (just reply to v1 to say you have done so to avoid anyone
wasting time reviewing old code).

It might make sense to do a project focused on the adxl375 if the aim is
to fill in missing features in the driver.  However, that's high risk as
you may be posing questions that need considerable discussion on list.

Long ago we had one GSOC project that ran into such a problem and ended up
going in a circle with 3 different solutions proposed before we ended up
back where we started. Project was a success but I'd imagine it
was very stressful for the person doing the project!

Jonathan


> Jonathan
> 
> > 
> > Regards,
> > Maíra
> >   
> > > 
> > > Good luck!
> > > 
> > > Jonathan
> > > 
> > > 
> > >     
> > > > 
> > > > Sincerely,
> > > > Maíra Canal    
> > >     
> 

Re: GSoC Proposal 2022

[Maíra Canal]

On 04/11, Jonathan Cameron wrote:
> On Sun, 10 Apr 2022 19:37:52 -0300
> Maíra Canal <maira.canal@usp.br> wrote:
> 
> > On 04/10, Jonathan Cameron wrote:
> > > On Thu, 7 Apr 2022 00:23:29 -0300
> > > Maíra Canal <maira.canal@usp.br> wrote:
> > >   
> > > > Hi everyone, I am Maíra Canal an undergrad student at the University
> > > > of São Paulo, Brazil, pursuing
> > > > computer engineering. I wish to participate in the GSoC 2021 as a part
> > > > of the Linux Foundation, IIO Project.  
> > > 
> > > Hi Maíra,
> > > 
> > > Nice to 'meet' you ;)
> > >   
> > > > 
> > > > I have been contributing to the Linux kernel for a couple of months
> > > > and have more than 20
> > > > accepted patches in a couple of subsystems.
> > > > 
> > > > I started looking through the catalog of Analog Devices Inc. and I'm
> > > > pretty interested in writing a driver for gyroscopes, inertial
> > > > measurement units (IMUs), magnetometers, pressure sensors, proximity
> > > > sensors, or temperature sensors. But, while looking through the
> > > > catalog, I could not figure out a sensor that would be relevant to
> > > > Linux Kernel. I mean, I would like to work on a sensor that would be
> > > > relevant to the community and to Analog Devices Inc.
> > > > 
> > > > In that sense, I would like to know if anyone in the IIO community
> > > > could recommend a sensor that would make sense for the company and the
> > > > IIO community. Any suggestion is appreciated!  
> > > 
> > > I'm not going to recommend a particular sensor, but more offer some general
> > > tips on what 'sort' of device makes a good target for a GSOC.
> > > Finding a sensor means trawling datasheets and I'm tight on time today
> > > + I've no real insight into what the ADI folk might like to see
> > > supported!
> > > 
> > > The nature of a GSOC driver submission is often a little different to
> > > how an experienced driver author might go about things, simply because you
> > > will / should be looking for feedback at more stages of development and
> > > hopefully to upstream things in multiple stages.  An old hand at IIO
> > > drivers will often just jump directly to a driver supporting all the
> > > features they wish to target.  As such, the 'perfect' device to target
> > > should meet a few requirements that may not be true for the approach of jumping
> > > straight to the end goal.  Note this is equally true for other people
> > > starting out writing drivers - though they can often do very simple
> > > devices first and that is not a good plan for a GSOC project where
> > > you need to have a progression during the project.
> > > 
> > > Try to find something that offers some advanced features to provide
> > > stretch goals but make sure the basic functionality will work with
> > > a much simpler driver. So devices that provide straight forward
> > > registers to access the latest channel value are great, whereas
> > > those that only offer a streaming interfaces / fifo may be less suitable.
> > > However if they offer both that is perfect as the fifo make a good
> > > later feature for a GSOC project if things are going particularly
> > > well!  For a real stretch goal, find a device with features that
> > > we don't support at all today (perhaps new sensor types, or some
> > > other new feature) as they'll give you the experience of defining
> > > new ABI + possibly modifying the IIO core to meet some requirements.
> > > 
> > > Another thing to look at it is whether the part is sufficiently
> > > different from those supported by existing drivers to justify a
> > > separate driver. If not, you may find your GSOC project becomes
> > > simply adding an ID! (then rapidly choosing a second device to
> > > work on).
> > > 
> > > Hope that provides a few hints on what to look at.  Probably the best
> > > way around is to suggest one or more parts you think look interesting
> > > then we can give feedback on whether we think they'd be a good choice
> > > or not.  
> > 
> > Hi Jonathan,
> > 
> > I really appreciate the answer. Thank you for your attention and time!
> > 
> > During the week, I ended up picking the ADXL375 accelerometer (although I am
> > open to any change proposed by ADI or the IIO community). Based on that device,
> > I wrote a proposal and I would appreciate if you provide some feedback on the
> > device choice and proposal: https://pt.overleaf.com/read/xsmmdpvzqrhd.
> 
> Unfortunately that part hits the second to last paragraph above.
> 
> It's so nearly compatible with the ADXL345 that the driver already supports it:
> https://elixir.bootlin.com/linux/v5.18-rc1/source/drivers/iio/accel/adxl345_i2c.c#L42
> This is very common for these types of devices as there are often many similar
> variants, usually with different ranges or with small additional features, or numbers
> of interrupt pins etc.  Another fun one is parts with ratings for different applications
> but identical software interfaces being given different part numbers.
> I think in this case the two parts have different scaling, but are otherwise
> identical.
> 
> So probably need to find another part.

Hi, Jonathan

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.

If possible, I would like to get your input on those options.

Sincerely,
Maíra

> 
> Jonathan
> 
> > 
> > Regards,
> > Maíra
> > 
> > > 
> > > Good luck!
> > > 
> > > Jonathan
> > > 
> > > 
> > >   
> > > > 
> > > > Sincerely,
> > > > Maíra Canal  
> > >   
> 

Re: GSoC Proposal 2022

[Andy Shevchenko]

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.

> If possible, I would like to get your input on those options.

P.S. Please try to remove unrelated text in your email replies.

-- 
With Best Regards,
Andy Shevchenko

Re: GSoC Proposal 2022

[Nuno Sá]

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).

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).

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á

Re: GSoC Proposal 2022

[Maíra Canal]

On 04/12, Nuno Sá 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:
> 
> 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.

I took another look at the Maxim Integrated catalog and end up finding
the MAX31889 Temperature Sensor.

I guess this sensor has an interesting challenge level with the need to
implement FIFO and interrupts support. 

Have you guys some thoughts on this one?

> 
> 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.

P.S.: Although the ADPD188BI looks like a lot of fun, I was afraid to don't be
able to deliver a full driver at the end of 12-weeks. So, I'm trying to find
a safer choice.

Maíra Canal

> 
> - Nuno Sá
> 

Re: GSoC Proposal 2022

[Nuno Sá]

On Tue, 2022-04-12 at 09:24 -0300, Maíra Canal wrote:
> On 04/12, Nuno Sá 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:
> > 
> > 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.
> 
> I took another look at the Maxim Integrated catalog and end up
> finding
> the MAX31889 Temperature Sensor.
> 
> I guess this sensor has an interesting challenge level with the need
> to
> implement FIFO and interrupts support. 
> 
> Have you guys some thoughts on this one?
> 

At first glance, it looks like a better choice when compared with
MAX31875...

- Nuno Sá
> 
> > 

Re: GSoC Proposal 2022

[Jonathan Cameron]

On Tue, 12 Apr 2022 16:23:55 +0200
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Tue, 2022-04-12 at 09:24 -0300, Maíra Canal wrote:
> > On 04/12, Nuno Sá 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:  
> > > 
> > > 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.  
> > 
> > I took another look at the Maxim Integrated catalog and end up
> > finding
> > the MAX31889 Temperature Sensor.
> > 
> > I guess this sensor has an interesting challenge level with the need
> > to
> > implement FIFO and interrupts support. 
> > 
> > Have you guys some thoughts on this one?
Hmm. The fifo is interesting, but I'm somewhat doubtful that it's actually
much use when connected to a linux system.  The sampling rate is 1Hz.
At that rate even in busy systems or low power situations, there is
little reason not to just poll the device.

You 'could' wire up a PWM or similar to the gpio and have it operate
like a 'self clocked' device but with sampling rates so low it's a fairly
contrived situation.

Temperature sensors in general are often a bad fit for IIO precisely because
they are mostly designed for monitoring type purposes which HWMON covers.
The exceptions are high speed or high accuracy devices or weird ones like
infrared thermometers.

For the corner cases we have the option of the iio-hwmon bridge driver
but they need to be more obviously not suited to hwmon than this one to
justify their presence in IIO. In general hwmon drivers are simpler, so
if you can get away with it they are a better choice. (also some hwmon
specific features like multiple levels of even of the same type for
warning / critical detection).

Jonathan

> >   
> 
> At first glance, it looks like a better choice when compared with
> MAX31875...
> 
> - Nuno Sá
> >   
> > >   
> 

Re: GSoC Proposal 2022

[Maíra Canal]

On 04/12, Jonathan Cameron wrote:
> On Tue, 12 Apr 2022 16:23:55 +0200
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > On Tue, 2022-04-12 at 09:24 -0300, Maíra Canal wrote:
> > > On 04/12, Nuno Sá 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:  
> > > > 
> > > > 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.  
> > > 
> > > I took another look at the Maxim Integrated catalog and end up
> > > finding
> > > the MAX31889 Temperature Sensor.
> > > 
> > > I guess this sensor has an interesting challenge level with the need
> > > to
> > > implement FIFO and interrupts support. 
> > > 
> > > Have you guys some thoughts on this one?
> Hmm. The fifo is interesting, but I'm somewhat doubtful that it's actually
> much use when connected to a linux system.  The sampling rate is 1Hz.
> At that rate even in busy systems or low power situations, there is
> little reason not to just poll the device.
> 
> You 'could' wire up a PWM or similar to the gpio and have it operate
> like a 'self clocked' device but with sampling rates so low it's a fairly
> contrived situation.
> 
> Temperature sensors in general are often a bad fit for IIO precisely because
> they are mostly designed for monitoring type purposes which HWMON covers.
> The exceptions are high speed or high accuracy devices or weird ones like
> infrared thermometers.

Okay, so temperature sensors are not a good choice for an IIO project.

Just another two suggestions: AD5124/AD5144/AD5144A potenciometer and AD7294-2
ADC. Any of those are a good idea for IIO?

P.S.: It's been hard to choose a component without any project requiments (like
in a real hardware project). I'm sorry for the buzz on the mailing list.

> 
> Jonathan
> 

Re: GSoC Proposal 2022

[Nuno Sá]

On Tue, 2022-04-12 at 16:24 -0300, Maíra Canal wrote:
> On 04/12, Jonathan Cameron wrote:
> > On Tue, 12 Apr 2022 16:23:55 +0200
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> > 
> > > On Tue, 2022-04-12 at 09:24 -0300, Maíra Canal wrote:
> > > > On 04/12, Nuno Sá 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:  
> > > > > 
> > > > > 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.  
> > > > 
> > > > I took another look at the Maxim Integrated catalog and end up
> > > > finding
> > > > the MAX31889 Temperature Sensor.
> > > > 
> > > > I guess this sensor has an interesting challenge level with the
> > > > need
> > > > to
> > > > implement FIFO and interrupts support. 
> > > > 
> > > > Have you guys some thoughts on this one?
> > Hmm. The fifo is interesting, but I'm somewhat doubtful that it's
> > actually
> > much use when connected to a linux system.  The sampling rate is
> > 1Hz.
> > At that rate even in busy systems or low power situations, there is
> > little reason not to just poll the device.
> > 
> > You 'could' wire up a PWM or similar to the gpio and have it
> > operate
> > like a 'self clocked' device but with sampling rates so low it's a
> > fairly
> > contrived situation.
> > 
> > Temperature sensors in general are often a bad fit for IIO
> > precisely because
> > they are mostly designed for monitoring type purposes which HWMON
> > covers.
> > The exceptions are high speed or high accuracy devices or weird
> > ones like
> > infrared thermometers.
> 
> Okay, so temperature sensors are not a good choice for an IIO
> project.
> 
> Just another two suggestions: AD5124/AD5144/AD5144A potenciometer and
> AD7294-2
> ADC. Any of those are a good idea for IIO?
> 

Both options look promising being AD7294-2, at first glance, more
complex. The latter actually looks like it fits iio/addac category of
devices. I just briefly looked at the datasheets so I cannot really say
for sure if buffering makese sense for these (for adc/dac often it
does).

- Nuno Sá
> > 

Re: GSoC Proposal 2022

[Jonathan Cameron]

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á
> 

Re: GSoC Proposal 2022

[Nuno Sá]

On Tue, 2022-04-12 at 16:59 +0100, Jonathan Cameron wrote:
> 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? 

Yeah, it is something that you can set on the device so a writable
sampling_frequency attr. I think it fits on your 3rd point. Anyways, it
din't even crossed my mind that these rates are so low that buffering
is is not worth it...
> 

- Nuno Sá

Re: GSoC Proposal 2022

[Andy Shevchenko]

On Mon, Apr 11, 2022 at 4:05 AM Jonathan Cameron <jic23@kernel.org> wrote:
> On Thu, 7 Apr 2022 00:23:29 -0300
> Maíra Canal <maira.canal@usp.br> wrote:
>
> > Hi everyone, I am Maíra Canal an undergrad student at the University
> > of São Paulo, Brazil, pursuing
> > computer engineering. I wish to participate in the GSoC 2021 as a part
> > of the Linux Foundation, IIO Project.

> > I have been contributing to the Linux kernel for a couple of months
> > and have more than 20
> > accepted patches in a couple of subsystems.
> >
> > I started looking through the catalog of Analog Devices Inc. and I'm
> > pretty interested in writing a driver for gyroscopes, inertial
> > measurement units (IMUs), magnetometers, pressure sensors, proximity
> > sensors, or temperature sensors. But, while looking through the
> > catalog, I could not figure out a sensor that would be relevant to
> > Linux Kernel. I mean, I would like to work on a sensor that would be
> > relevant to the community and to Analog Devices Inc.
> >
> > In that sense, I would like to know if anyone in the IIO community
> > could recommend a sensor that would make sense for the company and the
> > IIO community. Any suggestion is appreciated!
>
> I'm not going to recommend a particular sensor, but more offer some general
> tips on what 'sort' of device makes a good target for a GSOC.

My recommendation to GSoC participants stays the same, i.e. browse
stackoverflow for the questions regarding the sensors that are only
implemented in user space so far (by Python/Java/etc libraries) and
write a driver for one of them.

-- 
With Best Regards,
Andy Shevchenko