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. > > 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.
Attachment:
signature.asc
Description: PGP signature