linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Junho <djunho@gmail.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>,
	"lkcamp@lists.libreplanetbr.org" <lkcamp@lists.libreplanetbr.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: Doubts in getting started with the Analog AD7928 driver
Date: Sat, 30 Nov 2019 12:44:13 -0300	[thread overview]
Message-ID: <CAKxs2cDCox2k19ErZYKQxaw_gyOHzxtQTMwZe8TpcgeO+smNdw@mail.gmail.com> (raw)
In-Reply-To: <36ecb0e0-a593-2064-caf0-9b161c36f9b4@metafoo.de>

On Thu, Nov 28, 2019 at 4:16 PM Lars-Peter Clausen <lars@metafoo.de> wrote:
>
> On 11/28/19 6:49 PM, Daniel Junho wrote:
> > Continuing:
> > I will use the kernel 4.4 LTS official and on the mainline to continue.
> > I will let you know if my problem continues.
> >
> > To make my last update more clear:
> > I see the cs rising when sending the command transfer and falling only
> > after the read transfer. But not between, that is what I expected with
> > the cs_change.
> > I also suspected from my device tree but, when using a userspace
> > application (with spidev) it worked.
> >
> > Also, my device tree is the following one. I'm checking if I'm doing
> > anything wrong. Please let me know if you see any obvious problems.
> >
> > Thank you
>
> Hi,
>
> cs_change is a bit of an obscure feature since there are not many users
> and not all SPI controller drivers get it right.
>
> Check if this commits that was added in v4.6, maybe they'll help
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92dc20d83adec565378254c0630e839ff5674e14
>
> As a workaround you can also do multiple spi_transfer() calls.
>
> - Lars
>

Yes. The problem was exactly this! I applied this patch to the kernel
and it worked.

When it worked, I became very happy. I had spent a huge amount of time
trying different approaches, thinking that I did something wrong.

Now, the relationship between the SPI bus and its devices is much
clear in my mind. I  learned a lot from this.

Thank you all for the support. I will continue the development.


>
> >
> > dspi3: dspi3@400ad000 {
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> >     compatible = "fsl,vf610-dspi";
> >     reg = <0x400ad000 0x1000>;
> >     interrupts = <70 IRQ_TYPE_LEVEL_HIGH>;
> >     clocks = <&clks VF610_CLK_DSPI3>;
> >     clock-names = "dspi";
> >     spi-num-chipselects = <2>;
> >     /* Previously, this node was without DMA info - segmentation fault on use
> >     For proper usage, it MUST contain DMA channel info --> EDMA1 */
> >     dmas = <&edma1 0 12>,
> >         <&edma1 0 13>;
> >     dma-names = "rx", "tx";
> >     status = "disabled";
> > };
> >
> >
> > &dspi3 {
> >     status = "okay";
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> >
> >     /* This will create /dev/spidev3.0 */
> >     /*spidev30: spidev3@0 {
> >         compatible = "toradex,evalspi";
> >         reg = <0>;
> >         spi-max-frequency = <50000000>;
> >         fsl,spi-cs-sck-delay = <100>;
> >         fsl,spi-sck-cs-delay = <50>;
> >         status = "okay";
> >     };*/
> >
> >     ad7928@0 {
> >       compatible = "adi,ad7928";
> >       reg = <0>;
> >       spi-max-frequency = <20000000>;
> >       refin-supply = <&reg_5v0>;
> >     };
> >
> > };
> >
> > Daniel E. M. Junho
> >
> > On Thu, Nov 28, 2019 at 12:13 PM Daniel Junho <djunho@gmail.com> wrote:
> >>
> >> 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
>

  reply	other threads:[~2019-11-30 15:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKxs2cBVnL=6ZNbKgYRppaeUBM3xuog5BHdtmJHRxwttSfjugg@mail.gmail.com>
2019-09-16 23:50 ` Doubts in getting started with the Analog AD7928 driver Daniel Junho
2019-09-17  6:24   ` Ardelean, Alexandru
2019-09-18  0:47     ` Daniel Junho
2019-09-18  6:13       ` Ardelean, Alexandru
2019-11-28 15:13         ` Daniel Junho
2019-11-28 17:49           ` Daniel Junho
2019-11-28 19:16             ` Lars-Peter Clausen
2019-11-30 15:44               ` Daniel Junho [this message]
2019-11-30 16:18                 ` Fabio Estevam
2019-11-28 19:23           ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKxs2cDCox2k19ErZYKQxaw_gyOHzxtQTMwZe8TpcgeO+smNdw@mail.gmail.com \
    --to=djunho@gmail.com \
    --cc=alexandru.Ardelean@analog.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=lkcamp@lists.libreplanetbr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).