Re: Doubts in getting started with the Analog AD7928 driver

[Daniel Junho <djunho@gmail.com>]

Hello.

After some effort to extend the AD7923 to include the AD7928, I got
stuck because it won't work.

After several days trying to figure out, I could use an oscilloscope
to analyze and, it seems that the cs_change does not affect the
driver.

```
  struct spi_transfer t[] = {
           {
                   .tx_buf = &st->tx_buf[0],
                   .len = 2,
                   .cs_change = 1,
           }, {
                   .rx_buf = &st->rx_buf[0],
                   .len = 2,
           },
   };
   ret = spi_sync_transfer(st->spi, t, ARRAY_SIZE(t));
```

The code above sends the first cmd and does not deselect the cs to get
the answer.

I am using kernel 4.4.107 from Toradex to deploy the driver. That is
the version used on the project of the board.

Does anyone have any idea what I am doing wrong? Should I update the
kernel, or it should work as well in this version? Or any ideas of how
to debug it?

Daniel E. M. Junho


On Wed, Sep 18, 2019 at 3:13 AM Ardelean, Alexandru
<alexandru.Ardelean@analog.com> wrote:
>
> On Tue, 2019-09-17 at 21:47 -0300, Daniel Junho wrote:
> > On Tue, Sep 17, 2019 at 3:24 AM Ardelean, Alexandru
> > <alexandru.Ardelean@analog.com> wrote:
> > > On Mon, 2019-09-16 at 20:50 -0300, Daniel Junho wrote:
> > > > [External]
> > > >
> > > > Hello everybody.
> > > >
> > > > I am still learning about kernel developing. I would like to try to
> > > > develop a device driver for the AD7928 [1], from Analog Device.
> > > >
> > > > Can someone give some words to guide me?
> > > >
> > > > I was thinking about forking the analog kernel repo [2] but I don't
> > > > know to which branch should I commit to when doing a pull request. Or
> > > > if this is the correct way for the devices from Analog.
> > > >
> > >
> > > Hey,
> > >
> > > Thanks for the interest in writing the driver for this.
> > >
> > > In some cases, some new parts may have an existing driver available
> > > already
> > > that can be re-used partially or completely.
> > >
> > > You're in luck.
> > > There is driver seems to be partially implemented via
> > > drivers/iio/adc/ad7923.c
> > >
> > > I've done only a minor/quick check but the control register bits are
> > > compatible for the AD7928 as well.
> > >
> > > Typically, you can extend that driver and add the new parts and test
> > > them.
> > >
> > > So, my suggestion would be:
> > > 1. Get an eval-board or a AD7928 part; depending on the case we could
> > > help
> > > with this
> > > 2. Try to set it up with a Raspberry Pi with the eval board
> > >    a. it looks to me that you need a 7V-9V power-supply
> > >    b. you can hook the SPI to the test-points on the eval board
> > > 3. Write a basic device-tree overlay ; you can adapt something from
> > > other
> > > examples.
> > > Look here:
> > > https://github.com/analogdevicesinc/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/Makefile
> > > Usually  rpi-adXXX.dts  are ADI parts.
> > > 4. Enable the driver for the kernel.
> > > If using the ADI kernel, there's a guide here for RPi.
> > > https://wiki.analog.com/resources/tools-software/linux-build/generic/raspberrypi
> > > Check the branch that matches your Raspbian image (rpi-4.19.y is the
> > > latest)
> > > 5. Build the kernel
> > > 6. Write it to the SD-card image
> > > 7. Test
> > > 8. Modify & repeat
> > >
> > > Thanks
> > > Alex
> > >
> > > > [1] https://www.analog.com/en/products/ad7928.html
> > > > [2] https://github.com/analogdevicesinc/linux
> > > >
> > > > Daniel Junho
> >
> > Hi Alex.
> >
> > It seems that using AD7923 will be the best choice. They are very
> > similar.
> >
> > Thank you for your reply and suggestion.
> > I don't have an EVB, but at work, we have a board with the AD7928
>
> If you have the chip already connected, then it's even better.
> You don't need to go through the trouble of interfacing it anymore.
>
> > using a user driver. So I will try to use it for this development, at
>
> And if you've already validated with a user-driver, it's again better, as
> the connections have been validated.
>
> > least for now.
> >
> > I believe that will be fun =)
>
> Should be.
> If this whole thing is new to you, it's always easier to start with a
> base/existing driver and extend than go through the process of writing it
> from scratch.
> It's mostly how I learn(ed) things: taking things apart, seeing what people
> have done, and then using the best ideas in my future processes.
>
> >
> > Daniel Junho