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
