On Sat, 1 Feb 2025 17:38:20 +0200 Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote: > On 31/01/2025 19:41, Jonathan Cameron wrote: > > On Fri, 31 Jan 2025 15:37:48 +0200 > > Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote: > > > >> The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports > >> an automatic measurement mode, with an alarm interrupt for out-of-window > >> measurements. The window is configurable for each channel. > >> > >> The I2C protocol for manual start of the measurement and data reading is > >> somewhat peculiar. It requires the master to do clock stretching after > >> sending the I2C slave-address until the slave has captured the data. > >> Needless to say this is not well suopported by the I2C controllers. > > > > From what I recall that is in the I2C spec, so in theory should be supported. > > Ah well. > > Could be I am mistaken then. Or, maybe I just misused the term "master > to do clock stretching". > > I know that it is not rare the slave device is keeping the clock down > for extended period (in this case so that the measurement would be > completed) - but at least I am not aware of any APIs which could be used > to cause the _master_ side to keep the SCL low for an extended period > after receiving the ACK (after sending the slave address). In this case > it would require this driver to be able to set a time for how long the > master would keep SCL low after sensing the slave address, before > sending the "command" bytes. > > |S|ADDRESS+R|a|STRETCH|8-bit-i2c-frame|A|8-bit-i2c-frame|A|STRETCH|8-bit-i2c... > > Above denotes this "master stretching". CAPITALs are initiated by > master, lowercase by slave. S, is start, a is ack and R is read-bit. Ah. That is indeed more unusual. You were correct that i was thinking of the client side doing the stretching! > > If there is a standard way to implement this in Linux side, then I might > consider using it as it'd allowed much higher capture rates. Not that I'm aware of. Wolfram, have you seen anything like this? > > >> It is worth noting that the ADC input pins can be also configured as > >> general purpose outputs. The pin mode should be configured using pincmux > >> driver. > > > > We shouldn't be presenting channels that are configure for GPIOs as > > ADC channels. It is very rare that there is a usecase for any > > dynamic switching. > > Thanks :) If the dynamic switching is rare, then you're definitely > right. I need to see if using the pinmux still makes sense, and if we > can implement this while using (separate) pinmux driver. > > > Normally it's a case of what is wired and > > so static. > > I should implement a device which can be controlled via it's analog > output line :) If nothing else then a device shutting down when it's > output is pulled low ;) > > ...Well, I have no real use-case for dynamic config either. > > > Hence build the iio_chan_spec array for just the > > channels you want, not the the lot. Channel sub nodes in the > > DT are how we most commonly specify what is wired. > > Hmm. That'd mean the ADC channels _must_ be defined in DT in order to be > usable(?) Well, if this is the usual way, then it should be well known > by users. Thanks. Yes. We basically have two types of binding wrt to channels. 1) Always there - no explicit binding, but also no way to describe anything specific about the channels. 2) Subnode per channel with stuff from adc.yaml and anything device specific. Only channels that that have a node are enabled. There are a few drivers that for historical reasons support both options with 'no channels' meaning 'all channels'. J
