p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
linux_old1/include/linux/platform_data/sht15.h

39 lines
1.1 KiB
C
Raw Normal View History

hwmon: sht15 humidity sensor driver Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-14 05:39:45 +08:00
/*
* sht15.h - support for the SHT15 Temperature and Humidity Sensor
*
* Copyright (c) 2009 Jonathan Cameron
*
* Copyright (c) 2007 Wouter Horre
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
hwmon: (sht15) general code clean-up * Add a documentation file for the device. * Respect a bit more the kernel-doc syntax. * Rename some variables for clarity. * Use bool type for flags. * Use an enum for states (actions being done). Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:36 +08:00
*
* For further information, see the Documentation/hwmon/sht15 file.
hwmon: sht15 humidity sensor driver Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-14 05:39:45 +08:00
*/
hwmon: (sht15) add include guard Add include guard to include/linux/platform_data/sht15.h to prevent multiple inclusion. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-01-11 05:44:46 +08:00
#ifndef _PDATA_SHT15_H
#define _PDATA_SHT15_H
hwmon: sht15 humidity sensor driver Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-14 05:39:45 +08:00
/**
* struct sht15_platform_data - sht15 connectivity info
hwmon: (sht15) general code clean-up * Add a documentation file for the device. * Respect a bit more the kernel-doc syntax. * Rename some variables for clarity. * Use bool type for flags. * Use an enum for states (actions being done). Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:36 +08:00
* @gpio_data: no. of gpio to which bidirectional data line is
* connected.
* @gpio_sck: no. of gpio to which the data clock is connected.
* @supply_mv: supply voltage in mv. Overridden by regulator if
* available.
hwmon: (sht15) add support for CRC validation The sht15 sensor allows validating exchanges to and from the device using a crc8 function. An utility function to reverse a byte has also been added. Signed-off-by: Jerome Oufella <jerome.oufella@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:39 +08:00
* @checksum: flag to indicate the checksum should be validated.
hwmon: (sht15) add support for the status register * Add support for: - Heater. - End of battery notice. - Ability not to reload from OTP. - Low resolution (12bit temp, 8bit humidity). * Add an utility function to read individual bytes from the device. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:38 +08:00
* @no_otp_reload: flag to indicate no reload from OTP.
* @low_resolution: flag to indicate the temp/humidity resolution to use.
hwmon: (sht15) general code clean-up * Add a documentation file for the device. * Respect a bit more the kernel-doc syntax. * Rename some variables for clarity. * Use bool type for flags. * Use an enum for states (actions being done). Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:36 +08:00
*/
hwmon: sht15 humidity sensor driver Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-14 05:39:45 +08:00
struct sht15_platform_data {
int gpio_data;
int gpio_sck;
int supply_mv;
hwmon: (sht15) add support for CRC validation The sht15 sensor allows validating exchanges to and from the device using a crc8 function. An utility function to reverse a byte has also been added. Signed-off-by: Jerome Oufella <jerome.oufella@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:39 +08:00
bool checksum;
hwmon: (sht15) add support for the status register * Add support for: - Heater. - End of battery notice. - Ability not to reload from OTP. - Low resolution (12bit temp, 8bit humidity). * Add an utility function to read individual bytes from the device. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2011-04-13 03:34:38 +08:00
bool no_otp_reload;
bool low_resolution;
hwmon: sht15 humidity sensor driver Data sheet at: http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf These sensors communicate over a 2 wire bus running a device specific protocol. The complexity of the driver is mainly due to handling the substantial delays between requesting a reading and the device pulling the data line low to indicate that the data is available. This is handled by an interrupt that is disabled under all other conditions. I wasn't terribly clear on the best way to handle this, so comments on that aspect would be particularly welcome! Interpretation of the temperature depends on knowing the supply voltage. If configured in a board config as a regulator consumer this is obtained from the regulator subsystem. If not it should be provided in the platform data. I've placed this driver in the hwmon subsystem as it is definitely a device that may be used for hardware monitoring and with it's relatively slow response times (up to 120 millisecs to get a reading) a caching strategy certainly seems to make sense! Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-14 05:39:45 +08:00
};
hwmon: (sht15) add include guard Add include guard to include/linux/platform_data/sht15.h to prevent multiple inclusion. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-01-11 05:44:46 +08:00
#endif /* _PDATA_SHT15_H */