00:12 <Guest47> @zmatt: good advice on the apt-get purge there, that freed up almost 300MB, much better now.  Ty

00:14 <zmatt> yw

00:15 <GenTooMan> set_, haven't touched them in a while mind keeps going blank when I do ... I guess that is to be expected :D

01:38 <set_> Oh.

01:39 <set_> I keep reading. I get ideas here and there but nothing compounded.

01:39 <set_> No summaries yet...blah.

01:40 <set_> It seems BBBlue and arducopter beat me again. I even broke something else this time (AGAIN).

01:41 <set_> It is like an endless loop of not working correctly and yet people are flying around their BBBlues w/ arducopter? Aw!

01:42 <set_> Anyway, Friday Funday turned out to be a bugger in the milk.

01:42 <set_> No one wants tarnished silver.

01:44 <set_> Ha.

11:31 <AKN> what is the difference between libgpiod from rcn-ee repo and normal repo

11:31 <AKN> I have installed latest version from the normal repo but gpiochip number was messed up

11:33 <AKN> I checked on the Debian Image it was from rcn-ee it was also gpiochip(n-1)

11:34 <AKN> Can we define gpiochip in the DTS file?

12:57 <zmatt> AKN: which SoC are you referring to, the am572x ?

12:58 <zmatt> regardless, gpio devices are numbered 0-based in whatever order they're probed by the kernel

13:37 <AKN_R> zmatt: Yes AM572x.

13:38 <AKN_R> In Beaglebone debian its gpiochip(n-1) but in ti-linux-kernel 5.10.y its gpiochip(n+1)

13:39 <zmatt> yeah obnoxiously TI used 1-based numbering for some (but inconsistently, not all) things on the AM572x

13:40 <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)

13:40 <AKN_R> rcn's 4.14-ti kernel

13:42 <AKN_R> Linux beaglebone 4.14.108-ti-r131

13:49 <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

13:51 <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

13:51 <zmatt> e.g. UART1 is /dev/ttyS0, I2C1 is /dev/i2c-0

13:51 <zmatt> blame TI

13:52 <AKN_R> zmatt: Yes, It took us a while to figure the issue. Thank you.

13:53 <zmatt> and only certain peripherals have stable numbering (guaranteed using DT), gpio is not one of these

13:53 <zmatt> even though people often rely on its numbering regardless

13:54 <AKN_R> It's making hard to debug even smallest issue.

13:55 <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: ...

13:55 <zmatt> ...https://pastebin.com/YKW7Wcqu

13:56 <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

13:59 <AKN_R> zmatt: Thank you.

13:59 <zmatt> (I don't use gpiod since its design and functionality is worse than sysfs gpio)