09:45 <geertu> broonie: Are you doing linux-next this week?

12:59 <phh> Hello. My company is trying to do a kinda rpi-compatible board (fwiw based on refurbed apq8098 board). What are the mechanisms used to match the GPIOs/pinctrls? Like my instinct is to create a fake /dev/gpiochip0 that would map to real GPIOs to have a gpiochip0 that has the same pinout as rpi. That sounds rather sad. GPIO can be given a name, but the userspace codes I've seen doesn't seem to care about those. And then there is the question of HAT dtbos where i

12:59 <phh> just can't see how they can work cross-boards.

13:01 <geertu> phh: The fake gpiochip is called "gpio-aggregator" upstream

13:01 <geertu> Making dtbos match is something different...

13:11 <jn> as long as the DTBOs only use GPIO and perhaps a few I2C/SPI/serial buses, it should be possible

13:31 <LeSpocky> phh: my userspace code usually uses "gpiod_line_find()" from libgpiod 1.x so I don't need to care about gpio chip at all, but it requires reasonable line names … however rpi folks tend to avoid libgpiod anyways, and came up with all kinds of incompatible new gpio libraries in the past, so probably you can not make it compatible anyways

13:37 <phh> geertu: oh cool thanks! Just to confirm what i'm reading from https://docs.kernel.org/admin-guide/gpio/gpio-aggregator.html, it can't be done from dts, it has to be done from userspace? (I don't exactly have a hard opinion on which side this compat should go anyway)

13:38 <phh> jn: I'll read those dtbos to check, but dont't dtbos usually refers like gpios = <&gpiochip1 13>; so you need to have a gpiochip with same pinout?

13:44 <phh> LeSpocky: thanks. just to be perfectly sure, you do gpiod_line_find("GPIO14") which is pin 8 of the connector, right? and they are all just called GPIOx, not SPI_MOSI or something?

13:48 <geertu> phh: It can be done from DTS, cfr. the "Generic GPIO Driver" section. You do have to add #gpio-cells = <...>

13:50 <phh> well it still mentions there is a userpace part required with the driver_override, unless we declare a "gpio-delay", which err

13:56 <LeSpocky> phh: I don't do it on rpi but other arm boards, but yes sth. like gpiod_line_find("GPIO14")

13:59 <phh> ok thanks

14:40 <broonie> geertu: I've got a build running now

14:58 <geertu> phh: Come up with a good compatible value, document it, and add it to gpio_aggregator_dt_ids[]? Then no driver_override is needed.

15:01 <phh> geertu: my instinct says that someone would have tried, but yeah ok, i guess it's worth a try. I'm just surprised, there is no reason we would be the first one to wonder about that

16:13 <robmur01> phh: if it's just a case of mapping SoC pins to a "standard" connector, isn't this what you want - https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#nexus-nodes-and-specifier-mapping

16:19 <phh> robmur01: looks good thanks. But that doesn't create a gpiochip for it, does it? So the mapping only works for kernel and not for user space?

16:20 <cambrian_invader> huh, that's pretty neat

16:20 <cambrian_invader> when did that get added

16:24 <cambrian_invader> 2018 apparently (!)

16:48 <jn> phh: yes, you'll need the same pinout, which is the point of the GPIO aggregator