**** BEGIN LOGGING AT Sat Jun 27 02:59:57 2020
Jun 27 03:09:51 <ayjay_t> going to live in #math for a while
Jun 27 03:10:02 <zmatt> lol
Jun 27 05:59:57 <MattB0ne> zmatt: I see you did another push
Jun 27 06:00:04 <MattB0ne> and I read the logs
Jun 27 06:01:00 <MattB0ne> about the silent loss of the received byte
Jun 27 06:01:55 <zmatt> yeah I suddenly realized what was going on
Jun 27 06:02:21 <MattB0ne> you a genius
Jun 27 06:02:49 <MattB0ne> and you threw in some read functions
Jun 27 06:02:53 <MattB0ne> yay!!!!
Jun 27 06:03:02 <MattB0ne> is that behavior unique to python
Jun 27 06:03:10 <zmatt> unique to python's ctypes module
Jun 27 06:03:24 <zmatt> well, dunno if it's "unique", but memoryview doesn't have the problem
Jun 27 06:06:52 <MattB0ne> cool I am gonna try and talk to EM100 tomorrow I am going to look up some of these python things like @property and stuff
Jun 27 06:07:35 <MattB0ne> big leap for me is understanding these bit operations
Jun 27 06:07:51 <MattB0ne> i will take that as a win for the day
Jun 27 06:08:52 <zmatt> which bit operations?
Jun 27 06:10:37 <MattB0ne>  just you setting parameters like 1 << 6 or something like that
Jun 27 06:10:52 <MattB0ne> never had to use binary operations
Jun 27 06:11:04 <MattB0ne> or bit manipulation
Jun 27 06:13:25 <MattB0ne> if I can understand what each line is doing that will go a long way to understand the PRUs
Jun 27 06:13:42 <MattB0ne> better than any manual i have seen
Jun 27 06:13:52 <MattB0ne> but python is known for readability
Jun 27 15:32:42 <pdp7> I want to set default mux for free gpio lines in upstream PocketBeagle dts.
Jun 27 15:32:42 <pdp7> Any opinions on if input or output mode a "safer" default?
Jun 27 17:56:14 <zmatt> pdp7: there's no such thing, the macros are just badly named
Jun 27 17:56:28 <zmatt> PIN_INPUT = input enabled, PIN_OUTPU = input disabled
Jun 27 17:56:38 <zmatt> it has no effect on the output driver
Jun 27 17:56:54 <zmatt> and therefore has no effect on safety
Jun 27 18:06:33 <pdp7> zmatt: doesn't output driver depend on the pin control register value?
Jun 27 18:06:53 <zmatt> output driver solely depends on the mux mode, and what the selected peripheral is doing
Jun 27 18:07:08 <pdp7> 0xf being mode 7 and no bias
Jun 27 18:07:33 <pdp7> So that does not effect the electrical output?
Jun 27 18:07:41 <zmatt> for mode 7 (gpio) the output is enabled if the output is enabled in the gpio controller
Jun 27 18:07:54 <pdp7> It is gated by the gpio controller value?
Jun 27 18:08:35 <zmatt> the selected peripheral (in this case the gpio controller) decides whether output is enabled, and if so what the output value is
Jun 27 18:09:06 <pdp7> Ah ok, so it depends on the value at reset in the gpio controller
Jun 27 18:09:12 <zmatt> all gpios are output-disabled after reset
Jun 27 18:09:31 <zmatt> the only way for a gpio to be output-enabled is if software enabled it
Jun 27 18:09:48 <pdp7> Ah ok, thanks
Jun 27 18:11:34 <zmatt> so honestly, the reset defaults are probably fine
Jun 27 18:11:54 <zmatt> the .dts should just leave unused pins unused
Jun 27 18:12:19 <zmatt> so that a dts file for a more specific hardware setup can #include the pocketbeagle dts and add their own devices and pinmux blocks to it without conflits
Jun 27 18:13:30 <zmatt> especially since upstream has no gpio-of-helper so what would you even do with the pins?  what device owns them?
Jun 27 18:29:48 <pdp7> am33xx_pinmux node can own the default state
Jun 27 18:30:54 <zmatt> that's terrible practice though and generally a last resort to fix fuckups in the hardware defaults or whatever is left by u-boot
Jun 27 18:31:42 <pdp7> I wanted something out of the box for upstream users so that they can do something with libgpiod without changing the dts
Jun 27 18:31:58 <zmatt> the reset defaults should be fine for that
Jun 27 18:32:09 <pdp7> But it won't be mode 7
Jun 27 18:32:15 <zmatt> the reset defaults are mode 7
Jun 27 18:32:19 <zmatt> on the am335x
Jun 27 18:32:33 <pdp7> Oh
Jun 27 18:32:38 <pdp7> Good to know
Jun 27 18:32:54 <zmatt> and the fact that libgpiod is inherently incompatible with pinmux declaration is yet another great example of the awfulness of gpiod
Jun 27 18:34:26 <zmatt> because you're basically letting userspace claim arbitrary pins as gpios at runtime, instead of declaring them in DT (with associated pinmux blocks)
Jun 27 18:34:54 <zmatt> I don't understand why anyone thinks this is a good idea
Jun 27 18:35:02 <zmatt> the whole thing is just terrible
Jun 27 18:35:03 <pdp7> Right so that is what I was going to do for the pinmux node default state
Jun 27 18:35:43 <pdp7> To make explicit that those will be mode 7
Jun 27 18:35:47 <zmatt> but, well, you already know my opinion about gpiod, we've talked a fair bit
Jun 27 18:35:58 <pdp7> Because they are being reserved for userspace
Jun 27 18:36:06 <zmatt> except they're not being "reserved"
Jun 27 18:36:11 <zmatt> there's no device making that reservation
Jun 27 18:36:32 <pdp7> gpiod will see that they a not claimed
Jun 27 18:36:55 <zmatt> which is not the same as "reserved for userspace"
Jun 27 18:37:18 <zmatt> https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi  <-- that's what I call "reserved for userspace"
Jun 27 18:37:22 <pdp7> I know that no other driver is using them as nothing claimed them
Jun 27 18:37:42 <zmatt> that's still not the same as reserved for userspace
Jun 27 18:37:57 <pdp7> Ah yes gpio-of-helper
Jun 27 18:38:08 <pdp7> I am trying to figure how to do this without it
Jun 27 18:38:23 <zmatt> you're trying to make something that sucks not suck
Jun 27 18:38:26 <pdp7> I think it is better but it is not upstream
Jun 27 18:39:17 <zmatt> anyway, no use in repeating my arguments from last time ;) ( https://liktaanjeneus.nl/gpio-discussion.html )
Jun 27 18:39:32 <zmatt> gpiod is strictly inferior to sysfs-gpio in every way afaict
Jun 27 18:39:51 <zmatt> and I personally don't consider it usable
Jun 27 18:40:17 <zmatt> but if you do want to use it, the AM335x reset defaults are fine, you don't need to do anything
Jun 27 18:40:49 <zmatt> (and on the AM572x you're expected to let u-boot do the setup)
Jun 27 18:41:02 <pdp7> That is interesting about the am3358
Jun 27 18:41:43 <zmatt> this also means that on the BBB, gpiod lets userspace make short-circuits \o/
Jun 27 18:42:06 <zmatt> which is obviously a great feature to have, for hardware safety
Jun 27 18:42:39 <zmatt> (since some processor pins are tied together in pairs, and userspace could drive them in opposite directions)
Jun 27 18:51:39 <pdp7> Well we already let people do that config-pin. But bone-pinmux-helper will never be accepted
Jun 27 18:52:05 <zmatt> ?  what does this have to do with pinmux-helper?
Jun 27 18:52:09 <zmatt> I'm purely talking about gpio here
Jun 27 18:52:46 <zmatt> I understand upstream doesn't like pinmux-helper, it _is_ kinda gross
Jun 27 18:53:34 <zmatt> and I don't use it myself
Jun 27 18:55:34 <zmatt> (in case it wasn't clear, "obviously a great feature to have" was sarcasm.  I was shitting on gpiod again as usual)
Jun 27 22:25:10 <Srikanth> Hello!!!
Jun 27 22:42:53 <Srikanth> Can anyone help me
Jun 27 22:43:06 <Srikanth> I am not able to connect to the BBB
Jun 27 22:43:27 <Srikanth> nor through SSH neither with puTTy
Jun 27 23:10:43 <Srikanth> hellooo
Jun 27 23:26:36 <Srikanth> hellloooooooooo
Jun 27 23:28:40 <vagrantc> do you have a question?
Jun 27 23:28:47 <Srikanth> Yes
Jun 27 23:29:02 <Srikanth> I am not able to connect wifi to BBB
Jun 27 23:29:16 <Srikanth> I cant find wlan0 either
Jun 28 00:55:47 <Srikanth> Hello Guys!
Jun 28 00:55:52 <Srikanth> anyone here?
Jun 28 01:19:59 <ayjay_t> i ma now
Jun 28 01:20:19 <ayjay_t> oh god nevermind i'm not
Jun 28 01:24:18 <Srikanth> Hey Ayjay
Jun 28 01:24:32 <Srikanth> i am looking for some help
Jun 28 01:24:45 <Srikanth> to get my BBB wifi conected
**** ENDING LOGGING AT Sun Jun 28 02:59:57 2020