On Tue, Jun 04, 2024 at 02:39:18PM -0500, David Lechner wrote: > On 6/4/24 2:33 PM, Conor Dooley wrote: > > On Thu, May 30, 2024 at 02:24:17PM -0500, David Lechner wrote: > >> On 5/29/24 3:07 AM, Nuno Sá wrote: > >>> On Sun, 2024-05-26 at 18:35 +0100, Conor Dooley wrote: > >> > >> > >>>> It might be easy to do it this way right now, but be problematic for a > >>>> future device or if someone wants to chuck away the ADI provided RTL and > >>>> do their own thing for this device. Really it just makes me wonder if > >>>> what's needed to describe more complex data pipelines uses an of_graph, > >>>> just like how video pipelines are handled, rather than the implementation > >>>> of io-backends that don't really seem to model the flow of data. > >>>> > >>> > >>> Yeah, backends is more for devices/soft-cores that extend the functionality of the > >>> device they are connected too. Like having DACs/ADCs hdl cores for connecting to high > >>> speed controllers. Note that in some cases they also manipulate or even create data > >>> but since they fit in IIO, having things like the DMA property in the hdl binding was > >>> fairly straight. > >>> > >>> Maybe having an offload dedicated API (through spi) to get/share a DMA handle would > >>> be acceptable. Then we could add support to "import" it in the IIO core. Then it > >>> would be up to the controller to accept or not to share the handle (in some cases the > >>> controller could really want to have the control of the DMA transfers). > >> > >> I could see this working for some SPI controllers, but for the AXI SPI Engine > >> + DMA currently, the DMA has a fixed word size, so can't be used as a generic > >> DMA with arbitrary SPI xfers. For example, if the HDL is compiled with a 32-bit > >> word size, then even if we are reading 16-bit sample data, the DMA is going to > >> put it in a 32-bit slot. So one could argue that this is still doing some data > >> manipulation similar to the CRC checker example. > >> > >>> > >>> Not familiar enough with of_graph so can't argue about it but likely is something > >>> worth looking at. > >> > >> I did try implementing something using graph bindings when I first started > >> working on this, but it didn't seem to really give us any extra useful > >> information. It was just describing connections (endpoints) that I thought > >> we could just implicitly assume. After this discussion though, maybe worth > >> a second look. I'll have to think about it more. > > > > Could you elaborate on why you think you can assume the connections? What > > happens when you have multiple stages of data processing and/or multiple > > ADCs in your system? As I've previously said, I work on FPGA stuff, and > > everyone here seems to fawn over having <insert custom DSP IP here> in > > their data pipelines. I can't imagine it being any different for ADC data, > > and an io-backend property that doesn't describe how the data flows is > > gonna become lacklustre I think. > > I was more ignorant back then. :-) > > That is is why I said "thought" instead of "think". I am more enlightened now. Heh, I didn't mean it in a bad way. I just wanted to flesh out why you thought that way.
Attachment:
signature.asc
Description: PGP signature
