**** BEGIN LOGGING AT Sat Nov 05 02:59:57 2022
Nov 05 11:31:01 <AKN> what is the difference between libgpiod from rcn-ee repo and normal repo
Nov 05 11:31:52 <AKN> I have installed latest version from the normal repo but gpiochip number was messed up
Nov 05 11:33:07 <AKN> I checked on the Debian Image it was from rcn-ee it was also gpiochip(n-1)
Nov 05 11:34:13 <AKN> Can we define gpiochip in the DTS file?
Nov 05 12:57:59 <zmatt> AKN: which SoC are you referring to, the am572x ?
Nov 05 12:58:51 <zmatt> regardless, gpio devices are numbered 0-based in whatever order they're probed by the kernel
Nov 05 13:37:17 <AKN_R> zmatt: Yes AM572x.
Nov 05 13:38:43 <AKN_R> In Beaglebone debian its gpiochip(n-1) but in ti-linux-kernel 5.10.y its gpiochip(n+1)
Nov 05 13:39:10 <zmatt> yeah obnoxiously TI used 1-based numbering for some (but inconsistently, not all) things on the AM572x
Nov 05 13:40:22 <zmatt> when you say beaglebone debian, you mean rcn's 5.10-ti kernel?  that sounds odd since it's directly based on TI's kernel (hence the name)
Nov 05 13:40:41 <AKN_R> rcn's 4.14-ti kernel
Nov 05 13:42:14 <AKN_R> Linux beaglebone 4.14.108-ti-r131
Nov 05 13:49:25 <zmatt> AKN_R: sorry, had connection trouble.... anyway, it might be a kernel version thing then?  though if it's kernel version dependent then that's even more reason to not rely on gpiochip numbering
Nov 05 13:51:25 <zmatt> due to TI's 1-based numbering of peripherals on the am572x there are many examples where the numbering in the kernel (and u-boot) is off-by-one from the numbering in the AM572x documentation
Nov 05 13:51:46 <zmatt> e.g. UART1 is /dev/ttyS0, I2C1 is /dev/i2c-0
Nov 05 13:51:52 <zmatt> blame TI
Nov 05 13:52:25 <AKN_R> zmatt: Yes, It took us a while to figure the issue. Thank you.
Nov 05 13:53:18 <zmatt> and only certain peripherals have stable numbering (guaranteed using DT), gpio is not one of these
Nov 05 13:53:34 <zmatt> even though people often rely on its numbering regardless
Nov 05 13:54:16 <AKN_R> It's making hard to debug even smallest issue.
Nov 05 13:55:42 <zmatt> my preferred way to use gpio is by using DT to individually name, configure, and export gpios via sysfs using DT: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi   and then use the udev rule listed in that file to created named symlinks so that applications can access the gpios by name and don't have to know or care about gpio numbering or what gpiochip they belong to: ...
Nov 05 13:55:48 <zmatt> ...https://pastebin.com/YKW7Wcqu
Nov 05 13:56:49 <zmatt> that way if we move gpios in a revision of our hardware (to free up certain pins because we want to use some other functionality that's only available on those pins), we only have to update the dts and applications will work on both hardware revisions without modification
Nov 05 13:59:20 <AKN_R> zmatt: Thank you.
Nov 05 13:59:54 <zmatt> (I don't use gpiod since its design and functionality is worse than sysfs gpio)
**** ENDING LOGGING AT Sun Nov 06 02:59:56 2022