Add the lantiq cpu temperature sensor support for xrx200.
Signed-off-by: Florian Eckert <[email protected]>
---
v2:
- remove default in Makefile
- fix spelling
- removing first read delay, because temperature value is not read during boot
anymore
- change calculation, compiler should to the optimization
- remove unnecessary initialization
- use new devm_hwmon_device_register_with_info API
- use module_platform_driver function
v3:
- sort includes in alphabetic order
- add missing linux/bitops.h include
- fix alignment
- fix switch case indentation
- use octal file permission instead of S_IRUGO
- set hwmon device name to "ltq_cputemp"
- enable temperature chip before hwmon registration
- remove release function registrate ltq_cputemp_disable()
with devm_add_action
- remove init_ltq_cputemp and clean_ltq_cputemp not used
overlooked it on v2
drivers/hwmon/Kconfig | 7 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/ltq-cputemp.c | 163 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 171 insertions(+)
create mode 100644 drivers/hwmon/ltq-cputemp.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5ef2814345ef..218332f0e913 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -790,6 +790,13 @@ config SENSORS_LTC4261
This driver can also be built as a module. If so, the module will
be called ltc4261.
+config SENSORS_LTQ_CPUTEMP
+ bool "Lantiq cpu temperature sensor driver"
+ depends on LANTIQ
+ help
+ If you say yes here you get support for the temperature
+ sensor inside your CPU.
+
config SENSORS_MAX1111
tristate "Maxim MAX1111 Serial 8-bit ADC chip and compatibles"
depends on SPI_MASTER
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d4641a9f16c1..c84d9784be98 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_SENSORS_LTC4222) += ltc4222.o
obj-$(CONFIG_SENSORS_LTC4245) += ltc4245.o
obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
obj-$(CONFIG_SENSORS_LTC4261) += ltc4261.o
+obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
obj-$(CONFIG_SENSORS_MAX1111) += max1111.o
obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
diff --git a/drivers/hwmon/ltq-cputemp.c b/drivers/hwmon/ltq-cputemp.c
new file mode 100644
index 000000000000..1d33f94594c1
--- /dev/null
+++ b/drivers/hwmon/ltq-cputemp.c
@@ -0,0 +1,163 @@
+/* Lantiq cpu temperature sensor driver
+ *
+ * Copyright (C) 2017 Florian Eckert <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version
+ *
+ * This program is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>
+ */
+
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+
+#include <lantiq_soc.h>
+
+/* gphy1 configuration register contains cpu temperature */
+#define CGU_GPHY1_CR 0x0040
+#define CGU_TEMP_PD BIT(19)
+
+static void ltq_cputemp_enable(void)
+{
+ ltq_cgu_w32(ltq_cgu_r32(CGU_GPHY1_CR) | CGU_TEMP_PD, CGU_GPHY1_CR);
+}
+
+static void ltq_cputemp_disable(void *data)
+{
+ ltq_cgu_w32(ltq_cgu_r32(CGU_GPHY1_CR) & ~CGU_TEMP_PD, CGU_GPHY1_CR);
+}
+
+static int ltq_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *temp)
+{
+ int value;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ /* get the temperature including one decimal place */
+ value = (ltq_cgu_r32(CGU_GPHY1_CR) >> 9) & 0x01FF;
+ value = value * 5;
+ /* range -38 to +154 °C, register value zero is -38.0 °C */
+ value -= 380;
+ /* scale temp to millidegree */
+ value = value * 100;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ *temp = value;
+ return 0;
+}
+
+static umode_t ltq_is_visible(const void *_data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type != hwmon_temp)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static const u32 ltq_chip_config[] = {
+ HWMON_C_REGISTER_TZ,
+ 0
+};
+
+static const struct hwmon_channel_info ltq_chip = {
+ .type = hwmon_chip,
+ .config = ltq_chip_config,
+};
+
+static const u32 ltq_temp_config[] = {
+ HWMON_T_INPUT,
+ 0
+};
+
+static const struct hwmon_channel_info ltq_temp = {
+ .type = hwmon_temp,
+ .config = ltq_temp_config,
+};
+
+static const struct hwmon_channel_info *ltq_info[] = {
+ <q_chip,
+ <q_temp,
+ NULL
+};
+
+static const struct hwmon_ops ltq_hwmon_ops = {
+ .is_visible = ltq_is_visible,
+ .read = ltq_read,
+};
+
+static const struct hwmon_chip_info ltq_chip_info = {
+ .ops = <q_hwmon_ops,
+ .info = ltq_info,
+};
+
+static int ltq_cputemp_probe(struct platform_device *pdev)
+{
+ struct device *hwmon_dev;
+ int err = 0;
+
+ /* available on vr9 v1.2 SoCs only */
+ if (ltq_soc_type() != SOC_TYPE_VR9_2)
+ return -ENODEV;
+
+ err = devm_add_action(&pdev->dev, ltq_cputemp_disable, NULL);
+ if (err)
+ return err;
+
+ ltq_cputemp_enable();
+
+ hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
+ "ltq_cputemp",
+ NULL,
+ <q_chip_info,
+ NULL);
+
+ if (IS_ERR(hwmon_dev)) {
+ dev_err(&pdev->dev, "Failed to register as hwmon device");
+ return PTR_ERR(hwmon_dev);
+ }
+
+ return 0;
+}
+
+const struct of_device_id ltq_cputemp_match[] = {
+ { .compatible = "lantiq,cputemp" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ltq_cputemp_match);
+
+static struct platform_driver ltq_cputemp_driver = {
+ .probe = ltq_cputemp_probe,
+ .driver = {
+ .name = "ltq-cputemp",
+ .of_match_table = ltq_cputemp_match,
+ },
+};
+
+module_platform_driver(ltq_cputemp_driver);
+
+MODULE_AUTHOR("Florian Eckert <[email protected]>");
+MODULE_DESCRIPTION("Lantiq cpu temperature sensor driver");
+MODULE_LICENSE("GPL");
--
2.11.0
Document the devicetree bindings for the ltq-cputemp
Signed-off-by: Florian Eckert <[email protected]>
---
Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
new file mode 100644
index 000000000000..33fd00a987c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
@@ -0,0 +1,10 @@
+Lantiq cpu temperatur sensor
+
+Requires node properties:
+- compatible value :
+ "lantiq,cputemp"
+
+Example:
+ cputemp@0 {
+ compatible = "lantiq,cputemp";
+ };
--
2.11.0
On Fri, Sep 01, 2017 at 08:58:17AM +0200, Florian Eckert wrote:
> Add the lantiq cpu temperature sensor support for xrx200.
>
> Signed-off-by: Florian Eckert <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter
> ---
> v2:
> - remove default in Makefile
> - fix spelling
> - removing first read delay, because temperature value is not read during boot
> anymore
> - change calculation, compiler should to the optimization
> - remove unnecessary initialization
> - use new devm_hwmon_device_register_with_info API
> - use module_platform_driver function
>
> v3:
> - sort includes in alphabetic order
> - add missing linux/bitops.h include
> - fix alignment
> - fix switch case indentation
> - use octal file permission instead of S_IRUGO
> - set hwmon device name to "ltq_cputemp"
> - enable temperature chip before hwmon registration
> - remove release function registrate ltq_cputemp_disable()
> with devm_add_action
> - remove init_ltq_cputemp and clean_ltq_cputemp not used
> overlooked it on v2
>
> drivers/hwmon/Kconfig | 7 ++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/ltq-cputemp.c | 163 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 171 insertions(+)
> create mode 100644 drivers/hwmon/ltq-cputemp.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 5ef2814345ef..218332f0e913 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -790,6 +790,13 @@ config SENSORS_LTC4261
> This driver can also be built as a module. If so, the module will
> be called ltc4261.
>
> +config SENSORS_LTQ_CPUTEMP
> + bool "Lantiq cpu temperature sensor driver"
> + depends on LANTIQ
> + help
> + If you say yes here you get support for the temperature
> + sensor inside your CPU.
> +
> config SENSORS_MAX1111
> tristate "Maxim MAX1111 Serial 8-bit ADC chip and compatibles"
> depends on SPI_MASTER
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index d4641a9f16c1..c84d9784be98 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -110,6 +110,7 @@ obj-$(CONFIG_SENSORS_LTC4222) += ltc4222.o
> obj-$(CONFIG_SENSORS_LTC4245) += ltc4245.o
> obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
> obj-$(CONFIG_SENSORS_LTC4261) += ltc4261.o
> +obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
> obj-$(CONFIG_SENSORS_MAX1111) += max1111.o
> obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
> obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
> diff --git a/drivers/hwmon/ltq-cputemp.c b/drivers/hwmon/ltq-cputemp.c
> new file mode 100644
> index 000000000000..1d33f94594c1
> --- /dev/null
> +++ b/drivers/hwmon/ltq-cputemp.c
> @@ -0,0 +1,163 @@
> +/* Lantiq cpu temperature sensor driver
> + *
> + * Copyright (C) 2017 Florian Eckert <[email protected]>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version
> + *
> + * This program is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +#include <lantiq_soc.h>
> +
> +/* gphy1 configuration register contains cpu temperature */
> +#define CGU_GPHY1_CR 0x0040
> +#define CGU_TEMP_PD BIT(19)
> +
> +static void ltq_cputemp_enable(void)
> +{
> + ltq_cgu_w32(ltq_cgu_r32(CGU_GPHY1_CR) | CGU_TEMP_PD, CGU_GPHY1_CR);
> +}
> +
> +static void ltq_cputemp_disable(void *data)
> +{
> + ltq_cgu_w32(ltq_cgu_r32(CGU_GPHY1_CR) & ~CGU_TEMP_PD, CGU_GPHY1_CR);
> +}
> +
> +static int ltq_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *temp)
> +{
> + int value;
> +
> + switch (attr) {
> + case hwmon_temp_input:
> + /* get the temperature including one decimal place */
> + value = (ltq_cgu_r32(CGU_GPHY1_CR) >> 9) & 0x01FF;
> + value = value * 5;
> + /* range -38 to +154 ?C, register value zero is -38.0 ?C */
> + value -= 380;
> + /* scale temp to millidegree */
> + value = value * 100;
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + *temp = value;
> + return 0;
> +}
> +
> +static umode_t ltq_is_visible(const void *_data, enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + if (type != hwmon_temp)
> + return 0;
> +
> + switch (attr) {
> + case hwmon_temp_input:
> + return 0444;
> + default:
> + return 0;
> + }
> +}
> +
> +static const u32 ltq_chip_config[] = {
> + HWMON_C_REGISTER_TZ,
> + 0
> +};
> +
> +static const struct hwmon_channel_info ltq_chip = {
> + .type = hwmon_chip,
> + .config = ltq_chip_config,
> +};
> +
> +static const u32 ltq_temp_config[] = {
> + HWMON_T_INPUT,
> + 0
> +};
> +
> +static const struct hwmon_channel_info ltq_temp = {
> + .type = hwmon_temp,
> + .config = ltq_temp_config,
> +};
> +
> +static const struct hwmon_channel_info *ltq_info[] = {
> + <q_chip,
> + <q_temp,
> + NULL
> +};
> +
> +static const struct hwmon_ops ltq_hwmon_ops = {
> + .is_visible = ltq_is_visible,
> + .read = ltq_read,
> +};
> +
> +static const struct hwmon_chip_info ltq_chip_info = {
> + .ops = <q_hwmon_ops,
> + .info = ltq_info,
> +};
> +
> +static int ltq_cputemp_probe(struct platform_device *pdev)
> +{
> + struct device *hwmon_dev;
> + int err = 0;
> +
> + /* available on vr9 v1.2 SoCs only */
> + if (ltq_soc_type() != SOC_TYPE_VR9_2)
> + return -ENODEV;
> +
> + err = devm_add_action(&pdev->dev, ltq_cputemp_disable, NULL);
> + if (err)
> + return err;
> +
> + ltq_cputemp_enable();
> +
> + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
> + "ltq_cputemp",
> + NULL,
> + <q_chip_info,
> + NULL);
> +
> + if (IS_ERR(hwmon_dev)) {
> + dev_err(&pdev->dev, "Failed to register as hwmon device");
> + return PTR_ERR(hwmon_dev);
> + }
> +
> + return 0;
> +}
> +
> +const struct of_device_id ltq_cputemp_match[] = {
> + { .compatible = "lantiq,cputemp" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ltq_cputemp_match);
> +
> +static struct platform_driver ltq_cputemp_driver = {
> + .probe = ltq_cputemp_probe,
> + .driver = {
> + .name = "ltq-cputemp",
> + .of_match_table = ltq_cputemp_match,
> + },
> +};
> +
> +module_platform_driver(ltq_cputemp_driver);
> +
> +MODULE_AUTHOR("Florian Eckert <[email protected]>");
> +MODULE_DESCRIPTION("Lantiq cpu temperature sensor driver");
> +MODULE_LICENSE("GPL");
> --
> 2.11.0
>
On Fri, Sep 01, 2017 at 08:58:18AM +0200, Florian Eckert wrote:
> Document the devicetree bindings for the ltq-cputemp
>
> Signed-off-by: Florian Eckert <[email protected]>
I see nothing special with the bindings, and they are in line with other lantiq
bindings, so I am taking the risk of accepting this patch (and the matching
driver) without waiting for explicit approval from Rob. Rob, scream at me if
that is not ok.
Thanks,
Guenter
> ---
> Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> new file mode 100644
> index 000000000000..33fd00a987c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> @@ -0,0 +1,10 @@
> +Lantiq cpu temperatur sensor
> +
> +Requires node properties:
> +- compatible value :
> + "lantiq,cputemp"
> +
> +Example:
> + cputemp@0 {
> + compatible = "lantiq,cputemp";
> + };
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 01, 2017 at 07:26:22AM -0700, Guenter Roeck wrote:
> On Fri, Sep 01, 2017 at 08:58:18AM +0200, Florian Eckert wrote:
> > Document the devicetree bindings for the ltq-cputemp
> >
> > Signed-off-by: Florian Eckert <[email protected]>
>
> I see nothing special with the bindings, and they are in line with other lantiq
> bindings, so I am taking the risk of accepting this patch (and the matching
> driver) without waiting for explicit approval from Rob. Rob, scream at me if
> that is not ok.
Perhaps the existing one was not well reviewed.
>
> Thanks,
> Guenter
>
> > ---
> > Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> > new file mode 100644
> > index 000000000000..33fd00a987c7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> > @@ -0,0 +1,10 @@
> > +Lantiq cpu temperatur sensor
s/temperatur/temperature/
> > +
> > +Requires node properties:
> > +- compatible value :
> > + "lantiq,cputemp"
Kind of non-specific. How is this device even accessed without any other
property?
> > +
> > +Example:
> > + cputemp@0 {
unit-address without reg property is not valid.
> > + compatible = "lantiq,cputemp";
> > + };
> > --
> > 2.11.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Rob
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
>> > @@ -0,0 +1,10 @@
>> > +Lantiq cpu temperatur sensor
>
> s/temperatur/temperature/
Will update this in a follow up page based on the old one. So no v4?
>
>> > +
>> > +Requires node properties:
>> > +- compatible value :
>> > + "lantiq,cputemp"
>
> Kind of non-specific. How is this device even accessed without any
> other
> property?
It does not need any further properties. If this is set in the device
tree then the driver is loaded.
After loading the temperature could be read from "/sys/class/hwmon".
Let me know what should i do to get this fixed?
Thanks for feedback
Florian
On Tue, Sep 12, 2017 at 11:20:08AM -0500, Rob Herring wrote:
> On Fri, Sep 01, 2017 at 07:26:22AM -0700, Guenter Roeck wrote:
> > On Fri, Sep 01, 2017 at 08:58:18AM +0200, Florian Eckert wrote:
> > > Document the devicetree bindings for the ltq-cputemp
> > >
> > > Signed-off-by: Florian Eckert <[email protected]>
> >
> > I see nothing special with the bindings, and they are in line with other lantiq
> > bindings, so I am taking the risk of accepting this patch (and the matching
> > driver) without waiting for explicit approval from Rob. Rob, scream at me if
> > that is not ok.
>
> Perhaps the existing one was not well reviewed.
>
Bummer. Should teach me to never accept DT patches without your review.
I owe you a beer or two.
Guenter
> >
> > Thanks,
> > Guenter
> >
> > > ---
> > > Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> > > new file mode 100644
> > > index 000000000000..33fd00a987c7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> > > @@ -0,0 +1,10 @@
> > > +Lantiq cpu temperatur sensor
>
> s/temperatur/temperature/
>
> > > +
> > > +Requires node properties:
> > > +- compatible value :
> > > + "lantiq,cputemp"
>
> Kind of non-specific. How is this device even accessed without any other
> property?
>
> > > +
> > > +Example:
> > > + cputemp@0 {
>
> unit-address without reg property is not valid.
>
> > > + compatible = "lantiq,cputemp";
> > > + };
> > > --
> > > 2.11.0
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> > > the body of a message to [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 13, 2017 at 07:36:16AM +0200, Florian Eckert wrote:
> Hello Rob
>
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
> >>> @@ -0,0 +1,10 @@
> >>> +Lantiq cpu temperatur sensor
> >
> >s/temperatur/temperature/
>
> Will update this in a follow up page based on the old one. So no v4?
>
Please send a follow-up patch.
Thanks,
Guenter
> >
> >>> +
> >>> +Requires node properties:
> >>> +- compatible value :
> >>> + "lantiq,cputemp"
> >
> >Kind of non-specific. How is this device even accessed without any other
> >property?
>
> It does not need any further properties. If this is set in the device tree
> then the driver is loaded.
> After loading the temperature could be read from "/sys/class/hwmon".
>
> Let me know what should i do to get this fixed?
>
> Thanks for feedback
>
> Florian
>
>> >
>> >>> +
>> >>> +Requires node properties:
>> >>> +- compatible value :
>> >>> + "lantiq,cputemp"
>> >
>> >Kind of non-specific. How is this device even accessed without any other
>> >property?
>>
>> It does not need any further properties. If this is set in the device
>> tree
>> then the driver is loaded.
>> After loading the temperature could be read from "/sys/class/hwmon".
>> Let me know what should i do to get this fixed?
>>
What about with this is this OK from your side or do I have do to
something?
So I only update "s/temperatur/temperature/" with an follow-up patch
based the current linux-next tree?
Thanks
Florian
On Wed, Sep 13, 2017 at 04:42:33PM +0200, Florian Eckert wrote:
> >>>
> >>>>> +
> >>>>> +Requires node properties:
> >>>>> +- compatible value :
> >>>>> + "lantiq,cputemp"
> >>>
> >>>Kind of non-specific. How is this device even accessed without any other
> >>>property?
> >>
> >>It does not need any further properties. If this is set in the device
> >>tree
> >>then the driver is loaded.
> >>After loading the temperature could be read from "/sys/class/hwmon".
> >>Let me know what should i do to get this fixed?
> >>
>
> What about with this is this OK from your side or do I have do to something?
> So I only update "s/temperatur/temperature/" with an follow-up patch based
> the current linux-next tree?
>
Also s/cputemp@0/cputemp/ if I understand Rob's comment correctly.
Question for Rob: The driver checks the SOC version and bails out
if the version is not vr9 v1.2. Should that be expressed in DT ?
Guenter
> Thanks
>
> Florian
>
>
On Wed, Sep 13, 2017 at 12:36 AM, Florian Eckert <[email protected]> wrote:
> Hello Rob
>
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
>>> > @@ -0,0 +1,10 @@
>>> > +Lantiq cpu temperatur sensor
>>
>>
>> s/temperatur/temperature/
>
>
> Will update this in a follow up page based on the old one. So no v4?
>
>>
>>> > +
>>> > +Requires node properties:
>>> > +- compatible value :
>>> > + "lantiq,cputemp"
>>
>>
>> Kind of non-specific. How is this device even accessed without any other
>> property?
>
>
> It does not need any further properties. If this is set in the device tree
> then the driver is loaded.
DT is not the only way to instantiate drivers.
What I meant is how do you access the hardware? That should be evident
from the binding and it is not.
Looking at the driver, you have some memory mapped system control
registers which get ioremapped in arch/mips/lantiq/xway/sysctrl.c and
accesses thru some platform specific macros. That is not the ideal way
to do things as we use syscon and regmap for such things. But that's
all mostly kernel details not so relevant to the DT binding.
For DT, I'd expect this is a child node of the sysctrl block with a
reg property value of <0x40 4> (along with any other child devices).
You could also not even put this in DT and the system controller can
have it's own driver that instantiates the child device for this
driver.
Rob
Hello Rob
>>>> > +
>>>> > +Requires node properties:
>>>> > +- compatible value :
>>>> > + "lantiq,cputemp"
>>>
>>>
>>> Kind of non-specific. How is this device even accessed without any
>>> other
>>> property?
>>
>>
>> It does not need any further properties. If this is set in the device
>> tree
>> then the driver is loaded.
>
> DT is not the only way to instantiate drivers.
>
> What I meant is how do you access the hardware? That should be evident
> from the binding and it is not.
Agree with our statement.
>
> Looking at the driver, you have some memory mapped system control
> registers which get ioremapped in arch/mips/lantiq/xway/sysctrl.c and
> accesses thru some platform specific macros. That is not the ideal way
> to do things as we use syscon and regmap for such things. But that's
> all mostly kernel details not so relevant to the DT binding.
For lanitq xrx200 this is all i have. So if i have to use syscon and
regmap i am also not sure how to handle this.
> For DT, I'd expect this is a child node of the sysctrl block with a
> reg property value of <0x40 4> (along with any other child devices).
> You could also not even put this in DT and the system controller can
> have it's own driver that instantiates the child device for this
> driver.
Yes this would be the best practice. But the hardware designer for what
ever reason
placed the Register for the temperature sensors into the CGU (Clock
Generation Unit) section!
And the Register is also shared with some other stuff which is not only
assign for temperature
stuff! I am not sure how to handle this in the device tree.
This is a Register description extract from the data sheet
GPHY Configuration Register 01
This register configures the booting options of GPHY1 IP.
Offset 0x0040
Reset Value 0x01FC0000
31: RES
30: 100FX_H
29: 100FX_F
28: 10BT_F
27: 10BT_H
26: 100BT_F
25: 100BT_H
24: 1000BT_F
23: 1000BT_H
22: RES
21: RES
19: TEMP_PD <--- NEEDED Power down the Temperature Sensor
18: TEMP_HL <--- NEEDED Indicate temperature higher than 128 C
17: TEMP <--- NEEDED Value
16: TEMP <--- NEEDED Value
15: TEMP <--- NEEDED Value
14: TEMP <--- NEEDED Value
13: TEMP <--- NEEDED Value
12: TEMP <--- NEEDED Value
11: TEMP <--- NEEDED Value
10: TEMP <--- NEEDED Value
09: TEMP <--- NEEDED Value
08: RES
07: RES
06: SPI_Delay
05: SPI_Delay
04: AHB_EnD
03: DMA_OR
02: RES
01: RES
00: RES
And that is a dts tree from LEDE/Openwrt for lantiq
URL:
https://github.com/lede-project/source/blob/c88770c766fdc5599efc4672bca230017f52e8e4/target/linux/lantiq/dts/vr9.dtsi#L54
Extraction:
sram@1F000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "lantiq,sram", "simple-bus";
reg = <0x1F000000 0x800000>;
ranges = <0x0 0x1F000000 0x7FFFFF>;
eiu0: eiu@101000 {
#interrupt-cells = <1>;
interrupt-controller;
compatible = "lantiq,eiu-xway";
reg = <0x101000 0x1000>;
interrupt-parent = <&icu0>;
lantiq,eiu-irqs = <166 135 66 40 41 42>;
};
pmu0: pmu@102000 {
compatible = "lantiq,pmu-xway";
reg = <0x102000 0x1000>;
};
cgu0: cgu@103000 {
compatible = "lantiq,cgu-xway";
reg = <0x103000 0x1000>;
-> This is the place to add the binding?
};
Sorry for the noise but i am unsure how to do this.
Thanks for help
Florian
On Thu, Sep 14, 2017 at 2:06 AM, Florian Eckert <[email protected]> wrote:
> Hello Rob
>
>>>>> > +
>>>>> > +Requires node properties:
>>>>> > +- compatible value :
>>>>> > + "lantiq,cputemp"
>>>>
>>>>
>>>>
>>>> Kind of non-specific. How is this device even accessed without any other
>>>> property?
>>>
>>>
>>>
>>> It does not need any further properties. If this is set in the device
>>> tree
>>> then the driver is loaded.
>>
>>
>> DT is not the only way to instantiate drivers.
>>
>> What I meant is how do you access the hardware? That should be evident
>> from the binding and it is not.
>
>
> Agree with our statement.
>
>>
>> Looking at the driver, you have some memory mapped system control
>> registers which get ioremapped in arch/mips/lantiq/xway/sysctrl.c and
>> accesses thru some platform specific macros. That is not the ideal way
>> to do things as we use syscon and regmap for such things. But that's
>> all mostly kernel details not so relevant to the DT binding.
>
>
> For lanitq xrx200 this is all i have. So if i have to use syscon and regmap
> i am also not sure how to handle this.
>
>> For DT, I'd expect this is a child node of the sysctrl block with a
>> reg property value of <0x40 4> (along with any other child devices).
>> You could also not even put this in DT and the system controller can
>> have it's own driver that instantiates the child device for this
>> driver.
>
>
> Yes this would be the best practice. But the hardware designer for what ever
> reason
> placed the Register for the temperature sensors into the CGU (Clock
> Generation Unit) section!
> And the Register is also shared with some other stuff which is not only
> assign for temperature
> stuff! I am not sure how to handle this in the device tree.
This is quite common and there are plenty of examples. Look for
bindings with "syscon".
>
> This is a Register description extract from the data sheet
>
> GPHY Configuration Register 01
> This register configures the booting options of GPHY1 IP.
>
> Offset 0x0040
> Reset Value 0x01FC0000
>
> 31: RES
> 30: 100FX_H
> 29: 100FX_F
> 28: 10BT_F
> 27: 10BT_H
> 26: 100BT_F
> 25: 100BT_H
> 24: 1000BT_F
> 23: 1000BT_H
> 22: RES
> 21: RES
> 19: TEMP_PD <--- NEEDED Power down the Temperature Sensor
> 18: TEMP_HL <--- NEEDED Indicate temperature higher than 128 C
> 17: TEMP <--- NEEDED Value
> 16: TEMP <--- NEEDED Value
> 15: TEMP <--- NEEDED Value
> 14: TEMP <--- NEEDED Value
> 13: TEMP <--- NEEDED Value
> 12: TEMP <--- NEEDED Value
> 11: TEMP <--- NEEDED Value
> 10: TEMP <--- NEEDED Value
> 09: TEMP <--- NEEDED Value
> 08: RES
> 07: RES
> 06: SPI_Delay
> 05: SPI_Delay
> 04: AHB_EnD
> 03: DMA_OR
> 02: RES
> 01: RES
> 00: RES
>
> And that is a dts tree from LEDE/Openwrt for lantiq
> URL:
> https://github.com/lede-project/source/blob/c88770c766fdc5599efc4672bca230017f52e8e4/target/linux/lantiq/dts/vr9.dtsi#L54
>
> Extraction:
> sram@1F000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "lantiq,sram", "simple-bus";
> reg = <0x1F000000 0x800000>;
> ranges = <0x0 0x1F000000 0x7FFFFF>;
>
> eiu0: eiu@101000 {
> #interrupt-cells = <1>;
> interrupt-controller;
> compatible = "lantiq,eiu-xway";
> reg = <0x101000 0x1000>;
> interrupt-parent = <&icu0>;
> lantiq,eiu-irqs = <166 135 66 40 41 42>;
> };
>
> pmu0: pmu@102000 {
> compatible = "lantiq,pmu-xway";
> reg = <0x102000 0x1000>;
> };
>
> cgu0: cgu@103000 {
> compatible = "lantiq,cgu-xway";
> reg = <0x103000 0x1000>;
> -> This is the place to add the binding?
Yes.
> };
>
> Sorry for the noise but i am unsure how to do this.
> Thanks for help
>
> Florian