> I noticed that Lager "ES3.0" board can't boot on this and previous -rc2 branch. > In my and Shimoda-san's check, "ES2.0" seems have no problem. I understand the issue now. It is not about ES3.0 vs. ES2.0, it is about cold-boot vs. warm-boot. I remembered the DA9xxx interrupt storm problems we had, and voila, I could reproduce the lockup on ES2.0 here, but you need to cold-boot and have the da9xxx drivers enabled. The fixup which we have in mach-shmobile/regulator-quirk-rcar-gen2.c is flaky. It only works if the da9xxx devices are added before their drivers are registered. Only then it can apply the fixes to both devices. Otherwise, the driver for the first device gets probed before the fix for the second can be applied. This is what happens with the IP core switcher which is initialized after the i2c drivers are already loaded. The same issue would happen without the IP core switcher if one loads the I2C master driver as a module. So, we need to disable both da9xxx once we detected one. I first had the idea of installing mini i2c drivers which are loaded before the "real" ones and prepare the devices accordingly and then hand over. But even sketching this looks ugly, so I suggest to just use i2c_transfer with hardcoded i2c_messages and device addresses. The fixup is used on specific boards only, and the addresses are not going to change there. If so, the new boards need a new compatible value. I will work the i2c_transfer solution right after I had lunch. Regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
