Message-ID: <1c0d4c55-1d76-8256-ac45-6e0e150309d9@axentia.se>
Date:   Wed, 14 Oct 2020 11:12:07 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: using one gpio for multiple dht22 sensors

Hi Rasnus,

On 2020-10-13 23:34, Rasmus Villemoes wrote:
> Hi Peter
> 
> Since you're the author of io-channel-mux.txt, gpio-mux.txt and
> mux-controller.txt, I hope you don't mind me asking some perhaps silly
> questions.

Right, I ended up being the maintainer for a bunch of code I needed to
do things "the right way", i.e. without resorting to gpio-manipulation
and other breaches of abstractions from user-space...

> I'm going to hook up a bunch of dht22 humidity (and temperature) sensors
> [1] (drivers/iio/humidity/dht11.c), but partly due to limited number of
> available gpios, I'm also going to use a 74hc4051 multiplexer [2], so
> that all the dht22's actually sit on the same gpio.
> 
> It's pretty obvious how the multiplexer is to be described in
> device-tree (I'm probably going to send a patch to add support for an
> optional "enable-gpio", as on the 74hc4051, so that MUX_IDLE_DISCONNECT
> gets supported).
> 
> It also seems like io-channel-mux should somehow magically apply to all
> kinds of iio devices, but it can't be that simple. And if it is, I can't
> figure out how to write the DT. So:

The io-channel-mux is for the situation where you have only one iio-device,
and where you can control its environment with a mux. I.e. it is not about
how the device communicates with the host. You then get one new "virtual"
iio-device for every (valid) state of the mux, and when you access those
iio-devices, the mux is configured to select the correct input/output for
the iio-device in question. At least, it should be possible for output
devices as well, but I guess you kind of get into trouble with the output
signal not persisting when the mux changes state, but that is a problem
for the HW people ;-). I originally used it for a single adc device where
the mux simply selected what to measure.

> - do I need to teach the dht11.c driver to be mux-aware?
> - currently, a dht11/dht22 shows up in sysfs with just two files,
> in_humidityrelative_input and in_temp_input. Now, should I end up with
> one device and, say, 2*8 files (so that it seems like one sensor with
> eight input channels), or should it show up as eight different devices?
> If the latter, I guess the device tree would end up with the same "gpios
> = " spec for all eight - is that even allowed?

It's not 100% clear to me how this is connected, but I'm guessing that you
have the "DATA-signal" pin of the dht22s connected to the Y pins of the 4051,
and that Z pin of the 4051 is connected to some gpio, so that you are able
to communicate with the various dht22s by controlling the mux.

This calls for a mux on the single source of communication from the host
to the various real devices that share this single source of communication.
In other words, more like an i2c-mux than an io-channel-mux.

I.e., what you need is "the other kind" of mux/gpio driver, i.e. a driver
that "fans out" a single gpio so that other drivers can treat the pins on
the other side of the mux as gpios.

I guess you'd have to sort out irq-routing through this new mux-gpio driver
since the dht22 driver uses irqs to read input, and there are probably
various other interesting problems as well. Maybe the dgt22 driver needs
to be adjusted depending on how these problems are handled? E.g. maybe it
needs to disable IRQs when it is not expecting communication or something.

I'm not an expert on the intricacies of the gpio subsystem...

Does that help?

Cheers,
Peter

> If you can show how the DT is supposed to describe this situation, I'll
> try to fill out the missing pieces on the driver side.
> 
> [I could also just not describe the multiplexer at all and control
> everything about it by toggling gpios from userspace, and just have a
> single dht22 in DT, but I prefer doing this "the right way" if it's
> feasible.]
> 
> Thanks,
> Rasmus
> 
> Just FTR:
> 
> [1]
> https://www.electroschematics.com/wp-content/uploads/2015/02/DHT22-datasheet.pdf
> [2] https://assets.nexperia.com/documents/data-sheet/74HC_HCT4051.pdf
> 

Powered by blists - more mailing lists