15:08 <zmatt> (you should definitely never define a phandle)

17:56 <zmatt> hnv: what did you mean by "I should define the phandle anyway" ? you should definitely never assign a value to the "phandle" property of nodes, the dtc compiler deals with that

17:59 <zmatt> *the dt compiler (dtc) deals with that

18:01 <zmatt> whatever overlay enables the i2c bus should also attach appropriate pinmux to it

18:02 <zmatt> (or you can use runtime pin configuration using config-pin)

18:04 <zmatt> you can use my show-pins script to verify pin configuration: https://github.com/mvduin/bbb-pin-utils#show-pins

18:53 <hnv> zmatt: about the phandle, I have that footnote wrong maybe. I was talking about the string? assigned to `pinctrl-0` that should match the label in `&am33xx_pinmux`

18:59 <hnv> I wrote the overlay and the physical part works. The bbb as i2c slave works fine, most of the time. My main issue is that I'm missing the first byte. `I2C_SLAVE_WRITE_RECEIVED` event arrives with the second byte; sometimes the first if I'm lucky. I have no clue. maybe there is an "no-idle" directive to add?

21:36 <zmatt> sounds more like whatever this "slave patch" for the kernel driver is doing is broken

22:04 <hnv> this is the patch btw https://github.com/enndubyu/omap_i2c_slave/blob/master/0001-i2c-omap-add-slave-support.patch

22:11 <zmatt> note that multi-master is inherently broken in the omap i2c peripheral, but using it slave-only should iirc be fine

22:17 <hnv> There is only one master in this bus. The thing is, this master is so rude, it's constantly reading bytes, like "anything new?" like in a FreeRTOS task with no sleep/delay. It's achieving some sort of unintended "attack" and Opps-ing the subsystem and disabling the irq

22:17 <zmatt> (apart from the lockup bug where an sda glitch or certain other protocol errors causes the peripheral to no longer respond to slave address nor initiate any master transaction)

22:17 <zmatt> hnv: well, that doesn't matter with i2c since the am335x will simply stretch the clock

22:17 <zmatt> if the master is going too fast

22:20 <zmatt> oh ew I found some old messages, I found more issues with the omap i2c peripheral in slave mode

22:21 <hnv> the Opps: https://pastebin.com/68TB8chr

22:23 <zmatt> a fragment from an old message I wrote: https://pastebin.com/s1QJg9fq

22:24 <zmatt> an oops is a kernel bug, though since you've applied an unofficial patch and are testing with a custom driver I'd say those are the most likely candidates for being responsible for the oops

22:26 <zmatt> looks like an i2c transfer was started whose data was a NULL pointer?

22:30 <zmatt> regardless, if this master is constantly performing reads then you really don't want to handle this in linux since your system will be frozen, I'd say use PRU instead.

22:32 <zmatt> as in, have PRU service the I2C controller that's operating in slave mode... it will have no trouble keeping up with it

22:32 <zmatt> brb

22:33 <hnv> I would love to, but I'm a bit rusted with the PRUs

22:34 <hnv> "I2C controller" in the silicon or in the kernel/module?

22:44 <zmatt> silicon

22:45 <zmatt> i2c is so slow that it wouldn't matter if you take the performance hit of programming the PRU core in C instead of asm :P

22:48 <hnv> And who is going to configure the controller, the PRUs? or using UIO? or some other driver?

22:49 <hnv> (if the controller takes care of the slave state machine it will be great)

22:50 <zmatt> many years ago I did quite extensive testing of TI's i2c controller, I had a perfect environment for it with a baremetal Forth on the SoC that allows me to interactively poke the peripheral while logging changes in irq status and on the bus I had a microcontroller running a simple i2c debugger I wrote which could log i2c bus activity in real time (using clock stretching as needed to slow it down) as ...

22:50 <zmatt> ...well as having a mode where I could single-step i2c transactions bit for bit

22:52 <hnv> awesome.

22:52 <zmatt> here are the notes I wrote, showing detailed i2c controller behavioured in various examples and corner cases: https://pastebin.com/rrphk18q

22:53 <zmatt> but yeah, the controller takes care of a lot of it

22:54 <zmatt> if you only need to support i2c reads then the only case you'll ever see is the very first one listed, "slave transmitter"

22:59 <zmatt> so what is the master reading, what data are you sending in response?

22:59 <zmatt> like, is this data the PRU could easily produce? (e.g. read a fixed buffer in memory)

23:08 <hnv> Yeah, I think. apart from constantly reading for any news from the slave, the master writes something like `size, -question-, checksum, stop` and the slave stops transmitting "nothing new", and sends `size, checksum, stop`,`-answer-, checksum, stop`. There are multiple questions and answers I'm trying to figure up. I have the actual slave too.

23:08 <hnv> There are multiple questions, and I was using hashtables for that. But I can switch to a fixed buffer I guess

23:09 <zmatt> ah okay so it's not just reads

23:16 <zmatt> well okay so the code won't be completely trivial, but it's still pretty straightforward. like, you get an event when addressed as slave and you'll either get bytes of data for a write or you'll be expected to provide bytes of data for a read

23:16 <zmatt> assuming the work of preparing data to be read is done when the write is performed, the read is presumably trivial

23:21 <zmatt> I'm looking at some bare metal code I wrote... initialization appears to be like 10 lines of code

23:22 <zmatt> or less

23:25 <zmatt> writing this code in PRU is probably simpler than debugging whatever is going on in the linux kernel :P

23:26 <zmatt> and as a bonus you'll have something that can actually tolerate getting spammed by the master

23:27 <hnv> A long time ago, I wrote the initialization for the spi0 on C and share it to the PRU through shared memory

23:27 <hnv> Yeah, I was starting to set up kgdb

23:27 <zmatt> what bus speed are you using? 100 kHz ?

23:28 <hnv> yes

23:29 <zmatt> so 2000 pru clock cycles per bit... like, PRU will have no problem handling any event before the next clock edge

23:30 <zmatt> which also eliminates most headaches of this controller (like the possibility of losing track of which bytes belong to which transaction obviously doesn't apply)

23:31 <zmatt> bbl