Thanks.The i2c_stub is not Device Tree-aware in any way - it's not associated with any particular hardware, so even if it could be made to appear in the DT, the Linux devs would not allow it (DT describes hardware, mmmkay?).
Because i2c_stub and the bus it creates do not appear in the DT, there's no way (or at least I can't think of a way) to get an overlay to connect to it.
That brings up a second question I was going to write a separate post for. I'm guessing, since DT only represents physical hardware, there is no such thing as a "virtual" GPIO within the device tree?
The reason I want one (actually 3) is the board I am working on setting up has 4 x tvl320ADC3101 chips on it. Each of these has a RESET pin and they are all hard wired together so all 4 can be RESET by toggling a single GPIO. The problem is that when the driver is probed it first toggles the reset GPIO and then configures the chip (via I2C). This would be ok if all 4 chips had separate GPIOs for the reset but they don't. This means that if I was able to assign the same GPIO to all 4 instances (not even sure I can do that) then when the last chip was probed it would reset the other 3 and they would lose their settings. I do have options to solve this and they are:
- Assign non existent GPIOs to 3 of the chips (virtual GPIO)
- Assign 3 real GPIOs but don't connect them to anything
- Modify the driver so the reset GPIO is optional rather than mandatory
- Something I haven't thought of.
1 is my preferred solution, 2 is a bit of a fudge and 3 is simply a pain since a new kernel may break the modified driver.
Statistics: Posted by SynAckFin — Thu May 30, 2024 6:08 am