[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240613194324.GA2352022-robh@kernel.org>
Date: Thu, 13 Jun 2024 13:43:24 -0600
From: Rob Herring <robh@...nel.org>
To: Nuno Sá <noname.nuno@...il.com>
Cc: David Lechner <dlechner@...libre.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Jonathan Cameron <jic23@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
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, Jun 13, 2024 at 05:11:48PM +0200, Nuno Sá wrote:
> 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?
Yeah, it doesn't really matter much in that case.
> Or is there another usecase that I'm not aware about (or maybe it just makes sense to
> document properly...)?
Somewhat I guess. Perhaps if there's a 3rd chip with higher rate, then
it will be more obvious what to do and we don't have to have this
discussion again for it. :)
Rob
Powered by blists - more mailing lists