On Mon, 9 Dec 2024 07:41:01 -0800 Guillaume Ranquet <granquet@xxxxxxxxxxxx> wrote: > On Mon, 18 Nov 2024 21:48, David Lechner <dlechner@xxxxxxxxxxxx> wrote: > >On 11/15/24 4:34 AM, Guillaume Ranquet wrote: > >> Some chips of the ad7173 family supports open wire detection. > >> > >> Generate a threshold event whenever an external source is disconnected > >> from the system input on single conversions. > >> > >> Signed-off-by: Guillaume Ranquet <granquet@xxxxxxxxxxxx> > >> --- > >> Hi. > >> > >> This patch adds the openwire detection support for the ad4111 chip. > >> > >> The openwire detection is done in software and relies on comparing the > >> results of two conversions on different channels. > >> > >> As presented here, the code sends a THRESH Rising event tied to the > >> in_voltageX_raw channel on which it happened. > >> > >> We think this is not correct but we can't seem to find an implementation > >> that would be elegant. > >> > >> The main idea would be to add a specific channel for openwire detection > >> but we still would need to have the openwire enablement and threshold > >> tied to the voltage channel. See below, but a few things in this intro that will make that make more sense... The threshold does make things fiddlier. I wonder if the right value is a actually always a hardware circuit characteristic and should be encoded in firmware. That may not help though as we still need to trigger an explicit test of the channel if I understand correctly. > >> > >> Any thought on this? > >> > >Just to spell this out in a bit more detail, my understanding is that > >the procedure works like this... > > > >To detect an open wire on a single-ended input, we measure the voltage > >on pin VIN0 using channel register 15, the we read the voltage on the > >same pin again using channel register 0. The datasheet isn't clear on > >the details, but on one or the other or both of these, the ADC chip is > >applying some kind of pull up or pull down on the input pin so that > >each measurement will be nearly the same if there is a wire attached > >with a 0-10V signal on it. Or if the wire is detached and the pins are > >left floating, the two measurements will be different (> 300 mV). Ok. So it's a kind of input impedance measure. > > > >So this threshold value (the 300 mV) is measured in terms of the > >difference between two voltage measurements, but of the same input pin. > > > >My suggestion is to create extra differential channels like > >in_voltage0-involtage100_* where 100 is an arbitrary number. These > >channels would be defined as the difference between the two measurements > >on the same pin. The event attributes would use these channels since they > >are triggered by exceeding the threshold value according to this difference > >measurement. > > > >To complicate matters, these chips can also be configured so that two > >input pins can be configured as a fully differential pair. And we can > >also do open wire detection on these differential pairs. In this case > >we would configure input pins VIN0 and VIN1 as a differential pair, then > >read the difference of those two pins using channel register 1, then > >read again using channel register 2. The we see if the difference of the > >two differences exceeds the threshold. > > > >In this case, we can't have in_(voltage0-voltage1)-(voltage100-voltage101)_* > >attributes. So I guess we would have to do something like > >in_voltage200-voltage300 to handle this case? (voltage200 would represent > >the first measurement of voltage0-voltage1 and voltage300 would represent > >the 2nd measurement of the same). That's getting non intuitive fast. We already have the channels, so maybe if we are doing something that is channels specific we should have a trigger attribute on the relevant channel. _check that runs any appropriate checks. That doesn't give the reporting path though. > > Hi Jonathan, > > I was wondering if you had any opinions on this RFC? You caught me hiding from the tricky question :) This was always the last email in my todo list because almost all the others were easier! Hmm. Lack of sensible handling for hardware failure of this sort of 'wire fell out' category has been a long term kernel gap in general, not just in IIO. I've talked to various maintainers etc about it over the years and it was always in the category of things that were interesting but no one had the time to take on. I've never really come up with a satisfactory plan on what to do about it. With my server kernel engineer hat on, I think there are masses of well established paths for what is basically a RAS event, but are those well suited for embedded ADC cases. To give background on how we do it for big systems (ignoring EDAC as that's definitely not relevant here). 1) Error detection anywhere in software spits out a tracepoint. 2) Tracepoints are scooped up by interested software. The opensource project for those is RASdaemon https://github.com/mchehab/rasdaemon +CC Mauro - my goto person for RAS events :) Note that any other interested application with sufficient priv can also listen for those tracepoints. So what to do for embedded cases. I'd love a general agreement as a wire out is a wire out whether it's an spi bus wire, a line to a camera or a input line to an ADC but maybe that's a stretch too far. So we could do: a) Something a bit like you have here. Squirt it out as some sort of event on an IIO channel. I think it needs to be on the normal channel and not care about the complexity of how it is done under the hood. The solution of magic channels is way too device specific. That may mean new attributes to trigger the check and new events to report a failure. + New event types - I'm fine with a top level code for this if we go that way rather than using THRESH. b) Do the triggering of checks as above (may well use a userspace script to do that periodically or even an in kernel thread). Spit the error out as a RAS trace event. We'd need to try and define some general it broke event structures to avoid a massive proliferation with all the userspace tooling mess that brings. Mauro, how does a trace event sound for this sort of thing to you? Do you think we'd get any sort of general adoption? It's a bit early to poke the likely folk (hwmon, SPI, I2C, other buses, maybe clk, regulator etc + all the the other subsytems that have the sort of signals where wire out or short are common events to detect) but if we feel it is a path forwards then I guess I'm sure we can put together a good proposal for what will end up as a stable set of tracepoints. IIO folk, would a trace event be too hard to deal with? Steven Rostedt has some nice libraries etc that wrap up all the complexity pretty well. The tracepoint syntax itself to declare them takes some getting used to but once you've got your head around them is really neat. Jonathan > > Thx, > Guillaume.
