On Fri, Aug 16, 2019 at 05:05:53PM +0300, Vladimir Oltean wrote: > I'm not sure how to respond to this, because I don't know anything > about the timing of DMA transfers. > Maybe snapshotting DMA transfers the same way is not possible (if at > all). Maybe they are not exactly adequate for this sort of application > anyway. Maybe it depends. DMA transfers generally proceed without any involvement from the CPU, this is broadly the point of DMA. You *may* be able to split into multiple transactions but it's not reliable that you'd be able to do so on byte boundaries and there will be latency getting notified of completions. > In other words, from a purely performance perspective, I am against > limiting the API to just snapshotting the first and last byte. At this > level of "zoom", if I change the offset of the byte to anything other > than 3, the synchronization offset refuses to converge towards zero, > because the snapshot is incurring a constant offset that the servo > loop from userspace (phc2sys) can't compensate for. > Maybe the SPI master driver should just report what sort of > snapshotting capability it can offer, ranging from none (default > unless otherwise specified), to transfer-level (DMA style) or > byte-level. That does then have the consequence that the majority of controllers aren't going to be usable with the API which isn't great. > I'm afraid more actual experimentation is needed with DMA-based > controllers to understand what can be expected from them, and as a > result, how the API should map around them. > MDIO bus controllers are in a similar situation (with Hubert's patch) > but at least there the frame size is fixed and I haven't heard of an > MDIO controller to use DMA. I'm not 100% clear what the problem you're trying to solve is, or if it's a sensible problem to try to solve for that matter.
Attachment:
signature.asc
Description: PGP signature
