02:03 <zmatt> I don't see why you'd have any kernel driver involved in this other than perhaps the uio driver to be able to observe the registers from userspace for debugging

02:05 <zmatt> though you'll want to force the kernel to keep the module clock enabled... in 4.x kernels you can do e.g. &i2c2 { status = "disabled"; ti,no-idle; }; or &i2c2 { compatible = "uio", ti,no-idle; };

02:06 <zmatt> I'm not sure whether ti,no-idle; still works in 5.x kernels since there's been some major changes

05:51 <set_> ?

10:00 <set_> ISPs got you down...yeppers.

13:17 <hnv> zmatt: I spent a lot of time making a module that it worked fine for "normal" i2c masters and the sysfs was ready for the reverse engineering process. Sending byte strings to sysfs I was able to set and get the configuration of the (transport layer?) protocol the master I'm trying to RE requires. I know I could use UIO. Despite the problems of

13:17 <hnv> debugging a module I felt attraction to making it :P

13:21 <hnv> I'm configuring the i2c registers based on `i2c-omap.c`, (I've read the `I2C_REVNB_HI` to test my module). I will have to learn how to TX/RX from the PRUs seting the hw i2c registers, and how to load firmware to the PRUs inside the module.

21:14 <hnv> The configuration flowcharts of the OMAP4460 TRM are so cool