* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-26 8:51 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-26 8:51 UTC (permalink / raw)
To: Shawn Guo, Jean Delvare
Cc: jimwall, brian, Maxime Ripard, Grant Likely, Rob Herring,
Rob Landley, Guenter Roeck, Russell King, devicetree-discuss,
linux-doc, linux-kernel, lm-sensors, linux-arm-kernel,
Alexandre Belloni
The low resolution ADC of the mxs is able to read an internal temperature
sensor, expose that using hwmon.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
.../devicetree/bindings/hwmon/mxs-cputemp.txt | 18 +++
Documentation/hwmon/mxs-cputemp | 29 +++++
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/mxs-cputemp.c | 132 +++++++++++++++++++++
5 files changed, 190 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
create mode 100644 Documentation/hwmon/mxs-cputemp
create mode 100644 drivers/hwmon/mxs-cputemp.c
diff --git a/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
new file mode 100644
index 0000000..7d3ae47
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
@@ -0,0 +1,18 @@
+mxs cputemp hwmon sensors
+-------------------------
+
+See: Documentation/hwmon/mxs-cputemp
+
+Required properties:
+- compatible: should be "fsl,mxs-internal-temp"
+- io-channels: should list the two adc channels needed to calculate the
+ temperature
+- io-channel-names: should map the previously listed adc channels to the "min"
+ and "max" value
+
+Example:
+ temp {
+ compatible = "fsl,mxs-internal-temp";
+ io-channels = <&lradc 8>, <&lradc 9>;
+ io-channel-names = "min", "max";
+ };
diff --git a/Documentation/hwmon/mxs-cputemp b/Documentation/hwmon/mxs-cputemp
new file mode 100644
index 0000000..6c6201f
--- /dev/null
+++ b/Documentation/hwmon/mxs-cputemp
@@ -0,0 +1,29 @@
+Kernel driver mxs-cputemp
+=========================
+
+Supported chips:
+ * Freescale i.mx28
+ Datasheet: i.MX28 Applications Processor Reference Manual, Rev. 1, 2010
+ http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
+
+Author: Alexandre Belloni
+
+Description
+-----------
+This driver permits reading the internal die temperature sensor embedded inside
+Freescale i.mx28 SoCs. This sensor is read through two channels of the on chip
+Low-Resolution ADC. After calculation, the three-sigma error of the temperature
+sensor should be within ± 1.5% in degrees Kelvin. Additionally, the temperature
+sampling has a three-sigma sample-to-sample variation of 2 degrees Kelvin. If
+desired, this error can be removed by oversampling and averaging the temperature
+result.
+
+The formula is:
+ (Channel9 – Channel8) * Gain_correction/4
+
+As recommended by the datasheet, Gain_correction is equal to 1.012.
+
+sysfs entries
+-------------
+temp1_input Measured and corrected temperature in millidegrees Celsius
+
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0428e8a..2daf794 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -929,6 +929,16 @@ config SENSORS_MCP3021
This driver can also be built as a module. If so, the module
will be called mcp3021.
+config SENSORS_MXS_CPU
+ tristate "MXS internal CPU temperature sensor"
+ depends on MXS_LRADC
+ help
+ If you say yes here you get support for the i.mx28 internal
+ temperature sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called mxs-cputemp
+
config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
depends on !PPC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d17d3e6..366c92d 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
+obj-$(CONFIG_SENSORS_MXS_CPU) += mxs-cputemp.o
obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
diff --git a/drivers/hwmon/mxs-cputemp.c b/drivers/hwmon/mxs-cputemp.c
new file mode 100644
index 0000000..a312fb5
--- /dev/null
+++ b/drivers/hwmon/mxs-cputemp.c
@@ -0,0 +1,132 @@
+/*
+ * Driver for the mxs internal temperature sensor
+ *
+ * Copyright 2013 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#define DRVNAME "mxs-hwmon"
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/iio/consumer.h>
+
+#define GAIN_CORRECTION 1012
+
+/* The value we calculate from the ADCs is in Kelvins, don't forget to convert
+ * it to Celsius */
+#define VALUES_TO_MILLIC(min, max) ((max - min) * GAIN_CORRECTION / 4 - 272150)
+
+struct mxs_hwmon_data {
+ struct device *hwmon_dev;
+ struct iio_channel *chan_min;
+ struct iio_channel *chan_max;
+};
+
+static int mxs_hwmon_show_temp(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int err, val_min, val_max;
+
+ struct mxs_hwmon_data *data = dev_get_drvdata(dev);
+
+ err = iio_read_channel_raw(data->chan_min, &val_min);
+ if (err < 0)
+ return err;
+
+ err = iio_read_channel_raw(data->chan_max, &val_max);
+ if (err < 0)
+ return err;
+
+ return sprintf(buf, "%u\n", VALUES_TO_MILLIC(val_min, val_max));
+}
+
+static DEVICE_ATTR(temp1_input, S_IRUGO, mxs_hwmon_show_temp, NULL);
+
+static int mxs_hwmon_probe(struct platform_device *pdev)
+{
+ int err;
+ struct mxs_hwmon_data *data;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+
+ err = device_create_file(&pdev->dev, &dev_attr_temp1_input);
+ if (err)
+ return err;
+
+ data->chan_min = iio_channel_get(&pdev->dev, "min");
+ if (IS_ERR(data->chan_min)) {
+ err = PTR_ERR(data->chan_min);
+ goto error_chan_min;
+ }
+
+ data->chan_max = iio_channel_get(&pdev->dev, "max");
+ if (IS_ERR(data->chan_max)) {
+ err = PTR_ERR(data->chan_max);
+ goto error_chan_max;
+ }
+
+ data->hwmon_dev = hwmon_device_register(&pdev->dev);
+ if (IS_ERR(data->hwmon_dev)) {
+ err = PTR_ERR(data->hwmon_dev);
+ goto error_hwmon;
+ }
+
+ return 0;
+
+error_hwmon:
+ iio_channel_release(data->chan_max);
+error_chan_max:
+ iio_channel_release(data->chan_min);
+error_chan_min:
+ device_remove_file(&pdev->dev, &dev_attr_temp1_input);
+
+ return err;
+}
+
+static int mxs_hwmon_remove(struct platform_device *pdev)
+{
+ struct mxs_hwmon_data *data = platform_get_drvdata(pdev);
+
+ iio_channel_release(data->chan_min);
+ iio_channel_release(data->chan_max);
+ hwmon_device_unregister(data->hwmon_dev);
+
+ device_remove_file(&pdev->dev, &dev_attr_temp1_input);
+
+ return 0;
+}
+
+static struct of_device_id mxs_hwmon_of_match[] = {
+ { .compatible = "fsl,mxs-internal-temp", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mxs_hwmon_of_match);
+
+static struct platform_driver mxs_hwmon_driver = {
+ .probe = mxs_hwmon_probe,
+ .remove = mxs_hwmon_remove,
+ .driver = {
+ .name = DRVNAME,
+ .owner = THIS_MODULE,
+ .of_match_table = mxs_hwmon_of_match,
+ },
+};
+
+module_platform_driver(mxs_hwmon_driver);
+
+MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@free-electrons.com>");
+MODULE_DESCRIPTION("Freescale i.MX28 hwmon sensor driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:mxs-hwmon");
--
1.8.1.2
^ permalink raw reply related [flat|nested] 42+ messages in thread* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-26 8:51 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-26 8:51 UTC (permalink / raw)
To: linux-arm-kernel
The low resolution ADC of the mxs is able to read an internal temperature
sensor, expose that using hwmon.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
.../devicetree/bindings/hwmon/mxs-cputemp.txt | 18 +++
Documentation/hwmon/mxs-cputemp | 29 +++++
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/mxs-cputemp.c | 132 +++++++++++++++++++++
5 files changed, 190 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
create mode 100644 Documentation/hwmon/mxs-cputemp
create mode 100644 drivers/hwmon/mxs-cputemp.c
diff --git a/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
new file mode 100644
index 0000000..7d3ae47
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
@@ -0,0 +1,18 @@
+mxs cputemp hwmon sensors
+-------------------------
+
+See: Documentation/hwmon/mxs-cputemp
+
+Required properties:
+- compatible: should be "fsl,mxs-internal-temp"
+- io-channels: should list the two adc channels needed to calculate the
+ temperature
+- io-channel-names: should map the previously listed adc channels to the "min"
+ and "max" value
+
+Example:
+ temp {
+ compatible = "fsl,mxs-internal-temp";
+ io-channels = <&lradc 8>, <&lradc 9>;
+ io-channel-names = "min", "max";
+ };
diff --git a/Documentation/hwmon/mxs-cputemp b/Documentation/hwmon/mxs-cputemp
new file mode 100644
index 0000000..6c6201f
--- /dev/null
+++ b/Documentation/hwmon/mxs-cputemp
@@ -0,0 +1,29 @@
+Kernel driver mxs-cputemp
+=========================
+
+Supported chips:
+ * Freescale i.mx28
+ Datasheet: i.MX28 Applications Processor Reference Manual, Rev. 1, 2010
+ http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
+
+Author: Alexandre Belloni
+
+Description
+-----------
+This driver permits reading the internal die temperature sensor embedded inside
+Freescale i.mx28 SoCs. This sensor is read through two channels of the on chip
+Low-Resolution ADC. After calculation, the three-sigma error of the temperature
+sensor should be within ? 1.5% in degrees Kelvin. Additionally, the temperature
+sampling has a three-sigma sample-to-sample variation of 2 degrees Kelvin. If
+desired, this error can be removed by oversampling and averaging the temperature
+result.
+
+The formula is:
+ (Channel9 ? Channel8) * Gain_correction/4
+
+As recommended by the datasheet, Gain_correction is equal to 1.012.
+
+sysfs entries
+-------------
+temp1_input Measured and corrected temperature in millidegrees Celsius
+
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0428e8a..2daf794 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -929,6 +929,16 @@ config SENSORS_MCP3021
This driver can also be built as a module. If so, the module
will be called mcp3021.
+config SENSORS_MXS_CPU
+ tristate "MXS internal CPU temperature sensor"
+ depends on MXS_LRADC
+ help
+ If you say yes here you get support for the i.mx28 internal
+ temperature sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called mxs-cputemp
+
config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
depends on !PPC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d17d3e6..366c92d 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
+obj-$(CONFIG_SENSORS_MXS_CPU) += mxs-cputemp.o
obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
diff --git a/drivers/hwmon/mxs-cputemp.c b/drivers/hwmon/mxs-cputemp.c
new file mode 100644
index 0000000..a312fb5
--- /dev/null
+++ b/drivers/hwmon/mxs-cputemp.c
@@ -0,0 +1,132 @@
+/*
+ * Driver for the mxs internal temperature sensor
+ *
+ * Copyright 2013 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#define DRVNAME "mxs-hwmon"
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/iio/consumer.h>
+
+#define GAIN_CORRECTION 1012
+
+/* The value we calculate from the ADCs is in Kelvins, don't forget to convert
+ * it to Celsius */
+#define VALUES_TO_MILLIC(min, max) ((max - min) * GAIN_CORRECTION / 4 - 272150)
+
+struct mxs_hwmon_data {
+ struct device *hwmon_dev;
+ struct iio_channel *chan_min;
+ struct iio_channel *chan_max;
+};
+
+static int mxs_hwmon_show_temp(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int err, val_min, val_max;
+
+ struct mxs_hwmon_data *data = dev_get_drvdata(dev);
+
+ err = iio_read_channel_raw(data->chan_min, &val_min);
+ if (err < 0)
+ return err;
+
+ err = iio_read_channel_raw(data->chan_max, &val_max);
+ if (err < 0)
+ return err;
+
+ return sprintf(buf, "%u\n", VALUES_TO_MILLIC(val_min, val_max));
+}
+
+static DEVICE_ATTR(temp1_input, S_IRUGO, mxs_hwmon_show_temp, NULL);
+
+static int mxs_hwmon_probe(struct platform_device *pdev)
+{
+ int err;
+ struct mxs_hwmon_data *data;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+
+ err = device_create_file(&pdev->dev, &dev_attr_temp1_input);
+ if (err)
+ return err;
+
+ data->chan_min = iio_channel_get(&pdev->dev, "min");
+ if (IS_ERR(data->chan_min)) {
+ err = PTR_ERR(data->chan_min);
+ goto error_chan_min;
+ }
+
+ data->chan_max = iio_channel_get(&pdev->dev, "max");
+ if (IS_ERR(data->chan_max)) {
+ err = PTR_ERR(data->chan_max);
+ goto error_chan_max;
+ }
+
+ data->hwmon_dev = hwmon_device_register(&pdev->dev);
+ if (IS_ERR(data->hwmon_dev)) {
+ err = PTR_ERR(data->hwmon_dev);
+ goto error_hwmon;
+ }
+
+ return 0;
+
+error_hwmon:
+ iio_channel_release(data->chan_max);
+error_chan_max:
+ iio_channel_release(data->chan_min);
+error_chan_min:
+ device_remove_file(&pdev->dev, &dev_attr_temp1_input);
+
+ return err;
+}
+
+static int mxs_hwmon_remove(struct platform_device *pdev)
+{
+ struct mxs_hwmon_data *data = platform_get_drvdata(pdev);
+
+ iio_channel_release(data->chan_min);
+ iio_channel_release(data->chan_max);
+ hwmon_device_unregister(data->hwmon_dev);
+
+ device_remove_file(&pdev->dev, &dev_attr_temp1_input);
+
+ return 0;
+}
+
+static struct of_device_id mxs_hwmon_of_match[] = {
+ { .compatible = "fsl,mxs-internal-temp", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mxs_hwmon_of_match);
+
+static struct platform_driver mxs_hwmon_driver = {
+ .probe = mxs_hwmon_probe,
+ .remove = mxs_hwmon_remove,
+ .driver = {
+ .name = DRVNAME,
+ .owner = THIS_MODULE,
+ .of_match_table = mxs_hwmon_of_match,
+ },
+};
+
+module_platform_driver(mxs_hwmon_driver);
+
+MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@free-electrons.com>");
+MODULE_DESCRIPTION("Freescale i.MX28 hwmon sensor driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:mxs-hwmon");
--
1.8.1.2
^ permalink raw reply related [flat|nested] 42+ messages in thread* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-26 8:51 ` Alexandre Belloni
(?)
@ 2013-06-26 14:39 ` Guenter Roeck
-1 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-26 14:39 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Shawn Guo, Jean Delvare, jimwall, brian, Maxime Ripard,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> The low resolution ADC of the mxs is able to read an internal temperature
> sensor, expose that using hwmon.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
Guenter
> .../devicetree/bindings/hwmon/mxs-cputemp.txt | 18 +++
> Documentation/hwmon/mxs-cputemp | 29 +++++
> drivers/hwmon/Kconfig | 10 ++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/mxs-cputemp.c | 132 +++++++++++++++++++++
> 5 files changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
> create mode 100644 Documentation/hwmon/mxs-cputemp
> create mode 100644 drivers/hwmon/mxs-cputemp.c
>
> diff --git a/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
> new file mode 100644
> index 0000000..7d3ae47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
> @@ -0,0 +1,18 @@
> +mxs cputemp hwmon sensors
> +-------------------------
> +
> +See: Documentation/hwmon/mxs-cputemp
> +
> +Required properties:
> +- compatible: should be "fsl,mxs-internal-temp"
> +- io-channels: should list the two adc channels needed to calculate the
> + temperature
> +- io-channel-names: should map the previously listed adc channels to the "min"
> + and "max" value
> +
> +Example:
> + temp {
> + compatible = "fsl,mxs-internal-temp";
> + io-channels = <&lradc 8>, <&lradc 9>;
> + io-channel-names = "min", "max";
> + };
> diff --git a/Documentation/hwmon/mxs-cputemp b/Documentation/hwmon/mxs-cputemp
> new file mode 100644
> index 0000000..6c6201f
> --- /dev/null
> +++ b/Documentation/hwmon/mxs-cputemp
> @@ -0,0 +1,29 @@
> +Kernel driver mxs-cputemp
> +=========================
> +
> +Supported chips:
> + * Freescale i.mx28
> + Datasheet: i.MX28 Applications Processor Reference Manual, Rev. 1, 2010
> + http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
> +
> +Author: Alexandre Belloni
> +
> +Description
> +-----------
> +This driver permits reading the internal die temperature sensor embedded inside
> +Freescale i.mx28 SoCs. This sensor is read through two channels of the on chip
> +Low-Resolution ADC. After calculation, the three-sigma error of the temperature
> +sensor should be within ± 1.5% in degrees Kelvin. Additionally, the temperature
> +sampling has a three-sigma sample-to-sample variation of 2 degrees Kelvin. If
> +desired, this error can be removed by oversampling and averaging the temperature
> +result.
> +
> +The formula is:
> + (Channel9 – Channel8) * Gain_correction/4
> +
> +As recommended by the datasheet, Gain_correction is equal to 1.012.
> +
> +sysfs entries
> +-------------
> +temp1_input Measured and corrected temperature in millidegrees Celsius
> +
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0428e8a..2daf794 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -929,6 +929,16 @@ config SENSORS_MCP3021
> This driver can also be built as a module. If so, the module
> will be called mcp3021.
>
> +config SENSORS_MXS_CPU
> + tristate "MXS internal CPU temperature sensor"
> + depends on MXS_LRADC
> + help
> + If you say yes here you get support for the i.mx28 internal
> + temperature sensor.
> +
> + This driver can also be built as a module. If so, the module
> + will be called mxs-cputemp
> +
> config SENSORS_NCT6775
> tristate "Nuvoton NCT6775F and compatibles"
> depends on !PPC
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index d17d3e6..366c92d 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -108,6 +108,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
> obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
> obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
> obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
> +obj-$(CONFIG_SENSORS_MXS_CPU) += mxs-cputemp.o
> obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
> obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
> obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
> diff --git a/drivers/hwmon/mxs-cputemp.c b/drivers/hwmon/mxs-cputemp.c
> new file mode 100644
> index 0000000..a312fb5
> --- /dev/null
> +++ b/drivers/hwmon/mxs-cputemp.c
> @@ -0,0 +1,132 @@
> +/*
> + * Driver for the mxs internal temperature sensor
> + *
> + * Copyright 2013 Free Electrons
> + *
> + * Licensed under the GPLv2 or later.
> + */
> +
> +#define DRVNAME "mxs-hwmon"
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/iio/consumer.h>
> +
> +#define GAIN_CORRECTION 1012
> +
> +/* The value we calculate from the ADCs is in Kelvins, don't forget to convert
> + * it to Celsius */
> +#define VALUES_TO_MILLIC(min, max) ((max - min) * GAIN_CORRECTION / 4 - 272150)
> +
> +struct mxs_hwmon_data {
> + struct device *hwmon_dev;
> + struct iio_channel *chan_min;
> + struct iio_channel *chan_max;
> +};
> +
> +static int mxs_hwmon_show_temp(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + int err, val_min, val_max;
> +
> + struct mxs_hwmon_data *data = dev_get_drvdata(dev);
> +
> + err = iio_read_channel_raw(data->chan_min, &val_min);
> + if (err < 0)
> + return err;
> +
> + err = iio_read_channel_raw(data->chan_max, &val_max);
> + if (err < 0)
> + return err;
> +
> + return sprintf(buf, "%u\n", VALUES_TO_MILLIC(val_min, val_max));
> +}
> +
> +static DEVICE_ATTR(temp1_input, S_IRUGO, mxs_hwmon_show_temp, NULL);
> +
> +static int mxs_hwmon_probe(struct platform_device *pdev)
> +{
> + int err;
> + struct mxs_hwmon_data *data;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, data);
> +
> + err = device_create_file(&pdev->dev, &dev_attr_temp1_input);
> + if (err)
> + return err;
> +
> + data->chan_min = iio_channel_get(&pdev->dev, "min");
> + if (IS_ERR(data->chan_min)) {
> + err = PTR_ERR(data->chan_min);
> + goto error_chan_min;
> + }
> +
> + data->chan_max = iio_channel_get(&pdev->dev, "max");
> + if (IS_ERR(data->chan_max)) {
> + err = PTR_ERR(data->chan_max);
> + goto error_chan_max;
> + }
> +
> + data->hwmon_dev = hwmon_device_register(&pdev->dev);
> + if (IS_ERR(data->hwmon_dev)) {
> + err = PTR_ERR(data->hwmon_dev);
> + goto error_hwmon;
> + }
> +
> + return 0;
> +
> +error_hwmon:
> + iio_channel_release(data->chan_max);
> +error_chan_max:
> + iio_channel_release(data->chan_min);
> +error_chan_min:
> + device_remove_file(&pdev->dev, &dev_attr_temp1_input);
> +
> + return err;
> +}
> +
> +static int mxs_hwmon_remove(struct platform_device *pdev)
> +{
> + struct mxs_hwmon_data *data = platform_get_drvdata(pdev);
> +
> + iio_channel_release(data->chan_min);
> + iio_channel_release(data->chan_max);
> + hwmon_device_unregister(data->hwmon_dev);
> +
> + device_remove_file(&pdev->dev, &dev_attr_temp1_input);
> +
> + return 0;
> +}
> +
> +static struct of_device_id mxs_hwmon_of_match[] = {
> + { .compatible = "fsl,mxs-internal-temp", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, mxs_hwmon_of_match);
> +
> +static struct platform_driver mxs_hwmon_driver = {
> + .probe = mxs_hwmon_probe,
> + .remove = mxs_hwmon_remove,
> + .driver = {
> + .name = DRVNAME,
> + .owner = THIS_MODULE,
> + .of_match_table = mxs_hwmon_of_match,
> + },
> +};
> +
> +module_platform_driver(mxs_hwmon_driver);
> +
> +MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@free-electrons.com>");
> +MODULE_DESCRIPTION("Freescale i.MX28 hwmon sensor driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:mxs-hwmon");
> --
> 1.8.1.2
>
>
^ permalink raw reply [flat|nested] 42+ messages in thread* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-26 14:39 ` Guenter Roeck
0 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-26 14:39 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> The low resolution ADC of the mxs is able to read an internal temperature
> sensor, expose that using hwmon.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
Guenter
> .../devicetree/bindings/hwmon/mxs-cputemp.txt | 18 +++
> Documentation/hwmon/mxs-cputemp | 29 +++++
> drivers/hwmon/Kconfig | 10 ++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/mxs-cputemp.c | 132 +++++++++++++++++++++
> 5 files changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
> create mode 100644 Documentation/hwmon/mxs-cputemp
> create mode 100644 drivers/hwmon/mxs-cputemp.c
>
> diff --git a/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
> new file mode 100644
> index 0000000..7d3ae47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/mxs-cputemp.txt
> @@ -0,0 +1,18 @@
> +mxs cputemp hwmon sensors
> +-------------------------
> +
> +See: Documentation/hwmon/mxs-cputemp
> +
> +Required properties:
> +- compatible: should be "fsl,mxs-internal-temp"
> +- io-channels: should list the two adc channels needed to calculate the
> + temperature
> +- io-channel-names: should map the previously listed adc channels to the "min"
> + and "max" value
> +
> +Example:
> + temp {
> + compatible = "fsl,mxs-internal-temp";
> + io-channels = <&lradc 8>, <&lradc 9>;
> + io-channel-names = "min", "max";
> + };
> diff --git a/Documentation/hwmon/mxs-cputemp b/Documentation/hwmon/mxs-cputemp
> new file mode 100644
> index 0000000..6c6201f
> --- /dev/null
> +++ b/Documentation/hwmon/mxs-cputemp
> @@ -0,0 +1,29 @@
> +Kernel driver mxs-cputemp
> +=========================
> +
> +Supported chips:
> + * Freescale i.mx28
> + Datasheet: i.MX28 Applications Processor Reference Manual, Rev. 1, 2010
> + http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
> +
> +Author: Alexandre Belloni
> +
> +Description
> +-----------
> +This driver permits reading the internal die temperature sensor embedded inside
> +Freescale i.mx28 SoCs. This sensor is read through two channels of the on chip
> +Low-Resolution ADC. After calculation, the three-sigma error of the temperature
> +sensor should be within ? 1.5% in degrees Kelvin. Additionally, the temperature
> +sampling has a three-sigma sample-to-sample variation of 2 degrees Kelvin. If
> +desired, this error can be removed by oversampling and averaging the temperature
> +result.
> +
> +The formula is:
> + (Channel9 ? Channel8) * Gain_correction/4
> +
> +As recommended by the datasheet, Gain_correction is equal to 1.012.
> +
> +sysfs entries
> +-------------
> +temp1_input Measured and corrected temperature in millidegrees Celsius
> +
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0428e8a..2daf794 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -929,6 +929,16 @@ config SENSORS_MCP3021
> This driver can also be built as a module. If so, the module
> will be called mcp3021.
>
> +config SENSORS_MXS_CPU
> + tristate "MXS internal CPU temperature sensor"
> + depends on MXS_LRADC
> + help
> + If you say yes here you get support for the i.mx28 internal
> + temperature sensor.
> +
> + This driver can also be built as a module. If so, the module
> + will be called mxs-cputemp
> +
> config SENSORS_NCT6775
> tristate "Nuvoton NCT6775F and compatibles"
> depends on !PPC
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index d17d3e6..366c92d 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -108,6 +108,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
> obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
> obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
> obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
> +obj-$(CONFIG_SENSORS_MXS_CPU) += mxs-cputemp.o
> obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
> obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
> obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
> diff --git a/drivers/hwmon/mxs-cputemp.c b/drivers/hwmon/mxs-cputemp.c
> new file mode 100644
> index 0000000..a312fb5
> --- /dev/null
> +++ b/drivers/hwmon/mxs-cputemp.c
> @@ -0,0 +1,132 @@
> +/*
> + * Driver for the mxs internal temperature sensor
> + *
> + * Copyright 2013 Free Electrons
> + *
> + * Licensed under the GPLv2 or later.
> + */
> +
> +#define DRVNAME "mxs-hwmon"
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/iio/consumer.h>
> +
> +#define GAIN_CORRECTION 1012
> +
> +/* The value we calculate from the ADCs is in Kelvins, don't forget to convert
> + * it to Celsius */
> +#define VALUES_TO_MILLIC(min, max) ((max - min) * GAIN_CORRECTION / 4 - 272150)
> +
> +struct mxs_hwmon_data {
> + struct device *hwmon_dev;
> + struct iio_channel *chan_min;
> + struct iio_channel *chan_max;
> +};
> +
> +static int mxs_hwmon_show_temp(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + int err, val_min, val_max;
> +
> + struct mxs_hwmon_data *data = dev_get_drvdata(dev);
> +
> + err = iio_read_channel_raw(data->chan_min, &val_min);
> + if (err < 0)
> + return err;
> +
> + err = iio_read_channel_raw(data->chan_max, &val_max);
> + if (err < 0)
> + return err;
> +
> + return sprintf(buf, "%u\n", VALUES_TO_MILLIC(val_min, val_max));
> +}
> +
> +static DEVICE_ATTR(temp1_input, S_IRUGO, mxs_hwmon_show_temp, NULL);
> +
> +static int mxs_hwmon_probe(struct platform_device *pdev)
> +{
> + int err;
> + struct mxs_hwmon_data *data;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, data);
> +
> + err = device_create_file(&pdev->dev, &dev_attr_temp1_input);
> + if (err)
> + return err;
> +
> + data->chan_min = iio_channel_get(&pdev->dev, "min");
> + if (IS_ERR(data->chan_min)) {
> + err = PTR_ERR(data->chan_min);
> + goto error_chan_min;
> + }
> +
> + data->chan_max = iio_channel_get(&pdev->dev, "max");
> + if (IS_ERR(data->chan_max)) {
> + err = PTR_ERR(data->chan_max);
> + goto error_chan_max;
> + }
> +
> + data->hwmon_dev = hwmon_device_register(&pdev->dev);
> + if (IS_ERR(data->hwmon_dev)) {
> + err = PTR_ERR(data->hwmon_dev);
> + goto error_hwmon;
> + }
> +
> + return 0;
> +
> +error_hwmon:
> + iio_channel_release(data->chan_max);
> +error_chan_max:
> + iio_channel_release(data->chan_min);
> +error_chan_min:
> + device_remove_file(&pdev->dev, &dev_attr_temp1_input);
> +
> + return err;
> +}
> +
> +static int mxs_hwmon_remove(struct platform_device *pdev)
> +{
> + struct mxs_hwmon_data *data = platform_get_drvdata(pdev);
> +
> + iio_channel_release(data->chan_min);
> + iio_channel_release(data->chan_max);
> + hwmon_device_unregister(data->hwmon_dev);
> +
> + device_remove_file(&pdev->dev, &dev_attr_temp1_input);
> +
> + return 0;
> +}
> +
> +static struct of_device_id mxs_hwmon_of_match[] = {
> + { .compatible = "fsl,mxs-internal-temp", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, mxs_hwmon_of_match);
> +
> +static struct platform_driver mxs_hwmon_driver = {
> + .probe = mxs_hwmon_probe,
> + .remove = mxs_hwmon_remove,
> + .driver = {
> + .name = DRVNAME,
> + .owner = THIS_MODULE,
> + .of_match_table = mxs_hwmon_of_match,
> + },
> +};
> +
> +module_platform_driver(mxs_hwmon_driver);
> +
> +MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@free-electrons.com>");
> +MODULE_DESCRIPTION("Freescale i.MX28 hwmon sensor driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:mxs-hwmon");
> --
> 1.8.1.2
>
>
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-26 14:39 ` Guenter Roeck
0 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-26 14:39 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Shawn Guo, Jean Delvare, jimwall, brian, Maxime Ripard,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
T24gV2VkLCBKdW4gMjYsIDIwMTMgYXQgMTA6NTE6MTJBTSArMDIwMCwgQWxleGFuZHJlIEJlbGxv
bmkgd3JvdGU6Cj4gVGhlIGxvdyByZXNvbHV0aW9uIEFEQyBvZiB0aGUgbXhzIGlzIGFibGUgdG8g
cmVhZCBhbiBpbnRlcm5hbCB0ZW1wZXJhdHVyZQo+IHNlbnNvciwgZXhwb3NlIHRoYXQgdXNpbmcg
aHdtb24uCj4gCj4gU2lnbmVkLW9mZi1ieTogQWxleGFuZHJlIEJlbGxvbmkgPGFsZXhhbmRyZS5i
ZWxsb25pQGZyZWUtZWxlY3Ryb25zLmNvbT4KPiAtLS0KCldvdWxkbid0IGl0IG1ha2UgbW9yZSBz
ZW5zZSB0byB1c2UgaWlvLWh3bW9uIGFuZCBpbXByb3ZlIGl0IGlmIG5lY2Vzc2FyeSA/CgpHdWVu
dGVyCgo+ICAuLi4vZGV2aWNldHJlZS9iaW5kaW5ncy9od21vbi9teHMtY3B1dGVtcC50eHQgICAg
ICB8ICAxOCArKysKPiAgRG9jdW1lbnRhdGlvbi9od21vbi9teHMtY3B1dGVtcCAgICAgICAgICAg
ICAgICAgICAgfCAgMjkgKysrKysKPiAgZHJpdmVycy9od21vbi9LY29uZmlnICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgMTAgKysKPiAgZHJpdmVycy9od21vbi9NYWtlZmlsZSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKwo+ICBkcml2ZXJzL2h3bW9uL214cy1jcHV0
ZW1wLmMgICAgICAgICAgICAgICAgICAgICAgICB8IDEzMiArKysrKysrKysrKysrKysrKysrKysK
PiAgNSBmaWxlcyBjaGFuZ2VkLCAxOTAgaW5zZXJ0aW9ucygrKQo+ICBjcmVhdGUgbW9kZSAxMDA2
NDQgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2h3bW9uL214cy1jcHV0ZW1wLnR4
dAo+ICBjcmVhdGUgbW9kZSAxMDA2NDQgRG9jdW1lbnRhdGlvbi9od21vbi9teHMtY3B1dGVtcAo+
ICBjcmVhdGUgbW9kZSAxMDA2NDQgZHJpdmVycy9od21vbi9teHMtY3B1dGVtcC5jCj4gCj4gZGlm
ZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9od21vbi9teHMtY3B1
dGVtcC50eHQgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvaHdtb24vbXhzLWNw
dXRlbXAudHh0Cj4gbmV3IGZpbGUgbW9kZSAxMDA2NDQKPiBpbmRleCAwMDAwMDAwLi43ZDNhZTQ3
Cj4gLS0tIC9kZXYvbnVsbAo+ICsrKyBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5n
cy9od21vbi9teHMtY3B1dGVtcC50eHQKPiBAQCAtMCwwICsxLDE4IEBACj4gK214cyBjcHV0ZW1w
IGh3bW9uIHNlbnNvcnMKPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICsKPiArU2VlOiBE
b2N1bWVudGF0aW9uL2h3bW9uL214cy1jcHV0ZW1wCj4gKwo+ICtSZXF1aXJlZCBwcm9wZXJ0aWVz
Ogo+ICstIGNvbXBhdGlibGU6IHNob3VsZCBiZSAiZnNsLG14cy1pbnRlcm5hbC10ZW1wIgo+ICst
IGlvLWNoYW5uZWxzOiBzaG91bGQgbGlzdCB0aGUgdHdvIGFkYyBjaGFubmVscyBuZWVkZWQgdG8g
Y2FsY3VsYXRlIHRoZQo+ICsJICAgICAgIHRlbXBlcmF0dXJlCj4gKy0gaW8tY2hhbm5lbC1uYW1l
czogc2hvdWxkIG1hcCB0aGUgcHJldmlvdXNseSBsaXN0ZWQgYWRjIGNoYW5uZWxzIHRvIHRoZSAi
bWluIgo+ICsJCSAgICBhbmQgIm1heCIgdmFsdWUKPiArCj4gK0V4YW1wbGU6Cj4gKwl0ZW1wIHsK
PiArCQljb21wYXRpYmxlID0gImZzbCxteHMtaW50ZXJuYWwtdGVtcCI7Cj4gKwkJaW8tY2hhbm5l
bHMgPSA8JmxyYWRjIDg+LCA8JmxyYWRjIDk+Owo+ICsJCWlvLWNoYW5uZWwtbmFtZXMgPSAibWlu
IiwgIm1heCI7Cj4gKwl9Owo+IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL2h3bW9uL214cy1j
cHV0ZW1wIGIvRG9jdW1lbnRhdGlvbi9od21vbi9teHMtY3B1dGVtcAo+IG5ldyBmaWxlIG1vZGUg
MTAwNjQ0Cj4gaW5kZXggMDAwMDAwMC4uNmM2MjAxZgo+IC0tLSAvZGV2L251bGwKPiArKysgYi9E
b2N1bWVudGF0aW9uL2h3bW9uL214cy1jcHV0ZW1wCj4gQEAgLTAsMCArMSwyOSBAQAo+ICtLZXJu
ZWwgZHJpdmVyIG14cy1jcHV0ZW1wCj4gKz09PT09PT09PT09PT09PT09PT09PT09PT0KPiArCj4g
K1N1cHBvcnRlZCBjaGlwczoKPiArICAqIEZyZWVzY2FsZSBpLm14MjgKPiArICAgIERhdGFzaGVl
dDogaS5NWDI4IEFwcGxpY2F0aW9ucyBQcm9jZXNzb3IgUmVmZXJlbmNlIE1hbnVhbCwgUmV2LiAx
LCAyMDEwCj4gKyAgICAJICAgICAgIGh0dHA6Ly9jYWNoZS5mcmVlc2NhbGUuY29tL2ZpbGVzL2Rz
cC9kb2MvcmVmX21hbnVhbC9NQ0lNWDI4Uk0ucGRmCj4gKwo+ICtBdXRob3I6IEFsZXhhbmRyZSBC
ZWxsb25pCj4gKwo+ICtEZXNjcmlwdGlvbgo+ICstLS0tLS0tLS0tLQo+ICtUaGlzIGRyaXZlciBw
ZXJtaXRzIHJlYWRpbmcgdGhlIGludGVybmFsIGRpZSB0ZW1wZXJhdHVyZSBzZW5zb3IgZW1iZWRk
ZWQgaW5zaWRlCj4gK0ZyZWVzY2FsZSBpLm14MjggU29Dcy4gVGhpcyBzZW5zb3IgaXMgcmVhZCB0
aHJvdWdoIHR3byBjaGFubmVscyBvZiB0aGUgb24gY2hpcAo+ICtMb3ctUmVzb2x1dGlvbiBBREMu
IEFmdGVyIGNhbGN1bGF0aW9uLCB0aGUgdGhyZWUtc2lnbWEgZXJyb3Igb2YgdGhlIHRlbXBlcmF0
dXJlCj4gK3NlbnNvciBzaG91bGQgYmUgd2l0aGluIMKxIDEuNSUgaW4gZGVncmVlcyBLZWx2aW4u
IEFkZGl0aW9uYWxseSwgdGhlIHRlbXBlcmF0dXJlCj4gK3NhbXBsaW5nIGhhcyBhIHRocmVlLXNp
Z21hIHNhbXBsZS10by1zYW1wbGUgdmFyaWF0aW9uIG9mIDIgZGVncmVlcyBLZWx2aW4uIElmCj4g
K2Rlc2lyZWQsIHRoaXMgZXJyb3IgY2FuIGJlIHJlbW92ZWQgYnkgb3ZlcnNhbXBsaW5nIGFuZCBh
dmVyYWdpbmcgdGhlIHRlbXBlcmF0dXJlCj4gK3Jlc3VsdC4KPiArCj4gK1RoZSBmb3JtdWxhIGlz
Ogo+ICsJKENoYW5uZWw5IOKAkyBDaGFubmVsOCkgKiBHYWluX2NvcnJlY3Rpb24vNAo+ICsKPiAr
QXMgcmVjb21tZW5kZWQgYnkgdGhlIGRhdGFzaGVldCwgR2Fpbl9jb3JyZWN0aW9uIGlzIGVxdWFs
IHRvIDEuMDEyLgo+ICsKPiArc3lzZnMgZW50cmllcwo+ICstLS0tLS0tLS0tLS0tCj4gK3RlbXAx
X2lucHV0CU1lYXN1cmVkIGFuZCBjb3JyZWN0ZWQgdGVtcGVyYXR1cmUgaW4gbWlsbGlkZWdyZWVz
IENlbHNpdXMKPiArCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaHdtb24vS2NvbmZpZyBiL2RyaXZl
cnMvaHdtb24vS2NvbmZpZwo+IGluZGV4IDA0MjhlOGEuLjJkYWY3OTQgMTAwNjQ0Cj4gLS0tIGEv
ZHJpdmVycy9od21vbi9LY29uZmlnCj4gKysrIGIvZHJpdmVycy9od21vbi9LY29uZmlnCj4gQEAg
LTkyOSw2ICs5MjksMTYgQEAgY29uZmlnIFNFTlNPUlNfTUNQMzAyMQo+ICAJICBUaGlzIGRyaXZl
ciBjYW4gYWxzbyBiZSBidWlsdCBhcyBhIG1vZHVsZS4gIElmIHNvLCB0aGUgbW9kdWxlCj4gIAkg
IHdpbGwgYmUgY2FsbGVkIG1jcDMwMjEuCj4gIAo+ICtjb25maWcgU0VOU09SU19NWFNfQ1BVCj4g
Kwl0cmlzdGF0ZSAiTVhTIGludGVybmFsIENQVSB0ZW1wZXJhdHVyZSBzZW5zb3IiCj4gKwlkZXBl
bmRzIG9uIE1YU19MUkFEQwo+ICsJaGVscAo+ICsJICBJZiB5b3Ugc2F5IHllcyBoZXJlIHlvdSBn
ZXQgc3VwcG9ydCBmb3IgdGhlIGkubXgyOCBpbnRlcm5hbAo+ICsJICB0ZW1wZXJhdHVyZSBzZW5z
b3IuCj4gKwo+ICsJICBUaGlzIGRyaXZlciBjYW4gYWxzbyBiZSBidWlsdCBhcyBhIG1vZHVsZS4g
IElmIHNvLCB0aGUgbW9kdWxlCj4gKwkgIHdpbGwgYmUgY2FsbGVkIG14cy1jcHV0ZW1wCj4gKwo+
ICBjb25maWcgU0VOU09SU19OQ1Q2Nzc1Cj4gIAl0cmlzdGF0ZSAiTnV2b3RvbiBOQ1Q2Nzc1RiBh
bmQgY29tcGF0aWJsZXMiCj4gIAlkZXBlbmRzIG9uICFQUEMKPiBkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9od21vbi9NYWtlZmlsZSBiL2RyaXZlcnMvaHdtb24vTWFrZWZpbGUKPiBpbmRleCBkMTdkM2U2
Li4zNjZjOTJkIDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvaHdtb24vTWFrZWZpbGUKPiArKysgYi9k
cml2ZXJzL2h3bW9uL01ha2VmaWxlCj4gQEAgLTEwOCw2ICsxMDgsNyBAQCBvYmotJChDT05GSUdf
U0VOU09SU19NQVg2NjUwKQkrPSBtYXg2NjUwLm8KPiAgb2JqLSQoQ09ORklHX1NFTlNPUlNfTUFY
NjY5NykJKz0gbWF4NjY5Ny5vCj4gIG9iai0kKENPTkZJR19TRU5TT1JTX01DMTM3ODNfQURDKSs9
IG1jMTM3ODMtYWRjLm8KPiAgb2JqLSQoQ09ORklHX1NFTlNPUlNfTUNQMzAyMSkJKz0gbWNwMzAy
MS5vCj4gK29iai0kKENPTkZJR19TRU5TT1JTX01YU19DUFUpCSs9IG14cy1jcHV0ZW1wLm8KPiAg
b2JqLSQoQ09ORklHX1NFTlNPUlNfTkNUNjc3NSkJKz0gbmN0Njc3NS5vCj4gIG9iai0kKENPTkZJ
R19TRU5TT1JTX05UQ19USEVSTUlTVE9SKQkrPSBudGNfdGhlcm1pc3Rvci5vCj4gIG9iai0kKENP
TkZJR19TRU5TT1JTX1BDODczNjApCSs9IHBjODczNjAubwo+IGRpZmYgLS1naXQgYS9kcml2ZXJz
L2h3bW9uL214cy1jcHV0ZW1wLmMgYi9kcml2ZXJzL2h3bW9uL214cy1jcHV0ZW1wLmMKPiBuZXcg
ZmlsZSBtb2RlIDEwMDY0NAo+IGluZGV4IDAwMDAwMDAuLmEzMTJmYjUKPiAtLS0gL2Rldi9udWxs
Cj4gKysrIGIvZHJpdmVycy9od21vbi9teHMtY3B1dGVtcC5jCj4gQEAgLTAsMCArMSwxMzIgQEAK
PiArLyoKPiArICogRHJpdmVyIGZvciB0aGUgbXhzIGludGVybmFsIHRlbXBlcmF0dXJlIHNlbnNv
cgo+ICsgKgo+ICsgKiBDb3B5cmlnaHQgMjAxMyBGcmVlIEVsZWN0cm9ucwo+ICsgKgo+ICsgKiBM
aWNlbnNlZCB1bmRlciB0aGUgR1BMdjIgb3IgbGF0ZXIuCj4gKyAqLwo+ICsKPiArI2RlZmluZSBE
UlZOQU1FICJteHMtaHdtb24iCj4gKwo+ICsjaW5jbHVkZSA8bGludXgvZGV2aWNlLmg+Cj4gKyNp
bmNsdWRlIDxsaW51eC9lcnIuaD4KPiArI2luY2x1ZGUgPGxpbnV4L2h3bW9uLmg+Cj4gKyNpbmNs
dWRlIDxsaW51eC9od21vbi1zeXNmcy5oPgo+ICsjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+Cj4g
KyNpbmNsdWRlIDxsaW51eC9vZi5oPgo+ICsjaW5jbHVkZSA8bGludXgvb2ZfZGV2aWNlLmg+Cj4g
KyNpbmNsdWRlIDxsaW51eC9wbGF0Zm9ybV9kZXZpY2UuaD4KPiArI2luY2x1ZGUgPGxpbnV4L2lp
by9jb25zdW1lci5oPgo+ICsKPiArI2RlZmluZSBHQUlOX0NPUlJFQ1RJT04gMTAxMgo+ICsKPiAr
LyogVGhlIHZhbHVlIHdlIGNhbGN1bGF0ZSBmcm9tIHRoZSBBRENzIGlzIGluIEtlbHZpbnMsIGRv
bid0IGZvcmdldCB0byBjb252ZXJ0Cj4gKyAqIGl0IHRvIENlbHNpdXMgKi8KPiArI2RlZmluZSBW
QUxVRVNfVE9fTUlMTElDKG1pbiwgbWF4KSAoKG1heCAtIG1pbikgKiBHQUlOX0NPUlJFQ1RJT04g
LyA0IC0gMjcyMTUwKQo+ICsKPiArc3RydWN0IG14c19od21vbl9kYXRhIHsKPiArCXN0cnVjdCBk
ZXZpY2UgKmh3bW9uX2RldjsKPiArCXN0cnVjdCBpaW9fY2hhbm5lbCAqY2hhbl9taW47Cj4gKwlz
dHJ1Y3QgaWlvX2NoYW5uZWwgKmNoYW5fbWF4Owo+ICt9Owo+ICsKPiArc3RhdGljIGludCBteHNf
aHdtb25fc2hvd190ZW1wKHN0cnVjdCBkZXZpY2UgKmRldiwKPiArCQkJICAgICAgIHN0cnVjdCBk
ZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyICpidWYpCj4gK3sKPiArCWludCBlcnIsIHZhbF9t
aW4sIHZhbF9tYXg7Cj4gKwo+ICsJc3RydWN0IG14c19od21vbl9kYXRhICpkYXRhID0gZGV2X2dl
dF9kcnZkYXRhKGRldik7Cj4gKwo+ICsJZXJyID0gaWlvX3JlYWRfY2hhbm5lbF9yYXcoZGF0YS0+
Y2hhbl9taW4sICZ2YWxfbWluKTsKPiArCWlmIChlcnIgPCAwKQo+ICsJCXJldHVybiBlcnI7Cj4g
Kwo+ICsJZXJyID0gaWlvX3JlYWRfY2hhbm5lbF9yYXcoZGF0YS0+Y2hhbl9tYXgsICZ2YWxfbWF4
KTsKPiArCWlmIChlcnIgPCAwKQo+ICsJCXJldHVybiBlcnI7Cj4gKwo+ICsJcmV0dXJuIHNwcmlu
dGYoYnVmLCAiJXVcbiIsIFZBTFVFU19UT19NSUxMSUModmFsX21pbiwgdmFsX21heCkpOwo+ICt9
Cj4gKwo+ICtzdGF0aWMgREVWSUNFX0FUVFIodGVtcDFfaW5wdXQsIFNfSVJVR08sIG14c19od21v
bl9zaG93X3RlbXAsIE5VTEwpOwo+ICsKPiArc3RhdGljIGludCBteHNfaHdtb25fcHJvYmUoc3Ry
dWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKPiArewo+ICsJaW50IGVycjsKPiArCXN0cnVjdCBt
eHNfaHdtb25fZGF0YSAqZGF0YTsKPiArCj4gKwlkYXRhID0gZGV2bV9remFsbG9jKCZwZGV2LT5k
ZXYsIHNpemVvZigqZGF0YSksIEdGUF9LRVJORUwpOwo+ICsJaWYgKCFkYXRhKQo+ICsJCXJldHVy
biAtRU5PTUVNOwo+ICsKPiArCXBsYXRmb3JtX3NldF9kcnZkYXRhKHBkZXYsIGRhdGEpOwo+ICsK
PiArCWVyciA9IGRldmljZV9jcmVhdGVfZmlsZSgmcGRldi0+ZGV2LCAmZGV2X2F0dHJfdGVtcDFf
aW5wdXQpOwo+ICsJaWYgKGVycikKPiArCQlyZXR1cm4gZXJyOwo+ICsKPiArCWRhdGEtPmNoYW5f
bWluID0gaWlvX2NoYW5uZWxfZ2V0KCZwZGV2LT5kZXYsICJtaW4iKTsKPiArCWlmIChJU19FUlIo
ZGF0YS0+Y2hhbl9taW4pKSB7Cj4gKwkJZXJyID0gUFRSX0VSUihkYXRhLT5jaGFuX21pbik7Cj4g
KwkJZ290byBlcnJvcl9jaGFuX21pbjsKPiArCX0KPiArCj4gKwlkYXRhLT5jaGFuX21heCA9IGlp
b19jaGFubmVsX2dldCgmcGRldi0+ZGV2LCAibWF4Iik7Cj4gKwlpZiAoSVNfRVJSKGRhdGEtPmNo
YW5fbWF4KSkgewo+ICsJCWVyciA9IFBUUl9FUlIoZGF0YS0+Y2hhbl9tYXgpOwo+ICsJCWdvdG8g
ZXJyb3JfY2hhbl9tYXg7Cj4gKwl9Cj4gKwo+ICsJZGF0YS0+aHdtb25fZGV2ID0gaHdtb25fZGV2
aWNlX3JlZ2lzdGVyKCZwZGV2LT5kZXYpOwo+ICsJaWYgKElTX0VSUihkYXRhLT5od21vbl9kZXYp
KSB7Cj4gKwkJZXJyID0gUFRSX0VSUihkYXRhLT5od21vbl9kZXYpOwo+ICsJCWdvdG8gZXJyb3Jf
aHdtb247Cj4gKwl9Cj4gKwo+ICsJcmV0dXJuIDA7Cj4gKwo+ICtlcnJvcl9od21vbjoKPiArCWlp
b19jaGFubmVsX3JlbGVhc2UoZGF0YS0+Y2hhbl9tYXgpOwo+ICtlcnJvcl9jaGFuX21heDoKPiAr
CWlpb19jaGFubmVsX3JlbGVhc2UoZGF0YS0+Y2hhbl9taW4pOwo+ICtlcnJvcl9jaGFuX21pbjoK
PiArCWRldmljZV9yZW1vdmVfZmlsZSgmcGRldi0+ZGV2LCAmZGV2X2F0dHJfdGVtcDFfaW5wdXQp
Owo+ICsKPiArCXJldHVybiBlcnI7Cj4gK30KPiArCj4gK3N0YXRpYyBpbnQgbXhzX2h3bW9uX3Jl
bW92ZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQo+ICt7Cj4gKwlzdHJ1Y3QgbXhzX2h3
bW9uX2RhdGEgKmRhdGEgPSBwbGF0Zm9ybV9nZXRfZHJ2ZGF0YShwZGV2KTsKPiArCj4gKwlpaW9f
Y2hhbm5lbF9yZWxlYXNlKGRhdGEtPmNoYW5fbWluKTsKPiArCWlpb19jaGFubmVsX3JlbGVhc2Uo
ZGF0YS0+Y2hhbl9tYXgpOwo+ICsJaHdtb25fZGV2aWNlX3VucmVnaXN0ZXIoZGF0YS0+aHdtb25f
ZGV2KTsKPiArCj4gKwlkZXZpY2VfcmVtb3ZlX2ZpbGUoJnBkZXYtPmRldiwgJmRldl9hdHRyX3Rl
bXAxX2lucHV0KTsKPiArCj4gKwlyZXR1cm4gMDsKPiArfQo+ICsKPiArc3RhdGljIHN0cnVjdCBv
Zl9kZXZpY2VfaWQgbXhzX2h3bW9uX29mX21hdGNoW10gPSB7Cj4gKwl7IC5jb21wYXRpYmxlID0g
ImZzbCxteHMtaW50ZXJuYWwtdGVtcCIsIH0sCj4gKwl7fQo+ICt9Owo+ICtNT0RVTEVfREVWSUNF
X1RBQkxFKG9mLCBteHNfaHdtb25fb2ZfbWF0Y2gpOwo+ICsKPiArc3RhdGljIHN0cnVjdCBwbGF0
Zm9ybV9kcml2ZXIgbXhzX2h3bW9uX2RyaXZlciA9IHsKPiArCS5wcm9iZSA9IG14c19od21vbl9w
cm9iZSwKPiArCS5yZW1vdmUgPSBteHNfaHdtb25fcmVtb3ZlLAo+ICsJLmRyaXZlcgk9IHsKPiAr
CQkubmFtZSA9IERSVk5BTUUsCj4gKwkJLm93bmVyID0gVEhJU19NT0RVTEUsCj4gKwkJLm9mX21h
dGNoX3RhYmxlID0gbXhzX2h3bW9uX29mX21hdGNoLAo+ICsJfSwKPiArfTsKPiArCj4gK21vZHVs
ZV9wbGF0Zm9ybV9kcml2ZXIobXhzX2h3bW9uX2RyaXZlcik7Cj4gKwo+ICtNT0RVTEVfQVVUSE9S
KCJBbGV4YW5kcmUgQmVsbG9uaSA8YWxleGFuZHJlLmJlbGxvbmlAZnJlZS1lbGVjdHJvbnMuY29t
PiIpOwo+ICtNT0RVTEVfREVTQ1JJUFRJT04oIkZyZWVzY2FsZSBpLk1YMjggaHdtb24gc2Vuc29y
IGRyaXZlciIpOwo+ICtNT0RVTEVfTElDRU5TRSgiR1BMIHYyIik7Cj4gK01PRFVMRV9BTElBUygi
cGxhdGZvcm06bXhzLWh3bW9uIik7Cj4gLS0gCj4gMS44LjEuMgo+IAo+IAoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxp
c3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcv
bWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-26 14:39 ` [lm-sensors] " Guenter Roeck
(?)
(?)
@ 2013-06-27 9:17 ` Maxime Ripard
-1 siblings, 0 replies; 42+ messages in thread
From: Maxime Ripard @ 2013-06-27 9:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alexandre Belloni, Shawn Guo, Jean Delvare, jimwall, brian,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > The low resolution ADC of the mxs is able to read an internal temperature
> > sensor, expose that using hwmon.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
>
> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
Actually, I wonder if we should not just put the hwmon driver
capabilities directly into the mxs-lradc driver, just like it's already
been done in this driver for the touchscreen support.
The probing of this hwmon driver doesn't really belong to the DT, it's
not really realistic to probe it from the machine definition, and it
really is the IP that is wired that way.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 9:17 ` Maxime Ripard
0 siblings, 0 replies; 42+ messages in thread
From: Maxime Ripard @ 2013-06-27 9:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alexandre Belloni, Shawn Guo, Jean Delvare, jimwall,
brian-ZKiFAVwZFM2FeswfMrDH8w, Grant Likely, Rob Herring,
Rob Landley, Russell King,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > The low resolution ADC of the mxs is able to read an internal temperature
> > sensor, expose that using hwmon.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
>
> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
Actually, I wonder if we should not just put the hwmon driver
capabilities directly into the mxs-lradc driver, just like it's already
been done in this driver for the touchscreen support.
The probing of this hwmon driver doesn't really belong to the DT, it's
not really realistic to probe it from the machine definition, and it
really is the IP that is wired that way.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 9:17 ` Maxime Ripard
0 siblings, 0 replies; 42+ messages in thread
From: Maxime Ripard @ 2013-06-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > The low resolution ADC of the mxs is able to read an internal temperature
> > sensor, expose that using hwmon.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
>
> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
Actually, I wonder if we should not just put the hwmon driver
capabilities directly into the mxs-lradc driver, just like it's already
been done in this driver for the touchscreen support.
The probing of this hwmon driver doesn't really belong to the DT, it's
not really realistic to probe it from the machine definition, and it
really is the IP that is wired that way.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130627/c335f37b/attachment.sig>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 9:17 ` Maxime Ripard
0 siblings, 0 replies; 42+ messages in thread
From: Maxime Ripard @ 2013-06-27 9:17 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alexandre Belloni, Shawn Guo, Jean Delvare, jimwall, brian,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
[-- Attachment #1.1: Type: text/plain, Size: 927 bytes --]
On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > The low resolution ADC of the mxs is able to read an internal temperature
> > sensor, expose that using hwmon.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
>
> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
Actually, I wonder if we should not just put the hwmon driver
capabilities directly into the mxs-lradc driver, just like it's already
been done in this driver for the touchscreen support.
The probing of this hwmon driver doesn't really belong to the DT, it's
not really realistic to probe it from the machine definition, and it
really is the IP that is wired that way.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-27 9:17 ` [lm-sensors] " Maxime Ripard
(?)
@ 2013-06-27 14:27 ` Guenter Roeck
-1 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-27 14:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Alexandre Belloni, Shawn Guo, Jean Delvare, jimwall, brian,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> > On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > > The low resolution ADC of the mxs is able to read an internal temperature
> > > sensor, expose that using hwmon.
> > >
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > > ---
> >
> > Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>
> Actually, I wonder if we should not just put the hwmon driver
> capabilities directly into the mxs-lradc driver, just like it's already
> been done in this driver for the touchscreen support.
>
> The probing of this hwmon driver doesn't really belong to the DT, it's
> not really realistic to probe it from the machine definition, and it
> really is the IP that is wired that way.
>
Merging iio-hwmon functionality into an adc driver seems just as bad
(or even worse) as copying it into a new driver.
If the lradc driver knows that the ADC channels are temperature sensors, it
should register them with the iio subsystem as IIO_TEMP type. Then you should
be able to use iio_hwmon as is.
Guenter
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 14:27 ` Guenter Roeck
0 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-27 14:27 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> > On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > > The low resolution ADC of the mxs is able to read an internal temperature
> > > sensor, expose that using hwmon.
> > >
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > > ---
> >
> > Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>
> Actually, I wonder if we should not just put the hwmon driver
> capabilities directly into the mxs-lradc driver, just like it's already
> been done in this driver for the touchscreen support.
>
> The probing of this hwmon driver doesn't really belong to the DT, it's
> not really realistic to probe it from the machine definition, and it
> really is the IP that is wired that way.
>
Merging iio-hwmon functionality into an adc driver seems just as bad
(or even worse) as copying it into a new driver.
If the lradc driver knows that the ADC channels are temperature sensors, it
should register them with the iio subsystem as IIO_TEMP type. Then you should
be able to use iio_hwmon as is.
Guenter
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 14:27 ` Guenter Roeck
0 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-27 14:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Alexandre Belloni, Shawn Guo, Jean Delvare, jimwall, brian,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
> > On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
> > > The low resolution ADC of the mxs is able to read an internal temperature
> > > sensor, expose that using hwmon.
> > >
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > > ---
> >
> > Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>
> Actually, I wonder if we should not just put the hwmon driver
> capabilities directly into the mxs-lradc driver, just like it's already
> been done in this driver for the touchscreen support.
>
> The probing of this hwmon driver doesn't really belong to the DT, it's
> not really realistic to probe it from the machine definition, and it
> really is the IP that is wired that way.
>
Merging iio-hwmon functionality into an adc driver seems just as bad
(or even worse) as copying it into a new driver.
If the lradc driver knows that the ADC channels are temperature sensors, it
should register them with the iio subsystem as IIO_TEMP type. Then you should
be able to use iio_hwmon as is.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-27 14:27 ` [lm-sensors] " Guenter Roeck
(?)
(?)
@ 2013-06-27 19:26 ` Alexandre Belloni
-1 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-27 19:26 UTC (permalink / raw)
To: Guenter Roeck
Cc: Maxime Ripard, Shawn Guo, Jean Delvare, jimwall, brian,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
Hi,
On 27/06/2013 16:27, Guenter Roeck wrote:
> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>> sensor, expose that using hwmon.
>>>>
>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>> ---
>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>> Actually, I wonder if we should not just put the hwmon driver
>> capabilities directly into the mxs-lradc driver, just like it's already
>> been done in this driver for the touchscreen support.
>>
>> The probing of this hwmon driver doesn't really belong to the DT, it's
>> not really realistic to probe it from the machine definition, and it
>> really is the IP that is wired that way.
>>
> Merging iio-hwmon functionality into an adc driver seems just as bad
> (or even worse) as copying it into a new driver.
>
> If the lradc driver knows that the ADC channels are temperature sensors, it
> should register them with the iio subsystem as IIO_TEMP type. Then you should
> be able to use iio_hwmon as is.
They are already registered as IIO_TEMP but only implement read_raw. Also,
iio_hwmon_read_val() is using iio_read_channel_processed() and that will
basically only read one of the 2 channels. As I documented, you actually
need to read both channel 8 and channel 9 and then compute the value in
Kelvins. I'm not sure how you want me to do that in the current framework.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 19:26 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-27 19:26 UTC (permalink / raw)
To: Guenter Roeck
Cc: Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian-ZKiFAVwZFM2FeswfMrDH8w, Grant Likely, Rob Herring,
Rob Landley, Russell King,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Hi,
On 27/06/2013 16:27, Guenter Roeck wrote:
> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>> sensor, expose that using hwmon.
>>>>
>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>>> ---
>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>> Actually, I wonder if we should not just put the hwmon driver
>> capabilities directly into the mxs-lradc driver, just like it's already
>> been done in this driver for the touchscreen support.
>>
>> The probing of this hwmon driver doesn't really belong to the DT, it's
>> not really realistic to probe it from the machine definition, and it
>> really is the IP that is wired that way.
>>
> Merging iio-hwmon functionality into an adc driver seems just as bad
> (or even worse) as copying it into a new driver.
>
> If the lradc driver knows that the ADC channels are temperature sensors, it
> should register them with the iio subsystem as IIO_TEMP type. Then you should
> be able to use iio_hwmon as is.
They are already registered as IIO_TEMP but only implement read_raw. Also,
iio_hwmon_read_val() is using iio_read_channel_processed() and that will
basically only read one of the 2 channels. As I documented, you actually
need to read both channel 8 and channel 9 and then compute the value in
Kelvins. I'm not sure how you want me to do that in the current framework.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 19:26 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-27 19:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 27/06/2013 16:27, Guenter Roeck wrote:
> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>> sensor, expose that using hwmon.
>>>>
>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>> ---
>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>> Actually, I wonder if we should not just put the hwmon driver
>> capabilities directly into the mxs-lradc driver, just like it's already
>> been done in this driver for the touchscreen support.
>>
>> The probing of this hwmon driver doesn't really belong to the DT, it's
>> not really realistic to probe it from the machine definition, and it
>> really is the IP that is wired that way.
>>
> Merging iio-hwmon functionality into an adc driver seems just as bad
> (or even worse) as copying it into a new driver.
>
> If the lradc driver knows that the ADC channels are temperature sensors, it
> should register them with the iio subsystem as IIO_TEMP type. Then you should
> be able to use iio_hwmon as is.
They are already registered as IIO_TEMP but only implement read_raw. Also,
iio_hwmon_read_val() is using iio_read_channel_processed() and that will
basically only read one of the 2 channels. As I documented, you actually
need to read both channel 8 and channel 9 and then compute the value in
Kelvins. I'm not sure how you want me to do that in the current framework.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-27 19:26 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-27 19:26 UTC (permalink / raw)
To: Guenter Roeck
Cc: Maxime Ripard, Shawn Guo, Jean Delvare, jimwall, brian,
Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
Hi,
On 27/06/2013 16:27, Guenter Roeck wrote:
> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>> sensor, expose that using hwmon.
>>>>
>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>> ---
>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>> Actually, I wonder if we should not just put the hwmon driver
>> capabilities directly into the mxs-lradc driver, just like it's already
>> been done in this driver for the touchscreen support.
>>
>> The probing of this hwmon driver doesn't really belong to the DT, it's
>> not really realistic to probe it from the machine definition, and it
>> really is the IP that is wired that way.
>>
> Merging iio-hwmon functionality into an adc driver seems just as bad
> (or even worse) as copying it into a new driver.
>
> If the lradc driver knows that the ADC channels are temperature sensors, it
> should register them with the iio subsystem as IIO_TEMP type. Then you should
> be able to use iio_hwmon as is.
They are already registered as IIO_TEMP but only implement read_raw. Also,
iio_hwmon_read_val() is using iio_read_channel_processed() and that will
basically only read one of the 2 channels. As I documented, you actually
need to read both channel 8 and channel 9 and then compute the value in
Kelvins. I'm not sure how you want me to do that in the current framework.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-27 19:26 ` [lm-sensors] " Alexandre Belloni
(?)
@ 2013-06-28 14:18 ` Lars-Peter Clausen
-1 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 14:18 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian, Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
> Hi,
>
> On 27/06/2013 16:27, Guenter Roeck wrote:
>> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>>> sensor, expose that using hwmon.
>>>>>
>>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>>> ---
>>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>>> Actually, I wonder if we should not just put the hwmon driver
>>> capabilities directly into the mxs-lradc driver, just like it's already
>>> been done in this driver for the touchscreen support.
>>>
>>> The probing of this hwmon driver doesn't really belong to the DT, it's
>>> not really realistic to probe it from the machine definition, and it
>>> really is the IP that is wired that way.
>>>
>> Merging iio-hwmon functionality into an adc driver seems just as bad
>> (or even worse) as copying it into a new driver.
>>
>> If the lradc driver knows that the ADC channels are temperature sensors, it
>> should register them with the iio subsystem as IIO_TEMP type. Then you should
>> be able to use iio_hwmon as is.
>
> They are already registered as IIO_TEMP but only implement read_raw. Also,
>
> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
> basically only read one of the 2 channels. As I documented, you actually
> need to read both channel 8 and channel 9 and then compute the value in
> Kelvins. I'm not sure how you want me to do that in the current framework.
What are these two channels actually measuring? Is the value of a single
channel meaningful on it's own? If not it might make sense to update the IIO
driver to just have one temperature channel.
- Lars
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 14:18 ` Lars-Peter Clausen
0 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 14:18 UTC (permalink / raw)
To: linux-arm-kernel
On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
> Hi,
>
> On 27/06/2013 16:27, Guenter Roeck wrote:
>> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>>> sensor, expose that using hwmon.
>>>>>
>>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>>> ---
>>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>>> Actually, I wonder if we should not just put the hwmon driver
>>> capabilities directly into the mxs-lradc driver, just like it's already
>>> been done in this driver for the touchscreen support.
>>>
>>> The probing of this hwmon driver doesn't really belong to the DT, it's
>>> not really realistic to probe it from the machine definition, and it
>>> really is the IP that is wired that way.
>>>
>> Merging iio-hwmon functionality into an adc driver seems just as bad
>> (or even worse) as copying it into a new driver.
>>
>> If the lradc driver knows that the ADC channels are temperature sensors, it
>> should register them with the iio subsystem as IIO_TEMP type. Then you should
>> be able to use iio_hwmon as is.
>
> They are already registered as IIO_TEMP but only implement read_raw. Also,
>
> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
> basically only read one of the 2 channels. As I documented, you actually
> need to read both channel 8 and channel 9 and then compute the value in
> Kelvins. I'm not sure how you want me to do that in the current framework.
What are these two channels actually measuring? Is the value of a single
channel meaningful on it's own? If not it might make sense to update the IIO
driver to just have one temperature channel.
- Lars
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 14:18 ` Lars-Peter Clausen
0 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 14:18 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian, Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
> Hi,
>
> On 27/06/2013 16:27, Guenter Roeck wrote:
>> On Thu, Jun 27, 2013 at 11:17:32AM +0200, Maxime Ripard wrote:
>>> On Wed, Jun 26, 2013 at 07:39:27AM -0700, Guenter Roeck wrote:
>>>> On Wed, Jun 26, 2013 at 10:51:12AM +0200, Alexandre Belloni wrote:
>>>>> The low resolution ADC of the mxs is able to read an internal temperature
>>>>> sensor, expose that using hwmon.
>>>>>
>>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>>> ---
>>>> Wouldn't it make more sense to use iio-hwmon and improve it if necessary ?
>>> Actually, I wonder if we should not just put the hwmon driver
>>> capabilities directly into the mxs-lradc driver, just like it's already
>>> been done in this driver for the touchscreen support.
>>>
>>> The probing of this hwmon driver doesn't really belong to the DT, it's
>>> not really realistic to probe it from the machine definition, and it
>>> really is the IP that is wired that way.
>>>
>> Merging iio-hwmon functionality into an adc driver seems just as bad
>> (or even worse) as copying it into a new driver.
>>
>> If the lradc driver knows that the ADC channels are temperature sensors, it
>> should register them with the iio subsystem as IIO_TEMP type. Then you should
>> be able to use iio_hwmon as is.
>
> They are already registered as IIO_TEMP but only implement read_raw. Also,
>
> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
> basically only read one of the 2 channels. As I documented, you actually
> need to read both channel 8 and channel 9 and then compute the value in
> Kelvins. I'm not sure how you want me to do that in the current framework.
What are these two channels actually measuring? Is the value of a single
channel meaningful on it's own? If not it might make sense to update the IIO
driver to just have one temperature channel.
- Lars
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-28 14:18 ` [lm-sensors] " Lars-Peter Clausen
(?)
@ 2013-06-28 14:50 ` Alexandre Belloni
-1 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-28 14:50 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian, Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On 28/06/2013 16:18, Lars-Peter Clausen wrote:
> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>
>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>
>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>> basically only read one of the 2 channels. As I documented, you actually
>> need to read both channel 8 and channel 9 and then compute the value in
>> Kelvins. I'm not sure how you want me to do that in the current framework.
> What are these two channels actually measuring? Is the value of a single
> channel meaningful on it's own? If not it might make sense to update the IIO
> driver to just have one temperature channel.
It's not actually meaningful on its own. So, what you would do is expose
one iio channel for two ADC channels and do the computation in read_raw
? or read_processed ? Then using iio-hwon to export it. ?
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 14:50 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-28 14:50 UTC (permalink / raw)
To: linux-arm-kernel
On 28/06/2013 16:18, Lars-Peter Clausen wrote:
> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>
>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>
>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>> basically only read one of the 2 channels. As I documented, you actually
>> need to read both channel 8 and channel 9 and then compute the value in
>> Kelvins. I'm not sure how you want me to do that in the current framework.
> What are these two channels actually measuring? Is the value of a single
> channel meaningful on it's own? If not it might make sense to update the IIO
> driver to just have one temperature channel.
It's not actually meaningful on its own. So, what you would do is expose
one iio channel for two ADC channels and do the computation in read_raw
? or read_processed ? Then using iio-hwon to export it. ?
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 14:50 ` Alexandre Belloni
0 siblings, 0 replies; 42+ messages in thread
From: Alexandre Belloni @ 2013-06-28 14:50 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian, Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On 28/06/2013 16:18, Lars-Peter Clausen wrote:
> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>
>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>
>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>> basically only read one of the 2 channels. As I documented, you actually
>> need to read both channel 8 and channel 9 and then compute the value in
>> Kelvins. I'm not sure how you want me to do that in the current framework.
> What are these two channels actually measuring? Is the value of a single
> channel meaningful on it's own? If not it might make sense to update the IIO
> driver to just have one temperature channel.
It's not actually meaningful on its own. So, what you would do is expose
one iio channel for two ADC channels and do the computation in read_raw
? or read_processed ? Then using iio-hwon to export it. ?
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-28 14:50 ` [lm-sensors] " Alexandre Belloni
(?)
(?)
@ 2013-06-28 15:24 ` Lars-Peter Clausen
-1 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 15:24 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian, Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> On 28/06/2013 16:18, Lars-Peter Clausen wrote:
>> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>>
>>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>>
>>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>>> basically only read one of the 2 channels. As I documented, you actually
>>> need to read both channel 8 and channel 9 and then compute the value in
>>> Kelvins. I'm not sure how you want me to do that in the current framework.
>> What are these two channels actually measuring? Is the value of a single
>> channel meaningful on it's own? If not it might make sense to update the IIO
>> driver to just have one temperature channel.
>
> It's not actually meaningful on its own. So, what you would do is expose
> one iio channel for two ADC channels and do the computation in read_raw
> ? or read_processed ? Then using iio-hwon to export it. ?
>
> Regards,
>
Yes, return channel9 - channel8 as the raw value for the temperature channel
and provide proper scale and offset values, so that
iio_read_channel_processed() will return the correct value.
- Lars
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 15:24 ` Lars-Peter Clausen
0 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 15:24 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian-ZKiFAVwZFM2FeswfMrDH8w, Grant Likely, Rob Herring,
Rob Landley, Russell King,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
lm-sensors-GZX6beZjE8VD60Wz+7aTrA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA
On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> On 28/06/2013 16:18, Lars-Peter Clausen wrote:
>> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>>
>>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>>
>>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>>> basically only read one of the 2 channels. As I documented, you actually
>>> need to read both channel 8 and channel 9 and then compute the value in
>>> Kelvins. I'm not sure how you want me to do that in the current framework.
>> What are these two channels actually measuring? Is the value of a single
>> channel meaningful on it's own? If not it might make sense to update the IIO
>> driver to just have one temperature channel.
>
> It's not actually meaningful on its own. So, what you would do is expose
> one iio channel for two ADC channels and do the computation in read_raw
> ? or read_processed ? Then using iio-hwon to export it. ?
>
> Regards,
>
Yes, return channel9 - channel8 as the raw value for the temperature channel
and provide proper scale and offset values, so that
iio_read_channel_processed() will return the correct value.
- Lars
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 15:24 ` Lars-Peter Clausen
0 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 15:24 UTC (permalink / raw)
To: linux-arm-kernel
On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> On 28/06/2013 16:18, Lars-Peter Clausen wrote:
>> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>>
>>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>>
>>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>>> basically only read one of the 2 channels. As I documented, you actually
>>> need to read both channel 8 and channel 9 and then compute the value in
>>> Kelvins. I'm not sure how you want me to do that in the current framework.
>> What are these two channels actually measuring? Is the value of a single
>> channel meaningful on it's own? If not it might make sense to update the IIO
>> driver to just have one temperature channel.
>
> It's not actually meaningful on its own. So, what you would do is expose
> one iio channel for two ADC channels and do the computation in read_raw
> ? or read_processed ? Then using iio-hwon to export it. ?
>
> Regards,
>
Yes, return channel9 - channel8 as the raw value for the temperature channel
and provide proper scale and offset values, so that
iio_read_channel_processed() will return the correct value.
- Lars
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 15:24 ` Lars-Peter Clausen
0 siblings, 0 replies; 42+ messages in thread
From: Lars-Peter Clausen @ 2013-06-28 15:24 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Guenter Roeck, Maxime Ripard, Shawn Guo, Jean Delvare, jimwall,
brian, Grant Likely, Rob Herring, Rob Landley, Russell King,
devicetree-discuss, linux-doc, linux-kernel, lm-sensors,
linux-arm-kernel, linux-iio
On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> On 28/06/2013 16:18, Lars-Peter Clausen wrote:
>> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
>>>
>>> They are already registered as IIO_TEMP but only implement read_raw. Also,
>>>
>>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
>>> basically only read one of the 2 channels. As I documented, you actually
>>> need to read both channel 8 and channel 9 and then compute the value in
>>> Kelvins. I'm not sure how you want me to do that in the current framework.
>> What are these two channels actually measuring? Is the value of a single
>> channel meaningful on it's own? If not it might make sense to update the IIO
>> driver to just have one temperature channel.
>
> It's not actually meaningful on its own. So, what you would do is expose
> one iio channel for two ADC channels and do the computation in read_raw
> ? or read_processed ? Then using iio-hwon to export it. ?
>
> Regards,
>
Yes, return channel9 - channel8 as the raw value for the temperature channel
and provide proper scale and offset values, so that
iio_read_channel_processed() will return the correct value.
- Lars
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
2013-06-28 15:24 ` [lm-sensors] " Lars-Peter Clausen
(?)
@ 2013-06-28 16:35 ` Guenter Roeck
-1 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-28 16:35 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Alexandre Belloni, Maxime Ripard, Shawn Guo, Jean Delvare,
jimwall, brian, Grant Likely, Rob Herring, Rob Landley,
Russell King, devicetree-discuss, linux-doc, linux-kernel,
lm-sensors, linux-arm-kernel, linux-iio
On Fri, Jun 28, 2013 at 05:24:43PM +0200, Lars-Peter Clausen wrote:
> On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> > On 28/06/2013 16:18, Lars-Peter Clausen wrote:
> >> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
> >>>
> >>> They are already registered as IIO_TEMP but only implement read_raw. Also,
> >>>
> >>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
> >>> basically only read one of the 2 channels. As I documented, you actually
> >>> need to read both channel 8 and channel 9 and then compute the value in
> >>> Kelvins. I'm not sure how you want me to do that in the current framework.
> >> What are these two channels actually measuring? Is the value of a single
> >> channel meaningful on it's own? If not it might make sense to update the IIO
> >> driver to just have one temperature channel.
> >
> > It's not actually meaningful on its own. So, what you would do is expose
> > one iio channel for two ADC channels and do the computation in read_raw
> > ? or read_processed ? Then using iio-hwon to export it. ?
> >
> > Regards,
> >
>
> Yes, return channel9 - channel8 as the raw value for the temperature channel
> and provide proper scale and offset values, so that
> iio_read_channel_processed() will return the correct value.
>
Agreed.
Guenter
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 16:35 ` Guenter Roeck
0 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-28 16:35 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 28, 2013 at 05:24:43PM +0200, Lars-Peter Clausen wrote:
> On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> > On 28/06/2013 16:18, Lars-Peter Clausen wrote:
> >> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
> >>>
> >>> They are already registered as IIO_TEMP but only implement read_raw. Also,
> >>>
> >>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
> >>> basically only read one of the 2 channels. As I documented, you actually
> >>> need to read both channel 8 and channel 9 and then compute the value in
> >>> Kelvins. I'm not sure how you want me to do that in the current framework.
> >> What are these two channels actually measuring? Is the value of a single
> >> channel meaningful on it's own? If not it might make sense to update the IIO
> >> driver to just have one temperature channel.
> >
> > It's not actually meaningful on its own. So, what you would do is expose
> > one iio channel for two ADC channels and do the computation in read_raw
> > ? or read_processed ? Then using iio-hwon to export it. ?
> >
> > Regards,
> >
>
> Yes, return channel9 - channel8 as the raw value for the temperature channel
> and provide proper scale and offset values, so that
> iio_read_channel_processed() will return the correct value.
>
Agreed.
Guenter
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [lm-sensors] [PATCH 3/4] hwmon: Add a simple driver to read the MXS SoC temperature
@ 2013-06-28 16:35 ` Guenter Roeck
0 siblings, 0 replies; 42+ messages in thread
From: Guenter Roeck @ 2013-06-28 16:35 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Alexandre Belloni, Maxime Ripard, Shawn Guo, Jean Delvare,
jimwall, brian, Grant Likely, Rob Herring, Rob Landley,
Russell King, devicetree-discuss, linux-doc, linux-kernel,
lm-sensors, linux-arm-kernel, linux-iio
On Fri, Jun 28, 2013 at 05:24:43PM +0200, Lars-Peter Clausen wrote:
> On 06/28/2013 04:50 PM, Alexandre Belloni wrote:
> > On 28/06/2013 16:18, Lars-Peter Clausen wrote:
> >> On 06/27/2013 09:26 PM, Alexandre Belloni wrote:
> >>>
> >>> They are already registered as IIO_TEMP but only implement read_raw. Also,
> >>>
> >>> iio_hwmon_read_val() is using iio_read_channel_processed() and that will
> >>> basically only read one of the 2 channels. As I documented, you actually
> >>> need to read both channel 8 and channel 9 and then compute the value in
> >>> Kelvins. I'm not sure how you want me to do that in the current framework.
> >> What are these two channels actually measuring? Is the value of a single
> >> channel meaningful on it's own? If not it might make sense to update the IIO
> >> driver to just have one temperature channel.
> >
> > It's not actually meaningful on its own. So, what you would do is expose
> > one iio channel for two ADC channels and do the computation in read_raw
> > ? or read_processed ? Then using iio-hwon to export it. ?
> >
> > Regards,
> >
>
> Yes, return channel9 - channel8 as the raw value for the temperature channel
> and provide proper scale and offset values, so that
> iio_read_channel_processed() will return the correct value.
>
Agreed.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 42+ messages in thread