Tests:RCar-Gen2-I2C-demux

From eLinux.org
Revision as of 13:10, 15 December 2017 by W sang (talk | contribs) (release)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This document describes how to test the I2C demux feature on the newly added I2C busses on various R-Car Gen2 based boards.

Setup

Kernel Version and Configuration

Support for this feature is expected to land upstream in v4.16. It is currently available in a topic branch:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/ip-switch-rework-2017

The shmobile_defconfig is suitable for these tests.

Hardware Environment

Busses on the following boards can be tested:

Board/SoC HW I2C bus # Linux I2C bus devicename
Lager/r8a7790 (R-Car H2 SoC) I2C2, I2C3 i2c-12, i2c-13
Koelsch/r8a7791 (R-Car M2-W SoC) I2C2, I2C4 i2c-13, i2c-14
Porter/r8a7791 (R-Car M2-W SoC) I2C2 i2c-10
Gose/r8a7793 (R-Car M2-N SoC) I2C2, I2C4 i2c-11, i2c-12
Alt/r8a7794 (R-Car E2 SoC) I2C1 i2c-11
Silk/r8a7794 (R-Car E2 SoC) I2C1 i2c-10

No hardware modifications are needed.

Software Environment

A busybox with standard commands like cd, cat, echo is needed. Also, i2cdump and i2cdetect from the i2c-tools package are useful for excercising client devices after switching.

Testing (similar to here)

Note: these examples use i2c-11 (used on a Lager board) as the Linux I2C bus devicename. Please replace it with the desired devicename from the table above.

Verify I2C Demux Pinctl Support

The presence of an available_masters file in the sysfs directory for an i2c device indicates that it is a demuxer.

# ls /sys/devices/platform/i2c-11/available_masters
/sys/devices/platform/i2c-11/available_masters

The use of the I2C demux pinctl driver by an I2C demux device can be confirmed by inspecting the driver link in its sysctl directory.

e.g.:

# ls -l /sys/devices/platform/i2c-11/driver
lrwxrwxrwx 1 root root 0 Jan  1 00:05 /sys/devices/platform/i2c-11/driver -> ../../../bus/platform/drivers/i2c-demux-pinctrl

Core Switching

The cores available for use by an i2c demux device may be retrieved from the available_masters file in the device's sysfs directory.

e.g.:

# cat /sys/devices/platform/i2c-11/available_masters
0:/i2c@e6510000 1:/i2c@e6518000 2:/i2c-8

The core currently used by an i2c demux device may be retrieved from the current_master file in the device's sysfs directory. The value shown is the index of the core in use.

e.g.:

# cat /sys/devices/platform/i2c-11/current_master 
0

And the core may be changed by writing to the index of the core to the current_master file.

e.g.:

# echo 2 > /sys/devices/platform/i2c-11/current_master 

You can now start using the bus, e.g. by scanning for devices:

# i2cdetect -y 11
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- 12 -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- 38 39 -- -- 3c -- 3e 3f 
40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- 5a 5b -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

Issues

A Silk board was not available for testing. All other boards have been tested, either locally or remotely.

In general, the tested boards boot fine. No regressions have been encountered. Also, the busses which are only routed to EXIO connectors worked flawlessly as far as this could be remotely tested.

However, changing I2C bus masters at runtime for busses dealing with HDMI or PM will likely cause kernel warnings and maybe OOPSes. The I2C bus may not be available anymore after that. This is a known issue. Before this task started, it was already decided that we consider these as follow-up problems which should not hold back these patches any longer.

These issues come from rebind-issues in the V4L and regulator subsystems. For the former, fixing is WIP. For the latter, it is currently unknown how to deal with rebinding in general.

Conclusion

For all tested boards, all I2C busses could be switched. No further issues than the already known issues have been showing up. All tested boards were able to boot without regressions. A Silk board was not availbale for testing.