Re: [PATCH v3 0/8] iio: add new backend framework

[Jonathan Cameron <jic23@kernel.org>]

> > >   
> > > >     
> > > > > > And if there's another consumer in the chain, then a node could 
> > > > > > certainly be both an io-channels consumer and producer.
> > > > > >     
> > > > > 
> > > > > This should also be possible with this architecture. A node can be both
> > > > > a backend
> > > > > (provider) and a consumer and we have an out of tree design that fits
> > > > > this (that
> > > > > I
> > > > > surely want to upstream after the foundations are done).
> > > > >     
> > > > > > The architecture of the drivers seems odd to me. It looks similar to 
> > > > > > making a phy driver handle all the state and protocol with the host 
> > > > > > controller being a backend.    
> > > > > 
> > > > > In this case, it's not really a controller. It's more like an extension
> > > > > of the
> > > > > device
> > > > > because we need a way to handle the high sample rates this ADCs can do.
> > > > > Then we
> > > > > can
> > > > > also do test tones with the backend which is useful for interface tuning
> > > > > (as
> > > > > mentioned above).
> > > > > 
> > > > > To give you a bit more context, I'm adding the generic property because
> > > > > we will
> > > > > have
> > > > > more users for it (from ADI - the next should be the axi-dac core) but
> > > > > STM is
> > > > > also
> > > > > interested in this (likely the next user).
> > > > > 
> > > > > Hope this makes it a bit more clear...    
> > > > 
> > > > Yes, thanks.
> > > > 
> > > > I generally ask for 2 users on new common bindings. I've accepted too 
> > > > many only to have the 2nd user come in a month later and need additions. 
> > > > An ack on the binding from the STM folks would be nice here. And 
> > > > Jonathan too.
> > > >     
> > > 
> > > Olivier, could we get an ack on the bindings patch? Do you also have any
> > > idea about
> > > how long it would take for you to send patches so we have another user of
> > > the schema?
> > > 
> > > On my side, it might very well take a month or so (given we have holidays
> > > nearby) as
> > > the axi-dac core is more complex than the axi-adc. Bah it might take less
> > > than a
> > > month to have the first version of it posted in the lists but I can't make
> > > any
> > > promises.  
> > 
> > For the driver side of things I'd like at least 2, preferably 3 users before
> > merging.
> > We have more flexibility to rework things as any issues will probably be
> > internal
> > interfaces, but I'd rather wait if we are going to have 3 users within another
> > month
> > or 2.
> >   
> 
> Totally fine by me. But how would this look like? Could we have an immutable
> branch where we can send patches about this? Or maybe staging? I'm asking
> because adding more stuff into these series might make it harder to review (the
> axi-dac might have some fun ABI discussion :)). Ideally, we would have this
> merged somewhere and then add users on top of it.

It's fine to post a bunch of series with stated dependencies
(I've gotten 5 series + deep in the past :)

Obviously useful to have a git tree with them all on somewhere though
but if you host that it would be ideal given you are driving this
work in general.

Jonathan

> 
> - Nuno Sá