GSoC IIO project: Mugil

GSoC IIO project: Mugil

[Mugil Raj]

Hi,
This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
GSoC'21 for the project IIO driver. So, I need help from you guys with
the application process and finding the device to develop a driver.
I've done few exercises on patch submissions and completed a Linux
Foundations course, "A beginners guide to Linux kernel development
(LFD103)". I found this "https://kernelnewbies.org/IIO_tasks" task for
beginners, and now I'm doing that also If anyone suggests some fixes
to develop, that would be helpful for me.

Is there any IRC channel for IIO?

Thanks,
Mugil

Re: GSoC IIO project: Mugil

[Alexandru Ardelean]

On Thu, Mar 11, 2021 at 9:03 AM Mugil Raj <dmugil2000@gmail.com> wrote:
>
> Hi,
> This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
> GSoC'21 for the project IIO driver. So, I need help from you guys with
> the application process and finding the device to develop a driver.
> I've done few exercises on patch submissions and completed a Linux
> Foundations course, "A beginners guide to Linux kernel development
> (LFD103)". I found this "https://kernelnewbies.org/IIO_tasks" task for
> beginners, and now I'm doing that also If anyone suggests some fixes
> to develop, that would be helpful for me.
>


hey,

i posted some ideas here:
https://lore.kernel.org/linux-iio/CA+U=Dsp98caW89g9FbsV-+KQ-NjyOqd+KSkO+aaFp4qBb-hpMg@mail.gmail.com/T/#md6c49f2e457d66d922d3d22f1f6fdb54971e6b8a

[a quick copy + paste from that email]

One thing I've always wanted to do, is to convert the entire IIO
subsystem to devm_ variants.
Essentially getting rid of the iio_device_unregister() function in
favor of using devm_iio_device_unregister() and similar.

There's about ~217 uses of this function.
The more complicated one is in the 'drivers/platform/x86/toshiba_acpi.c'
I think reworking the Toshiba ACPI driver would also be interesting,
but it is some work.

Now, converting everything to devm_ variants can be considered a bit
of an obsession [by some people].
But I sometimes find potential memory leaks by doing this conversion.
And chances are that we may never be able to fully convert the IIO API
to be devm_ variant-only.
But it is an interesting process [for me], just the cleanup itself.

Another one, that was interesting until 1-2 years ago, was the
conversion of OF drivers to be a bit more ACPI friendly [as well].
This is also a bit of work to convert drivers that use only
of_property_read_xxxx()  functions to   device_property_read_xxx()
functions.
This isn't always straightforward in all drivers, but I do find it
interesting to unify the OF & ACPI interfaces, so that all you have to
do, is just switch the system from OF to ACPI underneath, and if the
device-tree conversion to ACPI is done right, it just works.

Then, there's the matter of moving fields [marked as [INTERN] )  from
"struct iio_dev"  to "struct iio_dev_opaque".
The value of this conversion is to reduce the review pain of having to
tell people not-to-use [INTERN] fields [especially when older drivers
do].


> Is there any IRC channel for IIO?
>
> Thanks,
> Mugil

Re: GSoC IIO project: Mugil

[Enrico Weigelt, metux IT consult]

On 11.03.21 08:01, Mugil Raj wrote:

Hi,

[ CC'ing Utkarsh, who's got a similar question ]

> This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
> GSoC'21 for the project IIO driver. So, I need help from you guys with
> the application process and finding the device to develop a driver.

Since you're not very experienced, I suggest starting with some
simple device like plain ADCs. Several vendors like TI or AD offer
a huge range of ADCs where we no drivers for.

I'd start w/ the simple SPI based devices. It seems they've got quite
some overlap (quite simiar protocols), so parts of that maybe could be
consolidated into some common library code.


For simple ADCs, I've also got yet another(more complex) idea:

Create some 'simple-ADC' subsys, which gives a *simple* API for the
*simple* cases that's bridged to iio and hwmon (maybe even other
subsys's). The idea is getting actual hw drivers for those devices very
simple and small, make them usable in IIO as well as hwmon.

An interesting question here, that needs some deeper thoughs, is the
driver instantiation into the actual subsystems.

For example, if some DT says, there's some "ti,adcXYZABC" on the board,
what does that actually mean for us ? Where (eg. in which subsys) shall
it appear ? Is it an IIO or hwmon device ? Shall that decision even be
made only by DT, or do we rely on some other configuration layer ?


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: GSoC IIO project: Mugil

[Lars-Peter Clausen]

On 3/11/21 8:01 AM, Mugil Raj wrote:
> Hi,
> This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
> GSoC'21 for the project IIO driver. So, I need help from you guys with
> the application process and finding the device to develop a driver.
> I've done few exercises on patch submissions and completed a Linux
> Foundations course, "A beginners guide to Linux kernel development
> (LFD103)". I found this "https://kernelnewbies.org/IIO_tasks" task for
> beginners, and now I'm doing that also If anyone suggests some fixes
> to develop, that would be helpful for me.
> 
> Is there any IRC channel for IIO?

#linux-iio in irc.oftc.net. It is a bit quiet at times, but if you stick around 
you'll usually get a reply.

- Lars

Re: GSoC IIO project: Mugil

[Lars-Peter Clausen]

On 3/11/21 2:59 PM, Enrico Weigelt, metux IT consult wrote:
> On 11.03.21 08:01, Mugil Raj wrote:
> 
> Hi,
> 
> [ CC'ing Utkarsh, who's got a similar question ]
> 
>> This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
>> GSoC'21 for the project IIO driver. So, I need help from you guys with
>> the application process and finding the device to develop a driver.
> 
> Since you're not very experienced, I suggest starting with some
> simple device like plain ADCs. Several vendors like TI or AD offer
> a huge range of ADCs where we no drivers for >
> I'd start w/ the simple SPI based devices. It seems they've got quite
> some overlap (quite simiar protocols), so parts of that maybe could be
> consolidated into some common library code.

They are sometimes similar, but then have subtle differences. Sometimes 
hardware designers like to move bits around, just because they can.

For one family (100+ devices) we already have such a library, see 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/adc/ad_sigma_delta.c.

What can make a good target for shared code is single channels converters (both 
ADCs and DACs),since there is really only that many ways how to implement that 
in hardware.

> 
> 
> For simple ADCs, I've also got yet another(more complex) idea:
> 
> Create some 'simple-ADC' subsys, which gives a *simple* API for the
> *simple* cases that's bridged to iio and hwmon (maybe even other
> subsys's). The idea is getting actual hw drivers for those devices very
> simple and small, make them usable in IIO as well as hwmon.

Not to forget ALSA. Some ADCs are multi-purpose so that they can be used for 
monitoring, but also audio applications.

I did propose such a ADC subsystem maybe 10 years ago. The conclusions back 
then was that we shouldn't create a subsystem for every sensor type and instead 
use IIO.

> 
> An interesting question here, that needs some deeper thoughs, is the
> driver instantiation into the actual subsystems.
> 
> For example, if some DT says, there's some "ti,adcXYZABC" on the board,
> what does that actually mean for us ? Where (eg. in which subsys) shall
> it appear ? Is it an IIO or hwmon device ? Shall that decision even be
> made only by DT, or do we rely on some other configuration layer ?

Yes, that is a really complicated question. DT is not supposed to describe the 
software (sub-)systems that are used.

Re: GSoC IIO project: Mugil

[Alexandru Ardelean]

On Sat, Mar 13, 2021 at 5:28 PM Mugilraj <dmugil2000@gmail.com> wrote:
>
> On Thu, Mar 11, 2021 at 10:58:53AM +0200, Alexandru Ardelean wrote:
> > On Thu, Mar 11, 2021 at 9:03 AM Mugil Raj <dmugil2000@gmail.com> wrote:
> > >
> > > Hi,
> > > This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
> > > GSoC'21 for the project IIO driver. So, I need help from you guys with
> > > the application process and finding the device to develop a driver.
> > > I've done few exercises on patch submissions and completed a Linux
> > > Foundations course, "A beginners guide to Linux kernel development
> > > (LFD103)". I found this "https://kernelnewbies.org/IIO_tasks" task for
> > > beginners, and now I'm doing that also If anyone suggests some fixes
> > > to develop, that would be helpful for me.
> > >
> >
> >
> > hey,
> >
> > i posted some ideas here:
> > https://lore.kernel.org/linux-iio/CA+U=Dsp98caW89g9FbsV-+KQ-NjyOqd+KSkO+aaFp4qBb-hpMg@mail.gmail.com/T/#md6c49f2e457d66d922d3d22f1f6fdb54971e6b8a
> >
> > [a quick copy + paste from that email]
> >
> > One thing I've always wanted to do, is to convert the entire IIO
> > subsystem to devm_ variants.
> > Essentially getting rid of the iio_device_unregister() function in
> > favor of using devm_iio_device_unregister() and similar.
> >
> > There's about ~217 uses of this function.
> > The more complicated one is in the 'drivers/platform/x86/toshiba_acpi.c'
> > I think reworking the Toshiba ACPI driver would also be interesting,
> > but it is some work.
> >
> > Now, converting everything to devm_ variants can be considered a bit
> > of an obsession [by some people].
> > But I sometimes find potential memory leaks by doing this conversion.
> > And chances are that we may never be able to fully convert the IIO API
> > to be devm_ variant-only.
> > But it is an interesting process [for me], just the cleanup itself.
> I've gone through docs and I hade a dout on devm_iio_device_register().
> If we use this function it  will automatically unregistered on driver
> detach. Then what is the use of devm_iio_device_unregister().

I think you forgot to hit reply all.
So, devm_iio_device_unregister() should no longer exist in a recent kernel.
So, the docs you are reading are from an older kernel.
I think 5.7 is the kernel where some IIO devm_ functions were removed.

But this is a general topic about why should there be a devm_init()
and a devm_uninit()
Especially if the resource allocated with devm_init() is known to be
automatically free'd at driver unload.

The reasons why these existed in IIO [and other places] is because of
the classic C model of "you write an allocation function, then you
also write a deallocation function".
But if you use functions like devm_iio_device_unregister() then it's
likely that the driver has some bad design.

Now there are some cases like  devm_k***alloc() and devm_kfree().
In these cases, you sometimes need to free a resource during driver
operation because it is allocated with devm_kalloc(), but you need to
change the size of the allocated memory block.
Example:

resoure_array = devm_kcalloc(n, m);
devm_kfree(resoure_array)
resoure_array = devm_kcalloc(n + 1, m);

If you were to use kfree() it would have caused a crash during driver
unload, because it would try to free an already free'd block.
Recently, a devm_krealloc() got introduced for this [in August 2020],
but you will see that devm_kfree() is quite used in the kernel.
I suspect it may be the most used  devm_<release_resource>() function
in the kernel (probably because there was no devm_krealloc() before),
because you need to do this run-time memory management for some driver
logic, but you also want the neatness of it being unloaded at driver
unload.

>
> It may be a silly question sorry:).

not a silly question;
this is all kernel API stuff, which isn't obvious in the beginning

> >
> > Another one, that was interesting until 1-2 years ago, was the
> > conversion of OF drivers to be a bit more ACPI friendly [as well].
> > This is also a bit of work to convert drivers that use only
> > of_property_read_xxxx()  functions to   device_property_read_xxx()
> > functions.
> > This isn't always straightforward in all drivers, but I do find it
> > interesting to unify the OF & ACPI interfaces, so that all you have to
> > do, is just switch the system from OF to ACPI underneath, and if the
> > device-tree conversion to ACPI is done right, it just works.
> >
> > Then, there's the matter of moving fields [marked as [INTERN] )  from
> > "struct iio_dev"  to "struct iio_dev_opaque".
> > The value of this conversion is to reduce the review pain of having to
> > tell people not-to-use [INTERN] fields [especially when older drivers
> > do].
> >
> >
> > > Is there any IRC channel for IIO?
> > >
> > > Thanks,
> > > Mugil

Re: GSoC IIO project: Mugil

[Jonathan Cameron]

On Sat, 13 Mar 2021 20:43:33 +0200
Alexandru Ardelean <ardeleanalex@gmail.com> wrote:

> On Sat, Mar 13, 2021 at 5:28 PM Mugilraj <dmugil2000@gmail.com> wrote:
> >
> > On Thu, Mar 11, 2021 at 10:58:53AM +0200, Alexandru Ardelean wrote:  
> > > On Thu, Mar 11, 2021 at 9:03 AM Mugil Raj <dmugil2000@gmail.com> wrote:  
> > > >
> > > > Hi,
> > > > This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
> > > > GSoC'21 for the project IIO driver. So, I need help from you guys with
> > > > the application process and finding the device to develop a driver.
> > > > I've done few exercises on patch submissions and completed a Linux
> > > > Foundations course, "A beginners guide to Linux kernel development
> > > > (LFD103)". I found this "https://kernelnewbies.org/IIO_tasks" task for
> > > > beginners, and now I'm doing that also If anyone suggests some fixes
> > > > to develop, that would be helpful for me.
> > > >  
> > >
> > >
> > > hey,
> > >
> > > i posted some ideas here:
> > > https://lore.kernel.org/linux-iio/CA+U=Dsp98caW89g9FbsV-+KQ-NjyOqd+KSkO+aaFp4qBb-hpMg@mail.gmail.com/T/#md6c49f2e457d66d922d3d22f1f6fdb54971e6b8a
> > >
> > > [a quick copy + paste from that email]
> > >
> > > One thing I've always wanted to do, is to convert the entire IIO
> > > subsystem to devm_ variants.
> > > Essentially getting rid of the iio_device_unregister() function in
> > > favor of using devm_iio_device_unregister() and similar.
> > >
> > > There's about ~217 uses of this function.
> > > The more complicated one is in the 'drivers/platform/x86/toshiba_acpi.c'
> > > I think reworking the Toshiba ACPI driver would also be interesting,
> > > but it is some work.
> > >
> > > Now, converting everything to devm_ variants can be considered a bit
> > > of an obsession [by some people].
> > > But I sometimes find potential memory leaks by doing this conversion.
> > > And chances are that we may never be able to fully convert the IIO API
> > > to be devm_ variant-only.
> > > But it is an interesting process [for me], just the cleanup itself.  
> > I've gone through docs and I hade a dout on devm_iio_device_register().
> > If we use this function it  will automatically unregistered on driver
> > detach. Then what is the use of devm_iio_device_unregister().  
> 
> I think you forgot to hit reply all.
> So, devm_iio_device_unregister() should no longer exist in a recent kernel.
> So, the docs you are reading are from an older kernel.
> I think 5.7 is the kernel where some IIO devm_ functions were removed.
> 
> But this is a general topic about why should there be a devm_init()
> and a devm_uninit()
> Especially if the resource allocated with devm_init() is known to be
> automatically free'd at driver unload.
> 
> The reasons why these existed in IIO [and other places] is because of
> the classic C model of "you write an allocation function, then you
> also write a deallocation function".

I can absolutely confirm that was how this particular function
came to be!  I wasn't thinking at the time. Oops ;)

> But if you use functions like devm_iio_device_unregister() then it's
> likely that the driver has some bad design.
> 
> Now there are some cases like  devm_k***alloc() and devm_kfree().
> In these cases, you sometimes need to free a resource during driver
> operation because it is allocated with devm_kalloc(), but you need to
> change the size of the allocated memory block.
> Example:
> 
> resoure_array = devm_kcalloc(n, m);
> devm_kfree(resoure_array)
> resoure_array = devm_kcalloc(n + 1, m);
> 
> If you were to use kfree() it would have caused a crash during driver
> unload, because it would try to free an already free'd block.
> Recently, a devm_krealloc() got introduced for this [in August 2020],
> but you will see that devm_kfree() is quite used in the kernel.
> I suspect it may be the most used  devm_<release_resource>() function
> in the kernel (probably because there was no devm_krealloc() before),
> because you need to do this run-time memory management for some driver
> logic, but you also want the neatness of it being unloaded at driver
> unload.
> 
> >
> > It may be a silly question sorry:).  
> 
> not a silly question;
> this is all kernel API stuff, which isn't obvious in the beginning

This particular question focuses on one of the most common things people
do wrong when first writing a driver (unnecessary cleanup of managed
functions)  I have to explain this at least 10 times a year!

If you spread out beyond IIO over time you'll find they don't all
start with devm_ for example pcim_ which is much more subtle to spot.
I'm glad we didn't go with iiom_* :)

Jonathan

> 
> > >
> > > Another one, that was interesting until 1-2 years ago, was the
> > > conversion of OF drivers to be a bit more ACPI friendly [as well].
> > > This is also a bit of work to convert drivers that use only
> > > of_property_read_xxxx()  functions to   device_property_read_xxx()
> > > functions.
> > > This isn't always straightforward in all drivers, but I do find it
> > > interesting to unify the OF & ACPI interfaces, so that all you have to
> > > do, is just switch the system from OF to ACPI underneath, and if the
> > > device-tree conversion to ACPI is done right, it just works.
> > >
> > > Then, there's the matter of moving fields [marked as [INTERN] )  from
> > > "struct iio_dev"  to "struct iio_dev_opaque".
> > > The value of this conversion is to reduce the review pain of having to
> > > tell people not-to-use [INTERN] fields [especially when older drivers
> > > do].
> > >
> > >  
> > > > Is there any IRC channel for IIO?
> > > >
> > > > Thanks,
> > > > Mugil  

Re: GSoC IIO project: Mugil

[Lars-Peter Clausen]

On 3/13/21 7:43 PM, Alexandru Ardelean wrote:
> On Sat, Mar 13, 2021 at 5:28 PM Mugilraj <dmugil2000@gmail.com> wrote:
>> On Thu, Mar 11, 2021 at 10:58:53AM +0200, Alexandru Ardelean wrote:
>>> On Thu, Mar 11, 2021 at 9:03 AM Mugil Raj <dmugil2000@gmail.com> wrote:
>>>> Hi,
>>>> This is Mugilraj, an undergrad at NIT Trichy, India. I'm applying to
>>>> GSoC'21 for the project IIO driver. So, I need help from you guys with
>>>> the application process and finding the device to develop a driver.
>>>> I've done few exercises on patch submissions and completed a Linux
>>>> Foundations course, "A beginners guide to Linux kernel development
>>>> (LFD103)". I found this "https://kernelnewbies.org/IIO_tasks" task for
>>>> beginners, and now I'm doing that also If anyone suggests some fixes
>>>> to develop, that would be helpful for me.
>>>>
>>>
>>> hey,
>>>
>>> i posted some ideas here:
>>> https://lore.kernel.org/linux-iio/CA+U=Dsp98caW89g9FbsV-+KQ-NjyOqd+KSkO+aaFp4qBb-hpMg@mail.gmail.com/T/#md6c49f2e457d66d922d3d22f1f6fdb54971e6b8a
>>>
>>> [a quick copy + paste from that email]
>>>
>>> One thing I've always wanted to do, is to convert the entire IIO
>>> subsystem to devm_ variants.
>>> Essentially getting rid of the iio_device_unregister() function in
>>> favor of using devm_iio_device_unregister() and similar.
>>>
>>> There's about ~217 uses of this function.
>>> The more complicated one is in the 'drivers/platform/x86/toshiba_acpi.c'
>>> I think reworking the Toshiba ACPI driver would also be interesting,
>>> but it is some work.
>>>
>>> Now, converting everything to devm_ variants can be considered a bit
>>> of an obsession [by some people].
>>> But I sometimes find potential memory leaks by doing this conversion.
>>> And chances are that we may never be able to fully convert the IIO API
>>> to be devm_ variant-only.
>>> But it is an interesting process [for me], just the cleanup itself.
>> I've gone through docs and I hade a dout on devm_iio_device_register().
>> If we use this function it  will automatically unregistered on driver
>> detach. Then what is the use of devm_iio_device_unregister().
> [...]
>> It may be a silly question sorry:).
> not a silly question;
> this is all kernel API stuff, which isn't obvious in the beginning

Mugil,

There are two drivers that would be good candidates to get started with this, send your first patch and familiarize yourself with the process.

  * drivers/iio/dac/max517.c
  * drivers/iio/gyro/adis16080.c

Basically if iio_device_unregister() is the last function that gets called in the remove() function of the driver it is usually safe to convert the iio_device_register() in the probe function to a devm_iio_device_register().

- Lars

ADC subsystem [WAS: GSoC IIO project: Mugil]

[Enrico Weigelt, metux IT consult]

On 11.03.21 16:45, Lars-Peter Clausen wrote:

>> For simple ADCs, I've also got yet another(more complex) idea:
>>
>> Create some 'simple-ADC' subsys, which gives a *simple* API for the
>> *simple* cases that's bridged to iio and hwmon (maybe even other
>> subsys's). The idea is getting actual hw drivers for those devices very
>> simple and small, make them usable in IIO as well as hwmon.
> 
> Not to forget ALSA. Some ADCs are multi-purpose so that they can be used 
> for monitoring, but also audio applications.

Oh, how could I forget that ;-)

> I did propose such a ADC subsystem maybe 10 years ago. The conclusions 
> back then was that we shouldn't create a subsystem for every sensor type 
> and instead use IIO.

I don't think, IIO is a good place here. IIO seems to be kinda catchall
for anything that delivers samples of potentially multiple channels.
That's okay for generic data acquisition, where the OS really can't know
whats behind those IOs right know, and an specific application needs
to take care of that. But it's a bad idea, if the IO has some specific
and fixed purpose, eg. audio input, battery monitoring, etc.

Yes, some of these device classes are already handled by IIO (different
channel types, conversions, ...), but still that needs to be customized
for each use case (the same ADC can be used for many different things),
and often special userland code (eg. in the audio case).

Maybe we need some kind of "policy layer" which tells what some physical
device is used for ...

>> An interesting question here, that needs some deeper thoughs, is the
>> driver instantiation into the actual subsystems.
>>
>> For example, if some DT says, there's some "ti,adcXYZABC" on the board,
>> what does that actually mean for us ? Where (eg. in which subsys) shall
>> it appear ? Is it an IIO or hwmon device ? Shall that decision even be
>> made only by DT, or do we rely on some other configuration layer ?
> 
> Yes, that is a really complicated question. DT is not supposed to 
> describe the software (sub-)systems that are used.

Nore sure, whether that belongs into category "software". Probably a
different one describing the actual use in the greater context of a
complete machine (which might be more than just the mainboard). In the
audio example, it indeed is about hardware, but one that's only
partially reflected in DT.

Maybe should introduce the idea of "composite devices". For DT that
would introduce additional information what that particular ADC is
used for. Could be an extra device_node that describes the audio output,
which just happens to use the ADC as a component:

     audio0 {
         compatible = "composite,simple-audio";
         adc = <&adc1>;
         headphone-detect-gpio = <&gpio77>;
	...
     };

Same could be done w/ other things like battery monitoring, etc.


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287