using one gpio for multiple dht22 sensors

using one gpio for multiple dht22 sensors

[Rasmus Villemoes]

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.

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:

- 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?

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

Re: using one gpio for multiple dht22 sensors

[Peter Rosin]

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
> 

Re: using one gpio for multiple dht22 sensors

[Peter Rosin]

On 2020-10-14 11:12, Peter Rosin wrote:
> Hi Rasnus,

Rasmus.

*Blush*

Cheers,
Peter

Re: using one gpio for multiple dht22 sensors

[Rasmus Villemoes]

On 14/10/2020 11.12, Peter Rosin wrote:
> Hi Rasnus,
> 
> On 2020-10-13 23:34, Rasmus Villemoes wrote:
>> Hi Peter
>>
>> 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.

I see, so it's not really applicable here.

>> - 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.

Exactly. And currently, I just have one dht22 in DT, listing the gpio
the Z-pin is connected to, and have tested that I can talk to all of
them by manipulating the mux from userspace (well, the driver thinks
there's only one dht22, so it imposes a 2 second delay before trying to
talk to "it" again - which is one reason I want to do this right).

> 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.

Hm, so I should create a new "gpio-controller" driver that presents each
of the Y pins as a separate gpio to other DT consumers? But while all
the devm_gpiod_get() would then succeed, only one of them could be
usable at a time. The "gpio-controller" driver would have to handle any
gpiod_xxx call by setting the mux appropriately, then forward the
gpiod_xxx call to the Z pin - but it can't really know when the consumer
is actually done with the gpio. And the consumer (dht11.c) has no way to
know that it should somehow "acquire" and "release" the gpiod when it's
not in use.

> 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,

Well... I've had to monkeypatch the dht11 driver to do
local_irq_save()/read the gpio tightly in a loop until 80something edges
have been seen/local_irq_restore() to get stable readings (maybe I'll do
that as a real patch hanging off a module parameter - the dht22 "1-wire"
protocol is kinda crappy...), so that's not really a problem.

> 
> I'm not an expert on the intricacies of the gpio subsystem...
> 
> Does that help?

Somewhat. Thanks for the quick reply, I'll have to do some more digging
and experimentation.

Rasmus