IIO drivers left in drivers/staging/

IIO drivers left in drivers/staging/

[Greg KH]

Hi Jonathan,

I'd really like to figure out what is left to do with all of the
remaining IIO staging drivers, and see if we can get them all moved out
soon.

As part of the OPW intern program, Kristina has agreed to help out with
staging kernel drivers and I thought that doing this type of work would
be a great task.  There seems to be a number of different types of
IIO drivers here, so that should keep her from being bored with just one
specific type of sensor.  There are also some "dummy" IIO drivers, which
I don't really understand what they are for (as well as why they remain
in staging.)

The drivers/staging/TODO file seems pretty old, being dated back in 2009
and not really done much with the exception of adding one entry.

So, any thoughts about what to do here?  Any pointers to devices that
she can aquire if that needs to happen, or APIs that need to be
standardized across types?

thanks,

greg k-h

Re: IIO drivers left in drivers/staging/

[Jonathan Cameron]

On June 11, 2014 2:30:07 AM GMT+01:00, Greg KH <gregkh@linuxfoundation.org> wrote:
>Hi Jonathan,
Hi Kristina/Greg.
>
>I'd really like to figure out what is left to do with all of the
>remaining IIO staging drivers, and see if we can get them all moved out
>soon.
There is a lot of each driver having its own peculiar set of little and sometimes big
 issues! We have also kind of gotten into the habbit of treating staging graduations as if
 they were initial driver submissions so proposed moves get quite a bit of review and
 that often extends the list of things to fix or improve rather a lot. Of course any help is
 welcome.

I'll reply in more detail about this later. 

For now I have cc'd Lars as he has inherited
 responsibility for a lot of AD drivers that have been around from the early days when
 things were a little loose.

If Christina is raring to get started, my notes say the lpc32xx_ADC driver needs some
 prefixes on #define constants and that is all I picked up for that driver when reviewing it
 for a staging graduation.

If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
 If I recall they are pretty clean and straight forward. Probably some ABI in need of
 documentation (sysfs attribute naming). If not do you have any short term suggestions?

>
>As part of the OPW intern program, Kristina has agreed to help out with
>staging kernel drivers and I thought that doing this type of work would
>be a great task.  There seems to be a number of different types of
>IIO drivers here, so that should keep her from being bored with just
>one
>specific type of sensor.  There are also some "dummy" IIO drivers,
>which
>I don't really understand what they are for (as well as why they remain
>in staging.)
Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
 hardware threshold interrupts etc.

This device is basically a fake. The intent was to allow those with no hardware to hand
 to work at or understand the core of iio.
It has come in very handy as a test tool!

The other intended purpose is to act as an example of best practice and provide
 documentation of a sort.

As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
>
>The drivers/staging/TODO file seems pretty old, being dated back in
>2009
>and not really done much with the exception of adding one entry.

Oops
>
>So, any thoughts about what to do here?  Any pointers to devices that
>she can aquire if that needs to happen, or APIs that need to be
>standardized across types?
Most ABI bits are now to do with new stuff.
Having said that the resolver and CDC
 drivers use some ABI that is probably documented but that documentation is also
 a candidate for cleaning up and moving out of staging.

Busy day (pesky customer demo) so will get back with more concrete stuff later.
>
>thanks,
>
>greg k-h
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: IIO drivers left in drivers/staging/

[Jonathan Cameron]

On June 11, 2014 2:30:07 AM GMT+01:00, Greg KH <gregkh@linuxfoundation.org> wrote:
>Hi Jonathan,
Hi Kristina/Greg.
>
>I'd really like to figure out what is left to do with all of the
>remaining IIO staging drivers, and see if we can get them all moved out
>soon.
There is a lot of each driver having its own peculiar set of little and sometimes big
 issues! We have also kind of gotten into the habbit of treating staging graduations as if
 they were initial driver submissions so proposed moves get quite a bit of review and
 that often extends the list of things to fix or improve rather a lot. Of course any help is
 welcome.

I'll reply in more detail about this later. 

For now I have cc'd Lars as he has inherited
 responsibility for a lot of AD drivers that have been around from the early days when
 things were a little loose.

If Christina is raring to get started, my notes say the lpc32xx_ADC driver needs some
 prefixes on #define constants and that is all I picked up for that driver when reviewing it
 for a staging graduation.

If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
 If I recall they are pretty clean and straight forward. Probably some ABI in need of
 documentation (sysfs attribute naming). If not do you have any short term suggestions?

>
>As part of the OPW intern program, Kristina has agreed to help out with
>staging kernel drivers and I thought that doing this type of work would
>be a great task.  There seems to be a number of different types of
>IIO drivers here, so that should keep her from being bored with just
>one
>specific type of sensor.  There are also some "dummy" IIO drivers,
>which
>I don't really understand what they are for (as well as why they remain
>in staging.)
Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
 hardware threshold interrupts etc.

This device is basically a fake. The intent was to allow those with no hardware to hand
 to work at or understand the core of iio.
It has come in very handy as a test tool!

The other intended purpose is to act as an example of best practice and provide
 documentation of a sort.

As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
>
>The drivers/staging/TODO file seems pretty old, being dated back in
>2009
>and not really done much with the exception of adding one entry.

Oops
>
>So, any thoughts about what to do here?  Any pointers to devices that
>she can aquire if that needs to happen, or APIs that need to be
>standardized across types?
Most ABI bits are now to do with new stuff.
Having said that the resolver and CDC
 drivers use some ABI that is probably documented but that documentation is also
 a candidate for cleaning up and moving out of staging.

Busy day (pesky customer demo) so will get back with more concrete stuff later.
>
>thanks,
>
>greg k-h
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: IIO drivers left in drivers/staging/

[Kristina Martšenko]

On 11/06/14 11:05, Jonathan Cameron wrote:
> On June 11, 2014 2:30:07 AM GMT+01:00, Greg KH <gregkh@linuxfoundation.org> wrote:
>> Hi Jonathan,
> Hi Kristina/Greg.

Hi Jonathan!

>> I'd really like to figure out what is left to do with all of the
>> remaining IIO staging drivers, and see if we can get them all moved out
>> soon.
> There is a lot of each driver having its own peculiar set of little and sometimes big
>  issues! We have also kind of gotten into the habbit of treating staging graduations as if
>  they were initial driver submissions so proposed moves get quite a bit of review and
>  that often extends the list of things to fix or improve rather a lot. Of course any help is
>  welcome.

Sounds good, I'm glad to help out however I can.

> I'll reply in more detail about this later. 
> 
> For now I have cc'd Lars as he has inherited
>  responsibility for a lot of AD drivers that have been around from the early days when
>  things were a little loose.
> 
> If Christina is raring to get started, my notes say the lpc32xx_ADC driver needs some
>  prefixes on #define constants and that is all I picked up for that driver when reviewing it
>  for a staging graduation.
> 
> If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
>  If I recall they are pretty clean and straight forward. Probably some ABI in need of
>  documentation (sysfs attribute naming). If not do you have any short term suggestions?
> 
>>
>> As part of the OPW intern program, Kristina has agreed to help out with
>> staging kernel drivers and I thought that doing this type of work would
>> be a great task.  There seems to be a number of different types of
>> IIO drivers here, so that should keep her from being bored with just
>> one
>> specific type of sensor.  There are also some "dummy" IIO drivers,
>> which
>> I don't really understand what they are for (as well as why they remain
>> in staging.)
> Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
>  hardware threshold interrupts etc.
> 
> This device is basically a fake. The intent was to allow those with no hardware to hand
>  to work at or understand the core of iio.
> It has come in very handy as a test tool!
> 
> The other intended purpose is to act as an example of best practice and provide
>  documentation of a sort.
> 
> As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
>>
>> The drivers/staging/TODO file seems pretty old, being dated back in
>> 2009
>> and not really done much with the exception of adding one entry.
> 
> Oops
>>
>> So, any thoughts about what to do here?  Any pointers to devices that
>> she can aquire if that needs to happen, or APIs that need to be
>> standardized across types?
> Most ABI bits are now to do with new stuff.
> Having said that the resolver and CDC
>  drivers use some ABI that is probably documented but that documentation is also
>  a candidate for cleaning up and moving out of staging.
> 
> Busy day (pesky customer demo) so will get back with more concrete stuff later.

Okay so right now I'm getting the following things I could work on:

1) prefixes on define constants for lpc32xx_ADC (then trying to move it
out of staging and seeing what other issues people find?)
2) resolver/CDC ABI documentation cleanup
3) dummy driver fake event interrupt hack
4) Lars may have more ideas?

The plan is for me to start working on this stuff full time next week,
so if you think of anything more, please let me know!

Kristina

Re: IIO drivers left in drivers/staging/

[Kristina Martšenko]

Hi Jonathan,

On 12/06/14 14:21, Kristina Martšenko wrote:
> On 11/06/14 11:05, Jonathan Cameron wrote:
>> On June 11, 2014 2:30:07 AM GMT+01:00, Greg KH <gregkh@linuxfoundation.org> wrote:
>>> Hi Jonathan,
>> Hi Kristina/Greg.
> 
> Hi Jonathan!
> 
>>> I'd really like to figure out what is left to do with all of the
>>> remaining IIO staging drivers, and see if we can get them all moved out
>>> soon.
>> There is a lot of each driver having its own peculiar set of little and sometimes big
>>  issues! We have also kind of gotten into the habbit of treating staging graduations as if
>>  they were initial driver submissions so proposed moves get quite a bit of review and
>>  that often extends the list of things to fix or improve rather a lot. Of course any help is
>>  welcome.
> 
> Sounds good, I'm glad to help out however I can.
> 
>> I'll reply in more detail about this later. 
>>
>> For now I have cc'd Lars as he has inherited
>>  responsibility for a lot of AD drivers that have been around from the early days when
>>  things were a little loose.
>>
>> If Christina is raring to get started, my notes say the lpc32xx_ADC driver needs some
>>  prefixes on #define constants and that is all I picked up for that driver when reviewing it
>>  for a staging graduation.
>>
>> If not, Lars, what about looking at the resolver drivers or perhaps the CDC drivers?
>>  If I recall they are pretty clean and straight forward. Probably some ABI in need of
>>  documentation (sysfs attribute naming). If not do you have any short term suggestions?
>>
>>>
>>> As part of the OPW intern program, Kristina has agreed to help out with
>>> staging kernel drivers and I thought that doing this type of work would
>>> be a great task.  There seems to be a number of different types of
>>> IIO drivers here, so that should keep her from being bored with just
>>> one
>>> specific type of sensor.  There are also some "dummy" IIO drivers,
>>> which
>>> I don't really understand what they are for (as well as why they remain
>>> in staging.)
>> Ah. There is only really one dummy driver, be it with a software interrupt driver to fake
>>  hardware threshold interrupts etc.
>>
>> This device is basically a fake. The intent was to allow those with no hardware to hand
>>  to work at or understand the core of iio.
>> It has come in very handy as a test tool!
>>
>> The other intended purpose is to act as an example of best practice and provide
>>  documentation of a sort.
>>
>> As for why it is still in staging... It comes down to the dubious hack that provides fake event interrupts. We do it much nicer in the sysfs trigger and would like to either use that approach or find something more generic.
>>>
>>> The drivers/staging/TODO file seems pretty old, being dated back in
>>> 2009
>>> and not really done much with the exception of adding one entry.
>>
>> Oops
>>>
>>> So, any thoughts about what to do here?  Any pointers to devices that
>>> she can aquire if that needs to happen, or APIs that need to be
>>> standardized across types?
>> Most ABI bits are now to do with new stuff.
>> Having said that the resolver and CDC
>>  drivers use some ABI that is probably documented but that documentation is also
>>  a candidate for cleaning up and moving out of staging.
>>
>> Busy day (pesky customer demo) so will get back with more concrete stuff later.
> 
> Okay so right now I'm getting the following things I could work on:
> 
> 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
> out of staging and seeing what other issues people find?)
> 2) resolver/CDC ABI documentation cleanup
> 3) dummy driver fake event interrupt hack
> 4) Lars may have more ideas?
> 
> The plan is for me to start working on this stuff full time next week,
> so if you think of anything more, please let me know!

Haven't heard back from you about this. Have you found anything else
that needs to be done with staging IIO drivers before they can be moved out?

Thanks,
Kristina

Re: IIO drivers left in drivers/staging/

[Peter Meerwald]

Hello Kristina,

> > Okay so right now I'm getting the following things I could work on:
> > 
> > 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
> > out of staging and seeing what other issues people find?)
> > 2) resolver/CDC ABI documentation cleanup
> > 3) dummy driver fake event interrupt hack
> > 4) Lars may have more ideas?
> > 
> > The plan is for me to start working on this stuff full time next week,
> > so if you think of anything more, please let me know!
> 
> Haven't heard back from you about this. Have you found anything else
> that needs to be done with staging IIO drivers before they can be moved out?

IIO is a bit problematic since testing usually requires possessing the 
sensor chip

regarding staging/iio/magnetometer/hmc5843:
the driver has one specific DEVICE_ATTR left (meas_conf), otherwise clean 
I think; so we could (a) document it as special ABI or (b) drop it

regarding staging/iio/light/isl*:
drivers have plenty of custom ATTRs and do not follow style 
(function name prefixes, #define PREFIXes)
some of the special ATTRs could converted to using SAMPL_FREQ, INT_TIME, 
SCALE

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: IIO drivers left in drivers/staging/

[Jonathan Cameron]

On June 18, 2014 1:56:52 PM GMT+01:00, Peter Meerwald <pmeerw@pmeerw.net> wrote:
>Hello Kristina,
>
>> > Okay so right now I'm getting the following things I could work on:
>> > 
>> > 1) prefixes on define constants for lpc32xx_ADC (then trying to
>move it
>> > out of staging and seeing what other issues people find?)
>> > 2) resolver/CDC ABI documentation cleanup
>> > 3) dummy driver fake event interrupt hack
>> > 4) Lars may have more ideas?
>> > 
>> > The plan is for me to start working on this stuff full time next
>week,
>> > so if you think of anything more, please let me know!
>> 
>> Haven't heard back from you about this. Have you found anything else
>> that needs to be done with staging IIO drivers before they can be
>moved out?
Sorry, got caught up and failed to get back to you with more stuff.
>
>IIO is a bit problematic since testing usually requires possessing the 
>sensor chip
Whilst true, one can normally assume code as present works. Hence a lot can be done
 without hardware. Just a good idea to keep changes small and make it clear when they are untested.
>
>regarding staging/iio/magnetometer/hmc5843:
>the driver has one specific DEVICE_ATTR left (meas_conf), otherwise
>clean 
>I think; so we could (a) document it as special ABI or (b) drop it
>
>regarding staging/iio/light/isl*:
>drivers have plenty of custom ATTRs and do not follow style 
>(function name prefixes, #define PREFIXes)
>some of the special ATTRs could converted to using SAMPL_FREQ,
>INT_TIME, 
>SCALE
Good points.

A useful if perhaps dull task is to look at interfaces that are not in the ABI and figure out which ones need fixing and which, like those Peter highlights need new interfaces or should not be exposed to userspace at all. 
Killing off remaining bits that are now possible through info_mask_* is also helpful.

I have some patches for this outside staging but plenty to do in the drivers still there.
>
>regards, p.

Looking forward to patches!

J

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: IIO drivers left in drivers/staging/

[Greg KH]

On Wed, Jun 18, 2014 at 02:56:52PM +0200, Peter Meerwald wrote:
> Hello Kristina,
> 
> > > Okay so right now I'm getting the following things I could work on:
> > > 
> > > 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
> > > out of staging and seeing what other issues people find?)
> > > 2) resolver/CDC ABI documentation cleanup
> > > 3) dummy driver fake event interrupt hack
> > > 4) Lars may have more ideas?
> > > 
> > > The plan is for me to start working on this stuff full time next week,
> > > so if you think of anything more, please let me know!
> > 
> > Haven't heard back from you about this. Have you found anything else
> > that needs to be done with staging IIO drivers before they can be moved out?
> 
> IIO is a bit problematic since testing usually requires possessing the 
> sensor chip

Any specific chips / devices we should look into buying for these
drivers to help make it easier to do development?

> regarding staging/iio/magnetometer/hmc5843:
> the driver has one specific DEVICE_ATTR left (meas_conf), otherwise clean 
> I think; so we could (a) document it as special ABI or (b) drop it

Which is it?  It should be easy to delete a driver :)

thanks,

greg k-h

Re: IIO drivers left in drivers/staging/

[Jonathan Cameron]

On 18/06/14 18:47, Greg KH wrote:
> On Wed, Jun 18, 2014 at 02:56:52PM +0200, Peter Meerwald wrote:
>> Hello Kristina,
>>
>>>> Okay so right now I'm getting the following things I could work on:
>>>>
>>>> 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
>>>> out of staging and seeing what other issues people find?)
>>>> 2) resolver/CDC ABI documentation cleanup
>>>> 3) dummy driver fake event interrupt hack
>>>> 4) Lars may have more ideas?
>>>>
>>>> The plan is for me to start working on this stuff full time next week,
>>>> so if you think of anything more, please let me know!
>>>
>>> Haven't heard back from you about this. Have you found anything else
>>> that needs to be done with staging IIO drivers before they can be moved out?
>>
>> IIO is a bit problematic since testing usually requires possessing the
>> sensor chip
>
> Any specific chips / devices we should look into buying for these
> drivers to help make it easier to do development?
>
>> regarding staging/iio/magnetometer/hmc5843:
>> the driver has one specific DEVICE_ATTR left (meas_conf), otherwise clean
>> I think; so we could (a) document it as special ABI or (b) drop it
>
> Which is it?  It should be easy to delete a driver :)
Drop the attribute, not the driver!
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: IIO drivers left in drivers/staging/

[Jonathan Cameron]

On 18/06/14 19:06, Jonathan Cameron wrote:
> On 18/06/14 18:47, Greg KH wrote:
>> On Wed, Jun 18, 2014 at 02:56:52PM +0200, Peter Meerwald wrote:
>>> Hello Kristina,
>>>
>>>>> Okay so right now I'm getting the following things I could work on:
>>>>>
>>>>> 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
>>>>> out of staging and seeing what other issues people find?)
>>>>> 2) resolver/CDC ABI documentation cleanup
>>>>> 3) dummy driver fake event interrupt hack
>>>>> 4) Lars may have more ideas?
>>>>>
>>>>> The plan is for me to start working on this stuff full time next week,
>>>>> so if you think of anything more, please let me know!
>>>>
>>>> Haven't heard back from you about this. Have you found anything else
>>>> that needs to be done with staging IIO drivers before they can be moved out?
>>>
>>> IIO is a bit problematic since testing usually requires possessing the
>>> sensor chip
>>
>> Any specific chips / devices we should look into buying for these
>> drivers to help make it easier to do development?
On that note, perhaps ask for people to shout what they have access
to and we'll see what is left.

Of stuff still in staging I have:
* lis3l02dq (it's there because we probably want to add this part to the
   much more general st-sensors driver rather than moving it out as is).
* sca3000 (still there because we now have a better idea of how to handle
   chips with hardware buffers - route them through a software buffer,
   dropping the explicit trigger as done in the am35x driver last summer).

J

>>
>>> regarding staging/iio/magnetometer/hmc5843:
>>> the driver has one specific DEVICE_ATTR left (meas_conf), otherwise clean
>>> I think; so we could (a) document it as special ABI or (b) drop it
>>
>> Which is it?  It should be easy to delete a driver :)
> Drop the attribute, not the driver!
>>
>> thanks,
>>
>> greg k-h
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IIO drivers left in drivers/staging/

[Alexandre Belloni]

Hi,

On 18/06/2014 at 10:47:17 -0700, Greg KH wrote :
> On Wed, Jun 18, 2014 at 02:56:52PM +0200, Peter Meerwald wrote:
> > Hello Kristina,
> > 
> > > > Okay so right now I'm getting the following things I could work on:
> > > > 
> > > > 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
> > > > out of staging and seeing what other issues people find?)
> > > > 2) resolver/CDC ABI documentation cleanup
> > > > 3) dummy driver fake event interrupt hack
> > > > 4) Lars may have more ideas?
> > > > 
> > > > The plan is for me to start working on this stuff full time next week,
> > > > so if you think of anything more, please let me know!
> > > 
> > > Haven't heard back from you about this. Have you found anything else
> > > that needs to be done with staging IIO drivers before they can be moved out?
> > 
> > IIO is a bit problematic since testing usually requires possessing the 
> > sensor chip
> 
> Any specific chips / devices we should look into buying for these
> drivers to help make it easier to do development?
> 

I would say that the latest addition to the TODO file is quite valid ;)
We have been looking at moving the mxs-lradc out of staging for a while
now. It still has a few contributions coming from time to time and can
definitely be improved. The main thing to do would be to create an MFD.

I understand this may be a considerable amount of work but it has the
advantage of allowing to have a look at at least 3 different subsystems.

I am willing to review and test patches.

I would suggest that board:
http://www.crystalfontz.com/product/CFA921TS

It may not be the cheapeast one but it has good mainline support and I
know it well.

Crystalfontz provided me some of their boards so that I could give them
out at ELC. If you are interested in the topic, it may be worth asking
whether they are willing to sponsor you ;)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: IIO drivers left in drivers/staging/

[Greg KH]

On Thu, Jun 19, 2014 at 02:54:16PM +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 18/06/2014 at 10:47:17 -0700, Greg KH wrote :
> > On Wed, Jun 18, 2014 at 02:56:52PM +0200, Peter Meerwald wrote:
> > > Hello Kristina,
> > > 
> > > > > Okay so right now I'm getting the following things I could work on:
> > > > > 
> > > > > 1) prefixes on define constants for lpc32xx_ADC (then trying to move it
> > > > > out of staging and seeing what other issues people find?)
> > > > > 2) resolver/CDC ABI documentation cleanup
> > > > > 3) dummy driver fake event interrupt hack
> > > > > 4) Lars may have more ideas?
> > > > > 
> > > > > The plan is for me to start working on this stuff full time next week,
> > > > > so if you think of anything more, please let me know!
> > > > 
> > > > Haven't heard back from you about this. Have you found anything else
> > > > that needs to be done with staging IIO drivers before they can be moved out?
> > > 
> > > IIO is a bit problematic since testing usually requires possessing the 
> > > sensor chip
> > 
> > Any specific chips / devices we should look into buying for these
> > drivers to help make it easier to do development?
> > 
> 
> I would say that the latest addition to the TODO file is quite valid ;)
> We have been looking at moving the mxs-lradc out of staging for a while
> now. It still has a few contributions coming from time to time and can
> definitely be improved. The main thing to do would be to create an MFD.
> 
> I understand this may be a considerable amount of work but it has the
> advantage of allowing to have a look at at least 3 different subsystems.
> 
> I am willing to review and test patches.
> 
> I would suggest that board:
> http://www.crystalfontz.com/product/CFA921TS
> 
> It may not be the cheapeast one but it has good mainline support and I
> know it well.

What sensors does it have on it that are iio drivers that need fixing
up?

It's not that expensive, my budget for Linux devices can cover it...

thanks,

greg k-h

Re: IIO drivers left in drivers/staging/

[Alexandre Belloni]

On 20/06/2014 at 13:42:48 -0700, Greg KH wrote :
> > 
> > I would say that the latest addition to the TODO file is quite valid ;)
> > We have been looking at moving the mxs-lradc out of staging for a while
> > now. It still has a few contributions coming from time to time and can
> > definitely be improved. The main thing to do would be to create an MFD.
> > 
> > I understand this may be a considerable amount of work but it has the
> > advantage of allowing to have a look at at least 3 different subsystems.
> > 
> > I am willing to review and test patches.
> > 
> > I would suggest that board:
> > http://www.crystalfontz.com/product/CFA921TS
> > 
> > It may not be the cheapeast one but it has good mainline support and I
> > know it well.
> 
> What sensors does it have on it that are iio drivers that need fixing
> up?
> 

It is i.mx28 based so it has the mxs LRADC which is currently supported
through drivers/staging/iio/adc/mxs-lradc.c.
It is also a touchscreen controller, a temperature sensor and a battery
voltage monitor so it would make sense to create an mfd and move the
touchscreen part in the input subsystem and add a driver for the voltage
monitor in the power subsystem.

You can also have a look at that thread:
http://www.spinics.net/lists/linux-iio/msg11004.html

> It's not that expensive, my budget for Linux devices can cover it...
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: IIO drivers left in drivers/staging/

[Greg KH]

On Sat, Jun 21, 2014 at 09:55:22AM +0200, Alexandre Belloni wrote:
> On 20/06/2014 at 13:42:48 -0700, Greg KH wrote :
> > > 
> > > I would say that the latest addition to the TODO file is quite valid ;)
> > > We have been looking at moving the mxs-lradc out of staging for a while
> > > now. It still has a few contributions coming from time to time and can
> > > definitely be improved. The main thing to do would be to create an MFD.
> > > 
> > > I understand this may be a considerable amount of work but it has the
> > > advantage of allowing to have a look at at least 3 different subsystems.
> > > 
> > > I am willing to review and test patches.
> > > 
> > > I would suggest that board:
> > > http://www.crystalfontz.com/product/CFA921TS
> > > 
> > > It may not be the cheapeast one but it has good mainline support and I
> > > know it well.
> > 
> > What sensors does it have on it that are iio drivers that need fixing
> > up?
> > 
> 
> It is i.mx28 based so it has the mxs LRADC which is currently supported
> through drivers/staging/iio/adc/mxs-lradc.c.
> It is also a touchscreen controller, a temperature sensor and a battery
> voltage monitor so it would make sense to create an mfd and move the
> touchscreen part in the input subsystem and add a driver for the voltage
> monitor in the power subsystem.
> 
> You can also have a look at that thread:
> http://www.spinics.net/lists/linux-iio/msg11004.html

That sounds promising, I'll look it over.

thanks,

greg k-h