00:57 <set_> Do not bother with whatever I was typing early this morning. I think I found a way in/out.

10:46 <blathijs> Anyone know if enabling internal pullups through the gpiod API should work on a BBB? I've tried running `gpiomon --bias pull-up <chipnum> <linenum>` and that does show "pull-up" in `gpioinfo`, but the pin reads as 0 continuously, and measuring the pin also shows 0V. I've tested with a bare BBB board, and also checked that this pin (P8_17 / GPIO0_17) has nothing else connected on the BBB schematic

10:46 <blathijs> either...

10:52 <blathijs> The debugfs pinmux-pins file for this pin says: `pin 11 (PIN11): ocp:P8_17_pinmux (GPIO UNCLAIMED) function pinmux_P8_17_default_pin group pinmux_P8_17_default_pin`, but I'm not sure how to read that. I'm wondering if the pin might be pin muxed for non-gpio use. If I add an external pullup, I can read the pin as expected, but maybe GPIO read works even with a different pin mux setting?

11:23 <blathijs> Hm, seems indeed that the ocp driver / universal cape overlay is controlling the pull state, if I run `echo gpio_pu | sudo tee /sys/devices/platform/ocp/ocp:P8_17_pinmux/state` (which is what config-pin would run, but I do not have that), then the pullup is enabled as expected.

11:24 <blathijs> Could it be that the GPIO controller bias/pullup state is not propagated to the right place? Can I change some devicetree or other param to have that propagate properly? I'd prefer to manage pull state for gpios through the gpiod interface, and not have another (BBB-specific) setup to do..

11:52 <blathijs> Digging in the kernel sources, there does seem to be machinery in place for this - the omap4-gpio driver calls gpiochip_generic_config() which calls into the pinmux set_config callback, which should set the bias config. It also seems the the gpio-ranges config is set up as expected...

12:23 <blathijs> All this is with a bookworm image from rcn-ee btw, not an official image (since those have no minimal/cli flavor): https://rcn-ee.net/rootfs/release/2023-10-07/bookworm-minimal-armhf/

14:45 <blathijs> Ah, I think I figured it out. It seems the pinctrl DT should have e.g. pinctrl-single,bias-pullup attributes to let the pinctrl driver know what bits to modify to control the bias, as documented in https://www.kernel.org/doc/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt

14:50 <blathijs> A bit weird that no error is returned if the bias bits are unconfigured, since I think an error should be returned from https://github.com/torvalds/linux/blob/45ec2f5f6ed3ec3a79ba1329ad585497cdcbe663/drivers/pinctrl/pinctrl-single.c#L605-L606 via https://github.com/torvalds/linux/blob/45ec2f5f6ed3ec3a79ba1329ad585497cdcbe663/drivers/gpio/gpio-omap.c#L943

15:34 <blathijs> Ok, confirmed that was the problem. Adding this overlay makes gpiod control of pullup/pulldown work (almost - disabling does not work, I copied these values from the pocketbeagle, but the disable values are wrong): https://gist.github.com/matthijskooijman/1632bb60c4349697ba73e04477a428ea

16:08 <blathijs> rcn-ee: ^^ See above - I would like to add "pinctrl-single,bias-pullup/down" properties to the "am335x-bone-uboot-univ.dtb" DT shipped with your images, but I cannot quite find where the source for that DT file lives. Can you point me in the right direction?

16:53 <blathijs> q

16:54 <blathijs> w00ps

17:00 <blathijs> Also, any pointers about what kernel sources and config are used for the builds? Seems there is also a bug in the pinctrl-single driver that I might want to try and fix, but that requires rebuilding the BBB kernel.