09:29 <jkridner> rcn-ee zmatt: let me know if i understand. i think this is all about setting up the dt properly such that there is a header-pin associated entry with pinmux assignments for suitable peripherals, including gpio using this aggregator thing, such that my suggested led/button hacks aren’t needed. pinctrl would then either assign the pinmuxes at boot based on enabling those entries in the dt or at runtime based on debugfs updates to enable a

09:29 <jkridner> peripheral. conflicts would detect appropriately. is that right?

10:45 <zmatt> jkridner: I have no idea what you're saying. I'm assuming with "led/button" hacks you mean declaring gpios as leds (if outputs) or buttons (if inputs) even though they're not leds nor buttons? I've never understood why that's a thing anyone would do unless somehow unaware that there's gpio interfaces (sysfs and gpiod)

10:48 <zmatt> gpio-aggregator lets you use DT to combine gpios into a gpiochip device, which is useful for access control since gpiod doesn't let you assign permissions per gpio (like you can with sysfs-gpio), only per gpiochip

10:49 <zmatt> none of this has anything to do with pinmux

10:51 <zmatt> (nor does changing pinmux "enable a peripheral" technically speaking, peripherals and their drivers are unaware of pinmux)

10:56 <zmatt> for runtime pinmux changes, bone-pinmux-helper is actually a pretty straightforward wrapper around the kernel mechanism for selecting pinmux

10:57 <zmatt> (it could have been named better, since there's nothing beaglebone-specific about it)

16:05 <jkridner> zmatt: yeah, it was to give a sysfs hack more versatile than other methods.

16:05 <jkridner> aggregator seems great to give a header gpio definition.

16:07 <jkridner> i think the relationship to pinmux is having a driver to consume the pinctrl such that the pinmux is properly set.

16:08 <jkridner> if someone upstreamed pinmux-helper, that’d be great, but i understood it was rejected

19:20 <zmatt> I mean, if you don't need runtime pinmux switching then attach it to the device whose pins are being muxed, but if you want runtime pinmux switching then pinmux-helper is still the way afaik (mainline or not, it's a trivial enough driver to maintain out of tree if mainline can't come up with something better)

22:34 <rcn-ee> With gpio-aggregrator, I've been successful in getting it to trigger running pinmux changes... On am67a, so usually what pinmux-helper did