On Wed, Aug 25, 2021 at 06:13:01PM +0100, Lucas tanure wrote: > On 8/24/21 5:37 PM, Mark Brown wrote: > > 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 > 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, In the same way it does for transfers that are too long. If the controller has a property saying that it can't handle more than one transfer then the core needs to either combine multiple transfers in a single message into a single transfer or return an error to the caller (modulo handling of cs_change). If the controller can handle the message it should just get passed straight through. > 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? The spi_message says what the message should look like on the bus. The semantics of what's in the message don't matter. > 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 This would force us to marshall the data in memory prior to sending which adds overhead. > 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? Like I said in reply to your driver patch it looks like this fundamentally doesn't do what you want in the first place.
Attachment:
signature.asc
Description: PGP signature
