| Message ID | 20200629185318.23381-1-wsa+renesas@sang-engineering.com |
|---|---|
| Headers | show |
| Series | i2c: add slave testunit driver | expand |
Hi Wolfram, On Mon, Jun 29, 2020 at 06:53:17PM +0000, Wolfram Sang wrote: > Motivated by a series by Alain Volmat which implements SMBus Host Notify > support as a slave backend[1], I wondered how I could actually test it. > Then, I picked up my old idea of a "custom remote device" and > implemented it as another slave backend. This is the first draft and it > works quite well on my Renesas Lager board where I connected two I2C > busses where both I2C controllers are master and slave. One slave is the > testunit, one slave is the HostNotify listener. > > While I really like Alain's approach, there is still some more testing > needed. So, I already release my testing environment, maybe other people > are interested, too. This patch depends on a documentation update. Also, > for Renesas R-Car SoCs, some fixes are needed. I suggest you simply pull > this branch here: > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/i2c/slave-testunit > > As mentioned elsewhere, support for SMBus Alert and I2C_M_RECV_LEN are > already planned. But I guess you can do much more. > > Ideas and comments welcome! Very good idea to use a slave to send the Host-Notify command to the host for testing. Later on, for SMBus-Alert, a GPIO can be used to loop it back to the tested master to verify that SMBus-Alert is working fine. What you implemented is the "remote" side which I understood is meant to replace a "real" device for those features which are not that common. Shouldn't we also have the "master" side loopback test driver as well to work with this test slave driver ? For example for the Host-Notify that master side loopback test driver would perform the request_irq allowing it to be called back when the slave test driver sends the host-notify command. In case of SMBus-Alert, that would be implementing the .alert function that would be called when the SMBus-Alert is received .. With that the whole loop can be automatically tested. This kind of stuff can of course be enhanced to a LOT of cases .... basically something similar to spi-loopback driver for example except that in case of i2c it needs 2 I2C controllers instead of one for the SPI. > > Happy hacking, > > Wolfram > > [1] http://patchwork.ozlabs.org/project/linux-i2c/list/?series=185718&state=* > > Wolfram Sang (1): > i2c: add slave testunit driver > > Documentation/i2c/slave-testunit-backend.rst | 48 ++++++ > drivers/i2c/Kconfig | 8 + > drivers/i2c/Makefile | 1 + > drivers/i2c/i2c-slave-testunit.c | 146 +++++++++++++++++++ > 4 files changed, 203 insertions(+) > create mode 100644 Documentation/i2c/slave-testunit-backend.rst > create mode 100644 drivers/i2c/i2c-slave-testunit.c > > -- > 2.20.1 >
> Very good idea to use a slave to send the Host-Notify command to the host > for testing. Later on, for SMBus-Alert, a GPIO can be used to loop it back > to the tested master to verify that SMBus-Alert is working fine. Glad you like it! Yes, SMBusAlert is the next addition planned. > What you implemented is the "remote" side which I understood is meant to > replace a "real" device for those features which are not that common. Correct. > Shouldn't we also have the "master" side loopback test driver as well to > work with this test slave driver ? Yes, ultimately we want that. But for this first draft, I simply triggered with 'i2cset' and checked debug prints plus debugfs for desired outcome. > For example for the Host-Notify that master side loopback test driver would > perform the request_irq allowing it to be called back when the slave test > driver sends the host-notify command. > In case of SMBus-Alert, that would be implementing the .alert function that > would be called when the SMBus-Alert is received .. Exactly. I am simply focussed on the remote side for now because I am curious if it works at all. And what other parts need fixing, e.g. the I2C core patch I sent a few minutes ago. > With that the whole loop can be automatically tested. This kind of stuff > can of course be enhanced to a LOT of cases .... basically something similar > to spi-loopback driver for example except that in case of i2c it needs 2 > I2C controllers instead of one for the SPI. This is my ultimate goal, too: scriptable tests for I2C mastes. Basic functionality can be tested with a simple device, say an EEPROM. But the rare stuff needs something like this testunit.