> Probably I know the reason of this - I have taken chuwi vi8 with > gsl1680, after modprobe i2c-dev, i2cdetect -r 3 - detects gsl1680 on > 0x40 PERMANENTLY! In Android touch is on i2c-4, but on the same > address. The differing bus assignment by be caused by slightly different loading order or DeviceTree or platform driver configurations. > AFAIK - i2c devices could switch bus number but not their port on bus, > this means that if you have chipone icn85xx it should answer on 0x48 > on one of the i2c bus. > Am I right? Yes, the device address is normally hardcoded into the device itself. So, unless there is an internal register or a chip pin to change, it will always be the same. And since I2C addressing is standardised, the physical and logical addresses are identical. As mentioned above, the logical I2C bus number may change depending on certain factors. The physical bus pins are still the same though. > In case of Chuwi Vi10 with Chipone icn8528 situation with i2cdetect is > very very strange. > On kernels 4.4.2 and 4.0.1 - modprobe i2c-dev and then i2cdetect -r X > (1,2,3,4) does NOT!!!!!!!! Detect NOTHING permanently on 0x48 on any > bus! > This make me confused completely! To wake up something it should be > visible on i2c bus but it is NOT! It's possible that the device simply doesn't answer until the wakeup pin has turned it on. In the case of the Silead chips, I think they are already turned on at system boot and stay on until they are shut down via PM commands. So you definitely need to configure the GPIO pin, send the wakeup sequence, and then you should be able to communicate with the chip. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
