On Mon, Jan 09, 2023 at 12:43:53PM -0800, William Zhang wrote:
> On 01/09/2023 11:31 AM, Mark Brown wrote:

> > If this relies on software control of the chip select (which is what I
> > *think* your dummy CS workaround thing is about, the other patch about
> > that is really hard to understand) then I'm confused about what the
> > advantage is?

> Dummy CS workaround is implemented by Jonas when he first upstream the
> driver. It does not work on all the board designs so prepend mode is
> introduced. I have some detail explanation on this in [PATCH 10/16] spi:
> bcm63xx-hsspi: Make dummy cs workaround as an option.

Yes, it is the description in patch 10 that I was having a lot of
trouble following.

> The controller only work in one mode and that's why driver code has some
> dependency between these two modes. The advantage of the premode is it works
> on all hw design however it does not support all types mem_ops operation.
> That is why you see the patch 14 to disable the dual io mem op. But dummy cs
> workaround can support this and in case there is such pattern from non mem
> op spi transaction, dummy cs workaround can be used as long as it does not
> have the board design limitation.   So neither one is perfect but hopefully
> with both options available, we can cover all the cases.

We can't switch modes per message?

> You mentioned there is some existing logic to rewrite messages to match
> driver constraints in the core driver.  I didn't see it when I did a quick
> search on spi.c. I will take a deep look into the file. But if you can point
> me where this logic is so I can be sure that I am looking at the right place
> and will double check if this can be done or not in the core level.  Thanks!

spi_replace_transfers().