On Thu, Nov 28, 2019 at 4:16 PM Lars-Peter Clausen <lars@xxxxxxxxxx> 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 = <®_5v0>; > > }; > > > > }; > > > > Daniel E. M. Junho > > > > On Thu, Nov 28, 2019 at 12:13 PM Daniel Junho <djunho@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 >
