On Thu, Nov 30, 2023 at 4:20 PM Nuno Sá <noname.nuno@xxxxxxxxx> wrote: > Well, I did spent some time on the gpio thing so I would like to have it in but yeah, > no hard feelings if it does not go in. I think it's a good idea to include it, especially if you can, in the commit message, illustrate how you test it with the libgpiod toolset. If you can test it all the way such that you have real hardware connected to real electronics where you can observe the values on these pins or read them: even better. GPIOs tend to get used, and then we are prepared. > So, I actually talk with some hw guys and the pull_low is not really like a pull_low > resistor. We usually call it pull down, so the PIN_CONFIG_BIAS_PULL_DOWN config property. This is vital to e.g. create a bit-banged I2C link, which is something I suspect could be useful on this hardware. >These pins are effectively an open drain. Which means, setting them as > input means setting them in high-z (turning off the mosffet) - and I do have a bug in > my code regarding this - The gpiolib framework assumes we can do open drain emulation by setting lines as input. It is used as fallback unless the hardware has an explicit open drain setting. > Or if you want them as outputs you can set the level low > (and it will always be low - just turn on the mosffet) or you can also set high-z > which means it will be either low or high depending on your external circuitry. The > point is, you can still have your pin acting as a normal gpo if you accommodate your > circuitry for it (can also use these pins for things like buses). Yeah that is just standard open drain behaviour, by the book. Also documented in https://docs.kernel.org/driver-api/gpio/driver.html under the heading "GPIO lines with open drain/source support". > Also got me thinking if a gpi vs gpo devicetree property would make sense. But I > would likely leave it more generic/relaxed for now (even though I think you would > need to be creative and actually use more HW to have the possibility of using these > pins as GPIs and GPOs at the same time). We don't define that in the device tree currently, we just make the driver not support output on input-only pins and vice versa, by returning error codes on the .set_direction() callbacks. Yours, Linus Walleij
