Re: [PATCH v4 1/6] spi: Enable controllers to extend the SPI protocol with MOSI idle configuration

[Marcelo Schmitt <marcelo.schmitt1@xxxxxxxxx>]

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:
> >>
> >>
> 
> ...
> 
> >>
> >>> +the peripheral and also when CS is inactive.
> >>
> >> As I mentioned in a previous review, I think the key detail here is that the
> >> MOSI line has to be in the required state during the CS line assertion
> >> (falling edge). I didn't really get that from the current wording. The current
> >> wording makes it sound like MOSI needs to be high indefinitely longer.
> > 
> > It may be that we only need MOSI high just before bringing CS low. Though,
> > I don't see that info in the datasheets. How much time would MOSI be required
> > to be high prior to bringing CS low? The timing diagrams for register access and
> > ADC sampling in "3-wire" mode all start and end with MOSI at logical 1 (high).
> > I think reg access work if MOSI is brought low after CS gets low, but sample
> > read definitely don't work.
> > 
> > From the info available in datasheets, it looks like MOSI is indeed expected 
> > to be high indefinitely amount of time. Except when the controller is clocking
> > out data to the peripheral.
> > 
> > Even if find out the amount of time MOSI would be required high prior to CS low,
> > then we would need some sort of MOSI high/low state set with a delay prior to
> > active CS. That might be enough to support the AD4000 series of devices but,
> > would it be worth the added complexity?
> > 
> 
> It needs to happen at the same time as setting CPOL for the SCLK line for the
> device that is about to have the CS asserted. So I don't think we are breaking
> new ground here. Typically, in most datasheets I've seen they tend to say
> something like 2 ns before the CS change. So in most cases, I don't think
which datasheets? Are any of those for devices supported by the ad4000 driver?

> anyone bothers adding a delay. But if a longer delay was really needed for
> a specific peripheral, we could add a SPI xfer with no read/write that has
> cs_off=1 and a delay to get the correct state of both MOSI and SCLK a longer
> time before the CS change.

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.