On Thu, Jan 11, 2024 at 7:00 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Wed, Jan 10, 2024 at 04:31:25PM -0600, David Lechner wrote: > > On Wed, Jan 10, 2024 at 3:39 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > Glancing through here I'm not seeing anything here that handles DMA > > > mapping, given that the controller will clearly be doing DMA here that > > > seems surprising. > > > In the use case implemented in this series, the RX data is going to > > DMA, but in general, that doesn't have to be the case. In theory, it > > could get piped directly to a DSP or something like that. So I left > > the RX DMA part out of the SPI controller and implemented as a > > separate device in "iio: offload: add new PWM triggered DMA buffer > > driver". The SPI controller itself isn't aware that it is connected to > > DMA (i.e. there are no registers that have to be poked to enable DMA > > or anything like that). > > If there's a buffer being assigned to the device (or removed from the > device) it needs mapping, this will ensure the device is allowed to > access it if there's IOMMUs involved, and that there's no pending cache > operations which could corrupt data. Currently, in this series, the mapping is being handled by the existing DMA buffer framework in the IIO subsystem. It is the IIO device that owns/manages the DMA rather than the SPI controller. Nuno has also made some relevant comments in some of the other threads about why it would be preferable to do it that way. But this sounds like something we should come back to later after we have a look at breaking down this series into smaller parts.
