mbox series

[00/17] iio:adc:ad7280a Cleanup and proposed staging graduation.

Message ID 20210614113507.897732-1-jic23@kernel.org (mailing list archive)
Headers show
Series iio:adc:ad7280a Cleanup and proposed staging graduation. | expand

Message

Jonathan Cameron June 14, 2021, 11:34 a.m. UTC
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Hi All,

This one proved an interesting diversion.

Work done against a somewhat hacked up QEMU emulation of 3 daisy chained
ad7280a devices (18 channels).  Note that the emulation isn't complete
but does do chaining, CRC, and readout of channels etc in a fashion that
worked with the original driver (up to the bug in patch 1) and continues
to work with the updated version. I've not intention to upstream the
emulation (as would need to make it more completed and flexible), but
happy to share it with anyone who is interested.

I briefly flirted with posting a patch to just drop the driver entirely,
but the part is still available and it looked like fun + isn't going
to greatly impact maintainability of the subsystem long term so is low
cost even if it goes obsolete sometime soonish.

There are lots of things we could do after this set to improved the driver
and make things more flexible, but it should basically 'just work'

Anyhow, as normal for staging graduations, last patch has rename detection
turned off so that people can easily see what I am proposing we move
out of staging.

Jonathan Cameron (17):
  staging:iio:adc:ad7280a: Fix handing of device address bit reversing.
  staging:iio:adc:ad7280a: Register define cleanup.
  staging:iio:adc:ad7280a: rename _read() to _read_reg()
  staging:iio:adc:ad7280a: Split buff[2] into tx and rx parts
  staging:iio:adc:ad7280a: Use bitfield ops to managed fields in
    transfers.
  staging:iio:adc:ad7280a: Switch to standard event control
  staging:iio:adc:ad7280a: Standardize extended ABI naming
  staging:iio:adc:ad7280a: Drop unused timestamp channel.
  staging:iio:adc:ad7280a: Trivial comment formatting cleanup
  staging:iio:adc:ad7280a: Make oversampling_ratio a runtime control
  staging:iio:adc:ad7280a: Cleanup includes
  staging:iio:ad7280a: Reflect optionality of irq in ABI
  staging:iio:adc:ad7280a: Use a local dev pointer to avoid &spi->dev
  staging:iio:adc:ad7280a: Use device properties to replace platform
    data.
  dt-bindings:iio:adc:ad7280a: Add binding
  iio:adc:ad7280a: Document ABI for cell balance switches
  iio:adc:ad7280a: Move out of staging

 .../ABI/testing/sysfs-bus-iio-adc-ad7280a     |   14 +
 .../bindings/iio/adc/adi,ad7280a.yaml         |   87 ++
 drivers/iio/adc/Kconfig                       |   11 +
 drivers/iio/adc/Makefile                      |    1 +
 drivers/iio/adc/ad7280a.c                     | 1116 +++++++++++++++++
 drivers/staging/iio/adc/Kconfig               |   11 -
 drivers/staging/iio/adc/Makefile              |    1 -
 drivers/staging/iio/adc/ad7280a.c             | 1044 ---------------
 drivers/staging/iio/adc/ad7280a.h             |   37 -
 9 files changed, 1229 insertions(+), 1093 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a
 create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
 create mode 100644 drivers/iio/adc/ad7280a.c
 delete mode 100644 drivers/staging/iio/adc/ad7280a.c
 delete mode 100644 drivers/staging/iio/adc/ad7280a.h

Comments

Marcelo Schmitt June 22, 2021, 5:36 p.m. UTC | #1
Hey Jonathan,

On 06/14, Jonathan Cameron wrote:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> 
> Hi All,
> 
> This one proved an interesting diversion.
> 
> Work done against a somewhat hacked up QEMU emulation of 3 daisy chained
> ad7280a devices (18 channels).  Note that the emulation isn't complete
> but does do chaining, CRC, and readout of channels etc in a fashion that
> worked with the original driver (up to the bug in patch 1) and continues
> to work with the updated version. I've not intention to upstream the
> emulation (as would need to make it more completed and flexible), but
> happy to share it with anyone who is interested.

I'm interested in seeing your device emulation with QEMU.
I was looking at the ad7150 emulation you shared earlier this year but had
some trouble getting the i2c slave created.

Being able to see it running, I may feel more confident to provide a review
for this set :)

Regards,

Marcelo
> 
> I briefly flirted with posting a patch to just drop the driver entirely,
> but the part is still available and it looked like fun + isn't going
> to greatly impact maintainability of the subsystem long term so is low
> cost even if it goes obsolete sometime soonish.
> 
> There are lots of things we could do after this set to improved the driver
> and make things more flexible, but it should basically 'just work'
> 
> Anyhow, as normal for staging graduations, last patch has rename detection
> turned off so that people can easily see what I am proposing we move
> out of staging.
> 
> Jonathan Cameron (17):
>   staging:iio:adc:ad7280a: Fix handing of device address bit reversing.
>   staging:iio:adc:ad7280a: Register define cleanup.
>   staging:iio:adc:ad7280a: rename _read() to _read_reg()
>   staging:iio:adc:ad7280a: Split buff[2] into tx and rx parts
>   staging:iio:adc:ad7280a: Use bitfield ops to managed fields in
>     transfers.
>   staging:iio:adc:ad7280a: Switch to standard event control
>   staging:iio:adc:ad7280a: Standardize extended ABI naming
>   staging:iio:adc:ad7280a: Drop unused timestamp channel.
>   staging:iio:adc:ad7280a: Trivial comment formatting cleanup
>   staging:iio:adc:ad7280a: Make oversampling_ratio a runtime control
>   staging:iio:adc:ad7280a: Cleanup includes
>   staging:iio:ad7280a: Reflect optionality of irq in ABI
>   staging:iio:adc:ad7280a: Use a local dev pointer to avoid &spi->dev
>   staging:iio:adc:ad7280a: Use device properties to replace platform
>     data.
>   dt-bindings:iio:adc:ad7280a: Add binding
>   iio:adc:ad7280a: Document ABI for cell balance switches
>   iio:adc:ad7280a: Move out of staging
> 
>  .../ABI/testing/sysfs-bus-iio-adc-ad7280a     |   14 +
>  .../bindings/iio/adc/adi,ad7280a.yaml         |   87 ++
>  drivers/iio/adc/Kconfig                       |   11 +
>  drivers/iio/adc/Makefile                      |    1 +
>  drivers/iio/adc/ad7280a.c                     | 1116 +++++++++++++++++
>  drivers/staging/iio/adc/Kconfig               |   11 -
>  drivers/staging/iio/adc/Makefile              |    1 -
>  drivers/staging/iio/adc/ad7280a.c             | 1044 ---------------
>  drivers/staging/iio/adc/ad7280a.h             |   37 -
>  9 files changed, 1229 insertions(+), 1093 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
>  create mode 100644 drivers/iio/adc/ad7280a.c
>  delete mode 100644 drivers/staging/iio/adc/ad7280a.c
>  delete mode 100644 drivers/staging/iio/adc/ad7280a.h
> 
> -- 
> 2.32.0
>
Jonathan Cameron June 23, 2021, 8:37 a.m. UTC | #2
On Tue, 22 Jun 2021 14:36:17 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> Hey Jonathan,
> 
> On 06/14, Jonathan Cameron wrote:
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > 
> > Hi All,
> > 
> > This one proved an interesting diversion.
> > 
> > Work done against a somewhat hacked up QEMU emulation of 3 daisy chained
> > ad7280a devices (18 channels).  Note that the emulation isn't complete
> > but does do chaining, CRC, and readout of channels etc in a fashion that
> > worked with the original driver (up to the bug in patch 1) and continues
> > to work with the updated version. I've not intention to upstream the
> > emulation (as would need to make it more completed and flexible), but
> > happy to share it with anyone who is interested.  
> 
> I'm interested in seeing your device emulation with QEMU.
> I was looking at the ad7150 emulation you shared earlier this year but had
> some trouble getting the i2c slave created.

Sure.  Let me do a bit of tidying up they I'll push a suitable branch out.
(probably will still have lots of stuff missing!)

Might take a little while to get to this though.

> 
> Being able to see it running, I may feel more confident to provide a review
> for this set :)

:)

> 
> Regards,
> 
> Marcelo
> > 
> > I briefly flirted with posting a patch to just drop the driver entirely,
> > but the part is still available and it looked like fun + isn't going
> > to greatly impact maintainability of the subsystem long term so is low
> > cost even if it goes obsolete sometime soonish.
> > 
> > There are lots of things we could do after this set to improved the driver
> > and make things more flexible, but it should basically 'just work'
> > 
> > Anyhow, as normal for staging graduations, last patch has rename detection
> > turned off so that people can easily see what I am proposing we move
> > out of staging.
> > 
> > Jonathan Cameron (17):
> >   staging:iio:adc:ad7280a: Fix handing of device address bit reversing.
> >   staging:iio:adc:ad7280a: Register define cleanup.
> >   staging:iio:adc:ad7280a: rename _read() to _read_reg()
> >   staging:iio:adc:ad7280a: Split buff[2] into tx and rx parts
> >   staging:iio:adc:ad7280a: Use bitfield ops to managed fields in
> >     transfers.
> >   staging:iio:adc:ad7280a: Switch to standard event control
> >   staging:iio:adc:ad7280a: Standardize extended ABI naming
> >   staging:iio:adc:ad7280a: Drop unused timestamp channel.
> >   staging:iio:adc:ad7280a: Trivial comment formatting cleanup
> >   staging:iio:adc:ad7280a: Make oversampling_ratio a runtime control
> >   staging:iio:adc:ad7280a: Cleanup includes
> >   staging:iio:ad7280a: Reflect optionality of irq in ABI
> >   staging:iio:adc:ad7280a: Use a local dev pointer to avoid &spi->dev
> >   staging:iio:adc:ad7280a: Use device properties to replace platform
> >     data.
> >   dt-bindings:iio:adc:ad7280a: Add binding
> >   iio:adc:ad7280a: Document ABI for cell balance switches
> >   iio:adc:ad7280a: Move out of staging
> > 
> >  .../ABI/testing/sysfs-bus-iio-adc-ad7280a     |   14 +
> >  .../bindings/iio/adc/adi,ad7280a.yaml         |   87 ++
> >  drivers/iio/adc/Kconfig                       |   11 +
> >  drivers/iio/adc/Makefile                      |    1 +
> >  drivers/iio/adc/ad7280a.c                     | 1116 +++++++++++++++++
> >  drivers/staging/iio/adc/Kconfig               |   11 -
> >  drivers/staging/iio/adc/Makefile              |    1 -
> >  drivers/staging/iio/adc/ad7280a.c             | 1044 ---------------
> >  drivers/staging/iio/adc/ad7280a.h             |   37 -
> >  9 files changed, 1229 insertions(+), 1093 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a
> >  create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
> >  create mode 100644 drivers/iio/adc/ad7280a.c
> >  delete mode 100644 drivers/staging/iio/adc/ad7280a.c
> >  delete mode 100644 drivers/staging/iio/adc/ad7280a.h
> > 
> > -- 
> > 2.32.0
> >
Jonathan Cameron July 11, 2021, 2:50 p.m. UTC | #3
On Wed, 23 Jun 2021 09:37:41 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Tue, 22 Jun 2021 14:36:17 -0300
> Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> 
> > Hey Jonathan,
> > 
> > On 06/14, Jonathan Cameron wrote:  
> > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > 
> > > Hi All,
> > > 
> > > This one proved an interesting diversion.
> > > 
> > > Work done against a somewhat hacked up QEMU emulation of 3 daisy chained
> > > ad7280a devices (18 channels).  Note that the emulation isn't complete
> > > but does do chaining, CRC, and readout of channels etc in a fashion that
> > > worked with the original driver (up to the bug in patch 1) and continues
> > > to work with the updated version. I've not intention to upstream the
> > > emulation (as would need to make it more completed and flexible), but
> > > happy to share it with anyone who is interested.    
> > 
> > I'm interested in seeing your device emulation with QEMU.
> > I was looking at the ad7150 emulation you shared earlier this year but had
> > some trouble getting the i2c slave created.  
> 
> Sure.  Let me do a bit of tidying up they I'll push a suitable branch out.
> (probably will still have lots of stuff missing!)
> 
> Might take a little while to get to this though.

I pretended to myself for a few weeks that I'd get around to tidying this up in
a remotely meaningful way.  That's clearly not happening so I pushed out the
untidy version with appropriate eats babies messages:

https://github.com/jic23/qemu/commits/ad7280a-hacks

Note there is loads of stuff that isn't implemented as it was developed alongside
this patch series to verify individual patches rather than with the intent of
actually emulating the device.

It's hard coded to 2 a chain of 3 ad7280a devices because that seemed to hit most possible
corner cases.

The top commit has the launch string I'm using.  You'll need a filesystem, but
you can probably use one of the convenient ones debian posts as nocloud cloud
images. 

There is some info on that on people.kernel.org/jic23 as I wrote up how to test
CXL stuff on ARM recently and gave guidance on easy ways to get a filesystem.
http://cdimage.debian.org/cdimage/cloud/sid/daily/20210702-691/debian-sid-nocloud-arm64-daily-20210702-691.qcow2
will probably work and is more recent than the one linked from that blog post. 

Give me a shout if you need more specific guidance than this very very rough guide!

I mentioned this thread in the diversion the rust on linux thread took into
use of QEMU to emulate devices which motivated me to stop being lazy and at least
post this hideous version.  Probably the most useful bit is how to get a working
spi device emulated on the arm virt machine as that is very handy for all manner
of testing.  One day someone might implement a large set of IIO device emulation
and bolt it into a CI...

Jonathan

> 
> > 
> > Being able to see it running, I may feel more confident to provide a review
> > for this set :)  
> 
> :)
> 
> > 
> > Regards,
> > 
> > Marcelo  
> > > 
> > > I briefly flirted with posting a patch to just drop the driver entirely,
> > > but the part is still available and it looked like fun + isn't going
> > > to greatly impact maintainability of the subsystem long term so is low
> > > cost even if it goes obsolete sometime soonish.
> > > 
> > > There are lots of things we could do after this set to improved the driver
> > > and make things more flexible, but it should basically 'just work'
> > > 
> > > Anyhow, as normal for staging graduations, last patch has rename detection
> > > turned off so that people can easily see what I am proposing we move
> > > out of staging.
> > > 
> > > Jonathan Cameron (17):
> > >   staging:iio:adc:ad7280a: Fix handing of device address bit reversing.
> > >   staging:iio:adc:ad7280a: Register define cleanup.
> > >   staging:iio:adc:ad7280a: rename _read() to _read_reg()
> > >   staging:iio:adc:ad7280a: Split buff[2] into tx and rx parts
> > >   staging:iio:adc:ad7280a: Use bitfield ops to managed fields in
> > >     transfers.
> > >   staging:iio:adc:ad7280a: Switch to standard event control
> > >   staging:iio:adc:ad7280a: Standardize extended ABI naming
> > >   staging:iio:adc:ad7280a: Drop unused timestamp channel.
> > >   staging:iio:adc:ad7280a: Trivial comment formatting cleanup
> > >   staging:iio:adc:ad7280a: Make oversampling_ratio a runtime control
> > >   staging:iio:adc:ad7280a: Cleanup includes
> > >   staging:iio:ad7280a: Reflect optionality of irq in ABI
> > >   staging:iio:adc:ad7280a: Use a local dev pointer to avoid &spi->dev
> > >   staging:iio:adc:ad7280a: Use device properties to replace platform
> > >     data.
> > >   dt-bindings:iio:adc:ad7280a: Add binding
> > >   iio:adc:ad7280a: Document ABI for cell balance switches
> > >   iio:adc:ad7280a: Move out of staging
> > > 
> > >  .../ABI/testing/sysfs-bus-iio-adc-ad7280a     |   14 +
> > >  .../bindings/iio/adc/adi,ad7280a.yaml         |   87 ++
> > >  drivers/iio/adc/Kconfig                       |   11 +
> > >  drivers/iio/adc/Makefile                      |    1 +
> > >  drivers/iio/adc/ad7280a.c                     | 1116 +++++++++++++++++
> > >  drivers/staging/iio/adc/Kconfig               |   11 -
> > >  drivers/staging/iio/adc/Makefile              |    1 -
> > >  drivers/staging/iio/adc/ad7280a.c             | 1044 ---------------
> > >  drivers/staging/iio/adc/ad7280a.h             |   37 -
> > >  9 files changed, 1229 insertions(+), 1093 deletions(-)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a
> > >  create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
> > >  create mode 100644 drivers/iio/adc/ad7280a.c
> > >  delete mode 100644 drivers/staging/iio/adc/ad7280a.c
> > >  delete mode 100644 drivers/staging/iio/adc/ad7280a.h
> > > 
> > > -- 
> > > 2.32.0
> > >     
>
Marcelo Schmitt July 12, 2021, 6:08 p.m. UTC | #4
On 07/11, Jonathan Cameron wrote:
> On Wed, 23 Jun 2021 09:37:41 +0100
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> 
> > On Tue, 22 Jun 2021 14:36:17 -0300
> > Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> > 
> > > Hey Jonathan,
> > > 
> > > On 06/14, Jonathan Cameron wrote:  
> > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > 
> > > > Hi All,
> > > > 
> > > > This one proved an interesting diversion.
> > > > 
> > > > Work done against a somewhat hacked up QEMU emulation of 3 daisy chained
> > > > ad7280a devices (18 channels).  Note that the emulation isn't complete
> > > > but does do chaining, CRC, and readout of channels etc in a fashion that
> > > > worked with the original driver (up to the bug in patch 1) and continues
> > > > to work with the updated version. I've not intention to upstream the
> > > > emulation (as would need to make it more completed and flexible), but
> > > > happy to share it with anyone who is interested.    
> > > 
> > > I'm interested in seeing your device emulation with QEMU.
> > > I was looking at the ad7150 emulation you shared earlier this year but had
> > > some trouble getting the i2c slave created.  
> > 
> > Sure.  Let me do a bit of tidying up they I'll push a suitable branch out.
> > (probably will still have lots of stuff missing!)
> > 
> > Might take a little while to get to this though.
> 
> I pretended to myself for a few weeks that I'd get around to tidying this up in
> a remotely meaningful way.  That's clearly not happening so I pushed out the
> untidy version with appropriate eats babies messages:
> 
> https://github.com/jic23/qemu/commits/ad7280a-hacks

Thanks. I don't mind if it's not exactly tidy or elegant code provided I
can understand whats going on and get it running.

> 
> Note there is loads of stuff that isn't implemented as it was developed alongside
> this patch series to verify individual patches rather than with the intent of
> actually emulating the device.
> 
OK, will be aware of that.

> It's hard coded to 2 a chain of 3 ad7280a devices because that seemed to hit most possible
> corner cases.
> 
> The top commit has the launch string I'm using.  You'll need a filesystem, but
> you can probably use one of the convenient ones debian posts as nocloud cloud
> images. 
> 
> There is some info on that on people.kernel.org/jic23 as I wrote up how to test
> CXL stuff on ARM recently and gave guidance on easy ways to get a filesystem.
> http://cdimage.debian.org/cdimage/cloud/sid/daily/20210702-691/debian-sid-nocloud-arm64-daily-20210702-691.qcow2
> will probably work and is more recent than the one linked from that blog post. 

I was using a debian imgage created from following the instructions on a
tutorial pointed by the QEMU docs.
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
Anyhow, I'll chance to the nocloud one if see things don't get working.

> 
> Give me a shout if you need more specific guidance than this very very rough guide!

Sure, let's see if I can get through it now. Otherwise ...

> 
> I mentioned this thread in the diversion the rust on linux thread took into
> use of QEMU to emulate devices which motivated me to stop being lazy and at least
> post this hideous version.  Probably the most useful bit is how to get a working
> spi device emulated on the arm virt machine as that is very handy for all manner
> of testing.  One day someone might implement a large set of IIO device emulation
> and bolt it into a CI...

Agree, it's hard to get IIO drivers runtime tested because we often don't
have the required hardware to do it. I think emulation would help us with
that or, at least, would give us a little bit more confidence in our
changes than just relying on sharp eyes and compile/static tests.
Puching that into a CI would also be rather nice.

> 
> Jonathan
> 
> > 
> > > 
> > > Being able to see it running, I may feel more confident to provide a review
> > > for this set :)  
> > 
> > :)
> > 
> > > 
> > > Regards,
> > > 
> > > Marcelo  
> > > > 
> > > > I briefly flirted with posting a patch to just drop the driver entirely,
> > > > but the part is still available and it looked like fun + isn't going
> > > > to greatly impact maintainability of the subsystem long term so is low
> > > > cost even if it goes obsolete sometime soonish.
> > > > 
> > > > There are lots of things we could do after this set to improved the driver
> > > > and make things more flexible, but it should basically 'just work'
> > > > 
> > > > Anyhow, as normal for staging graduations, last patch has rename detection
> > > > turned off so that people can easily see what I am proposing we move
> > > > out of staging.
> > > > 
> > > > Jonathan Cameron (17):
> > > >   staging:iio:adc:ad7280a: Fix handing of device address bit reversing.
> > > >   staging:iio:adc:ad7280a: Register define cleanup.
> > > >   staging:iio:adc:ad7280a: rename _read() to _read_reg()
> > > >   staging:iio:adc:ad7280a: Split buff[2] into tx and rx parts
> > > >   staging:iio:adc:ad7280a: Use bitfield ops to managed fields in
> > > >     transfers.
> > > >   staging:iio:adc:ad7280a: Switch to standard event control
> > > >   staging:iio:adc:ad7280a: Standardize extended ABI naming
> > > >   staging:iio:adc:ad7280a: Drop unused timestamp channel.
> > > >   staging:iio:adc:ad7280a: Trivial comment formatting cleanup
> > > >   staging:iio:adc:ad7280a: Make oversampling_ratio a runtime control
> > > >   staging:iio:adc:ad7280a: Cleanup includes
> > > >   staging:iio:ad7280a: Reflect optionality of irq in ABI
> > > >   staging:iio:adc:ad7280a: Use a local dev pointer to avoid &spi->dev
> > > >   staging:iio:adc:ad7280a: Use device properties to replace platform
> > > >     data.
> > > >   dt-bindings:iio:adc:ad7280a: Add binding
> > > >   iio:adc:ad7280a: Document ABI for cell balance switches
> > > >   iio:adc:ad7280a: Move out of staging
> > > > 
> > > >  .../ABI/testing/sysfs-bus-iio-adc-ad7280a     |   14 +
> > > >  .../bindings/iio/adc/adi,ad7280a.yaml         |   87 ++
> > > >  drivers/iio/adc/Kconfig                       |   11 +
> > > >  drivers/iio/adc/Makefile                      |    1 +
> > > >  drivers/iio/adc/ad7280a.c                     | 1116 +++++++++++++++++
> > > >  drivers/staging/iio/adc/Kconfig               |   11 -
> > > >  drivers/staging/iio/adc/Makefile              |    1 -
> > > >  drivers/staging/iio/adc/ad7280a.c             | 1044 ---------------
> > > >  drivers/staging/iio/adc/ad7280a.h             |   37 -
> > > >  9 files changed, 1229 insertions(+), 1093 deletions(-)
> > > >  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a
> > > >  create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml
> > > >  create mode 100644 drivers/iio/adc/ad7280a.c
> > > >  delete mode 100644 drivers/staging/iio/adc/ad7280a.c
> > > >  delete mode 100644 drivers/staging/iio/adc/ad7280a.h
> > > > 
> > > > -- 
> > > > 2.32.0
> > > >     
> > 
>
Marcelo Schmitt Aug. 5, 2021, 3:52 a.m. UTC | #5
[...]

> > 
> > Note there is loads of stuff that isn't implemented as it was developed alongside
> > this patch series to verify individual patches rather than with the intent of
> > actually emulating the device.
> > 
> OK, will be aware of that.
> 
> > It's hard coded to 2 a chain of 3 ad7280a devices because that seemed to hit most possible
> > corner cases.
> > 
> > The top commit has the launch string I'm using.  You'll need a filesystem, but
> > you can probably use one of the convenient ones debian posts as nocloud cloud
> > images. 
> > 
> > There is some info on that on people.kernel.org/jic23 as I wrote up how to test
> > CXL stuff on ARM recently and gave guidance on easy ways to get a filesystem.
> > http://cdimage.debian.org/cdimage/cloud/sid/daily/20210702-691/debian-sid-nocloud-arm64-daily-20210702-691.qcow2
> > will probably work and is more recent than the one linked from that blog post. 
> 
> I was using a debian imgage created from following the instructions on a
> tutorial pointed by the QEMU docs.
> https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
> Anyhow, I'll chance to the nocloud one if see things don't get working.
> 
> > 
> > Give me a shout if you need more specific guidance than this very very rough guide!
> 
> Sure, let's see if I can get through it now. Otherwise ...

I've managed to get it running and see the emulated ad7280a working.
Still getting some trouble with the ad7150 emulation though.
I added a pull request with some comments about the ad7150 emulation on the
github repository. 
Overall I don't think it was so hacky, I just wonder if it could have been
done more cleanly by passing a custom dtb in the launching string. The hacks
at virt.c are mostly to add the busses, add the device nodes, and connect
device gpio to interrupt lines. We could do it all by editing a dt, right?
Anyhow, thanks a lot for sharing this stuff.

> 
> > 
> > I mentioned this thread in the diversion the rust on linux thread took into
> > use of QEMU to emulate devices which motivated me to stop being lazy and at least
> > post this hideous version.  Probably the most useful bit is how to get a working
> > spi device emulated on the arm virt machine as that is very handy for all manner
> > of testing.  One day someone might implement a large set of IIO device emulation
> > and bolt it into a CI...
> 
> Agree, it's hard to get IIO drivers runtime tested because we often don't
> have the required hardware to do it. I think emulation would help us with
> that or, at least, would give us a little bit more confidence in our
> changes than just relying on sharp eyes and compile/static tests.
> Puching that into a CI would also be rather nice.
> 
> > 
> > Jonathan
> > 
> > > 
> > > > 
> > > > Being able to see it running, I may feel more confident to provide a review
> > > > for this set :)  

Guess I've been too optimistic. The way things are going I may take a few
more weeks to have a closer look at all the patches. I'll try to make it
before the next merge window or give up otherwise. It's not reasonable to
ask you wait more since this set has been sitting on the list for so long.


[...]
Jonathan Cameron Aug. 5, 2021, 12:51 p.m. UTC | #6
On Thu, 5 Aug 2021 00:52:04 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> [...]
> 
> > > 
> > > Note there is loads of stuff that isn't implemented as it was developed alongside
> > > this patch series to verify individual patches rather than with the intent of
> > > actually emulating the device.
> > >   
> > OK, will be aware of that.
> >   
> > > It's hard coded to 2 a chain of 3 ad7280a devices because that seemed to hit most possible
> > > corner cases.
> > > 
> > > The top commit has the launch string I'm using.  You'll need a filesystem, but
> > > you can probably use one of the convenient ones debian posts as nocloud cloud
> > > images. 
> > > 
> > > There is some info on that on people.kernel.org/jic23 as I wrote up how to test
> > > CXL stuff on ARM recently and gave guidance on easy ways to get a filesystem.
> > > http://cdimage.debian.org/cdimage/cloud/sid/daily/20210702-691/debian-sid-nocloud-arm64-daily-20210702-691.qcow2
> > > will probably work and is more recent than the one linked from that blog post.   
> > 
> > I was using a debian imgage created from following the instructions on a
> > tutorial pointed by the QEMU docs.
> > https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
> > Anyhow, I'll chance to the nocloud one if see things don't get working.
> >   
> > > 
> > > Give me a shout if you need more specific guidance than this very very rough guide!  
> > 
> > Sure, let's see if I can get through it now. Otherwise ...  
> 
> I've managed to get it running and see the emulated ad7280a working.
> Still getting some trouble with the ad7150 emulation though.
> I added a pull request with some comments about the ad7150 emulation on the
> github repository. 

Will take a look at some point.  Thanks.

> Overall I don't think it was so hacky, I just wonder if it could have been
> done more cleanly by passing a custom dtb in the launching string. The hacks
> at virt.c are mostly to add the busses, add the device nodes, and connect
> device gpio to interrupt lines. We could do it all by editing a dt, right?
> Anyhow, thanks a lot for sharing this stuff.

That's the alternative, though you also need to actually create the relevant
devices.  The dtb stuff is lengthy but really simple to do, it's also somewhat
resilient to other changes in how the virt model works (address changes etc).

Given I was there anyway, it seemed easier to do it all in one place.
 
> 
> >   
> > > 
> > > I mentioned this thread in the diversion the rust on linux thread took into
> > > use of QEMU to emulate devices which motivated me to stop being lazy and at least
> > > post this hideous version.  Probably the most useful bit is how to get a working
> > > spi device emulated on the arm virt machine as that is very handy for all manner
> > > of testing.  One day someone might implement a large set of IIO device emulation
> > > and bolt it into a CI...  
> > 
> > Agree, it's hard to get IIO drivers runtime tested because we often don't
> > have the required hardware to do it. I think emulation would help us with
> > that or, at least, would give us a little bit more confidence in our
> > changes than just relying on sharp eyes and compile/static tests.
> > Puching that into a CI would also be rather nice.
> >   
> > > 
> > > Jonathan
> > >   
> > > >   
> > > > > 
> > > > > Being able to see it running, I may feel more confident to provide a review
> > > > > for this set :)    
> 
> Guess I've been too optimistic. The way things are going I may take a few
> more weeks to have a closer look at all the patches. I'll try to make it
> before the next merge window or give up otherwise. It's not reasonable to
> ask you wait more since this set has been sitting on the list for so long.

Don't worry about it.  Driver was in staging a long time. It can wait as
long as we know it will move forwards eventually!

Jonathan

> 
> 
> [...]