Messages in this thread | | | Date | Tue, 10 Jan 2023 21:18:39 +0000 | From | Mark Brown <> | Subject | Re: [PATCH 11/16] spi: bcm63xx-hsspi: Add prepend feature support |
| |
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(). [unhandled content-type:application/pgp-signature] | |