Re: [PATCH 1/3] spi: core: add max_msg_size to spi_master

[Heiner Kallweit <hkallweit1@gmail.com>]

Am 23.11.2015 um 12:38 schrieb Mark Brown:
> On Sun, Nov 22, 2015 at 05:15:04PM +0100, Heiner Kallweit wrote:
>> Am 22.11.2015 um 14:16 schrieb Mark Brown:
> 
>> To avoid misunderstandings:
>> For fsl-espi the length of a SPI transfer has to be programmed (max 64K)
>> and after this number of bytes has been transferred CS is deselected
>> internally. There's no way to control CS directly.
>> Do you consider this a message or transfer size limit?
>> To me this seems to be exactly what you describe as "devices that aren't
>> able to deal with multiple transfers independently".
> 
> Well, possibly.  What happens with a very large proportion of SPI
> controllers is that we just ignore the /CS functionality of the
> controller and use a GPIO instead, most SoC integrations also support
> GPIO on the same pin and there's rarely any advantage in trying to use
> the integrated support.
> 
Right, that's the case also for fsl-espi. The bad thing is that there's
no way to change only the CS pin to a GPIO.
Only the complete block of SPI signals can be switched to GPIO.

>>> For slightly more complex things like this it probably also makes sense
>>> to use an accessor - I can see us wanting to combine restrictions from
>>> DMA engines into restrictions for the SPI controller for example.  That
>>> gives us a bit of insulation between the clients and the API.
> 
>> When you talk about accessors do you think of hooks in spi_master so that
>> each controller driver can provide its own implementation of e.g.
>> something like get_max_msg_size()?
> 
> No, for the clients so they aren't peering at the struct.
> 
Sure, do you think of a simple getter like this or a more complex thing?

size_t spi_get_max_msg_size(struct spi_master *master)
{
	return master->max_msg_size;
}