| Message ID | 5650F7D4.1090209@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Nov 22, 2015 at 12:01:40AM +0100, Heiner Kallweit wrote: > Add a member to spi_master allowing to better handle > SPI chips with a message size HW limit. How many devices have an actual message size limit (as opposed to a transfer size limit)? It seems like the restrictions here are really on transfer sizes and that we probably want a second limit for devices that aren't able to deal with multiple transfers independently. 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.
Am 22.11.2015 um 14:16 schrieb Mark Brown: > On Sun, Nov 22, 2015 at 12:01:40AM +0100, Heiner Kallweit wrote: >> Add a member to spi_master allowing to better handle >> SPI chips with a message size HW limit. > > How many devices have an actual message size limit (as opposed to a > transfer size limit)? It seems like the restrictions here are really on > transfer sizes and that we probably want a second limit for devices that > aren't able to deal with multiple transfers independently. > 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". > 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()? -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 27, 2015 at 08:26:52PM +0100, Heiner Kallweit wrote: > Am 23.11.2015 um 12:38 schrieb Mark Brown: > > 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; > } That's fine, the point is to allow it to get complicated later rather than that we have anything else to put in there right now.
Am 30.11.2015 um 17:42 schrieb Mark Brown: > On Fri, Nov 27, 2015 at 08:26:52PM +0100, Heiner Kallweit wrote: >> Am 23.11.2015 um 12:38 schrieb Mark Brown: > >>> 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; >> } > > That's fine, the point is to allow it to get complicated later rather > than that we have anything else to put in there right now. > OK, then I'll submit an updated version of the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index cce80e6..23e259b 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -302,6 +302,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) * and it's up to the individual driver to perform any validation. * @min_speed_hz: Lowest supported transfer speed * @max_speed_hz: Highest supported transfer speed + * @max_msg_size: maximum message size * @flags: other constraints relevant to this driver * @bus_lock_spinlock: spinlock for SPI bus locking * @bus_lock_mutex: mutex for SPI bus locking @@ -417,6 +418,9 @@ struct spi_master { u32 min_speed_hz; u32 max_speed_hz; + /* maximum message size */ + size_t max_msg_size; + /* other constraints relevant to this driver */ u16 flags; #define SPI_MASTER_HALF_DUPLEX BIT(0) /* can't do full duplex */
Add a member to spi_master allowing to better handle SPI chips with a message size HW limit. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- include/linux/spi/spi.h | 4 ++++ 1 file changed, 4 insertions(+)