Re: [PATCH 11/16] spi: bcm63xx-hsspi: Add prepend feature support

From: William Zhang
Date: Mon Jan 09 2023 - 15:44:50 EST



On 01/09/2023 11:31 AM, Mark Brown wrote:
On Fri, Jan 06, 2023 at 07:52:35PM -0800, William Zhang wrote:
On 01/06/2023 02:00 PM, Mark Brown wrote:
On Fri, Jan 06, 2023 at 12:08:03PM -0800, William Zhang wrote:

Multiple transfers within a SPI message may be combined into one
transfer to the controller using its prepend feature. A SPI message is
prependable only if the following are all true:
* One or more half duplex write transfer
* Optional full duplex read/write at the end
* No delay and cs_change between transfers

There is nothing driver specific here, this should be implemented in the
core - we have existing logic to rewrite messages to match driver
constraints, this could be added there possibly with flags to allow
drivers to disable or enable the merging if they've got special
requirements.

My understanding of combining the spi transfer in the core level does not
quite work out to our controller. For example, for a spi message with three
transfers, tx, tx and rx. We can possibly combine them in single duplex
tx/rx transfer in the core. But this will be treated as duplex transaction
in our controller level which require tx and rx data happens at the same
time. Obviously this won't work when rx depends on tx happening first. We

I'm saying that if this logic is useful then implement in the core
rather than in the driver.

can not differentiate this combined duplex transfer from the true duplex
transfer unless there is some flag to indicate that. Also there is limit of
max tx length as the prepend buffer so maybe another parameter. And another
reason to be done in the driver level is this prepend mode has dependency on
dummy cs workaround which is driver level parameter currently. I am not
sure how practical and useful this is to factor them out to the core level?

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.

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.

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!



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature