On Fri, 2023-12-08 at 15:30 +0000, Conor Dooley wrote: > On Fri, Dec 08, 2023 at 04:14:07PM +0100, Nuno Sa via B4 Relay wrote: > > This series depends on [1] and it only build on top of it. The point is > > to already speed up the reviewing of the framework. That obviously means > > that all those pacthes were dropped in v2. > > > > v1: > > > > https://lore.kernel.org/linux-iio/20231204144925.4fe9922f@jic23-huawei/T/#m222f517 > > 5273b81dbfe40b7f0daffcdc67d6cb8ff > > > > Changes in v2: > > - Patch 1-2 and 5 > > * new patches. > > - Patch 6: > > * Fixed some docs failures; > > * Fixed a legacy 'conv' name in one of the function parameters; > > * Added .request_buffer() and .free_buffer() ops; > > * Refactored the helper macros; > > * Added Olivier as Reviewer. > > - Patch 7: > > * Use new devm_iio_backend_request_buffer(). > > - Patch 8: > > * Implement new .request_buffer() and .free_buffer() ops; > > > > Also would like to mention that in v2 I'm experimenting in having the > > DMA on the backend device (as discussed with David in v1). Does not look > > to bad but as I said before, I'm not seeing a big issue if we end up > > having the buffer allocation in the frontend. > > > > For the bindings folks: > > > > I'm introducing a new io-backends property in the ad9467 bindings but I'm > > not sure this is the way to do it. Ideally that new property become a > > generic schema and I'm guessing I should send a PULL to? > > > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/iio/iio-consumer.yaml > > That seems like the right thing to do to me, depending on how widespread > the use of these backends might be. What is seemingly missing though, > from this cover and from the bindings patch in the series in particular, > is an explanation of what the "iio-backends" hardware actually is. > Yeah, sorry about the bindings patch but I was already with the feeling that a PR in devicetree-org to be the right place. I'll be adding more drivers needing that property and STM also wants make use this. I'll improve on the explanation and send a PR for a generic schema. > There is some text below, but it does not seem complete to me. Is the > idea that this "backend" is shared between multiple frontend consumers? > The one example is described as being "highly focused on ADI usecases" > For now it cannot really be shared. The code is not prepared for it (we would need to keep enable/disable counters etc...). For now, I'm just adding the simpler cases of 1:1 and 1:n (1 frontend for multiple backends). Internally we do have 1:n designs that I definitely want (in time) to bring upstream. That said, having a usecase for it in the future, it is something that can be added, yes... Thanks for the feedback! - Nuno Sá >
