[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f0776ba5163578453e26352763ff1b4687bcf87.camel@gmail.com>
Date: Thu, 13 Jun 2024 17:11:48 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: David Lechner <dlechner@...libre.com>, Krzysztof Kozlowski
<krzk@...nel.org>, Jonathan Cameron <jic23@...nel.org>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>
Cc: Michael Hennerich <michael.hennerich@...log.com>, Nuno
Sá
<nuno.sa@...log.com>, Jonathan Corbet <corbet@....net>,
linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: iio: adc: add AD4695 and similar ADCs
On Thu, 2024-06-13 at 09:39 -0500, David Lechner wrote:
> On 6/13/24 9:18 AM, Krzysztof Kozlowski wrote:
> > On 13/06/2024 15:57, David Lechner wrote:
> > >
> > > >
> > > > > + - const: adi,ad4695
> > > > > + - items:
> > > > > + - const: adi,ad4697-wlcsp
> > > > > + - const: adi,ad4697
> > > > > + # same chips with higher max sample rate
> > >
> > > I suppose one could make the argument that the programming model is
> > > the same on these too, but the maximum sampling frequency does seem
> > > like an important bit of information so that you don't try to set
> > > the conversion trigger rate too high.
> > >
> >
> > which property is that? I don't see differences in the driver, so I
> > don't get how these wlcsp compatibles allow you to control value of
> > conversion trigger.
>
> This comment is unrelated to the package type (WLCSP or LFCSP).
>
> What I mean is that e.g. AD4695 and AD4696 are virtually identical
> other than the maximum allowable sample rate (500 kSPS or 1 MSPS).
>
> So my thinking was that it would make sense to have:
>
> compatible = "ad4695";
>
> for the lower sample rate chip and
>
> compatible = "ad4696", "ad4695";
>
> for the higher sample rate chip since ad4696 can do everything
> that ad4695 does plus a bit more.
>
IMO, that would make sense yes. If the higher sample rate chip fallsback, it will
still work but not at full speed. The other way around is the one that we can't allow
naturally.
But possibly dumb question now... since both devices will be supported at the same
time, do we actually care about having the fallback compatible? My understanding of
the fallback story is that we may load a DTS in an older kernel where chip A is
supported but chip B is not and it is ok for chip B to fallback to chip A. Since
these devices will be supported at the same time, do we need to care? Unless out of
tree stuff enters the equation?
Or is there another usecase that I'm not aware about (or maybe it just makes sense to
document properly...)?
- Nuno Sá
>
Powered by blists - more mailing lists