* using one gpio for multiple dht22 sensors @ 2020-10-13 21:34 Rasmus Villemoes 2020-10-14 9:12 ` Peter Rosin 0 siblings, 1 reply; 4+ messages in thread From: Rasmus Villemoes @ 2020-10-13 21:34 UTC (permalink / raw) To: Peter Rosin; +Cc: LKML 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: using one gpio for multiple dht22 sensors 2020-10-13 21:34 using one gpio for multiple dht22 sensors Rasmus Villemoes @ 2020-10-14 9:12 ` Peter Rosin 2020-10-14 9:13 ` Peter Rosin 2020-10-14 11:56 ` Rasmus Villemoes 0 siblings, 2 replies; 4+ messages in thread From: Peter Rosin @ 2020-10-14 9:12 UTC (permalink / raw) To: Rasmus Villemoes; +Cc: LKML 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: using one gpio for multiple dht22 sensors 2020-10-14 9:12 ` Peter Rosin @ 2020-10-14 9:13 ` Peter Rosin 2020-10-14 11:56 ` Rasmus Villemoes 1 sibling, 0 replies; 4+ messages in thread From: Peter Rosin @ 2020-10-14 9:13 UTC (permalink / raw) To: Rasmus Villemoes; +Cc: LKML On 2020-10-14 11:12, Peter Rosin wrote: > Hi Rasnus, Rasmus. *Blush* Cheers, Peter ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: using one gpio for multiple dht22 sensors 2020-10-14 9:12 ` Peter Rosin 2020-10-14 9:13 ` Peter Rosin @ 2020-10-14 11:56 ` Rasmus Villemoes 1 sibling, 0 replies; 4+ messages in thread From: Rasmus Villemoes @ 2020-10-14 11:56 UTC (permalink / raw) To: Peter Rosin, Rasmus Villemoes; +Cc: LKML 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-10-14 11:56 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-13 21:34 using one gpio for multiple dht22 sensors Rasmus Villemoes 2020-10-14 9:12 ` Peter Rosin 2020-10-14 9:13 ` Peter Rosin 2020-10-14 11:56 ` Rasmus Villemoes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).