Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Peter Rosin <peda@axentia.se>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: using one gpio for multiple dht22 sensors
Cc:     LKML <linux-kernel@vger.kernel.org>
Message-ID: <91c25030-d5d1-e3e7-2d26-ac631dddc756@rasmusvillemoes.dk>
Date:   Tue, 13 Oct 2020 23:34:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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