09:46 <Daulity> hey

09:46 <Daulity> is there a kernel option to not reset gpio state at linux boot ?

09:52 <zmatt> Daulity: the kernel does not reset any gpio unless explicitly requested to by a driver

09:55 <zmatt> though by default if cape-universal is enabled then a gpio-of-helper device gets set up which configures all gpios as input... though that is normally the state they are in anyway after reset

09:56 <zmatt> Daulity: why? are you setting gpios in u-boot?

10:04 <Daulity> yes u-boot sets a few gpio's before it boots the kernel they get reset to a certain state not certain if u-boot or linux kernel

10:04 <Daulity> was just wondering

10:06 <zmatt> the annoying bit is that this isn't really fixable by applying an overlay on top of cape-universal due the the limitations of overlays and the fact that status="disabled"; doesn't work on individual gpios of a gpio-of-helper device node

10:07 <zmatt> so your options are to modify the cape-universal overlay or disable cape-universal entirely and use an overlay to declare/export gpios (with initialization of your choice)

10:07 <Daulity> i see

10:07 <zmatt> (or fix the gpio-of-helper drivers to respect the status property of individual gpios... which is probably a 2-line patch)

10:07 <zmatt> *driver

10:12 <zmatt> interesting, if CONFIG_OF_KOBJ=n then nodes with non-okay status property don't even get deserialized, however in practice CONFIG_OF_KOBJ is always y (specifically, it is only n in kernels that lack sysfs support)

10:14 <zmatt> yeah it's definitely a 2-line fix

10:16 <zmatt> https://pastebin.com/f8V8pz1V

10:17 <Daulity> thanks :)

10:19 <zmatt> rcn-ee: can you include that patch? that way overlays can disable cape-universal's gpio export for individual gpios used by the overlay

10:20 <zmatt> e.g. &ocp { cape-universal { P9_14 { status = "disabled"; }; }; };

10:23 <zmatt> Daulity: you can use that in an overlay and then if you still want the gpio exported you can just declare your own gpio-of-helper ... unfortunately it doesn't support exporting a gpio without initializing it, but at least you can choose *how* to initialize it (input, output-low, output-high) and whether or not linux userspace is allowed to change the direction of the gpio

14:56 <rcn-ee> zmatt, how far back, should i do everything? (v4.14.x -> mainline). ;)

16:16 <zmatt> rcn-ee: if you include it e.g. in a 4.19 kernel I'm willing to verify it actually works (although I have no idea how it could possibly _not_ work) and then I'd say make it part of the patch that adds gpio-of-helper ... it should probably have been part of it from the start

16:16 <zmatt> not being able to disable cape-universal gpios is presumably also why you did the hack to try to disable gpio conflict detection

16:19 <rcn-ee> i assume it would work for every version..

16:19 <zmatt> indeed

16:21 <zmatt> of_device_is_available(node) returns true if the "status" property of the node is missing, "okay", or "ok", and has been around with that exact functionality since ancient prehistory... like kernel 2.6 or something

21:15 <mattb0ne> zmatt: are you aware of python having some overhead if you were to do a save?

22:39 <mattb0ne> if python is locked to 1 cpu how would threading help

22:39 <mattb0ne> stuck between a rock and a hard place

22:39 <mattb0ne> I need to save data while doing other stuff

22:39 <mattb0ne> this is just something that python is not very good at

22:40 <mattb0ne> if I switched to C or C++ would i see a benefit if I had 1 thread dedicated to saving data

23:07 <zmatt> mattb0ne: for logging data to eMMC/SD you mean? is that necessary, as opposed to sending data to a client system (not the BBB) and saving it there?

23:08 <zmatt> regardless, if you're getting blocked on I/O then using a separate thread in python will indeed help, in the sense of allowing other stuff to get done while the writer thread is blocked on I/O

23:09 <zmatt> while python only allows a single thread at any given time to be executing python code, a thread that's blocked in I/O does not count as "executing python code"

23:09 <zmatt> so while that worker thread is blocked in I/O, your main thread can do other stuff

23:11 <zmatt> mattb0ne: also, everything on the bbb is "locked to 1 cpu" since it only has one :P

23:33 <mattb0ne> yeah I am talking about computer side

23:34 <zmatt> hmm, it's having trouble writing a few dozen KB/s ?

23:53 <mattb0ne> no i have images, so I am having to write ideally 15MB at 30 fps

23:54 <mattb0ne> so I have an enterprise drive that can handle the throughput

23:54 <mattb0ne> using DD I can write sequentially at 1.2GB/s

23:54 <mattb0ne> but saving data to disk and running a gui is too much for a single python thread

23:55 <zmatt> where is the data coming from?

23:55 <zmatt> I'd be more concerned with how the data is being handled in python

23:56 <zmatt> although yes, you may indeed also need a writer thread, but I don't know if that will fix the problem

23:57 <mattb0ne> coming from a area scan camera

23:57 <mattb0ne> so i have these big numpy arrays that I save as npy files for speed

23:58 <mattb0ne> but they are big

23:58 <mattb0ne> tiff have some sort of conversion and are saved at half the speed but the file size is much smaller

23:58 <mattb0ne> i was going to whip up a python program that just makes large randome matrix and save to disk to see how fast I can go