On Sat, 2 Dec 2023 10:16:52 -0600 David Lechner <dlechner@xxxxxxxxxxxx> wrote: > On Sat, Dec 2, 2023 at 3:37 AM Nuno Sá <noname.nuno@xxxxxxxxx> wrote: > > > > On Fri, 2023-12-01 at 21:53 -0600, David Lechner wrote: > > > On Thu, Nov 30, 2023 at 5:54 PM David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > > > > > > > On Tue, Nov 21, 2023 at 4:17 AM Nuno Sa via B4 Relay > > > > <devnull+nuno.sa.analog.com@xxxxxxxxxx> wrote: > > > > > > > > > > Hi all, > > > > > > > > > > This is a Framework to handle complex IIO aggregate devices. > > > > > > > > > > The typical architecture is to have one device as the frontend device which > > > > > can be "linked" against one or multiple backend devices. All the IIO and > > > > > userspace interface is expected to be registers/managed by the frontend > > > > > device which will callback into the backends when needed (to get/set > > > > > some configuration that it does not directly control). > > > > > > > > > > The basic framework interface is pretty simple: > > > > > - Backends should register themselves with @devm_iio_backend_register() > > > > > - Frontend devices should get backends with @devm_iio_backend_get() > > > > > > > > > > (typical provider - consumer stuff) > > > > > > > > > > > > > The "typical provider - consumer stuff" seems pretty straight forward > > > > for finding and connecting two different devices, but the definition > > > > of what is a frontend and what is a backend seems a bit nebulous. It > > > > would be nice to seem some example devicetree to be able to get a > > > > better picture of how this will be used in practices (links to the the > > > > hardware docs for those examples would be nice too). > > > > > > > > > > Fulfilling my own request here... > > > > > > Since AD9467 is being use as the example first user of the IIO offload framework > > > I did a deep dive into how it is actually being used. It looks like this: > > > > > > > This is not an offload framework... I think somehow you're connecting this to the > > spi_engine offload and these are two completely different things. Maybe they can > > intersect at some point but as of now, I don't see any benefit in doing it. The goal > > of this patchseries is to have a simple and generic framework so we can connect IIO > > devices (frontends) to a backend device having kind of an IIO aggregate device so to > > say. Moreover, we just want to have the ad9467 driver in the same state it was before > > to keep things simple. I'm already fixing some things but I don't want extend that > > too much as the primary goal is to have the framework in. Cleanups can come > > afterwards. > > > > That said, is fine to have this kind of discussion but I honestly think you're over > > engineering the whole thing. Maybe you're already too ahead of me :), but where we > > stand right now, I don't see any reason for anything so complicated as the below. > > Also note this should be simple and generic. As I already said, this is not supposed > > to be an ADI only thing and STM also wants to make use of this infrastructure. But > > see below some of my comments on why I think it's too much... > > This is a very fair point. I do have a tendency to overthink things. :-) > > At the very least, being able to see the schematic of how it all fits > together filled in the holes of my understanding and now everything > you are doing in this series makes sense to me. And I totally agree > with keeping it simpler is better. Interesting discussion. One key thing it has highlighted for me is that even the simpler proposal that Nuno has put forward deserves some more documentation! Preferably with some asci art - though maybe not as complex as David's pretty picture. I keep forgetting which is the backend and which is the front end for this discussion which isn't helping me get my head around it. Jonathan
