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; } -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html