Re: [PATCH 3/9] regmap: spi: SPI_CONTROLLER_CS_PER_TRANSFER affects max read/write

[Lucas tanure]

On 8/24/21 5:37 PM, Mark Brown wrote:
> On Tue, Aug 24, 2021 at 11:40:35AM +0100, Lucas Tanure wrote:
> > regmap-spi will split data and address between two transfers in the
> > same message so use addr_affects_max_raw_rw to flag that the number
> > bytes to read or write should be a little less (address + padding size),
> > so that the SPI controller can merge the entire message into a single
> > CS period
>
> This should be handled by the SPI core, it's already relying on being
> able to do multiple transfers to handle message size limits and in any
> case this is a super standard thing to do so many clients would require
> special code.  The core should transparently coalesce things where it
> can, or error out if it can't, like it currently does when splitting
> transfers up.
__spi_validate seems a good candidate, but I don't think spi have enough
information to merge two transfers into a single one.

For a message with N transfers how can spi core decide what to merge or 
what not merge. If mergers everything and is less than max_transfer_size 
success, but if bigger will need to stop merging and add an address in 
front of the next not merged transfer, but spi core is not aware of 
addresses
And in the case of multiple addresses and data transfers, how it will 
know doesn't need to be merged?

For me seems more reasonable for the regmap-spi stop splitting address
and data. Or at least if the controller has some flag change the bus for
one where it uses different functions for gather_write, async_write etc

Can you point which way you think the code should go? Investigate more 
spi core to coalesce transfers or change regmap-spi to not split address 
and data anymore?

Thanks
Lucas