Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

[Prince Kumar]

Dear Linux IIO Maintainers,

I hope you are doing well. I am interested in contributing to the
Linux Industrial I/O (IIO) subsystem as part of GSoC 2025 under the
Linux Foundation. I would appreciate your feedback on my project idea
to ensure it aligns with the community's goals and best practices.

Project Proposal: ADE9113 IIO Driver Development

My goal is to develop a mainline-compatible Linux kernel driver for
the ADE9113 ADC (or similar SPI-based ADCs), enabling seamless
integration into the IIO subsystem. The driver will expose sensor data
via sysfs, libiio, and standard Linux interfaces, making it accessible
for various applications.

Technical Approach
1. IIO Driver Implementation:
Develop a modular and reusable kernel driver for ADE9113, ensuring
compliance with IIO standards.
Implement buffered and direct register read/write methods for
real-time data access.

2. Extensibility & Optimization:
Design the driver with flexible Device Tree (DT) bindings, allowing
support for other SPI-based ADCs with similar architectures.
Explore an MCU-assisted vs. direct SPI approach to evaluate
performance and CPU overhead trade-offs.

3. Testing & Documentation:
Provide unit tests using kselftest or libiio to validate the driver.
Write comprehensive kernel documentation to guide future contributors.
Ensure compatibility with existing Linux tools for IIO sensor data
visualization.

Community Involvement & Next Steps
I have reviewed existing IIO ADC drivers and the Linux IIO framework
to ensure this proposal aligns with upstream development goals. I
would greatly appreciate your input on:

Feasibility: Is this project a good fit for IIO and GSoC?
Driver Design: Are there any best practices or existing reference
drivers I should study?
Additional Considerations: Are there specific IIO guidelines I should follow?

I am eager to receive feedback and refine my approach to make a
meaningful contribution. Looking forward to your thoughts!

Best regards,
Prince Kumar

Re: Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

[Jonathan Cameron]

On Mon, 3 Mar 2025 22:15:38 +0530
Prince Kumar <855princekumar@gmail.com> wrote:

> Dear Linux IIO Maintainers,
> 
> I hope you are doing well. I am interested in contributing to the
> Linux Industrial I/O (IIO) subsystem as part of GSoC 2025 under the
> Linux Foundation. I would appreciate your feedback on my project idea
> to ensure it aligns with the community's goals and best practices.
> 
> Project Proposal: ADE9113 IIO Driver Development
> 
> My goal is to develop a mainline-compatible Linux kernel driver for
> the ADE9113 ADC (or similar SPI-based ADCs), enabling seamless
> integration into the IIO subsystem. The driver will expose sensor data
> via sysfs, libiio, and standard Linux interfaces, making it accessible
> for various applications.
> 
> Technical Approach
> 1. IIO Driver Implementation:
> Develop a modular and reusable kernel driver for ADE9113, ensuring
> compliance with IIO standards.
> Implement buffered and direct register read/write methods for
> real-time data access.
> 
> 2. Extensibility & Optimization:
> Design the driver with flexible Device Tree (DT) bindings, allowing
> support for other SPI-based ADCs with similar architectures.

This is an interesting comment.  On what basis do you plan to decide
the trade off between flexibility and maintainability of that binding?
It's rare to put much effort into making a DT binding for a specific
part flexible in this way (as opposed to generic shared bindings that
aren't specific to a part like this in adc.yaml)

> Explore an MCU-assisted vs. direct SPI approach to evaluate
> performance and CPU overhead trade-offs.

Perhaps expand a little on this.  You are talking about something
not particularly standard so anyone reviewing this doc is likely
to want to know if it is a well thought out plan or just a vague
idea.

> 
> 3. Testing & Documentation:
> Provide unit tests using kselftest or libiio to validate the driver.
> Write comprehensive kernel documentation to guide future contributors.
> Ensure compatibility with existing Linux tools for IIO sensor data
> visualization.
> 
> Community Involvement & Next Steps
> I have reviewed existing IIO ADC drivers and the Linux IIO framework
> to ensure this proposal aligns with upstream development goals. I
> would greatly appreciate your input on:
> 
> Feasibility: Is this project a good fit for IIO and GSoC?
> Driver Design: Are there any best practices or existing reference
> drivers I should study?

Generally no, but we have the dummy fake driver in iio/dummy/ that
is there to exercise interfaces etc without hardware.  Otherwise
we don't maintain any specific driver to current best practice so
you may just want to look at recent drivers for suitable references.

> Additional Considerations: Are there specific IIO guidelines I should follow?

Follow local coding style.  There are subtle differences across
the kernel but mostly we want to see a driver that 'looks and smells'
like other drivers.  Keep innovation to where it is needed. In most
cases copying and adapting is a better plan than inventing something
new.

Jonathan

> 
> I am eager to receive feedback and refine my approach to make a
> meaningful contribution. Looking forward to your thoughts!
> 
> Best regards,
> Prince Kumar
> 

Re: Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

[Prince Kumar]

Hi Jonathan,

Thanks for your valuable feedback! Your insights are really helpful in
refining my approach and ensuring alignment with best practices.

1. DT Binding Flexibility:
   I initially considered making the DT binding adaptable for similar
SPI-based ADCs to potentially support minor hardware variations with
minimal changes. However, your point about maintainability makes
sense, and I see that most existing bindings tend to be more specific.
I’ll revisit this and reconsider whether a part-specific approach
would be more appropriate. If there are examples of flexible but
maintainable bindings worth looking into, I’d appreciate any pointers.

2. MCU-Assisted vs. Direct SPI:
   This was more of an exploratory idea rather than a fully defined
plan. My initial thought was to assess whether offloading certain
operations to an MCU (e.g., pre-processing or buffering) could offer
benefits over direct SPI communication with the Linux system. Given
that this isn’t a typical approach, I’ll take a step back and ensure I
properly evaluate the feasibility and trade-offs before including it
in the proposal. If there are existing implementations that explore
similar optimizations, I’d be keen to study them.

3. Reference Drivers & Guidelines:
   I’ll definitely check out the iio/dummy/ driver for understanding
interface testing and take a closer look at recent ADC drivers to
align with best practices. Also, I’ll make sure to follow the Linux
kernel coding style closely and avoid unnecessary deviations.

I really appreciate your feedback. It's helping me reconsider certain
aspects of the plan to ensure it fits well within the IIO framework.
I'm looking forward to any further insights you might have.

Best regards,
Prince Kumar

Re: Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

[Jonathan Cameron]

On Mon, 10 Mar 2025 10:33:44 +0530
Prince Kumar <855princekumar@gmail.com> wrote:

> Hi Jonathan,
> 
> Thanks for your valuable feedback! Your insights are really helpful in
> refining my approach and ensuring alignment with best practices.
> 
> 1. DT Binding Flexibility:
>    I initially considered making the DT binding adaptable for similar
> SPI-based ADCs to potentially support minor hardware variations with
> minimal changes. However, your point about maintainability makes
> sense, and I see that most existing bindings tend to be more specific.
> I’ll revisit this and reconsider whether a part-specific approach
> would be more appropriate. If there are examples of flexible but
> maintainable bindings worth looking into, I’d appreciate any pointers.

The problem with increasing flexibility is that in usually means
more complex matching rules (see allOf/oneOf statements in existing
bindings) to ensure we require what is needed for a given specific
device.  Those are a lot harder to read than separate files but do
make sense if there are only one or two minor differences between
a small number of devices.

> 
> 2. MCU-Assisted vs. Direct SPI:
>    This was more of an exploratory idea rather than a fully defined
> plan. My initial thought was to assess whether offloading certain
> operations to an MCU (e.g., pre-processing or buffering) could offer
> benefits over direct SPI communication with the Linux system. Given
> that this isn’t a typical approach, I’ll take a step back and ensure I
> properly evaluate the feasibility and trade-offs before including it
> in the proposal. If there are existing implementations that explore
> similar optimizations, I’d be keen to study them.

There is SPI offload logic in the kernel that will merge this cycle.
(it's in the IIO tree on git.kernel.org togreg branch

Expanding that to MCU based handling (all implementations are currently
FPGA based) would be an interesting project. May be too complex to fit
in the timescale of a GSOC.  Perhaps a valid stretch goal though if the
rest falls in place quickly.

Jonathan

Re: Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

[Prince Kumar]

Hi Jonathan,

Thanks for the valuable insights!

DT Binding Flexibility: I see how increased flexibility can complicate
matching rules. I'll lean towards a part-specific binding unless
there's a strong case for generalization, and I'll review adc.yaml for
best practices.

MCU-Assisted vs. Direct SPI: I’ll check the IIO tree (togreg branch)
for SPI offload logic. Adapting it for an MCU is intriguing but likely
beyond GSoC’s scope—could be a stretch goal if time permits.

Reference & Guidelines: I’ll align with recent ADC drivers and
iio/dummy/, ensuring consistency with IIO standards.

Appreciate the guidance—it's helping refine the approach. Let me know
if there’s anything else worth considering!

Best,
Prince Kumar

On Tue, Mar 11, 2025 at 1:02 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Mon, 10 Mar 2025 10:33:44 +0530
> Prince Kumar <855princekumar@gmail.com> wrote:
>
> > Hi Jonathan,
> >
> > Thanks for your valuable feedback! Your insights are really helpful in
> > refining my approach and ensuring alignment with best practices.
> >
> > 1. DT Binding Flexibility:
> >    I initially considered making the DT binding adaptable for similar
> > SPI-based ADCs to potentially support minor hardware variations with
> > minimal changes. However, your point about maintainability makes
> > sense, and I see that most existing bindings tend to be more specific.
> > I’ll revisit this and reconsider whether a part-specific approach
> > would be more appropriate. If there are examples of flexible but
> > maintainable bindings worth looking into, I’d appreciate any pointers.
>
> The problem with increasing flexibility is that in usually means
> more complex matching rules (see allOf/oneOf statements in existing
> bindings) to ensure we require what is needed for a given specific
> device.  Those are a lot harder to read than separate files but do
> make sense if there are only one or two minor differences between
> a small number of devices.
>
> >
> > 2. MCU-Assisted vs. Direct SPI:
> >    This was more of an exploratory idea rather than a fully defined
> > plan. My initial thought was to assess whether offloading certain
> > operations to an MCU (e.g., pre-processing or buffering) could offer
> > benefits over direct SPI communication with the Linux system. Given
> > that this isn’t a typical approach, I’ll take a step back and ensure I
> > properly evaluate the feasibility and trade-offs before including it
> > in the proposal. If there are existing implementations that explore
> > similar optimizations, I’d be keen to study them.
>
> There is SPI offload logic in the kernel that will merge this cycle.
> (it's in the IIO tree on git.kernel.org togreg branch
>
> Expanding that to MCU based handling (all implementations are currently
> FPGA based) would be an interesting project. May be too complex to fit
> in the timescale of a GSOC.  Perhaps a valid stretch goal though if the
> rest falls in place quickly.
>
> Jonathan
>


-- 
Regards,
Prince Kumar
Phone: +91-8557032850(M), 8556911521(M)