On Tue, Dec 01, 2015 at 10:10:21AM -0600, Nishanth Menon wrote: > TMP102 works based on conversions done periodically. However, as per > the TMP102 data sheet[1] the first conversion is triggered immediately > after we program the configuration register. The temperature data > registers do not reflect proper data until the first conversion is > complete (in our case HZ/4). > > The driver currently sets the last_update to be jiffies - HZ, just > after the configuration is complete. When TMP102 driver registers > with the thermal framework, it immediately tries to read the sensor > temperature data. This takes place even before the conversion on the > TMP102 is complete and results in an invalid temperature read. > > Depending on the value read, this may cause thermal framework to > assume that a critical temperature event has occurred and attempts to > shutdown the system. > > Instead of causing an invalid mid-conversion value to be read > erroneously, we mark the last_update to be in-line with the current > jiffies. This allows the tmp102_update_device function to skip update > until the required conversion time is complete. Further, we ensure to > return -EAGAIN result instead of returning spurious temperature (such > as 0C) values to the caller to prevent any wrong decisions made with > such values. NOTE: this allows the read functions not to be blocking > and allows the callers to make the decision if they would like to > block or try again later. At least the current user(thermal) seems to > handle this by retrying later. > > A simpler alternative approach could be to sleep in the probe for the > duration required, but that will result in latency that is undesirable > and delay boot sequence un-necessarily. > > [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf > > Cc: Eduardo Valentin <edubezval@xxxxxxxxx> > Reported-by: Aparna Balasubramanian <aparnab@xxxxxx> > Reported-by: Elvita Lobo <elvita@xxxxxx> > Reported-by: Yan Liu <yan-liu@xxxxxx> > Signed-off-by: Nishanth Menon <nm@xxxxxx> Applied. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
