Hi Kenny, > If the device can enter deep-sleep arbitrarily, then we presumably also > have problems in i2c_hid_output_raw_report() and > i2c_hid_get_raw_report() which could happen after the device has gone to > sleep from inactivity. These places would also need EREMOTEIO retry logic. It does not enter deep-sleep arbitrarily and therefore it is not a problem with other communication patterns. The design which was chosen back in the day, to save the battery power is event based instead of level based (some HW line). Therefore to avoid power leak we need to request low power state (to prevent power leak in case the kernel will not boot up soon). Basically we need to take out the device from deep state logic by message, without knowing if the device is on the bus or it is on the bus but not responding. > > All these places should have the same sleeping behavior as they are > working around the same device glitch. I imagine the client ACK timeout > is longer than your required 400µs, in which case you don't need any > sleep on retry at all, as is the case in the current i2c_hid_set_power() > implementation. > > However, as we litter retry-code all over the place, Johan's suggestion > about doing this in the I2C driver does become a bit more relevant... > > Best regards, > Kenny Levinsen >
