Hi Conor,
On 6/27/24 18:13, Conor Dooley wrote:
On Wed, Jun 26, 2024 at 06:40:58PM +0200, Olivier MOYSAN wrote:
Hi Conor,
On 6/25/24 17:34, Conor Dooley wrote:
On Tue, Jun 25, 2024 at 05:07:13PM +0200, Olivier Moysan wrote:
Add documentation of device tree bindings to support
sigma delta modulator backend in IIO framework.
Signed-off-by: Olivier Moysan <olivier.moysan@xxxxxxxxxxx>
I don't review bindings for a job, I can only reliably get to look at
my mail queue in the evenings, please give me a chance to reply to you
before you submit a new version.
Sorry, the short review delay.
+$id: http://devicetree.org/schemas/iio/adc/sd-modulator-backend.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sigma delta modulator backend
Same comments about filename and title apply here as the previous
version. "TI $foo Sigma Delta Modulator" and drop the reference to back
ends or the pretence of being generic.
The logic here is the same as for the former sigma delta modulator driver.
(see discussion [1])
I mean introducing a generic and minimalist driver to support sd modulators,
but not dedicated to a specific modulator. The ads1201 is chosen as a basic
modulator here. But it is rather an arbitrary choice.
I agree "backend" reference is not really relevant here. I have to think
about a way to manage the coexistence of this sigma delta modulator driver
with its former version.
To be blunt, I don't care about drivers! Well I do, but not in this
particular context. You can absolutely have a driver that supports
multiple backends or sigma delta modulators, but right now we are
talking about a binding and this binding supports exactly one sigma
delta modulator - and with an explicit compatible. In that context,
presenting the binding as generic makes little sense.
[1] https://lore.kernel.org/all/6943aaf5-b580-0fd1-7a2e-b99f7a266388@xxxxxx/
Looking at this though, I question the binding more... The programming
model of the device is identical as a backend or otherwise, so it
shouldn't be getting a new compatible. Isn't this actually as simple as
adding #io-backend-cells to the existing binding and using that to
determine whether the device is being used as a backend or in isolation?
For sure. I came to the same conclusion. My first idea was to isolate
the deprecated binding. But I agree that the best approach is to adapt
the existing binding. I prepared a v3 like this.
BRs
Olivier
Thanks,
Conor.
