Thanks for the reply. We hooked it up to an oscilloscope. The signal looked clean overall. We did notice a small voltage spike on SDA right near the end. I am not sure if that is something checking to see if the line is busy or not. I added pull-up resistors to ensure the signal would move up faster but that didn’t help so I am pretty confident that it isn’t a hardware issue. Not sure if there are any other ideas you have, it sounds like we need to dig into the IMX driver. Oscilloscope images: https://imgur.com/a/CIsZEnx From: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> Date: Tuesday, August 24, 2021 at 12:48 AM To: Andrew Manley <andrew.manley@xxxxxxxxxxxxxxx> Cc: linux-i2c@xxxxxxxxxxxxxxx <linux-i2c@xxxxxxxxxxxxxxx>, biwen.li@xxxxxxx <biwen.li@xxxxxxx>, wsa@xxxxxxxxxx <wsa@xxxxxxxxxx>, Tim Harvey <tharvey@xxxxxxxxxxxxx>, Embedded Controller <embedded-controller@xxxxxxxxxxxxxxx> Subject: Re: I2C_SLAVE_STOP with i.MX 8M Mini I2C driver CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Andrew, On Thu, Aug 19, 2021 at 12:23:29PM +0000, Andrew Manley wrote: > Dear maintainers, > > I have an i.MX 8M Mini and I am running a 5.13 Linux kernel. I am attempting to send IPMI commands to a Supermicro server over I2C. However, I am not sure that the I2C_SLAVE_STOP event is triggering when it is supposed to or at least when I assumed it would trigger. > > First, I instantiated an I2C slave backend with its own address. Then I crafted some IPMI messages following the specification, specifying that the server responds to the slave address that I used to create the backend. After that, I can write the bytes to the server as a master on the I2C bus with no problems. As part of the IPMI specification, the server responds to my request by becoming a master on the I2C bus and then writing the response back to us at the address specified. > > At this point, the i2c-imx.c driver seems to handle all the slave events related to being written to and the backend driver receives all the bytes as they are being received. However, the backend driver doesn't appear to receive the I2C_SLAVE_STOP event when we are finished. This causes a problem as then there is no determinable way to know when the bytes have finished writing. After reading the documentation for the event https://www.kernel.org/doc/html/latest/i2c/slave-interface.html, I assumed it would be triggered after the master is finished writing to us. I also thought as part of the I2C specification that the master was required to send a STOP signal when it was finished. Is it possible that it isn't triggering but should? >From the i2c-imx driver point of view we, detect stop signal on this path: i2c_imx_slave_isr() if (status & I2SR_IAAS) { /* Addressed as a slave */ ... } else if (!(ctl & I2CR_MTX)) { /* Receive mode */ if (status & I2SR_IBB) { /* No STOP signal detected */ ... } else { /* STOP signal is detected */ If IBB would change just after we have read it in the interrupt handler, we would not be able to detect the STOP signal. This is only my assumption. You will need to compare transfer on the BUS (with logic analyzer) with kernel traces. > I noticed that there is a patch 05ae60bc24f765d0db6b7c6e5acabf22718b823d from December that is supposed to "Synthesize end of transaction events". Is it not possible to figure out when the transmission actually ends? It depends on actual hardware implementation of the IBB bit. For example, are we actually able to get IRQ for this bit or we need to poll it? imx8mm documentation is not very clear about it. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ ; | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
