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().
Attachment:
signature.asc
Description: PGP signature
