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

From: Mark Brown
Date: Mon Jan 09 2023 - 14:32:07 EST


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?

Attachment: signature.asc
Description: PGP signature