On 6/20/24 1:21 PM, Marcelo Schmitt wrote: > On 06/20, David Lechner wrote: >> On 6/20/24 10:12 AM, Marcelo Schmitt wrote: >>> On 06/19, David Lechner wrote: >>>> On 6/19/24 1:58 PM, Marcelo Schmitt wrote: >>>>> On 06/19, David Lechner wrote: >>>>>> On 6/18/24 6:10 PM, Marcelo Schmitt wrote: >>>>>> >>>>>> >>>> >>>> ... >>>> >>> I don't know if that would actually work. I have not tested doing something like that. >>> This also implies the controller will be able to start the next transfer right >>> after the first preparatory transfer ends and it will meet that inter-transfer >>> timing requirement (which I still didn't find documented anywhere). >>> I'm not convinced that would be the best way to support those devices. >> >> I did something like this in the ad7944 driver where we needed an up to >> 500ns delay before asserting CS. On SPI controllers without a hardware >> sleep or FIFO, the delay will of course be much longer. But the delay >> is just a minimum delay, so longer doesn't hurt. It just affects the >> max sample rate that can be reliably achieved. >> > In ad7944_3wire_cs_mode_init_msg(), xfers[1] is prepared with spi_transfer.delay > which is the "delay to be introduced after this transfer before > (optionally) changing the chipselect status, then starting the next transfer or > completing this @spi_message." That should work for ad7944 because > it has ADC SDI physically connected to VIO in that setup. > For ad4000, we would want to set MOSI high (by writing 1s) such that MOSI > is high when CS is brought high (if I'm getting what you are suggesting). > But spi_transfer.delay is introduced after the transfer and before changing CS > so I think MOSI may return to low if the controller idles MOSI low. > I can't see how this would work for ad4000. > Other delays we have for spi_transfer (cs_change_delay, word_delay) don't seem > to help for this particular case either. I was actually referring to ad7944_4wire_mode_init_msg(). In the case of ad4000, the SPI controller will be required to support the new SPI_MOSI_IDLE_HIGH flag. So at the beginning of the message, before any of the individual xfers, the controller driver will configure SCLK base on CPOL and MOSI based on SPI_MOSI_IDLE_HIGH. Then it will do whatever the xfers say. For most SPI controllers in Linux, this SCLK/MOSI config will happen in ctlr->prepare_message() which happens before xfers are processed in ctlr->transfer_one_message(). In the AXI SPI Engine, the SCLK/MOSI config is in a separate instruction that happens before anything else in the message. So if the first xfer is just a delay with no read/write, the delay will always happen after SCLK and MOSI are configured. We don't have to write 1s because SPI_MOSI_IDLE_HIGH already does the right thing.
