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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux