Hi David, On Wed, 2024-01-10 at 13:49 -0600, David Lechner wrote: > This adds a feature for specialized SPI controllers that can record > a series of SPI transfers, including tx data, cs assertions, delays, > etc. and then play them back using a hardware trigger without CPU > intervention. > > The intended use case for this is with the AXI SPI Engine to capture > data from ADCs at high rates (MSPS) with a stable sample period. > > Most of the implementation is controller-specific and will be handled by > drivers that implement the offload_ops callbacks. The API follows a > prepare/enable pattern that should be familiar to users of the clk > subsystem. > > Consumers of this API will make calls similar to this: > > /* in probe() */ > offload = spi_offload_get(spi, 0); > ... > On top of what Mark already stated, and as we already discussed offline, I personally don't like this provider - consumer interface for the offload. The first thing is that this is taking into account the possibility of having multiple offload cores. While the FGPA core was designed with that in mind, we don't really have any design using multiple offloads in one spi engine (always one). Hence this is all pretty much untested. If we want to already have this support, my feeling is that we should have a simple integer dt property for the peripheral devices (similar to cs). When a device is being created/added, the spi core would parse this property and get it's offload index. The point is that this would all be transparent for spi devices drivers that would only have to call the SPI API's and the core would make sure the right index is passed to the controller. But honestly, IMO, I would just keep things simple for now and assume one core per engine. I would probably also prefer to see all the new interfaces part of the spi_controller struct directly... - Nuno Sá
